--- Comment #8 from bergner at gcc dot gnu dot org 2010-08-01 15:23 ---
Answering Steven's question from Comment #7: Yes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10474
--- Comment #7 from bergner at gcc dot gnu dot org 2010-07-30 14:24 ---
Trunk is fixed for powerpc64-linux too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45134
--- Comment #5 from bergner at gcc dot gnu dot org 2010-07-29 19:37 ---
Debugger info:
#0 fancy_abort (file=0x112a7098
"/home/bergner/gcc/gcc-mainline-base/gcc/dce.c", line=495,
function=0x112a7180 "delete_corresponding_reg_eq_notes") at
/home/bergner/gcc/g
--- Comment #3 from bergner at gcc dot gnu dot org 2010-07-29 18:57 ---
Ditto for powerpc64-linux:
/home/bergner/gcc/gcc-mainline-base/gcc/fortran/module.c: In function
read_module:
/home/bergner/gcc/gcc-mainline-base/gcc/fortran/module.c:4542:1: internal
compiler error: in
--- Comment #3 from bergner at gcc dot gnu dot org 2010-07-09 20:04 ---
Hit on powerpc64-linux too. This is the assert:
/* When something is defined, it should have a node attached.
FIXME: For fortran this is still not the case since wrapup global
decls is done
ity: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bergner at gcc dot gnu dot org
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44895
--- Comment #7 from bergner at gcc dot gnu dot org 2010-07-09 16:34 ---
Ye, it ICE's there:
/home/bergner/gcc/gcc-mainline-r161924/gcc/testsuite/gcc.c-torture/compile/pr30338.c:5:5:
internal compiler error: in create_mem_ref_raw, at tree-ssa-address.c:363
Please submit a ful
--- Comment #5 from bergner at gcc dot gnu dot org 2010-07-09 16:25 ---
(gdb) call debug_tree(base)
unit size
align 64 symtab 0 alias set -1 canonical type 0x441 precision
64 min max >
visited var def_stmt D.2060_43 = ivtmp.27_37
+ D.2059_42;
vers
--- Comment #4 from bergner at gcc dot gnu dot org 2010-07-09 16:08 ---
gcc/testsuite/gcc.c-torture/compile/pr30338.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44890
--- Comment #2 from bergner at gcc dot gnu dot org 2010-07-09 14:53 ---
Full backtrace:
(gdb) bt
#0 fancy_abort (file=0x10ab02e0
"/home/bergner/gcc/gcc-mainline-r161924/gcc/tree.c", line=3717,
function=0x10aafb20 "build2_stat")
at /home/bergner/gcc/gcc-
--- Comment #10 from bergner at gcc dot gnu dot org 2010-07-09 14:37
---
Yes, it ICE's on trunk. I just opened PR44890 for the new ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30338
middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bergner at gcc dot gnu dot org
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44890
--- Comment #8 from bergner at gcc dot gnu dot org 2010-07-08 21:50 ---
The test case that was added to the testsuite (pr30338.c) ICE's on
powerpc64-linux with the following options: -Os -m64
Looking at a backtrace, we're hitting this assert in tree.c:build2_stat():
--- Comment #13 from bergner at gcc dot gnu dot org 2010-07-08 14:18
---
Subject: Bug 44828
Author: bergner
Date: Thu Jul 8 14:17:52 2010
New Revision: 161956
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161956
Log:
PR middle-end/44828
* gcc.c
--- Comment #9 from bergner at gcc dot gnu dot org 2010-07-08 04:19 ---
The fix in Comment #8 fixes the test case on systems that have a default of
unsigned char (eg, powerpc*-linux).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44828
--- Comment #8 from bergner at gcc dot gnu dot org 2010-07-08 04:12 ---
Subject: Bug 44828
Author: bergner
Date: Thu Jul 8 04:12:04 2010
New Revision: 161942
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161942
Log:
PR middle-end/44828
* gcc.c-torture
--- Comment #7 from bergner at gcc dot gnu dot org 2010-07-07 22:51 ---
Jakub's test case still fails on powerpc*-linux because we default to unsigned
char. I think the obvious fix is to just pass -fsigned-char in dg-options.
--
bergner at gcc dot gnu dot org ch
--- Comment #5 from bergner at gcc dot gnu dot org 2010-07-06 16:59 ---
Fixed in trunk and the 4.5 branch.
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from bergner at gcc dot gnu dot org 2010-07-06 16:57 ---
Subject: Bug 44195
Author: bergner
Date: Tue Jul 6 16:57:21 2010
New Revision: 161874
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161874
Log:
Backport from mainline
2010-07-0
--- Comment #3 from bergner at gcc dot gnu dot org 2010-07-06 16:09 ---
Subject: Bug 44195
Author: bergner
Date: Tue Jul 6 16:09:13 2010
New Revision: 161872
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161872
Log:
PR testsuite/44195
* gcc.dg/lto/2010
--- Comment #8 from bergner at gcc dot gnu dot org 2010-07-02 19:52 ---
So what asm do we expect that we should get form the and-1.c testcase?
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bergner at gcc dot gnu dot org 2010-06-22 15:01 ---
I just noticed this on powerpc64-linux too. Can't we do something similar to
what test case 20081126_0.c does? Namely:
/* { dg-skip-if "" { ! { i?86-*-* x86_64-*-* } } { "*" } { "
--- Comment #12 from bergner at gcc dot gnu dot org 2010-06-09 14:15
---
Subject: Bug 44067
Author: bergner
Date: Wed Jun 9 14:15:11 2010
New Revision: 160479
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160479
Log:
Backport from mainline:
2010-06-0
--- Comment #7 from bergner at gcc dot gnu dot org 2010-06-07 20:55 ---
I'll note that the thread I pointed to in the previous comment mentioned that I
thought we should be handling DDmode the same as DFmode (normally we do), but
Joseph's post here:
http://gcc.gnu.org/ml/g
--- Comment #6 from bergner at gcc dot gnu dot org 2010-06-07 20:50 ---
I believe Edmar already bootstrapped and regtested the same patch.
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00346.html
--
bergner at gcc dot gnu dot org changed:
What|Removed
--- Comment #26 from bergner at gcc dot gnu dot org 2010-06-02 15:40
---
Subject: Bug 44199
Author: bergner
Date: Wed Jun 2 15:40:09 2010
New Revision: 160160
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160160
Log:
Backport from GCC 4.4:
2010-05-2
--- Comment #5 from bergner at gcc dot gnu dot org 2010-05-29 14:17 ---
Subject: Bug 44266
Author: bergner
Date: Sat May 29 14:17:26 2010
New Revision: 160028
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160028
Log:
Backport from mainline:
2010-05-
--- Comment #25 from bergner at gcc dot gnu dot org 2010-05-27 16:31
---
Subject: Bug 44199
Author: bergner
Date: Thu May 27 16:31:05 2010
New Revision: 159930
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159930
Log:
Backport from mainline:
2010-05-2
--- Comment #15 from bergner at gcc dot gnu dot org 2010-05-21 19:14
---
I also did a powerpc64-linux bootstrap and regtest (both 32-bit and 64-bit) and
I didn't see any new failures and I also did not see any extra UNSUPPORTED
tests. The only time UNSUPPORTED showed up i
--- Comment #7 from bergner at gcc dot gnu dot org 2010-05-19 21:52 ---
Pat is going to SPEC test the patch and will report back here with his results.
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bergner at gcc dot gnu dot org 2010-05-17 13:41 ---
Subject: Bug 44075
Author: bergner
Date: Mon May 17 13:41:22 2010
New Revision: 159487
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159487
Log:
Backport from mainline:
2010-05-
--- Comment #119 from bergner at gcc dot gnu dot org 2010-04-29 14:34
---
Subject: Bug 26854
Author: bergner
Date: Thu Apr 29 14:34:35 2010
New Revision: 158902
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158902
Log:
Backport from mainline.
2009-08-
--- Comment #113 from bergner at gcc dot gnu dot org 2010-04-29 14:34
---
Subject: Bug 33928
Author: bergner
Date: Thu Apr 29 14:34:35 2010
New Revision: 158902
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158902
Log:
Backport from mainline.
2009-08-
--- Comment #15 from bergner at gcc dot gnu dot org 2010-04-29 14:34
---
Subject: Bug 41081
Author: bergner
Date: Thu Apr 29 14:34:35 2010
New Revision: 158902
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158902
Log:
Backport from mainline.
2009-08-
--- Comment #14 from bergner at gcc dot gnu dot org 2010-04-28 22:53
---
Subject: Bug 41081
Author: bergner
Date: Wed Apr 28 22:52:57 2010
New Revision: 158846
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158846
Log:
Backport from mainline:
2009-08-
--- Comment #5 from bergner at gcc dot gnu dot org 2010-04-23 16:24 ---
Sorry, I meant type attribute where I mentioned variable attribute.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43859
--- Comment #4 from bergner at gcc dot gnu dot org 2010-04-23 16:15 ---
Interesting, using:
union __attribute__ ((transparent_union)) q
{
unsigned n;
unsigned get_n () const { return n; }
};
does seem to cure it. However, is the attribute location really incorrect? It
--- Comment #1 from bergner at gcc dot gnu dot org 2010-04-22 22:26 ---
Created an attachment (id=20466)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20466&action=view)
transparent_union test case
berg...@begna:~/reghunt/work>
/home/bergner/gcc/install/gcc-mainline-r12
normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bergner at gcc dot gnu dot org
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43859
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bergner at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43824
--- Comment #5 from bergner at gcc dot gnu dot org 2010-04-12 17:45 ---
Subject: Bug 25972
Author: bergner
Date: Mon Apr 12 17:44:59 2010
New Revision: 158231
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158231
Log:
Backport from ibm/gcc-4_3-branch
20
--- Comment #10 from bergner at gcc dot gnu dot org 2010-03-18 03:14
---
Fixed.
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #9 from bergner at gcc dot gnu dot org 2010-03-18 03:10 ---
Subject: Bug 42427
Author: bergner
Date: Thu Mar 18 03:10:04 2010
New Revision: 157530
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157530
Log:
gcc/
PR target/42427
* config/rs600
--- Comment #13 from bergner at gcc dot gnu dot org 2010-03-04 19:59
---
I verified this is fixed with a fresh checkout of mainline.
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from bergner at gcc dot gnu dot org 2010-03-04 19:08
---
This bug was fixed with Jeff Law's commit (revision 157168) of the patch
attached to the Patch URL listed above.
--
bergner at gcc dot gnu dot org changed:
What|Re
--- Comment #9 from bergner at gcc dot gnu dot org 2010-02-23 21:57 ---
This is a generic reload bug. With this test case and options, we have the
following instructions just before IRA:
(insn 203 2 213 2 (set (reg/f:DI 256 [ vect_pk.44 ])
(plus:DI (reg/f:DI 255
--- Comment #7 from bergner at gcc dot gnu dot org 2010-02-19 16:28 ---
Sorry, David and I talked offline about the last patch and he still has some
reservations about the code (even the pre-patched code). After discussing
this, I'm going to try adding a splitter which should hope
--- Comment #8 from bergner at gcc dot gnu dot org 2010-02-16 20:02 ---
Thanks for the reduced testcase. I'll have a look at what's wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42431
--- Comment #3 from bergner at gcc dot gnu dot org 2010-01-27 21:17 ---
Confirmed. Alan, can you have a look at this? This is ICE'ing at the
gcc_assert(!TARGET_SECURE_PLT) you added to define_insn
"*sibcall_value_nonlocal_sysv" as part of your fix for PR36634. The ins
--- Comment #5 from bergner at gcc dot gnu dot org 2010-01-14 21:12 ---
This ended up being a latent bug exposed by Bernd's patch. I posted a fix
here:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00678.html
--
bergner at gcc dot gnu dot org changed:
--- Comment #4 from bergner at gcc dot gnu dot org 2010-01-04 23:05 ---
Ahh, yes, you are correct. I can confirm the bogus assembly code. I'll
investigate.
--
bergner at gcc dot gnu dot org changed:
What|Removed |
--- Comment #2 from bergner at gcc dot gnu dot org 2010-01-04 21:57 ---
The assembly looks different and doesn't error with today's trunk (revision
155629). I'll try with the revision Janis pointed out and see if it really is
fixed or is just latent again.
--
htt
--- Comment #8 from bergner at gcc dot gnu dot org 2009-10-06 22:03 ---
Created an attachment (id=18732)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18732&action=view)
Potential patch to fix pr40737
Here is a patch from Adhemerval Zanella from our IBM LTC Performance tea
--- Comment #112 from bergner at gcc dot gnu dot org 2009-10-03 01:39
---
Subject: Bug 33928
Author: bergner
Date: Sat Oct 3 01:39:14 2009
New Revision: 152430
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152430
Log:
Backport from mainline.
2009-08-
--- Comment #111 from bergner at gcc dot gnu dot org 2009-10-03 01:39
---
Subject: Bug 26854
Author: bergner
Date: Sat Oct 3 01:39:14 2009
New Revision: 152430
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152430
Log:
Backport from mainline.
2009-08-
--- Comment #13 from bergner at gcc dot gnu dot org 2009-10-03 01:39
---
Subject: Bug 41081
Author: bergner
Date: Sat Oct 3 01:39:14 2009
New Revision: 152430
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152430
Log:
Backport from mainline.
2009-08-
--- Comment #12 from bergner at gcc dot gnu dot org 2009-10-02 17:12
---
Subject: Bug 41081
Author: bergner
Date: Fri Oct 2 17:12:31 2009
New Revision: 152411
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152411
Log:
Backport from mainline:
2009-08-
--- Comment #8 from bergner at gcc dot gnu dot org 2009-10-02 17:12 ---
Subject: Bug 40473
Author: bergner
Date: Fri Oct 2 17:12:31 2009
New Revision: 152411
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152411
Log:
Backport from mainline:
2009-08-
--- Comment #6 from bergner at gcc dot gnu dot org 2009-09-02 21:47 ---
My patch solved the problem, but was very very neutral wrt SPEC2000 scores.
Vlad's idea of moving update_equiv_regs() into its own pass before sched1 makes
sense to me and seems to produce better performing
--- Comment #5 from bergner at gcc dot gnu dot org 2009-08-26 20:57 ---
>From my bug analysis and request for comment on the mailinglist:
http://gcc.gnu.org/ml/gcc/2009-08/msg00485.html
This is caused by update_equiv_regs() which IRA inherited from local-alloc.c.
Although with
--- Comment #4 from bergner at gcc dot gnu dot org 2009-08-26 15:22 ---
It's update_equiv_regs() that is causing this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41171
--- Comment #3 from bergner at gcc dot gnu dot org 2009-08-26 15:14 ---
Actually, they're already reordered by the time we call ira_color and the ira
dumps shows that:
;; Function f (f)
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze c
--- Comment #2 from bergner at gcc dot gnu dot org 2009-08-26 13:44 ---
The problem here, is that for some reason, IRA is spilling the two pseudos in
the test case, even though it seems it should be trivial. Looking deeper.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41171
--- Comment #16 from bergner at gcc dot gnu dot org 2009-08-04 13:35
---
There have been many patches posted, but most have caused serious performance
degradations on power. However, the two latest patches to reload do not. They
are:
1) http://gcc.gnu.org/ml/gcc-patches/2009-07
--- Comment #17 from bergner at gcc dot gnu dot org 2009-07-02 16:48
---
Alan, do you have any ideas?
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #31 from bergner at gcc dot gnu dot org 2009-07-02 02:50
---
I think we recursed off the stack. This is the backtrace:
#0 0x1047bedc in gimple_boolify (expr=0x45e33c0) at
/home/bergner/gcc/PR40597/gcc-mainline-base/gcc/gimplify.c:2750
#1 0x1047e230
--- Comment #30 from bergner at gcc dot gnu dot org 2009-07-02 02:23
---
Comparing the testsuite runs against the result from r149023 (the commit
previous to the cond-optab checkin), the default 32-bit testsuite run showed no
regressions. The 64-bit default testsuite run has a few
--- Comment #29 from bergner at gcc dot gnu dot org 2009-07-01 21:05
---
The 64-bit default build finished bootstrapping with no errors too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
--- Comment #28 from bergner at gcc dot gnu dot org 2009-07-01 18:35
---
Mainline + patch from Comment #27 has passed bootstrap with a 32-bit default
build (the 64-bit default run is still running). I'm running the testsuite now
and will compare to one of Janis' rece
--- Comment #26 from bergner at gcc dot gnu dot org 2009-07-01 15:32
---
Created an attachment (id=18111)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18111&action=view)
And yet another one...
Here's another test case to use with the patch from Comment #25.
--- Comment #24 from bergner at gcc dot gnu dot org 2009-07-01 13:42
---
Created an attachment (id=18107)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18107&action=view)
Yet another ICE test case
New test case for use after the commit of the patch in Comment #23.
--
--- Comment #21 from bergner at gcc dot gnu dot org 2009-07-01 03:29
---
Created an attachment (id=18104)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18104&action=view)
Tetscase for use without comment #11 patch
/home/bergner/gcc/PR40597/build/gcc-mainline-base-32/./p
--- Comment #20 from bergner at gcc dot gnu dot org 2009-07-01 03:26
---
Here's a backtrace for a 32-bit default build without Comment #11 patch:
#0 fancy_abort (file=0x1096c5e4
"/home/bergner/gcc/PR40597/gcc-mainline-base/gcc/simplify-rtx.c", line=4966,
func
--- Comment #18 from bergner at gcc dot gnu dot org 2009-06-30 21:57
---
This is my backtrace:
#0 fancy_abort (file=0x1091d148
"/home/bergner/gcc/PR40597/gcc-mainline-base/gcc/simplify-rtx.c", line=4966,
function=0x1091dc04 "simplify_subreg") at
/home/ber
--- Comment #16 from bergner at gcc dot gnu dot org 2009-06-30 21:02
---
Created an attachment (id=18103)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18103&action=view)
Preprocessed testcase
Preprocessed source file compiled with:
/home/bergner/gcc/PR40597/build/gcc-m
--- Comment #14 from bergner at gcc dot gnu dot org 2009-06-30 18:40
---
Confirmed, a --with-cpu=default32 build dies with:
/home/bergner/gcc/PR40597/gcc-mainline-base/gcc/builtins.c: In function
get_memory_rtx:
/home/bergner/gcc/PR40597/gcc-mainline-base/gcc/builtins.c:1210:10
--- Comment #3 from bergner at gcc dot gnu dot org 2009-04-29 02:14 ---
Michael, did you configure with --enable-decimal-float? I can never remember
whether that is enabled by default for powerpc64-linux or not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39955
--- Comment #2 from bergner at gcc dot gnu dot org 2008-09-10 15:14 ---
With a mainline from today, it fails for me at -O2. Looking into it, it's
foo() that is miscompiled (I broke the 3 functions into their own files and
recompiled them), It's also the last element of r
--- Comment #4 from bergner at gcc dot gnu dot org 2008-09-10 15:14 ---
Sorry, ignore my Comment #3. It should have been posted to a different
bugzilla entry. :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
--- Comment #3 from bergner at gcc dot gnu dot org 2008-09-10 01:33 ---
With a mainline from today, it fails for me at -O2. Looking into it, it's
foo() that is miscompiled (I broke the 3 functions into their own files and
recompiled them), It's also the last element of r
--- Comment #13 from bergner at gcc dot gnu dot org 2008-08-28 03:52
---
There are actually a subset of TARGET_POWERP64 instructions that are safe to
use in 32-bit mode regardless of whether OS_MISSING_POWERPC64 is set or not
(eg, fcfid). For example, given the code below:
double
--- Comment #2 from bergner at gcc dot gnu dot org 2008-06-23 19:59 ---
Janis, is this fixed so we can close this bugzilla?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35712
--- Comment #2 from bergner at gcc dot gnu dot org 2008-06-23 19:57 ---
Janis, is this fixed with your patch so we can close this bugzilla?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35620
--- Comment #2 from bergner at gcc dot gnu dot org 2008-06-13 22:14 ---
We shouldn't be attempting to call mark_reg_pointer in set_reg_attrs_from_value
for a hard reg, since they can be shared between different values. Andrew
mentioned we maybe shouldn't
--- Comment #17 from bergner at gcc dot gnu dot org 2008-04-15 21:16
---
Created an attachment (id=15480)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15480&action=view)
Updated test case ready for inclusion in gcc's testsuite.
Ok, I bootstrapped (powerpc64-linux) a
--- Comment #16 from bergner at gcc dot gnu dot org 2008-04-15 14:36
---
I'll fire off a bootstrap and regtest of Alan's patch on powerpc64-linux and
running the test suite in 32-bit and 64-bit modes (ie, -m32 and -m64).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
--- Comment #11 from bergner at gcc dot gnu dot org 2008-04-11 22:04
---
Hacking the test case to use up more stack space, I did get it to access more
than 288 bytes below the stack frame for -m64, so we obviously need something
more here.
--
http://gcc.gnu.org/bugzilla
--- Comment #9 from bergner at gcc dot gnu dot org 2008-04-11 19:08 ---
This isn't accessing data below the stack pointer, it's accessing below the
previous stack pointer value which is in the current stack frame.
>From a technical standpoint, the ppc64 ABI allows us t
--- Comment #6 from bergner at gcc dot gnu dot org 2008-04-11 17:33 ---
FYI, it results in the updated asm:
--- glibc02-bad.s 2008-04-11 12:21:48.0 -0500
+++ glibc02-good.s 2008-04-11 12:21:33.0 -0500
@@ -66,12 +66,12 @@
mr 3,30
vadduwm 2,31,2
--- Comment #5 from bergner at gcc dot gnu dot org 2008-04-11 17:20 ---
Created an attachment (id=15467)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15467&action=view)
Restore altivec regs after frame pointer setup
I agree with Andrew, it looks like Eric's pat
--- Comment #53 from bergner at gcc dot gnu dot org 2008-04-09 15:38
---
Author: bergner
Date: Wed Apr 9 13:42:43 2008
New Revision: 134139
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134139
Log:
PR middle-end/PR28690
* explow.c (break_out_memory_re
--- Comment #51 from bergner at gcc dot gnu dot org 2008-04-08 18:50
---
Ok, I dug into this a little deeper. For the following test case:
int array[1024];
void
clear_table (unsigned int n)
{
unsigned int i;
for (i = 0; i < n; i++)
array[i] = 0;
}
compil
--- Comment #2 from bergner at gcc dot gnu dot org 2008-04-08 15:41 ---
An updated patch (minus the rtlanal.c which has since been reverted) has fixed
this problem.
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg02044.html
--
bergner at gcc dot gnu dot org changed:
What
--- Comment #49 from bergner at gcc dot gnu dot org 2008-04-08 14:49
---
The offending hunk has been reverted in revision 134095.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
--- Comment #3 from bergner at gcc dot gnu dot org 2008-04-08 14:47 ---
That hunk has been reverted:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00650.html
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from bergner at gcc dot gnu dot org 2008-03-07 15:44
---
(In reply to comment #11)
> Is there a reason why you don't use GET_MODE_SIZE (mode) != N in the
> expression?
Well, the T[IFD]mode don't allow reg+reg addressing, but other 8 byte modes
--- Comment #12 from bergner at gcc dot gnu dot org 2008-03-07 15:21
---
Subject: Bug 35373
Author: bergner
Date: Fri Mar 7 15:20:31 2008
New Revision: 133008
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133008
Log:
PR target/35373
* config/rs6000/
--- Comment #10 from bergner at gcc dot gnu dot org 2008-03-07 04:15
---
Created an attachment (id=15276)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15276&action=view)
Updated patch to disallow TFmode and TDmode from reg+reg addressing
Here is an updated patch t
--- Comment #8 from bergner at gcc dot gnu dot org 2008-03-04 05:25 ---
Created an attachment (id=15256)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15256&action=view)
Disallow TFmode and TDmode from reg+reg addressing
This ICE is similar to the one Nathan fixed which is
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.0 4.4.0
Priority|P3 |P2
1 - 100 of 145 matches
Mail list logo
