This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFA] Silence some warnings [was Re: "introduce no new bootstrap..."]
On Mon, Jan 15, 2001 at 08:11:18PM +0000, Neil Booth wrote:
> Hi Zack,
>
> OK, I relent, but only slightly.
...
> I have exported an interface from cpplib
>
> int cpp_sys_objmacro_p (cpp_reader *);
>
> which returns true if the macro at the top of the macro stack was
> defined in a system header, and is an object-like macro. So "simple"
> uses of stuff like UINT_MAX will return true.
>
> I have updated cppexp.c and c-lex.c to check this before giving the
> -Wtraditional warning.
>
> However, this is only a very simple check, and (though I haven't
> tried) undoubtedly will fail on some things. It will also fail in the
> event of token look-ahead, either by cpplib or front ends. At
> present, only cpplib does look-ahead, and only occasionally and for
> single tokens. The front-ends could well start using this cpplib
> facility in the future, in which case we could start getting more
> macro uses that have since been "popped" off the macro stack and the
> warnings will re-appear.
We can live with some level of false positives. In the long term I
want to see more information carried downstream with each token:
at least the file it came from and the position within. This isn't
just for warning suppression. One of the secondary goals of cpplib
was so we could issue diagnostics and emit debug info inside complex
macros, that referred to the real location of the source code.
Obviously this is a post-3.0 concern.
> I really don't think doing any more than this is workable or
> realistic. I hope this makes people that don't like the current
> situation a bit happier, and that we examine every new warning to be
> "suppressed" along these lines on a case-by-case basis, and with some
> scepticism.
Yes. We ought to look at the existing blanket suppressions a bit more
closely, too. This is a contrived example, but what if you have a
system header that constructs code from user #defines? [I've been
planning to write such a thing, to squeeze cycles out of hashtab.c.]
We'd want to see warnings in there if they were caused by user code...
> Anyway, how does this float people's boat? It will help silence
> gazillions of warnings caused by glibc in recent Linux bootstraps.
>
> I'll post a testcase soon. Bootstrapping i586 Linux. OK to commit
> this in the slush period?
I don't know what Mark's reaction will be, but my attitude is that
overzealous warnings are a bug, so the patch qualifies as a bug fix.
It's not hugely invasive and doesn't affect code generation, either.
zw