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=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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
Thorsten Otto changed:
What|Removed |Added
CC||ad...@tho-otto.de
--- Comment #7 from
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=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]
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 #12 from Thorsten Otto ---
Created attachment 58187
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58187=edit
2nd test case
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
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 #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*)':
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
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 #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
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
Bug ID: 115010
Summary: m68k: invalid subl instruction generated
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111279
Thorsten Otto changed:
What|Removed |Added
CC||ad...@tho-otto.de
--- Comment #2 from
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88160
Thorsten Otto changed:
What|Removed |Added
CC||ad...@tho-otto.de
--- Comment #5 from
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=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=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=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=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=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=110126
--- Comment #10 from Thorsten Otto ---
Yes, thank you, that seems to work.
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
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:
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=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=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
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=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=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:
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=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=110003
Bug ID: 110003
Summary: Wrong source line listed for unused parameters
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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
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=92336
Thorsten Otto changed:
What|Removed |Added
CC||ad...@tho-otto.de
--- Comment #5 from
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=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
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
45 matches
Mail list logo