[Bug c++/94027] [10 Regression] ice in comptypes, at cp/typeck.c:1489 since r10-6907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94027 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug c++/94027] [10 Regression] ice in comptypes, at cp/typeck.c:1489 since r10-6907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94027 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Nathan Sidwell --- Fixed 191bcd0f30dd37dec773efb0125afdcae9bd90ef
[Bug c++/94117] New: non-dependent expr treated as-if dependent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94117
Bug ID: 94117
Summary: non-dependent expr treated as-if dependent
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
Created attachment 48006
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48006&action=edit
distilled from ranges
We accept the attached test case, which should be rejected.
It comes from these two fragments of the ranges header:
lines ~1595
static constexpr decltype(auto)
__iter_move(const _Iterator& __i = {})
noexcept(noexcept(std::__invoke(*__i._M_parent->_M_fun,
*__i._M_current)))
{
if constexpr (is_lvalue_reference_v)
return std::move(*__i);
else
return *__i;
}
lines ~1752
friend constexpr decltype(auto)
iter_move(const _Iterator& __i) noexcept(noexcept(__iter_move()))
{ return __iter_move(__i); }
If we change __iter_move's argument type to int, we reject complaining that the
call in iter_move's noexcept spec requires the default argument before it's
been parsed. Clang rejects either way.
the '__iter_move ()' call is not dependent because it has no arguments.
Addition of the default argument does not make it dependent.
filing a separate issue to fix libstdc++
[Bug c++/94117] non-dependent expr treated as-if dependent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94117 Nathan Sidwell changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-10 --- Comment #3 from Nathan Sidwell --- This is the error that should be emitted (modulo the argument type being _Iterator) devvm2772:6>./cc1plus -fmodule-header -quiet b_a.H In file included from b_a.H:1: b.h:10:69: error: call to 'static void _Iterator<_Const>::mover(const int&)' uses the default argument for parameter 1, which is not yet defined 10 | friend void move (const _Iterator &arg) noexcept (noexcept (mover ()))
[Bug c++/94117] non-dependent expr treated as-if dependent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94117 Nathan Sidwell changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Nathan Sidwell --- Ah, I understand what is happening. We don't defer parsing of the noexcept specified of friend functions. That leads us to construct a base-link expr whose type contains the deferred parse exception specification of the *static* member function -- there being only one, it doesn't get unknown type. In processing the deferred exception specification of that fn, we don't fixup all the type variants that might have been created. There's a restriction on friend declarations that contain default args. This is the same problem that is trying to avoid.
[Bug c++/94117] deferred noexcept specifications and friend fns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94117 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|SUSPENDED --- Comment #9 from Nathan Sidwell --- Discussing on the core list https://lists.isocpp.org/core/2020/03/8632.php (password required) I have a fix the the problem I encountered on the modules branch. Not suitable at this stage for trunk, and there's probably a better solution out there. As Marek says 'nobody implements this'
[Bug c++/94147] New: mangling of lambdas in initializers is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94147
Bug ID: 94147
Summary: mangling of lambdas in initializers is wrong
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
inline auto var = [] (int) {};
should mangle the lambda as _ZN3varMUlE_clEv
likewise for static member variables
[Bug c++/94147] mangling of lambdas in initializers is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94147 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-03-11
[Bug c++/94044] [10 Regression] internal compiler error: in comptypes, at cp/typeck.c:1490 on riscv64-unknown-linux-gnu and arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94044 Nathan Sidwell changed: What|Removed |Added Last reconfirmed||2020-03-12 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug c++/94044] [10 Regression] internal compiler error: in comptypes, at cp/typeck.c:1490 on riscv64-unknown-linux-gnu and arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94044 --- Comment #4 from Nathan Sidwell --- I cannot reproduce this with the cross or native compilers I've tried: native: x86_64-linux, aarch64-linux cross: arm-eabi riscv64-unknown-linux The cross compilers are hosted on x86_64-linux
[Bug c++/94044] [10 Regression] internal compiler error: in comptypes, at cp/typeck.c:1490 on riscv64-unknown-linux-gnu and arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94044 --- Comment #6 from Nathan Sidwell --- Still no luck. I'm at cb99630f254 2020-03-11 | fold undefined pointer offsetting Configured with ../../src/configure '--with-mpfr=/data/users/nathans/tools' '--with-mpc=/data/users/nathans/tools' '--enable-checking=yes' --disable-multilib --disable-bootstrap '--enable-languages=c,c++,lto' '--target=arm-eabi' devvm2772+2:5>./cc1plus -quiet variadic-sizeof4.C -quiet -mcpu=arm7tdmi -marm -march=armv4t -std=c++14 -o - ... assembly emitted ... I'm using a fresh binutils cross toolchain I understand where the compiler got to from your traceback. I don't understand what constructed the trees that got it there!
[Bug c++/94044] [10 Regression] internal compiler error: in comptypes, at cp/typeck.c:1490 on riscv64-unknown-linux-gnu and arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94044 --- Comment #10 from Nathan Sidwell --- Thanks for poking at this Jim!
[Bug c++/94147] mangling of lambdas in initializers is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94147 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Nathan Sidwell --- Fixed 11cf25c40e3f586d19474108c78a2dfad7925902
[Bug c++/94044] [10 Regression] internal compiler error: in comptypes, at cp/typeck.c:1490 on riscv64-unknown-linux-gnu and arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94044 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Nathan Sidwell --- Fixed 26b3e568a60e9fd851efb436531752a5e49e6419
[Bug c++/94257] ICE in inline nested namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94257 Nathan Sidwell changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/94257] ICE in inline nested namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94257 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Nathan Sidwell --- Fixed 9dba60130dc3ebf7cce8716a36672281688693f7
[Bug c++/84733] [8/9/10 Regression] internal compiler error: Segmentation fault (check_local_shadow())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84733 --- Comment #18 from Nathan Sidwell --- fixed GCC 10 13dfc007557c384683118fa12cd255e69b70a34d
[Bug c++/84733] [8/9/10 Regression] internal compiler error: Segmentation fault (check_local_shadow())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84733 --- Comment #23 from Nathan Sidwell --- Fixed trunk and gcc-9
[Bug c++/94426] [10 Regression] ICE in mangle_decl with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94426 Nathan Sidwell changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Status|NEW |SUSPENDED
[Bug c++/94426] [10 Regression] ICE in mangle_decl with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94426 Nathan Sidwell changed: What|Removed |Added Status|SUSPENDED |ASSIGNED --- Comment #4 from Nathan Sidwell --- nope, I fat fingered the status
[Bug c++/94426] [10 Regression] ICE in mangle_decl with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94426
--- Comment #5 from Nathan Sidwell ---
Reduced testcase:
template using Void = void;
template bool Init (U);
template bool VAR = Init ([] {});
template
Void> Foo (T)
{}
void q ()
{
Foo ([] {});
}
bug.ii: At global scope:
bug.ii:5:38: internal compiler error: in mangle_decl, at cp/mangle.c:3907
5 | template bool VAR = Init ([] {});
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454
Nathan Sidwell changed:
What|Removed |Added
CC||nathan at gcc dot gnu.org
--- Comment #4 from Nathan Sidwell ---
Oh, it is from the template specialization hash table. I suggest making that
very poor to increase collisions:
pt.c:
static hashval_t
hash_tmpl_and_args (tree tmpl, tree args)
{
hashval_t val = iterative_hash_object (DECL_UID (tmpl), 0);
return val; // INSERT THIS LINE
return iterative_hash_template_arg (args, val);
}
sorry for not realizing this earlier
[Bug c++/94476] New: NSDMI deferred parse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94476
Bug ID: 94476
Summary: NSDMI deferred parse
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
This code, extracted from leaves an unparsed NSDMI for _M_type.
That kills the module streamer, which doesn't expect to meet such things.
Bizarrely, removing either the 'signed char' underlying type, the ctor
declaration, or the _M_path field removes the problem. Not sure if the
non-module compiler copes?
enum class file_type : signed char { none = 0 };
class directory_entry
{
public:
directory_entry(int);
int _M_path;
file_type _M_type = file_type::none;
};
[Bug c++/94476] NSDMI deferred parse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94476 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-04-03 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug c++/94476] NSDMI deferred parse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94476 Nathan Sidwell changed: What|Removed |Added Priority|P3 |P4 Status|ASSIGNED|SUSPENDED --- Comment #1 from Nathan Sidwell --- this caused by the as_base creation code copying the field_decl, deferred NSDMI and all. That doesn't affect trunk's behaviour so is harmless. But we should get it right. Fixed on modules 2c6b4bd9ab0 Can push to trunk once stage 1 opens up. PR c++/94476 gcc/cp/ * class.c (layout_class_type): Zap NSDMI of as_base fields. gcc/testsuite/ * g++.dg/modules/nsdmi-2.C: New.
[Bug c++/94528] coroutines: ICE building cppcoro in gimplify_expr, at gimplify.c:14399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94528 Nathan Sidwell changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment #3 from Nathan Sidwell --- The patch is ok. For avoidance of doubt, the 'for now' comment refers to an issue addressed in a following patch.
[Bug c++/70790] Can't mangle noexcept expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70790 Nathan Sidwell changed: What|Removed |Added CC||nathan at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org --- Comment #3 from Nathan Sidwell --- ... so I don't forget. but not a GCC 10 thing
[Bug c++/94426] [10 Regression] ICE in mangle_decl with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94426 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Nathan Sidwell --- Fixed 8d213cbbe18
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454
--- Comment #10 from Nathan Sidwell ---
I cannot reproduce it, but looking at the gist referenced in comment #1 I see
that the complaint is about two instances of the same instantiation of struct
std::integral_constant >
One of which has __attribute__ ((__abi_tag__ ("cxx11"))) attached to it. That
seems to be the error -- how did that abi_tag get there? it's not on the
original declaration.
I can't see how those could have become attached. AFAICT we don't propagate
attributes from the arguments of an instantiation, to the instantiation itself
(and that wouldn't explain it here, as 'and_v' and __is_constructible are
unattributed.
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454 --- Comment #12 from Nathan Sidwell --- Created attachment 48270 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48270&action=edit asserts to trigger it I have found the cause, but not the underlying reason. We have template arguments that compare equal but hash differently. So the earlier attempts to cause hash collisions by neutering the hasher, made the bug go away. This patch neuters the hasher, but adds an assert into the argyment comparator -- if the args compare equal, they better hash equal. This triggers on the testcase with a pair of template_id_exprs.
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug c++/94608] Fix for PR94426 causes a regression in g++.dg/lto/pr83720 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94608 Nathan Sidwell changed: What|Removed |Added Last reconfirmed||2020-04-15 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org --- Comment #1 from Nathan Sidwell --- Quite probably Christophe
[Bug c++/94608] Fix for PR94426 causes a regression in g++.dg/lto/pr83720 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94608 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Nathan Sidwell --- Fixed 75fbe1b98c7
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454 --- Comment #13 from Nathan Sidwell --- Created attachment 48313 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48313&action=edit testing shim
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Nathan Sidwell --- Fixed: * a6f400239d7 2020-04-20 | c++: tpl-tpl-parms are not canonicalizable types [pr94454] (HEAD -> master, origin/master, origin/HEAD) [Nathan Sidwell] * 7fcb93431ef 2020-04-20 | c++: Expr pack expansion equality [pr94454] [Nathan Sidwell] * aa576f2a860 2020-04-20 | c++: Template argument hashing [pr94454] [Nathan Sidwell]
[Bug c++/85046] [8/9/10 Regression] cp/name-lookup.c:6175:53: runtime error: member access within null pointer of type 'struct cp_binding_level'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85046 --- Comment #8 from Nathan Sidwell --- the reduced testcases no longer crash the compiler. The first emits a correct error, the second succeeds. The original testcase still crashes the compiler, after emitting a slew of errors about ill-formed code.
[Bug c++/94691] New: ICE resolving deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94691
Bug ID: 94691
Summary: ICE resolving deduction guide
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
Created attachment 48324
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48324&action=edit
testcase
This ICEs. Removing 'const' makes it work.
devvm2772:52>./cc1plus -std=c++20 jc.ii
void f()
jc.ii:14:10: internal compiler error: in alias_ctad_tweaks, at cp/pt.c:28472
14 | X1 x1{ };
| ^
0xcd5728 alias_ctad_tweaks
../../../src/gcc/cp/pt.c:28472
0xcd6438 deduction_guides_for
../../../src/gcc/cp/pt.c:28644
[Bug c++/94691] ICE resolving deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94691 --- Comment #2 from Nathan Sidwell --- Created attachment 48353 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48353&action=edit another case Attached another example of the same assert triggering
[Bug libstdc++/94747] Confusing code in libsupc++/dyncast.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94747 Nathan Sidwell changed: What|Removed |Added Last reconfirmed||2020-04-24 Summary|Undefined behavior: integer |Confusing code in |overflow in |libsupc++/dyncast.cc |libsupc++/dyncast.cc| CC||nathan at gcc dot gnu.org Status|RESOLVED|ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #3 from Nathan Sidwell --- While the code is well formed, it does not convey intent well. I wrote that code, and probably even considered spelling as -ptrdiff_t (offsetof ...). but didn't because it causes a line wrap and has no semantic difference. negating unsigned numbers often shows programmer confusion, and can cause bugs on I32LP64 systems, where the negation happens at a lower precision than expected. That's not the case here. If size_t has fewer bits than a pointer, there cannot be overflow from the top size_t bit to the pointer arithmetic -- that breaks C & C++ semantics. Something for stage 1
[Bug c++/94807] Inconsistency in lambda instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94807 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-04-27 --- Comment #1 from Nathan Sidwell --- Something for stage 1
[Bug c++/94807] New: Inconsistency in lambda instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94807
Bug ID: 94807
Summary: Inconsistency in lambda instantiation
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
The parser renames a lambda's function operator's object pointer argument to be
'__closure' (closure_identifier). This gets lost, if that lambda's in a
template, when the containing template is instantiated.
This is confusing to compiler devs, and (at least) causes a workaround in the
coro machinery.
template struct frob
{
int i;
void m ()
{
auto b = [] {}; // named __closure in the template
b ();
}
};
frob<0> i;
int x ()
{
i.m (); // named __this in the instantiation
}
[Bug libstdc++/94823] New: modulo arithmetic bug in random.tcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94823
Bug ID: 94823
Summary: modulo arithmetic bug in random.tcc
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
I think there's a bug in libstdc++v3/include/bits/random.tcc, found by ubsan's
(over conservative) unsigned overflow checker. This time, a true positive.
there's a bunch of code like:
for (size_t __k = 0; __k < __m; ++__k)
{
_Type __arg = (__begin[__k % __n]
^ __begin[(__k + __p) % __n]
^ __begin[(__k - 1) % __n]); // this line
... calculate stuff
__begin[(__k + __p) % __n] += __r1;
__begin[(__k + __q) % __n] += __r2;
__begin[__k % __n] = __r2;
}
AFAICT we're treating __begin as a circular buffer length __n. __n has no
special properties. The marked line is presuming that '(V mod 2^n) mod __n' is
the same as '(V mod __n)' which is not true in general. In particular when
__k is zero we're taking '(2^64 - 1) mod __n', which is not necessarily __n -
1, the last position in the buffer, right?
I don't know if the prior line __k + __p can overflow too. If it can't then I
think the marked line should be:
__begin[(__k + __n - 1) % __n]
[Bug c++/94827] [10 Regression] crash on requires clause in tparam list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94827 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2020-04-28 --- Comment #1 from Nathan Sidwell --- hm, yeah, we're completely unprepared to go inspecting the parm vector during parsing the parameters. Not sure how this worked previously.
[Bug libstdc++/94823] modulo arithmetic bug in random.tcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94823 Nathan Sidwell changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2020-04-29 Ever confirmed|0 |1 Resolution|WONTFIX |--- --- Comment #6 from Nathan Sidwell --- Reopening. Such subtlety should be commented upon in the code.
[Bug c++/94827] [10 Regression] crash on requires clause in tparam list since r10-4424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94827 --- Comment #3 from Nathan Sidwell --- Created attachment 48425 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48425&action=edit try instantiating the fn This one ices with the initial patch.
[Bug c++/94827] [10 Regression] crash on requires clause in tparam list since r10-4424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94827 --- Comment #4 from Nathan Sidwell --- Note to stage-1 me: Jason wrote: But I don't think that we need to keep saving the converted current_template_parms; diagnostics could also normalize using NULL_TREE args. And it looks like diagnose_nested_requirement isn't currently doing re-normalization anyway. This doesn't need to block the release, though.
[Bug c++/94827] crash on requires clause in tparam list since r10-4424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94827 Nathan Sidwell changed: What|Removed |Added Summary|[10 Regression] crash on|crash on requires clause in |requires clause in tparam |tparam list since r10-4424 |list since r10-4424 | --- Comment #5 from Nathan Sidwell --- fixed c416c52bcdb, leaving open for stage-1 issue
[Bug c++/94827] crash on requires clause in tparam list since r10-4424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94827 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Nathan Sidwell --- Cleanup pushed f1621d18f55
[Bug libstdc++/94747] Confusing code in libsupc++/dyncast.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94747 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Nathan Sidwell --- Fixed e6b31fc7172
[Bug c++/94807] Inconsistency in lambda instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94807 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Nathan Sidwell --- Fixed 733195e367d, adjusted instantiation to set the name.
[Bug c++/94946] [9/10/11 Regression] error: ‘template JSC::FunctionPtr::FunctionPtr(returnType (*)())’ cannot be overloaded since r10-7998-g5f1cd1da1a805c3d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94946 Nathan Sidwell changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Nathan Sidwell --- Patch pushed to 9, 10 & master
[Bug c++/94984] New: rejects requires clause in array declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94984
Bug ID: 94984
Summary: rejects requires clause in array declaration
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
Daveed tells us we reject this (clang & edg accept). gcc-9 and 10 reject it
(so not a regression)
template
char (*f(int i))[N] requires(sizeof(i) < 100) {}
dav.ii:2:21: error: expected initializer before 'requires'
2 | char (*f(int i))[N] requires(sizeof(i) < 100) {}
[Bug c++/94984] rejects requires clause in array declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94984
Nathan Sidwell changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2020-05-07
Status|UNCONFIRMED |NEW
--- Comment #1 from Nathan Sidwell ---
silly write only comments:
Daveed tried the following, which we accept
template
char (*f(int i) requires(sizeof(i) < 100))[N] {}
(note how the trailing-requires-clause was moved to within the declarator) and
sure enough GCC accepts that.
[Bug preprocessor/88937] valgrind error in parse_has_include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88937 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Nathan Sidwell --- I fixed this as a drive by working on 93452. 2020-01-24 Nathan Sidwell * expr.c (parse_has_include): Remove bogus controlling macro code.
[Bug c++/94984] rejects requires clause in array declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94984 Nathan Sidwell changed: What|Removed |Added Assignee|nathan at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #2 from Nathan Sidwell --- I didn;t mean to grab this.
[Bug objc++/95013] [11 Regression] FAIL: obj-c++.dg/property/property-neg-6.mm syntax-error-10.mm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95013 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug preprocessor/95013] [11 Regression] FAIL: obj-c++.dg/property/property-neg-6.mm syntax-error-10.mm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95013 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Nathan Sidwell --- Fixed 2a0225e4786
[Bug pch/95131] Instantiate templates at pch generation time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95131 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Nathan Sidwell --- 1) The future is sooner than you think :) 2) template instantiation cannot be done speculatively -- only when language constructs require it. Otherwise you can change the meaning of well-formed code.
[Bug preprocessor/95183] [11 Regression] ICE: Segmentation fault (in _cpp_lex_direct)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95183 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug preprocessor/95183] [11 Regression] ICE: Segmentation fault (in _cpp_lex_direct)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95183 --- Comment #2 from Nathan Sidwell --- This is a bug, but you're running a --traditional C preprocessor test through the c++ compiler, right? (A regular test run doesn't fail this test for me at least)
[Bug preprocessor/95183] [11 Regression] ICE: Segmentation fault (in _cpp_lex_direct)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95183 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Nathan Sidwell --- Fixed a641d6d3e63
[Bug middle-end/95208] New: missed switch optimization as bit test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95208 Bug ID: 95208 Summary: missed switch optimization as bit test Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- Created attachment 48565 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48565&action=edit The if case is optimized better This comes from libcpp/lex.c's raw string lexer. We're testing whether a character falls into a particular set of values. The switch is emitted as the usual dispatch table. The if case, after range checking, turns into 'if ((1ul << (c - BASE)) & MAGIC_VALUE)' Which is somewhat better. Why doesn't the switch form do that? _Z3bazc: .LFB1: .cfi_startproc leal-97(%rdi), %eax cmpb$29, %al jbe .L7 subl$33, %edi cmpb$62, %dil ja .L6 movabsq $8646911282403868279, %rax btq %rdi, %rax jc .L7 .L6: ret .p2align 4,,10 .p2align 3 .L7: jmp _Z3barv .cfi_endproc
[Bug target/95182] Change the definition of Pmode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95182 Nathan Sidwell changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment #4 from Nathan Sidwell --- That patch was aiming for 95183, but missed :)
[Bug preprocessor/95183] [11 Regression] ICE: Segmentation fault (in _cpp_lex_direct)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95183 --- Comment #5 from Nathan Sidwell --- patch got attached to p95182, because reasons
[Bug c++/95149] lex.c:1729:8: warning: result of comparison against a string literal is unspecified (use an explicit string comparison function instead) [-Wstring-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95149 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Nathan Sidwell --- Fixed ed63c387aa0
[Bug c++/95263] [11 Regression] ICE in lookup_template_class_1 since r11-504-g74744bb1f2847b5b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95263 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug c++/95288] New: Poor error message with function-scope enum definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95288
Bug ID: 95288
Summary: Poor error message with function-scope enum definition
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
Created attachment 48587
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48587&action=edit
testcase
A malformed enum definition in function-scope gives a very poor diagnostic. In
this example I typoed a '.' (DOT) for a ',' (COMMA). the compiler complains at
the 'enum' token, not at the dot.
Contrast the error for X and (namespace-scope) Y. Class-scope enums behave
like namespace-scope ones.
(1)bester:139>g++ -c f.cc
f.cc: In function ‘void f()’:
f.cc:4:3: error: expected primary-expression before ‘enum’
4 | enum X
| ^~~~
f.cc: At global scope:
f.cc:13:4: error: expected ‘}’ before ‘.’ token
13 | c. // DOT
|^
f.cc:12:1: note: to match this ‘{’
12 | {
| ^
f.cc:13:4: error: expected unqualified-id before ‘.’ token
13 | c. // DOT
|^
f.cc:15:1: error: expected declaration before ‘}’ token
15 | };
[Bug c++/95337] New: duplicated deprecated attribute gives incorrectly duplicated diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95337
Bug ID: 95337
Summary: duplicated deprecated attribute gives incorrectly
duplicated diagnostic
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
Created attachment 48607
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48607&action=edit
yesterday, no, testcase. That's the word
If a declaration has two (different) deprecated attributes. We diagnose twice
(good), but use the same message both times (bad):
zathras:3>g++ -std=c++2a -c d.cc
d.cc: In function ‘void g()’:
d.cc:5:6: warning: ‘void f()’ is deprecated: dob [-Wdeprecated-declarations]
5 | f ();
| ^
d.cc:1:6: note: declared here
1 | void f [[deprecated("bob")]] [[deprecated("dob")]] ();
| ^
d.cc:5:6: warning: ‘void f()’ is deprecated: dob [-Wdeprecated-declarations]
5 | f ();
| ^
d.cc:1:6: note: declared here
1 | void f [[deprecated("bob")]] [[deprecated("dob")]] ();
| ^
check whether noignore has the same problem
[Bug c++/95263] [11 Regression] ICE in lookup_template_class_1 since r11-504-g74744bb1f2847b5b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95263
--- Comment #1 from Nathan Sidwell ---
Reduced:
template class TPL {
template using INT = int;
};
template class Klass
{
public:
template using ALIAS = typename TPL::INT;
template static void FUNC (); // OK
template static ALIAS FUNC (); // SFINAE error
};
void Fn ()
{
Klass::FUNC<0> ();
}
[Bug c++/95337] duplicated deprecated attribute gives incorrectly duplicated diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95337 --- Comment #1 from Nathan Sidwell --- Oops, I ran my installed compiler, and on this machine that's still 9.3. On trunk we get one diagnostic. Ignoring the other deprecated reason.
[Bug c++/95428] ABI breakage for "base object constructor" for final classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428 --- Comment #5 from Nathan Sidwell --- i have filed ABI issue 104 https://github.com/itanium-cxx-abi/cxx-abi/issues/104
[Bug c++/95428] ABI breakage for "base object constructor" for final classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428 --- Comment #7 from Nathan Sidwell --- Richard Smith thinks the ABI is clear and compilers should always emit the as-base ctor. Even though that wording was written before final was a thing. Depends if Jason wants to argue the case?
[Bug c++/95677] undefined reference to `(anonymous namespace)::xx'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677 --- Comment #3 from Nathan Sidwell --- I think the testcase is should be formed. it was ok in C++98, but that changed when anonymous namespaces gave their contents internal linkage (rather than external but with unpronounceable symbols). [basic.link]/6 does not anticipate this issue.
[Bug c++/95677] undefined reference to `(anonymous namespace)::xx'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677 Nathan Sidwell changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-06-15 --- Comment #6 from Nathan Sidwell --- Ah, anonymous namespaces have internal linkage (and a program-wide unique identifier). Their contents have the linkage they have. but because they're within the anonumous namespace they cannot be named from elsewhere, so they have internal linkage for implementation purposes. when we actually gave anonymous namespaces there would be no collisions between TUs for '::x'. Now we give it a specific name and adjust the linkages of their contents. The C++ FE should adjust the linkage of '::x' too.
[Bug c++/95809] GCC treats inline namespace declaration as "ambiguous"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95809 --- Comment #2 from Nathan Sidwell --- yup, dr2061 made that ill-formed. p1701 (wg21.link/p1701) documents the behaviour and it appears EWG is exploring another avenue to resolve the underlying problem 2061 was attempting to fix.
[Bug c++/95809] GCC treats inline namespace declaration as "ambiguous"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95809 --- Comment #4 from Nathan Sidwell --- The code is invalid due to DR2061
[Bug demangler/96143] C++ demangler should not add a lambda as a substitution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96143 Nathan Sidwell changed: What|Removed |Added Last reconfirmed||2020-07-10 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Nathan Sidwell --- Thanks for the reminder. If you do indeed have a patch, you know what to do :)
[Bug c++/96257] [11 Regression] ICE in cp_parser_skip_to_pragma_eol, at cp/parser.c:3948
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96257 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Nathan Sidwell --- shouldn't that test add -fopenmp to the options?
[Bug c++/96257] [11 Regression] ICE in cp_parser_skip_to_pragma_eol, at cp/parser.c:3948
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96257 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Nathan Sidwell --- Fixed 4d6e94960aa The reason I didn't originally see this is it's a C testcase, not a C++ one :)
[Bug c++/96363] New: bogus error with constrained partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96363 Bug ID: 96363 Summary: bogus error with constrained partial specialization Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- template class TPL; template struct Trait; template requires (Trait::val == 0) class TPL; // #1 template requires (Trait::val == 1) class TPL; // #2 error here cc1plus -quiet -std=c++20 par.cc par.cc:11:7: error: ‘TPL’ does not match original declaration 11 | class TPL; | ^~ par.cc:1:29: note: original template declaration here 1 | template class TPL; | ^~~ ICBW, but if #2 is rejected, why is #1 accepted. Aren't these just two partial specializations with different constraints?
[Bug preprocessor/95889] [10 regression] __has_include broken with -traditional-cpp (and therefore with Fortran)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95889 Nathan Sidwell changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Last reconfirmed||2020-07-29 Status|UNCONFIRMED |ASSIGNED CC||nathan at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Nathan Sidwell --- thanks for the patch, taking so I don't forget
[Bug preprocessor/95889] [10 regression] __has_include broken with -traditional-cpp (and therefore with Fortran)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95889 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Nathan Sidwell --- Fixed trunk f6fe3bbf9f6 Fixed gcc-10 5e66b6c0103
[Bug c++/96523] New: variable templates of constant types have incorrect linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96523 Bug ID: 96523 Summary: variable templates of constant types have incorrect linkage Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- Created attachment 49022 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49022&action=edit testcase part 1 non-template namespace-scope variables of constant type get internal linkage. We're doing the same for template-variables, which is wrong. The attached two sources should link and run w/o error. The executable returns 2 as the two instantiations of CONST each has internal linkage. devvm293:110>./cc1plus var-1_a.C -quiet devvm293:111>./cc1plus var-1_b.C -quiet devvm293:112>g++ var-1_*.s devvm293:113>./a.out (2)devvm293:114> [basic.link]/3: A name having namespace scope (6.4.6) has internal linkage if it is the name of (3.1) — a variable, variable template, function, or function template that is explicitly declared static; or (3.2) — a non-template variable of non-volatile const-qualified type, unless ... [Note: An instantiated variable template that has const-qualified type can have external or module linkage, even if not declared extern. — end note] working on a fix, but would like confirmation of bug
[Bug c++/96523] variable templates of constant types have incorrect linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96523 --- Comment #1 from Nathan Sidwell --- Created attachment 49023 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49023&action=edit testcase part 2
[Bug c++/96523] variable templates of constant types have incorrect linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96523 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug tree-optimization/96633] New: missed optimization?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96633
Bug ID: 96633
Summary: missed optimization?
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
Matt Godbolt's https://queue.acm.org/detail.cfm?id=3372264
has an example of optimizing on amd64:
bool isWhitespace(char c)
{
return c == ' '
|| c == '\r'
|| c == '\n'
|| c == '\t';
}
GCC generates:
xorl%eax, %eax
cmpb$32, %dil
ja .L1
movabsq $4294977024, %rax
movl%edi, %ecx
shrq%cl, %rax
andl$1, %eax
.L1:
ret
following an amazing comment on the ML, I've determined the following is abot
12% faster (and shorter too):
movabsq $4294977024, %rax
movl %edi, %ecx
shrq%cl, %rax
shr$6, %ecx
andl$1, %eax
shrq%cl, %rax
ret
We're dealing with chars in the range [-128,128), and x86's shift operator only
considers the bottom 6 bits.
[Bug c++/88003] ICE on outside definition of inner function-local class in poplevel_class, at cp/name-lookup.c:4325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88003 Nathan Sidwell changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org CC||nathan at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Nathan Sidwell --- I accidentally fixed this, cos I grepped for internal compiler error to find what I'd just broken. You tricked me!
[Bug target/96246] [AVX512] unefficient code generatation for vpblendm*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96246
Nathan Sidwell changed:
What|Removed |Added
CC||nathan at gcc dot gnu.org
Resolution|FIXED |---
Status|RESOLVED|REOPENED
--- Comment #5 from Nathan Sidwell ---
FAIL: g++.target/i386/avx512bw-pr96246-2.C execution test
FAIL: g++.target/i386/avx512vl-pr96246-2.C execution test
the tests can fail at runtime, because they do not check
/* { dg-do run { avx512f_runtime } } */
or alternatively use
#include "avx512f-check.h"
[Bug objc++/97015] [11 regression] ICE in set_decl_context_in_fn, at cp/name-lookup.c:2862 after r11-3100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97015 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Last reconfirmed||2020-09-11
[Bug objc++/97015] [11 regression] ICE in set_decl_context_in_fn, at cp/name-lookup.c:2862 after r11-3100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97015 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Nathan Sidwell --- Resolved 7fc41f719a8
[Bug c++/97171] [11 Regression] ICE in symtab_node::get_for_asmname at gcc/symtab.c:1023 since r11-3192-ge9fdb9a73249f95f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97171 Nathan Sidwell changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/97171] [11 Regression] ICE in symtab_node::get_for_asmname at gcc/symtab.c:1023 since r11-3192-ge9fdb9a73249f95f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97171
--- Comment #2 from Nathan Sidwell ---
reduced testcase:
template
void transform(_UnaryOperation);
template
void Apply ()
{
extern T Maker (void); // block-scope extern with dependent type
transform (Maker);
}
template void Apply ();
That;s a weird local extern!
[Bug c++/97171] [11 Regression] ICE in symtab_node::get_for_asmname at gcc/symtab.c:1023 since r11-3192-ge9fdb9a73249f95f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97171 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Nathan Sidwell --- Resolved 13f7c5d504b CWG informed such decls appear in the wild.
[Bug c++/95677] undefined reference to `(anonymous namespace)::xx'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677 Nathan Sidwell changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #10 from Nathan Sidwell --- I think I'm on the path to fixing this as a side effect of getting local externs dtrt. This is a frontend bug
[Bug c++/69855] Missing diagnostic for overload that only differs by return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69855 Nathan Sidwell changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|ASSIGNED --- Comment #9 from Nathan Sidwell --- Reopening. I think I'm on the path of getting this right ...
[Bug c++/91826] [8/9/10 Regression] Unexpected behavior when class defined with namespace alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91826 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug c++/92370] [10 Regression] ICE in cp_lexer_consume_token, at cp/parser.c:1118
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92370 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug c++/92370] [10 Regression] ICE in cp_lexer_consume_token, at cp/parser.c:1118
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92370 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Nathan Sidwell --- Fixed r277853.
[Bug c++/92370] [10 Regression] ICE in cp_lexer_consume_token, at cp/parser.c:1118
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92370 --- Comment #3 from Nathan Sidwell --- Author: nathan Date: Tue Nov 5 16:59:41 2019 New Revision: 277853 URL: https://gcc.gnu.org/viewcvs?rev=277853&root=gcc&view=rev Log: [PR c++/92370] ICE with VC marker https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00323.html cp/ PR c++/92370 * parser.c (cp_parser_error_1): Check EOF and UNKNOWN_LOCATION when skipping over version control marker. testsuite/ PR c++/92370 * g++.dg/pr92370.C: New. Added: trunk/gcc/testsuite/g++.dg/pr92370.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/55809] g++ doesn't differentiate elaborated type specifier and typename specifier in dependent types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55809 --- Comment #3 from Nathan Sidwell --- I think it's ill-formed. the parameter is a non-type template parameter, using a qualified-id containing a dependent type. As such typename T::X * is correct. Using class there is ill-formed. typename and class are only synonyms when naming a type-parameter-key.
