[Bug middle-end/40981] aermod.f90 ICEs on -O2 -fgraphite-identity -floop-strip-mine
--- Comment #23 from bagnara at cs dot unipr dot it 2009-08-14 22:49 --- What you can do is to use ppl_Linear_Expression_OK() and ppl_Pointset_Powerset_C_Polyhedron_OK() to make sure you are not working with corrupted objects. If both the *_OK() functions evaluate to true, you could use the functions ppl_Linear_Expression_ascii_dump() and ppl_Pointset_Powerset_C_Polyhedron_ascii_dump() and attach the resulting output here: this should allow us to reproduce the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40981
[Bug target/37581] IEEE inexact-flag not working on the Alpha
--- Comment #4 from bagnara at cs dot unipr dot it 2009-01-24 08:08 --- I don't know why the bug was closed: I can confirm the erroneous behavior is present also in GCC 4.3.2. -- bagnara at cs dot unipr dot it changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37581
[Bug target/37661] long double is buggy on sparc64
--- Comment #2 from bagnara at cs dot unipr dot it 2008-09-27 18:03 --- This is good news. However, is there any known workaround for versions before 4.4? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37661
[Bug target/37661] New: long double is buggy on sparc64
$ cat b.cc #include using namespace std; void init(long double& n, int k) { n = k; } int main() { long double n; init(n, -2); cout << n << endl; } $ g++ b.cc ; ./a.out -2 $ g++ -m64 b.cc ; ./a.out 4.29497e+09 $ g++ -O1 -m64 b.cc ; ./a.out -2 $ g++ -O2 -m64 b.cc ; ./a.out -2 $ g++ -O3 -m64 b.cc ; ./a.out -2 $ g++ -mhard-quad-float -m64 b.cc ; ./a.out -2 $ gcc -v Using built-in specs. Target: sparc-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-2' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --with-cpu=v8 --with-long-double-128 --enable-checking=release --build=sparc-linux-gnu --host=sparc-linux-gnu --target=sparc-linux-gnu Thread model: posix gcc version 4.3.1 (Debian 4.3.1-2) $ cat /proc/cpuinfo cpu : TI UltraSparc II (BlackBird) fpu : UltraSparc II integrated FPU prom: OBP 3.16.1 1999/04/19 07:55 type: sun4u ncpus probed: 2 ncpus active: 2 D$ parity tl1 : 0 I$ parity tl1 : 0 Cpu0ClkTck : 17d78400 Cpu1ClkTck : 17d78400 MMU Type: Spitfire State: CPU0: online CPU1: online -- Summary: long double is buggy on sparc64 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bagnara at cs dot unipr dot it GCC host triplet: sparc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37661
[Bug target/37581] IEEE inexact-flag not working on the Alpha
--- Comment #1 from bagnara at cs dot unipr dot it 2008-09-19 07:04 --- Created an attachment (id=16359) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16359&action=view) Assembly code generated with g++ -S -mieee-with-inexact sf.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37581
[Bug target/37581] New: IEEE inexact-flag not working on the Alpha
The following shows a problem on the Alpha whereby the division 2/3 made on floats is flagged as exact. Here are the details: $ cat sf.cc #include #include int main() { float x = 2; float y = 3; feclearexcept(FE_INEXACT); x = x / y; printf("%d %.1000g\n", fetestexcept(FE_INEXACT) != 0, x); } $ g++ -v Using built-in specs. Target: alpha-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-libssp --with-long-double-128 --enable-checking=release --build=alpha-linux-gnu --host=alpha-linux-gnu --target=alpha-linux-gnu Thread model: posix gcc version 4.2.4 (Debian 4.2.4-3) $ g++ -mieee-with-inexact sf.cc $ ./a.out 0 0.66686534881591796875 $ cat /proc/cpuinfo cpu : Alpha cpu model : EV56 cpu variation : 7 cpu revision: 0 cpu serial number : system type : Rawhide system variation: Tincup system revision : 0 system serial number: AY74642662 cycle frequency [Hz]: 399642346 est. timer frequency [Hz]: 1200.00 page size [bytes] : 8192 phys. address bits : 40 max. addr. space # : 127 BogoMIPS: 705.16 kernel unaligned acc: 0 (pc=0,va=0) user unaligned acc : 31 (pc=2074c18,va=87) platform string : AlphaServer 1200 5/400 4MB cpus detected : 1 cpus active : 1 cpu active mask : 0001 L1 Icache : 8K, 1-way, 32b line L1 Dcache : 8K, 1-way, 32b line L2 cache: 96K, 3-way, 64b line L3 cache: 4096K, 1-way, 64b line $ I attach the generated assembly code, which shows this is not a constant propagation issue. -- Summary: IEEE inexact-flag not working on the Alpha Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bagnara at cs dot unipr dot it GCC host triplet: alphaev56-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37581
[Bug c++/37413] New: Spurious warning about undefining "__STDC_LIMIT_MACROS"
$ cat bug.cc #define __STDC_LIMIT_MACROS #ifdef __STDC_LIMIT_MACROS #undef __STDC_LIMIT_MACROS #endif $ g++ -W -Wall -c bug.cc bug.cc:4:8: warning: undefining "__STDC_LIMIT_MACROS" $ g++ -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20070626 (Red Hat 4.1.2-13) $ -- Summary: Spurious warning about undefining "__STDC_LIMIT_MACROS" Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bagnara at cs dot unipr dot it GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37413
[Bug c++/33802] g++ says `z' is used uninitialized but this is not true
--- Comment #7 from bagnara at cs dot unipr dot it 2008-01-07 19:32 --- Created an attachment (id=14894) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14894&action=view) New testcase showing the problem with GCC 4.3.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33802
[Bug c++/33802] g++ says `z' is used uninitialized but this is not true
--- Comment #6 from bagnara at cs dot unipr dot it 2008-01-07 19:30 --- Please, forget comment #5. Let me try again. Indeed the testcase does not compile with GCC 4.3 (while compiling perfectly with GCC 4.0, 4.1 and 4.2). For some reason, GCC 4.3 dislikes the implementation of the STL that is shipped with previous versions. I have thus reconstructed the testcase by compiling the non-preprocessed sources with GCC version 4.3.0 20071228. Here is what happens (note that, differently from what was the case, now the warning is give three times in a row): $ bunzip2 bug2.cc.bz2 $ md5sum bug2.cc 63b807d5f4dc8d88c00d84a2e951f048 bug2.cc $ g++ -W -Wall -Wno-parentheses -O2 -c bug2.cc bug.cc: In function void Parma_Polyhedra_Library::add_mul_assign(Parma_Polyhedra_Library::Checked_Number&, const Parma_Polyhedra_Library::Checked_Number&, const Parma_Polyhedra_Library::Checked_Number&) [with T = long int, Policy = Parma_Polyhedra_Library::Checked_Number_Default_Policy]: bug.cc:3675: warning: z is used uninitialized in this function bug.cc:3669: note: z was declared here bug.cc: In member function Parma_Polyhedra_Library::Poly_Gen_Relation Parma_Polyhedra_Library::Octagonal_Shape::relation_with(const Parma_Polyhedra_Library::Generator&) const [with T = __gmp_expr<__mpq_struct [1], __mpq_struct [1]>]: bug.cc:3669: warning: z may be used uninitialized in this function bug.cc:3669: note: z was declared here bug.cc:3669: warning: z may be used uninitialized in this function bug.cc:3669: note: z was declared here bug.cc:3669: warning: z may be used uninitialized in this function bug.cc:3669: note: z was declared here $ g++ --version g++ (GCC) 4.3.0 20071228 (experimental) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33802
[Bug c++/33802] g++ says `z' is used uninitialized but this is not true
--- Comment #5 from bagnara at cs dot unipr dot it 2008-01-07 19:20 --- Indeed the testcase does not compile with GCC 4.3 (while compiling perfectly with GCC 4.0, 4.1 and 4.2). For some reason, GCC 4.3 dislikes the implementation of the STL that is shipped with previous versions. I have thus reconstructed the testcase by compiling the non-preprocessed sources with GCC version 4.3.0 20071228. Here is what happens (note that, differently from what was the case, now the warning is give three times in a row): $ bunzip2 bug2.cc.bz2 $ md5sum bug2.cc 63b807d5f4dc8d88c00d84a2e951f048 bug2.cc $ g++ -W -Wall -Wno-parentheses -O2 -c bug.cc bug.cc: In function void Parma_Polyhedra_Library::add_mul_assign(Parma_Polyhedra_Library::Checked_Number&, const Parma_Polyhedra_Library::Checked_Number&, const Parma_Polyhedra_Library::Checked_Number&) [with T = long int, Policy = Parma_Polyhedra_Library::Checked_Number_Default_Policy]: bug.cc:3675: warning: z is used uninitialized in this function bug.cc:3669: note: z was declared here bug.cc: In member function Parma_Polyhedra_Library::Poly_Gen_Relation Parma_Polyhedra_Library::Octagonal_Shape::relation_with(const Parma_Polyhedra_Library::Generator&) const [with T = __gmp_expr<__mpq_struct [1], __mpq_struct [1]>]: bug.cc:3669: warning: z may be used uninitialized in this function bug.cc:3669: note: z was declared here bug.cc:3669: warning: z may be used uninitialized in this function bug.cc:3669: note: z was declared here bug.cc:3669: warning: z may be used uninitialized in this function bug.cc:3669: note: z was declared here $ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33802
[Bug c++/33802] g++ says `z' is used uninitialized but this is not true
--- Comment #1 from bagnara at cs dot unipr dot it 2007-10-17 18:40 --- Created an attachment (id=14366) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14366&action=view) (Big) testcase that allows to reproduce -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33802
[Bug c++/33802] New: g++ says `z' is used uninitialized but this is not true
For the attached testcase, g++ gives a warning saying "`z' is used uninitialized in this function" (_is_ used uninitialized, not _may be_ used uninitialized) in the statement marked with (***) below. However, `z' is indeed initialized by the mul() function template, which takes the first argument by (non-const) reference: template inline Result add_mul_int(Type& to, const Type x, const Type y, Rounding_Dir dir) { Type z; Result r = mul(z, x, y, dir); switch (r) { case V_NEG_OVERFLOW: case V_LT: if (to <= 0) { to = z; (***) return r; } To reproduce: $ bunzip2 bug.cc.bz2 $ md5sum bug.cc bb3e86d1d865d1b661dd86da3456c909 bug.cc $ g++ -Wall -O2 -c bug.cc bug.cc: In function void Parma_Polyhedra_Library::add_mul_assign(Parma_Polyhedra_Library::Checked_Number&, const Parma_Polyhedra_Library::Checked_Number&, const Parma_Polyhedra_Library::Checked_Number&) [with T = long int, Policy = Parma_Polyhedra_Library::Checked_Number_Default_Policy]: bug.cc:37941: warning: z is used uninitialized in this function $ g++ -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20070626 (Red Hat 4.1.2-13) $ The file bug.cc.t28.ssa is 944683 bytes once compressed: I will attach it if required. -- Summary: g++ says `z' is used uninitialized but this is not true Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bagnara at cs dot unipr dot it GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33802
[Bug middle-end/33675] Badly optimized negations on x86 with -frounding-math
--- Comment #2 from bagnara at cs dot unipr dot it 2007-10-06 13:03 --- I don't understand. Do you mean that what I consider the natural compilation of that piece of code (the shorter assembly listing) is incorrect? In other words: do you think that the shorter assembly listing does not properly honor the volatile qualifier? If so, why? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33675
[Bug middle-end/21032] [4.0 Regression] With -frounding-math, incorrectly reorders unary minus
--- Comment #25 from bagnara at cs dot unipr dot it 2007-10-06 09:51 --- Done: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33675 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug c/33675] New: Badly optimized negations on x86 with -frounding-math
If you compile the function void assign2(float* a, double b) { volatile float v = -b; *a = -v; } you will see that GCC 4.1.2, e.g., at -O2, produces fldl12(%ebp) fchs movl8(%ebp), %eax fstps -20(%ebp) flds-20(%ebp) fstps -4(%ebp) flds-4(%ebp) fchs fstps (%eax) insted of simply fldl12(%ebp) fchs fstps -4(%ebp) flds-4(%ebp) fchs fstps (%eax) -- Summary: Badly optimized negations on x86 with -frounding-math Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bagnara at cs dot unipr dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33675
[Bug middle-end/21032] [4.0 Regression] With -frounding-math, incorrectly reorders unary minus
--- Comment #23 from bagnara at cs dot unipr dot it 2007-09-10 12:32 --- My fault: I forgot to use the -frounding-math option. So, for the "wrong-code" aspect there is no problem. But the "missed-optimization" bit is still there: why do we have fldl12(%ebp) fchs movl8(%ebp), %eax fstps -20(%ebp) flds-20(%ebp) fstps -4(%ebp) flds-4(%ebp) fchs fstps (%eax) insted of simply fldl12(%ebp) fchs fstps -4(%ebp) flds-4(%ebp) fchs fstps (%eax) ? -- bagnara at cs dot unipr dot it changed: What|Removed |Added CC||abramobagnara at tin dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug middle-end/21032] [4.0 Regression] With -frounding-math, incorrectly reorders unary minus
--- Comment #21 from bagnara at cs dot unipr dot it 2007-09-05 08:22 --- It seems the bug has reappeared in GCC 4.1.2. Here is what I obtain: .file "bug.c" .text .p2align 4,,15 .globl assign2 .type assign2, @function assign2: pushl %ebp movl%esp, %ebp subl$20, %esp fldl12(%ebp) fstps -20(%ebp) movl8(%ebp), %eax flds-20(%ebp) fchs fstps -4(%ebp) flds-4(%ebp) fchs fstps (%eax) leave ret .size assign2, .-assign2 .ident "GCC: (GNU) 4.1.2 20070626 (Red Hat 4.1.2-13)" .section.note.GNU-stack,"",@progbits -- bagnara at cs dot unipr dot it changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug target/30484] New: Miscompilation of remainder expressions on CPUs of the i386 family
The program below shows (at all the optimization levels) a miscompilation of the remainder expression that causes INT_MIN % -1 to cause a SIGFPE on CPUs of the i386 family. #include #include int minus_one(int n) { return (n+1)*(n-1)-n*n; } void p(int x, int y) { int z = x % y; printf("%d %% %d -> %d\n", x, y, z); } int main(int argc, char** argv) { p(INT_MIN, minus_one(argc)); } For simpler programs, the behavior depends on the ability of the optimizer to realize that the divisor is -1, in which case the compiler evaluates the remainder expression (to 0, at compile-time) and no signal is raised. Since the remainder is always defined, this violates the C standard. By the way, the Ariane 5 Flight 501 crash was caused by an unexpected exception (http://en.wikipedia.org/wiki/Ariane_5_Flight_501). -- Summary: Miscompilation of remainder expressions on CPUs of the i386 family Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bagnara at cs dot unipr dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30484
[Bug c++/30059] Wrong function selected
--- Comment #1 from bagnara at cs dot unipr dot it 2006-12-03 16:39 --- Created an attachment (id=12732) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12732&action=view) Program exhibiting the described behavior -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30059
[Bug c++/30059] New: Wrong function selected
The attached program should print void func(int &, int &) void func(int &, int &) Instead it prints void func(T&, T&) [with T = int] void func(int&, int&) This causes efficiency bugs that are very difficult to detect. -- Summary: Wrong function selected Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bagnara at cs dot unipr dot it GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30059
[Bug c++/30042] ICE on invalid code
--- Comment #1 from bagnara at cs dot unipr dot it 2006-12-01 17:25 --- Created an attachment (id=12725) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12725&action=view) The file g++ asked me to attach. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30042
[Bug c++/30042] New: ICE on invalid code
g++ --save-temps -W -Wall bug.cc bug.cc: In function `void p(T&)': bug.cc:10: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla> for instructions. Preprocessed source stored into /tmp/ccGdoZOR.out file, please attach this to your bugreport. -- Summary: ICE on invalid code Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bagnara at cs dot unipr dot it GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30042
[Bug c++/29803] Program links only at -O2 or above
--- Comment #2 from bagnara at cs dot unipr dot it 2006-11-11 20:26 --- This is not a duplicate of 23147: it raises a couple of issues that have nothing to do with that bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29803
[Bug c++/29803] New: Program links only at -O2 or above
// The optimization level should not prevent a conforming program // to compile and link correctly. This program shows that this // is not the case for GCC 4.1.1. template struct c { static const int a = 3; static const int b = 4; }; // If the following `#if 0' is turned into `#if 1', then the program // links only with -O2 and higher optimization levels. #if 0 int not_ok() { return c().a; } int not_ok(bool b) { return b ? c::a : c::b; } #endif // The following functions should be completely equivalent to the // above ones, but these do not cause any linking problem, whatever // the optimization level is. int ok() { // How is this different from `return c().a'? return c::a; } int ok(bool b) { // How is this different from `return b ? c::a : c::b'? if (b) return c::a; else return c::b; } int main(int, char**) { } -- Summary: Program links only at -O2 or above Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bagnara at cs dot unipr dot it GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29803
[Bug middle-end/27173] ICE with -O -ftrapv
--- Comment #1 from bagnara at cs dot unipr dot it 2006-04-14 20:22 --- Created an attachment (id=11274) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11274&action=view) Testcase that allows to reproduce the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27173
[Bug middle-end/27173] New: ICE with -O -ftrapv
The attached program causes an ICE when compiled with both -O and -ftrapv: $ g++ -O -ftrapv -c Linear_System.ii g++: Internal error: Segmentation fault (program cc1plus) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: ICE with -O -ftrapv Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bagnara at cs dot unipr dot it GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27173
[Bug c/12963] Wrong and misleading warning encourages writing non-portable code
--- Comment #19 from bagnara at cs dot unipr dot it 2006-01-25 11:39 --- Just a small update. On one of our projects we have now thousands of warnings on the test "x < 0" for the function below, when Type is instantiated to an unsigned integral type: template inline Result sgn_generic(const Type& x) { if (x < 0) return V_LT; if (x > 0) return V_GT; return V_EQ; } The net result is that some of us started using "-w" or stopped paying attention to warnings, and, as a consequence bugs are creeping in at a much increased rate. Please, give us a way to at least turn off that warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963
[Bug middle-end/21032] GCC 3.4.3 wrongly reorders floating-point operations
--- Comment #7 from bagnara at cs dot unipr dot it 2005-12-20 07:49 --- I can confirm both problems (incorrect reordering and performance regression) are present in GCC version 4.0.2 and version 4.2.0 20051209 (experimental). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug c++/24273] New: g++ misses a warning that gcc, instead, gives
$ cat pointless_volatile.c volatile double limit_precision(double v) { volatile double x = v; return x; } $ gcc -Wall -c pointless_volatile.c pointless_volatile.c:1: warning: type qualifiers ignored on function return type $ g++ -Wall -c pointless_volatile.c $ g++ -Wall -W -pedantic -c pointless_volatile.c $ This is strange, because the reasons for giving a warning are good in C++ as they are good in C. See Section 3.10 of the C++ standard: Point 6: The result of calling a function that does not return a reference is an rvalue. User defined operators are functions, and whether such operators expect or yield lvalues is determined by their parameter and return types. Point 9: Class rvalues can have cv-qualified types; non-class rvalues always have cv-unqualified types. Rvalues shall always have complete types or the void type; in addition to these types, lvalues can also have incomplete types. -- Summary: g++ misses a warning that gcc, instead, gives Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bagnara at cs dot unipr dot it GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24273
[Bug middle-end/21067] Excessive optimization of floating point expression
--- Additional Comments From bagnara at cs dot unipr dot it 2005-04-17 08:52 --- Subject: Re: Excessive optimization of floating point expression pinskia at gcc dot gnu dot org wrote: > Note GCC does not know about the rounding mode, This seems a good reason not to attempt optimizations that only work with a given rounding mode. > in fact the round mode is only changeable in C99 > by the #pragma which GCC does not do right now and I thought that is a > different PR already. I do not see the connection with the #pragma you are talking about. IMHO, a program that uses the services of , which is covered by section 7.6 of the C99 standard, is a perfectly legal C99 program, and thus deserves to be compiled correctly as prescribed by that standard. Am I missing something? All the best, Roberto -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21067
[Bug middle-end/21067] New: Excessive optimization of floating point expression
Compiling the following with GCC 3.4.3 (with "gcc -O2 -S file.c") float mul2(float a, float b) { float v = -a * b; return -v; } produce the erroneous code pushl %ebp movl%esp, %ebp flds8(%ebp) fmuls 12(%ebp) popl%ebp ret where the sign changes have been erroneously elided. Notice that, depending on the rounding mode in effect, this produces the wrong results. Strangely enough, the code produced for float div2(float a, float b) { float v = -a / b; return -v; } is instead correct. -- Summary: Excessive optimization of floating point expression Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bagnara at cs dot unipr dot it CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21067
[Bug middle-end/21032] GCC 3.4.3 wrongly reorders floating-point operations
--- Additional Comments From bagnara at cs dot unipr dot it 2005-04-16 12:27 --- I can add the following: 1) the bug was not present in GCC 3.3.3 and is present since version 3.4.0, so I think it qualifies as a regression; 2) the bug is also present in GCC 4.0.0 20050226 (prerelease), which compiles the code even worse than done by GCC 3.4.3 (for whatever optimization level and -march option one gives). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug middle-end/21032] GCC 3.4.3 wrongly reorders floating-point operations
--- Additional Comments From bagnara at cs dot unipr dot it 2005-04-15 07:01 --- Subject: Re: GCC 3.4.3 wrongly reorders floating-point operations pinskia at gcc dot gnu dot org wrote: > Note neg just flips a bit so it is correct anyways > and there is no loss of precession. Can you please clarify what do you mean by "correct"? I believe that: 1) The produced code is incorrect, since operations cannot be reordered that way. Notice that the compiler cannot prove that the result is the same (in fact it is not, in general, as it depends on the rounding direction). 2) A piece of standard C that, when correctly compiled, performs a double to float conversion rounding up, when the rounding mode is downward, or rounding down, when the rounding mode is upward, no longer works when compiled with GCC. So the produced code is incorrect not only from a language-lawyer point of view: I am actually obtaining the wrong results. All the best, Roberto Bagnara -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug c/21032] New: GCC 3.4.3 wrongly reorders floating-point operations
If you compile the function void assign2(float* a, double b) { volatile float v = -b; *a = -v; } you will see that GCC 3.4.3, e.g., at -O2, produces fldl12(%ebp) fstps -20(%ebp) movl8(%ebp), %eax flds-20(%ebp) fchs fstps -4(%ebp) flds-4(%ebp) fchs fstps (%eax) where the first sign change is performed /after/ reducing the precision and not /before/, as I believe it should (according to ISO/IEC 9899, 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2). The produced code seems also very badly optimized, considering that something like fldl12(%ebp) fchs fstps -4(%ebp) flds-4(%ebp) fchs fstps (%eax) would be significantly more efficient (besides being correct). The same problem can be seen with gcc-4.0.0 20050406 (Fedora Core 3). Roberto Bagnara -- Summary: GCC 3.4.3 wrongly reorders floating-point operations Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bagnara at cs dot unipr dot it CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug c++/19092] g++ accepts code that violates 14.6.4.2
--- Additional Comments From bagnara at cs dot unipr dot it 2004-12-20 18:32 --- Created an attachment (id=7784) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7784&action=view) Small program that allows to reproduce the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092
[Bug c++/19092] New: g++ accepts code that violates 14.6.4.2
The attached snippet should not compile, since foo() has internal linkage. Instead, g++ compiles it happily and without a warning even when given -Wall -W -pedantic. -- Summary: g++ accepts code that violates 14.6.4.2 Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bagnara at cs dot unipr dot it CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092
[Bug c++/18581] New: ICE in 3.4.3, regression from 3.4.2
The following snippet compiles fine with GCC versions prior to 3.4.3 and aborts with an ICE with 3.4.3: struct S { int i; int a[]; }; S v = { 0, {} }; $ g++ -V 3.4.3 -c bug.cc bug.cc:6: internal compiler error: in tree_low_cst, at tree.c:3313 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. $ g++ -V 3.4.2 -c bug.cc $ g++ -V 3.4.1 -c bug.cc $ g++ -V 3.4.0 -c bug.cc $ g++ -V 3.3.3 -c bug.cc -- Summary: ICE in 3.4.3, regression from 3.4.2 Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bagnara at cs dot unipr dot it CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18581