[Bug target/53040] nested functions may trash floating point registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53040 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Alan Modra 2013-02-06 02:39:54 UTC --- Fixed. Not a regression so not applying to FSF branches.
[Bug target/53038] cfi_restore for cr before cr is actually restored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53038 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Alan Modra 2013-02-06 03:04:58 UTC --- Fixed mainline. Not a regression so not applying to FSF branches.
[Bug target/54009] incorrect code generated for DFmode lo_sum mem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54009 --- Comment #4 from Alan Modra 2013-02-06 13:04:43 UTC --- Regressed due to pr54131 fix.
[Bug target/53040] nested functions may trash floating point registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53040 --- Comment #6 from Alan Modra 2013-02-06 13:31:45 UTC --- This one is hardly an annoying bug. You need a) nested functions, b) using floating point, c) with an unusual set of callee saved fprs, d) and -Os. I found the bug only because I wrote a fairly complete test for prologue/epilogue code. OTOH, the patch is quite obvious and completely safe..
[Bug target/44364] Wrong code with e500 double floating point
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #50 from Alan Modra 2013-02-07 01:44:07 UTC --- Fixed all currently active branches.
[Bug target/54009] incorrect code generated for DFmode lo_sum mem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54009 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Alan Modra 2013-02-07 02:46:30 UTC --- Fixed.
[Bug target/45053] libgcc_s link command misses crtsavgpr_s and crtresgpr_s for powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45053 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED CC||amodra at gmail dot com AssignedTo|unassigned at gcc dot |amodra at gmail dot com |gnu.org | --- Comment #12 from Alan Modra 2013-02-07 08:36:45 UTC --- Some of the claims made in various comments are wrong, at least for current gcc-4.7 svn rev 195829. Even the subject is wrong. libgcc_s.so *is* linked with the crtsav/res objects. They are contained in libgcc.a, and libgcc.a is used when linking libgcc_s.so. I have verified that libgcc_s.so built with -Os due to --enable-target-optspace does need various _savegpr* and _restgpr* functions. Comment #4 shows the real problem nicely. Notice that the reference to _savegpr_31 comes from crtend.o which the penultimate object on the linker command line, *after* libgcc.a. So if no other object linked needs the out-of-line register save functions they won't be extracted from libgcc.a. $ nm crtbegin.o | grep gpr U _restgpr_29_x $ nm crtend.o | grep gpr U _restgpr_31_x U _savegpr_31
[Bug target/45053] libgcc_s link command misses crtsavgpr_s and crtresgpr_s for powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45053 --- Comment #13 from Alan Modra 2013-02-07 08:40:15 UTC --- Created attachment 29382 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29382 Fix
[Bug target/55431] Invalid auxv search in ppc linux-unwind code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED CC|amodra at gcc dot gnu.org |amodra at gmail dot com AssignedTo|unassigned at gcc dot |amodra at gmail dot com |gnu.org |
[Bug target/55431] Invalid auxv search in ppc linux-unwind code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431 --- Comment #5 from Alan Modra 2013-02-12 03:04:28 UTC --- Created attachment 29420 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29420 use /proc/self/auxv At the time the original code was being developed, linux-2.4.x was in widespread use. /proc/self/auxv was introduced with linux-2.6.0 in Dec 2003. I guess it's reasonable to rely on that nowadays. BTW, it's not entirely an optimization to condition reading of altivec regs on AT_HWCAP. I believe it may be possible to segv if the unwinder tries to dereference a location past the end of struct sigcontext.
[Bug target/55431] Invalid auxv search in ppc linux-unwind code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431 --- Comment #7 from Alan Modra 2013-02-12 13:23:59 UTC --- On thinking about this a little more, the idea of using /proc/self/auxv isn't that good. MD_FALLBACK_FRAME_STATE_FOR is only needed for older kernels; Kernels 2.6.15 and later provide a vdso with unwind info for signal frames. So I don't think it makes sense to restrict libgcc's support for old kernels to 2.6.0 thru 2.6.14. If we're going to support old kernels, then we ought to continue supporting them all as best we can. And, yes, really old kernels used a different sigcontext for the simple reason that they predated altivec. I'm inclined to close this bug as WONTFIX, or possibly make __libc_stack_end weak so that libgcc builds with musl libc.
[Bug target/55431] Invalid auxv search in ppc linux-unwind code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-02/msg00744.htm ||l Resolution||FIXED --- Comment #10 from Alan Modra 2013-02-15 13:54:58 UTC --- Fixed
[Bug target/55431] Invalid auxv search in ppc linux-unwind code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431 Alan Modra changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #16 from Alan Modra 2012-10-24 05:35:06 UTC --- gas is broken. http://sourceware.org/bugzilla/show_bug.cgi?id=14758
[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619 --- Comment #17 from Alan Modra 2012-10-26 03:51:35 UTC --- Fixed in gas and ld. I think the only thing that needs doing in gcc is fixing the lwa constraint.
[Bug libstdc++/52839] [4.7/4.8 Regression] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #36 from Alan Modra 2012-11-02 02:13:20 UTC --- The change I mention in #c22 http://gcc.gnu.org/viewcvs?view=revision&revision=184110 tests for atomic ops on all of bool, short, int and long long, where the previous test was for *either* atomic bool or atomic short. My fix for powerpc removed the long long test. Does mips lack atomic on bool or short?
[Bug libstdc++/52839] [4.7/4.8 Regression] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #38 from Alan Modra 2012-11-02 02:39:29 UTC --- Ah, the #c3 fail on powerpc was due to a powerpc glibc pthread_once bug. And comment #36 should have read: ..previous test was for *either* atomic bool or atomic int.
[Bug target/65780] [5 Regression] Uninitialized common handling in executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-16 CC||amodra at gmail dot com Ever confirmed|0 |1 --- Comment #4 from Alan Modra --- optopt is common, and from a linker perspective I believe the correct resolution of a common symbol in the executable and a strong definition in a shared library, is the shared library symbol. Therefore the change to binds_local_p is wrong. What's going on here is that HJ has made changes for x86 to always copy variables defined in a shared library into the executable's .dynbss if referenced by the executable. This is necessary to support non-PIC without text relocations, but isn't necessary for PIC. It is certainly possible to do this for PIC but I think only x86 does so.
[Bug target/65780] [5 Regression] Uninitialized common handling in executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780 Alan Modra changed: What|Removed |Added CC|amodra at gcc dot gnu.org | Summary|[5 Regression] |[5 Regression] |Uninitialized common|Uninitialized common |handling in PIE |handling in executables --- Comment #8 from Alan Modra --- Changing the summary back to as it was. -fPIE is not necessary to show this bug on powerpc64 (or mips by the look of comment #1).
[Bug target/65779] [5/6 Regression] undefined local symbol on powerpc [regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #2 from Alan Modra ---
The underlying problem here is that this sequence setting up the GOT/TOC
pointer in adler32():
(insn 358 357 359 2 (parallel [
(set (reg:SI 65 lr)
(symbol_ref:SI ("*.LCF2")))
(use (unspec [
(symbol_ref:SI ("*.LCF2"))
] UNSPEC_TOC))
])
../../../../../../../../../rtems/c/src/lib/libbsp/powerpc/motorola_p\
owerpc/bootloader/../../../powerpc/shared/bootloader/zlib.c:2081 -1
(nil))
(insn 359 358 360 2 (set (reg:SI 30 30)
(reg:SI 65 lr))
../../../../../../../../../rtems/c/src/lib/libbsp/power\
pc/motorola_powerpc/bootloader/../../../powerpc/shared/bootloader/zlib.c:2081
-\
1
(expr_list:REG_DEAD (reg:SI 65 lr)
(nil)))
(insn 360 359 376 2 (set (reg:SI 0 0)
(mem:SI (plus:SI (reg:SI 30 30)
(minus:SI (symbol_ref:SI ("*.LCL2"))
(symbol_ref:SI ("*.LCF2" [0 S4 A8]))
../../../../../..\
/../../../rtems/c/src/lib/libbsp/powerpc/motorola_powerpc/bootloader/../../../p\
owerpc/shared/bootloader/zlib.c:2081 -1
(nil))
(debug_insn 376 360 361 2 (var_location:SI D#37 (reg/v:SI 0 0 [orig:239 s2 ]
[2\
39])) -1
(nil))
(insn 361 376 362 2 (set (reg:SI 30 30)
(plus:SI (reg:SI 0 0)
(reg:SI 30 30)))
../../../../../../../../../rtems/c/src/lib/libbsp/\
powerpc/motorola_powerpc/bootloader/../../../powerpc/shared/bootloader/zlib.c:2\
081 -1
(expr_list:REG_DEAD (reg:SI 0 0)
(expr_list:REG_UNUSED (reg:SI 30 30)
(nil
is deleted by peephole2
DCE: Deleting insn 361
deleting insn with uid = 361.
DCE: Deleting insn 360
deleting insn with uid = 360.
DCE: Deleting insn 359
deleting insn with uid = 359.
DCE: Deleting insn 358
deleting insn with uid = 358.
resulting in uses_TOC() returning false due to not finding UNSPEC_TOC, and thus
not emitting the labels. Deleting the insns is correct; we don't need the GOI
pointer set up in adler32(). gcc-4.9 also does the same thing, but doesn't
leak the labels into debug insns.
[Bug target/65779] [5/6 Regression] undefined local symbol on powerpc [regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779
--- Comment #3 from Alan Modra ---
Re comment #1, insn 36 is not removed, but moved later to bb3
(insn 363 364 41 3 (set (reg/v:SI 0 0 [orig:239 s2 ] [239])
(lshiftrt:SI (reg/v:SI 3 3 [orig:265 adler ] [265])
(const_int 16 [0x10]))) 270 {lshrsi3}
(nil))
(debug_insn 41 363 42 3 (var_location:SI s2 (reg/v:SI 0 0 [orig:239 s2 ]
[239])\
) -1
(nil))
The trouble is that the original debug insn is not removed. We still have
(debug_insn 37 35 39 2 (var_location:SI s2 (reg/v:SI 0 0 [orig:239 s2 ]
[239]))\
../../../../../../../../../rtems/c/src/lib/libbsp/powerpc/motorola_powerpc/boo\
tloader/../../../powerpc/shared/bootloader/zlib.c:2083 -1
(nil))
but this is not valid. s2 does *not* live in reg:SI 0 at this point.
[Bug debug/65779] [5/6 Regression] undefined local symbol on powerpc [regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779 --- Comment #4 from Alan Modra --- Created attachment 35342 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35342&action=edit prototype patch This seems to cure the testcase. I haven't bootstrapped it, and it probably isn't ideal since I haven't poked at debug insns a lot.. Still, it points out where the problem is, in move_insn_for_shrink_wrap. --- Comment #5 from Alan Modra --- Hmm, the bootstrap didn't get very far. Seems I need a df_insn_rescan_debug_internal (dinsn); after setting INSN_VAR_LOCATION_LOC. Maybe the debug insn in this case can be deleted?
[Bug target/65810] New: powerpc64 libgfortran alignment issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810
Bug ID: 65810
Summary: powerpc64 libgfortran alignment issue?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Testsuite results between two identical powerpc64-linux builds, except for the
source path name, differ.
+FAIL: gfortran.dg/fmt_en.f90 -O0 execution test
+FAIL: gfortran.dg/fmt_en.f90 -O0 scan-file All kinds rounded to nearest
+FAIL: gfortran.dg/fmt_en.f90 -O1 execution test
+FAIL: gfortran.dg/fmt_en.f90 -O1 scan-file All kinds rounded to nearest
+FAIL: gfortran.dg/fmt_en.f90 -O2 execution test
+FAIL: gfortran.dg/fmt_en.f90 -O2 scan-file All kinds rounded to nearest
+FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer execution test
+FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions execution test
+FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions scan-file All kinds rounded to nearest
+FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer -funroll-loops
execution test
+FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer -funroll-loops
scan-file All kinds rounded to nearest
+FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer scan-file All kinds
rounded to nearest
+FAIL: gfortran.dg/fmt_en.f90 -O3 -g execution test
+FAIL: gfortran.dg/fmt_en.f90 -O3 -g scan-file All kinds rounded to nearest
+FAIL: gfortran.dg/fmt_en.f90 -Os execution test
+FAIL: gfortran.dg/fmt_en.f90 -Os scan-file All kinds rounded to nearest
+FAIL: gfortran.dg/large_real_kind_1.f90 -O0 execution test
+FAIL: gfortran.dg/large_real_kind_1.f90 -O1 execution test
+FAIL: gfortran.dg/large_real_kind_1.f90 -O2 execution test
+FAIL: gfortran.dg/large_real_kind_1.f90 -O3 -fomit-frame-pointer execution
test
+FAIL: gfortran.dg/large_real_kind_1.f90 -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions execution test
+FAIL: gfortran.dg/large_real_kind_1.f90 -O3 -fomit-frame-pointer
-funroll-loops execution test
+FAIL: gfortran.dg/large_real_kind_1.f90 -O3 -g execution test
+FAIL: gfortran.dg/large_real_kind_1.f90 -Os execution test
+FAIL: gfortran.dg/quad_2.f90 -O0 execution test
+FAIL: gfortran.dg/quad_2.f90 -O1 execution test
+FAIL: gfortran.dg/quad_2.f90 -O2 execution test
+FAIL: gfortran.dg/quad_2.f90 -O3 -fomit-frame-pointer execution test
+FAIL: gfortran.dg/quad_2.f90 -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions execution test
+FAIL: gfortran.dg/quad_2.f90 -O3 -fomit-frame-pointer -funroll-loops
execution test
+FAIL: gfortran.dg/quad_2.f90 -O3 -g execution test
+FAIL: gfortran.dg/quad_2.f90 -Os execution test
Both compilers configured with
CC="gcc -m64" CXX="g++ -m64" \
${gcc_src}/configure --build=powerpc64-linux \
--with-cpu=power7 \
--disable-nls --enable-__cxa_atexit --enable-secureplt \
--with-long-double-128 --enable-gnu-indirect-function \
--enable-languages=all,go --enable-lto
In one case gcc_src=/home/amodra/src/gcc-5-virgin
the other gcc_src=/home/amodra/src/gcc-5-vir
Running the testcases by hand with different LD_LIBRARY_PATH show the problem
is in libgfortran, not the testcase code. valgrind doesn't show any
uninitialized accesses.
Looking at quad_2.f90 under gdb, I see the abort is due to str3 having an extra
leading space.
[Bug target/65810] powerpc64 libgfortran alignment issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810 --- Comment #3 from Alan Modra --- amodra@bns:~/build/gcc-5-virgin> gcc/gfortran -v Using built-in specs. COLLECT_GCC=gcc/gfortran Target: powerpc64-linux Configured with: /home/amodra/src/gcc-5-virgin/configure --build=powerpc64-linux --with-cpu=power7 --disable-nls --enable-__cxa_atexit --enable-secureplt --with-long-double-128 --enable-gnu-indirect-function --enable-languages=all,go --enable-lto Thread model: posix gcc version 5.0.1 20150416 (prerelease) (GCC)
[Bug target/65810] powerpc64 libgfortran alignment issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-04-20 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Ever confirmed|0 |1 --- Comment #4 from Alan Modra --- Here's the bad code 0x0fffb7f6c438 :addis r9,r2,-2 0x0fffb7f6c43c :li r27,0 0x0fffb7f6c440 :lfd f24,32760(r9) 0x0fffb7f6c444 :lfd f25,-32768(r9) It's from write_float.def:888 r *= 10; so is supposed to be loading up 10.0L but instead gets a completely bogus low double as seen in "d" below. __gcc_qmul (a=1, b=0, c=10, d=-7.3968712249802237e+209) So not something odd in libgfortran.. Hmm p/x $r2 $31 = 0xfffb7fa1bd8 So, gcc emits toc sections with alignment of 8 bytes, which the linker respects, leading to a toc pointer (r2) that can only be assumed to be 8 byte aligned. This completely breaks rs6000.c:offsettable_ok_by_alignment. My bug. Short term fix will be to limit offsettable_ok_by_alignment to 8 byte alignment. Longer term, modify the linker to increase r2 alignment.
[Bug target/65810] powerpc64 alignment of r2 insufficient for loading long-double constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810 --- Comment #6 from Alan Modra --- It isn't seen most of the time because the failure happens only when r2 isn't 16-byte aligned (50% chance) and the r2 offset to a long double constant is n*64k+32k-8 (0.012% chance per long double). libgfortran stores paths for error messages in .rodata, so source path can affect placement of those long double constants. I'm just lucky.
[Bug target/65810] powerpc64 alignment of r2 insufficient for loading long-double constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #8 from Alan Modra --- Fixed
[Bug target/58744] Illegal Memory Access on 3-byte packed struct ARCH: x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58744 Bug 58744 depends on bug 36043, which changed state. Bug 36043 Summary: gcc reads 8 bytes for a struct of size 6 which leads to sigsegv https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/65408] powerpc64 function argument passing may access invalid memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65408 Bug 65408 depends on bug 36043, which changed state. Bug 36043 Summary: gcc reads 8 bytes for a struct of size 6 which leads to sigsegv https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #26 from Alan Modra --- Fixed for 5.2
[Bug target/58744] Illegal Memory Access on 3-byte packed struct ARCH: x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58744 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #6 from Alan Modra --- Fixed for 5.2
[Bug target/65408] powerpc64 function argument passing may access invalid memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65408 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #10 from Alan Modra --- Fixed for 5.2
[Bug target/37954] odd sized packed structures passed by value, under ARM, cause lockup of application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37954 Bug 37954 depends on bug 36043, which changed state. Bug 36043 Summary: gcc reads 8 bytes for a struct of size 6 which leads to sigsegv https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/66020] [6.0 regression] FAIL: gcc.target/powerpc/ppc64-abi-2.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66020 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-06 Ever confirmed|0 |1
[Bug target/66033] New: rs6000 nops removed by rtl_dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66033 Bug ID: 66033 Summary: rs6000 nops removed by rtl_dce Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Target Milestone: --- gen_nop() is called in various places in rs6000.c. These nops don't survive rtl_dce, thus breaking darwin's TARGET_FIX_AND_CONTINUE, and the scheduler nop insertion.
[Bug target/66020] [6.0 regression] FAIL: gcc.target/powerpc/ppc64-abi-2.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66020 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED CC|amodra at gcc dot gnu.org | Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
[Bug target/66033] rs6000 nops removed by rtl_dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66033 Alan Modra changed: What|Removed |Added Target||powerpc* Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-05-06 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Ever confirmed|0 |1
[Bug target/66033] rs6000 nops removed by rtl_dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66033 --- Comment #2 from Alan Modra --- Right, but there will be when I have my split-stack implementation done.
[Bug target/66020] [6.0 regression] FAIL: gcc.target/powerpc/ppc64-abi-2.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66020 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Alan Modra --- Fixed
[Bug libgcc/66225] libgcc/config/rs6000/morecore.S will not build on systems with an older assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66225 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||amodra at gmail dot com Resolution|--- |FIXED --- Comment #5 from Alan Modra --- Fixed.
[Bug go/66870] split stack issues on ppc64le and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-15 Ever confirmed|0 |1 --- Comment #7 from Alan Modra --- The attached patch looks good, but it would be slightly better if the condition "flags_split_stack && lookup_attribute (...) == 0" were used throughout rs6000_emit_prologue. Probably best implemented by assigning a new auto var at the start of rs6000_emit_prologue then using that in place of flag_split_stack.
[Bug go/66870] split stack issues on ppc64le and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 --- Comment #11 from Alan Modra --- I can reproduce the fail. It is caused by shrink-wrapping.
[Bug go/66870] split stack issues on ppc64le and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 --- Comment #12 from Alan Modra --- Created attachment 36003 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36003&action=edit fix shrink-wrap issue The attached patch cures the shrink wrap problem. I haven't yet bootstrapped it but fmt.o looks good by inspection.
[Bug target/57052] New: missed optimization with rotate and mask
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57052
Bug #: 57052
Summary: missed optimization with rotate and mask
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amo...@gmail.com
/* -m32 -O -S */
int
foo (unsigned int x, int r)
{
return ((x << r) | (x >> (32 - r))) & 0xff;
}
results in:
foo:
rlwnm 3,3,4,0x
rlwinm 3,3,0,24,31
blr
Compiling the same code with -m32 -O -S -mlittle gives the properly optimized
result of:
foo:
rlwnm 3,3,4,0xff
blr
This is because many of the rs6000.md rotate/shift and mask patterns use
subregs with wrong byte offsets. eg. rotlsi3_internal7, the insn that ought to
match here, has (subreg:QI (rotate:SI ...) 0). The 0 selects the most
significant byte when BYTES_BIG_ENDIAN and the least significant when
!BYTES_BIG_ENDIAN.
Fortunately combine doesn't seem to generate subregs for high parts, so
changing the testcase mask to 0xff00 doesn't result in wrong code.
Annoyingly, rotlsi3_internal4 would match here too if combine_simplify_rtx()
didn't simplify (set (reg:SI) (and:SI () 255)) to use subregs.
[Bug target/57052] missed optimization with rotate and mask
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57052 Alan Modra changed: What|Removed |Added Target||powerpc-linux Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-04/msg01370.htm ||l Keywords||missed-optimization Last reconfirmed||2013-04-24 AssignedTo|unassigned at gcc dot |amodra at gmail dot com |gnu.org | Ever Confirmed|0 |1
[Bug target/57052] missed optimization with rotate and mask
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57052 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #1 from Alan Modra 2013-04-25 07:57:39 UTC --- http://gcc.gnu.org/ml/gcc-cvs/2013-04/msg00982.html
[Bug middle-end/57134] ICE with -mstrict-align and inline assembly on ppc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-01 CC||amodra at gmail dot com Ever Confirmed|0 |1 --- Comment #1 from Alan Modra 2013-05-01 14:32:49 UTC --- I think the bug here is that we lose EXPAND_MEMORY when recursively calling expand_expr() for the inner part of a COMPONENT_REF.
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #2 from Alan Modra 2013-05-02 08:18:45 UTC --- BTW, running gkeytool without any args shows the problem too. When libjava is built with -g -O2, I get Exception in thread "main" java.lang.NoClassDefFoundError: gnu.classpath.tools.keytool.Main at java.lang.Class.initializeClass(natClass.cc) Caused by: java.lang.IllegalMonitorStateException: current thread not owner at java.lang.Object.notifyAll(natObject.cc:1437) at gnu.gcj.runtime.SystemClassLoader.findClass(natSystemClassLoader.cc:29) at java.lang.ClassLoader.loadClass(ClassLoader.java) at java.lang.ClassLoader.loadClass(ClassLoader.java:387) at java.lang.Class.initializeClass(natClass.cc:728) But note that natObject.cc:1437 is a lie! The real failure occurs natObject.cc:1431 and it looks like the two identical throws have merged. Putting a break on the right place, I see (gdb) p this $8 = (java::lang::Object * const) 0xffc6aec (gdb) p/x addr $9 = 0xffc6aec Uh oh! The address is not 8-byte aligned, so one of the flag bits appears to be set. This is why we appear to have locking problems.
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 --- Comment #3 from Alan Modra 2013-05-02 08:54:39 UTC --- In libgcj-tools.so 20316: 00456aec 144 OBJECT LOCAL DEFAULT 22 _ZN3gnu9classpath5tools7keytool17Main$ShutdownHook6class$E That's in .data, as expected. >From the .o file (classpath/tools/.libs/libgcj_tools_la-tools.o) I see this is laid out *not* at an 8 byte address. 26803: 000680ac 144 OBJECT GLOBAL HIDDEN 110 _ZN3gnu9classpath5tools7keytool17Main$ShutdownHook6class$E While the containing section is 8-byte aligned. [110] .data.rel.local PROGBITS 2151b8 07358c 00 WA 0 0 8 So a gcj bug by the look of it.
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 --- Comment #4 from Alan Modra 2013-05-02 11:35:20 UTC --- I believe this is triggered by powerpc turning on -fsection-anchors by default, and a section anchor bug loses the alignment. The classes are all nicely aligned if I compile with -fno-section-anchors
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074
--- Comment #5 from Alan Modra 2013-05-02 14:01:59
UTC ---
So the section anchor code places vars (and constants) in blocks according to
their alignment and sizes (varasm.c:place_block_symbol). The calculations are
all good, offsets are properly aligned, and the overall block aligned. The
problem is that when we come to actually output the vars, in some cases we emit
*more* data than given by the size. That results in following vars being at a
different offset than originally calculated, and sometimes misaligned.
Here's an example of output showing the mismatch.
.type _atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook,
@object
.size _atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook, 24
_atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook:
.long _Utf259
.long _Utf111
.long _Utf110
.long _Utf166
.long _Utf111
.long _Utf257
.long 0
.long 0
.long 0
Notice the actual size is 36 bytes, not the 24 give by .size.
unit size
align 32 symtab 0 alias set 22 canonical type 0xfffb60f46e0 fields
pointer_to_this >
BLK
size
unit size
align 32 symtab 0 alias set 22 canonical type 0xfffb60f4788
domain
SI
size
unit size
align 32 symtab 0 alias set -1 canonical type 0xfffb60f4248
precision 32 min max >
pointer_to_this >
constant addressable asm_written used static ignored BLK file
/home/alan/src/gcc-virgin/libjava/classpath/tools/gnu/classpath/tools/keytool/Main.java
line 0 col 0 size unit size
align 32 initial
(mem/c:BLK (symbol_ref:SI
("_atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook") [flags 0x82]
) [22
_atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook+0 S24 A32]) chain
>
I'm not sure how we came to think the array had 3 elements rather than 2.
Here's that "initial" field.
unit size
align 32 symtab 0 alias set 22 canonical type 0xfffb60f46e0 fields
pointer_to_this >
BLK
size
unit size
align 32 symtab 0 alias set 22 canonical type 0xfffb60f4788
domain
SI
size
unit size
align 32 symtab 0 alias set -1 canonical type 0xfffb60f4248
precision 32 min max >
pointer_to_this >
constant lngt 3
val
constant lngt 3
idx
unsigned SI file line 0 col 0 size unit size
align 32 offset_align 128
offset
bit offset context
chain >
val
readonly constant arg 0 >
idx
unsigned SI file line 0 col 0 size unit size
align 32 offset_align 128 offset bit
offset context chain
>
val
readonly constant arg 0 >
idx
unsigned SI file line 0 col 0 size unit size
align 32 offset_align 128 offset
bit offset context
>
val
readonly constant arg 0 >>
val
constant lngt 3 idx
val
readonly constant arg 0 > idx
val idx
val
readonly constant arg 0 >>
val
constant lngt 3 idx
val idx val idx val >>
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 Alan Modra changed: What|Removed |Added Target Milestone|4.8.1 |--- --- Comment #10 from Alan Modra 2013-05-02 23:04:37 UTC --- Another fairly easy fix is to make output_object_block() emit the .align directives instead of padding. Yes, this covers up the real bug that Jakub has been looking at, but it might be worth doing for robustness.
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 --- Comment #11 from Alan Modra 2013-05-03 10:42:12 UTC --- No, of course that doesn't work. We make references into the section anchor block as .LANCHORn+offset, so the items in the block must be exactly where place_block_symbol() expects them to be.
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 --- Comment #12 from Alan Modra 2013-05-03 10:47:22 UTC --- Created attachment 30017 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30017 Use .org instead of padding in section anchor block This one ensures that offsets of emitted items exactly match the values calculated in place_block_symbol(). Right now that means we die building libjava with lots of "Error: attempt to move .org backwards" from gas.
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074
--- Comment #15 from Alan Modra 2013-05-04 01:21:50
UTC ---
With this patch I'm still seeing odd trees in place_block_symbol(). In the
following, the type is the correct size (168 bytes), but the var_decl size too
small (48 bytes). place_block_symbol() uses the var_decl size. Hmm, I reckon
that's a bug in place_block_symbol(). Shouldn't it be using DECL_INITIAL size?
unit size
align 64 symtab 0 alias set 20 canonical type 0xf6072b80 fields
pointer_to_this >
BLK
size
unit size
align 64 symtab 0 alias set 20 canonical type 0xf61115c0
domain
DI
size
unit size
align 64 symtab 0 alias set -1 canonical type 0xf6111560 precision
64 min max >
pointer_to_this >
constant addressable asm_written static ignored BLK file
/home/amodra/src/gcc-current/libjava/classpath/gnu/java/awt/dnd/peer/gtk/GtkDragSourceContextPeer.java
line 0 col 0
size
constant 384>
unit size
constant 48>
align 64 initial
(mem/c:BLK (symbol_ref:DI
("_atable_syms_gnu_java_awt_dnd_peer_gtk_GtkDragSourceContextPeer") [flags
0x82] ) [20
_atable_syms_gnu_java_awt_dnd_peer_gtk_GtkDragSourceContextPeer+0 S48 A64])
chain >
[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865
--- Comment #9 from Alan Modra 2013-05-04 14:34:39
UTC ---
>From what I see on current mainline for a testcase based on
glibc/nss/nss_files/files-init.c the var_decl size and the type size agree and
are correct. What causes a problem with -fsection-anchors is that the actual
data emitted by output_constant() is wrong.
struct traced_file
{
long pad;
char fname[];
};
#define TF(id, filename, ...)\
union\
{\
struct traced_file file;\
char buf[sizeof (struct traced_file) + sizeof (filename)];\
} id##_traced_file =\
{\
.file =\
{\
.fname = filename\
}\
}
TF (pwd, "/etc/passwd");
TF (grp, "/etc/group");
Gives me
.file"unioninit.c"
.globl grp_traced_file
.globl pwd_traced_file
.section".data"
.align 2
.LANCB0:
.org .LANCB0+0
.typegrp_traced_file, @object
.sizegrp_traced_file, 16
grp_traced_file:
.zero4
.string"/etc/group"
.zero12
.org .LANCB0+16
.typepwd_traced_file, @object
.sizepwd_traced_file, 16
pwd_traced_file:
.zero4
.string"/etc/passwd"
.zero12
.ident"GCC: (GNU) 4.9.0 20130502 (experimental)"
.section.note.GNU-stack,"",@progbits
Those ".zero 12" lines shouldn't be there.
[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865 --- Comment #10 from Alan Modra 2013-05-04 14:39:34 UTC --- Incidentall, I expect the patch referred to in comment #6 will ICE with tree-checking on due to CONSTRUCTOR nodes not having the required fields for DECL_SIZE_UNIT.
[Bug c/57180] New: Structures with a flexible arrray member have wrong size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57180
Bug #: 57180
Summary: Structures with a flexible arrray member have wrong
size
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amo...@gmail.com
CC: algr...@acm.org, amo...@gmail.com,
fredrickprasha...@gmail.com, gcc-bugs@gcc.gnu.org,
lauro.venan...@gmail.com, qrc...@knm.org.pl,
sbsid...@gmail.com
Depends on: 28865
+++ This bug was initially created as a clone of Bug #28865 +++
Cloned from 28865, because the problem is more than just getting .size wrong.
The following testcase fails on all targets at all optimization levels.
The testcase was taken from glibc/nss/nss_files/files-init.c, which is
miscompiled on powerpc or any other target using -fsection-anchors.
union
{
struct { long j; char c[]; } s;
char pad[32];
} x[2] =
{
{ .s = { .c = "abc123" } },
{ .s = { .c = "xyz" } }
};
int
main (void)
{
if (sizeof (x[0]) != 32)
__builtin_abort ();
if (x[1].s.c[0] != 'x')
__builtin_abort ();
return 0;
}
[Bug c/57180] Structures with a flexible arrray member have wrong size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57180 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-06 Ever Confirmed|0 |1
[Bug target/55033] [4.7/4.8/4.9 Regression] PowerPC section type conflict error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-10 CC||amodra at gmail dot com Ever confirmed|0 |1 --- Comment #7 from Alan Modra --- Fix mainline and 4.8 http://gcc.gnu.org/ml/gcc-cvs/2013-05/msg00282.html http://gcc.gnu.org/ml/gcc-cvs/2013-05/msg00283.html
[Bug middle-end/57134] [4.9 Regression] ICE with -mstrict-align and inline assembly on ppc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-06/msg00642.htm ||l Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
[Bug middle-end/57586] ICE when expanding volatile asm using unaligned pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57586 Alan Modra changed: What|Removed |Added Status|WAITING |ASSIGNED CC||amodra at gmail dot com Component|target |middle-end Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Severity|major |normal
[Bug target/57717] error: unrecognizable insn compiling ./strtod_l.c from glibc on powerpc-gnuspe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57717 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #3 from Alan Modra --- Created attachment 30383 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30383&action=edit potential fix This reverts part of the patch identified in comment #1, and cures the testcase failure.
[Bug target/57836] New: large constants evaluated inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57836
Bug ID: 57836
Summary: large constants evaluated inline
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
On powerpc64 with -mcmodel=small -O1, this
int x;
void f1 (long long hx)
{
if (hx < 0x3ff0LL)
x++;
}
results in
.L.f1:
lis 9,0x3fef
ori 9,9,65535
sldi 9,9,32
oris 9,9,0x
ori 9,9,65535
cmpd 7,3,9
bgtlr 7
ld 9,.LC1@toc(2)
lwz 10,0(9)
addi 10,10,1
stw 10,0(9)
blr
The -mcmodel isn't significant, just there to make comparison with older
compilers easy. Prior to gcc-4.5 we generated
.L.f1:
ld 0,.LC0@toc(2)
cmpd 7,3,0
bgtlr 7
ld 9,.LC1@toc(2)
lwz 11,0(9)
addi 0,11,1
stw 0,0(9)
blr
Both pre- and post-4.5 compilers initially expand rtl using the constant load
from toc, but 4.5 and later substitute the constant in the first cse pass.
The problem stems from rtx cost for the load from toc being the same as the
inline constant form.
The costs are the same both pre- and post-4.5. The reason pre-4.5 does not
substitute the constant is related to this comment is cse.c:
/* Find cheapest and skip it for the next time. For items
of equal cost, use this order:
src_folded, src, src_eqv, src_related and hash table entry. */
Pre-4.5 src_folded is NULL, src is a mem, src_eqv the constant.
Post-4.5 src_folded is the constant, src is a mem, src_eqv the constant again.
Pre-4.5, rs6000.c lacked delegitimize_address. src_folded is set by fold_rtx,
which calls equiv_constant, which calls avoid_constant_pool_reference, which
calls targetm.delegitimize_address. When this is missing, we don't get to see
the constant..
[Bug target/57865] Broken _save64gpr and _rest64gpr usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-07-10 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Ever confirmed|0 |1 --- Comment #2 from Alan Modra --- My guess is that it's this change -#define FIRST_SAVED_GP_REGNO 13 +#define FIRST_SAVED_GP_REGNO (FIXED_R13 ? 14 : 13) messing with ool_adjust.
[Bug target/57865] Broken _save64gpr and _rest64gpr usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865 --- Comment #4 from Alan Modra --- Created attachment 30489 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30489&action=edit Fix ool_adjust Please verify that this fixes the problem
[Bug rtl-optimization/58034] New: glibc nptl/tst-cleanup2 fail due to scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034
Bug ID: 58034
Summary: glibc nptl/tst-cleanup2 fail due to scheduling
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Created attachment 30575
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30575&action=edit
preprocessed test case
nprl/tst-cleanup2 fails when compiled with -O2 -mcpu=power6 due to sched1
moving an assignment to a REG over code that traps.
The relevant test case source:
if (setjmp (jmpbuf))
{
puts ("Exiting main...");
return 0;
}
sprintf (p, "This should segv\n");
return 1;
}
The sprintf is optimised to three loads and stores. The problem occurs due to
the assignment of 1 to the REG holding the function return value being
scheduled before the sprintf expansion.
[Bug rtl-optimization/58034] glibc nptl/tst-cleanup2 fail due to scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034
Alan Modra changed:
What|Removed |Added
Known to work||4.7.2
Known to fail||4.8.1, 4.8.2, 4.9.0
--- Comment #5 from Alan Modra ---
This somewhat reduced testcase fails with mainline.
#include
#include
static sigjmp_buf jmpbuf;
static void
sig_handler (int signo)
{
siglongjmp (jmpbuf, 1);
}
int
main (void)
{
char *p = 0;
struct sigaction sa;
sa.sa_handler = sig_handler;
sigemptyset (&sa.sa_mask);
sa.sa_flags = SA_SIGINFO;
if (sigaction (SIGSEGV, &sa, 0))
return 1;
if (setjmp (jmpbuf))
return 0;
__builtin_memcpy (p, "abc", 4);
return 1;
}
[Bug target/57865] Broken _save64gpr and _rest64gpr usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Alan Modra --- Fixed mainline and 4.8. 4.7 doesn't need the patch.
[Bug target/58330] powerpc64 atomic store split in two
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58330 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #2 from Alan Modra --- I think this is a backend problem, specifically with bswapdi2_64bit accepting a DImode mem then splitting to two SImode. Potential fix is to add && !(MEM_P (operands[0]) && MEM_VOLATILE_P (operands[0])) && !(MEM_P (operands[1]) && MEM_VOLATILE_P (operands[1])) to the insn condition.
[Bug middle-end/57134] [4.9 Regression] ICE with -mstrict-align and inline assembly on ppc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134 --- Comment #5 from Alan Modra --- r200086 fixed Anton's first testcase but then he found another one. See http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00983.html
[Bug target/57589] Linux powerpc -mcpu=native returns pointer to variable on stack in driver-rs6000.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57589 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com Resolution|FIXED |INVALID
[Bug target/64687] powerpc: GCC 5.0 (trunk@219851) build failure for powerpc with hardware decimal floating point disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64687 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #5 from Alan Modra --- Looks similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64205
[Bug tree-optimization/64703] New: glibc sysdeps/powerpc/powerpc64/dl-machine.h miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64703
Bug ID: 64703
Summary: glibc sysdeps/powerpc/powerpc64/dl-machine.h
miscompile
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
This testcase, extracted from glibc sysdeps/powerpc/powerpc64/dl-machine.h
shows gcc optimising away the "opd" initialisation at -O1. ie. it's as if the
indirect call doesn't cause gcc to see that "value" is used. Adding the asm
cures the problem, as does passing the function pointer to another function
rather than calling via function pointer in resolve_ifunc.
struct link_map {
unsigned long l_addr;
int l_relocated;
};
typedef struct {
unsigned long fd_func;
unsigned long fd_toc;
unsigned long fd_aux;
} Elf64_FuncDesc;
extern const struct link_map *dl_rtld_map;
extern unsigned long dl_hwcap;
unsigned long
resolve_ifunc (unsigned long value,
const struct link_map *map, const struct link_map *sym_map)
{
Elf64_FuncDesc opd;
if (map != sym_map
&& sym_map != dl_rtld_map
&& !sym_map->l_relocated)
{
Elf64_FuncDesc *func = (Elf64_FuncDesc *) value;
opd.fd_func = func->fd_func + sym_map->l_addr;
opd.fd_toc = func->fd_toc + sym_map->l_addr;
opd.fd_aux = func->fd_aux;
value = (unsigned long) &opd;
}
#if 0
__asm__ ("#%0" : : "r" (value));
#endif
return ((unsigned long (*) (unsigned long)) value) (dl_hwcap);
}
[Bug target/64703] glibc sysdeps/powerpc/powerpc64/dl-machine.h miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64703 --- Comment #6 from Alan Modra --- Re comment #2, yes I agree that conversion between void* or pointer to object and pointer to function is not strictly allowed. Fixing that by way of a union was one of the first things I tried, before looking at dumps and finding that tree dse was where we lost the opd stores. And yes, the testcase can be compiled on x86_64 where (unsurprisingly) the stores are seen as dead too.
[Bug target/64703] glibc sysdeps/powerpc/powerpc64/dl-machine.h miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64703 --- Comment #7 from Alan Modra --- Created attachment 34539 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34539&action=edit prototype patch How does this look as a potential fix? Obviously I'd need to provide the new targetm field and arrange for it to be set on powerpc64 elfv1, but before I do that I'd like some indication that this is going in the right direction.
[Bug target/59828] Broken assembly on ppc* with two -mcpu= options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59828 Alan Modra changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|amodra at gmail dot com|unassigned at gcc dot gnu.org
[Bug go/64876] Regressions in gcc-testresults for powerpc64 gccgo in 5.0 due to change for static chain for closures (219776)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64876
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-02-03
Ever confirmed|0 |1
--- Comment #3 from Alan Modra ---
Confirmed. libffi does not appear to be involved here. If I look at the
escape.go testcase Lynn singles out, the code generated with the patch (or with
-mno-pointers-to-nested-functions) is the following for the call that dies
without the patch.
Breakpoint 2, main.for_escapes3 (y=106, x=105) at
/home/amodra/src/gcc-virgin/gcc/testsuite/go.test/test/escape.go:155
155return f[0](), f[1]()
(gdb) disass $pc,$pc+0x3f
Dump of assembler code from 0x1000267c to 0x100026bb:
=> 0x1000267c :ld r11,112(r1)
0x10002680 :ld r9,0(r11)
0x10002684 :std r2,40(r1)
0x10002688 :ld r10,0(r9)
0x1000268c :mtctr r10
0x10002690 :ld r2,8(r9)
0x10002694 :bctrl
0x10002698 :ld r2,40(r1)
(gdb) stepi 7
main.$nested0 () at
/home/amodra/src/gcc-virgin/gcc/testsuite/go.test/test/escape.go:152
152f[n] = func() *int { return p }
(gdb) disass
Dump of assembler code for function main.$nested0:
=> 0x10001960 <+0>:ld r9,8(r11)
0x10001964 <+4>:ld r3,0(r9)
0x10001968 <+8>:blr
Clearly r11 is expected to hold the address of a struct on entry to
main.$nested0.
(gdb) x/2xg $r11
0xc208e0:0x100144700x00c20903c000
(gdb) x 0x00c20903c000
0xc20903c000:0x00c208d8
(gdb) x 0x00c208d8
0xc208d8:0x0069
Yup, there's our 105, so the value returned is as expected.
If I compile the testcase without -mno-pointers-to-nested-functions then the
code for the call in main.for_escapes3 is:
0x1000267c <+172>:ld r9,112(r1)
---Type to continue, or q to quit---
0x10002680 <+176>:ld r9,0(r9)
0x10002684 <+180>:std r2,40(r1)
0x10002688 <+184>:ld r10,0(r9)
0x1000268c <+188>:ld r11,16(r9)
0x10002690 <+192>:mtctr r10
0x10002694 <+196>:ld r2,8(r9)
0x10002698 <+200>:bctrl
=> 0x1000269c <+204>:ld r2,40(r1)
So r11 is not loaded with the proper parameter from 112(r1), but instead set up
with a zero from the function descriptor.
[Bug target/64876] Regressions in gcc-testresults for powerpc64 gccgo in 5.0 due to change for static chain for closures (219776)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64876 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED Component|go |target Assignee|ian at airs dot com|amodra at gmail dot com --- Comment #5 from Alan Modra --- Oh yeah, this is really an rs6000 backend bug, not a go bug. In 185.r.expand I see ;; _12 = _11 (); [static-chain: _9] (insn 78 77 79 (set (reg:DI 11 11) (reg/f:DI 181 [ D.1382 ])) /home/amodra/src/gcc-virgin/gcc/testsuite/go.test/test/escape.go:155 -1 (nil)) So there's the static chain being loaded. Trouble is, indirect calls on ELFv1 load r11 from the function descriptor so the proper value is overwritten.. (insn 79 78 80 (set (mem/v/c:DI (plus:DI (reg/f:DI 1 1) (const_int 40 [0x28])) [28 S8 A8]) (reg:DI 2 2)) /home/amodra/src/gcc-virgin/gcc/testsuite/go.test/test/escape.go:155 -1 (nil)) (insn 80 79 81 (set (reg:DI 198) (mem:DI (reg/f:DI 182 [ D.1381 ]) [0 S8 A8])) /home/amodra/src/gcc-virgin/gcc/testsuite/go.test/test/escape.go:155 -1 (nil)) (insn 81 80 82 (set (reg:DI 11 11) (mem:DI (plus:DI (reg/f:DI 182 [ D.1381 ]) (const_int 16 [0x10])) [0 S8 A8])) /home/amodra/src/gcc-virgin/gcc/testsuite/go.test/test/escape.go:155 -1 (nil)) ..above. (call_insn 82 81 83 (parallel [ (set (reg:DI 3 3) (call (mem:SI (reg:DI 198) [0 *_11 S4 A8]) (const_int 64 [0x40]))) (use (mem:DI (plus:DI (reg/f:DI 182 [ D.1381 ]) (const_int 8 [0x8])) [0 S8 A8])) (set (reg:DI 2 2) (unspec:DI [ (const_int 40 [0x28]) ] UNSPEC_TOCSLOT)) (clobber (reg:DI 65 lr)) ]) /home/amodra/src/gcc-virgin/gcc/testsuite/go.test/test/escape.go:155 -1 (expr_list:REG_CALL_DECL (nil) (nil)) (expr_list (use (reg:DI 11 11)) (expr_list (use (reg:DI 11 11)) (nil Thus the patch to clear TARGET_POINTERS_TO_NESTED_FUNCTIONS which turns off loading of r11 from function descriptors.
[Bug target/64876] Regressions in gcc-testresults for powerpc64 gccgo in 5.0 due to change for static chain for closures (219776)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64876 Alan Modra changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2015-02/msg00135.ht ||ml CC|amodra at gcc dot gnu.org, | |amodra at gmail dot com| Target Milestone|--- |5.0
[Bug testsuite/64930] [5 regression] FAIL: gcc.target/powerpc/atomic-p7.c scan-assembler-times isync 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64930 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #7 from Alan Modra --- My opinion, FWIW, is that adjusting the expected count of isync is plain wrong. The pr59448 "fix" effectively means that gcc doesn't support atomic consume, so I think the testcase should remain failing (maybe add a comment saying why) or #if 0 out all the consume tests.
[Bug testsuite/64930] [5 regression] FAIL: gcc.target/powerpc/atomic-p7.c scan-assembler-times isync 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64930 --- Comment #9 from Alan Modra --- My point was that if you write a testcase that specifically tests for consume and get acquire code then that is a fail. The code generated is using a bigger hammer than necessary. Imagine for a moment if gcc promoted everything to seq_cst. That would also be "supporting" the atomics, but for powerpc we'd be quite unhappy and would want to know about such a change with a testsuite failure.. I recognize that the testcase doesn't properly test consume semantics, and that teaching gcc to track dependencies is not simple. Huh, I just checked and it appears powerpc emits unnecessary isyncs for atomic_load consumes prior to the pr59448 change, probably in recognition that dependency tracking isn't done. So I withdraw my objection to adjusting the isync counts.
[Bug target/65172] New: rs6000 rtl checking failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65172 Bug ID: 65172 Summary: rs6000 rtl checking failure Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Found when building libjava with rtl checking on. /home/amodra/build/gcc/./gcc/gcj -B/home/amodra/build/gcc/powerpc64-linux/libjava/ -B/home/amodra/build/gcc/./gcc/ -B/usr/powerpc64-linux/bin/ -B/usr/powerpc64-linux/lib/ -isystem /usr/powerpc64-linux/include -isystem /usr/powerpc64-linux/sys-include -mminimal-toc -fclasspath= -fbootclasspath=/home/amodra/src/gcc/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -findirect-dispatch -fno-bootstrap-classes -fno-indirect-classes -fsource-filename=/home/amodra/build/gcc/powerpc64-linux/libjava/classpath/tools/all-classes.lst -g -O2 -c classpath/tools/tools.zip -fPIC -o classpath/tools/.libs/libgcj_tools_la-tools.o /home/amodra/src/gcc/libjava/classpath/tools/gnu/classpath/tools/rmic/SourceGiopRmicCompiler.java: In class 'gnu.classpath.tools.rmic.SourceGiopRmicCompiler': [snip] /home/amodra/src/gcc/libjava/classpath/tools/gnu/classpath/tools/rmic/SourceGiopRmicCompiler.java:322:0: internal compiler error: RTL check: expected code 'reg', have 'plus' in rhs_regno, at rtl.h:1710 return new MethodGenerator(m, this); ^ 0x107149c7 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int, char const*) /home/amodra/src/gcc/gcc/rtl.c:731 0x10b2c507 rhs_regno /home/amodra/src/gcc/gcc/rtl.h:1710 0x10b34adf rhs_regno /home/amodra/src/gcc/gcc/config/rs6000/rs6000.c:27229 0x10b34adf mem_locations_overlap [snip] Breakpoint 1, get_memref_parts (mem=mem@entry=0xfff84a1c900, base=base@entry=0xfffd840, offset=offset@entry=0xfffd828, size=size@entry=0xfffd820) at /home/amodra/src/gcc/gcc/config/rs6000/rs6000.c:27188 27188 *base = XEXP (addr_rtx, 0); (gdb) p debug_rtx(addr_rtx) (plus:DI (plus:DI (reg/f:DI 9 9 [162]) (const_int 65536 [0x1])) (const_int -31752 [0x83f8])) $5 = void
[Bug target/65172] rs6000 rtl checking failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65172 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-02-23 Ever confirmed|0 |1
[Bug target/65169] [5 Regression] r210201 miscompiles LLVM's TableGen on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65169 --- Comment #1 from Alan Modra --- Preprocessed source for llvm-tblgen and gcc command line to compile same would be appreciated.
[Bug target/65172] rs6000 rtl checking failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65172 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Alan Modra --- Fixed with rev 220924 (and 220925 for the pr typo in changelog)
[Bug middle-end/65182] -Wuninitialized fails when pointer to variable later passed to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65182 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #4 from Alan Modra --- Apologies for the wrong pr reference in comment #3
[Bug target/65169] [5 Regression] r210201 miscompiles LLVM's TableGen on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65169
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #2 from Alan Modra ---
I couldn't reproduce this using svn llvm rev 230301, gcc-5 20150223, and
binutils 2.25.51.20150223. I was building on a power7 box (because that's
where I happened to have my latest gcc build), so used -mcpu=power7
-mno-strict-align. That ought to trigger the same block move code as
-mcpu=power8, and a quick visual inspection showed that to be the case.
I'm guessing that the "s/break/ eak/" difference Markus sees comes from
utils/TableGen/IntrinsicEmitter.cpp IntrinsicEmitter::EmitAttributes
if (numAttrs) {
OS << " NumAttrs = " << numAttrs << ";\n";
OS << " break;\n";
OS << " }\n";
My generated code for the above looked good, and ran properly on power7.
-mcpu=power8 code didn't look much different.
Markus, are you using gold? (I wasn't.) The strings are in a string merge
section, and I'm wondering if gold miscalculates some string offset.
[Bug target/65263] [5 Regression] ICE (error: unrecognizable insn / in insn_min_length, at config/rs6000/rs6000.md) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65263 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-02 CC||amodra at gmail dot com, ||hubicka at gcc dot gnu.org, ||mliska at suse dot cz Ever confirmed|0 |1 --- Comment #1 from Alan Modra --- This is caused by revision 221040 +2015-02-26 Jan Hubicka + Martin Liska + + PR bootstrap/65150 [snip] #2 0x00bca3fa in _fatal_insn_not_found (insn=insn@entry=0x76ae4ca8, file=file@entry=0x13852e0 "/src/gcc-current/gcc/config/rs6000/rs6000.md", line=line@entry=7813, function=function@entry=0x139c330 "insn_min_length") at /src/gcc-current/gcc/rtl-error.c:118 #3 0x00f1e9f2 in insn_min_length (insn=insn@entry=0x76ae4ca8) at /src/gcc-current/gcc/config/rs6000/rs6000.md:7813 #4 0x0095c8e2 in shorten_branches (first=0x76ad8038) at /src/gcc-current/gcc/final.c:1221 #5 0x00eea239 in rs6000_output_mi_thunk (file=0x1c37950, thunk_fndecl=, delta=, vcall_offset=, function=) at /src/gcc-current/gcc/config/rs6000/rs6000.c:25835 That's here: /* Run just enough of rest_of_compilation to get the insns emitted. There's not really enough bulk here to make other passes such as instruction scheduling worth while. Note that use_thunk calls assemble_start_function and assemble_end_function. */ insn = get_insns (); shorten_branches (insn);
[Bug target/65263] [5 Regression] ICE (error: unrecognizable insn / in insn_min_length, at config/rs6000/rs6000.md) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65263 --- Comment #4 from Alan Modra --- > I assume the problem is that thunk can not be generated to non-local symbol. Yes, that is at the root of this problem. The thunk can't be allowed to jump to anything outside the current object file. The pattern is a sibcall_local64 except that the symbol_ref doesn't match rs6000/predicates.md: current_file_function_operand.
[Bug target/65263] [5 Regression] ICE (error: unrecognizable insn / in insn_min_length, at config/rs6000/rs6000.md) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65263 --- Comment #6 from Alan Modra --- rev 221098 plus the patch segfaults on the testcase in cgraph_node::function_symbol. node->callees is NULL.
[Bug c/65287] Current trunk ICE in address_matters_p, at symtab.c:1908
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65287 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-03 CC||amodra at gmail dot com Ever confirmed|0 |1 --- Comment #2 from Alan Modra --- Confirmed on both x86_64 and powerpc64-linux.
[Bug target/65263] [5 Regression] ICE (error: unrecognizable insn / in insn_min_length, at config/rs6000/rs6000.md) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65263 --- Comment #11 from Alan Modra --- Martin, your patch passes bootstrap and regression testing on powerpc64-linux.
[Bug target/65286] When building on powerpc64le-unknown-linux-gnu, --disable-multilib must be used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65286 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|2015-03-03 00:00:00 |2015-03-06 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Ever confirmed|0 |1 --- Comment #2 from Alan Modra --- Mine.
[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-07 CC||amodra at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Alan Modra --- Confirmed. The problem occurs in fwprop1 where instructions corresponding to the following assembly addis r2,r31,ha16(_A.1.1600-L1$pb) la r9,lo16(_A.1.1600-L1$pb)(r2) ld r2,0(r9) are combined to addis r2,r31,ha16(_A.1.1600-L1$pb) la r9,lo16(_A.1.1600-L1$pb)(r2) ld r2,lo16(_A.1.1600-L1$pb)(r2) ie. the offset is propagated into the memory load. This ought to give you an error at assembly or link time. If not, you have a bad assembler or linker.. movdi_low is the culprit, I think. It should require a suitably aligned offset (operand 2).
[Bug target/65286] When building on powerpc64le-unknown-linux-gnu, --disable-multilib must be used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65286 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Alan Modra --- Fixed
[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342
Alan Modra changed:
What|Removed |Added
CC|amodra at gcc dot gnu.org |
--- Comment #4 from Alan Modra ---
Here's another failing powerpc-darwin testcase due to movdi_low (movdf_low_di
and their store counterparts have the same problem of course).
/* -m64 -O1 -S -fno-pic */
struct {
char c;
long l;
} __attribute__ ((__packed__)) x;
long get_x (void)
{
return x.l;
}
[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342 --- Comment #6 from Alan Modra --- Created attachment 35001 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35001&action=edit workaround You might like to consider this patch that effectively reverts r210201 for Darwin. This should cure the regression.
[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342 --- Comment #9 from Alan Modra --- As far as fixing the real underlying problem goes, I'm not so familiar with the darwin support that I can state with certainty that you need to fix movdi_low and friends. It might help to explain why powerpc64-linux -mcmodel=medium code doesn't hit the intrinsic_unpack problem even though the resultant code looks very similar to darwin code. We don't see a similar propagation of offset into memory load because legitimate_addres_p() says that isn't valid. It isn't valid because legitimate_constant_pool_address_p (also handles toc-relative medium model addresses) checks alignment. So fwprop and combine don't create the problem memory loads in the first place. However, if we did see such a memory load, reload would fix it for us due to the predicate and constraints in movdi_internal64. Note that having legitimate_address_p() prevent these addresses does mean we lose some optimization opportunites, but on the other hand, if we allowed everything early we'd end up with lots of reloads and probably worse code. You may be able to do something similar in legitimate_address_p for darwin.
[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342 --- Comment #10 from Alan Modra --- > permitted? (i.e. modifying %1, which is an input operand) Yes. You're outputting assembly, practically anything goes.
