[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] bitfield handling

From: Michael Matz
Subject: Re: [Tinycc-devel] bitfield handling
Date: Wed, 3 May 2017 01:56:10 +0200 (CEST)
User-agent: Alpine 2.20 (LSU 67 2015-01-07)


On Tue, 2 May 2017, grischka wrote:

Michael Matz wrote:
I chose to adjust field layout instead of field type; the latter can cause invalid mem accesses with packed structs/fields:

Hi Michael,

May I suggest something:

It appears to me that it's the point of packed (pcc) bitfields that
all bits are fully tightly packed with no padding whatsoever, such that
they can be used for decoding bit-stream protocols or some such.

No, the (my) point always was to be compatible with existing compilers in the sense that bitfields are layed out as the source author customized to $compiler expected/intended or was used to. All my changes were about GCC and MSVC compatibility (for GCC see (*)). At least insofar as bitfields are required in gawk and linux kernel and strange hand-written testcases.

[side mark: The rationale for msvc or pcc or $whatever bitfield layout is really of no consequence (i.e why they decided to put the bits here or there); most probably nobody can explain anymore why they chose this or that specific layout of bit-fields (and in fact many CPU vendors didn't think about this at all; they used whatever was default with GCC). But the layout of _tcc_ bitfields IMHO should be clear: they should follow whatever the native compiler (i.e. GCC or MSVC) is doing.; if realistically possible]

Yes, we could simplify the bitfield layout code quite much by ignoring this aspect (i.e. devise a TCC specific layout and be done with all the strangenesses). IMHO we shouldn't.

"More or less" packed isn't better than not at all in that case
because it is just not what people will expect (I suppose).

Therefor I'd suggest to revert the layout code to the point where it
actually was producing the correct layout, then comment out the
pcc:packed part and substitute by a warning "currently unsupported",
for now.

So ... (as per above) reversion is IMHO out of question, all the changes were made for a reason. Perhaps my comments are crappy (and I'd admit that parts of them are crappy because the bitfield layout code in GCC is _really_ complicated and that I skimmed over details) but that shouldn't stand in the way of code.

OTOH your mentioning of "to the point where it actually was producing the correct layout" indicates that it's not producing correct (i.e. expected) layout/code anymore. Examples? Because, really, I fixed struct bit-field incompatibilities with both MSVC and GCC, and hence am interested where it's getting things still wrong. (Yes, the recent report was an example. I haven't checked if it got everything right before by design or luck, or superstition.) Still, other examples where things go wrong would be appreciated. :)


(*) GCC compatibility: GCC started out as alternative compiler for $random platform, where range($random) really was large. At that time it was therefore an alternative compiler for whatever existed on the machine (e.g. the C runtime library). For that GCC needed to emulate all aspects of the ABI (how functions are called; at that time the concept of ABI wasn't widespread, but existed) that the native compiler would produce (e.g. procedure calling conventions for functions in libc). Many of the ABIs were based on whatever PCC (portable C compiler) produced, they weren't in fact really thought out, especially in the corner aspects (bit-fields!). So, in the end many of the traditional unix ABIs for random architectures are actually just what "the" compiler happened to produce". And from then it went "oh, but we need to be compatible". That's why PCC bit-field layout still exists, and isn't just called GCC bit-field layout; because it isn't. It's the traditional "if I don't do anything special then this is what I get" layout :)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]