Opened 14 years ago

Closed 13 years ago

#8 closed defect (wontfix)

OSI unitTest failure: -fomit-frame-pointer fails, g++ 3.3.1, SuSE 2.4.21-303-smp4G

Reported by: lou Owned by: somebody
Priority: minor Component: component1
Version: Keywords: OSI unitTest failure
Cc:

Description

The OSI unitTest dumps core on throws when built with -fomit-frame-pointer. Build environment is g++ 3.3.1, SuSE Linux 2.4.21-303-smpG4. When all components are rebuilt with identical options except for -fomit-frame-pointer, all is copacetic. Seems likely this is a problem with GCC. Testing is annoying --- OsiSolverInterfaceTest.cpp requires 15 minutes to compile in this environment.

Change History (7)

comment:1 Changed 14 years ago by lou

A related problem occurs with the clp unitTest. Attempting to compile at -O3 (with or without omit-frame-pointer), the compiler bails out with `out of memory'. Best fix is probably an upgrade to GCC 4.X.

comment:2 Changed 14 years ago by andreasw

Has this issue been fixed? Can we close the ticket?

comment:3 Changed 14 years ago by lou

Not just yet, I think. Just did a build at home last evening (Fedora Core 4, GCC 4.0.1) and I'm getting a CoinError throw with --omit-frame-pointer that vanishes when I do a build without it. But I should run a few more tests to narrow down the problem.

comment:4 Changed 14 years ago by lou

After a bit more testing, it looks like any throw will trigger this bug. On the other hand, the bug is absent in GCC 4.1.1 on my local SuSE box. Will try to work up an autoconf macro to test whether --omit-frame-pointer is safe.

comment:5 Changed 13 years ago by andreasw

Is this still an issue? Can we close the ticket?

comment:6 Changed 13 years ago by lou

I added an item in the 'Current Issues' page with suggested workarounds. Trouble is, people will likely see this as an OSI unit test error or some other execution error. All environments available to me are now upgraded to a GCC version that handles --omit-frame-pointer without error, so it'll be a real pain to develop a macro to test for this. I'd say 'close the ticket,' recognising we may yet have to revisit the issue.

comment:7 Changed 13 years ago by andreasw

  • Resolution set to wontfix
  • Status changed from new to closed

Great - I'm closing the ticket then. Thanks for adding this to current issues.

Note: See TracTickets for help on using tickets.