I found a new (small) bug in gpc compiled with gcc-4.3.5 backend following instructions of Waldek on github. hopefully it could be simply solved by who writed it
First compilation of GPC without problems on an old fedora 6 system to which I have full access and practice (same bug occurs on a recent cluster front end, but this needed more twiddlings to install it, which are irrelevant here)
$ gpc-4.3.5 -v Using built-in specs. Configured with: ../gcc-4.3.5/configure --prefix=/usr/local --program-suffix=-4.3.5 --disable-shared --enable-threads=posix --disable-nls --without-included-gettext --with-system-zlib --enable-__cxa_atexit --enable-languages=c,pascal --enable-multilib --disable-mapped-location --enable-bootstrap Thread model: posix gpc version 20070904, based on gcc-4.3.5
with only 23 "unexpected failures" for the 64 bits checks 17 32
the bug is displayed by the following minimal program
program test3;
const c = 9; n = 32- c mod 2;
begin if n = 31 then writeln('OK') else writeln('failed'); end.
$ gpc-4.3.5 test3.pas -o test3 test3.pas:0: error: constant has non-constant value
(no error or course with various older gcc-3.4.x based compilers)
The problem is not with the mod operator itself (it occurs at many places in the test suite). The bug disappear by putting c mod 2 between parentheses. For that reason, and because Waldek said on github
3) -Wparenthesis does not work with gcc-4.3.z
I tried $ gpc-4.3.5 test3.pas -o test3 -Wparentheses gpc1: warning: command line option "-Wparentheses" is valid for C/C++/ObjC/ObjC++ but not for Pascal test3.pas:0: error: constant has non-constant value
??? (My goal was to see on more complex programs if one can gain performances on the cluster with more recent gcc)
Maurice