[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc > gcc-4.2.x
--- Comment #36 from amodra at bigpond dot net dot au 2009-10-07 22:35 --- Andreas, there is no way this bug can be fixed 100% in gcc, except perhaps if you are willing to compile -static. Source and/or compiler fixes only work to the extent that they limit code+data size to less than 33M. If you go over that size, and are using the old-style bss plt with .eh_frame data, then you start playing russian roulette. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc > gcc-4.2.x
--- Comment #33 from amodra at bigpond dot net dot au 2009-09-30 02:29 --- To save people looking through the binutils bug report, here's the bug analysis: "You are using the old-style plt and got rather than the new secure plt (forced by old startup files even if all the other code is capable of using the new secure plt). The old-style plt is a bss section, located towards the end of the image. Calls branch into the plt, then bounce from there to their final destination. At the time code is relaxed some data sections, located between .text and .plt, have not yet been sized. In particular, .eh_frame_hdr is still zero size. When this section is properly sized, some of the branches will no longer reach. This is a horrible bug. To fix it I'll need to change quite a lot of code in the linker, for all elf targets." So to avoid the bug you'll need a new linker (binutils 2.20 has the fix) or not use old libraries and startup files lacking -msecure-plt support. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
[Bug target/40473] -mno-sched-prolog breaks function parameter debug location lists
--- Comment #7 from amodra at bigpond dot net dot au 2009-09-23 22:39 --- . -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40473
[Bug target/41081] redundant ZERO_EXTENDs
--- Comment #10 from amodra at bigpond dot net dot au 2009-08-24 02:38 --- No, that looks like a different problem. It affects powerpc64 too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41081
[Bug target/41081] redundant ZERO_EXTENDs
--- Comment #7 from amodra at bigpond dot net dot au 2009-08-23 03:49 --- . -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41081
[Bug target/41081] redundant ZERO_EXTENDs
--- Comment #4 from amodra at bigpond dot net dot au 2009-08-16 03:07 --- Please ignore the RS6000_ALT_REG_ALLOC_ORDER hunk in rs6000-2.diff. I forgot to edit that out.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41081
[Bug target/41081] redundant ZERO_EXTENDs
--- Comment #3 from amodra at bigpond dot net dot au 2009-08-16 03:05 --- Created an attachment (id=18374) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18374&action=view) aims to teach gcc that rotate/shift insn input register's high bits are ignored This patch is aimed at the "79 other redundant clrldi", removing 59 cases on rotate/shift input. I'm not particularly happy with it due to hack for LOAD_EXTEND_OP zero_extends. Before I discovered that particular problem, fwprop seemed a natural place to teach gcc about insn inputs. If we don't leave those zero_extends alone, some rotate insns will take their input directly from the load, while other insns still need the zero_extend. This prevents combine from removing the zero_extend on loads. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41081
[Bug target/41081] redundant ZERO_EXTENDs
--- Comment #2 from amodra at bigpond dot net dot au 2009-08-16 02:45 --- Created an attachment (id=18373) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18373&action=view) Cure the zero_extends on rotate output This patch teaches gcc that the powerpc rotate/shift unit appropriately zero or sign extends to the full register width, at least for the most common case of SImode operations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41081
[Bug target/41081] redundant ZERO_EXTENDs
--- Comment #1 from amodra at bigpond dot net dot au 2009-08-16 02:41 --- Created an attachment (id=18372) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18372&action=view) block sha1 source blk_SHA1Block takes all its input from unsigned ints and only writes to unsigned ints, thus all zero_extends in the body of this function are redundant -- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41081
[Bug target/41081] New: redundant ZERO_EXTENDs
Linux kernel block sha1 code on powerpc64 has many redundant clrldi instructions, significantly slowing execution time. Current gcc seems to generate more of these than 3.4.5 which is in turn worse than 3.3. Breakdown of clrldi insns - 140 redundant clrldi on rotate insn output - 79 other redundant clrldi - 11 useful -- Summary: redundant ZERO_EXTENDs Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amodra at bigpond dot net dot au GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41081
[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc > gcc-4.2.x
--- Comment #18 from amodra at bigpond dot net dot au 2009-07-03 01:38 --- I wonder whether people reporting that this bug has not been fixed (at least for C/C++) realize that the fix needs to be in the sources you are building. It's not a fix that affects the installed compiler. I've resisted turning on relax by default in ld because it slows down link time due to adding another pass over the relocations in input files. I probably should look at doing something clever in ld. A neat trick would be to automatically turn on relax if executable sections have addresses that might result in reloc overflow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
[Bug middle-end/40493] [4.5 Regression] New SRA miscompiled binutils
--- Comment #5 from amodra at bigpond dot net dot au 2009-06-20 03:26 --- Oops, you're correct. I wan't using the compiler I thought I was. make CC=... wasn't passing $CC down to the bfd dir for some reason. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40493
[Bug middle-end/40493] [4.5 Regression] New SRA miscompiled binutils
--- Comment #3 from amodra at bigpond dot net dot au 2009-06-19 23:38 --- With 148536 and current mainline cvs binutils I see no failures in the gas testsuite. I do see a bunch of failures in the ld testsuite, which are all because /usr/bin/ld is being run despite a -B option being passed to gcc that should cause the newly built ld to be used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40493
[Bug target/40473] -mno-sched-prolog breaks function parameter debug location lists
--- Comment #3 from amodra at bigpond dot net dot au 2009-06-17 14:36 --- Created an attachment (id=18016) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18016&action=view) patch proposal Actually, it doesn't look all that hard to fix. The attached patch is a little horrible in that it doesn't use the normal method of insert_insn_on_edge(), commit_edge_insertions(), but we are too late for that. I tried, and found verify_flow_info() in commit_edge_insertions() was bombing on stuff already present. Patch currently bootstrapping with BOOT_CFLAGS="-g -O2 -mno-sched-prolog". -- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40473
[Bug target/40473] -mno-sched-prolog breaks function parameter debug location lists
--- Comment #1 from amodra at bigpond dot net dot au 2009-06-17 09:21 --- See http://sourceware.org/bugzilla/show_bug.cgi?id=10231 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40473
[Bug target/40473] New: -mno-sched-prolog breaks function parameter debug location lists
/* When compiled with -g -O -mno-sched-prolog, the debug info location
lists for p1 and p2 do not cover the start of f. There are other
inaccuracies, but not covering the start of the function is specific
to -nno-sched-prolog. */
int f (int p1, int p2)
{
extern int bar (int);
int x, y;
for (x = p1, y = 0; x < p2; x++)
y += bar (x);
return y;
}
--
Summary: -mno-sched-prolog breaks function parameter debug
location lists
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amodra at bigpond dot net dot au
GCC target triplet: powerpc-*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40473
[Bug tree-optimization/40222] New: anon namespace function emitted when all uses inlined
Seen on powerpc64-linux and i686-linux, probably all targets with sufficiently recent glibc. libstdc++-v3/libsupc++/eh_globals.cc get_global is defined inside anonymous namespace thus is local to the file. All uses of get_global are inlined, but get_global is still emitted. -- Summary: anon namespace function emitted when all uses inlined Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amodra at bigpond dot net dot au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40222
[Bug target/39634] powerpc64 libgcc contains useless softfp functions
--- Comment #4 from amodra at bigpond dot net dot au 2009-04-07 01:21 --- Fixed -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.3.4 4.4.0 4.5.0 |4.3.3 4.4.0 4.5.0 Resolution||FIXED Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39634
[Bug target/39634] powerpc64 libgcc contains useless softfp functions
-- amodra at bigpond dot net dot au changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail||4.3.4 4.4.0 4.5.0 Known to work||4.0.0 4.1.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2009-04-04 04:01:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39634
[Bug target/39634] New: powerpc64 libgcc contains useless softfp functions
softfp functions are not supposed to be compiled for the 64-bit version of libgcc, since 64-bit ABI doesn't suport softfp. -- Summary: powerpc64 libgcc contains useless softfp functions Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: amodra at bigpond dot net dot au ReportedBy: amodra at bigpond dot net dot au GCC target triplet: powerpc-*-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39634
[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails
--- Comment #8 from amodra at bigpond dot net dot au 2009-01-18 23:36 --- I believe that this is a user error and that this bugzilla should be closed. Your problem with ld "cannot find /tools/lib/libc.so.6 inside /tools" is simply that your glibc is built wrongly for your sysroot. (glibc is not sysroot aware.) You'll find that the script libc.so has a line something like GROUP ( /tools/lib/libc.so.6 /tools/usr/lib/libc_nonshared.a AS_NEEDED ( /tools/lib/ld-linux.so.2 ) ) The /tools sysroot prefix ought not be present on any of these paths. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35804
[Bug c++/37473] New: typedef results in wrong function call linkage
The following testcase compiled with -O -fPIC results in a non-PLT call to
A::check. On x86_64 that means an R_X86_64_PC32 reloc, which the linker later
correctly complains about if we are building a shared library. Curiously, if
either or both of the typedefs are removed, you get the code I'd expect.
typedef struct
{
int check ();
} A;
typedef struct
{
A a;
int validate ();
private:
int check ();
} B;
int
B::check ()
{
return a.check ();
}
int
B::validate ()
{
return check ();
}
int
doit ()
{
B b;
return b.validate ();
}
--
Summary: typedef results in wrong function call linkage
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amodra at bigpond dot net dot au
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37473
[Bug regression/37456] gcc4.4 ICE: verify_flow_info failed
-- amodra at bigpond dot net dot au changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet||powerpc-linux Last reconfirmed|-00-00 00:00:00 |2008-09-10 08:14:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37456
[Bug target/36955] [4.4 Regression] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #15 from amodra at bigpond dot net dot au 2008-07-30 02:44 --- . -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug target/36955] [4.4 Regression] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #13 from amodra at bigpond dot net dot au 2008-07-29 01:04 --- Blah, of course that's the wrong place to add the use_reg. Needs to be a few lines lower. I guess I may as well take this bug and go thru a boot/regress cycle. -- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED Last reconfirmed|2008-07-29 00:20:29 |2008-07-29 01:04:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug target/36955] [4.4 Regression] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #12 from amodra at bigpond dot net dot au 2008-07-29 00:37
---
So, the easy fix for this bug is (totally untested, not even compiled)
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 138134)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -3940,7 +3940,12 @@ rs6000_legitimize_tls_address (rtx addr,
else if (DEFAULT_ABI == ABI_AIX && !TARGET_64BIT)
insn = gen_tls_gd_aix32 (r3, got, addr, tga, const0_rtx);
else if (DEFAULT_ABI == ABI_V4)
- insn = gen_tls_gd_sysvsi (r3, got, addr, tga, const0_rtx);
+ {
+ insn = gen_tls_gd_sysvsi (r3, got, addr, tga, const0_rtx);
+ if (TARGET_SECURE_PLT && flag_pic == 2)
+ use_reg (&CALL_INSN_FUNCTION_USAGE (insn),
+pic_offset_table_rtx);
+ }
else
gcc_unreachable ();
@@ -3962,7 +3967,12 @@ rs6000_legitimize_tls_address (rtx addr,
else if (DEFAULT_ABI == ABI_AIX && !TARGET_64BIT)
insn = gen_tls_ld_aix32 (r3, got, tga, const0_rtx);
else if (DEFAULT_ABI == ABI_V4)
- insn = gen_tls_ld_sysvsi (r3, got, tga, const0_rtx);
+ {
+ insn = gen_tls_ld_sysvsi (r3, got, tga, const0_rtx);
+ if (TARGET_SECURE_PLT && flag_pic == 2)
+ use_reg (&CALL_INSN_FUNCTION_USAGE (insn),
+pic_offset_table_rtx);
+ }
else
gcc_unreachable ();
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug target/36955] [4.4 Regression] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #11 from amodra at bigpond dot net dot au 2008-07-29 00:20
---
When -fPIC, r30 needs to be set to point into the .got2 section for the
function, so that r30 is valid for the __tls_get_addr plt call stub. Note that
this is a different GOT pointer than that used by @[EMAIL PROTECTED], which
points into
the .got section (as for the -fpic GOT). If there's anything to boo about it's
this, rather than using a particular register for .got2 addressing. -fPIC tls
really ought to use the .got2 section too.
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
CC|amodra at bigpond dot net |
|dot au |
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-07-29 00:20:29
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug target/36634] -msecure-plt combine gives invalid call insn
--- Comment #6 from amodra at bigpond dot net dot au 2008-07-04 02:53 --- Fixed all active branches -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36634
[Bug target/36634] -msecure-plt combine gives invalid call insn
--- Comment #5 from amodra at bigpond dot net dot au 2008-07-04 02:53 --- Created an attachment (id=15850) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15850&action=view) patch for 4.1 Since there will be no more releases from 4.1 branch, I won't be applying the patch to that branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36634
[Bug target/36634] -msecure-plt combine gives invalid call insn
--- Comment #1 from amodra at bigpond dot net dot au 2008-06-27 01:52
---
(insn 9 8 11 1 (set (reg/v/f:SI 119 [ p ])
(mem/u/c:SI (plus:SI (reg:SI 30 30)
(const:SI (minus:SI (symbol_ref/u:SI ("*.LC2") [flags 0x2])
(symbol_ref:SI ("*.LCTOC1") [5 S4 A8])) -1 (nil)
(expr_list:REG_EQUAL (symbol_ref:SI ("myprint") [flags 0x1] )
(nil)))
[snip]
(call_insn 12 11 13 1 (parallel [
(call (mem:SI (reg/v/f:SI 119 [ p ]) [0 S4 A8])
(const_int 0 [0x0]))
(use (const_int 0 [0x0]))
(clobber (scratch:SI))
]) -1 (nil)
(nil)
(expr_list:REG_DEP_TRUE (use (reg:SI 3 3))
(nil)))
The first instruction is a GOT load of the function address, the second an
indirect call. No problem there. Indirect calls for -msecure-plt don't need
the GOT pointer to be valid.
The trouble occurrs when combine substitutes the first insn into the second to
get:
(call_insn 12 11 13 0 (parallel [
(call (mem:SI (symbol_ref:SI ("myprint") [flags 0x1] ) [0 S4 A8])
(const_int 0 [0x0]))
(use (const_int 0 [0x0]))
(clobber (scratch:SI))
]) 402 {*call_nonlocal_sysv} (insn_list:REG_DEP_TRUE 11 (nil))
(expr_list:REG_UNUSED (scratch:SI)
(expr_list:REG_DEAD (reg:SI 3 3)
(nil)))
(expr_list:REG_DEP_TRUE (use (reg:SI 3 3))
(nil)))
Note that lack of anything marking r30 as used.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36634
[Bug target/36634] -msecure-plt combine gives invalid call insn
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail||4.1.3 4.2.5 Last reconfirmed|-00-00 00:00:00 |2008-06-25 21:30:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36634
[Bug target/36634] New: -msecure-plt combine gives invalid call insn
The -msecure-plt ABI requires that -fpic/-fPIC calls via the PLT have the GOT
pointer register valid. gcc accomplishes this by adding pic_offset_table_rtx
to CALL_INSN_FUNCTION_USAGE for such calls at rtl expansion time. See
rs6000.md define_expand "call". Now, indirect calls do *not* need a GOT
pointer since they don't go via the PLT, and we wouldn't want indirect calls to
cause unnecessary code in a function prologue to set up the GOT pointer. This
is a lurking problem for the RTL combiner if it should happen to see an
opportunity to combine an instruction loading a function pointer followed by an
indirect call, since it will combine them to a PLT call that lacks a use of
pic_offset_table_rtx.
$ cat pr44759.c
#include
#include
extern void first_call (void);
int main (void)
{
first_call ();
printf ("All finished\n");
}
$ cat pr44759-1.c
#include
#include
typedef void (*simple) (signed int);
void myprint (unsigned int i)
{
printf("I am printing\n");
}
static inline void lets_inline (void (*p)(signed int), int v)
{
(*p)(v);
}
void first_call (void)
{
lets_inline ((simple)myprint, 0);
}
$ gcc -c pr44759.c -fPIC -O2 -msecure-plt
$ gcc -c pr44759-1.c -fPIC -O2 -msecure-plt
$ gcc -o libpr44759.so pr44759-1.o -fPIC -shared -msecure-plt
$ gcc -o pr44759 pr44759.o libpr44759.so
$ LD_LIBRARY_PATH=. ./pr44759
Segmentation fault
Note that the testcase does not fail on mainline or gcc-4.3, presumably because
combining happens at the tree level there. I'm also not sure whether the
testcase is completely valid code, but even if not, there may be other ways to
expose the rtl combine error.
--
Summary: -msecure-plt combine gives invalid call insn
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amodra at bigpond dot net dot au
GCC target triplet: powerpc-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36634
[Bug target/36525] New: prologue code may give invalid stack back chain
The SPU ABI states:
"The first word of the stack frame must always point to the previously
allocated stack frame (toward higher addresses), except for the first stack
frame, which must have a back chain pointer of 0 (NULL)."
SPU doesn't have a single instruction that can both write the back chain and
adjust the stack pointer, so keeping the above invariant in the presence of
interrupts is a little tricky. For frames smaller than 2000 bytes,
spu_expand_prologue first writes the back chain word, then adjusts the stack.
This is fine since we have a 2000 byte red zone. For frames larger than 2000
bytes, the stack is decremented first, then the back chain word is written.
This opens a small window where an interrupt can occur with an uninitialized
back chain. If the interrupt handler walks stack frames for some reason, it
will see a broken frame. Tools like oprofile are known to have such handlers.
A possible solution is to ensure that the back chain write and the stack adjust
insns are always in the same dispatch pair.
--
Summary: prologue code may give invalid stack back chain
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amodra at bigpond dot net dot au
GCC target triplet: spu-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36525
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #22 from amodra at bigpond dot net dot au 2008-04-17 12:29 --- Fixed -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #18 from amodra at bigpond dot net dot au 2008-04-16 00:41 --- My bootstrap and regression tests also pass. It took a while... I didn't have a recent baseline to compare against so needed to do two bootstraps. -- amodra at bigpond dot net dot au changed: What|Removed |Added Priority|P1 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #14 from amodra at bigpond dot net dot au 2008-04-14 10:25 --- Yes, I think you could use hard_frame_pointer_rtx in rs6000_emit_epilogue if frame_pointer_needed, anywhere up to the point where gprs are restored. Probably done best as a separate patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #12 from amodra at bigpond dot net dot au 2008-04-14 07:19 --- Created an attachment (id=15476) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15476&action=view) proposed patch I think we want something like the attached patch (as yet untested). Besides the epilogue bug exposed by alloca, there is another bug with vrsave. If all non-volatile gp and fp regs are saved/restored by a function, then vrsave will be stored at frame-288-4 for 64-bit. After sp is adjusted, this location may be trashed by an interrupt routine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug debug/35615] Debug information for .debug_loc section incorrect
--- Comment #8 from amodra at bigpond dot net dot au 2008-03-19 01:17 --- Can you attach the object file that has the odd file name entry? I can't reproduce this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35615
[Bug debug/35615] Debug information for .debug_loc section incorrect
--- Comment #7 from amodra at bigpond dot net dot au 2008-03-19 00:54 --- Following up on comment #4, it was this part of Nick's patch that fixed the --debug-dump=loc problem: "Correct list of attributes which can reference a location list." http://sourceware.org/ml/binutils/2007-11/msg00191.html hunk 1123,1137 that removed DW_AT_lower_bound and others. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35615
[Bug target/34393] ICE: in extract_insn, at recog.c:1990
--- Comment #8 from amodra at bigpond dot net dot au 2008-02-14 00:18 --- fix applied -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34393
[Bug target/34393] ICE: in extract_insn, at recog.c:1990
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||02/msg00437.html Status|NEW |ASSIGNED Last reconfirmed|2007-12-19 02:14:56 |2008-02-13 06:27:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34393
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #41 from amodra at bigpond dot net dot au 2007-11-05 04:45 --- In reply to #27, I'm reasonably happy with the idea of ld treating a zero offset into a discarded section as special. I'd also happily approve a patch that allowed relocations with addends against any local symbol (except for the section symbol) in a discarded section so long as the symbol value in the kept section was the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #26 from amodra at bigpond dot net dot au 2007-10-31 04:03 --- I believe the linker is correct to reject relocations against local symbols in discarded sections. The reason being that the linker allows linkonce (and comdat group) section contents to differ between two files, so that for example, two files may be compiled with different optimisations yet still link correctly. Since the contents may differ, the location of symbols within the section may also differ between files. Using the value of "local_sym + offset" in one file (in the discarded section) may point to an entirely wrong location in the other file (in the kept section). You could argue that the linker ought to look up the value of "local_sym" in the file with the kept section, but relocations against local symbols are often reduced to relocations against section symbols, so the original "local_sym" is lost. The situation is different with global symbols because globals are merged. The definition in the kept section will be used for all relocations. I hope this answers Geoff's remark "ld refuses to link your program for no good reason". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug target/33812] [4.3 Regression] ICE from epilogue vrsave code
--- Comment #12 from amodra at bigpond dot net dot au 2007-10-20 13:12 --- Patch applied -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.3 Regression] Vectorizer |[4.3 Regression] ICE from |testcases fail |epilogue vrsave code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33812
[Bug target/33812] [4.3 Regression] Vectorizer testcases fail
--- Comment #10 from amodra at bigpond dot net dot au 2007-10-20 00:08 --- Prior to my patch: .L.main1: mflr 0 mr 12,1 std 0,16(1) lis 0,0x ori 0,0,4656 stdux 1,1,0 mfvrsave 0 stw 0,-4(12) so we store vrsave at frame_top-4 ... lwz 12,-4(1) li 3,0 mtvrsave 12 but here we restore from frame_top+0xfff...f4656-4 ld 1,0(1) because the frame isn't popped until here. ld 0,16(1) mtlr 0 blr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33812
[Bug middle-end/33806] [regression 4.3] gfortran.dg/cray_pointers_2.f90 give an ICE at -O3 -m64 on Darwin
--- Comment #3 from amodra at bigpond dot net dot au 2007-10-19 23:51 --- *** This bug has been marked as a duplicate of 33812 *** -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33806
[Bug target/33812] [4.3 Regression] Vectorizer testcases fail
--- Comment #9 from amodra at bigpond dot net dot au 2007-10-19 23:51 --- *** Bug 33806 has been marked as a duplicate of this bug. *** -- amodra at bigpond dot net dot au changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33812
[Bug target/33812] [4.3 Regression] Vectorizer testcases fail
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED Last reconfirmed|2007-10-18 16:56:18 |2007-10-19 23:50:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33812
[Bug target/33812] [4.3 Regression] Vectorizer testcases fail
--- Comment #8 from amodra at bigpond dot net dot au 2007-10-19 23:48 --- I'm building a current powerpc64 compiler at the moment to verify, but I think this is because rs6000_emit_epilogue is now generating mems with address sp+offset where offset is too large. Prior to my patch we restored altivec regs and vrsave from the wrong address... Fix is to move the block of code restoring vrsave to after we have restored the old stack pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33812
[Bug target/33168] [4.3 Regression] GCC Boot failure, building libstc++
--- Comment #11 from amodra at bigpond dot net dot au 2007-09-26 14:27 --- We first choose a section here, when decl readonly_flag is false: #0 get_section (name=0x4cca824 ".data._ZSt15system_category", flags=512, decl=0x4e44000) at /src/gcc-current/gcc/varasm.c:527 #1 0x1067bd70 in get_block_for_decl (decl=0x4e44000) at /src/gcc-current/gcc/varasm.c:1196 #2 0x1067c588 in make_decl_rtl (decl=0x4e44000) at /src/gcc-current/gcc/varasm.c:1395 #3 0x1067d3d8 in notice_global_symbol (decl=0x4e44000) at /src/gcc-current/gcc/varasm.c:1558 #4 0x106dd04c in varpool_mark_needed_node (node=0x4f12500) at /src/gcc-current/gcc/varpool.c:192 #5 0x106dda78 in varpool_finalize_decl (decl=0x4e44000) at /src/gcc-current/gcc/varpool.c:297 #6 0x10403fac in rest_of_decl_compilation (decl=0x4e44000, top_level=1, at_end=0) at /src/gcc-current/gcc/passes.c:192 #7 0x1002c624 in make_rtl_for_nonlocal_decl (decl=0x4e44000, init=0x0, asmspec=0x10b4f398 "") at /src/gcc-current/gcc/cp/decl.c:5136 #8 0x1003e1ec in cp_finish_decl (decl=0x4e44000, init=0x0, init_const_expr_p=0 '\0', asmspec_tree=, flags=8) at /src/gcc-current/gcc/cp/decl.c:5511 Note flags=512 is SECTION_WRITE in get_section call. We set readonly near the end of cp_finish_decl. This change in the readonly flag is the cause of later trouble when assemble_variable is called, as targetm.section_type_flags (called from get_named_section, from get_variable_section, from assemble_variable) now returns 0. get_section is then called with flags=0, triggering the error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33168
[Bug target/32621] New: undefined weak sym test broken when pic
extern int foo () __attribute__ ((weak));
extern int bar __attribute__ ((weak));
int
main ()
{
if (foo)
foo ();
if (&bar)
bar++;
return 0;
}
When compiled with -fPIC, the tests for non-zero foo and bar address have a pic
adjustment made before comparing against zero. If the code is run at an
address other than where it was linked this will result in foo being called
when it is undefined, and similarly for bar.
--
Summary: undefined weak sym test broken when pic
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amodra at bigpond dot net dot au
GCC target triplet: spu-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32621
[Bug middle-end/29943] [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
--- Comment #14 from amodra at bigpond dot net dot au 2007-02-20 01:29 --- Patch applied -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug middle-end/29943] [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED Last reconfirmed|2006-11-23 02:12:55 |2007-02-20 01:28:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug target/29943] [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|amodra at bigpond dot net |unassigned at gcc dot gnu |dot au |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug target/29943] [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
--- Comment #7 from amodra at bigpond dot net dot au 2006-11-23 08:01
---
This is the simple patch I've bootstrapped and am currently regression testing.
Index: varasm.c
===
--- varasm.c(revision 119100)
+++ varasm.c(working copy)
@@ -981,6 +981,10 @@ use_blocks_for_decl_p (tree decl)
if (DECL_INITIAL (decl) == decl)
return false;
+ /* If this decl is an alias, then we don't want to emit a definition. */
+ if (lookup_attribute ("alias", DECL_ATTRIBUTES (decl)))
+return false;
+
return true;
}
Another possibility is to check for named sections in handle_alias_attribute
(and alias attributes in handle_section_attribute), possibly giving a
diagnostic. It's clear that code like
extern int a __attribute__ ((section (".sec1")));
extern int b __attribute__ ((section (".sec2")))
__attribute__ ((alias ("a")));
is invalid; b can't alias a and be in a different section. However, from the
previous discussion over 28598 I gather we don't want to go down the path of
checking section attributes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug target/29943] [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED Last reconfirmed|2006-11-22 22:21:39 |2006-11-23 02:12:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug target/29943] [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
--- Comment #4 from amodra at bigpond dot net dot au 2006-11-22 22:41 --- Not particularly. s/.data.rel.ro/.mysect/ does the same thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug target/29943] [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
--- Comment #2 from amodra at bigpond dot net dot au 2006-11-22 22:27
---
Removing __attribute__ ((section (".data.rel.ro"))) from _dl_argv_internal also
generates good code.
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
Component|middle-end |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug target/29943] [4.2 Regression] gcc generate incorrect alias symbols for PPC
--- Comment #1 from amodra at bigpond dot net dot au 2006-11-22 22:21 --- relevant -O2 assembly is .globl _dl_argv .globl _dl_argv_internal .hidden _dl_argv_internal .set_dl_argv_internal,_dl_argv .section.data.rel.ro,"aw",@progbits .align 2 .set.LANCHOR0,. + 0 .type _dl_argv_internal, @object .size _dl_argv_internal, 4 _dl_argv_internal: .zero 4 .type _dl_argv, @object .size _dl_argv, 4 _dl_argv: .zero 4 -fno-section-anchors generates good code -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-22 22:21:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug target/28904] operand out of range on Linux/PowerPC
--- Comment #3 from amodra at bigpond dot net dot au 2006-09-05 22:50 --- This is a limitation of the -fPIC implementation used on powerpc-linux. You get a maximum of 64K bytes of GOT entries per function (ie. 16K entries). -fpic is even more limited, with only 64K bytes of GOT for the entire executable. (-fpic used to be 32k for the entire executable until the linker was enhanced.) -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-05 22:50:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28904
[Bug target/28702] Profiler call clobbers lr
--- Comment #1 from amodra at bigpond dot net dot au 2006-08-13 02:45 --- Indeed it does. _mcount is supposed to restore lr before returning. -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28702
[Bug target/28207] 128-bit IBM long double misaligned on stack
--- Comment #4 from amodra at bigpond dot net dot au 2006-07-04 04:41 --- Patch applied 4.1 and 4.2 -- amodra at bigpond dot net dot au changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||07/msg00085.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28207
[Bug target/28207] 128-bit IBM long double misaligned on stack
-- amodra at bigpond dot net dot au changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-30 10:11:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28207
[Bug target/28207] 128-bit IBM long double misaligned on stack
--- Comment #1 from amodra at bigpond dot net dot au 2006-06-30 10:10 --- Created an attachment (id=11783) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11783&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28207
[Bug target/28207] New: 128-bit IBM long double misaligned on stack
long doubles are only aligned to word boundaries when passed via the stack (ie. to a function that uses more than 8 fp regs for other parameters). The va_arg support expects long doubles to be double word aligned, resulting in a mismatch between caller and callee for variable argument functions. -- Summary: 128-bit IBM long double misaligned on stack Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amodra at bigpond dot net dot au GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28207
[Bug target/28170] [4.1/4.2 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode
--- Comment #9 from amodra at bigpond dot net dot au 2006-06-27 01:47 --- Uh, that should be "INTVAL (sizeop) <= 0". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug target/28170] [4.1/4.2 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode
--- Comment #8 from amodra at bigpond dot net dot au 2006-06-27 01:41
---
I think insvdi_rshift_rlwimi_p is totally broken. It should look something
like the following to match the capabilities of rlwimi according to my reading
of the powerpc architecture specification.
/* Return 1 if operands will generate valid arguments to the rlwimi
instruction for insert with right shift in 64-bit mode. */
int
insvdi_rshift_rlwimi_p (rtx sizeop, rtx startop, rtx shiftop)
{
/* The field that we insert into must start in the low word. */
if (INTVAL (startop) < 32 || INTVAL (startop) >= 64)
return 0;
/* And it must end there too. */
if (INTVAL (sizeop) < 0 || INTVAL (sizeop) + INTVAL (startop) >= 64)
return 0;
/* The value we are inserting must also come from the low word.
Since the sign bit isn't in the low word, we don't need to worry
about ashiftrt vs. lshiftrt. */
if (INTVAL (shiftop) + INTVAL (sizeop) >= 32)
return 0;
return 1;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug tree-optimization/27657] [4.2 regression] bogus undefined reference error to static var with -g and -O
--- Comment #1 from amodra at bigpond dot net dot au 2006-05-29 03:07 --- Confirmed. The reference is the relocation for DW_AT_const_value. $ readelf -wi test.o [snip] <1><7a>: Abbrev Number: 8 (DW_TAG_variable) DW_AT_name: (indirect string, offset: 0x0): gconf_g_utf8_skip DW_AT_decl_file : 1 DW_AT_decl_line : 2 DW_AT_type: <89> DW_AT_const_value : 0 [snip] $ readelf -r test.o Relocation section '.rela.debug_info' at offset 0x53c contains 8 entries: [snip] 0085 0b01 R_PPC_ADDR32 utf8_skip_data + 0 -- amodra at bigpond dot net dot au changed: What|Removed |Added CC| |amodra at bigpond dot net | |dot au Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-29 03:07:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27657
[Bug target/27682] float to int conversion doesn't raise invalid exception
--- Comment #6 from amodra at bigpond dot net dot au 2006-05-29 02:52 --- Oh, I suppose rounding might change the result if we always subtract off 2**(n-1). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27682
[Bug target/27682] float to int conversion doesn't raise invalid exception
--- Comment #5 from amodra at bigpond dot net dot au 2006-05-29 02:48 --- Note that fctidz is used because we are converting to unsigned. gcc uses fctiwz if converting to int. Of course, it isn't correct to simply replace fctidz with fctiwz.. To get this right, gcc would need to generate something like the following fctidz 0,0 stfd 0,temp_slot(1) ld 9,temp_slot(1) rldicl 0,9,0,32 cmpd 0,9 beq .+8 mtfsb1 23 with the last three insns being the extras needed to set the invalid operation. Conversion to unsigned int on ppc32 will also need some tweaks. Hmm, there we are using code generated by optabs.c (search for comment "For an unsigned conversion, there is one more way to do it.") Why doesn't this code always subtract off 2**(n-1), convert, then add 2**(n-1)? That way we'd get the invalid op bits set correctly. -- amodra at bigpond dot net dot au changed: What|Removed |Added CC| |amodra at bigpond dot net | |dot au Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-29 02:48:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27682
[Bug target/27479] TLS accesses use one more instruction than necessary
--- Comment #3 from amodra at bigpond dot net dot au 2006-05-08 23:36 --- Either that, or rewrite rs6000 tls support without using unspecs.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27479
[Bug target/27479] TLS accesses use one more instruction than necessary
--- Comment #2 from amodra at bigpond dot net dot au 2006-05-08 23:28 --- Confirmed. TLS code sequences consist of address generation followed by address dereference, for all TLS models. The address generation part uses UNSPECs because we need to differentiate the addis/addi from other hi/lo_sum patterns: The TLS versions need to emit reloc specifiers. Existing combined patterns cannot be used. To fix this problem, the rs6000 backend needs to be taught how to combine the lo_sum lookalike part of the TLS address generation with the TLS load/store. I would guess that the easiest way to implement this is with new peephole2 patterns. -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-08 23:28:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27479
[Bug middle-end/27260] [4.1 Regression] ICE in expand_expr_real_1, at expr.c:6750
--- Comment #12 from amodra at bigpond dot net dot au 2006-05-08 06:14 --- Patch commited to 4.1 -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27260
[Bug middle-end/27095] [4.1 Regression] O2 produces duplicate code
--- Comment #11 from amodra at bigpond dot net dot au 2006-05-08 00:49 --- Testcase fixed by simply xfailing *-*-darwin*. It might be possible to tweak the pattern we match to accommodate darwin, but I'll leave that to a darwin maintainer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27095
[Bug middle-end/27260] [4.1/4.2 Regression] ICE in expand_expr_real_1, at expr.c:6750
--- Comment #7 from amodra at bigpond dot net dot au 2006-04-24 13:18 --- I'll look at it in the morning. I've been away this (extended) weekend, without email access. -- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED Last reconfirmed|2006-04-22 20:22:17 |2006-04-24 13:18:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27260
[Bug target/27230] many obj-c++.dg tests ICE in rs6000_output_function_epilogue
--- Comment #4 from amodra at bigpond dot net dot au 2006-04-21 01:53 --- Fixed mainline. -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27230
[Bug target/27230] many obj-c++.dg tests ICE in rs6000_output_function_epilogue
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-21 01:52:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27230
[Bug middle-end/25989] gomp ICE with -O2 and schedule(guided)
--- Comment #6 from amodra at bigpond dot net dot au 2006-04-20 03:04 --- Ditto on powerpc-linux, due to NULL for_stmt. #0 extract_omp_for_data (for_stmt=0x0, fd=0xffa80d78) at /src/gcc-current/gcc/omp-low.c:157 #1 0x10106a10 in expand_parallel_call (region=0x10792098, bb=0x40104d20, entry_stmt=0x400f4f90, ws_args=0x40102f00) at /src/gcc-current/gcc/omp-low.c:2038 #2 0x1010a4e8 in expand_omp (region=0x10792098) at /src/gcc-current/gcc/omp-low.c:2392 #3 0x1010b224 in execute_expand_omp () at /src/gcc-current/gcc/omp-low.c:3332 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25989
[Bug target/11594] testcase gcc.dg/20020103-1.c fails with "scan-assembler-not LC"
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|amodra at bigpond dot net |unassigned at gcc dot gnu |dot au |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11594
[Bug rtl-optimization/26026] power of 2 mod missing optimisation
--- Comment #4 from amodra at bigpond dot net dot au 2006-04-18 23:46 --- Patch applied mainline -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26026
[Bug middle-end/27095] [4.1 Regression] O2 produces duplicate code
--- Comment #8 from amodra at bigpond dot net dot au 2006-04-18 12:35 --- As Roger requested, I was waiting a few days to apply the patch on the 4.1 branch. -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Priority|P2 |P3 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27095
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #32 from amodra at bigpond dot net dot au 2006-04-17 00:09 --- I've closed this bug incorrectly twice, the last time simply because I hadn't committed a patch already in my tree. Edmar, please resolve this bug as fixed if e500 is back in bootstrap land. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug middle-end/27095] [4.1/4.2 Regression] O2 produces duplicate code
--- Comment #3 from amodra at bigpond dot net dot au 2006-04-12 07:12 --- Testing a fix -- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED Last reconfirmed|2006-04-09 21:49:06 |2006-04-12 07:12:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27095
[Bug pending/27092] Compiling a special asm-statment will fail if -O1 -fgcse is set.
--- Comment #2 from amodra at bigpond dot net dot au 2006-04-11 06:09 --- Current 4.0, 4.1, and mainline compile the testcase OK. -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27092
[Bug target/18900] Don't use fp/vmx regs for mem moves without explicit use of fp/vmx
--- Comment #3 from amodra at bigpond dot net dot au 2006-04-11 02:10 --- The same issue applies to VMX (Altivec) registers. With lazy fp/vmx task switching, the first use of fp/vmx regs in a task can be expensive. -- amodra at bigpond dot net dot au changed: What|Removed |Added Summary|Should be able to not use fp|Don't use fp/vmx regs for |moves for functions that|mem moves without explicit |don't implicted use float |use of fp/vmx |point registers | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18900
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #27 from amodra at bigpond dot net dot au 2006-04-11 00:37 --- Sorry! My apologies for closing this bug without checking that the original problem had been fixed. I was focusing on the code generation problems. -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug target/27075] [4.1/4.2 Regression] Compiler generate incorrect assembler for __sync_fetch-* builtins on e500 aka SPE
--- Comment #8 from amodra at bigpond dot net dot au 2006-04-09 13:51
---
This horrible hack should cure the problem, I think. The rationale is that
spe.md uses %y only for evldd and evstdd insns, which load or store 8 bytes.
The lock insns use %y for 4 byte quantities (e500 doesn't support 64-bit
ldarx/stdcx. as far as I know).
--- rs6000.c(revision 112800)
+++ rs6000.c(working copy)
@@ -10750,7 +10750,7 @@ print_operand (FILE *file, rtx x, int co
tmp = XEXP (x, 0);
- if (TARGET_E500)
+ if (TARGET_E500 && GET_MODE_SIZE (GET_MODE (x)) == 8)
{
/* Handle [reg]. */
if (GET_CODE (tmp) == REG)
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
CC| |amodra at bigpond dot net
| |dot au
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27075
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #23 from amodra at bigpond dot net dot au 2006-03-31 01:54 --- Fixed -- amodra at bigpond dot net dot au changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||03/msg01751.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #19 from amodra at bigpond dot net dot au 2006-03-27 01:41 --- After applying the patch, I decided I really ought to find where the regression from 4.0 occurred. It's a pity I didn't do that before developing the patch.. To my surprise I found that on the face of it, 4.0 ought to have the same problem, because it has exactly the same peephole. A debug session revealed that 4.0 doesn't think that (subreg:DF (reg:DI 3 3 [128]) 0) is a valid gpc_reg_operand for e500 double target, while 4.1 does. After some head-scratching, I discovered the reason for this is the TARGET_IEEEQUAD change to rs6000.h:CANNOT_CHANGE_MODE_CLASS (well, really, it's the change to use IBM extended double for powerpc-linux targets). The first few lines of this macro are: #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \ (!TARGET_IEEEQUAD \ && GET_MODE_SIZE (FROM) >= 8 && GET_MODE_SIZE (TO) >= 8\ ? 0\ This of course interacts badly with later TARGET_E500_DOUBLE tests for DFmode and DImode, because now that TARGET_IEEEQUAD is false for linuxspe, we never get to make the TARGET_E500_DOUBLE checks. At the minimum, the TARGET_E500_DOUBLE checks ought to be done before this test allows a zero return. These lines were added here PR target/11848 * rs6000.h (CANNOT_CHANGE_MODE_CLASS): Allow change of mode in floating-point registers between TFmode and DImode. Really, I think it would be better to check for TFmode<->DImode explicitly rather than the rather obscure check that Geoff added. We have quite a few modes that have size greater than eight. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #16 from amodra at bigpond dot net dot au 2006-03-25 03:00 --- Indeed, that patch cures the problem. -- amodra at bigpond dot net dot au changed: What|Removed |Added CC|amodra at bigpond dot net | |dot au | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED Last reconfirmed|2006-02-24 18:42:12 |2006-03-25 02:59:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #15 from amodra at bigpond dot net dot au 2006-03-24 14:23 --- Appears to be the peephole in rs6000.md immediately after this comment: ;; after inserting conditional returns we can sometimes have ;; unnecessary register moves. (subreg:DF (reg:DI 3 3 [128]) 0) is a valid gpc_reg_operand. Try this (totally untested) patch. Index: gcc/config/rs6000/rs6000.md === --- gcc/config/rs6000/rs6000.md (revision 112347) +++ gcc/config/rs6000/rs6000.md (working copy) @@ -9771,18 +9771,20 @@ "operands[0] = widen_memory_access (operands[0], V2DFmode, 0); operands[1] = gen_rtx_REG (V2DFmode, REGNO (operands[1]));") -;; after inserting conditional returns we can sometimes have +;; After inserting conditional returns we can sometimes have ;; unnecessary register moves. Unfortunately we cannot have a ;; modeless peephole here, because some single SImode sets have early ;; clobber outputs. Although those sets expand to multi-ppc-insn ;; sequences, using get_attr_length here will smash the operands ;; array. Neither is there an early_cobbler_p predicate. +;; Disallow subregs for E500 so we don't munge frob_di_df_2. (define_peephole2 [(set (match_operand:DF 0 "gpc_reg_operand" "") (match_operand:DF 1 "any_operand" "")) (set (match_operand:DF 2 "gpc_reg_operand" "") (match_dup 0))] - "peep2_reg_dead_p (2, operands[0])" + "!(TARGET_E500_DOUBLE && GET_CODE (operands[2]) == SUBREG) + && peep2_reg_dead_p (2, operands[0])" [(set (match_dup 2) (match_dup 1))]) (define_peephole2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug target/26607] [4.1/4.2 Regression] Illegal inlined assembler on config/rs6000/darwin-ldouble.c
--- Comment #7 from amodra at bigpond dot net dot au 2006-03-23 22:37 --- fixed -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26607
[Bug target/26607] [4.1/4.2 Regression] Illegal inlined assembler on config/rs6000/darwin-ldouble.c
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-21 05:14:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26607
[Bug target/26453] [3.4 Regression] Segfault with -m64 -mtraceback=full
--- Comment #4 from amodra at bigpond dot net dot au 2006-03-19 22:28 --- 3.4 branch is closed -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|3.3.6 4.2.0 4.1.1 |3.3.6 4.2.0 4.1.1 4.0.4 Resolution||FIXED Summary|[3.4/4.0 Regression]|[3.4 Regression] Segfault |Segfault with -m64 -|with -m64 -mtraceback=full |mtraceback=full | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26453
[Bug target/26525] New: missed opportunity to use value in fp reg
The following compiled with -m64 -O2 -S
double f1 (double xh)
{
long long hi = (long long) xh;
if (hi == __LONG_LONG_MAX__)
{
xh += -__LONG_LONG_MAX__ - 1;
xh += 1.0;
}
else
xh -= hi;
return xh;
}
generates
fctidz 0,1
li 0,-1
rldicl 0,0,0,1
stfd 0,-16(1)
ld 9,-16(1)
cmpd 7,9,0
beq 7,.L7
std 9,-16(1)#
nop #
nop #
nop #
lfd 13,-16(1) #
fcfid 0,13 #
fsub 1,1,0
blr
.p2align 4,,15
.L7:
lfs 0,[EMAIL PROTECTED](2)
lfs 13,[EMAIL PROTECTED](2)
fsub 0,1,0
fadd 1,0,13
blr
The sequence marked with # could be replaced with just one insn,
fcfid 0,0
because HI is in fr0 at that point.
A similar function
double f2 (double xh)
{
long long hi = (long long) xh;
xh -= hi;
if (hi == __LONG_LONG_MAX__)
{
xh += hi;
xh += -__LONG_LONG_MAX__ - 1;
xh += 1.0;
}
return xh;
}
does use the value in th fp reg
fctidz 0,1
li 0,-1
rldicl 0,0,0,1
stfd 0,-16(1)
fcfid 0,0 <== here
fsub 1,1,0
ld 9,-16(1)
cmpd 7,9,0
bnelr 7
fadd 0,0,1
lfs 13,[EMAIL PROTECTED](2)
lfs 12,[EMAIL PROTECTED](2)
fsub 0,0,13
fadd 1,0,12
blr
--
Summary: missed opportunity to use value in fp reg
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amodra at bigpond dot net dot au
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26525
[Bug target/21616] [3.4 only] ICE: unable to find a register to spill in class `FLOAT_REGS'
--- Comment #13 from amodra at bigpond dot net dot au 2006-03-01 01:06 --- . -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21616
[Bug target/21616] [3.4 only] ICE: unable to find a register to spill in class `FLOAT_REGS'
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED Known to work||3.3.6 Last reconfirmed|2006-01-07 01:55:02 |2006-02-28 23:55:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21616
[Bug target/26453] Segfault with -m64 -mtraceback=full
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail||3.4.6 4.1.0 4.2.0 Known to work||3.3.6 Last reconfirmed|-00-00 00:00:00 |2006-02-24 02:02:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26453
[Bug target/26453] New: Segfault with -m64 -mtraceback=full
The following segfaults in rs6000_output_function_epilogue when compiled with
-m64 -mtraceback=full. r_o_f_e is being called via final_end_function in
rs6000_output_mi_thunk. This is a regression from gcc-3.3.x.
class A1 {
public:
virtual ~A1();
};
class A2 : public A1 { };
class A3 : virtual public A2 { };
class A4 : public A3 {
public:
~A4(void);
};
A4::~A4(void) {}
--
Summary: Segfault with -m64 -mtraceback=full
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amodra at bigpond dot net dot au
GCC target triplet: powerpc64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26453
