[Bug target/101469] wrong code with "-O2 -fPIE" for SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469 --- Comment #2 from Valeriy E. Ushakov --- I don't have the latest gcc handy, but I see this bug already in an old netbsd tree from about an year ago with gcc 8.4.0 As hgutch@n.o pointed out, this seems to be a problem with this peephole2: ;; mov r12,r0 ;; add #-48,r0 -> add #-48,r12 ;; mov.l r0,@(4,r10) mov.l r12,@(4,r10) ;; (r12 dead) (define_peephole2 [(set (match_operand:SI 0 "arith_reg_dest") (match_operand:SI 1 "arith_reg_dest")) (set (match_dup 0) (plus:SI (match_dup 0) (match_operand:SI 2 "const_int_operand"))) (set (match_operand:SI 3 "general_movdst_operand") (match_dup 0))] as far as I can tell, it optimizes r0 = r2 r0 += 64 *(r0+4) = r0 to r2 += 64 *(r0+4) = r2 failing to notice that the the destination uses r0 too. Then in the cprop-registers step that r0 is replaced with r12 b/c of r0 = r12 done a bit earlier.
[Bug bootstrap/32497] Crosscomiling native sh3 gcc on a 64-bit host fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497 --- Comment #16 from Valeriy E. Ushakov --- (In reply to Eric Gallager from comment #15) > (In reply to Valeriy E. Ushakov from comment #11) > > Created attachment 44668 [details] > > Diff against gcc-6.4.0 > > > > This is essentially the same diff except gcc now provides its own > > HOST_WIDE_INT_C() macro, so the patch uses that instead of defining its own. > > can you please send it to the gcc-patches mailing list for review? This patch has been sitting in your bugtracker for 11 years. Anything I know about this bug is written in this bug report and swapped out of my active memory, so I cannot meaningfully answer any questions about that patch on gcc-patches@ other than by referring people to what's written here in this bug report. Why do I have to go through this strange ritual of taking this patch out of gcc's own bugtracker and sending it to gcc's own list for proposed patches? This is not some proposed change that I can meaningfully advocate (like a new feature or something). I.e. what that action is going to change from the standpoint of communication setup? As I see it, it can only make things worse b/c if I'm actually asked any questions I can't answer them, or someone replies to that patch only to the mailing list and I miss that reply (and it's not recorded here too). And then it will just look as my fault, not engaging in a proper discussion.
[Bug bootstrap/32497] Crosscomiling native sh3 gcc on a 64-bit host fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497 --- Comment #14 from Valeriy E. Ushakov --- Sorry, I meant comment #6 in the above.
[Bug bootstrap/32497] Crosscomiling native sh3 gcc on a 64-bit host fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497 --- Comment #13 from Valeriy E. Ushakov --- The above build was done on a linux/amd64 host. The error happens when NetBSD build cross-compiles native NetBSD/sh3 gcc, i.e. the compiler that will run natively on sh3 as part of the NetBSD distribution. I'm sorry, but I don't have time or energy to come up with a standalone reproducer, especially given prior history of this bug report being ignored for over a decade. Someone familiar with gcc code base should be able to do that easily I think. And as I said in comment #5, you can reproduce it with the NetBSD source tree with a single command on about any modern unix on a 64-bit host. I guess linux-sh folks have never run into this because they use cross-compiler exclusively and never compile stuff on sh3 itself, so they never build native gcc for sh3.
[Bug bootstrap/32497] Crosscomiling native sh3 gcc on a 64-bit host fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497
--- Comment #12 from Valeriy E. Ushakov ---
I've attached updated patch against gcc 6.4.0. If I un-apply that patch to the
NetBSD tree with patch -R (i.e. revert the files to their original state as in
gcc 6.4.0) I get
$ nbmake-landisk insn-emit.o
# compile backend/insn-emit.o
/home/uwe/work/netbsd/build/tools/bin/shle--netbsdelf-c++ -Os -freorder-blocks
-Wall -Wpointer-arith -Wno-sign-compare -Wa,--fatal-warnings -Wno-uninitialized
-Wno-maybe-uninitialized -Werror -fPIE -Wno-narrowing -Wno-unused
-std=gnu++98 -Wno-stack-protector -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -I.
-I/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/usr.bin/backend/../gcc/arch/sh3el
-DIN_GCC -DHAVE_CONFIG_H
-I/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/dist/gcc
-I/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/dist/gcc/.
-I/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/dist/gcc/../include
-I/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/dist/gcc/../libcpp/include
-I/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/dist/gcc/../libdecnumber
-I/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/dist/gcc/../libdecnumber/dpd
-I/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/dist/gcc/../libbacktrace
-DTARGET_NAME=\"shle--netbsdelf\"
-I/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/dist/libgcc
-I/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/usr.bin/backend/../../lib/libgcc/libgcov/arch/sh3el
--sysroot=/home/uwe/work/netbsd/build/distrib/landisk
-DLOCALEDIR=\"/usr/share/locale\" -DNETBSD_NATIVE -I. -DENABLE_SHARED_LIBGCC
-cinsn-emit.c -o insn-emit.o
insn-emit.c:6346:3: error: this decimal constant is unsigned only in ISO C90
[-Werror]
return gen_rtx_SET (operand0,
^~
cc1plus: all warnings being treated as errors
[...]
$ cat -n insn-emit.c | sed -n '6341,6354p'
6341 rtx
6342 gen_mshflo_l_di (rtx operand0 ATTRIBUTE_UNUSED,
6343 rtx operand1 ATTRIBUTE_UNUSED,
6344 rtx operand2 ATTRIBUTE_UNUSED)
6345 {
6346return gen_rtx_SET (operand0,
6347 gen_rtx_IOR (DImode,
6348 gen_rtx_AND (DImode,
6349 operand1,
6350 GEN_INT (4294967295L)),
6351 gen_rtx_ASHIFT (DImode,
6352 operand2,
6353 const_int_rtx[MAX_SAVED_CONST_INT + (32)])));
6354 }
and
$ nbmake-landisk insn-recog.o
# compile backend/insn-recog.o
/home/uwe/work/netbsd/build/tools/bin/shle--netbsdelf-c++ -Os -freorder-blocks
-Wall -Wpointer-arith -Wno-sign-compare -Wa,--fatal-warnings -Wno-uninitialized
-Wno-maybe-uninitialized -Werror -fPIE -Wno-narrowing -Wno-unused
-std=gnu++98 -Wno-stack-protector -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -I.
-I/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/usr.bin/backend/../gcc/arch/sh3el
-DIN_GCC -DHAVE_CONFIG_H
-I/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/dist/gcc
-I/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/dist/gcc/.
-I/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/dist/gcc/../include
-I/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/dist/gcc/../libcpp/include
-I/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/dist/gcc/../libdecnumber
-I/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/dist/gcc/../libdecnumber/dpd
-I/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/dist/gcc/../libbacktrace
-DTARGET_NAME=\"shle--netbsdelf\"
-I/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/dist/libgcc
-I/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/usr.bin/backend/../../lib/libgcc/libgcov/arch/sh3el
--sysroot=/home/uwe/work/netbsd/build/distrib/landisk
-DLOCALEDIR=\"/usr/share/locale\" -DNETBSD_NATIVE -I. -DENABLE_SHARED_LIBGCC
-cinsn-recog.c -o insn-recog.o
insn-recog.c:1532:7: error: this decimal constant is unsigned only in ISO C90
[-Werror]
|| XWINT (x4, 0) != -2147483648L
^~
insn-recog.c:5762:5: error: this decimal constant is unsigned only in ISO C90
[-Werror]
case -2147483648L:
^~~~
/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/dist/gcc/config/sh/sh.md:15774:15:
error: this decimal constant is unsigned only in ISO C90 [-Werror]
DONE;
^
/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/dist/gcc/config/sh/sh.md:4832:17:
error: this decimal constant is unsigned only in ISO C90 [-Werror]
(and:SI (match_dup 1) (const_int 1
^~~~
/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/dist/gcc/config/sh/sh.md:16430:17:
error: this decimal constant is unsigned only in ISO C90 [-Werror]
(define_split
^
/home/uwe/work/netbsd/ro/src/external/gpl3/gcc.old/dist/gcc/config/sh/sh.md:14012:15:
error: this decimal constant is unsigned only in ISO C90 [-Werror]
[(set (match_operand:DF 0 "fp_arith_reg_operand" "=f")
^~
cc1plus: all warnings being treated as errors
[Bug bootstrap/32497] Crosscomiling native sh3 gcc on a 64-bit host fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497 Valeriy E. Ushakov changed: What|Removed |Added CC||uwe at netbsd dot org --- Comment #11 from Valeriy E. Ushakov --- Created attachment 44668 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44668&action=edit Diff against gcc-6.4.0 This is essentially the same diff except gcc now provides its own HOST_WIDE_INT_C() macro, so the patch uses that instead of defining its own.
[Bug bootstrap/32497] Crosscomiling native sh3 gcc on a 64-bit host fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497 --- Comment #8 from Valeriy E. Ushakov --- I don't understand. The title mentions sh3, which is not obsolete. It's been 11 (eleven!) years. As far as I know this patch (adjusted to catch up with the changes, but essentially the same) is still necessary for gcc 6.4 that is the compiler in NetBSD-current.
[Bug bootstrap/32497] Crosscomiling native sh3 gcc on a 64-bit host fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497 --- Comment #6 from Valeriy E. Ushakov --- (In reply to Oleg Endo from comment #5) > (In reply to Valeriy E. Ushakov from comment #4) > > > GEN_INT (-4294967296L; > > > GEN_INT (4294967295L)), > > I think those should be -4294967296LL and 4294967295LL. Right, with the patch above (committed in NetBSD) I get the following diff between insn-emit.c: - GEN_INT (-4294967296L; + GEN_INT (HOST_WIDE_INT_CONSTANT (-4294967296); ... etc so, effectively, it removes the L/LL decision from genemit.c and delays it until insn-emit.c is compiled. > Do you have that build setup at hand to try this out? I guess the easiest way to get out NetBSD source tree and to cross-build say NetBSD/landisk on a 64 bit host (any linux/amd64 will do, osx probably too, but there were a couple of pitfalls recently). You can grab sources from e.g. http://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0.1/source/sets/ and consult BUILDING, but in a nutshell something like ./build.sh -m landisk -j8 -u -U distribution (where -j8 is the amount of parallel jobs you want). You can mail me privately if you need any help with this. > BTW, those two patterns do not exist anymore in trunk, as SH5 stuff has been > removed. Yes, but that just masks the bug that L/LL selection is done in wrong context.
[Bug bootstrap/32497] Crosscomiling native sh3 gcc on a 64-bit host fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497
--- Comment #4 from Valeriy E. Ushakov ---
Seems to fail more or less the same way without the patch. NetBSD current with
gcc 5.4.0. Building on linux/amd64. When native gcc is cross compiled
shle--netbsdelf-c++ ... -c insn-emit.c
fails with:
insn-emit.c:6382:3: error: this decimal constant is unsigned only in ISO C90
[-Werror]
This is about 4294967295L in gen_mshflo_l_di(). It no longer complains about
-4294967296L in gen_mshfhi_l_di() just above, though. The relevant fragment of
insn-emit.c is:
/*
/home/uwe/work/netbsd/ro/src/external/gpl3/gcc/dist/gcc/config/sh/sh.md:15987
*/
rtx
gen_mshfhi_l_di (rtx operand0 ATTRIBUTE_UNUSED,
rtx operand1 ATTRIBUTE_UNUSED,
rtx operand2 ATTRIBUTE_UNUSED)
{
return gen_rtx_SET (VOIDmode,
operand0,
gen_rtx_IOR (DImode,
gen_rtx_LSHIFTRT (DImode,
operand1,
const_int_rtx[MAX_SAVED_CONST_INT + (32)]),
gen_rtx_AND (DImode,
operand2,
GEN_INT (-4294967296L;
}
/*
/home/uwe/work/netbsd/ro/src/external/gpl3/gcc/dist/gcc/config/sh/sh.md:16037
*/
rtx
gen_mshflo_l_di (rtx operand0 ATTRIBUTE_UNUSED,
rtx operand1 ATTRIBUTE_UNUSED,
rtx operand2 ATTRIBUTE_UNUSED)
{
return gen_rtx_SET (VOIDmode,
operand0,
gen_rtx_IOR (DImode,
gen_rtx_AND (DImode,
operand1,
GEN_INT (4294967295L)),
gen_rtx_ASHIFT (DImode,
operand2,
const_int_rtx[MAX_SAVED_CONST_INT + (32)])));
}
[Bug bootstrap/32497] Crosscomiling native sh3 gcc on a 64-bit host fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497 --- Comment #3 from Valeriy E. Ushakov --- The patch above has been committed to the NetBSD imported version of gcc back in April 2008 and has been merged in all the new imported versions ever since. It's been quite a few years so I don't remember most details, however I assume the patch is still relevant. I will try to back it out and see what happens.
[Bug target/60039] sh3 optimisation bug with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60039 --- Comment #6 from Valeriy E. Ushakov --- As far as I can tell the actual problem is in this code: .loc 1 189 0 mov.l.L91,r0 ; ... addr12,r0 mov.l.L84,r1 jsr@r0; udivsi3 for 32*1024/pagesz ; ... .loc 1 189 0 bsrfr1; morepages call .LPCS6: movr0,r4; with result of division .L91: .long__udivsi3@GOTOFF .L84: .longmorepages-(.LPCS6+2) That code assumes that r1 is not clobbered, but in our case it is. So instead of calling morepages() we end up with a small branch forward. and pagepool_start is not initialized properly, causing SIGSEGV later. I don't remember how we build udivsi3 &c bits in NetBSD, we might be violating assumptions about clobbered regs. FWIW, our in-tree gcc 4.5 generates for this: mov.l .L75,r0 ; ... mov.l @(r0,r12),r2 jsr @r2 ; ... mov.l .L67,r1 mov r0,r4 bsrfr1 .LPCS6: .L75: .long __udivsi3_i4i@GOT .L67: .long morepages-(.LPCS6+2) Because, as far as I can tell, in 4.5 sh_override_options() has an extra else if (TARGET_SH2)/* ??? EXPERIMENTAL */ sh_div_strategy = SH_DIV_CALL_TABLE; clause, that is missing in 4.8 sh_option_override().
[Bug target/50068] Invalid memory access in incr_ticks_for_insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50068 --- Comment #7 from Valeriy E. Ushakov 2011-08-24 21:26:23 UTC --- This fixes the problem. Thanks.
[Bug rtl-optimization/50068] Invalid memory access in incr_ticks_for_insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50068 --- Comment #2 from Valeriy E. Ushakov 2011-08-13 01:27:57 UTC --- The command that fails: .../libexec/gcc/shle--netbsdelf/4.5.3/cc1plus -fpreprocessed fstream-inst.i -quiet -dumpbase fstream-inst.i -auxbase-strip fstream-inst.o -Os -Werror -Wno-stack-protector -std=gnu++0x -frandom-seed=4cd80fc7 -freorder-blocks -fno-implicit-templates -fdiagnostics-show-location=once -o /tmp/cc83k8TV.s
[Bug rtl-optimization/50068] Invalid memory access in incr_ticks_for_insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50068 --- Comment #1 from Valeriy E. Ushakov 2011-08-13 01:18:00 UTC --- Created attachment 24995 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24995 Preprocessed source that triggers the bug
[Bug rtl-optimization/50068] New: Invalid memory access in incr_ticks_for_insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50068 Bug #: 50068 Summary: Invalid memory access in incr_ticks_for_insn Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: u...@netbsd.org I'm not sure about a good short description for this, so please bear with me. NetBSD is currently in a process of switching to gcc-4.5.3 as its system compiler. I have built a NetBSD release with the new gcc and, as a test, I decided to build NetBSD/landisk (SuperH) on a landisk machine itself (with the newly compiled system) to verify bootstrap/self-hosting. While it takes several days, it's an interesting exercise and last time I did it I actually found a sequence point bug in out lint... But I digressed. The build failed with: # compile libstdc++-v3/fstream-inst.o /usr/nb/tools/bin/shle--netbsdelf-c++ -frandom-seed=4cd80fc7 -Os -freorder-blocks -Werror -fno-implicit-templates -fdiagnostics-show-location=once --sysroot=/usr/nb/distrib/landisk -I/usr/src/external/gpl3/gcc/dist/gcc -I/usr/src/external/gpl3/gcc/dist/include -I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/libsupc++ -I/usr/src/external/gpl3/gcc/lib/libstdc++-v3/../libstdc++-v3_4/arch/sh3el -I. -DHAVE_STDLIB_H -DHAVE_STRING_H -I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/include -I/usr/src/external/gpl3/gcc/lib/libstdc++-v3/arch/sh3el -c -Wno-stack-protector -std=gnu++0x /usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/fstream-inst.cc -o fstream-inst.o /usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/fstream-inst.cc: In member function 'void std::basic_fstream::_ZTv0_n12_NSt13basic_fstreamIcSt11char_traitsIcEED1Ev()': /usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/fstream-inst.cc:46:1: internal compiler error: Bus error That SIGBUS happens in incr_ticks_for_insn at resource.c:1275 doing bb_ticks[b]++; and bb_ticks is an address aligned as x*4+2. Since it's not properly aligned for int*, there's SIGBUS triggered. bb_ticks is allocated at resource.c:1201 as: bb_ticks = XCNEWVEC (int, last_basic_block); and for the faulty allocation the last_basic_block is 0. Now, xcalloc in libiberty checks that if (nelem == 0 || elsize == 0) nelem = elsize = 1; and so it ends up with calloc(1, 1). NetBSD's jemalloc rounds allocation size=1 up to 2 and allocates memory at x*4+2 that IS properly aligned for size=2, but IS NOT properly aligned for int *bb_ticks. Since SuperH is strict about alignment, eventual invalid access in incr_ticks_for_insn causes SIGBUS and exposes the bug. The compiler under investigation in the above was build on SuperH to run on SuperH targeting SuperH. To verify this bug I did a cross-build of NetBSD/landisk on an amd64 RedHat machine. Then I manually ran the command that failed in my landisk build using valgrind. So in this verification I used compiler built on amd64, running on amd64 targeting SuperH. Valgrind complained about: ==12675== Invalid read of size 4 ==12675==at 0x743398: incr_ticks_for_insn (in netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus) ==12675==by 0x741636: fill_simple_delay_slots (in netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus) ==12675==by 0x741FA9: dbr_schedule (in netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus) ==12675==by 0x8D9BC7: sh_output_mi_thunk (in netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus) ==12675==by 0x8DF98E: cgraph_expand_function (in netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus) ==12675==by 0x8E11A4: cgraph_optimize (in netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus) ==12675==by 0x8E1A54: cgraph_finalize_compilation_unit (in netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus) ==12675==by 0x4D2BF4: cp_write_global_declarations (in netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus) ==12675==by 0x78D905: do_compile (in netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus) ==12675==by 0x78E04D: toplev_main (in netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus) ==12675==by 0x35C801D973: (below main) (in /lib64/libc-2.5.so) ==12675== Address 0x4f22524 is 3 bytes after a block of size 1 alloc'd ==12675==at 0x4A0516B: calloc (vg_replace_malloc.c:418) ==12675==by 0xA2C628: xcalloc (in netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus) ==12675==by 0x74412B: init_resource_info (in netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus) ==12675==by 0x741F62: dbr_schedule (in netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus) ==12675==by 0x8D9BC7: sh_output_mi_thunk (in netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus) ==12675==by 0x8DF98E: cgraph_expand_function (in netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3a/cc1plus) ==12675==by 0x8E11A4: cgraph_optimize (in netbsd/tools/libexec/gcc/shle-
[Bug target/49880] New: SuperH: ICE when -m4 is used with -mdiv=call-div1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49880
Summary: SuperH: ICE when -m4 is used with -mdiv=call-div1
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: u...@netbsd.org
Host: i386--netbsdelf
Target: shle--netbsdelf
Build: i386--netbsdelf
$ cat idiv.c
int
foo(int a, int b)
{
return a/b;
}
$ /usr/nbgcc45/tools/bin/shle--netbsdelf-gcc -S -m4 -mdiv=call-div1 idiv.c
idiv.c: In function 'foo':
idiv.c:5:1: error: unrecognizable insn:
(insn 14 13 15 3 idiv.c:4 (parallel [
(set (reg:SI 159 [ D.1950 ])
(div:SI (reg:SI 4 r4)
(reg:SI 5 r5)))
(clobber (reg:SI 147 t))
(clobber (reg:SI 146 pr))
(clobber (reg:SI 1 r1))
(clobber (reg:SI 2 r2))
(clobber (reg:SI 3 r3))
(use (reg:SI 165))
]) -1 (expr_list:REG_EQUAL (div:SI (mem/c/i:SI (plus:SI (reg/f:SI 163)
(const_int 60 [0x3c])) [0 a+0 S4 A32])
(mem/c/i:SI (plus:SI (reg/f:SI 164)
(const_int 56 [0x38])) [0 b+0 S4 A32]))
(nil)))
idiv.c:5:1: internal compiler error: in extract_insn, at recog.c:2103
[Bug c++/43135] Possible bug in name resolution during template instantiation
--- Comment #6 from uwe at netbsd dot org 2010-02-22 04:47 --- (In reply to comment #5) > What confuses me is that explictly qualifying the offending call as > > Node::test(op.i) > > makes it compile correctly. I mean as far as I understand Node::test should resolve to the same sibling, so your explanation of why the original fails should still be applicable. Yet it works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43135
[Bug c++/43135] Possible bug in name resolution during template instantiation
--- Comment #5 from uwe at netbsd dot org 2010-02-22 04:45 ---
(In reply to comment #4)
> What I meant to say is this: during parsing ...
So do I get this right (knowing nothing about g++ internals) that in the first
phase ("during parsing") the call to "test" is resolved to sibling because it's
a dependent name with a declaration in-scope. Then during instantiation time
that sibling call is flagged as invalid?
What confuses me is that explictly qualifying the offending call as
Node::test(op.i)
makes it compile correctly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43135
[Bug c++/43135] Possible bug in name resolution during template instantiation
--- Comment #3 from uwe at netbsd dot org 2010-02-22 04:08 --- (In reply to comment #2) > This is not a bug. Because the base class of Node::OpNode does not > depend on template arguments, the members of the base class are > visible in Node::OpNode::f(). On the other hand, since the base > class of Node::FooOpNode depends on template arguments, the members > of the base class are not visible during parsing and before template > arguments are substituted. But doesn't this error happens during instantiation as the error message indicates? If definition of Node::FooNode is commented out, the templates themselves are accepted. Also, if the nested classes are un-nested out of Node, the code compiles w/out errors too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43135
[Bug c++/43135] Possible bug in name resolution during template instantiation
--- Comment #1 from uwe at netbsd dot org 2010-02-22 02:51 --- Created an attachment (id=19932) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19932&action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43135
[Bug c++/43135] New: Possible bug in name resolution during template instantiation
I'm reporting this against my system compiler (4.1.2 on NetBSD/macppc), but I
can reproduce it using all versions from 3.4 (when two-stage name lookup was
introduced) to 4.4 - which I was able to test on a linux/amd64 machine with a
large collection of compilers installed.
The following code (minimized test case) is rejected with
$ g++ -S bug_p.cpp
bug_p.cpp: In member function 'bool Node::FooOpNode<_Op>::f() [with _Op = X]':
bug_p.cpp:63: instantiated from here
bug_p.cpp:54: error: cannot call member function 'bool Node::test(int)' without
object
If offending call to "test" is qualified as "Node::test", compiler accepts it
happily.
Yes, I read http://gcc.gnu.org/onlinedocs/gcc/Name-lookup.html#Name-lookup
8<8<
struct X {
int i;
};
class Node {
public:
template class OpNode;
template class FooOpNode;
class FooNode;
Node() {}
virtual ~Node() {}
bool test(int i) { return true; }
virtual bool f() { return true; }
};
template
class Node::OpNode
: public Node
{
public:
typedef OpNode<_Op> OpNodeBase;
_Op &op;
OpNode(_Op &op) : Node(), op(op) {}
// "test" call ok here
virtual bool f() { return !test(op.i); }
};
template
class Node::FooOpNode
: public OpNode<_Op>
{
public:
typedef OpNode<_Op> OpNodeBase;
using OpNodeBase::op;
typedef FooOpNode<_Op> FooOpNodeBase;
FooOpNode(_Op &op) : OpNodeBase(op) {}
// "test" call marked as error here
// unless qualified as Node::test()
virtual bool f() {
return
// Node::
test(op.i);
}
};
class Node::FooNode
: public FooOpNode
{
public:
FooNode(X &x) : FooOpNodeBase(x) {}
};
8<8<
--
Summary: Possible bug in name resolution during template
instantiation
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uwe at netbsd dot org
GCC build triplet: powerpc--netbsd
GCC host triplet: powerpc--netbsd
GCC target triplet: powerpc--netbsd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43135
[Bug bootstrap/32497] Crosscomiling native sh3 gcc on a 64-bit host fails
--- Comment #1 from uwe at netbsd dot org 2008-04-17 20:14 --- Created an attachment (id=15492) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15492&action=view) Suggested fix Attached patch makes NetBSD/landisk (sh4) cross-build complete successfully on NetBSD/amd64, where it used to fail before. Native gcc built as part of the system (host sh3 -> target sh3) works and produces binaries identical to binaries produced by the native compiler w/out this patch (cross-compiled from i386). The patch basically defers the choice of L/LL suffix until the moment when insn-*.c is compiled with correct HOST_WIDE* defines (gen*.c uses build machine HOST_WIDE* values, not target machine). There's still the problem (marked with XXX in the patch) with the minimim host wide decimal constant that I'm not sure how to address properly, short of always generating -1/+1 hack for all negative values. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497
[Bug bootstrap/32497] New: Crosscomiling native sh3 gcc on a 64-bit host fails
NetBSD autobuild cluster is a mixture of i386 and amd64 machines, and
when sh3 builds hit an amd64 build host the build fails when
cross-compiling native /usr/bin/gcc for sh3 target.
/usr/nb/tools/bin/shle--netbsdelf-gcc ... -c insn-emit.c
insn-emit.c: In function 'gen_mshfhi_l_di':
insn-emit.c:5476: warning: integer constant is too large for 'long' type
insn-emit.c: In function 'gen_mshflo_l_di':
insn-emit.c:5493: warning: this decimal constant is unsigned only in ISO C90
--- insn-emit.o ---
*** [insn-emit.o] Error code 1
1 error
nbmake: stopped in /home/builds/ab/HEAD/src/gnu/usr.bin/gcc4/backend
My i386 build (this one is ok) has:
/* /usr/src/gnu/dist/gcc4/gcc/config/sh/sh.md:12291 */
rtx
gen_mshfhi_l_di (rtx operand0 ATTRIBUTE_UNUSED,
rtx operand1 ATTRIBUTE_UNUSED,
rtx operand2 ATTRIBUTE_UNUSED)
{
return gen_rtx_SET (VOIDmode,
operand0,
gen_rtx_IOR (DImode,
gen_rtx_LSHIFTRT (DImode,
operand1,
const_int_rtx[MAX_SAVED_CONST_INT + (32)]),
gen_rtx_AND (DImode,
operand2,
GEN_INT (-4294967296LL;
}
/* /usr/src/gnu/dist/gcc4/gcc/config/sh/sh.md:12343 */
rtx
gen_mshflo_l_di (rtx operand0 ATTRIBUTE_UNUSED,
rtx operand1 ATTRIBUTE_UNUSED,
rtx operand2 ATTRIBUTE_UNUSED)
{
return gen_rtx_SET (VOIDmode,
operand0,
gen_rtx_IOR (DImode,
gen_rtx_AND (DImode,
operand1,
GEN_INT (4294967295LL)),
gen_rtx_ASHIFT (DImode,
operand2,
const_int_rtx[MAX_SAVED_CONST_INT + (32)])));
}
I don't have any 64-bit machine handy, but a friend sent me
insn-emit.c (failing like above) from his 64-bit machine and it has
4294967295 and -4294967296 in the above marked as long (L),
not long long (LL). And as that insn-emit.c is compiled with
shle--netbsdelf-gcc it is not happy about those constants.
While this issue was discussed on NetBSD mailing lists
the following comment was made by Izumi Tsutsui:
| The statements in insn-emit.c are generated by
| the following line:
| > printf (HOST_WIDE_INT_PRINT_DEC_C, INTVAL (x));
| in src/gnu/dist/gcc4/gcc/genemit.c, and HOST_WIDE_INT_PRINT_DEC_C
| is defined in src/gnu/dist/gcc4/gcc/hwint.h.
[...]
| Sources for the "build" machine should include "bconfig.h"
| then HOST_foo macros will represent build's sizes.
| Sources for the "host" machine should include "config.h"
| then HOST_foo macros will represent host's sizes.
|
| But in genemit.c case, it's a source for the build so
| it includes "bconfig.h" then HOST_foo macros represent
| build's size, but HOST_WIDE_INT_PRINT_DEC_C is used
| in printf(3) to create insn-emit.c which is a source
| of the host machine.
| Then a build's type (long) is used in a host's source
| where it should be a host's type (long long).
|
| Is there any way to refer host's sizes ("LL" suffix
| for 64bit integers in this case) in build's sources?
--
Summary: Crosscomiling native sh3 gcc on a 64-bit host fails
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uwe at netbsd dot org
GCC build triplet: x86_64--netbsd
GCC host triplet: shle--netbsdelf
GCC target triplet: shle--netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497
[Bug other/32163] Compiling with stack protector causes reigster spill failure
--- Comment #2 from uwe at netbsd dot org 2007-05-31 11:44 --- Before failing to compile pic version of asprintf.o as reportde above, non-pic version is successfully compiled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32163
[Bug other/32163] Compiling with stack protector causes reigster spill failure
--- Comment #1 from uwe at netbsd dot org 2007-05-31 11:37 --- Created an attachment (id=13638) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13638&action=view) Preprocessed source of the file that causes the error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32163
[Bug other/32163] New: Compiling with stack protector causes reigster spill failure
Building NetBSD/sh3 soruce tree with stack protector enabled fails with
/usr/nb-ssp/tools/bin/shle--netbsdelf-gcc -O -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wno-traditional
-Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra
-Wno-unused-parameter -std=gnu99 -Werror -fstack-protector -Wstack-protector
--param ssp-buffer-size=1 -D_LIBC -DLIBC_SCCS -DSYSLIBC_SCCS -D_REENTRANT
-DHESIOD -DINET6 -DNLS -DYP -I/usr/src/lib/libc/include -I/usr/src/lib/libc
-DSOFTFLOAT -I/usr/src/lib/libc/arch/sh3/softfloat
-I/usr/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -I/usr/src/sys
-I/usr/src/lib/libc/compat/stdlib -I/usr/src/lib/libc/compat/../stdlib
-I/usr/src/lib/libc/../../common/lib/libc/quad
-I/usr/src/lib/libc/../../common/lib/libc/string
-I/usr/src/lib/libc/../../common/lib/libc/arch/sh3/string
-D__DBINTERFACE_PRIVATE -DI18NMODULE_MAJOR=4 -DCITRUS
-I/usr/src/libexec/ld.elf_so -I/usr/src/lib/libc/dlfcn
-I/usr/src/lib/libc/gdtoa -DNO_FENV_H -I/usr/src/lib/libc/arch/sh3/gdtoa
-DCITRUS_ICONV -DWITH_RUNE -I/usr/src/lib/libc -DPOSIX_MISTAKE -DCOMPAT__RES
-DUSE_POLL -DPORTMAP -DWIDE_DOUBLE -DALL_STATE -DUSG_COMPAT -nostdinc -isystem
/usr/nb-ssp/distrib/landisk/usr/include -c -D_I18N_DYNAMIC -fPIC -DPIC
/usr/src/lib/libc/stdio/asprintf.c -o asprintf.so
/usr/src/lib/libc/stdio/asprintf.c: In function '_asprintf':
/usr/src/lib/libc/stdio/asprintf.c:85: error: unable to find a register to
spill in class 'R0_REGS'
/usr/src/lib/libc/stdio/asprintf.c:85: error: this is the insn:
(insn 191 211 210 7 (set (reg/f:SI 2 r2 [246])
(mem/u/c:SI (plus:SI (reg:SI 12 r12)
(reg/f:SI 1 r1 [247])) [0 S4 A32])) 171 {movsi_i}
(insn_list:REG_DEP_TRUE 189 (nil))
(expr_list:REG_DEAD (reg/f:SI 1 r1 [247])
(expr_list:REG_EQUIV (symbol_ref:SI ("__stack_chk_guard") [flags 0x40]
)
(nil
/usr/src/lib/libc/stdio/asprintf.c:85: confused by earlier errors, bailing out
The compiler is gcc 4.1.2 as imported into the NetBSD tree:
shle--netbsdelf-gcc (GCC) 4.1.2 20070110 (prerelease) (NetBSD nb1 20070110)
--
Summary: Compiling with stack protector causes reigster spill
failure
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uwe at netbsd dot org
GCC build triplet: i386--netbsdelf
GCC host triplet: i386--netbsdelf
GCC target triplet: sh3--netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32163
[Bug bootstrap/30598] Misdetection of COMDAT group support
--- Comment #2 from uwe at netbsd dot org 2007-02-26 16:35 --- (In reply to comment #1) > On the second thought, I might be confused here. Please, leave UNCONFIRMED. > I'll do more testing and get back with an update later today. Sorry. That was a pilot error. Please close. Sorry for the fuss. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30598
[Bug bootstrap/30598] Misdetection of COMDAT group support
--- Comment #1 from uwe at netbsd dot org 2007-01-26 14:18 --- On the second thought, I might be confused here. Please, leave UNCONFIRMED. I'll do more testing and get back with an update later today. Sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30598
[Bug bootstrap/30598] New: Misdetection of COMDAT group support
We discovered this issue while importing newer gcc 4.1* into NetBSD tree and
saw that suddently it no longer thinks COMDAT is supported.
I've tracked it down to the following change:
http://gcc.gnu.org/viewcvs?view=rev&revision=99395
that changed configure.ac to check $ld_date to decide if COMDAT is supported.
There are two problems with that change:
1) Released versions of binutils 2.16* do NOT have date in the ld version
string:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldver.c?rev=1.10&content-type=text/x-cvsweb-markup&cvsroot=src
fprintf (stdout, _("GNU ld version %s\n"), BFD_VERSION_STRING);
2) The above change to confgiure unconditionally overrides
gcc_cv_as_comdat_group and gcc_cv_as_comdat_group_percent passed via
environment
so we cannot even work around the problem #1 by supplying correct values
--
Summary: Misdetection of COMDAT group support
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uwe at netbsd dot org
GCC build triplet: i386--netbsdelf
GCC host triplet: i386--netbsdelf
GCC target triplet: i386--netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30598
[Bug middle-end/28283] SuperH: Very unoptimal code generated for 64-bit ints
--- Comment #9 from uwe at netbsd dot org 2006-07-20 03:27 --- (In reply to comment #8) > Author: sayle > Date: Wed Jul 19 05:13:56 2006 > New Revision: 115578 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115578 > Log: > > PR middle-end/28283 > * expmed.c (expand_shift): Additionally check that the shift_cost > is not MAX_COST and that INTVAL(op1) is less than MAX_BITS_PER_WORD > before implementing a LSHIFT_EXPR as a sequence of additions. > * config/sh/sh.c (shift_costs): Return MAX_COST to inform the > middle-end that DImode shifts need to be synthesized by expand. > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/config/sh/sh.c > trunk/gcc/expmed.c Thanks! Is this planned for pull-up to 4.1.x? -uwe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28283
[Bug rtl-optimization/28283] New: SuperH: Very unoptimal code generated for 64-bit ints
NetBSD has recently imported gcc 4.1.2 prerelease. I've noticed that
for sh3 there's a serious degradation in the quality of the generated
code for long long handling.
While generally the generated code is more compact, as soon as 64-bit
ints come into play, the size increases, e.g. softfloat.o explodes
from 10K to 28K just to pick one of the worst cases from our libc.
The worst case was actually bswap64 - by an oversight libc used C
version instead of hand-written asm version and it grew from a few
instructions to 100+ instructions.
A minimal self-contained test case (extracted from bswap64) that
demonstrates this is:
unsigned long long int
expand64(unsigned int x)
{
return (unsigned long long int)x << 32;
}
Compiling with -O2 -fomit-frame-pointer I get:
* gcc3
shle--netbsdelf-gcc (GCC) 3.3.6 (NetBSD nb1 20060605)
expand64:
mov r4,r5
mov #0,r4
mov r4,r0
rts
mov r5,r1
* gcc4
shle--netbsdelf-gcc (GCC) 4.1.2 20060628 (prerelease) (NetBSD nb1 20060602)
expand64:
mov #0,r5
mov r4,r1
clrt
addcr4,r1
mov r5,r2
addcr5,r2
mov r1,r3
clrt
addcr1,r3
mov r2,r4
addcr2,r4
clrt
addcr3,r3
addcr4,r4
...
/* crlt/addc/addc sequence repeated total of 32 times */
...
mov r3,r0
rts
mov r4,r1
--
Summary: SuperH: Very unoptimal code generated for 64-bit ints
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uwe at netbsd dot org
GCC build triplet: i386--netbsdelf
GCC host triplet: i386--netbsdelf
GCC target triplet: shle--netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28283
