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 -- Maurice Lombardi Laboratoire Interdisciplinaire de Physique, (ex Spectrometrie Physique) Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr