[Bug inline-asm/17346] [3.5 Regression] linux kernel: handwritten offsetof break inline asm

["jsm at polyomino dot org dot uk" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From jsm at polyomino dot org dot uk  2004-09-09 16:28 -------
Subject: Re:  [3.5 Regression] linux kernel: handwritten
 offsetof break inline asm

On Thu, 9 Sep 2004, matz at suse dot de wrote:

> The kernel does use offsetof().  But of course it has its own headers, 
> defining this macro to the usual construct, instead of using 
> __builtin_offsetof (which didn't exist in older compilers).  I was merely 
> expanding the offsetof macro in the testcase by hand, in order to make it 
> visible, where exactly it breaks. 

The compiler's versions of the headers required of freestanding 
implementations are mostly intended to be usable for non-userspace code.  
(If using <limits.h>, you will need to provide your own replacement for 
libc's one which GCC's includes with #include_next, or disable it by 
defining _LIBC_LIMITS_H_.)

> And I would extend this to not just const-fold in asms.  There is no reason 
> to not do this optimization also outside.  There is enough code out there 
> which still uses the legacy definition of offsetof.  Why pessimize it? 
> (This doesn't mean that this construct should be regarded as a constant 
> in the language sense.  My point was, that it does boil down to a constant, 
> no matter what the language says). 

We should optimise in all cases, at the various stages of compilation at 
which it makes sense, and this should be independent of the checks on what 
is sufficiently constant where the standards require a constant.  My model 
of constant expressions <http://www.srcf.ucam.org/~jsm28/gcc/#const> 
defines the given expression as being an address constant of integer type, 
so usable in initializers though not where integer constant expressions 
are required (case labels, enum values, bit-field widths, initializer 
designators, null pointer constants), whereas __builtin_offsetof will 
expand to an actual integer constant expression usable in all those 
places.  But the expression should be optimised to a constant early in 
compilation (no later than an early pass on GIMPLE).

Because of the inherently implementation-dependent nature of asm 
statements, whether something is an integer constant when an asm needs an 
integer constant shouldn't be checked based on standard rules for constant 
expressions, but on whether it can be optimised to a constant.  How much 
optimisation should be used - whether e.g. it shouldn't be checked until 
after SSA constant propagation - I'm not sure; either you have the problem 
of emitting diagnostics after what should be a valid translation unit has 
been passed off from the front end to the middle end in GIMPLE, or you 
have the problem of not accepting cases that may be useful to some users 
of asm statements.  There is even a case for accepting the strange sorts 
of constants Geoff Keating mentioned in 
<http://gcc.gnu.org/ml/gcc/2004-08/msg00812.html>, for appropriate asm 
constraints, if the assembler might accept them, to provide the window for 
people knowing what strange things their assembler considers OK in a given 
context to use them.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17346