[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
