-fstrict-aliasing/-fomit-frame-pointer and ostringstream-constructor

[Felix Natter <fnatter at gmx dot net>]

hi,
(libstdc++-2.90.7 with gcc-2.95.2)
(bug-reporting via sourceware.cygnus.com/libstdc++/ -> bug-reports does
not
work: I am redirected to the same page over and over)

I get problems when compiling with either -fstrict-aliasing or
-fomit-frame-pointer.

When using -fstrict-aliasing, I get something like an
infinite loop - I can't figure out what it is; when I hit ^C, gdb stops in
an ostringstream-constructor, and the arguments from the stack-trace don't
seem to match the argument I see in the source-code-reference..? (see
gdb-session below).

using -fomit-frame-pointer the stack-frame seems to get "corrupted":
"main" does not appear in the backtrace.

I have compiled (in source-form ;-) a test-case and have uploaded it to
http://www.ndh.net/home/natter/testcase.tar.bz2 (30k)
It's not a small program, however. A lot of headers are included because I
couldn't figure out how to isolate the problem, sorry. But it should not
be
hard to debug (i.e. it always happens in one place, and this function is
only called once):

gdb-session (when compiled with -fstrict-aliasing):
---------------------------
(gdb) bt
#0  0x4007baff in memset () at soinit.c:27
#1  0x8078ab9 in basic_ostringstream<char, char_traits<char>,
allocator<char> >::basic_ostringstream (this=0xaff0dc74, __in_chrg=134711993, __mode=32)
    at ../../bits/std_sstream.h:260
#2  0x8075c9c in void _S_pad_char<char, char_traits<char> > (
    __ios=@0xbffff540, __news=0xb7f867b4 "", __olds=0x810f564 "0", 
    __newlen=134711994, __oldlen=1) at ../../bits/ostream.tcc:421
#3  0x80761b4 in basic_ostream<char, char_traits<char> > &
operator<<<char_traits<char> > (__out=@0xbffff53c, __s=0x810f564 "0") at
../../bits/ostream.tcc:634
#4  0x8079854 in basic_ostream<char, char_traits<char> > &
operator<<<char, char_traits<char>, allocator<char> > (__out=@0xbffff53c, __s=@0x8111550)
    at ../../bits/ostream.tcc:657
#5  0x80ae898 in MSLEMatrix<RationalNumber>::printascii (this=0xbffff624, 
    out=@0xbffff53c) at MSLEMatrix.tcc:95
#6  0x804c725 in LaTeXPrintableComponent::print_fancy (this=0xbffff624, 
    out=@0x81099a0) at LaTeXPrintableComponent.cc:38
#7  0x804d26e in operator<< (out=@0x81099a0, lpc=@0xbffff624)
    at LaTeXPrintableComponent.cc:75
#8  0x80531f2 in main () at testcase.cc:13
Current language:  auto; currently c
(gdb) frame 1
#1  0x8078ab9 in basic_ostringstream<char, char_traits<char>,
allocator<char> >::basic_ostringstream (this=0xaff0dc74, __in_chrg=134711993, __mode=32)
    at ../../bits/std_sstream.h:260
Current language:  auto; currently c++
(gdb) l
255	
256	    public:
257	      // Constructors/destructor:
258	      explicit 
259	      basic_ostringstream(ios_base::openmode __mode = ios_base::out)
260	      : __ostream_type(new __stringbuf_type(__mode | ios_base::out))
261	      { }
262	
263	      explicit 
264	      basic_ostringstream(const __string_type __str,
(gdb)
q
-------------------------------------------------------------------------------

BTW: It would be nice if you could help me debug a gcc-problem that I am
having: when I compile some of the modules in this testcase-directory with
-O, cc1plus takes literally forever.

The problem does not occur if I compile with -O -fno-inline and also not
with -finline-functions (without -O), so I conclude that it occurs with
some strange combination of optimizations ?

-O: ?? seems to get stuck, although if I attach gdb to the process, it
 changes stack-frames (there appears to be no debugging-information for
 "cc1plus" although I compiled both gcc and binutils with -g ?) 
[ I've left it compiling during the night ... ]
=> compiling this "testcase" with -O takes about 80min.;

If I try to compile some of the more complex programs with -O (this
program
also requires -ftemplate-depth-25), it stops after about 2h with "virtual
memory exhausted" (I have 128M + 128M swap).

this is compared to:
-finline-functions: < 2min.
-O -fno-inline: < 3min.

then I looked up "-O" in "info gcc"
     When you specify `-O', the compiler turns on `-fthread-jumps' and
     `-fdefer-pop' on all machines.  The compiler turns on
     `-fdelayed-branch' on machines that have delay slots, and
     `-fomit-frame-pointer' on machines that can support debugging even
     without a frame pointer.  On some machines the compiler also turns
     on other flags.
but the problem is that if I turn on all these flags, then I do not get
the
same result as with "-O" (it compiles about equally fast as "-O
-fno-inline").

It's not important for me to get a fix for that. I'm mostly trying to
figure out why this is so.

thanks,

-- 
Felix Natter

-- 
Sent through GMX FreeMail - http://www.gmx.net