Thread (39 messages) 39 messages, 13 authors, 2026-03-31

Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO

From: "Arnd Bergmann" <arnd@arndb.de>
Date: 2026-03-26 21:33:54
Also in: linux-kbuild, linux-mm, linux-um, lkml, llvm, rust-for-linux

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:
quoted
On 3/26/26 2:47 PM, Miguel Ojeda wrote:
quoted
On Thu, Mar 26, 2026 at 11:10 AM Alice Ryhl [off-list ref] 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help