marsupial (Frederich Munch)
User

Projects

User does not belong to any projects.
User Since
Jul 25 2016, 10:43 PM (34 w, 5 d)

Recent Activity

Mon, Mar 20

marsupial updated the diff for D30107: Make DynamicLibrary::getPermanentLibrary have a defined ordering..
Mon, Mar 20, 4:23 PM
marsupial added a comment to D30787: Implement emulated TLS on Windows..

ping

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

ping

Mon, Mar 20, 11:21 AM
marsupial added a comment to D30107: Make DynamicLibrary::getPermanentLibrary have a defined ordering..

ping

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

ping

Mon, Mar 20, 11:21 AM

Mon, Mar 13

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

I don't have commit access...

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

Thu, Mar 9

marsupial created D30787: Implement emulated TLS on Windows..
Thu, Mar 9, 12:25 PM

Tue, Mar 7

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

ping

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

Mon, Mar 6

marsupial added a comment to D30107: Make DynamicLibrary::getPermanentLibrary have a defined ordering..

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.

Mon, Mar 6, 2:13 PM

Wed, Mar 1

marsupial added a comment to D30107: Make DynamicLibrary::getPermanentLibrary have a defined ordering..

Ping.

Wed, Mar 1, 9:12 AM

Feb 23 2017

marsupial added inline comments to D30107: Make DynamicLibrary::getPermanentLibrary have a defined ordering..
Feb 23 2017, 2:54 PM
marsupial updated the diff for D30107: Make DynamicLibrary::getPermanentLibrary have a defined ordering..

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: Make DynamicLibrary::getPermanentLibrary have a defined ordering..
Feb 22 2017, 6:04 PM
marsupial added inline comments to D30107: Make DynamicLibrary::getPermanentLibrary have a defined ordering..
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: Make DynamicLibrary::getPermanentLibrary have a defined ordering..
Feb 21 2017, 8:18 PM
marsupial updated the diff for D30107: Make DynamicLibrary::getPermanentLibrary have a defined ordering..

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: Make DynamicLibrary::getPermanentLibrary have a defined ordering..

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: Make DynamicLibrary::getPermanentLibrary have a defined ordering..

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: Make DynamicLibrary::getPermanentLibrary have a defined ordering..
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: Make DynamicLibrary::getPermanentLibrary have a defined ordering..
Feb 19 2017, 5:52 PM

Feb 17 2017

marsupial added reviewers for D30107: Make DynamicLibrary::getPermanentLibrary have a defined ordering.: davide, chapuni.
Feb 17 2017, 2:31 PM
marsupial updated subscribers of D30107: Make DynamicLibrary::getPermanentLibrary have a defined ordering..
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: Make DynamicLibrary::getPermanentLibrary have a defined ordering..
Feb 17 2017, 2:31 PM
marsupial updated subscribers of D30107: Make DynamicLibrary::getPermanentLibrary have a defined ordering..
Feb 17 2017, 2:31 PM
marsupial abandoned D30055: DynamicLibrary module handles on Windows..
Feb 17 2017, 11:26 AM
marsupial created D30107: Make DynamicLibrary::getPermanentLibrary have a defined ordering..
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