[Bug target/114358] ICE in change_address_1, at emit-rtl.cc:2287 on m68k-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114358 --- Comment #6 from Thorsten Glaser --- Oh okay. I have no easy way to check the trunk; gcc-snapshot_1:20240117-1 failed to build (due to an ICE in libgo). In about two days, gcc-14_14-20240315-1 should be built, which I can check then, if that helps (I’m not sure if the fix was before gcc-14 was branched off).
[Bug target/114358] ICE in change_address_1, at emit-rtl.cc:2287 on m68k-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114358 Thorsten Glaser changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #2 from Thorsten Glaser --- Sure? bug 110934 was about =all and using =used fixed the ICE back then. Now it ICEs in both.
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
Thorsten Glaser changed:
What|Removed |Added
CC||tg at mirbsd dot org
--- Comment #47 from Thorsten Glaser ---
Regarding the proposed attribute: it would also be really great if I could do…
struct foo {
int type;
char name[] __attribute__((__element_count__(0)));
};
… to denote name[] is a NUL-terminated string.
This also allows, although not static, bounds checking for most of the use
cases not covered by a counting member (optionally multiplied by an extra
factor).
[Bug c/111398] GCC should warn if a struct with flexible array member is declared static or onstack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111398 --- Comment #2 from Thorsten Glaser --- Right, which is why I suggested a -Wextra level option to warn about these. Thanks!
[Bug c/111398] New: GCC should warn if a struct with flexible array member is declared static or onstack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111398
Bug ID: 111398
Summary: GCC should warn if a struct with flexible array member
is declared static or onstack
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tg at mirbsd dot org
Target Milestone: ---
If I have (-std=c99 and up) a…
struct foo {
size_t len;
char buf[];
};
… then I would like to be warned (at least with -Wextra or something) if I do
either of…
static struct foo a; // this
struct foo b; // this
extern struct foo x; // and probably even this!
void bla(void) {
static struct foo c; // this
struct foo d; // and this
}
(Probably the same for GCC’s char buf[0]; extension.)
[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #18 from Thorsten Glaser --- I cannot, unfortunately. But I have found _another_ “mitigation”: varsub() is static and has only one caller: https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/mksh.git;a=blob;f=eval.c;h=cb959b1d1104229ead20a698ff2dc974b8da3b10;hb=35563a7897b98de2743233c5f3340a14bea6ebf2#l400 By making varsub… https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/mksh.git;a=blob;f=eval.c;h=cb959b1d1104229ead20a698ff2dc974b8da3b10;hb=35563a7897b98de2743233c5f3340a14bea6ebf2#l1238 … not static, the bug *also* goes away. (Probably because varsub is not inlined.) Now we see that… 399 sp = cstrchr(sp, '\0') + 1; 400 type = varsub(, varname, sp, , ); … the varsub call is *directly* below the strchr/strlen line, *and* it gets passed the sp variable. (Inside varsub, the variable is also modified.) My suspicion here is that, somehow only triggerable on x32+dietlibc, something about the multiple modifications of sp (just before and within varsub) confuses GCC? And indeed. Adding -O2, -O1, -O0 to the GCC command line doesn’t help, but -fno-inline again does. As does adding an attribute to the function prototype: static int varsub(Expand *, const char *, const char *, unsigned int *, int *) __attribute__((noinline)); Could we somehow debug there further? I really don’t see a way to reproduce this on x32/glibc or amd64…
[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #17 from Thorsten Glaser --- Hm, okay, I’ll try to find if I can trigger it in glibc/x32 then…
[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #16 from Thorsten Glaser ---
If I add -maddress-mode=long to the build of the expr.c file, then link it with
the rest, it still fails.
I’m not sure about reducing, and not sure about the cross-anything, but I *did*
get it to fail on amd64 now! (Just differently.) HOWEVER, I’m not sure whether
this is from x32/amd64 mismatch or from the bug, as the resulting pattern
differs.
The code flow is roughly: eval.c from line 1608 onwards opens a temporary file,
dups it to stdout, calls funsub() from line 2147, and on return rewinds that
file and restores stdout. This all is called from line 352 (where the jump to
the subroutine is), but the strlen in question is on line 399 in a different
codepath (where the stuff immediately following '${' is parsed). They only have
the use of the variable 'sp' and the jumping past the first NUL in it in common
(the funsub caller has 'sp = strnul(sp) + 1;' instead, but that’s just
'sp+strlen(sp)', and changing the 'sp = cstrchr(sp, '\0') + 1;' to that (which
I did in upstream CVS HEAD now anyway) doesn’t “fix” the issue.
In a Debian sid/amd64 chroot, with GCC 13.2.0-1 (as packaged in Debian), I did:
gcc-13 -g -fno-lto -fno-asynchronous-unwind-tables -fno-strict-aliasing
-fstack-protector-strong -malign-data=abi -fwrapv -I. -D_FORTIFY_SOURCE=2
-DMKSH_BUILDMEAT -DMKSH_BUILDSH=1 -D_GNU_SOURCE -DSETUID_CAN_FAIL_WITH_EAGAIN=1
-DHAVE_STRING_POOLING=2 -DHAVE_ATTRIBUTE_BOUNDED=0 -DHAVE_ATTRIBUTE_FORMAT=1
-DHAVE_ATTRIBUTE_NORETURN=1 -DHAVE_ATTRIBUTE_UNUSED=1 -DHAVE_ATTRIBUTE_USED=1
-DHAVE_SYS_TIME_H=1 -DHAVE_TIME_H=1 -DHAVE_BOTH_TIME_H=1 -DHAVE_SYS_SELECT_H=1
-DHAVE_SELECT_TIME_H=1 -DHAVE_SYS_BSDTYPES_H=0 -DHAVE_SYS_FILE_H=1
-DHAVE_SYS_MKDEV_H=0 -DHAVE_SYS_MMAN_H=1 -DHAVE_SYS_PARAM_H=1
-DHAVE_SYS_PTEM_H=0 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SYSMACROS_H=1
-DHAVE_BSTRING_H=0 -DHAVE_GRP_H=1 -DHAVE_IO_H=0 -DHAVE_LIBGEN_H=1
-DHAVE_LIBUTIL_H=0 -DHAVE_PATHS_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1
-DHAVE_TERMIOS_H=1 -DHAVE_ULIMIT_H=1 -DHAVE_VALUES_H=1 -DHAVE_CAN_INTTYPES=1
-DHAVE_SIG_T=1 -DHAVE_STRERRORDESC_NP=1 -DHAVE_SYS_ERRLIST=1
-DHAVE_SIGABBREV_NP=1 -DHAVE_SYS_SIGNAME=0 -DHAVE_SIGDESCR_NP=1
-DHAVE_SYS_SIGLIST=1 -DHAVE_FLOCK=1 -DHAVE_LOCK_FCNTL=1 -DHAVE_RLIMIT=1
-DHAVE_RLIM_T=1 -DHAVE_GET_CURRENT_DIR_NAME=1 -DHAVE_GETRANDOM=0
-DHAVE_GETRUSAGE=1 -DHAVE_GETSID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_KILLPG=1
-DHAVE_MEMMOVE=1 -DHAVE_MKNOD=0 -DHAVE_MMAP=1 -DHAVE_FTRUNCATE=1 -DHAVE_NICE=1
-DHAVE_RENAME=1 -DHAVE_REVOKE=0 -DHAVE_POSIX_UTF8_LOCALE=0 -DHAVE_SELECT=1
-DHAVE_SETRESUGID=1 -DHAVE_SETGROUPS=1 -DHAVE_SIGACTION=1 -DHAVE_STRERROR=0
-DHAVE_STRSIGNAL=0 -DHAVE_STRLCPY=0 -DHAVE_STRSTR=1 -DHAVE_FLOCK_DECL=1
-DHAVE_REVOKE_DECL=1 -DHAVE_SYS_ERRLIST_DECL=1 -DHAVE_SYS_SIGLIST_DECL=1
-DHAVE_ST_MTIMENSEC=0 -DHAVE_INTCONSTEXPR_RSIZE_MAX=0
-DHAVE_PERSISTENT_HISTORY=1 -DMKSH_BUILD_R=599 -c lalloc.c edit.c eval.c exec.c
expr.c funcs.c histrap.c jobs.c lex.c main.c misc.c shf.c syn.c tree.c var.c
ulimit.c strlcpy.c
gcc-13 -g -fno-lto -fno-asynchronous-unwind-tables -fno-strict-aliasing
-fstack-protector-strong -malign-data=abi -fwrapv -fno-lto -o mksh lalloc.o
edit.o eval.o exec.o expr.o funcs.o histrap.o jobs.o lex.o main.o misc.o shf.o
syn.o tree.o var.o ulimit.o strlcpy.o
./mksh -c 'x=q; x=${ echo a; typeset e=2; return 3; echo x$e;}; echo .$x.'
gcc-13 -g -fno-lto -fno-asynchronous-unwind-tables -fno-strict-aliasing
-fstack-protector-strong -malign-data=abi -fwrapv -I. -D_FORTIFY_SOURCE=2
-DMKSH_BUILDMEAT -DMKSH_BUILDSH=1 -D_GNU_SOURCE -DSETUID_CAN_FAIL_WITH_EAGAIN=1
-DHAVE_STRING_POOLING=2 -DHAVE_ATTRIBUTE_BOUNDED=0 -DHAVE_ATTRIBUTE_FORMAT=1
-DHAVE_ATTRIBUTE_NORETURN=1 -DHAVE_ATTRIBUTE_UNUSED=1 -DHAVE_ATTRIBUTE_USED=1
-DHAVE_SYS_TIME_H=1 -DHAVE_TIME_H=1 -DHAVE_BOTH_TIME_H=1 -DHAVE_SYS_SELECT_H=1
-DHAVE_SELECT_TIME_H=1 -DHAVE_SYS_BSDTYPES_H=0 -DHAVE_SYS_FILE_H=1
-DHAVE_SYS_MKDEV_H=0 -DHAVE_SYS_MMAN_H=1 -DHAVE_SYS_PARAM_H=1
-DHAVE_SYS_PTEM_H=0 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SYSMACROS_H=1
-DHAVE_BSTRING_H=0 -DHAVE_GRP_H=1 -DHAVE_IO_H=0 -DHAVE_LIBGEN_H=1
-DHAVE_LIBUTIL_H=0 -DHAVE_PATHS_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1
-DHAVE_TERMIOS_H=1 -DHAVE_ULIMIT_H=1 -DHAVE_VALUES_H=1 -DHAVE_CAN_INTTYPES=1
-DHAVE_SIG_T=1 -DHAVE_STRERRORDESC_NP=1 -DHAVE_SYS_ERRLIST=1
-DHAVE_SIGABBREV_NP=1 -DHAVE_SYS_SIGNAME=0 -DHAVE_SIGDESCR_NP=1
-DHAVE_SYS_SIGLIST=1 -DHAVE_FLOCK=1 -DHAVE_LOCK_FCNTL=1 -DHAVE_RLIMIT=1
-DHAVE_RLIM_T=1 -DHAVE_GET_CURRENT_DIR_NAME=1 -DHAVE_GETRANDOM=0
-DHAVE_GETRUSAGE=1 -DHAVE_GETSID=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_KILLPG=1
-DHAVE_MEMMOVE=1 -DHAVE_MKNOD=0 -DHAVE_MMAP=1 -DHAVE_FTRUNCATE=1 -DHAVE_NICE=1
-DHAVE_RENAME=1 -DHAVE_REVOKE=0 -DHAVE_POSIX_UTF8_LOCALE=0 -DHAVE_SELECT=1
-DHAVE_SETRESUGID=1 -DHAVE_SETGROUPS=1 -DHAVE_SIGACTION=1 -DHAVE_STRERROR=0
-DHAVE_STRSIGNAL=0 -DHAVE_STRLCPY=0 -DHAVE_STRSTR=1 -DHAVE_FLOCK_DECL=1
-DHAVE_REVOKE_DECL=1 -DHAVE_SYS_ERRLIST_DECL=1 -DHAVE_SYS_SIGLIST_DECL=1
-DHAVE_ST_MTIMENSEC=0
[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #13 from Thorsten Glaser --- The interesting part is around the occurrence of… # eval.c:399: sp = cstrchr(sp, '\0') + 1; … in the .s files (it occurs thrice, the first is the beginning of the setup part, the second and third surround the strlen call, so they’re all within a bunch of lines).
[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #12 from Thorsten Glaser --- Created attachment 55808 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55808=edit tarball (.xz) with preprocessed and assembly output I’ve verified (back to unmodified source) that it is indeed only the file eval.c that’s at fault. I’ve compiled mksh with gcc-12, then built that one file with gcc-13, linked with gcc-12, and it failed. I’m attaching an xz-compressed tarball with preprocessed and assembly (both AT and Intel, both -fverbose-asm and not) of the file with exactly identical options between GCC 12 and 13, in the hope of that being helpful to hunt this down.
[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #11 from Thorsten Glaser --- OK, to summarise: When using the original code but providing a wrapper function (in a separate CU) for strchr, it works. When replacing the strchr with strlen (which GCC also does), it fails even without the presence of dietlibc’s strlen. (And yes, disassembly of main.o (where I added it) shows no call to dietlibc from xstrlen.) This doesn’t seem to be coupled to the name of the function (the wrapper functions are called cstrchr and xstrlen, so the compiler cannot make any assumptions about them).
[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #10 from Thorsten Glaser ---
oh no, wait, that was for strchr… the strlen one… but, yeah, that too:
extern size_t xstrlen(const char *s);
and changing the line again to…
sp += xstrlen(sp) + 1;
… and adding in another .c file:
size_t xstrlen(const char *s) {
register const char *cp = s;
while (*cp++ != '\0')
;
return (--cp - s);
}
And it still fails.
[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #9 from Thorsten Glaser --- > Does providing your own (trivially correct) strlen implementation in a > separate CU also fix the issue? Even providing one that just calls dietlibc’s (in a separate CU) fixes the issue, so I’m very sure it’s not that, but probably some codegen surrounding the call.
[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #7 from Thorsten Glaser --- (but with this, I think it’s neither the GCC builtins, nor a change thereof, nor anything about dietlibc that is at fault; feel free to adjust the title accordingly) Surrounding code: https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/mksh.git;a=blob;f=eval.c;h=cb959b1d1104229ead20a698ff2dc974b8da3b10;hb=35563a7897b98de2743233c5f3340a14bea6ebf2#l399 Would gcc-12‑ and ‑13-generated .s files from otherwise identical builds, for comparison, help? (With -fverbose-asm I presume?) Or anything else?
[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #6 from Thorsten Glaser ---
dietlibc’s strlen is a horrid SSE nightmare that doesn’t call (f)emms, but it
has a switch global variable __valgrind, if setting that to 1 it uses a very
traditional loop instead, and the registers before/after strlen also match
(only rax has changed), so I’m at a loss.
Changing the line to…
sp += strlen(sp) + 1;
… doesn’t make the problem go away, for some reason. Replacing it with…
while (*sp++) ;
… however *does* make it go away.
I’ll paste a screenlog of single-stepping through the valgrind version of the
code below (http://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/.gdbinit?rev=HEAD
has the helpful t macro):
Breakpoint 1, expand (ccp=, wp=wp@entry=0xcdf0, f=f@entry=0)
at eval.c:401
401 asm volatile("nop"); //401
(gdb) t
=> 0x40a63f : nop
402 sp = cstrchr(sp, '\0') + 1;
rax0xf7ff790e 4160715022
rbx0x0 0
rcx0x0 0
rdx0xff81 4294967169
rsi0x98152
rdi0xcd5c 4294954332
rbp0xf7ff790c 4160715020
rsp0xcc90 4294954128
r8 0xa0160
r9 0x3 3
r100x0 0
r110x206 518
r120x2 2
r130xd1b4 4294955444
r140xf7ff510c 4160704780
r150x0 0
rip0x40a6404236864
eflags 0x287 [ CF PF SF IF ]
cs 0x3351
ss 0x2b43
ds 0x2b43
es 0x2b43
fs 0x0 0
gs 0x0 0
=> 0x40a640 : movebx,DWORD PTR [rsp+0x48]
0x40a644 : movrdi,rbx
0x40a647 : call 0x42cc7e
(gdb) t
=> 0x40a640 : movebx,DWORD PTR [rsp+0x48]
0x0040a644 402 sp = cstrchr(sp, '\0')
+ 1;
rax0xf7ff790e 4160715022
rbx0xf7ff790e 4160715022
rcx0x0 0
rdx0xff81 4294967169
rsi0x98152
rdi0xcd5c 4294954332
rbp0xf7ff790c 4160715020
rsp0xcc90 4294954128
r8 0xa0160
r9 0x3 3
r100x0 0
r110x206 518
r120x2 2
r130xd1b4 4294955444
r140xf7ff510c 4160704780
r150x0 0
rip0x40a6444236868
eflags 0x287 [ CF PF SF IF ]
cs 0x3351
ss 0x2b43
ds 0x2b43
es 0x2b43
fs 0x0 0
gs 0x0 0
=> 0x40a644 : movrdi,rbx
0x40a647 : call 0x42cc7e
0x40a64c : movecx,DWORD PTR [rsp+0x48]
(gdb) t
=> 0x40a644 : movrdi,rbx
0x0040a647 402 sp = cstrchr(sp, '\0')
+ 1;
rax0xf7ff790e 4160715022
rbx0xf7ff790e 4160715022
rcx0x0 0
rdx0xff81 4294967169
rsi0x98152
rdi0xf7ff790e 4160715022
rbp0xf7ff790c 4160715020
rsp0xcc90 4294954128
r8 0xa0160
r9 0x3 3
r100x0 0
r110x206 518
r120x2 2
r130xd1b4 4294955444
r140xf7ff510c 4160704780
r150x0 0
rip0x40a6474236871
eflags 0x287 [ CF PF SF IF ]
cs 0x3351
ss 0x2b43
ds 0x2b43
es 0x2b43
fs 0x0 0
gs 0x0 0
=> 0x40a647 : call 0x42cc7e
0x40a64c : movecx,DWORD PTR [rsp+0x48]
0x40a650 : lear12d,[rcx+rax*1+0x1]
(gdb) t
=> 0x40a647 : call 0x42cc7e
0x0042cc7e in strlen ()
rax0xf7ff790e 4160715022
rbx0xf7ff790e 4160715022
rcx0x0 0
rdx0xff81 4294967169
rsi0x98152
rdi0xf7ff790e 4160715022
rbp0xf7ff790c 4160715020
rsp0xcc88 4294954120
r8 0xa0
[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #5 from Thorsten Glaser ---
I managed to isolate one specific strchr call changing which causes the
breakage to go away:
asm volatile("nop"); //401
sp = cstrchr(sp, '\0') + 1;
asm volatile("nop"); //403
where:
#define cstrchr(s,c)((const char *)strchr((s), (c)))
const char *sp;
I inserted NOPs around (see above) and set gdb breakpoints there, and
before/after those breakpoints, the callee-saved registers differ (only showing
callee-saved registers for amd64/x32):
(gdb) info r
rbx0x0 0
rbp0xf7ff790c 4160715020
r120x2 2
r130xd1b4 4294955444
r140xf7ff510c 4160704780
r150x0 0
(gdb) c
(gdb) info r
rbx0xf7ff790e 4160715022
rbp0xf7ff790c 4160715020
r120xf7ff7912 4160715026
r130xd1b4 4294955444
r140xf7ff510c 4160704780
r150x0 0
Corresponding disassembly of generated code between the NOPs:
=> 0x0040a635 <+1875>: nop
0x0040a636 <+1876>: mov0x48(%rsp),%ebx
0x0040a63a <+1880>: mov%rbx,%rdi
0x0040a63d <+1883>: call 0x42cc6e
0x0040a642 <+1888>: mov0x48(%rsp),%ecx
0x0040a646 <+1892>: lea0x1(%rcx,%rax,1),%r12d
0x0040a64b <+1897>: nop
or, in readable:
=> 0x0040a635 <+1875>: nop
0x0040a636 <+1876>: movebx,DWORD PTR [rsp+0x48]
0x0040a63a <+1880>: movrdi,rbx
0x0040a63d <+1883>: call 0x42cc6e
0x0040a642 <+1888>: movecx,DWORD PTR [rsp+0x48]
0x0040a646 <+1892>: lear12d,[rcx+rax*1+0x1]
0x0040a64b <+1897>: nop
OK, huh… no strchr involved here.
For comparison, with -fno-builtin-strchr:
=> 0x0040a632 <+1872>: nop
0x0040a633 <+1873>: movebx,DWORD PTR [rsp+0x48]
0x0040a637 <+1877>: xoresi,esi
0x0040a639 <+1879>: movrdi,rbx
0x0040a63c <+1882>: call 0x42cba4
0x0040a641 <+1887>: movr14d,eax
0x0040a644 <+1890>: inceax
0x0040a646 <+1892>: movDWORD PTR [rsp+0x3c],eax
0x0040a64a <+1896>: nop
I’ll dig into strlen in dietlibc/x32 next.
[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #4 from Thorsten Glaser ---
Its {,sig}{set,long}jmp for x32 look good.
[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #3 from Thorsten Glaser --- Not yet, given it’s been relatively clearly tracked down to a change in GCC. I’ll have at its setjmp/longjmp myself now, will report back.
[Bug target/111165] New: [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
Bug ID: 65
Summary: [13 regression] builtin strchr miscompiles on
Debian/x32 with dietlibc
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tg at mirbsd dot org
Target Milestone: ---
Debian bug reported as:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050589
I’ve got no idea how to quickly reduce that down, but perhaps anyone has got an
idea.
In an x32 (amd64ilp32) environment, with dietlibc/x32 as packaged in Debian (no
shared libraries), building mksh and then running the command 'x=q; x=${ echo
a; typeset e=2; return 3; echo x$e;}; echo .$x.' with the resulting binary
results in the output “..” instead of “.a.”.
This does not occur when either
- giving -fno-builtin-strchr
- wrapping strchr as outlined below
(which makes me think of register corruption occurring here)
- using amd64 instead of x32 (amd64ilp32)
- using glibc, klibc or musl (though klibc/x32 is in reality amd64 so it can be
discounted)
- using GCC 12.3.0
The codepath is a bit convoluted, setjmp/longjmp are involved.
Wrapping strchr by adding…
char *ucstrchr(char *, int);
const char *cstrchr(const char *, int);
#undef strchr
#define strchr poisoned_strchr
… to a .h file that’s globally included, and adding the following…
#undef strchr
char *ucstrchr(char *s, int c)
{
return (strchr(s, c));
}
const char *cstrchr(const char *s, int c)
{
return (strchr(s, c));
}
… to one .c file *also* works around the bug, for some reason. (mksh is built
with -fno-lto because of other GCC issues I filed regarding this.)
IIRC the builtins are hidden within the LISPy machine definitions or something;
I’m afraid at this point this is beyond my own ability to reduce down, but do
ask me (ideally via eMail to both <1050589-submit...@bugs.debian.org> and
<1050...@bugs.debian.org> (to keep the bug in Cc), but
@mirabi...@toot.mirbsd.org on Fediverse is fine too) if you need any further
details.
(All testing has been done with GCC and dietlibc as packaged in Debian;
especially the latter has quite the deviation from upstream, but I have looked
at diffs and logs and don’t think those are relevant here.)
[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885 Thorsten Glaser changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #15 from Thorsten Glaser --- -Wexp sounds like experimental
[Bug c/64470] New: “floating constant exceeds range” warning for constants that should fit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64470 Bug ID: 64470 Summary: “floating constant exceeds range” warning for constants that should fit Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tg at mirbsd dot org From what I understand, 0x1.0p1024 (and 1E1024 which also warns) should fit into a “double” if __DBL_MAX_EXP__ is 1024. This is a reduced testcase; the original problem used 0x1.0p1024L but __LDBL_MAX_EXP__ on ARM is also 1024. (sid-amd64)tglase@tglase:~ $ cat x.c double foo = 0x1.0p1024; (sid-amd64)tglase@tglase:~ $ /usr/lib/gcc-snapshot/bin/gcc -Woverflow -c x.c x.c:1:1: warning: floating constant exceeds range of 'double' [-Woverflow] double foo = 0x1.0p1024; ^ (sid-amd64)tglase@tglase:~ $ /usr/lib/gcc-snapshot/bin/gcc --version gcc (Debian 20141218-1) 5.0.0 20141218 (experimental) [trunk revision 218861] Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. (sid-amd64)tglase@tglase:~ $ :| /usr/lib/gcc-snapshot/bin/gcc -E -dD - | fgrep DBL_MAX_EXP #define __DBL_MAX_EXP__ 1024 #define __LDBL_MAX_EXP__ 16384 This warning is spewn in libc/stdio/_fpmaxtostr.c in µClibc-ng, which we’re trying to get to build warning-free at the moment.
[Bug web/64471] New: 403 Forbidden on GCC 5 page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64471 Bug ID: 64471 Summary: 403 Forbidden on GCC 5 page Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: tg at mirbsd dot org https://gcc.gnu.org/gcc-5/ Forbidden You don't have permission to access /gcc-5/ on this server. Apache Server at gcc.gnu.org Port 443 Since this page is linked from the front page, I’d expect it to work ;-)
[Bug target/59842] New: `__x86.get_pc_thunk.bx' referenced in section `.text': defined in discarded section…
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59842 Bug ID: 59842 Summary: `__x86.get_pc_thunk.bx' referenced in section `.text': defined in discarded section… Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tg at mirbsd dot org Created attachment 31855 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31855action=edit test runner Hi *, I originally filed this as Debian #735564 but a user informed me they are also seeing this on other GNU/Linux distributions, and with GCC 4.7.1 on Slackware. Since a while, I’m getting errors like these: `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o I used to be able to avoid them (although, back then, the symbol was named “__i686.get_pc_thunk.bx”) by adding -march=i486, but this no longer helps. Screen log (the files x.sh, x.i and x.sym are attached): tglase@tglase:~ $ mksh x.sh `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o `__x86.get_pc_thunk.bx' referenced in section `.text' of x3.o: defined in discarded section `.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]' of x3.o collect2: error: ld returned 1 exit status IMHO, GCC may not mark symbols as discardable that it uses by itself. Adding this to the symbol file is no solution either, as this becomes highly platform- and compiler-dependent.
[Bug target/59842] `__x86.get_pc_thunk.bx' referenced in section `.text': defined in discarded section…
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59842 --- Comment #2 from Thorsten Glaser tg at mirbsd dot org --- Created attachment 31857 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31857action=edit symbols file
[Bug target/59842] `__x86.get_pc_thunk.bx' referenced in section `.text': defined in discarded section…
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59842 --- Comment #1 from Thorsten Glaser tg at mirbsd dot org --- Created attachment 31856 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31856action=edit preprocessed source code
[Bug target/59842] `__x86.get_pc_thunk.bx' referenced in section `.text': defined in discarded section…
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59842 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added Target||i486-linux-gnu URL||http://bugs.debian.org/cgi- ||bin/bugreport.cgi?bug=73556 ||4 Known to work||4.6.4 Host||i486-linux-gnu Known to fail||4.7.1, 4.8.2 Build||i486-linux-gnu --- Comment #3 from Thorsten Glaser tg at mirbsd dot org --- Adding extra info. GCC 4.6 (Debian sid) works iff you add -march=i486 but exhibits the same problem (with different symbol) otherwise. GCC 3.4.6 (MirBSD) works.
[Bug target/59842] `__x86.get_pc_thunk.bx' referenced in section `.text': defined in discarded section…
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59842 --- Comment #5 from Thorsten Glaser tg at mirbsd dot org --- Hm, unsure. These versioning scripts are pretty much recent GNU stuff. But if you have input… cvs -d _anon...@anoncvs.mirbsd.org:/cvs co -PA -d xchat-randex contrib/hosted/tg/code/xchat-randex
[Bug rtl-optimization/52714] [4.7/4.8/4.9 regression] ICE in fixup_reorder_chain, at cfglayout.c:880
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52714 --- Comment #10 from Thorsten Glaser tg at mirbsd dot org --- Yes, we still run with the code reverted to the 4.5 version in Debian. http://patch-tracker.debian.org/patch/series/view/gcc-4.8/4.8.2-10/pr52714.diff
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added Known to fail||4.8.1 --- Comment #22 from Thorsten Glaser tg at mirbsd dot org --- The Debian GCC maintainer refuses to accept my workaround patch. I’m not sure whether he’d accept a patch to always disable -fauto-inc-dec on m68k. A “proper” fix would be welcome as lots of software, most prominently anything Qt (both 4 and 5), FTBFS without this.
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #19 from Thorsten Glaser tg at mirbsd dot org --- Created attachment 30668 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30668action=edit Testcase from qtbase-opensource-src_5.1.0+dfsg-4 and g++ 4.8.1 This issue still appears with GCC 4.8 In GCC 4.6 in Debian/m68k I eventually applied a patch that simply retries the build with -O1 then -O0 to mask this issue, but the underlying issue is still unfixed. This occurs in 4.8 now too, so I guess (from a distro PoV) I need to port said patch, until someone finds out what precisely is going on here. g++ -c x.cc -std=c++0x -fno-exceptions ⇒ compiles fine g++ -c x.cc -std=c++0x -fno-exceptions -O2 ⇒ ICEs: In file included from ../../../include/QtCore/qlist.h:1:0, from ../../../include/QtCore/../../src/corelib/tools/qhash.h:47, from ../../../include/QtCore/qhash.h:1, from ../../../include/QtCore/../../src/corelib/io/qdebug.h:46, from ../../../include/QtCore/qdebug.h:1, from ditaxmlgenerator.cpp:46: ../../../include/QtCore/../../src/corelib/tools/qlist.h: In member function ‘void QListT::append(const T) [with T = Section]’: ../../../include/QtCore/../../src/corelib/tools/qlist.h:521:1: internal compiler error: in cselib_record_set, at cselib.c:2373 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.8/README.Bugs for instructions. Preprocessed source stored into /tmp/ccUYfyzd.out file, please attach this to your bugreport.
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #21 from Thorsten Glaser tg at mirbsd dot org --- -fno-auto-inc-dec helps, thanks!
[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #23 from Thorsten Glaser tg at mirbsd dot org --- Can this please be committed, it definitely fixes gcc-4.8 on Debian/m68k (applied it locally for now and asked the maintainer to include it in the source package).
[Bug java/57929] New: gcc-4.8: FTBFS on m68k: ICE compiling libjava/interpret.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57929 Bug ID: 57929 Summary: gcc-4.8: FTBFS on m68k: ICE compiling libjava/interpret.cc Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java Assignee: unassigned at gcc dot gnu.org Reporter: tg at mirbsd dot org Created attachment 30525 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30525action=edit original preprocessed source code Hi, this is a forward for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711558 which is an ICE trying to bootstrap gcj-4.8 that I *think* remember seeing for gcj-4.7 (but not gcj-4.6 which works fine) already too, on the Debian/m68k Linux 3.x (NPTL, atomics via syscall) platform. The problem is now that the gcj part got merged into the main gcc source package and this is kinda holding up our entire toolchain update (also, I think gcj-4.6 got removed from sid). Since I was unable to get OpenJDK/zero working either, gcj is our only hope to keep Linux/m68k spinning so I’m hoping that $skilled_people will have a look at it. Preprocessed source attached here, too (xz compressed, hope that’s ok).
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added Summary|ICE in CSE |ICE in cselib_record_set, ||at cselib.c:2158 --- Comment #12 from Thorsten Glaser tg at mirbsd dot org 2013-01-29 21:17:04 UTC --- # cat /usr/bin/g++ #!/bin/mksh-static /usr/bin/g++-4.6 $@ exit 0 /usr/bin/g++-4.6 $@ -O1 exit 0 exec /usr/bin/g++-4.6 $@ -O0 Has anyone thought of making GCC do that automatically? It already retries on ICEs to weed out possibly bad memory… if we have an ICE like this specific case, where we *know* optimisation makes a difference and it’s a bug in the compiler, we could just retry lowering the optimisation level each time. (My shell script is very suboptimal as it always retries twice. I’m using it only for the second time now, and both times only during the build, after all configury has been run. Some C++ code seems to exercise PR52306 more than, say, libvirt which has only one occurrence (times two)…)
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #13 from Thorsten Glaser tg at mirbsd dot org 2013-01-29 21:25:58 UTC --- … oh, sorry, the automatic retry is apparently Debian/Feodora specific. Still… in this very case… this ICE in CSE is hitting us often enough…
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306
--- Comment #14 from Thorsten Glaser tg at mirbsd dot org 2013-01-29 23:29:54
UTC ---
just don’t hit me… I’m trying this now, until someone fixes this PR:
# DP: retry a known ICE with -O1 then -O0 in case it gets better
--- a/src/gcc/diagnostic.c
+++ b/src/gcc/diagnostic.c
@@ -242,6 +242,12 @@ diagnostic_action_after_output (diagnost
See %s for instructions.\n, bug_report_url);
exit (ICE_EXIT_CODE);
+case DK_TGV:
+ fnotice (stderr, Retrying with lowered optimisation,\n
+ this is a known bug, do not worry. If it'll\n
+ still fail, just fail the package build.\n);
+ exit (TGV_EXIT_CODE);
+
case DK_FATAL:
if (context-abort_on_error)
real_abort ();
@@ -426,7 +432,7 @@ diagnostic_report_diagnostic (diagnostic
/* If we're reporting an ICE in the middle of some other error,
try to flush out the previous error, then let this one
through. Don't do this more than once. */
- if (diagnostic-kind == DK_ICE context-lock == 1)
+ if ((diagnostic-kind == DK_ICE || diagnostic-kind == DK_TGV)
context-lock == 1)
pp_flush (context-printer);
else
error_recursion (context);
@@ -494,7 +500,7 @@ diagnostic_report_diagnostic (diagnostic
context-lock++;
- if (diagnostic-kind == DK_ICE)
+ if (diagnostic-kind == DK_ICE || diagnostic-kind == DK_TGV)
{
#ifndef ENABLE_CHECKING
/* When not checking, ICEs are converted to fatal errors when an
@@ -507,7 +513,7 @@ diagnostic_report_diagnostic (diagnostic
expanded_location s = expand_location (diagnostic-location);
fnotice (stderr, %s:%d: confused by earlier errors, bailing out\n,
s.file, s.line);
- exit (ICE_EXIT_CODE);
+ exit (diagnostic-kind == DK_TGV ? TGV_EXIT_CODE : ICE_EXIT_CODE);
}
#endif
if (context-internal_error)
@@ -902,3 +908,17 @@ real_abort (void)
{
abort ();
}
+
+void
+tgv_abort (const char *gmsgid, ...)
+{
+ diagnostic_info diagnostic;
+ va_list ap;
+
+ va_start (ap, gmsgid);
+ diagnostic_set_info (diagnostic, gmsgid, ap, input_location, DK_TGV);
+ report_diagnostic (diagnostic);
+ va_end (ap);
+
+ gcc_unreachable ();
+}
--- a/src/gcc/diagnostic.def
+++ b/src/gcc/diagnostic.def
@@ -43,3 +43,4 @@ prefix does not matter. */
DEFINE_DIAGNOSTIC_KIND (DK_PEDWARN, pedwarn: )
DEFINE_DIAGNOSTIC_KIND (DK_PERMERROR, permerror: )
+DEFINE_DIAGNOSTIC_KIND (DK_TGV, internal compiler error: )
--- a/src/gcc/system.h
+++ b/src/gcc/system.h
@@ -235,6 +235,7 @@ extern int errno;
#endif
#define ICE_EXIT_CODE 4
+#define TGV_EXIT_CODE 23
#ifdef HAVE_UNISTD_H
# include unistd.h
@@ -642,6 +643,15 @@ extern void fancy_abort (const char *, i
#define gcc_assert(EXPR) ((void)(0 (EXPR)))
#endif
+extern void tgv_abort (const char *, ...) ATTRIBUTE_NORETURN;
+#if ENABLE_ASSERT_CHECKING
+#define gcc_assert_and_retry_with_lowered_optimisation_level(EXPR) \
+ ((void)(!(EXPR) ? tgv_abort (in %s, at %s:%d, __FUNCTION__, trim_filename
(__FILE__), __LINE__), 0 : 0))
+#else
+#define gcc_assert_and_retry_with_lowered_optimisation_level(EXPR)\
+ gcc_assert (EXPR)
+#endif
+
#ifdef ENABLE_CHECKING
#define gcc_checking_assert(EXPR) gcc_assert (EXPR)
#else
--- a/src/gcc/gcc.c
+++ b/src/gcc/gcc.c
@@ -253,6 +253,7 @@ static const char *convert_filename (con
#if !(defined (__MSDOS__) || defined (OS2) || defined (VMS))
static void retry_ice (const char *prog, const char **argv);
#endif
+static const char **tgv_argv(const char **);
static const char *getenv_spec_function (int, const char **);
static const char *if_exists_spec_function (int, const char **);
@@ -2464,6 +2465,7 @@ execute (void)
{
int i;
int n_commands;/* # of command. */
+ int retry_tgv = 0;
char *string;
struct pex_obj *pex;
struct command
@@ -2529,7 +2531,8 @@ execute (void)
/* If -v, print what we are about to do, and maybe query. */
- if (verbose_flag)
+ do {
+ if (verbose_flag || retry_tgv)
{
/* For help listings, put a blank line between sub-processes. */
if (print_help_list)
@@ -2659,13 +2662,12 @@ execute (void)
pfatal_with_name (errmsg);
}
}
-
- if (i string != commands[i].prog)
-free (CONST_CAST (char *, string));
}
execution_count++;
+ retry_tgv = ~0x80;
+
/* Wait for all the subprocesses to finish. */
{
@@ -2717,6 +2719,26 @@ execute (void)
/* For ICEs in cc1, cc1obj, cc1plus see if it is
reproducible or not. */
const char *p;
+if (WEXITSTATUS (status) == TGV_EXIT_CODE
+ i == 0
+ (p = strrchr (commands[0].argv[0], DIR_SEPARATOR))
+ ! strncmp (p + 1, cc1, 3)) {
+ if (retry_tgv == 0) {
+commands[0].argv = tgv_argv(commands[0].argv);
+retry_tgv = 0x81;
+goto foo_tgv;
+ }
+ if (retry_tgv == 1) {
+size_t qqq = 0;
+
+while
[Bug target/56087] New: [m68k] gcc miscompiles pari (multiplication)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56087 Bug #: 56087 Summary: [m68k] gcc miscompiles pari (multiplication) Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: t...@mirbsd.org Created attachment 29257 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29257 preprocessed reduced testcase More context: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698380 This turned out to be a miscompilation of one function; reduced testcase (still pretty large due to header inclusion, but, oh my) attached. Using the same register twice in muls.l is not permitted. Removing -funroll-loops lets this use two distinct ones, as do control flow differences. This happens on native compilation but can be reproduced on cross compilation. tg@freewrt:~ $ m68k-linux-gnu-gcc -c -g -O3 -funroll-loops -S -o testcase.S testcase.i fgrep muls testcase.S muls.l #954437177,%d2:%d2 tg@freewrt:~ $ m68k-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=m68k-linux-gnu-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/m68k-linux-gnu/4.6/lto-wrapper Target: m68k-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-15' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/m68k-linux-gnu/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libssp --enable-plugin --enable-objc-gc --disable-werror --disable-multilib --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=m68k-linux-gnu --program-prefix=m68k-linux-gnu- --includedir=/usr/m68k-linux-gnu/include --with-headers=/usr/m68k-linux-gnu/include --with-libs=/usr/m68k-linux-gnu/lib Thread model: posix gcc version 4.6.3 (Debian 4.6.3-15)
[Bug target/56087] [m68k] gcc miscompiles pari (multiplication)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56087 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added Keywords||wrong-code Target||m68k-linux-gnu Known to work||4.7.2 Host||x86_64-linux-gnu or ||m68k-linux-gnu Known to fail||4.6.3 Build||x86_64-linux-gnu or ||m68k-linux-gnu --- Comment #1 from Thorsten Glaser tg at mirbsd dot org 2013-01-23 20:03:57 UTC --- There it works: root@aranym:~ # gcc-4.7 -c -g -O3 -funroll-loops -S -o testcase.S testcase.i fgrep muls testcase.S muls.l #954437177,%d2:%d5 root@aranym:~ # gcc-4.7 -v Using built-in specs. COLLECT_GCC=gcc-4.7 COLLECT_LTO_WRAPPER=/usr/lib/gcc/m68k-linux-gnu/4.7/lto-wrapper Target: m68k-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libssp --disable-libitm --enable-plugin --enable-objc-gc --disable-werror --disable-multilib --enable-checking=release --build=m68k-linux-gnu --host=m68k-linux-gnu --target=m68k-linux-gnu Thread model: posix gcc version 4.7.2 (Debian 4.7.2-5) Would still be nice to get a patch for 4.6 which is currently the “workhorse” compiler for m68k (lots of use, patches, Ada works, fixes and ports to MiNT).
[Bug target/56087] [m68k] gcc miscompiles pari (multiplication)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56087 --- Comment #3 from Thorsten Glaser tg at mirbsd dot org 2013-01-23 22:15:36 UTC --- tags 698380 + patch fixed-upstream thanks mikpe at it dot uu.se dixit: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56087 Mikael Pettersson mikpe at it dot uu.se changed: --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-01-23 21:15:40 UTC --- (In reply to comment #0) This sounds a lot like PR52573, a patch was proposed in July 2012 and finally approved and committed a few days ago in r195288, see http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00936.html. Thanks Mikael! @GCC developers, in this case sorry for the noise, but you do have a better overview of possible causes. Doko, could you please apply the aforementioned patch in your next upload of gcc-4.6 to unstable? Thanks in advance, //mirabilos
[Bug rtl-optimization/52714] ICE in fixup_reorder_chain, at cfglayout.c:880
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52714 --- Comment #8 from Thorsten Glaser tg at mirbsd dot org 2013-01-07 23:19:01 UTC --- OK, this helped. Wonderful, thanks!
[Bug rtl-optimization/52714] ICE in fixup_reorder_chain, at cfglayout.c:880
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52714 --- Comment #7 from Thorsten Glaser tg at mirbsd dot org 2013-01-05 14:35:37 UTC --- Cool, thanks! I got another one where it fails (centerim) and will test it with this patch, then report back (that should take a few days).
[Bug middle-end/52306] ICE in CSE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #11 from Thorsten Glaser tg at mirbsd dot org 2012-12-24 00:53:01 UTC --- Created attachment 29040 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29040 preprocessed source of festival occurrence Here's another one, from festival (some TTS engine thingy I think). Maybe it's different enough from the others (or similar enough) for someone who knows about this stuff to figure out the root case…
[Bug rtl-optimization/52714] ICE in fixup_reorder_chain, at cfglayout.c:880
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52714 --- Comment #4 from Thorsten Glaser tg at mirbsd dot org 2012-12-09 18:03:08 UTC --- Created attachment 28910 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28910 preprocessed source, xz compressed I ran into this as well, native compilation on Debian/m68k: CC src/proxy-bio-unittest.o gcc -DHAVE_CONFIG_H -I. -g -O1 -Wall -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -fstack-protector-all -fwrapv -fPIE -Wstack-protector --param=ssp-buffer-size=1 -c -o src/proxy-bio-unittest.o src/proxy-bio-unittest.c src/proxy-bio-unittest.c: In function 'need_out_bytes': src/proxy-bio-unittest.c:38:5: warning: stack protector not protecting local variables: variable length buffer [-Wstack-protector] src/proxy-bio-unittest.c:60:1: internal compiler error: in fixup_reorder_chain, at cfglayout.c:877 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions. Preprocessed source stored into /tmp/ccqReOfy.out file, please attach this to your bugreport. make[2]: *** [src/proxy-bio-unittest.o] Error 1 (pbuild3928)root@ara5:/ # gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc-4.6.real COLLECT_LTO_WRAPPER=/usr/lib/gcc/m68k-linux-gnu/4.6/lto-wrapper Target: m68k-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14+m68k.2' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libssp --enable-plugin --enable-objc-gc --disable-werror --disable-multilib --enable-checking=release --build=m68k-linux-gnu --host=m68k-linux-gnu --target=m68k-linux-gnu Thread model: posix gcc version 4.6.3 (Debian 4.6.3-14+m68k.2) That’s from building http://lists.debian.org/debian-devel-changes/2012/12/msg00549.html
[Bug middle-end/52306] ICE in CSE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #5 from Thorsten Glaser tg at mirbsd dot org 2012-12-04 09:26:12 UTC --- Also happens in src:kde4libs (= 4:4.8.4-4) on ../../kdecore/util/kpluginfactory.cpp – I tested -O1, which helped. If there’s any need of _more_ preprocessed source… just shout, but seeing as we’ve got some already… the line is 2158 by now in Debian though, with all the changes. (gcc -O2 -g -fPIC -c x.c on Attachment 27325 still triggers it.) Though, with the three recent patches, my genattrtab time went down from six or so *hours* to two *minutes*, so I have much faster turnaround times now, thanks to Mikael Petterson who backported them ;)
[Bug middle-end/52306] ICE in CSE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #7 from Thorsten Glaser tg at mirbsd dot org 2012-12-04 12:58:35 UTC --- Created attachment 28876 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28876 preprocessed source of second kde4libs occurrence OK. I found another one in the meantime, which I added. It can be triggered thus: ara3:~# gcc -x c++ -g -fPIC -ansi -fno-exceptions -fno-check-new -fno-common -fno-threadsafe-statics -O2 -c kstatusnotifieritem.i ../../kdeui/notifications/kstatusnotifieritem.cpp: In member function 'KDbusImageVector KStatusNotifierItemPrivate::iconToVector(const QIcon)': ../../kdeui/notifications/kstatusnotifieritem.cpp:1037:1: internal compiler error: in cselib_record_set, at cselib.c:2158 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions. Preprocessed source stored into /tmp/cc8gGDaq.out file, please attach this to your bugreport. (I’ve just attached the .i file, they’re virtually identical save for newlines.) The set of compiler options is not minimal, but just -O2 -g -fPIC wasn’t enough. Appending -O1 solves it.
[Bug c/55009] New: compile-time assertions no longer usable: error: variably modified ‘ari_sign_32_bit_and_wrap’ at file scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55009
Bug #: 55009
Summary: compile-time assertions no longer usable: error:
variably modified ‘ari_sign_32_bit_and_wrap’ at file
scope
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t...@mirbsd.org
Hi everyone,
I’ve been using compile-time assertions, that is, compiling .c files with
arrays that are either 1 or -1 bytes long, depending on some assertion, for a
while now, and one of these now no longer works: the check whether a certain
integer type is 32-bit with usable wraparound, as asked for by -fwrapv. (I need
to check this because the program in question is a shell that guarantees this
behaviour to scripts run in it, even for signed integers, and recent GCC
versions are known to optimise the wraparound away, as it’s UD, strictly
spoken, but can be made to work.)
This affects recent gcc-4.6 and gcc-4.7 uploads into Debian and Ubuntu, at
least, as well as gcc trunk:
tg@zigo:~ $ /usr/lib/gcc-snapshot/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20121008-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id
--with-system-zlib --disable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-snap/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-snap
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-snap
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --with-arch-32=i586 --with-tune=generic --disable-werror
--enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.0 20121008 (experimental) [trunk revision 192192] (Debian
20121008-1)
tg@zigo:~ $ cat t.c
#include stdint.h
typedef int32_t mksh_ari_t;
char ari_sign_32_bit_and_wrap[(
(mksh_ari_t)(mksh_ari_t)1 15) 15) - 1) * 2 + 1)
(mksh_ari_t)(mksh_ari_t)1 15) 15) - 1) * 2 + 2)
) ? 1 : -1];
int main(void) { return (sizeof(ari_sign_32_bit_and_wrap)); }
tg@zigo:~ $ if /usr/lib/gcc-snapshot/bin/gcc -O t.c; then ./a.out; echo ok $?;
else echo error $?; fi
t.c:6:62: warning: integer overflow in expression [-Woverflow]
(mksh_ari_t)(mksh_ari_t)1 15) 15) - 1) * 2 + 2)
^
t.c:3:6: error: variably modified 'ari_sign_32_bit_and_wrap' at file scope
char ari_sign_32_bit_and_wrap[(
^
error 1
tg@zigo:~ $ gcc-4.7 -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.7.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-2'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-2)
tg@zigo:~ $ if gcc-4.7 -O t.c; then ./a.out; echo ok $?; else echo error $?; fi
t.c:6:62: warning: integer overflow in expression [-Woverflow]
t.c:3:6: error: variably modified ‘ari_sign_32_bit_and_wrap’ at file scope
error 1
tg@zigo:~ $ gcc-4.6 -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.6.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-10'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls
[Bug middle-end/21161] clobbered by longjmp warning ignores the data flow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161
Thorsten Glaser tg at mirbsd dot org changed:
What|Removed |Added
CC||tg at mirbsd dot org
--- Comment #4 from Thorsten Glaser tg at mirbsd dot org 2012-09-29 22:25:14
UTC ---
Confirmed, happens in mksh now (but not with 4.6 or 4.7), reduced testcase:
tg@zigo:~/b/mksh-40.9.20120630 $ /usr/lib/gcc-snapshot/bin/gcc --version
gcc (Debian 20120915-1) 4.8.0 20120915 (experimental) [trunk revision 191353]
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
tg@zigo:~/b/mksh-40.9.20120630 $ /usr/lib/gcc-snapshot/bin/gcc -O2 -Wextra -c
t.c
t.c: In function 'hereinval':
t.c:12:27: warning: argument 'content' might be clobbered by 'longjmp' or
'vfork' [-Wclobbered]
int hereinval(const char *content, int sub, char **resbuf) {
^
tg@zigo:~/b/mksh-40.9.20120630 $ cat t.c
#include setjmp.h
#include string.h
struct source {
int foo;
const char *str;
} *source = NULL;
jmp_buf jb;
extern char *evalstr(void);
extern struct source *pushs(void);
extern void newenv(void);
extern void quitenv(void);
int hereinval(const char *content, int sub, char **resbuf) {
const char *ccp;
struct source *s, *osource;
osource = source;
newenv();
if (setjmp(jb)) {
source = osource;
quitenv();
return (-2);
}
if (sub) {
s = pushs();
s-str = content;
source = s;
/* ... */
ccp = evalstr();
source = osource;
} else
ccp = content;
*resbuf = strdup(ccp);
return (0);
}
[Bug target/40134] symbols not resolved when building shared libraries (link with -lgcc_s -lgcc?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40134 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #7 from Thorsten Glaser tg at mirbsd dot org 2012-06-24 23:25:53 UTC --- Looks like this is needed for all architectures having such symbols in libgcc.a only – I just backported those for m68k to gcc-4.6 and encountered this issue, which Mikael Pettersson helped to solve.
[Bug target/40134] symbols not resolved when building shared libraries (link with -lgcc_s -lgcc?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40134 --- Comment #8 from Thorsten Glaser tg at mirbsd dot org 2012-06-24 23:27:34 UTC --- Looks like this is needed for all architectures having such symbols in libgcc.a only – I just backported those for m68k to gcc-4.6 and encountered this issue, which Mikael Pettersson helped to solve. Just so anyone who’ll encounter these later knows. (Also, rebuild *all* involved DLLs against the libgcc_s.so linker script, not just libstdc++.)
[Bug regression/52383] [4.6 Regression] miscompiles Perl on m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52383 --- Comment #6 from Thorsten Glaser tg at mirbsd dot org 2012-05-22 12:17:36 UTC --- Hm, I was pretty sure I tracked it down to aranym. But anyway, it’s gone.
[Bug middle-end/52306] ICE in CSE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #3 from Thorsten Glaser tg at mirbsd dot org 2012-05-06 14:16:07 UTC --- Created attachment 27325 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27325 preprocessed source of libxslt occurrence The same thing happens in libxslt-1.1.26 but even with PIC: /bin/bash ../libtool --tag=CC --mode=compile gcc -Wl,--as-needed -DHAVE_CONFIG_H -I. -I../../../libxslt -I.. -I../../.. -I../../../libxslt -I/usr/include/libxml2-g -O2 -Wall -c -o xslt.lo ../../../libxslt/xslt.c libtool: compile: gcc -Wl,--as-needed -DHAVE_CONFIG_H -I. -I../../../libxslt -I.. -I../../.. -I../../../libxslt -I/usr/include/libxml2 -g -O2 -Wall -c ../../../libxslt/xslt.c -fPIC -DPIC -o .libs/xslt.o ../../../libxslt/xslt.c: In function 'xsltParseStylesheetProcess': ../../../libxslt/xslt.c:6464:1: internal compiler error: in cselib_record_set, at cselib.c:2148 In the meantime, we’ve got 4.6.3 in Debian, and all patches recommended by Mikael Patterson are applied: (pbuild11307)root@ara3:~/libxslt-1.1.26/build/main/libxslt # gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/m68k-linux-gnu/4.6/lto-wrapper Target: m68k-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-4+m68k.1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libssp --enable-plugin --enable-objc-gc --disable-werror --disable-multilib --enable-checking=release --build=m68k-linux-gnu --host=m68k-linux-gnu --target=m68k-linux-gnu Thread model: posix gcc version 4.6.3 (Debian 4.6.3-4+m68k.1) Lowering to -O1 allows the file to compile.
[Bug middle-end/52306] ICE in CSE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added Known to fail||4.6.3 --- Comment #4 from Thorsten Glaser tg at mirbsd dot org 2012-05-06 17:04:12 UTC --- Luckily, -Os works in the libxslt case (not in the libvirt case, though), although, from the earlier comments, optimisation is just hiding the bug by changing control flow.
[Bug regression/52383] [4.6 Regression] miscompiles Perl on m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52383 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #4 from Thorsten Glaser tg at mirbsd dot org 2012-04-22 15:41:44 UTC --- Upgrading didn’t help, but in the meantime, I got it built. I blame ARAnyM, as it succeeds on a box I put Petr’s .deb on… so no wonder Andreas couldn’t reproduce it.
[Bug ada/48835] porting GNAT to m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #52 from Thorsten Glaser tg at mirbsd dot org 2012-03-10 00:52:32 UTC --- Mikael’s patches work fine for me, gnat-4.6 (4.6.3-1+m68k.2) has just made its way to debian-ports.org unreleased, chances are it’ll become part of the stock unstable sources soon. Full three-stage bootstrap passes (with assorted GCC bugfix backports applied by Mikael’s suggestion of course), although I did not run the testsuite due to lack of time. Thanks to everyone involved!
[Bug regression/52383] [4.6 Regression] miscompiles Perl on m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52383 --- Comment #3 from Thorsten Glaser tg at mirbsd dot org 2012-03-03 15:50:06 UTC --- Hrm. Building 4.6.3 now, to see whether it goes away.
[Bug rtl-optimization/47612] [4.6 regression] RTL crash when cc0 setter moved away from cc0 user
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #22 from Thorsten Glaser tg at mirbsd dot org 2012-02-27 19:23:11 UTC --- The fix applies as-is to gcc-4.6 with only a fuzz in line offset.
[Bug regression/52383] New: gcc-4.6 regression: miscompiles Perl on m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52383 Bug #: 52383 Summary: gcc-4.6 regression: miscompiles Perl on m68k Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: t...@mirbsd.org Created attachment 26753 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26753 gzip’d tarball with preprocessed source and assembler output Hi, this was originally reported as: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658050 The problem is that Perl misbehaves at runtime due to being miscompiled. It is not reproducible without a native m68k system thus. Sorry about that. I’ve tracked the problem down to one file. The failure mode is (“cc” is gcc-4.6): […] cc -c -DPERL_CORE -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-regmove -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -Wall -W -Wextra -Wdeclaration-after-statement -Wendif-labels -Wc++-compat -Wwrite-strings -fPIC -DPERL_IS_MINIPERL -DPERL_EXTERNAL_GLOB perlmini.c LD_LIBRARY_PATH=/tmp/buildd/perl-5.14.2 cc -fstack-protector -L/usr/local/lib -o miniperl gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o miniperlmain.o opmini.o perlmini.o -ldl -lm -lpthread -lc -lcrypt LD_LIBRARY_PATH=/tmp/buildd/perl-5.14.2 ./miniperl -Ilib make_patchnum.pl Failure yields: Out of memory during list extend at make_patchnum.pl line 126. Success yields one of these (the first only once): Updating 'git_version.h' and 'lib/Config_git.pl' Reusing 'git_version.h' and 'lib/Config_git.pl' I’ve attached the results of the following commands: cc -c -DPERL_CORE -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-regmove -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -Wall -W -Wextra -Wdeclaration-after-statement -Wendif-labels -Wc++-compat -Wwrite-strings -fPIC -DPERL_IS_MINIPERL -DPERL_EXTERNAL_GLOB perlmini.c -E -o perlmini.i gcc-4.6 -S -O1 -fPIC perlmini.i -o perlmini.-O1.s gcc-4.6 -S -O2 -fPIC perlmini.i -o perlmini.-O2.s gcc-4.4 -S -O2 -fPIC perlmini.i -o perlmini.4_4.s The following commands (plus linking and running) will fail: gcc-4.6 -c -O2 -fPIC perlmini.i The following commands (plus linking and running) will succeed: gcc-4.6 -c -O1 -fPIC perlmini.i gcc-4.4 -c -O2 -fPIC perlmini.i So this is an optimisation bug (I think) in gcc-4.6 and a regression from gcc-4.4 (the linking command uses gcc-4.6 in all cases as I’ve not changed it). Naturally, these are not easily diff’able. Version information: gcc-4.6 a.k.a. cc is compiled from Debian 4.6.2-15 sources plus the (second) bugfix from PR47612: Using built-in specs. Target: m68k-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.6-14' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --disable-libssp --enable-objc-gc --disable-werror --disable-multilib --enable-checking=release --build=m68k-linux-gnu --host=m68k-linux-gnu --target=m68k-linux-gnu Thread model: posix gcc version 4.4.6 (Debian 4.4.6-14) gcc-4.4 is compiled from unmodified Debian sid sources: Using built-in specs. Target: m68k-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.6-14' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --disable-libssp --enable-objc-gc --disable-werror --disable-multilib --enable-checking=release --build=m68k-linux-gnu --host=m68k-linux-gnu --target=m68k-linux-gnu Thread model: posix gcc version 4.4.6 (Debian 4.4.6-14) If you need me to copy out any more files from this chroot, or tar it up entirely, or run tests; sure, can be done.
[Bug regression/52383] gcc-4.6 regression: miscompiles Perl on m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52383 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added Keywords||wrong-code Target||m68k-linux-gnu URL||http://bugs.debian.org/cgi- ||bin/bugreport.cgi?bug=65805 ||0 Known to work||4.4.6 Host||m68k-linux-gnu Known to fail||4.6.2 Build||m68k-linux-gnu --- Comment #1 from Thorsten Glaser tg at mirbsd dot org 2012-02-25 22:53:50 UTC --- Sorry, mis-pasted. This is gcc-4.6 -v: Using built-in specs. COLLECT_GCC=gcc-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/m68k-linux-gnu/4.6/lto-wrapper Target: m68k-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.2-15+m68k.1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --disable-libssp --enable-plugin --enable-objc-gc --disable-werror --disable-multilib --enable-checking=release --build=m68k-linux-gnu --host=m68k-linux-gnu --target=m68k-linux-gnu Thread model: posix gcc version 4.6.2 (Debian 4.6.2-15+m68k.1)
[Bug middle-end/52306] New: ICE in CSE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 Bug #: 52306 Summary: ICE in CSE Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: t...@mirbsd.org CC: aol...@gcc.gnu.org, gcc-bugs@gcc.gnu.org, ja...@gcc.gnu.org, li...@gcc.gnu.org, mi...@it.uu.se, seg...@gcc.gnu.org, t...@mirbsd.org Host: x86_64-linux Target: score-elf +++ This bug was initially created as a clone of Bug #43437 +++ I’m also getting one of these. […] Interestingly enough (this is a libtool build), the line with -fPIC -DPIC did not fail. See Mikael’s explanations on #43437 for when/where the bug appears and a reduced testcase.
[Bug target/43437] ICE in CSE, during libgcc build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437 --- Comment #22 from Thorsten Glaser tg at mirbsd dot org 2012-02-18 23:31:40 UTC --- ok, moved it to #52306
[Bug target/43437] ICE in CSE, during libgcc build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437 --- Comment #20 from Thorsten Glaser tg at mirbsd dot org 2012-02-07 21:24:33 UTC --- Just a reminder that the bug (which Mikael kindly begun to analyse) still happens on the 4.6 branch and, as he said it, is most likely only masked on 4.7.
[Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847 --- Comment #4 from Thorsten Glaser tg at mirbsd dot org 2012-01-21 16:04:41 UTC --- Mikael, you are amazing! I’m sort of sorry that I’ve led you to so much effort and fighting against bugs and build system issues. I’ve only ever built gcj with fastjar, even in the gcc 3.4 times on MirBSD. I didn’t even know it could generate a wrapper script… Looking at it, I guess that your zip (Info-ZIP) may be broken, as it merely uses that. Do you still have the jar file that generates an NPE lying around? If so, mail it to me privately, and I can have a look at that when I’m back from vacation.
[Bug target/43437] ICE in CSE, during libgcc build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437 --- Comment #11 from Thorsten Glaser tg at mirbsd dot org 2011-12-18 21:52:43 UTC --- Created attachment 26129 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26129 preprocessed source for another occurence I’m also getting one of these. Not sure if it’s the same issue though. Messages: /tmp/buildd/libvirt-0.9.8/./src/conf/domain_conf.c: In function 'virDomainDefParseXML': /tmp/buildd/libvirt-0.9.8/./src/conf/domain_conf.c:7939:1: internal compiler error: in cselib_record_set, at cselib.c:2148 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions. Preprocessed source stored into /tmp/ccCjFD7F.out file, please attach this to your bugreport. Compile command: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I/tmp/buildd/libvirt-0.9.8/./src -I.. -I/tmp/buildd/libvirt-0.9.8/./gnulib/lib -I../gnulib/lib -I../include -I/tmp/buildd/libvirt-0.9.8/./src/util -I/tmp/buildd/libvirt-0.9.8/./include -DIN_LIBVIRT -I/usr/include/libxml2 -Wall -W -Wformat-y2k -Wformat-security -Winit-self -Wmissing-include-dirs -Wunused -Wunknown-pragmas -Wstrict-aliasing -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wlogical-op -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Winline -Winvalid-pch -Wvolatile-register-var -Wdisabled-optimization -Wbuiltin-macro-redefined -Wmudflap -Wpacked-bitfield-compat -Wsync-nand -Wattributes -Wcoverage-mismatch -Wmultichar -Wcpp -Wdeprecated-declarations -Wdiv-by-zero -Wdouble-promotion -Wendif-labels -Wextra -Wformat-contains-nul -Wformat-extra-args -Wformat-zero-length -Wformat=2 -Wmultichar -Wnormalized=nfc -Woverflow -Wpointer-to-int-cast -Wpragmas -Wsuggest-attribute=const -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure -Wtrampolines -Wno-missing-field-initializers -Wno-sign-compare -Wjump-misses-init -Wno-format-nonliteral -Wframe-larger-than=4096 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-all --param=ssp-buffer-size=4 -fexceptions -fasynchronous-unwind-tables -fdiagnostics-show-option -funit-at-a-time -fipa-pure-const -Wno-suggest-attribute=pure -Wno-suggest-attribute=const -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Wall -c /tmp/buildd/libvirt-0.9.8/./src/conf/domain_conf.c -o libvirt_conf_la-domain_conf.o Compiler used: (pbuild22074)root@ara5:/tmp # gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/m68k-linux-gnu/4.6/lto-wrapper Target: m68k-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.2-7' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --disable-libssp --enable-plugin --enable-objc-gc --disable-werror --disable-multilib --enable-checking=release --build=m68k-linux-gnu --host=m68k-linux-gnu --target=m68k-linux-gnu Thread model: posix gcc version 4.6.2 (Debian 4.6.2-7) Environment: clean cowbuilder chroot of Debian sid (unstable) Linux ara5.mirbsd.org 3.0.0-2-atari #1 Sun Oct 9 00:23:32 UTC 2011 m68k GNU/Linux Interestingly enough (this is a libtool build), the line with -fPIC -DPIC did not fail.
[Bug target/43437] ICE in CSE, during libgcc build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #12 from Thorsten Glaser tg at mirbsd dot org 2011-12-18 22:00:28 UTC --- Indeed. Compiling the file (renamed to x.i) with • gcc -O2 -c x.i ⇒ fails with the same error • gcc -O2 -c -fPIC x.i ⇒ succeeds. Note that -O2 is needed, otherwise it won’t compile at all (apparently some bug when something is not inlined in the original source, didn’t investigate).
[Bug target/43437] ICE in CSE, during libgcc build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437 --- Comment #13 from Thorsten Glaser tg at mirbsd dot org 2011-12-18 22:10:13 UTC --- This is a regression: this works gcc-4.4 -std=gnu99 -DHAVE_CONFIG_H -I. -I/tmp/buildd/libvirt-0.9.8/./src -I.. -I/tmp/buildd/libvirt-0.9.8/./gnulib/lib -I../gnulib/lib -I../include -I/tmp/buildd/libvirt-0.9.8/./src/util -I/tmp/buildd/libvirt-0.9.8/./include -DIN_LIBVIRT -I/usr/include/libxml2 -Wall -W -Wformat-y2k -Wformat-security -Winit-self -Wmissing-include-dirs -Wunused -Wunknown-pragmas -Wstrict-aliasing -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wlogical-op -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Winline -Winvalid-pch -Wvolatile-register-var -Wdisabled-optimization -Wbuiltin-macro-redefined -Wmudflap -Wpacked-bitfield-compat -Wsync-nand -Wattributes -Wcoverage-mismatch -Wmultichar -Wdeprecated-declarations -Wdiv-by-zero -Wendif-labels -Wextra -Wformat-contains-nul -Wformat-extra-args -Wformat-zero-length -Wformat=2 -Wmultichar -Wnormalized=nfc -Woverflow -Wpointer-to-int-cast -Wpragmas -Wno-missing-field-initializers -Wno-sign-compare -Wno-format-nonliteral -Wframe-larger-than=4096 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-all --param=ssp-buffer-size=4 -fexceptions -fasynchronous-unwind-tables -fdiagnostics-show-option -funit-at-a-time -fipa-pure-const -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Wall -c /tmp/buildd/libvirt-0.9.8/./src/conf/domain_conf.c -o libvirt_conf_la-domain_conf.o (same command line with s/^gcc/gcc-4.4/ and a few -W* options removed); the preprocessed source FTB with gcc-4.4 (pbuild22074)root@ara5:~/libvirt-0.9.8/debian/build/src # gcc-4.4 -v Using built-in specs. Target: m68k-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.6-14' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --disable-libssp --enable-objc-gc --disable-werror --disable-multilib --enable-checking=release --build=m68k-linux-gnu --host=m68k-linux-gnu --target=m68k-linux-gnu Thread model: posix gcc version 4.4.6 (Debian 4.4.6-14)
[Bug target/43437] ICE in CSE, during libgcc build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437 --- Comment #15 from Thorsten Glaser tg at mirbsd dot org 2011-12-19 00:28:18 UTC --- Hi Mikael, thanks for caring, you seem to be everywhere ;-) Yes, it is reproducible with the cross-compilers I build using the standard procedure from https://wiki.debian.org/BuildingCrossCompilers on amd64. tg@zigo:~ $ m68k-linux-gnu-gcc-4.6 -O2 -c x.i /tmp/buildd/libvirt-0.9.8/./src/conf/domain_conf.c: In function ‘virDomainDefParseXML’: /tmp/buildd/libvirt-0.9.8/./src/conf/domain_conf.c:7939:1: internal compiler error: in cselib_record_set, at cselib.c:2148 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions. Preprocessed source stored into /tmp/cckdrq16.out file, please attach this to your bugreport. 1|tg@zigo:~ $ m68k-linux-gnu-gcc-4.6 -v Using built-in specs. COLLECT_GCC=m68k-linux-gnu-gcc-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/m68k-linux-gnu/4.6/lto-wrapper Target: m68k-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.2-7' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/m68k-linux-gnu/include/c++/4.6.2 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --disable-libssp --enable-plugin --enable-objc-gc --disable-werror --disable-multilib --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=m68k-linux-gnu --program-prefix=m68k-linux-gnu- --includedir=/usr/m68k-linux-gnu/include --with-headers=/usr/m68k-linux-gnu/include --with-libs=/usr/m68k-linux-gnu/lib Thread model: posix gcc version 4.6.2 (Debian 4.6.2-7)
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #39 from Thorsten Glaser tg at mirbsd dot org 2011-10-17 20:29:52 UTC --- (In reply to comment #38) (In reply to comment #36) few m68k or HAVE_cc0 patches from 4.7 (pr43804, pr47612/pr48554, pr47955, Do you think those could help with the gcj-4.6 showstopper, too? cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847 I checked, they didn't; with them on top of 4.6.1 I got a SEGV while compiling Random.java just like PR49847 described. Yes, same here (just today I got the result…). Damn, no such luck :| My next step wrt GNAT/m68k is to bisect the 4.5-4.6 changes to see what broke GNAT/m68k in the first place. OK. I’m personally not happy with the s-memory.adb changes. It basically replaces “we have an Ada function returning System.Address and expose that to C” with “we have an Ada function returning System.Address, write a wrapper that unchecked-converts the result to Char_Ptr, and expose that to C”. This does not scale. This will require patching any and all third-party Ada source code which exposes functions to C (that return pointers). Those people will think it pointless, not listen (“who cares about m68k”), or not do it because only a certain checksum-controlled source code is qualified for $thing. I’d rather see the System.Address type being made a C pointer type, globally, in the first place. Since I don’t speak Ada, I can’t do it “the right way”. But what prevents us from changing Char_Ptr in + type Char_Ptr is access all Character; + pragma Convention (C, Char_Ptr); + pragma No_Strict_Aliasing (Char_Ptr); to System.Address, replacing the previous “opaque” definition?
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #36 from Thorsten Glaser tg at mirbsd dot org 2011-10-14 08:39:06 UTC --- With this patch, a trivial forward-port of the gcc-4.5.3 Ada/m68k patch, and a … r178834) I was finally able to successfully bootstrap Ada on m68k-linux. I'll test this patch on more archs over the next couple of days, then if no regressions appeared I'll submit it to gcc-patches. Thanks, greatly appreciated! few m68k or HAVE_cc0 patches from 4.7 (pr43804, pr47612/pr48554, pr47955, Do you think those could help with the gcj-4.6 showstopper, too? cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #30 from Thorsten Glaser tg at mirbsd dot org 2011-09-10 13:11:16 UTC --- (In reply to comment #29) After a lengthy bisection process, I've now finally identified r171341 http://gcc.gnu.org/ml/gcc-cvs/2011-03/msg00765.html as the critical change that unbroke GNAT/m68k on trunk. r171341 mixes cleanups with bugfixes, and is Wow, kudos for the work! You’re doing great! far too big to backport as-is to 4.6, so I'm now trying to split it up to identify a minimal bugfix-only fragment that unbreaks GNAT/m68k. That’s nice, Debian apparently switched to GNAT 4.6 for Wheezy.
[Bug java/49847] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added Severity|normal |critical --- Comment #1 from Thorsten Glaser tg at mirbsd dot org 2011-09-03 19:32:10 UTC --- Raising importance; this bug prevents 4.6 from being switched to in Debian.
[Bug target/47908] attribute((optimize(2))) causes ICE in m68k_sched_issue_rate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47908 --- Comment #6 from Thorsten Glaser tg at mirbsd dot org 2011-07-27 23:29:13 UTC --- Mikael, can you please publish your “fully tested patches to fix this for 4.4.5, 4.5.2, and 4.6.0” so we can at least include this in the packages? If the FSF itself (i.e. gnulib) starts using those pragmas which cause this ICE, I think we’re going to see more and more popping up; I could convince the maintainer of libvirt to include the m68k workaround in his package (compile with -DWRAPV -fwrapv) but that doesn’t really scale. Without the copyright assignment (WTF is going on there, mine took about three weeks!) it’s still distributable under GPL, just with you as author. Thanks!
[Bug target/49856] New: ICE when compiling mktime.c (gnulib, embedded in libvirt)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49856
Summary: ICE when compiling mktime.c (gnulib, embedded in
libvirt)
Product: gcc
Version: 4.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t...@mirbsd.org
Created attachment 24836
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24836
preprocessed source exhibiting the problem
tg@zigo:~ $ m68k-linux-gnu-gcc -O2 -c y.i
y.i: In function ‘ranged_convert’:
y.i:632: internal compiler error: in m68k_sched_issue_rate, at
config/m68k/m68k.c:5877
Please submit a full bug report,
with preprocessed source if appropriate.
tg@zigo:~ $ gdb --args /home/tg/Xg/gcc-4.4-4.4.6/build/gcc/cc1 -fpreprocessed
y.i -m68020 -O2 -o y.s
(gdb) b fancy_abort
Breakpoint 1 at 0x4c1850: file ../../src/gcc/diagnostic.c, line 711.
(gdb) frame 1
#1 0x00754f2d in m68k_sched_issue_rate () at
../../src/gcc/config/m68k/m68k.c:5877
5877 gcc_unreachable ();
(gdb) list m68k_sched_issue_rate
5860}
5861
5862/* Return maximal number of insns that can be scheduled on a single
cycle. */
5863static int
5864m68k_sched_issue_rate (void)
5865{
5866 switch (m68k_sched_cpu)
5867{
5868case CPU_CFV1:
5869case CPU_CFV2:
(gdb)
5870case CPU_CFV3:
5871 return 1;
5872
5873case CPU_CFV4:
5874 return 2;
5875
5876default:
5877 gcc_unreachable ();
5878 return 0;
5879}
(gdb) print m68k_sched_cpu
$1 = CPU_UNKNOWN
[Bug target/49856] ICE when compiling mktime.c (gnulib, embedded in libvirt)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49856 --- Comment #1 from Thorsten Glaser tg at mirbsd dot org 2011-07-26 20:04:49 UTC --- Also applies to 4.6.1-4: root@ara5:~ # /usr/lib/m68k-linux-gnu/gcc/m68k-linux-gnu/4.6.1/cc1 -fpreprocessed y.i -m68020 -O2 -o y.s __strcspn_c1 __strcspn_c2 __strcspn_c3 __strspn_c1 __strspn_c2 __strspn_c3 __strpbrk_c2 __strpbrk_c3 __strtok_r_1c __strsep_1c __strsep_2c __strsep_3c leapyear isdst_differ ydhms_diff time_t_avg time_t_add_ok time_t_int_add_ok guess_time_tm ranged_convert mktime_internal rpl_mktime Analyzing compilation unit Performing interprocedural optimizations *free_lang_data visibility early_local_cleanups whole-program ipa-profile cp inline pure-const static-varAssembling functions: ranged_convert y.i: In function ‘ranged_convert’: y.i:632:1: internal compiler error: in m68k_sched_issue_rate, at config/m68k/m68k.c:6055 Please submit a full bug report,
[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804 --- Comment #26 from Thorsten Glaser tg at mirbsd dot org 2011-07-26 20:16:22 UTC --- Both gcc-4.4 and gcc-4.6 with that patch applied compile memtest.i properly.
[Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847 Summary: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassig...@gcc.gnu.org ReportedBy: t...@mirbsd.org Forwarding from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633754 Trying to bootstrap gcj-4.6 on Debian/m68k (gcj-4.4 and gcc-4.6 work fine). Reproducible ICE trying to build the runtime library, after bootstrapping passed: /bin/bash ./libtool --tag=GCJ --mode=compile /tmp/buildd/gcj-4.6-4.6.1/build/./gcc/gcj -B/tmp/buildd/gcj-4.6-4.6.1/build/m68k-linux-gnu/m68040/libjava/ -B/tmp/buildd/gcj-4.6-4.6.1/build/m68k-linux-gnu/m68040/libjava/ -B/tmp/buildd/gcj-4.6-4.6.1/build/./gcc/ -B/usr/m68k-linux-gnu/bin/ -B/usr/m68k-linux-gnu/lib/ -isystem /usr/m68k-linux-gnu/include -isystem /usr/m68k-linux-gnu/sys-include -m68040 -fclasspath= -fbootclasspath=../../../../src/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -m68040 -c -o java/util.lo -fsource-filename=/tmp/buildd/gcj-4.6-4.6.1/build/m68k-linux-gnu/m68040/libjava/classpath/lib/classes -MT java/util.lo -MD -MP -MF java/util.deps @java/util.list /tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/Random.java:427:0: internal compiler error: Segmentation fault This is still a cc0 architecture, as the problem is: Program received signal SIGSEGV, Segmentation fault. equiv_constant (x=0x0) at ../../src/gcc/cse.c:3812 3812 if (REG_P (x) (gdb) bt #0 equiv_constant (x=0x0) at ../../src/gcc/cse.c:3812 #1 0x804b0542 in fold_rtx (x=0xc83cb5f4, insn=0xc83cc1c0) at ../../src/gcc/cse.c:3274 #2 0x804b05fe in fold_rtx (x=0xc83c4f30, insn=0xc83cc1c0) at ../../src/gcc/cse.c:3279 #3 0x804b35ec in cse_insn (insn=0xc83cc1c0) at ../../src/gcc/cse.c:4511 […] (gdb) frame 1 #1 0x804b0542 in fold_rtx (x=0xc83cb5f4, insn=0xc83cc1c0) at ../../src/gcc/cse.c:3274 3274const_arg = equiv_constant (folded_arg); (gdb) list 3269 3270#ifdef HAVE_cc0 3271 case CC0: 3272folded_arg = prev_insn_cc0; 3273mode_arg = prev_insn_cc0_mode; 3274const_arg = equiv_constant (folded_arg); 3275break; 3276#endif 3277 3278 default: (gdb) print folded_arg $1 = (rtx) 0x0 (gdb) print prev_insn_cc0 $2 = (rtx) 0x0 (gdb) print prev_insn_cc0_mode $3 = VOIDmode More information in the linked bug report.
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #20 from Thorsten Glaser tg at mirbsd dot org 2011-07-11 22:52:04 UTC --- Have you applied the patch I attached to this bugreport before? The sections in Makefile.in are actually target specific, and my patch added one for m68k-linux as: +ifeq ($(strip $(filter-out m68k% linux%,$(arch) $(osys))),) I’m fairly certain it did pick these when I built it.
[Bug tree-optimization/49618] When building uClibc with GCC 4.6.1 old_atexit is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49618 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #1 from Thorsten Glaser tg at mirbsd dot org 2011-07-03 14:58:47 UTC --- Ouch. I can see where it might be NULL… but in anal-C99 taking a pointer of an object (__dso_handle) can never be a NULL pointer, so GCC might, in a very theoretical sense, be correct in optimising away this check. Does adding -fno-delete-null-pointer-checks to the compile options help?
[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804 --- Comment #25 from Thorsten Glaser tg at mirbsd dot org 2011-07-01 19:36:06 UTC --- Applied the diff from svn r172920 to the Debian gcc-4.6 source package as well; let’s see whether this works.
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #12 from Thorsten Glaser tg at mirbsd dot org 2011-06-14 10:59:03 UTC --- Why not patch the frontend to magically make System.Address a pointer type for the backend to deal with? That way, no functions have to be changed, and potential other targets with “weird” calling conventions immediately share in the benefit. As for the “compatibility trick”, it works the other way around, only when a pointer-returning function is called expecting integers. Here, we have an integer-returning function by mistake.
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #7 from Thorsten Glaser tg at mirbsd dot org 2011-06-10 20:54:58 UTC --- OK, so the fix is that the System.Address type must be changed in GNAT to be handled as pointer in the GCC middle-/back-end. Is any GCC/GNAT developer please working on this?
[Bug ada/37109] can't canadian cross ada (if host=target, but host!=build)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37109 --- Comment #8 from Thorsten Glaser tg at mirbsd dot org 2011-04-30 13:36:17 UTC --- (In reply to comment #7) manually. The more serious problem I found is that the final gnat executables segfault on the m68k target. Even with no argument, yes. It’s in: hostparm.ads: Normalized_CWD : constant String := . Direct_Separator; This in end calls memcpy with a length of about 2 GiB. I had thought this to be an issue of bootstrapping from amd64, which platform did you use?
[Bug ada/37109] can't canadian cross ada (if host=target, but host!=build)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37109 --- Comment #10 from Thorsten Glaser tg at mirbsd dot org 2011-04-30 13:56:23 UTC --- (In reply to comment #9) (In reply to comment #8) to be an issue of bootstrapping from amd64, which platform did you use? i686-linux. Ok, then I can continue with trying from amd64. *THANKS*! That saves me quite a lot of additional effort for nothing. At a first glance, there’s a lot of system-linux-*.ads but none for m68k. Should I have a look in that area, or is that not an issue at all? (I know almost nothing about Ada, except it’s written with a capital A, like Lovelace.)
[Bug ada/37109] can't canadian cross ada (if host=target, but host!=build)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37109 --- Comment #12 from Thorsten Glaser tg at mirbsd dot org 2011-04-30 15:20:08 UTC --- (In reply to comment #11) It will be an issue, but I got the segfaults even with such a file, so I think the problem is more fundamental than that. OK, I’ll try. What you should do is make system-linux-m68k.ads a clone of e.g. I’ve cloned system.ads and made changes while looking at i386, mipseb, armeb and macppc – let’s see how it goes from there. system-linux-ppc.ads (both big-endian 32-bitters), set the ZCX variables to false, and disable stack check probes. Then update gcc-interface/Makefile.in with a case that matches m68k-linux and does what other linux targets do, but selecting system-linux-m68k.ads and setting EH_MECHANISM= (the empty string). This enables SJLJ EH which is simpler and adequate for initial bootstrap. Once gnat works on m68k you can try enabling ZCX EH (which will need dwarf2 unwinding). Will do if that fails. Thanks for the ideas. (I can't post a patch due to delays at the FSF wrt my employer's disclaimer.) That’s luckily no problem for me, I have papers with the FSF standing, even explicitly for GCC already.
[Bug ada/37109] can't canadian cross ada (if host=target, but host!=build)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37109 --- Comment #13 from Thorsten Glaser tg at mirbsd dot org 2011-04-30 15:31:06 UTC --- Ah well. I found out that Ada doesn’t compile if you have a style error õÕ and that “make clean” doesn’t clean all stampfiles… got a crosscompiler now, let’s see whether it can cross-build a native compiler and that then works. Should we open up another bugreport for _that_ (port GNAT to GNU/Linux/m68k) though, since it doesn’t really belong here?
[Bug ada/48835] New: Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 Summary: Porting GNAT to GNU/Linux/m68k Product: gcc Version: 4.4.6 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: t...@mirbsd.org Created attachment 24151 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24151 first draft Discussion about attempting to port GNAT to GNU/Linux/m68k. I’ve come this far: root@ara5:...mnt/home/tg/Xg/gcc-4.4-4.4.6/b68k/gcc # gdb ./gnat1 GNU gdb (GDB) 7.2-debian Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as m68k-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /mnt/home/tg/Xg/gcc-4.4-4.4.6/b68k/gcc/gnat1...done. warning: not using untrusted file .gdbinit (gdb) r Starting program: /mnt/home/tg/Xg/gcc-4.4-4.4.6/b68k/gcc/gnat1 #NO_APP .file stdin Program received signal SIGSEGV, Segmentation fault. 0xc014d428 in memcpy (dstpp=0x8018668a, srcpp=0x80a2688e, len=2149082762) at memcpy.c:61 61 memcpy.c: No such file or directory. in memcpy.c (gdb) bt #0 0xc014d428 in memcpy (dstpp=0x8018668a, srcpp=0x80a2688e, len=2149082762) at memcpy.c:61 #1 0x80137084 in hostparm___elabs () at ../../src/gcc/ada/hostparm.ads:54 #2 0x800049cc in adainit () at ada/b_gnat1.c:317 #3 0x80015a3a in gnat_parse_file (set_yydebug=0) at ../../src/gcc/ada/gcc-interface/misc.c:198 #4 0x80459e62 in compile_file (argc=1, argv=0xefe5dc24) at ../../src/gcc/toplev.c:970 #5 do_compile (argc=1, argv=0xefe5dc24) at ../../src/gcc/toplev.c:2197 #6 toplev_main (argc=1, argv=0xefe5dc24) at ../../src/gcc/toplev.c:2229 #7 0xc00fae68 in __libc_start_main (main=0x802a29e4 main, argc=1, ubp_av=0xefe5dc24, init=0x806dadd0 __libc_csu_init, fini=0x806dadc8 __libc_csu_fini, rtld_fini=0xc000d320 _dl_fini, stack_end=0xefe5dc24) at libc-start.c:228 #8 0x80003a6e in _start () (gdb) frame 1 #1 0x80137084 in hostparm___elabs () at ../../src/gcc/ada/hostparm.ads:54 54 Normalized_CWD : constant String := . Direct_Separator; (gdb) disas Dump of assembler code for function hostparm___elabs: 0x80136ef0 +0: linkw %fp,#0 0x80136ef4 +4: moveml %d2-%d7,%sp@- 0x80136ef8 +8: movel 0x806db078 __gnat_vmsp,%d0 0x80136efe +14:sne %d0 0x80136f00 +16:negb %d0 0x80136f02 +18:moveb %d0,0x807eff68 hostparm__openvms 0x80136f08 +24:moveb 0x807ab130 __gnat_dir_separator,%d2 0x80136f0e +30:movel #-2140172272,%d0 0x80136f14 +36:movel #-2140172268,%d1 0x80136f1a +42:andil #255,%d2 0x80136f20 +48:movel %d2,%sp@- 0x80136f22 +50:movel %d1,%sp@- 0x80136f24 +52:movel %d0,%sp@- 0x80136f26 +54:jsr 0x80187a8a system__string_ops__str_concat_sc […] See how %d0 and %d1 (arguments to System.String_Ops.Str_Concat) have immense sizes. I don’t know the Ada calling conventions though, and three things are pushed, yet . is a one-byte string, and Direct_Separator is only a char. This matches the “len” argument to memcpy. (gdb) info r d0 0x1 1 d1 0xf 15 d2 0x8018668a -2145884534 d3 0xf 15 d4 0x1c 28 d5 0x1 1 d6 0x1 1 d7 0x1 1 a0 0x8018668a 0x8018668a a1 0x80a2688f 0x80a2688f a2 0x0 0x0 a3 0x802f3094 0x802f3094 a4 0x8000319c 0x8000319c a5 0xc0202000 0xc0202000 fp 0xefe5dadc 0xefe5dadc sp 0xefe5dab4 0xefe5dab4 ps 0x300[ I0 I1 ] pc 0x80137084 0x80137084 hostparm___elabs+404 fpcontrol 0x0 0 fpstatus 0x0 0 fpiaddr0x0 0 I’m attaching my current patch (I have copyright assignments standing), although the result is currently the same with the patch not applied. My baseline is Debian gcc-4.4 (4.4.6-2), since that contains all needed backports for working C, C++ and GCJ on m68k.
[Bug ada/37109] can't canadian cross ada (if host=target, but host!=build)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37109 --- Comment #15 from Thorsten Glaser tg at mirbsd dot org 2011-04-30 15:48:47 UTC --- (In reply to comment #14) (In reply to comment #13) Should we open up another bugreport for _that_ (port GNAT to GNU/Linux/m68k) though, since it doesn’t really belong here? Yes. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added Host|m68k-linux | --- Comment #3 from Thorsten Glaser tg at mirbsd dot org 2011-04-30 22:16:10 UTC --- Actually, the backtrace is bogus. The problem lies here: hostparm___elabs: .LFB0: .file 1 ../../src/gcc/ada/hostparm.ads […] move.l %d0,hostparm__Tnormalized_cwdS___SIZE_A_UNIT move.l %d0,-(%sp) .cfi_escape 0x2e,0x4 jsr __gnat_malloc move.l %a0,%d2 move.l hostparm__Tnormalized_cwdS___SIZE_A_UNIT,-(%sp) move.l hostparm__R6s,-(%sp) 0x8013707c move.l %a0,-(%sp) .cfi_escape 0x2e,0xc 0x8013707e jsr memcpy 0x80137084 move.l %d2,hostparm__normalized_cwd lea (16,%sp),%sp .loc 1 38 0 movem.l -24(%fp),#252 unlk %fp rts .cfi_endproc The call to memcpy above SIGSEGVs. Upon entering memcpy@plt, the stack looks as follows: 0xefcdaab0: 0x80137084 0x8018668a 0x80a2688e 0x0002 ret addrdst src len (gdb) x 0x80a2688e 0x80a2688e system__secondary_stack__chunk+24: 0x2e2f (gdb) x 0x8018668a 0x8018668a system__soft_links__abort_undefer_nt: 0x4e56 tg@zigo:~/Xg/gcc-4.4-4.4.6/b68k $ nm gcc/gnat1 | fgrep -we system__secondary_stack__chunk -e system__soft_links 80a26876 b system__secondary_stack__chunk 8018668a T system__soft_links__abort_undefer_nt So basically, this tries to overwrite space at T (.text segment). __gnat_malloc is apparently assumed to return in a0… … grepping gives: ada/socket.c:extern void *__gnat_malloc32 (__SIZE_TYPE__); ada/raise.h:extern void *__gnat_malloc (__SIZE_TYPE__); ada/i-cstrin.adb: pragma Import (C, Memory_Alloc, __gnat_malloc); ada/s-memory.ads: pragma Export (C, Alloc, __gnat_malloc); I believe we may have our culprit, considering m68k return value locations. Phew!
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #4 from Thorsten Glaser tg at mirbsd dot org 2011-04-30 22:17:36 UTC --- (In reply to comment #2) apparently not treated as a pointer, thus the value is returned in %d0. But the caller expects the returned value in %a0. Ah, I see. We both got the same guess then, which makes me kind of happy to see that the analysis seems good. I lost quite some time tracking down my first error though (even annotating EVERY line of a disassembly with what it does), only to find out it now segfaulted later… ☺
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835
--- Comment #5 from Thorsten Glaser tg at mirbsd dot org 2011-04-30 22:28:03
UTC ---
(In reply to comment #2)
the caller expects the returned value in %a0.
It’s even worse, __gnat_malloc contains:
jsr malloc
addq.l #4,%sp
move.l %d0,-8(%fp)
Apparently, the Ada functions that are {Im,Ex}port’ed all assume
they get their values in d0 not a0…
I wonder if this is a conceptual problem preventing Ada to work
with the m68k ELF ABI. How does vxworks/m68k (which, apparently,
has a GNAT port) manage it? (Even if we “fix” the Export, the
Import of libc malloc will still fail… would this work if some
types were handled specially (like System.Address)? I wonder how
many third-party programmes would break on m68k when they have C
imports with uncleanly specified types then…)
[Bug ada/37109] can't canadian cross ada (if host=target, but host!=build)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37109
Thorsten Glaser tg at mirbsd dot org changed:
What|Removed |Added
CC||tg at mirbsd dot org
--- Comment #4 from Thorsten Glaser tg at mirbsd dot org 2011-04-29 23:00:59
UTC ---
Confirmed for gcc-4.4 (4.4.6-2)
[…]
/opt/crossada/bin/m68k-linux-gnu-gcc -c -g -O2 -gnatpg -gnata -gnatwns
-nostdinc -I- -I. -Iada -I../../src/gcc/a
da -I../../src/gcc/ada/gcc-interface ../../src/gcc/ada/butil.adb -o ada/butil.o
/opt/crossada/bin/m68k-linux-gnu-gcc -c -g -O2 -gnatpg -gnata -gnatwns
-nostdinc -I- -I. -Iada -I../../src/gcc/a
da -I../../src/gcc/ada/gcc-interface ../../src/gcc/ada/casing.adb -o
ada/casing.o
mkdir -p ada/bldtools/nmake_b
rm -f ada/bldtools/nmake_b/sinfo.ads ada/bldtools/nmake_b/nmake.adt
ada/bldtools/nmake_b/xnmake.adb ada/bldtools/
nmake_b/xutil.ads ada/bldtools/nmake_b/xutil.adb
cp -p ../../src/gcc/ada/sinfo.ads ../../src/gcc/ada/nmake.adt
../../src/gcc/ada/xnmake.adb ../../src/gcc/ada/xuti
l.ads ../../src/gcc/ada/xutil.adb ada/bldtools/nmake_b
(cd ada/bldtools/nmake_b m68k-linux-gnu-gnatmake -q xnmake ./xnmake -b
../../nmake.adb )
./xnmake[1]: syntax error: '(' unexpected
make[2]: *** [ada/nmake.adb] Error 1
make[2]: Leaving directory `/home/tg/Xg/gcc-4.4-4.4.6/b68k/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/tg/Xg/gcc-4.4-4.4.6/b68k'
make: *** [all] Error 2
[Bug ada/37109] can't canadian cross ada (if host=target, but host!=build)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37109 --- Comment #5 from Thorsten Glaser tg at mirbsd dot org 2011-04-29 23:09:28 UTC --- Confirmed for gcc-4.4 (4.4.6-2) Building from Debian/amd64 by the way. Workaround is: copy/paste the failing command line into another shell, then edit it (remove the m68k-linux-gnu-) and run it, then re-run make: 1|tg@zigo:~/Xg/gcc-4.4-4.4.6/b68k/gcc $ (cd ada/bldtools/nmake_s gnatmake -q xnmake ./xnmake -s ../../nma x-gnu-gnatmake -q xtreeprs ./xtreeprs ../../treeprs.ads ) /bin/mksh: ./xtreeprs: not executable: magic 7F45 1|tg@zigo:~/Xg/gcc-4.4-4.4.6/b68k/gcc $ (cd ada/bldtools/treeprs gnatmake -q xtreeprs ./xtreeprs ../../tr
[Bug ada/37109] can't canadian cross ada (if host=target, but host!=build)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37109 --- Comment #6 from Thorsten Glaser tg at mirbsd dot org 2011-04-29 23:41:11 UTC --- I also believe this in gnattools/Makefile (generated) to be wrong: # For cross builds of gnattools, # put the host RTS dir first in the PATH to hide the default runtime # files that are among the sources # FIXME: This should be done in configure. RTS_DIR:=$(strip $(subst \,/,$(shell gnatls -v | grep adalib ))) gnattools-cross: $(GCC_DIR)/stamp-tools See how it calls gnatls to find out the path to adalib, even though it’s cross-compiling? From amd64 to m68k (LP64 → ILP32), this produces errors later on; changing gnatls to m68k-linux-gnu-gnatls fixes them.
[Bug tree-optimization/47677] [4.6 Regression] Hang in VRP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47677 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #5 from Thorsten Glaser tg at mirbsd dot org 2011-02-10 17:57:31 UTC --- Wow, that was quick, thanks. (I think mksh ought to become a compiler testcase… found a lot of bugs in pcc, one in SUNWcc, and a few in gcc, including when -fwhole-program --combine – now gone – broke twice.)
[Bug c/47533] New: [m68k] stack corruption with -Os (probably due to tail call optimisation)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47533
Summary: [m68k] stack corruption with -Os (probably due to tail
call optimisation)
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t...@mirbsd.org
I just discovered a stack corruption in klibc in m68k and tracked it down to
this reduced testcase. When using -O2 or -Os, the problem happens. The
component may be wrong, but I don’t know the correct one to use (backend?
*-optimisation? target?) so please reassign. I didn’t choose target because
this _might_ happen on !m68k too (I don’t know, but if so, it’s a major
problem).
GNU C (Debian 4.4.5-10) version 4.4.5 (m68k-linux-gnu)
compiled by GNU C version 4.4.5, GMP version 4.3.2, MPFR version
3.0.0-p3.
root@ara2:~ # gcc tst1.S tst2.c -Os
root@ara2:~ # ./a.out
want: C010
got1: C010
syscall with 1, 258, 16 reached
got2: 0010
The problem appears to be this:
8448 baz:
8448: 4e56 linkw %fp,#0
844c: 4280clrl %d0
844e: 302e 0012 movew %fp@(18),%d0
8452: 2d40 0010 movel %d0,%fp@(16)
8456: 006e 0100 000e oriw #256,%fp@(14)
845c: 4e5eunlk %fp
845e: 60ff ffb0 bral 8410 __baz
This basically does the equivalent of:
return __baz(a, b | 0x100, (int)(c 0x));
However, c actually wasn’t passed (pushed onto the stack) and is in the
caller’s frame a local variable…
The issue comes from the C library function open(int, int, short) which calls
the syscall __open(int, int | O_LARGEFILE, short) and argument promotion. I
think when doing tail call optimisation, the calling function’s stack should
not be touched. The problem is: baz(int, int, short) takes 3 arguments, but
_can_ be called with two arguments only (how many people use the 3-argument
form of open() unless it’s for O_CREAT anyway?).
Here’s the testcase – the caller is an assembly function, to display the
problem. I don’t “really” speak m68k assembly, only i8086/i386, so feel free to
direct stylistic flames to me, I’m just teaching this myself as I go along. (No
preprocessed source because cpp doesn’t even touch the two files, I think.)
root@ara2:~ # cat tst1.S
.text
.globl foo
.type foo, @function
foo:
/* create a stack frame, reserve 4 bytes for local variables */
linkw %fp, #-4
/* imagine we have locvarname = func() == 0xC010 */
move.l #0xC010, %d0
move.l %d0, -4(%fp)
/* here is the point where foo and bar differ */
/* now return this value from locvarname */
move.l -4(%fp), %d0
unlk%fp
rts
.size foo, . - foo
.globl bar
.type bar, @function
bar:
/* create a stack frame, reserve 4 bytes for local variables */
linkw %fp, #-4
/* imagine we have locvarname = func() == 0xC010 */
move.l #0xC010, %d0
move.l %d0, -4(%fp)
/* now call baz(1, 2) */
move.l #2, %d1
move.l %d1, -(%sp)
move.l #1, %d1
move.l %d1, -(%sp)
jsr baz
add.l #8, %sp
/* now return this value from locvarname */
move.l -4(%fp), %d0
unlk%fp
rts
.size bar, . - bar
root@ara2:~ # cat tst2.c
extern int printf(const char *, ...);
extern unsigned int foo(void);
extern unsigned int bar(void);
/* imagine open() here */
int __baz(int, int, unsigned short) __attribute__((noinline));
int baz(int, int, unsigned short) __attribute__((noinline));
int
main(void)
{
unsigned int i;
i = foo();
printf(want: C010\ngot1: %08X\n, i);
i = bar();
printf(got2: %08X\n, i);
return (0);
}
int
__baz(int a, int b, unsigned short c)
{
printf(syscall with %d, %d, %d reached\n, a, b, c);
return (a + b + c);
}
int
baz(int a, int b, unsigned short c)
{
/* imagine O_LARGEFILE here */
return (__baz(a, b | 0x100, c));
}
[Bug c/47533] [m68k] stack corruption with -Os (probably due to tail call optimisation)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47533
--- Comment #3 from Thorsten Glaser tg at mirbsd dot org 2011-01-29 17:39:42
UTC ---
You don't really say what the error is. Is it that the number after got2
differs from the one after got1?
Yes, it’s a local variable of foo() and bar() and thus not supposed to be
overwritten by baz()
Can you rewrite the test case so that it does
a runtime check and an exit(1) or similar if the error is detected?
Sure. But…
Looking in klibc-1.5.21 I see that the published prototype for open() is:
__extern int open(const char *, int, ...);
This looks fine, but the actual definition (which deliberately doesn't see the
above prototype) is:
int open(const char *pathname, int flags, mode_t mode)
{ ... }
This is invalid C, and very sloppy programming.
… if this is the case (is it? I seem to think *everyone* handles open()
this way), then it’s not a bug in gcc (I think) but in klibc.
[Bug c/47533] [m68k] stack corruption with -Os (probably due to tail call optimisation)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47533 --- Comment #4 from Thorsten Glaser tg at mirbsd dot org 2011-01-29 17:53:19 UTC --- I see, now, from the patch. Thanks, will try that. Is it okay with you to submit this to klibc, if it works?
[Bug c/47533] [m68k] stack corruption with -Os (probably due to tail call optimisation)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47533 --- Comment #5 from Thorsten Glaser tg at mirbsd dot org 2011-01-29 18:05:47 UTC --- Created attachment 23164 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23164 Mikael’s patch, against klibc git I converted your patch to one against klibc git. I’m building it right now; will test it then.
[Bug c/47533] [m68k] stack corruption with -Os (probably due to tail call optimisation)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47533 --- Comment #8 from Thorsten Glaser tg at mirbsd dot org 2011-01-29 18:51:23 UTC --- OK, the patch fixes the problem indeed. Thanks! (Sorry for the noise, too.)
[Bug web/47306] Wrong name of a programming language used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47306 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Comment #3 from Thorsten Glaser tg at mirbsd dot org 2011-01-21 22:40:40 UTC --- This doesn’t change the fact that it’s not _right_ for Google to do that. I’ve read the term “steamrolling” in Issue 9 later and find it fitting. I also think that someone working for Google should not be able to close this bug as WONTFIX due to a conflict of interests. Call it Google-Go or World of… well, taken. Or Issue 9. The compiler frontend probably can stay named gccgo.
[Bug web/47306] New: Wrong name of a programming language used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47306 Summary: Wrong name of a programming language used Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: t...@mirbsd.org Hi, both http://gcc.gnu.org/gcc-4.6/changes.html and today’s http://gcc.gnu.org/index.html#news pretend GCC has gained support for the Go programming lan- guage, whereas it has only gained support for the Google-Go programming language instead, according to what I read. Please see (I hate to point to Wikipedia, but that’s illustrating the problem) the information at http://en.wikipedia.org/wiki/Go!_(programming_language) and correct the attribution. The Go language not in GCC has been around far longer and as such earlier naming rights, and it’s wrong for the FSF / GCC-SC to follow a vendor’s attempt of this hostile takeover. Thanks in advance!
