[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gsl] SV decomp failure
From: |
Steve Brosnan |
Subject: |
Re: [Bug-gsl] SV decomp failure |
Date: |
Sun, 23 Sep 2012 19:04:09 -0700 |
Hi Rhys,
Well, I took a stab at it. But the results are confusing.
First, some info I've learned since my last message:
(1) The compiler symbolically linked by 'gcc' on the Mac is 'llvm-gcc-4.2', not
gnu gcc. The llvm version is supposed to be interoperable, but that may not be
fully true, particularly where optimization is concerned.
(2) On Lion (OS X 10.7.4) the default (preferred?) compiler in Xcode is the
'Apple LLVM Compiler 4.0'. I think this is, or is related to, the Clang
compiler, and is the direction that Apple is headed in.
(3) Using the LLVM Compiler 4.0, with -O2, the SV-decomp tests succeed.
(4) As reported before, the tests also succeed with the llvm-gcc-4.2 compiler
with -Os optimization selected. HOWEVER, my prior statement that the SV-decomp
tests fail if I 'export CFLAGS="-Os -g"' before the gsl configure/make/make
check sequence using the gsl build mechanism is WRONG. -Os SUCCEEDS. (I
discovered my error, probably a dumb typo in the prior test, after doing the
tests described in the following paragraph.)
That said, I tried to do as you requested and tabulate the SV-decomp test
results as the optimization switches are added within Xcode. The compiler was
llvm-gcc-4.2 in all cases, with -O1 selected. Under the 'Other C flags' heading
in Xcode, I added the following switches one by one (the gcc man page says that
they are what separate -O1 from -O2):
-fthread-jumps -fcrossjumping -foptimize-sibling-calls
-fcse-follow-jumps -fcse-skip-blocks -fgcse -fgcse-lm
-fexpensive-optimizations -frerun-cse-after-loop -fcaller-saves
-fpeephole2 -fschedule-insns -fschedule-insns2
-fsched-interblock -fsched-spec -fregmove -fstrict-aliasing
-fstrict-overflow
-fdelete-null-pointer-checks -freorder-blocks -freorder-functions
-falign-functions -falign-jumps -falign-loops
-falign-labels -ftree-vrp -ftree-pre
However, the tests never failed. -O1 succeeded. -O2 failed. But adding all the
switches that separate -O1 and -O2 also succeeded! I'm baffled. If anyone can
educate me, please do.
As far as options of how to proceed to a solution, here are my, as a gsl
noobie, suggestions:
(1) Accept -O1 as the baseline and modify the makefiles accordingly.
(2) Modify 'configure' to use the -Os optimization for Macs running OS X 10.7.4
and later. Is this hard?
But in the meantime, Mac people can use the 'export CFLAGS="-Os -g"' trick.
Hope this helps. If you have other suggestions, I will do the best I can.
Regards,
Steve
On Sep 23, 2012, at 12:49 PM, Rhys Ulerich wrote:
> Hi Steve,
>
> Any chance you'd be willing to dig into the gcc optimization delta
> between -O1 and -O2 to determine exactly which optimization causes the
> SVD failure on recent OS X systems? You'd have to dig up a
> version-specific set of GCC documentation, but the details should look
> something like http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html.
>
> It would be nice to either a) report the problem upstream and/or b)
> disable this specific optimization at the smallest possible scope when
> detecting OS X along with issuing a compiler warning.
>
> - Rhys
- Re: [Bug-gsl] SV decomp failure, (continued)
- Re: [Bug-gsl] SV decomp failure, Rhys Ulerich, 2012/09/17
- Re: [Bug-gsl] SV decomp failure, Peter Lelievre, 2012/09/18
- Re: [Bug-gsl] SV decomp failure, Rhys Ulerich, 2012/09/18
- Re: [Bug-gsl] SV decomp failure, Peter Lelievre, 2012/09/18
- Re: [Bug-gsl] SV decomp failure, Rhys Ulerich, 2012/09/18
- Re: [Bug-gsl] SV decomp failure, Peter Lelievre, 2012/09/18
- Re: [Bug-gsl] SV decomp failure, Rhys Ulerich, 2012/09/18
- Re: [Bug-gsl] SV decomp failure, Peter Lelievre, 2012/09/18
Re: [Bug-gsl] SV decomp failure, Steve Brosnan, 2012/09/19