[Bug c++/38123] New: [4.3 regression] error: incorrect sharing of tree nodes ap->fp_offset = D.2748;
Compiling the attached file with latest g++ from trunk: $ ~/gcc_inst/bin/g++ /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c: In function int main(): /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c:84: warning: deprecated conversion from string constant to char* /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c:85: warning: deprecated conversion from string constant to char* /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c:88: warning: deprecated conversion from string constant to char* /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c:89: warning: deprecated conversion from string constant to char* /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c:92: warning: deprecated conversion from string constant to char* /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c:93: warning: deprecated conversion from string constant to char* /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c: In function void test(char*, __va_list_tag*): /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c:96: error: incorrect sharing of tree nodes ap->fp_offset = D.2748; *ap /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c:96: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. This is: Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --disable-multilib --disable-static --prefix=/home/edwin/gcc_inst/ --enable-languages=c,c++ Thread model: posix gcc version 4.4.0 20081114 (experimental) [trunk revision 141857] (GCC) -- Summary: [4.3 regression] error: incorrect sharing of tree nodes ap->fp_offset = D.2748; Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38123
[Bug c++/38123] [4.3 regression] error: incorrect sharing of tree nodes ap->fp_offset = D.2748;
--- Comment #1 from edwintorok at gmail dot com 2008-11-14 20:15 --- Created an attachment (id=16677) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16677&action=view) original sourcecode -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38123
[Bug c++/38123] [4.3 regression] error: incorrect sharing of tree nodes ap->fp_offset = D.2748;
--- Comment #2 from edwintorok at gmail dot com 2008-11-14 20:18 --- Created an attachment (id=16678) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16678&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38123
[Bug c++/38132] New: std::string is faster with -D_GLIBCXX_DEBUG=1 than without
basic_string.tcc contains 'extern template basic_string', which prevents
the template from being instantiated, and thus all calls to basic_string
methods remain calls even at -O3.
If I -D_GLIBCXX_DEBUG=1 _GLIBCXX_EXTERN_TEMPLATE is 0, thus it will no longer
contain 'extern template basic_string', so the body of methods will be
available, and inlining will be performed.
However _GLIBCXX_DEBUG=1 activates debug code, so I would like to be able to
get the methods inlined w/o definining debug mode.
Can the semantics of 'extern template' be changed [*] in such a way, that *if*
the body of some of the methods are suitable for inlining, they will be inlined
(and other methods won't get instantiated), and if none of the methods are
suitable, the behaviour stays as currently.
[*] by introducing a new compiler flag, that can be activated at -O3 (and maybe
-O2) at the expense of code size.
--
Summary: std::string is faster with -D_GLIBCXX_DEBUG=1 than
without
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38132
[Bug c++/38132] std::string is faster with -D_GLIBCXX_DEBUG=1 than without
--- Comment #1 from edwintorok at gmail dot com 2008-11-15 13:56 --- Created an attachment (id=16682) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16682&action=view) example to illustrate compile with g++ -O3, I get: real0m0.130s user0m0.100s sys 0m0.028s compile with g++ -D_GLIBCXX_DEBUG=1 -O3 I get: real0m0.080s user0m0.056s sys 0m0.028s If I explicitly instantiate the template, I get similar effect as of defining _GLIBCXX_DEBUG: template class basic_string; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38132
[Bug rtl-optimization/38139] New: --enable-checking=all times out during bootstrap
I tried to build a gcc 4.4.0 with --enable-checking=all but it timed out:
$ /home/edwin/gcc-obj/./prev-gcc/xgcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --disable-multilib --disable-static
--prefix=/home/edwin/gcc_inst/ --enable-languages=c,c++ --enable-checking=all
Thread model: posix
gcc version 4.4.0 20081115 (experimental) [trunk revision 141891] (GCC)
xgcc: Internal error: Killed (program cc1)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [insn-emit.o] Error 1
make[3]: *** Waiting for unfinished jobs
xgcc: Internal error: Killed (program cc1)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [insn-recog.o] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
^it was building insn-emit and insn-recog in parallel, both timed out.
I was running it under ulimit with a one hour timeout:
ulimit -t 3600 -v 1048576
make -j4 >makelog 2>makelog2
CPU is Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz, 4GB RAM.
I know that --enable-checking=all is very slow, but it should take less than an
hour to compile insn-emit.o, shouldn't it?
--
Summary: --enable-checking=all times out during bootstrap
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38139
[Bug rtl-optimization/38139] --enable-checking=all times out during bootstrap
-- edwintorok at gmail dot com changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38139
[Bug rtl-optimization/38139] --enable-checking=all times out during bootstrap
--- Comment #2 from edwintorok at gmail dot com 2008-11-15 21:59 --- (In reply to comment #1) > Subject: Re: New: --enable-checking=all times out during bootstrap > > > > Sent from my iPhone > > On Nov 15, 2008, at 1:27 PM, "edwintorok at gmail dot com" > <[EMAIL PROTECTED] > > wrote: > > > I tried to build a gcc 4.4.0 with --enable-checking=all but it timed > > out: > > Since --enable-checking=all enables gc all the time then yes > It will take a long time. Maybe even days. Marking is expensive. > Thanks, this is the 'gcac' flag, right? What if I build with "assert,df,fold,rtl,misc,tree,gc,rtlflag,runtime", would that build within a reasonable amount of time? And is it worth to build with more checking, than those enabled by default? [i.e. did that expose bugs in the past?] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38139
[Bug c/38157] New: -fconserve-stack enabled by default
At both O0 and O3 conserve-stack is enabled.
"The compiler will attempt to use less stack space, even if that makes the
program slower."
Doesn't that contradict with -O2 and -O3?
gcc_inst/bin/gcc -O0 -Q foo.c --help=optimizers |grep conserve-stack
-fconserve-stack [enabled]
gcc_inst/bin/gcc -O3 -Q foo.c --help=optimizers |grep conserve-stack
-fconserve-stack [enabled]
gcc_inst/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --disable-multilib --disable-static
--prefix=/home/edwin/gcc_inst/ --enable-languages=c,c++
--enable-checking=assert,df,fold,gc,misc,rtl,rtlflag,runtime,tree
Thread model: posix
gcc version 4.4.0 20081116 (experimental) [trunk revision 141912] (GCC)
--
Summary: -fconserve-stack enabled by default
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38157
[Bug tree-optimization/38224] New: libdecnumber/bid/host-ieee32.c:50: internal compiler error: fold check: original tree changed by fold
With SVN r142097, configured with checking enabled:
$ ../gcc/configure --disable-multilib --disable-static
--prefix=/home/edwin/gcc_inst/ --enable-languages=c,c++
--enable-checking=assert,df,fold,gc,misc,rtl,rtlflag,runtime,tree
$ source='../../gcc/libdecnumber/bid/host-ieee32.c' object='host-ieee32.o'
libtool=no /home/edwin/gcc-obj/./prev-gcc/xgcc
-B/home/edwin/gcc-obj/./prev-gcc/
-B/home/edwin/gcc_inst//x86_64-unknown-linux-gnu/bin/ -I../../gcc/libdecnumber
-I. -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -Wcast-qual -pedantic
-Wno-long-long -Werror -I../../gcc/libdecnumber -I. -c
../../gcc/libdecnumber/bid/host-ieee32.c
../../gcc/libdecnumber/bid/host-ieee32.c: In function __host_to_ieee_32:
../../gcc/libdecnumber/bid/host-ieee32.c:50: internal compiler error: fold
check: original tree changed by fold
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: libdecnumber/bid/host-ieee32.c:50: internal compiler
error: fold check: original tree changed by fold
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38224
[Bug tree-optimization/38224] libdecnumber/bid/host-ieee32.c:50: internal compiler error: fold check: original tree changed by fold
--- Comment #1 from edwintorok at gmail dot com 2008-11-22 08:21 ---
Testcase:
$ /home/edwin/gcc-obj/./prev-gcc/xgcc -B/home/edwin/gcc-obj/./prev-gcc/
-B/home/edwin/gcc_inst//x86_64-unknown-linux-gnu/bin/ -Wfatal-errors -c -O1
testcase-min.i
/* testcase */
typedef unsigned int UINT32;
typedef struct {} decimal32;
void __host_to_ieee_32 (UINT32 in, decimal32 * out)
{
memcpy ((char *) out, (char *) &in, 4);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38224
[Bug middle-end/36359] missed optimization in some cases with PRE VRP and other passes combined together
--- Comment #17 from edwintorok at gmail dot com 2008-11-24 18:33 --- Created an attachment (id=16761) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16761&action=view) drivers/scsi/sd.c Similar problem with drivers/scsi/sd.c I can compile the attached preprocessed on x86_64 linux: $ gcc-4.3 -c x.i -o x.o -O2 && nm -u x.o|grep ilog2 $ ~/gcc_inst/bin/gcc -c x.i -o x.o -O2 && nm -u x.o|grep ilog2 U ilog2_NaN IMHO the kernel is abusing gcc as a static analyzer, which gcc is not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug c/38296] New: documentation: improve documentation of __builtin_constant_p()
Because __builtin_constant_p() is sometimes (ab)used as a static analyzer, the
documentation should give more details what is expected to work, and what you
should not use it for. (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359)
Here is my suggestion, please incorporate it into the gcc 4.4.0 documentation
if you consider it appropriate:
- __builtin_constant_p() can return 1 even if during the execution of the
program it never is a constant
for example: the optimizer splits the case when a value is zero and
non-zero, and fully expands the zero case, considering the variable is zero.
This doesn't mean that during a real execution the value can ever be zero.
This can happen for example if the optimizer cannot "see" that a certain value
is impossible.
- __builtin_constant_p() is not a static analyzer, as it doesn't offer
soundness or completeness guarantees for the analysis it makes
- when you write optimized code for the __builtin_constant_p() == 1 case,
you should not treat invalid constant values as build time errors, instead you
should fall back to using the generic code at runtime (which should handle the
invalid cases anyway). The reason is because gcc may constant-propagate/expand
a value that may not be reached ever, because of the reasons described above.
for example, instead of doing this:
__builtin_constant_p(val) ? (VALID(val) ? OPTIMIZED(val) :
__build_error())
: generic_case(val)
Do this:
(__builtin_constant_p(val) && VALID(val)) ? OPTIMIZED(val)
: generic_case(val);
What happens if you don't take the above advice: anytime gcc's optimizer is
changed, your code may break
--
Summary: documentation: improve documentation of
__builtin_constant_p()
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38296
[Bug c/38408] New: compilation error during bootstrap in fold-const.c using TOT!
Using SVN r142442, my nightly gcc-4.4.0 boostrapper failed: Configured with ../gcc/configure --disable-multilib --disable-static --prefix=/home/edwin/gcc_inst/ --enable-languages=c,c++ --enable-checking=assert,df,fold,gc,misc,rtl,rtlflag,runtime,tree /home/edwin/gcc-obj/./prev-gcc/xgcc -B/home/edwin/gcc-obj/./prev-gcc/ -B/home/edwin/gcc_inst//x86_64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber -DCLOOG_PPL_BACKEND ../../gcc/gcc/fold-const.c -o fold-const.o ../../gcc/gcc/fold-const.c:13363: error: dereferencing pointer '__t' does break strict-aliasing rules ../../gcc/gcc/fold-const.c:13363: note: initialized from here ../../gcc/gcc/fold-const.c:13377: error: dereferencing pointer 'tmp' does break strict-aliasing rules ../../gcc/gcc/fold-const.c:13378: error: dereferencing pointer 'tmp' does break strict-aliasing rules ../../gcc/gcc/fold-const.c:13379: error: dereferencing pointer 'tmp' does break strict-aliasing rules ../../gcc/gcc/fold-const.c:13380: error: dereferencing pointer 'tmp' does break strict-aliasing rules ../../gcc/gcc/fold-const.c:13383: error: dereferencing pointer 'tmp' does break strict-aliasing rules ../../gcc/gcc/fold-const.c:13384: error: dereferencing pointer 'tmp' does break strict-aliasing rules ../../gcc/gcc/fold-const.c:13376: note: initialized from here make[3]: *** [fold-const.o] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 -- Summary: compilation error during bootstrap in fold-const.c using TOT! Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38408
[Bug tree-optimization/38224] libdecnumber/bid/host-ieee32.c:50: internal compiler error: fold check: original tree changed by fold
--- Comment #3 from edwintorok at gmail dot com 2008-12-06 08:37 --- This got fixed somewhere between r142405 and r142487, because r142487 has bootstrapped successfully. -- edwintorok at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38224
[Bug rtl-optimization/38854] New: missed optimization with -m32: empty functions shouldn't contain push/mov/pop
Testcase:
void noop(char* foo) {}
For 64-bit it does the right thing:
$ gcc -O2 foo.c -S
Output is:
noop:
.LFB2:
rep
ret
However for 32-bit it has useless extra instructions:
$ gcc -m32 -O2 foo.c -S
noop:
pushl %ebp
movl%esp, %ebp
popl%ebp
ret
The push/mov/pop should be removed.
I tested this with gcc-4.2, 4.3, and 4.4(trunk revision 143382), all produce
same code.
--
Summary: missed optimization with -m32: empty functions shouldn't
contain push/mov/pop
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38854
[Bug rtl-optimization/38854] missed optimization with -m32: empty functions shouldn't contain push/mov/pop
--- Comment #2 from edwintorok at gmail dot com 2009-01-15 09:50 --- (In reply to comment #1) > This is the frame-pointer setup code. You can get the same code as x86_64 > with > -momit-leaf-frame-pointer. > Ok. But can't the optimizers see that you push ebp, write something to it, and then pop to it again, and remove that code automatically? At least the movl is a dead store ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38854
[Bug rtl-optimization/38854] missed optimization with -m32: empty functions shouldn't contain push/mov/pop
--- Comment #3 from edwintorok at gmail dot com 2009-01-15 09:51 --- (In reply to comment #2) > (In reply to comment #1) > > This is the frame-pointer setup code. You can get the same code as x86_64 > > with > > -momit-leaf-frame-pointer. > > > > Ok. But can't the optimizers see that you push ebp, write something to it, and > then pop to it again, and remove that code automatically? > At least the movl is a dead store ... > Or is the prologue/epilogue code special, and not run through such optimizations? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38854
[Bug libmudflap/33591] New: mudflap gives warnings exceeding bounds on valid code, when using readdir(2) on large directories
When reading entries of a directory with readdir() on a directory
containing many files, mudflap gives warning about out-of-bound writes.
mudflap.c: MF_VALIDATE_EXTENT (p, sizeof (*p), __MF_CHECK_WRITE, "readdir
result");
mudflap checks that the entire struct dirent is writable, however the size of
struct dirent is undefined (according to the manpage).
I think it should only check that d_reclen bytes are accessible, instead of the
entire structure.
Bug initially discovered on directory with 76000 entries, reproduced on
directory with 1000 entries.
I have run the test on a reiserfs filesystem, but it can also be
reproduced by creating a directory with 1000 entries on a tmpfs filesystem
mounted on /tmp
Steps to reproduce:
$ mkdir test/
$ for i in `seq 1 1000`; do touch test/$i; done
$ gcc -fmudflap mudflap_readdir.i -lmudflap -o mudflap_readdir
$ ./mudflap_readdir test/ 2>error_log
$ grep ^\ error_log|sort -u
/lib/libc.so.6 [0x3dfd295d89]
/lib/libc.so.6(opendir+0x58) [0x3dfd295e58]
./mudflap_readdir(main+0xc9) [0x400a11]
/usr/lib/libmudflap.so.0(__mf_check+0x41) [0x2b7f247ffdb1]
/usr/lib/libmudflap.so.0(__mf_register+0x41) [0x2b7f247ff8e1]
/usr/lib/libmudflap.so.0(__mfwrap_readdir+0x91) [0x2b7f24804b91]
/usr/lib/libmudflap.so.0(__wrap_malloc+0xdd) [0x2b7f24800b8d]
Snippet of error_log:
***
mudflap violation 1 (check/write): time=1191088752.714610 ptr=0x7043c8 size=280
pc=0x2b7f247ffdb1 location=`(readdir result)'
/usr/lib/libmudflap.so.0(__mf_check+0x41) [0x2b7f247ffdb1]
/usr/lib/libmudflap.so.0(__mfwrap_readdir+0x91) [0x2b7f24804b91]
./mudflap_readdir(main+0xc9) [0x400a11]
Nearby object 1: checked region begins 3896B into and ends 24B after
mudflap object 0x7044f0: name=`malloc region'
bounds=[0x703490,0x7044c7] size=4152 area=heap check=0r/163w liveness=163
alloc time=1191088752.713885 pc=0x2b7f247ff8e1
/usr/lib/libmudflap.so.0(__mf_register+0x41) [0x2b7f247ff8e1]
/usr/lib/libmudflap.so.0(__wrap_malloc+0xdd) [0x2b7f24800b8d]
/lib/libc.so.6 [0x3dfd295d89]
/lib/libc.so.6(opendir+0x58) [0x3dfd295e58]
number of nearby objects: 1
***
Environment:
$ uname -a
Linux lightspeed2 2.6.23-rc8-hrt1-cfs-v22-g1bef7dc0-dirty #16 Sat Sep 29
15:54:22 EEST 2007 x86_64 GNU/Linux
$ cat /etc/debian_version
lenny/sid
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --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-mpfr --disable-werror
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.1 (Debian 4.2.1-5)
$ mount|grep /home
/dev/mapper/main-home on /home type reiserfs (rw,noatime,notail)
$ mount|grep tmp
tmpfs on /tmp type tmpfs (rw,nosuid,mode=1777)
--
Summary: mudflap gives warnings exceeding bounds on valid code,
when using readdir(2) on large directories
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33591
[Bug libmudflap/33591] mudflap gives warnings exceeding bounds on valid code, when using readdir(2) on large directories
--- Comment #1 from edwintorok at gmail dot com 2007-09-29 18:10 --- Created an attachment (id=14267) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14267&action=view) preprocessed C program to reproduce bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33591
[Bug c/37178] New: false positive with -Wstrict-overflow=2 on code not involving signed overflow
Using gcc version 4.3.1 (Debian 4.3.1-9) on amd64 I get a warning I shouldn't:
$ gcc -O2 -Wstrict-overflow=2 testcase-min.i -c
testcase-min.i: In function cli_scanrar:
testcase-min.i:40: warning: assuming signed overflow does not occur when
simplifying conditional to constant
At line 40 there is this (ret is int, but it only gets values assigned, no
arithmetic is performed on it)
if(ret == 2) ret = 0;
I am attaching the reduced testcase.
More system info:
$ uname -a
Linux lightspeed2 2.6.26-1-amd64 #1 SMP Fri Aug 8 13:17:41 UTC 2008 x86_64
GNU/Linux
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-9'
--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-cld --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.1 (Debian 4.3.1-9)
--
Summary: false positive with -Wstrict-overflow=2 on code not
involving signed overflow
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37178
[Bug c/37178] false positive with -Wstrict-overflow=2 on code not involving signed overflow
--- Comment #1 from edwintorok at gmail dot com 2008-08-20 17:52 --- Created an attachment (id=16115) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16115&action=view) reduced testcase the testcase is reduced from clamav's scanners.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37178
[Bug c/37186] New: -Wno-error=pointer-sign does not work
Doesn't work, it still considers these warnings as errors:
$ gcc-4.3 x.c -c -Wall -Werror -Wno-error=pointer-sign
cc1: warnings being treated as errors
x.c: In function bar:
x.c:4: error: pointer targets in passing argument 1 of foo differ in
signedness
$ gcc-4.3 x.c -c -Wpointer-sign -Werror -Wno-error=pointer-sign
cc1: warnings being treated as errors
x.c: In function bar:
x.c:4: error: pointer targets in passing argument 1 of foo differ in
signedness
This of course works, but I don't see the warning anymore:
$ gcc-4.3 x.c -c -Wall -Werror -Wno-pointer-sign
$ echo $?
0
$ gcc-4.3 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-9'
--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-cld --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.1 (Debian 4.3.1-9)
$ cat x.c
int foo(signed char *);
int bar(unsigned char *p)
{
return foo(p);
}
--
Summary: -Wno-error=pointer-sign does not work
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: Linux lightspeed2 2.6.26-1-amd64 #1 SMP Fri Aug 8
13:17:41 UTC 2
GCC host triplet: Linux lightspeed2 2.6.26-1-amd64 #1 SMP Fri Aug 8
13:17:41 UTC 2
GCC target triplet: Linux lightspeed2 2.6.26-1-amd64 #1 SMP Fri Aug 8
13:17:41 UTC 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37186
[Bug c/37187] New: please provide a way to treat -pedantic as warning when using -Werror
Consider this code snippet:
cat x.c
struct test {
void *tst;
};
struct yy {
void **z;
};
int foo(struct test *x)
{
struct yy y[] ={
{ (void**) &x->tst }
};
return 0;
}
$ gcc x.c -c -pedantic
x.c: In function foo:
x.c:10: warning: initializer element is not computable at load time
x.c:10: warning: initializer element is not computable at load time
I now use -Werror:
$ gcc -Werror x.c -c -pedantic
cc1: warnings being treated as errors
x.c: In function foo:
x.c:10: error: initializer element is not computable at load time
x.c:10: error: initializer element is not computable at load time
This is fine, but now I want -Werror (perhaps because I use -Wall or some other
-W flags), but I don't want warnings from -pedantic to be errors (but I still
want to see them!):
$ gcc -Wall x.c -c -pedantic -Werror -Wno-error=pedantic
cc1: error: -Werror=pedantic: No option -Wpedantic
This doesn't work, and I see no other way to downgrade -pedantic to warning
after I used -Werror.
--
Summary: please provide a way to treat -pedantic as warning when
using -Werror
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37187
[Bug c/37187] please provide a way to treat -pedantic as warning when using -Werror
--- Comment #1 from edwintorok at gmail dot com 2008-08-21 13:26 --- Also -fdiagnostics-show-option doesn't show that the error is coming from -pedantic: $ gcc -Werror -pedantic x.c -c -fdiagnostics-show-option cc1: warnings being treated as errors x.c: In function foo: x.c:10: error: initializer element is not computable at load time x.c:10: error: initializer element is not computable at load time $ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-9' --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-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.1 (Debian 4.3.1-9) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37187
[Bug c/37190] New: -Wredundant-decls -Wno-error=redundant-decls not working as expected
Consider this code:
extern char *optarg;
extern char *optarg;
$ gcc testcase-min.i -c -Werror -Wredundant-decls -Wno-error=redundant-decls
-fdiagnostics-show-option
testcase-min.i:2: warning: redundant redeclaration of optarg
[-Wredundant-decls]
cc1: warnings being treated as errors
testcase-min.i:1: error: previous declaration of optarg was here
It does work if I don't use -Wredundant-decls at all, but I want to see the
warning:
$ gcc testcase-min.i -c -Wall -Werror
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-9'
--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-cld --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.1 (Debian 4.3.1-9)
--
Summary: -Wredundant-decls -Wno-error=redundant-decls not working
as expected
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37190
[Bug c/37190] -Wredundant-decls -Wno-error=redundant-decls not working as expected
--- Comment #3 from edwintorok at gmail dot com 2008-08-21 16:08 --- (In reply to comment #2) > Thanks for the report anyway! > Ok, when is GCC 4.4 scheduled to be released? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37190
[Bug c/37192] New: --combine problems with one source defining _GNU_SOURCE and the other one doesn't
Consider these two minimal files:
p1.c:
#define _GNU_SOURCE
#include
p2.c:
#include
They compile just fine by themselves.
Now trying --combine:
$ gcc --combine -c p1.c p2.c
In file included from /usr/include/sys/types.h:220,
from p2.c:1:
/usr/include/sys/select.h:109: error: conflicting types for select
/usr/include/sys/select.h:109: error: previous declaration of select was here
/usr/include/sys/select.h:121: error: conflicting types for pselect
/usr/include/sys/select.h:121: error: previous declaration of pselect was
here
Of course the prototype is different with _GNU_SOURCE vs. non _GNU_SOURCE, but
why does --combine care?
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-9'
--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-cld --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.1 (Debian 4.3.1-9)
--
Summary: --combine problems with one source defining _GNU_SOURCE
and the other one doesn't
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37192
[Bug c/37192] --combine problems with one source defining _GNU_SOURCE and the other one doesn't
--- Comment #1 from edwintorok at gmail dot com 2008-08-21 17:48 --- Created an attachment (id=16122) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16122&action=view) preprocessed source Generated with: gcc --combine p1.c p2.c -c -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37192
[Bug c/37192] --combine problems with one source defining _GNU_SOURCE and the other one doesn't
--- Comment #3 from edwintorok at gmail dot com 2008-08-21 17:52 --- (In reply to comment #2) > This sounds like a glibc bug really. glibc's headers has invalid C in it :). > > >why does --combine > Because GCC checks that the prototypes are compatible across translational > units with --combine and errors out if they are not since that is invalid C > :). > Agreed, but I thought --combine is smarter than to just concatenate the sources. Compiling the sources separately works, and they are valid C separately. IMHO LTO should deal with situations like this, or make an exception for system headers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37192
[Bug tree-optimization/37573] New: gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
Compiling the testcase below with -O2 works, and fails with -O3. gcc-4.3 works with both -O2 and -O3. $ x86_64-unknown-linux-gnu-gcc-4.4.0 -O2 testcase-min.i $ ./a.out OK $ x86_64-unknown-linux-gnu-gcc-4.4.0 -O3 testcase-min.i $ ./a.out Failed: /.G7��G��?�?�; $ ./a.out Failed: �G7 h�G��3�?� $ gcc-4.3 -O3 testcase-min.i $ ./a.out OK Actually it is -ftree-vectorize that causes the failure: $ x86_64-unknown-linux-gnu-gcc-4.4.0 -O1 -ftree-vectorize testcase-min.i $ ./a.out Failed:"�@���@ �?�� The output is random garbage with -O3, but should be '>AUTOIT UNICODE SCRIPT<'. $ x86_64-unknown-linux-gnu-gcc-4.4.0 --version x86_64-unknown-linux-gnu-gcc-4.4.0 (GCC) 4.4.0 20080918 (experimental) Copyright (C) 2008 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. gcc-4.4 is a build from svn: $ svn info Path: . URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 140456 Node Kind: directory Schedule: normal Last Changed Author: amacleod Last Changed Rev: 140456 Last Changed Date: 2008-09-18 17:07:35 +0300 (Thu, 18 Sep 2008) $ gcc-4.3 --version gcc-4.3 (Debian 4.3.2-1) 4.3.2 Copyright (C) 2008 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. -- Summary: gcc-4.4 regression: incorrect code generation with -O1 - ftree-vectorize Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu-gcc-4.4.0 GCC host triplet: x86_64-unknown-linux-gnu-gcc-4.4.0 GCC target triplet: x86_64-unknown-linux-gnu-gcc-4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug tree-optimization/37573] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
--- Comment #1 from edwintorok at gmail dot com 2008-09-18 17:30 ---
Testcase:
extern int printf (__const char *__restrict __format, ...);
extern int strcmp (__const char *__s1, __const char *__s2);
extern int puts (__const char *__s);
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
struct MT
{
uint32_t *next;
uint32_t items;
uint32_t mt[624];
};
static uint8_t
MT_getnext (struct MT *MT)
{
uint32_t r;
if (!--MT->items)
{
uint32_t *mt = MT->mt;
unsigned int i;
MT->next = mt;
for (i = 0; i < 227; i++)
mt[i] =
mt[i] ^ mt[i + 1]) & 0x7ffe) ^ mt[i]) >> 1) ^
((0 - (mt[i + 1] & 1)) & 0x9908b0df) ^ mt[i + 397];
}
r = *(MT->next++);
r ^= (r >> 11);
r ^= ((r & 0xff3a58ad) << 7);
r ^= ((r & 0xdf8c) << 15);
r ^= (r >> 18);
return (uint8_t) (r >> 1);
}
static void
MT_decrypt (uint8_t * buf, unsigned int size, uint32_t seed)
{
struct MT MT;
unsigned int i;
uint32_t *mt = MT.mt;
*mt = seed;
for (i = 1; i < 624; i++)
mt[i] = i + 0x6c078965 * ((mt[i - 1] >> 30) ^ mt[i - 1]);
MT.items = 1;
while (size--)
*buf++ ^= MT_getnext (&MT);
};
static uint8_t buf[23] = {
0xc0, 0x49, 0x17, 0x32, 0x62, 0x1e, 0x2e, 0xd5, 0x4c, 0x19, 0x28, 0x49,
0x91, 0xe4, 0x72, 0x83, 0x91, 0x3d, 0x93, 0x83, 0xb3, 0x61, 0x38
};
int
main (void)
{
uint32_t s;
s = 23;
MT_decrypt (buf, s, s + 0xa25e);
if (!strcmp (">AUTOIT UNICODE SCRIPT<", buf))
{
puts ("OK");
return 0;
}
else
{
printf ("Failed:%s\n", buf);
return 1;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug tree-optimization/37573] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
--- Comment #2 from edwintorok at gmail dot com 2008-09-18 17:31 --- Created an attachment (id=16357) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16357&action=view) config.log for gcc 4.4 Some more system info: $ uname -a Linux debian 2.6.26-1-amd64 #1 SMP Wed Sep 10 15:31:12 UTC 2008 x86_64 GNU/Linux $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz stepping: 7 cpu MHz : 2000.000 cache size : 6144 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm bogomips: 5669.97 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz stepping: 7 cpu MHz : 2000.000 cache size : 6144 KB physical id : 0 siblings: 4 core id : 3 cpu cores : 4 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm bogomips: 5666.05 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz stepping: 7 cpu MHz : 2000.000 cache size : 6144 KB physical id : 0 siblings: 4 core id : 1 cpu cores : 4 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm bogomips: 5666.03 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz stepping: 7 cpu MHz : 2000.000 cache size : 6144 KB physical id : 0 siblings: 4 core id : 2 cpu cores : 4 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm bogomips: 5666.03 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug rtl-optimization/37617] New: gcc 4.4 regression: ICE on valid code
I get an ICE using SVN version 140562: ~/gcc_inst/bin/gcc testcase-min.i -O1 testcase-min.i: In function test_token_dval: testcase-min.i:19: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. This does not happen with my previous build of gcc 4.4 SVN r140456: $ x86_64-unknown-linux-gnu-gcc-4.4.0 -O1 test.i -c $ $ ~/gcc_inst/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-languages=c --disable-multilib --disable-bootstrap --disable-static --prefix=/home/edwin/gcc_inst/ Thread model: posix gcc version 4.4.0 20080922 (experimental) (GCC) $ x86_64-unknown-linux-gnu-gcc-4.4.0 -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-languages=c --disable-multilib Thread model: posix gcc version 4.4.0 20080918 (experimental) (GCC) -- Summary: gcc 4.4 regression: ICE on valid code Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37617
[Bug rtl-optimization/37617] gcc 4.4 regression: ICE on valid code
--- Comment #1 from edwintorok at gmail dot com 2008-09-22 20:18 ---
/* testcase compile this with -O1 */
typedef struct TCase TCase;
typedef void (*TFun) (int);
typedef struct Suite Suite;
void _tcase_add_test (TCase * tc, TFun tf, const char *fname, int signal,
int start, int end);
void _fail_unless (int result, const char *file, int line, const char *expr,
...);
enum val_type
{
vtype_undefined, vtype_cstring, vtype_string, vtype_scope, vtype_dval,
vtype_ival
};
typedef struct token
{
union
{
char *string;
double dval;
}
val;
enum val_type vtype;
}
yystype;
static int
vtype_compatible (enum val_type orig, enum val_type req)
{
}
static void
test_token_dval (int _i __attribute__ ((unused)))
{
{
int val = 0.12345;
yystype tok;
do
{
(&tok)->val.dval = (val);
}
while (0);
_fail_unless ((vtype_compatible ((&tok)->vtype, vtype_string) ? (&tok)->
val.string : ((void *) 0)) == ((void *) 0),
"../../../trunk/unit_tests/check_jsnorm.c", 150,
"Assertion '" "TOKEN_GET(&tok, string) == NULL" "' failed",
"token dval->string", ((void *) 0));
}
}
Suite *
test_jsnorm_suite (void)
{
TCase *tc_jsnorm_gperf, *tc_jsnorm_token, *tc_jsnorm_api,
*tc_jsnorm_tokenizer, *tc_jsnorm_bugs, *tc_screnc_infloop;
_tcase_add_test ((tc_jsnorm_token), (test_token_dval),
"" "test_token_dval" "", (0), 0, 1);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37617
[Bug tree-optimization/37658] New: gcc-4.3 regression: long compile times on source with lots of labels/gotos
Using gcc-4.3 to compile Gauche-0.8.13/src/vm.c with -O2 takes several minutes,
this problem doesn't occur with gcc-4.2.
$ time /usr/bin/gcc-4.3 -O2 vm.i -c
real2m13.341s
user2m13.008s
sys 0m0.308s
$ time /usr/bin/gcc-4.3 -O2 testcase.i -c
real2m2.527s
user2m2.004s
sys 0m0.336s
$ time /usr/bin/gcc-4.2 -O2 vm.i -c
real0m2.265s
user0m2.216s
sys 0m0.040s
$ gcc-4.3 -v
Using built-in specs.
Target: x86_64-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-cld --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1)
$ gcc-4.2 -v
Using built-in specs.
Target: x86_64-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 --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.4 (Debian 4.2.4-3)
[not sure about the component, it could be the register allocator, because I
encountered a spiller error while reducing the testcase]
--
Summary: gcc-4.3 regression: long compile times on source with
lots of labels/gotos
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37658
[Bug tree-optimization/37658] gcc-4.3 regression: long compile times on source with lots of labels/gotos
--- Comment #1 from edwintorok at gmail dot com 2008-09-27 16:20 --- Created an attachment (id=16415) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16415&action=view) testcase time gcc-4.3 -O2 testcase.i -c real2m13.341s user2m13.008s sys 0m0.308s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37658
[Bug rtl-optimization/37659] New: unable to find a register to spill in class �AREG�
While reducing the testcase for PR37658 I found another bug:
$ gcc-4.3 -fschedule-insns testcase.i
...
testcase.i:193: error: unable to find a register to spill in class ÂAREGÂ
testcase.i:193: error: this is the insn:
(insn 17782 17785 17783 1528 testcase.i:189 (parallel [
(set (reg:SI 1 dx [9986])
(div:SI (reg:SI 3 bx [orig:524 D.8216 ] [524])
(reg:SI 1 dx [orig:522 D.8218 ] [522])))
(set (reg:SI 9987)
(mod:SI (reg:SI 3 bx [orig:524 D.8216 ] [524])
(reg:SI 1 dx [orig:522 D.8218 ] [522])))
(clobber (reg:CC 17 flags))
]) 318 {*divmodsi4_nocltd} (expr_list:REG_DEAD (reg:SI 3 bx [orig:524
D.8216 ] [524])
(expr_list:REG_DEAD (reg:SI 1 dx [orig:522 D.8218 ] [522])
(expr_list:REG_UNUSED (reg:SI 9987)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil))
testcase.i:193: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/ccA3kPTQ.out file, please attach this to
your bugreport.
This happens with all gcc versions I have here (with slightly different error
message):
$ gcc-4.3 -v
Using built-in specs.
Target: x86_64-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-cld --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1)
$ gcc-4.2 -v
Using built-in specs.
Target: x86_64-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 --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.4 (Debian 4.2.4-3)
$ gcc-4.1 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,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.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.1.3 20080623 (prerelease) (Debian 4.1.2-23)
--
Summary: unable to find a register to spill in class ÂAREGÂ
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37659
[Bug rtl-optimization/37659] unable to find a register to spill in class �AREG�
--- Comment #1 from edwintorok at gmail dot com 2008-09-27 16:28 --- Created an attachment (id=16416) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16416&action=view) file dumped by gcc This is the file dumped by gcc, I am trying to get a reduced testcase using delta, will attach here when I have it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37659
[Bug rtl-optimization/37659] unable to find a register to spill in class �AREG�
--- Comment #2 from edwintorok at gmail dot com 2008-09-27 16:40 ---
Reduced testcase:
/* gcc -fschedule-insns */
int foo(int a, int b) {
return bar(foobar(b) / foobar(a));
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37659
[Bug rtl-optimization/37659] unable to find a register to spill in class �AREG�
--- Comment #3 from edwintorok at gmail dot com 2008-09-27 16:43 ---
the error message for the above testcase:
$ gcc-4.3 -fschedule-insns v.i
v.i: In function ÂfooÂ:
v.i:3: error: unable to find a register to spill in class ÂAREGÂ
v.i:3: error: this is the insn:
(insn 17 20 18 2 v.i:2 (parallel [
(set (reg:SI 1 dx [66])
(div:SI (reg:SI 3 bx [orig:61 D.1552 ] [61])
(reg:SI 1 dx [orig:60 D.1553 ] [60])))
(set (reg:SI 67)
(mod:SI (reg:SI 3 bx [orig:61 D.1552 ] [61])
(reg:SI 1 dx [orig:60 D.1553 ] [60])))
(clobber (reg:CC 17 flags))
]) 318 {*divmodsi4_nocltd} (expr_list:REG_DEAD (reg:SI 3 bx [orig:61
D.1552 ] [61])
(expr_list:REG_DEAD (reg:SI 1 dx [orig:60 D.1553 ] [60])
(expr_list:REG_UNUSED (reg:SI 67)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil))
v.i:3: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/ccYIfwlr.out file, please attach this to
your bugreport.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37659
[Bug tree-optimization/37617] [4.4 Regression] ICE on valid code
--- Comment #7 from edwintorok at gmail dot com 2008-10-01 16:43 --- Thanks, gcc4.4 doesn't crash anymore now. -- edwintorok at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37617
[Bug tree-optimization/37867] New: inconsistent results on -O2 when reading bits from packed struct
Running gcc-4.3 -O2 on PR1386.c I get different results than with -O1.
$ gcc-4.3 -O2 PR1386.c && ./a.out
PR1386.c: In function main:
PR1386.c:15: warning: large integer implicitly truncated to unsigned type
PR1386.c:17: warning: large integer implicitly truncated to unsigned type
bad bits: fff0
$ gcc-4.3 -O2 PR1386.c && ./a.out
PR1386.c: In function main:
PR1386.c:15: warning: large integer implicitly truncated to unsigned type
PR1386.c:17: warning: large integer implicitly truncated to unsigned type
bad bits: fff0
gcc-4.2 is fine:
$ gcc-4.2 -O2 PR1386.c && ./a.out
PR1386.c: In function main:
PR1386.c:15: warning: large integer implicitly truncated to unsigned type
PR1386.c:17: warning: large integer implicitly truncated to unsigned type
bad bits: 0
$ gcc-4.2 -O3 PR1386.c && ./a.out
PR1386.c: In function main:
PR1386.c:15: warning: large integer implicitly truncated to unsigned type
PR1386.c:17: warning: large integer implicitly truncated to unsigned type
bad bits: 0
The file is from an LLVM testcase http://llvm.org/bugs/show_bug.cgi?id=1386
#include
#include
struct X {
unsigned char pad : 4;
uint64_t a : 64;
uint64_t b : 60;
} __attribute__((packed));
int main (void)
{
struct X x;
uint64_t bad_bits;
x.pad = 255;
x.a = -1ULL;
x.b = -1ULL;
bad_bits = ((uint64_t)-1ULL) ^ *(1+(uint64_t *) &x);
printf("bad bits: %llx\n", bad_bits);
return bad_bits != 0;
}
--
Summary: inconsistent results on -O2 when reading bits from
packed struct
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37867
[Bug tree-optimization/37867] inconsistent results on -O2 when reading bits from packed struct
--- Comment #1 from edwintorok at gmail dot com 2008-10-18 13:39 --- (In reply to comment #0) > Running gcc-4.3 -O2 on PR1386.c I get different results than with -O1. > > $ gcc-4.3 -O2 PR1386.c && ./a.out > PR1386.c: In function main: > PR1386.c:15: warning: large integer implicitly truncated to unsigned type > PR1386.c:17: warning: large integer implicitly truncated to unsigned type > bad bits: fff0 $ gcc-4.3 -O1 PR1386.c && ./a.out PR1386.c: In function main: PR1386.c:15: warning: large integer implicitly truncated to unsigned type PR1386.c:17: warning: large integer implicitly truncated to unsigned type bad bits: 0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37867
[Bug tree-optimization/37867] inconsistent results on -O2 when reading bits from packed struct
--- Comment #4 from edwintorok at gmail dot com 2008-10-18 18:07 --- (In reply to comment #3) > Does it work with -fno-strict-aliasing? > It doesn't. [EMAIL PROTECTED]:~$ g++ -O2 -fno-strict-aliasing x.c x.c: In function int main(): x.c:15: warning: large integer implicitly truncated to unsigned type x.c:17: warning: large integer implicitly truncated to unsigned type [EMAIL PROTECTED]:~$ ./a.out bad bits: fff0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37867
[Bug tree-optimization/37868] New: code that doesn't breaks TBAA is misoptimized even with -fno-strict-aliasing
+++ This bug was initially created as a clone of Bug #37867 +++
Cloning bug on Chris's request.
Running gcc-4.3 -O2 on PR1386.c I get different results than with -O1.
$ gcc-4.3 -O1 PR1386.c && ./a.out
PR1386.c: In function main:
PR1386.c:15: warning: large integer implicitly truncated to unsigned type
PR1386.c:17: warning: large integer implicitly truncated to unsigned type
bad bits: 0
$ gcc-4.3 -O2 PR1386.c && ./a.out
PR1386.c: In function main:
PR1386.c:15: warning: large integer implicitly truncated to unsigned type
PR1386.c:17: warning: large integer implicitly truncated to unsigned type
bad bits: fff0
$ g++-4.3 -O2 -fno-strict-aliasing x.c
x.c: In function int main():
x.c:15: warning: large integer implicitly truncated to unsigned type
x.c:17: warning: large integer implicitly truncated to unsigned type
[EMAIL PROTECTED]:~$ ./a.out
bad bits: fff0
--
Summary: code that doesn't breaks TBAA is misoptimized even with
-fno-strict-aliasing
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37868
[Bug c++/37933] New: reference to ... is amibgous: same error shown twice for same line of code
$ cat test.cpp
namespace x {
extern char *foo;
};
using namespace x;
char *foo;
char bar()
{
return *foo;
}
$ g++ test.cpp -fsyntax-only
test.cpp: In function char bar():
test.cpp:8: error: reference to foo is ambiguous
test.cpp:5: error: candidates are: char* foo
test.cpp:2: error: char* x::foo
test.cpp:8: error: reference to foo is ambiguous
test.cpp:5: error: candidates are: char* foo
test.cpp:2: error: char* x::foo
The same error is shown twice.
I think it would be enough to show the error once.
This is with:
$ g++ -v
Using built-in specs.
Target: x86_64-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-cld --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1)
Same happens with g++-4.2, and trunk (r141407), g++-4.1 appears to infloop.
--
Summary: reference to ... is amibgous: same error shown twice for
same line of code
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37933
[Bug c++/37934] New: show a warning when a symbol is unused and completely removed from the output file
Consider the testcase below.
$ cat test.cpp
namespace x {
extern const char ** const foo;
extern const char ** const bar;
};
using namespace x;
namespace {
const char* X;
};
const char ** const foo = &X;
const char ** const x::bar = &X;
$ g++ test.cpp -Wall -Wunused -Wextra -c -o test.o
$ nm test.o | c++filt
b (anonymous namespace)::X
R x::bar
foo is completely removed from the output, and no warning is shown.
It would be useful to show a warning here.
For example in the above testcase I forgot to add the x:: namespace qualifier
to foo (the extern declaration was in a header and I didn't notice it was part
of a namespace).
Since I didn't get any warning, I got a linker error, and had to spend some
time tracing down this typo in my code.
Had I seen a warning from the compiler that 'foo' is not used
and will get removed I would have immediately noticed the absence of the x::
namespace qualifier.
--
Summary: show a warning when a symbol is unused and completely
removed from the output file
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37934
[Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
--- Comment #13 from edwintorok at gmail dot com 2008-10-29 18:48 --- I just noticed that this testcase also fails with -O3 on gcc version 4.1.2 20070626 (Red Hat 4.1.2-14), but works on gcc version 4.1.3 20080623 (prerelease) (Debian 4.1.2-23) -- edwintorok at gmail dot com changed: What|Removed |Added Known to fail||4.1.2 Known to work||4.1.3 4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
--- Comment #17 from edwintorok at gmail dot com 2008-11-03 17:50 --- Thanks. -- edwintorok at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug c/38037] New: false uninitialized warnings when using a pointer as a guard
With the testcode below I get an uninitialized use warning. There should be no warning since foobar is always assigned when (!bar), and foobar is only used when (!bar). bar is an argument to the function and nothing changes it, and it is not aliased. $ gcc -O2 -Wall -c foo.c foo.c: In function foo: foo.c:6: warning: foobar may be used uninitialized in this function This happens on both 4.3.2 and trunk $ gcc -v Using built-in specs. Target: x86_64-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-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1) $ gcc_inst/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --disable-multilib --disable-static --prefix=/home/edwin/gcc_inst/ --enable-languages=c,c++ Thread model: posix gcc version 4.4.0 20081103 (experimental) [trunk revision 141547] (GCC) -- Summary: false uninitialized warnings when using a pointer as a guard Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38037
[Bug c/38037] false uninitialized warnings when using a pointer as a guard
--- Comment #1 from edwintorok at gmail dot com 2008-11-06 20:58 ---
/* testcase
gcc -O2 -Wall -c foo.c */
char *get(void);
int use(const char *);
void foo(const char *bar)
{
char *foobar;
if(!bar)
foobar = get();
if(use(bar))
return;
if(!bar)
free(foobar);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38037
[Bug c/38037] false uninitialized warnings when using a pointer as a guard
--- Comment #2 from edwintorok at gmail dot com 2008-11-06 20:59 ---
/* testcase
* gcc -Wall -O2 -c foo.c
*/
char *get(void);
int use(const char *);
void foo(const char *bar)
{
char *foobar;
if(!bar)
foobar = get();
if(use(bar))
return;
if(!bar)
use(foobar);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38037
[Bug c/38037] false uninitialized warnings when using a pointer as a guard
--- Comment #3 from edwintorok at gmail dot com 2008-11-06 21:01 ---
Same happens if I use int instead of a pointer:
/* testcase */
/* gcc -O2 -Wall -c foo.c */
int get(void);
int use(int);
void foo(int bar)
{
int foobar;
if(!bar)
foobar = get();
if(use(bar))
return;
if(!bar)
use(foobar);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38037
[Bug c/38046] New: 'warning: comparison between signed and unsigned' shouldn't be given for equality comparisons
Consider this code:
int foo(int a, unsigned b)
{
return a != b;
}
int bar(int a, unsigned b)
{
return (unsigned)a != b;
}
int foobar(int a, unsigned b)
{
return a != (int)b;
}
$ gcc -O2 -Wall -W foo.c -c
foo.c: In function foo:
foo.c:3: warning: comparison between signed and unsigned integer expressions
The generated code is identical for all 3 functions, so there is no reason
to "fix" the warning in the code. Rather I think gcc shouldn't warn in this
case at all.
A more realistic example:
#include
int foo(int fd, char *buf, size_t n)
{
return (read(fd, buf, n) != n);
}
FWIW, if I change int to 'short int' or 'signed char' (and unsigned
appropriately) I get no warning.
--
Summary: 'warning: comparison between signed and unsigned'
shouldn't be given for equality comparisons
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38046
[Bug c/38046] 'warning: comparison between signed and unsigned' shouldn't be given for equality comparisons
--- Comment #3 from edwintorok at gmail dot com 2008-11-07 17:14 ---
(In reply to comment #2)
> Subject: Re: New: 'warning: comparison between signed and
> unsigned' shouldn't be given for equality comparisons
>
> On Fri, 7 Nov 2008, edwintorok at gmail dot com wrote:
>
> > Consider this code:
> >
> > int foo(int a, unsigned b)
> > {
> > return a != b;
> > }
>
> > $ gcc -O2 -Wall -W foo.c -c
> > foo.c: In function foo:
> > foo.c:3: warning: comparison between signed and unsigned integer expressions
>
> Seems correct to me. You could have a == -1 and b == UINT_MAX and they
> would compare equal, but it's not at all obvious from the code that this
> is the user's intent; and if it is their intent, they can use an explicit
> cast.
It would be nice to have a separate warning option for ==, != comparisons, and
another for <,>,<=,>= comparisons.
The problem is that with code that uses read(2) and write(2) you get lots of
warnings, and adding casts is time-consuming and of little benefit.
I'd like to turn -Wsign-compare into -Werror for 'make distcheck' in my
project, but can't do that due to the != comparisons. If I would have a
distinct -W flag for it, I could -Wno-error that.
>
> > FWIW, if I change int to 'short int' or 'signed char' (and unsigned
> > appropriately) I get no warning.
>
> Both short and unsigned short will be promoted to int before the
> comparison, so you won't get -1 and USHRT_MAX comparing equal.
>
Ok
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38046
[Bug rtl-optimization/35643] New: gcc-4.2 -O1 -fstrict-aliasing misoptimization
When I compile the testcase with -O2, or with '-O1 -fstrict-aliasing' incorrect code is generated. The testcase calls abort() in this case. This is a regression in gcc-4.2 only: gcc-4.1 and gcc-4.3 do not show the bug. $ gcc-4.2 -O1 test.i -o ok && ./ok $ gcc-4.2 -O2 test.i -o fails && ./fails Aborted $ gcc-4.2 -O1 -fstrict-aliasing test.i -o fails2 && ./fails2 Aborted $ gcc-4.2 -O3 test.i -o fails3 && ./fails3 Aborted The testcase gives no warnings: $ gcc-4.2 -Wall -W -O2 -Wstrict-aliasing test.i The original code that is miscompiled is ClamAV, but only if -O3 is used. I created an initial reduced testcase using delta. Manually inlining some functions show this bug even at -O2 on the reduced testcase. I reproduced this on 2 different systems: [EMAIL PROTECTED]:~$ uname -a Linux lightspeed2 2.6.25-rc4-00134-g84c6f60 #4 Sun Mar 9 19:40:34 EET 2008 x86_64 GNU/Linux [EMAIL PROTECTED]:~$ gcc-4.2 -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --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-libmudflap --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.2.3 (Debian 4.2.3-2) I also reproduced the bug with gcc 4.2.3 built with --enable-checking=yes: [EMAIL PROTECTED]:~$ gcc-4.2.3/inst/bin/gcc -O1 -fstrict-aliasing test.i -o fails && ./fails Aborted [EMAIL PROTECTED]:~$ gcc-4.2.3/inst/bin/gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../configure --enable-languages=c --prefix=/home/edwin/gcc-4.2.3/obj/../inst --enable-checking=yes --disable-multilib --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap Thread model: posix gcc version 4.2.3 The second system: [EMAIL PROTECTED]:~$ uname -a Linux thunder 2.6.25-rc5-00323-g9a9e0d6 #22 SMP PREEMPT Sun Mar 16 10:23:46 EET 2008 i686 GNU/Linux [EMAIL PROTECTED]:~$ gcc-4.2 -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --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-libmudflap --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.2.3 (Debian 4.2.3-2) -- Summary: gcc-4.2 -O1 -fstrict-aliasing misoptimization Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35643
[Bug rtl-optimization/35643] gcc-4.2 -O1 -fstrict-aliasing misoptimization
--- Comment #1 from edwintorok at gmail dot com 2008-03-19 18:54 ---
Created an attachment (id=15345)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15345&action=view)
testcase
Some observations:
If you remove some dead code the optimization bug goes away:
Remove either of these and you'll get correct code, for example:
if (metadata->chunk_current >= metadata->chunk_end) {
}
If I remove that if and compare assembly output, I see this:
$ diff -wu bad.s ok.s
--- bad.s 2008-03-19 20:51:59.0 +0200
+++ ok.s2008-03-19 20:51:47.0 +0200
@@ -60,7 +60,7 @@
testb %al, %al
js .L9
movsbq %sil,%rax
- addq%rax, %rcx
+ leaq1(%rcx,%rax), %rcx
.L11:
movzbl (%rdx), %eax
addq$1, %rdx
Of course the original code that is miscompiled doesn't have dead code, it is
just because of the reduction.
If you need more info please ask.
This is related to this bug (but that occurs only at -O3):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470557
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35643
[Bug rtl-optimization/35643] gcc-4.2 -O1 -fstrict-aliasing misoptimization
--- Comment #2 from edwintorok at gmail dot com 2008-03-19 19:35 --- Created an attachment (id=15346) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15346&action=view) another reduced testcase I reduced the testcase further using delta, however I had to be careful to avoid deleting initializations. This testcase is valgrind clean. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35643
[Bug tree-optimization/35653] New: gcc-4.3 -O3/-ftree-vectorize regression: incorrect code generation
On x86-64 when clamav is compiled with gcc-4.3 -O3, it crashes in mew.c. Compiling a reduced testcase shows -ftree-vectorize introduces the bug. This happens only on gcc-4.3, gcc-4.2 and gcc-4.1 work ok with -O3/-ftree-vectorize. $ gcc-4.3 -O3 test.i -o fails && ./fails Segmentation fault $ gcc-4.3 -O1 -ftree-vectorize test.i -o fails2 && ./fails2 Segmentation fault $ gcc-4.3 -O2 test.i -o works && ./works $ gcc-4.2 -O3 test.i -o works2 && ./works2 $ gcc-4.2 -O3 -ftree-vectorize test.i -o works3 && ./works3 To reproduce on 32-bit x86 use: $ gcc-4.3 -O1 -ftree-vectorize -msse -msse2 test.i -o fails3 && ./fails3 Segmentation fault $ gcc-4.3 -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure linux gnu Thread model: posix gcc version 4.3.1 20080309 (prerelease) (Debian 4.3.0-1) $ uname -a Linux lightspeed2 2.6.25-rc4-00134-g84c6f60 #4 Sun Mar 9 19:40:34 EET 2008 x86_64 GNU/Linux -- Summary: gcc-4.3 -O3/-ftree-vectorize regression: incorrect code generation Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35653
[Bug tree-optimization/35653] gcc-4.3 -O3/-ftree-vectorize regression: incorrect code generation
--- Comment #1 from edwintorok at gmail dot com 2008-03-21 12:42 --- Created an attachment (id=15353) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15353&action=view) reduced testcase $ gcc-4.3 -O1 -g -ftree-vectorize test.i -o fails $ gdb ./fails GNU gdb 6.7.1-debian Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r Starting program: /home/edwin/clam/svn3/builds/gcc43opt/fortify-asserts-exp/tmpd/fails Program received signal SIGSEGV, Segmentation fault. 0x00400532 in main () at test.i:14 14 (*(uint32_t *)(dest)=(uint32_t)(0x4000400)); (gdb) p dest $1 = 0x7fffaae00672 "" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35653
[Bug tree-optimization/35653] [4.3/4.4 Regression]: gcc-4.3 -O3/-ftree-vectorize regression: incorrect code generation
--- Comment #8 from edwintorok at gmail dot com 2008-03-23 16:59 --- (In reply to comment #7) > Subject: Re: [4.3/4.4 Regression]: gcc-4.3 -O3/-ftree-vectorize regression: > incorrect code generation > > This code violates c/c++ aliasing rules. > -Wstrict-aliasing doesn't give a warning about it. Accessing the memory as uint32_t is done for performance reasons, the alternative would be to use byte-sized accesses. When reading, it would involve additional shift/or instructions. If the pointer is not aligned at 4 bytes, then uint32_t can't be done? If that is the case, a warning would be *very* useful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35653
[Bug tree-optimization/35653] [4.3/4.4 Regression]: gcc-4.3 -O3/-ftree-vectorize regression: incorrect code generation
--- Comment #13 from edwintorok at gmail dot com 2008-03-24 17:00 ---
(In reply to comment #11)
> I think the code is violating alignment requirements of the C/C++ standard.
>
First a real bug here is that -Wstrict-aliasing doesn't warn of this situation.
Do you agree?
Unaligned accesses is undefined in general, I agree.
But on x86 it has always been possible to do unaligned accesses, and it is
possible even with vector instructions (movdqu). Of course these are slower
than aligned accesses, but there should be some way to express them in C [*]
The most natural way to do that is to typecast, and this has worked, knowing
that x86 doesn't have instructions that can SIGBUS/SIGSEGV on unaligned
accesses (not true anymore with vector instructions), or knowing that compilers
won't generate vectorized code for unaligned accesses (true until gcc-4.3
AFAIK).
If you decide to handle unaligned accesses as undefined even for x86, the Linux
kernel developers should be notified:
The kernel has a macro, that is defined as such on x86:
#define get_unaligned(ptr) (*(ptr))
And defined using these generically for non-x86 architectures
struct __una_u32 { __u32 x __attribute__((packed)); };
static inline __u32 __uldl(const __u32 *addr)
{
const struct __una_u32 *ptr = (const struct __una_u32 *) addr;
return ptr->x;
}
[*]: this can be used to express unaligned accesses safely
And it is being used in a loop:
http://lxr.linux.no/linux/net/bluetooth/bnep/core.c#L153
BTW, the original code for this bugreport does unaligned accesses only on
little-endian architectures, and this has worked on all compilers until now:
#if WORDS_BIGENDIAN == 0
..
#define cli_readint32(buff) (*(const int32_t *)(buff))
...
#else
...
static inline int32_t cli_readint32(const char *buff)
{
int32_t ret;
ret = buff[0] & 0xff;
ret |= (buff[1] & 0xff) << 8;
ret |= (buff[2] & 0xff) << 16;
ret |= (buff[3] & 0xff) << 24;
return ret;
}
...
#endif
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35653
[Bug tree-optimization/39736] New: signed overflow in loop induction variable: missing warning and wrong code
[This bug was discovered by kantorzs...@yahoo.com]
When compiling the testcase below at -O2, using gcc 4.3.3 instead of an infite
loop, where the variable 'from' takes values from -32768 to 32767,
it goes up way beyond that limit:
$ gcc -O2 tes -Wall -W -Wstrict-overflow=5 && ./a.out
0
1
...
2253491
When using -fwrapv, or -fno-strict-overflow 'from' iterates between -32768 and
32767 in an infinite loop, as expected.
There are 2 bugs here:
- no warning is given with -Wstrict-overflow=5, although -fstrict-overflow
changes the behaviour of the code
- from is of type short, so when sign extended to an int, it should only take
values allowed for a short: -32768 to 32767, not all values allowed for an int
(like 2253491)
I think this is a bug, because although signed overflow is undefined behaviour,
that should affect only the value of 'from', which is still of type 'short',
and converting to int should obey the limits for the 'short' type, i.e. use a
sign-extension.
Here is a diff of the assembly, when using -O2, vs -O2 -fno-strict-overflow:
--- x2.s2009-04-11 15:28:01.0 +0300
+++ x2-no-overflow.s2009-04-11 15:27:58.0 +0300
@@ -10,15 +10,16 @@
.LFB13:
pushq %rbx
.LCFI0:
+ xorl%esi, %esi
xorl%ebx, %ebx
.p2align 4,,10
.p2align 3
.L2:
- movl%ebx, %esi
movl$.LC0, %edi
xorl%eax, %eax
- callprintf
addl$1, %ebx
+ callprintf
+ movswl %bx,%esi
jmp .L2
.LFE13:
.size main, .-main
Testcase:
#include
int
main ()
{
int until = 40001;
short from = 0;
for (; from < until; from++)
printf ("%d\n", from);
return 0;
}
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.3-5'
--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-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.3 (Debian 4.3.3-5)
Also reproduced with trunk:
$ ~/gcc_inst/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --disable-multilib --disable-static
--prefix=/home/edwin/gcc_inst/ --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20090408 (experimental) [trunk revision 145769] (GCC)
--
Summary: signed overflow in loop induction variable: missing
warning and wrong code
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39736
[Bug tree-optimization/39736] signed overflow in loop induction variable: missing warning and wrong code
--- Comment #3 from edwintorok at gmail dot com 2009-04-12 09:32 --- (In reply to comment #2) > (In reply to comment #1) > > There is no undefined behavior here (increment of a short value converts > > to int, increments then converts back to short, none of which are > > undefined), so at least the wrong code issue would be the same as bug > > 35634. > > It's not undefined, but the conversion from int back to short provokes > implementation-defined behaviour when the int value doesn't fit in a short. > That makes this test program not strictly conforming. But converting from short to int for the argument to printf should behave as if a short value was converted to int, i.e. the int value should be in range -32768 to 32767, right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39736
[Bug tree-optimization/39736] signed overflow in loop induction variable: missing warning and wrong code
--- Comment #5 from edwintorok at gmail dot com 2009-04-13 06:56 --- (In reply to comment #4) > (In reply to comment #3) > > But converting from short to int for the argument to printf should behave > > as if > > a short value was converted to int, i.e. the int value should be in range > > -32768 to 32767, right? > > Usually but not here. Since you compiled with -fstrict-overflow (implicitly > via > -O2) the compiler can assume your short variables will have proper short > values. As an optimisation the compiler could decide to store short variables > in wider int variables and to perform short arithmetic using int arithmetic. > Since you promised not to cause signed overflow those int variables would > always be the proper sign-extension of the corresponding short variables. > > But your test program does cause signed overflow, so this optimisation changes > behaviour. It's still not the compiler's fault. If you deliberately cause > signed overflow, do not compile with -fstrict-overflow. > Understood. Then this is not wrong code, just a missing warning. (In reply to comment #0) > There are 2 bugs here: > - no warning is given with -Wstrict-overflow=5, although -fstrict-overflow > changes the behaviour of the code This is still a bug: "It warns about cases where the compiler optimizes based on the assumption that signed overflow does not occur." > - from is of type short, so when sign extended to an int, it should only take > values allowed for a short: -32768 to 32767, not all values allowed for an int > (like 2253491) This is not a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39736
[Bug middle-end/39891] New: Bogus location given for warning, no warning at real location: dereferencing pointer �� does break strict-aliasing rules
Compile attached testcase using:
$ g++-4.4 -c -O1 -fstrict-aliasing -Wstrict-aliasing foo.i
foo.i: In function Âbool foo()Â:
foo.i:8: warning: dereferencing pointer ÂÂ does break
strict-aliasing rules
foo.i:26: note: initialized from here
Line 8 has this:
7: APSInt &operator=(const APSInt &RHS) {
8:APInt::operator=(RHS);
Line 26 has this:
26: AdditionalOffset = Val.getInt();
None of these violate the strict aliasing rules.
The only place that could violate the strict aliasing rules in the testcase is
at line 17:
14: void *Data[sizeof(APSInt)];
15: public:
16: APSInt &getInt() {
17:return *(APSInt*)(void*)Data;
g++ 4.3.3 doesn't give any warning, neither does g++ 4.2.4.
I think this is a bug because:
- the warning is not given at the place that (possibly) violates the strict
aliasing rules, but at the place where the pointer obtained by violating the
rules is dereferenced.
- removing line 26 silences the warning, and no warning given for getInt or
operator= anymore
Also does the construct at line 17 really violate the aliasing rules?
$ g++-4.4 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.0-1~exp1'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-objc-gc
--with-arch-32=i486 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.0 (Debian 4.4.0-1~exp1)
--
Summary: Bogus location given for warning, no warning at real
location: dereferencing pointer ÂÂ does break
strict-aliasing rules
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39891
[Bug middle-end/39891] Bogus location given for warning, no warning at real location: dereferencing pointer �� does break strict-aliasing rules
--- Comment #1 from edwintorok at gmail dot com 2009-04-25 09:39 --- Created an attachment (id=17690) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17690&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39891
[Bug middle-end/39895] New: gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
Considering this code:
void dummy(void *x);
union union_t {
unsigned un;
char c;
} __attribute__((packed));
unsigned foo()
{
char x[4];
dummy(x);
return ((union union_t*)x)->un;
}
unsigned bar(char *x)
{
return ((union union_t*)x)->un;
}
With gcc-4.4 -Wstrict-aliasing=1 is the only one that does *not* give a
warning, levels 2 and 3 do give warnings:
$ gcc-4.4 -Wstrict-aliasing p.c -O2 -c
p.c: In function foo:
p.c:11: warning: dereferencing type-punned pointer will break strict-aliasing
rules
$ gcc-4.4 -Wstrict-aliasing=2 p.c -O2 -c
p.c: In function foo:
p.c:11: warning: dereferencing type-punned pointer will break strict-aliasing
rules
$ gcc-4.4 -Wstrict-aliasing=1 p.c -O2 -c
However in the case of gcc-4.3, -Wstrict-aliasing=2 is the only one that gives
warnings, levels 1 and 3 give no warning:
$ gcc-4.3 -Wstrict-aliasing p.c -O2 -c
$ gcc-4.3 -Wstrict-aliasing=2 p.c -O2 -c
p.c: In function foo:
p.c:11: warning: dereferencing type-punned pointer might break strict-aliasing
rules
$ gcc-4.3 -Wstrict-aliasing=1 p.c -O2 -c
According to the gcc manpage -Wstrict-aliasing=3 should have the fewest false
positives and false negatives, yet with gcc-4.4 -Wstrict-aliasing=3 gives a
warning that is not given at -Wstrict-aliasing=1 (the one that is supposed to
have many false positives).
This only happens if 'x' is allocated on the stack, gcc-4.4 is perfectly happy
if it is a char* argument to the function.
I've also tried the 'Casting through a union (1)' described at
http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html
but that too gives warnings by default.
Conclusion is that with gcc-4.4 -O2 -Wall there is no way to read/store from a
stack allocated variable through a union, using a different type member of the
union without raising a warning.
Is there another recommended way in gcc-4.4 to cast from uint8_t* to uint32_t*?
--
Summary: gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3
behaves like -Wstrict-aliasing=2 in gcc-4.3
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895
[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
--- Comment #2 from edwintorok at gmail dot com 2009-04-25 13:49 ---
(In reply to comment #1)
> Casting through a union (2)
>
> describes an invalid way of doing type-punning.
There is also a citation from C99 on that page:
"An object shall have its stored value accessed only by an lvalue expression
that has one of the following types:
* a type compatible with the effective type of the object,
* a qualified version of a type compatible with the effective type of the
object,
* a type that is the signed or unsigned type corresponding to the effective
type of the object,
* a type that is the signed or unsigned type corresponding to a qualified
version of the effective type of the object,
* an aggregate or union type that includes one of the aforementioned types
among its members (including, recursively, a member of a subaggregate or
contained union), or
* a character type."
I'm casting to a union that has both types as members, why doesn't that fit
under the 5th case in the above quote?
Also there is a warning for foo(), but there is no warning for bar(), but I
think they are exactly the same things wrt to violating or not the aliasing
rules.
>
> The only conforming and portable way is
>
> unsigned bar(char *x)
> {
> unsigned un;
> memcpy (&un, x, sizeof (un));
> return un;
> }
That may be too slow for me, I'll go with a static inline function that takes a
void* instead of a macro that does the cast.
>
> I have no opinion on the different levels of warnings (I think this case
> should be unconditionally).
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895
[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
--- Comment #4 from edwintorok at gmail dot com 2009-04-25 14:12 --- (In reply to comment #3) > > The above is properly optimized. Why do you think that an inline > function taking void * would fix anything? I can't know if memcpy will be inlined, it may just be a function call on certain systems, with certain compilers. The inline function should be a more portable way of expressing what I need, and it shouldn't cause any bugs with -fstrict-aliasing, since gcc already knows I gave my pointer to a function taking void*, so anything could happen with it, right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895
[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
--- Comment #7 from edwintorok at gmail dot com 2009-04-25 14:18 --- (In reply to comment #5) > > > "An object shall have its stored value accessed only by an lvalue > > > expression > > > that has one of the following types: > > > > > > * a type compatible with the effective type of the object, > > > * a qualified version of a type compatible with the effective type of > > > the > > > object, > > > * a type that is the signed or unsigned type corresponding to the > > > effective > > > type of the object, > > > * a type that is the signed or unsigned type corresponding to a > > > qualified > > > version of the effective type of the object, > > > * an aggregate or union type that includes one of the aforementioned > > > types > > > among its members (including, recursively, a member of a subaggregate or > > > contained union), or > > > * a character type." > > > > > > I'm casting to a union that has both types as members, why doesn't that > > > fit > > > under the 5th case in the above quote? > > > > Because it is certainly backwards. > > Or rather, this refers to a compatible type to the type that was used > to store the value, so it doesn't apply to type-punning. > Yes, the union has a compatibly type to the one used to store the value (it has a char member), hence the union can be used to access the value. I use a different member to access the value, but isn't that what unions are for? :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895
[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
--- Comment #9 from edwintorok at gmail dot com 2009-04-25 14:22 ---
(In reply to comment #6)
> No, not if it is inlined (and if not you can as well use memcpy).
>
> You can also do (GCC extension)
>
> union union_t {
> unsigned un;
> char c[4];
> };
>
> unsigned bar(char *x)
> {
> union union_t u;
> u.c[0] = x[0];
> u.c[1] = x[1];
> u.c[2] = x[2];
> u.c[3] = x[3];
> return u.un;
> }
>
> but that will even generate worse code with GCC than the
> memcpy (it's even horrible code).
Hmm, looks like the only way out is for me to put #if defined(__GNUC__) &&
(__GNUC__ > 4) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) and use memcpy.
Either that or add a configure rule to add -fno-strict-aliasing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895
[Bug lto/41756] New: LTO: -flto -O1 -use-linker-plugin, linking files compiled with -fno-exceptions with ones compiled with exceptions yields error "BB 14 can not throw but has an EH edge"
$ /home/edwin/inst/bin/g++ -v Using built-in specs. COLLECT_GCC=/home/edwin/inst/bin/g++ COLLECT_LTO_WRAPPER=/home/edwin/inst/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-lto --enable-languages=c,c++ --enable-gold Thread model: posix gcc version 4.5.0 20091019 (experimental) (GCC) sh -x script + /home/edwin/inst/bin/g++ -fPIC SourceMgr.i -flto -fno-exceptions -O1 -c -o SourceMgr.o + /home/edwin/inst/bin/g++ -fPIC AsmMatcherEmitter.i -flto -O1 -c -o AsmMatcher.o + /home/edwin/inst/bin/g++ -flto -use-linked-plugin -O1 AsmMatcher.o SourceMgr.o -shared In function EmitIsSubclass: lto1: error: BB 14 can not throw but has an EH edge lto1: error: BB 15 can not throw but has an EH edge lto1: error: BB 16 can not throw but has an EH edge lto1: error: BB 18 can not throw but has an EH edge lto1: error: BB 19 can not throw but has an EH edge lto1: error: BB 20 can not throw but has an EH edge lto1: error: BB 22 can not throw but has an EH edge lto1: error: BB 23 can not throw but has an EH edge lto1: error: BB 25 can not throw but has an EH edge lto1: error: BB 26 can not throw but has an EH edge lto1: error: BB 27 can not throw but has an EH edge lto1: error: BB 30 can not throw but has an EH edge lto1: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. lto-wrapper: /home/edwin/inst/bin/g++ returned 1 exit status collect2: lto-wrapper returned 1 exit status -- Summary: LTO: -flto -O1 -use-linker-plugin, linking files compiled with -fno-exceptions with ones compiled with exceptions yields error "BB 14 can not throw but has an EH edge" Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
[Bug lto/41756] LTO: -flto -O1 -use-linker-plugin, linking files compiled with -fno-exceptions with ones compiled with exceptions yields error "BB 14 can not throw but has an EH edge"
--- Comment #1 from edwintorok at gmail dot com 2009-10-19 16:55 --- Created an attachment (id=18827) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18827&action=view) SourceMgr.i preprocessed SourceMgr.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
[Bug lto/41756] LTO: -flto -O1 -use-linker-plugin, linking files compiled with -fno-exceptions with ones compiled with exceptions yields error "BB 14 can not throw but has an EH edge"
--- Comment #2 from edwintorok at gmail dot com 2009-10-19 16:56 --- Created an attachment (id=18828) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18828&action=view) AsmMatcherEmitter.i.bz2 bzipped preprocessed AsmMatcherEmitter.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
[Bug lto/41756] LTO: -flto -O1 -use-linker-plugin, linking files compiled with -fno-exceptions with ones compiled with exceptions yields error "BB 14 can not throw but has an EH edge"
--- Comment #3 from edwintorok at gmail dot com 2009-10-19 16:58 --- ld -v GNU gold (GNU Binutils for Debian 2.20) 1.9 This happens only if I use all of -flto -O1 -use-linker-plugin, not using -O1, or not using -use-linker-plugin hides the bug (and not using -flto too of course). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
[Bug lto/41756] LTO: -flto -O1 -use-linker-plugin, linking files compiled with -fno-exceptions with ones compiled with exceptions yields error "BB 14 can not throw but has an EH edge"
--- Comment #4 from edwintorok at gmail dot com 2009-10-19 16:59 --- (In reply to comment #3) > ld -v > GNU gold (GNU Binutils for Debian 2.20) 1.9 > > This happens only if I use all of -flto -O1 -use-linker-plugin, not using -O1, > or not using -use-linker-plugin hides the bug (and not using -flto too of > course). > Actually -use-linker-plugin makes no difference -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
[Bug lto/41761] New: lto1: error: type mismatch in component reference (const with non-const)
$ ~/inst/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/edwin/inst/bin/gcc COLLECT_LTO_WRAPPER=/home/edwin/inst/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-lto --enable-languages=c,c++ --enable-gold Thread model: posix gcc version 4.5.0 20091019 (experimental) (GCC) gcc -flto fails to compile ClamAV when built with --disable-shared, I reduced the problem to these two files: $ /home/edwin/inst/bin/gcc -flto 7z.i -o 7z.o -c $ /home/edwin/inst/bin/gcc -flto 7zIn.i -o 7zIn.o -c $ /home/edwin/inst/bin/gcc 7z.o 7zIn.o -flto -shared -use-linker-plugin In function SzArEx_GetFolderFullPackSize: lto1: error: type mismatch in component reference const struct CSzAr struct CSzAr D.1996_3 = p_2(D)->db.Folders; lto1: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. lto-wrapper: /home/edwin/inst/bin/gcc returned 1 exit status /usr/bin/ld: fatal error: lto-wrapper failed collect2: ld returned 1 exit status -- Summary: lto1: error: type mismatch in component reference (const with non-const) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41761
[Bug lto/41761] lto1: error: type mismatch in component reference (const with non-const)
--- Comment #1 from edwintorok at gmail dot com 2009-10-20 07:05 --- Created an attachment (id=18830) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18830&action=view) reduced testcase reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41761
[Bug lto/41761] lto1: error: type mismatch in component reference (const with non-const)
--- Comment #2 from edwintorok at gmail dot com 2009-10-20 07:06 --- Created an attachment (id=18831) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18831&action=view) original files The original 7z.i and 7zIn.i files that show the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41761
[Bug lto/41761] lto1: error: type mismatch in component reference (const with non-const)
--- Comment #7 from edwintorok at gmail dot com 2009-10-20 15:06 --- (In reply to comment #6) > Fixed. > Thanks, I can now successfully build ClamAV with lto. -- edwintorok at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41761
[Bug lto/41782] New: lto/gold: -flto -user-linker-plugin dies with internal error in gold
When trying to compile and link the attached not.i with lto the linker dies with this error: /usr/bin/ld: internal error in set_linkonce_size, at ../../gold/layout.h:250 This only occurs if I use -use-linker-plugin, so I think this may be a bug in gcc's gold plugin, so I'm filing this as a gcc bug (but it may also be a bug in gold triggered by lto). To reproduce: $ /home/edwin/inst/bin/g++ -flto -c not.i -o not.o $ /home/edwin/inst/bin/g++ -shared -flto -use-linker-pluginnot.o /usr/bin/ld: internal error in set_linkonce_size, at ../../gold/layout.h:250 collect2: ld returned 1 exit status $ /home/edwin/inst/bin/g++ -v Using built-in specs. COLLECT_GCC=/home/edwin/inst/bin/g++ COLLECT_LTO_WRAPPER=/home/edwin/inst/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-lto --enable-languages=c,c++ --enable-gold : (reconfigured) ../gcc/configure --enable-lto --enable-languages=c,c++ --enable-gold Thread model: posix gcc version 4.5.0 20091020 (experimental) (GCC) $ ld -v GNU gold (GNU Binutils for Debian 2.20) 1.9 -- Summary: lto/gold: -flto -user-linker-plugin dies with internal error in gold Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41782
[Bug lto/41782] lto/gold: -flto -user-linker-plugin dies with internal error in gold
--- Comment #1 from edwintorok at gmail dot com 2009-10-21 11:22 --- Created an attachment (id=18855) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18855&action=view) testcase (reduced not.i) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41782
[Bug preprocessor/50144] New: cc1plus double free / out of bounds read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50144 Bug #: 50144 Summary: cc1plus double free / out of bounds read Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassig...@gcc.gnu.org ReportedBy: edwinto...@gmail.com Created attachment 25066 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25066 x.cpp Lately gcc 4.6.1 has been segfaulting quite often. Not always on the same file, but usually when building ClamAV in 'make distcheck' mode. See below for a double free stacktrace. Running valgrind on the preprocessed file doesn't show anything, but running valgrind on original GCC invocation shows some errors in the preprocessor. Here is a command that reproduces the valgrind error. $ valgrind /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus -quiet x.cpp -E >/dev/null The file x.cpp is attached, and has all #include removed and still shows the valgrind error: ==3237== Invalid read of size 8 ==3237==at 0xBFEFE9: ??? (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xBFF181: _cpp_clean_line (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xBFFB57: _cpp_get_fresh_line (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xC012D1: _cpp_lex_direct (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xC02116: _cpp_lex_token (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xC04817: cpp_get_token (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xC04AAF: cpp_get_token_with_location (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x5AE914: preprocess_file (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x5ACF1A: c_common_init (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x513228: cxx_init (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x7D40AC: toplev_main (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x3C7141EEAC: (below main) (libc-start.c:228) ==3237== Address 0x4ceb0c0 is 7,232 bytes inside a block of size 7,238 alloc'd ==3237==at 0x4A07882: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3237==by 0xC2865C: xrealloc (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xBF3E5B: _cpp_convert_input (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xBFC782: ??? (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xBFD17A: _cpp_stack_file (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xBFEA55: cpp_read_main_file (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x5AC72A: c_common_post_options (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x7D3BA2: toplev_main (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x3C7141EEAC: (below main) (libc-start.c:228) ==3237== ==3237== Invalid read of size 8 ==3237==at 0xBFEFD3: ??? (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xBFF181: _cpp_clean_line (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xBFFB57: _cpp_get_fresh_line (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xC012D1: _cpp_lex_direct (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xC02116: _cpp_lex_token (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xC04817: cpp_get_token (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xC04AAF: cpp_get_token_with_location (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x5AE914: preprocess_file (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x5ACF1A: c_common_init (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x513228: cxx_init (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x7D40AC: toplev_main (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x3C7141EEAC: (below main) (libc-start.c:228) ==3237== Address 0x4ceb0c0 is 7,232 bytes inside a block of size 7,238 alloc'd ==3237==at 0x4A07882: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3237==by 0xC2865C: xrealloc (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xBF3E5B: _cpp_convert_input (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xBFC782: ??? (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus
[Bug preprocessor/50144] cc1plus double free / out of bounds read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50144 --- Comment #1 from Török Edwin 2011-08-21 15:52:33 UTC --- And here is a stacktrace from a local GCC build so you have line numbers: $ valgrind --trace-children=yes /home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc/xgcc -B/home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc /tmp/x.cpp -E >/dev/null ==2671== Memcheck, a memory error detector ==2671== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==2671== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==2671== Command: /home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc/xgcc -B/home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc /tmp/x.cpp -E ==2671== ==2675== Memcheck, a memory error detector ==2675== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==2675== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==2675== Command: /home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc/cc1plus -E -quiet -iprefix /home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc/../lib/gcc/x86_64-linux-gnu/4.6.1/ -isystem /home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc/include -isystem /home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc/include-fixed -D_GNU_SOURCE /tmp/x.cpp -mtune=generic -march=x86-64 ==2675== ==2675== Invalid read of size 8 ==2675==at 0x11D71C9: search_line_sse2 (lex.c:394) ==2675==by 0x11D7361: _cpp_clean_line (lex.c:666) ==2675==by 0x11D7D37: _cpp_get_fresh_line (lex.c:1887) ==2675==by 0x11D94B1: _cpp_lex_direct (lex.c:1952) ==2675==by 0x11DA2F6: _cpp_lex_token (lex.c:1826) ==2675==by 0x11DC9F7: cpp_get_token (macro.c:1240) ==2675==by 0x11DCC8F: cpp_get_token_with_location (macro.c:1352) ==2675==by 0x6C87A4: preprocess_file (c-ppoutput.c:175) ==2675==by 0x6C6D2B: c_common_init (c-opts.c:1057) ==2675==by 0x5C7668: cxx_init (lex.c:254) ==2675==by 0xA3204C: toplev_main (toplev.c:1742) ==2675==by 0x3C7141EEAC: (below main) (libc-start.c:228) ==2675== Address 0x4cec1f0 is 7,232 bytes inside a block of size 7,238 alloc'd ==2675==at 0x4A07882: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2675==by 0x120070C: xrealloc (xmalloc.c:179) ==2675==by 0x11CC03B: _cpp_convert_input (charset.c:1734) ==2675==by 0x11D4962: read_file (files.c:648) ==2675==by 0x11D535A: _cpp_stack_file (files.c:723) ==2675==by 0x11D6C35: cpp_read_main_file (init.c:570) ==2675==by 0x6C64EA: c_common_post_options (c-opts.c:1016) ==2675==by 0xA31B30: toplev_main (toplev.c:1283) ==2675==by 0x3C7141EEAC: (below main) (libc-start.c:228) ==2675== ==2675== Invalid read of size 8 ==2675==at 0x11D71B3: search_line_sse2 (lex.c:382) ==2675==by 0x11D7361: _cpp_clean_line (lex.c:666) ==2675==by 0x11D7D37: _cpp_get_fresh_line (lex.c:1887) ==2675==by 0x11D94B1: _cpp_lex_direct (lex.c:1952) ==2675==by 0x11DA2F6: _cpp_lex_token (lex.c:1826) ==2675==by 0x11DC9F7: cpp_get_token (macro.c:1240) ==2675==by 0x11DCC8F: cpp_get_token_with_location (macro.c:1352) ==2675==by 0x6C87A4: preprocess_file (c-ppoutput.c:175) ==2675==by 0x6C6D2B: c_common_init (c-opts.c:1057) ==2675==by 0x5C7668: cxx_init (lex.c:254) ==2675==by 0xA3204C: toplev_main (toplev.c:1742) ==2675==by 0x3C7141EEAC: (below main) (libc-start.c:228) ==2675== Address 0x4cec1f0 is 7,232 bytes inside a block of size 7,238 alloc'd ==2675==at 0x4A07882: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2675==by 0x120070C: xrealloc (xmalloc.c:179) ==2675==by 0x11CC03B: _cpp_convert_input (charset.c:1734) ==2675==by 0x11D4962: read_file (files.c:648) ==2675==by 0x11D535A: _cpp_stack_file (files.c:723) ==2675==by 0x11D6C35: cpp_read_main_file (init.c:570) ==2675==by 0x6C64EA: c_common_post_options (c-opts.c:1016) ==2675==by 0xA31B30: toplev_main (toplev.c:1283) ==2675==by 0x3C7141EEAC: (below main) (libc-start.c:228)
[Bug preprocessor/50144] cc1plus double free / out of bounds read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50144 --- Comment #3 from Török Edwin 2011-08-21 16:41:19 UTC --- (In reply to comment #2) > The valgrind errors about search_line_sse2 are valgrind bugs rather than gcc > bugs. Just ignore them. OK, I'll try to find some other valgrind trace. (In reply to comment #0) > CXXMemoryBuiltins.lo > *** glibc detected *** > /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus: double free or > corruption (out): 0x02a0e280 *** > === Backtrace: = > /lib/x86_64-linux-gnu/libc.so.6[0x3c71472606] > /lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x3c7147733c] > /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus(ggc_internal_alloc_stat+0x25e)[0x5bb86e] > /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus(ggc_internal_cleared_alloc_stat+0x16)[0x6c1446] > /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus(make_node_stat+0x1f)[0x8e1fff] > /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus(alloc_stmt_list+0x5a)[0x8059ca] > /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus(push_stmt_list+0x6)[0x5b47f6] > /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus[0x550e25] > /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus(begin_if_stmt+0x15)[0x551765] begin_if_stmt appears to be part of the parser though, not the preprocessor (I thought if refers to #if, but apparently not). So was this a parser crash?
[Bug preprocessor/50144] cc1plus double free / out of bounds read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50144 Török Edwin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Török Edwin 2011-08-21 19:48:34 UTC --- Nevermind, just did a memtest and it found 1 stuck bit in one of the 4G modules. Going to close this as invalid for now, as I was not able to get any more warnings with valgrind.
[Bug tree-optimization/43280] New: gcc4.5 -m32 -O2: misoptimizes sha256!
gcc-4.5 -O2 -m32 misoptimizes sha256: $ ~/gcc/install/bin/gcc-4.5 sha256.c -L/home/edwin/gcc/install/lib/gcc/x86_64-unknown-linux-gnu/lib32 -O2 -m32 $ ./a.out sha256 test vector #1 failed sha256 test vector #2 failed sha256 test vector #3 failed Aborted Without -m32 it works: $ ~/gcc/install/bin/gcc-4.5 sha256.c -L/home/edwin/gcc/install/lib/gcc/x86_64-unknown-linux-gnu/lib64 -O2 $ ./a.out $ And -m32 -O1 works too: $ ~/gcc/install/bin/gcc-4.5 sha256.c -L/home/edwin/gcc/install/lib/gcc/x86_64-unknown-linux-gnu/lib32 -O1 -m32 $ ./a.out $ gcc version: ~/gcc/install/bin/gcc-4.5 -v Using built-in specs. COLLECT_GCC=/home/edwin/gcc/install/bin/gcc-4.5 COLLECT_LTO_WRAPPER=/home/edwin/gcc/install/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --enable-languages=c --enable-checking=release --enable-ssp --disable-libssp --disable-plugin --disable-libmudflap --with-system-zlib --enable-version-specific-runtime-libs --program-suffix=-4.5 --enable-linux-futex -without-system-libunwind --with-arch-32=i586 --with-tune=generic --with-mpfr=/opt/cfarm/mpfr-2.4.1 --with-gmp=/opt/cfarm/gmp-4.2.4 --with-libelf=/opt/cfarm/libelf-0.8.12 --with-mpc=/opt/cfarm/mpc-0.8 --disable-bootstrap : (reconfigured) ../gcc-trunk/configure --prefix=/home/edwin/gcc/install --enable-languages=c --enable-checking=release --enable-ssp --disable-libssp --disable-plugin --disable-libmudflap --with-system-zlib --enable-version-specific-runtime-libs --program-suffix=-4.5 --enable-linux-futex -without-system-libunwind --with-arch-32=i586 --with-tune=generic --with-mpfr=/opt/cfarm/mpfr-2.4.1 --with-gmp=/opt/cfarm/gmp-4.2.4 --with-libelf=/opt/cfarm/libelf-0.8.12 --with-mpc=/opt/cfarm/mpc-0.8 --disable-bootstrap Thread model: posix gcc version 4.5.0 20100307 (experimental) (GCC) Bug initially reported against openSUSE 11.3 factory's gcc-4.5, but I reproduced with upstream gcc-4.5 SVN r157262. See https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1862 for the original report. -- Summary: gcc4.5 -m32 -O2: misoptimizes sha256! Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43280
[Bug tree-optimization/43280] gcc4.5 -m32 -O2: misoptimizes sha256!
--- Comment #1 from edwintorok at gmail dot com 2010-03-07 12:19 --- Created an attachment (id=20038) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20038&action=view) sha256.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43280
[Bug tree-optimization/43280] gcc4.5 -m32 -O2: misoptimizes sha256!
--- Comment #2 from edwintorok at gmail dot com 2010-03-07 12:19 --- Created an attachment (id=20039) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20039&action=view) preprocessed sha256.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43280
[Bug tree-optimization/43297] New: [4.3 regression] sparc64 -O2 -fPIC breaks htmlnorm.c
On sparc64 gcc 4.4.1 -O3 -fPIC breaks ClamAV's htmlnorm.c. To reproduce bug: $ /opt/cfarm/release/4.4.1/bin/gcc -O3 -fPIC hh.c $ ./a.out Aborted On the attached testcase -O2 -fPIC breaks too (on ClamAV's htmlnorm only -O3 breaks): $ /opt/cfarm/release/4.4.1/bin/gcc -O2 -fPIC hh.c $ ./a.out Aborted Working flags/compilers: $ /opt/cfarm/release/4.4.1/bin/gcc -O1 -fPIC hh.c $ ./a.out $ /opt/cfarm/release/4.4.1/bin/gcc -O2 hh.c $ ./a.out $ /opt/cfarm/release/4.4.1/bin/gcc -O3 hh.c $ ./a.out $ /opt/cfarm/release/4.3.3/bin/gcc -O3 -fPIC hh.c $ ./a.out $ /opt/cfarm/release/4.3.3/bin/gcc -O2 -fPIC hh.c $ ./a.out $ gcc -O3 -fPIC hh.c $ ./a.out $ gcc -O2 -fPIC hh.c $ ./a.out System: Linux gcc54 2.6.18-6-sparc64 #1 Sat Dec 27 11:05:53 UTC 2008 sparc64 GNU/Linux Buggy compiler version: $ /opt/cfarm/release/4.4.1/bin/gcc -v Using built-in specs. Target: sparc64-unknown-linux-gnu Configured with: ../gcc-4.4.1/configure --enable-languages=all,ada --enable-__cxa_atexit --disable-nls --with-mpfr=/opt/cfarm/mpfr-2.4.1 --with-gmp=/opt/cfarm/gmp-4.2.4 --prefix=/opt/cfarm/release/4.4.1 --with-cpu=v8 Thread model: posix gcc version 4.4.1 (GCC) Working compilers: $ /opt/cfarm/release/4.3.3/bin/gcc -v Using built-in specs. Target: sparc64-unknown-linux-gnu Configured with: ../gcc-4.3.3/configure --prefix=/opt/cfarm/release/4.3.3 --enable-__cxa_atexit --disable-nls --enable-threads=posix --with-mpfr=/opt/cfarm/mpfr-2.3.2 --with-cpu=v8 --enable-languages=c,ada Thread model: posix gcc version 4.3.3 (GCC) $ gcc -v Using built-in specs. Target: sparc-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-cpu=v8 --enable-checking=release sparc-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) -- Summary: [4.3 regression] sparc64 -O2 -fPIC breaks htmlnorm.c Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: sparc64-unknown-linux-gnu GCC host triplet: sparc64-unknown-linux-gnu GCC target triplet: sparc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43297
[Bug tree-optimization/43297] [4.3 regression] sparc64 -O2 -fPIC breaks htmlnorm.c
--- Comment #1 from edwintorok at gmail dot com 2010-03-08 21:03 --- Created an attachment (id=20046) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20046&action=view) testcase Testcase (partially) reduced with delta. Could probably be reduced further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43297
[Bug target/43297] [4.4 regression] -O2 -fPIC breaks htmlnorm.c
--- Comment #4 from edwintorok at gmail dot com 2010-03-09 13:01 --- (In reply to comment #3) > Please test a more recent version from the 4.4 branch (and trunk if possible). > Ok, I found gcc 4.4.3 on gcc200 and it still produces wrong code: $ /opt/cfarm/release/4.4.3/bin/gcc -v Using built-in specs. Target: sparc64-unknown-linux-gnu Configured with: ../gcc-4.4.3/configure --prefix=/opt/cfarm/release/4.4.3 --disable-werror --enable-languages=c,c++,fortran,ada --enable-__cxa_atexit --disable-nls --enable-threads=posix --with-gmp=/opt/cfarm/gmp-4.2.4 --with-mpfr=/opt/cfarm/mpfr-2.4.2 --with-cpu=v8 --disable-multilib Thread model: posix gcc version 4.4.3 (GCC) $ /opt/cfarm/release/4.4.3/bin/gcc -O2 -fPIC hh.c $ ./a.out Aborted It seems to be a problem only when creating 32-bit code, -m64 works fine: $ /opt/cfarm/release/4.4.3-64/bin/gcc -O2 -fPIC -m64 hh.c $./a.out And -m32 aborts of course: $ /opt/cfarm/release/4.4.3-64/bin/gcc -O2 -fPIC -m32 hh.c $./a.out /opt/cfarm/release/4.4.3-64/bin/gcc -v Using built-in specs. Target: sparc64-unknown-linux-gnu Configured with: ../gcc-4.4.3/configure --prefix=/opt/cfarm/release/4.4.3-64 --disable-werror --enable-languages=c,c++,fortran,ada --enable-__cxa_atexit --disable-nls --enable-threads=posix --with-gmp=/opt/cfarm/gmp-4.2.4-64 --with-mpfr=/opt/cfarm/mpfr-2.4.2-64 Thread model: posix gcc version 4.4.3 (GCC) Aborted -- edwintorok at gmail dot com changed: What|Removed |Added Known to fail|4.4.1 |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43297
[Bug tree-optimization/43472] New: gcc -O3: exhausts memory on whetstone.cbe.
gcc -O2 works on this file: gcc whetstone.cbe.c -lm -O2 -fno-strict-aliasing -fno-inline -m64 -fomit-frame-pointer gcc -O3 exhausts memory: gcc whetstone.cbe.c -lm -O3 -fno-strict-aliasing -fno-inline -m64 -fomit-frame-pointer virtual memory exhausted: Cannot allocate memory $ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.3-3' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.3 (Debian 4.4.3-3) $ uname -a Linux debian 2.6.33-00175-g2d1299a0 #10 SMP PREEMPT Mon Mar 15 15:42:54 EET 2010 x86_64 GNU/Linux The system has plenty of memory (4G of RAM + even more swap) $ free total used free sharedbuffers cached Mem: 398003213922882587744 0 20492 569508 -/+ buffers/cache: 8022883177744 Swap: 5863704 885085916 -- Summary: gcc -O3: exhausts memory on whetstone.cbe. Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43472
[Bug tree-optimization/43472] gcc -O3: exhausts memory on whetstone.cbe.
--- Comment #1 from edwintorok at gmail dot com 2010-03-21 20:11 --- Created an attachment (id=20155) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20155&action=view) whetstone.cbe.c testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43472
[Bug c++/43874] New: gcc should warn when 'new' is used on type with alignof greater than 2*sizeof(void*)
See
https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
http://sourceware.org/bugzilla/show_bug.cgi?id=206
When __alignof(type) is 16 on a 32-bit system, and 'new' returns only 8-byte
aligned memory, -ftree-vectorize can cause the code to crash.
GCC should at least warn (or even error out) when __alignof(type) >
alignment_of_new/malloc.
Or it could use memalign, to fix this and avoid the crash.
Right now it just silently creates code that crashes.
--
Summary: gcc should warn when 'new' is used on type with alignof
greater than 2*sizeof(void*)
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43874
[Bug libstdc++/42624] New: libstdc++ parallel mode deadlocks in barrier
s*) () from /home/edwin/clam/git/publicgitgit/libclamav/.libs/libclamav.so.6 #12 0x7f5191906e47 in llvm::LLVMTargetMachine::addCommonCodeGenPasses(llvm::PassManagerBase&, llvm::CodeGenOpt::Level) () from /home/edwin/clam/git/publicgitgit/libclamav/.libs/libclamav.so.6 #13 0x7f5191906c01 in llvm::LLVMTargetMachine::addPassesToEmitMachineCode(llvm::PassManagerBase&, llvm::JITCodeEmitter&, llvm::CodeGenOpt::Level) () from /home/edwin/clam/git/publicgitgit/libclamav/.libs/libclamav.so.6 #14 0x7f519139165e in llvm::JIT::JIT(llvm::ModuleProvider*, llvm::TargetMachine&, llvm::TargetJITInfo&, llvm::JITMemoryManager*, llvm::CodeGenOpt::Level, bool) () from /home/edwin/clam/git/publicgitgit/libclamav/.libs/libclamav.so.6 #15 0x7f5191391209 in llvm::JIT::createJIT(llvm::ModuleProvider*, std::string*, llvm::JITMemoryManager*, llvm::CodeGenOpt::Level, bool, llvm::CodeModel::Model) () from /home/edwin/clam/git/publicgitgit/libclamav/.libs/libclamav.so.6 #16 0x7f5191391131 in llvm::ExecutionEngine::createJIT(llvm::ModuleProvider*, std::string*, llvm::JITMemoryManager*, llvm::CodeGenOpt::Level, bool, llvm::CodeModel::Model) () from /home/edwin/clam/git/publicgitgit/libclamav/.libs/libclamav.so.6 #17 0x7f51913948ec in llvm::JIT::create(llvm::ModuleProvider*, std::string*, llvm::JITMemoryManager*, llvm::CodeGenOpt::Level, bool, llvm::CodeModel::Model) () from /home/edwin/clam/git/publicgitgit/libclamav/.libs/libclamav.so.6 #18 0x7f5191544b3f in llvm::EngineBuilder::create() () from /home/edwin/clam/git/publicgitgit/libclamav/.libs/libclamav.so.6 #19 0x7f519132d365 in cli_bytecode_prepare_jit () from /home/edwin/clam/git/publicgitgit/libclamav/.libs/libclamav.so.6 #20 0x7f5191310de8 in cli_bytecode_prepare (bcs=0x1703104) at bytecode.c:1580 #21 0x7f51912a380d in cl_engine_compile (engine=0x17009f0) at readdb.c:2614 #22 0x0040b0ea in reload_db (engine=0x17009f0, dboptions=8234, opts=, do_check=, ret=0x7fff884c216c) at server-th.c:231 #23 0x0040c426 in recvloop_th (socketds=0x0, nsockets=, engine=, dboptions=, opts=) at server-th.c:1265 #24 0x00407b4b in main (argc=, argv=) at clamd.c:486 (gdb) 9. See that in the thread backtrace one thread is waiting in poll(), other one in gomp_team_barrier_end, and those are only 2 threads. 10. Deadlock System info: $ g++ -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.2-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.2 (Debian 4.4.2-8) Sorry that I didn't reduce a testcase, a trivial testcase with std::find and pthread doesn't hang. There is also a problem with parallel mode when building LLVM, LLVM's tblgen makes very slow progress when multiple tblgen processes are executing in parallel on a multicore machine (see http://llvm.org/bugs/show_bug.cgi?id=5804) -- Summary: libstdc++ parallel mode deadlocks in barrier Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
--- Comment #1 from edwintorok at gmail dot com 2010-01-05 18:09 --- (In reply to comment #0) > $ make -j4 This should have been: make CCLD=g++ -j4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
--- Comment #4 from edwintorok at gmail dot com 2010-01-12 07:28 --- (In reply to comment #3) > Johannes is looking into it, Thanks. > certainly reproducing the problem will not be a > trivial taks, I'm afraid... > If the steps I listed in the bugreport don't work for you just let me know for which step you need more info. You can also ping me on #gcc (oftc.net), or #clamav (freenode.net). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
