On 16.07.2018 00:00, Kamil Rytarowski wrote:
> On 15.07.2018 20:08, Christos Zoulas wrote:
>> Hi,
>>
>> Gcc is now working on aarch64 but the kernel does not compile because of
>> some idiomatic clang code that is not supported by gcc (at least gcc-6)
>>
>> To define constants, it uses:
>>
>> static const uintmax_t
>> FOO = __BIT(9),
>> BAR = FOO;
>>
>> While this is nice, specially for the debugger, it produces an error
>> in gcc. While fixing these is easy, gcc also complains about using the
>> constants as switch labels. Thus it is better to just nukem all and
>> rewrite them as:
>>
>> #define FOO __BIT(9)
>> #define BAR FOO
>>
>> Should I go ahead and do it, or there is a smarter solution?
>>
>> christos
>>
> 
> I used to have problems to build rumpkernel aarch64 on Linux with GCC
> (some years ago) due to usage __uint128_t in reg.h.
> 
> Can we drop it? The __uint128_t type is not used anywhere else in
> aarch64 subdirs.
> 
> It's used in assembly in FPREG_Q0-FPREQ_Q31 in cpuswitch.S. The same
> optimization can be done without the usage of __uint128_t, probably just
> need for proper alignment of fp_reg (15).

16*

> 
> There is also some mysterious fallout that General Purpose Registers in
> core files are shipped with 128bit containers. It's not compatible with
> LLDB and requires needless generic work for no purpose.
> 
> I can try to prepare a patch blindly and share with aarch64 owners.
> 

Looking deeper, there are various reports regarding aarch64 128-bit
broken support.

"Be careful of GCC's __uint128_t. It caused us problems on a number of
platforms, like ARM64, ARMEL and S/390. We had to give up using it
because it was so buggy. For example, GCC calculated the result of u =
93 - 0 - 0 - 0 (using the 128-bit types) as 18446744073709551615 on ARM64"

https://stackoverflow.com/questions/11656241/how-to-print-uint128-t-number-using-gcc

There are no utility features for such numbers such as PRIu128, no
support in printf(3), snprintf(3) etc.

I will prepare a patch for removal of this from public machine headers.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to