marsupial (Frederich Munch)Email Not Verified
User

Projects

User does not belong to any projects.

User Details

User Since
Jul 25 2016, 10:43 PM (39 w, 5 d)

Recent Activity

Thu, Apr 27

marsupial committed rL301595: Fix a few pedantic warnings..
Fix a few pedantic warnings.
Thu, Apr 27, 3:24 PM
marsupial closed D32611: Fix a few pedantic warnings. by committing rL301595: Fix a few pedantic warnings..
Thu, Apr 27, 3:23 PM
marsupial added reviewers for D32611: Fix a few pedantic warnings.: zturner, hansw.
Thu, Apr 27, 11:47 AM
marsupial created D32611: Fix a few pedantic warnings..
Thu, Apr 27, 11:45 AM
marsupial committed rL301572: Limit disabling of warnings emitted from r301571 by checking __GNUC__..
Limit disabling of warnings emitted from r301571 by checking __GNUC__.
Thu, Apr 27, 11:18 AM
marsupial committed rL301571: Fix warnings from test added in r301562 on Windows (when built without….
Fix warnings from test added in r301562 on Windows (when built without…
Thu, Apr 27, 10:46 AM
marsupial committed rL301562: Refactor DynamicLibrary so searching for a symbol will have a defined order and.
Refactor DynamicLibrary so searching for a symbol will have a defined order and
Thu, Apr 27, 10:08 AM
marsupial closed D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called. by committing rL301562: Refactor DynamicLibrary so searching for a symbol will have a defined order and.
Thu, Apr 27, 10:08 AM

Wed, Apr 26

marsupial committed rL301449: PPCallbacks::MacroUndefined, change signature and add test..
PPCallbacks::MacroUndefined, change signature and add test.
Wed, Apr 26, 1:00 PM
marsupial closed D29923: PPCallbacks::MacroUndefined, change signature and add test. by committing rL301449: PPCallbacks::MacroUndefined, change signature and add test..
Wed, Apr 26, 1:00 PM

Tue, Apr 25

marsupial committed rL301350: [builtins] Implement emulated TLS on Windows..
[builtins] Implement emulated TLS on Windows.
Tue, Apr 25, 12:17 PM
marsupial closed D30787: [builtins] Implement emulated TLS on Windows. by committing rL301350: [builtins] Implement emulated TLS on Windows..
Tue, Apr 25, 12:17 PM
marsupial added inline comments to D30787: [builtins] Implement emulated TLS on Windows..
Tue, Apr 25, 10:30 AM
marsupial updated the diff for D30787: [builtins] Implement emulated TLS on Windows..
Tue, Apr 25, 10:25 AM

Mon, Apr 24

marsupial reopened D30787: [builtins] Implement emulated TLS on Windows..
Mon, Apr 24, 5:55 PM
marsupial updated the diff for D30787: [builtins] Implement emulated TLS on Windows..

Only define atomic operations when not built with clang & compiler-rt.

Mon, Apr 24, 5:55 PM
marsupial reopened D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..

Still looking for a tester for mingw32 on Linux...
Thanks.

Mon, Apr 24, 2:47 PM
marsupial updated the diff for D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..

Fix case sensitive include for mingw on Linux.

Mon, Apr 24, 2:47 PM
marsupial committed rL301240: Revert "Refactor DynamicLibrary so searching for a symbol will have a defined….
Revert "Refactor DynamicLibrary so searching for a symbol will have a defined…
Mon, Apr 24, 1:29 PM
marsupial committed rL301236: Refactor DynamicLibrary so searching for a symbol will have a defined order and.
Refactor DynamicLibrary so searching for a symbol will have a defined order and
Mon, Apr 24, 1:08 PM
marsupial closed D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called. by committing rL301236: Refactor DynamicLibrary so searching for a symbol will have a defined order and.
Mon, Apr 24, 1:08 PM
marsupial added a comment to D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..

Ok, thanks.
I've been able to setup a separate CI that could at least validate the changes compile properly on Ming.
I'll try to land it once more and if it fails again search for someone who can contribute more info.

Mon, Apr 24, 12:56 PM

Sun, Apr 23

marsupial updated the diff for D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..

Ming seems to have EnumProcessModules which will also work on Win32, so only use EnumProcessModulesEx on Win64 (where EnumProcessModules will fail!).

Sun, Apr 23, 10:10 PM
marsupial reopened D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..

This is causing some problems on the mingw32 build, and I'm a bit out of my depth there.
Hopefully the only remaining issue is that EnumProcessModulesEx seems not to be is not available in ming (possibly only the 32 bit version).

Sun, Apr 23, 9:14 PM
marsupial updated the diff for D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..

Fixes for warning on i686-mingw32 bot.

Sun, Apr 23, 9:09 PM
marsupial committed rL301157: Revert "Refactor DynamicLibrary so searching for a symbol will have a defined….
Revert "Refactor DynamicLibrary so searching for a symbol will have a defined…
Sun, Apr 23, 8:46 PM
marsupial committed rL301156: Fix warning converting from boolean to pointer introduced in r301153..
Fix warning converting from boolean to pointer introduced in r301153.
Sun, Apr 23, 8:25 PM
marsupial committed rL301155: Fix warning converting from void* to boolean introduced in r301153..
Fix warning converting from void* to boolean introduced in r301153.
Sun, Apr 23, 8:04 PM
marsupial committed rL301153: Refactor DynamicLibrary so searching for a symbol will have a defined order and.
Refactor DynamicLibrary so searching for a symbol will have a defined order and
Sun, Apr 23, 7:43 PM
marsupial closed D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called. by committing rL301153: Refactor DynamicLibrary so searching for a symbol will have a defined order and.
Sun, Apr 23, 7:43 PM

Sat, Apr 22

marsupial committed rL301089: [builtins] Implement emulated TLS on Windows..
[builtins] Implement emulated TLS on Windows.
Sat, Apr 22, 11:58 AM
marsupial closed D30787: [builtins] Implement emulated TLS on Windows. by committing rL301089: [builtins] Implement emulated TLS on Windows..
Sat, Apr 22, 11:58 AM
marsupial updated the diff for D30787: [builtins] Implement emulated TLS on Windows..

Rebase to master

Sat, Apr 22, 11:01 AM
marsupial abandoned D32390: [builtins] Implement emulated TLS on Windows..
Sat, Apr 22, 10:59 AM
marsupial created D32390: [builtins] Implement emulated TLS on Windows..
Sat, Apr 22, 10:56 AM

Fri, Apr 21

marsupial committed rL301046: [Test commit] Remove extra newline..
[Test commit] Remove extra newline.
Fri, Apr 21, 2:52 PM
marsupial updated the diff for D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..

Thanks.
I've added the line for CMake and rebased against master.
The changes from https://reviews.llvm.org/rL299203 seem unnecessary, but will wait a few days for a response on that.

Fri, Apr 21, 10:42 AM
marsupial added a comment to rL299203: Do not pollute the namespace in a header file..

Hello. I've authored changes in the same area that are now conflicting with this.
https://reviews.llvm.org/D30107

Fri, Apr 21, 10:25 AM

Mar 20 2017

marsupial updated the diff for D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..
Mar 20 2017, 4:23 PM
marsupial added a comment to D30787: [builtins] Implement emulated TLS on Windows..

ping

Mar 20 2017, 11:22 AM
marsupial added a comment to D29923: PPCallbacks::MacroUndefined, change signature and add test..

ping

Mar 20 2017, 11:21 AM
marsupial added a comment to D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..

ping

Mar 20 2017, 11:21 AM
marsupial added a comment to D30709: Handle IMAGE_REL_AMD64_ADDR32NB in RuntimeDyldCOFF.

ping

Mar 20 2017, 11:21 AM

Mar 13 2017

marsupial added a comment to D30787: [builtins] Implement emulated TLS on Windows..

I don't have commit access...

Mar 13 2017, 5:01 PM
marsupial updated the diff for D29923: PPCallbacks::MacroUndefined, change signature and add test..
Mar 13 2017, 3:01 PM
marsupial updated the diff for D29923: PPCallbacks::MacroUndefined, change signature and add test..
Mar 13 2017, 8:02 AM

Mar 9 2017

marsupial created D30787: [builtins] Implement emulated TLS on Windows..
Mar 9 2017, 12:25 PM

Mar 7 2017

marsupial added a comment to D29923: PPCallbacks::MacroUndefined, change signature and add test..

ping

Mar 7 2017, 11:22 AM
marsupial created D30709: Handle IMAGE_REL_AMD64_ADDR32NB in RuntimeDyldCOFF.
Mar 7 2017, 11:19 AM

Mar 6 2017

marsupial added a comment to D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..

I was asked to make the changes that grew it in size.
There doesn't seem to be an -easy- way to fix the issues at hand for a couple of reasons.
Just fixing the iteration order by using rbegin and rend is not enough, as the storage in a set is also a culprit.
Just fixing the Windows portion, means differing (and still broken) behavior on Unix.
The remaining broken behaviour on Unix means that the test cannot be added.

Mar 6 2017, 2:13 PM

Mar 1 2017

marsupial added a comment to D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..

Ping.

Mar 1 2017, 9:12 AM

Feb 23 2017

marsupial added inline comments to D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..
Feb 23 2017, 2:54 PM
marsupial updated the diff for D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..

Refactor platform specific code.
Remove Windows caching of libraries.
Add tests.

Feb 23 2017, 2:46 PM

Feb 22 2017

marsupial added inline comments to D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..
Feb 22 2017, 6:04 PM
marsupial added inline comments to D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..
Feb 22 2017, 5:46 PM
marsupial added a comment to D29955: Allow externally dlopen-ed libraries to be registered as permanent libraries..

Yeah, I didn't mean to create more work for you in D30107! The 'with-lock' helper seemed like the right solution here, and I have still have some questions/comments about D30107, hence the lgtm.

It shouldn't be that much work integrating it...was just saying as the addPermanentLibraryWithLock is a bit ugly and would go away anyway.

Feb 22 2017, 5:24 PM
marsupial added a comment to D29955: Allow externally dlopen-ed libraries to be registered as permanent libraries..

FWIW applying D30107 before this would mean addPermanentLibraryWithLock would no longer be necessary.

Feb 22 2017, 9:51 AM

Feb 21 2017

marsupial updated the summary of D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..
Feb 21 2017, 8:18 PM
marsupial updated the diff for D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..

Store and search for symbols the same way on Unix (in reverse and giving priority to the owning process' symbols).

Feb 21 2017, 12:43 PM
marsupial updated the diff for D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..

The problem of undefined ordering was affecting Unix as well so moved to using an llvm::SetVector there.
Updated diff to latest changes.

Feb 21 2017, 12:02 PM

Feb 20 2017

marsupial updated the diff for D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..

Wound up splitting most of it into a separate class. Predominately so ManagedStatic can reinitialize properly if necessary, but seems to provide a nicer separation and less code duplication when D29955 adds addPermanentLibrary

Feb 20 2017, 10:16 PM
marsupial added a comment to D30178: Do not leak OpenedHandles.

Ok, point taken about llvm_shutdown...I'll change it over there.

Feb 20 2017, 7:31 PM
marsupial added a comment to D30178: Do not leak OpenedHandles.

I get what ManagedStatic is supposed to be doing, but versus using a std::unique_ptr the cost seems more with it (both in terms of size and startup time).
But I guess that conversation would add a bit of noise and doesn't have much to do with this patch.

Feb 20 2017, 6:50 PM
marsupial added inline comments to D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..
Feb 20 2017, 4:29 PM
marsupial added a comment to D30178: Do not leak OpenedHandles.

Believe it is fixed in my patch: allocating into a std::unique_ptr which should auto-destruct the contents on exit.
The ManagedStatic docs seems to talk about startup time, but I find it hard to believe that allocating space for a single pointer would be slower than the three it allocates plus other internals.

Feb 20 2017, 2:29 PM
marsupial added a comment to D29955: Allow externally dlopen-ed libraries to be registered as permanent libraries..

This is somewhat related to something I've been trying to get reviewed here: https://reviews.llvm.org/D30107
I think there is a serious problem with DynamicLibrary::getPermanentLibrary on Windows.
I believe D30107 handles the memory leak as well.

Feb 20 2017, 11:38 AM

Feb 19 2017

marsupial updated the summary of D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..
Feb 19 2017, 5:52 PM

Feb 17 2017

marsupial added reviewers for D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called.: davide, chapuni.
Feb 17 2017, 2:31 PM
marsupial updated subscribers of D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..
Feb 17 2017, 2:31 PM
marsupial updated the summary of D29923: PPCallbacks::MacroUndefined, change signature and add test..
Feb 17 2017, 2:31 PM
marsupial updated subscribers of D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..
Feb 17 2017, 2:31 PM
marsupial updated subscribers of D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..
Feb 17 2017, 2:31 PM
marsupial abandoned D30055: DynamicLibrary module handles on Windows..
Feb 17 2017, 11:26 AM
marsupial created D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called..
Feb 17 2017, 11:25 AM
marsupial updated the diff for D30055: DynamicLibrary module handles on Windows..
Feb 17 2017, 11:01 AM
marsupial added reviewers for D30055: DynamicLibrary module handles on Windows.: davide, chapuni.
Feb 17 2017, 10:06 AM

Feb 16 2017

marsupial updated the diff for D30055: DynamicLibrary module handles on Windows..
Feb 16 2017, 7:54 PM
marsupial updated the diff for D29923: PPCallbacks::MacroUndefined, change signature and add test..

Added test for un-definition callback.

Feb 16 2017, 6:30 PM
marsupial created D30055: DynamicLibrary module handles on Windows..
Feb 16 2017, 2:41 PM

Feb 14 2017

marsupial added a comment to D29923: PPCallbacks::MacroUndefined, change signature and add test..

I need notification that a macro has been undefined. It's equally as important as a when it was defined.
I'll happily make a test case but want to make sure this would get in before doing so.

Feb 14 2017, 11:02 AM

Feb 13 2017

marsupial created D29923: PPCallbacks::MacroUndefined, change signature and add test..
Feb 13 2017, 8:17 PM

Aug 18 2016

marsupial added a comment to D22797: Fix for compiling with clang <= 3.7 and g++6 headers..

The problem is either libstd++ tuple or clang's parsing of it. The second or third comment in this thread is the output log.
The result is someone on clang-3.7 and gcc6 has no way to upgrade their install.
In particular I need to compile LLVM/clang for their libraries not clang itself and it is not possible to do so currently.

Aug 18 2016, 5:45 PM

Aug 14 2016

marsupial added a comment to D22797: Fix for compiling with clang <= 3.7 and g++6 headers..

Linking works fine, it's just a compilation issue.
Seems a nice thing for someone on 3.7 to be able to compile 3.9.
I certainly need to.

Aug 14 2016, 9:29 PM

Aug 13 2016

marsupial added a reviewer for D22797: Fix for compiling with clang <= 3.7 and g++6 headers.: alexfh.
Aug 13 2016, 5:09 AM

Aug 8 2016

marsupial added a comment to D22797: Fix for compiling with clang <= 3.7 and g++6 headers..

Any further thoughts?

Aug 8 2016, 12:44 PM

Aug 2 2016

marsupial added a comment to D22797: Fix for compiling with clang <= 3.7 and g++6 headers..

Found one:

In file included from ../../lib/CodeGen/LexicalScopes.cpp:17:
In file included from ../../include/llvm/CodeGen/LexicalScopes.h:20:
In file included from ../../include/llvm/ADT/ArrayRef.h:13:
In file included from ../../include/llvm/ADT/Hashing.h:49:
In file included from ../../include/llvm/Support/Host.h:17:
In file included from ../../include/llvm/ADT/StringMap.h:18:
In file included from ../../include/llvm/Support/Allocator.h:24:
In file included from ../../include/llvm/ADT/SmallVector.h:29:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/memory:79:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/functional:55:
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:1400:14: error: 
      no matching constructor for initialization of 'tuple<llvm::LexicalScope
      *&&, const llvm::DILocalScope *&&, nullptr_t &&, bool &&>'
    { return tuple<_Elements&&...>(std::forward<_Elements>(__args)...); }
             ^                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/CodeGen/LexicalScopes.cpp:155:36: note: in instantiation of function
      template specialization 'std::forward_as_tuple<llvm::LexicalScope *&,
      const llvm::DILocalScope *&, nullptr_t, bool>' requested here
                              std::forward_as_tuple(Parent, Scope, nullptr,
                                   ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:600:18: note: 
      candidate template ignored: disabled by 'enable_if' [with _Dummy = void]
                 _TCC<_Dummy>::template
                 ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:611:18: note: 
      candidate template ignored: disabled by 'enable_if' [with _Dummy = void]
                 _TCC<_Dummy>::template
                 ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:628:5: note: 
      candidate template ignored: disabled by 'enable_if' [with _UElements =
      <llvm::LexicalScope *&, const llvm::DILocalScope *&, nullptr_t, bool>]
                  _TC<sizeof...(_UElements) == 1, _Elements...>::template
                  ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:641:5: note: 
      candidate template ignored: disabled by 'enable_if' [with _UElements =
      <llvm::LexicalScope *&, const llvm::DILocalScope *&, nullptr_t, bool>]
                  _TC<sizeof...(_UElements) == 1, _Elements...>::template
                  ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:737:19: note: 
      candidate template ignored: disabled by 'enable_if' [with _Alloc = const
      llvm::DILocalScope *, _UElements = <nullptr_t, bool>]
        enable_if<_TMC<_UElements...>::template
                  ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:748:19: note: 
      candidate template ignored: disabled by 'enable_if' [with _Alloc = const
      llvm::DILocalScope *, _UElements = <nullptr_t, bool>]
        enable_if<_TMC<_UElements...>::template
                  ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:579:17: note: 
      candidate constructor template not viable: requires 0 arguments, but 4
      were provided
      constexpr tuple()
                ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:589:26: note: 
      candidate constructor template not viable: requires 0 arguments, but 4
      were provided
      explicit constexpr tuple()
                         ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:670:19: note: 
      candidate constructor template not viable: requires single argument
      '__in', but 4 arguments were provided
        constexpr tuple(const tuple<_UElements...>& __in)
                  ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:682:28: note: 
      candidate constructor template not viable: requires single argument
      '__in', but 4 arguments were provided
        explicit constexpr tuple(const tuple<_UElements...>& __in)
                           ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:694:19: note: 
      candidate constructor template not viable: requires single argument
      '__in', but 4 arguments were provided
        constexpr tuple(tuple<_UElements...>&& __in)
                  ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:705:28: note: 
      candidate constructor template not viable: requires single argument
      '__in', but 4 arguments were provided
        explicit constexpr tuple(tuple<_UElements...>&& __in)
                           ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:721:2: note: 
      candidate constructor template not viable: requires 6 arguments, but 4
      were provided
        tuple(allocator_arg_t __tag, const _Alloc& __a,
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:732:11: note: 
      candidate constructor template not viable: requires 6 arguments, but 4
      were provided
        explicit tuple(allocator_arg_t __tag, const _Alloc& __a,
                 ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:711:2: note: 
      candidate constructor template not viable: requires 2 arguments, but 4
      were provided
        tuple(allocator_arg_t __tag, const _Alloc& __a)
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:759:2: note: 
      candidate constructor template not viable: requires 3 arguments, but 4
      were provided
        tuple(allocator_arg_t __tag, const _Alloc& __a, const tuple& __in)
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:763:2: note: 
      candidate constructor template not viable: requires 3 arguments, but 4
      were provided
        tuple(allocator_arg_t __tag, const _Alloc& __a, tuple&& __in)
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:772:2: note: 
      candidate constructor template not viable: requires 3 arguments, but 4
      were provided
        tuple(allocator_arg_t __tag, const _Alloc& __a,
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:784:11: note: 
      candidate constructor template not viable: requires 3 arguments, but 4
      were provided
        explicit tuple(allocator_arg_t __tag, const _Alloc& __a,
                 ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:796:2: note: 
      candidate constructor template not viable: requires 3 arguments, but 4
      were provided
        tuple(allocator_arg_t __tag, const _Alloc& __a,
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:808:11: note: 
      candidate constructor template not viable: requires 3 arguments, but 4
      were provided
        explicit tuple(allocator_arg_t __tag, const _Alloc& __a,
                 ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:654:17: note: 
      candidate constructor not viable: requires 1 argument, but 4 were provided
      constexpr tuple(tuple&&) = default; 
                ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:652:17: note: 
      candidate constructor not viable: requires 1 argument, but 4 were provided
      constexpr tuple(const tuple&) = default;
                ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:1400:14: error: 
      no matching constructor for initialization of 'tuple<llvm::LexicalScope
      *&&, const llvm::DILocalScope *&&, const llvm::DILocation *&&, bool &&>'
    { return tuple<_Elements&&...>(std::forward<_Elements>(__args)...); }
             ^                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/CodeGen/LexicalScopes.cpp:186:43: note: in instantiation of function
      template specialization 'std::forward_as_tuple<llvm::LexicalScope *&,
      const llvm::DILocalScope *&, const llvm::DILocation *&, bool>' requested
      here
                                     std::forward_as_tuple(Parent, Scope,
                                          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:600:18: note: 
      candidate template ignored: disabled by 'enable_if' [with _Dummy = void]
                 _TCC<_Dummy>::template
                 ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:611:18: note: 
      candidate template ignored: disabled by 'enable_if' [with _Dummy = void]
                 _TCC<_Dummy>::template
                 ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:628:5: note: 
      candidate template ignored: disabled by 'enable_if' [with _UElements =
      <llvm::LexicalScope *&, const llvm::DILocalScope *&, const
      llvm::DILocation *&, bool>]
                  _TC<sizeof...(_UElements) == 1, _Elements...>::template
                  ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:641:5: note: 
      candidate template ignored: disabled by 'enable_if' [with _UElements =
      <llvm::LexicalScope *&, const llvm::DILocalScope *&, const
      llvm::DILocation *&, bool>]
                  _TC<sizeof...(_UElements) == 1, _Elements...>::template
                  ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:737:19: note: 
      candidate template ignored: disabled by 'enable_if' [with _Alloc = const
      llvm::DILocalScope *, _UElements = <const llvm::DILocation *&, bool>]
        enable_if<_TMC<_UElements...>::template
                  ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:748:19: note: 
      candidate template ignored: disabled by 'enable_if' [with _Alloc = const
      llvm::DILocalScope *, _UElements = <const llvm::DILocation *&, bool>]
        enable_if<_TMC<_UElements...>::template
                  ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:579:17: note: 
      candidate constructor template not viable: requires 0 arguments, but 4
      were provided
      constexpr tuple()
                ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:589:26: note: 
      candidate constructor template not viable: requires 0 arguments, but 4
      were provided
      explicit constexpr tuple()
                         ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:670:19: note: 
      candidate constructor template not viable: requires single argument
      '__in', but 4 arguments were provided
        constexpr tuple(const tuple<_UElements...>& __in)
                  ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:682:28: note: 
      candidate constructor template not viable: requires single argument
      '__in', but 4 arguments were provided
        explicit constexpr tuple(const tuple<_UElements...>& __in)
                           ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:694:19: note: 
      candidate constructor template not viable: requires single argument
      '__in', but 4 arguments were provided
        constexpr tuple(tuple<_UElements...>&& __in)
                  ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:705:28: note: 
      candidate constructor template not viable: requires single argument
      '__in', but 4 arguments were provided
        explicit constexpr tuple(tuple<_UElements...>&& __in)
                           ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:721:2: note: 
      candidate constructor template not viable: requires 6 arguments, but 4
      were provided
        tuple(allocator_arg_t __tag, const _Alloc& __a,
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:732:11: note: 
      candidate constructor template not viable: requires 6 arguments, but 4
      were provided
        explicit tuple(allocator_arg_t __tag, const _Alloc& __a,
                 ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:711:2: note: 
      candidate constructor template not viable: requires 2 arguments, but 4
      were provided
        tuple(allocator_arg_t __tag, const _Alloc& __a)
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:759:2: note: 
      candidate constructor template not viable: requires 3 arguments, but 4
      were provided
        tuple(allocator_arg_t __tag, const _Alloc& __a, const tuple& __in)
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:763:2: note: 
      candidate constructor template not viable: requires 3 arguments, but 4
      were provided
        tuple(allocator_arg_t __tag, const _Alloc& __a, tuple&& __in)
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:772:2: note: 
      candidate constructor template not viable: requires 3 arguments, but 4
      were provided
        tuple(allocator_arg_t __tag, const _Alloc& __a,
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:784:11: note: 
      candidate constructor template not viable: requires 3 arguments, but 4
      were provided
        explicit tuple(allocator_arg_t __tag, const _Alloc& __a,
                 ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:796:2: note: 
      candidate constructor template not viable: requires 3 arguments, but 4
      were provided
        tuple(allocator_arg_t __tag, const _Alloc& __a,
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:808:11: note: 
      candidate constructor template not viable: requires 3 arguments, but 4
      were provided
        explicit tuple(allocator_arg_t __tag, const _Alloc& __a,
                 ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:654:17: note: 
      candidate constructor not viable: requires 1 argument, but 4 were provided
      constexpr tuple(tuple&&) = default; 
                ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:652:17: note: 
      candidate constructor not viable: requires 1 argument, but 4 were provided
      constexpr tuple(const tuple&) = default;
                ^
../../lib/CodeGen/LexicalScopes.cpp:208:32: error: no matching function for call
      to 'forward_as_tuple'
                               std::forward_as_tuple(Parent, Scope,
                               ^~~~~~~~~~~~~~~~~~~~~
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:1399:5: note: 
      candidate template ignored: substitution failure [with _Elements =
      <llvm::LexicalScope *&, const llvm::DILocalScope *&, nullptr_t, bool>]
    forward_as_tuple(_Elements&&... __args) noexcept
Aug 2 2016, 9:47 AM

Aug 1 2016

marsupial added a comment to D22797: Fix for compiling with clang <= 3.7 and g++6 headers..

It's definitely a bit more intrusive than I'd like, but was the only thing that worked.
The log's have been overwritten by now, but easily reproduced with gcc-6 and clang-3.7.
The arguments forwarded to LexicalScope::LexicalScope were not being resolving properly.

Aug 1 2016, 6:25 PM

Jul 28 2016

marsupial updated D22797: Fix for compiling with clang <= 3.7 and g++6 headers..
Jul 28 2016, 10:25 AM

Jul 26 2016

marsupial added a comment to D22798: Fix for compiling with clang <= 3.7 and g++6 headers..

Would be nice...I have no commit access.
https://reviews.llvm.org/D22797 Is the LLVM portion, if they should land together

Jul 26 2016, 7:48 PM

Jul 25 2016

marsupial added a dependency for D22797: Fix for compiling with clang <= 3.7 and g++6 headers.: D22798: Fix for compiling with clang <= 3.7 and g++6 headers..
Jul 25 2016, 11:01 PM
marsupial added a dependent revision for D22798: Fix for compiling with clang <= 3.7 and g++6 headers.: D22797: Fix for compiling with clang <= 3.7 and g++6 headers..
Jul 25 2016, 11:01 PM
marsupial retitled D22798: Fix for compiling with clang <= 3.7 and g++6 headers. from to Fix for compiling with clang <= 3.7 and g++6 headers..
Jul 25 2016, 11:00 PM
marsupial added a reviewer for D22797: Fix for compiling with clang <= 3.7 and g++6 headers.: dexonsmith.
Jul 25 2016, 10:53 PM
marsupial retitled D22797: Fix for compiling with clang <= 3.7 and g++6 headers. from to Fix for compiling with clang <= 3.7 and g++6 headers..
Jul 25 2016, 10:49 PM