[Mesa-dev] [PATCH] mesa: Fix test for big-endian architecture in compiler.h

[Jochen Rollwagen]

Am 16.02.2016 um 12:40 schrieb Jonathan Gray:
> On Tue, Feb 16, 2016 at 08:13:45PM +1100, Jonathan Gray wrote:
>> On Tue, Feb 16, 2016 at 10:37:47AM +0200, Oded Gabbay wrote:
>>> On Tue, Feb 16, 2016 at 9:23 AM, Jonathan Gray <jsg at jsg.id.au> wrote:
>>>> On Fri, Feb 12, 2016 at 10:01:21AM +0100, Jochen Rollwagen wrote:
>>>>> Hi,
>>>>>
>>>>> i think i found & fixed a bug in mesa concerning tests for big-endian
>>>>> machines. The defines tested don't exist or are wrongly defined so the test
>>>>> (probably) never fires. The gcc defines on my machine concerning big-endian
>>>>> are
>>>>>
>>>>> jochen at mac-mini:~/sources/mesa$ gcc -dM -E - < /dev/null | grep BIG
>>>>> #define __BIGGEST_ALIGNMENT__ 16
>>>>> #define __BIG_ENDIAN__ 1
>>>>> #define __FLOAT_WORD_ORDER__ __ORDER_BIG_ENDIAN__
>>>>> #define _BIG_ENDIAN 1
>>>>> #define __ORDER_BIG_ENDIAN__ 4321
>>>>> #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__
>>>>>
>>>>> The tested values in current mesa are quite different :-)
>>>>>
>>>>> The following patch fixes this.
>>>> I think you have this backwards.
>>>>
>>>> On OpenBSD/sparc64
>>>> $ gcc -dM -E - < /dev/null | grep BIG
>>>> $
>>>> $ sysctl hw.byteorder
>>>> hw.byteorder=4321
>>>>
>>>> endian.h defines BYTE_ORDER and it should be included to test it.
>>>>
>>>> I was under the impression the headers on linux had similiar defines.
>>>>
>>>> Look at how src/gallium/include/pipe/p_config.h does it.
>>>> _______________________________________________
>>>> mesa-dev mailing list
>>>> mesa-dev at lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>> After looking at it last night, I also think a better solution will be
>>> to just include <endian.h> in compiler.h file
>>>
>>> Oded
>> Right, I suspect it will end up looking something like the following
>> untested diff.
>>
>> It would be nice if this didn't have to be duplicated in two places
>> in Mesa though.
> At least on OpenBSD/amd64 the only place where endian.h is not picked up
> indirectly when in matters seems to be shaderimage.c, otherwise
> BYTE_ORDER is defined and compiler.h somehow included.
>
> CPU_TO_LE32 isn't used

Well, actually it is, via compiler.h:

  #define LE32_TO_CPU( x ) CPU_TO_LE32( x )


Actually i only stumbled across all of this by chance, i would naively 
have expected to find info’s about the CPU mesa is running on in a place 
so exotic as, wait a minute, now let me see, how about……. 
  Mesa/main/cpuinfo.h !

Yeah I know, completely absurd. Well, at least not as absurd as 
„compiler.h“ (what compiler, anyway ?). Or p_config.h.

IMHO there are three alternatives (well, actually four) on how to proceed:

1.Trying to fix compiler.h

2.Taking the Gallium code and putting it in a sane place (like for 
example cpuinfo.h), nuking compiler.h and thereby eliminating the 
redundant code between dri and gallium driver

3.With people doing crazy things like running little-endian kernels on 
pp64 replacing the #ifdef compile-time-checks in the radeon driver by 
runtime checks

4.Doing nothing

I would opt personally for number 2.

>
>