[Bug middle-end/103950] [9/10/11/12 Regression] printf("\xff") incorrectly optimized to putchar(-1)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103950 --- Comment #6 from Thorsten Otto --- A similar fix will be needed in gimple_fold_builtin_fputs

[Bug c/103950] New: printf("\xff") incorrectly optimized to putchar(-1)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103950 Bug ID: 103950 Summary: printf("\xff") incorrectly optimized to putchar(-1) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c/103950] printf("\xff") incorrectly optimized to putchar(-1)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103950 --- Comment #1 from Thorsten Otto --- In gimple_fold_builtin_printf(), a call to printf() with a single-character-string is optimized to putchar(). However that is also done with non-ascii-characters, which in the case of printf("\ff") will

[Bug target/111279] ICE: Segmentation fault with m68k,SJLJ and -malign-int

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111279 Thorsten Otto changed: What|Removed |Added CC||ad...@tho-otto.de --- Comment #2 from

[Bug target/111279] ICE: Segmentation fault with m68k,SJLJ and -malign-int

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111279 --- Comment #3 from Thorsten Otto --- Created attachment 55837 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55837=edit Avoid segmentation fault when calling assign_temp with a NULL type pointer Attached is a potential patch to fix

[Bug modula2/110002] Using -fcpp only invokes cc1 from pre-configured path $(libexec)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110002 --- Comment #3 from Thorsten Otto --- Created attachment 55745 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55745=edit Possible workaround I currently use the attached patch to work around this. However it is a bit hackish as it uses a

[Bug target/88160] Error: register save offset not a multiple of 4 only with optimize

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88160 Thorsten Otto changed: What|Removed |Added CC||ad...@tho-otto.de --- Comment #5 from

[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126 --- Comment #10 from Thorsten Otto --- Yes, thank you, that seems to work.

[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126 --- Comment #13 from Thorsten Otto --- Just found a small problem: asm statements without any lists, like in ASM(""); now are warned about with "syntax warning, ':' missing"

[Bug modula2/110633] New: Using an unknown identifier as argument to ORD results in ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110633 Bug ID: 110633 Summary: Using an unknown identifier as argument to ORD results in ICE Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal

[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126 Thorsten Otto changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED

[Bug modula2/110019] New: Reported line numbers ar off-by-1 when preprocessing source files

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110019 Bug ID: 110019 Summary: Reported line numbers ar off-by-1 when preprocessing source files Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal

[Bug modula2/110002] New: Using -fcpp only invokes cc1 from pre-configured path $(libexec)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110002 Bug ID: 110002 Summary: Using -fcpp only invokes cc1 from pre-configured path $(libexec) Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal

[Bug modula2/92336] cross compiling gcc fails in gm2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92336 Thorsten Otto changed: What|Removed |Added CC||ad...@tho-otto.de --- Comment #5 from

[Bug modula2/110002] Using -fcpp only invokes cc1 from pre-configured path $(libexec)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110002 --- Comment #1 from Thorsten Otto --- When using -fcpp, gm2cc1 invokes cc1 only from the configured $(libexec) directory, eg. /usr/lib64/gcc/x86_64-suse-linux/13/cc1. But when installed in a different directory, it should use

[Bug modula2/110125] Variables are reported as uninitialized when only set inside WITH statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110125 --- Comment #2 from Thorsten Otto --- Maybe related to this: MODULE foo; TYPE Head = RECORD magic: INTEGER; END; Carrier = RECORD head: Head; tail: Head; END; PROCEDURE test(VAR

[Bug modula2/110174] New: Using illegal constraints for builtin return_address gives ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110174 Bug ID: 110174 Summary: Using illegal constraints for builtin return_address gives ICE Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal

[Bug modula2/110189] New: Using an unknown TYPE as argument to VAL gives ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110189 Bug ID: 110189 Summary: Using an unknown TYPE as argument to VAL gives ICE Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126 --- Comment #8 from Thorsten Otto --- And here are examples that trigger the bug: DEFINITION MODULE BIOS; FROM SYSTEM IMPORT ADDRESS, CARDINAL32, INTEGER16, INTEGER32; END BIOS. IMPLEMENTATION MODULE BIOS; PROCEDURE trap_13_w(n:

[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126 Thorsten Otto changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED

[Bug modula2/110125] New: Variables are reported as uninitialized when only set inside WITH statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110125 Bug ID: 110125 Summary: Variables are reported as uninitialized when only set inside WITH statement Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity:

[Bug modula2/110126] New: Variables are reported as unused when only referenced by ASM statements

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126 Bug ID: 110126 Summary: Variables are reported as unused when only referenced by ASM statements Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity:

[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126 --- Comment #2 from Thorsten Otto --- But even if i rewrite it like that, i still get the warning. I avoided doing anything machine specific in the first example, but if i actually do, and use something like: PROCEDURE test; BEGIN ASM("movl

[Bug modula2/110161] New: Comparing a typed procedure variable to 0 gives ICE or assertions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110161 Bug ID: 110161 Summary: Comparing a typed procedure variable to 0 gives ICE or assertions Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal

[Bug modula2/110003] New: Wrong source line listed for unused parameters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110003 Bug ID: 110003 Summary: Wrong source line listed for unused parameters Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug modula2/110189] Using an unknown TYPE as argument to VAL gives ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110189 --- Comment #5 from Thorsten Otto --- Many thanks for fixing it. But just found, that same thing seems to happen when using other builtin functions like ORD(). Should i open a new report for this?

[Bug modula2/110246] New: Using variables of type CHAR or BYTE as array index does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110246 Bug ID: 110246 Summary: Using variables of type CHAR or BYTE as array index does not work Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal

[Bug modula2/110246] Using variables of type CHAR or BYTE as array index does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110246 --- Comment #1 from Thorsten Otto --- Edit: the problem seems to be caused by using a FOR loop. Changing it to a similar WHILE loop: ch := 'A'; WHILE ch <= 'Z' DO arr[ch] := 0; INC(ch); END; does work without problems.

[Bug target/111279] ICE: Segmentation fault with m68k,SJLJ and -malign-int

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111279 --- Comment #5 from Thorsten Otto --- I don't mind. If your patch also contains a test case, just use that.

[Bug c/114430] New: False positive for -Wformat

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114430 Bug ID: 114430 Summary: False positive for -Wformat Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug target/115010] New: m68k: invalid subl instruction generated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010 Bug ID: 115010 Summary: m68k: invalid subl instruction generated Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug target/115010] m68k: invalid subl instruction generated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010 --- Comment #7 from Thorsten Otto --- Created attachment 58151 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58151=edit Shortened test case

[Bug target/115010] m68k: invalid subl instruction generated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010 --- Comment #8 from Thorsten Otto --- I've never use cvise before, but it gave the attached short source. It inserted a strange recursive call at the end, but it gives me these error messages: test.c: In function 'void mul_hwi(bool*)':

[Bug target/115010] m68k: invalid subl instruction generated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010 --- Comment #2 from Thorsten Otto --- Yes, i'm aware of that. And as already mentioned, the bug is not triggered by all gcc versions. Is there something i can do to track down the issue? tree-data-ref.cc is quite large.

[Bug target/115010] m68k: invalid subl instruction generated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010 --- Comment #6 from Thorsten Otto --- Oh, yes, of course. command line that failed: m68k-atari-mint-g++-14.1.0 -m68020-60 "-fno-PIE" "-c" "-O2" "-fomit-frame-pointer" "-DIN_GCC" "-fno-exceptions" "-fno-rtti" "-fasynchronous-unwind-tables" "-W"

[Bug target/115010] m68k: invalid subl instruction generated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010 --- Comment #9 from Thorsten Otto --- Doing some more testing: - a cross-compiler build for m68k-suse-linux gives the same error on the reduced testcase - the error only occurs when using -m68020-60 or -m68060 - older compiler versions (tested

[Bug target/115010] m68k: invalid subl instruction generated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010 --- Comment #4 from Thorsten Otto --- Created attachment 58150 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58150=edit preprocessed source & assembler output of tree-data-ref.cc

[Bug target/115010] m68k: invalid subl instruction generated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010 --- Comment #12 from Thorsten Otto --- Created attachment 58187 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58187=edit 2nd test case

[Bug target/115010] m68k: invalid subl instruction generated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010 --- Comment #13 from Thorsten Otto --- Now its getting really strange. I've attached a 2nd test case above. With that, the bug can be reproduced also with gcc 11.4.0 (but not with gcc-10, gcc-12 or gcc-13). It is slightly larger than the first

[Bug target/115010] m68k: invalid subl instruction generated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010 --- Comment #14 from Thorsten Otto --- A bisect between 10.0.0 and 11.4.0 for the 2nd testcase gave me this commit: commit 512c6ba04102295fccc62a173ee0086ca733c920 From: Richard Biener Date: Thu, 12 Nov 2020 11:29:12 +0100 Subject: [PATCH]

[Bug target/115010] m68k: invalid subl instruction generated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010 --- Comment #11 from Thorsten Otto --- Confirmed, reverting that commit will prevent the error. Now the question is how to find the real cause of the problem, since reverting that commit is most likely not the solution. OTOH, it would be nice