[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
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ad...@tho-otto.de
Target Milestone: ---
[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 call putchar
with a value of (-1) == EOF. That happens even if -funsigned-char is used.
[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/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
Assignee: unassigned at gcc dot gnu.org
Reporter: ad...@tho-otto.de
Target Milestone: ---
Using GCC 13.2.1, with:
#include
struct WWPerson
{
char Name[12];
};
struct WWPerson WWPersons[] = {
{"Bill R"},
{"Bill R"},
{"Barry G"},
};
char item[12 + 1];
void test()
{
for (size_t i = 0; i < sizeof(WWPersons) / sizeof(struct WWPerson); i++) {
sprintf(item, "%s", WWPersons[i].Name);
}
}
When compiling with -O2, i get:
bla.c: In function ‘test’:
bla.c:18:24: warning: ‘%s’ directive writing up to 35 bytes into a region of
size 13 [-Wformat-overflow=]
18 | sprintf(item, "%s", WWPersons[i].Name);
|^~
bla.c:18:9: note: ‘sprintf’ output between 1 and 36 bytes into a destination of
size 13
18 | sprintf(item, "%s", WWPersons[i].Name);
| ^~
I get the same warning with version 10.5.0, but not with version 9.5.0
The warning disappears when i remove one element from the array.
[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 Thorsten Otto --- Another possible patch would be: --- a/gcc/config/m68k/m68k.cc2023-07-27 10:13:04.0 +0200 +++ b/gcc/config/m68k/m68k.cc 2023-08-13 08:59:00.959510772 +0200 @@ -712,6 +712,14 @@ m68k_option_override (void) else m68k_sched_mac = MAC_NO; } + + /* + * disable -fcombine-stack-adjustments for coldfire/mshort combination, + * which generates wrong CFI offsets. + * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88160 + */ + if (TARGET_COLDFIRE && TARGET_SHORT && (write_symbols & DWARF2_DEBUG)) +flag_combine_stack_adjustments = 0; } This is only a workaround, but should prevent the bug.
[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&action=edit Possible workaround I currently use the attached patch to work around this. However it is a bit hackish as it uses a global variable to access argv[0]. Using GetArgV() does not seem to work because that module was not yet initialized.
[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 Thorsten Otto --- emit_push_insn is called from https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/calls.cc;h=1f3a6d5c45099499deeef63f867ed11774dec47e;hb=HEAD#l4585 where only a NULL_TREE pointer is passed for the type, and crashes when trying to access the TREE_CODE. The call to assign_temp was inserted by https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=46bd2beed4c78dcb32fcde4913815527c14e5e17
[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&action=edit Avoid segmentation fault when calling assign_temp with a NULL type pointer Attached is a potential patch to fix that. The above mentioned commit was made for gcc 4.3, and all compiler versions after that are affected by it.
[Bug target/115010] m68k: invalid subl instruction generated
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
[Bug target/115010] m68k: invalid subl instruction generated
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 lower-subreg.cc's resolve_simple_move. Which basically reverts the commit already mentioned above. So it looks like the problem was caused by the side-effects mentioned in the patch.
[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: target Assignee: unassigned at gcc dot gnu.org Reporter: ad...@tho-otto.de Target Milestone: --- While configuring a cross-compiler for m68k, and then trying to use that cross-compiler to build a native compiler, a wrong subl instruction gets generated: Assembler messages: /tmp/ccpLXgrk.s:16664: Error: operands mismatch -- statement sub.l -402(%fp),-446(%fp)' ignored /tmp/ccpLXgrk.s:16813: Error: operands mismatch -- statement sub.l -274(%fp),-302(%fp)' ignored make[1]: *** [Makefile:1202: tree-data-ref.o] Error 1 That instruction is invalid, because atleast one of the operands must be a data register. Unfortunately the steps to reproduce are a bit complicated, using a bare m68k-elf target not work, because for the 2nd step you will also need a working c-library. And of course you also need binutils for that target. I should also mention that the same bug already happened in gcc 11.4.0, but strangely not in gcc 13.2.0 or gcc 12.3.0 (but maybe this was just by incident). The problem also disappears when compiling tree-data-ref.c using -Os instead of -O2. I'm not that really familiar with the machine description files, but to me (define_insn "subsi3" [(set (match_operand:SI 0 "nonimmediate_operand" "=md,ma,m,d,a") (minus:SI (match_operand:SI 1 "general_operand" "0,0,0,0,0") (match_operand:SI 2 "general_src_operand" "I,I,dT,mSrT,mSrs")))] "" "@ subq%.l %2, %0 subq%.l %2, %0 sub%.l %2,%0 sub%.l %2,%0 sub%.l %2,%0" [(set_attr "type" "aluq_l,aluq_l,alu_l,alu_l,alu_l") (set_attr "opy" "2") (set_attr "flags_valid" "noov,unchanged,noov,noov,unchanged")]) Looks suspicious. If i'm not wrong, that pattern is used to turn something like "x = x - y" into "x -= y". But alternative 3 can match a memory operand for operand 0, and constraint 'T' for operand 2 is defined as (define_constraint "T" "Used for operands that satisfy 's' when -mpcrel is not in effect." (and (match_code "symbol_ref,label_ref,const") (match_test "!TARGET_PCREL") (match_test "!flag_pic || LEGITIMATE_PIC_OPERAND_P (op)"))) so it can match a symbol_ref. Could that be the cause?
[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 #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
[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" "-Wall" "-Wno-narrowing" "-Wwrite-strings"
"-Wcast-qual" "-Wmissing-format-attribute" "-Wconditionally-supported"
"-Woverloaded-virtual" "-pedantic" "-Wno-long-long" "-Wno-variadic-macros"
"-Wno-overlength-strings" "-DHAVE_CONFIG_H" "-fno-PIE" "-I." "-I."
"-I/home/sebilla/m68k-atari-mint-gcc/gcc"
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/."
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/../include"
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/../libcpp/include"
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/../libcody"
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/../libdecnumber"
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/../libdecnumber/dpd"
"-I../libdecnumber" "-I/home/sebilla/m68k-atari-mint-gcc/gcc/../libbacktrace"
"-o" "tree-data-ref.o" "-save-temps"
"/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc"
(where /home/sebilla/m68k-atari-mint-gcc is the source directory of the repo)
The original cross-compiler (m68k-atari-mint-g++-14.1.0) was configured with:
/home/sebilla/m68k-atari-mint-gcc/configure --target=m68k-atari-mint
--build=x86_64-suse-linux-gnu --prefix=/usr --libdir=/usr/lib64
--bindir=/usr/bin --libexecdir='' 'CFLAGS_FOR_BUILD=-O2 -fomit-frame-pointer
-include /home/sebilla/m68k-atari-mint-gcc/gcc/libcwrap.h' CFLAGS='-O2
-fomit-frame-pointer -include /home/sebilla/m68k-atari-mint-gcc/gcc/libcwrap.h'
'CXXFLAGS_FOR_BUILD=-O2 -fomit-frame-pointer ' CXXFLAGS='-O2
-fomit-frame-pointer' 'BOOT_CFLAGS=-O2 -fomit-frame-pointer'
'CFLAGS_FOR_TARGET=-O2 -fomit-frame-pointer' 'CXXFLAGS_FOR_TARGET=-O2
-fomit-frame-pointer' LDFLAGS_FOR_BUILD= LDFLAGS= GNATMAKE_FOR_HOST=gnatmake-14
GNATBIND_FOR_HOST=gnatbind-14 GNATLINK_FOR_HOST=gnatlink-14
--with-pkgversion='MiNT 20240507' --disable-libcc1 --disable-werror
--with-gxx-include-dir=/usr/m68k-atari-mint/sys-root/usr/include/c++/14
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-gcc-major-version-only
--with-gcc --with-gnu-as --with-gnu-ld --with-system-zlib
--without-static-standard-libraries --without-stage1-ldflags --disable-libgomp
--without-libatomic --without-newlib --disable-libstdcxx-pch --disable-threads
--disable-win32-registry --disable-lto --enable-ssp --enable-libssp
--disable-plugin --disable-decimal-float --disable-nls
--with-libiconv-prefix=/usr --with-libintl-prefix=/usr
--with-sysroot=/usr/m68k-atari-mint/sys-root
--enable-languages=c,c++,fortran,ada,d,m2
The compiler that i'm trying to build was configured with:
'--target=m68k-atari-mint' '--host=m68k-atari-mint'
'--build=x86_64-suse-linux-gnu' '--prefix=/usr' '--libdir=/usr/lib'
'--bindir=/usr/bin' '--libexecdir=${libdir}' '--with-pkgversion=MiNT 20240507'
'--disable-libcc1' '--disable-werror'
'--with-gxx-include-dir=/usr/include/c++/14'
'--with-libstdcxx-zoneinfo=/usr/share/zoneinfo' '--with-gcc-major-version-only'
'--with-gcc' '--with-gnu-as' '--with-gnu-ld' '--with-system-zlib'
'--disable-libgomp' '--without-newlib' '--disable-libstdcxx-pch'
'--disable-threads' '--disable-win32-registry' '--disable-lto' '--enable-ssp'
'--enable-libssp' '--disable-plugin' '--disable-decimal-float' '--disable-nls'
'--with-cpu=m68020-60' '--with-build-sysroot=/usr/m68k-atari-mint/sys-root'
'build_alias=x86_64-suse-linux-gnu' 'host_alias=m68k-atari-mint'
'target_alias=m68k-atari-mint' 'CC=m68k-atari-mint-gcc-14.1.0 -m68020-60'
'CFLAGS=-O2 -fomit-frame-pointer' 'LDFLAGS=-Wl,-stack,512k'
'CXX=m68k-atari-mint-g++-14.1.0 -m68020-60' 'CXXFLAGS=-O2 -fomit-frame-pointer'
'CC_FOR_TARGET=m68k-atari-mint-gcc-14.1.0'
'CXX_FOR_TARGET=m68k-atari-mint-g++-14.1.0'
'GCC_FOR_TARGET=m68k-atari-mint-gcc-14.1.0'
'GFORTRAN_FOR_TARGET=m68k-atari-mint-gfortran-14.1.0'
'GOC_FOR_TARGET=m68k-atari-mint-goc-14.1.0'
'AS_FOR_TARGET=/home/sebilla/mintstd/binary7-package/usr/bin/m68k-atari-mint-as'
'RANLIB_FOR_TARGET=m68k-atari-mint-ranlib'
'STRIP_FOR_TARGET=m68k-atari-mint-strip' '--enable-languages=c,c++'
compiler output was:
/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc: In function 'bool
siv_subscript_p(const_tree, const_tree)':
/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc:3587:15: warning: this
statement may fall through [-Wimplicit-fallthrough=]
3587 | if (CHREC_VARIABLE (chrec_a) != CHREC_VARIABLE (chrec_b))
| ^~
/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc:3591:13: note: here
3591 | default:
| ^~~
/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc: In function 'bool
get_references_in_stmt(gimple*, vec*)':
/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc:5888:25: warning: this
statement may fall through [-Wimplicit-fallthrough=]
5888 | ref.is_read = true;
| ^~
/home/sebilla/m68k-atari-mint-gcc
[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&action=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*)':
test.c:4:6: warning: infinite recursion detected [-Winfinite-recursion]
4 | void mul_hwi(bool *overflow) {
| ^~~
test.c:6:10: note: recursive call
6 | mul_hwi(&mul_hwi_ovf);
| ~~~^~
test.s: Assembler messages:
test.s:101: Error: operands mismatch -- statement `sub.l 80(%sp),52(%sp)'
ignored
[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 gcc 13.2.0, gcc-12.3.0, gcc-11.4.0, and gcc-10.5.0) do not give the error
[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 to know why the call to emit_clobber() originally was done.
[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&action=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 case, but also has references to __builtin_mul_overflow(). The 1st test case does not trigger the bug in gcc-11 though. Note that the commit that was identified as the culprit was only applied to the gcc-14 branch, but not to gcc-11.
[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] Avoid PRE insert iteration when possible
[Bug target/115010] m68k: invalid subl instruction generated
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 the 32x32 muls.l instruction which is not implemented on 060. That makes less registers available in the caller.
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
Thorsten Otto changed:
What|Removed |Added
CC||ad...@tho-otto.de
--- Comment #7 from Thorsten Otto ---
I ran into a similar problem. The symptom was that code in
tree-switch-conversion was miscompiled:
if (k == count)
{
gcc_checking_assert (count < m_max_case_bit_tests);
test[k].mask = wi::zero (prec);
test[k].target_bb = n->m_case_bb;
test[k].label = n->m_case_label_expr;
test[k].bits = 0;
test[k].prob = profile_probability::never ();
count++;
}
--- good.s 2024-06-02 13:20:13.453987931 +0200
+++ bad.s 2024-06-02 13:50:03.452881214 +0200
@@ -26976,11 +26976,10 @@
move.l %d1,-330(%a0)| prephitmp_336, MEM
[(struct wide_int_storage *)&test][count_1036].mask.D.16112.len
| gcc/tree-switch-conversion.cc:1639: test[k].target_bb =
n->m_case_bb;
move.l 4(%a3),%d1 | MEM [(void *)n_1051
+ 4B], vect__12.3140
- lea (-322,%fp),%a4 |,,
- lea (%a4,%d0.l),%a1 |, vectp.3143
+ lea (%fp,%d0.l),%a1 | tmp12, tmp638, vectp.3143
| gcc/tree-switch-conversion.cc:1639: test[k].target_bb =
n->m_case_bb;
move.l 8(%a3),(%a1) | MEM [(void *)n_1051
+ 8B], MEM [(void *)vectp.3143_425]
- move.l %d1,4(%a1) | vect__12.3140, MEM
[(void *)vectp.3143_425 + 4B]
+ move.l %d1,-318(%a1)| vect__12.3140, MEM
[(void *)vectp.3143_425 + 4B]
| gcc/tree-switch-conversion.cc:1641: test[k].bits = 0;
clr.l -314(%a0) | test[count_1036].bits
| gcc/tree-switch-conversion.cc:1642: test[k].prob =
profile_probability::never ();
Apparently the offset to the local test array was optimized away for the first
store, causing the outer loop to not find the previous m_case_bb pointer, and
then either crash or fail with an assertion because the array overflowed.
Seems like this is not the first regression caused by this "optimization".
Maybe it should be disabled for targets other than riscv, atleast until more
tests have been written.
A crash with such a buggy compiler can be produced with eg.
int date_is_valid(int mon)
{
switch (mon) {
case 1:
case 3:
case 5:
case 7:
case 8:
case 10:
case 12:
break;
default:
return 0x2400;
}
return 0;
}
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
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: if even after 3-4 attempts of fixing this it still does not work, please revert that fold-mem-offset patch(es), or atleast disable them. Its not worth of doing unsafe optimizations whose only purpose is to save a single instruction for a particular machine, but cause trouble for others.
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
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?
[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 Thorsten Otto --- I get a related problem here. Configuring works, but during build, some of the helper programs (like mc) are compiled using $(CXX), which is already a cross-compiler, and therefor the resulting binaries cannot be executed.
[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 Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: ad...@tho-otto.de Target Milestone: ---
[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 /../lib64/gcc/x86_64-suse-linux/13/cc1 first, like the driver does.
[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 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: ad...@tho-otto.de Target Milestone: --- When compiling a module with -Wall and a parameter in the in implementation module is unused, the error message lists the source line of the definition module instead: DEFINITION MODULE foo; PROCEDURE bla(a: INTEGER); END foo. IMPLEMENTATION MODULE foo; PROCEDURE bla(a: INTEGER); BEGIN END bla; END foo. $ gm2 -c -Wall foo.mod ./foo.def:3:15: warning: In procedure 'bla': unused parameter 'a' in procedure 'bla' 3 | PROCEDURE bla(a: INTEGER); | ^ That information is rather useless, because an unused parameter can only be unused in the implementation.
[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 Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: ad...@tho-otto.de Target Milestone: --- When preprocessing modula sources with -fcpp, both the line number and the quoted source line are off-by-1 in error reports. Compiling eg: MODULE foo; BEGIN i := 0; END foo. gives: foo.mod:3:3: error: In program module 'foo': unknown symbol 'i' 3 | BEGIN | ^ foo.mod:4:8: error: the following unknown symbols in module 'foo' were unresolved: and i 4 | i := 0; |^ Additionally, the "and" in the summary of unresolved symbols is wrong.
[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: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: ad...@tho-otto.de Target Milestone: --- In the following fragment: MODULE foo; TYPE Date = RECORD day: INTEGER; END; PROCEDURE test(): Date; VAR d: Date; BEGIN WITH d DO day := 0; END; RETURN d; END test; END foo. When compiling with $ gm2 -c -O2 -Wall foo.mod i get reports about d being uninitialized: foo.mod:9:5: warning: In procedure ‘test’: variable ‘d’ is being used but it is never initialized in procedure ‘test’ 9 | VAR d: Date; | ^ This does not happen when *not* using WITH, eg MODULE foo; TYPE Date = RECORD day: INTEGER; END; PROCEDURE test(): Date; VAR d: Date; BEGIN d.day := 0; RETURN d; END test; END foo.
[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: normal
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: ad...@tho-otto.de
Target Milestone: ---
In the following fragment:
MODULE foo;
VAR x: INTEGER;
PROCEDURE test;
BEGIN
ASM("" : : "m"(x));
END test;
END foo.
x is reported as unused (same happens when specifying it as output parameter)
Even worse, when used as input operand only, the whole asm statement seems to
be optimized away.
[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 %1,%%eax; addl $1,%%eax; movl %%eax,%0" : "=r"(x) : "0"(x) :
"eax");
END test;
i still get the warning.
BTW, is there a reason why the string in the asm statement can't be
concatenated?
eg. especially if the statement becomes longer, you would usually want to write
it something like
ASM("movl %1,%%eax;" +
"addl $1,%%eax;" +
"movl %%eax,%0"
: "=r"(x) : "0"(x) : "eax");
[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 Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: ad...@tho-otto.de Target Milestone: --- In the following example: MODULE foo; TYPE xProc = PROCEDURE(): BOOLEAN; VAR x: xProc; BEGIN IF x = 0 THEN END; END foo. I get: cc1gm2: internal compiler error: assert failed (unfortunately without any line number information). Same happens when comparing to NIL or PROC(0). Only xProc(0) works.
[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 carrier: Carrier); BEGIN carrier.head.magic := 0; carrier.tail.magic := 0; END test; VAR x: Carrier; BEGIN test(x); END foo. also gives warning about unused parameter "carrier" in function test.
[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
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: ad...@tho-otto.de
Target Milestone: ---
When compiling the the following module with -O2
MODULE foo;
FROM Builtins IMPORT return_address;
FROM SYSTEM IMPORT ADDRESS;
VAR x: ADDRESS;
PROCEDURE test();
BEGIN
ASM VOLATILE("" : "=m"(x) : "m"(return_address(0)) : );
END test;
BEGIN
test();
END foo.
I get an ICE:
during RTL pass: expand
In function ‘test’,
inlined from ‘_M2_foo_init’ at foo.mod:13:3:
foo.mod:9:56: internal compiler error: in expand_asm_stmt, at cfgexpand.cc:3419
9 | ASM VOLATILE("" : "=m"(x) : "m"(return_address(0)) : );
|^
The ICE is triggered at
https://github.com/gcc-mirror/gcc/blob/9589a46ddadc8b93c224c3f84fa94746c04596bf/gcc/cfgexpand.cc#L3419
Using "m" as constraint is actually wrong, however the C backend handles that
correctly:
foo.c:5:39: error: memory input 1 is not directly addressable
5 | __asm__ volatile("" : "=m"(x) : "m"(__builtin_return_address(0)) : );
[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 |--- --- Comment #7 from Thorsten Otto --- Thanks for looking into this. Unfortunately, with the new patch applied, i now get cc1gm2: internal compiler error: symbol out of bounds 0x7f4dfde2cbaf __libc_start_call_main ???:0 0x7f4dfde2cc78 __libc_start_main_alias_1 ???:0 Have yet to try to create a simple testcase that triggers this bug.
[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: INTEGER16): [ INTEGER32 ];
VAR
retvalue: INTEGER32;
BEGIN
ASM VOLATILE(""
: "=r"(retvalue)
: "g"(n)
: "cc", "memory"
);
RETURN retvalue
END trap_13_w;
BEGIN
END BIOS.
The crash disappears when i remove the clobber list from the asm.
[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
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: ad...@tho-otto.de
Target Milestone: ---
In the following example:
MODULE foo;
VAR x: INTEGER;
BEGIN
x := VAL(abcd, 0);
END foo.
I get:
M2MetaError.mod:1535:internalformat error detected
errorBlock
type = abort
out = ||
in= |undeclared type found in builtin procedure function {%AkVAL}
{%A1ad}|
Length (out) = 0
len = 68
highplus1 = 1*** WARNING *** there are active plugins, do not report this as a
bug unless you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH| m2rte
cc1gm2: internal compiler error: in libc_abort, at m2/mc-boot-ch/Glibc.c:70
0x195d5c6 internal_error(char const*, ...)
???:0
0x6f0e97 fancy_abort(char const*, int, char const*)
???:0
0x6aa497 libc_abort
???:0
0x808f05 FormatStrings_Sprintf1
???:0
0x767c73 M2Printf_fprintf1
???:0
0x76da13 M2MetaError_MetaErrorStringT1
???:0
0x786078 M2Quads_BuildFunctionCall
???:0
0x7e59d9 P3Build_CompilationUnit
???:0
0x75ba6b M2Comp_compile
???:0
[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/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
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: ad...@tho-otto.de
Target Milestone: ---
In the following example:
IMPLEMENTATION MODULE foo;
FROM SYSTEM IMPORT BYTE;
VAR arr: ARRAY['A'..'Z'] OF INTEGER;
VAR ch: CHAR;
BEGIN
FOR ch := 'A' TO 'Z' DO arr[ch] := 0 END;
END foo.
I get error messages:
/usr/lib64/gcc/x86_64-suse-linux/13/m2/m2pim/COROUTINES.def:37:1: error: type
incompatibility, attempting to use a string ('_T38') when a CHAR is expected
/usr/lib64/gcc/x86_64-suse-linux/13/m2/m2pim/COROUTINES.def:37:1: error: type
incompatibility, attempting to use a string ('_T38') when a CHAR is expected
/usr/lib64/gcc/x86_64-suse-linux/13/m2/m2pim/COROUTINES.def:37:1: error: type
incompatibility, attempting to use a string ('_T38') when a CHAR is expected
/usr/lib64/gcc/x86_64-suse-linux/13/m2/m2pim/COROUTINES.def:37:1: error: type
incompatibility, attempting to use a string ('_T38') when a CHAR is expected
(note also the totally unrelated source line in the error message)
Changing the type of ch to BYTE i get instead:
/usr/lib64/gcc/x86_64-suse-linux/13/m2/m2pim/COROUTINES.def:37:1: error: left
operand ‘ch’ of type ‘BYTE’ is not allowed in binary expression +
[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 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/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
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: ad...@tho-otto.de
Target Milestone: ---
When compiling
MODULE foo;
VAR x: CARDINAL;
BEGIN
x := ORD(nosuchvar);
END foo.
I get:
M2MetaError.mod:1535:internalformat error detected
errorBlock
type = abort
out = ||
in= |the parameter to {%A1k%a} must be a variable or constant, seen
{%2ad}|
Length (out) = 0
len = 69
highplus1 = 2*** WARNING *** there are active plugins, do not report this as a
bug unless you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH| m2rte
cc1gm2: internal compiler error: in libc_abort, at m2/mc-boot-ch/Glibc.c:70
Might be a general problem when using builtin functions (replacing ORD by CHR
gives the same ICE). Maybe a similar problem as in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110189
[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 |---
--- Comment #14 from Thorsten Otto ---
And another problem i just encountered. In the following example:
DEFINITION MODULE foo;
PROCEDURE ConWS(str: ARRAY OF CHAR);
END foo.
IMPLEMENTATION MODULE foo;
FROM SYSTEM IMPORT ADR, CARDINAL16, CARDINAL32, INTEGER16, ADDRESS,
INTEGER32, WORD;
FROM StrIO IMPORT WriteString, WriteLn;
TYPE strtmp = ARRAY [0..255] OF CHAR;
PROCEDURE str0(VAR dst: strtmp; src: ARRAY OF CHAR);
VAR i, len: CARDINAL;
BEGIN
len := HIGH(dst);
FOR i := 0 TO len DO
dst[i] := src[i];
END;
END str0;
PROCEDURE trap_1_wl(n: INTEGER16; a: ADDRESS): [ INTEGER32 ];
VAR
retvalue: INTEGER32;
BEGIN
ASM VOLATILE("move.l %2,-(%%sp); move.w %1,-(%%sp); trap #1; addq.l
#6,%%sp; move.l %%d0,%0"
: "=r"(retvalue)
: "g"(n), "r"(a)
: "memory"
);
RETURN retvalue
END trap_1_wl;
PROCEDURE ConWS(str: ARRAY OF CHAR);
VAR s: strtmp;
BEGIN
str0(s, str);
trap_1_wl(9, ADR(s));
END ConWS;
END foo.
The call to str0 (in reality supposed to ensure the string is 0-terminated;
just simplified for the example) is now completely eliminated. The assembler
statement is of course only for m68k, but it can even be triggered for other
targets when just producing assembler output.
It does not happen when replacing the call to trap_1_wl eg. by WriteString.
[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 target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
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.
[Bug target/96532] [m68k] gcc 10.x generates calls to memset even for very small amounts
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, although the commit in question does not look to me as if it had any target dependencies. Also note that the commit itself (due to a typo) is not compilable, you have to use the next one (https://github.com/gcc-mirror/gcc/commit/5fbe6a8e73b52c6ebc28b9111456226c1cda6472) instead.
