lz4demo silently failing when built with Oracle Solaris Studio on sparc Solaris

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Compile with 
cc -xc99 -fast -I. -m32 lz4.c lz4hc.c bench.c lz4demo.c -o lz4demo.exe 
-xmemalign=1i -erroff=E_WHITE_SPACE_IN_DIRECTIVE
2. run ./lz4demo.exe ./lz4demo.exe target && ./lz4demo.exe -d target back && 
cmp ./lz4demo.exe back

What is the expected output? What do you see instead?
No errors from cmp.
Instead:
./lz4demo.exe back differ: char 44, line 1

What version of the product are you using? On what operating system?
Solaris 10 sparc. cc: Sun C 5.12 SunOS_sparc Spica 2011/07/21

Please provide any additional information below.

This can be fixed by moving the #include directives to the top.
Solaris Studio needs to include some files  before it can have sensible values 
for BIG_ENDIAN or BYTE_ORDER.

I know I have reported this before and not followed up.
This time I promise to follow up and do all tests you ask of me.

Original issue reported on code.google.com by thwill...@gmail.com on 26 Nov 2012 at 2:52

[GoogleCodeExporter]

Hi
Is the issue located into lz4.c ?

Original comment by yann.col...@gmail.com on 29 Nov 2012 at 7:56

[GoogleCodeExporter]

Yes it is in lz4.c.
And in lz4hc.c. ( high compression fails silently also).

In both cases it helps to just move all the #includes before the cpu feature 
detection.

Original comment by thwill...@gmail.com on 30 Nov 2012 at 10:22

[GoogleCodeExporter]

I'll handle it.

Original comment by yann.col...@gmail.com on 30 Nov 2012 at 1:58

• Changed state: Accepted

[GoogleCodeExporter]

You could also fix it by adding a 
|| defined(__sparc)
to your huge #if

Original comment by thwill...@gmail.com on 4 Dec 2012 at 4:20

[GoogleCodeExporter]

Good point. I'll look into it.

Original comment by yann.col...@gmail.com on 4 Dec 2012 at 5:55

[GoogleCodeExporter]

Hi

I'm back on LZ4, after spending some time of xxHash.
One nice outcome is that it resulted in a much improved endian detection macro, 
which is proposed in the release candidate (attached file).
I expect it to solve your reported issue on sun solaris + sparc, although some 
actual fact checking is welcomed :)

I've also moved the #include statement in front of the macro, as you suggested. 
This however will have to be checked, since there may be some situations which 
actually need to setup some #define before loading the #include. 
One such situation happens in bench.c for example, and this is why i initially 
intended to keep "compiler options" before #include statement.

Original comment by yann.col...@gmail.com on 18 Dec 2012 at 5:56

Attachments:

• lz4_rc86.zip

[GoogleCodeExporter]

Hopefully corrected into r86.

Original comment by yann.col...@gmail.com on 21 Dec 2012 at 4:50

• Changed state: Fixed