[Bug c++/93589] New: Template instantiation creates a conversion warning when it should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93589 Bug ID: 93589 Summary: Template instantiation creates a conversion warning when it should not Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lokeshjanghel91 at gmail dot com Target Milestone: --- Created attachment 47780 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47780&action=edit Run the attached file with -Wconversion When compiling the attached file, a conversion warning is given if the compiler is GCC. This does not happen with CLANG. $ g++ -Wconversion example.cpp example.cpp: In instantiation of ‘void print_byte_order(T) [with T = short int]’: example.cpp:12:27: required from here example.cpp:7:5: warning: conversion to ‘short int’ from ‘int’ may alter its value [-Wconversion] val |=( 5 * static_cast(i)); ^
[Bug tree-optimization/93588] New: Vectorized load followed by FMA pessimizes on Haswell from version 8.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93588
Bug ID: 93588
Summary: Vectorized load followed by FMA pessimizes on Haswell
from version 8.1
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: alex.reinking at gmail dot com
Target Milestone: ---
Using vector intrinsics (via immintrin.h) on GCC 7.3 with -O3 -march=haswell
performs the following compilation:
---
for (int k = 0; k < n; ++k) {
ymm12 = _mm256_broadcast_sd(&b[k]);
ymm13 = _mm256_broadcast_sd(&b[k + ldb]);
ymm14 = _mm256_broadcast_sd(&b[k + 2 * ldb]);
ymm15 = _mm256_loadu_pd(&a[k * lda]);
ymm0 = _mm256_fmadd_pd(ymm15, ymm12, ymm0);
ymm4 = _mm256_fmadd_pd(ymm15, ymm13, ymm4);
ymm8 = _mm256_fmadd_pd(ymm15, ymm14, ymm8);
ymm15 = _mm256_loadu_pd(&a[4 + k * lda]);
ymm1 = _mm256_fmadd_pd(ymm15, ymm12, ymm1);
ymm5 = _mm256_fmadd_pd(ymm15, ymm13, ymm5);
ymm9 = _mm256_fmadd_pd(ymm15, ymm14, ymm9);
ymm15 = _mm256_loadu_pd(&a[8 + k * lda]);
ymm2 = _mm256_fmadd_pd(ymm15, ymm12, ymm2);
ymm6 = _mm256_fmadd_pd(ymm15, ymm13, ymm6);
ymm10 = _mm256_fmadd_pd(ymm15, ymm14, ymm10);
ymm15 = _mm256_loadu_pd(&a[12 + k * lda]);
ymm3 = _mm256_fmadd_pd(ymm15, ymm12, ymm3);
ymm7 = _mm256_fmadd_pd(ymm15, ymm13, ymm7);
ymm11 = _mm256_fmadd_pd(ymm15, ymm14, ymm11);
}
---
.L3:
lea rax, [r8+rcx]
vbroadcastsdymm2, QWORD PTR [rcx]
vmovupd ymm3, YMMWORD PTR [rsi]
add rcx, 8
vbroadcastsdymm1, QWORD PTR [rax]
vbroadcastsdymm0, QWORD PTR [rax+r8]
vfmadd231pd ymm15, ymm3, ymm2
vfmadd231pd ymm11, ymm3, ymm1
vfmadd231pd ymm7, ymm3, ymm0
vmovupd ymm3, YMMWORD PTR [rsi+32]
vfmadd231pd ymm14, ymm3, ymm2
vfmadd231pd ymm10, ymm3, ymm1
vfmadd231pd ymm6, ymm3, ymm0
vmovupd ymm3, YMMWORD PTR [rsi+64]
vfmadd231pd ymm13, ymm3, ymm2
vfmadd231pd ymm9, ymm3, ymm1
vfmadd231pd ymm5, ymm3, ymm0
vmovupd ymm3, YMMWORD PTR [rsi+96]
add rsi, rdx
vfmadd231pd ymm12, ymm3, ymm2
vfmadd231pd ymm8, ymm3, ymm1
vfmadd231pd ymm4, ymm3, ymm0
cmp rdi, rcx
jne .L3
---
This reuses the registers that are loaded from memory (and in fact uses all 16
ymm registers). However, when compiling with GCC 8.1 or newer, we get:
---
.L3:
vbroadcastsdymm2, QWORD PTR [rcx]
lea rax, [r8+rcx]
add rcx, 8
vbroadcastsdymm1, QWORD PTR [rax]
vbroadcastsdymm0, QWORD PTR [rax+r8]
vfmadd231pd ymm14, ymm2, YMMWORD PTR [rsi]
vfmadd231pd ymm10, ymm1, YMMWORD PTR [rsi]
vfmadd231pd ymm6, ymm0, YMMWORD PTR [rsi]
vfmadd231pd ymm13, ymm2, YMMWORD PTR [rsi+32]
vfmadd231pd ymm9, ymm1, YMMWORD PTR [rsi+32]
vfmadd231pd ymm5, ymm0, YMMWORD PTR [rsi+32]
vfmadd231pd ymm12, ymm2, YMMWORD PTR [rsi+64]
vfmadd231pd ymm8, ymm1, YMMWORD PTR [rsi+64]
vfmadd231pd ymm4, ymm0, YMMWORD PTR [rsi+64]
vfmadd231pd ymm11, ymm2, YMMWORD PTR [rsi+96]
vfmadd231pd ymm7, ymm1, YMMWORD PTR [rsi+96]
vfmadd231pd ymm3, ymm0, YMMWORD PTR [rsi+96]
add rsi, rdx
cmp rdi, rcx
jne .L3
---
This code has half the throughput on both my i9-7900X and NERSC's Xeon E5-2698
v3. Enabling -mtune=skylake "fixes" the problem, but it isn't clear why it does
or how this code could be written to be more robust to compiler changes. The
intrinsics are supposed to map to the corresponding assembly instructions, no?
Here are some Compiler Explorer links to show the behavior:
[GCC 7.3] https://gcc.godbolt.org/z/nLHD47
[GCC 8.1] https://gcc.godbolt.org/z/6EEt2N
[GCC 8.1 -mtune=skylake] https://gcc.godbolt.org/z/XGZKtX
[Bug target/93587] New: [RX] bclr,bnot,bset on byte memory with bit 7 not fused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93587
Bug ID: 93587
Summary: [RX] bclr,bnot,bset on byte memory with bit 7 not
fused
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
The bit manipulation of bit 7 in a byte variable doesn't get fused into a
single instruction.
void bleh_0 (uint8_t* x, uint8_t* y, uint8_t* z)
{
*x ^= 1 << 7;
*y |= 1 << 7;
*z &= ~(1 << 7);
}
compiles to:
mov.B [r1], r14
xor #-128, r14
mov.B r14, [r1]
mov.B [r2], r14
or #-128, r14
mov.B r14, [r2]
mov.B [r3], r14
and #0x7f, r14
mov.B r14, [r3]
rts
while other bit positions like
void bleh_1 (uint8_t* x, uint8_t* y, uint8_t* z)
{
*x ^= 1 << 6;
*y |= 1 << 6;
*z &= ~(1 << 6);
}
compile to:
bnot#6, [r1].B
bset#6, [r2].B
bclr#6, [r3].B
rts
[Bug tree-optimization/93586] [10 Regression] wrong code at -O1 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93586 --- Comment #2 from Qirun Zhang --- (In reply to Andrew Pinski from comment #1) > (In reply to Qirun Zhang from comment #0) > > commit ede31f6ffe73357705e95016046e77c7e3d6ad13 > > Author: Jan Hubicka > > Date: Tue Oct 1 21:46:09 2019 +0200 > > g:ede31f6ffe73357705e95016046e77c7e3d6ad13 Thanks for the tip, Andrew. First report after the git migration
[Bug tree-optimization/93586] [10 Regression] wrong code at -O1 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93586 Andrew Pinski changed: What|Removed |Added Keywords||alias, wrong-code Version|unknown |10.0 Target Milestone|--- |10.0 Summary|wrong code at -O1 on|[10 Regression] wrong code |x86_64-linux-gnu|at -O1 on x86_64-linux-gnu
[Bug tree-optimization/93586] wrong code at -O1 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93586 --- Comment #1 from Andrew Pinski --- (In reply to Qirun Zhang from comment #0) > commit ede31f6ffe73357705e95016046e77c7e3d6ad13 > Author: Jan Hubicka > Date: Tue Oct 1 21:46:09 2019 +0200 g:ede31f6ffe73357705e95016046e77c7e3d6ad13
[Bug c++/93585] Linker resolves variable with extern variable of same name but different type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93585 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Andrew Pinski --- This can be only done with LTO and it is handled already. Oh GCC does not implement the linker. You could report it to the GNU linker.
[Bug tree-optimization/93586] New: wrong code at -O1 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93586
Bug ID: 93586
Summary: wrong code at -O1 on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
Target Milestone: ---
The master branch version of gcc miscompiles the code at -O1 and above.
It seems to be a recent regression. gcc-9 works fine.
Bisection points to:
commit ede31f6ffe73357705e95016046e77c7e3d6ad13
Author: Jan Hubicka
Date: Tue Oct 1 21:46:09 2019 +0200
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200204 (experimental) [master revision
5f0653a8b75:037d7906159:5bc9d2f5ed4c39a7cad74db34e2bb125e012fa60] (GCC)
$ gcc-trunk abc.c && ./a.out
0
$ gcc-9 -O1 abc.c && ./a.out
0
$ gcc-trunk -O1 abc.c && ./a.out
-1
$ cat abc.c
int printf(const char *, ...);
short a;
long b;
int main() {
char c[][10][1] = {7, 0, 5, 5};
for (; b <= 3; b++) {
a = 0;
for (; a >= 0; a--)
if (c[a][b][a])
break;
}
printf("%d\n", a);
}
[Bug c++/93585] New: Linker resolves variable with extern variable of same name but different type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93585
Bug ID: 93585
Summary: Linker resolves variable with extern variable of same
name but different type
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: normvcr at telus dot net
Target Milestone: ---
Here are two source files which compile and link without error, but which break
type expectations and not what the programmer would want. The type of "foo" is
different in the two files:
a.cpp:
//
double foo = 2.1;
b.cpp
//
#include
using namespace std;
extern int foo;
int main( int argc, char* argv[] )
{
cout << "foo= " << foo << endl;
return 0;
}
On Windows 10, the visual studio cl.exe complains at link time.
[Bug c++/92003] [8/9/10 Regression] constexpr-ness of char const* doesn't propagate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92003 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug libfortran/93567] G edit descriptor uses E instead of F editing in rounding mode UP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93567 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- hmm, I will have to take a closer look at this one.
[Bug target/91102] [9 Regression] aarch64 ICE on Linux kernel with -Os starting with r270266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91102 Taras Kondratiuk changed: What|Removed |Added CC||kondratyuk.taras at gmail dot com --- Comment #10 from Taras Kondratiuk --- Looks like this fix missed 9.2. Can it be added to 9.3? It doesn't seem to be present in the gcc-9 branch.
[Bug middle-end/84275] missing warning on conflicting alloc_size attributes on different declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84275 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-05 Summary|missing warning on |missing warning on |conflicting attributes on |conflicting alloc_size |different declarations |attributes on different ||declarations Ever confirmed|0 |1 Known to fail||10.0, 8.2.0, 9.2.0 --- Comment #1 from Martin Sebor --- No progress in GCC 10.0.
[Bug analyzer/93543] [10 regression] bootstrap with clang fails in analyzer: reinterpret_cast from 'nullptr_t' to 'function *' is not allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93543 --- Comment #7 from Gerald Pfeifer --- Thank you - and I just received confirmation that also the new patch addresses the original issue coming from a FreeBSD user with clang 9.0.1.
[Bug libstdc++/93584] New: std::string::find_first_not_of is about 9X slower than strspn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93584 Bug ID: 93584 Summary: std::string::find_first_not_of is about 9X slower than strspn Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rafael at espindo dot la Target Milestone: --- Created attachment 47779 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47779&action=edit testcase In the attached test program the benchmark function takes 0.26837 seconds if calling std::string::find_first_not_of and 0.0291547 seconds if calling strspn.
[Bug target/87213] ICE in final_scan_insn_1, at final.c:3070
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87213 --- Comment #2 from Segher Boessenkool --- I don't know how I reproduced this before, but I cannot any more.
[Bug c++/92413] [temp.explicit] Explicit template instantiations should not define member functions that are not defined at the point of instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92413
--- Comment #3 from David Blaikie ---
Ah, miswrote the example, here:
template struct C {void foo();};
template struct C;
template void C::foo() {
static_assert(sizeof(T) == 1);
}
Here's a godbolt comparing Clang trunk and GCC trunk:
https://godbolt.org/z/6jP_QM
[Bug fortran/93579] [9/10 Regression] ICE in gfc_conv_substring_expr, at fortran/trans-expr.c:8587
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93579 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-04 CC||kargl at gcc dot gnu.org Depends on||93580 Ever confirmed|0 |1 --- Comment #2 from kargl at gcc dot gnu.org --- Fixed by patch in pr93580. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93580 [Bug 93580] [9/10 Regression] ICE in gfc_validate_kind(): Got bad kind
[Bug rtl-optimization/93565] Combine duplicates count trailing zero instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565 --- Comment #2 from Segher Boessenkool --- Of course it first tried to do Failed to match this instruction: (parallel [ (set (reg:DI 101 [ _9 ]) (ctz:DI (reg/v:DI 98 [ x ]))) (set (reg:DI 100) (ctz:DI (reg/v:DI 98 [ x ]))) ]) so we could try to do that as just the ctz and then a register move, and hope that move can be optimised away. But this is more expensive if it can *not* be optimised (higher latency). Hrm.
[Bug rtl-optimization/93565] Combine duplicates count trailing zero instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #1 from Segher Boessenkool ---
Well, on power9 I get just
cmpdi 0,3,0
beq 0,.L2
cnttzd 3,3
sldi 9,3,2
lwzx 9,4,9
or 3,9,3
stw 3,0(4)
.L2:
li 3,0
blr
so it is more than just CTZ_DEFINED_VALUE_AT_ZERO = 2 .
(Also on power7, power8, but those don't have that neat ctz insn).
On aarch64, combine starts with
insn_cost 4 for43: r106:DI=x0:DI
REG_DEAD x0:DI
insn_cost 4 for 2: r98:DI=r106:DI
REG_DEAD r106:DI
insn_cost 4 for44: r107:DI=x1:DI
REG_DEAD x1:DI
insn_cost 4 for 3: r99:DI=r107:DI
REG_DEAD r107:DI
insn_cost 4 for 7: cc:CC=cmp(r98:DI,0)
insn_cost 4 for 8: pc={(cc:CC==0)?L17:pc}
REG_DEAD cc:CC
REG_BR_PROB 536870916
insn_cost 4 for10: r100:DI=ctz(r98:DI)
REG_DEAD r98:DI
insn_cost 4 for12: r101:DI=sign_extend(r100:DI#0)
insn_cost 16 for14: r104:SI=[r101:DI*0x4+r99:DI]
REG_DEAD r101:DI
insn_cost 4 for15: r103:SI=r104:SI|r100:DI#0
REG_DEAD r104:SI
REG_DEAD r100:DI
insn_cost 4 for16: [r99:DI]=r103:SI
REG_DEAD r103:SI
REG_DEAD r99:DI
insn_cost 4 for23: x0:DI=0
insn_cost 0 for24: use x0:DI
r100 (set in 10) is used later, just like r101 (set in 12).
Trying 10 -> 12:
10: r100:DI=ctz(r98:DI)
REG_DEAD r98:DI
12: r101:DI=sign_extend(r100:DI#0)
Successfully matched this instruction:
(set (reg:DI 100)
(ctz:DI (reg/v:DI 98 [ x ])))
Successfully matched this instruction:
(set (reg:DI 101 [ _9 ])
(ctz:DI (reg/v:DI 98 [ x ])))
allowing combination of insns 10 and 12
original costs 4 + 4 = 8
replacement costs 4 + 4 = 8
So, it is *not* duplicating the ctz: the duplicate was already there to start
with, in some sense.
[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #11 from Martin Sebor ---
-mtune=z13 seems to enable more inlining so many of the past-the-end references
to the tempGrab local variable end up inlined into the bodies of the functions
that define them.
For example:
PassivGrab.c: In function 'UngrabKeyOrButton':
PassivGrab.c:8738:56: warning: array subscript 0 is outside array bounds of
'XtServerGrabRec[1]' {aka 'struct _XtServerGrabRec[1]'} [-Warray-bounds]
8738 | second.pMask =
((XtServerGrabExtPtr)((pSecondGrab)+1))->pModifiersMask;
| ~~~^~~~
PassivGrab.c:9144:21: note: while referencing 'tempGrab'
9144 | XtServerGrabRec tempGrab;
| ^~~~
In the VRP dump for UngrabKeyOrButton we see:
...
struct XtServerGrabRec tempGrab;
followed by:
...
[local count: 653983619]:
_172 = MEM[(struct _XtGrabExtRec *)&tempGrab + 24B].pModifiersMask;
if (_172 == 0B)
sizeof (struct XtServerGrabRec) == 24, so the read of the memory at (struct
_XtGrabExtRec *)&tempGrab + 24B is out-of-bounds.
I think the code relies on the tempGrab.hasExt member being zero to avoid
actually performing the out-of-bounds access so it's safe, but GCC doesn't
connect the relationship between the test and the member so it emits the access
and the warning.
The warning can be avoided by replacing the instances of the local tempGrab
declarations with two-element arrays, like so:
struct XtServerGrabRec tempGrab[2];
and accesses to its members such as tempGrab.widget with
tempGrab->widget = widget;
[Bug c++/92593] [10 Regression] ICE with CTAD using undeclared constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92593 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 93551, which changed state. Bug 93551 Summary: [10 Regression] Call from templated function to constrained constructor segfaults when attempting to narrow to bool https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93551 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/93551] [10 Regression] Call from templated function to constrained constructor segfaults when attempting to narrow to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93551 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jason Merrill --- Fixed.
[Bug c++/93551] [10 Regression] Call from templated function to constrained constructor segfaults when attempting to narrow to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93551 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:85409531ff032a008ebfbb715344648f15492dac commit r10-6438-g85409531ff032a008ebfbb715344648f15492dac Author: Jason Merrill Date: Tue Feb 4 17:18:35 2020 -0500 c++: Fix error-recovery with concepts. Here, push_tinst_level refused to push into the scope of Foo::Foo because it was triggered from the ill-formed function fun. But we didn't check the return value and tried to pop the un-pushed level. PR c++/93551 * constraint.cc (satisfy_declaration_constraints): Check return value of push_tinst_level.
[Bug c++/67727] [concepts] parameterized constraint not being checked for unused variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67727 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Jason Merrill --- Fixed for GCC10.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 67727, which changed state. Bug 67727 Summary: [concepts] parameterized constraint not being checked for unused variables https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67727 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/67720] [concepts] bug with recursive constrained function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67720 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #2 from Jason Merrill --- Fixed for GCC 10.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 67720, which changed state. Bug 67720 Summary: [concepts] bug with recursive constrained function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67720 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 67719, which changed state. Bug 67719 Summary: [concepts] bug with concepts using logical or https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67719 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/67719] [concepts] bug with concepts using logical or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67719 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #2 from Jason Merrill --- Fixed for GCC 10.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 67704, which changed state. Bug 67704 Summary: [concepts] requirements not being applied to aliases https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67704 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/67704] [concepts] requirements not being applied to aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67704 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #5 from Jason Merrill --- Fixed for GCC 10 (in r278785).
[Bug c++/67697] [concepts] ICE when using non-constexpr in requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67697 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Jason Merrill --- Fixed for GCC 10.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 67697, which changed state. Bug 67697 Summary: [concepts] ICE when using non-constexpr in requires expression https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67697 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 67686, which changed state. Bug 67686 Summary: [concepts] segfault in finish_call_expr function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67686 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/67686] [concepts] segfault in finish_call_expr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67686 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Jason Merrill --- Fixed for GCC 10.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 67684, which changed state. Bug 67684 Summary: [concepts] friend access not working with constrained function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67684 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/67684] [concepts] friend access not working with constrained function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67684 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Jason Merrill --- So, fixed for GCC 10.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 67658, which changed state. Bug 67658 Summary: [concepts] invalid code with constrained concepts compiles https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67658 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/67658] [concepts] invalid code with constrained concepts compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67658 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #4 from Jason Merrill --- Fixed for GCC 10.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 67654, which changed state. Bug 67654 Summary: [concepts] ICE when using concepts in constexpr function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67654 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/67654] [concepts] ICE when using concepts in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67654 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Jason Merrill --- So, fixed for GCC 10.
[Bug c++/67545] [concepts] Failure to properly substitute template parameters into requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67545 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Jason Merrill --- Fixed in GCC 10.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 67545, which changed state. Bug 67545 Summary: [concepts] Failure to properly substitute template parameters into requires-clause https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67545 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/67319] Short-hand concepts for variadic member functions broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67319 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Jason Merrill --- So, fixed in GCC 10.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 67319, which changed state. Bug 67319 Summary: Short-hand concepts for variadic member functions broken https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67319 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/67070] [concepts] Concept with negation and disjunction not checked correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67070 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #12 from Jason Merrill --- (In reply to Andrew Sutton from comment #11) > The concepts-cxx2a branch implements the new semantics. And so fixed for GCC 10.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 67070, which changed state. Bug 67070 Summary: [concepts] Concept with negation and disjunction not checked correctly https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67070 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/66844] [c++-concepts] Requires-expression parameter with void type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66844 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #5 from Jason Merrill --- Fixed for GCC 10.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 66844, which changed state. Bug 66844 Summary: [c++-concepts] Requires-expression parameter with void type https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66844 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/90951] [8/9/10 Regression] error initializing a constexpr array of a struct with const member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90951
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:0712ea6313bc44f9ae8feb235c1b02c92cdd0527
commit r10-6437-g0712ea6313bc44f9ae8feb235c1b02c92cdd0527
Author: Jason Merrill
Date: Tue Feb 4 15:54:17 2020 -0500
c++: Fix constexpr vs. omitted aggregate init.
Value-initialization is importantly different from {}-initialization for
this testcase, where the former calls the deleted S constructor and the
latter initializes S happily.
PR c++/90951
* constexpr.c (cxx_eval_array_reference): {}-initialize missing
elements instead of value-initializing them.
[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582 --- Comment #10 from Marek Polacek --- Cross-compiled s390x-redhat-linux gcc shows that the warning appears with -mtune=z13, but not without it (using -O2).
[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582 --- Comment #9 from Marek Polacek --- Created attachment 47778 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47778&action=edit original .i file Attaching the original .i file
[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582 --- Comment #8 from Martin Sebor --- We would need to see the original code (the translation unit) to tell for sure why the warning is only issued on some targets and not on others, but the most likely answer is that the code results in different internal representation, and GCC can reliably detect problems only in some and not in others. I don't think this type of -Warray-bounds warning (the one for direct array accesses as opposed to the one for library functions) detects out-of-bounds accesses in dynamically allocated memory yet so I wouldn't expect to see it for the snippet you showed in comment #5, regardless of what the access looks like. The warning still only detects such accesses to declared objects but those don't make it possible to initialize trailing arrays with more than the declared number of elements. The only kind of a trailing array that can be initialized to more elements than its bound suggests in a declared object is a C99 flexible array member (as a GCC extension). Neither zero-length arrays nor arrays of length 1 can be initialized with excess elements. Of those, only zero-length arrays are supported as "flexible array members." Treating trailing arrays of length 1 the same is discouraged. See https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html for details.
[Bug rtl-optimization/91333] [9/10 Regression] suboptimal register allocation for inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91333 --- Comment #16 from Vladimir Makarov --- (In reply to rsand...@gcc.gnu.org from comment #15) > (In reply to Jakub Jelinek from comment #14) > > I think what matters is whether the new asm for those is the same or better > > than before. If the tests hardcode particular RA decisions, they'll > > obviously FAIL when something in the RA changes. > > The kind of change is from: > > mov z2.d, x0 > movprfx z0, z1 > uabdz0.d, p0/m, z0.d, z2.d > ret > > to: > > mov z0.d, x0 > mov z2.d, z0.d > movprfx z0, z1 > uabdz0.d, p0/m, z0.d, z2.d > ret > > so this is a genuine regression. Hi, Richard. Could you write me what options and test (I guess it is pr91333.c) you used.
[Bug target/93270] [8/9/10 Regression] DSE removes store incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93270 --- Comment #6 from Jeffrey A. Law --- I can live with that :-)
[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582 --- Comment #7 from Adam Jackson --- (In reply to Marek Polacek from comment #6) > Well, zero-length arrays are a GNU C extension, but pre-C99 you could use > pixels[1] and post-C99 you can use pixels[]. Is non of that an option? The code could be changed, sure. We hit this _only_ on s390x when rebuilding libXt. If the code is invalid then why the inconsistency?
[Bug c/93577] [8/9/10 Regression] internal compiler error: tree check: expected integer_cst, have non_lvalue_expr in get_len, at tree.h:5902
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93577 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-04 CC||jakub at gcc dot gnu.org Target Milestone|--- |8.4 Summary|internal compiler error:|[8/9/10 Regression] |tree check: expected|internal compiler error: |integer_cst, have |tree check: expected |non_lvalue_expr in get_len, |integer_cst, have |at tree.h:5902 |non_lvalue_expr in get_len, ||at tree.h:5902 Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Started most likely with r0-92186-g928c19bbb001967c7ab83a9f856c740680b6661f
[Bug fortran/93580] [9/10 Regression] ICE in gfc_validate_kind(): Got bad kind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93580
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-02-04
CC||kargl at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from kargl at gcc dot gnu.org ---
Patch against svn r280157.
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c (revision 280157)
+++ gcc/fortran/primary.c (working copy)
@@ -2241,6 +2241,15 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag,
if (inquiry)
sym = NULL;
+ if (sep == '%'
+ && tmp && (tmp->u.i == INQUIRY_RE || tmp->u.i == INQUIRY_IM)
+ && primary->ts.type != BT_COMPLEX)
+ {
+ gfc_error ("The RE or IM part_ref at %C must be "
+"applied to a COMPLEX expression");
+ return MATCH_ERROR;
+ }
+
if (sep == '%' && primary->ts.type != BT_UNKNOWN)
intrinsic = true;
}
[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #6 from Marek Polacek ---
(In reply to Adam Jackson from comment #5)
> (In reply to Martin Sebor from comment #4)
> > It seems like the reporter might be conflating the forming of a past-the-end
> > pointer (what the GRABEXT macro does) with dereferencing that pointer (the
> > use of the -> operator with the result).
>
> I'm not conflating it, I'm pretty sure the whole point of computing that
> address
> is to dereference it because that's where the data I want is. The caller is
> doing somemthing of the form:
>
> struct image {
> int w, h, bpp;
> // unsigned char pixels[];
> };
>
> struct image *i = malloc(sizeof(*i) + w * h * bpp);
>
> This is not uncommon in code older than zero-length arrays.
Well, zero-length arrays are a GNU C extension, but pre-C99 you could use
pixels[1] and post-C99 you can use pixels[]. Is non of that an option?
[Bug c++/93551] [10 Regression] Call from templated function to constrained constructor segfaults when attempting to narrow to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93551 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
Adam Jackson changed:
What|Removed |Added
CC||ajax at redhat dot com
--- Comment #5 from Adam Jackson ---
(In reply to Martin Sebor from comment #4)
> It seems like the reporter might be conflating the forming of a past-the-end
> pointer (what the GRABEXT macro does) with dereferencing that pointer (the
> use of the -> operator with the result).
I'm not conflating it, I'm pretty sure the whole point of computing that
address
is to dereference it because that's where the data I want is. The caller is
doing somemthing of the form:
struct image {
int w, h, bpp;
// unsigned char pixels[];
};
struct image *i = malloc(sizeof(*i) + w * h * bpp);
This is not uncommon in code older than zero-length arrays.
[Bug c/93577] internal compiler error: tree check: expected integer_cst, have non_lvalue_expr in get_len, at tree.h:5902
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93577
--- Comment #1 from Yongheng Chen ---
Stack dump:
---
tt.c: In function ‘main’:
tt.c:2:48: warning: implicit declaration of function ‘f’
[-Wimplicit-function-declaration]
2 | struct s { int x [ 16 == ( ( ( sizeof ( ( 3 , f ( ) > 1000 < 5000 < 2
) ) / 2 ) != x > ( 6 / 3 / 2 ) ) ) ] ;
|^
tt.c:2:90: warning: comparison between pointer and integer
2 | struct s { int x [ 16 == ( ( ( sizeof ( ( 3 , f ( ) > 1000 < 5000 < 2
) ) / 2 ) != x > ( 6 / 3 / 2 ) ) ) ] ;
|
^
tt.c:14:3: error: variable-sized object may not be initialized
14 | } g_207 = { 1 , 2 , 3 } ;
| ^
tt.c:14:15: warning: excess elements in array initializer
14 | } g_207 = { 1 , 2 , 3 } ;
| ^
tt.c:14:15: note: (near initialization for ‘g_207.x’)
tt.c:14:3: internal compiler error: tree check: expected integer_cst, have
non_lvalue_expr in get_len, at tree.h:5902
14 | } g_207 = { 1 , 2 , 3 } ;
| ^
0x760c33 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9685
0x82393a tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3534
0x82393a wi::extended_tree<192>::get_len() const
../../gcc/tree.h:5902
0x82393a wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int >
const&)
../../gcc/wide-int.h:985
0x82393a wide_int_ref_storage::wide_int_ref_storage >
>(generic_wide_int > const&, unsigned int)
../../gcc/wide-int.h:1034
0x82393a generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
../../gcc/wide-int.h:790
0x82393a bool wi::lts_p >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../gcc/wide-int.h:1901
0x836cb2 wi::binary_traits >,
generic_wide_int >,
wi::int_traits > >::precision_type,
wi::int_traits >
>::precision_type>::signed_predicate_result operator<
>,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int<$i::extended_tree<192> > const&)
../../gcc/wide-int.h:3248
0x836cb2 tree_int_cst_lt(tree_node const*, tree_node const*)
../../gcc/tree.h:6058
0x836cb2 find_init_member
../../gcc/c/c-typeck.c:9434
0x836dde push_init_level(unsigned int, int, obstack*)
../../gcc/c/c-typeck.c:8433
0x8444d7 process_init_element(unsigned int, c_expr, bool, obstack*)
../../gcc/c/c-typeck.c:10200
0x86614f c_parser_initval
../../gcc/c/c-parser.c:5533
0x866410 c_parser_initelt
../../gcc/c/c-parser.c:5505
0x866410 c_parser_braced_init
../../gcc/c/c-parser.c:5273
0x8674b3 c_parser_initializer
../../gcc/c/c-parser.c:5221
0x879bf3 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2249
0x85cec7 c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5713
0x879348 c_parser_compound_statement
../../gcc/c/c-parser.c:5616
0x87adcb c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2504
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/93574] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:2925
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93574
--- Comment #1 from Yongheng Chen ---
Stack dump:
---
tt.c:1:26: error: variable or field ‘y’ declared void
1 | struct s { struct { void y ;
| ^
tt.c: In function ‘main’:
tt.c:7:23: warning: implicit declaration of function ‘sum’
[-Wimplicit-function-declaration]
7 | x = ( ( 6 / ( ( 0 * sum ( 3 , 4 ) + ( 1 , 2 ) ) / 114 / 2 ) / 2
) ) > 0 & ( x == sizeof ( ( int * ( * ( int f ( struct list ) ) ) [ * *
main ] ) 1 ) ) ;
| ^~~
tt.c:7:128: warning: ‘struct list’ declared inside parameter list will not be
visible outside of this definition or declaration
7 | x = ( ( 6 / ( ( 0 * sum ( 3 , 4 ) + ( 1 , 2 ) ) / 114 / 2 ) / 2
) ) > 0 & ( x == sizeof ( ( int * ( * ( int f ( struct list ) ) ) [ * *
main ] ) 1 ) ) ;
|
^~~~
tt.c:7:128: error: size of unnamed array has non-integer type
tt.c:7:99: error: cast specifies function type
7 | x = ( ( 6 / ( ( 0 * sum ( 3 , 4 ) + ( 1 , 2 ) ) / 114 / 2 ) / 2
) ) > 0 & ( x == sizeof ( ( int * ( * ( int f ( struct list ) ) ) [ * *
main ] ) 1 ) ) ;
|
^
tt.c:7:128: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:2925
7 | x = ( ( 6 / ( ( 0 * sum ( 3 , 4 ) + ( 1 , 2 ) ) / 114 / 2 ) / 2
) ) > 0 & ( x == sizeof ( ( int * ( * ( int f ( struct list ) ) ) [ * *
main ] ) 1 ) ) ;
|
^~~~
0x7610ae tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.c:9735
0x625ebb tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/tree.h:3401
0x625ebb c_expr_sizeof_expr(unsigned int, c_expr)
../../gcc/c/c-typeck.c:2925
0x862167 c_parser_sizeof_expression
../../gcc/c/c-parser.c:8341
0x862167 c_parser_unary_expression
../../gcc/c/c-parser.c:8238
0x862dad c_parser_cast_expression
../../gcc/c/c-parser.c:8108
0x8631b1 c_parser_binary_expression
../../gcc/c/c-parser.c:8034
0x864025 c_parser_conditional_expression
../../gcc/c/c-parser.c:7645
0x864640 c_parser_expr_no_commas
../../gcc/c/c-parser.c:7562
0x8648a1 c_parser_expression
../../gcc/c/c-parser.c:10630
0x85d495 c_parser_postfix_expression
../../gcc/c/c-parser.c:9121
0x86155a c_parser_unary_expression
../../gcc/c/c-parser.c:8266
0x862dad c_parser_cast_expression
../../gcc/c/c-parser.c:8108
0x8631b1 c_parser_binary_expression
../../gcc/c/c-parser.c:8034
0x864025 c_parser_conditional_expression
../../gcc/c/c-parser.c:7645
0x864640 c_parser_expr_no_commas
../../gcc/c/c-parser.c:7562
0x8646ea c_parser_expr_no_commas
../../gcc/c/c-parser.c:7604
0x8648a1 c_parser_expression
../../gcc/c/c-parser.c:10630
0x865047 c_parser_expression_conv
../../gcc/c/c-parser.c:10663
0x85a90b c_parser_statement_after_labels
../../gcc/c/c-parser.c:6294
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/93573] internal compiler error: in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93573
--- Comment #1 from Yongheng Chen ---
Stack dump:
---
tt.c:1:5: error: ‘f1’ declared as function returning a function
1 | int f1 ( char * p ) ( ) { int x ;
| ^~
tt.c: In function ‘f1’:
tt.c:4:9: warning: implicit declaration of function ‘sum’
[-Wimplicit-function-declaration]
4 | if ( ( sum ( 1 , 2 ) / 2 ) != 1 ) return 1 ;
| ^~~
tt.c:5:60: error: size of array ‘X’ has non-integer type
5 | if ( - ( 2 * sum ( 3 , 4 ) + sum ( ( union foo { int i , X [ 2 ] [ -
( 100.00 / 2 ) * 2 ] , k ;
|^
tt.c:7:34: error: field ‘f1’ declared as a function
7 |float ( * f1 ( int a , int b ) ) ( int c , int
b ) ;
| ^~
tt.c:5:32: internal compiler error: in force_constant_size, at gimplify.c:733
5 | if ( - ( 2 * sum ( 3 , 4 ) + sum ( ( union foo { int i , X [ 2 ] [ -
( 100.00 / 2 ) * 2 ] , k ;
|
^
6 | char * p ;
| ~~
7 |float ( * f1 ( int a , int b ) ) ( int c , int
b ) ;
|
~~~
8 | } ) p , 2 ) ) != 0 - 4 ) return 1 ;
| ~
0x69d4dc force_constant_size
../../gcc/gimplify.c:733
0xb1b637 gimple_add_tmp_var(tree_node*)
../../gcc/gimplify.c:771
0xae9287 create_tmp_var(tree_node*, char const*)
../../gcc/gimple-expr.c:485
0xb2d5df create_tmp_from_val
../../gcc/gimplify.c:561
0xb2d5df lookup_tmp_var
../../gcc/gimplify.c:582
0xb2d5df internal_get_tmp_var
../../gcc/gimplify.c:635
0xb26ccf get_formal_tmp_var(tree_node*, gimple**)
../../gcc/gimplify.c:663
0xb26ccf gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14582
0xb287c6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14030
0xb314b4 gimplify_expr
../../gcc/gimplify.c:14628
0xb5 gimplify_call_expr
../../gcc/gimplify.c:3497
0xb28467 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13553
0xb27790 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14350
0xb27757 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14348
0xb3cdbb gimplify_cond_expr
../../gcc/gimplify.c:4177
0xb27ece gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13538
0xb2af96 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6822
0xb2885b gimplify_statement_list
../../gcc/gimplify.c:1869
0xb2885b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14025
0xb2af96 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6822
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/93572] internal compiler error: q from h referenced in main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93572
--- Comment #1 from Yongheng Chen ---
Stack dump:
---
tt.c:3:4: error: expected ‘;’, identifier or ‘(’ before ‘short’
3 | } short main ( ) { int x ;
|^
tt.c: In function ‘h’:
tt.c:5:14: warning: comparison between pointer and integer
5 | int v [ & q != 2 ] ;
| ^~
tt.c:6:2: error: expected declaration specifiers before numeric constant
6 | 2 * ( 3 + 4 ) ;
| ^
tt.c:7:2: error: expected declaration specifiers before ‘x’
7 | x = x & ( 6 / ( 6 / 114 / 2 ) / 2 ) ;
| ^
tt.c:8:2: error: expected declaration specifiers before ‘return’
8 | return x - 1 ;
| ^~
tt.c:9:2: error: expected declaration specifiers before ‘}’ token
9 | }
| ^
tt.c:4:6: warning: type of ‘x’ defaults to ‘int’ [-Wimplicit-int]
4 | int h ( x , y ) char arr [ ( 1 , 2 ) - ( ( 1 , 2 ) / 2 ) * 2 ] [
sizeof 0 ] , ( * p ) [ ] , * q ;
| ^
tt.c:4:6: warning: type of ‘y’ defaults to ‘int’ [-Wimplicit-int]
tt.c:5:6: error: declaration for parameter ‘v’ but no such parameter
5 | int v [ & q != 2 ] ;
| ^
tt.c:4:96: error: declaration for parameter ‘q’ but no such parameter
4 | int h ( x , y ) char arr [ ( 1 , 2 ) - ( ( 1 , 2 ) / 2 ) * 2 ] [
sizeof 0 ] , ( * p ) [ ] , * q ;
|
^
tt.c:4:84: error: declaration for parameter ‘p’ but no such parameter
4 | int h ( x , y ) char arr [ ( 1 , 2 ) - ( ( 1 , 2 ) / 2 ) * 2 ] [
sizeof 0 ] , ( * p ) [ ] , * q ;
|
^
tt.c:4:23: error: declaration for parameter ‘arr’ but no such parameter
4 | int h ( x , y ) char arr [ ( 1 , 2 ) - ( ( 1 , 2 ) / 2 ) * 2 ] [
sizeof 0 ] , ( * p ) [ ] , * q ;
| ^~~
tt.c:9: error: expected ‘{’ at end of input
9 | }
|
tt.c: In function ‘main’:
tt.c:9:2: error: expected declaration or statement at end of input
9 | }
| ^
tt.c:3:10: internal compiler error: q from h referenced in main
3 | } short main ( ) { int x ;
| ^~~~
0xe74559 convert_nonlocal_reference_op
../../gcc/tree-nested.c:1063
0x108af7a walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void
*, hash_set >*))
../../gcc/tree.c:11954
0xe742ed convert_nonlocal_reference_op
../../gcc/tree-nested.c:1105
0x108af7a walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void
*, hash_set >*))
../../gcc/tree.c:11954
0xb11f20 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:202
0xb1230c walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0xb124a0 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xb12391 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:686
0xb124a0 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xe6fc94 walk_body
../../gcc/tree-nested.c:713
0xe6fc94 walk_function
../../gcc/tree-nested.c:724
0xe6fc94 walk_all_functions
../../gcc/tree-nested.c:789
0xe76008 lower_nested_functions(tree_node*)
../../gcc/tree-nested.c:3528
0x98c4dc cgraph_node::analyze()
../../gcc/cgraphunit.c:675
0x98f19f analyze_functions
../../gcc/cgraphunit.c:1210
0x98fd62 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2956
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug middle-end/93576] [10 Regression] internal compiler error: Segmentation fault (in gimplify.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93576 --- Comment #6 from Yongheng Chen --- I see. I will do it for future bugs.
[Bug middle-end/93576] [10 Regression] internal compiler error: Segmentation fault (in gimplify.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93576 --- Comment #5 from Martin Sebor --- The full compiler output is useful. Some of us use it to quickly see what part of the compiler is affected. It also helps make sure we're reproducing the same problem.
[Bug libstdc++/79193] libstdc++ configure incorrectly decides linking works for cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79193 --- Comment #5 from sandra at gcc dot gnu.org --- *** Bug 88999 has been marked as a duplicate of this bug. ***
[Bug middle-end/93576] [10 Regression] internal compiler error: Segmentation fault (in gimplify.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93576 --- Comment #4 from Andrew Pinski --- (In reply to Yongheng Chen from comment #3) > It seems I overwrote Andrew Pinski's comment by mistake. Sorry about that LOL I did not have any comment changes, only the addition of the error-recovery keyword which is still there.
[Bug libstdc++/88999] [9/10 Regression] testcases using in_avail() fail on nios2-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88999 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from sandra at gcc dot gnu.org --- Yes, confirmed: this is a misconfiguration error, same as PR 79193. *** This bug has been marked as a duplicate of bug 79193 ***
[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Martin Sebor --- It seems like the reporter might be conflating the forming of a past-the-end pointer (what the GRABEXT macro does) with dereferencing that pointer (the use of the -> operator with the result). This would be valid: void *p = GRABEXT (&e); The test case in comment #0 is not because it accesses the object at that address (past the end of e).
[Bug c++/93425] [9/10 Regression] Template parameter deduction failure when template parameters have template template parameter since r9-3807-g5d9a0e3b99e31a21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93425 Marek Polacek changed: What|Removed |Added Priority|P3 |P2
[Bug c++/91793] [8/9/10 Regression] ICE on unexpanded parameter pack in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91793 Marek Polacek changed: What|Removed |Added Priority|P3 |P2 CC||mpolacek at gcc dot gnu.org
[Bug c++/92003] [8/9/10 Regression] constexpr-ness of char const* doesn't propagate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92003 Marek Polacek changed: What|Removed |Added Priority|P3 |P2
[Bug c++/93559] [10 Regression] ICE: side-effects element in no-side-effects CONSTRUCTOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93559 Marek Polacek changed: What|Removed |Added Priority|P3 |P1
[Bug c++/93549] [10 Regression] ICE / Segfault in constexpr expansion involving vector_size(16) short COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93549 Marek Polacek changed: What|Removed |Added Priority|P3 |P1
[Bug c++/93551] [10 Regression] Call from templated function to constrained constructor segfaults when attempting to narrow to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93551 Marek Polacek changed: What|Removed |Added Priority|P3 |P1 CC||mpolacek at gcc dot gnu.org
[Bug c++/90951] [8/9/10 Regression] error initializing a constexpr array of a struct with const member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90951 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/90966] [9/10 Regression] ICE in tsubst_copy, at cp/pt.c:16155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90966 Jason Merrill changed: What|Removed |Added CC||haoranni at terpmail dot umd.edu --- Comment #6 from Jason Merrill --- *** Bug 92625 has been marked as a duplicate of this bug. ***
[Bug c++/92625] [8/9/10 Regression] Internal compiler error accessing element in static constexpr char array in template class using alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92625 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jason Merrill --- Fixed by the patch for 90966. *** This bug has been marked as a duplicate of bug 90966 ***
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 92625, which changed state. Bug 92625 Summary: [8/9/10 Regression] Internal compiler error accessing element in static constexpr char array in template class using alias https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92625 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582 --- Comment #3 from Marek Polacek --- This is about us not accepting the code anymore, I think it's what libXt relies on. Quoting Adam J.: "Where GRABEXT here is just doing the standard C trick for incrementing past the current struct and returning a (differently typed) pointer to the data beyond: #define GRABEXT(p) ((XtServerGrabExtPtr)((p)+1))" I'm not sure if we want to break this though the code certainly look dubious. clang currently accepts it.
[Bug middle-end/93576] [10 Regression] internal compiler error: Segmentation fault (in gimplify.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93576 --- Comment #3 from Yongheng Chen --- It seems I overwrote Andrew Pinski's comment by mistake. Sorry about that LOL
[Bug c++/92625] [8/9/10 Regression] Internal compiler error accessing element in static constexpr char array in template class using alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92625 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/93442] [8/9 Regression] lambda in if constexpr fails to compile since r8-5529
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93442 Jason Merrill changed: What|Removed |Added Summary|[8/9/10 Regression] lambda |[8/9 Regression] lambda in |in if constexpr fails to|if constexpr fails to |compile since r8-5529 |compile since r8-5529 --- Comment #3 from Jason Merrill --- Fixed for GCC 10 so far.
[Bug c++/86917] [8/9 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:2798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86917 Jason Merrill changed: What|Removed |Added Summary|[8/9/10 Regression] ICE in |[8/9 Regression] ICE in |verify_ctor_sanity, at |verify_ctor_sanity, at |cp/constexpr.c:2798 |cp/constexpr.c:2798 --- Comment #9 from Jason Merrill --- Fixed for GCC 10 so far.
[Bug middle-end/93576] [10 Regression] internal compiler error: Segmentation fault (in gimplify.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93576 --- Comment #2 from Yongheng Chen --- Hi Martin, I included the CMD line "gcc -o tmp poc.c" in the report but not the stack dump. Is the stack dump necessary? I didn't include it because I think the POC is enough to reproduce the problem and the report will look cleaner without the stack dump.
[Bug c++/86917] [8/9/10 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:2798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86917
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:a1c9c9ff06ab15e697d5bac6ea6e5da2df840cf5
commit r10-6436-ga1c9c9ff06ab15e697d5bac6ea6e5da2df840cf5
Author: Jason Merrill
Date: Tue Feb 4 14:21:59 2020 -0500
c++: Fix ({ ... }) array mem-initializer.
Here, we were going down the wrong path in perform_member_init because of
the incorrect parens around the mem-initializer for the array. And then
cxx_eval_vec_init_1 didn't know what to do with a CONSTRUCTOR as the
initializer. The latter issue was a straightforward fix, but I also wanted
to fix us silently accepting the parens, which led to factoring out
handling
of TREE_LIST and flexarrays. The latter led to adjusting the expected
behavior on flexary29.C: we should complain about the initializer, but not
complain about a missing initializer.
As I commented on PR 92812, in this process I noticed that we weren't
handling C++20 parenthesized aggregate initialization as a mem-initializer.
So my TREE_LIST handling includes a commented out section that should
probably be part of a future fix for that issue; with it uncommented we
continue to crash on the testcase in C++20 mode, but should instead
complain
about the braced-init-list not being a valid initializer for an A.
PR c++/86917
* init.c (perform_member_init): Simplify.
* constexpr.c (cx_check_missing_mem_inits): Allow uninitialized
flexarray.
(cxx_eval_vec_init_1): Handle CONSTRUCTOR.
[Bug c++/92812] Implement P1975R0: Fixing the wording of parenthesized aggregate-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92812
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:a1c9c9ff06ab15e697d5bac6ea6e5da2df840cf5
commit r10-6436-ga1c9c9ff06ab15e697d5bac6ea6e5da2df840cf5
Author: Jason Merrill
Date: Tue Feb 4 14:21:59 2020 -0500
c++: Fix ({ ... }) array mem-initializer.
Here, we were going down the wrong path in perform_member_init because of
the incorrect parens around the mem-initializer for the array. And then
cxx_eval_vec_init_1 didn't know what to do with a CONSTRUCTOR as the
initializer. The latter issue was a straightforward fix, but I also wanted
to fix us silently accepting the parens, which led to factoring out
handling
of TREE_LIST and flexarrays. The latter led to adjusting the expected
behavior on flexary29.C: we should complain about the initializer, but not
complain about a missing initializer.
As I commented on PR 92812, in this process I noticed that we weren't
handling C++20 parenthesized aggregate initialization as a mem-initializer.
So my TREE_LIST handling includes a commented out section that should
probably be part of a future fix for that issue; with it uncommented we
continue to crash on the testcase in C++20 mode, but should instead
complain
about the braced-init-list not being a valid initializer for an A.
PR c++/86917
* init.c (perform_member_init): Simplify.
* constexpr.c (cx_check_missing_mem_inits): Allow uninitialized
flexarray.
(cxx_eval_vec_init_1): Handle CONSTRUCTOR.
[Bug middle-end/93576] [10 Regression] internal compiler error: Segmentation fault (in gimplify.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93576
Martin Sebor changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-02-04
CC||msebor at gcc dot gnu.org
Component|c |middle-end
Summary|internal compiler error:|[10 Regression] internal
|Segmentation fault (in |compiler error:
|gimplify.c) |Segmentation fault (in
||gimplify.c)
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
Confirmed. Please include the compiler options and its output in bug reports
(see What We Need in https://gcc.gnu.org/bugs).
$ gcc -S -Wall pr92576.c
pr92576.c: In function ‘main’:
pr92576.c:1:34: error: ‘e’ undeclared (first use in this function)
1 | int main ( ) { int x [ ] = { 1 , e } ;
| ^
pr92576.c:1:34: note: each undeclared identifier is reported only once for each
function it appears in
pr92576.c:2:24: error: ‘p’ undeclared (first use in this function)
2 | return x [ ( ( char ) p % ( sizeof ( 0 ) < main ) >= ( ( ( char * ( *
( * (
|^
pr92576.c:2:15: warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
2 | return x [ ( ( char ) p % ( sizeof ( 0 ) < main ) >= ( ( ( char * ( *
( * (
| ^
pr92576.c:2:43: warning: comparison between pointer and integer
2 | return x [ ( ( char ) p % ( sizeof ( 0 ) < main ) >= ( ( ( char * ( *
( * (
| ^
pr92576.c:3:14: warning: ‘struct list’ declared inside parameter list will not
be visible outside of this definition or declaration
3 | int ( struct list ) ) ) [ ! ( 1 , 2 * ( 3 , ! x != ( 1 , sizeof ( char
* ) < (
| ^~~~
pr92576.c:3:45: warning: the address of ‘x’ will always evaluate as ‘true’
[-Waddress]
3 | int ( struct list ) ) ) [ ! ( 1 , 2 * ( 3 , ! x != ( 1 , sizeof ( char
* ) < (
| ^
pr92576.c:4:5: warning: left-hand operand of comma expression has no effect
[-Wunused-value]
4 | ( 1 , 2 ) / 2 != 7 , 2 ) ) ) ) ] ) [ * * main ] ) p + 4 ) >= & x [ 12 ]
) ) ] ;
| ^
pr92576.c:4:20: warning: left-hand operand of comma expression has no effect
[-Wunused-value]
4 | ( 1 , 2 ) / 2 != 7 , 2 ) ) ) ) ] ) [ * * main ] ) p + 4 ) >= & x [ 12 ]
) ) ] ;
|^
pr92576.c:3:56: warning: left-hand operand of comma expression has no effect
[-Wunused-value]
3 | int ( struct list ) ) ) [ ! ( 1 , 2 * ( 3 , ! x != ( 1 , sizeof ( char
* ) < (
|^
pr92576.c:3:49: warning: logical not is only applied to the left hand side of
comparison [-Wlogical-not-parentheses]
3 | int ( struct list ) ) ) [ ! ( 1 , 2 * ( 3 , ! x != ( 1 , sizeof ( char
* ) < (
| ^~
pr92576.c:3:45: note: add parentheses around left hand side expression to
silence this warning
3 | int ( struct list ) ) ) [ ! ( 1 , 2 * ( 3 , ! x != ( 1 , sizeof ( char
* ) < (
| ^~~
| ( )
pr92576.c:3:43: warning: left-hand operand of comma expression has no effect
[-Wunused-value]
3 | int ( struct list ) ) ) [ ! ( 1 , 2 * ( 3 , ! x != ( 1 , sizeof ( char
* ) < (
| ^
pr92576.c:3:33: warning: left-hand operand of comma expression has no effect
[-Wunused-value]
3 | int ( struct list ) ) ) [ ! ( 1 , 2 * ( 3 , ! x != ( 1 , sizeof ( char
* ) < (
| ^
pr92576.c:3:14: error: size of unnamed array has non-integer type
3 | int ( struct list ) ) ) [ ! ( 1 , 2 * ( 3 , ! x != ( 1 , sizeof ( char
* ) < (
| ^~~~
pr92576.c:2:59: error: cast specifies function type
2 | return x [ ( ( char ) p % ( sizeof ( 0 ) < main ) >= ( ( ( char * ( *
( * (
| ^
pr92576.c:3:14: internal compiler error: Segmentation fault
3 | int ( struct list ) ) ) [ ! ( 1 , 2 * ( 3 , ! x != ( 1 , sizeof ( char
* ) < (
| ^~~~
0x12d1642 crash_signal
/src/gcc/trunk/gcc/toplev.c:328
0xe0bdd7 gimplify_compound_expr
/src/gcc/trunk/gcc/gimplify.c:6021
0xe0bdf7 gimplify_compound_expr
/src/gcc/trunk/gcc/gimplify.c:6022
0xe3402e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/src/gcc/trunk/gcc/gimplify.c:13571
0xe380cb gimplify_expr
/src/gcc/tr
[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #2 from Martin Sebor ---
Below is a simplified C test case. The warning is justified and works
correctly, but the index and the type it prints might be a little confusing.
The index corresponds to the MEM_REF offset which is set to zero by the front
end regardless of the value of the original offset (for an empty object).
There's nothing the warning can do about that. Rather than letting the
out-of-bounds reference result in a bogus value VRP could fold it to zero (that
would be consistent with what the folder does for accesses to constants), but
that seems like a separate issue.
For simplicity, the warning treats singleton objects the same as arrays of one
element, so the type ‘struct E[1]’ simply refers to the type of the global e.
Since the warning also prints a note pointing to the object I wouldn't expect
this to be too big of a problem.
So unless this report is about the details of the message as opposed to issuing
it at all I'm inclined to resolve it as invalid.
$ cat t.c && gcc -O2 -S -Wall -fdump-tree-vrp=/dev/stdout t.c
struct E { } e;
struct A { int i; };
int f (void)
{
struct E *ep = &e;
return ((struct A*) (ep + 9))->i;
}
;; Function f (f, funcdef_no=0, decl_uid=1934, cgraph_uid=1, symbol_order=1)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
Value ranges after VRP:
_2: int VARYING
t.c: In function ‘f’:
t.c:8:32: warning: array subscript 0 is outside array bounds of ‘struct E[1]’
[-Warray-bounds]
8 | return ((struct A*) (ep + 1))->i;
|^~
t.C:1:14: note: while referencing ‘e’
1 | struct E { } e;
| ^
f ()
{
int _2;
[local count: 1073741824]:
_2 = MEM[(struct A *)&e].i;
return _2;
}
;; Function f (f, funcdef_no=0, decl_uid=1934, cgraph_uid=1, symbol_order=1)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
Value ranges after VRP:
_2: int VARYING
f ()
{
int _2;
[local count: 1073741824]:
_2 = MEM[(struct A *)&e].i;
return _2;
}
[Bug c++/92812] Implement P1975R0: Fixing the wording of parenthesized aggregate-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92812 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Mine.
[Bug rtl-optimization/93583] [10 Regression] bootstrap failure on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93583 --- Comment #1 from Matthias Klose --- a build without lto seems to succeed.
[Bug rtl-optimization/93583] New: [10 Regression] bootstrap failure on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93583 Bug ID: 93583 Summary: [10 Regression] bootstrap failure on powerpc64le-linux-gnu Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: doko at ubuntu dot com Target Milestone: --- seen with trunk 20200204 5124c34fcc62f0f880ae947542678e28aa2ce703 on powerpc64le-linux-gnu. during RTL pass: expand ../../src/gcc/config/rs6000/driver-rs6000.c: In function 'host_detect_local_cpu': ../../src/gcc/config/rs6000/driver-rs6000.c:342:25: internal compiler error: Segmentation fault 342 | return describe_cache (l1_sizekb, l1_line, l1_assoc, l2_sizekb); | ^ 0x1077f863 crash_signal ../../src/gcc/toplev.c:328 0x101f0a60 expand_call(tree_node*, rtx_def*, int) ../../src/gcc/calls.c:4672 0x103664ff expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../src/gcc/expr.c:11130 0x1020249f expand_expr ../../src/gcc/expr.h:282 0x1020249f expand_call_stmt ../../src/gcc/cfgexpand.c:2703 0x1020249f expand_gimple_stmt_1 ../../src/gcc/cfgexpand.c:3682 0x1020249f expand_gimple_stmt ../../src/gcc/cfgexpand.c:3847 0x10209117 expand_gimple_basic_block ../../src/gcc/cfgexpand.c:5887 0x10209117 execute ../../src/gcc/cfgexpand.c:6542 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. make[6]: *** [/tmp/cc4GyZt0.mk:5: /tmp/cpp.EgoT71.ltrans1.ltrans.o] Error 1 make[6]: *** Waiting for unfinished jobs lto-wrapper: fatal error: /usr/bin/make returned 2 exit status compilation terminated. /usr/bin/powerpc64le-linux-gnu-ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status make[5]: *** [Makefile:2089: cpp] Error 1 make[5]: *** Waiting for unfinished jobs this is a compiler defaulting to hardening options, configured with Configured with: -v --enable-languages=c,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=powerpc64le-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --enable-plugin --enable-default-pie --with-system-zlib --disable-libphobos --enable-objc-gc=auto --enable-secureplt --with-cpu=power8 --enable-targets=powerpcle-linux --disable-multilib --enable-multiarch --disable-werror --with-long-double-128 --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex
[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582 Marek Polacek changed: What|Removed |Added CC||msebor at gcc dot gnu.org Target Milestone|--- |10.0 Summary|-Warray-bounds gives error: |[10 Regression] |array subscript 0 is|-Warray-bounds gives error: |outside array bounds of |array subscript 0 is |struct E[1] |outside array bounds of ||struct E[1] --- Comment #1 from Marek Polacek --- Started with r10-4300-g49fb45c81f4ac068d9fb859968d8f223bc438251
[Bug middle-end/93582] New: -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
Bug ID: 93582
Summary: -Warray-bounds gives error: array subscript 0 is
outside array bounds of struct E[1]
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
Reduced from libXt:
struct E {
} e;
struct A {
unsigned long *l;
};
struct C {
unsigned long *l;
} c;
void
bar (struct E *ep)
{
c.l = ((struct A*) ((ep) + 1))->l;
}
void
f ()
{
bar (&e);
}
$ ./cc1 -quiet -O3 x.c -Warray-bounds
x.c: In function ‘f’:
x.c:15:33: warning: array subscript 0 is outside array bounds of ‘struct E[1]’
[-Warray-bounds]
15 | c.l = ((struct A*) ((ep) + 1))->l;
| ^~~
x.c:2:3: note: while referencing ‘e’
2 | } e;
| ^
[Bug target/93532] RISCV g++ hangs with optimization >= -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532 --- Comment #11 from Jim Wilson --- I'm able to reproduce with the gcc-8-branch now. Maybe I made a mistake with my earlier build. Anyways, it looks like it is going wrong here in the reload dump Creating newreg=1856, assigning class NO_REGS to save r1856 434: fa0:SF=call [`sqrtf'] argc:0 REG_UNUSED fa0:SF REG_CALL_DECL `sqrtf' REG_EH_REGION 0 Add reg<-save after: 2446: r114:SF#0=r1856:DF 432: NOTE_INSN_BASIC_BLOCK 24 Add save<-reg after: 2445: r1856:DF=r114:SF#0 then later we appear to end up in a loop generating secondary reloads that need secondary reloads themselves, and so forth. The instruction above looks funny, trying to use a subreg to convert DFmode to SFmode. I don't think we should be generating that. So it looks like a caller save problem. If I add -fno-caller-saves the compile finishes. It appears that we need a definition for HARD_REGNO_CALLER_SAVE_MODE because the default definition can't work here. The comment in sparc.h for HARD_REGNO_CALLER_SAVE_MODE looks relevant. The same definition may work for RISC-V. Looks like the MIPS port does it the same way too.
[Bug fortran/93581] New: [9/10 Regression] ICE in gfc_get_dataptr_offset, at fortran/trans-array.c:6951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93581 Bug ID: 93581 Summary: [9/10 Regression] ICE in gfc_get_dataptr_offset, at fortran/trans-array.c:6951 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20181028 (rejected) and 20181104 (ICE): (scalar case z0 works) $ cat z0.f90 program p complex, target :: z = (1.0, 2.0) real, pointer :: r r => z%re print *, r r => z%im print *, r end $ gfortran-10-20200105 z0.f90 && ./a.out 1. 2. $ cat z1.f90 program p complex, target :: z(2) = (1.0, 2.0) real, pointer :: r(:) r => z%re print *, r end $ gfortran-10-20200202 -c z1.f90 z1.f90:4:0: 4 |r => z%re | internal compiler error: in gfc_get_dataptr_offset, at fortran/trans-array.c:6951 0x703c04 gfc_get_dataptr_offset(stmtblock_t*, tree_node*, tree_node*, tree_node*, bool, gfc_expr*) ../../gcc/fortran/trans-array.c:6951 0x708ac1 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-array.c:7746 0x734f43 gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*) ../../gcc/fortran/trans-expr.c:9293 0x6f5eb7 trans_code ../../gcc/fortran/trans.c:1872 0x71f504 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6835 0x6a83a6 translate_all_program_units ../../gcc/fortran/parse.c:6306 0x6a83a6 gfc_parse_file() ../../gcc/fortran/parse.c:6545 0x6f295f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:210
