[Bug rtl-optimization/106364] ICE when compiling inline asm with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106364 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Last reconfirmed||2022-07-20 Status|UNCONFIRMED |NEW
[Bug tree-optimization/106360] [13 regression] ICE in many test cases after r13-1745-g4c323130257744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106360 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-07-20
[Bug tree-optimization/106365] Miss to handle ifn .LEN_STORE in FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106365 Kewen Lin changed: What|Removed |Added CC||rguenth at gcc dot gnu.org, ||segher at gcc dot gnu.org Keywords||missed-optimization Ever confirmed|0 |1 Target||powerpc*-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2022-07-20 --- Comment #1 from Kewen Lin --- Now vn_reference_lookup_3 of sccvn can handle bif memcpy, it seems we can teach it about this IFN there. Another idea seems to fold this ifn into something early that sccvn already supports, like aggregate construction with constants?
[Bug target/106355] Linux s390x -O2 argument passing miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106355 Richard Biener changed: What|Removed |Added CC||krebbel at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Did you see whether this is changed behavior from GCC 11?
[Bug target/106356] static-pie for arm not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106356 Richard Biener changed: What|Removed |Added Severity|normal |enhancement
[Bug middle-end/106010] Miss vectorization for complex type copy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106010 --- Comment #5 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:f9d4c3b45c5ed5f45c8089c990dbd4e181929c3d commit r13-1762-gf9d4c3b45c5ed5f45c8089c990dbd4e181929c3d Author: liuhongt Date: Tue Jul 19 17:24:52 2022 +0800 Lower complex type move to enable vectorization for complex type load&store. 2022-07-20 Richard Biener Hongtao Liu gcc/ChangeLog: PR tree-optimization/106010 * tree-complex.cc (init_dont_simulate_again): Lower complex type move. (expand_complex_move): Also expand COMPLEX_CST for rhs. gcc/testsuite/ChangeLog: * gcc.target/i386/pr106010-1a.c: New test. * gcc.target/i386/pr106010-1b.c: New test. * gcc.target/i386/pr106010-1c.c: New test. * gcc.target/i386/pr106010-2a.c: New test. * gcc.target/i386/pr106010-2b.c: New test. * gcc.target/i386/pr106010-2c.c: New test. * gcc.target/i386/pr106010-3a.c: New test. * gcc.target/i386/pr106010-3b.c: New test. * gcc.target/i386/pr106010-3c.c: New test. * gcc.target/i386/pr106010-4a.c: New test. * gcc.target/i386/pr106010-4b.c: New test. * gcc.target/i386/pr106010-4c.c: New test. * gcc.target/i386/pr106010-5a.c: New test. * gcc.target/i386/pr106010-5b.c: New test. * gcc.target/i386/pr106010-5c.c: New test. * gcc.target/i386/pr106010-6a.c: New test. * gcc.target/i386/pr106010-6b.c: New test. * gcc.target/i386/pr106010-6c.c: New test. * gcc.target/i386/pr106010-7a.c: New test. * gcc.target/i386/pr106010-7b.c: New test. * gcc.target/i386/pr106010-7c.c: New test. * gcc.target/i386/pr106010-8a.c: New test. * gcc.target/i386/pr106010-8b.c: New test. * gcc.target/i386/pr106010-8c.c: New test. * gcc.target/i386/pr106010-9a.c: New test. * gcc.target/i386/pr106010-9b.c: New test. * gcc.target/i386/pr106010-9c.c: New test. * gcc.target/i386/pr106010-9d.c: New test.
[Bug tree-optimization/106360] [13 regression] ICE in many test cases after r13-1745-g4c323130257744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106360 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug target/106364] ICE when compiling inline asm with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106364 Richard Biener changed: What|Removed |Added Target||i?86-*-* Keywords||diagnostic Component|rtl-optimization|target --- Comment #1 from Richard Biener --- possibly a diagnostic issue only - we might want to gate the diagnostic on error_count/sorry_count == 0. But then the question is whether we can "safely" stop doing lra_assign here or if there's an alternative "silent" way to terminate compilation.
[Bug target/106342] [12/13 Regression] internal compiler error: in extract_insn, at recog.cc:2791 since r12-4240-g2b8453c401b699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106342 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Keywords|needs-bisection | Status|UNCONFIRMED |NEW Last reconfirmed||2022-07-20 Summary|[12/13 Regression] internal |[12/13 Regression] internal |compiler error: in |compiler error: in |extract_insn, at|extract_insn, at |recog.cc:2791 |recog.cc:2791 since ||r12-4240-g2b8453c401b699 --- Comment #4 from Martin Liška --- Started with r12-4240-g2b8453c401b699 where vectorization was enabled for -O2.
[Bug target/106355] Linux s390x -O2 argument passing miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106355 --- Comment #2 from Stephan Bergmann --- (In reply to Richard Biener from comment #1) > Did you see whether this is changed behavior from GCC 11? I didn't check that myself, but the Debian LibreOffice maintainer claims that he sees the same symptoms when building with some GCC 11 (against some GCC 12 libstdc++, though). (It appears that this issue only happened to start to hit builds of LibreOffice after some recent code changes in LibreOffice, so we don't have any historic data on which versions of GCC would not have had this issue.)
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 106010, which changed state. Bug 106010 Summary: Miss vectorization for complex type copy. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106010 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/106010] Miss vectorization for complex type copy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106010 Hongtao.liu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Hongtao.liu --- Fixed in GCC13, I'll revisit PR105923 for complex type libmvec.
[Bug c/105923] unsupported return type ‘complex double’ for simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105923 Bug 105923 depends on bug 106010, which changed state. Bug 106010 Summary: Miss vectorization for complex type copy. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106010 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/102575] Failure to optimize double _Complex stores to use largest loads/stores possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102575 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #3 from Hongtao.liu --- This should be fixed by r13-1762-gf9d4c3b45c5ed5f45c8089c990dbd4e181929c3d
[Bug tree-optimization/106365] Miss to handle ifn .LEN_STORE in FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106365 Richard Biener changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #2 from Richard Biener --- What's the semantic of .LEN_STORE? I can't find documentation for this :/ There's docs for the len_store optab but how 'mask' and 'bias' relate to its operands isn't documented anywhere. If the cited .LEN_STORE is a full store then sure - folding to a plain MEM = value; is preferred. Otherwise I wouldn't split it up. Handling of partial stores in VN is possible, the "easiest" way is probably via vn_reference_lookup_3 and its support for partial defs (for constant masks a store may then be composed of multiple partial defs and "masked" parts that are required will be taken from earlier stores). Maybe handling of all partial store IFNs can be commonized somehow. Alias analysis in general (ref_maybe_used_by_stmt_p, call_may_clobber_ref_p, stmt_kills_ref_p) also miss handling of them - possibly some more general helpers can facilitate that.
[Bug bootstrap/106145] [12/13 Regression] /usr/bin/ld: libcommon.a(input.o): copy relocation against non-copyable protected symbol `__cxa_pure_virtual' on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106145 Matthias Klose changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Matthias Klose --- and now unreproducible with updated binutils and gcc packages ... closing
[Bug tree-optimization/106365] Miss to handle ifn .LEN_STORE in FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106365
--- Comment #3 from Kewen Lin ---
(In reply to Richard Biener from comment #2)
> What's the semantic of .LEN_STORE? I can't find documentation for this :/
> There's docs for the len_store optab but how 'mask' and 'bias' relate to its
> operands isn't documented anywhere.
Yeah, it seems that in general we don't document for IFNs, I guess it's because
in most cases IFN is mapped to one relevant optab. In the doc for len_store
optab, there are some notes for "bias" (operand 3), it's either 0 or -1, and
used as part of the value to specify how many (op2 - op3) vector elements will
be stored. For now, Power10 uses 0 and s390 uses 1.
" Store (operand 2 - operand 3) vector elements from vector register operand 1
into memory operand 0, leaving the other elements of operand 0 unchanged.
...
Operand 2 can be a variable or a constant amount. Operand 3 specifies a
constant bias: it is either a constant 0 or a constant -1. The predicate on
operand 3 must only accept the bias values that the target actually supports.
GCC handles a bias of 0 more efficiently than a bias of -1."
For the statement:
.LEN_STORE (&MEM [(void *)&a + 32B], 128B, 8, { 64, 0, 0, 0, 81, 0,
0, 0, 100, 0, 0, 0, 121, 0, 0, 0 }, 0);
op0 is dest mem, op1 128B is alias align info, op2 8 is length in bytes to
be stored, op3 is src const vector, op4 is the bias.
> If the cited .LEN_STORE is a full store
> then sure - folding to a plain MEM = value; is preferred.
The src constant vector is 16 bytes above, the length is 8 bytes, so it's not a
full store in this case.
> Otherwise I wouldn't
> split it up. Handling of partial stores in VN is possible, the "easiest" way
> is probably via vn_reference_lookup_3 and its support for partial defs
> (for constant masks a store may then be composed of multiple partial defs
> and "masked" parts that are required will be taken from earlier stores).
>
OK, thanks for the pointer! i'll have a look at it.
> Maybe handling of all partial store IFNs can be commonized somehow.
>
I just had a try with SVE (partial load/store with mask) with
-msve-vector-bits=128 --param vect-partial-vector-usage=1, it also ends with
sub-optimal code:
[local count: 97603129]:
MEM [(int *)&a] = { 0, 1, 4, 9 };
MEM [(int *)&a + 16B] = { 16, 25, 36, 49 };
.MASK_STORE (&MEM [(void *)&a + 32B], 128B, { -1, -1, 0, 0 }, { 64,
81, 100, 121 });
vect__2.10_13 = MEM [(int *)&a];
vect__2.10_29 = MEM [(int *)&a + 16B];
vect_res_10.11_30 = vect__2.10_13 + vect__2.10_29;
_35 = (vector(4) int) vect_res_10.11_30;
vect__7.16_41 = .MASK_LOAD (&MEM [(void *)&a + 32B], 128B, { -1,
-1, 0, 0 });
vect_res_15.17_42 = .COND_ADD ({ -1, -1, 0, 0 }, _35, vect__7.16_41, _35);
_44 = .REDUC_PLUS (vect_res_15.17_42); [tail call]
a ={v} {CLOBBER(eol)};
return _44;
> Alias analysis in general (ref_maybe_used_by_stmt_p, call_may_clobber_ref_p,
> stmt_kills_ref_p) also miss handling of them - possibly some more general
> helpers can facilitate that.
[Bug tree-optimization/106365] Miss to handle ifn .LEN_STORE in FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106365
--- Comment #4 from Richard Biener ---
int __attribute__((noinline,noclone))
foo (int *out)
{
int mask[] = { 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1 };
int i;
for (i = 0; i < 32; ++i)
{
if (mask[i])
out[i] = i;
}
return out[7];
}
testcase for x86_64 and .MASK_STORE, could be optimized to return 1. FRE
sees
.MASK_STORE (out_41(D), 32B, mask__7.9_47, { 0, 1, 2, 3, 4, 5, 6, 7 });
_10 = &mask[8] + 32;
MEM [(int *)_10] = { 0, 1, 0, 1, 0, 1, 0, 1 };
and 'mask' having address taken makes it clobbered by .MASK_STORE. There's
also the older issue that when mask is incoming but marked __restrict that
isn't good enough because __restrict and calls doesn't work.
The IL with .LEN_STORE might suffer similar issues at the point FRE gets
to see it.
We might be able to improve BB SLP to not code-gen
_10 = &mask[8] + 32;
MEM [(int *)_10] = { 0, 1, 0, 1, 0, 1, 0, 1 };
here, making 'mask' addressable again. I have a patch for this in testing.
[Bug tree-optimization/102575] Failure to optimize double _Complex stores to use largest loads/stores possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102575 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Richard Biener --- Thanks Hongtao
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 102575, which changed state. Bug 102575 Summary: Failure to optimize double _Complex stores to use largest loads/stores possible https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102575 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/106365] Miss to handle ifn .LEN_STORE in FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106365 --- Comment #5 from Richard Biener --- I will try to add handling for .MASK_STORE, hopefully that will be good enough to massage the code for .LEN_STORE (which IIRC is "easier" since it's a contiguous store rather than .MASK_STORE which can have multiple "pieces").
[Bug tree-optimization/106365] Miss to handle ifn .LEN_STORE in FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106365 --- Comment #6 from Kewen Lin --- (In reply to Richard Biener from comment #5) > I will try to add handling for .MASK_STORE, hopefully that will be good > enough to massage the code for .LEN_STORE (which IIRC is "easier" since it's > a contiguous store rather than .MASK_STORE which can have multiple "pieces"). Nice, thanks! Yeah, it's contiguous. :)
[Bug c++/96830] GCC does not complain template-head containing requires clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96830
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2020-08-28 00:00:00 |2022-7-20
--- Comment #3 from Jonathan Wakely ---
Another examples:
template requires true
struct S
{
template
friend struct S;
};
S s;
EDG:
"diff.C", line 5: error: requires-clause incompatible with class template "S"
(declared at line 2)
friend struct S;
^
detected during instantiation of class "S [with T=int]" at line 8
1 error detected in the compilation of "diff.C".
Clang:
diff.C:4:3: error: requires clause differs in template redeclaration
template
^
diff.C:8:8: note: in instantiation of template class 'S' requested here
S s;
^
diff.C:1:28: note: previous template declaration is here
template requires true
^
1 error generated.
[Bug sanitizer/106368] New: ASan fails to report an error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106368
Bug ID: 106368
Summary: ASan fails to report an error.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Hi,
For the following code snippet, `gcc-trunk -O0 -fsanitize=address` reports
nothing but `gcc-trunk -O3` reports it.
$ cat a.c
#pragma pack(1)
struct a {
int b;
long c
};
#pragma pack()
struct d {
long b;
struct a c
};
struct d f;
static long *g = &f.c.c;
int main() {
volatile int e = *(g+1);
}
$
$gcc-trunk -O0 -fsanitize=address a.c && ./a.out
$
$gcc-trunk -O3 -fsanitize=address a.c && ./a.out
==1==ERROR: AddressSanitizer: unknown-crash on address 0x00404134 at pc
0x004011a8 bp 0x7ffeadf39d20 sp 0x7ffeadf39d18
READ of size 8 at 0x00404134 thread T0
#0 0x4011a7 in main /app/example.c:14
#1 0x7f044e5530b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x240b2) (BuildId:
9fdb74e7b217d06c93172a8243f8547f947ee6d1)
#2 0x40120d in _start (/app/output.s+0x40120d) (BuildId:
a4a82ec9bae1cc563083aff345004ea80e8df0db)
0x00404138 is located 0 bytes to the right of global variable 'f' defined
in '/app/example.c:11:10' (0x404120) of size 24
SUMMARY: AddressSanitizer: unknown-crash /app/example.c:14 in main
Shadow bytes around the buggy address:
0x800787d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800787e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800787f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078810: 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
=>0x80078820: 00 00 00 00 00 00[00]f9 f9 f9 f9 f9 00 00 00 00
0x80078830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078850: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Container overflow: fc
Array cookie:ac
Intra object redzone:bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone:cb
==1==ABORTING
[Bug lto/91252] [Bug] When use -flto "weak symbol" are converted to "t".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91252 Eason Lai changed: What|Removed |Added CC||sen2403 at hotmail dot com --- Comment #5 from Eason Lai --- d
[Bug lto/91252] [Bug] When use -flto "weak symbol" are converted to "t".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91252 --- Comment #6 from Eason Lai --- (In reply to Eason Lai from comment #5) > d Sorry for add wrong comment.
[Bug c++/106369] New: ICE in output_constructor_regular_field, at varasm.cc:5515
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106369 Bug ID: 106369 Summary: ICE in output_constructor_regular_field, at varasm.cc:5515 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: h2+bugs at fsfe dot org Target Milestone: --- Created attachment 53322 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53322&action=edit backtrace Also reproducible with GCC-10.3 (varasm.c:5254). I don't know if this is a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103285 since that is in the fortran component.
[Bug tree-optimization/106365] Miss to handle ifn .LEN_STORE in FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106365 --- Comment #7 from Richard Biener --- Created attachment 53323 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53323&action=edit prototype I'm testing this - for .LEN_STORE you mainly have to compute pd.rhs_off, pd.offset, pd.size and do a single return data->push_partial_def (pd, set, set, offseti, maxsizei);
[Bug lto/91299] LTO inlines a weak definition in presence of a non-weak definition from an ELF file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91299
--- Comment #10 from Eason Lai ---
Add my test program.
$cat boo.c
#include "boo.h"
int get_t(void)
{
return 1;
}
$cat main.c
#include "boo.h"
__attribute__((weak)) int get_t(void)
{
return 0;
}
int a;
int main(void)
{
a = get_t();
return a;
}
$arm-none-eabi-gcc -mlittle-endian -mthumb -mcpu=cortex-m33 -Os -flto -c main.c
-o main.o
#arm-none-eabi-gcc -mlittle-endian -mthumb -mcpu=cortex-m33 -Os -fno-lto -c
boo.c -o boo.o
#arm-none-eabi-gcc --specs=nano.specs -lnosys -nostartfiles -Wl,--gc-sections
-Wl,-Ttest.ld boo.o main.o -o main -save-temps
$arm-none-eabi-objdump -d main
main: file format elf32-littlearm
Disassembly of section .test:
1000 :
1000: 2000movsr0, #0
1002: 4770bx lr
$cat "./-lm.res"
1
main.o 3
190 a62a5458565feecb PREEMPTED_REG get_t
192 a62a5458565feecb PREVAILING_DEF main
196 a62a5458565feecb PREVAILING_DEF_IRONLY a
[Bug c/106370] New: enhancement: last statement of loop is continue is redundant ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106370 Bug ID: 106370 Summary: enhancement: last statement of loop is continue is redundant ? Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Cppcheck has just been enhanced to detect the last statement of a loop is a continue and mark it as a bad style. For example: gcc/cp/init.cc:1439:4: style: 'continue' is redundant since it is the last statement in a loop. [redundantContinue] Source code is splice: *p = TREE_CHAIN (*p); continue; } I feel this is a minor style issue which gcc may not be interested in, but I thought it best to make others aware. 21 cases in the gcc source code. List available.
[Bug target/100799] Stackoverflow in optimized code on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799 --- Comment #10 from Alexander Grund --- (In reply to Peter Bergner from comment #2) > The failure with GCC 7 and later coincides with the PPC port starting to > default to LRA instead of reload. Is there a compiler flag that can switch the default back as a workaround?
[Bug tree-optimization/106365] Miss to handle ifn .LEN_STORE in FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106365 Richard Biener changed: What|Removed |Added Attachment #53323|0 |1 is obsolete|| --- Comment #8 from Richard Biener --- Created attachment 53324 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53324&action=edit updated prototype
[Bug c++/106369] ICE in output_constructor_regular_field, at varasm.cc:5515
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106369 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-07-20 Status|UNCONFIRMED |NEW Keywords||needs-reduction --- Comment #1 from Richard Biener --- Confirmed.
[Bug rtl-optimization/101347] [11/12/13 Regression] ICE in cfg_layout_initialize with __builtin_setjmp and -fprofile-generate -fprofile-use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101347 --- Comment #5 from CVS Commits --- The master branch has been updated by Alexander Monakov : https://gcc.gnu.org/g:daa36cfc2fc2538810db071b81d250f4d621f7ea commit r13-1766-gdaa36cfc2fc2538810db071b81d250f4d621f7ea Author: Alexander Monakov Date: Tue Jul 19 18:04:30 2022 +0300 Avoid registering __builtin_setjmp_receiver label twice [PR101347] The testcase in the PR demonstrates how it is possible for one __builtin_setjmp_receiver label to appear in nonlocal_goto_handler_labels list twice (after the block with __builtin_setjmp_setup referring to it was duplicated). remove_node_from_insn_list did not account for this possibility and removed only the first copy from the list. Add an assert verifying that duplicates are not present. To avoid adding a label to the list twice, move registration of the label from __builtin_setjmp_setup handling to __builtin_setjmp_receiver. gcc/ChangeLog: PR rtl-optimization/101347 * builtins.cc (expand_builtin) [BUILT_IN_SETJMP_SETUP]: Move population of nonlocal_goto_handler_labels from here ... (expand_builtin) [BUILT_IN_SETJMP_RECEIVER]: ... to here. * rtlanal.cc (remove_node_from_insn_list): Verify that a duplicate is not present in the remainder of the list.
[Bug rtl-optimization/101347] [11/12 Regression] ICE in cfg_layout_initialize with __builtin_setjmp and -fprofile-generate -fprofile-use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101347 Alexander Monakov changed: What|Removed |Added Summary|[11/12/13 Regression] ICE |[11/12 Regression] ICE in |in cfg_layout_initialize|cfg_layout_initialize with |with __builtin_setjmp and |__builtin_setjmp and |-fprofile-generate |-fprofile-generate |-fprofile-use |-fprofile-use --- Comment #6 from Alexander Monakov --- Should be fixed on the trunk, suggestions regarding backports welcome.
[Bug target/106356] static-pie for arm not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106356 --- Comment #2 from Lance Fredrickson --- Submission made here. https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598610.html
[Bug target/100799] Stackoverflow in optimized code on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799 --- Comment #11 from Alexander Grund --- Some more experiments with GCC 10.3, OpenBLAS 0.3.15 and FlexiBLAS 3.0.4: Baseline: Broken at -O1, working at -Og I got it to break with "-Og -fmove-loop-invariants". Then it worked again by adding "-fstack-protector-all". But that is seemingly not advisable: https://developers.redhat.com/blog/2020/05/22/stack-clash-mitigation-in-gcc-part-3 Hence the current workaround is to use "-O2 -fno-move-loop-invariants"
[Bug c++/106371] New: Bogus narrowing conversion reported due to bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106371
Bug ID: 106371
Summary: Bogus narrowing conversion reported due to bitfield
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Consider:
#include
struct A {
uint64_t x : 32;
};
struct B {
uint32_t x;
};
void f() {
auto a = A{.x = 1};
auto b = B{.x = a.x};
}
gcc currently emits a narrowing warning here:
:13:24: warning: narrowing conversion of '(long unsigned int)a.A::x'
from 'long unsigned int' to 'uint32_t' {aka 'unsigned int'} [-Wnarrowing]
13 | auto b = B{ .x = a.x };
| ~~^
It is true that a.x is a uint64_t, but also it's only a 32-bit bitfield, there
isn't actually any narrowing possible. This code should be fine.
clang doesn't warn here (only if A::x were actually a uint64_t, or the width of
the bitfield was larger than 32).
[Bug target/106340] flag set from SVE svwhilelt intrinsic not reused in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106340 Yichao Yu changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Yichao Yu --- Over at the llvm bug report, it was pointed out to me that the standard pattern to use is to do the branch based on ptest intrinsics. It matches the flag setting of the whilelt family of instructions better and gcc is already able to omit the ptest instruction in such case.
[Bug c++/106372] New: error: redefinition of ‘const char *mangled function name*[]’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106372
Bug ID: 106372
Summary: error: redefinition of ‘const char *mangled function
name*[]’
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: striker159 at web dot de
Target Milestone: ---
The following minimal code compiles with g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) ,
but does not compile with g++-11 (Ubuntu 11.1.0-1ubuntu1~20.04). Target:
x86_64-linux-gnu
-
Error message:
bug1.cpp:26:2: error: redefinition of ‘const char
_ZTSZN1AIjEC4ESt8functionIFmmEEEd_UlT_E_ []’
26 | };
| ^
bug1.cpp:26:2: note: ‘const char _ZTSZN1AIjEC4ESt8functionIFmmEEEd_UlT_E_ [37]’
previously defined here
-
//g++-11 -std=c++17 -Wall -Wextra -O3 bug1.cpp -c -o bug1_g++11.o
#include
#include
#include
template
struct A{
using Callback = std::function;
A(Callback pol = [](auto){return 42;}){
pol(1);
}
};
struct B{
B() = default;
B(int){}
A member;
};
struct C{
void foo() {
auto ptr = std::make_unique();
}
};
[Bug c++/106372] error: redefinition of ‘const char *mangled function name*[]’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106372 --- Comment #1 from striker159 at web dot de --- Created attachment 53325 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53325&action=edit preprocessed file
[Bug c++/106372] error: redefinition of ‘const char *mangled function name*[]’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106372 --- Comment #2 from Jonathan Wakely --- This is already fixed in GCC 11.3
[Bug c++/103186] [11 Regression] ICE with lambda as default argument in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103186 Jonathan Wakely changed: What|Removed |Added CC||striker159 at web dot de --- Comment #17 from Jonathan Wakely --- *** Bug 106372 has been marked as a duplicate of this bug. ***
[Bug c++/106372] error: redefinition of ‘const char *mangled function name*[]’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106372 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Jonathan Wakely --- Fixed by r12-6973 for PR c++/103186 *** This bug has been marked as a duplicate of bug 103186 ***
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #43 from Jonathan Wakely --- I still haven't figured out why configure is setting LD_LIBRARY_PATH when using ld.gold. It's not coming from the libstdc++ build, I think it's the top-level configure which is setting RPATH_ENVVAR.
[Bug c++/106371] Bogus narrowing conversion reported due to bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106371 --- Comment #1 from Marek Polacek --- May be a missing unlowered_expr_type call.
[Bug c++/106371] Bogus narrowing conversion reported due to bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106371 --- Comment #2 from Andrew Pinski --- MSVC produces an error though: (14): error C2397: conversion from 'unsigned __int64' to 'unsigned int' requires a narrowing conversion
[Bug c++/106369] ICE in output_constructor_regular_field, at varasm.cc:5515
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106369 Marek Polacek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- I think this started with r12-2975-g32c3a75390623a.
[Bug c++/106369] [12/13 Regression] ICE in output_constructor_regular_field, at varasm.cc:5515
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106369 Andrew Pinski changed: What|Removed |Added Summary|ICE in |[12/13 Regression] ICE in |output_constructor_regular_ |output_constructor_regular_ |field, at varasm.cc:5515|field, at varasm.cc:5515 Target Milestone|--- |12.2
[Bug c++/106369] [12/13 Regression] ICE in output_constructor_regular_field, at varasm.cc:5515
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106369 --- Comment #3 from Andrew Pinski --- reducing ...
[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791 since r13-1607-gc3ed9e0d6e96d869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106303 Roger Sayle changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com
[Bug target/106347] [13 Regression] ICE in ix86_output_ssemov, at config/i386/i386.cc:5565, or ICE in final_scan_insn_1, at final.cc:2860 (error: could not split insn) since r13-1607-gc3ed9e0d6e96d869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106347 Roger Sayle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com Status|NEW |ASSIGNED
[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791 since r13-1607-gc3ed9e0d6e96d869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106303 --- Comment #5 from H.J. Lu --- The original TImode STV pass only converts load and store. When other operations were added, timode_remove_non_convertible_regs no longer works correctly. After an instruction is removed from the candidate list, any instructions which use the associated registers should also be removed from the candidate list.
[Bug target/100799] Stackoverflow in optimized code on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799 --- Comment #12 from Segher Boessenkool --- (In reply to Alexander Grund from comment #10) > (In reply to Peter Bergner from comment #2) > > The failure with GCC 7 and later coincides with the PPC port starting to > > default to LRA instead of reload. > > Is there a compiler flag that can switch the default back as a workaround? No, the PowerPC GCC port only supports LRA since g:7a5cbf29beb2 (from 2017).
[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791 since r13-1607-gc3ed9e0d6e96d869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106303 --- Comment #6 from H.J. Lu --- Created attachment 53326 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53326&action=edit Something like this
[Bug target/100799] Stackoverflow in optimized code on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799 --- Comment #13 from Segher Boessenkool --- (In reply to Alexander Grund from comment #11) > Some more experiments with GCC 10.3, OpenBLAS 0.3.15 and FlexiBLAS 3.0.4: > > Baseline: Broken at -O1, working at -Og > > I got it to break with "-Og -fmove-loop-invariants". > Then it worked again by adding "-fstack-protector-all". Both are great info! > But that is > seemingly not advisable: > https://developers.redhat.com/blog/2020/05/22/stack-clash-mitigation-in-gcc- > part-3 -fstack-protector-strong is cheap enough that you can (and perhaps should) enable it almost always. Some distributions do this even? -fstack-check= is an Ada thing. -fstack-clash-protection is a different thing as well (that's what that article is about). Enabling ssp is not a great workaround of course, it is much to roundabout; and I suspect the only reason it works is because it changes the stack layout. Still, useful info, thanks :-)
[Bug analyzer/106373] New: False positives from -Wanalyzer-tainted-array-index with casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106373
Bug ID: 106373
Summary: False positives from -Wanalyzer-tainted-array-index
with casts
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106358
Target Milestone: ---
See: https://godbolt.org/z/P5nGMohxd
Am seeing false positive with -O1 -fanalyzer -fanalyzer-checker=taint on this
code:
struct raw_ep {
/* ...snip... */
int state;
/* ...snip... */
};
struct raw_dev {
/* ...snip... */
struct raw_ep eps[30];
int eps_num;
/* ...snip... */
};
int __attribute__((tainted_args))
simplified_raw_ioctl_ep_disable(struct raw_dev *dev, unsigned long value)
{
int ret = 0, i = value;
if (i < 0 || i >= dev->eps_num) {
ret = -16;
goto out_unlock;
}
if (dev->eps[i].state == 0) {
ret = -22;
goto out_unlock;
}
out_unlock:
return ret;
}
../../src/raw_gadget.c: In function ‘simplified_raw_ioctl_ep_disable’:
../../src/raw_gadget.c:23:18: warning: use of attacker-controlled value ‘value’
in array lookup without upper-bounds checking [CWE-129]
[-Wanalyzer-tainted-array-index]
23 | if (dev->eps[i].state == 0) {
| ~~~^~
‘simplified_raw_ioctl_ep_disable’: event 1
|
| 15 | simplified_raw_ioctl_ep_disable(struct raw_dev *dev, unsigned long
value)
| | ^~~
| | |
| | (1) function ‘simplified_raw_ioctl_ep_disable’ marked with
‘__attribute__((tainted_args))’
|
+--> ‘simplified_raw_ioctl_ep_disable’: events 2-5
|
| 15 | simplified_raw_ioctl_ep_disable(struct raw_dev *dev,
unsigned long value)
| | ^~~
| | |
| | (2) entry to ‘simplified_raw_ioctl_ep_disable’
|..
| 19 | if (i < 0 || i >= dev->eps_num) {
| | ~
| | |
| | (3) following ‘false’ branch...
|..
| 23 | if (dev->eps[i].state == 0) {
| | ~
| | |
| | (4) ...to here
| | (5) use of attacker-controlled value
‘value’ in array lookup without upper-bounds checking
|
Seems to need at least -O1.
Reduced from false positives seen in various ioctl handlers in Linux kernel in
drivers/usb/gadget/legacy/raw_gadget.c (with "allyesconfig").
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358
[Bug 106358] [meta-bug] tracker bug for building the Linux kernel with
-fanalyzer
[Bug c++/106366] CTAD fails to prioritize initializer_list when done via Deduction guide and inherited CTORS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106366
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
CC||ppalka at gcc dot gnu.org
Keywords||rejects-valid
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2022-07-20
--- Comment #1 from Patrick Palka ---
Confirmed, reduced:
#include
template
struct A { A(...); };
template
A(std::initializer_list) -> A;
A a{1,2,3};
This seems valid according to [over.match.class.deduct]/4. In order for the
initializer-list phase of overload resolution to kick in the class template
doesn't necessarily need an initializer-list constructor, it suffices to just
have a guide that looks like one.
[Bug fortran/101330] [openmp]ICE in free_expr0(): Bad expr type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101330 --- Comment #6 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:26bbe78f77f73bb66af1ac13d0deec888a3c6510 commit r13-1767-g26bbe78f77f73bb66af1ac13d0deec888a3c6510 Author: Harald Anlauf Date: Wed Jul 20 20:40:23 2022 +0200 Fortran: fix parsing of omp task affinity iterator clause [PR101330] gcc/fortran/ChangeLog: PR fortran/101330 * openmp.cc (gfc_match_iterator): Remove left-over code from development that could lead to a crash on invalid input. gcc/testsuite/ChangeLog: PR fortran/101330 * gfortran.dg/gomp/affinity-clause-7.f90: New test.
[Bug fortran/101330] [openmp]ICE in free_expr0(): Bad expr type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101330 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED Target Milestone|--- |12.2 --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on mainline so far.
[Bug analyzer/106373] False positives from -Wanalyzer-tainted-array-index on comparison with non-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106373 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-07-20 Status|UNCONFIRMED |ASSIGNED Summary|False positives from|False positives from |-Wanalyzer-tainted-array-in |-Wanalyzer-tainted-array-in |dex with casts |dex on comparison with ||non-const --- Comment #1 from David Malcolm --- The issue isn't the casts; it's the comparison against non-const, which looks like: _1 = dev_6(D)->eps_num; if (_1 <= i_4(D)) at the gimple level, and where i_4(D) is on the RHS, and sm-taint.cc is only looking at comparisons of the LHS. I'm testing a fix.
[Bug fortran/101330] [openmp]ICE in free_expr0(): Bad expr type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101330 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:16155316ea663d854e3ab72b49f1fe1bfacd5e18 commit r12-8587-g16155316ea663d854e3ab72b49f1fe1bfacd5e18 Author: Harald Anlauf Date: Wed Jul 20 20:40:23 2022 +0200 Fortran: fix parsing of omp task affinity iterator clause [PR101330] gcc/fortran/ChangeLog: PR fortran/101330 * openmp.cc (gfc_match_iterator): Remove left-over code from development that could lead to a crash on invalid input. gcc/testsuite/ChangeLog: PR fortran/101330 * gfortran.dg/gomp/affinity-clause-7.f90: New test. (cherry picked from commit 26bbe78f77f73bb66af1ac13d0deec888a3c6510)
[Bug fortran/101330] [openmp]ICE in free_expr0(): Bad expr type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101330 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed. Thanks for the report!
[Bug libstdc++/106013] weakly_incrementable cannot apply on common_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106013 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2022-07-20 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug target/83782] [10/11 Regression] Inconsistent address for hidden ifunc in a shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83782 --- Comment #10 from Alexandre Oliva --- sorry, I typoed the failing test. it's in g++.dg/ext, and it has a .C extesion. how unfortunate that there was another test matching the lower-case name I typoed.
[Bug target/81708] The x86 stack canary location should be customizable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708 --- Comment #18 from Alexandre Oliva --- on x86_64 with -fPIC or -fpic, my_guard's address is indeed loaded from the GOT with @GOTPCREL indeed on x86_64 with -fPIE or -fpie, however, it is used just as expected by the testcase. which should be fine as long as my_guard is required to be a link-time defined constant. but if it is, then there's no point in loading its address from the GOT, not on x86_64 PIC, not on ia32 PIC/PIE. thus my question. something's fishy there.
[Bug analyzer/106374] New: -fanalyzer ICE with certain const static vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106374
Bug ID: 106374
Summary: -fanalyzer ICE with certain const static vars
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106358
Target Milestone: ---
I'm seeing an ICE in -fanalyzer on the Linux kernel's fs/crypto/hkdf.c in
function hkdf_extract.
Reduced reproducer:
typedef unsigned char u8;
extern int foo(const u8 *key, unsigned int keylen);
int test (void)
{
static const u8 default_salt[64];
return foo(default_salt, 64);
}
It's an assertion failure here:
1106binding_cluster::binding_cluster (const region *base_region)
1107: m_base_region (base_region), m_map (),
1108 m_escaped (false), m_touched (false)
1109{
1110 gcc_assert (base_region->tracked_p ());
}
I'm working on a fix.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358
[Bug 106358] [meta-bug] tracker bug for building the Linux kernel with
-fanalyzer
[Bug analyzer/106374] -fanalyzer ICE with certain const static vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106374 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-07-20 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- I added the assertion in r13-1761-g68871a008e686d.
[Bug c++/106369] [12/13 Regression] ICE in output_constructor_regular_field, at varasm.cc:5515
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106369 --- Comment #4 from Andrew Pinski --- Created attachment 53327 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53327&action=edit reduced testcase Note aminoacid_empty_base is important to hit the bug.
[Bug analyzer/106373] False positives from -Wanalyzer-tainted-array-index on comparison with non-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106373 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:5e830693dd335621940368b6d39b23afc2c98545 commit r13-1768-g5e830693dd335621940368b6d39b23afc2c98545 Author: David Malcolm Date: Wed Jul 20 17:25:35 2022 -0400 analyzer: update "tainted" state of RHS in comparisons [PR106373] Doing so fixes various false positives from -Wanalyzer-tainted-array-index at -O1 and above (e.g. seen on the Linux kernel) gcc/analyzer/ChangeLog: PR analyzer/106373 * sm-taint.cc (taint_state_machine::on_condition): Potentially update the state of the RHS as well as the LHS. gcc/testsuite/ChangeLog: PR analyzer/106373 * gcc.dg/analyzer/torture/taint-read-index-3.c: New test. Signed-off-by: David Malcolm
[Bug fortran/77652] Invalid rank error in ASSOCIATED when rank is remapped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77652
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
Keywords||rejects-valid
--- Comment #4 from anlauf at gcc dot gnu.org ---
The following patch seems to work:
diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 91d87a1b2c1..6365c4ab809 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -1502,8 +1502,17 @@ gfc_check_associated (gfc_expr *pointer, gfc_expr
*target)
t = false;
/* F2018 C838 explicitly allows an assumed-rank variable as the first
argument of intrinsic inquiry functions. */
- if (pointer->rank != -1 && !rank_check (target, 0, pointer->rank))
-t = false;
+ if (pointer->rank != -1 && target->rank != 1 && pointer->rank !=
target->rank)
+{
+ if (gfc_option.warn_std & GFC_STD_F2003)
+ {
+ if (!rank_check (target, 0, pointer->rank))
+ t = false;
+ }
+ else if (!gfc_notify_std (GFC_STD_F2008, "Rank remapping target is not "
+ "rank 1 at %L", &target->where))
+ t = false;
+}
if (target->rank > 0 && target->ref)
{
for (i = 0; i < target->rank; i++)
Needs regtesting.
[Bug c++/106150] [DR 2084] union with more than one variant and non-trivial constructor is not accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106150
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=98423
--- Comment #7 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #3)
> Here is an example which is valid (after
> https://cplusplus.github.io/CWG/issues/2084.html):
> struct S1 {
> S1();
> };
> struct S {
> S();
> };
> union U {
> S s{};
> S1 s1;
> } u;
>
> The check in GCC for this seems to be off, if only the variant s is there,
> GCC (and clang) accepts it.
>
> So the full check for the defect report was never really done (and it was
> not even mentioned in the defect report commentary either).
Yes, all of gcc, clang, edg and msvc reject cases like this.
It should not matter that S1 does not have a trivial default ctor, because the
default member initializer should make this equivalent to:
union U {
S s;
S1 s1;
U() : s() { }
};
Having to write a user-provided constructor is annoying, because to do it
"right" in a generic std::lib template requires:
constexpr U() noexcept(is_nothrow_default_constructible_v) requires
default_initializable { }
But that should be approximately how the defaulted default ctor is defined
automatically, without all that verbosity.
This is a dup of PR 98423, where Jakub pointed out the code that needs to
change, and what needs to happen.
[Bug analyzer/106373] False positives from -Wanalyzer-tainted-array-index on comparison with non-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106373 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed on trunk by the above patch.
[Bug analyzer/106358] [meta-bug] tracker bug for building the Linux kernel with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358 Bug 106358 depends on bug 106373, which changed state. Bug 106373 Summary: False positives from -Wanalyzer-tainted-array-index on comparison with non-const https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106373 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/83782] [10/11 Regression] Inconsistent address for hidden ifunc in a shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83782 --- Comment #11 from H.J. Lu --- The problem is that calling an IFUNC class member function via a member function pointer needs PLT in 32-bit mode since the IFUNC function pointer points to its PLT entry. But we don't want to require PLT for calling via a function pointer.
[Bug c++/98423] The defaulted default constructor defined as deleted when one of variant member has a default member initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98423 Jason Merrill changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-07-20 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED
[Bug c++/96830] GCC does not complain about redeclaration with inconsistent requires clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96830 --- Comment #4 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3b5567c3ec7e5759bdecc6a6fc0be2b65a93636e commit r13-1769-g3b5567c3ec7e5759bdecc6a6fc0be2b65a93636e Author: Jonathan Wakely Date: Wed Jul 20 12:49:28 2022 +0100 libstdc++: Fix minor bugs in std::common_iterator The noexcept-specifier for some std::common_iterator constructors was incorrectly using an rvalue as the first argument of std::is_nothrow_assignable_v. This gave the wrong answer for some types, e.g. std::common_iterator, because an rvalue of scalar type cannot be assigned to. Also fix the friend declaration to use the same constraints as on the definition of the class template. G++ fails to diagnose this error, due to PR c++/96830. Finally, the copy constructor was using std::move for its argument in some cases, which should be removed. libstdc++-v3/ChangeLog: * include/bits/stl_iterator.h (common_iterator): Fix incorrect uses of is_nothrow_assignable_v. Fix inconsistent constraints on friend declaration. Do not move argument in copy constructor. * testsuite/24_iterators/common_iterator/1.cc: Check for noexcept constructibnle/assignable.
[Bug libstdc++/100823] Special member functions of common_iterator should be conditionally trivial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100823 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:56c9998602fd5091ba0985e2e5eaa90c6478 commit r13-1770-g56c9998602fd5091ba0985e2e5eaa90c6478 Author: Jonathan Wakely Date: Wed Jul 20 16:51:44 2022 +0100 libstdc++: Fix std::common_iterator assignment [PR100823] This fixes the following conformance problems reported in the PR: - Move constructor and move assignment should be defined. - Copy assignment from a valueless object should be allowed. Assignment is completely rewritten by this patch, as the previous version had a number of problems. The converting assignment failed to handle the case of assigning a new value to a valueless object, which should work. It only accepted lvalue arguments, so wasn't usable to implement the move assignment operator. Finally, it enforced the precondition that the argument is not valueless, which is correct for the converting assignment but not for the copy assignment. A new _M_assign member is added to handle all cases of assignment (copying from an lvalue, moving from an rvalue, and converting from a different type). The not valueless precondition is checked in the converting assignment before calling _M_assign, so isn't enforced for copy and move assignment. The new function no longer uses a switch, so handles valueless objects as the LHS or RHS of the assignment. libstdc++-v3/ChangeLog: PR libstdc++/100823 * include/bits/stl_iterator.h (common_iterator): Define move constructor and move assignment operator. (common_iterator::_M_assign): New function implementing assignment. (common_iterator::operator=): Use _M_assign. (common_iterator::_S_valueless): New constant. * testsuite/24_iterators/common_iterator/100823.cc: New test.
[Bug libstdc++/100823] Special member functions of common_iterator should be conditionally trivial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100823 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:87a9bfe86d8a87d09de5d60e430d14bfa6c816f0 commit r13-1771-g87a9bfe86d8a87d09de5d60e430d14bfa6c816f0 Author: Jonathan Wakely Date: Wed Jul 20 16:51:44 2022 +0100 libstdc++: Fix std::common_iterator triviality [PR100823] This fixes the remaining problem reported in the PR, that the special members should be trivial. This can be done by constraining the non-trivial versions and adding defaulted overloads that will be used when the union members are trivial. Making these members trivial alters the argument passing ABI and so isn't suitable for backporting to release branches. libstdc++-v3/ChangeLog: PR libstdc++/100823 * include/bits/stl_iterator.h (common_iterator): Define destructor, copy constructor and move constructor as trivial when the underlying types allow. * testsuite/24_iterators/common_iterator/100823.cc: Check triviality of special members.
[Bug libstdc++/100823] Special member functions of common_iterator should be conditionally trivial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100823 --- Comment #3 from Jonathan Wakely --- Fixed on trunk so far. I plan to backport the r13-1770 commit (but not the one changing triviality).
[Bug c++/106202] [11/12/13 Regression] ICE in move_fn_p, at cp/decl.cc:14907 since r12-885-gf71ca97def69b8ae
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106202 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug analyzer/106374] [13 Regression] -fanalyzer ICE with certain const static vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106374 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:a6c192e80a87efbe6c0641f25a963c7bee9990fb commit r13-1773-ga6c192e80a87efbe6c0641f25a963c7bee9990fb Author: David Malcolm Date: Wed Jul 20 21:34:03 2022 -0400 analyzer: fix ICE on untracked decl_regions [PR106374] gcc/analyzer/ChangeLog: PR analyzer/106374 * region.cc (decl_region::get_svalue_for_initializer): Bail out on untracked regions. gcc/testsuite/ChangeLog: PR analyzer/106374 * gcc.dg/analyzer/untracked-2.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/106374] [13 Regression] -fanalyzer ICE with certain const static vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106374 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Fixed on trunk by the above commit.
[Bug analyzer/106358] [meta-bug] tracker bug for building the Linux kernel with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358 Bug 106358 depends on bug 106374, which changed state. Bug 106374 Summary: [13 Regression] -fanalyzer ICE with certain const static vars https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106374 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/106375] New: [13 regreesion] Lowering complex type mov regressed loop distribution for memset/memcpy/memmov.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106375
Bug ID: 106375
Summary: [13 regreesion] Lowering complex type mov regressed
loop distribution for memset/memcpy/memmov.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
void
foo (_Complex double* p, _Complex double* __restrict q)
{
for (int i = 0; i != 1000; i++)
p[i] = q[i];
}
before lowering complex type move
[local count: 10737416]:
__builtin_memcpy (p_10(D), q_9(D), 16000);
return;
After r13-1762-gf9d4c3b45c5ed5f45c8089c990dbd4e181929c3d, it's
18 [local count: 1063004409]:
19 # i_15 = PHI
20 # ivtmp_13 = PHI
21 _1 = (long unsigned int) i_15;
22 _2 = _1 * 16;
23 _3 = q_9(D) + _2;
24 _4 = p_10(D) + _2;
25 _7 = REALPART_EXPR <*_3>;
26 _6 = IMAGPART_EXPR <*_3>;
27 REALPART_EXPR <*_4> = _7;
28 IMAGPART_EXPR <*_4> = _6;
29 i_12 = i_15 + 1;
30 ivtmp_5 = ivtmp_13 - 1;
31 if (ivtmp_5 != 0)
32goto ; [99.00%]
33 else
[Bug tree-optimization/106315] [13 Regression] 7.8% increased codesize on specfp 507.cactuBSSN_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106315 --- Comment #2 from Levy Hsu --- Cheked non-LTO build (-march=native -Ofast -funroll-loops), codesize increasd by 7.1%
[Bug libstdc++/106376] New: The implementation of std::pointer_traits seems wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106376
Bug ID: 106376
Summary: The implementation of std::pointer_traits seems wrong
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
[pointer.traits.types]:
using element_type = see below;
Type: Ptr::element_type if the qualified-id Ptr::element_type is valid
and denotes a type ([temp.deduct]); otherwise, T if Ptr is a class template
instantiation of the form SomePointer, where Args is zero or more type
arguments; otherwise, the specialization is *ill-formed*.
So for the following, the instantiation of pointer_traits will be ill-formed,
and static_assert will cause a hard error, just like libc++ and MSVC-STL do.
libstdc++ specifies element_type as a meaningless type, so the static_assert
still passes.
Although the behavior of libstdc++ is incorrect, but I am not feel good about
this static_assert hard error..
#include
struct I {
using iterator_category = std::contiguous_iterator_tag;
using difference_type = std::ptrdiff_t;
using value_type = int;
value_type& operator*() const;
I& operator++();
I operator++(int);
I& operator--();
I operator--(int);
I& operator+=(difference_type);
I& operator-=(difference_type);
value_type* operator->() const;
value_type& operator[](difference_type) const;
friend I operator+(I, difference_type);
friend I operator+(difference_type, I);
friend I operator-(I, difference_type);
friend difference_type operator-(I, I);
auto operator<=>(const I&) const = default;
};
static_assert(std::contiguous_iterator);
https://godbolt.org/z/sx763oMn6
[Bug libstdc++/106376] The implementation of std::pointer_traits seems wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106376 --- Comment #1 from 康桓瑋 --- oops, this is basically https://cplusplus.github.io/LWG/issue3545, I am waiting for your paper.
[Bug c++/106377] New: A injected-class-name of a private class is not accessible in the member of the derived class.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106377
Bug ID: 106377
Summary: A injected-class-name of a private class is not
accessible in the member of the derived class.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xmh970252187 at gmail dot com
Target Milestone: ---
struct B{};
struct C:private B{
};
struct D:C{
void show(){
struct B b;
}
};
This example is accepted by GCC but Clang rejects it. The injected-class-name
of `B` would be accessible as a private member of `C`, which is not accessible
in the member of `D` as per [class.access.base] p4.
Further, [class.access] says
> Access control is applied uniformly to declarations and expressions.
> The interpretation of a given construct is established without regard to
> access control. If the interpretation established makes use of inaccessible
> members or base classes, the construct is ill-formed.
[Bug rtl-optimization/105041] '-fcompare-debug' failure w/ -mcpu=power6 -O2 -fharden-compares -frename-registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105041 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Surya Kumari Jangala : https://gcc.gnu.org/g:8522fab3f900d6fe0cc43be52fdd850f5c9c44db commit r11-10156-g8522fab3f900d6fe0cc43be52fdd850f5c9c44db Author: Surya Kumari Jangala Date: Fri Jun 10 19:52:57 2022 +0530 regrename: Fix -fcompare-debug issue in check_new_reg_p [PR105041] In check_new_reg_p, the nregs of a du chain is computed by obtaining the MODE of the first element in the chain, and then calling hard_regno_nregs() with the MODE. But the first element of the chain can be a DEBUG_INSN whose mode need not be the same as the rest of the elements in the du chain. This was resulting in fcompare-debug failure as check_new_reg_p was returning a different result with -g for the same candidate register. We can instead obtain nregs from the du chain itself. 2022-06-10 Surya Kumari Jangala gcc/ PR rtl-optimization/105041 * regrename.c (check_new_reg_p): Use nregs value from du chain. gcc/testsuite/ PR rtl-optimization/105041 * gcc.target/powerpc/pr105041.c: New test. (cherry picked from commit 3e16b4359e86b36676ed01219e6deafa95f3c16b)
[Bug tree-optimization/106360] [13 regression] ICE in many test cases after r13-1745-g4c323130257744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106360 --- Comment #1 from prathamesh3492 at gcc dot gnu.org --- Hi, Sorry for the breakage. I will take a look.
[Bug fortran/106367] New: ICE in fold_convert_loc.c when referencing an array-of-structure-eleents from within a polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106367 Bug ID: 106367 Summary: ICE in fold_convert_loc.c when referencing an array-of-structure-eleents from within a polymorphic function Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: federico.perini at gmail dot com Target Milestone: --- Created attachment 53321 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53321&action=edit test program I get an ICE with all gfortran versions from 5 to 12 when having a type-bound procedure that creates an array from some of its structure components. The error does not appear if the same command is called not within a function, or, the when the function argument is not polymorphic. The error (on 11.3.0) points to 31 | array = c%list%indices(c%v(1:)%flag) |1 internal compiler error: in fold_convert_loc, at fold-const.c:2440 This is a minimal program that reproduces the error. It was part of a far more complex structure: ``` module mymod implicit none type vert integer :: flag= 0 ! The fvm node flag (16 exploitable bits) end type vert type contnr type(vert), allocatable :: v(:) integer, allocatable :: list(:) contains procedure :: poly_get_list end type contnr contains ! Polymorphic function causes ICE function poly_get_list(c) result(array) class(contnr), intent(in) :: c integer, allocatable :: array(:) ! ICE internal compiler error: in fold_convert_loc, at fold-const.c:2440 (11.3.0) ! when this is put into a function array = c%list(c%v(1:)%flag) end function poly_get_list ! Non-polymorphic version works function get_list(c) result(array) type(contnr), intent(in) :: c integer, allocatable :: array(:) array = c%list(c%v(1:)%flag) end function get_list end module mymod program arrayOfStruct use mymod implicit none type(contnr) :: c integer :: i allocate(c%v(-1:100),c%list(-1:100)) forall(i=1:100) c%v(i)%flag = i c%list(i) = 100-i+1 end forall ! Direct: works! print "(*(1x,i0))", c%list(c%v(1:)%flag) ! Wrapped with TYPE(contnr): works! print "(*(1x,i0))", get_list(c) ! Wrapped with polymorphic CLASS(contnr): ICE ! Wrapped with TYPE(contnr): works! print "(*(1x,i0))", c%poly_get_list() end program arrayOfStruct ```
[Bug lto/91299] LTO inlines a weak definition in presence of a non-weak definition from an ELF file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91299 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #9 from Alexander Monakov --- I can reproduce it with gcc-10.2. Why is main 'overwritable', but foo is 'available'? cat /tmp/cchaUSjV.ltrans0.o.079i.inline ;; Function main (main, funcdef_no=0, decl_uid=4385, cgraph_uid=1, symbol_order=1) (executed once) weakdef.c:5:5: note: Inlining foo/0 to main/1 with frequency 1.00 foo/0 (foo) @0x7f51a512d168 Type: function definition analyzed Visibility: preempted_reg external public weak References: Referring: Function foo/0 is inline copy in main/1 Availability: available Unit id: 2 Function flags: count:1073741824 (estimated locally) body nonfreeing_fn Called by: main/1 (inlined) (1073741824 (estimated locally),1.00 per call) Calls: main/1 (main) @0x7f51a512d000 Type: function definition analyzed Visibility: externally_visible prevailing_def public References: Referring: Availability: overwritable Unit id: 2 Function flags: count:1073741824 (estimated locally) body only_called_at_startup nonfreeing_fn executed_once Called by: Calls: foo/0 (inlined) (1073741824 (estimated locally),1.00 per call)
