RE: C++ Optimization with g++

RE: C++ Optimization with g++

[lrtaylor]

Have you tried looking at a stack trace?  If your program is SEGV'ing,
it should be producing a core file (I guess unless you're on Windows).
You can inspect that core file using GDB, including the full stack
(including variable values, etc.) at the time of the crash.  That's
usually the first place I look when a program crashes.

Good luck,
Lyle

-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of David.Carter-Hitchin
Sent: Thursday, February 19, 2004 7:13 AM
To: gcc-help@gcc.gnu.org
Subject: C++ Optimization with g++

Hi,

I haven't done a great deal of optimization, so apologies in advance for
any
dumb or mis-directed questions.

I've got this nice little ~5,000 line c++ program at home which plots
the
positions of planets and the Yale Bright Star Catalogue.

So far so good.

Scrolling an zooming are fine, but when I swtich the option on to
display
dates (which involves rotating the bitmaps for the textstrings through
90
degrees) it runs "like a dog" and I'm not talking greyhound, more like a
three-legged dachshund.

So I tried putting -O[0123] on and ploop, the program is just warming up
and
then it SEGV's.  It seems to be happening at the end of one function
call
(which appears to run fine) or at the very start of another.  Compiling
with
-g and running in gdb shows the point, which is just at the final } from
the
last function that works successfully.

Ultimately I can reprogram the date stuff so I don't have to rotate the
dates on the fly (which is the way I should have done it originally),
but
now I'm curious.

How can I find out why -O[0123] fails?  Is there a strategy I can follow
or doc I should read?  Is there a "simple" way of debugging my way out
of
this situation, or is there no alternative to inspecting the assembly?

gcc version 2.9.something (not threaded).

All help and clues appreciated.

Many thanks,

David Carter-Hitchin,
GSD-Risk-IT, UBS Investment Bank

RE: C++ Optimization with g++

[David.Carter-Hitchin]

Hi Lyle,

Thanks for the interest you've taken in this little problem.

I have tried looking at the core file with gdb, but I didn't get anything
meaningful from it.  I typed "where" and merely got something like this:

# 00000000? at () ??

(That's from memory, so it might be not 100% correct - but it's faily
close).  That was after compilining with -g (I also tried -g3).

Apart from that I don't really know what else to do with a core file.  If
you've got any good "magic commands" that would be ace if you could share
them with me.

Some other helpful folk, have offered reams of advice concerning my
programming style (or lack thereof), so I'll try their suggestions and post
back to this thread when I solve the problem.

Many thanks,

David Carter-Hitchin,
GSD-Risk-IT, UBS Investment Bank

On Thu, 19 Feb 2004 lrtaylor@micron.com wrote:

> Have you tried looking at a stack trace?  If your program is SEGV'ing,
> it should be producing a core file (I guess unless you're on Windows).
> You can inspect that core file using GDB, including the full stack
> (including variable values, etc.) at the time of the crash.  That's
> usually the first place I look when a program crashes.
>
> Good luck,
> Lyle
>
> -----Original Message-----
> From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
> Behalf Of David.Carter-Hitchin
> Sent: Thursday, February 19, 2004 7:13 AM
> To: gcc-help@gcc.gnu.org
> Subject: C++ Optimization with g++
>
> Hi,
>
> I haven't done a great deal of optimization, so apologies in advance for
> any
> dumb or mis-directed questions.
>
> I've got this nice little ~5,000 line c++ program at home which plots
> the
> positions of planets and the Yale Bright Star Catalogue.
>
> So far so good.
>
> Scrolling an zooming are fine, but when I swtich the option on to
> display
> dates (which involves rotating the bitmaps for the textstrings through
> 90
> degrees) it runs "like a dog" and I'm not talking greyhound, more like a
> three-legged dachshund.
>
> So I tried putting -O[0123] on and ploop, the program is just warming up
> and
> then it SEGV's.  It seems to be happening at the end of one function
> call
> (which appears to run fine) or at the very start of another.  Compiling
> with
> -g and running in gdb shows the point, which is just at the final } from
> the
> last function that works successfully.
>
> Ultimately I can reprogram the date stuff so I don't have to rotate the
> dates on the fly (which is the way I should have done it originally),
> but
> now I'm curious.
>
> How can I find out why -O[0123] fails?  Is there a strategy I can follow
> or doc I should read?  Is there a "simple" way of debugging my way out
> of
> this situation, or is there no alternative to inspecting the assembly?
>
> gcc version 2.9.something (not threaded).
>
> All help and clues appreciated.
>
> Many thanks,
>
> David Carter-Hitchin,
> GSD-Risk-IT, UBS Investment Bank
>

Re: C++ Optimization with g++

[David Carter-Hitchin]

Hi,

Trying to resolve my problems with "-Ox", a gentleman on this list
suggested that I use gprof to work out why my code was doing.
Unfortunately my ancient g++ (2.95.4) doesn't support "-gp" so I've
downloaded gcc33 and am running the testsuite.

I'm getting some failiures below.  gcc -Ox fails and badmalloc.C fails for
C++.  I am only intending to use the C++ compiler so I'd like to fix these
two.  (Presumably g++ relies on parts of gcc?)

Can anyone suggest anything? Is my libc too old? I ran gdb on the core
file produced by badmalloc.C:

Core was generated by `a.out'.
Program terminated with signal 6, Abort trap.
Reading symbols from /usr/lib/libstdc++.so.3...done.
Reading symbols from /usr/lib/libm.so.2...done.
Reading symbols from /usr/lib/libc.so.4...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0  0x280feba8 in kill () from /usr/lib/libc.so.4
(gdb) where
#0  0x280feba8 in kill () from /usr/lib/libc.so.4
#1  0x28140136 in abort () from /usr/lib/libc.so.4
#2  0x280a625f in __default_terminate () from /usr/lib/libstdc++.so.3
#3  0x280a3c35 in terminate () from /usr/lib/libstdc++.so.3
#4  0x280a3cdd in __eh_alloc () from /usr/lib/libstdc++.so.3
#5  0x80489cc in fn_throw () at
./work/gcc-3.3-20031201/gcc/testsuite/g++.old-deja/g++.eh/badalloc1.C:82
#6  0x80490be in main () at
./work/gcc-3.3-20031201/gcc/testsuite/g++.old-deja/g++.eh/badalloc1.C:103
#7  0x80487ce in _start ()

Thanks,
David

==========================================================================
Results of make -k test (sorry I didn't use test_summary - I think I
needed to fire that up before running the tests?).
==========================================================================

Script started on Sun Feb 22 00:19:05 2004
[501]->make -k check
cd /usr/ports/lang/gcc33/work/build; export RUNTESTFLAGS='--target_board ''unix{-pthread}'''; gmake -sk check
./test-demangle: 649 tests, 0 failures
Making check in include
Making check in libio
Making check in libmath
Making check in libsupc++
Making check in src
Making check in po
Making check in testsuite
Makefile:480: warning: overriding commands for target `check-am'
Makefile:396: warning: ignoring old commands for target `check-am'
Makefile:480: warning: overriding commands for target `check-am'
Makefile:396: warning: ignoring old commands for target `check-am'
WARNING: Couldn't find the global config file.
WARNING: Couldn't find tool init file
Test Run By root on Sun Feb 22 00:19:14 2004
Native configuration is i386-portbld-freebsd4.8

		=== libstdc++-v3 tests ===

Schedule of variations:
    unix/-pthread

Running target unix/-pthread
Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for target.
Using /usr/ports/lang/gcc33/work/gcc-3.3-20031201/libstdc++-v3/testsuite/config/default.exp as tool-and-target-specific interface file.
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/libstdc++-v3/testsuite/libstdc++-v3.dg/dg.exp ...

		=== libstdc++-v3 Summary ===

# of expected passes		430
# of expected failures		17
Makefile:480: warning: overriding commands for target `check-am'
Makefile:396: warning: ignoring old commands for target `check-am'
../../.././..//gcc-3.3-20031201/libf2c/libU77/u77-test.f: In program `MAIN__':
../../.././..//gcc-3.3-20031201/libf2c/libU77/u77-test.f:214: warning:
         call idate (i,j,k)
              ^
Intrinsic `IDATE', invoked at (^), known to be non-Y2K-compliant [info -f g77 M Y2KBAD]
../../.././..//gcc-3.3-20031201/libf2c/libU77/u77-test.f:223: warning:
         call date (ctim)
              ^
Intrinsic `DATE', invoked at (^), known to be non-Y2K-compliant [info -f g77 M Y2KBAD]
1 GNU libU77 test at: Sun Feb 22 00:32:15 2004

 Logical units 5 and 6 correspond (FNUM) to Unix i/o units   0,   1
 Command-line arguments:  0
 Arg  0 is: ./a.out
 and 6 is a tty device (ISATTY) named /dev/ttyp0
 Process id (GETPID):      16833
 User id (GETUID):          0
 Group id (GETGID):          0
 If you have the `id' program, the following call
 of SYSTEM should agree with the above:
  uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 25(smmsp), 31(guest)
 Login name (GETLOG): root
 Login name (GETENV of LOGNAME): root
 UMASK returns 18
 FDATE returns: Sun Feb 22 00:32:15 2004
 CALL FDATE returns: Sun Feb 22 00:32:15 2004
 LTIME returns:  15  32   0  22   1 104   0  52   0
 GMTIME returns:  15  32   0  22   1 104   0  52   0
 SYSTEM_CLOCK returns:  469518221 128 2147483647
 DATE_AND_TIME returns: 20040222 003215.102 +0000  2004 2 22 0 0 32 15 102
 Sleeping for 1 second (SLEEP) ...
 Elapsed total, user, system time (ETIME):      0.009     0.004     0.004
 Looping until clock ticks at least once...
 Differences in total, user, system time (DTIME):      0.000     0.000     0.000
 Elapsed total, user, system time (ETIME):      0.009     0.004     0.004
 (Clock-tick detected after  1 1K loops.)
 IDATE (date,month,year):  22 2 2004
 ... and the VXT version (month,date,year):  2 22 4
 DATE (dd-mmm-yy): 22-Feb-04
 ITIME (hour,minutes,seconds):  0 32 16
 TIME: 00:32:16
 SECNDS(0.0) returns:   1936.
 SECOND returns:   0.0090549998
 CALL SECOND returns:   0.00908900052
 Current directory is "/usr/ports/lang/gcc33/work/build/i386-portbld-freebsd4.8/libf2c/libU77"
 Host name is stoat.clara.net
 Creating file "foo" for testing...
   with stat array  226316 4278119 33206 1 0 0 17705451 2 1077409936 1077409936
 1077409936 8192 2
 The current error number is:   2 and the corresponding message is:
 No such file or directory
 This is sent to stderr prefixed by the program name
./a.out: No such file or directory
 MCLOCK returns  0
 MCLOCK8 returns  0
 CPU_TIME returns   0.0110550001
 You should see exit status 1
Making check in include
Making check in libltdl
Making check in testsuite
WARNING: Couldn't find the global config file.
Test Run By root on Sun Feb 22 00:32:28 2004
Native configuration is i386-portbld-freebsd4.8

		=== libjava tests ===

Schedule of variations:
    unix/-pthread

Running target unix/-pthread
Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for target.
Using /usr/ports/lang/gcc33/work/gcc-3.3-20031201/libjava/testsuite/config/default.exp as tool-and-target-specific interface file.
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/libjava/testsuite/libjava.compile/compile.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/libjava/testsuite/libjava.jacks/jacks.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/libjava/testsuite/libjava.jni/jni.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/libjava/testsuite/libjava.lang/lang.exp ...
FAIL: SyncGlobal -O execution - bytecode->native test
WARNING: program timed out.
FAIL: SyncTest execution - gij test
WARNING: program timed out.
FAIL: SyncTest execution - bytecode->native test
WARNING: program timed out.
FAIL: SyncTest execution - gij test
WARNING: program timed out.
FAIL: SyncTest -O execution - bytecode->native test
FAIL: Thread_Sleep -O output - bytecode->native test
FAIL: Throw_2 execution - source compiled test
FAIL: Throw_2 execution - gij test
FAIL: Throw_2 execution - bytecode->native test
FAIL: Throw_2 -O execution - source compiled test
FAIL: Throw_2 execution - gij test
FAIL: Throw_2 -O execution - bytecode->native test
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/libjava/testsuite/libjava.loader/loader.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/libjava/testsuite/libjava.mauve/mauve.exp ...

		=== libjava Summary ===

# of expected passes		2968
# of unexpected failures	12
# of expected failures		16
# of untested testcases		23
gmake[4]: *** [check-DEJAGNU] Error 1
gmake[3]: *** [check-am] Error 2
gmake[3]: Target `check' not remade because of errors.
Making check in gcj
Making check in include
gmake[2]: *** [check-recursive] Error 1
gmake[2]: Target `check' not remade because of errors.
gmake[1]: *** [check-target-libjava] Error 2
Making check in include
Completed 3 tests
Allocated 5694246 collectable objects
Allocated 306 uncollectable objects
Allocated 3750000 atomic objects
Allocated 33000 stubborn objects
Finalized 6606/6606 objects - finalization is probably ok
Total number of bytes allocated is 190207840
Final heap size is 9875456 bytes
Collector appears to work
Completed 155 collections
PASS: gctest
==================
All 1 tests passed
==================
WARNING: Couldn't find the global config file.
Test Run By root on Sun Feb 22 02:54:11 2004
Native configuration is i386-portbld-freebsd4.8

		=== gcc tests ===

Schedule of variations:
    unix/-pthread

Running target unix/-pthread
Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for target.
Using /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/config/default.exp as tool-and-target-specific interface file.
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.c-torture/compile/compile.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.c-torture/execute/execute.exp ...
FAIL: gcc.c-torture/execute/conversion.c execution,  -O0
FAIL: gcc.c-torture/execute/conversion.c execution,  -O1
FAIL: gcc.c-torture/execute/conversion.c execution,  -O2
FAIL: gcc.c-torture/execute/conversion.c execution,  -Os
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.c-torture/execute/ieee/ieee.exp ...
FAIL: gcc.c-torture/execute/ieee/rbug.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/ieee/rbug.c execution,  -O3 -g
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.c-torture/execute/ieee/ieee.exp ...
FAIL: gcc.c-torture/execute/ieee/rbug.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/ieee/rbug.c execution,  -O3 -g
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.c-torture/unsorted/unsorted.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.dg/cpp/cpp.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.dg/cpp/trad/trad.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.dg/cpp/trad/trad.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.dg/debug/debug.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.dg/dg.exp ...
FAIL: gcc.dg/duff-2.c (test for excess errors)
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.dg/format/format.exp ...
FAIL: gcc.dg/format/attr-3.c non-id format (test for errors, line 37)
FAIL: gcc.dg/format/attr-3.c (test for excess errors)
FAIL: gcc.dg/format/attr-3.c non-id format (test for errors, line 37)
FAIL: gcc.dg/format/attr-3.c (test for excess errors)
FAIL: gcc.dg/format/c99-scanf-3.c vfscanf (test for warnings, line 21)
FAIL: gcc.dg/format/c99-scanf-3.c vfscanf (test for warnings, line 21)
FAIL: gcc.dg/format/ext-6.c vfscanf (test for warnings, line 42)
FAIL: gcc.dg/format/ext-6.c vfscanf (test for warnings, line 42)
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.dg/noncompile/noncompile.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.dg/special/ecos.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.dg/special/mips-abi.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.dg/special/special.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.dg/tls/tls.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.dg/weak/weak.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.misc-tests/acker1.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.misc-tests/arm-isr.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.misc-tests/bprob.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.misc-tests/dg-test.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.misc-tests/dhry.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.misc-tests/gcov.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.misc-tests/i386-prefetch.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.misc-tests/linkage.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.misc-tests/matrix1.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.misc-tests/mg.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.misc-tests/sieve.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/gcc.misc-tests/sort2.exp ...

		=== gcc Summary ===

# of expected passes		21619
# of unexpected failures	17
# of expected failures		68
# of unsupported tests		91
/usr/ports/lang/gcc33/work/build/gcc/xgcc version 3.3.3 20031201 (prerelease) [FreeBSD]


WARNING: Couldn't find the global config file.
Test Run By root on Sun Feb 22 03:37:43 2004
Native configuration is i386-portbld-freebsd4.8

		=== g++ tests ===

Schedule of variations:
    unix/-pthread

Running target unix/-pthread
Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for target.
Using /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/config/default.exp as tool-and-target-specific interface file.
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/g++.dg/bprob/bprob.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/g++.dg/compat/compat.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/g++.dg/debug/debug.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/g++.dg/dg.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/g++.dg/gcov/gcov.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/g++.dg/special/ecos.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/g++.dg/tls/tls.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/g++.old-deja/old-deja.exp ...
FAIL: g++.eh/badalloc1.C  Execution test

		=== g++ Summary ===

# of expected passes		8145
# of unexpected failures	1
# of expected failures		95
# of untested testcases		12
# of unsupported tests		14
/usr/ports/lang/gcc33/work/build/gcc/testsuite/../g++ version 3.3.3 20031201 (prerelease) [FreeBSD]


WARNING: Couldn't find the global config file.
Test Run By root on Sun Feb 22 03:56:07 2004
Native configuration is i386-portbld-freebsd4.8

		=== g77 tests ===

Schedule of variations:
    unix/-pthread

Running target unix/-pthread
Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for target.
Using /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/config/default.exp as tool-and-target-specific interface file.
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/g77.dg/bprob/bprob.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/g77.dg/dg.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/g77.dg/gcov/gcov.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/g77.f-torture/compile/compile.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/g77.f-torture/execute/execute.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/g77.f-torture/noncompile/noncompile.exp ...

		=== g77 Summary ===

# of expected passes		1686
# of unsupported tests		8
/usr/ports/lang/gcc33/work/build/gcc/testsuite/../g77 version 3.3.3 20031201 (prerelease) [FreeBSD]


WARNING: Couldn't find the global config file.
Test Run By root on Sun Feb 22 04:00:33 2004
Native configuration is i386-portbld-freebsd4.8

		=== objc tests ===

Schedule of variations:
    unix/-pthread

Running target unix/-pthread
Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for target.
Using /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/config/default.exp as tool-and-target-specific interface file.
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/objc/compile/compile.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/objc/execute/execute.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/objc.dg/dg.exp ...
Running /usr/ports/lang/gcc33/work/gcc-3.3-20031201/gcc/testsuite/objc.dg/special/special.exp ...

		=== objc Summary ===

# of expected passes		1153
/usr/ports/lang/gcc33/work/build/gcc/xgcc version 3.3.3 20031201 (prerelease) [FreeBSD]


gmake[1]: Target `do-check' not remade because of errors.
gmake: *** [check] Error 2
*** Error code 2 (continuing)


Script done on Sun Feb 22 09:11:53 2004

Re: C++ Optimization with g++

[law]

In message <363801FFD7B74240A329CEC3F7FE4CC40215DA27@ntxboimbx07.micron.com>, l
rtaylor@micron.com writes:
 >Hi David,
 >
 >UBS?  Is that the one in Geneva?
 >
 >Anyway, if you compiled with -g and you don't get any more info than
 >that in GDB, I'm not sure what to tell you.  That's what I'd expect if
 >you stripped the binary, but not just after a debug build...  Are you
 >starting GDB like this: gdb /path/to/app core?  Are you running GDB
 >using the installed application, or just a debug version in your build
 >directory?  If using an installed version, is it getting stripped during
 >the install process?  If so, you might try disabling the stripping so
 >that you don't lose all of your symbol information.  
 >
 >Otherwise, I think I've used up my usefulness.  :-)
To me it looks like somehow he jumped to location zero.  When I see that
I usually use x/x $sp to get some data off the stack in the hopes that
I can find return addresses buried in the stack which can point me
towards the code which jumped or called to 0.

jeff

RE: C++ Optimization with g++

[lrtaylor]

Hi David,

UBS?  Is that the one in Geneva?

Anyway, if you compiled with -g and you don't get any more info than
that in GDB, I'm not sure what to tell you.  That's what I'd expect if
you stripped the binary, but not just after a debug build...  Are you
starting GDB like this: gdb /path/to/app core?  Are you running GDB
using the installed application, or just a debug version in your build
directory?  If using an installed version, is it getting stripped during
the install process?  If so, you might try disabling the stripping so
that you don't lose all of your symbol information.  

Otherwise, I think I've used up my usefulness.  :-)

Good luck,
Lyle

-----Original Message-----
From: David.Carter-Hitchin [mailto:carterda@ubs.com] 
Sent: Friday, February 20, 2004 11:05 AM
To: lrtaylor
Cc: gcc-help@gcc.gnu.org
Subject: RE: C++ Optimization with g++

Hi Lyle,

Thanks for the interest you've taken in this little problem.

I have tried looking at the core file with gdb, but I didn't get
anything
meaningful from it.  I typed "where" and merely got something like this:

# 00000000? at () ??

(That's from memory, so it might be not 100% correct - but it's faily
close).  That was after compilining with -g (I also tried -g3).

Apart from that I don't really know what else to do with a core file.
If
you've got any good "magic commands" that would be ace if you could
share
them with me.

Some other helpful folk, have offered reams of advice concerning my
programming style (or lack thereof), so I'll try their suggestions and
post
back to this thread when I solve the problem.

Many thanks,

David Carter-Hitchin,
GSD-Risk-IT, UBS Investment Bank

On Thu, 19 Feb 2004 lrtaylor@micron.com wrote:

> Have you tried looking at a stack trace?  If your program is SEGV'ing,
> it should be producing a core file (I guess unless you're on Windows).
> You can inspect that core file using GDB, including the full stack
> (including variable values, etc.) at the time of the crash.  That's
> usually the first place I look when a program crashes.
>
> Good luck,
> Lyle
>
> -----Original Message-----
> From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org]
On
> Behalf Of David.Carter-Hitchin
> Sent: Thursday, February 19, 2004 7:13 AM
> To: gcc-help@gcc.gnu.org
> Subject: C++ Optimization with g++
>
> Hi,
>
> I haven't done a great deal of optimization, so apologies in advance
for
> any
> dumb or mis-directed questions.
>
> I've got this nice little ~5,000 line c++ program at home which plots
> the
> positions of planets and the Yale Bright Star Catalogue.
>
> So far so good.
>
> Scrolling an zooming are fine, but when I swtich the option on to
> display
> dates (which involves rotating the bitmaps for the textstrings through
> 90
> degrees) it runs "like a dog" and I'm not talking greyhound, more like
a
> three-legged dachshund.
>
> So I tried putting -O[0123] on and ploop, the program is just warming
up
> and
> then it SEGV's.  It seems to be happening at the end of one function
> call
> (which appears to run fine) or at the very start of another.
Compiling
> with
> -g and running in gdb shows the point, which is just at the final }
from
> the
> last function that works successfully.
>
> Ultimately I can reprogram the date stuff so I don't have to rotate
the
> dates on the fly (which is the way I should have done it originally),
> but
> now I'm curious.
>
> How can I find out why -O[0123] fails?  Is there a strategy I can
follow
> or doc I should read?  Is there a "simple" way of debugging my way out
> of
> this situation, or is there no alternative to inspecting the assembly?
>
> gcc version 2.9.something (not threaded).
>
> All help and clues appreciated.
>
> Many thanks,
>
> David Carter-Hitchin,
> GSD-Risk-IT, UBS Investment Bank
>

Re: C++ Optimization with g++

[Ken Foskey]

On Fri, 2004-02-20 at 01:12, David.Carter-Hitchin wrote:

> How can I find out why -O[0123] fails?  Is there a strategy I can follow
> or doc I should read?  Is there a "simple" way of debugging my way out of
> this situation, or is there no alternative to inspecting the assembly?

Profiling sounds like what you need.  Look up the -gp option which
switches the profile on and then gprof, there is also a kde program to
support this.

If you are on Intel Linux you might want to look up valgrind to trace
whether there are any memory problems.

-- 
Thanks
KenF
OpenOffice.org developer

C++ Optimization with g++

[David.Carter-Hitchin]

Hi,

I haven't done a great deal of optimization, so apologies in advance for any
dumb or mis-directed questions.

I've got this nice little ~5,000 line c++ program at home which plots the
positions of planets and the Yale Bright Star Catalogue.

So far so good.

Scrolling an zooming are fine, but when I swtich the option on to display
dates (which involves rotating the bitmaps for the textstrings through 90
degrees) it runs "like a dog" and I'm not talking greyhound, more like a
three-legged dachshund.

So I tried putting -O[0123] on and ploop, the program is just warming up and
then it SEGV's.  It seems to be happening at the end of one function call
(which appears to run fine) or at the very start of another.  Compiling with
-g and running in gdb shows the point, which is just at the final } from the
last function that works successfully.

Ultimately I can reprogram the date stuff so I don't have to rotate the
dates on the fly (which is the way I should have done it originally), but
now I'm curious.

How can I find out why -O[0123] fails?  Is there a strategy I can follow
or doc I should read?  Is there a "simple" way of debugging my way out of
this situation, or is there no alternative to inspecting the assembly?

gcc version 2.9.something (not threaded).

All help and clues appreciated.

Many thanks,

David Carter-Hitchin,
GSD-Risk-IT, UBS Investment Bank