||2022-11-10
Ever confirmed|0 |1
CC||jgreenhalgh at gcc dot gnu.org
--- Comment #1 from James Greenhalgh ---
Confirming - I also found this when search results pointed me to
https://gcc.gnu.org/onlinedocs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
James Greenhalgh changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
||jgreenhalgh at gcc dot gnu.org
Last reconfirmed||2020-10-08
Status|UNCONFIRMED |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96958
--- Comment #1 from James Greenhalgh ---
Asleep at the wheel today, I had intended to link to the
https://gcc.gnu.org/pipermail/libstdc++/2011-September/036420.html original
discussion rather than leave it as a tedious exercise for the reader.
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
Target Milestone: ---
It was pointed out that some forks of GCC (
https://github.com/FEX-Emu/gcc/commit/8a2b7389f50a50a4e26ec98101d47fb1fc1c1bcd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96313
James Greenhalgh changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95133
--- Comment #2 from James Greenhalgh ---
Should reproduce further back if you force it on with -ftree-vectorize .
i.e.
gcc foo.c -ftree-vectorize -O3
Breaks somewhere between:
gcc version 7.0.0 20160615
gcc version 7.0.0 20160907
: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
Target Milestone: ---
A colleague tripped up on this typo:
void bar();
void
foo (int x)
{
if (x) return
bar
||2018-07-30
CC||jgreenhalgh at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from James Greenhalgh ---
On the platforms I'm looking at, this is equal to a 13% regression in dynamic
instruction count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85682
--- Comment #3 from James Greenhalgh ---
The bisect robot doesn't bootstrap, only build a stage 1 compiler.
I've checked your most recent patch against these testcases, and they execute
and complete fine.
(In reply to Luis Machado from comment
: middle-end
Assignee: luis.machado at linaro dot org
Reporter: jgreenhalgh at gcc dot gnu.org
CC: hjl.tools at gmail dot com, law at redhat dot com,
luis.machado at linaro dot org
Target Milestone: ---
Target: x86-64-none-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85466
--- Comment #11 from James Greenhalgh ---
With Jonathon's suggested change, copied in to the original poster's framework
(without -fno-trapping-math), Clang hot loop ( score: 165065
http://quick-bench.com/6NaD8ay0f8qMh9n0aMriYEiuKNA ) is:
0.16%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85466
James Greenhalgh changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521
James Greenhalgh changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84243
--- Comment #2 from James Greenhalgh ---
gcc -v:
Configured with: .../gcc/configure --disable-bootstrap
--enable-languages=c,c++,fortran --disable-multilib --disable-libsanitizer
--prefix=.../build/install/
FAIL:
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
CC: itsimbal at gcc dot gnu.org
Target Milestone: ---
Target: x86-64-none-linux-gnu, aarch64-none-linux-gnu
Hi, our bisect robot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84242
--- Comment #1 from James Greenhalgh ---
Also gcc.target/i386/mvc9.c on x86-64-none-linux-gnu.
: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
Target: aarch64-none-linux-gnu, x86-64-none-linux-gnu
Hi
Our testing robot spotted
||2018-01-25
CC||jgreenhalgh at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from James Greenhalgh ---
Confirmed on aarch64-none-linux-gnu. My bisect pointed to the same revision
r255569 . The 50x slow
||2018-01-03
CC||jgreenhalgh at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |jgreenhalgh at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from James Greenhalgh ---
I
,
||jgreenhalgh at gcc dot gnu.org,
||sudi.das at arm dot com
Known to work|6.4.1 |4.8.1
Known to fail||4.9.1, 5.1.1
--- Comment #3 from James
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83114
James Greenhalgh changed:
What|Removed |Added
Target Milestone|7.3 |6.6
Summary|[7/8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
James Greenhalgh changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63250
James Greenhalgh changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||jgreenhalgh at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #2 from James Greenhalgh ---
Comment 1 claims this is fixed, Andrew, please reopen if it is still an issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82237
James Greenhalgh changed:
What|Removed |Added
Target||aarch64*-*-*
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
Target Milestone: ---
A destructive operation is one in which an input operand is both read and
written. For example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81832
James Greenhalgh changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81456
--- Comment #2 from James Greenhalgh ---
(In reply to Martin Liška from comment #1)
> Confirmed, started with r238594.
The cost model relies on the target giving a reasonable approximation for an
instruction size through ix86_rtx_costs.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71778
James Greenhalgh changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71778
--- Comment #9 from James Greenhalgh ---
Author: jgreenhalgh
Date: Mon Jun 19 17:12:12 2017
New Revision: 249380
URL: https://gcc.gnu.org/viewcvs?rev=249380=gcc=rev
Log:
Backport: [Patch ARM] Fix PR71778
gcc/
PR target/71778
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71778
--- Comment #8 from James Greenhalgh ---
Author: jgreenhalgh
Date: Mon Jun 19 16:58:03 2017
New Revision: 249379
URL: https://gcc.gnu.org/viewcvs?rev=249379=gcc=rev
Log:
Backport: [Patch ARM] Fix PR71778
gcc/
PR target/71778
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71778
--- Comment #7 from James Greenhalgh ---
Author: jgreenhalgh
Date: Fri Jun 16 17:29:56 2017
New Revision: 249272
URL: https://gcc.gnu.org/viewcvs?rev=249272=gcc=rev
Log:
[Patch ARM] Fix PR71778
gcc/
PR target/71778
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80457
--- Comment #7 from James Greenhalgh ---
Thanks for your help!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80457
--- Comment #3 from James Greenhalgh ---
(In reply to Bill Schmidt from comment #2)
> Per https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00967.html, James
> Greenhalgh has a more comprehensive patch for this, so removing myself from
> the
: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
Target Milestone: ---
This testcase:
double
bar (double a)
{
return 1.0/__builtin_sqrt(a);
}
Fails with an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79534
--- Comment #12 from James Greenhalgh ---
So while there's nothing buggy about the if-conversion which causes the
performance issue, it does show an interesting missed optimization that ifcvt
can't handle.
We make the transform through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79534
--- Comment #10 from James Greenhalgh ---
The most striking improvement was in libquantum, for which we saw a 15%
performance improvement on Cortex-A72 (3% on cortex-A57) directly attributable
to basic block ordering after this patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79534
--- Comment #8 from James Greenhalgh ---
In the case before Honza's patch, corrupt profile information leads to a branch
being marked as 100% taken. After Honza's patch, the branch is instead seen
with 95.6% taken:
(jump_insn 1916 1915 1922 309
|unassigned at gcc dot gnu.org |jgreenhalgh at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79534
--- Comment #7 from James Greenhalgh ---
I'm not sure there are any bugs here to fix, though I can still reproduce the
performance differences.
First up, basic block reordering causes an issue across all microarchitectures
on which I've looked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79534
James Greenhalgh changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79534
James Greenhalgh changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80136
--- Comment #17 from James Greenhalgh ---
I've also successfully bootstrapped and regression tested this patch native on
aarch64-none-linux-gnu with no issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80136
James Greenhalgh changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80136
James Greenhalgh changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu.org
||2017-03-15
CC||jgreenhalgh at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from James Greenhalgh ---
Confirmed. A patch fixing this would be a welcome contribution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77468
--- Comment #27 from James Greenhalgh ---
(In reply to PeteVine from comment #25)
> The original issue never mentioned -Ofast or -ffast-math and I see no
> difference at -Ofast, indeed:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68749
--- Comment #13 from James Greenhalgh ---
(In reply to Dominik Vogt from comment #12)
> This also fails on s390x with -m31 and s390.
I'd just add those targets to the dg-skip-if if they don't have support for
conditional select instructions.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77468
James Greenhalgh changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664
--- Comment #17 from James Greenhalgh ---
(In reply to David Edelsohn from comment #16)
> > That isn't an argument for -fno-sched-spec, it is an argument for a cost
> > model which better matches the cost of the transformation, using the
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664
--- Comment #15 from James Greenhalgh ---
(In reply to Segher Boessenkool from comment #14)
> I'm not sure how to read your remark. An insn where the result is
> not used is not on the critical path by definition; and you seem to
> be arguing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664
--- Comment #11 from James Greenhalgh ---
Presumably, this check in sched-rgn.c:new_ready is the problem...
/* For speculative insns, before inserting to ready/queue,
check live, exception-free, and issue-delay. */
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53659
--- Comment #10 from James Greenhalgh ---
(In reply to PeteVine from comment #9)
> @jgreenhalgh Please have a look at the profiled assembly for both fast and
> slow codegen. (attached)
>
> According to @aldyh's bisection in #68664 this probably
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79245
--- Comment #9 from James Greenhalgh ---
> I'm curious how that benchmarks for you (with -ftree-loop-distribution vs.
> without).
Taking trunk as 100%, I see a 2% gain on trunk with
-fno-tree-loop-distribution-patterns , and 1% gain with your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79245
--- Comment #4 from James Greenhalgh ---
(In reply to Richard Biener from comment #3)
> Note the trivial fix will FAIL gcc.dg/tree-ssa/ldist-23.c which looks like
>
> int i;
> for (i = 0; i < 128; ++i)
> {
> a[i] = a[i] + 1;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79245
--- Comment #1 from James Greenhalgh ---
Created attachment 40592
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40592=edit
Code generation for -Ofast -fomit-frame-pointer -mcpu=cortex-a72+crypto
-ftree-loop-distribute-patterns
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
Target Milestone: ---
Created attachment 40591
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40591=edit
Code generation for -Ofast -fomit-frame-pointer -mcpu=cor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664
James Greenhalgh changed:
What|Removed |Added
Target|powerpc*-*-*, aarch64*-*-* |powerpc*-*-*, aarch64*-*-*,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664
James Greenhalgh changed:
What|Removed |Added
CC||siarhei.siamashka at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53659
James Greenhalgh changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664
James Greenhalgh changed:
What|Removed |Added
CC||tulipawn at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77468
James Greenhalgh changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77468
--- Comment #19 from James Greenhalgh ---
(In reply to Aldy Hernandez from comment #18)
> (In reply to Aldy Hernandez from comment #17)
> > Created attachment 40573 [details]
> > preprocessed testcase
>
> Here's the preprocessed testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77468
--- Comment #15 from James Greenhalgh ---
(In reply to Aldy Hernandez from comment #13)
> The aarch64-linux-gnu regression originally reported for -mcpu=cortex-a53
> was caused by:
>
> commit 08993ad1c669cab64baf352f79cd7f8584dd8e0c
> Author:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785
--- Comment #28 from James Greenhalgh ---
> As far as I can tell the kernel is the only project where this issue ever
> popped up. The fix is straightforward. It just needs to be send to the
> correct kernel maintainer.
Right, but getting the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785
--- Comment #26 from James Greenhalgh ---
(In reply to dhowe...@redhat.com from comment #21)
> (In reply to Markus Trippelsdorf from comment #20)
> > *** Bug 78879 has been marked as a duplicate of this bug. ***
>
> Kernel bug or not, it should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78529
--- Comment #27 from James Greenhalgh ---
(In reply to Jim Wilson from comment #26)
> I can reproduce the problem with this new reduced testcase. I don't have
> knowledge of all of the details how the gcc implementation of LTO works, but
> my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
James Greenhalgh changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #8 from James Greenhalgh ---
Is anyone currently looking at this?
If the bug is still blocked on correcting the profile information (which sounds
like a large job), should we consider weakening or reverting the cost model for
GCC 7?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78796
James Greenhalgh changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78529
James Greenhalgh changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78319
James Greenhalgh changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78696
--- Comment #15 from James Greenhalgh ---
(In reply to James Greenhalgh from comment #14)
> Did you accidentally commit it as part of r243419? I don't see the changes
> marked in your ChangeLog, nor did you tag that revision as a fix for this
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78696
--- Comment #14 from James Greenhalgh ---
(In reply to Martin Sebor from comment #13)
> Created attachment 40272 [details]
> Lightly tested patch.
>
> (In reply to Martin Sebor from comment #6)
>
> After some more testing, although the patch I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78733
James Greenhalgh changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78733
James Greenhalgh changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #18 from James Greenhalgh ---
Author: jgreenhalgh
Date: Wed Dec 7 14:01:59 2016
New Revision: 243345
URL: https://gcc.gnu.org/viewcvs?rev=243345=gcc=rev
Log:
[Patch PR78561 PowerPC] Revert to old behaviour for counting constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78696
--- Comment #7 from James Greenhalgh ---
That fixes my miscompilation, and the miscompilation of the library I reduced
the testcase from. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #16 from James Greenhalgh ---
Created attachment 40267
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40267=edit
Proposed Patch
Would you mind testing the attached to see if it fixes your issue?
I've bootstrapped it on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78696
James Greenhalgh changed:
What|Removed |Added
Target|aarch64-none-linux-gnu |*-*-*
--- Comment #2 from James
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78696
James Greenhalgh changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
Target Milestone: ---
For this testcase:
#include
int __attribute__ ((noinline))
wrap_snprintf (char *buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #15 from James Greenhalgh ---
(In reply to Segher Boessenkool from comment #14)
> I used trunk. --disable-bootstrap fails the same, just much faster ;-)
>
> Maybe the binutils etc. version matters?
Do you have a "modern" GCC on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #13 from James Greenhalgh ---
(In reply to Segher Boessenkool from comment #12)
> It still happens here, also on gcc110. Note you need --disable-werror,
> to avoid another bootstrap error.
>
> Did you perchance use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #11 from James Greenhalgh ---
My bootstrap at r243245 on gcc110 seemed to work fine.
[jgreenhalgh@gcc1-power7 gcc]$ ../build-gcc/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=../build-gcc/gcc/xgcc
Target: powerpc64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #9 from James Greenhalgh ---
(In reply to Segher Boessenkool from comment #8)
> I usually use --disable-libgomp, but otherwise everything default (well,
> --enable-languages=all,ada,go,obj-c++).
I need a bit more hand holding on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #7 from James Greenhalgh ---
(In reply to Segher Boessenkool from comment #5)
> Oh btw, you forgot to commit the testcase in 2/2.
Thanks, that's the easy one to fix. Would you be able to help me with a
configure line I can use for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #6 from James Greenhalgh ---
Author: jgreenhalgh
Date: Mon Dec 5 09:35:28 2016
New Revision: 243239
URL: https://gcc.gnu.org/viewcvs?rev=243239=gcc=rev
Log:
[Patch 2/2 PR78561] Recalculate constant pool size before emitting it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #3 from James Greenhalgh ---
Author: jgreenhalgh
Date: Fri Dec 2 14:31:10 2016
New Revision: 243183
URL: https://gcc.gnu.org/viewcvs?rev=243183=gcc=rev
Log:
[Patch 2/2 PR78561] Recalculate constant pool size before emitting it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #2 from James Greenhalgh ---
Author: jgreenhalgh
Date: Fri Dec 2 14:29:35 2016
New Revision: 243182
URL: https://gcc.gnu.org/viewcvs?rev=243182=gcc=rev
Log:
[Patch 1/2 PR78561] Rename get_pool_size to get_pool_size_upper_bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #7 from James Greenhalgh ---
Right, I've trimmed too much context from my message.
This performance regression starts with r239219 which adds a cost model to the
threader which relies on frequency information (arguably this is a bad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
James Greenhalgh changed:
What|Removed |Added
Last reconfirmed|2016-09-03 00:00:00 |2016-11-30
CC|
|unassigned at gcc dot gnu.org |jgreenhalgh at gcc dot
gnu.org
--- Comment #1 from James Greenhalgh ---
Well, confirmed - and an easy fix is to recompute the offset data while
sweeping for valid constants at the end of compilation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78547
James Greenhalgh changed:
What|Removed |Added
CC||hjl at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120
James Greenhalgh changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
James Greenhalgh changed:
What|Removed |Added
Target||aarch64*-*-*
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
Target Milestone: ---
This bug report is mostly from inspection, but the effects of this issue can be
seen
||jgreenhalgh at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #12 from James Greenhalgh ---
I can still trigger this with a testcase using 16-bit floating-point types, and
the tiny memory model:
int
main (__fp16 x)
{
__fp16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78509
--- Comment #12 from James Greenhalgh ---
I tried looking at the generated assembly for that test with the compilers I
built before my patch series, and after the patch series + the fix above. I
couldn't see any difference in code generated for
1 - 100 of 299 matches
Mail list logo
