rd when compiled
in 64-bit mode
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bergner at vnet
--- Comment #1 from bergner at vnet dot ibm dot com 2006-06-26 18:42
---
Created an attachment (id=11758)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11758&action=view)
Simple test case to show the problem.
The bad code generation is in change_byte_order().
--
--- Comment #2 from bergner at vnet dot ibm dot com 2006-06-26 18:44
---
Forgot to mention this fails on both the 4.1 branch and mainline. It does work
with 3.4 and earlier versions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
--- Comment #3 from bergner at vnet dot ibm dot com 2006-06-26 18:49
---
Janis performed a regression hunt on mainline and identified this patch as the
start of the test failure:
r83568 | dje | 2004-06-23 21:19:00 + (Wed, 23 Jun 2004) | 7 lines
* config/rs6000/rs6000.c
--- Comment #10 from bergner at vnet dot ibm dot com 2006-07-06 14:32
---
I used Alan's code changes from comments #8 and #9 on the 4.1 branch and it
bootstrapped and regression tested (32-bit and 64-bit) fine.
Mainline bootstraps and regression tests are still running.
--
--- Comment #12 from bergner at vnet dot ibm dot com 2006-07-06 18:00
---
Mainline with Alan's changed bootstrapped, but showed a few regressions.
David's suggested fix from comment #7 (using mainline) bootstrapped and is
currently in the middle of running the test suite.
--- Comment #15 from bergner at vnet dot ibm dot com 2005-11-04 17:38
---
For completeness, here is a minimal test case that shows the problem we are
having:
[EMAIL PROTECTED]:~/olaf/PR24644-4> cat bar.c
register struct paca_struct * local_paca asm("r13");
struc
--- Comment #4 from bergner at vnet dot ibm dot com 2005-11-08 16:04
---
Shouldn't libtool being using -print-multi-os-directory rather than
-print-search-dirs?
http://www.redhat.com/archives/fedora-devel-list/2004-January/msg01027.html
--
bergner at vnet dot ibm dot com ch
--- Comment #8 from bergner at vnet dot ibm dot com 2005-12-06 01:57
---
We're miscompiling htab_bolt_mapping(). What do I win? ;-)
I have a userland test case which I'll attach once I've shunk it down a little.
--
bergner at vnet dot ibm dot com changed:
--- Comment #9 from bergner at vnet dot ibm dot com 2005-12-06 06:26
---
Created an attachment (id=10414)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10414&action=view)
Minimal test case.
Here's a minimal test case. This works with older gcc's and withou
--- Comment #14 from bergner at vnet dot ibm dot com 2005-12-06 13:40
---
sizeof(unsigned long) and sizeof(unsigned long long) are both 8 bytes on ppc64.
Olaf, -O1 isn't a workaround, it's the minimum optimization level that still
shows the bug. Trying some -fno-* options,
--- Comment #22 from bergner at vnet dot ibm dot com 2005-12-06 18:47
---
...and I can verify that the patch fixes the reduced test case. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25248
rmace problem with indexed load/stores on powerpc
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bergner at vnet do
--- Comment #3 from bergner at vnet dot ibm dot com 2006-08-26 04:24
---
Ok, I tracked down where the expander is swapping the operands. It's occuring
at simplify-rtx.c:simplify_binary_operation() at line 1459:
/* Make sure the constant is second. */
if (GET_RTX_CLASS
--- Comment #5 from bergner at vnet dot ibm dot com 2006-09-05 18:43
---
Created an attachment (id=12190)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12190&action=view)
Patch to rs6000_legitimize_address to force base pointers into rA position of
indexed load/store instr
--- Comment #7 from bergner at vnet dot ibm dot com 2006-09-05 20:01
---
Well, to get REG_POINTER regs to be the first operand, we'd need to increase
their commutative_operand_precedence. I tried that change already, but that
led to an infinite recursion loop while attempti
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bergner at vnet dot ibm dot com
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-
--- Comment #8 from bergner at vnet dot ibm dot com 2006-09-07 05:14
---
Ok, this also passed regression tests on powerpc64-linux (32-bit and 64-bit
testsuite runs) for c, c++, fortran, objc, obj-c++ and java.
Does the attached patch look reasonable to everyone?
--
http
--- Comment #9 from bergner at vnet dot ibm dot com 2006-09-21 18:14
---
Created an attachment (id=12305)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12305&action=view)
Patch to rs6000_legitimize_address to force base pointers into rA position of
indexed load/store instr
--- Comment #10 from bergner at vnet dot ibm dot com 2006-09-21 18:16
---
(From update of attachment 12190)
Forgot to obsolete this patch by the updated patch.
--
bergner at vnet dot ibm dot com changed:
What|Removed |Added
--- Comment #11 from bergner at vnet dot ibm dot com 2006-09-21 18:19
---
Created an attachment (id=12306)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12306&action=view)
Alternate patch to rs6000_legitimize_address to force base pointers into rA
position of indexed loa
--- Comment #12 from bergner at vnet dot ibm dot com 2006-09-22 16:30
---
Anton dicovered that we don't get multiple dimensioned arrays like the
following test case:
int indexedload(int ***base, int idx0, int idx1, int idx2)
{
return base[idx0][idx1][idx2];
}
This one leads
--- Comment #13 from bergner at vnet dot ibm dot com 2006-09-22 16:56
---
Yet another test case from Anton we don't catch. Will they never end?!?! ;)
int indexedload(int *base, int len)
{
int i, sum = 0;
for (i=0; i < len; i++)
sum += base[i];
return sum;
}
In t
normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bergner at vnet dot ibm dot com
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux
http://gcc.gnu.org
--- Comment #17 from bergner at vnet dot ibm dot com 2006-10-03 03:30
---
Created an attachment (id=12375)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12375&action=view)
Patch to swap_commutative_operands_p and gen_addr_rtx to force base pointers
into rA position of
--- Comment #19 from bergner at vnet dot ibm dot com 2006-10-03 15:51
---
David has already said offline that he would reject any patch that would cause
us to view a non-REG_POINTER + REG_POINTER expression an not legitimate. I
agree with that.
Sorry, but I'm slowly learnin
--- Comment #8 from bergner at vnet dot ibm dot com 2005-11-03 21:48
---
Adding myself to the CC list.
--
bergner at vnet dot ibm dot com changed:
What|Removed |Added
--- Comment #11 from bergner at vnet dot ibm dot com 2005-11-04 05:52
---
I've determined why we're dying, but not sure who is at fault yet. While
scanning through Olaf's assembly diff's, I noticed some code that normally
wouldn't be a problem in user code, bu
--- Comment #11 from bergner at vnet dot ibm dot com 2010-02-24 22:08
---
Subject: Re: [4.5 Regression] wrong code for
200.sixtrack with vectorization and -fdata-sections
On Wed, 2010-02-24 at 21:01 +, meissner at linux dot vnet dot ibm dot com
wrote:
>
> --- Comme
Summary: ICE compiling glibc part using -O1 -m64 -mlong-double-
128
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #1 from bergner at vnet dot ibm dot com 2006-01-31 20:47
---
Created an attachment (id=10767)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10767&action=view)
Test case as an attachment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26049
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bergner at vnet dot ibm dot com
GCC build triplet: powerpc64-unknown-linux-gnu
GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-u
--- Comment #1 from bergner at vnet dot ibm dot com 2006-03-08 22:03
---
Created an attachment (id=10997)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10997&action=view)
Reduced test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26610
--- Comment #24 from bergner at vnet dot ibm dot com 2006-11-08 03:30
---
Ok, Anton hit another test case the last patch doesn't transform. It's
actually the same test case as in comment #13, except, "int *base" is now a
global variable rather than a function p
--- Comment #28 from bergner at vnet dot ibm dot com 2006-11-29 20:11
---
Another problem with the current patch, is we get one testsuite regression
(gfortran.fortran-torture/compile/defined_type_2.f90 at -O1). For this simple
testcase, we end up generating bad assembler:
mr 9
--- Comment #29 from bergner at vnet dot ibm dot com 2006-11-29 22:23
---
Talking with Andrew on IRC, he said the test case in comment #27 fails for the
same reason as the test case in comment #24 (ie, it looks like an artificial
decl) and should be fixed with his PTR_PLUS_EXPR work
--- Comment #11 from bergner at vnet dot ibm dot com 2006-12-05 02:06
---
The testcase pr26943-2.c fails intermittently for me using unpatched mainline.
Is anyone else seeing that? I'm building on powerpc64-linux with -m32. If I
run it a few times, it mainly passes, but every on
--- Comment #30 from bergner at vnet dot ibm dot com 2006-12-05 04:22
---
Ok, the problem from comment #28 was due to a latent bug in
reload1.c:eliminate_regs_in_insn(). The bug is that eliminate_regs_in_insn()
calls single_set() on the passed in insn. This has been fine before, but
--- Comment #31 from bergner at vnet dot ibm dot com 2006-12-05 04:41
---
...and here's the patch I mentioned in the previous comment:
Index: reload1.c
===
--- reload1.c (revision 119497)
+++ reload1.c (working
--- Comment #7 from bergner at vnet dot ibm dot com 2006-12-13 19:25
---
Ok, the reload fix has been reverted until we can find another way to fix this.
Sorry for all of the trouble.
Author: bergner
Date: Wed Dec 13 19:19:03 2006
New Revision: 119844
URL: http://gcc.gnu.org/viewcvs
40 matches
Mail list logo
