Re: c++ regression in trunk

Re: c++ regression in trunk

[Jack Howarth]

Geoff,
    When building xplor with -shared-libgcc -whyload, I don't see any
explicit symbols being loaded from libgcc_s. However from 
libxplorCmd.dylib, which has code called from xplor, I see...

/usr/lib/libgcc_s.1.dylib(unwind-dw2_s.o) loaded to resolve symbol: __Unwind_Resume
/usr/lib/libgcc_s.1.dylib(darwin-fallback_s.o) loaded to resolve private symbol: __Unwind_fallback_frame_state_for
/usr/lib/libgcc_s.1.dylib(dylib1.o) loaded to resolve private symbol: dyld_stub_binding_helper
/usr/lib/libgcc_s.1.dylib(link editor) loaded to resolve private symbol: __mh_dylib_header
/usr/lib/libgcc_s.1.dylib(darwin-fpsave_s.o) loaded to resolve private symbol: restFP
/usr/lib/libgcc_s.1.dylib(unwind-dw2-fde-darwin_s.o) loaded to resolve symbol: __Unwind_Find_FDE

Finally from libintVar.dylib, which has code called from libxplorCmd.dylib, I see...

/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.2.0/../../../libgcc_s.10.4.dylib(single module) loaded to resolve symbol: __Unwind_Resume

Let me know if you need anything else to pin this problem down.
            Jack

Re: c++ regression in trunk

[Geoffrey Keating]

[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]


On 31/05/2006, at 6:19 PM, Jack Howarth wrote:

> If I take the link line generated for -shared-libgcc and substitute  
> the
> the static libgcc, the resulting xplor binary doesn't abort on the  
> throw.
> Also if I take the link line generated without -shared-libgcc and add
> "-lgcc_s.10.4", the resulting xplor binary also doesn't abort on the
> throw. Anything else to try to help pin this down?

I think that's pretty conclusive: something in the FSF GCC libgcc is  
causing this behaviour.

But...  whatever it is must be in libgcc.a.  That is, the part of  
libgcc that *doesn't* contain any exception-handling code!

Some parts of libgcc.a (the moddi and divdi routines) are built with  
unwind information.  They're normally pretty simple, but maybe they  
contain bad data, or at least data that the shared library on Tiger  
doesn't understand.  I don't see anything particularly weird in my copy.

I guess the next step would be to try to narrow it down to a specific  
file in libgcc.a.  I think you can pass the '-whyload' command to the  
linker to see each .o file that gets loaded.  Hopefully this will  
narrow it down to just one, which I guess you could then send to me  
so I can see if it's different from the one I have built here.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2408 bytes --]

Re: c++ regression in trunk

[Jack Howarth]

Geoff,
   I should clarify my last comments. After looking at this some more it
appears that abort occurs unless I link in libgcc_s.10.4. That is both...

 "/sw/lib/gcc4/libexec/gcc/powerpc-apple-darwin8/4.2.0/collect2" "-dynamic" "-arch" "ppc" "-weak_reference_mismatches" "non-weak" "-o" "xplor" "-lcrt1.o" "/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.2.0/crt2.o" "-L." "-L/Users/howarth/Desktop/xplor-nih-2.14/bin.Darwin_8/" "-L/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config" "-L/Users/howarth/Desktop/xplor-nih-2.14/bin.Darwin_8/" "-L/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.2.0" "-L/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.2.0/../../.." "xplor.o" "-lxplorCmd" "-lxplor" "-lfft" "-lintVar" "-lvmd" "-lpy" "-lswigpy-xplor" "-ltclXplor" "-lswigtcl8-xplor" "-lnmrPot" "-lcommon" "-lmarvin" "-lpython2.3" "-ldl" "-lcrypto" "-lgcc" "-lSystemStubs" "-lSystem"

...and...

 "/sw/lib/gcc4/libexec/gcc/powerpc-apple-darwin8/4.2.0/collect2" "-dynamic" "-arch" "ppc" "-macosx_version_min" "10.3" "-multiply_defined" "suppress" "-weak_reference_mismatches" "non-weak" "-o" "xplor" "-lcrt1.o" "/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.2.0/crt2.o" "/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.2.0/crt3.o" "-L." "-L/Users/howarth/Desktop/xplor-nih-2.14/bin.Darwin_8/" "-L/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config" "-L/Users/howarth/Desktop/xplor-nih-2.14/bin.Darwin_8/" "-L/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.2.0" "-L/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.2.0/../../.." "xplor.o" "-lxplorCmd" "-lxplor" "-lfft" "-lintVar" "-lvmd" "-lpy" "-lswigpy-xplor" "-ltclXplor" "-lswigtcl8-xplor" "-lnmrPot" "-lcommon" "-lmarvin" "-lpython2.3" "-ldl" "-lcrypto" "-lgcc" "-lSystemStubs" "-lSystem"

...exhibit the abort on the c++ throw. However the first form works if I
substitute "-lgcc_s.10.4" for "-lgcc" in that link line. Also I have
verified that the static libgcc linked in is the one from gcc 4.2 and
not the one from the system libraries.
                 Jack

Re: c++ regression in trunk

[Jack Howarth]

Geoff,
   I am seeing...

gcc-4 -### -o xplor xplor.o  \
   \
  -L. -lxplorCmd -lxplor -L/Users/howarth/Desktop/xplor-nih-2.14/bin.Darwin_8/ -lfft -lintVar -lvmd -lpy -lswigpy-xplor -ltclXplor -lswigtcl8-xplor -lnmrPot -lcommon -lmarvin  \
  -L/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config -lpython2.3 -ldl   -L/Users/howarth/Desktop/xplor-nih-2.14/bin.Darwin_8/     -lcrypto \
   
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: ../gcc-4.2-20060529/configure --prefix=/sw --prefix=/sw/lib/gcc4 --disable-multilib --enable-languages=c,c++,fortran --infodir=/sw/lib/gcc4/share/info --with-gmp=/sw --with-included-gettext --host=powerpc-apple-darwin8 --with-as=/sw/lib/odcctools/bin/as --with-ld=/sw/lib/odcctools/bin/ld --with-nm=/sw/lib/odcctools/bin/nm
Thread model: posix
gcc version 4.2.0 20060529 (experimental)
 "/sw/lib/gcc4/libexec/gcc/powerpc-apple-darwin8/4.2.0/collect2" "-dynamic" "-arch" "ppc" "-weak_reference_mismatches" "non-weak" "-o" "xplor" "-lcrt1.o" "/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.2.0/crt2.o" "-L." "-L/Users/howarth/Desktop/xplor-nih-2.14/bin.Darwin_8/" "-L/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config" "-L/Users/howarth/Desktop/xplor-nih-2.14/bin.Darwin_8/" "-L/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.2.0" "-L/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.2.0/../../.." "xplor.o" "-lxplorCmd" "-lxplor" "-lfft" "-lintVar" "-lvmd" "-lpy" "-lswigpy-xplor" "-ltclXplor" "-lswigtcl8-xplor" "-lnmrPot" "-lcommon" "-lmarvin" "-lpython2.3" "-ldl" "-lcrypto" "-lgcc" "-lSystemStubs" "-lSystem"

...without passing -shared-libgcc to gcc and with -shared-libgcc I see...

gcc-4 -### -shared-libgcc -o xplor xplor.o  \
   \
  -L. -lxplorCmd -lxplor -L/Users/howarth/Desktop/xplor-nih-2.14/bin.Darwin_8/ -lfft -lintVar -lvmd -lpy -lswigpy-xplor -ltclXplor -lswigtcl8-xplor -lnmrPot -lcommon -lmarvin  \
  -L/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config -lpython2.3 -ldl   -L/Users/howarth/Desktop/xplor-nih-2.14/bin.Darwin_8/     -lcrypto \
   
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: ../gcc-4.2-20060529/configure --prefix=/sw --prefix=/sw/lib/gcc4 --disable-multilib --enable-languages=c,c++,fortran --infodir=/sw/lib/gcc4/share/info --with-gmp=/sw --with-included-gettext --host=powerpc-apple-darwin8 --with-as=/sw/lib/odcctools/bin/as --with-ld=/sw/lib/odcctools/bin/ld --with-nm=/sw/lib/odcctools/bin/nm
Thread model: posix
gcc version 4.2.0 20060529 (experimental)
 "/sw/lib/gcc4/libexec/gcc/powerpc-apple-darwin8/4.2.0/collect2" "-dynamic" "-arch" "ppc" "-macosx_version_min" "10.3" "-multiply_defined" "suppress" "-weak_reference_mismatches" "non-weak" "-o" "xplor" "-lcrt1.o" "/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.2.0/crt2.o" "/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.2.0/crt3.o" "-L." "-L/Users/howarth/Desktop/xplor-nih-2.14/bin.Darwin_8/" "-L/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config" "-L/Users/howarth/Desktop/xplor-nih-2.14/bin.Darwin_8/" "-L/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.2.0" "-L/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.2.0/../../.." "xplor.o" "-lxplorCmd" "-lxplor" "-lfft" "-lintVar" "-lvmd" "-lpy" "-lswigpy-xplor" "-ltclXplor" "-lswigtcl8-xplor" "-lnmrPot" "-lcommon" "-lmarvin" "-lpython2.3" "-ldl" "-lcrypto" "-lgcc_s.10.4" "-lgcc" "-lSystemStubs" "-lSystem"

If I take the link line generated for -shared-libgcc and substitute the
the static libgcc, the resulting xplor binary doesn't abort on the throw.
Also if I take the link line generated without -shared-libgcc and add
"-lgcc_s.10.4", the resulting xplor binary also doesn't abort on the
throw. Anything else to try to help pin this down?
         Jack

Re: c++ regression in trunk

[Geoffrey Keating]

[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]


On 31/05/2006, at 4:59 PM, Jack Howarth wrote:

> Geoff,
>     Nice call. If I relink xplor with 'gcc -shared-libgcc', the  
> program
> no longer aborts on the throw in the c++ code. As before, if I remove
> the '-shared-libgcc' and link with gcc, I get the abort on the throw.
> Anything else can provide to help pin this problem down? I did test
> current gcc trunk built on a Fedora Core 5 intel box and can confirm
> that this issue is darwin specific. I don't see any problems on intel
> linux with xplor-nih built using gcc trunk.

OK, this is helpful; but it's not quite enough yet.  One possibility  
is that the FSF GCC libgcc is somehow incompatible or broken on  
Darwin.  Another possibility is that something else triggered by - 
shared-libgcc is the cause (the other things at the moment are  
crt3.o, the minimum system version passed to the linker, and the  
setting of -multiply_defined to the linker).

So, what you want to do is use '-###' to see what's changing, and  
either take the working link line and substitute a static libgcc, or  
take the broken one and substitute the shared libgcc.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2408 bytes --]

Re: c++ regression in trunk

[Jack Howarth]

Geoff,
    Nice call. If I relink xplor with 'gcc -shared-libgcc', the program
no longer aborts on the throw in the c++ code. As before, if I remove
the '-shared-libgcc' and link with gcc, I get the abort on the throw.
Anything else can provide to help pin this problem down? I did test
current gcc trunk built on a Fedora Core 5 intel box and can confirm
that this issue is darwin specific. I don't see any problems on intel
linux with xplor-nih built using gcc trunk.
           Jack

Re: c++ regression in trunk

[Mike Stump]

On May 30, 2006, at 9:14 PM, Jack Howarth wrote:
> I am able to suppress the aborts on the throw in xplor-nih when
> built under gcc 4.2 if I link the main xplor program with g++ rather
> than gcc. Should this be considered a regression from gcc 4.0/4.1?

Don't know, as we don't know what the bug is yet.  If it is a bug in  
the compiler, and it has regressed, then yes, it is a regression,  
otherwise, no.

Re: c++ regression in trunk

[Geoffrey Keating]

howarth@bromo.msbb.uc.edu (Jack Howarth) writes:

> Mike,
>    Actually the problem appears unrelated to cxa_atexit as neither
> -fuse-cxa-atexit nor -fno-use-cxa-atexit eliminates the problem
> with the throw aborting the program. 
>    I do believe I have found a work-around to the problem which
> identifies the nature of the issue as well. The xplor-nih program
> (xplor) is linked with gcc (since it contains only a single object
> file of c). However shared libraries of c++ and fortran code are
> linked to the main xplor program as well. The main c routine in
> xplor calls a fortran routine in one of its fortran shared libraries
> which in turn calls and returns from c++ code in a c++ shared library.
>   I am able to suppress the aborts on the throw in xplor-nih when
> built under gcc 4.2 if I link the main xplor program with g++ rather
> than gcc. Should this be considered a regression from gcc 4.0/4.1?
> Since the c++ shared libraries are linked with g++ and the fortran
> shared libraries are linked with gfortran, it seemed that the main
> program (containing only a single object file from c code) should
> be linkable with gcc (despite c++ and fortran shared libraries being
> linked in to the main xplor program).

To further narrow this down, try linking with 'gcc -shared-libgcc'.

Yes, if the main program has no C++ code then it should be able to be
linked with gcc.

Re: c++ regression in trunk

[Jack Howarth]

Mike,
   Actually the problem appears unrelated to cxa_atexit as neither
-fuse-cxa-atexit nor -fno-use-cxa-atexit eliminates the problem
with the throw aborting the program. 
   I do believe I have found a work-around to the problem which
identifies the nature of the issue as well. The xplor-nih program
(xplor) is linked with gcc (since it contains only a single object
file of c). However shared libraries of c++ and fortran code are
linked to the main xplor program as well. The main c routine in
xplor calls a fortran routine in one of its fortran shared libraries
which in turn calls and returns from c++ code in a c++ shared library.
  I am able to suppress the aborts on the throw in xplor-nih when
built under gcc 4.2 if I link the main xplor program with g++ rather
than gcc. Should this be considered a regression from gcc 4.0/4.1?
Since the c++ shared libraries are linked with g++ and the fortran
shared libraries are linked with gfortran, it seemed that the main
program (containing only a single object file from c code) should
be linkable with gcc (despite c++ and fortran shared libraries being
linked in to the main xplor program).
                   Jack

Re: c++ regression in trunk

[Mike Stump]

On May 30, 2006, at 3:25 PM, Jack Howarth wrote:
> ...and I get no hits suggesting it can't be a wrong visibility  
> problem.

I prefer the idea that it reduces the likelihood of such a problem.  :-)

> Is there some approach I can use to figure out if it is a throw across
> a dylib or bundle boundary?

Yes.  If you aren't using bundles forget about that issue.  The  
approach is to write a dylib and app that mirror the direction you  
are throwing.

For example, the obvious:

main() {
   try { dylib(); } catch(...) { printf("It worked"."); }
}

and in the dylib:

void dolib() {
   throw 1;
}

tests to see if a throw from a dylib into the app works.

> I noticed from the 4.2 change page that...
>
> The configure variable enable-__cxa_atexit is now enabled by default

> Is darwin one of those targets that changed at 4.2? If so is there  
> a flag
> to reverse that behavior for individual source files?

Why ask me, when you can ask the compiler with documented -fuse-cxa- 
atexit and -fno-use-cxa-atexit flags and have it tell you with  
amazing accuracy?  Yes, Geoff has been playing in this area.  It had  
been off, and it later versions, it is on.  You can check the  
ChangeLog file and find:

2006-03-15  Geoffrey Keating  <geoffk@apple.com>

         * config.gcc (*-*-darwin*): Don't build crt2.o for all  
Darwin ports.
         Do switch on default_use_cxa_atexit.
         (powerpc*-*-darwin*): Build crt2.o on powerpc.
         * config/darwin-crt3.o: New.
         * config/darwin.h (LINK_SPEC): If -shared-libgcc, make  
linker default
         to 10.3.  Pass '-multiply_defined suppress' if crt3.o is in  
use.
         (STARTFILE_SPEC): Add crt3.o when -shared-libgcc and  
appropriate
         OS version.
         * config/rs6000/t-darwin: Move crt2.o building to here.
         * config/rs6000/darwin.h (C_COMMON_OVERRIDE_OPTIONS): Update
         Mac OS version for using __cxa_get_exception_ptr.  Don't  
test versions
         of __cxa_atexit.

and you can also test before and after it to see if it is related,  
though, in theory the -f flags should be enough.

Also, this list isn't the right place to obtain help with broken user  
code, just broken compiler code.  Ideally, we want you to first debug  
it and then ask here for help after broken user code is ruled out.   
If the app shows an issue with the new cxa code-gen, I'd hazard a  
guess that it is an app bug [ fingers crossed ].

Re: c++ regression in trunk

[Jack Howarth]

Mike,
   I've checked all of the object files in xplor-nih with...

nm -m *.o | c++filt | grep info | grep -v external

...and I get no hits suggesting it can't be a wrong visibility problem.
Is there some approach I can use to figure out if it is a throw across
a dylib or bundle boundary? My initial guess is that it isn't that either.
The .cc source files that show up in the backtrace (dinternal.cc,
dint-xplor.cc and dint-powell.cc) are all linked together into
libintVar.dylib using...

g++-4 -dynamiclib -flat_namespace -undefined suppress -single_module dinternal.o dint-atom.o dint-node.o dint-loop.o dint-step.o dint-powell.o dint-conmin.o dint-simplex.o dint-pc6.o dint-xplor.o publicIVM.o -o libintVar.dylib    -lcrypto /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib 

Also, I don't see this c++ regression when building xplor-nih with
the gcc/g++ from Xcode 2.3 and gfortran from gcc trunk or with
gcc/g++/gfortran from gcc 4.1.1. If it really were a problem with
a throw across a dylib wouldn't those versions break as well?
    I noticed from the 4.2 change page that...

The configure variable enable-__cxa_atexit is now enabled by default for more targets. Enabling this variable is necessary in order for static destructors to be executed in the correct order, but it depends upon the presence of a non-standard C library in the target library in order to work. The variable is now enabled for more targets which are known to have suitable C libraries.

Is darwin one of those targets that changed at 4.2? If so is there a flag
to reverse that behavior for individual source files?
              Jack

Re: c++ regression in trunk

[Mike Stump]

On May 29, 2006, at 1:17 PM, Jack Howarth wrote:
> In building xplor-nih against the gcc trunk, I noticed that there  
> is a c++ related
> regression

I'll let Andrew comment if it sounds like anything he's seen.  I'd  
recommend a binary search to narrow down the translation unit and the  
compiler version that went bad if the prospects of actually trying to  
debug this are daunting.

Off-hand, sounds like throw across dylib/bundle boundary problem, or  
someone using the wrong visibility on classes.

You can  check for the later by something like:

nm -m *.o | c++filt | grep info | grep -v external

and seeing if you get any hits.  If so, they could be the cause of  
the problem.

The first case might be easier to test in the small, as if it is  
totally busted, even the most trivial of programs will show the  
breakage.

c++ regression in trunk

[Jack Howarth]

    In building xplor-nih against the gcc trunk, I noticed that there is a c++ related
regression that isn't present when building xplor-nih against gcc 4.1.1 or the gfortran
of gcc trunk and the gcc/g++ of Apple's current Xcode 2.3 release. The error shows up
in xplor-nih's dipCoup.inp test which aborts as follows when built with g++ from the
trunk...

 -------------------------------------------------------------------------------
 -- POWELL ------ step=      5 --- stepsize=  0.020455 --- energy evals=    2 --
 | Etotal =181.583    grad(E)=4.894      E(BOND)=6.068      E(ANGL)=160.218    |
 | E(IMPR)=5.596      E(XDIP)=9.701                                            |
 -------------------------------------------------------------------------------
Powell::step: irregular exit: Line search abandoned: gradient may be incorrect
terminate called after throwing an instance of 'Integrator::Finished'

Program received signal SIGABRT, Aborted.
0x9004802c in kill ()
(gdb) bt
#0  0x9004802c in kill ()
#1  0x9012dfb4 in abort ()
#2  0x052a9df4 in __gnu_cxx::__verbose_terminate_handler () at ../../../../gcc-4.2-20060526/libstdc++-v3/libsupc++/vterminate.cc:98
#3  0x052a78b8 in __cxxabiv1::__terminate (handler=0) at ../../../../gcc-4.2-20060526/libstdc++-v3/libsupc++/eh_terminate.cc:43
#4  0x052a67a4 in __cxa_call_terminate (ue_header=0x5a346d0) at ../../../../gcc-4.2-20060526/libstdc++-v3/libsupc++/eh_call.cc:59
#5  0x052a75fc in __gxx_personality_v0 (version=0, actions=2, exception_class=11529286998044974156, ue_header=0x5a346d0, context=0xbfffcb2c) at ../../../../gcc-4.2-20060526/libstdc++-v3/libsupc++/eh_personality.cc:639
#6  0x91429918 in _Unwind_RaiseException_Phase2 ()
#7  0x91429a18 in _Unwind_Resume ()
#8  0x0022d19c in Powell::step (this=0x5a3d940, stepsize=0.00039998906256061956) at dint-powell.cc:321
#9  0x00207728 in IVM::step (this=0x5a0d050, timeStep=@0x2a2c28) at dinternal.cc:813
#10 0x0023c268 in XplorIVM::entry (this=0x5a0d050) at dint-xplor.cc:804
#11 0x02970b34 in dynmcs_ (fbeta=0x0, x=0x0, y=0xa0004170, z=0xa0001c4c, dx=0x5a346d0, dy=0xbfffb33c, dz=0x5a24230, xv=0x900227b4, yv=0x6287600, zv=0x6289000, amass=0x628c400, imove=0x628de00, res=0x6292400, resid=0x6293200, type=0x6294000, ib=0x600b400, jb=0x600ce00, _res=-1073750708, _resid=12192, _type=12200) at dynamc.f:86
#12 0x000634c4 in xplor_parse_ (qsubshell=@0xbfffdd48) at xplorFunc.f:423
#13 0x000027b4 in main (argc=2, argv=0xbfffde58) at xplor.c:116

The "Powell::step: irregular exit: Line search abandoned: gradient may be incorrect" output is normal, but the terminate called
isn't of course. Building the c++ code in xplor-nih with -O0 doesn't eliminate this problem. Does this issue resemble any
existing PR or should I attempt to pin this one done (which may be difficult since the code is pretty complex)?
          Jack