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
Compone
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 call
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
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
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88160
Thorsten Otto changed:
What|Removed |Added
CC||ad...@tho-otto.de
--- Comment #5 from Th
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&action=edit
Possible workaround
I currently use the attached patch to work around this. However it is a bit
hackish as it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111279
Thorsten Otto changed:
What|Removed |Added
CC||ad...@tho-otto.de
--- Comment #2 from T
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&action=edit
Avoid segmentation fault when calling assign_temp with a NULL type pointer
Attached is a potential patch to fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
--- Comment #18 from Thorsten Otto ---
Confirmed. I'll try to bisect which commit caused the error to disappear,
starting with commit 77ccfa6ac8d6e4dfefdea45c4259a2873ff9eb3d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
--- Comment #19 from Thorsten Otto ---
Bisecting gave me:
>From dba20679f1bf138ab5e61ad131b887db42083174 Mon Sep 17 00:00:00 2001
From: Xianmiao Qu
Date: Sun, 25 Aug 2024 11:22:21 -0600
Subject: [PATCH] [PATCH] Re-add calling emit_clobber in l
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: targe
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.
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&action=edit
preprocessed source & assembler output of tree-data-ref.cc
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"
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&action=edit
Shortened test case
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*)':
test.c:4
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
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 to
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&action=edit
2nd test case
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
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] Avo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
--- Comment #16 from Thorsten Otto ---
Yes, i'm just curious what that "latent bug" might be.
It might not have to do directly with that __builtin_mul_overflow() at all,
because when using -m68060, library calls to __mulsi3() are used to avoid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
Thorsten Otto changed:
What|Removed |Added
CC||ad...@tho-otto.de
--- Comment #7 from T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--- Comment #10 from Thorsten Otto ---
In my case it didn't fix the issue. I still get
internal compiler error: in emit, at tree-switch-conversion.cc:1637
when i configure it atleast with --enable-checking=misc
So i can just repeat myself: i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--- Comment #12 from Thorsten Otto ---
Can you try to compile the date_is_valid() snippet in comment#7?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92336
Thorsten Otto changed:
What|Removed |Added
CC||ad...@tho-otto.de
--- Comment #5 from Th
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
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
/../lib64/gcc/x86_6
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
Component:
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
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:
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: norm
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
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
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 car
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126
Thorsten Otto changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
Resolution|FIXED
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: INTEGER16):
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
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126
--- Comment #10 from Thorsten Otto ---
Yes, thank you, that seems to work.
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"
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
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.
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?
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126
Thorsten Otto changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--- Comment #19 from Thorsten Otto ---
I've already done that, as shown above in comment #7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96532
--- Comment #10 from Thorsten Otto ---
Looks like that for m68k, this was fixed by
https://github.com/gcc-mirror/gcc/commit/da9e6e63d1ae22e530ec7baf59f6ed028bf05776
However, as Christian pointed out, other targets seem to be still affected,
alth
49 matches
Mail list logo
