[Bug c/68524] Please support attributes between function definition and opening brace

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68524 Thorsten Glaser changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #5

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #25 from Thorsten Glaser --- Good as I can tell, __valgrind is always 1, at least when looking at it in gdb… I even had to add -ffreestanding because it otherwise triggered an optimisation to transform the loop into a call to strlen

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #21 from Thorsten Glaser --- … reverting that precise workaround FIXES the bug with GCC 14 🤯 Something deep inside must be buggy, and the triggering with this only an accident.

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #20 from Thorsten Glaser --- I would like some assistance in debugging this further. I had been able to work around this by… -static int varsub(Expand *, const char *, const char *, unsigned int *, int *); +static int varsub(Expand

[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

[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

[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

[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

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

[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=cb9

[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

[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, t

[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&action=edit tarball (.xz) with preprocessed and assembly output I’ve verified (back to unmodified source) that it is in

[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 withou

[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; … an

[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 su

[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/

[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

[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("no

[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

: 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

[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

[Bug web/64471] New: 403 Forbidden on GCC 5 page

: 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 c/64470] New: “floating constant exceeds range” warning for constants that should fit

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 origi

[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 --- 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 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 changed: What|Removed |Added Target||i486-linux-gnu URL|

[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 --- Created attachment 31856 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31856&action=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 --- Comment #2 from Thorsten Glaser --- Created attachment 31857 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31857&action=edit symbols file

[Bug target/59842] New: `__x86.get_pc_thunk.bx' referenced in section `.text': defined in discarded section…

NCONFIRMED 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=31855&action=edit test runner Hi *, I origina

[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 --- 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 changed: What|Removed |Added Known to fail||4.8.1 --- Comment #22 from Thorsten Gla

[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 --- -fno-auto-inc-dec helps, thanks!

[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 --- Created attachment 30668 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30668&action=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

[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 changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #23

[Bug java/57929] New: gcc-4.8: FTBFS on m68k: ICE compiling libjava/interpret.cc

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=30525&action=edit original preprocessed source code Hi, this is a forward f

[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 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/dia

[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 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 Thorsten Glaser changed: What|Removed |Added Summary|ICE in CSE |ICE in cselib_record_set,

[Bug target/56087] [m68k] gcc miscompiles pari (multiplication)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56087 --- Comment #3 from Thorsten Glaser 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 changed: >--- Comment

[Bug target/56087] [m68k] gcc miscompiles pari (multiplication)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56087 Thorsten Glaser changed: What|Removed |Added Keywords||wrong-code Target|

[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

[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 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 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 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 th

[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 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:

[Bug middle-end/52306] ICE in CSE

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #7 from Thorsten Glaser 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

[Bug middle-end/52306] ICE in CSE

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #5 from Thorsten Glaser 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

[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:

[Bug middle-end/21161] "clobbered by longjmp" warning ignores the data flow

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161 Thorsten Glaser changed: What|Removed |Added CC||tg at mirbsd dot org

[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 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

[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 changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #7

[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 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 Thorsten Glaser changed: What|Removed |Added Known to fail||4.6.3 --- Comment #4 from Thorsten Glas

[Bug middle-end/52306] ICE in CSE

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #3 from Thorsten Glaser 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 P

[Bug regression/52383] [4.6 Regression] miscompiles Perl on m68k

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52383 Thorsten Glaser changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|

[Bug ada/48835] porting GNAT to m68k-linux

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #52 from Thorsten Glaser 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.

[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 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 changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #22

[Bug regression/52383] gcc-4.6 regression: miscompiles Perl on m68k

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52383 Thorsten Glaser changed: What|Removed |Added Keywords||wrong-code Target|

[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 Priori

[Bug target/43437] ICE in CSE, during libgcc build

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437 --- Comment #22 from Thorsten Glaser 2012-02-18 23:31:40 UTC --- ok, moved it to #52306

[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

[Bug target/43437] ICE in CSE, during libgcc build

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437 --- Comment #20 from Thorsten Glaser 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 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

[Bug target/43437] ICE in CSE, during libgcc build

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437 --- Comment #15 from Thorsten Glaser 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/Buil

[Bug target/43437] ICE in CSE, during libgcc build

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437 --- Comment #13 from Thorsten Glaser 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

[Bug target/43437] ICE in CSE, during libgcc build

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437 Thorsten Glaser changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #12

[Bug target/43437] ICE in CSE, during libgcc build

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437 --- Comment #11 from Thorsten Glaser 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 sam

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #39 from Thorsten Glaser 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 th

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #36 from Thorsten Glaser 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 pat

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #30 from Thorsten Glaser 2011-09-10 13:11:16 UTC --- (In reply to comment #29) > After a lengthy bisection process, I've now finally identified r171341 > as the critical change >

[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 changed: What|Removed |Added Severity|normal |critical --- Comment #1 from Thorsten G

[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 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) s

[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 2011-07-26 20:16:22 UTC --- Both gcc-4.4 and gcc-4.6 with that patch applied compile memtest.i properly.

[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 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 __strsp

[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

[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 Compone

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #20 from Thorsten Glaser 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

[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 changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #1

[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 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 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

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #7 from Thorsten Glaser 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/48835] Porting GNAT to GNU/Linux/m68k

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #5 from Thorsten Glaser 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

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #4 from Thorsten Glaser 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 sa

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 Thorsten Glaser changed: What|Removed |Added Host|m68k-linux | --- Comment #3 from Thorsten Glaser 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 #15 from Thorsten Glaser 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 her

[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.g

[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 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 cros

[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 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 s

[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 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 tryin

[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 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: hostp

[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 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

[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 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-g

[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 changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #4

[Bug tree-optimization/47677] [4.6 Regression] Hang in VRP

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47677 Thorsten Glaser changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #5

[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 2011-01-29 18:51:23 UTC --- OK, the patch fixes the problem indeed. Thanks! (Sorry for the noise, too.)

[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 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

[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 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?

  1   2   >