[Bug tree-optimization/101202] ICE at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101202 --- Comment #5 from Richard Biener --- (In reply to David Binderman from comment #4) > I see this also on gcc bootstrap with -O3, so it looks quite important. I'll see to test the patch with -O3 bootstrap then - thanks for the info.
[Bug tree-optimization/101202] ICE at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101202 --- Comment #6 from Martin Liška --- And I noticed the same ICE in botan benchmark.
[Bug tree-optimization/101202] ICE at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101202 --- Comment #7 from David Binderman --- (In reply to Richard Biener from comment #5) > I'll see to test the patch with -O3 bootstrap then - thanks for the info. You are very welcome. With the benefit of hindsight, changes in the -O3 area of the compiler would be well tested before commit with one of 1. bootstrap-O3 2. After a configure command, doing something like this: sed 's/-O2/-O3/' < Makefile > Makefile.tmp diff Makefile Makefile.tmp mv Makefile.tmp Makefile I am not sure of the difference, but they are pretty similar.
[Bug c/101204] New: infinite recursion in gtype-desc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101204
Bug ID: 101204
Summary: infinite recursion in gtype-desc.c
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: ---
For a recent gcc build with clang, I get:
gtype-desc.c:10853:1: warning: all paths through this function will call itself
[-Winfinite-recursion]
Source code is
void
gt_pch_nx (int_hash* x ATTRIBUTE_UNUSED,
ATTRIBUTE_UNUSED gt_pointer_operator op,
ATTRIBUTE_UNUSED void *cookie)
{
gt_pch_nx (&((*x)), op, cookie);
}
I think this has probably first appeared in the last week or so.
[Bug middle-end/101197] __builtin_memmove does not perform constant optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101197 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I guess it can be expanded inline iff it is done through a modified move_by_pieces - one that instead of emitting read store read store read store emits all the reads first and then all the stores. And hopefully the aliasing info will make it clear for all the following RTL passes that it can overlap and thus scheduling etc. can't reorder the stores with the reads. emit_block_move_hints will need some small tweaks. Currently for might_overlap it only tries emit_block_move_via_pattern and punts if that fails. I think we'd need some m_* flag and adjust the run method so that if that is true, it emits the stores in a separate sequence from the reads.
[Bug target/101205] New: csinv does not have an zero_extend version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101205
Bug ID: 101205
Summary: csinv does not have an zero_extend version
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
While improving phi-opt I ran into this issue.
gcc.target/aarch64/csinv-neg.c started to fail because we move the cast out of
the conditional and such.
Here is a testcase which shows the problem even without improvment of phiopt:
unsigned long long
inv1(unsigned a, unsigned b, unsigned c)
{
unsigned t = a ? b : ~c;
return t;
}
[Bug middle-end/101197] __builtin_memmove does not perform constant optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101197 --- Comment #4 from Jakub Jelinek --- Also, one will probably need to rename all the MOVE_* and *move_* stuff to COPY_* and *copy_* and reserve MOVE_* and *move_* for the overlapping copies. And most likely on various arches it might need smaller size limits, because it will also depend on how many registers the target has (besides fixes/special ones or those that likely need to be used for the to and from addresses), some small spilling might be ok, but heavy spilling would essentially mean memcpy to a temporary spill area and memcpy back.
[Bug target/101188] [AVR] Miscompilation and function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
Senthil Kumar Selvaraj changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC||saaadhu at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2021-06-25
--- Comment #1 from Senthil Kumar Selvaraj ---
Confirmed with 12.0.0 20210625
Here's a reduced testcase that hangs indefinitely with avrtest - the log shows
call to address 0.
$ cat fail.c
#include
#include
typedef uint8_t (*fn1)(void *a);
typedef void (*fn2)(void *a, const uint32_t *arg);
struct S {
uint8_t buffer[64];
uint16_t n;
fn2 f2;
void *a;
fn1 f1;
};
volatile uint16_t x;
void __attribute__((noinline))
foo(uint16_t n)
{
x = n;
}
void __attribute__((noinline)) testfn(struct S *self)
{
uint32_t arg;
foo(self->n);
self->n++;
self->f2(self->a, &arg);
self->buffer[0] = self->f1(self->a);
}
static unsigned char myfn2_called = 0;
static void
myfn2(void *a, const uint32_t * arg)
{
myfn2_called = 1;
}
static uint8_t
myfn1(void *a)
{ }
int main() {
struct S s;
s.n = 0; s.f2 = myfn2; s.f1 = myfn1;
testfn(&s);
if (myfn2_called != 1)
abort();
return 0;
}
$ avr-gcc -mmcu=atmega128 fail.c -O2 ~/code/avrtest/exit-atmega128.o --version
avr-gcc (GCC) 12.0.0 20210625 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ~/code/avrtest/avrtest -mmcu=avr51 a.out
^C
The below code is at fault - there's an ldi to r31, followed by a load to Z
using R31:R30, and then an icall. The clobbering of r31 at 0x138 causes junk
values (0) to be read into Z, and icall calls address 0.
138: f4 e4 ldi r31, 0x44 ; 68
13a: ef 0e add r14, r31
13c: f1 1c adc r15, r1
13e: 32 96 adiwr30, 0x02 ; 2
140: 01 90 ld r0, Z+
142: f0 81 ld r31, Z
144: e0 2d mov r30, r0
146: be 01 movwr22, r28
148: 6f 5f subir22, 0xFF ; 255
14a: 7f 4f sbcir23, 0xFF ; 255
14c: d7 01 movwr26, r14
14e: 8d 91 ld r24, X+
150: 9c 91 ld r25, X
152: 09 95 icall
[Bug c++/85319] std::char_traits::length does not always function in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85319 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Component|libstdc++ |c++ Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- Fixed in GCC 9.1 by r267341 *** This bug has been marked as a duplicate of bug 86524 ***
[Bug c++/86524] [8 Regression] std::less with pointer arguments not usable in static_assert in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86524 Jonathan Wakely changed: What|Removed |Added CC||v at vsamko dot com --- Comment #13 from Jonathan Wakely --- *** Bug 85319 has been marked as a duplicate of this bug. ***
[Bug middle-end/101204] infinite recursion in gtype-desc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101204 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||msebor at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Most likely r12-1801-g7036e9ef462fde8181bece4ac4e03f3aa27204dc
[Bug middle-end/100672] wrong code with vector shift and unary minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100672 --- Comment #13 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:e0dae9c92aa248c858f682f03ee1b16471297718 commit r11-8652-ge0dae9c92aa248c858f682f03ee1b16471297718 Author: Richard Biener Date: Wed May 19 13:35:07 2021 +0200 middle-end/100672 - fix bogus right shift folding This fixes the bogus use of TYPE_PRECISION on vector types from optimizing -((int)x >> 31) into (unsigned)x >> 31. 2021-05-19 Richard Biener PR middle-end/100672 * fold-const.c (fold_negate_expr_1): Use element_precision. (negate_expr_p): Likewise. * gcc.dg/torture/pr100672.c: New testcase. (cherry picked from commit 8d51039cb7c807ed84ff7df5416a1e3ba07a5e63)
[Bug tree-optimization/101105] [11 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101105 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:00ab8e994b87693b9e56fa68c3b3ede01425a2c0 commit r11-8653-g00ab8e994b87693b9e56fa68c3b3ede01425a2c0 Author: Richard Biener Date: Wed Jun 23 12:43:03 2021 +0200 tree-optimization/101105 - fix runtime alias test optimization We were ignoring DR_STEP for VF == 1 which is OK only in case the scalar order is preserved or both DR steps are the same. 2021-06-23 Richard Biener PR tree-optimization/101105 * tree-vect-data-refs.c (vect_prune_runtime_alias_test_list): Only ignore steps when they are equal or scalar order is preserved. * gcc.dg/torture/pr101105.c: New testcase. (cherry picked from commit 50374fdacbd121bc4a61b073e559208ff61bee06)
[Bug tree-optimization/101151] [11 Regression] ICE at -O1 and above on x86_64-linux-gnu: verify_ssa failed since r11-3705-gdae673abd37d4004
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101151 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:8dc3768ffb4debc559e428fd508a4e8c59586c00 commit r11-8654-g8dc3768ffb4debc559e428fd508a4e8c59586c00 Author: Richard Biener Date: Tue Jun 22 10:14:02 2021 +0200 tree-optimization/101151 - fix irreducible region check for sinking The check whether two blocks are in the same irreducible region and thus post-dominance checks being unreliable was incomplete since an irreducible region can contain reducible sub-regions but if one block is in the irreducible part and one not the check still doesn't work as expected. 2021-06-22 Richard Biener PR tree-optimization/101151 * tree-ssa-sink.c (statement_sink_location): Expand irreducible region check. * gcc.dg/torture/pr101151.c: New testcase. (cherry picked from commit a2ef8395fa970498985764514044e5fd00f7d5c0)
[Bug tree-optimization/101158] [10/11 Regression] ICE in gimple_call_arg, at gimple.h:3247
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101158 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:48097089ae539bd5c2649681f93ce4a6bad72b11 commit r11-8655-g48097089ae539bd5c2649681f93ce4a6bad72b11 Author: Richard Biener Date: Tue Jun 22 09:24:24 2021 +0200 tree-optimization/101158 - adjust SLP call matching sequence This moves the check for same operands after verifying we're facing compatible calls. 2021-06-22 Richard Biener PR tree-optimization/101158 * tree-vect-slp.c (vect_build_slp_tree_1): Move same operand checking after checking for matching operation. * gfortran.dg/pr101158.f90: New testcase. (cherry picked from commit 7a22d8a764418265680a6bb9a9aec31e984eb015)
[Bug tree-optimization/101105] [9/10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101105 Richard Biener changed: What|Removed |Added Known to fail||11.1.0 Target Milestone|11.2|9.5 Summary|[11 Regression] wrong code |[9/10 Regression] wrong |at -O3 on x86_64-linux-gnu |code at -O3 on ||x86_64-linux-gnu Known to work||11.1.1
[Bug tree-optimization/101151] [11 Regression] ICE at -O1 and above on x86_64-linux-gnu: verify_ssa failed since r11-3705-gdae673abd37d4004
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101151 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed.
[Bug testsuite/101206] New: [12 Regression] gcc.target/aarch64/vect-vmaxv.c and gcc.target/aarch64/vect-vaddv.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101206 Bug ID: 101206 Summary: [12 Regression] gcc.target/aarch64/vect-vmaxv.c and gcc.target/aarch64/vect-vaddv.c fail Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: aarch64 These testcases fail: FAIL: gcc.target/aarch64/vect-vmaxv.c scan-assembler umaxv\\tb[0-9]+, v[0-9]+.16b FAIL: gcc.target/aarch64/vect-vmaxv.c scan-assembler uminv\\tb[0-9]+, v[0-9]+.16b FAIL: gcc.target/aarch64/vect-vaddv.c scan-assembler addv\\tb[0-9]+, v[0-9]+.16b But they are failing because the above instructions that were in the scan-assembler are now optimized away. They are optimized in *r.dse1 I have not looked into what revision caused them to be optimized away though. But the generated code is correct.
[Bug testsuite/101206] [12 Regression] gcc.target/aarch64/vect-vmaxv.c and gcc.target/aarch64/vect-vaddv.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101206 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/101200] Unneeded AND after shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101200
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||law at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
Doing everything in DImode or SImode has some advantages, but lots of
disadvantages too.
x86 can do 8/16/32/64bit arithmetics just fine (although 16bit can cause some
performance problems).
The second & 15 from the source is optimized away during GIMPLE operations.
But later on reappears from just a zero extension from 8 bits to 64 bits, with
a few bits known to be zero (so not & 255 but just & 15).
I think the right pass to optimize this back is REE.
If I manually undo the optimization that combine did and replace
(insn 14 13 15 2 (parallel [
(set (reg:DI 95 [ a ])
(and:DI (subreg:DI (reg:QI 93 [ a ]) 0)
(const_int 15 [0xf])))
(clobber (reg:CC 17 flags))
]) "pr101200.c":9:10 494 {*anddi_1}
with
(insn 14 13 15 2 (set (reg:DI 95 [ a ])
(zero_extend:DI (reg:QI 93 [ a ]))) "pr101200.c":9:10 137
{zero_extendqidi2}
then REE tries something but gives up anyway:
Trying to eliminate extension:
(insn 14 13 15 2 (set (reg:DI 0 ax [orig:95 a ] [95])
(zero_extend:DI (reg:QI 0 ax [orig:93 a ] [93]))) "pr101200.c":9:10 137
{zero_extendqidi2}
(nil))
Tentatively merged extension with definition :
(insn 12 10 13 2 (parallel [
(set (reg:DI 0 ax)
(zero_extend:DI (lshiftrt:QI (reg:QI 0 ax [orig:82 d.0_1 ]
[82])
(const_int 4 [0x4]
(clobber (reg:CC 17 flags))
]) "pr101200.c":8:17 -1
(nil))
Merge cancelled, non-mergeable definitions:
(insn 12 10 13 2 (parallel [
(set (reg:QI 0 ax [orig:93 a ] [93])
(lshiftrt:QI (reg:QI 0 ax [orig:82 d.0_1 ] [82])
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) "pr101200.c":8:17 717 {*lshrqi3_1}
(nil))
Elimination opportunities = 1 realized = 0
So, to handle this, REE would need to figure out that some ANDs following
logical right shifts can be treated as zero extensions too and also be taught
to handle lshiftrts, replace the QImode MEM read with zero extending one,
widening the right shift from QImode to DImode too (or ideally to SImode given
the behavior of x86) and optimizing away the zero extension (emitted as AND
15).
[Bug target/101200] Unneeded AND after shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101200 --- Comment #5 from Jakub Jelinek --- BTW, I certainly can't reproduce what #c0 shows, while I see movzbl in there because QImode loads are done that way in most tunings, I certainly see shrb$4, %al rather than 64-bit right shift.
[Bug tree-optimization/101207] New: [12 Regress] gcc.dg/vect/vect-strided-mult.c fails after SLP improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101207 Bug ID: 101207 Summary: [12 Regress] gcc.dg/vect/vect-strided-mult.c fails after SLP improvements Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: aarch64-linux-gnu So after the recent SLP improvements gcc.dg/vect/vect-strided-mult.c started to fail on aarch64-linux-gnu . There was one place where SLP happens where it did not happen before with: || ires[i].a != iarr[i].b - iarr[i].a || ires[i].b != iarr[i].b + iarr[i].a Which produces in optimized: vect__22.39_7 = MEM [(unsigned int *)_101]; _46 = BIT_FIELD_REF ; _8 = BIT_FIELD_REF ; _24 = _8 - _46; ... _47 = .REDUC_PLUS (vect__22.39_7); In the assembly code: - ldr d0, [x1] - umovw8, v0.s[1] - fmovw5, s0 - sub w5, w5, w8 -addpv0.2s, v0.2s, v0.2s Where before we did: + ldp w6, w3, [x1] + sub w8, w3, w6 + add wN, w3, w6 The add should be ok but the subtraction I think is failing.
[Bug tree-optimization/101207] [12 Regress] gcc.dg/vect/vect-strided-mult.c fails after SLP improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101207 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug libffi/101208] New: libffi.call/nested_struct12.c fails on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101208 Bug ID: 101208 Summary: libffi.call/nested_struct12.c fails on aarch64 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: aarch64-linux-gnu Mostly filing just to record this test failing. >From IRC: [03:09] ktkacho2: seems my new nested_struct12.c libffi testcase FAILs on aarch64, doesn't aarch64 libffi have a similar bug to the one that got fixed on x86_64? [03:10] ktkachov2: ^^^; passes on all other targets I've tested (armv7hl, s390x, ppc64le, x86_64, i686) [03:20] jakub: I'm afraid I don't know much about that area [03:23] James Greenhalgh and Marcus Shawcroft did the libffi port, but haven't seen them on gcc-patches for a while; anyone else in ARM would be familiar with libffi? I'm afraid I don't know anything about aarch64 parameter passing rules [03:23] pinskia: ^^^
[Bug tree-optimization/101207] [12 Regress] gcc.dg/vect/vect-strided-*-mult.c fails after SLP improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101207 Andrew Pinski changed: What|Removed |Added Summary|[12 Regress]|[12 Regress] |gcc.dg/vect/vect-strided-mu |gcc.dg/vect/vect-strided-*- |lt.c fails after SLP|mult.c fails after SLP |improvements|improvements --- Comment #1 from Andrew Pinski --- Note it looks like was more than just that testcase too: FAIL: gcc.dg/vect/vect-strided-a-mult.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-strided-a-mult.c execution test FAIL: gcc.dg/vect/vect-strided-a-u32-mult.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-strided-a-u32-mult.c execution test FAIL: gcc.dg/vect/vect-strided-mult.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-strided-mult.c execution test FAIL: gcc.dg/vect/vect-strided-u32-mult.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-strided-u32-mult.c execution test
[Bug fortran/101079] [OPENMP] The value of list-item in linear clause in loop construct is not calculated on each iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101079 --- Comment #5 from Jakub Jelinek --- OpenMP language committee discussions aren't public, there will be soon an OpenMP 5.2 public draft though. The particular restriction under discussion is: "For a linear clause that appears on a loop-associated construct, the difference between the value of a list item at the end of a logical iteration and its value at the beginning of the logical iteration must be equal to linear-step."
[Bug libffi/101208] libffi.call/nested_struct12.c fails on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101208 --- Comment #1 from Andrew Pinski --- Just for reference the x86_64 fix was r12-1524 .
[Bug tree-optimization/101202] ICE at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101202 --- Comment #8 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:55a1546b73b60d2601f35671ba9e8f12a52a7b77 commit r12-1809-g55a1546b73b60d2601f35671ba9e8f12a52a7b77 Author: Richard Biener Date: Fri Jun 25 09:20:56 2021 +0200 tree-optimization/101202 - fix ICE with failed backedge SLP nodes This fixes an ICE with failed backedge SLP nodes still in the graph while doing permute optimization by explicitely handling those. 2021-06-25 Richard Biener PR tree-optimization/101202 * tree-vect-slp.c (vect_optimize_slp): Explicitely handle failed nodes. * gcc.dg/torture/pr101202.c: New testcase.
[Bug tree-optimization/101202] ICE at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101202 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener --- Fixed.
[Bug tree-optimization/101207] [12 Regression] gcc.dg/vect/vect-strided-*-mult.c fails after SLP improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101207 --- Comment #2 from Andrew Pinski --- Most likely introduced by r12-1551 .
[Bug tree-optimization/101207] [12 Regression] gcc.dg/vect/vect-strided-*-mult.c fails after SLP improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101207 Andrew Pinski changed: What|Removed |Added Target|aarch64-linux-gnu |aarch64-linux-gnu, ||arm-none-eabi --- Comment #3 from Andrew Pinski --- Looks like it is failing also on arm-none-eabi too: https://gcc.gnu.org/pipermail/gcc-testresults/2021-June/702031.html
[Bug tree-optimization/101145] niter analysis fails for until-wrap condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145
--- Comment #5 from Jiu Fu Guo ---
(In reply to bin cheng from comment #4)
> (In reply to Jiu Fu Guo from comment #3)
> > Yes, while the code in adjust_cond_for_loop_until_wrap seems somehow tricky:
> >
> > /* Only support simple cases for the moment. */
> > if (TREE_CODE (iv0->base) != INTEGER_CST
> > || TREE_CODE (iv1->base) != INTEGER_CST)
> > return false;
> >
> > This code requires both sides are constant.
> Actually it requires an IV with constant base.
I also feel that the intention of this function may only require one side
constant for IV0 CODE IV1.
As tests, for below loop, adjust_cond_for_loop_until_wrap return false:
foo (int *__restrict__ a, int *__restrict__ b, unsigned i)
{
while (++i > 100)
*a++ = *b++ + 1;
}
For below code, adjust_cond_for_loop_until_wrap returns true:
i = UINT_MAX - 200;
while (++i > 100)
*a++ = *b++ + 1;
[Bug tree-optimization/80635] [9/10 regression] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Paul Fee changed:
What|Removed |Added
CC||paul.f.fee at gmail dot com
--- Comment #65 from Paul Fee ---
Below is some code that produces unexpected -Wmaybe-uninitialized warnings. Is
this a variant of this bug or a separate bug?
I've tried a few configurations:
Unexpected warnings:
$ g++-10 -Wall -O2 warn.cpp -DBOOST
warn.cpp: In function ‘int main()’:
warn.cpp:19:10: warning: ‘*((void*)& i +1)’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
19 | m_i(i)
| ^
warn.cpp:32:10: note: ‘*((void*)& i +1)’ was declared here
32 | optb i;
| ^
No warnings (c++17 flag not needed with GCC 11).
$ g++-10 -Wall -O2 warn.cpp -std=c++17
$ g++-11 -Wall -O2 warn.cpp -DBOOST
$ g++-11 -Wall -O2 warn.cpp
The constructor takes three optional and one optional.
Adjusting the number and types of parameters makes a difference, but I don't
see why. Perhaps with less parameters, passing by register rather than stack
memory affects warning generation. However 4 x optional gives no
warning and that would be larger than 3 x optional plus 1 x
optional.
It's not clear why std::optional would be free from warnings, yet
boost::optional not. Is adoption of std::optional an effective way of avoiding
unnecessary -Wmaybe-uninitialized warnings?
It seems that GCC 11 has better behaviour. Is this expected or would some
other (perhaps larger) collection of parameters trigger the same warning with
GCC 11?
If GCC 11 incorporates a specific fix, will that be backported to GCC 10?
Tested with GCC on openSUSE Tumbleweed. Package versions:
gcc10-c++-10.3.0+git1587-2.1.x86_64
gcc11-c++-11.1.1+git340-1.1.x86_64
The source for warn.cpp:
#include
#ifdef BOOST
#include
using opts = boost::optional;
using optb = boost::optional;
#else
#include
using opts = std::optional;
using optb = std::optional;
#endif
class foo
{
public:
foo(opts a, opts b, opts c,
optb i)
: m_a(a), m_b(b), m_c(c),
m_i(i)
{}
private:
opts m_a;
opts m_b;
opts m_c;
optb m_i;
};
int main()
{
opts a, b, c;
optb i;
foo bar(a, b, c, i);
}
[Bug target/101200] Unneeded AND after shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101200 --- Comment #6 from Steinar H. Gunderson --- You're right, I don't know why the shrq happened. When I run now, I get shrb. Doesn't matter for the bug, though.
[Bug fortran/101079] [OPENMP] The value of list-item in linear clause in loop construct is not calculated on each iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101079 --- Comment #6 from xiao@compiler-dev.com --- (In reply to Jakub Jelinek from comment #5) > OpenMP language committee discussions aren't public, there will be soon an > OpenMP 5.2 public draft though. > The particular restriction under discussion is: > "For a linear clause that appears on a loop-associated construct, > the difference between the value of a list item at the end of a logical > iteration and its value at the beginning of the logical iteration must > be equal to linear-step." Thanks.
[Bug c++/101209] New: ICE with trailing return type on a conversion operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101209
Bug ID: 101209
Summary: ICE with trailing return type on a conversion operator
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aaron at aaronballman dot com
Target Milestone: ---
I was curious what kind of diagnostics different compilers would give me for
some nonsense code, and found that the following code causes an ICE in GCC.
struct S {
operator int() const -> double;
};
:2:27: internal compiler error: in splice_late_return_type, at
cp/pt.c:29753
2 | operator int() const -> double;
| ^~
0x1d48999 internal_error(char const*, ...)
???:0
0x724013 fancy_abort(char const*, int, char const*)
???:0
0x9847fc splice_late_return_type(tree_node*, tree_node*)
???:0
0x808c53 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
???:0
0x834403 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
???:0
0x94cadd c_parse_file()
???:0
0xacfe82 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/101209] ICE with trailing return type on a conversion operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101209 --- Comment #1 from Aaron Ballman --- > This should likely give an error about using a trailing return type for a > function with a declared return type other than a placeholder type. Err, that would be bad now that I think about it (http://eel.is/c++draft/class.conv.fct#6). So I'd amend this to: it should probably give a reasonable diagnostic. :-)
[Bug libffi/101208] libffi.call/nested_struct12.c fails on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101208 Anthony Green changed: What|Removed |Added CC||green at redhat dot com --- Comment #2 from Anthony Green --- It's passing in upstream libffi... https://rl.gl/doc-text?id=RLGL-N0ZQWLP1 ...so check for any fixes that weren't migrated to gcc.
[Bug tree-optimization/101145] niter analysis fails for until-wrap condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145
--- Comment #6 from Jiu Fu Guo ---
> As tests, for below loop, adjust_cond_for_loop_until_wrap return false:
>
> foo (int *__restrict__ a, int *__restrict__ b, unsigned i)
> {
> while (++i > 100)
> *a++ = *b++ + 1;
> }
For the above code, niter still may be zero: e.g. "i < 100" at the start.
For the below code, niter can be determined as constant at compiling time.
>
> For below code, adjust_cond_for_loop_until_wrap returns true:
> i = UINT_MAX - 200;
> while (++i > 100)
> *a++ = *b++ + 1;
For below code, niter is also may be zero: e.g. "UINT_MAX - 100 < n" .
i = UINT_MAX - 200
while (++i > n)
*a++ = *b++ + 1;
[Bug c++/96204] gcc complains about private member access in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug fortran/101199] program changes the value of a dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101199 Jürgen Reuter changed: What|Removed |Added CC||juergen.reuter at desy dot de --- Comment #3 from Jürgen Reuter --- I think that indeed this is not something the compiler needs to do as expected, as it is an aliasing problem. In the advance TBP you are calling again the init routine. The init routines sets the value of this%var1 to the argument with which it is called. In this%advance you are calling the init routine with the argument this%var1. However, in the init routine, the struct1 type is intent(out), so it is not guaranteed that the value of struct1%var1 is accessible when calling the init routine from an earlier initialization of that type. That is the aliasing problem: advance calls the init routine, the init routine creates a new instance of struct1 and you are not guaranteed that you can access the struct1%var1 component. There are several ways out: (1) define this in the init routine as intent(inout), very unusual for an initializer, but then gfortran does what you expect (2) define a global instance of struct1 in the module, e.g. type(original_struct), save, public :: struct_global and in advance then call the (before initialized) this%init(struct_global%var1)
[Bug fortran/101199] program changes the value of a dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101199 --- Comment #4 from ygal klein --- (In reply to Jürgen Reuter from comment #3) > I think that indeed this is not something the compiler needs to do as > expected, as it is an aliasing problem. > In the advance TBP you are calling again the init routine. The init > routines sets the value of this%var1 to the argument with which it is > called. In this%advance you are calling the init routine with the > argument this%var1. However, in the init routine, the struct1 type > is intent(out), so it is not guaranteed that the value of struct1%var1 > is accessible when calling the init routine from an earlier initialization > of that type. That is the aliasing problem: advance calls > the init routine, the init routine creates a new instance of struct1 > and you are not guaranteed that you can access the struct1%var1 component. > There are several ways out: > (1) define this in the init routine as intent(inout), very unusual for > an initializer, but then gfortran does what you expect > (2) define a global instance of struct1 in the module, e.g. > type(original_struct), save, public :: struct_global > and in advance then call the (before initialized) > this%init(struct_global%var1) Thank you for the reply. After posting the bug report - I saw that implementing (inout) as your number 1 suggestion - dodges the problem - though as you mentioned having inout for this in an init routine is somewhat unnatural. The 2nd suggestion is something that I was trying to avoid in the first place - i.e copying a whole type (this minimal example is a small type - but originally it is a type with a lot of instances and procedures) In fact - I could have had advance as a function that returns a type - but then I would be paying the price of copyin assignment of a big type. Anyway - you conclude that gfortran is behaving as it should and that the fact that ifort works - is somewhat a coincidence?
[Bug fortran/101199] program changes the value of a dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101199 --- Comment #5 from Jürgen Reuter --- (In reply to ygal klein from comment #4) >) > > Thank you for the reply. > > After posting the bug report - I saw that implementing (inout) as your > number 1 suggestion - dodges the problem - though as you mentioned having > inout for this in an init routine is somewhat unnatural. > > The 2nd suggestion is something that I was trying to avoid in the first > place - i.e copying a whole type (this minimal example is a small type - but > originally it is a type with a lot of instances and procedures) > > In fact - I could have had advance as a function that returns a type - but > then I would be paying the price of copyin assignment of a big type. > > Anyway - you conclude that gfortran is behaving as it should and that the > fact that ifort works - is somewhat a coincidence? Let's see what the gfortran developers have to say about this. In any case it looks strange if you try to call an init routine from a different TBP of the same object. An init routine is usually called only at the very instantiation of the object. If you want a shallow copy then you need a pointer.
[Bug c++/101210] New: [7/8/9/10/11/12 regression] spurious "reference binding to misaligned address" ubsan error for integer comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101210
Bug ID: 101210
Summary: [7/8/9/10/11/12 regression] spurious "reference
binding to misaligned address" ubsan error for integer
comparison
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jlegg at feralinteractive dot com
Target Milestone: ---
With -fsanitize=undefined, this C++ code:
int main()
{
int x;
int & y {x};
return reinterpret_cast(&y) == 1;
}
Produces this error at runtime:
test.cc:5:40: runtime error: reference binding to misaligned address
0x0001 for type 'int', which requires 4 byte alignment
0x0001: note: pointer points here
However, address 1 is never bound to a reference to an int. It is an integer
which is compared to another integer (which happens to be pointer sized and
derived from an address taken from a reference).
Checking various versions with compiler explorer, GCC 6 did not have this
issue, but later releases did.
[Bug libstdc++/101211] New: [12 regression] 17_intro/names.cc fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101211 Bug ID: 101211 Summary: [12 regression] 17_intro/names.cc fails Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- I've noticed that 17_intro/names.cc fails to compile on arm/aarch64 (and others according to gcc-testresults): FAIL: 17_intro/names.cc (test for excess errors) Excess errors: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/sysroot-arm-none-linux-gnueabi/usr/include/sys/ucontext.h:89: error: expected unqualified-id before ':' token /aci-gcc-fsf/builds/gcc-fsf-gccsrc/sysroot-arm-none-linux-gnueabi/usr/include/sys/ucontext.h:89: error: expected ')' before ':' token This appeared between r12-1737 and r12-1744
[Bug libstdc++/101211] [12 regression] 17_intro/names.cc fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101211 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-06-25 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- Presumably r12-1742 Is __lockable used as an identifier in that header? Maybe I need to revert the change to the test. But then we won't have any verification that we don't reintroduce the name __lockable, which breaks newlib targets.
[Bug libstdc++/101211] [12 regression] 17_intro/names.cc fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101211 --- Comment #2 from Jonathan Wakely --- Oh, is it this? unsigned int j:1;
[Bug libstdc++/101211] [12 regression] 17_intro/names.cc fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101211
--- Comment #3 from Jonathan Wakely ---
Ah, I bet it started to fail because I added this to the test:
{ dg-add-options no_pch }
So this should fix it for arm:
--- a/libstdc++-v3/testsuite/17_intro/names.cc
+++ b/libstdc++-v3/testsuite/17_intro/names.cc
@@ -208,6 +208,11 @@
#undef r
#endif
+#if defined (__linux__) && defined (__arm__)
+// defines fpregset_t::fpregs::j
+#undef j
+#endif
+
#if defined (__linux__) && defined (__powerpc__)
// defines __vector128::u
#undef u
What is the exact error for aarch64?
[Bug libstdc++/101211] [12 regression] 17_intro/names.cc fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101211 --- Comment #4 from Christophe Lyon --- It works for aarch64-linux-gnu, but fails for aarch64-elf (with newlib): FAIL: 17_intro/names.cc (test for excess errors) Excess errors: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:194: error: expected ')' before ';' token /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:195: error: expected ')' before ';' token /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:196: error: expected ')' before ';' token /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:197: error: expected ')' before ';' token /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:198: error: expected ')' before ';' token /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:199: error: expected ')' before ';' token /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:200: error: expected ')' before ';' token /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:201: error: expected ')' before ';' token /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/time.h:110: error: expected unqualified-id before ';' token /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/time.h:110: error: expected ')' before ';' token /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/inttypes.h:323: error: expected ')' before ';' token
[Bug libstdc++/101211] [12 regression] 17_intro/names.cc fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101211
--- Comment #5 from Jonathan Wakely ---
(In reply to Christophe Lyon from comment #4)
> It works for aarch64-linux-gnu, but fails for aarch64-elf (with newlib):
> FAIL: 17_intro/names.cc (test for excess errors)
> Excess errors:
> /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:194:
> error: expected ')' before ';' token
> /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:195:
> error: expected ')' before ';' token
> /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:196:
> error: expected ')' before ';' token
> /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:197:
> error: expected ')' before ';' token
> /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:198:
> error: expected ')' before ';' token
> /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:199:
> error: expected ')' before ';' token
> /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:200:
> error: expected ')' before ';' token
> /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:201:
> error: expected ')' before ';' token
I think that's due to bugs in newlib's on these lines:
extern int __isinff (float x);
extern int __isinfd (double x);
extern int __isnanf (float x);
extern int __isnand (double x);
extern int __fpclassifyf (float x);
extern int __fpclassifyd (double x);
extern int __signbitf (float x);
extern int __signbitd (double x);
Those should use __x not x.
> /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/time.h:110:
> error: expected unqualified-id before ';' token
> /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/time.h:110:
> error: expected ')' before ';' token
Non-reserved names in this newlib type:
typedef struct __tzrule_struct
{
char ch;
int m;
int n;
int d;
int s;
time_t change;
long offset; /* Match type of _timezone. */
} __tzrule_type;
I'll have to adjust the test for that.
> /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/inttypes.h:
> 323: error: expected ')' before ';' token
This is a newlib bug:
extern intmax_t imaxabs(intmax_t j);
It should be using __j here, and similarly for the next line:
extern imaxdiv_t imaxdiv(intmax_t numer, intmax_t denomer);
[Bug c/101212] New: forward declaration of parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101212
Bug ID: 101212
Summary: forward declaration of parameter
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
In the following function definition GCC does not warn about the forward
declaration of 'x' which then is not a parameter.
void foo(int x;)
{
}
[Bug c++/101213] New: Improve support for decltype(std)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101213
Bug ID: 101213
Summary: Improve support for decltype(std)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: llvm at rifkin dot dev
Target Milestone: ---
Gcc treats decltype(std) as an integer. It only works in some situations
though:
// OK
decltype(std) a;
static_assert(std::is_same::value);
// Not OK
static_assert(std::is_same::value);
// OK
decltype(std) a;
using b = decltype(a);
using c = b;
// Not OK
using a = decltype(std);
using b = a;
decltype(std) foo(int a) {} // OK
auto foo() -> decltype(std) {} // OK
void foo(decltype(std) a) {} // Not OK
// Not OK
std::vector v;
This bug is hilarious please improve support for it and make it a feature :)
It's invaluable for code bowling and nerd sniping.
[Bug testsuite/101114] new test case libgomp.c/../libgomp.c-c++-common/struct-elem-5.c fails after its introduction in r12-1565
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101114 --- Comment #3 from CVS Commits --- The master branch has been updated by Chung-Lin Tang : https://gcc.gnu.org/g:e0672017370b9a9362fda52ecffe33d1c9c41829 commit r12-1813-ge0672017370b9a9362fda52ecffe33d1c9c41829 Author: Chung-Lin Tang Date: Sat Jun 26 00:42:58 2021 +0800 testsuite/101114: Adjust libgomp.c-c++-common/struct-elem-5.c testcase The dg-shouldfail testcase libgomp.c-c++-common/struct-elem-5.c does not properly fail for non-shared address space offloading. Adjust testcase to limit testing only for "target offload_device_nonshared_as". libgomp/ChangeLog: PR testsuite/101114 * testsuite/libgomp.c-c++-common/struct-elem-5.c: Add "target offload_device_nonshared_as" condition for enabling test.
[Bug c++/101210] [9/10/11/12 regression] spurious "reference binding to misaligned address" ubsan error for integer comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101210 Jakub Jelinek changed: What|Removed |Added Summary|[7/8/9/10/11/12 regression] |[9/10/11/12 regression] |spurious "reference binding |spurious "reference binding |to misaligned address" |to misaligned address" |ubsan error for integer |ubsan error for integer |comparison |comparison CC||jakub at gcc dot gnu.org Target Milestone|--- |9.5 --- Comment #1 from Jakub Jelinek --- I think this is caused by the PR70920 fix r7-2226-g8f63caf6826e918678482413161e34b037a13fa7 We have (long) y == 1 where y has REFERENCE_TYPE and that match.pd rule transforms it into y == 1 where 1 has also that REFERENCE_TYPE. As ubsan instrumentation happens on partially GENERIC folded trees, doing that in GENERIC for REFERENCE_TYPE is wrong, we should defer it to GIMPLE.
[Bug c++/101213] Improve support for decltype(std)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101213 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Jonathan Wakely --- This is just how GCC recovers from a bad parse, so that it can attempt to continue and give diagnostics for the rest of the code. An invalid type in certain declaration contexts is replaced with 'int'. Often it does more harm than good, because you get errors about int::foo being invalid because it's not a class type (which is true, but then it wasn't int in the original code!) I've sometimes wondered whether it would be better to use an invented, incomplete class type as the default instead of int. On balance, most un-parseable types are probably classes, not fundamental types.
[Bug c++/92105] [8/9/10 Regression] decltype(decltype(decltype)) prints exponential number of repeated errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92105 --- Comment #7 from Jonathan Wakely --- Glad we could help ;-)
[Bug libstdc++/101211] [12 regression] 17_intro/names.cc fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101211 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #5) > (In reply to Christophe Lyon from comment #4) > > It works for aarch64-linux-gnu, but fails for aarch64-elf (with newlib): > > FAIL: 17_intro/names.cc (test for excess errors) > > Excess errors: > > /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:194: > > error: expected ')' before ';' token > > /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:195: > > error: expected ')' before ';' token > > /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:196: > > error: expected ')' before ';' token > > /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:197: > > error: expected ')' before ';' token > > /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:198: > > error: expected ')' before ';' token > > /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:199: > > error: expected ')' before ';' token > > /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:200: > > error: expected ')' before ';' token > > /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/math.h:201: > > error: expected ')' before ';' token > > I think that's due to bugs in newlib's on these lines: > > > extern int __isinff (float x); > extern int __isinfd (double x); > extern int __isnanf (float x); > extern int __isnand (double x); > extern int __fpclassifyf (float x); > extern int __fpclassifyd (double x); > extern int __signbitf (float x); > extern int __signbitd (double x); > > Those should use __x not x. Which you already fixed: commit 4c49accf8997da21be19be0396b2a88f33b9f949 Author: Christophe Lyon Date: Mon Sep 21 15:22:30 2020 + libc/include/math.h: Remove parameter name As discussed in GCC bug 97088 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97088), parameters in prototypes of library functions should use reserved names, or no name at all. > > /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/include/inttypes.h: > > 323: error: expected ')' before ';' token > > This is a newlib bug: > extern intmax_t imaxabs(intmax_t j); > > It should be using __j here, and similarly for the next line: > extern imaxdiv_t imaxdiv(intmax_t numer, intmax_t denomer); That was fixed in newlib a few months ago as well: commit 615cf4bdce0de86e57bdc27e008a35dd713e483f Author: Torbjörn SVENSSON Date: Thu Oct 1 12:44:43 2020 +0200 libc/include/inttypes.h: Remove parameter name As discussed in GCC bug 97088 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97088), parameters in prototypes of library functions should use reserved names, or no name at all.
[Bug libstdc++/101211] [12 regression] 17_intro/names.cc fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101211 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #7 from Jonathan Wakely --- dup, but it now happens without --disable-libstdcxx-pch because the test disables pch itself. *** This bug has been marked as a duplicate of bug 97088 ***
[Bug libstdc++/97088] 17_intro/names.cc and experimental/names.cc fail with --disable-libstdcxx-pch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97088 --- Comment #5 from Jonathan Wakely --- *** Bug 101211 has been marked as a duplicate of this bug. ***
[Bug libstdc++/97088] 17_intro/names.cc and experimental/names.cc fail with --disable-libstdcxx-pch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97088
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-06-25
--- Comment #6 from Jonathan Wakely ---
This now happens even without --disable-libstdcxx-pch because in r12-1742 I
added
{ dg-add-options no_pch }
which means the PCH headers aren't used for the test.
[Bug c++/101214] New: ranges::split_view::sentinel lacks default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101214
Bug ID: 101214
Summary: ranges::split_view::sentinel lacks default
constructor
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
#include
int main() {
auto r = std::views::iota(0) | std::views::take(5);
decltype(std::views::split(r, 0).end()) e{};
}
https://godbolt.org/z/oK9zbE5WG
[Bug c++/43933] Suboptimal error message when supplying a bad default value in initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43933 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #5) > It's not fixed in GCC 9 though. I think it's probably fixed by r11-2546 for > PR 94024 but I can't bisect right now. Confirmed as that revision. *** This bug has been marked as a duplicate of bug 94024 ***
[Bug c++/94024] Error message has misleading source location for constructor member initialisation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94024 Jonathan Wakely changed: What|Removed |Added CC||bero at arklinux dot org --- Comment #5 from Jonathan Wakely --- *** Bug 43933 has been marked as a duplicate of this bug. ***
[Bug libstdc++/101214] ranges::split_view::sentinel lacks default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101214
--- Comment #1 from 康桓瑋 ---
(In reply to 康桓瑋 from comment #0)
> #include
>
> int main() {
> auto r = std::views::iota(0) | std::views::take(5);
> decltype(std::views::split(r, 0).end()) e{};
> }
>
Another tiny issue is that in ranges#L3309:
constexpr
split_view(_Range&& __r, range_value_t<_Range> __e)
: _M_pattern(views::single(__e)),
_M_base(views::all(std::forward<_Range>(__r)))
{ }
it should be _M_pattern(views::single(std::move(__e))) just like
lazy_split_view.
[Bug c++/101213] Improve support for decltype(std)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101213 --- Comment #2 from Jeremy R. --- (In reply to Jonathan Wakely from comment #1) > This is just how GCC recovers from a bad parse, so that it can attempt to > continue and give diagnostics for the rest of the code. An invalid type in > certain declaration contexts is replaced with 'int'. Often it does more harm > than good, because you get errors about int::foo being invalid because it's > not a class type (which is true, but then it wasn't int in the original > code!) > > I've sometimes wondered whether it would be better to use an invented, > incomplete class type as the default instead of int. On balance, most > un-parseable types are probably classes, not fundamental types. That's super cool, thanks for the insight into why decltype(std) is replaced with int in the first place. Is the substitution but lack of diagnostic intentional in a case like this https://godbolt.org/z/K91j35rTs? The lack of diagnostic is of course appreciated for code bowling :) What's the reason why this substitution is only made in certain contexts?
[Bug target/100952] [12 regression] several test case failures after r12-1202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952 --- Comment #8 from seurer at gcc dot gnu.org --- I just tried with current trunk: g:e0672017370b9a9362fda52ecffe33d1c9c41829, r12-1813 make -k check-gcc-fortran RUNTESTFLAGS="dg.exp=gfortran.dg/parity_1.f90" FAIL: gfortran.dg/parity_1.f90 -O0 execution test # of expected passes11 # of unexpected failures1 My configure is pretty simple: /home/seurer/gcc/git/gcc-test/configure --prefix=/home/seurer/gcc/git/install/gcc-test --enable-languages=c,fortran,c++ --with-cpu=power10 --disable-bootstrap --with-as=/home/seurer/binutils/install/bin/as --with-ld=/home/seurer/binutils/install/bin/ld --with-ar=/home/seurer/binutils/install/bin/ar The --with-XX things are to pick up the 2.36.1 version of binutils which is also on my path.
[Bug c++/100975] [C++23] Allow pointer to array of auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100975
--- Comment #2 from Marek Polacek ---
Looks like just disabling the check in create_array_type_for_decl lets us
compile:
struct false_type { static constexpr bool value = false; };
struct true_type { static constexpr bool value = true; };
template
struct is_same : false_type {};
template
struct is_same : true_type {};
void
g ()
{
int a[3];
auto (*p)[3] = &a;
auto (&r)[3] = a;
static_assert (is_same::value);
static_assert (is_same::value);
}
[Bug libstdc++/97088] 17_intro/names.cc and experimental/names.cc fail with --disable-libstdcxx-pch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97088 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e83a5a6b6893e910dc0b6b1cd034e1a258406c93 commit r12-1814-ge83a5a6b6893e910dc0b6b1cd034e1a258406c93 Author: Jonathan Wakely Date: Fri Jun 25 18:31:22 2021 +0100 libstdc++: More workarounds in 17_intro/names.cc test [PR 97088] Conditionally #undef some more names that are used in system headers. libstdc++-v3/ChangeLog: PR libstdc++/97088 * testsuite/17_intro/names.cc: Undef more names for newlib and also for arm-none-linux-gnueabi. * testsuite/experimental/names.cc: Disable PCH.
[Bug libstdc++/101214] ranges::split_view::sentinel lacks default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101214 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-06-25 CC||ppalka at gcc dot gnu.org
[Bug target/101215] New: Using non-standard custom linker with -fuse-ld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101215 Bug ID: 101215 Summary: Using non-standard custom linker with -fuse-ld Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: freesoftware at logarithmus dot dev Target Milestone: --- Hello. I'd like to have an ability to use custom linkers with gcc. Unfortunately gcc's `-fuse-ld` option only supports fixed set of linkers: ld, gold & lld. On the other hand, clang supports passing path to linker's binary with `-fuse-ld`. My specific use case is novell `mold` linker: https://github.com/rui314/mold I know that I can use mold like this: `mold -run gcc `. But it works by intercepting system calls and changing all calls to `ld` with `mold`. It looks kinda hacky to be honest. So I think the best solution would be to implement custom linkers support into gcc. I've never worked with gcc codebase before, so I'll appreciate any guidance about implementing this feature.
[Bug middle-end/101216] New: [12 regression] setjmp/longjmp excess errors after r12-1805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101216
Bug ID: 101216
Summary: [12 regression] setjmp/longjmp excess errors after
r12-1805
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
g:e9e2bad7251477db92ab9ebcdc010f9282dd9890, r12-1805
make -k check-gcc RUNTESTFLAGS="analyzer.exp=gcc.dg/analyzer/setjmp-2.c"
FAIL: gcc.dg/analyzer/setjmp-2.c (test for excess errors)
# of expected passes2
# of unexpected failures1
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/setjmp-2.c
-fdiagnostics-plain-output -fanalyzer -Wanalyzer-too-complex
-fanalyzer-call-summaries -fdiagnostics-show-line-numbers
-fdiagnostics-path-format=inline-events -fdiagnostics-show-caret -S -o
setjmp-2.s
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/setjmp-2.c: In
function 'test_2':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/setjmp-2.c:30:7:
note: path
30 | __analyzer_dump_path (); /* { dg-message "path" } */
| ^~~
'test_2': event 1
|
| 23 | i = SETJMP(env);
| | ^~
| | |
| | (1) 'setjmp' called here
|
'test_2': events 2-4
|
| 27 | if (i != 0)
| | ^
| | |
| | (2) following 'false' branch (when 'i == 0')...
|..
| 33 | longjmp (env, 1);
| |
| | |
| | (3) ...to here
| | (4) rewinding within 'test_2' from 'longjmp'...
|
'test_2': event 5
|
| 23 | i = SETJMP(env);
| | ^~
| | |
| | (5) ...to 'setjmp' (saved at (1))
|
'test_2': events 6-8
|
| 27 | if (i != 0)
| | ^
| | |
| | (6) following 'true' branch (when 'i != 0')...
| 28 | {
| 29 | foo (2);
| | ~~~
| | |
| | (7) ...to here
| 30 | __analyzer_dump_path (); /* { dg-message "path" } */
| | ~~~
| | |
| | (8) here
|
In file included from
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/setjmp-2.c:5:
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/setjmp-2.c: In
function 'test_1':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/test-setjmp.h:19:12:
note: in a call to function 'setjmp'
19 | extern int setjmp(jmp_buf env);
|^~
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/setjmp-2.c: In
function 'test_3':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/test-setjmp.h:22:13:
note: in a call to function 'longjmp'
22 | extern void longjmp(jmp_buf env, int val);
| ^~~
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/setjmp-2.c: In
function 'test_4':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/test-setjmp.h:22:13:
note: in a call to function 'longjmp'
PASS: gcc.dg/analyzer/setjmp-2.c (test for warnings, line 30)
PASS: gcc.dg/analyzer/setjmp-2.c expected multiline pattern lines 39-83 was
found: "\s*NN \| __analyzer_dump_path \(\);.*\n \|
\^~~\n 'test_2': event 1.*\n\|.*\n\| NN \| i =
SETJMP\(env\);.*\n\| \| \^~\n\| \| \|.*\n
\| \| \(1\) 'setjmp' called here.*\n\|.*\n 'test_2': events
2-4.*\n\|.*\n\| NN \| if \(i != 0\).*\n\| \| \^\n
\| \| \|.*\n\| \| \(2\) following 'false' branch \(when
'i == 0'\)\.\.\..*\n\|\.\.\.\.\.\..*\n\| NN \| longjmp \(env,
1\);.*\n\| \| \n\| \| \|.*\n\|
\| \(3\) \.\.\.to here.*\n\| \| \(4\) rewinding within
'test_2' from 'longjmp'\.\.\..*\n\|.*\n 'test_2': event 5.*\n\|.*\n
\| NN \| i = SETJMP\(env\);.*\n\| \| \^~\n\| \|
\|.*\n\| \| \(5\) \.\.\.to 'setjmp' \(saved at \(1\)\).*\n
\|.*\n 'test_2': events 6-8.*\n\|.*\n\| NN \| if \(i != 0\).*\n
\| \| \^\n\| \| \|.*\n\| \| \(6\)
following 'true' branch \(when 'i != 0'\)\.\.\..*\n\| NN \| \{.*\n
\| NN \| foo \(2\);.*\n\| \| ~~~\n\| \|
\|.*\n\| \| \(7\) \.\.\.to here.*\n\| NN \|
__analyzer_dump_path \(\);.*\n\| \| ~~~\n
\| \| \|.*\n\| \| \(8\) he
[Bug c++/101194] [9/10/11/12 Regression] aggregate init requires default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101194 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug middle-end/101216] [12 regression] setjmp/longjmp excess errors after r12-1805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101216 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Target|powerpc64-linux-gnu,|powerpc64-linux-gnu, |powerpc64le-linux-gnu |powerpc64le-linux-gnu, ||aarch64-linux-gnu Keywords||diagnostic Ever confirmed|0 |1 Build|powerpc64-linux-gnu,| |powerpc64le-linux-gnu | CC||pinskia at gcc dot gnu.org Host|powerpc64-linux-gnu,| |powerpc64le-linux-gnu | Status|UNCONFIRMED |NEW Last reconfirmed||2021-06-25 --- Comment #1 from Andrew Pinski --- I Noticed this failure too on aarch64-linux-gnu.
[Bug target/101215] Using non-standard custom linker with -fuse-ld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101215 --- Comment #1 from Jonathan Wakely --- I think you should be able to build GCC with --with-ld=/path/to/mold you just can't select it later using -fuse-ld
[Bug target/101215] Using non-standard custom linker with -fuse-ld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101215 --- Comment #2 from logarithmus.dev at gmail dot com --- I think that making `-fuse-ld` to accept arbitrary path to linker's binary instead of adding `mold` to the list of predefined values is a much better strategy in long term. AFAIK clang already does this. On Fri, 2021-06-25 at 20:28 +, redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101215 > > --- Comment #1 from Jonathan Wakely --- > I think you should be able to build GCC with --with-ld=/path/to/mold > you just > can't select it later using -fuse-ld >
[Bug middle-end/101216] [12 regression] setjmp/longjmp excess errors after r12-1805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101216 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug driver/101215] Using non-standard custom linker with -fuse-ld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101215 H.J. Lu changed: What|Removed |Added Last reconfirmed||2021-06-25 Status|UNCONFIRMED |NEW Keywords||patch Ever confirmed|0 |1 --- Comment #3 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550340.html
[Bug driver/101215] Using non-standard custom linker with -fuse-ld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101215 H.J. Lu changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from H.J. Lu --- Dup *** This bug has been marked as a duplicate of bug 93645 ***
[Bug driver/93645] Support Clang 12 --ld-path=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645 H.J. Lu changed: What|Removed |Added CC||freesoftware at logarithmus dot de ||v --- Comment #7 from H.J. Lu --- *** Bug 101215 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/56223] Integer ABS is not recognized for more complicated pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56223 Andrew Pinski changed: What|Removed |Added Depends on||101205 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #7) > (In reply to Andrew Pinski from comment #5) > > I also noticed that factor_out_conditional_conversion has a similar issue > > where the cast is inside both if and else part. > > I have a fix for that, though we don't remove one of the BB if it becomes > empty. I have a patch for that but I ran into a code generation regression on aarch64, PR 101205. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101205 [Bug 101205] csinv does not have an zero_extend version
[Bug driver/56062] Enhance -fuse-ld= option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56062 Andrew Pinski changed: What|Removed |Added Resolution|WONTFIX |DUPLICATE --- Comment #6 from Andrew Pinski --- Dup of bug 93645. *** This bug has been marked as a duplicate of bug 93645 ***
[Bug driver/93645] Support Clang 12 --ld-path=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93645 Andrew Pinski changed: What|Removed |Added CC||d.g.gorbachev at gmail dot com --- Comment #8 from Andrew Pinski --- *** Bug 56062 has been marked as a duplicate of this bug. ***
[Bug middle-end/101217] New: Stray "note" diagnostics when warning suppressed in gcc.dg/analyzer/setjmp-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101217
Bug ID: 101217
Summary: Stray "note" diagnostics when warning suppressed in
gcc.dg/analyzer/setjmp-2.c
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: msebor at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573695.html reports
On Linux/x86_64,
e9e2bad7251477db92ab9ebcdc010f9282dd9890 is the first bad commit
commit e9e2bad7251477db92ab9ebcdc010f9282dd9890
Author: Martin Sebor
Date: Thu Jun 24 19:22:06 2021 -0600
middle-end: add support for per-location warning groups.
caused
FAIL: gcc.dg/analyzer/setjmp-2.c (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-1805/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="analyzer.exp=gcc.dg/analyzer/setjmp-2.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="analyzer.exp=gcc.dg/analyzer/setjmp-2.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="analyzer.exp=gcc.dg/analyzer/setjmp-2.c
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="analyzer.exp=gcc.dg/analyzer/setjmp-2.c
--target_board='unix{-m64\ -march=cascadelake}'"
I can reproduce this without the analyzer via:
$ ./xgcc -B. ../../src/gcc/testsuite/gcc.dg/analyzer/setjmp-2.c -S
In file included from ../../src/gcc/testsuite/gcc.dg/analyzer/setjmp-2.c:5:
../../src/gcc/testsuite/gcc.dg/analyzer/setjmp-2.c: In function ‘test_1’:
../../src/gcc/testsuite/gcc.dg/analyzer/test-setjmp.h:19:12: note: in a call to
function ‘setjmp’
19 | extern int setjmp(jmp_buf env);
|^~
../../src/gcc/testsuite/gcc.dg/analyzer/setjmp-2.c: In function ‘test_3’:
../../src/gcc/testsuite/gcc.dg/analyzer/test-setjmp.h:22:13: note: in a call to
function ‘longjmp’
22 | extern void longjmp(jmp_buf env, int val);
| ^~~
../../src/gcc/testsuite/gcc.dg/analyzer/setjmp-2.c: In function ‘test_4’:
../../src/gcc/testsuite/gcc.dg/analyzer/test-setjmp.h:22:13: note: in a call to
function ‘longjmp’
Looks like notes are emitted here:
#5 0x00994645 in maybe_warn_rdwr_sizes (rwm=0x7fffca60,
fndecl=,
fntype=, exp=) at
../../src/gcc/calls.c:2231
2231inform (DECL_SOURCE_LOCATION (fndecl),
(gdb) list
2226fntype, attrstr);
2227}
2228 else if (opt_warned != N_OPTS)
2229{
2230 if (fndecl)
2231inform (DECL_SOURCE_LOCATION (fndecl),
2232"in a call to function %qD", fndecl);
Looks like something's wrong with the way this interacts with the
TREE_NO_WARNING rewrite.
[Bug middle-end/101217] Stray "note" diagnostics when warning suppressed in gcc.dg/analyzer/setjmp-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101217 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 101216. *** This bug has been marked as a duplicate of bug 101216 ***
[Bug middle-end/101216] [12 regression] setjmp/longjmp excess errors after r12-1805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101216 Andrew Pinski changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- *** Bug 101217 has been marked as a duplicate of this bug. ***
[Bug middle-end/101216] [12 regression] setjmp/longjmp excess "note" when warning suppressed after r12-1805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101216 David Malcolm changed: What|Removed |Added Summary|[12 regression] |[12 regression] |setjmp/longjmp excess |setjmp/longjmp excess |errors after r12-1805 |"note" when warning ||suppressed after r12-1805 --- Comment #3 from David Malcolm --- As noted in bug 101217 this doesn't need -fanalyzer to reproduce; stray "note"s are coming from calls.c
[Bug middle-end/101216] [12 regression] setjmp/longjmp excess "note" when warning suppressed after r12-1805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101216 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:fd51b344ca86c9673db0161d4a383cccdb2f429c commit r12-1819-gfd51b344ca86c9673db0161d4a383cccdb2f429c Author: Martin Sebor Date: Fri Jun 25 17:01:01 2021 -0600 PR middle-end/101216 - spurious notes for function calls PR middle-end/101216 gcc/ChangeLog: * calls.c (maybe_warn_rdwr_sizes): Use the no_warning constant. gcc/testsuite/ChangeLog: * gcc.dg/Wnonnull-7.c: New test.
[Bug middle-end/101216] [12 regression] setjmp/longjmp excess "note" when warning suppressed after r12-1805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101216 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Sebor --- Fixed.
[Bug middle-end/101204] infinite recursion in gtype-desc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101204 --- Comment #2 from Martin Sebor --- gtype-desc.c is a generated file. There's also r12-1096. Without it, r12-1801 wouldn't compile.
[Bug c++/100752] [11/12 Regression] error: cannot call member function ‘void S::f()’ without object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100752 --- Comment #5 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:f9c80eb12c58126a94ad869380af5b88b752c06f commit r12-1822-gf9c80eb12c58126a94ad869380af5b88b752c06f Author: Marek Polacek Date: Tue Jun 8 17:44:13 2021 -0400 c++: Failure to delay noexcept parsing with ptr-operator [PR100752] We weren't passing 'flags' to the recursive call to cp_parser_declarator in the ptr-operator case and as an effect, delayed parsing of noexcept didn't work as advertised. The following change passes more than just CP_PARSER_FLAGS_DELAY_NOEXCEPT but that doesn't seem to break anything. I'm now also passing member_p and static_p, as a consequence, two tests needed small tweaks. PR c++/100752 gcc/cp/ChangeLog: * parser.c (cp_parser_declarator): Pass flags down to cp_parser_declarator. Also pass static_p/member_p. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/noexcept69.C: New test. * g++.dg/parse/saved1.C: Adjust dg-error. * g++.dg/template/crash50.C: Likewise.
[Bug c++/100752] [11 Regression] error: cannot call member function ‘void S::f()’ without object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100752 Marek Polacek changed: What|Removed |Added Summary|[11/12 Regression] error: |[11 Regression] error: |cannot call member function |cannot call member function |‘void S::f()’ without |‘void S::f()’ without |object |object --- Comment #6 from Marek Polacek --- Fixed on trunk so far.
[Bug c/101218] New: ICE on valid code with -O3 only: Segmentation fault, vect_optimize_slp(vec_info*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101218
Bug ID: 101218
Summary: ICE on valid code with -O3 only: Segmentation fault,
vect_optimize_slp(vec_info*)
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cnsun at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.buHCZx7AOn-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210625 (experimental) [master revision
:1cefadb26:e9e2bad7251477db92ab9ebcdc010f9282dd9890] (GCC)
$ cat mutant.c
unsigned fib[];
count_fib() {
int i;
fib[1] = 1;
for (i = 2; i < 1000; i++)
fib[i] = fib[i - 1] + fib[i - 2];
}
$ gcc-trunk -O3 mutant.c
mutant.c:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
2 | count_fib() {
| ^
mutant.c:1:10: warning: array ‘fib’ assumed to have one element
1 | unsigned fib[];
| ^~~
mutant.c: In function ‘count_fib’:
mutant.c:6:30: warning: iteration 1 invokes undefined behavior
[-Waggressive-loop-optimizations]
6 | fib[i] = fib[i - 1] + fib[i - 2];
| ~~~^~~
mutant.c:5:17: note: within this loop
5 | for (i = 2; i < 1000; i++)
| ~~^~
during GIMPLE pass: slp
mutant.c:2:1: internal compiler error: Segmentation fault
2 | count_fib() {
| ^
0xf13763 crash_signal
/tmp/tmp.buHCZx7AOn-gcc-builder/gcc/gcc/toplev.c:327
0x11e1f55 vect_optimize_slp(vec_info*)
/tmp/tmp.buHCZx7AOn-gcc-builder/gcc/gcc/tree-vect-slp.c:3694
0x11eb481 vect_optimize_slp(vec_info*)
/tmp/tmp.buHCZx7AOn-gcc-builder/gcc/gcc/tree-vect-slp.c:5644
0x11eb481 vect_slp_analyze_bb_1
/tmp/tmp.buHCZx7AOn-gcc-builder/gcc/gcc/tree-vect-slp.c:5608
0x11eb481 vect_slp_region
/tmp/tmp.buHCZx7AOn-gcc-builder/gcc/gcc/tree-vect-slp.c:5695
0x11ec5c8 vect_slp_bbs
/tmp/tmp.buHCZx7AOn-gcc-builder/gcc/gcc/tree-vect-slp.c:5845
0x11ec9fc vect_slp_function(function*)
/tmp/tmp.buHCZx7AOn-gcc-builder/gcc/gcc/tree-vect-slp.c:5931
0x11f3761 execute
/tmp/tmp.buHCZx7AOn-gcc-builder/gcc/gcc/tree-vectorizer.c:1445
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug fortran/101135] Use of absent assumed-shape array argument as an actual argument for an optional dummy argument mistakenly flagged as error by UndefinedBehaviourSanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101135 --- Comment #1 from Marcel Jacobse --- With some bisecting I managed to track this down to commit https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=243c288370fe51ba55c3a9ee61eb2a1a62cb1279 being the first "faulty" one. >From what I can tell the commit aimed to catch null pointer dereferences in more cases. Not sure if this means that the commit made the check to broad so that it generates false positives for this Fortran case. Or if gfortran perhaps generates intermediate representation that is not quite valid and is correctly flagged by UBSan.
[Bug tree-optimization/101145] niter analysis fails for until-wrap condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145
--- Comment #7 from bin cheng ---
(In reply to Jiu Fu Guo from comment #5)
> (In reply to bin cheng from comment #4)
> > (In reply to Jiu Fu Guo from comment #3)
> > > Yes, while the code in adjust_cond_for_loop_until_wrap seems somehow
> > > tricky:
> > >
> > > /* Only support simple cases for the moment. */
> > > if (TREE_CODE (iv0->base) != INTEGER_CST
> > > || TREE_CODE (iv1->base) != INTEGER_CST)
> > > return false;
> > >
> > > This code requires both sides are constant.
> > Actually it requires an IV with constant base.
>
> I also feel that the intention of this function may only require one side
> constant for IV0 CODE IV1.
> As tests, for below loop, adjust_cond_for_loop_until_wrap return false:
>
> foo (int *__restrict__ a, int *__restrict__ b, unsigned i)
> {
> while (++i > 100)
> *a++ = *b++ + 1;
> }
>
> For below code, adjust_cond_for_loop_until_wrap returns true:
> i = UINT_MAX - 200;
> while (++i > 100)
> *a++ = *b++ + 1;
Oh sorry for being misleading. When I mentioned it requires something(...), I
was describing the current behavior, not that the conditions are necessary.
Feel free to improve such cases. Looking into niter analysis, these
cases(trade-offs) are not rare.
Thanks
[Bug c/98892] FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98892
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #2 from Jim Wilson ---
I ran into this with a riscv toolchain make check.
Debugging, I discovered that if my terminal window is 80 characters wide, then
context->max_caret_width gets set to 78 in diagnostic.c, and then in
diagnostic-show-locus.c m_x_offset_display gets set to 9, and then in
print_trailing_fixits it calls move_to_column with column set to 9 which causes
an extra unnecessary newline to be emitted. This extra newline leads to the "1
blank lines in output" error. Also, I suspect that there is a contributing bug
in the dg-{begin,end}-multiline-output support that causes it to fail when an
error is followed by two newlines. This causes the "expected multiline pattern
lines 550-551" failure.
A bit of experimenting with the testcase in isolation shows that if my screen
is 88 chars wide there is no extra newline, and if my screen is 87 chars wide I
get the extra newline.
A bit of experimenting with RUNTESTFLAGS="plugin.exp" show that the testcase
fails every time when my screen is 80 characters wide and works everytime when
my screen is 81 characters wide. I don't know why this number is different
than above.
A testcase whose success depends on screen width is very annoying.
One way to work around the problem is to make the line shorter. If I delete
one tab char from line 548 of gcc.dg/plugin/diagnostic-test-expressions-1.c and
8 space characters from the two matching error lines 550 and 551, then the
testcase does work with an 80 character wide terminal. However, it does now
fail with a 77 char wide screen due to a different line 415-416. So this isn't
an ideal solution. But it works for me as my screens are always 80 characters
wide.
ideally there should be a way to turn off the max_caret_width stuff when
running the testsuite so results don't depend on screen width. Someone who
knows the diagnostic code should probably look at this.
Or maybe print_trailing_fixits can be fixed? It isn't obvious why it needs to
call move_to_column at the end.
[Bug c++/97566] [[no_unique_address]] causes miscompiles when mixed with EBO in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97566 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2168bfb81448ae1bfa4351760a23d4ec051c2a00 commit r12-1827-g2168bfb81448ae1bfa4351760a23d4ec051c2a00 Author: Jason Merrill Date: Thu Jun 24 17:32:02 2021 -0400 c++: constexpr aggr init of empty class [PR101040] This is basically the aggregate initializer version of PR97566; as in that bug, we are trying to initialize empty field 'obj' in 'single' when there's no CONSTRUCTOR entry for the 'single' base class subobject of 'derived'. As with that bug, the fix is to stop trying to add entries for empty fields, this time in cxx_eval_bare_aggregate. The change to the other function isn't necessary for this version of the patch, but seems worthwhile for robustness anyway. PR c++/101040 PR c++/97566 gcc/cp/ChangeLog: * class.c (is_empty_field): Handle null argument. * constexpr.c (cxx_eval_bare_aggregate): Discard initializer for empty field. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/no_unique_address13.C: New test.
[Bug c++/101040] [11/12 Regression] Internal compiler error: in get_or_insert_ctor_field, at cp/constexpr.c:3571 since r11-7980-gc3d3bb0f03dbd025
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101040 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2168bfb81448ae1bfa4351760a23d4ec051c2a00 commit r12-1827-g2168bfb81448ae1bfa4351760a23d4ec051c2a00 Author: Jason Merrill Date: Thu Jun 24 17:32:02 2021 -0400 c++: constexpr aggr init of empty class [PR101040] This is basically the aggregate initializer version of PR97566; as in that bug, we are trying to initialize empty field 'obj' in 'single' when there's no CONSTRUCTOR entry for the 'single' base class subobject of 'derived'. As with that bug, the fix is to stop trying to add entries for empty fields, this time in cxx_eval_bare_aggregate. The change to the other function isn't necessary for this version of the patch, but seems worthwhile for robustness anyway. PR c++/101040 PR c++/97566 gcc/cp/ChangeLog: * class.c (is_empty_field): Handle null argument. * constexpr.c (cxx_eval_bare_aggregate): Discard initializer for empty field. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/no_unique_address13.C: New test.
[Bug c++/101040] [11/12 Regression] Internal compiler error: in get_or_insert_ctor_field, at cp/constexpr.c:3571 since r11-7980-gc3d3bb0f03dbd025
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101040 --- Comment #3 from Jason Merrill --- Created attachment 51060 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51060&action=edit bits dropped from the patch putting these here in case I want them later.
