[Bug target/103571] ABI: V2HF, V4HF and V8HFmode argument passing issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103571 --- Comment #4 from Uroš Bizjak --- (In reply to Hongyu Wang from comment #3) > So we may need to support V8HFmode in VALID_SSE2_REG_MODE if we don't want > to modify those function_args and function_value stuff. We have V8HFmode moves for TARGET_SSE, So I guress we can enable it for VALID_SSE2_REG_MODE.
[Bug target/103571] ABI: V2HF, V4HF and V8HFmode argument passing issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103571 Hongyu Wang changed: What|Removed |Added CC||wwwhhhyyy333 at gmail dot com --- Comment #3 from Hongyu Wang --- (In reply to Hongtao.liu from comment #2) > > > > Also, baz iz highly un-optimal for 32bit targets. > > Yes, it needs to be fixed, note w/ -mavx512fp16 codegen for baz is optimal > on 32-bit target, maybe related to vector_mode_supported_p, but then why > codegen for baz on 64-bit target is optimal w/o TARGET_AVX512FP16? For V8HFmode that is unsupported in VALID_SSE2_REG_MODE, function_value_32 has return gen_rtx_REG (orig_mode, regno); so the retval is (reg:BLK 20 xmm0). while function_value_64 uses construct_container and returns (parallel:BLK [ (expr_list:REG_DEP_TRUE (reg:V8HF 20 xmm0) (const_int 0 [0])) ]) This could be optimized to simple movaps finally. So we may need to support V8HFmode in VALID_SSE2_REG_MODE if we don't want to modify those function_args and function_value stuff.
[Bug lto/94776] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94776 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Version|lto |9.2.1 --- Comment #1 from Richard Biener --- I suspect this is another case of running into this assert with not using the linker plugin. At least this one is on a still maintained branch and as Sandra recently noted the code is basically unchanged since a long time. /* Be sure that we never try to duplicate partitioned symbol or add external symbol. */ gcc_assert (c != SYMBOL_EXTERNAL && (c == SYMBOL_DUPLICATE || !symbol_partitioned_p (node)));
[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866 Richard Biener changed: What|Removed |Added CC||harrywong at live dot com --- Comment #19 from Richard Biener --- *** Bug 88550 has been marked as a duplicate of this bug. ***
[Bug lto/88550] A compiler error when use lto: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88550 Richard Biener changed: What|Removed |Added Resolution|--- |DUPLICATE Status|WAITING |RESOLVED --- Comment #6 from Richard Biener --- Let's assume this was fixed, GCC 8 is no longer maintained. Sorry for not following up after you provided the requested information. *** This bug has been marked as a duplicate of bug 69866 ***
[Bug lto/86344] GCC 8.1 ICEd at LTO stage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86344 Richard Biener changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Richard Biener --- Reporter says he figured a way that works for him. Since GCC 8 is no longer maintained, lets close this.
[Bug lto/81847] ICE with LTO enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81847 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Known to work||8.1.0 Status|NEW |RESOLVED --- Comment #8 from Richard Biener --- Fixed then.
[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Richard Biener --- Fixed.
[Bug lto/65995] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:211 for debug build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65995 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||sandra at codesourcery dot com Summary|LTO: ICE in |LTO: ICE in |add_symbol_to_partition_1 |add_symbol_to_partition_1, |for debug build |at lto/lto-partition.c:211 ||for debug build Keywords||ice-on-valid-code --- Comment #8 from Richard Biener --- On trunk this is lto-partition.c:215 now with a patch attacking such ICE posted at https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586290.html
[Bug lto/56963] GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56963 Richard Biener changed: What|Removed |Added CC||linuxsquirrel.dev at gmail dot com --- Comment #10 from Richard Biener --- *** Bug 57715 has been marked as a duplicate of this bug. ***
[Bug lto/57715] lto1.exe: internal compiler error: in add_symbol_to_partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57715 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Richard Biener --- Closing as duplicate in the attempt to weed out old bugs that lack reproducers. *** This bug has been marked as a duplicate of bug 56963 ***
[Bug c++/93809] bogus error class tag used in naming union on typedef typename ::U U2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93809 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/83469] union is not accepted as a valid class-key in template name resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83469 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- I have a patch for this and PR 93809
[Bug tree-optimization/103596] [9/10/11/12 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103596
Andrew Pinski changed:
What|Removed |Added
Known to work||7.5.0
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2021-12-07
Known to fail||8.1.0
--- Comment #2 from Andrew Pinski ---
Confirmed.
Reduced testcase:
int n;
void qux (int a){}
int baz (void)
{
return -1;
}
__attribute__ ((returns_twice)) int
bar (int b)
{
if (n != 0)
{
switch (b) {
default: return n + b;
case 0:
case 2:;
}
if (n == 2)
return 0;
}
__builtin_unreachable();
}
void
foo (void)
{
qux (n);
bar (baz ());
}
CUT -
Only -O3 is needed to produce the ICE with the above testcase.
And it was working in GCC 7.5.0 with the above one and started to fail in GCC
8.1.0.
[Bug tree-optimization/103596] [9/10/11/12 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103596
Andrew Pinski changed:
What|Removed |Added
Summary|[11/12 Regression] ICE: |[9/10/11/12 Regression]
|tree check: expected class |ICE: tree check: expected
|'type', have 'exceptional' |class 'type', have
|(error_mark) in |'exceptional' (error_mark)
|useless_type_conversion_p, |in
|at gimple-expr.c:88 |useless_type_conversion_p,
||at gimple-expr.c:88
Target Milestone|--- |9.5
--- Comment #1 from Andrew Pinski ---
Testcase which shows this is an older bug:
int n;
void
qux (int a)
{
}
int
baz (void)
{
return -1;
}
__attribute__ ((returns_twice)) int
bar (int b)
{
if (n != 0)
{
switch (b) {
default: return n + b;
case 0:
case 2:;
}
if (n == 2)
return 0;
}
}
void
foo (void)
{
qux (n);
bar (baz ());
}
[Bug tree-optimization/103596] New: [11/12 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103596
Bug ID: 103596
Summary: [11/12 Regression] ICE: tree check: expected class
'type', have 'exceptional' (error_mark) in
useless_type_conversion_p, at gimple-expr.c:88
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc 12.0.0 20211205 snapshot (g:c9419faef0bfaf31e6a6f744baa064892e0d105c) ICEs
when compiling the following testcase w/ -O3 --param case-values-threshold=1:
int n;
void
qux (int a)
{
}
int
baz (void)
{
return -1;
}
__attribute__ ((returns_twice)) int
bar (int b)
{
if (n != 0)
{
if (b != 2)
if (b != 0)
return n + b;
if (n == 2)
return 0;
}
}
void
foo (void)
{
qux (n);
bar (baz ());
}
% gcc-12.0.0 -O3 --param case-values-threshold=1 -c ubzlb8tx.c
during GIMPLE pass: fre
ubzlb8tx.c: In function 'foo':
ubzlb8tx.c:33:1: internal compiler error: tree check: expected class 'type',
have 'exceptional' (error_mark) in useless_type_conversion_p, at
gimple-expr.c:88
33 | }
| ^
0x78363b tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/tree.c:8752
0x6b6df4 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/tree.h:3564
0x6b6df4 useless_type_conversion_p(tree_node*, tree_node*)
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/gimple-expr.c:88
0xee4e5a verify_gimple_comparison
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/tree-cfg.c:3550
0xef9fe9 verify_gimple_in_cfg(function*, bool)
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/tree-cfg.c:5514
0xdbbecf execute_function_todo
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/passes.c:2084
0xdbc40c execute_todo
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/passes.c:2138
[Bug c++/83469] union is not accepted as a valid class-key in template name resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83469 --- Comment #3 from Andrew Pinski --- (In reply to Marek Polacek from comment #1) > (gdb) p type > $4 = > (gdb) p class_key > $5 = union_type > > Should we allow such a combination? Yes. The code change here will also fix PR 93809. Let me try to see if I can fix it correctly.
[Bug c++/95873] Duplicated warning message "'class' tag used in naming 'union a'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95873 --- Comment #2 from Andrew Pinski --- The warning is invalid in this case anyways so even though there is a duplicated warning it only happens with valid code which should not warn at all.
[Bug c++/93809] bogus error class tag used in naming union on typedef typename ::U U2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93809 --- Comment #4 from Andrew Pinski --- *** Bug 95873 has been marked as a duplicate of this bug. ***
[Bug c++/95873] Duplicated warning message "'class' tag used in naming 'union a'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95873 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 93809. *** This bug has been marked as a duplicate of bug 93809 ***
[Bug c++/94404] [meta-bug] C++ core issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 Bug 94404 depends on bug 67013, which changed state. Bug 67013 Summary: [DR569] Compilation error for well-formed program with empty declaration in the global namespace https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67013 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/96068] Extra semicolon outside of a function should be allowed after c++11?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96068 Andrew Pinski changed: What|Removed |Added CC||anders.granlund.0 at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 67013 has been marked as a duplicate of this bug. ***
[Bug c++/67013] [DR569] Compilation error for well-formed program with empty declaration in the global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67013 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #12 from Andrew Pinski --- Fixed in GCC 11+, even though this is an older bug report of the problem, PR 96068 already has the reference to the commit message and all so closing as a dup of that bug. *** This bug has been marked as a duplicate of bug 96068 ***
[Bug c++/90107] [9/10/11/12 Regression] rejects-valid on global-namespace-qualified variable declared after class definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90107 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.5
[Bug c++/90107] [9/10/11/12 Regression] rejects-valid on global-namespace-qualified variable declared after class definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90107
Andrew Pinski changed:
What|Removed |Added
Known to fail||4.6.4
Summary|rejects-valid on|[9/10/11/12 Regression]
|global-namespace-qualified |rejects-valid on
|variable declared after |global-namespace-qualified
|class definition|variable declared after
||class definition
Known to work||4.1.2, 4.4.7, 4.5.3
--- Comment #1 from Andrew Pinski ---
Full valid testcase (instead of 2 sources combined together):
struct A;
namespace N { extern A a; }
struct A {} ::N::a;
struct A1;
struct B { static A1 a1; };
struct A1 {} ::B::a1;
[Bug c++/66892] [9/10/11/12 Regression] [DR355] Fix of core language defect 355 has status c++11 but is not implemented yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66892 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.5 Summary|[DR355] Fix of core |[9/10/11/12 Regression] |language defect 355 has |[DR355] Fix of core |status c++11 but is not |language defect 355 has |implemented yet |status c++11 but is not ||implemented yet Known to fail||3.4.0 Known to work||3.3.3 --- Comment #4 from Andrew Pinski --- Since the defect report says it work in GCC at the time I am going to assume this actually did and it was introduced by the new parser so this is a regression.
[Bug c++/66892] [DR355] Fix of core language defect 355 has status c++11 but is not implemented yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66892 Andrew Pinski changed: What|Removed |Added CC||haoxintu at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 95610 has been marked as a duplicate of this bug. ***
[Bug c++/95610] GCC rejects class definition with a global qualification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95610 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 66892. *** This bug has been marked as a duplicate of bug 66892 ***
[Bug c++/66892] [DR355] Fix of core language defect 355 has status c++11 but is not implemented yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66892
Andrew Pinski changed:
What|Removed |Added
Alias||cwg355
--- Comment #2 from Andrew Pinski ---
testcase:
struct A;
struct ::A { };
namespace B {
struct A;
}
struct ::B::A { };
Looks the error message was added with the new parser in GCC 3.4.0.
The fix might be easy but I have not tested it to see if there is any
regressions.
That is remove the following code from parser.c:
/* Issue the error about the overly-qualified name now. */
if (qualified_p)
{
cp_parser_error (parser,
"global qualification of class name is invalid");
type = error_mark_node;
goto out;
}
else
[Bug c++/44400] member function can have same name as constructor if declared using a typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44400 Andrew Pinski changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- *** Bug 91013 has been marked as a duplicate of this bug. ***
[Bug c++/91013] member function can have same name as constructor if declared using a typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91013 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 44400. *** This bug has been marked as a duplicate of bug 44400 ***
[Bug target/100868] PPC: Inefficient code for vec_reve(vector double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100868 HaoChen Gui changed: What|Removed |Added Resolution|--- |FIXED CC||guihaoc at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #3 from HaoChen Gui --- Fixed on trunk.
[Bug c++/34810] [DR1310] accepts invalid dependent type in template class method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810 Andrew Pinski changed: What|Removed |Added Summary|accepts invalid |[DR1310] accepts invalid |dependent(?) type in|dependent type in template |template class method |class method Blocks||94404 Alias||cwg1310 --- Comment #12 from Andrew Pinski --- Found what changed clang to start rejecting it: http://wg21.link/cwg1310 [Moved to DR at the April, 2013 meeting.] Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 [Bug 94404] [meta-bug] C++ core issues
[Bug target/103571] ABI: V2HF, V4HF and V8HFmode argument passing issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103571 --- Comment #2 from Hongtao.liu --- > > Also, baz iz highly un-optimal for 32bit targets. Yes, it needs to be fixed, note w/ -mavx512fp16 codegen for baz is optimal on 32-bit target, maybe related to vector_mode_supported_p, but then why codegen for baz on 64-bit target is optimal w/o TARGET_AVX512FP16?
[Bug c++/34810] accepts invalid dependent(?) type in template class method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810
--- Comment #11 from Andrew Pinski ---
Someone who has better understanding of the C++ standard should answer the
question if this is valid or not because I don't understand all of the specific
rules rules which are in play here. Especially when there has been some defect
reports in this area before even.
The question is:
class B { };
class A: public B {
A::B ab; // B is the inherited injected B
};
typename A::A a;
vs:
class B { };
class A: public B {
A::B ab; // B is the inherited injected B
};
struct A::A a;
CWG 318 clearifies the struct case but I don't see why typename would be
handled here any different from struct case.
[Bug target/103554] -mavx generates worse code on scalar code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103554 --- Comment #8 from Hongtao.liu --- > but the x86 backend chooses to not let the vectorizer compare costs with > different vector sizes but instead asks it to pick the first working > solution from the vector of modes to consider (and in that order). We > might want to reconsider that (maybe at least for BB vectorization and > maybe with some extra special mode?). Shouldn't the vectorizer compare costs of different vector factors and choose the samllest one, or vectorizer already support the corresponding framework, but the x86 backend doesn't implement the corresponding target_hook?
[Bug c++/34810] accepts invalid dependent(?) type in template class method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810 --- Comment #10 from Andrew Pinski --- Oh this: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#318 In a lookup in which the constructor is an acceptable lookup result, if the nested-name-specifier nominates a class C and the name specified after the nested-name-specifier, when looked up in C, is the injected class name of C (clause Clause 11 [class]), the name is instead considered to name the constructor of class C. [Note: For example, the constructor is not an acceptable lookup result in an elaborated type specifier so the constructor would not be used in place of the injected class name.] So the question becomes is typename is enough here.
[Bug c++/40294] method definition can have the class scope multiple time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40294 --- Comment #4 from Andrew Pinski --- *** Bug 33659 has been marked as a duplicate of this bug. ***
[Bug c++/33659] g++ permits duplicate class names in definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33659 --- Comment #3 from Andrew Pinski --- This is actually valid code, the class name is injected and can be used in this context (the last one is used to name the constructor otherwise). Dup of bug 40294 which is recording all of the valid cases which were closed as a dup of bug 11764. *** This bug has been marked as a duplicate of bug 40294 ***
[Bug c++/40294] method definition can have the class scope multiple time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40294 Andrew Pinski changed: What|Removed |Added Resolution|DUPLICATE |INVALID --- Comment #3 from Andrew Pinski --- Actually this is valid code, the class name is injected always and will be used for lookup.
[Bug c++/34810] accepts invalid dependent(?) type in template class method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810 Andrew Pinski changed: What|Removed |Added Host|i386-portbld-freebsd6.2 | Build|i386-portbld-freebsd6.2 | Target|i386-portbld-freebsd6.2 | --- Comment #9 from Andrew Pinski --- Note ICC and MSVC both accept this testcase (and the duplicated testcases) while clang is rejects it.
[Bug c++/34810] accepts invalid dependent(?) type in template class method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810 --- Comment #8 from Andrew Pinski --- DR 147 is definitely the defect report here. Reading the new text still gives me questions about the case if typename is used: If the nested-name-specifier nominates a class C, and the name specified after the nested-name-specifier, when looked up in C, is the injected-class-name of C (clause Clause 11 [class]), the name is instead considered to name the constructor of class C. Such a constructor name shall only be used in the declarator-id of a constructor definition that appears outside of the class definition.
[Bug c++/34810] accepts invalid dependent(?) type in template class method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=11764 --- Comment #7 from Andrew Pinski --- Related to the older bug 11764 (which is fixed the case without typename I think).
[Bug c++/89642] gcc rejects valid implicit typename context in cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89642 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-12-07 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- Confirmed.
[Bug c++/34810] accepts invalid dependent(?) type in template class method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810 Andrew Pinski changed: What|Removed |Added CC||vgheorgh at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 66350 has been marked as a duplicate of this bug. ***
[Bug c++/66350] typename should be forbidden in inheriting constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66350 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #6 from Andrew Pinski --- This is just a dup of bug 34810. *** This bug has been marked as a duplicate of bug 34810 ***
[Bug c++/34810] accepts invalid dependent(?) type in template class method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810 Andrew Pinski changed: What|Removed |Added CC||ahuszagh at gmail dot com --- Comment #5 from Andrew Pinski --- *** Bug 82347 has been marked as a duplicate of this bug. ***
[Bug c++/82347] Class Name Injection and Constructor Typenames
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82347 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 34810. *** This bug has been marked as a duplicate of bug 34810 ***
[Bug c++/34810] accepts invalid dependent(?) type in template class method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34810 Andrew Pinski changed: What|Removed |Added CC||johelegp at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 103564 has been marked as a duplicate of this bug. ***
[Bug c++/103564] type-requirement that names a constructor should fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103564 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 34810. *** This bug has been marked as a duplicate of bug 34810 ***
[Bug c++/103564] type-requirement that names a constructor should fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103564 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > Maybe there is defect report in this area. Note even the original testcase MSVC accepts too.
[Bug c++/103564] type-requirement that names a constructor should fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103564
--- Comment #1 from Andrew Pinski ---
Hmm, this is not really concept related, because GCC/ICC/MSVC all accept the
following too:
struct base { };
template
void f(void)
{
typename T::base a;
};
int main(void)
{
f();
}
--- CUT
While clang rejects it.
Maybe there is defect report in this area.
[Bug c++/103566] confusing error message for typedefs with initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103566 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=7353 --- Comment #1 from Andrew Pinski --- yes there used to be an (undocumented) GNU extension which was removed in GCC 3.2 (it caused ICE in GCC 3.1 but was ok for GCC 3.0), see PR 7353. The extension was: typedef A = 0; Which would be similar to: typedef decltype(0) A; Confirmed.
[Bug c++/103569] Type alias from result of lambda call in unevaluated context, used in template, is inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103569 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||rejects-valid, wrong-code Last reconfirmed||2021-12-07 --- Comment #1 from Andrew Pinski --- Confirmed. I get the feeling like integer promotion is happening for some reason when it should not be. Note: static_assert(std::is_same_v); // !! Should really be: static_assert(!std::is_same_v); // !! if we want a testcase that goes into the testsuite.
[Bug target/103594] [12 Regression] ICE in get, at cgraph.h:1335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103594 --- Comment #2 from Andrew Pinski --- Created attachment 51937 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51937=edit Rewrite ix86_call_use_plt_p to be better Here is a rewrite and adds the check for FUNCTION_DECL before calling of cgraph_node::get. I am not going to test this though.
[Bug target/103594] [12 Regression] ICE in get, at cgraph.h:1335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103594 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-12-07 --- Comment #1 from Andrew Pinski --- Confirmed caused by: r12-5771
[Bug c++/103186] [11/12 Regression] ICE with lambdas as default since r11-7965-g23be03a0f243a084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103186 Andrew Pinski changed: What|Removed |Added CC||mortenkschou at gmail dot com --- Comment #10 from Andrew Pinski --- *** Bug 103595 has been marked as a duplicate of this bug. ***
[Bug c++/103595] [11/12 Regression] std::function parameter with default value lambda, fails with error redefinition of 'const char _ZT... []'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103595 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 103186. That is they are the same underlying problem. *** This bug has been marked as a duplicate of bug 103186 ***
[Bug c++/103186] [11/12 Regression] ICE with lambdas as default since r11-7965-g23be03a0f243a084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103186
--- Comment #9 from Andrew Pinski ---
Just lambdas as default is needed really, reduced testcase:
struct f
{
template
f(const T1&){}
};
template class A {
public:
void foo(A a, const f& fn = [](){}) { }
void bar(A a) { foo(a); }
};
int main() {
A a;
a.foo(a);
a.bar(a);
return 0;
}
[Bug c++/103595] [11/12 Regression] std::function parameter with default value lambda, fails with error redefinition of 'const char _ZT... []'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103595 Andrew Pinski changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |11.3 Summary|[11 Regression] |[11/12 Regression] |std::function parameter |std::function parameter |with default value lambda, |with default value lambda, |fails with error|fails with error |redefinition of 'const char |redefinition of 'const char |_ZT... []' |_ZT... []'
[Bug c++/103595] [11 Regression] std::function parameter with default value lambda, fails with error redefinition of 'const char _ZT... []'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103595
--- Comment #1 from Andrew Pinski ---
typeinfo name for A::foo(A, std::function const&)::{default
arg#1}::{lambda()#1}
[Bug c++/103595] New: [11 Regression] std::function parameter with default value lambda, fails with error redefinition of 'const char _ZT... []'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103595
Bug ID: 103595
Summary: [11 Regression] std::function parameter with default
value lambda, fails with error redefinition of 'const
char _ZT... []'
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mortenkschou at gmail dot com
Target Milestone: ---
Created attachment 51936
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51936=edit
preprocessed source
A (templated) function takes a const std::function& as a parameter with a
lambda as the default value. When this function is called from two separate
places (in a certain way and order) gcc-11 fails with the following error:
bug.cpp:12:1: error: redefinition of ‘const char
_ZTSZN1AIiE3fooES0_RKSt8functionIFvvEEEd_UlvE_ []’
12 | }
| ^
bug.cpp:12:1: note: ‘const char _ZTSZN1AIiE3fooES0_RKSt8functionIFvvEEEd_UlvE_
[43]’ previously defined here
See minimal code example (https://godbolt.org/z/Mqs1Mbb1z)
#include
template class A {
public:
void foo(A a, const std::function& fn = [](){}) { }
void bar(A a) { foo(a); }
};
int main() {
A a;
a.foo(a);
a.bar(a);
return 0;
}
This code compiles (according to godbolt.org) on gcc-10.3 and prior as well as
clang and MSVC, but fails on gcc-11.x.
Note that calling bar before foo compiles successfully on gcc-11.
I don't know if this is a compiler error, an error in
implementation, or a violation of the C++ standard.? But my bet would be on a
compiler error.
Full compilation output. (Also .ii file in attachment)
$ gcc -v --save-temp bug.cpp
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.2.0-7ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-ZPT0kp/gcc-11-11.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-ZPT0kp/gcc-11-11.2.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Ubuntu 11.2.0-7ubuntu2)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=x86-64'
'-dumpdir' 'a-'
/usr/lib/gcc/x86_64-linux-gnu/11/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE bug.cpp -mtune=generic -march=x86-64
-fpch-preprocess -fasynchronous-unwind-tables -fstack-protector-strong -Wformat
-Wformat-security -fstack-clash-protection -fcf-protection -o a-bug.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/11"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/11/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/11
/usr/include/x86_64-linux-gnu/c++/11
/usr/include/c++/11/backward
/usr/lib/gcc/x86_64-linux-gnu/11/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=x86-64'
'-dumpdir' 'a-'
/usr/lib/gcc/x86_64-linux-gnu/11/cc1plus -fpreprocessed a-bug.ii -quiet
-dumpdir a- -dumpbase bug.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64
-version -fasynchronous-unwind-tables -fstack-protector-strong -Wformat
-Wformat-security -fstack-clash-protection -fcf-protection -o a-bug.s
GNU C++17 (Ubuntu 11.2.0-7ubuntu2) version 11.2.0 (x86_64-linux-gnu)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.0, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param
[Bug ipa/103594] [12 Regression] ICE in get, at cgraph.h:1335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103594 Andrew Pinski changed: What|Removed |Added CC||marxin at gcc dot gnu.org Component|target |ipa Target Milestone|--- |12.0
[Bug target/103594] New: [12 Regression] ICE in get, at cgraph.h:1335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103594 Bug ID: 103594 Summary: [12 Regression] ICE in get, at cgraph.h:1335 Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: x86_64-unknown-linux-gnu gcc 12.0.0 20211205 snapshot (g:c9419faef0bfaf31e6a6f744baa064892e0d105c) ICEs when compiling gcc/testsuite/gcc.c-torture/compile/pr37433.c and a few other testcases w/ -O1: % x86_64-unknown-linux-gnu-gcc-12.0.0 -O1 -c gcc/testsuite/gcc.c-torture/compile/pr37433.c during RTL pass: expand gcc/testsuite/gcc.c-torture/compile/pr37433.c: In function 'regex_subst': gcc/testsuite/gcc.c-torture/compile/pr37433.c:6:11: internal compiler error: in get, at cgraph.h:1335 6 | return (*(int (*)(int))subst) (0); | ~^ 0x79e142 cgraph_node::get(tree_node const*) /var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/cgraph.h:1335 0x7a0d8e cgraph_node::get(tree_node const*) /var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/config/i386/i386.c:15988 0x7a0d8e ix86_call_use_plt_p(rtx_def*) /var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/config/i386/i386.c:15994 0x7a0d8e ix86_call_use_plt_p(rtx_def*) /var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/config/i386/i386.c:15986 0x12eea5a ix86_expand_call(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, bool) /var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/config/i386/i386-expand.c:9136 0x1797462 gen_call_value(rtx_def*, rtx_def*, rtx_def*, rtx_def*) /var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/config/i386/i386.md:14694 0x1215a38 target_gen_call_value /var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/config/i386/i386.md:14618 0x9a1273 emit_call_1 /var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/calls.c:466 0x9a8e64 expand_call(tree_node*, rtx_def*, int) /var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/calls.c:3606 0xaef80e expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/expr.c:11536 0xafcd7e store_expr(tree_node*, rtx_def*, int, bool, bool) /var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/expr.c:6087 0xafe560 expand_assignment(tree_node*, tree_node*, bool) /var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/expr.c:5819 0x9be46b expand_call_stmt /var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/cfgexpand.c:2829 0x9be46b expand_gimple_stmt_1 /var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/cfgexpand.c:3864 0x9be46b expand_gimple_stmt /var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/cfgexpand.c:4028 0x9c482f expand_gimple_basic_block /var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/cfgexpand.c:6069 0x9c6396 execute /var/tmp/portage/sys-devel/gcc-12.0.0_p20211205/work/gcc-12-20211205/gcc/cfgexpand.c:6795
[Bug rtl-optimization/70782] zero-initialized long returned by value generates useless stores/loads to the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70782
--- Comment #3 from Andrew Pinski ---
For the memset/memcpy version, I wonder if we should convert:
MEM[(char * {ref-all})] = _10;
...
MEM [(char * {ref-all})] = _8;
Into using BIT_FIELD_REF.
[Bug target/57009] Select best typed instruction for scalar bitwise operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57009
--- Comment #2 from Andrew Pinski ---
(In reply to Marc Glisse from comment #1)
> union A { double d; unsigned long long i; };
> bool f(double x){
> A a; a.d = x;
> unsigned long long inf = 0x7ff0;
> return (a.i & inf) != inf;
> }
>
> (I use != and not < in the example above because gcc insists on creating a
> new constant inf-1 and replacing
[Bug target/26546] missed optimization with respect of vector intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26546 --- Comment #4 from Andrew Pinski --- Without the uninitialized variable even LLVM produces the same assembly code. Is there really anything more to opimize here?
[Bug analyzer/103533] Enable "taint" state machine with -fanalyzer without requiring -fanalyzer-checker=taint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103533
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:c9543403c19fdc3c3b5a8db8546340de085bd14e
commit r12-5815-gc9543403c19fdc3c3b5a8db8546340de085bd14e
Author: David Malcolm
Date: Mon Dec 6 14:04:35 2021 -0500
analyzer: fix equivalence class state purging [PR103533]
Whilst debugging state explosions seen when enabling taint detection
with -fanalyzer (PR analyzer/103533), I noticed that constraint
manager instances could contain stray, redundant constants, such
as this instance:
constraint_manager:
equiv classes:
ec0: {(int)0 == [m_constant]â0â}
ec1: {(size_t)4 == [m_constant]â4â}
constraints:
where there are two equivalence classes, each just containing a
constant, with no constraints using them.
This patch makes constraint_manager::canonicalize more aggressive
about purging state, handling the case of purging a redundant
EC containing just a constant.
gcc/analyzer/ChangeLog:
PR analyzer/103533
* constraint-manager.cc (equiv_class::contains_non_constant_p):
New.
(constraint_manager::canonicalize): Call it when determining
redundant ECs.
(selftest::test_purging): New selftest.
(selftest::run_constraint_manager_tests): Likewise.
* constraint-manager.h (equiv_class::contains_non_constant_p):
New decl.
Signed-off-by: David Malcolm
[Bug tree-optimization/29756] SSE intrinsics hard to use without redundant temporaries appearing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29756
Andrew Pinski changed:
What|Removed |Added
Component|target |tree-optimization
--- Comment #17 from Andrew Pinski ---
Confirmed on the trunk, this is no longer a target issue:
__builtin_ia32_shufps is lowered into a VEC_PERM_EXPR now:
_1 = MEM[(const float &)v_7(D) + 12];
MEM[(float &)] = _1;
_24 = D.5891._rep.vecf;
_25 = VEC_PERM_EXPR <_24, _24, { 0, 0, 0, 0 }>;
[Bug target/95740] Failure to avoid using the stack when interpreting a float as an integer when it is modified afterwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95740 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Andrew Pinski --- as mentioned fixed in GCC 12.
[Bug tree-optimization/103584] Points-to information is not conservatively correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103584 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-12-06 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug d/103558] [12 Regression] perf_event.d:2076:32: error: module 'bitmanip' is in file 'std/bitmanip.d' which cannot be read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103558 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Summary|perf_event.d:2076:32: |[12 Regression] |error: module 'bitmanip' is |perf_event.d:2076:32: |in file 'std/bitmanip.d'|error: module 'bitmanip' is |which cannot be read|in file 'std/bitmanip.d' ||which cannot be read
[Bug c/103492] 2 * new warnings in clang build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103492
--- Comment #7 from Andrew Pinski ---
reduced testcase for clang's warning:
struct f
{
unsigned a:2;
unsigned b:(32-2);
};
int g(struct f *b)
{
switch (b->a)
{
case 0:
return 2;
case 1:
return 3;
case 2:
return 5;
case 3:
return 1;
}
}
[Bug d/103558] perf_event.d:2076:32: error: module 'bitmanip' is in file 'std/bitmanip.d' which cannot be read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103558 Iain Buclaw changed: What|Removed |Added CC||doko at debian dot org --- Comment #2 from Iain Buclaw --- *** Bug 103582 has been marked as a duplicate of this bug. ***
[Bug d/103582] [12 Regression] trunk 20210501 ftbfs in libphobos on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103582 Iain Buclaw changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Iain Buclaw --- Duplicate of same issue for HPPA. *** This bug has been marked as a duplicate of bug 103558 ***
[Bug c/47781] warnings from custom printf format specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 --- Comment #26 from joseph at codesourcery dot com --- It's hard to define something that is sufficiently general to be useful but doesn't expose too much of the details of GCC's internal data structures for describing standard formats. %b for binary is now a standard C23 format and supported for GCC 12 and later.
[Bug c/102291] [9/10/11/12 Regression] wrong overflow warning for compound expression conversion and bit_and expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102291 --- Comment #7 from joseph at codesourcery dot com --- I don't think TREE_OVERFLOW should be introduced in folding expressions that didn't have undefined behavior in the original source code.
[Bug c++/103593] [11/12 Regression] Naming the constructor of a template class without using the injected-class-name causes parse error with C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103593 Andrew Pinski changed: What|Removed |Added Known to work||10.3.0 Summary|Naming the constructor of a |[11/12 Regression] Naming |template class without |the constructor of a |using the |template class without |injected-class-name causes |using the |parse error with C++20 |injected-class-name causes ||parse error with C++20 Target Milestone|--- |11.3 Known to fail||11.1.0, 11.2.0, 12.0 --- Comment #1 from Andrew Pinski --- Could there be a defect report in this area?
[Bug fortran/103588] ICE: Simplification error in gfc_ref_dimen_size, at fortran/array.c:2407
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103588 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2021-December/057134.html
[Bug c++/103593] New: Naming the constructor of a template class without using the injected-class-name causes parse error with C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103593
Bug ID: 103593
Summary: Naming the constructor of a template class without
using the injected-class-name causes parse error with
C++20
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: enolan at alumni dot cmu.edu
Target Milestone: ---
This seems to be a GCC 11/12 regression.
https://godbolt.org/z/vTPs9reTW
Flags: -std=c++20
Code:
```
template
class Foo {
public:
Foo();
};
```
Result:
```
:4:10: error: expected unqualified-id before ')' token
4 | Foo();
| ^
```
[Bug fortran/103591] ICE in gfc_compare_string, at fortran/arith.c:1119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103591 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2021-December/057132.html
[Bug testsuite/103545] [12 regression] gcc.target/powerpc/undef-bool-2.c fails after r12-5580
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103545 --- Comment #1 from CVS Commits --- The master branch has been updated by Paul Clarke : https://gcc.gnu.org/g:325c6163a33af91264d1b7817a45b8425d5e6a4f commit r12-5814-g325c6163a33af91264d1b7817a45b8425d5e6a4f Author: Paul A. Clarke Date: Mon Dec 6 16:16:31 2021 -0600 rs6000: Fix errant "vector" instead of "__vector" Fixes 85289ba36c2e62de84cc0232c954d9a74bda708a. 2021-12-06 Paul A. Clarke gcc PR target/103545 * config/rs6000/xmmintrin.h (_mm_movemask_ps): Replace "vector" with "__vector".
[Bug jit/103562] Jitted code produces incorrect result when returning 3-member struct from internal function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103562
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #2 from Andrew Pinski ---
(In reply to Martin Liška from comment #1)
> So there's fishy the [return slot optimization].
RSO should be fine there, that is what you get even with the C code version
from GCC (-O2 -fno-inline):
;; Function deref (deref, funcdef_no=0, decl_uid=1982, cgraph_uid=1,
symbol_order=0)
struct my_struct deref (struct my_struct * ptr)
{
[local count: 1073741824]:
= *ptr_2(D);
return ;
}
;; Function get_a (get_a, funcdef_no=1, decl_uid=1985, cgraph_uid=2,
symbol_order=1)
long int get_a (struct my_struct * s)
{
struct my_struct D.1993;
long int _4;
[local count: 1073741824]:
D.1993 = deref (s_2(D)); [return slot optimization]
_4 = D.1993.a;
return _4;
}
[Bug c++/65861] libstdc++ is silently generating wrong code when its std::search is given an input iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65861 --- Comment #13 from Andrew Pinski --- (In reply to Jonathan Wakely from comment #11) > (In reply to Andrew Pinski from comment #10) > > GCC 10+ started to reject the code just the same as CLANG does. > > Clang doesn't reject it, libc++ does. Clang with libstdc++ accepts it, and > so does GCC trunk (you just need some more headers for recent versions): I should have known the more headers for recent versions :).
[Bug c++/103583] Range loop: "error: 'begin' was not declared in this scope" when 'end' is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103583 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-12-06 Severity|normal |enhancement --- Comment #4 from Andrew Pinski --- (In reply to Jonathan Wakely from comment #3) > Another option would be to do lookup for begin(a) and end(a) with errors > suppressed, and if they aren't found, issue a custom diagnostic saying > something like "no suitable begin/end pair available for range-based 'for' > loop". I think this is a good option. Confirmed.
[Bug target/103565] GCC emits more assembly than clang for carry flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103565 --- Comment #4 from cqwrteur --- (In reply to Andrew Pinski from comment #3) > The tree level looks good: > _6 = (long long unsigned int) carry_1(D); > _13 = .ADD_OVERFLOW (a_3(D), _6); > temp_7 = REALPART_EXPR <_13>; > _14 = IMAGPART_EXPR <_13>; > _15 = .ADD_OVERFLOW (b_4(D), temp_7); > _8 = REALPART_EXPR <_15>; > _16 = IMAGPART_EXPR <_15>; > *out_5(D) = _8; > _9 = _16 != 0; > _10 = _14 != 0; > _11 = _9 | _10; so is that possible to understand the pattern of addcarry in C or C++ for GCC? clang does that by adding new builtins but Jakub said pattern matching is better since the compiler can optimize it later. I think it is totally possible for using pattern matching instead of built-in.
[Bug target/103565] GCC emits more assembly than clang for carry flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103565 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|tree-optimization |target --- Comment #3 from Andrew Pinski --- The tree level looks good: _6 = (long long unsigned int) carry_1(D); _13 = .ADD_OVERFLOW (a_3(D), _6); temp_7 = REALPART_EXPR <_13>; _14 = IMAGPART_EXPR <_13>; _15 = .ADD_OVERFLOW (b_4(D), temp_7); _8 = REALPART_EXPR <_15>; _16 = IMAGPART_EXPR <_15>; *out_5(D) = _8; _9 = _16 != 0; _10 = _14 != 0; _11 = _9 | _10;
[Bug tree-optimization/103592] fatigue2 benchmarks on zen runs 43% faster with -fno-tree-vectorize -fno-tree-slp-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103592 --- Comment #1 from hubicka at kam dot mff.cuni.cz --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 > [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95) note that fatigue2 is polyhedron, not spec...
[Bug tree-optimization/103565] GCC emits more assembly than clang for carry flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103565 --- Comment #2 from Andrew Pinski --- The difference is just argument and return register differences (and maybe a register allocation issue). That is the extra instructions are: for add_carry_pattern_test: movzx edi, dil mov r8, rcx xor ecx, ecx for add_carry_x86_intrinsics: movzx edi, dil
[Bug fortran/103591] ICE in gfc_compare_string, at fortran/arith.c:1119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103591
--- Comment #2 from anlauf at gcc dot gnu.org ---
Untested fix:
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 2bf21434a42..52bc5af7542 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -6075,6 +6075,15 @@ match_case_selector (gfc_case **cp)
m = gfc_match_init_expr (>high);
if (m == MATCH_ERROR)
goto cleanup;
+ if (m == MATCH_YES
+ && c->high->ts.type != BT_LOGICAL
+ && c->high->ts.type != BT_INTEGER
+ && c->high->ts.type != BT_CHARACTER)
+ {
+ gfc_error ("Expression in CASE selector at %L cannot be %s",
+>high->where, gfc_typename (c->high));
+ goto cleanup;
+ }
/* MATCH_NO is fine. It's OK if nothing is there! */
}
}
[Bug c/103587] [10/11/12 Regression] ICE in c_parser_consume_token, at c/c-parser.c:850
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103587 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.0 Last reconfirmed||2021-12-06 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug fortran/103591] ICE in gfc_compare_string, at fortran/arith.c:1119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103591 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||anlauf at gcc dot gnu.org Last reconfirmed||2021-12-06 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug fortran/103589] ICE in gfc_match_varspec, at fortran/primary.c:2551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103589 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-12-06 CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug fortran/103588] ICE: Simplification error in gfc_ref_dimen_size, at fortran/array.c:2407
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103588
--- Comment #2 from anlauf at gcc dot gnu.org ---
Untested patch:
diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index 5762c8d92d4..5f9ed17f919 100644
--- a/gcc/fortran/array.c
+++ b/gcc/fortran/array.c
@@ -2403,11 +2403,9 @@ gfc_ref_dimen_size (gfc_array_ref *ar, int dimen, mpz_t
*result, mpz_t *end)
{
stride_expr = gfc_copy_expr(ar->stride[dimen]);
- if(!gfc_simplify_expr(stride_expr, 1))
- gfc_internal_error("Simplification error");
-
- if (stride_expr->expr_type != EXPR_CONSTANT
- || mpz_cmp_ui (stride_expr->value.integer, 0) == 0)
+ if (!gfc_simplify_expr (stride_expr, 1)
+|| stride_expr->expr_type != EXPR_CONSTANT
+|| mpz_cmp_ui (stride_expr->value.integer, 0) == 0)
{
mpz_clear (stride);
return false;
[Bug tree-optimization/103592] New: fatigue2 benchmarks on zen runs 43% faster with -fno-tree-vectorize -fno-tree-slp-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103592 Bug ID: 103592 Summary: fatigue2 benchmarks on zen runs 43% faster with -fno-tree-vectorize -fno-tree-slp-vectorize Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- While looking into -fno-inline-functions-called-once difference I noticed that on zen hardware I get: - 0m33s runtime for fatigue2 benchmark (from phoronix) when built with -Ofast -march=native -fno-slp-vectorize -fno-tree-vectorize - 0m57s for -Ofast -march=native binary
[Bug fortran/103588] ICE: Simplification error in gfc_ref_dimen_size, at fortran/array.c:2407
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103588 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-12-06 CC||anlauf at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug fortran/101632] NON_RECURSIVE procedure prefix is unsupported. F2018 defaults to recursive procedures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101632
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-12-06
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #3)
> Better patch.
That patch produces many regressions in the test suite. Seems we're not ready
yet for RECURSIVE as the default.
Removing or commenting out the hunk
+ /* If neither NON_RECURSIVE nor RECURSIVE has been seen and the F2018
+ standard is in play, then mark the the procedure as recursive. */
+ if ((gfc_option.allow_std & GFC_STD_F2018)
+ && !current_attr.non_recursive && !current_attr.recursive)
+{
+ if (!gfc_add_recursive (_attr, NULL))
+ goto error;
+}
+
allows at least parsing of NON_RECURSIVE, while having no effect otherwise.
Still lacking: handling of NON_RECURSIVE in module.c .
[Bug fortran/103591] New: ICE in gfc_compare_string, at fortran/arith.c:1119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103591
Bug ID: 103591
Summary: ICE in gfc_compare_string, at fortran/arith.c:1119
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to at least r5 :
$ cat z1.f90
program p
integer :: n
select case (n)
case ('1':2.)
end select
end
$ gfortran-12-20211205 -c z1.f90
f951: internal compiler error: Segmentation fault
0xd6497f crash_signal
../../gcc/toplev.c:322
0x7640cb gfc_compare_string(gfc_expr*, gfc_expr*)
../../gcc/fortran/arith.c:1119
0x809f46 resolve_select
../../gcc/fortran/resolve.c:8784
0x8138f7 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:12165
0x8157b7 resolve_codes
../../gcc/fortran/resolve.c:17531
0x81587e gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17566
0x7fdba4 resolve_all_program_units
../../gcc/fortran/parse.c:6586
0x7fdba4 gfc_parse_file()
../../gcc/fortran/parse.c:6842
0x84afaf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216
[Bug fortran/103590] New: ICE: find_array_spec(): Missing spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103590 Bug ID: 103590 Summary: ICE: find_array_spec(): Missing spec Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 program p associate (a => 1) print *, [character(a(1)) :: '1'] end associate end $ cat z2.f90 program p character :: b(1) associate (a => 1) b = [character(a(1)) :: '1'] end associate end $ gfortran-12-20211205 -c z1.f90 f951: internal compiler error: find_array_spec(): Missing spec 0x799179 gfc_report_diagnostic ../../gcc/fortran/error.c:874 0x79ace7 gfc_internal_error(char const*, ...) ../../gcc/fortran/error.c:1494 0x81c09f find_array_spec ../../gcc/fortran/resolve.c:4989 0x81c09f gfc_resolve_ref(gfc_expr*) ../../gcc/fortran/resolve.c:5331 0x80c167 resolve_variable ../../gcc/fortran/resolve.c:5842 0x80c167 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7168 0x79f054 gfc_reduce_init_expr(gfc_expr*) ../../gcc/fortran/expr.c:3155 0x780562 char_len_param_value ../../gcc/fortran/decl.c:1129 0x7830b0 gfc_match_char_spec(gfc_typespec*) ../../gcc/fortran/decl.c:3541 0x7cd8c3 gfc_match_type_spec(gfc_typespec*) ../../gcc/fortran/match.c:2144 0x767b10 gfc_match_array_constructor(gfc_expr**) ../../gcc/fortran/array.c:1246 0x7d39a9 match_primary ../../gcc/fortran/matchexp.c:153 0x7d39a9 match_level_1 ../../gcc/fortran/matchexp.c:211 0x7d39a9 match_mult_operand ../../gcc/fortran/matchexp.c:267 0x7d3c08 match_add_operand ../../gcc/fortran/matchexp.c:356 0x7d3e5c match_level_2 ../../gcc/fortran/matchexp.c:480 0x7d3fb2 match_level_3 ../../gcc/fortran/matchexp.c:551 0x7d40a4 match_level_4 ../../gcc/fortran/matchexp.c:599 0x7d40a4 match_and_operand ../../gcc/fortran/matchexp.c:693 0x7d4292 match_or_operand ../../gcc/fortran/matchexp.c:722
[Bug fortran/103589] New: ICE in gfc_match_varspec, at fortran/primary.c:2551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103589 Bug ID: 103589 Summary: ICE in gfc_match_varspec, at fortran/primary.c:2551 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : (valid z2 works, but not the stripped one) $ cat z1.f90 integer(size([character::'1'])) :: a end $ cat z2.f90 program p integer(size([character::'1'])) :: a a = 1 end $ gfortran-12-20211205 -c z1.f90 f951: internal compiler error: Segmentation fault 0xd6497f crash_signal ../../gcc/toplev.c:322 0x8383ba gfc_get_default_type(char const*, gfc_namespace*) ../../gcc/fortran/symbol.c:231 0x801b32 gfc_match_varspec(gfc_expr*, int, bool, bool) ../../gcc/fortran/primary.c:2551 0x804100 gfc_match_rvalue(gfc_expr**) ../../gcc/fortran/primary.c:3930 0x7d39be match_primary ../../gcc/fortran/matchexp.c:157 0x7d39be match_level_1 ../../gcc/fortran/matchexp.c:211 0x7d39be match_mult_operand ../../gcc/fortran/matchexp.c:267 0x7d3c08 match_add_operand ../../gcc/fortran/matchexp.c:356 0x7d3e5c match_level_2 ../../gcc/fortran/matchexp.c:480 0x7d3fb2 match_level_3 ../../gcc/fortran/matchexp.c:551 0x7d40a4 match_level_4 ../../gcc/fortran/matchexp.c:599 0x7d40a4 match_and_operand ../../gcc/fortran/matchexp.c:693 0x7d4292 match_or_operand ../../gcc/fortran/matchexp.c:722 0x7d4362 match_equiv_operand ../../gcc/fortran/matchexp.c:765 0x7d4434 match_level_5 ../../gcc/fortran/matchexp.c:811 0x7d3811 gfc_match_expr(gfc_expr**) ../../gcc/fortran/matchexp.c:870 0x7a1f82 gfc_match_init_expr(gfc_expr**) ../../gcc/fortran/expr.c:3189 0x782b05 gfc_match_kind_spec(gfc_typespec*, bool) ../../gcc/fortran/decl.c:3241 0x7893a9 gfc_match_decl_type_spec(gfc_typespec*, int) ../../gcc/fortran/decl.c:4672 0x78a2e2 gfc_match_prefix(gfc_typespec*) ../../gcc/fortran/decl.c:6418
