Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

include by relative path, so root doesn't need to be in the search path #4

Merged
merged 1 commit into from
Jul 11, 2015
Merged

include by relative path, so root doesn't need to be in the search path #4

merged 1 commit into from
Jul 11, 2015

Conversation

baldurk
Copy link
Contributor

@baldurk baldurk commented Jul 8, 2015

I'm not sure if this is desired, but I've made some changes so that glslang doesn't depend any directories being in the include search path (which is default for building the project, but isn't so desirable when including glslang in a larger project).

On a related but separate note - the same include path requirement is true for osinclude.h. The include search path needs to be set up to point to either glslang/OSDependent/Linux or glslang/OSDependent/Windows on their respective platforms. I've changed this locally so that osinclude.h is included relatively like so:

#include "../glslang/OSDependent/osinclude.h"

and that file just contains a simple redirect based on platform macros:

#if defined(WIN32)
#include "Windows/osinclude.h"
#elif defined(__linux__)
#include "Linux/osinclude.h"
#else
#error "Unknown platform"
#endif

If that's desirable to have upstream then let me know and I can make a pull request, but otherwise I'll just keep the change locally.

johnkslang added a commit that referenced this pull request Jul 11, 2015
@johnkslang
Merge pull request #4 from baldurk/relative-include-paths
1f654e1 
include by relative path, so root doesn't need to be in the search path
@johnkslang johnkslang merged commit 1f654e1 into KhronosGroup:master Jul 11, 2015
@johnkslang
Copy link
Member

I think simplifying the integration into other projects is worthwhile. (Wish the file structure was less archaic, but it's working and changing it would break some things.) Feel free to make a pull request for the osinclude.h improvement.

Thanks

@baldurk baldurk deleted the relative-include-paths branch November 16, 2015 16:48
@fluxlalonde fluxlalonde mentioned this pull request Mar 28, 2017
Closed
@ajaybedi ajaybedi mentioned this pull request Jun 30, 2017
Closed
@infapi00 infapi00 mentioned this pull request Sep 19, 2018
Closed
glebm added a commit to glebm/glslang that referenced this pull request Jan 30, 2021
@glebm
callGraph.push_front -> emplace_front to fix UBSAN
7c546cd 
UBSAN rightly complains on `push_front`:

    glslang/MachineIndependent/localintermediate.h:100:8: runtime error: load of value 160, which is not a valid value for type 'bool'
    #0 in glslang::TCall::TCall(glslang::TCall&&) glslang/MachineIndependent/localintermediate.h:100
    KhronosGroup#1 in void __gnu_cxx::new_allocator<std::_List_node<glslang::TCall> >::construct<glslang::TCall, glslang::TCall>(glslang::TCall*, glslang::TCall&&) /usr/include/c++/10/ext/new_allocator.h:150
    KhronosGroup#2 in void std::allocator_traits<std::allocator<std::_List_node<glslang::TCall> > >::construct<glslang::TCall, glslang::TCall>(std::allocator<std::_List_node<glslang::TCall> >&, glslang::TCall*, glslang::TCall&&) /usr/include/c++/10/bits/alloc_traits.h:512
    KhronosGroup#3 in std::_List_node<glslang::TCall>* std::__cxx11::list<glslang::TCall, std::allocator<glslang::TCall> >::_M_create_node<glslang::TCall>(glslang::TCall&&) (...)
    KhronosGroup#4 in void std::__cxx11::list<glslang::TCall, std::allocator<glslang::TCall> >::_M_insert<glslang::TCall>(std::_List_iterator<glslang::TCall>, glslang::TCall&&) /usr/include/c++/10/bits/stl_list.h:1911
    KhronosGroup#5 in std::__cxx11::list<glslang::TCall, std::allocator<glslang::TCall> >::push_front(glslang::TCall&&) /usr/include/c++/10/bits/stl_list.h:1167
    KhronosGroup#6 in glslang::TIntermediate::addToCallGraph(TInfoSink&, std::__cxx11::basic_string<char, std::char_traits<char>, glslang::pool_allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, glslang::pool_allocator<char> > const&) glslang/MachineIndependent/Intermediate.cpp:2860

What happens here:

1. TCall's bool fields are not initialized on construction.
2. `push_front` move the `TCall` passed into it.
3. The move constructor copies unitialized bool, which may have an
   out-of-range value.

What this fix does:

Calls `emplace_back` to ensure no copy/move constructor is called.

Fixes KhronosGroup#2222
Refs KhronosGroup#2112
glebm added a commit to glebm/glslang that referenced this pull request Jan 30, 2021
@glebm
callGraph.push_front -> emplace_front to fix UBSAN
546f626 
UBSAN rightly complains on `push_front` here:

    glslang/MachineIndependent/localintermediate.h:100:8: runtime error: load of value 160, which is not a valid value for type 'bool'
    #0 in glslang::TCall::TCall(glslang::TCall&&) glslang/MachineIndependent/localintermediate.h:100
    KhronosGroup#1 in void __gnu_cxx::new_allocator<std::_List_node<glslang::TCall> >::construct<glslang::TCall, glslang::TCall>(glslang::TCall*, glslang::TCall&&) /usr/include/c++/10/ext/new_allocator.h:150
    KhronosGroup#2 in void std::allocator_traits<std::allocator<std::_List_node<glslang::TCall> > >::construct<glslang::TCall, glslang::TCall>(std::allocator<std::_List_node<glslang::TCall> >&, glslang::TCall*, glslang::TCall&&) /usr/include/c++/10/bits/alloc_traits.h:512
    KhronosGroup#3 in std::_List_node<glslang::TCall>* std::__cxx11::list<glslang::TCall, std::allocator<glslang::TCall> >::_M_create_node<glslang::TCall>(glslang::TCall&&) (...)
    KhronosGroup#4 in void std::__cxx11::list<glslang::TCall, std::allocator<glslang::TCall> >::_M_insert<glslang::TCall>(std::_List_iterator<glslang::TCall>, glslang::TCall&&) /usr/include/c++/10/bits/stl_list.h:1911
    KhronosGroup#5 in std::__cxx11::list<glslang::TCall, std::allocator<glslang::TCall> >::push_front(glslang::TCall&&) /usr/include/c++/10/bits/stl_list.h:1167
    KhronosGroup#6 in glslang::TIntermediate::addToCallGraph(TInfoSink&, std::__cxx11::basic_string<char, std::char_traits<char>, glslang::pool_allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, glslang::pool_allocator<char> > const&) glslang/MachineIndependent/Intermediate.cpp:2860

What happens here:

1. TCall's bool fields are not initialized on construction.
2. `push_front` move the `TCall` passed into it.
3. The move constructor copies unitialized bool, which may have an
   out-of-range value.

What this fix does:

Calls `emplace_back` to ensure no copy/move constructor is called.

Fixes KhronosGroup#2222
Refs KhronosGroup#2112
@ianelliottus ianelliottus mentioned this pull request Mar 9, 2021
Closed
jsmall-zzz added a commit to jsmall-zzz/glslang that referenced this pull request Oct 5, 2021
@jsmall-zzz
Merge pull request KhronosGroup#4 from jsmall-nvidia/feature/glslang-…
27bbb4a 
…11.16.0+

Upgrade to GLSLANG 11.6.0+
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@baldurk @johnkslang