bug-gsl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gsl] Test result for test release of gel 1.16


From: Steve Brosnan
Subject: Re: [Bug-gsl] Test result for test release of gel 1.16
Date: Tue, 4 Jun 2013 14:12:51 -0700

Hi Patrick,

Thanks for your work to make the changes you mentioned.

Yes, the clang compiler passes all tests, including SV-decomp-mod, for MacOS 
10.7 and 10.8. As you note, there was no problem using the default gcc compiler 
for MacOS 10.6. I think that at some point Apple deviated from using the gcc 
compiler and began using a synthesized version based on LLVM. This compiler has 
some optimization issues: SV-decomp-mod succeeds for -O0, -O1, & -Os, but fails 
for -O2. I once tried to sequentially add optimization related compiler 
switches from the -O1 to -O2 states to see if a switch was the problem, but 
failed to identify the problem.

This issue is an old one. Here is a list of Bug-gsl Digests (during Rhys's term 
as admin) that deal with it:
Bug-gsl Digest, Vol 116, Issue 11
Bug-gsl Digest, Vol 117, Issue 6
Bug-gsl Digest, Vol 117, Issue 11
Bug-gsl Digest, Vol 117, Issue 13
Bug-gsl Digest, Vol 117, Issue 14
Bug-gsl Digest, Vol 118, Issue 2

Hope this helps. I will try to do more if asked. But low level debugging of 
optimized code is beyond my skill level.

Steve

On Jun 4, 2013, at 1:07 PM, address@hidden wrote:

> Message: 1
> Date: Tue, 04 Jun 2013 12:41:11 -0600
> From: Patrick Alken <address@hidden>
> To: address@hidden
> Subject: Re: [Bug-gsl] Test result for test release of gel 1.16
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=windows-1252; format=flowed
> 
> Hi Steve, thanks for the reports - I've fixed the issues (hopefully) 
> with rng/test.c, specfunc/ellint.c and specfunc/coupling.c that you 
> reported.
> 
> Just for clarification, you're saying that the 'clang' compiler passes 
> the SV_decomp_mod, and the default cc does not? I can certainly add a 
> note about this. As an aside a few days ago I ran make check on Mac OS 
> 10.6, using a port of gcc, and everything went ok.
> 
> Patrick
> 
> On 06/02/2013 11:58 AM, Steve Brosnan wrote:
>> Test results on a mid-2011 iMac (quad-core i5) running MacOS 10.8.3 follow?
>> 
>> As exists for gsl-1.15, (./configure; make; make check) shows multiple 
>> errors for SV_decomp_mod. This has been investigated previously in this 
>> forum and was found to be related to optimization problems with the default 
>> cc compiler on Apple products. Apple's preferred compiler is now 'clang'.
>> 
>> Repeating the build (after make clean) using (./configure CC=clang; make; 
>> make check) results in the following:
>> Warnings issued in 'make':
>> ...
>> coupling.c:167:17: warning: implicit declaration of function 
>> 'gsl_sf_exp_err_e' is invalid in C99
>>       [-Wimplicit-function-declaration]
>>       status += gsl_sf_exp_err_e(bc1.val + bc2.val + bc3.val + lnorm.val,
>> ...
>> ellint.c:124:9: warning: type specifier missing, defaults to 'int' 
>> [-Wimplicit-int]
>>   const nmax = 10000;
>> ...
>> Warning issued in 'make check':
>> Making check in rng
>> make  test
>> clang -DHAVE_CONFIG_H -I. -I.. -I..    -g -O2 -MT test.o -MD -MP -MF 
>> .deps/test.Tpo -c -o test.o test.c
>> test.c:639:16: warning: implicit declaration of function 'rng_sanity_test' 
>> is invalid in C99 [-Wimplicit-function-declaration]
>>       status = rng_sanity_test (r);
>>                ^
>> 1 warning generated.
>> ...
>> 
>> Apparently clang is more picky than the standard compiler. I do not recall 
>> any such warnings in gsl 1.15, but I could be mistaken. I saw your comment 
>> about waiting to fix issues with strict compiler flags until another 
>> release. I understand your caution.
>> 
>> Since the root cause for the optimization issue has not been identified, 
>> there was previously some discussion about adding a note to the INSTALL file 
>> recommending that Mac users specify the 'clang' compiler. I did not see any 
>> such comment in the existing INSTALL file. I think it would be a good idea.
>> 
>> Steve



reply via email to

[Prev in Thread] Current Thread [Next in Thread]