1. 19 Apr, 2019 1 commit
  2. 17 Apr, 2019 2 commits
  3. 16 Apr, 2019 3 commits
  4. 15 Apr, 2019 1 commit
  5. 13 Apr, 2019 2 commits
  6. 08 Apr, 2019 1 commit
  7. 06 Apr, 2019 1 commit
    • Add cstdlib include · 0aea3106
      Daniel Koch authored
      On some platforms some of the includers of this header don't have
      'atoi' defined after the change in #1749
  8. 05 Apr, 2019 1 commit
  9. 04 Apr, 2019 3 commits
  10. 03 Apr, 2019 2 commits
  11. 02 Apr, 2019 1 commit
    • build: Don't ship GTEST headers in install target · 1d1fd885
      Karl Schultz authored
      A project that uses googletest(GTEST) shouldn't include googletest
      headers with its artifacts in its install target.  These headers
      simply are not needed by the consumers of the install target and
      can cause conflicts with other projects that use googletest
      themselves and this project's install target.  And they are just not
      part of the expected glslang build artifacts.
      
      It is likely that the addition of the googletest headers to the install
      target was a simple oversight that happens as a result of adding
      googletest as a CMake subdirectory.
      
      For more information on how this causes conflicts with other projects,
      please see: https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/821.
  12. 28 Mar, 2019 1 commit
  13. 27 Mar, 2019 3 commits
  14. 26 Mar, 2019 2 commits
  15. 19 Mar, 2019 2 commits
  16. 18 Mar, 2019 5 commits
  17. 17 Mar, 2019 1 commit
  18. 12 Mar, 2019 3 commits
  19. 11 Mar, 2019 1 commit
  20. 07 Mar, 2019 2 commits
  21. 06 Mar, 2019 2 commits
    • Move getBufferReferenceAlignment to be a method of TType · 7895e473
      Jeff Bolz authored
      This is a better place for it logically, since it is not specific to
      glsl->spirv translation. And in a future change I want to use it outside
      of glslangtospv.
    • Improved fix for buffer reference constants · 3fd12326
      Jeff Bolz authored
      This is an alternate fix for the issue described in commit be63facd, whose
      solution didn't work if there were non-trivial operations involved in computing
      a constant initializer which caused the 'constant unfolding' code to kick in
      (addConstantReferenceConversion). Instead, this change does the 'unfolding'
      later in createSpvConstantFromConstUnionArray. If a reference-type constant has
      survived that long, then folding is already done, this must be a 'real' (inside
      a function) use of the constant, and it should be safe to unfold and apply the
      bitcast.