* [RFC] __extension__ and warnings
@ 2002-12-11 14:16 Neil Booth
2002-12-11 14:19 ` Gabriel Dos Reis
2002-12-11 15:17 ` Zack Weinberg
0 siblings, 2 replies; 7+ messages in thread
From: Neil Booth @ 2002-12-11 14:16 UTC (permalink / raw)
To: gcc
I've been looking into PR 7263 about __extension__ not turning off
warnings about LL and ULL.
Not surprisingly, our treatment of warn_long_long is quite inconsistent
within front ends, and with cpplib, and with use of __extension__.
Getting things 100% right with __extension__ is hard, and would uglify
the parsers further. I don't think the pain is worth the gain, and I
don't want to go there. At present we turn of pedantic, warn_traditional,
warn_pointer_arith and flag_iso in the C front end, and pedantic in the
C++ front end.
I propose a simpler solution: simply do not emit any pedwarns whilst inside
the code affected by __extension__. This is easy to implement inside
pedwarn() itself.
With this, I can clear up some confused and confusing warning logic, and fix
its interaction with cpplib's number interpreter. Thoughts?
Neil.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] __extension__ and warnings
2002-12-11 14:16 [RFC] __extension__ and warnings Neil Booth
@ 2002-12-11 14:19 ` Gabriel Dos Reis
2002-12-11 22:55 ` Mark Mitchell
2002-12-11 15:17 ` Zack Weinberg
1 sibling, 1 reply; 7+ messages in thread
From: Gabriel Dos Reis @ 2002-12-11 14:19 UTC (permalink / raw)
To: Neil Booth; +Cc: gcc
Neil Booth <neil@daikokuya.co.uk> writes:
[...]
| I propose a simpler solution: simply do not emit any pedwarns whilst inside
| the code affected by __extension__. This is easy to implement inside
| pedwarn() itself.
|
| With this, I can clear up some confused and confusing warning logic, and fix
| its interaction with cpplib's number interpreter. Thoughts?
At first sight, I would say that sounds reasonable. I reserve my
comments for the concrete patch.
-- Gaby
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] __extension__ and warnings
2002-12-11 14:16 [RFC] __extension__ and warnings Neil Booth
2002-12-11 14:19 ` Gabriel Dos Reis
@ 2002-12-11 15:17 ` Zack Weinberg
2002-12-11 15:54 ` Neil Booth
1 sibling, 1 reply; 7+ messages in thread
From: Zack Weinberg @ 2002-12-11 15:17 UTC (permalink / raw)
To: Neil Booth; +Cc: gcc
Neil Booth <neil@daikokuya.co.uk> writes:
> Getting things 100% right with __extension__ is hard, and would uglify
> the parsers further. I don't think the pain is worth the gain, and I
> don't want to go there. At present we turn of pedantic, warn_traditional,
> warn_pointer_arith and flag_iso in the C front end, and pedantic in the
> C++ front end.
>
> I propose a simpler solution: simply do not emit any pedwarns whilst inside
> the code affected by __extension__. This is easy to implement inside
> pedwarn() itself.
>
> With this, I can clear up some confused and confusing warning logic, and fix
> its interaction with cpplib's number interpreter. Thoughts?
I'm definitely in favor of cleaning this stuff up, but I have to point
out that your proposed solution would change the effect of
__extension__ quite a bit. It is supposed to be the case that all
warnings under if (pedantic) are pedwarn() calls, but it is not the
case that all pedwarn() calls are under if (pedantic); most of the
warnings affected by warn_traditional and warn_pointer_arith are _not_
pedwarn(), nor should they be; and I don't know what-all flag_iso
does.
The spec for pedwarn and pedantic, as I understand it, which may be a
bit out of date, is:
- If and only if the diagnostic in question is mandated by the
relevant standard (C89, C99, C++98, F77, etc) use pedwarn()
(unless you are using error() instead).
- If, despite this, we do not think the warning should be on by
default, put the pedwarn call under if (pedantic) or possibly
if (pedantic||Wall).
The spec for __extension__ is, it asserts that the following
expression makes deliberate use of GNU extensions under proper
#ifdeffage, so don't bug the programmer about it. Some, but not all,
GNU extensions draw mandatory diagnostics; others are properly
complained about by -Wtraditional and the like. So the two properties
are somewhat orthogonal.
I'm now imagining turning the DT_* enumeration into a set of bitflags,
so that you could write e.g.
diagnostic (DT_EXTENSION | DT_MANDATED | DT_WARNING, "...")
to achieve the effect of 'pedwarn but shut up under __extension__.'
zw
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] __extension__ and warnings
2002-12-11 15:17 ` Zack Weinberg
@ 2002-12-11 15:54 ` Neil Booth
2002-12-11 23:54 ` Neil Booth
0 siblings, 1 reply; 7+ messages in thread
From: Neil Booth @ 2002-12-11 15:54 UTC (permalink / raw)
To: Zack Weinberg; +Cc: gcc
Zack Weinberg wrote:-
> The spec for pedwarn and pedantic, as I understand it, which may be a
> bit out of date, is:
>
> - If and only if the diagnostic in question is mandated by the
> relevant standard (C89, C99, C++98, F77, etc) use pedwarn()
> (unless you are using error() instead).
>
> - If, despite this, we do not think the warning should be on by
> default, put the pedwarn call under if (pedantic) or possibly
> if (pedantic||Wall).
>
> The spec for __extension__ is, it asserts that the following
> expression makes deliberate use of GNU extensions under proper
> #ifdeffage, so don't bug the programmer about it. Some, but not all,
> GNU extensions draw mandatory diagnostics; others are properly
> complained about by -Wtraditional and the like. So the two properties
> are somewhat orthogonal.
>
> I'm now imagining turning the DT_* enumeration into a set of bitflags,
> so that you could write e.g.
>
> diagnostic (DT_EXTENSION | DT_MANDATED | DT_WARNING, "...")
>
> to achieve the effect of 'pedwarn but shut up under __extension__.'
I prefer this. Fancy changing all error(), warning(), pedwarn(), ...,
calls? 8-)
Neil.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] __extension__ and warnings
2002-12-11 14:19 ` Gabriel Dos Reis
@ 2002-12-11 22:55 ` Mark Mitchell
0 siblings, 0 replies; 7+ messages in thread
From: Mark Mitchell @ 2002-12-11 22:55 UTC (permalink / raw)
To: Gabriel Dos Reis, Neil Booth; +Cc: gcc
--On Wednesday, December 11, 2002 11:10:40 PM +0100 Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> Neil Booth <neil@daikokuya.co.uk> writes:
>
> [...]
>
> | I propose a simpler solution: simply do not emit any pedwarns whilst
> inside | the code affected by __extension__. This is easy to implement
> inside | pedwarn() itself.
> |
> | With this, I can clear up some confused and confusing warning logic,
> and fix | its interaction with cpplib's number interpreter. Thoughts?
>
> At first sight, I would say that sounds reasonable. I reserve my
> comments for the concrete patch.
It sounds plausible to me as well.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] __extension__ and warnings
2002-12-11 15:54 ` Neil Booth
@ 2002-12-11 23:54 ` Neil Booth
2002-12-11 23:58 ` Gabriel Dos Reis
0 siblings, 1 reply; 7+ messages in thread
From: Neil Booth @ 2002-12-11 23:54 UTC (permalink / raw)
To: Zack Weinberg; +Cc: gcc
Neil Booth wrote:-
> > I'm now imagining turning the DT_* enumeration into a set of bitflags,
> > so that you could write e.g.
> >
> > diagnostic (DT_EXTENSION | DT_MANDATED | DT_WARNING, "...")
> >
> > to achieve the effect of 'pedwarn but shut up under __extension__.'
I think you mean DL_ constants, like I'm using in cpplib? It was meant
to stand for diagnostic level.
> I prefer this. Fancy changing all error(), warning(), pedwarn(), ...,
> calls? 8-)
Roughly there are 1965 error(), 820 warning() and 330 pedwarn() calls;
this includes the _with variants. Piece of cake 8-)
This is probably a good 3.4 project; it would be a great cleanup of our
diagnostics system. Do you agree Gaby?
Neil.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] __extension__ and warnings
2002-12-11 23:54 ` Neil Booth
@ 2002-12-11 23:58 ` Gabriel Dos Reis
0 siblings, 0 replies; 7+ messages in thread
From: Gabriel Dos Reis @ 2002-12-11 23:58 UTC (permalink / raw)
To: Neil Booth; +Cc: Zack Weinberg, gcc
Neil Booth <neil@daikokuya.co.uk> writes:
| Neil Booth wrote:-
|
| > > I'm now imagining turning the DT_* enumeration into a set of bitflags,
| > > so that you could write e.g.
| > >
| > > diagnostic (DT_EXTENSION | DT_MANDATED | DT_WARNING, "...")
| > >
| > > to achieve the effect of 'pedwarn but shut up under __extension__.'
|
| I think you mean DL_ constants, like I'm using in cpplib? It was meant
| to stand for diagnostic level.
|
| > I prefer this. Fancy changing all error(), warning(), pedwarn(), ...,
| > calls? 8-)
|
| Roughly there are 1965 error(), 820 warning() and 330 pedwarn() calls;
| this includes the _with variants. Piece of cake 8-)
|
| This is probably a good 3.4 project; it would be a great cleanup of our
| diagnostics system. Do you agree Gaby?
Yes, definitely.
-- Gaby
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2002-12-12 7:35 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-11 14:16 [RFC] __extension__ and warnings Neil Booth
2002-12-11 14:19 ` Gabriel Dos Reis
2002-12-11 22:55 ` Mark Mitchell
2002-12-11 15:17 ` Zack Weinberg
2002-12-11 15:54 ` Neil Booth
2002-12-11 23:54 ` Neil Booth
2002-12-11 23:58 ` Gabriel Dos Reis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).