gmp-5.0.5 1 of 59 tests failed

[Dennis Clarke]

> Dennis Clarke <dclarke at blastwave.org> writes:
> 
>   Strictly speaking .. yes, there is. 
>   
> It looks to me as if the pointer causing the crash is 3.  It is not only
> poorly aligned, but almost surely not close to an allocatable memory
> area.
> 
> Please isolate the problem in the compiler or GMP.

I started to do that. Then I saw that once again I had forgotten that one can not, traditionally, compile gmp with the Sun Studio tools and you and I agree on this and have exchanged many many emails over the years on this very topic. No argument there. 

However I accidentally, yes really, fell into building the latest gmp with Oracle Studio 12.3 and the build went fine. It was only one test that failed, thus far. The failure provided a core file and the issue was a SIGBUS.  

My first thought is that this is not the compiler. Since there was no compiler fault seen. Heuristics would suggest that I am able to build Apache 2.4.3 with this compiler as well as all the dependecies and never a problem like this was seen. Only in GMP. does this mean the issue is in GMP or the compiler?

I don't know. 

However I will take a look at the test code and see what I can fine there. Perhaps the Makefile for that specific test fails to pick up the CFLAGS that dictakes memalignment at 8s. The option to the compiler is -xmemalign=8s which means : 

TABLE B–28 The -xmemalign Alignment and Behavior Flags

parameter one 
1 Assume at most 1 byte alignment   
2 Assume at most 2 byte alignment. 
4 Assume at most 4 byte alignment.  
8 Assume at most 8 byte alignment.
16 Assume at most 16 byte alignment

parameter two 
 i Interpret access and continue execution.
 s Raise signal SIGBUS.
 f For variants of -xarch=v9 only Raise signal SIGBUS for alignments less or equal to 4,otherwise interpret access and continue execution. For all other -xarch values, the f flag is equivalent to i.

You must specify -xmemalign whenever you want to link to an object file that was compiled
with the value of b set to either i or f. For a complete list of all compiler options that must be
specified at both compile time and at link time, see Table A–2.
For memory accesses where the alignment is determinable at compile time, the compiler
generates the appropriate load/store instruction sequence for that alignment of data.
For memory accesses where the alignment cannot be determined at compile time, the compiler
must assume an alignment to generate the needed load/store sequence.
The -xmemalign option allows you to specify the maximum memory alignment of data to be
assumed by the compiler in these indeterminable situations. It also specifies the error behavior
to be followed at run time when a misaligned memory access does take place.
The following default values only apply when no -xmemalign option is present:
■ -xmemalgin=8i for all v8 architectures.
■ -xmemalign=8s for all v9 architectures.
Here is the default when -xmemalign option is present but no value is given:
■ -xmemalign=1i for all -xarch values.
The following table shows how you can use -xmemalign to handle different alignment
situations.

TABLE B–29 Examples of -xmemalign
-xmemalign=1s There are many misaligned accesses so trap handling is too slow

-xmemalign=8i There are occasional, intentional, misaligned accesses in code
that is otherwise correct.

-xmemalign=8s There should be no misaligned accesses in the program.

-xmemalign=2s You want to check for possible odd-byte accesses.

-xmemalign=2i You want to check for possible odd-byte access and you want
the program to work.

My thoughts and common proactice according to the Daryl Gove books is -xmemalign=8s and I have built every lib up to now using this as an option. When I say "every lib" I mean a great many. 

Strangely I have no idea how GCC is handling this and I don't see anything in the tests output that tells me. So this will take time to look into. 

Dennis