This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Need someone to look at a regression
- To: Carlo Wood <carlo at runaway dot xs4all dot nl>
- Subject: Re: Need someone to look at a regression
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Sun, 16 Aug 1998 21:20:48 -0600
- cc: egcs at cygnus dot com (egcs at cygnus dot com)
- Reply-To: law at cygnus dot com
In message <199808161324.PAA10943@jolan.ppro>you write:
> 1) The use of a mode() makes this code only ever make sense when
> compiled with gcc.
The whole construct only makes sense when compiled with gcc. It should
(IMHO) give an error instead of trying to do the right thing if you're
not compiling with gcc.
Why? If you try to "fake it", odds are you're not going to get it
right consistently and you'll end up silently generating incorrect
code. IMHO, it's better to get a compile time error in this case.
> Then suppression of the warning would be the best because when
> the warning is not suppressed people will add 'int' and then
> no warning will occur when compiling the code with another
> compiler which uses:
> #define __attribute__
Right.
> 2) It *does* make sense to compile code like this with other
> compilers (ie, using "#define __attribute__" somewhere).
>
> In that case you want a 'backup' type to be added that will
> be used when the __attribute__ is #defined away.
> We need a NEW warning then however, when the overridden
> type doesn't match the mode() somehow. I am not sure if
> that is possible since I don't know the mode() types :/
Many of the attributes make no sense when building with other compilers;
I think the mode attribute is one of them.
I don't see how to get the additional warning since the size of
the C data types is implementation specific, whereas the size of
most modes is fixed.
jeff