https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #17 from Wilco ---
(In reply to rguent...@suse.de from comment #16)
> But you can't elide the checks in the peeled copies and for 4-times
> unrolling you have most cases exiting on the first or fourth check.
See comment #8 for an ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #19 from Wilco ---
(In reply to Jakub Jelinek from comment #18)
> The duffs device doesn't need to be done with computed jump, it can be done
> with 3 conditional branches + 3 comparisons too. The advantage of doing
> that is especia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #20 from Wilco ---
I see Kyrill added some examples that show LLVM knows how to unroll loops:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
This kind of thing is much worse than a trailing loop, both for branch
prediction and co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #19 from Wilco ---
(In reply to Segher Boessenkool from comment #18)
> Well, it is always possible to generate code with the opposite endianness to
> what the hardware "wants". It just won't be very fast code.
>
> BITS_BIG_ENDIAN is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #21 from Wilco ---
(In reply to Eric Botcazou from comment #20)
> > BITS_BIG_ENDIAN is just a convenience to the target code writer. The other
> > four do matter, and are quite obvious really (and all four are necessary).
>
> Yes, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #25 from Wilco ---
(In reply to rguent...@suse.de from comment #17)
> On Tue, 8 Jan 2019, wilco at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
> >
> > --- Comment #16 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #27 from Wilco ---
(In reply to Eric Botcazou from comment #22)
> > Is it really pure RTL, therefore not used in tree? So the above patch using
> > BITS_BIG_ENDIAN for tree stuff would be incorrect to use it?
>
> I wouldn't say incor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #29 from Wilco ---
(In reply to Richard Biener from comment #26)
> Did anybody test the patch? Testing on x86_64 will be quite pointless...
Well that generates _18 = BIT_FIELD_REF <_2, 16, 14>; and becomes:
ubfxx1, x20, 2, 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #5 from Wilco ---
(In reply to Wilco from comment #4)
> (In reply to ktkachov from comment #2)
> > Created attachment 45386 [details]
> > aarch64-llvm output with -Ofast -mcpu=cortex-a57
> >
> > I'm attaching the full LLVM aarch64 ou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #7 from Wilco ---
(In reply to rguent...@suse.de from comment #6)
> On Wed, 9 Jan 2019, wilco at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
> >
> > --- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #33 from Wilco ---
(In reply to Richard Biener from comment #32)
> >
> > Index: gcc/expr.c
> > ===
> > --- gcc/expr.c (revision 267553)
> > +++ gcc/expr.c (working co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #34 from Wilco ---
With just the expr.c patch the gcc regression tests all pass on big-endian
AArch64. Interestingly this includes the new torture test, ie. it does not
trigger the union bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #37 from Wilco ---
(In reply to rsand...@gcc.gnu.org from comment #35)
> Yeah, the expr.c patch makes the original testcase work, but we still fail
> for:
That's the folding in ccp1 after inlining, which will require a similar fix.
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #14 from Wilco ---
(In reply to rguent...@suse.de from comment #13)
> Usually the peeling is done to improve branch prediction on the
> prologue/epilogue.
Modern branch predictors do much better on a loop than with this kind of code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #16 from Wilco ---
(In reply to rguent...@suse.de from comment #15)
> which is what I refered to for branch prediction. Your & prompts me
> to a way to do sth similar as duffs device, turning the loop into a nest.
>
> head:
>i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560
--- Comment #6 from Wilco ---
(In reply to Vladimir Makarov from comment #5)
> We have too many tests checking expected generated code. We should more
> focus on overall effect of the change. SPEC would be a good criterium
> although it is hard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #11 from Wilco ---
A SPEC2006 run shows the codesize cost of make_more_copies is 0.05%.
Practically all tests are worse, the largest increases are perlbench at 0.20%,
gromacs 0.12%, calculix 0.12%, soplex 0.08%, xalancbmk 0.07%, wrf 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #13 from Wilco ---
(In reply to Segher Boessenkool from comment #12)
> Before the change combine forwarded all argument (etc.) hard registers
> wherever
> it could, doing part of RA's job (and doing a lousy job of it). If after the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #17 from Wilco ---
(In reply to Vladimir Makarov from comment #14)
> I've checked cvtf_1.c generated code and I don't see additional fmov
> anymore. I guess it was fixed by an ira-costs.c change (a special
> consideration of moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #19 from Wilco ---
(In reply to Segher Boessenkool from comment #18)
> https://gcc.gnu.org/ml/gcc/2019-01/msg00112.html
Thanks, I hadn't noticed that yet... I need to look at it in more detail, but
are you saying that combine no long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #22 from Wilco ---
(In reply to Steve Ellcey from comment #21)
> If I look at this specific example:
>
> int f2 (int x, int y)
> {
> return (x & ~0x0ff000) | ((y & 0x0ff) << 12);
> }
>
> Is this because of x0 (a hard register) at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #23 from Wilco ---
Author: wilco
Date: Tue Jan 22 17:49:46 2019
New Revision: 268159
URL: https://gcc.gnu.org/viewcvs?rev=268159&root=gcc&view=rev
Log:
Fix vect-nop-move.c test
Fix a failing test - changes in Combine mean the test n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #19 from Wilco ---
(In reply to rguent...@suse.de from comment #18)
> > 1) Unrolling for load-pair-forming vectorisation (Richard Sandiford's
> > suggestion)
>
> If that helps, sure (I'd have guessed uarchs are going to split
> load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #21 from Wilco ---
(In reply to rguent...@suse.de from comment #20)
> On Thu, 24 Jan 2019, wilco at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
> >
> > --- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #32 from Wilco ---
Author: wilco
Date: Fri Jan 25 13:29:06 2019
New Revision: 268265
URL: https://gcc.gnu.org/viewcvs?rev=268265&root=gcc&view=rev
Log:
[PATCH][AArch64] Fix generation of tst (PR87763)
The TST instruction no longer m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #23 from Wilco ---
(In reply to ktkachov from comment #22)
> helps even more. On Cortex-A72 it gives a bit more than 6% (vs 3%)
> improvement on parest, and about 5.3% on a more aggressive CPU.
> I tried unrolling 8x in a similar man
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89101
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89101
Wilco changed:
What|Removed |Added
Status|WAITING |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89104
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89104
--- Comment #5 from Wilco ---
(In reply to Jakub Jelinek from comment #4)
> I really don't like these aarch64 warnings, declare simd is an optimization
> (admittedly with ABI consequences) and warning about this by default is
> weird,
> + it is g
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
The following testcases ICEs with -march=armv8-m.base on arm.none.eabi:
long long a;
int b, c;
int d(int e, int f) { return e << f; }
void g() {
long long h;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89190
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
The following testcase generates incorrect stack offsets on AArch64 since GCC7
when compiled with -O1 -mbig-endian:
struct S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195
Wilco changed:
What|Removed |Added
Target||aarch64
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195
--- Comment #1 from Wilco ---
make_extraction does:
if (MEM_P (inner))
{
poly_int64 offset;
/* POS counts from lsb, but make OFFSET count in memory order. */
if (BYTES_BIG_ENDIAN)
offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195
--- Comment #4 from Wilco ---
(In reply to Segher Boessenkool from comment #3)
> (In reply to Wilco from comment #1)
> > len is unsigned HOST_WIDE_INT, so bits_to_bytes_round_down does an unsigned
> > division...
>
> That shouldn't make a differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195
--- Comment #10 from Wilco ---
(In reply to Jakub Jelinek from comment #8)
> Created attachment 45606 [details]
> gcc9-pr89195.patch
>
> Now in patch form (untested so far).
That works fine indeed. It avoids accessing the object out of bounds b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195
--- Comment #11 from Wilco ---
(In reply to Segher Boessenkool from comment #9)
> That patch is pre-approved if it regchecks fine (on more than just x86).
> Thanks!
check-gcc is clean on aarch64_be-none-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70291
--- Comment #6 from Wilco ---
(In reply to ktkachov from comment #4)
> Implemented for GCC 9.
Since multiple people seem interested in the improvement, would it be useful to
backport?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85769
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666
--- Comment #8 from Wilco ---
(In reply to Hans-Peter Nilsson from comment #7)
> Thank you for your interest in the MMIX port.
>
> (In reply to Wilco from comment #3)
> > (In reply to Sergei Trofimovich from comment #1)
> >
> > > #define MMIX_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #7 from
NCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
New failures:
FAIL: 25_algorithms/make_heap/complexity.cc (test for excess errors)
FAIL: 25_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946
--- Comment #26 from Wilco ---
Author: wilco
Date: Mon Jun 18 11:10:51 2018
New Revision: 261698
URL: https://gcc.gnu.org/viewcvs?rev=261698&root=gcc&view=rev
Log:
[testsuite] Remove xfail from vect-abs-compile.c
Since PR64946 has been fixed, w
||wilco at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #27 from Wilco ---
Fixed and test updated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86076
--- Comment #7 from Wilco ---
Author: wilco
Date: Mon Jun 18 12:17:10 2018
New Revision: 261699
URL: https://gcc.gnu.org/viewcvs?rev=261699&root=gcc&view=rev
Log:
[testsuite] Add target pthread to pr86076.c
Add missing target pthread to ensure
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
Recently these tests started to fail on arm-none-linux-gnueabihf:
FAIL: 21_strings/basic_string/modifiers/64422.cc (test for excess errors)
FAIL: 21_strings
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
The following warning happens when you use memory_resource:
...libstdc++-v3/include/experimental/memory_resource:329: warning
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
Recently omp-low.c started to show an ICE:
UNRESOLVED: libgomp.oacc-c++/non-scalar-data.C -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -O2 compilation failed to produce executable
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
Recently the gfortran.dg/typebound_proc_35.f90 -Os test fails as follows:
f951: internal compiler error: Segmentation fault
0xc58e8f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86337
Wilco changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86333
--- Comment #3 from Wilco ---
(In reply to Jonathan Wakely from comment #2)
> These are the same failures as clyon reported for arm
> https://gcc.gnu.org/ml/libstdc++/2018-06/msg00130.html
>
> So I'm going to assume this report is based on an ol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85711
--- Comment #5 from Wilco ---
Author: wilco
Date: Mon Jul 15 11:00:48 2019
New Revision: 273491
URL: https://gcc.gnu.org/viewcvs?rev=273491&root=gcc&view=rev
Log:
Backport fix for PR85711
Backport from mainline
2019-01-23 Bin C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85711
Wilco changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
Since r273479 bootstrap fails with this error on AArch64:
Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/aarch64.o differs
gcc/dwarf2out.o differs
gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91176
--- Comment #2 from Wilco ---
(In reply to rsand...@gcc.gnu.org from comment #1)
> Dramantic differences in file size are expected, since stage2 is built with
> -gtoggle (to suppress debug info) whereas stage 3 is built normally. One of
> the th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83518
Wilco changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89190
--- Comment #4 from Wilco ---
Author: wilco
Date: Tue Jul 16 12:00:42 2019
New Revision: 273523
URL: https://gcc.gnu.org/viewcvs?rev=273523&root=gcc&view=rev
Log:
[ARM] Fix Thumb-1 ldm (PR89190)
This patch fixes an ICE in the Thumb-1 LDM peepho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89190
--- Comment #5 from Wilco ---
Author: wilco
Date: Tue Jul 16 12:06:55 2019
New Revision: 273524
URL: https://gcc.gnu.org/viewcvs?rev=273524&root=gcc&view=rev
Log:
Add missing testcase for PR89190
testsuite/
PR target/89190
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89190
--- Comment #6 from Wilco ---
Author: wilco
Date: Tue Jul 16 12:12:01 2019
New Revision: 273525
URL: https://gcc.gnu.org/viewcvs?rev=273525&root=gcc&view=rev
Log:
Add missing testcase for PR89190
testsuite/
PR target/89190
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89190
--- Comment #7 from Wilco ---
Backported to GCC8 branch, and added missing testcase to trunk and GCC9. All
fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89190
Wilco changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222
--- Comment #10 from Wilco ---
Author: wilco
Date: Tue Jul 16 12:37:14 2019
New Revision: 273526
URL: https://gcc.gnu.org/viewcvs?rev=273526&root=gcc&view=rev
Log:
[ARM] Fix PR89222
The GCC optimizer can generate symbols with non-zero offset fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222
--- Comment #11 from Wilco ---
Author: wilco
Date: Tue Jul 16 13:13:26 2019
New Revision: 273527
URL: https://gcc.gnu.org/viewcvs?rev=273527&root=gcc&view=rev
Log:
[ARM] Fix PR89222
The GCC optimizer can generate symbols with non-zero offset fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222
Wilco changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222
Wilco changed:
What|Removed |Added
Target Milestone|8.5 |7.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90684
--- Comment #4 from Wilco ---
Author: wilco
Date: Tue Jul 16 16:17:39 2019
New Revision: 273533
URL: https://gcc.gnu.org/viewcvs?rev=273533&root=gcc&view=rev
Log:
Fix alignment option parser (PR90684)
Fix the alignment option parser to always a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90684
Wilco changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
dot gnu.org |wilco at gcc dot gnu.org
Summary|[7/8/9/10] ICE for arm |[7/8/9] ICE for arm sha1h
|sha1h and wrong |and wrong optimisations on
|optimisations on|sha1h/c/m/p
|sha1h/c/m/p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
--- Comment #17 from Wilco ---
(In reply to Jeffrey A. Law from comment #16)
> The issue here (of course) is that aarch64 has a different set of defaults
> for when to open-code vs loop vs function call. My attempts to pick a
> better size for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91144
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
The new alias-4_0.C fails on Arm. Without LTO it also fails with -O2 on
AArch64, but it fails with -O2 and -O3 on Arm, so something must be different.
Unfortunately even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #12 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #14 from Wilco ---
(In reply to Martin Liška from comment #13)
> >
> > The key question is how does one dump rtl with -flto? It doesn't work at
> > all, making debugging this difficult...
>
> It does, look:
>
> marxin@marxinbox:/tm
||2019-08-09
Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #7 from Wilco ---
I'll have a look at this, I think it could easily be done in match.pd if we add
support for matching
||2019-08-09
Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #22 from Wilco ---
(In reply to Richard Earnshaw from comment #21)
> Fixed on trunk.
I ran an AArch64 bootstrap on GCC9 branch and that is fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81800
--- Comment #17 from Wilco ---
Author: wilco
Date: Tue Aug 13 10:46:44 2019
New Revision: 274376
URL: https://gcc.gnu.org/viewcvs?rev=274376&root=gcc&view=rev
Log:
[AArch64] Fix PR81800
PR81800 is about the lrint inline giving spurious FE_INEXA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81800
Wilco changed:
What|Removed |Added
Known to work||10.0
Summary|[8/9/10 regression] on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
Wilco changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
|NEW
Last reconfirmed||2019-08-30
CC||wilco at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Wilco ---
(In reply to Maxim Kuvyrkov from comment #2)
> Created attachm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83661
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83661
--- Comment #9 from Wilco ---
(In reply to Christophe Monat from comment #4)
> Hi Pratamesh,
>
> You're absolutely right - maybe it's more efficient when there is some
> hardware sincos available (Intel FSINCOS ?) but I would check also carefull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81800
--- Comment #19 from Wilco ---
Author: wilco
Date: Wed Sep 4 12:42:22 2019
New Revision: 275373
URL: https://gcc.gnu.org/viewcvs?rev=275373&root=gcc&view=rev
Log:
[AArch64] Fix PR81800
PR81800 is about the lrint inline giving spurious FE_INEXA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81800
--- Comment #20 from Wilco ---
Author: wilco
Date: Wed Sep 4 13:06:55 2019
New Revision: 275374
URL: https://gcc.gnu.org/viewcvs?rev=275374&root=gcc&view=rev
Log:
[AArch64] Fix PR81800
PR81800 is about the lrint inline giving spurious FE_INEXA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81800
--- Comment #21 from Wilco ---
Backported to GCC8 and GCC9 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81800
Wilco changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
The following small example fails with an ICE with -mcpu=cortex-a57:
typedef struct { int a, b, c; } S;
void g (S *s);
void bug1 (void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91684
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
Arm bootstrap still fails with latest trunk when configured with
--with-cpu=cortex-a57:
gcc/gcc/real.c:5240:1: internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
--- Comment #2 from Wilco ---
(In reply to Bernd Edlinger from comment #1)
> Oh, nice, could you say what config options you use?
The full set I used:
${src}/configure --disable-libsanitizer --enable-languages=c,c++
--prefix=${install} --targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
--- Comment #5 from Wilco ---
(In reply to Christophe Lyon from comment #4)
> (In reply to Bernd Edlinger from comment #3)
> > I will try to reproduce with building of a cross for this target.
>
> FWIW, cross-build looked fine for me at r275501:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42575
--- Comment #20 from Wilco ---
(In reply to Wilco from comment #19)
> (In reply to Christophe Lyon from comment #18)
> > This is still wrong with current trunk.
>
> I don't see it happening since expansion of DImode instructions improved.
> The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91690
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
--- Comment #8 from Wilco ---
(In reply to Bernd Edlinger from comment #7)
> without looking in detail, this could
> be another middle-end error or the back-end
> generating an invalid instruction where no assertions
> are, then lra can rewrite t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
--- Comment #11 from Wilco ---
Created attachment 46862
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46862&action=edit
Reproducer
g++ -mcpu=cortex-a57 -mfpu=fp-armv8 out.c -O2 -c reproduces the issue outside
of a bootstrap
101 - 200 of 724 matches
Mail list logo
