From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ken Raeburn To: egcs@cygnus.com Subject: Re: Need someone to look at a regression Date: Wed, 19 Aug 1998 19:04:00 -0000 Message-id: References: <11877.903381328@hurl.cygnus.com> X-SW-Source: 1998-08/msg00627.html Jeffrey A Law 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.