[Bug c++/111419] New: Eager instantiation of function return type in concept causes compilation error

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code fails to compile on GCC: template

[Bug c++/103511] __builtin_bit_cast requires a constructor call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103511 --- Comment #5 from Louis Dionne --- Note that my claim about TriviallyCopyable is taken from the Standard here, for reference (even though Jason probably knows this by heart :-). https://eel.is/c++draft/class.prop#1: > A trivially copyable

[Bug c++/103511] __builtin_bit_cast requires a constructor call

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103511 Louis Dionne changed: What|Removed |Added CC||ldionne.2 at gmail dot com --- Comment

[Bug c++/110000] GCC should implement exclude_from_explicit_instantiation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11 --- Comment #13 from Louis Dionne --- Nikolas already answered some, but just to expand on this: > But on the topic of this enhancement request, I don't see why functions > should be excluded from explicit instantiation if they're already

[Bug c++/110000] GCC should implement exclude_from_explicit_instantiation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11 --- Comment #9 from Louis Dionne --- (In reply to Andrew Pinski from comment #3) > I am getting a feeling this attribute is well defined enough. > > Is it really just supposed to block explicit instantiation of templates? > Is there a decent

[Bug c++/110000] GCC should implement exclude_from_explicit_instantiation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11 Louis Dionne changed: What|Removed |Added CC||ldionne.2 at gmail dot com --- Comment

[Bug bootstrap/107795] recursion through breaks non-GNU implementations of the C++ stdlib

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107795 --- Comment #13 from Louis Dionne --- Let me rephrase my whole request here. I understand that what GCC does work for GCC and GCC-adjacent projects. This report is about making the behavior of more friendly to implementations that are not

[Bug bootstrap/107795] recursion through breaks non-GNU implementations of the C++ stdlib

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107795 --- Comment #11 from Louis Dionne --- (In reply to Andrew Pinski from comment #9) > > GCC version specific includes > GCC version specific fixincludes > C library > includes > > That is for C. > C++ is: > libstdc++ library includes > ...

[Bug bootstrap/107795] recursion through breaks non-GNU implementations of the C++ stdlib

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107795 --- Comment #8 from Louis Dionne --- (In reply to Andrew Pinski from comment #5) > (In reply to Louis Dionne from comment #4) > > (In reply to Andrew Pinski from comment #2) > > > You should not be building on top of GCC's limits.h header at

[Bug bootstrap/107795] recursion through breaks non-GNU implementations of the C++ stdlib

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107795 --- Comment #4 from Louis Dionne --- (In reply to Andrew Pinski from comment #2) > You should not be building on top of GCC's limits.h header at all really. > Rather implementations should have their own. What do you mean by "implementations"?

[Bug libstdc++/107795] New: recursion through breaks non-GNU implementations of the C++ stdlib

Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The header currently includes "syslimits.h", which then recursively includes after defining the _GCC_NEXT_LIMI

[Bug libstdc++/48101] obscure error message with std::set

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48101 Louis Dionne changed: What|Removed |Added CC||ldionne.2 at gmail dot com --- Comment

[Bug c++/104760] Attribute [[deprecated]] causes diagnostic in never-instantiated template

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104760 --- Comment #3 from Louis Dionne --- (In reply to Marek Polacek from comment #2) > And I think this is the same problem as in > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911#c18. Not sure if we want > to change anything. Yup, I agree

[Bug c++/33911] attribute deprecated vs. templates

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911 Louis Dionne changed: What|Removed |Added CC||ldionne.2 at gmail dot com --- Comment

[Bug c++/104760] New: Attribute [[deprecated]] causes diagnostic in never-instantiated template

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- When using the [[deprecated]] attribute on a class template, a diagnostic is produced even if that class template is never

[Bug c++/70816] bogus error __builtin_strcmp is not a constant expression in a constexpr function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70816 Louis Dionne changed: What|Removed |Added CC||ldionne.2 at gmail dot com --- Comment

[Bug c++/102247] New: Overload resolution with brace-init is ambiguous when it shouldn't be

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code fails to compile when I believe it should succeed (https://godbolt.org/z/z9aved8Wb): #include

[Bug c++/97675] GCC does not allow turning off the warning for exceptions being caught by an earlier handler

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97675 --- Comment #3 from Louis Dionne --- Thanks a lot!

[Bug c++/97675] New: GCC does not allow turning off the warning for exceptions being caught by an earlier handler

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- In the LLVM libc++abi test suite, we test that an exception of type 'Child' is being caught by an earlier

[Bug c++/94745] No error emitted for unknown -Wno-meow argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94745 --- Comment #4 from Louis Dionne --- Thanks for your replies, all. We resolved the problem on our side by not trying to workaround the lack of error, which means that we might end up passing `-Wno-foo` to GCC when it's not supported. I think

[Bug c++/94745] New: No error emitted for unknown -Wno-meow argument

++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- GCC does not diagnose unsupported -Wno-meow command line flags unless another error happens during compilation. For example, the following compiles just fine even though -Wno

[Bug driver/94198] New: Placement of source file in GCC command line has impact on whether the link succeeds

Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- It seems that the position where the source file is specified to GCC has an impact on how it is linked when other

[Bug c++/88453] New: GCC pretends that constexpr default-constructible type is nothrow constructible

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code does not compile with GCC trunk

[Bug c++/67164] ICE: tree check: expected class ‘expression’, have ‘exceptional’ (argument_pack_select) in tree_operand_check, at tree.h:3356

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67164 --- Comment #14 from Louis Dionne --- I think so -- all the reproducers posted in this bug report can compile with GCC trunk.

[Bug c++/85659] New: ICE with inline assembly inside virtual function

: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following program causes an ICE with GCC 6.1.0 and up. GCC 5.5.0 compiles this fine

[Bug libstdc++/82156] New: [7/8 regression] Atomic is_lock_free is not true for 16 byte type

Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code prints true on GCC 4.x, 5.x and 6.x, but not on GCC 7.x and trunk: #include #include #include

[Bug c++/82047] non-existent variable template used to initialize variable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82047 --- Comment #7 from Louis Dionne --- Then, I think there's another bug in GCC (or maybe just a QOI issue), since the following code compiles (wandbox[1]): template constexpr T v; template constexpr T v(888); struct S { constexpr

[Bug c++/82047] non-existent variable template used to initialize variable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82047 Louis Dionne changed: What|Removed |Added CC||ldionne.2 at gmail dot com --- Comment

[Bug c++/82000] Missed optimization of char_traits::length() on constant string

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82000 --- Comment #2 from Louis Dionne --- > The example you wrote in the bug report makes no sense: missing includes, and > with the includes added it optimizes to return 0. Sorry, I did not mean the example I pasted here to be a complete

[Bug c++/82000] New: Missed optimization of char_traits::length() on constant string

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- In the following code, the calculation of the string length is not folded, despite the input string being visible to the compiler

[Bug c++/81933] New: [7 Regression] Invalid "constexpr call flows off the end of the function" error

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code does not compile with GCC 7,

[Bug c++/81525] New: [7 Regression] Invalid codegen with constexpr variable template

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code prints i = 0 N = 0 when it should print i = 0 N = 1 This seems to be a regression since GCC 7

[Bug c++/81299] New: Spurious "set but not used" warning with constexpr variable

ty: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code triggers a spurious warning on GCC trunk (8.0 ish): struct function_t { template void ope

[Bug c++/79189] New: Poor code generation when using stateless lambda instead of normal function

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- When doing an indirect call (through a function pointer), GCC generates different code depending on whether the function pointer

[Bug c++/59498] [DR 1430][4.9/5/6/7 Regression] Pack expansion error in template alias

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59498 --- Comment #12 from Louis Dionne --- Not sure, as I've been off pure-type computations for a while now. Looking at how Meta does it might be useful: https://github.com/ericniebler/meta/blob/master/include/meta/meta.hpp#L819

[Bug c++/67364] [5/6 Regression] "accessing uninitialized member" error in constexpr context

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67364 --- Comment #13 from Louis Dionne --- Actually, the problem is much worse than I thought. It turns out that with -O1, the following code does not pass the assertion: #include template struct tuple { Xn storage_;

[Bug c++/70097] New: Cannot assign ref-qualified non-static member function

Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code fails to compile on GCC trunk: struct F { void member() & { } }; using Member = void()&; Member F::* fptr = ::member; T

[Bug c++/70096] New: [Invalid codegen] Read of uninitialized value in ref-qualified pointer to member function

Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code has a codegen issue that causes the read of an uninitialized value, which can lead

[Bug c++/67364] [5/6 Regression] "accessing uninitialized member" error in constexpr context

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67364 --- Comment #12 from Louis Dionne --- The following code still fails to compile on GCC trunk: template struct tuple { Xn storage_; constexpr tuple(Xn const& xn) : storage_(xn) { } template

[Bug c++/70095] New: [C++14] Link error on partially specialized variable template

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code fails to link on GCC trunk: template struct Foo; template int variable_template = 0; template int

[Bug c++/69995] [5/6 Regression] [C++14] Invalid result when evaluating constexpr function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69995 --- Comment #2 from Louis Dionne --- I know but using a runtime assert allows showing that with/without constexpr have different results. Also, I wanted to emphasize the fact that it could result into a runtime error, since these are much more

[Bug c++/69995] New: [C++14] Invalid result when evaluating constexpr function

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code triggers a runtime assertion: -- #include #define

[Bug c++/67164] ICE: tree check: expected class ‘expression’, have ‘exceptional’ (argument_pack_select) in tree_operand_check, at tree.h:3356

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67164 --- Comment #6 from Louis Dionne --- The code I posted above does not seem to trigger the bug anymore on GCC trunk. However, the following code still produces an ICE on trunk: > ~/code/gcc/prefix/bin/g++ --version > g++ (GCC) 6.0.0 20160226

[Bug c++/69059] New: [C++14] Invalid rejection of expression as not-a-constant-expression

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code does not compile with GCC trunk (g++ 6.0.0 20151226 experimental): template struct holder { T value

[Bug c++/69060] New: Invalid 'cannot bind lvalue to rvalue' error

++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code does not compile on GCC trunk (g++ 6.0.0 20151226 experimental): template struct hold { T value; T&&

[Bug c++/67050] [C++14] ICE when calling a template member function from a lambda with implicit "this" capture

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67050 --- Comment #5 from Louis Dionne --- Agreed, the ICE seems to be fixed on trunk. However, the error you're getting is still a bug, right? The code compiles if I use `this->X()`, but not `X()` alone.

[Bug c++/67050] [C++14] ICE when calling a template member function from a lambda with implicit "this" capture

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67050 --- Comment #7 from Louis Dionne --- Yes, it seems like a dup. However, it would still be nice to know when this bug was fixed, because it seems unlikely to have been fixed by chance... It could be that something's still wrong, but the compiler

[Bug c++/68754] New: Explicitly defaulted constexpr assignment operator fails to compile

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code fails to compile on GCC 5.3.0: struct base { }; struct derived : base { constexpr derived

[Bug c++/67364] "accessing uninitialized member" error in constexpr context

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67364 --- Comment #1 from Louis Dionne --- Ping. This is one of the last bugs preventing Boost.Hana [1] to work with GCC. I would be eternally grateful if someone could fix this! [1]: https://github.com/ldionne/hana

[Bug c++/67371] New: Never executed throw in constexpr function fails to compile

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code fails to compile on GCC trunk: constexpr void f() { if (false) throw; } The error

[Bug c++/67164] ICE: tree check: expected class ‘expression’, have ‘exceptional’ (argument_pack_select) in tree_operand_check, at tree.h:3356

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67164 --- Comment #4 from Louis Dionne ldionne.2 at gmail dot com --- Still fails on trunk. Out of curiosity Markus, do you use software to reduce test cases? Did you generate these A, B, ... structs yourself? Anyway, I was able to reduce

[Bug c++/56958] Spurious set but not used variable warning in empty pack expansion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56958 Louis Dionne ldionne.2 at gmail dot com changed: What|Removed |Added CC||ldionne.2

[Bug c++/67371] Never executed throw in constexpr function fails to compile

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67371 --- Comment #1 from Louis Dionne ldionne.2 at gmail dot com --- This is almost certainly a duplicate of #66026, yet it is still unconfirmed.

[Bug c++/67376] New: Comparison with pointer to past-the-end of array fails inside constant expression

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code fails to compile on GCC trunk: struct array { int elems_[1]; }; constexpr array

[Bug c++/66135] trailing return type error for generic lambda

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66135 Louis Dionne ldionne.2 at gmail dot com changed: What|Removed |Added CC||ldionne.2

[Bug c++/67370] New: Invalid parameter packs not expanded error in lambda capture

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code does not compile with GCC trunk: template typename ...T void expand(T const ...); template typename ...T

[Bug c++/67041] [C++14] Variable template initialized by call to lambda does not compile

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67041 --- Comment #1 from Louis Dionne ldionne.2 at gmail dot com --- Can be simplified to: template typename ...Anything auto variable_template = [] { }; int main() { variable_template; } Still fails on GCC trunk.

[Bug c++/67364] New: accessing uninitialized member error in constexpr context

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code triggers a compilation error on GCC trunk: template typename Xn struct element : Xn { constexpr element() : Xn

[Bug c++/67050] [C++14] ICE when calling a template member function from a lambda with implicit this capture

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67050 Louis Dionne ldionne.2 at gmail dot com changed: What|Removed |Added CC||ldionne.2

[Bug c++/67050] New: [C++14] ICE when calling a template member function from a lambda with implicit this capture

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- Hi, The following code triggers an ICE (segmentation fault) on GCC trunk

[Bug c++/67041] New: [C++14] Variable template initialized by call to lambda does not compile

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code does not compile on GCC trunk: --- template typename ...Anything auto

[Bug c++/66693] New: [C++17] std::tuple_size fails with const std::array

: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code fails on GCC trunk: -- #include array int main() { std::tuple_sizestd

[Bug c++/66543] New: False positive warning variable set but not used

++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code triggers a unused but set variable warning on GCC trunk: int main() { auto f = []() { }; [=](auto) { using Foo = decltype(f

[Bug c++/65719] Link error with constexpr variable template

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65719 --- Comment #9 from Louis Dionne ldionne.2 at gmail dot com --- I can confirm that my original use case now works. Thanks a bunch!

[Bug c++/66538] New: Parameter not in scope of generic lambda trailing decltype

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- The following code does not compile on GCC trunk: auto f = [](auto x) - decltype((void)x) { }; The failure is error: ‘x

[Bug c++/65719] Link error with constexpr variable template

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65719 --- Comment #4 from Louis Dionne ldionne.2 at gmail dot com --- I added Jason to the CC list since he's the one who committed r213641. Jason, any clue about how to fix this?

[Bug c++/65719] Link error with constexpr variable template

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65719 --- Comment #3 from Louis Dionne ldionne.2 at gmail dot com --- This bug is a real, real pain. I'm willing to help fixing it and/or to provide test cases, but it'll take me forever if someone on your side does not assist, since I don't know

[Bug c++/66281] New: [C++14][Variable templates] internal compiler error: in tsubst, at cp/pt.c:12022

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- Hi, The following code causes an ICE on GCC trunk (couple of weeks old

[Bug c++/65719] New: Link error with constexpr variable template

++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com The following code triggers a link error on GCC trunk: -- struct FunctionObject { void operator()() const { } }; template

[Bug libstdc++/65473] Including ciso646 does not define __GLIBCXX__

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65473 --- Comment #4 from Louis Dionne ldionne.2 at gmail dot com --- (In reply to Jonathan Wakely from comment #3) (In reply to Louis Dionne from comment #2) Does the standard specify which headers should define those macros? Of course

[Bug c++/65708] New: Non-type template argument not visible causes substitution failure

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com The following code produces an error on GCC trunk. The error says that there is no matching `f` to call

[Bug c++/59766] c++1y: declaring friend function with 'auto' return type deduction is rejected with bogus reason

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766 Louis Dionne ldionne.2 at gmail dot com changed: What|Removed |Added CC||ldionne.2

[Bug c++/65707] New: internal compiler error: in unify, at cp/pt.c:18577

: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com The following code triggers an ICE on GCC trunk: -- #include type_traits template bool struct when; template typename

[Bug c++/65706] New: [c++14] Pack expansion with variable template incorrectly marked as invalid

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com The following code produces an error on GCC trunk: -- void allow_expansion

[Bug libstdc++/65473] Including ciso646 does not define __GLIBCXX__

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65473 --- Comment #2 from Louis Dionne ldionne.2 at gmail dot com --- Does the standard specify which headers should define those macros? If not, then it's a QOI issue that could easily be solved. In all cases, does stdcxx document which headers must

[Bug c++/65498] [5 Regression] ICE in cxx_eval_call_expression when using __func__ inside dependent context

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65498 --- Comment #5 from Louis Dionne ldionne.2 at gmail dot com --- [Just a quick comment: thank you for being so responsive. Most of my bug reports on Clang are left hanging for a long while before anyone ever considers them, and I appreciate

[Bug c++/65498] New: ICE in cxx_eval_call_expression when using __func__ inside dependent context

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com The following code triggers an ICE on GCC trunk: -- #include

[Bug c++/65498] ICE in cxx_eval_call_expression when using __func__ inside dependent context

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65498 --- Comment #1 from Louis Dionne ldionne.2 at gmail dot com --- Apologies; the lines of the example run were wrapped and it's unreadable from here. Here's what it looks like: https://gist.github.com/ldionne/054e276caf90f16e3223

[Bug libstdc++/65473] New: Including ciso646 does not define __GLIBCXX__

: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Hi, One would expect that including _any_ header from the standard library defines the relevant detection macros. For example, I usually include the ciso646 header to check for libc++ (per http

[Bug c++/59498] [DR 1430][4.9/4.10 Regression] Pack expansion error in template alias

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59498 --- Comment #7 from Louis Dionne ldionne.2 at gmail dot com --- I ran into this problem in another context, and I think it justifies some thinking about how this issue is going to be handled by the language. I _really_ think the following should

[Bug c++/59498] [DR 1430][4.9/4.10 Regression] Pack expansion error in template alias

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59498 --- Comment #8 from Louis Dionne ldionne.2 at gmail dot com --- I made further experiments to try and workaround this (I need it badly!) and I found some things that might be of interest to you. The following test case compiles on GCC 4.9.1

[Bug c++/59498] New: Pack expansion error in template alias

++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com GCC Version --- gcc-4.9 (GCC) 4.9.0 20131201 (experimental) Installed with Homebrew. System -- OS X 10.8.5 Command line to trigger the bug --- gcc-4.9 -std=c++11