On 16.07.2018 11:07, Kamil Rytarowski wrote: > On 16.07.2018 10:50, Kamil Rytarowski wrote: >> 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. >> > > I was asked to provide some links to gcc bugzilla: > > https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=__int128_t > https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=__uint128_t > > My reason is unportable construct of reg.h, no utility functions for > 128bits and alien style core files with 128bit containers for registers. >
This has been rejected by Martin.
signature.asc
Description: OpenPGP digital signature
