Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
"Arnd Bergmann" <[email protected]>
| Newsgroups | gmane.linux.kernel.rust,gmane.linux.ports.arm.kernel,gmane.linux.kbuild.devel,gmane.linux.kernel,gmane.linux.kernel.mm,gmane.linux.uml.devel |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Mar 26, 2026, at 16:18, Russell King (Oracle) wrote: > On Thu, Mar 26, 2026 at 03:31:26PM +0100, Christian Schrefl wrote: >> On 3/26/26 2:47 PM, Miguel Ojeda wrote: >> > On Thu, Mar 26, 2026 at 11:10 AM Alice Ryhl <[email protected]> wrote: > > I'm not sure if this is still true, but I believe it used to be the case > that the -linux-gnueabi target has one behaviour for enums (fixed size) > whereas -none-eabi, the size of the type depends on the range of values > included in the enum. I checked Debian's arm-none-eabi-gcc, which indeed still has this behavior: $ echo 'enum { A, B } x = sizeof(x);' | arm-none-eabi-gcc -xc - -O2 -o- -S | grep -A1 x: x: .byte 1 and I see the same thing for the hexagon target in clang, but none of the other targets that Linux runs on. In particular, clang always behaves like linux-gnueabi even when targeting plain eabi. $ echo 'enum { A, B } x = sizeof(x);' | clang --target=arm-none-eabi -xc - -O2 -o- -S | grep -A1 x: x: .long 4 I noticed a similar issue with m68k-linux, which has a bitfield alignment different from anything else on gcc, but uses the normal behavior on clang. Arnd