[Bug c/57061] New: [patch] gcc-4.7.3 has declarations after statements and fails to compile on old systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57061 Bug #: 57061 Summary: [patch] gcc-4.7.3 has declarations after statements and fails to compile on old systems Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: williamba...@hotmail.com Created attachment 29932 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29932 patch to fix compile errors in gcc-4.7.3 gcc-4.7.3 has declarations after statements and fails to compile on old systems, for example, gcc-2.96 on Red Hat Linux 7.1. The attached patch fixes the errors. William
[Bug c/52682] New: [patch] gcc-4.7.0/gcc/c-family/c-lex.c doesn't compile with old C compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52682 Bug #: 52682 Summary: [patch] gcc-4.7.0/gcc/c-family/c-lex.c doesn't compile with old C compilers Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: williamba...@hotmail.com Created attachment 26964 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26964 patch to fix the problem c-lex.c has declarations after an assignment and doesn't compile with gcc-2.96 distributed with Red Hat Linux 7.1. William williamba...@hotmail.com
[Bug bootstrap/78893] New: gcc-6.3.0 build fails on genattrtab on CentOS 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78893 Bug ID: 78893 Summary: gcc-6.3.0 build fails on genattrtab on CentOS 7 Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: williambader at hotmail dot com Target Milestone: --- Created attachment 40392 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40392&action=edit build log I built gcc-6.3.0 on CentOS 4, 5, and 6 using the same procedures that had worked for previous gcc-6 releases, but on CentOS 7, the build fails in genattrtab. genattrtab crashes pretty hard -- running it under valgrind ends with 'Killed', and valgrind exists without giving a traceback or diagnostics. gdb couldn't get a stack trace either. I also tried running the build with -O0. Is there anything else that I can try? I attached a log of the configure and make. The system is CentOS 7.3.1611 with kernel 3.10.0-327.36.2.el7.x86_64 and gcc 4.8.5 20150623 (Red Hat 4.8.5-11). Regards, William
[Bug bootstrap/78893] gcc-6.3.0 build fails on genattrtab on CentOS 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78893 --- Comment #2 from William Bader --- Thanks for the quick reply. The system is a VM. I have the results of 'free' below. The VMs where the build worked all have slightly more memory and swap. What is the recommended minimum to build gcc-6? $ free -h totalusedfree shared buff/cache available Mem: 993M239M382M 10M371M564M Swap: 1.0G977M 47M Regards, William
[Bug bootstrap/78893] gcc-6.3.0 build fails on genattrtab on CentOS 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78893 --- Comment #3 from William Bader --- Thanks! Increasing the allocated memory fixed the problem, and the gcc build completed. Regards, William $ /usr/bin/free -h totalusedfree shared buff/cache available Mem: 1.8G240M941M 28M658M1.3G Swap: 1.0G 81M943M
[Bug lto/48431] New: patch to fix a compile error in lto-plugin.c when using older C compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48431 Summary: patch to fix a compile error in lto-plugin.c when using older C compilers Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: williamba...@hotmail.com Created attachment 23867 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23867 patch to fix the problem The build for gcc-4.6.0 gets a compile error on lto-plugin.c on Red Hat Linux release 7.1 (Seawolf) with gcc version 2.96 2731 because this compiler does not allow declarations after the first statement. The attached patch moves a declaration a few lines back. For the build, I ran /u/gnu/gcc-4.6.0/configure --disable-nls --enable-checking=release --enable-werror=no --with-system-zlib --disable-multilib --with-gmp=/usr/local --with-mpfr=/usr/local make CC=gcc 'CFLAGS=-O0 -g -pipe' 'LIBCFLAGS=-O0 ' 'LIBCXXFLAGS=-O0 -fno-implicit-templates ' 'CXXFLAGS=-O0 -fno-implicit-templates ' 'CXXFLAGS_FOR_BUILD=-O0 -fno-implicit-templates ' 'CXXFLAGS_FOR_TARGET=-O0 -fno-implicit-templates ' 'GOCFLAGS_FOR_TARGET=-O0 -g -pipe' 'BOOT_CFLAGS= -O0 -g -pipe' AS=/usr/bin/as bootstrap-lean Without all of the -O0's, the stage2 xgcc gets an ICE almost immediately on almost any input.
[Bug rtl-optimization/89965] [8 Regression] wrong code with -O -mtune=nano-x2 -fcaller-saves -fexpensive-optimizations -fno-tree-dce -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89965 William Bader changed: What|Removed |Added CC||williambader at hotmail dot com --- Comment #17 from William Bader --- Something similar to this might be back in gcc 10. I have gcc-10.2.1-9.fc32.x86_64 (gcc 10.2.1 from Fedora 32) and it also happens on gcc-10.2.0 built from source on CentOS 6.10. I have a 64 bit CPU, but I am building a 32 bit executable. I have a 30K line C module that misbehaves with "-O1 -fcaller-saves -fexpensive-optimizations". It works with less optimization (-O1, -O0, or either of -fcaller-saves or -fexpensive-optimizations removed). It works under under valgrind (and does not show any uninitialized variables or memory overwrites). I have debug code like "if (debug) fprintf(stderr, ...);" It works if I set debug to 1. It also works if I go to any of several debug statements and change "if (debug)" to "if (debug || 1)". It seems as if one of the local variables is getting messed up, and either the preparation or clean up after a fprintf() call invalidates the register with the variable or gets a fresh copy from the stack. I suppose that it would be impossible to track down without an example, but if anyone has a similar problem with the combination of 32 bit Intel + -O1 + -fcaller-saves + -fexpensive-optimizations, maybe this comment will add another data point, and if there is a patch, I could try to build it.
[Bug rtl-optimization/89965] [8 Regression] wrong code with -O -mtune=nano-x2 -fcaller-saves -fexpensive-optimizations -fno-tree-dce -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89965 --- Comment #18 from William Bader --- I did a bisection for the bug from my previous comment (which is still present in the current gcc 11 in master): 058e97ecf33ad0dfd926b3876a4bcf59ac9556ff is the first bad commit commit 058e97ecf33ad0dfd926b3876a4bcf59ac9556ff Author: Vladimir Makarov Date: Tue Aug 26 12:39:58 2008 + `git diff '058e97ecf33ad0dfd926b3876a4bcf59ac9556ff^!' | wc -l` shows 16192 lines. gcc/caller-save.c has a lot of changes. I want it fixed in the current gcc. I don't care about gcc 4, other than that the git bisect found that the bug was introduced in a commit to gcc 4. Is it worth trying to fix it in gcc 4, or would that just waste time making a patch that would not apply to the current gcc?
[Bug c/99621] New: [5-11 REGRESSION] [bisected to 058e97ecf33ad0dfd926b3876a4bcf59ac9556ff] regression with -m32 -O1 -fcaller-saves -fexpensive-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621 Bug ID: 99621 Summary: [5-11 REGRESSION] [bisected to 058e97ecf33ad0dfd926b3876a4bcf59ac9556ff] regression with -m32 -O1 -fcaller-saves -fexpensive-optimizations Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: williambader at hotmail dot com Target Milestone: --- Created attachment 50402 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50402&action=edit C program processed by creduce and reformatted gcc generates incorrect code with -m32 -O1 -fcaller-saves -fexpensive-optimizations. It happens in the current git master (which is gcc 11) but dates back to gcc 4. I have a function in a large program that parses postscript. Adding any debug printfs or even a call to an empty function in another compilation module fixes it. I tracked it down to a combination of -m32 -O1 -fcaller-saves -fexpensive-optimizations. I made a small test and used it to do a gcc bisection. The bisection found 058e97ecf33ad0dfd926b3876a4bcf59ac9556ff , which is 16192 lines long. The commit makes heavy changes to gcc/caller-save.c, which is probably the problem because the bug requires -fcaller-saves (one of the optimizations included in -O2) and because adding a call to an empty function makes it work. I ran the test program through creduce, and that is what I am posting, along with a data file that it reads. In the full program, when I compile with the options to trigger the problem plus -S with and without an extra function call and then compare the results, I get --- bad.s 2021-03-15 20:06:27.701846497 + +++ good.s 2021-03-15 20:06:18.305695766 + @@ -2068,8 +2068,10 @@ jne .L570 fstp%st(0) .L197: + fstpl -13440(%ebp) + callgcc_bug_fix fldl-13512(%ebp) - fxch%st(1) + fldl-13440(%ebp) fucomi %st(1), %st fstp%st(1) jp .L198 It looks like it does the same thing, but I haven't written Intel assembly since MSDOS days. Both good and bad compilations run clean with valgrind and with bounds-checking-gcc-4.0.4. I also get the expected good results with clang. The strangest part is that a bad executable gets good results under valgrind.
[Bug rtl-optimization/99621] [5-11 REGRESSION] [bisected to 058e97ecf33ad0dfd926b3876a4bcf59ac9556ff] regression with -m32 -O1 -fcaller-saves -fexpensive-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621 --- Comment #1 from William Bader --- Created attachment 50403 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50403&action=edit Data file that the test program reads. postscript test file compressed with bzip2. It needs to be uncompresses. The test program has the filename hard-coded in one of the last lines. The test program does not take any command line options.
[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621 --- Comment #5 from William Bader --- `gcc -S -m32 -O2 bfinal-format.c` with Fedora 32 gcc 10.2.1 gives a section similar to one in my first comment. In particular, it calls fucomi "floating unordered compare of st(0) and st(i)" and then fstp "floating store of st(0) and then pop fpu stack". fstp can change the condition registers set by fucomi. It sets C1 for stack underflow, and its actions on C0, C2, and C3 are undefined. Does every place that generates fstp in config/i386/i386.c know that it can modify the C flags? Maybe the bad executable still works correctly in valgrind because valgrind's emulation of fstp doesn't trash the C flags. .L42: testl %esi, %esi je .L43 fldl8(%esp) faddl (%esp) fstpl 8(%esp) .L43: fldz fldl16(%esp) fucomi %st(1), %st fstp%st(1) jp .L105 jne .L106
[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621 --- Comment #7 from William Bader --- >Are you sure this just isn't an excess precision problem in all the floating >point calculations? I am pretty sure that it isn't a precision problem because the original program is parsing numbers from postscript, and they are all in a reasonable range between 0 and 3000 with at most 4 decimal places. >-mfpmath=sse -msse2 makes it go away, -fexcess-precision=standard too. >Why is 5167 bad but both 4806 and 5749 I'm getting with other options are good? The original program makes list with the starting Y position of each line. The buffer ends up 4287 when it runs correctly and 5167 when it fails. I cut the program down with creduce, targeting 5167. creduce eliminated the saves of Y position to the buffer. I don't think that it is a precision problem because the output would still work if it was off by a little bit. Also, the original program works correctly with -m32 and -m64 with various options and with clang with various options. If fails only with gcc -m32 -O2. A precision problem would probably give different results with different optimization levels, different architectures, or different compilers. Also, the original program has an #if that calls an empty function. Enabling that call makes it work with gcc -m32 -O2. I think that is a strong sign that it is not a precision error. If you want, I can post the program before I fed it to creduce. It is 962 lines and is human-readable.
[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
--- Comment #8 from William Bader ---
Created attachment 50404
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50404&action=edit
example program before creduce
This is the example that I cut from a much larger module. The problematic area
is around the line `#if DBUG_FIX`.
$ rm a.out ; gcc -Wall -O9 gcc-bug1-init.c ; a.out # ok in m64
len 4287, good
$ rm a.out ; gcc -m32 -Wall -O9 gcc-bug1-init.c ; a.out # fails in m32 -O9
len 5167, expected bad
$ rm a.out ; gcc -m32 -Wall -O0 gcc-bug1-init.c ; a.out # ok in m32 -O0
len 4287, good
$ rm a.out ; gcc -m32 -Wall -O9 -DBUG_FIX=1 gcc-bug1-init.c gcc-bug1b.c ; a.out
# ok in m32 -O9 calling an empty function
gcc-bug1-init.c: In function ‘find_ad_image_breaks’:
gcc-bug1-init.c:756:4: warning: implicit declaration of function ‘gcc_bug_fix’
[-Wimplicit-function-declaration]
756 |gcc_bug_fix();
|^~~
len 4287, good
$ cat gcc-bug1b.c
void gcc_bug_fix(void) { }
$ rm a.out ; clang -m32 -Wall -O3 gcc-bug1-init.c ; a.out # ok in clang
gcc-bug1-init.c:154:19: warning: illegal character encoding in string literal
[-Winvalid-source-encoding]
memcmp(buf, COREL_HEADER_STRING, COREL_HEADER_STRING_LEN) != 0) {
^~~
gcc-bug1-init.c:130:30: note: expanded from macro 'COREL_HEADER_STRING'
#define COREL_HEADER_STRING "" /* start of header
*/
^~~~
1 warning generated.
len 4287, good
$ uname -a
Linux laptop 5.10.22-100.fc32.x86_64 #1 SMP Tue Mar 9 17:40:24 UTC 2021 x86_64
x86_64 x86_64 GNU/Linux
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20201125 (Red Hat 10.2.1-9) (GCC)
[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621 --- Comment #10 from William Bader --- The program before creduce has debug code. Setting the variable to print the debug code makes the program work. Usually for something like this, I would put in debug code and see where the good and bad versions first differ, but that doesn't work because any call to an external function (even to an empty function) makes the program work. That is why I first suspected it was related to -fcaller-saves. In MSDOS days, stdio data was often in low memory, and null pointer references would sometimes get into stdio buffers, and adding a printf would keep it from doing damage, but I do not think that is the case with this program because just calling a an empty function makes it work. Also, the program runs cleanly in valgrind, gcc -fsanitize=undefined, and bounds-checking-gcc http://williambader.com/bounds/example.html and neither gcc, gcc -fanalyzer, or clang give warnings about uninitialized variables.
[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621 --- Comment #12 from William Bader --- >I modified the file to: Sorry about that. I hadn't originally intended to post that file, and I forgot to clean it up. >len 9, unknown bad That means that the data file isn't valid. I posted a binary file that needs to be uncompressed by bzip2 to make a viewable EPSF (eps with an embedded TIFF preview). The program needs the uncompressed file. I had to compress it to get under the byte limit for attachments. The buffer that the program generates has a count and then a list of Y positions of lines. A length of 9 is probably just the count and one Y position of 0 from not being able to parse the file. I cut it from a much larger program, and I removed some of the error checks. My guess is that the test program was looking at the compressed file or that the decompression was done in text mode on a system that converts to msdos line endings. This is what the data file should be $ ls -l 4329652-1.eps -rw-rw-rw- 1 william william 32 Mar 17 09:09 4329652-1.eps $ sum 4329652-1.eps 21790 1 $ md5sum 4329652-1.eps 3b34996094eb7f27ae046d9cae25587e 4329652-1.eps
[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621 --- Comment #14 from William Bader --- >It seems you attached a different file then: Sorry. I was testing how the 9 result came out, and I put in a small file. I've been up all night. It is 9:30am my time. This is the real file. It looks like it matches your file. $ ls -l 4329652-1.eps -r--r--r-- 1 william william 2134013 Mar 16 23:05 4329652-1.eps $ sum 4329652-1.eps 32813 2084 $ md5sum 4329652-1.eps 25607f50713e15f2bae5c322b95a8014 4329652-1.eps
[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621 --- Comment #16 from William Bader --- Is your pr99621-2.c somewhere that I can look at it? I tried downloading all of the attachments, and it all works for me, on my Fedora 32 laptop and on a CentOS 6 test server.
[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621 --- Comment #18 from William Bader --- Created attachment 50405 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50405&action=edit the example program with the binary string constant replaced Thanks for posting it. Your copy of the example C program was corrupted. The example program has binary text at line 130: #define COREL_HEADER_STRING should define xC5 xD0 xD3 xC6 in pr99621-2.c, they have been encoded as UTF-8. I changed the constant to use "\xC5\xD0\xD3\xC6" I think that in one of the comments, I showed a clang diagnostic complaining about that constant. In addition, I removed the path from the file name at the end. Also, if you are not on Linux, the second parameter to the fopen() at line 218 might need to be changed from "r" to "rb".
[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99621
--- Comment #24 from William Bader ---
Jakub was right. I didn't understand what he meant at first. Sorry about that.
I can confirm `gcc -m32 -O9 -fexcess-precision=standard gcc-bug1-init.c` on the
original example works correctly for me.
If I change line 758 (the line after #if BUG_FIX) from
if (new_qxd4_y == cur_qxd4_y && new_qxd4_x > cur_qxd4_x) {
to
if (new_qxd4_y >= cur_qxd4_y - 0.001 && new_qxd4_y <= cur_qxd4_y + 0.001 &&
new_qxd4_x > cur_qxd4_x) {
then it also works.
Years ago I did scientific programming in fortran, and I should have remembered
from that never to compare two real numbers for equality.
