https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105325
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
CC||acsawdey at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
--- Comment #5 from acsawdey at gcc dot gnu.org ---
Bisection reveals that this starts with this commit:
20d70cd2719815d9ea853314775ae5787648ece5 is the first bad commit
commit 20d70cd2719815d9ea853314775ae5787648ece5
Author: Alan Modra
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
--- Comment #4 from acsawdey at gcc dot gnu.org ---
I was compiling with -mcpu=power9, yes:
/home2/sawdey/work/gcc/trunk/build/gcc/xgcc
-B/home2/sawdey/work/gcc/trunk/build/gcc -O3 -mcpu=power9 bug2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
--- Comment #2 from acsawdey at gcc dot gnu.org ---
>From the reload dump:
0 Non input pseudo reload: reject++
1 Non-pseudo reload: reject+=2
1 Non input pseudo reload: reject++
alt=0,overall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
--- Comment #1 from acsawdey at gcc dot gnu.org ---
Looking at trunk, after expand we have this:
(note 5 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 5 3 2 (set (reg/v/f:DI 117 [ a ])
(reg:DI 3 3 [ a ])) "bug2.c":3:1 -1
(n
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acsawdey at gcc dot gnu.org
Target Milestone: ---
This got broken sometime in gcc 10 timeframe. For this test case:
#include
void m(char *a, char *b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100996
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Target
ormal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acsawdey at gcc dot gnu.org
Target Milestone: ---
The fusion-p10-addadd.c test case does not get vector add-add fusion when
compiling with -m32:
/home/sawdey/work/gcc/trunk/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97926
--- Comment #3 from acsawdey at gcc dot gnu.org ---
So the underlying problem here is that the unordered comparisons are not
allowed with -ffinite-math-only due to this predicate:
;; Return 1 if OP is a comparison operation that is valid for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97926
--- Comment #2 from acsawdey at gcc dot gnu.org ---
patch_jump_insn() is running into a land mine -- the insn before modification
is invalid:
(gdb) p insn_invalid_p(insn, true)
$4 = 1
(gdb) pr insn
(jump_insn 18 17 114 6 (set (pc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99070
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99070
--- Comment #4 from acsawdey at gcc dot gnu.org ---
OK, I see the fail with -mcpu=power9. Looks like I botched something with
addressing and allowed D-form addresses when it should be DS-form. On power10
this would result in selection of a prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99070
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=98692
--- Comment #7 from acsawdey at gcc dot gnu.org ---
The inline expansion should be disabled by -Os, the patterns for cmpstr[n]si
both have this:
if (optimize_insn_for_size_p ())
FAIL;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98688
--- Comment #3 from acsawdey at gcc dot gnu.org ---
Yeah it's pretty clear that something needs to be output, as with that code I
get an error like this:
In module imported at mma-module-2.C:1:1:
mma_foo0: In function ‘int bar(__vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98688
--- Comment #1 from acsawdey at gcc dot gnu.org ---
I don't know if this is the right thing to do, but ignoring the opaque type
here make the ICE go away. I suspect I need to construct a module test case
using vector_pair/vector_quad to r
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acsawdey at gcc dot gnu.org
Target Milestone: ---
Similar to PR98645, we run into trouble if we try to compile code using
vector_pair/vector_quad using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97947
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 #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=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 #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 #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
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 #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=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=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 #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()
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=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
: 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=95347
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
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
: 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=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]; }
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=94622
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
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
--- 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 #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
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2020-04-16
: 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=94542
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |acsawdey at gcc dot
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=92379
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
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=93129
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
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=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=88308
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
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
--- 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 #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 #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=89112
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|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
--- 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=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 #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 #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 #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 #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 #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
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=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
--- Comment #3 from acsawdey at gcc dot gnu.org ---
This appears to have to do with alignment. In this test case,
expand_block_clear() sees alignment of only 8 bits for the pointer p. If you
declare a local struct st and pass that to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88027
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=87474
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
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|NEW |ASSIGNED
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=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
--- 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 #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 #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=83660
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
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
--- 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=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
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=83660
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
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
--- 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
--- 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
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
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=85321
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
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
--- 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=83822
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83822
--- Comment #4 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Fri Mar 30 12:17:31 2018
New Revision: 258975
URL: https://gcc.gnu.org/viewcvs?rev=258975&root=gcc&view=rev
Log:
2018-03-30 Aaron Sawdey
PR targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83707
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83707
--- Comment #5 from acsawdey at gcc dot gnu.org ---
I can also confirm with trunk 258957 I do not see this fail with -m32
-mcpu=power7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84743
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84743
--- Comment #5 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Tue Mar 13 16:28:09 2018
New Revision: 258495
URL: https://gcc.gnu.org/viewcvs?rev=258495&root=gcc&view=rev
Log:
2018-03-13 Aaron Sawdey
PR targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84743
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Priority|P1 |P3
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84743
--- Comment #3 from acsawdey at gcc dot gnu.org ---
Yes I'm digging into this now and omnetpp is at the top of the list. I can see
if there is a difference between cpu2006 and 2017 as well. For gcc7 I used 2006
to determine the widths.
Priority: P3
Component: target
Assignee: acsawdey at gcc dot gnu.org
Reporter: acsawdey at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le power8
The width settings in rs6000_reassociation_width() were chosen to help
performance for SPEC CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84433
--- Comment #8 from acsawdey at gcc dot gnu.org ---
It looks like both gcc 7 and 8 assume that the statement
ptrA->sA[ptrB->int1].zt = parm1;
will only be executed 14+1 times because of the declaration sA[15].
However gcc 7 assum
1 - 100 of 233 matches
Mail list logo
