||amodra at gmail dot com
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
--- Comment #1 from Alan Modra ---
So, the "writes way past this" is writing into the parameter save area.
compare_kr is assuming that it was called with a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300
--- Comment #2 from Alan Modra ---
Created attachment 32854
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32854&action=edit
quick and dirty fix
This fixes the problem in a fairly obvious way, but I think we can use a more
refined approach
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300
--- Comment #4 from Alan Modra ---
You could do that, but smaller stack frames is one of the nice features of the
ELFv2 ABI! What I called the "quick and dirty" fix seems to be the way to go,
as the scheme I had in mind to avoid a new INCOMING_R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300
--- Comment #5 from Alan Modra ---
Actually, to work the patch in comment #3 would need to be
- if (!prototype_p (fun) || stdarg_p (fun))
+ if (1)
return true;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61098
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
URL|http://gcc.gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300
--- Comment #7 from Alan Modra ---
No, I don't believe there is a convenient way we can look at the
REG_PARM_STACK_SPACE argument to determine whether it was used for a call or
for a function body. (I did think it might be possible, hence my com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Target Milestone|4.8.4 |4.8.1
--- Comment #13 from Alan Modra ---
Fixed in 4.8.1
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Seen first on ibm-4.9 branch with powerpc64, but also occurs on 4.9 branch with
both powerpc64 and x86_64. x86_64 configured with --enable-threads=posix
--disable
||2014-06-23
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61583
--- Comment #1 from Alan Modra ---
A bit more poking and I see that VR info is being added during the vrp1 pass by
tree-vrp.c:remove_range_assertions, but not when -g.
Hmm, at a guess the root cause of the problem is that is_unreachable is being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61583
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
--- Comment #8 from amodra at gmail dot com 2010-02-10 23:20 ---
I haven't tested my patch against eon, just the testcase here and of course the
gcc testsuite. Latest patch url given above
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42344
--- Comment #11 from amodra at gmail dot com 2010-02-19 23:39 ---
Fixed
--
amodra at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342
--- Comment #6 from Alan Modra ---
Created attachment 35001
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35001&action=edit
workaround
You might like to consider this patch that effectively reverts r210201 for
Darwin. This should cure th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342
--- Comment #9 from Alan Modra ---
As far as fixing the real underlying problem goes, I'm not so familiar with the
darwin support that I can state with certainty that you need to fix movdi_low
and friends.
It might help to explain why powerpc64-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342
--- Comment #10 from Alan Modra ---
> permitted? (i.e. modifying %1, which is an input operand)
Yes. You're outputting assembly, practically anything goes.
||amodra at gmail dot com
--- Comment #13 from Alan Modra ---
Markus, are you sure about comment #9? I completely disabled the bswap pass
and still see a failure of the testcase at -O3.
Incidentally, if I compile with -O2 -fno-inline, the testcase fails on the
first iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369
--- Comment #14 from Alan Modra ---
That should be -O3 -fno-inline.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65408
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369
--- Comment #28 from Alan Modra ---
Created attachment 35024
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35024&action=edit
modified testcase without bswap optimization
This modified testcase avoids triggering the bswap optimization but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369
Alan Modra changed:
What|Removed |Added
Attachment #35016|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369
--- Comment #32 from Alan Modra ---
Richi, ptr+12 is nonsense. Suppose ptr is 16k+1, then first vector loads from
16k and second from the same address since (16k+1+12) & ~15 == 16k. But we
want to end up with 15 bytes from the first 16-byte ali
||2015-03-14
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #4 from Alan Modra ---
Created attachment 35032
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35032&action=edit
pr
gcc dot gnu.org |amodra at gmail dot com
||amodra at gmail dot com
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
gcc dot gnu.org |amodra at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342
--- Comment #12 from Alan Modra ---
We won't want that mem_operand_gpr change for Linux or AIX as we do the
alignment checking of more complex expressions in legitimate_address_p.
Do take heed to the comment about accepting odd rtl generated by r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64703
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65408
--- Comment #6 from Alan Modra ---
Code quality for both powerpc64le and x86_64 looks passable for the testcase
here and other structs with at least one int field (ie. when the struct size is
a multiple of 4, and alignment is 4). You get DImode
||amodra at gmail dot com
Resolution|--- |WONTFIX
--- Comment #3 from Alan Modra ---
32-bit support for powerpc64le hasn't been removed, it is just not enabled by
default since we don't support a 32-bit user runtime. As Andrew said, it is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65464
--- Comment #7 from Alan Modra ---
On x86_64-linux you can run 32-bit binaries. On powerpc64le-linux you can't.
It's that simple. -m32 support in powerpc64le gcc, by default, doesn't make
sense until we have
- supported and tested compat layer
onent: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Seen when compiling glibc with a freshly built powerpc64le gcc configured
without --with-cpu.
cat > ledefault.S <
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63150
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #14
||2015-04-01
CC||amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #4 from Alan Modra ---
Confirmed. The failure occurs with -mcpu=power6x or lower.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65576
--- Comment #6 from Alan Modra ---
The patch does appear to fix the problem for non-power7, but introduces an ICE
on power7 for pr33855.c.
gcc.c-torture/compile/pr33855.c:27:1: error: unrecognizable insn:
}
^
(insn 124 123 31 5 (set (mem:DF (p
-
||patches/2015-04/msg00043.ht
||ml
Assignee|meissner at gcc dot gnu.org|amodra at gmail dot com
--- Comment #7 from Alan Modra ---
Alternate patch posted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65576
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||2015-04-16
CC||amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #4 from Alan Modra ---
optopt is common, and from a linker perspective I believe the correct
resolution of a common symbol in the executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
Alan Modra changed:
What|Removed |Added
CC|amodra at gcc dot gnu.org |
Summary|[5 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779
--- Comment #3 from Alan Modra ---
Re comment #1, insn 36 is not removed, but moved later to bb3
(insn 363 364 41 3 (set (reg/v:SI 0 0 [orig:239 s2 ] [239])
(lshiftrt:SI (reg/v:SI 3 3 [orig:265 adler ] [265])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779
--- Comment #4 from Alan Modra ---
Created attachment 35342
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35342&action=edit
prototype patch
This seems to cure the testcase. I haven't bootstrapped it, and it probably
isn't ideal since I h
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Testsuite results between two identical powerpc64-linux builds, except for the
source path name, differ.
+FAIL: gfortran.dg/fmt_en.f90 -O0 execution test
+FAIL: gfortran.dg/fmt_en.f90 -O0 scan-file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810
--- Comment #3 from Alan Modra ---
amodra@bns:~/build/gcc-5-virgin> gcc/gfortran -v
Using built-in specs.
COLLECT_GCC=gcc/gfortran
Target: powerpc64-linux
Configured with: /home/amodra/src/gcc-5-virgin/configure
--build=powerpc64-linux --with-cpu
||2015-04-20
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #4 from Alan Modra ---
Here's the bad code
0x0fffb7f6c438 :addis r9,r2,-2
0x0fffb7f6c43c :li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810
--- Comment #6 from Alan Modra ---
It isn't seen most of the time because the failure happens only when r2 isn't
16-byte aligned (50% chance) and the r2 offset to a long double constant is
n*64k+32k-8 (0.012% chance per long double). libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58744
Bug 58744 depends on bug 36043, which changed state.
Bug 36043 Summary: gcc reads 8 bytes for a struct of size 6 which leads to
sigsegv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65408
Bug 65408 depends on bug 36043, which changed state.
Bug 36043 Summary: gcc reads 8 bytes for a struct of size 6 which leads to
sigsegv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58744
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65408
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37954
Bug 37954 depends on bug 36043, which changed state.
Bug 36043 Summary: gcc reads 8 bytes for a struct of size 6 which leads to
sigsegv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66020
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
gen_nop() is called in various places in rs6000.c. These nops don't survive
rtl_dce, thus breaking darwin's TARGET_FIX_AND_CONTINUE, and the scheduler nop
insertion.
dot gnu.org |
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
|ASSIGNED
Last reconfirmed||2015-05-06
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66033
--- Comment #2 from Alan Modra ---
Right, but there will be when I have my split-stack implementation done.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66020
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||amodra at gmail dot com
Resolution|--- |FIXED
--- Comment #5 from Alan Modra ---
Fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865
--- Comment #16 from Alan Modra ---
Hi Nick, that patch looks exactly like my first attempt to fix this bug. I
forget the details now but I'm fairly certain it wasn't a complete fix, which
is why I didn't submit my patch..
Note that the underlyi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865
--- Comment #17 from Alan Modra ---
I believe Eric's comment
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00179.html points at the correct
fix, but it's a bit messy. You need to recursively descend both "decl" and
"init" in code like c-decl.c:fin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865
--- Comment #19 from Alan Modra ---
Jakub, you're correct. I should have read the standard on flexible array
members before poking at this bug last year. Nick's patch is looking good to
me.
ISO/IEC 9899:1999 is quite clear that the answer to co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865
--- Comment #24 from Alan Modra ---
Nick's latest patch passes bootstrap and regression testing powerpc64-linux.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59814
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #1 from
||2014-01-16
CC||amodra at gmail dot com
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Ever confirmed|0 |1
||2014-02-04
CC||amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #1 from Alan Modra ---
Reduced testcase
void foo (void)
{
register float __attribute__ ((mode(SD))) r31 __asm__ ("r31");
regi
dot gnu.org |
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
--- Comment #2 from Alan Modra ---
Looks to be as simple as deleting SECONDARY_MEMORY_NEEDED_MODE. Testing..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032
--- Comment #3 from Alan Modra ---
No, not quite. SECONDARY_MEMORY_NEEDED_MODE looks to be required by lra, so
make rs6000_secondary_memory_needed_mode depend on lra_in_progress.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60073
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #2 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60073
--- Comment #7 from Alan Modra ---
The variadic support in libfii is fairly recent. And yes, it might have been
there earlier if the testcases actually tested what they were suppose to test!
Note that powerpc64-gcc passes fp arguments correspond
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||amodra at gmail dot com
Resolution|--- |DUPLICATE
--- Comment #1 from Alan Modra ---
Fixed by r207553. I'm not sure why this one didn't show up in the list of
tests I reported fixed in
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00273.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032
--- Comment #8 from Alan Modra ---
*** Bug 60029 has been marked as a duplicate of this bug. ***
||2014-02-10
CC||amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #3 from Alan Modra ---
I reckon this is overly restrictive checking in rs6000_secondary_reload_inner.
rtl during reload is a little messy
||amodra at gmail dot com
Resolution|--- |DUPLICATE
--- Comment #1 from Alan Modra ---
This is exactly the same issue as pr58675.
*** This bug has been marked as a duplicate of bug 58675 ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58675
--- Comment #4 from Alan Modra ---
*** Bug 57935 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58675
Alan Modra changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
--- Comment
||2014-02-10
CC||amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #1 from Alan Modra ---
This one also seems to be fixed by the patch in pr58675.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57936
--- Comment #2 from Alan Modra ---
No, cancel comment #1, I was fooled by version skew between the unpatched and
the patched compiler. The testcase doesn't ICE on recent versions of gcc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57936
--- Comment #3 from Alan Modra ---
The testcase doesn't ICE since 206639. That wasn't an rs6000 patch so we
probably still have the underlying issue in the rs6000 backend.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58675
Alan Modra changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59814
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59844
Alan Modra changed:
What|Removed |Added
CC||anton at samba dot org
--- Comment #5 from A
gcc dot gnu.org |amodra at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57936
Alan Modra changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57936
--- Comment #6 from Alan Modra ---
Bill, the ppc64-abi-dfp-1.c ICE is cured by the patch committed for pr58675 on
the trunk. Now committed to ibm-4.8.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57936
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||2015-09-07
CC||amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #1 from Alan Modra ---
This is a reload issue.
Here's the insn:
(insn 13 7 487 2 (set (reg:DI 183)
(mem/u/c:DI (pre_modify:DI
gcc dot gnu.org |amodra at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67378
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
-*-*
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-09-21
CC||amodra at gmail dot com
Summary|Suboptimal code generation |Suboptimal code generation
|for C11 |for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66033
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60158
--- Comment #2 from Alan Modra ---
Fixed on master with git commit 8e2a42caa / svn rev 223209.
Fixed for gcc-4.9 with git commit 110222ca0 / svn rev 223714.
Fixed for gcc-4.8 with git commit 071358356 / svn rev 223713.
Oddly, not backported to g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60158
--- Comment #4 from Alan Modra ---
I meant by my testcase comment that gcc/testsuite/gcc.target/powerpc/pr60158.c
is a poor test because it does not seem to emit addresses to .data.rel.ro.local
or any other non-got section, on gcc-4.9, gcc-5 or m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64687
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #5
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
This testcase, extracted from glibc sysdeps/powerpc/powerpc64/dl-machine.h
shows gcc optimising away the "opd" initialisation at -O1. ie. it&#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64703
--- Comment #6 from Alan Modra ---
Re comment #2, yes I agree that conversion between void* or pointer to object
and pointer to function is not strictly allowed. Fixing that by way of a union
was one of the first things I tried, before looking a
501 - 600 of 872 matches
Mail list logo
