[Bug c/44420] [feature request] Warn for certain integer overflows
--- Comment #4 from fm3 at os dot inf dot tu-dresden dot de 2010-06-08 06:19 --- Yes, you are right. This is a duplicate. Thanks. -- fm3 at os dot inf dot tu-dresden dot de changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44420
[Bug middle-end/44420] New: [feature request] Warn for certain integer overflows
This is a follow-up to http://gcc.gnu.org/ml/gcc-help/2010-06/msg5.html : Consider the following case: uint32_t foo, bar; ... foo = bar 20; Of course, this operation can overflow and warning about this probably does not make sense as the programmer should be aware of this case. However, a warning in the following case could be appropriate IMO: uint32_t bar; uint64_t foo; ... foo = bar 20; The intension is to catch the overflow case, therefore the assignment to a 64-bit variable. The intended code would be uint32_t bar; uint64_t foo; ... foo = (uint64_t)bar 20; I think it would be a big help if gcc could warn in the 2nd case. -- Summary: [feature request] Warn for certain integer overflows Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fm3 at os dot inf dot tu-dresden dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44420
[Bug target/37651] New: __sync_bool_compare_and_swap creates wrong code with -fPIC
The following example dumps a core if compiled with -march=i586 -fPIC:
#include stdint.h
int main(void)
{
static uint64_t volatile s_u64;
__sync_bool_compare_and_swap(s_u64, 0, 0);
}
The reason is that %ebx will be used as pointer for the memory variable.
I can reproduce this bug so far with gcc-4.2 and gcc-4.3.2 (both Debian Sid).
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1'
--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 --enable-targets=all --enable-cld
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1)
--
Summary: __sync_bool_compare_and_swap creates wrong code with -
fPIC
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fm3 at os dot inf dot tu-dresden dot de
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37651
[Bug c++/36474] New: gcc takes forever to compile a certain file
Compiling VirtualBox with gcc version 4.3.1 the C++ compiler takes forever running at 100% when compiling the file VBoxManage.c. It compiles fine with -O0 but takes forever with -O1. I will attach the pre-processed file. This is a regression since some weeks, sorry, I cannot report the exact version of gcc 4.3 when it started to fail. Older gcc compilers work. $ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-1' --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 --enable-targets=all --enable-cld --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.1 (Debian 4.3.1-1) -- Summary: gcc takes forever to compile a certain file Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fm3 at os dot inf dot tu-dresden dot de GCC build triplet: i386-pc-linux-gnu GCC host triplet: i386-pc-linux-gnu GCC target triplet: i386-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36474
[Bug c++/36474] gcc takes forever to compile a certain file
--- Comment #1 from fm3 at os dot inf dot tu-dresden dot de 2008-06-09 10:15 --- Created an attachment (id=15740) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15740action=view) VBoxManage.cpp (preprocessed with -E -dD and compressed) from current VirtualBox SVN. If you compile this file with g++ -c -o foo.o -O0 -fshort-wchar VBoxManage.cpp it will be compiled successfully. It you compile it with g++ -c -o foo.o -O1 -fshort-wchar VBoxManage.cpp (gcc 4.3.1) the g++ compiler will loop forever (aborted after 5 minutes). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36474
[Bug c++/25759] New: Missing Documentation: __attribute__((packed)) attached to a class definiton
The gcc manual does not describe the behaviour of __attribute__((packed))
attached to a class definition, e.g.
class foo
{
unsigned char;
unsigned long;
} __attribute__((packed));
As far as I have observed, the behaviour is the same if foo would be declared
as struct. The gcc manual describes packed only for variables, structs and
enums.
--
Summary: Missing Documentation: __attribute__((packed)) attached
to a class definiton
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fm3 at os dot inf dot tu-dresden dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25759
[Bug c/22141] New: Missing optimization when storing structures
In the attached example, the store of type_t is not optimized by gcc. Instead
of storing one 32-bit value, four 8-bit values are stored.
gcc-4.0.1 produces the following code:
/home/fm3/foo.c:16
80483b7: c6 05 13 96 04 08 04movb $0x4,0x8049613
80483be: c6 05 12 96 04 08 03movb $0x3,0x8049612
80483c5: c6 05 11 96 04 08 02movb $0x2,0x8049611
80483cc: c6 05 10 96 04 08 01movb $0x1,0x8049610
gcc-3.4.5 produces the following code:
/home/fm3/foo.c:16
8048391: ba 01 02 03 04 mov$0x4030201,%edx
/home/fm3/foo.c:15
8048396: 89 e5 mov%esp,%ebp
8048398: 83 ec 18sub$0x18,%esp
804839b: 83 e4 f0and$0xfff0,%esp
804839e: 83 ec 10sub$0x10,%esp
/home/fm3/foo.c:16
80483a1: 89 15 1c 96 04 08 mov%edx,0x804961c
(better)
gcc-2.95.4 produces the following code:
/home/fm3/foo.c:16
80483f7: c7 05 84 96 04 08 01movl $0x4030201,0x8049684
80483fe: 02 03 04
(best because no register allocation)
The example:
#include stdio.h
typedef struct
{
unsigned char a;
unsigned char b;
unsigned char c;
unsigned char d;
} type_t;
static type_t u;
int
main(void)
{
u = (type_t){ 1, 2, 3, 4};
printf(%d %d %d %d\n, u.a, u.b, u.c, u.d);
return 0;
}
gcc-4.0 -v -save-temps -g -o foo -W -Wall -Wformat=2 -O3 -Wall -W
-fomit-frame-pointer -march=pentium3 -g foo.c:
Using built-in specs.
Target: i486-linux
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls
--without-included-gettext --enable-threads=posix --program-suffix=-4.0
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--enable-mpfr --disable-werror --enable-checking=release i486-linux
Thread model: posix
gcc version 4.0.1 20050522 (prerelease) (Debian 4.0.0-9)
/usr/lib/gcc/i486-linux/4.0.1/cc1 -E -quiet -v foo.c -march=pentium3 -W -Wall
-Wformat=2 -Wall -W -fomit-frame-pointer -fworking-directory -O3
-fpch-preprocess -o foo.i
ignoring nonexistent directory
/usr/lib/gcc/i486-linux/4.0.1/../../../../i486-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/usr/lib/gcc/i486-linux/4.0.1/include
/usr/include
End of search list.
/usr/lib/gcc/i486-linux/4.0.1/cc1 -fpreprocessed foo.i -quiet -dumpbase foo.c
-march=pentium3 -auxbase foo -g -g -O3 -W -Wall -Wformat=2 -Wall -W -version
-fomit-frame-pointer -o foo.s
GNU C version 4.0.1 20050522 (prerelease) (Debian 4.0.0-9) (i486-linux)
compiled by GNU C version 4.0.1 20050522 (prerelease) (Debian
4.0.0-9).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64260
as -V -Qy --32 -o foo.o foo.s
GNU assembler version 2.15 (i486-linux-gnu) using BFD version 2.15
/usr/lib/gcc/i486-linux/4.0.1/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2 -o
foo /usr/lib/gcc/i486-linux/4.0.1/../../../../lib/crt1.o
/usr/lib/gcc/i486-linux/4.0.1/../../../../lib/crti.o
/usr/lib/gcc/i486-linux/4.0.1/crtbegin.o
-L/usr/lib/gcc/i486-linux/4.0.1 -L/usr/lib/gcc/i486-linux/4.0.1
-L/usr/lib/gcc/i486-linux/4.0.1/../../../../lib
-L/usr/lib/gcc/i486-linux/4.0.1/../../.. -L/lib/../lib -L/usr/lib/../lib foo.o
-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/lib/gcc/i486-linux/4.0.1/crtend.o
/usr/lib/gcc/i486-linux/4.0.1/../../../../lib/crtn.o
--
Summary: Missing optimization when storing structures
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fm3 at os dot inf dot tu-dresden dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i486-linux
GCC target triplet: i486-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141
[Bug c++/19605] [4.0 Regression] Wrong member offset in inherited classes
--- Additional Comments From fm3 at os dot inf dot tu-dresden dot de 2005-01-24 15:12 --- added myself as cc -- What|Removed |Added CC||fm3 at os dot inf dot tu- ||dresden dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19605
[Bug c++/19564] New: -Wparentheses and other warnings: g++ is less sensitive than gcc
g++ generates less warnings when using -Wparentheses than gcc. For instance gcc warns about if (a0 b0) ... (warning: suggest parentheses around comparison in operand of ) but g++ does not. And gcc warns about char a = 1024; (warning: overflow in implicit constant conversion) but g++ does not. -- Summary: -Wparentheses and other warnings: g++ is less sensitive than gcc Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fm3 at os dot inf dot tu-dresden dot de CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i486-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19564
[Bug c++/19565] New: g++ does not warn about overflow in conversion but gcc does
g++ does not warn if there occurs an overflow in conversion. For instance, gcc does not warn about char a = 1024; but gcc does. -- Summary: g++ does not warn about overflow in conversion but gcc does Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fm3 at os dot inf dot tu-dresden dot de CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i486-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19565
