https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92379
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92379
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acsawdey at gcc dot gnu.org
Target Milestone: ---
The test case is:
__thread double thrtest[81];
int main ()
{
double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94542
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |acsawdey at gcc dot
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acsawdey at gcc dot gnu.org
Target Milestone: ---
Compile command:
/home2/sawdey/work/gcc/mamboCI/build-mambo/gcc/xgcc
-B/home2/sawdey/work/gcc/mamboCI/build-mambo/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94622
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2020-04-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94622
--- Comment #1 from acsawdey at gcc dot gnu.org ---
Compiling with -dap we see:
sync # 7[c=12 l=4] *hwsync
plq 8,.LANCHOR0@pcrel# 8[c=8 l=12] load_quadpti
mr 10,9 # 9[c=4 l=4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94622
--- Comment #2 from acsawdey at gcc dot gnu.org ---
Solution is going to be to always use plq if prefixed, which makes sense anyway
for little endian because it avoids the ugly doubleword swap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94622
--- Comment #3 from acsawdey at gcc dot gnu.org ---
I'm wondering if the same problem exists for atomic_store, store_quadpti,
and pstq vs stq?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94622
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acsawdey at gcc dot gnu.org
Target Milestone: ---
Compiler is trunk 3bcdb5dec72b6d7b197821c2b814bc9fc07f4628 on ppc64le power9
host.
~/work/gcc/trunk/build/gcc/xgcc -B/home2/sawdey/work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94740
--- Comment #1 from acsawdey at gcc dot gnu.org ---
Reduced test case:
struct __attribute__((scalar_storage_order("big-endian"))) {
int a;
int b[];
} c;
int d;
int e() { d = c.b[0]; }
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acsawdey at gcc dot gnu.org
Target Milestone: ---
Problem exists in r11-639.
/home2/sawdey/work/gcc/mamboCI/build-mambo/gcc/xgcc
-B/home2/sawdey/work/gcc/mamboCI/build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95347
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2020-06-02
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95347
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: acsawdey at gcc dot gnu.org
Target Milestone: ---
Started to see this on trunk last night. Tested again and still see it with
r11-2018.
configured with:
/home2/sawdey/work/gcc/mamboCI/gcc-master/configure
--prefix=/opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96151
--- Comment #1 from acsawdey at gcc dot gnu.org ---
This compile is successful like this but fails if I add -mcpu=power9.
/home2/sawdey/work/gcc/mamboCI/build-mambo/./prev-gcc/xg++
-B/home2/sawdey/work/gcc/mamboCI/build-mambo/./prev-gcc/
-B/opt
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acsawdey at gcc dot gnu.org
Target Milestone: ---
Created attachment 49122
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49122&action=edit
hashtab.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96787
--- Comment #1 from acsawdey at gcc dot gnu.org ---
Created attachment 49123
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49123&action=edit
hashtab.c with target power9 attribute on htab_delete()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96787
--- Comment #2 from acsawdey at gcc dot gnu.org ---
I'm seeing some load-past-store code motion that happens when compiling for
power10 vs power9 that makes me suspicious.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96787
--- Comment #3 from acsawdey at gcc dot gnu.org ---
Never mind that, all I'm seeing is the lack of save/restore of r2 in the
power10 version.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #3 from acsawdey at gcc dot gnu.org ---
This also requires -mbig which may be implicit in the original poster's build.
But I see it failing as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |acsawdey at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #7 from acsawdey at gcc dot gnu.org ---
I wonder if this other case works properly when compiled with -m64. Trying to
generate a stxvp with a 32-bit address seems odd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #8 from acsawdey at gcc dot gnu.org ---
Another small test case, reduced from my compile failure of c/c-typeck.c and
modified to provoke truncation from POImode to various other modes:
typedef int *a;
struct b { a ba; };
enum c { c1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #9 from acsawdey at gcc dot gnu.org ---
I did post a small patch that fixes this, but more for the purpose of provoking
discussion than because I am sure it is the right way to fix this.
https://gcc.gnu.org/pipermail/gcc-patches/2020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #10 from acsawdey at gcc dot gnu.org ---
For now, disabling use of POImode for expansion of memcpy/memmove to avoid this
problem while we figure out the real fix:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553672.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93130
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93129
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88027
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88027
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89112
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89112
--- Comment #2 from acsawdey at gcc dot gnu.org ---
I'm seeing this on both gcc-8-branch and trunk, but only with -mcpu=power9.
I'll figure out what happened here and get it fixed in trunk then back ported
to 8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89112
--- Comment #3 from acsawdey at gcc dot gnu.org ---
It appears that gcc decided to split the bdnzt generated by the memcmp
expansion because the destination was out of range, and produced this:
bdz $+12
beq 0,$+8
b $+8;b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89112
--- Comment #4 from acsawdey at gcc dot gnu.org ---
Well I can't blame this one on the linker or optimization. The splitting for
the case where the branch destination is too far is wrong in tf_:
static char seq[96];
char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89112
--- Comment #5 from acsawdey at gcc dot gnu.org ---
This patch fixes the issue on trunk:
Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 268403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89112
--- Comment #7 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Tue Feb 5 16:30:45 2019
New Revision: 268546
URL: https://gcc.gnu.org/viewcvs?rev=268546&root=gcc&view=rev
Log:
2019-02-05 Aaron Sawdey
PR targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89112
--- Comment #8 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Tue Feb 5 16:32:06 2019
New Revision: 268547
URL: https://gcc.gnu.org/viewcvs?rev=268547&root=gcc&view=rev
Log:
2019-02-05 Aaron Sawdey
PR targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89112
--- Comment #9 from acsawdey at gcc dot gnu.org ---
The fixes for this are in trunk now. I will backport to gcc-8-branch in a week
and then this can be closed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85321
--- Comment #4 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Tue Apr 10 22:05:41 2018
New Revision: 259302
URL: https://gcc.gnu.org/viewcvs?rev=259302&root=gcc&view=rev
Log:
2018-04-10 Aaron Sawdey
PR targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85321
--- Comment #5 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Wed Apr 11 15:25:42 2018
New Revision: 259324
URL: https://gcc.gnu.org/viewcvs?rev=259324&root=gcc&view=rev
Log:
2018-04-11 Aaron Sawdey
PR targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85321
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83660
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
CC||acsawdey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83660
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83660
--- Comment #12 from acsawdey at gcc dot gnu.org ---
This function is called from cp/semantics.c maybe_cleanup_point_expr()
tree
fold_build_cleanup_point_expr (tree type, tree expr)
{
/* If the expression does not have side effects then we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83660
--- Comment #14 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Mon Apr 16 14:50:06 2018
New Revision: 259403
URL: https://gcc.gnu.org/viewcvs?rev=259403&root=gcc&view=rev
Log:
2018-04-16 Aaron Sawdey
PR targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83660
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83660
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acsawdey at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, segher at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85436
--- Comment #1 from acsawdey at gcc dot gnu.org ---
Created attachment 43966
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43966&action=edit
shorter reduced test case
I've further reduced the test case and now it's on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83660
--- Comment #17 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Tue Apr 24 00:14:21 2018
New Revision: 259586
URL: https://gcc.gnu.org/viewcvs?rev=259586&root=gcc&view=rev
Log:
2018-04-23 Aaron Sawdey
Backp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83660
--- Comment #18 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Tue Apr 24 00:19:43 2018
New Revision: 259590
URL: https://gcc.gnu.org/viewcvs?rev=259590&root=gcc&view=rev
Log:
2018-04-23 Aaron Sawdey
Backp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83660
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86222
--- Comment #3 from acsawdey at gcc dot gnu.org ---
OK, so this requires -m32 and also -mcpu=power6 or higher. I have reproduced it
so should have a fix shortly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86222
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86222
--- Comment #4 from acsawdey at gcc dot gnu.org ---
Well when compiling this with -m32 -mcpu=power[6789] I get this for the rtx of
the length argument:
(const_int -2147483648 [0x8000])
So when I am doing UINTVAL (bytes_rtx) I get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86222
--- Comment #5 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Fri Jun 22 15:37:36 2018
New Revision: 261906
URL: https://gcc.gnu.org/viewcvs?rev=261906&root=gcc&view=rev
Log:
Forgot PR target/86222 in ChangeLog
Modified:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86222
--- Comment #6 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Tue Jun 26 16:43:38 2018
New Revision: 262157
URL: https://gcc.gnu.org/viewcvs?rev=262157&root=gcc&view=rev
Log:
2018-06-26 Aaron Sawdey
Backport fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86222
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87808
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82190
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82190
--- Comment #3 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Tue Dec 12 22:22:53 2017
New Revision: 255592
URL: https://gcc.gnu.org/viewcvs?rev=255592&root=gcc&view=rev
Log:
2017-12-12 Aaron Sawdey
PR targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82190
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82190
--- Comment #5 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Tue Jan 2 17:02:17 2018
New Revision: 256083
URL: https://gcc.gnu.org/viewcvs?rev=256083&root=gcc&view=rev
Log:
Add missing changelog entry:
2017-12-12 Aaro
Priority: P3
Component: target
Assignee: acsawdey at gcc dot gnu.org
Reporter: acsawdey at gcc dot gnu.org
Target Milestone: ---
Target: ppc32 power7
This is apparently due to the inline expansion code that went into gcc7.
Haven't looked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83707
--- Comment #1 from acsawdey at gcc dot gnu.org ---
OK, this has nothing to do with memcmp builtin expansion. Also fails with just
-m32 -O1 -fno-builtin-memcmp. Passes with -O0. I checked in gdb and when it
fails the v2 and vt being compared are
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: acsawdey at gcc dot gnu.org
CC: dje at gcc dot gnu.org, wschmidt at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le power8
Attempting to bootstrap trunk 256388
../trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83757
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80946
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81038
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #9 from acsawdey at gcc dot gnu.org ---
Comparing behavior of 256764 on genoa (fails) and willow2 (works).
In directory powerpc64le-unknown-linux-gnu/libgo, this compile fails:
/home/sawdey/src/gcc/trunk/build/./gcc/gccgo
-B/home
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #10 from acsawdey at gcc dot gnu.org ---
This is the list of enabled passes between local-fnsummary2 (last sighting of
CleanPkgpath) and fixup_cfg4 which does not include CleanPkgpath. Need to take
a look at the ipa dumps next
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #11 from acsawdey at gcc dot gnu.org ---
It appears that -O1 -fexpensive-optimizations is the minimal optimization to
trigger this fail. And of what -fexpensive-optimizations turns on, this piece
in ira-costs.s (find_costs_and_classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #12 from acsawdey at gcc dot gnu.org ---
Another data point: go1 built with AT10.0 on willow2 does not fail on genoa,
whereas go1 built with AT 10.0 on genoa does fail.
Going to see if I can nail down which .o file is the carrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #13 from acsawdey at gcc dot gnu.org ---
one more interesting piece ...
Copying gcc/libbackend.a and gcc/*.o from willow2 (working build) to genoa and
linking go1 does not result in a working go1 binary. But, also copying over
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #14 from acsawdey at gcc dot gnu.org ---
I've narrowed this down a bit --- copying libcommon-target.a from the working
build on willow2 makes the build on genoa work, even with -O2. So it is
something in there. I'll continue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #15 from acsawdey at gcc dot gnu.org ---
The build succeeds with -fno-split-stack. Turned out that willow2 had
glibc-2.17 so split-stack was disabled and genoa has 2.23 which enables it. So
this issue has something to with compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #16 from acsawdey at gcc dot gnu.org ---
Created attachment 43208
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43208&action=edit
split-stack related bug test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #17 from acsawdey at gcc dot gnu.org ---
Seems to be some interaction between split-stack and inlining. The ICE does not
occur when compiling with -O2 -fdisable-ipa-inline.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #22 from acsawdey at gcc dot gnu.org ---
On genoa (power8, glibc 2.22 or 2.23) this compile always ICEs regardless of
how gcc was built:
/home/sawdey/src/gcc/trunk/build/./gcc/gccgo
-B/home/sawdey/src/gcc/trunk/build/./gcc/
-B/home
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #23 from acsawdey at gcc dot gnu.org ---
(In reply to Alexandre Oliva from comment #19)
> I was copied, presumably because the problem occurred in var-tracking.
>
> I've tried to duplicate the problem on gcc112. I bo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #26 from acsawdey at gcc dot gnu.org ---
A little bit more info:
It appears the parameter asmhdr in this function is at the center of this:
func (tools gccgoToolchain) gc(b *Builder, a *Action, archive string, importcfg
[]byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
CC||ebotcazou at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #29 from acsawdey at gcc dot gnu.org ---
The problematic expression was:
(mem/c:QI (plus:DI (plus:DI (reg/f:DI 187) (const_int 32 [0x20])) (const_int 72
[0x48]))
and internal_arg_pointer was (plus:DI (reg/f:DI 187) (const_int 32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #31 from acsawdey at gcc dot gnu.org ---
I'm not sure where the copy happens, I am just surmising that it must have been
added because the code clearly assumes it won't be copied.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89112
--- Comment #10 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Sat Feb 9 17:11:06 2019
New Revision: 268725
URL: https://gcc.gnu.org/viewcvs?rev=268725&root=gcc&view=rev
Log:
2019-02-09 Aaron Sawdey
Backpor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89112
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88308
--- Comment #3 from acsawdey at gcc dot gnu.org ---
One difference between compiling this -m32 and -m64 is that the label for the
jump table is marked /s in the 64-bit version:
(code_label/s 22 21 23 4 (nil) [4 uses])
(jump_table_data 23 22 24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88308
--- Comment #4 from acsawdey at gcc dot gnu.org ---
Tracked down the difference between -m32 and -m64. In the -m64 case,
rs6000_emit_move calls force_const_mem and that will set LABEL_PRESERVE_P on a
label_ref that it finds, which is what marks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88308
--- Comment #5 from acsawdey at gcc dot gnu.org ---
After some more digging, it appears that the problem is
move_insn_for_shrink_wrap() is deleting and re-creating insns to move them from
one BB to another. The label reference count gets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88308
--- Comment #6 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Fri Feb 15 15:41:25 2019
New Revision: 268942
URL: https://gcc.gnu.org/viewcvs?rev=268942&root=gcc&view=rev
Log:
2019-02-15 Aaron Sawdey
PR rtl-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88308
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87474
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87474
--- Comment #4 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Tue Oct 2 17:31:53 2018
New Revision: 264799
URL: https://gcc.gnu.org/viewcvs?rev=264799&root=gcc&view=rev
Log:
2018-10-02 Aaron Sawdey
PR targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87474
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #35 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Thu Feb 15 14:26:46 2018
New Revision: 257690
URL: https://gcc.gnu.org/viewcvs?rev=257690&root=gcc&view=rev
Log:
Fix my changelog entry for PR target/83758
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #36 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Thu Feb 15 14:48:15 2018
New Revision: 257691
URL: https://gcc.gnu.org/viewcvs?rev=257691&root=gcc&view=rev
Log:
2018-02-15 Aaron Sawdey
Back p
1 - 100 of 233 matches
Mail list logo
