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 09:56:34PM +0000, Neil Booth wrote:
> Zack Weinberg wrote:-
>
> > 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 is serious overhead, and further bloating of the token structure.
> We don't deal with token pointers in cpplib (and we know where that
> took us :-)), but with token objects --- and we do quite a lot of
> (mostly unavoidable) token copying.
Yes, I know. With cleverness it could be reduced. One of the reasons
I didn't want to give up end-of-line tokens was because you could put
line and file numbers only there, and the overhead was cut down to one
short (or even one byte) per token for column numbers.
At one point I was considering 'enter file' and 'leave file' special
tokens instead of callbacks.
> > 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.
>
> Is this really worth it? We can print a macro stack with minimal
> effort with existing code, and along with -E and -dD that should be
> verbose enough for even the meanest intelligence to figure out :-)
I suspect you've never had to debug inside one of the nastier tm.h
macros.
> Does DWARF2 or whatever have the ability to take all this info? I
> hate to think of the size that debug info would become.
I believe DWARF2 can handle it, and it's not significantly worse than
inline functions.
There's a level of filtering that has to happen, probably you don't
want to generate debug information on anything more fine grained than
an individual expression.
> > 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.
>
> I agree, but I'd like him to give it the thumbs up anyway.
Yep.
zw