Re: Need someone to look at a regression

[Ken Raeburn <raeburn at cygnus dot com>]

Jeffrey A Law <law@cygnus.com> writes:

>   In message <Pine.LNX.3.95.980817115257.25384E-100000@plum.dwd.interkom.pl>you write:
>   > 
>   > Definitely "int" and "__attribute__ ((mode (SF)))" on the same typedef
>   > clash.
>   > 
>   > However, "float" and "__attribute__ ((mode (SF)))" certainly do not.
> Yes, float and SFmode clash since there is no guarantee that a float
> has the same size as SFmode.

I'm inclined to think of it as the type sort of describing the general
class of types to be used (FP, int, pointer, complex types), with the
mode specifying exactly how big it is.  (Though how you'd use pointers
of strange sizes, I'm not sure.)  Or, to look at it another way, the
attributes modify the type described in some ways (size, alignment,
internal padding), and produce an error if the modification is invalid
(requires different class of base type, making pointer too small).

But that's very different from the implementation.  The mode-attribute
implementation is more like a __typeof__ kind of thing, which given
some input, produces a type that you use as is.  You don't specify the
mode for *your* type; you specify a mode and signedness, and the
compiler hands you the type it has decided you will use.  IMHO such a
thing should fit in syntactically like __typeof__ does, not like an
attribute.  Maybe "typedef __type_for_mode__ (SF) foo;"...


>   > Now, what do I want? An integer? A pointer? Or perhaps a 4-byte
>   > structure? GCC will use SImode for all of them on my machine.
> Right.  Once you get past the front-end, types are not preserved.  You
> just have mode and size.  And  this is precisely what the attributes
> are supposed to provide.

The mode does not indicate signedness.  While this is not an issue for
floating point types (you can specify it, but it's ignored), it does
indicate that the mode alone is not always sufficient.

Here's a random thought: What if someone writes support for
fixed-point variables and arithmetic?  At least for machines without
special support, I'd expect the implementation to use the usual
integer modes, with some special front-end type info indicating that
some of the HLL arithmetic ops need to be expanded differently.  In
that case, I could imagine using

	typedef __fixed(1) int halfstep __attribute__((mode (DI)));

where again the type info would be required to give the correct
semantics.


I'll also note that qualifiers appear to get discarded when the mode
attribute is used.  So
	typedef const int foo __attribute__((mode(SI)));
results in "foo" type variables going into read-write storage, when
they go into read-only storage when the attribute is omitted.  And
	typedef const __complex__ unsigned long long foo
					__attribute__((mode(SF)));
is silently made equivalent to
	typedef float foo;
This too is contrary to how I'd expect such an attribute to work, if I
hadn't looked at the implementation.  (Actually, this result seems
pretty ridiculous to me.)


Also, a minor issue, type_for_mode seems completely unaware of any
complex modes.  And it has support for char* and int* having different
modes, though I don't see how that can arise.