[Bug c/108476] Please turn -Wreturn-type on by default for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108476 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=53232 --- Comment #1 from Andrew Pinski --- Note the warning should really be split into two different options. One for the return type of the declaration and one for the missing return in non-void case.
[Bug c/70958] Flag -Wreturn-type does not warn about lacking return statement in main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70958 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup of bug 53232. *** This bug has been marked as a duplicate of bug 53232 ***
[Bug c/53232] No warning for main() without a return statement with -std=c99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53232 Andrew Pinski changed: What|Removed |Added CC||carlos.maziero at gmail dot com --- Comment #10 from Andrew Pinski --- *** Bug 70958 has been marked as a duplicate of this bug. ***
[Bug c/108476] New: Please turn -Wreturn-type on by default for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108476 Bug ID: 108476 Summary: Please turn -Wreturn-type on by default for C Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: alexhenrie24 at gmail dot com Target Milestone: --- According to the documentation, -Wreturn-type does the following: "Warn whenever a function is defined with a return type that defaults to int. Also warn about any return statement with no return value in a function whose return type is not void (falling off the end of the function body is considered returning without a value)." https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html I feel strongly that gcc should turn on -Wreturn-type by default for the following reasons: * Not specifying the return value of a function that returns a non-void value is almost always a bug. * C99 and later do not allow declaring or defining a function without a return type, so there's a good chance that code that omits the return type will break when used with other compilers. * GCC already turns the warning on by default for C++, and all but the most educated of users do not expect C and C++ to be different in this regard, so it gives a false sense of security when no such warnings appear when compiling C code. * Clang already turns the warning on by default for both C and C++, which goes to show that the warning does not come up much in practice. I've personally been bitten by forgetting to return a value from a function, so I hope you will agree that -Wreturn-type is a sensible default to help spot bugs sooner.
[Bug target/108436] ICE in gen_prefetch, at config/i386/i386.md:24155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108436 H.J. Lu changed: What|Removed |Added Target Milestone|--- |13.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from H.J. Lu --- Fixed
[Bug analyzer/108475] New: -Wanalyzer-deref-before-check false positives seen in haproxy's tcpcheck.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108475
Bug ID: 108475
Summary: -Wanalyzer-deref-before-check false positives seen in
haproxy's tcpcheck.c
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54314
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54314=edit
Reproducer
I'm attaching a reduced reproducer for a false +ve from
-Wanalyzer-deref-before-check
https://godbolt.org/z/s9fvbT3fP
Trunk emits this, all of which appear to be a false positives:
: In function 'proxy_parse_httpchk_req':
:138:6: warning: check of 'meth' for NULL after already dereferencing
it [-Wanalyzer-deref-before-check]
138 | if (meth) {
| ^
'proxy_parse_httpchk_req': events 1-14
|
| 110 | if (hdrs || body) {
| | ^
| | |
| | (1) following 'false' branch...
|..
| 115 | chk = calloc(1, sizeof(*chk));
| | ~~~
| | |
| | (2) ...to here
| 116 | if (!chk) {
| | ~
| | |
| | (3) following 'false' branch (when 'chk' is non-NULL)...
|..
| 120 | chk->action = TCPCHK_ACT_SEND;
| | ~
| | |
| | (4) ...to here
|..
| 127 | if (*args[cur_arg]) {
| | ~~~
| | ||
| | |(5) pointer 'meth' is dereferenced here
| | (6) following 'true' branch...
| 128 | if (!*args[cur_arg + 1])
| |~ ~
| || |
| || (7) ...to here
| |(8) following 'false' branch...
|..
| 131 | meth = args[cur_arg];
| | ~
| | |
| | (9) ...to here
| 132 | }
| 133 | if (*args[cur_arg + 1])
| | ~
| | |
| | (10) following 'true' branch...
| 134 | uri = args[cur_arg + 1];
| | ~
| | |
| | (11) ...to here
| 135 | if (*args[cur_arg + 2])
| | ~
| | |
| | (12) following 'false' branch...
|..
| 138 | if (meth) {
| | ~
| | |
| | (13) ...to here
| | (14) pointer 'meth' is checked for NULL here but it was
already dereferenced at (5)
|
:147:6: warning: check of 'uri' for NULL after already dereferencing it
[-Wanalyzer-deref-before-check]
147 | if (uri) {
| ^
'proxy_parse_httpchk_req': events 1-18
|
| 110 | if (hdrs || body) {
| | ^
| | |
| | (1) following 'false' branch...
|..
| 115 | chk = calloc(1, sizeof(*chk));
| | ~~~
| | |
| | (2) ...to here
| 116 | if (!chk) {
| | ~
| | |
| | (3) following 'false' branch (when 'chk' is non-NULL)...
|..
| 120 | chk->action = TCPCHK_ACT_SEND;
| | ~
| | |
| | (4) ...to here
|..
| 127 | if (*args[cur_arg]) {
| | ~
| | |
| | (5) following 'true' branch...
| 128 | if (!*args[cur_arg + 1])
| |~ ~~
| || ||
| || |(6) ...to here
| || (7) pointer 'uri' is dereferenced here
| |(8) following 'false' branch...
|..
| 131 | meth = args[cur_arg];
| | ~
| | |
| | (9) ...to here
| 132 | }
| 133 | if (*args[cur_arg + 1])
| | ~
| | |
| | (10) following 'true' branch...
| 134 | uri = args[cur_arg + 1];
| | ~
| | |
| | (11) ...to here
| 135 | if (*args[cur_arg + 2])
| | ~
| | |
| | (12) following 'false' branch...
|..
| 138 | if (meth) {
| | ~
| | |
| | (13) ...to here
| | (14) following 'true' branch (when 'meth' is non-NULL)...
| 139 | chk->send.http.meth.meth = find_http_meth(meth, strlen(meth));
| |
| | |
|
[Bug modula2/108373] Update 'contrib/gcc_update:files_and_dependencies' for Modula-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108373 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Gaius Mulley --- closing as patch has been applied.
[Bug c++/108474] static structured binding undefined reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108474 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from Andrew Pinski --- And yes it ICEs with LTO too.
[Bug c++/108474] New: static structured binding undefined reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108474
Bug ID: 108474
Summary: static structured binding undefined reference
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: link-failure, wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take this c++20 (-std=c++20):
```
struct t
{
int i, j;
};
t y;
static auto [i, j] = y;
int = i;
int s = i;
int *t =
int main() {}
```
This fails in a similar way as PR 53932 but this is for structued bindings
rather than static anonymous unions.
[Bug web/108473] bugzilla see also should support gitlab.com URLs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108473 --- Comment #1 from Andrew Pinski --- The address for that gitlab bug was: https://gitlab.com/qemu-project/qemu/-/issues/1454
[Bug web/108473] New: bugzilla see also should support gitlab.com URLs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108473 Bug ID: 108473 Summary: bugzilla see also should support gitlab.com URLs Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- I noticed that gitlab bug URLs are not supported when handling PR 108470.
[Bug ada/108472] gcc/ada/b_gnat1.adb:363: undefined reference to `system__assertions___elabs'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108472 --- Comment #5 from Dennis Clarke --- (In reply to Andreas Schwab from comment #3) > You are mixing two different ada compilers: > > /opt/imed/gcc12/bin/gcc -c -g -gnatpg -gnatwns -W -Wall -I- -I. > -Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada > ../../gcc-12.2.0/gcc/ada/gnat1drv.adb -o ada/gnat1drv.o > x86_64-linux-gnu-gnatbind -t -I- -I. -Iada/generated -Iada > -I../../gcc-12.2.0/gcc/ada -o b_gnat1.adb -n ada/gnat1drv.ali Brilliant! I shall dpkg --purge all other gnat/ada and then use the previously built and bootstrapped version I have in the /opt/imed directory structure. Thank you !
[Bug ada/108472] gcc/ada/b_gnat1.adb:363: undefined reference to `system__assertions___elabs'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108472 --- Comment #4 from Dennis Clarke --- (In reply to Andrew Pinski from comment #2) > >warning: "s-stalib.adb" and "gnat1drv.adb" compiled with different GNAT > >versions > > Is the first thing you should look into. > > Since you are setting the PATH to include /opt/imed/gcc12/bin but you don't > set LD_LIBRAR_PATH to include /opt/imed/gcc12/lib64 ... Actually I have never heard of such a thing. Let's give that a whirl !
[Bug rtl-optimization/97961] unnecessary moves with __builtin_{add,sub}_overflow_p and __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97961
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #2 from Andrew Pinski ---
Dup of bug 94804. The problem is arguments.
If we do:
```
bool f1(unsigned __int128 *a,unsigned __int128 *b) {
return __builtin_add_overflow_p(*a, *b, (unsigned __int128)0);
}
bool f2(__int128 *a,__int128 *b) {
return __builtin_add_overflow_p(*a, *b, (__int128)0);
}
bool f3(unsigned __int128 *a,unsigned __int128 *b) {
return __builtin_sub_overflow_p(*a, *b, (unsigned __int128)0);
}
bool f4(__int128 *a,__int128 *b) {
return __builtin_sub_overflow_p(*a, *b, (__int128)0);
}
```
We don't get extra mov's.
*** This bug has been marked as a duplicate of bug 94804 ***
[Bug rtl-optimization/94804] Failure to elide useless movs in 128-bit addition with __int128_t arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94804 Andrew Pinski changed: What|Removed |Added CC||denis.campredon at gmail dot com --- Comment #7 from Andrew Pinski --- *** Bug 97961 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/94804] Failure to elide useless movs in 128-bit addition with __int128_t arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94804
Andrew Pinski changed:
What|Removed |Added
Blocks||101926
Summary|Failure to elide useless|Failure to elide useless
|movs in 128-bit addition|movs in 128-bit addition
||with __int128_t arguments
--- Comment #6 from Andrew Pinski ---
This is ra issue with arguments really.
We get good code with:
```
using i128 = __int128;
i128 sub128(i128 *a, i128 *b)
{
return *a - *b;
}
```
```
movq(%rdi), %rax
movq8(%rdi), %rdx
subq(%rsi), %rax
sbbq8(%rsi), %rdx
```
With:
```
using i128 = __int128;
void sub128(i128 a, i128 b, i128 *c)
{
*c = a - b;
}
```
We get not so good code (extra movs):
```
movq%rsi, %rax
movq%rdi, %rsi
movq%rax, %rdi
subq%rdx, %rsi
sbbq%rcx, %rdi
movq%rsi, (%r8)
movq%rdi, 8(%r8)
```
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926
[Bug 101926] [meta-bug] struct/complex argument passing and return should be
improved
[Bug rtl-optimization/108471] Suboptimal codegen for __int128 subtraction on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108471 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 94804. *** This bug has been marked as a duplicate of bug 94804 ***
[Bug rtl-optimization/94804] Failure to elide useless movs in 128-bit addition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94804 Andrew Pinski changed: What|Removed |Added CC||rl.alt.accnt at gmail dot com --- Comment #5 from Andrew Pinski --- *** Bug 108471 has been marked as a duplicate of this bug. ***
[Bug ada/108472] gcc/ada/b_gnat1.adb:363: undefined reference to `system__assertions___elabs'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108472 --- Comment #3 from Andreas Schwab --- You are mixing two different ada compilers: /opt/imed/gcc12/bin/gcc -c -g -gnatpg -gnatwns -W -Wall -I- -I. -Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada ../../gcc-12.2.0/gcc/ada/gnat1drv.adb -o ada/gnat1drv.o x86_64-linux-gnu-gnatbind -t -I- -I. -Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada -o b_gnat1.adb -n ada/gnat1drv.ali
[Bug ada/108472] gcc/ada/b_gnat1.adb:363: undefined reference to `system__assertions___elabs'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108472 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-01-19 Status|UNCONFIRMED |WAITING --- Comment #2 from Andrew Pinski --- >warning: "s-stalib.adb" and "gnat1drv.adb" compiled with different GNAT >versions Is the first thing you should look into. Since you are setting the PATH to include /opt/imed/gcc12/bin but you don't set LD_LIBRAR_PATH to include /opt/imed/gcc12/lib64 ...
[Bug ada/108472] gcc/ada/b_gnat1.adb:363: undefined reference to `system__assertions___elabs'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108472 --- Comment #1 from Dennis Clarke --- Tried again with the system binutils and I see the same error : /bin/ld: ada/b_gnat1.o: in function `adainit': /opt/bw/build/gcc-12.2.0_linux_amd64.004/gcc/ada/b_gnat1.adb:363: undefined reference to `system__assertions___elabs' collect2: error: ld returned 1 exit status make[3]: *** [../../gcc-12.2.0/gcc/ada/gcc-interface/Make-lang.in:744: gnat1] Error 1
[Bug ada/108472] New: gcc/ada/b_gnat1.adb:363: undefined reference to `system__assertions___elabs'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108472 Bug ID: 108472 Summary: gcc/ada/b_gnat1.adb:363: undefined reference to `system__assertions___elabs' Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: dclarke at blastwave dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Not at all sure how to proceed here thus I will file this bug report in hopes that it is not environmental. Not sure how to make any sense from this : . . . /opt/imed/gcc12/bin/gcc -c -g -gnatpg -gnatwns -W -Wall -I- -I. -Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada ada/g-graphs.adb -o ada/g-graphs.o mkdir -p ada/ /opt/imed/gcc12/bin/gcc -c -g -gnatpg -gnatwns -W -Wall -I- -I. -Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada ada/g-lists.adb -o ada/g-lists.o mkdir -p ada/ /opt/imed/gcc12/bin/gcc -c -g -gnatpg -gnatwns -W -Wall -I- -I. -Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada ada/g-sets.adb -o ada/g-sets.o mkdir -p ada/ /opt/imed/gcc12/bin/gcc -c -g -gnatpg -gnatwns -W -Wall -I- -I. -Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada ada/s-pehage.adb -o ada/s-pehage.o mkdir -p ada/ /opt/imed/gcc12/bin/gcc -c -g -gnatpg -gnatwns -W -Wall -I- -I. -Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada ada/s-utf_32.adb -o ada/s-utf_32.o mkdir -p ada/ /opt/imed/gcc12/bin/gcc -c -g -gnatpg -gnatwns -W -Wall -I- -I. -Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada ../../gcc-12.2.0/gcc/ada/back_end.adb -o ada/back_end.o mkdir -p ada/ /opt/imed/gcc12/bin/gcc -c -g -gnatpg -gnatwns -W -Wall -I- -I. -Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada ../../gcc-12.2.0/gcc/ada/gnat1drv.adb -o ada/gnat1drv.o x86_64-linux-gnu-gnatbind -t -I- -I. -Iada/generated -Iada -I../../gcc-12.2.0/gcc/ada -o b_gnat1.adb -n ada/gnat1drv.ali warning: "s-stalib.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "a-except.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "ada.ads" and "gnat1drv.adb" compiled with different GNAT versions warning: "a-elchha.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "system.ads" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-soflin.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-secsta.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-parame.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-stoele.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-soliin.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-stache.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-exctab.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-except.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-excmac.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-excdeb.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-imgint.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-traceb.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-traent.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-trasym.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "a-contai.ads" and "gnat1drv.adb" compiled with different GNAT versions warning: "a-exctra.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "interfac.ads" and "gnat1drv.adb" compiled with different GNAT versions warning: "i-c.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-boustr.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-crtl.ads" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-dwalin.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "a-charac.ads" and "gnat1drv.adb" compiled with different GNAT versions warning: "a-chahan.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "a-chlat1.ads" and "gnat1drv.adb" compiled with different GNAT versions warning: "a-string.ads" and "gnat1drv.adb" compiled with different GNAT versions warning: "a-strmap.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-bitops.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-unstyp.ads" and "gnat1drv.adb" compiled with different GNAT versions warning: "a-stmaco.ads" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-addima.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-imguns.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-io.adb" and "gnat1drv.adb" compiled with different GNAT versions warning: "s-mmap.adb" and "gnat1drv.adb"
[Bug c++/53932] [10/11/12 Regression] C++ reference variable to member of anonymous union in global is error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53932 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11/12 Regression] C++ |C++ reference variable to |reference variable to |member of anonymous union |member of anonymous union |in global is error |in global is error --- Comment #12 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/108437] [13 Regression] ICE in build_min_non_dep_op_overload, at cp/tree.cc:3710
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108437 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed. Thanks for the report.
[Bug c++/108437] [13 Regression] ICE in build_min_non_dep_op_overload, at cp/tree.cc:3710
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108437 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:86caab6c5d1e26e1c54c3dceacc873d6e27bfc09 commit r13-5266-g86caab6c5d1e26e1c54c3dceacc873d6e27bfc09 Author: Jakub Jelinek Date: Thu Jan 19 23:31:15 2023 +0100 c++: Fix up handling of non-dependent subscript with static operator[] [PR108437] As the following testcases shows, when adding static operator[] support I've missed that the 2 build_min_non_dep_op_overload functions need to be adjusted. The first one we only use for the single index case, but as cp_tree_code_length (ARRAY_REF) is 2, we were running into an assertion there which compared nargs and expected_nargs. For ARRAY_REF, the operator[] is either a non-static member or newly static member, never out of class and for the static member case if user uses single index the operator[] needs to have a single argument as well, but the function is called with 2 - the object it is invoked on and the index. We need to evaluate side-effects of the object and use just a single argument in the call - the index. The other build_min_non_dep_op_overload overload has been added solely for ARRAY_REF - CALL_EXPR is the other operator that accepts variable number of operands but that one goes through different routines. There we asserted it is a METHOD_TYPE, so again we shouldn't assert that but handle the case when it is not one by making sure object's side-effects are evaluated if needed and passing all the index arguments to the static operator[]. 2023-01-19 Jakub Jelinek PR c++/108437 * cp-tree.h (keep_unused_object_arg): Declare. * call.cc (keep_unused_object_arg): No longer static. * tree.cc (build_min_non_dep_op_overload): Handle ARRAY_REF with overload being static member function. * g++.dg/cpp23/subscript12.C: New test. * g++.dg/cpp23/subscript13.C: New test.
[Bug c++/53932] [10/11/12/13 Regression] C++ reference variable to member of anonymous union in global is error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53932 --- Comment #11 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9b9a989adc042b304572fd6d4ade46b47be6ccb8 commit r13-5265-g9b9a989adc042b304572fd6d4ade46b47be6ccb8 Author: Jakub Jelinek Date: Thu Jan 19 23:27:34 2023 +0100 c++: Fix up handling of references to anon union members in initializers [PR53932] For anonymous union members we create artificial VAR_DECLs which have DECL_VALUE_EXPR for the actual COMPONENT_REF. That works just fine inside of functions (including global dynamic constructors), because during gimplification such VAR_DECLs are gimplified as their DECL_VALUE_EXPR. This is also done during regimplification. But references to these artificial vars in DECL_INITIAL expressions aren't ever replaced by the DECL_VALUE_EXPRs, so we end up either with link failures like on the testcase below, or worse ICEs with LTO. The following patch fixes those during cp_fully_fold_init where we already walk all the trees (!data->genericize means that function rather than cp_fold_function). 2023-01-19 Jakub Jelinek PR c++/53932 * cp-gimplify.cc (cp_fold_r): During cp_fully_fold_init replace DECL_ANON_UNION_VAR_P VAR_DECLs with their corresponding DECL_VALUE_EXPR. * g++.dg/init/pr53932.C: New test.
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #20 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c81e68a9cdbb5411dce1f1da3b35854212305c7c
commit r13-5264-gc81e68a9cdbb5411dce1f1da3b35854212305c7c
Author: Jakub Jelinek
Date: Thu Jan 19 23:26:35 2023 +0100
value-relation: Fix up relation_union [PR108447]
While looking at the PR, I've noticed one row in rr_union_table
is wrong. relation_union should be commutative, but due to that
bug is not. The following patch adds a self-test for that
property (fails without the first hunk) and fixes that line.
The actual floating point relation problem isn't fixed by this patch
though.
2023-01-19 Jakub Jelinek
PR tree-optimization/108447
* value-relation.cc (rr_union_table): Fix VREL_UNDEFINED row order.
(relation_tests): Add self-tests for relation_{intersect,union}
commutativity.
* selftest.h (relation_tests): Declare.
* function-tests.cc (test_ranges): Call it.
[Bug rtl-optimization/108471] Suboptimal codegen for __int128 subtraction on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108471 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization, ra Component|other |rtl-optimization --- Comment #1 from Andrew Pinski --- Most of this is just argument and return value register allocation issue and not much else. There is another bug that talks about this too.
[Bug other/108471] New: Suboptimal codegen for __int128 subtraction on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108471
Bug ID: 108471
Summary: Suboptimal codegen for __int128 subtraction on x86_64
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: rl.alt.accnt at gmail dot com
Target Milestone: ---
On x86_64, GCC generates an excessive amount of redundant `mov` instructions
for `__int128` subtraction in C/C++. Clicking through versions on godbolt shows
that this started getting worse in GCC 9.1 and later versions. See also
https://godbolt.org/z/86v6ar457
The code:
```
__int128 sub(__int128 a, __int128 b) { return a - b; }
```
At -O3 or -O2, GCC (trunk) generates:
```
sub:
mov r8, rdi
mov rax, rsi
mov rsi, r8
mov rdi, rax
mov r8, rdx
mov rax, rsi
mov rdx, rdi
sub rax, r8
sbb rdx, rcx
ret
```
Interestingly, the use of `r8` in the first three instructions disappears when
compiling w/ -O1, and those instructions are folded into two `mov`s instead.
By contrast, Clang (also at -O3) generates:
```
sub:
mov rax, rdi
sub rax, rdx
sbb rsi, rcx
mov rdx, rsi
ret
```
This is probably not a high-priority bug; I just wanted to bring attention to
the fact that this is happening.
[Bug target/108436] ICE in gen_prefetch, at config/i386/i386.md:24155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108436 --- Comment #3 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:77a67e3a9294c825ac1a2b205fbb266e7c29e82b commit r13-5263-g77a67e3a9294c825ac1a2b205fbb266e7c29e82b Author: H.J. Lu Date: Wed Jan 18 11:08:14 2023 -0800 x86: Check invalid third argument to __builtin_ia32_prefetch Check invalid third argument to __builtin_ia32_prefetch when expaning __builtin_ia32_prefetch to avoid ICE later. gcc/ PR target/108436 * config/i386/i386-expand.cc (ix86_expand_builtin): Check invalid third argument to __builtin_ia32_prefetch. gcc/testsuite/ * gcc.target/i386/pr108436.c: New test.
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447 Andrew Macleod changed: What|Removed |Added Attachment #54312|0 |1 is obsolete|| --- Comment #19 from Andrew Macleod --- Created attachment 54313 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54313=edit better patch A more consistent approach.. rather than directly call relation_intersect() from multiple places, add the floating point fix to value_relation::intersect and always go through that. This will cause the normal oracle and the path oracle to both make the previous adjustment to intersect for floating point operations. untested, running tests now.
[Bug ipa/108470] New: Missing documentation for alternate uses of __attribute__((noinline))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108470 Bug ID: 108470 Summary: Missing documentation for alternate uses of __attribute__((noinline)) Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: rth at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- The noinline attribute affects decisions made by ipa-split.cc and ipa-icf.cc that are not immediately obvious. At least the ipa-split choice affects code correctness for QEMU (in that we expect __builtin_return_address to be used in very specific contexts, and the transformation done by ipa-split invalidates that). Using noinline on the affected functions prevents the ipa-split optimization and restores functionality. It would be nice to document the effect, so that the workaround is not affected in future gcc versions.
[Bug middle-end/108459] [OpenMP] ICE during GIMPLE pass: ompexp (segfault) in expand_omp_for_init_counts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108459 --- Comment #7 from Jakub Jelinek --- Fixed on the trunk, will backport later.
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447 --- Comment #18 from Andrew Macleod --- Created attachment 54312 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54312=edit possible patch The only place I think it matters is in set_one_relation. THis is the central point where we add a new relation, and search for any relations leading to this point. If we find one, then we perform an intersection and register the result. If we also check for floating point operands, and see a LT, LE, GT, or GE involved in the intersection, and the result is EQ or NE, this patch simply doesn't register the new relation so combining <= and >= will simply leave the relation as <= instead of producing == Its not incorrect, just not exact.. but we have no way of representing the exact result yet. I think this is the only place we really use intersection, and the oracle does not use union for anything. We never merge incoming results that way.. we simply search the dominators rather than create new relations for merge points. THis probably needs to be checked in the path oracle too.. I dont think there are any other combinations of relations that will cause a problem?
[Bug middle-end/108459] [OpenMP] ICE during GIMPLE pass: ompexp (segfault) in expand_omp_for_init_counts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108459 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:46644ec99cb355845b23bb1d02775c057ed8ee88 commit r13-5262-g46644ec99cb355845b23bb1d02775c057ed8ee88 Author: Jakub Jelinek Date: Thu Jan 19 21:00:08 2023 +0100 openmp: Fix up OpenMP expansion of non-rectangular loops [PR108459] expand_omp_for_init_counts was using for the case where collapse(2) inner loop has init expression dependent on non-constant multiple of the outer iterator and the condition upper bound expression doesn't depend on the outer iterator fold_unary (NEGATE_EXPR, ...). This will just return NULL if it can't be folded, we need fold_build1 instead. 2023-01-19 Jakub Jelinek PR middle-end/108459 * omp-expand.cc (expand_omp_for_init_counts): Use fold_build1 rather than fold_unary for NEGATE_EXPR. * testsuite/libgomp.c/pr108459.c: New test.
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #17 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #15)
> I went through the whole rr_{intersect,union}_table tables and I think just
> --- gcc/value-relation.cc.jj 2023-01-02 09:32:42.088000605 +0100
> +++ gcc/value-relation.cc 2023-01-19 16:20:06.490126901 +0100
> @@ -115,7 +115,7 @@ relation_kind rr_union_table[VREL_LAST][
>{ VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING,
> VREL_VARYING, VREL_VARYING, VREL_VARYING },
> // VREL_UNDEFINED
> - { VREL_VARYING, VREL_LT, VREL_LE, VREL_GT, VREL_GE, VREL_UNDEFINED,
> + { VREL_VARYING, VREL_UNDEFINED, VREL_LT, VREL_LE, VREL_GT, VREL_GE,
> VREL_EQ, VREL_NE },
> // VREL_LT
>{ VREL_VARYING, VREL_LT, VREL_LT, VREL_LE, VREL_NE, VREL_VARYING, VREL_LE,
> is really wrong for the integral/pointer relations (plus the question what
> to do with the VREL_PE* relations and whether they need to be in the tables
> or punted on by the caller somehow).
THat was my conclusions as well.
As for the PE's.. it seemed easier just to leave the partial equivalences
there as the table only grows from 64 to 144 entries, and in the grand scheme
seemed easier than trying to add runtime checks for relation kind ranges just
to avoid those few extra words.
Besides, if we ever end up with x != y when there is a partial equivalence, we
may also be able to conclude x > y or something else.. just left the window
open for exploration.
>
> Now, when considering the relations in the fp with NAN meaning they have in
> C/C++
> (and assuming we don't try to replace say two actual comparisons in the IL
> with one
> with different exception behavior), the only relations in the tables which
> are true for unordered operand(s) are VREL_VARYING and VREL_NE. Maybe I
> miss something, but I can't think of an inappropriate intersection -
> VREL_VARYING intersects anything is anything,
> VREL_VARYING intersect VREL_VARYING is the only one that gives VREL_VARYING,
> VREL_{VARYING,NE} intersect VREL_NE or vice versa the only one that gives
> VREL_NE
> and VREL_UNDEFINED returned only from intersections of anything and
> VREL_UNDEFINED, or
> LT/LE/GT/GE vs. each other where there is no overlap (but in that case
> neither allows NANs), LT/GT vs. EQ (ditto) and EQ vs. NE (one relation
> doesn't allow NAN but the other does, so they aren't allowed.
> As for unions - LT U GT or vice versa is incorrectly NE, should be LAST or
> LTGT or some other way how to express we can't express it. LT U GE or LE U
> GT or LE U GE or vice versa are incorrectly VARYING, when they are together
> ORDERED (so again, need some way how to express that). Can't find anything
> else wrong.
> But unless we use VR_UNKNOWN or VR_LAST or whatever to stand for something
> we really don't know how to handle, we'd need the various combinations that
> tree.def has on top of the basics, LTGT, UNORDERED, ORDERED, UNLT, UNLE,
> UNGT, UNGE and UNEQ.
For this release, I wouldn't want to add too much extra stuff. Im inclined to
handle this pretty much where the problems arise as I think it is fairly
localized.
For the next release, I'm inclined to enhance the oracle and relations such
that any range class can specify its own relation sets.. so irange (and most
others) would use a set which implements what we have, and we could introduce a
floating point relation set which includes something like "<>" and "<=>" and we
can work out what that looks like to cover exactly what we need to model.
That way we can model slight behaviour changes more easily.
[Bug c++/107797] "warning right operand of comma operator has no effect" for expressions with no comma operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107797 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Marek Polacek --- This seems to work: diff --git a/gcc/cp/cvt.cc b/gcc/cp/cvt.cc index 0cbfd8060cb..d1e34d7de1a 100644 --- a/gcc/cp/cvt.cc +++ b/gcc/cp/cvt.cc @@ -711,8 +711,11 @@ ocp_convert (tree type, tree expr, int convtype, int flags, return error_mark_node; if (e == TREE_OPERAND (expr, 1)) return expr; - return build2_loc (EXPR_LOCATION (expr), COMPOUND_EXPR, TREE_TYPE (e), -TREE_OPERAND (expr, 0), e); + e = build2_loc (EXPR_LOCATION (expr), COMPOUND_EXPR, TREE_TYPE (e), + TREE_OPERAND (expr, 0), e); + if (warning_suppressed_p (expr, OPT_Wunused_value)) + suppress_warning (e, OPT_Wunused_value); + return e; } complete_type (type); diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc index f816c474cef..52e96fbe590 100644 --- a/gcc/cp/init.cc +++ b/gcc/cp/init.cc @@ -3800,6 +3800,8 @@ build_new_1 (vec **placement, tree type, tree nelts, if (cookie_expr) rval = build2 (COMPOUND_EXPR, TREE_TYPE (rval), cookie_expr, rval); + suppress_warning (rval, OPT_Wunused_value); + if (rval == data_addr && TREE_CODE (alloc_expr) == TARGET_EXPR) /* If we don't have an initializer or a cookie, strip the TARGET_EXPR and return the call (which doesn't need to be adjusted). */
[Bug analyzer/102471] RFE: add support to analyzer testsuite for running SAMATE/SARD tests (e.g. Juliet Test Suite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102471 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |MOVED --- Comment #7 from David Malcolm --- Marking this one as RESOLVED MOVED, since I'm now doing this in: https://github.com/davidmalcolm/gcc-analyzer-integration-tests
[Bug analyzer/108455] -Wanalyzer-deref-before-check false positive seen in git pack-revindex.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108455 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/108455] -Wanalyzer-deref-before-check false positive seen in git pack-revindex.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108455 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:0d6f7b1dd62e9c9dccb0b9b673f9cc3238b7ea6d commit r13-5261-g0d6f7b1dd62e9c9dccb0b9b673f9cc3238b7ea6d Author: David Malcolm Date: Thu Jan 19 13:51:16 2023 -0500 analyzer: use dominator info in -Wanalyzer-deref-before-check [PR108455] My integration testing [1] of -fanalyzer in GCC 13 is showing a lot of diagnostics from the new -Wanalyzer-deref-before-check warning on real-world C projects, and most of these seem to be false positives. This patch updates the warning to make it much less likely to fire: - only intraprocedural cases are now reported - reject cases in which there are control flow paths to the check that didn't come through the dereference, by looking at BB dominator information. This fixes a false positive seen in git-2.39.0's pack-revindex.c: load_revindex_from_disk (PR analyzer/108455), in which a shared "cleanup:" section checks "data" for NULL, and depending on how much of the function is executed "data" might or might not have already been dereferenced. The counts of -Wanalyzer-deref-before-check diagnostics in [1] before/after this patch show this improvement: Known false positives:6 -> 0 (-6) Known true positives: 1 -> 1 Unclassified positives: 123 -> 63 (-60) [1] https://github.com/davidmalcolm/gcc-analyzer-integration-tests gcc/analyzer/ChangeLog: PR analyzer/108455 * analyzer.h (class checker_event): New forward decl. (class state_change_event): Indent. (class warning_event): New forward decl. * checker-event.cc (state_change_event::state_change_event): Add "enode" param. (warning_event::get_desc): Update for new param of evdesc::final_event ctor. * checker-event.h (state_change_event::state_change_event): Add "enode" param. (state_change_event::get_exploded_node): New accessor. (state_change_event::m_enode): New field. (warning_event::warning_event): New "enode" param. (warning_event::get_exploded_node): New accessor. (warning_event::m_enode): New field. * diagnostic-manager.cc (state_change_event_creator::on_global_state_change): Pass src_node to state_change_event ctor. (state_change_event_creator::on_state_change): Likewise. (null_assignment_sm_context::set_next_state): Pass NULL for new param of state_change_event ctor. * infinite-recursion.cc (infinite_recursion_diagnostic::add_final_event): Update for new param of warning_event ctor. * pending-diagnostic.cc (pending_diagnostic::add_final_event): Pass enode to warning_event ctor. * pending-diagnostic.h (evdesc::final_event): Add reference to warning_event. * sm-malloc.cc: Include "analyzer/checker-event.h" and "analyzer/exploded-graph.h". (deref_before_check::deref_before_check): Initialize new fields. (deref_before_check::emit): Reject warnings in which we were unable to determine the enodes of the dereference and the check. Reject warnings interprocedural warnings. Reject warnings in which the dereference doesn't dominate the check. (deref_before_check::describe_state_change): Set m_deref_enode. (deref_before_check::describe_final_event): Set m_check_enode. (deref_before_check::m_deref_enode): New field. (deref_before_check::m_check_enode): New field. gcc/testsuite/ChangeLog: PR analyzer/108455 * gcc.dg/analyzer/deref-before-check-1.c: Add test coverage involving dominance. * gcc.dg/analyzer/deref-before-check-pr108455-1.c: New test. * gcc.dg/analyzer/deref-before-check-pr108455-git-pack-revindex.c: New test. Signed-off-by: David Malcolm
[Bug fortran/108434] [12/13 Regression] ICE in class_allocatable, at fortran/expr.cc:5000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108434 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:117848f425a3c0eda85517b4bdaf2ebe3bc705c2 commit r13-5260-g117848f425a3c0eda85517b4bdaf2ebe3bc705c2 Author: Harald Anlauf Date: Wed Jan 18 22:13:29 2023 +0100 Fortran: error recovery for invalid CLASS component [PR108434] gcc/fortran/ChangeLog: PR fortran/108434 * expr.cc (class_allocatable): Prevent NULL pointer dereference or invalid read. (class_pointer): Likewise. gcc/testsuite/ChangeLog: PR fortran/108434 * gfortran.dg/pr108434.f90: New test.
[Bug testsuite/108469] New: FAIL: g++.dg/pr104869.C (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108469 Bug ID: 108469 Summary: FAIL: g++.dg/pr104869.C (test for excess errors) Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../xg++ -B /home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../ /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/pr104869.C -fdiagnostics-plain-output -nostdinc++ -I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11 -I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -fvisibility=hidden -std=c++11 -L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/experimental/.libs -lm -o ./pr104869.exe ld: (Warning) Potential unresolved symbol "main": shared library reference is resolved to non-exported definition in file "/var/tmp//cc8TLIK5.o". 1 warnings. FAIL: g++.dg/pr104869.C (test for excess errors) Excess errors: ld: (Warning) Potential unresolved symbol "main": shared library reference is resolved to non-exported definition in file "/var/tmp//cc8TLIK5.o". 1 warnings.
[Bug c++/108468] [11/12/13 Regression] ICE in most_specialized_partial_spec/builtin_guide_p in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108468 Marek Polacek changed: What|Removed |Added Target Milestone|--- |11.4 Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Priority|P3 |P2 Last reconfirmed||2023-01-19 Summary|ICE in |[11/12/13 Regression] ICE |most_specialized_partial_sp |in |ec/builtin_guide_p in C++20 |most_specialized_partial_sp |mode|ec/builtin_guide_p in C++20 ||mode Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Confirmed. Started with r11-1615-g6b161257f9f8c7: commit 6b161257f9f8c7a26b7d119ebc32cbbc54d2e508 Author: Jason Merrill Date: Mon Jun 22 15:44:45 2020 -0400 c++: Improve CTAD for aggregates [PR93976] P2082R1 adjusted the rules for class template argument deduction for an aggregate to better handle arrays and pack expansions.
[Bug c++/108468] New: ICE in most_specialized_partial_spec/builtin_guide_p in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108468
Bug ID: 108468
Summary: ICE in most_specialized_partial_spec/builtin_guide_p
in C++20 mode
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ed at catmur dot uk
Target Milestone: ---
Since 11.1, the following ices in -std=c++20 and later:
template struct C { template static constexpr int x = 1; };
template template int C::x = 2;
int y = C<0>::x;
0x23ae54e internal_error(char const*, ...)
???:0
0xc5b614 deduction_guide_p(tree_node const*)
???:0
0xc5be2c builtin_guide_p(tree_node const*)
???:0
0xc82bdf most_specialized_partial_spec(tree_node*, int)
???:0
0xc83a76 instantiate_template(tree_node*, tree_node*, int)
???:0
0xc8c0d8 finish_template_variable(tree_node*, int)
???:0
0xcce05f finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*,
bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned int)
???:0
[Bug c++/53932] [10/11/12/13 Regression] C++ reference variable to member of anonymous union in global is error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53932 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- Created attachment 54311 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54311=edit gcc13-pr53932.patch Untested fix.
[Bug c++/108238] returns_nonnull attribute with auto return type fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108238
--- Comment #2 from Barnabás Pőcze ---
Here is a change that I believe might address this. It seems to work but I have
never done anything in gcc, so probably has shortcomings.
The error points to the return expression, like this:
asd2.cpp: In function ‘auto f2()’:
asd2.cpp:9:20: error: ‘returns_nonnull’ attribute on a function not returning
a pointer
9 | auto f2() { return 42; }
|^~
---
diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
index 4667f6de311..50f5ad6b8f1 100644
--- a/gcc/c-family/c-attribs.cc
+++ b/gcc/c-family/c-attribs.cc
@@ -5761,8 +5761,9 @@ static tree
handle_returns_nonnull_attribute (tree *node, tree name, tree, int,
bool *no_add_attrs)
{
+ auto type_code = TREE_CODE (TREE_TYPE (*node));
// Even without a prototype we still have a return type we can check.
- if (TREE_CODE (TREE_TYPE (*node)) != POINTER_TYPE)
+ if (type_code != POINTER_TYPE && type_code != TEMPLATE_TYPE_PARM)
{
error ("%qE attribute on a function not returning a pointer", name);
*no_add_attrs = true;
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 1656d02d6d1..b3ae608b350 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -12305,6 +12305,10 @@ apply_deduced_return_type (tree fco, tree return_type)
if (return_type == error_mark_node)
return;
+ tree returns_nonnull = lookup_attribute("returns_nonnull", TYPE_ATTRIBUTES
(TREE_TYPE (fco)));
+ if (returns_nonnull && TREE_CODE (return_type) != POINTER_TYPE)
+error ("% attribute on a function not returning a
pointer");
+
if (DECL_CONV_FN_P (fco))
DECL_NAME (fco) = make_conv_op_name (return_type);
[Bug c++/53932] [10/11/12/13 Regression] C++ reference variable to member of anonymous union in global is error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53932 --- Comment #9 from Jakub Jelinek --- So, the problem is that build_anon_union_vars builds artificial variables for the anon union members and they those VAR_DECLs have DECL_VALUE_EXPR set to the D.2763.i and similar COMPONENT_REFs. But VAR_DECLs with DECL_VALUE_EXPRs are only actually replaced with those DECL_VALUE_EXPR expressions during gimplification or regimplification (which explains why it works fine inside of code in functions or global constructors). Nothing replaces them in DECL_INITIAL expressions of statically initialized vars.
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447 --- Comment #16 from Jakub Jelinek --- BTW, because both union and intersect are commutative, so perhaps we should have a self-test that verifies that. Guess that would catch the VREL_UNDEFINED line errors.
[Bug tree-optimization/108467] false positive -Wmaybe-uninitialized warning at -O1 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108467 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Known to fail||4.1.2 Last reconfirmed||2023-01-19 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- After normalization [USE]: _7 = PHI <0(13), sh_4(8)> is conditional on: ((NOT (_3 == 0)) AND (emax.3_2 >= 0) AND (emin.2_1 <= 0)) _3 = rb_5 | sb_6; if (_3 == 0) Confirmed.
[Bug tree-optimization/108467] New: false positive -Wmaybe-uninitialized warning at -O1 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108467
Bug ID: 108467
Summary: false positive -Wmaybe-uninitialized warning at -O1 or
higher
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider the following code, derived from MPFR's sub1sp.c (where the issue
occurred since at least GCC 4.9.4 and the warning was silenced with the "sh =
sh" trick via an INITIALIZED() macro):
extern long emin;
extern long emax;
int f(void);
int g(void)
{
int sh, rb, sb;
if (f())
rb = sb = 0;
else
{
sh = f();
sb = f();
rb = f();
}
(0 >= emin && 0 <= emax) || (f(), __builtin_unreachable(), 0);
if (rb == 0 && sb == 0)
return 0;
else
return sh;
}
With gcc-12 (Debian 12.2.0-14) 12.2.0, I get:
$ gcc-12 -O2 -Wmaybe-uninitialized -c tst.c
tst.c: In function ‘g’:
tst.c:23:12: warning: ‘sh’ may be used uninitialized [-Wmaybe-uninitialized]
23 | return sh;
|^~
tst.c:8:7: note: ‘sh’ was declared here
8 | int sh, rb, sb;
| ^~
The warning also occurs at -O1 and -O3. It disappears if I slightly modify the
code.
Note: During the code reduction, I also got the warning, but with a different
location. However, the code was more complex, and I've already reported
PR108466 about a location issue (where the -Wmaybe-uninitialized is correct).
So I haven't reported an additional issue about the location.
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #15 from Jakub Jelinek ---
I went through the whole rr_{intersect,union}_table tables and I think just
--- gcc/value-relation.cc.jj2023-01-02 09:32:42.088000605 +0100
+++ gcc/value-relation.cc 2023-01-19 16:20:06.490126901 +0100
@@ -115,7 +115,7 @@ relation_kind rr_union_table[VREL_LAST][
{ VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING,
VREL_VARYING, VREL_VARYING, VREL_VARYING },
// VREL_UNDEFINED
- { VREL_VARYING, VREL_LT, VREL_LE, VREL_GT, VREL_GE, VREL_UNDEFINED,
+ { VREL_VARYING, VREL_UNDEFINED, VREL_LT, VREL_LE, VREL_GT, VREL_GE,
VREL_EQ, VREL_NE },
// VREL_LT
{ VREL_VARYING, VREL_LT, VREL_LT, VREL_LE, VREL_NE, VREL_VARYING, VREL_LE,
is really wrong for the integral/pointer relations (plus the question what to
do with the VREL_PE* relations and whether they need to be in the tables or
punted on by the caller somehow).
Now, when considering the relations in the fp with NAN meaning they have in
C/C++
(and assuming we don't try to replace say two actual comparisons in the IL with
one
with different exception behavior), the only relations in the tables which are
true for unordered operand(s) are VREL_VARYING and VREL_NE. Maybe I miss
something, but I can't think of an inappropriate intersection - VREL_VARYING
intersects anything is anything,
VREL_VARYING intersect VREL_VARYING is the only one that gives VREL_VARYING,
VREL_{VARYING,NE} intersect VREL_NE or vice versa the only one that gives
VREL_NE
and VREL_UNDEFINED returned only from intersections of anything and
VREL_UNDEFINED, or
LT/LE/GT/GE vs. each other where there is no overlap (but in that case neither
allows NANs), LT/GT vs. EQ (ditto) and EQ vs. NE (one relation doesn't allow
NAN but the other does, so they aren't allowed.
As for unions - LT U GT or vice versa is incorrectly NE, should be LAST or LTGT
or some other way how to express we can't express it. LT U GE or LE U GT or LE
U GE or vice versa are incorrectly VARYING, when they are together ORDERED (so
again, need some way how to express that). Can't find anything else wrong.
But unless we use VR_UNKNOWN or VR_LAST or whatever to stand for something we
really don't know how to handle, we'd need the various combinations that
tree.def has on top of the basics, LTGT, UNORDERED, ORDERED, UNLT, UNLE, UNGT,
UNGE and UNEQ.
[Bug middle-end/108448] GCC Elides Assignment to Pointer and memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448 --- Comment #9 from Gavin Howard --- > I suspect cmake didn't add -fno-strict-aliasing really. It did. I ran the build under `intercept-build` and looked at the `compile_commands.json` output. It had the `-fno-strict-aliasing` for every file. Anyway, I do not like your solution since it has a `void**`, the legality of which is dubious, but I tried it in `amal.c`, both with and without strict aliasing. (And I know it had `-fno-strict-aliasing` because I did the command-line by hand.) Both times still resulted in the failure. I even tried changing the `val_ptr` argument to be a `y_uchar*`, since that aliases everything, and it still failed, with and without strict aliasing.
[Bug middle-end/108448] GCC Elides Assignment to Pointer and memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448 --- Comment #8 from Gavin Howard --- Created attachment 54310 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54310=edit Amalgamation with License Header Not important for the bug, but I reuploaded the amalgamation with its proper license header. Sorry; need to do this for legal reasons.
[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108144 --- Comment #10 from Jonathan Wakely --- Isn't --enable-version-specific-runtime-libs completely broken anyway? See PR 32415
[Bug other/108464] [13 Regression] Broken -fdebug-prefix-map since r13-3599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464 --- Comment #5 from Richard Purdie --- (In reply to Jakub Jelinek from comment #4) > Though, even for the other options the change doesn't seem to be a good idea > as is. > I think instead the syntax of those remapping options should be extended, so > that for each of the pair one can choose the behavior which is wanted. > Using the OLD=NEW syntax > with the previous behavior, and some other to mark pairs where you want new > behavior > (dunno whether to mark those using say extra = at the end after NEW or > whatever else). > Then when populating file_prefix_map entries, one would record this > non-canonicalizing vs. canonicalizing flag and in the latter case > canonicalize the old_prefix path in the structure. > remap_filename then would ideally lazily lrealpath when seeing first map > entry with the bool flag indicating canonicalization. Having some way to enable the behaviour would be very valuable to the places we use prefix mapping so we could make that work FWIW.
[Bug c/108466] New: inconsistent -Wmaybe-uninitialized warning location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108466
Bug ID: 108466
Summary: inconsistent -Wmaybe-uninitialized warning location
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
With gcc-12 (Debian 12.2.0-14) 12.2.0, the -Wmaybe-uninitialized warning
location depends on the declared type. This is inconsistent.
To reproduce, consider a tst.c file:
int f(void);
int g(void)
{
T a;
if (f())
a = f();
if (f())
return 0;
else
return a;
}
I get:
$ for i in int long; do echo; echo "Type $i"; gcc-12 -O2 -Wmaybe-uninitialized
-DT=$i -c tst.c; done
Type int
tst.c: In function ‘g’:
tst.c:11:12: warning: ‘a’ may be used uninitialized [-Wmaybe-uninitialized]
11 | return a;
|^
tst.c:4:5: note: ‘a’ was declared here
4 | T a;
| ^
Type long
tst.c: In function ‘g’:
tst.c:4:5: warning: ‘a’ may be used uninitialized [-Wmaybe-uninitialized]
4 | T a;
| ^
[Bug modula2/108373] Update 'contrib/gcc_update:files_and_dependencies' for Modula-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108373 --- Comment #2 from Gaius Mulley --- git pushed the attachment and propose that the PR is closed.
[Bug modula2/108462] duplicate install of static libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108462 --- Comment #2 from Gaius Mulley --- There should be archives in the different architecture directories as per normal. Accompanying these should be the library module source SYSTEM.def (which could vary depending upon architectural characteristics). The remaining sources are copies from the source tree. It certainly looks as if the source files in ../13.0.1 are unnecessary given the driver search path uses: -I ... 13.0.1/m2/m2pim-L ... 13.0.1/m2/m2pim I think the static archives and sources in 13.0.1 could be removed.
[Bug middle-end/108465] Optimize (a < b) == (b < a) to a == b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108465 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Almost Exact dup of bug 107881. *** This bug has been marked as a duplicate of bug 107881 ***
[Bug tree-optimization/107881] (a <= b) == (b >= a) should be optimized to (a == b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107881 Andrew Pinski changed: What|Removed |Added CC||antoshkka at gmail dot com --- Comment #9 from Andrew Pinski --- *** Bug 108465 has been marked as a duplicate of this bug. ***
[Bug middle-end/108465] New: Optimize (a < b) == (b < a) to a == b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108465
Bug ID: 108465
Summary: Optimize (a < b) == (b < a) to a == b
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
For GCC 12 the following code with -O2:
int compare_eq(int a, int b) {
return ((a < b) == (b < a));
}
compiles into the following assembly:
compare_eq(int, int):
cmp edi, esi
setldl
setgal
cmp dl, al
seteal
movzx eax, al
ret
Which is suboptimal. More optimal assembly would be:
compare_eq(int, int):
xor eax, eax
cmp edi, esi
seteal
ret
Godbolt Playground: https://godbolt.org/z/4sfcTjjjb
Motivation: in generic C++ code the comparison is often done via a functor. The
algorithm is only allowed to use that functor:
if (__comp(a, b) == __comp(b, a)) {
return x;
} else if (__comp(b, a)) {
return y;
}
Because of that, with the inlined functor the comparison becomes ((a < b) == (b
< a))
[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108144 Martin Liška changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #9 from Martin Liška --- With the Richi's patch, I still see an issue with 32-bit .so files: $ ~/Programming/gcc/configure --enable-languages=c,c++,m2 --prefix=/tmp/gcc --disable-libsanitizer --enable-valgrind-annotations --disable-bootstrap --with-system-zlib --with-gcc-major-version-only --enable-version-specific-runtime-libs $ make $ make install ... $ find . -name libm2cor.so ./x86_64-pc-linux-gnu/libgm2/libm2cor/.libs/libm2cor.so ./x86_64-pc-linux-gnu/32/libgm2/libm2cor/.libs/libm2cor.so while it's not installed into the destination folder: $ find /tmp/gcc -name libm2cor.so /tmp/gcc/lib64/gcc/x86_64-pc-linux-gnu/13/libm2cor.so while .a files are installed (apparently multiple times): $ find /tmp/gcc -name libm2cor.a /tmp/gcc/lib64/gcc/x86_64-pc-linux-gnu/13/libm2cor.a /tmp/gcc/lib64/gcc/x86_64-pc-linux-gnu/13/m2/m2cor/libm2cor.a /tmp/gcc/lib64/gcc/x86_64-pc-linux-gnu/13/32/m2/m2cor/libm2cor.a @Richi: Can you please take a look?
[Bug modula2/108462] duplicate install of static libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108462 Gaius Mulley changed: What|Removed |Added CC||gaius at gcc dot gnu.org --- Comment #1 from Gaius Mulley --- Created attachment 54309 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54309=edit script to run coroutine test cases To check whether they are necessary it should be possible to run the coroutine test cases. It will need adapting as the gcc-read-write and build are hard coded.
[Bug target/108411] [13 Regression] ICEs in aarch64_layout_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108411 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Christophe Lyon --- Fixed.
[Bug fortran/108453] [10/11/12/13 Regression] ICE in gfc_trans_use_stmts, at fortran/trans-decl.cc:5361 since r6-3704-g2b3f52a2d0fb22ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108453 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression] |ICE in gfc_trans_use_stmts, |ICE in gfc_trans_use_stmts, |at |at |fortran/trans-decl.cc:5361 |fortran/trans-decl.cc:5361 ||since ||r6-3704-g2b3f52a2d0fb22ba Last reconfirmed||2023-01-19 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org, ||mikael at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r6-3704-g2b3f52a2d0fb22ba.
[Bug target/108411] [13 Regression] ICEs in aarch64_layout_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108411 --- Comment #2 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:74833b3165865a9373506f447720cf20f29c20c8 commit r13-5257-g74833b3165865a9373506f447720cf20f29c20c8 Author: Christophe Lyon Date: Tue Jan 17 13:10:10 2023 + aarch64: add -fno-stack-protector to some tests [PR108411] As discussed in the PR, these recently added tests fail when the testsuite is executed with -fstack-protector-strong. To avoid this, this patch adds -fno-stack-protector to dg-options. PR target/108411 gcc/testsuite * g++.target/aarch64/bitfield-abi-warning-align16-O2-extra.C: Add -fno-stack-protector. * g++.target/aarch64/bitfield-abi-warning-align16-O2.C: Likewise. * g++.target/aarch64/bitfield-abi-warning-align32-O2-extra.C: Likewise. * g++.target/aarch64/bitfield-abi-warning-align32-O2.C: Likewise. * g++.target/aarch64/bitfield-abi-warning-align8-O2.C: Likewise. * gcc.target/aarch64/bitfield-abi-warning-align16-O2-extra.c: Likewise. * gcc.target/aarch64/bitfield-abi-warning-align16-O2.c: Likewise. * gcc.target/aarch64/bitfield-abi-warning-align32-O2-extra.c: Likewise. * gcc.target/aarch64/bitfield-abi-warning-align32-O2.c: Likewise. * gcc.target/aarch64/bitfield-abi-warning-align8-O2.c: Likewise.
[Bug target/108411] [13 Regression] ICEs in aarch64_layout_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108411 --- Comment #1 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:a38c079248411ea9dc0610873b3366192315bfee commit r13-5256-ga38c079248411ea9dc0610873b3366192315bfee Author: Christophe Lyon Date: Mon Jan 16 17:48:25 2023 + aarch64: fix ICE in aarch64_layout_arg [PR108411] The previous patch added an assert which should not be applied to PST types (Pure Scalable Types) because alignment does not matter in this case. This patch moves the assert after the PST case is handled to avoid the ICE. PR target/108411 gcc/ * config/aarch64/aarch64.cc (aarch64_layout_arg): Improve comment. Move assert about alignment a bit later.
[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Last reconfirmed||2023-01-19 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- It's been there since Alexander's revision r13-4937-g012fdbc14233fbb4.
[Bug fortran/108450] [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380 since r12-5793-g689407ef916503b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108450 Martin Liška changed: What|Removed |Added Last reconfirmed||2023-01-19 Summary|[12/13 Regression] ICE in |[12/13 Regression] ICE in |sort_actual, at |sort_actual, at |fortran/intrinsic.cc:4380 |fortran/intrinsic.cc:4380 ||since ||r12-5793-g689407ef916503b2 CC||burnus at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r12-5793-g689407ef916503b2.
[Bug c++/86960] [10/11/12/13 Regression] ICE on specialization of member template with fixed parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86960 --- Comment #15 from Richard Biener --- Btw, clang rejects it: t.ii:8:15: error: non-type template parameter conflicts with previous non-type template parameter pack template ^ t.ii:3:19: note: previous non-type template parameter pack declared here template ^ t.ii:13:28: error: implicit instantiation of undefined template 'Outer::Inner' static_assert(Outer::Inner::value); ^ t.ii:4:12: note: template is declared here struct Inner; ^ 2 errors generated.
[Bug tree-optimization/108457] [13 Regression] tree-ssa-loop-niter.cc:2255:23: warning: variable 'mode' set but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108457 --- Comment #5 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #3) > Space between cast and mode. > Though I think various other uses of these macros solve this by simply using > SCALAR_INT_TYPE_MODE (utype) directly as argument to those macros rather than > using a temporary variable. I am ok with that too. This was just a quick patch to try to help to get it unstuck ...
[Bug c++/86960] [10/11/12/13 Regression] ICE on specialization of member template with fixed parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86960 Richard Biener changed: What|Removed |Added Last reconfirmed|2018-08-14 00:00:00 |2023-1-19 --- Comment #14 from Richard Biener --- Re-confirmed.
[Bug ipa/86905] [10/11/12/13 Regression] g++ ICE on valid code: verify_cgraph_node failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86905 Richard Biener changed: What|Removed |Added Last reconfirmed|2021-09-05 00:00:00 |2023-1-19 --- Comment #11 from Richard Biener --- re-confirmed
[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 Bug 59859 depends on bug 85497, which changed state. Bug 85497 Summary: [10/11/12/13 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85497 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/85497] [10/11/12/13 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85497 Richard Biener changed: What|Removed |Added Target Milestone|10.5|8.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Richard Biener --- Let's close this one, we have a "duplicate" with another testcase for the scev-expr-size issues.
[Bug rtl-optimization/84345] [10/11/12/13 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84345 --- Comment #19 from Richard Biener --- As to comment#7 I agree, for some qsort comparators we probably do not care if the outcome is really sorted in the end and the issue with different qsort implementations producing differently sorted results is gone. Maybe for those we should have a separately named entry, skipping the verification? gcc_heuristic_sort_nocheck ()?
[Bug c++/53932] [10/11/12/13 Regression] C++ reference variable to member of anonymous union in global is error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53932
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek ---
It isn't just references:
static union { int i; };
int = i;
int s = i;
int *t =
void
foo (int **p, int *q)
{
*p =
*q = i;
}
Inside of the function or global constructor for s it works ok.
[Bug c++/97452] [coroutines] incorrect sequencing of await_resume() when multiple co_await expressions occur in a single statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97452 --- Comment #12 from David Ledger --- (In reply to David Ledger from comment #11) > This did not occur with GCC 10.2, it started in GCC 10.3: > > 10.3 (https://godbolt.org/z/jrdv31M17): > ``` > 0x15d1ed3 A > 0x15d1ed2 ~A > 0x15d1ed3 ~A > ``` > > 10.2 (https://godbolt.org/z/rrvKh9h6K): > ``` > 0x2322ed1 A > 0x2322ed1 ~A > ``` Please ignore, responded to incorrect thread.
[Bug c++/83756] [10/11/12/13 Regression] gcc ICE in gimplify_expr on boost::call_once (-fms-extensions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83756 Richard Biener changed: What|Removed |Added Last reconfirmed|2021-12-02 00:00:00 |2023-1-19 --- Comment #17 from Richard Biener --- Re-confirmed. The gimplifier sees (gdb) p debug_tree (*expr_p) >> which supposedly is not to survive this long.
[Bug c++/53932] [10/11/12/13 Regression] C++ reference variable to member of anonymous union in global is error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53932 Richard Biener changed: What|Removed |Added Keywords|assemble-failure| --- Comment #7 from Richard Biener --- clang produces r: .quad _Z1i so it seems that something goes wrong in the C++ frontend.
[Bug c++/53932] [10/11/12/13 Regression] C++ reference variable to member of anonymous union in global is error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53932
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Keywords||wrong-code
--- Comment #6 from Richard Biener ---
The C++ frontend mangles union { int i; };
.local _ZL1i
.comm _ZL1i,4,4
but not the reference to the anonymous union member:
.globl r
.data
.align 8
.type r, @object
.size r, 8
r:
.quad i
they are even different decls:
i/3 (int i)
Type: variable
Body removed by symtab_remove_unreachable_nodes
Visibility: semantic_interposition artificial
References:
Referring: r/1 (addr)
Availability: not_available
Varpool flags:
r/1 (int& r)
Type: variable definition analyzed
Visibility: force_output externally_visible semantic_interposition no_reorder
asm_written public
Aux: @0x1
References: i/3 (addr)
Referring:
Availability: available
Varpool flags: initialized read-only const-value-known
_ZL1i/0 (_ZL1i)
Type: variable definition analyzed
Visibility: force_output semantic_interposition no_reorder
prevailing_def_ironly asm_written
Aux: @0x77ff3100
References:
Referring:
Availability: available
Varpool flags:
[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108144 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- This particular issue should be fixed now.
[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108144 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:1cfaaa42296298ea2d2b22a93d3c8c17104e6cd3 commit r13-5255-g1cfaaa42296298ea2d2b22a93d3c8c17104e6cd3 Author: Richard Biener Date: Thu Jan 19 12:15:14 2023 +0100 modula2/108144 - fix --enable-version-specific-runtime-libs The following fixes --enable-version-specific-runtime-libs for the modula2 target libraries. The issue is that the install happens via for example toolexeclib_LTLIBRARIES = libm2cor.la and toolexeclibdir is set to $(toolexecdir)/$(gcc_version)$(MULTISUBDIR) but the Makefile.am do not define $(gcc_version) but instead $(version) which is used locally to define libsubdir. The fix is to consistently define and use $(gcc_version), also properly supporting --with-gcc-major-version-only PR modula2/108144 libgm2/ * configure.ac: Add GCC_BASE_VER. * configure: Re-generate. * Makefile.am: Use @get_gcc_base_ver@ for gcc_version. * libm2cor/Makefile.am: Likewise. Use gcc_version instead of version. * libm2iso/Makefile.am: Likewise. * libm2log/Makefile.am: Likewise. * libm2min/Makefile.am: Likewise. * libm2pim/Makefile.am: Likewise. * Makefile.in: Re-generate. * libm2cor/Makefile.in: Likewise. * libm2iso/Makefile.in: Likewise. * libm2log/Makefile.in: Likewise. * libm2min/Makefile.in: Likewise. * libm2pim/Makefile.in: Likewise.
[Bug other/108464] [13 Regression] Broken -fdebug-prefix-map since r13-3599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464 --- Comment #4 from Jakub Jelinek --- Though, even for the other options the change doesn't seem to be a good idea as is. I think instead the syntax of those remapping options should be extended, so that for each of the pair one can choose the behavior which is wanted. Using the OLD=NEW syntax with the previous behavior, and some other to mark pairs where you want new behavior (dunno whether to mark those using say extra = at the end after NEW or whatever else). Then when populating file_prefix_map entries, one would record this non-canonicalizing vs. canonicalizing flag and in the latter case canonicalize the old_prefix path in the structure. remap_filename then would ideally lazily lrealpath when seeing first map entry with the bool flag indicating canonicalization.
[Bug other/108464] [13 Regression] Broken -fdebug-prefix-map since r13-3599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464 --- Comment #3 from Richard Purdie --- (In reply to Jakub Jelinek from comment #2) > Dunno about other uses of remap_filename, but for remap_debug_filename what > that commit changed doesn't seem to be ever appropriate. I think it depends on your use case. For example if via debug-prefix-map you say you want: /somepath/somesources translated to /somewhere and then some code references ../somesources and ../../somesources from it's build tree, would you want the user to have to add mappings for those and any other combination some build system might end up generating due to it's source layout? > Users pass often > pass what they get from pwd to -fdebug-prefix-map=, and that is usually not > the canonicalized path. And DW_AT_comp_dir was that same path as well and > IMHO it would be a very bad idea to change that. Debug info contains > relative paths in many cases, that also shouldn't be canonicalized, should > be whatever user used in -I etc. options or #include paths etc. > If one is mixing absolute paths and some are canonical and others aren't, > one can use multiple -fdebug-prefix-map= options. But ignoring what user > asked for is just wrong. It can be argued that if you ask for my above example and it doesn't remap the relative accesses, it is also just wrong. I can say that with all the cross compiling we do (in Yocto Project), making this handle the corner cases improved our binary reproducibility quite significantly. gcc can revert the change but we'd just have to patch something in to handle this. Another possible option is to resolve both sides of the equation before deciding to remap or not (i.e. the directory in debug-prefix-map and the potential target)?
[Bug ipa/106158] IPA SRA ssa_name_only_returned_p is quadratic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106158 --- Comment #4 from Martin Jambor --- (In reply to Richard Biener from comment #3) > it looks like the testcase no longer shows the issue(?) but the code in IPA > SRA didn't really change here I have fixed quadratic behavior in ipa-param-manipulation.cc two weeks ago, so perhaps the real problem was there. ssa_name_only_returned_p is on my TODO list :-)
[Bug other/108464] [13 Regression] Broken -fdebug-prefix-map since r13-3599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464 --- Comment #2 from Jakub Jelinek --- Dunno about other uses of remap_filename, but for remap_debug_filename what that commit changed doesn't seem to be ever appropriate. Users pass often pass what they get from pwd to -fdebug-prefix-map=, and that is usually not the canonicalized path. And DW_AT_comp_dir was that same path as well and IMHO it would be a very bad idea to change that. Debug info contains relative paths in many cases, that also shouldn't be canonicalized, should be whatever user used in -I etc. options or #include paths etc. If one is mixing absolute paths and some are canonical and others aren't, one can use multiple -fdebug-prefix-map= options. But ignoring what user asked for is just wrong.
[Bug target/103100] [11/12/13 Regression] unaligned access generated with memset or {} and -O2 -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100 --- Comment #13 from Richard Biener --- (In reply to Andrew Pinski from comment #10) > Updated patch submitted: > https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589254.html I think you need to ping your patches more aggressively ...
[Bug tree-optimization/102844] [10/11/12/13 Regression] DOM jump threading not copying block that became non-empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844 --- Comment #31 from Richard Biener --- The issue is still latent but cannot be reproduced on any maintained branch.
[Bug middle-end/105469] [10/11/12/13 Regression] "execution reached an unreachable program point" with -flto since r5-7027-g0b986c6ac777aa4e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105469 --- Comment #19 from Martin Jambor --- (In reply to Jakub Jelinek from comment #16) > Martin, is that a real fix for this or it just went latent? Not a fix, the bug mst be latent. But it is surprising so I'll have a look what happened too.
[Bug modula2/108373] Update 'contrib/gcc_update:files_and_dependencies' for Modula-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108373 Gaius Mulley changed: What|Removed |Added CC||gaius at gcc dot gnu.org --- Comment #1 from Gaius Mulley --- Created attachment 54308 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54308=edit Proposed patch for contrb/gcc_update Here is a proposed patch adding the automatically generated files used by m2.
[Bug tree-optimization/100061] [10/11 Regression] Comparison guarding undefined behaviour disappears
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100061 Richard Biener changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11 Regression] |Comparison guarding |Comparison guarding |undefined behaviour |undefined behaviour |disappears |disappears Known to fail||11.3.1 Known to work||12.1.0, 13.0 --- Comment #14 from Richard Biener --- Btw, eventually the refactoring done for PR105142 in r12-8012-gfc8d9e4497032d will help, at least the fixed problem is of similar nature. The original testcase seems fixed by this at least as we are no longer expanding the guarded c + 1.
[Bug other/108464] [13 Regression] Broken -fdebug-prefix-map since r13-3599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464 --- Comment #1 from Richard Purdie --- I can see why that would change behaviour with the patch :(. It is a tough dilemma since without the patch, files might have prefixes removed some of the time but not all the time, depending on whether they were accessed via a symlink (or similar) or not. It was effectively impossible to remap some prefix values meaning in some cases output files couldn't be build deterministically. One possible way to fix this issue might be to call realpath on DW_AT_comp_dir so that we're always working on canonicalized paths? I'm not sure if that would be acceptable or not, the challenge right now is that we're making comparisons against things which aren't always definitive.
[Bug ipa/103585] fatigue2 requires inlining of peridida to work well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103585 --- Comment #14 from Martin Jambor --- Honza, what remains to be done here (if anything)?
[Bug ipa/95558] [10/11/12/13 Regression] Invalid IPA optimizations based on weak definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2020-06-09 00:00:00 |2023-1-19 Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #16 from Richard Biener --- Re-confirmed. The bad attribute suggestion is also still there for the testcase in comment#1
[Bug tree-optimization/93444] [10/11 Regression] ssa-loop-im introduces unconditional use of uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93444 Richard Biener changed: What|Removed |Added Known to fail||12.2.0 Known to work||12.2.1, 13.0 Summary|[10/11/12/13 Regression]|[10/11 Regression] |ssa-loop-im introduces |ssa-loop-im introduces |unconditional use of|unconditional use of |uninitialized variable |uninitialized variable --- Comment #12 from Richard Biener --- This has been fixed with r13-4491-g44c8402d351605 on trunk and r12-8977-g812847a9d12c0b6 on the GCC 12 branch. It's unlikely going to be backported further.
[Bug other/108464] [13 Regression] Broken -fdebug-prefix-map since r13-3599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Priority|P3 |P1 Target Milestone|--- |13.0 CC||law at gcc dot gnu.org, ||richard.purdie@linuxfoundat ||ion.org Ever confirmed|0 |1 Last reconfirmed||2023-01-19
[Bug other/108464] New: [13 Regression] Broken -fdebug-prefix-map since r13-3599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464 Bug ID: 108464 Summary: [13 Regression] Broken -fdebug-prefix-map since r13-3599 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- Starting with r13-3599-ge5c15eb183f17e806ad -fdebug-prefix-map stopped working in some cases (breaks ccache testsuite among other things). Reproducer: mkdir -p foobar1/include foobar1/src echo 'int test;' > foobar1/include/test.h echo '#include ' > foobar1/src/test.c ln -sf foobar1 foobar2 cd foobar2 gcc -S -I include/ -fdebug-prefix-map=`pwd`= -g -dA src/test.c -o test.s; grep '\|foobar' test.s Before r13-3599, all the way back from r0-82686-gc8aea42ce2c691e4e8 when -fdebug-prefix-map= has been introduced, this prints (once or multiple times depending on exact version) and doesn't print any foobar strings. Even r13-3598 prints .long .LASF1 # DW_AT_comp_dir: "" .long .LASF1 # Directory Entry: 0: "" .string "" but starting with r13-3599 we print .long .LASF1 # DW_AT_comp_dir: "/home/jakub/foobar2" .long .LASF1 # Directory Entry: 0: "/home/jakub/foobar2" .string "/home/jakub/foobar2" instead, which is wrong because user asked for remapping of /home/jakub/foobar2 and it wasn't done.
[Bug modula2/108373] Update 'contrib/gcc_update:files_and_dependencies' for Modula-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108373 Gaius Mulley changed: What|Removed |Added Last reconfirmed||2023-01-19 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug bootstrap/107950] partial LTO linking of libbackend.a: gcc/gcc-rich-location.cc:207: undefined reference to `range_label_for_type_mismatch::get_text(unsigned int) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950 --- Comment #10 from Richard Biener --- I suppose a fix would be to provide a dummy implementation for range_label_for_type_mismatch::get_text in lto/, but I wonder how for example the fortran frontend avoids this issue? f951 has rich_location uses but no range_label_for_type_mismatch, it looks like range_label_for_* is used only from the C family frontends, so maybe another fix would be to move that class and implementation somewhere to c-family/?
