-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
After commit r278938, I've noticed regressions on aarch64:
FAIL: gcc.target/aarch64/fmla_intrinsic_1.c scan-assembler-times
fmla\\tv[0-9]+.2s, v[0-9]+.2s, v[0-9]+.2s\\[[0-9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91975
Bug 91975 depends on bug 92047, which changed state.
Bug 92047 Summary: [10 regression] aarch64 regressions after r276645
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92047
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92047
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91612
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91613
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91615
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92473
--- Comment #2 from Christophe Lyon ---
Created attachment 47218
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47218=edit
Execution trace for arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92473
--- Comment #1 from Christophe Lyon ---
Created attachment 47217
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47217=edit
Execution trace for aarch64
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
The test pr92324-2.c introduced at r277958 fails on arm and aarch64:
FAIL: gcc.dg/vect/pr92324-2.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/pr92324-2.c execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92333
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92208
--- Comment #9 from Christophe Lyon ---
(In reply to Tobias Burnus from comment #8)
> (In reply to Christophe Lyon from comment #7)
> > On gcc-9, the patch introduced regressions, seen on arm and aarch64:
>
> On trunk, the following was needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92208
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61761
--- Comment #13 from Christophe Lyon ---
It's still failing on trunk:
https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg00131.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61761
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207
--- Comment #7 from Christophe Lyon ---
When single-stepping in the r277178 executable, the final
=> 0x18bc0 <_malloc_r+1092>:str r3, [r2, #4]
succeeds and
(gdb) p /x $r2
$2 = 0x804aa40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207
--- Comment #6 from Christophe Lyon ---
In particular, the execution continues after the last block dumped by qemu:
0x00018e40: e5974008 ldr r4, [r7, #8]
0x00018e44: e0898008 add r8, sb, r8
0x00018e48: e3888001 orr r8, r8,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207
--- Comment #3 from Christophe Lyon ---
Created attachment 47104
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47104=edit
Execution trace for r277178
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207
--- Comment #4 from Christophe Lyon ---
Created attachment 47105
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47105=edit
Execution trace for r277179
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207
--- Comment #2 from Christophe Lyon ---
Created attachment 47103
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47103=edit
Executable from r277179
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207
--- Comment #1 from Christophe Lyon ---
Created attachment 47102
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47102=edit
Executable from r277178
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
As discussed in https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01619.html
I have noticed a regression after r277179.
However, it seems tricky to reproduce, and I had to manually
|u |u arm aarch64
CC||clyon at gcc dot gnu.org
--- Comment #1 from Christophe Lyon ---
Seen on arm and aarch64 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92128
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
|u |u aarch64 arm
CC||clyon at gcc dot gnu.org
--- Comment #1 from Christophe Lyon ---
Seen on aarch64 and arm too.
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
I've noticed that r276645 introduced a regression on armeb:
FAIL: gcc.dg/vect/fast-math-vect-pr29925.c scan-tree-dump-times vect
"vectorized 1 loops" 1
maybe
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
After r276645, I've noticed regressions on aarch64:
FAIL: gcc.target/aarch64/sve/index_offset_1.c -march=armv8.2-a+sve
scan-assembler-times ld1b\\tz[0-9]+.b, p[0-9]+/z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92016
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91983
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91982
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91909
--- Comment #5 from Christophe Lyon ---
I confirm that the proposed patch fixed the problem for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91885
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
After r275898, I've noticed a regression on armeb:
FAIL: gcc.dg/vect/vect-cond-4.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91749
Christophe Lyon changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91749
--- Comment #4 from Christophe Lyon ---
Author: clyon
Date: Tue Sep 17 08:13:11 2019
New Revision: 275799
URL: https://gcc.gnu.org/viewcvs?rev=275799=gcc=rev
Log:
[PR91749][arm] FDPIC: Handle -mflip-thumb
2019-09-16 Christophe Lyon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91749
Christophe Lyon changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91749
--- Comment #1 from Christophe Lyon ---
Can you share your configure options?
Also, it looks like you are forcing at least -mfdpic when running the
testsuite?
Why did you put "known to work 9.2", since -mfdpic does not exist in that
version?
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since r274823, this arm test fails:
FAIL: gcc.target/arm/pr53447-5.c scan-assembler-times (ldrd|vldr\\.64) 20
FAIL: gcc.target/arm/pr53447
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89188
--- Comment #9 from Christophe Lyon ---
Good point, I just checked with
gcc-linaro-7.4.1-2019.02-x86_64_aarch64-linux-gnu, and it does ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89188
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91684
--- Comment #8 from Christophe Lyon ---
Indeed, it's now unsupported in this config.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91684
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
++
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
The new test introduced at r275403 fails on arm targets:
/libstdc++-v3/testsuite/23_containers/span/get_neg.cc:27: error: call of
overloaded 'span(int*, long unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36262
--- Comment #16 from Christophe Lyon ---
> Wrong bugzilla? But also should be fixed by the followup.
I replied to the bugzilla mentioned in the ChangeLog...
>
> 2019-09-05 Richard Biener
>
> PR rtl-optimization/91656
> *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36262
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
Known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91603
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91615
--- Comment #7 from Christophe Lyon ---
(In reply to Bernd Edlinger from comment #6)
> Created attachment 46820 [details]
> untested patch
This patch fixes the armeb problems reported here, thanks!
(in addition to the scan-assembler-times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91615
--- Comment #5 from Christophe Lyon ---
(In reply to Bernd Edlinger from comment #4)
> Hi Christophe,
>
> many thanks for your invaluable help.
>
> I think except this one all regressions are fixed or
> at least understood.
>
> Unfortunately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91612
--- Comment #4 from Christophe Lyon ---
> I don't know yet for pr91613
This patch fixes pr91613 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91308
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91612
--- Comment #3 from Christophe Lyon ---
(In reply to Bernd Edlinger from comment #2)
> Created attachment 46792 [details]
> untested patch
>
> This is a untested patch it should fix
> pr91612 pr91613 pr91615 (?)
> pr91603
> and pr91605 (i386)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81740
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91615
--- Comment #1 from Christophe Lyon ---
There are also 2 regressions in gfortran
--target armeb-none-linux-gnueabihf
--with-cpu cortex-a9
--with-fpu neon-fp16
gfortran.dg/vect/no-vfa-pr32377.f90 -O (internal compiler error)
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since r274986 with the patch from
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg02018.html, I've noticed ICEs on
armeb (arm big-endian cross compiler):
gcc.c-torture/execute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91614
--- Comment #1 from Christophe Lyon ---
The same is true
--with-cpu cortex-a57
--with-fpu crypto-neon-fp-armv8
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since r274986, even with the patch from
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg02018.html, I've noticed:
FAIL
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
After r274986, even with the patch from
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg02018.html, I've noticed:
FAIL: gcc.dg/pr83930.c (internal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since r274985, I've noticed new failures, not fixed by the patch proposed at
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg02018.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
--- Comment #10 from Christophe Lyon ---
Thanks for the pointer to the glibc discussion.
My understanding is that GCC's warning is legitimate, and won't be removed?
Since this breaks all my validations, I guess the best course of action on my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91457
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109
--- Comment #15 from Christophe Lyon ---
Since r274532 (gcc-9-branch), I am seeing:
FAIL: gcc.c-torture/execute/20040709-1.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects execution test
target arm-none-linux-gnueabi
--with-mode arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109
--- Comment #12 from Christophe Lyon ---
Indeed, although r274163 fixes the problem I reported, it also introduces a
regression when compiling the very same testcase but adding -mthumb:
FAIL: gcc.c-torture/execute/20040709-1.c -O2 (internal
-*-*,
||aarch64-linux-gnu,
||arm*-linux-gnueabihf
CC||clyon at gcc dot gnu.org
--- Comment #13 from Christophe Lyon ---
The new test (gcc.dg/torture/pr91323.c) fails on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42575
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109
--- Comment #2 from Christophe Lyon ---
Removing the test*() calls from the end, the first failing one is testX().
However, if I remove all the preceding ones, the test passes.
Using -fwhole-program instead of -flto has no effect: the test
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
I've noticed that since r273135 (fix for PR91091), there is a regression on
arm-none-linux-gnueabi
--with-mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91060
--- Comment #13 from Christophe Lyon ---
Indeed, this seems to work:
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 820502a..4f69122 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -12471,7 +12471,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91060
--- Comment #8 from Christophe Lyon ---
(In reply to Richard Biener from comment #5)
> Hmm, using a cross configured as
>
> trunk/configure --target=armeb-none-linux-gnueabihf --with-cpu=cortex-a9
> --with-fpu=neon-fp16 --enable-languages=c
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91060
--- Comment #4 from Christophe Lyon ---
Unfortunately, it's still failing as of r273133.
It fails at the very first check:
v1 = 2 + v0; check (short, 8, v0, v1, 2, +, l);
The generated code for main is:
main:
@ args = 0, pretend
: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
Since r272843 was committed, I have noticed a regression on
armeb-none-linux-gnueabihf
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
Since r272843, I've noticed a failure on aarch64-elf:
FAIL: gcc.c-torture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89296
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 89296, which changed state.
Bug 89296 Summary: [7 Regression] tree copy-header masking uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89296
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90930
--- Comment #4 from Christophe Lyon ---
Created attachment 46505
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46505=edit
open62541.i.xz preprocessed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90930
--- Comment #1 from Christophe Lyon ---
Created attachment 46504
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46504=edit
testcase open62541.c and open62541.h
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
aarch64-linux-gnu-gcc consumes a lot of memory and takes a lot of time to
compile the attached code, or it fails with "cc1: out of memory allocating.."
depending on the ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806
--- Comment #6 from Christophe Lyon ---
I've manually rebuilt both toolchains, and recompiled the testcase.
The warnings are still different, the preprocessed files are identical, the
fdump-tree-wrestrict logs are identical too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70841
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71026
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90873
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90811
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
--- Comment #20 from Christophe Lyon ---
Hi Kugan,
The new test fails with -mabi=ilp32:
FAIL: gcc.target/aarch64/pr88834.c scan-assembler-times \\tld2w\\t{z[0-9]+.s -
z[0-9]+.s}, p[0-7]/z, \\[x[0-9]+, x[0-9]+, lsl 2\\]\\n 2
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90810
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806
--- Comment #4 from Christophe Lyon ---
gcc.log on the RH7 host contains lines which are absent from gcc.log on the RH6
host:
In function 'void wrap_memcpy_dst_diff_max(char*, const char*, ptrdiff_t,
size_t)',
inlined from 'void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90806
--- Comment #3 from Christophe Lyon ---
(In reply to Richard Biener from comment #2)
> GCC 6 is no longer maintained btw.
I'm talking about gcc-9 and trunk. The host (x86_64) is running either Redhat
Linux 6 or 7.
Both cases use dejagnu-1.5.1
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
I've noticed that c-c++-common/Warray-bounds-2.c passes on a cross-compiler for
aarch64 when the host runs RH7, but fails when the host is RH6:
FAIL: c-c++-common
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90738
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
Somewhere between r271733 and r271780, the test
gcc.dg/rtl/aarch64/subs_adds_sp.c started to fail with an ICE:
/gcc/testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440
--- Comment #26 from Christophe Lyon ---
Author: clyon
Date: Mon May 27 13:37:57 2019
New Revision: 271662
URL: https://gcc.gnu.org/viewcvs?rev=271662=gcc=rev
Log:
[testsuite,aarch64,arm] PR88440: Fix testcases
2019-05-27 Christophe Lyon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #20 from Christophe Lyon ---
Author: clyon
Date: Mon May 20 15:01:46 2019
New Revision: 271424
URL: https://gcc.gnu.org/viewcvs?rev=271424=gcc=rev
Log:
[testsuite] PR90106 Fix cdce3.c testcase
2019-05-20 Christophe Lyon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #18 from Christophe Lyon ---
(In reply to JunMa from comment #17)
> (In reply to Christophe Lyon from comment #16)
> > That's what I did... (use -fdump-tree-cdce-details).
> >
> > The assembler code is:
> > .arm
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #16 from Christophe Lyon ---
That's what I did... (use -fdump-tree-cdce-details).
The assembler code is:
.arm
.fpu softvfp
.type foo, %function
foo:
@ args = 0, pretend = 0, frame = 0
@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #14 from Christophe Lyon ---
Sure, here is the contents of cdce3.c.105t.cdce:
;; Function foo (foo, funcdef_no=0, decl_uid=4197, cgraph_uid=1,
symbol_order=0)
foo (float x)
{
float _4;
[local count: 1073741824]:
_4 = sqrtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90478
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813
--- Comment #10 from Christophe Lyon ---
And some regressions in g++ too:
g++.dg/compat/eh/unexpected1 cp_compat_x_tst.o-cp_compat_y_tst.o execute
g++.dg/cpp0x/lambda/lambda-eh2.C -std=gnu++14 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88709
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
501 - 600 of 1101 matches
Mail list logo
