Program: ---8X--------------------------- #include<fstream> int main() { std::ofstream file("test.txt"); std::streampos startpos = file.tellp(); file << 10; std::streampos endpos = file.tellp(); assert(endpos != startpos); return 0; } ---X8--------------------------- compile at g++ 3.4.3 and work fine, but fail after compile at g++ 4.0.0 20041215 (mainline). Also note: if set LD_LIBRARY_PATH point to gcc_34/lib (my gcc 3.4 lib directory) compiled with g++ 4.0 program work fine (using old gcc 3.4 shared libraries). I think problem in code of "libstdc++.so.6" or "libgcc_s.so.1" Vladimir
Created attachment 7772 [details] .ii file
Created attachment 7773 [details] .s file
Hmm, it works for me on ppc-darwin with the mainline (20041215 and 20041214 and 20041213).
First time i see this problem in september-october. Now i only fill PR. Program work for me only if it used gcc 3.4.x shared libraries. ~/pkg/gcc/bin/g++ test.cc setenv LD_LIBRARY_PATH $HOME/pkg/gcc_34/lib ./a.out setenv LD_LIBRARY_PATH $HOME/pkg/gcc/lib ./a.out Assertion failed: (endpos != startpos), function main, file test.cc, line 15. Abort (core dumped)
At my FreebSD 5.3 problem show-up with GCC mainline sources in range: At 2004-05-10 testcase work fine At 2004-05-14 testcase failed And i think this point to "The tree-ssa branch has been merged into mainline." event. I will attempt locate problematic commit at tree-ssa branch.
Cannot reproduce on i686-pc-linux-gnu too. I would suggest recategorizing as 'target'.
Good news: i found commit when problem arised: http://gcc.gnu.org/ml/gcc- cvs/2003-10/msg01125.html Before this commit testcase compile without problems. After this commit testcase compilation failed. Bad news: This is merge from mainline to tree-ssa.
In my opinion, this is definitely a (target dependent) code generation bug, rather serious, if confirmed. As such, we should do our best to reduce it and recategorize in the right way. Any chance you can try to reduce it to a short, pure c++ snippet? The relevant library code is quite straightforward.
At this moment i can't extract simple testcase. But problem indeed in miscompiletion. I am use modified testcase (additionl debug output line before assert (and iostream header include: std::cout << "begin==" << startpos << " end==" << endpos << "\n"; Valid output: "begin==0 end==8" Invalid output:"begin==-1 end==-1" I bootstrap GCC from current sources with additional -save-temps flag and compile and link libsupc++.a library and requred for my testcase .ii (renamed to .cc) files from libstdc++ library. Final testcase executible work without problems with valid output. But if i compile basic_file.cc (renamed .ii version) with -O2 option then testcase executible run terminated with invalid output "begin==-1 end==- 1" and assert fail.
Created attachment 7847 [details] .ii file from gcc build object directory
Created attachment 7848 [details] .s compiled from basic_file.cc with default oprions
Created attachment 7849 [details] .s compiled from basic_file.cc with -O2 (miscompiled version)
I extract problematic compiled (with -O2) function: ---8X----------------------------- #include <bits/basic_file.h> #include <fcntl.h> #include <limits> // For <off_t>::max() and min() and <streamsize>::max() namespace std { streamoff __basic_file<char>::seekoff(streamoff __off, ios_base::seekdir __way) { if (__off > numeric_limits<off_t>::max() || __off < numeric_limits<off_t>::min()) return -1L; return lseek(this->fd(), __off, __way); } } // namespace std ---X8-----------------------------
Created attachment 7852 [details] .s compiled from basic_file.cc with default oprions
Created attachment 7853 [details] .s compiled from basic_file.cc with -O2 (miscompiled version)
Hmm, this is the reduced testcase but it was not miscompiled as far as I can see: typedef int __attribute__((__mode__(__DI__))) __int64_t; typedef __int64_t int64_t; typedef int64_t streamoff; typedef __int64_t __off_t; typedef __off_t off_t; static long long min() throw() { return -9223372036854775807LL - 1; } static long long max() throw() { return 9223372036854775807LL; } __off_t lseek(int, __off_t, int); streamoff seekoff(streamoff __off) { if (__off > max() || __off < min()) return -1L; return 0; }
Andrew, this is *definitely* target dependent: it's about such a basic feature that we would have noticed, otherwise! (btw, thanks for the reduced testcase!)
This more simplifed version of your last testcase also catch -O2 problem: #include<cassert> typedef int __attribute__((__mode__(__DI__))) off_t; static long long min() throw() { return -9223372036854775807LL - 1; } static long long max() throw() { return 9223372036854775807LL; } void seekoff(off_t __off) { if (__off > max() || __off < min()) assert(false); } int main() { seekoff(10); return 0; }
Confirmed with your reduced testcase. t21.dom1 is where the problem comes in.
(In reply to comment #19) > Confirmed with your reduced testcase. > > t21.dom1 is where the problem comes in. This also happens on i686-pc-linux. I think this is related to HWI being only 32bit as it works with a x86_64 and -m32.
Yes, I can reproduce with the last testcase. Still, I can't with the original one, that explains why we haven't noticed yet... Thanks to everyone.
Ah, now I see: the problematic code path is actually used *only* when _GLIBCXX_USE_LFS is not defined, whereas normally is defined, on linux.
// C testcase void abort (void); static long long min () { return -9223372036854775807LL - 1; } void foo (long long j) { if (j > 10 || j < min ()) abort (); } int main () { foo (10); return 0; }
Note this is only reproducible with HWI being 32bit (x86 is an example but I cannot think of another one).
Patch here: <http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00205.html>.
New patch proposed by Jakub Jelinek: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00393.html work fine at FreeBSD 5.3 and fix 52 tests in libstdc++ testsuite at FreeBSD 5.3: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00609.html
Subject: Bug 19060 CVSROOT: /cvs/gcc Module name: gcc Changes by: jakub@gcc.gnu.org 2005-01-15 09:46:10 Modified files: gcc : ChangeLog fold-const.c tree-ssa-dom.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: 20050104-1.c Log message: PR tree-optimization/19060 * tree-ssa-dom.c (extract_range_from_cond) <case LT_EXPR, GT_EXPR>: Return 0 if op1 <= TYPE_MIN_VALUE () resp. op1 >= TYPE_MAX_VALUE (). (simplify_cond_and_lookup_avail_expr): Add assert for dummy == 0 and handle extract_range_from_cond returning false. * fold-const.c (fold): Optimize comparisons with min/max even for width > HOST_BITS_PER_WIDE_INT. * gcc.c-torture/execute/20050104-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7133&r2=2.7134 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.492&r2=1.493 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-dom.c.diff?cvsroot=gcc&r1=2.81&r2=2.82 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4889&r2=1.4890 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050104-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
Jakub, can you please close bugs after you have commited your fixes?
Subject: Re: [4.0 Regression] Miscompiling of if and "long long" steven at gcc dot gnu dot org wrote: > ------- Additional Comments From steven at gcc dot gnu dot org 2005-01-15 12:46 ------- > Jakub, can you please close bugs after you have commited your fixes? Do not close it, it causes bootstrap failure on ppc linux.
Do not know if it is really this patch or if we uncover another problem: /mnt/slice1/gcc-trunk/gcc/gcc/libgcc2.c: In function '__mulvdi3': /mnt/slice1/gcc-trunk/gcc/gcc/libgcc2.c:279: internal compiler error: in simplify_cond_and_lookup_avail_expr, at tree-ssa-dom.c:2099 on ppc linux with checking disabled.
Created attachment 7964 [details] libgcc2.i file from ppc linux
Starting program: /mnt/slice1/gcc-trunk/objdir/gcc/cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -auxbase-strip libgcc/./_mulvdi3.o -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fPIC -fvisibility=hidden -o libgcc2.s Gives this first bt frames: (gdb) bt full #0 fancy_abort ( file=0x105c0624 "/mnt/slice1/gcc-trunk/gcc/gcc/tree-ssa-dom.c", line=2099, function=0x105c0980 "simplify_cond_and_lookup_avail_expr") at /mnt/slice1/gcc-trunk/gcc/gcc/diagnostic.c:556 No locals. #1 0x100e6ee0 in simplify_cond_and_lookup_avail_expr (stmt=0x304341b8, ann=0x3043b690, insert=0) at /mnt/slice1/gcc-trunk/gcc/gcc/tree-ssa-dom.c:2099 tmp_high = 0x0 tmp_low = 0x3043e360 dummy = 0 lowequal = 276425792 vrp_hash_elt_p = (struct vrp_hash_elt *) 0x107bf130 highequal = 268349012 no_overlap = 2147479040 cond_inverted = 0 limit = 1 high = 0x300217c8 cond_high = 0x30263a60 subset = 267452224 vrp_records = 0x3043e360 slot = (void **) 0x107be8c4 low = 0x0 ---Type <return> to continue, or q <return> to quit--- cond_low = 0x30263a60 swapped = 268360004 element = (struct vrp_element *) 0x3043c400 vrp_hash_elt = {var = 0x30434848, records = 0x0} op0 = 0x30434848 op1 = 0x30263a60 cond = 0x3042bde8 __FUNCTION__ = "simplify_cond_and_lookup_avail_expr" #2 0x100e823c in eliminate_redundant_computations (walk_data=0x7ffff3e0, stmt=0x304341b8, ann=0x3043b690) at /mnt/slice1/gcc-trunk/gcc/gcc/tree-ssa-dom.c:2571 v_may_defs = 0x0 expr_p = (tree *) 0x43b6a4 def = 0x0 insert = 0 '\0' cached_lhs = 0x0 retval = 0 '\0' __FUNCTION__ = "eliminate_redundant_computations"
Subject: Re: [4.0 Regression] Miscompiling of if and "long long" > ------- Additional Comments From toa at pop dot agri dot ch 2005-01-15 > 12:48 ------- > Subject: Re: [4.0 Regression] Miscompiling of > if and "long long" > > steven at gcc dot gnu dot org wrote: >> ------- Additional Comments From steven at gcc dot gnu dot org >> 2005-01-15 12:46 ------- >> Jakub, can you please close bugs after you have commited your fixes? > > Do not close it, it causes bootstrap failure on ppc linux. Are you sure? I have bootstraped one day old gcc with this patch applyed. But current version GCC mainline terminated with same error at FreeBSD 5.3 (x86). I think this patch doesn't related to bootstrap failure. Vladimir
I have bootstrapped the patch yesterday on {i386,x86_64,ppc,ppc64,s390,s390x,ia64}-redhat-linux and it certainly worked. The only change was that tree_int_cst_equal || tree_int_cst_lt -> tree_int_cst_lt that ought to be correct. Anyway, I'll start debugging this in ~ 2 hours.
> Are you sure? I check GCC mainline (2005-01-15 09:00 GMT - before PR 19060 patch) - ./xgcc compile __mulvdi3 without problems And GCC mainline (2005-01-15 09:00 GMT - after PR 19060 patch) - ./xgcc __mulvdi3 compilation ICE And then PR 19060 patch create problem. :( Or interfere with another last day patch...