* DR handling for C++
@ 2004-09-20 20:44 Mark Mitchell
2004-09-20 20:47 ` Dale Johannesen
` (3 more replies)
0 siblings, 4 replies; 22+ messages in thread
From: Mark Mitchell @ 2004-09-20 20:44 UTC (permalink / raw)
To: gcc; +Cc: Matt Austern, Nathan Sidwell, Jason Merrill
I've been asked to provide my input on the handling of DRs in the C++
front end.
Unfortunately, I don't have the messages from the original thread, so
I'm off starting a new thread.
I certainly agree with Matt and Nathan that there's no point in
supporting C++98 separately from C++03. I also agree that new features
in future revisions of C++ should be supported only under a flag. I
think that fixes for existing features, however, should be incorporated
into the C++03 mode, even if they don't show up in C++03 itself. (A
"defect repot", after all, is supposed to refer to a bug in the
standard.) I think the threshold for incorporating such fixes should be
that the fixes are in WP status, in general, although I'd consider other
fixes if it seems clear that the commitee is going to accept the change
and the change seems important.
In the particular case of PR 15049, I think we should go with Matt's
approach. I'm not sure that, in general, I'd want to leave in support
for what the commitee basically considers to be bugs in C++03, but in
this case it looks very easy to do that, so we should probably go ahead.
I think that part of the confusion here comes from the
-pedwarn/-fpermissive situation. I think -fpermissive should just be
removed. I think that many of our pedwarns should become errors, many
should become warnings, -pedantic-errors should be off by default.
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-20 20:44 DR handling for C++ Mark Mitchell
@ 2004-09-20 20:47 ` Dale Johannesen
2004-09-20 20:55 ` Andrew Pinski
2004-09-20 21:00 ` Mark Mitchell
2004-09-20 20:54 ` Gabriel Dos Reis
` (2 subsequent siblings)
3 siblings, 2 replies; 22+ messages in thread
From: Dale Johannesen @ 2004-09-20 20:47 UTC (permalink / raw)
To: Mark Mitchell
Cc: Jason Merrill, gcc, Dale Johannesen, Nathan Sidwell, Matt Austern
On Sep 20, 2004, at 1:04 PM, Mark Mitchell wrote:
> I think -fpermissive should just be removed.
The eon SPECmark will no longer build if we do that.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-20 20:44 DR handling for C++ Mark Mitchell
2004-09-20 20:47 ` Dale Johannesen
@ 2004-09-20 20:54 ` Gabriel Dos Reis
2004-09-20 21:01 ` Mark Mitchell
2004-09-20 21:41 ` Matt Austern
2004-10-18 9:19 ` Jason Merrill
3 siblings, 1 reply; 22+ messages in thread
From: Gabriel Dos Reis @ 2004-09-20 20:54 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc, Matt Austern, Nathan Sidwell, Jason Merrill
Mark Mitchell <mark@codesourcery.com> writes:
| I've been asked to provide my input on the handling of DRs in the C++
| front end.
Historically, we have not been that methodoligical -- in the C++
front-end. I believe part of the confusion comes from the fact that
library policies were being discussed within the comments on Matt's
patch.
| Unfortunately, I don't have the messages from the original thread, so
| I'm off starting a new thread.
|
| I certainly agree with Matt and Nathan that there's no point in
| supporting C++98 separately from C++03. I also agree that new
I don't understand this part. Are you implying that there is no point
for -std=c++98 behaves differently than -std=c++03 (assuming the last
ever existed?)?
| features in future revisions of C++ should be supported only under a
| flag. I think that fixes for existing features, however, should be
| incorporated into the C++03 mode, even if they don't show up in C++03
| itself. (A "defect repot", after all, is supposed to refer to a bug
| in the standard.) I think the threshold for incorporating such fixes
| should be that the fixes are in WP status, in general, although I'd
| consider other fixes if it seems clear that the commitee is going to
| accept the change and the change seems important.
That makes a great deal of sense.
| In the particular case of PR 15049, I think we should go with Matt's
| approach. I'm not sure that, in general, I'd want to leave in support
| for what the commitee basically considers to be bugs in C++03, but in
| this case it looks very easy to do that, so we should probably go
| ahead.
|
| I think that part of the confusion here comes from the
| -pedwarn/-fpermissive situation. I think -fpermissive should just be
| removed. I think that many of our pedwarns should become errors, many
| should become warnings, -pedantic-errors should be off by default.
I'm support of -fpermissive disappearing. I would not cry if
-pedantic suddenly became inexistent (but I guess that is too much for
the moment). Indeed, most of the pedwarns should just be hard errors,
with an exceptional set being warnings. If -pedantic disappeared
then, it would be clear that -pedantic-errors should just go away too.
--
Gabriel Dos Reis
gdr@cs.tamu.edu
Texas A&M University -- Computer Science Department
301, Bright Building -- College Station, TX 77843-3112
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-20 20:47 ` Dale Johannesen
@ 2004-09-20 20:55 ` Andrew Pinski
2004-09-20 21:26 ` Dale Johannesen
2004-09-20 21:00 ` Mark Mitchell
1 sibling, 1 reply; 22+ messages in thread
From: Andrew Pinski @ 2004-09-20 20:55 UTC (permalink / raw)
To: Dale Johannesen
Cc: Jason Merrill, gcc, Nathan Sidwell, Mark Mitchell, Matt Austern
On Sep 20, 2004, at 4:34 PM, Dale Johannesen wrote:
>
> On Sep 20, 2004, at 1:04 PM, Mark Mitchell wrote:
>
>> I think -fpermissive should just be removed.
>
> The eon SPECmark will no longer build if we do that.
Huh? I had been building eon without -fpermissive for
a long time.
Thanks,
Andrew Pinski
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-20 20:47 ` Dale Johannesen
2004-09-20 20:55 ` Andrew Pinski
@ 2004-09-20 21:00 ` Mark Mitchell
2004-09-20 21:04 ` Matt Austern
1 sibling, 1 reply; 22+ messages in thread
From: Mark Mitchell @ 2004-09-20 21:00 UTC (permalink / raw)
To: Dale Johannesen; +Cc: Jason Merrill, gcc, Nathan Sidwell, Matt Austern
Dale Johannesen wrote:
> On Sep 20, 2004, at 1:04 PM, Mark Mitchell wrote:
>
>> I think -fpermissive should just be removed.
>
> The eon SPECmark will no longer build if we do that.
I suppose that's an issue, from a marketing perspective. With my
customer-service hat on, I care a fair amount, as I have customers who
definitely want SPEC numbers. With my GNU maintainer hat on, I don't
care as much.
It may also be that eon requires a relatively small subset of
functionality presently allowed with -fpermissive. It may also be that
if we do as I suggested (turn some pedwarns into errors, others into
warnings, leave others as pedwarns) that we would be OK because the
issues in question would become warnings, not errors.
My problem with -fpermissive is only tangentially that it allows us to
compile bogus code; to me, the bigger problem is that it's yet another
knob, and one that is C++ specific. I see no reason why the basic
warnings/errors/pedwarns structure from C should not also be used in C++.
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-20 20:54 ` Gabriel Dos Reis
@ 2004-09-20 21:01 ` Mark Mitchell
2004-09-20 21:07 ` Gabriel Dos Reis
0 siblings, 1 reply; 22+ messages in thread
From: Mark Mitchell @ 2004-09-20 21:01 UTC (permalink / raw)
To: Gabriel Dos Reis; +Cc: gcc, Matt Austern, Nathan Sidwell, Jason Merrill
Gabriel Dos Reis wrote:
>| Unfortunately, I don't have the messages from the original thread, so
>| I'm off starting a new thread.
>|
>| I certainly agree with Matt and Nathan that there's no point in
>| supporting C++98 separately from C++03. I also agree that new
>
>I don't understand this part. Are you implying that there is no point
>for -std=c++98 behaves differently than -std=c++03 (assuming the last
>ever existed?)?
>
>
Yes, that is what I am saying. I do not think it's worthwhile for GNU
C++ to have a C++98 mode that is separate from a C++03 mode. Much of
what has changed in C++03 is clarifications to C++98; in those cases,
it's not possible to know what C++98 should have done with the code,
because the actual C++98 standard did not say.
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-20 21:00 ` Mark Mitchell
@ 2004-09-20 21:04 ` Matt Austern
2004-09-20 21:08 ` Mark Mitchell
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: Matt Austern @ 2004-09-20 21:04 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc, Dale Johannesen, Nathan Sidwell, Jason Merrill
On Sep 20, 2004, at 1:44 PM, Mark Mitchell wrote:
> Dale Johannesen wrote:
>
>> On Sep 20, 2004, at 1:04 PM, Mark Mitchell wrote:
>>
>>> I think -fpermissive should just be removed.
>>
>> The eon SPECmark will no longer build if we do that.
>
> I suppose that's an issue, from a marketing perspective. With my
> customer-service hat on, I care a fair amount, as I have customers who
> definitely want SPEC numbers. With my GNU maintainer hat on, I don't
> care as much.
>
> It may also be that eon requires a relatively small subset of
> functionality presently allowed with -fpermissive. It may also be
> that if we do as I suggested (turn some pedwarns into errors, others
> into warnings, leave others as pedwarns) that we would be OK because
> the issues in question would become warnings, not errors.
>
> My problem with -fpermissive is only tangentially that it allows us to
> compile bogus code; to me, the bigger problem is that it's yet another
> knob, and one that is C++ specific. I see no reason why the basic
> warnings/errors/pedwarns structure from C should not also be used in
> C++.
Isn't the fundamental problem that we're using pedwarns differently in
the C and C++ front ends? In the C front end you don't even see
pedwarns unless you use a special compiler flag, and making them into
errors requires an even more special compiler flag. It's very odd that
it means something so different in the C++ front end.
This is really going off into a different subject (pedwarn policy, not
DR policy), but I'd suggest that we:
1. Change the C++ front end's pedwarn defaults to match the C front
end's policy.
2. Remove -fpermissive, which #1 will render redundant.
3. Go through our pedwarns and decide which ones should be errors,
which ones should be warnings, and which ones really should just be
pedwarns.
--Matt
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-20 21:01 ` Mark Mitchell
@ 2004-09-20 21:07 ` Gabriel Dos Reis
2004-09-20 21:14 ` Mark Mitchell
0 siblings, 1 reply; 22+ messages in thread
From: Gabriel Dos Reis @ 2004-09-20 21:07 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc, Matt Austern, Nathan Sidwell, Jason Merrill
Mark Mitchell <mark@codesourcery.com> writes:
| Gabriel Dos Reis wrote:
|
| >| Unfortunately, I don't have the messages from the original thread, so
| >| I'm off starting a new thread.
| > | | I certainly agree with Matt and Nathan that there's no point in
| >| supporting C++98 separately from C++03. I also agree that new
| >
| >I don't understand this part. Are you implying that there is no point
| >for -std=c++98 behaves differently than -std=c++03 (assuming the last
| >ever existed?)?
| >
| Yes, that is what I am saying. I do not think it's worthwhile for GNU
| C++ to have a C++98 mode that is separate from a C++03 mode. Much of
| what has changed in C++03 is clarifications to C++98; in those cases,
| it's not possible to know what C++98 should have done with the code,
| because the actual C++98 standard did not say.
If we do that, then we should probably align with the library too.
Otherwise it would become a very confusing situation.
-- Gaby
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-20 21:04 ` Matt Austern
@ 2004-09-20 21:08 ` Mark Mitchell
2004-09-20 21:36 ` Gabriel Dos Reis
2004-09-20 23:42 ` Joseph S. Myers
2 siblings, 0 replies; 22+ messages in thread
From: Mark Mitchell @ 2004-09-20 21:08 UTC (permalink / raw)
To: Matt Austern; +Cc: gcc, Dale Johannesen, Nathan Sidwell, Jason Merrill
Matt Austern wrote:
> Isn't the fundamental problem that we're using pedwarns differently in
> the C and C++ front ends? In the C front end you don't even see
> pedwarns unless you use a special compiler flag, and making them into
> errors requires an even more special compiler flag. It's very odd
> that it means something so different in the C++ front end.
>
> This is really going off into a different subject (pedwarn policy, not
> DR policy), but I'd suggest that we:
> 1. Change the C++ front end's pedwarn defaults to match the C front
> end's policy.
> 2. Remove -fpermissive, which #1 will render redundant.
> 3. Go through our pedwarns and decide which ones should be errors,
> which ones should be warnings, and which ones really should just be
> pedwarns.
Yes, that's exactly what I was trying to suggest.
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-20 21:07 ` Gabriel Dos Reis
@ 2004-09-20 21:14 ` Mark Mitchell
0 siblings, 0 replies; 22+ messages in thread
From: Mark Mitchell @ 2004-09-20 21:14 UTC (permalink / raw)
To: Gabriel Dos Reis; +Cc: gcc, Matt Austern, Nathan Sidwell, Jason Merrill
Gabriel Dos Reis wrote:
>Mark Mitchell <mark@codesourcery.com> writes:
>
>| Gabriel Dos Reis wrote:
>|
>| >| Unfortunately, I don't have the messages from the original thread, so
>| >| I'm off starting a new thread.
>| > | | I certainly agree with Matt and Nathan that there's no point in
>| >| supporting C++98 separately from C++03. I also agree that new
>| >
>| >I don't understand this part. Are you implying that there is no point
>| >for -std=c++98 behaves differently than -std=c++03 (assuming the last
>| >ever existed?)?
>| >
>| Yes, that is what I am saying. I do not think it's worthwhile for GNU
>| C++ to have a C++98 mode that is separate from a C++03 mode. Much of
>| what has changed in C++03 is clarifications to C++98; in those cases,
>| it's not possible to know what C++98 should have done with the code,
>| because the actual C++98 standard did not say.
>
>If we do that, then we should probably align with the library too.
>Otherwise it would become a very confusing situation.
>
>
I do not know if the DRs applying to the library are in the same
category. But, assuming that the C++03 library can be used with code
expecting a C++98 library, then I would happily ignore C++98 for the
library as well.
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-20 20:55 ` Andrew Pinski
@ 2004-09-20 21:26 ` Dale Johannesen
0 siblings, 0 replies; 22+ messages in thread
From: Dale Johannesen @ 2004-09-20 21:26 UTC (permalink / raw)
To: Andrew Pinski
Cc: Jason Merrill, gcc, Dale Johannesen, Nathan Sidwell,
Mark Mitchell, Matt Austern
On Sep 20, 2004, at 1:43 PM, Andrew Pinski wrote:
> On Sep 20, 2004, at 4:34 PM, Dale Johannesen wrote:
>> On Sep 20, 2004, at 1:04 PM, Mark Mitchell wrote:
>>
>>> I think -fpermissive should just be removed.
>>
>> The eon SPECmark will no longer build if we do that.
>
> Huh? I had been building eon without -fpermissive for
> a long time.
Thanks, you are right. Apparently I didn't notice when -fpermissive
stopped being necessary...I am sure it once was.
Never mind.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-20 21:04 ` Matt Austern
2004-09-20 21:08 ` Mark Mitchell
@ 2004-09-20 21:36 ` Gabriel Dos Reis
2004-09-20 23:42 ` Joseph S. Myers
2 siblings, 0 replies; 22+ messages in thread
From: Gabriel Dos Reis @ 2004-09-20 21:36 UTC (permalink / raw)
To: Matt Austern
Cc: Mark Mitchell, gcc, Dale Johannesen, Nathan Sidwell, Jason Merrill
Matt Austern <austern@apple.com> writes:
| On Sep 20, 2004, at 1:44 PM, Mark Mitchell wrote:
|
| > Dale Johannesen wrote:
| >
| >> On Sep 20, 2004, at 1:04 PM, Mark Mitchell wrote:
| >>
| >>> I think -fpermissive should just be removed.
| >>
| >> The eon SPECmark will no longer build if we do that.
| >
| > I suppose that's an issue, from a marketing perspective. With my
| > customer-service hat on, I care a fair amount, as I have customers
| > who definitely want SPEC numbers. With my GNU maintainer hat on, I
| > don't care as much.
| >
| > It may also be that eon requires a relatively small subset of
| > functionality presently allowed with -fpermissive. It may also be
| > that if we do as I suggested (turn some pedwarns into errors, others
| > into warnings, leave others as pedwarns) that we would be OK because
| > the issues in question would become warnings, not errors.
| >
| > My problem with -fpermissive is only tangentially that it allows us
| > to compile bogus code; to me, the bigger problem is that it's yet
| > another knob, and one that is C++ specific. I see no reason why the
| > basic warnings/errors/pedwarns structure from C should not also be
| > used in C++.
|
| Isn't the fundamental problem that we're using pedwarns differently in
| the C and C++ front ends? In the C front end you don't even see
| pedwarns unless you use a special compiler flag, and making them into
| errors requires an even more special compiler flag. It's very odd
| that it means something so different in the C++ front end.
I guess, the issue is to give a meaning to pedwarn() in C++ that would
require a special flag to behave as in C, without totally screwing up
the whole program. I have been under the impression that most of the
cases where we use pedwarn() in C++ are those where we substantially
deviate from the standard. I don't know whether the same is true for C.
-- Gaby
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-20 20:44 DR handling for C++ Mark Mitchell
2004-09-20 20:47 ` Dale Johannesen
2004-09-20 20:54 ` Gabriel Dos Reis
@ 2004-09-20 21:41 ` Matt Austern
2004-09-20 22:32 ` Gabriel Dos Reis
2004-09-20 22:59 ` Mark Mitchell
2004-10-18 9:19 ` Jason Merrill
3 siblings, 2 replies; 22+ messages in thread
From: Matt Austern @ 2004-09-20 21:41 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc, Nathan Sidwell, Jason Merrill
On Sep 20, 2004, at 1:04 PM, Mark Mitchell wrote:
> I've been asked to provide my input on the handling of DRs in the C++
> front end.
>
> Unfortunately, I don't have the messages from the original thread, so
> I'm off starting a new thread.
>
> I certainly agree with Matt and Nathan that there's no point in
> supporting C++98 separately from C++03. I also agree that new
> features in future revisions of C++ should be supported only under a
> flag. I think that fixes for existing features, however, should be
> incorporated into the C++03 mode, even if they don't show up in C++03
> itself. (A "defect repot", after all, is supposed to refer to a bug
> in the standard.) I think the threshold for incorporating such fixes
> should be that the fixes are in WP status, in general, although I'd
> consider other fixes if it seems clear that the commitee is going to
> accept the change and the change seems important.
I'd be unhappy about taking all "WP" changes unconditionally, either
CWG or LWG.
The fact is that the C++ committee uses DRs in several different ways.
In some cases it's "the standard calls for something that's
unimplementable or inconsistent, so here's a bug fix", and in other
cases it's "we think the standard called for something that's not a
good idea, so here's a better redesign."
Arguably the committee shouldn't ever be doing the latter, but it does.
That's especially true now that the committee is targeting changes at
the C++0x working paper rather than at a C++98 technical corrigendum.
In the committee's defense: we all know that the line between a bug fix
and a feature redesign can sometimes be fuzzy. The committee feels, in
my opinion justifiably, that it has more liberty to make changes now
that it's working on a new version of the standard. It's using the
issues list as one mechanism to track changes for that new version of
the standard.
My concern is that if we implement all issues in "WP" status we'll be
back in the bad place we were in the late 90s: tracking an unstable
document, and claiming to implement a "standard" that hasn't actually
been standardized.
There are some committee issues that ought to be implemented, because
there are some cases where the standard really is unimplementable,
vague, meaningless, or contradictory. But at this point there is only
only official C++ standard, and where that standard is clear and
consistent our users have a right to expect that we'll follow it.
--Matt
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-20 21:41 ` Matt Austern
@ 2004-09-20 22:32 ` Gabriel Dos Reis
2004-09-20 22:59 ` Mark Mitchell
1 sibling, 0 replies; 22+ messages in thread
From: Gabriel Dos Reis @ 2004-09-20 22:32 UTC (permalink / raw)
To: Matt Austern; +Cc: Mark Mitchell, gcc, Nathan Sidwell, Jason Merrill
Matt Austern <austern@apple.com> writes:
[...]
| The fact is that the C++ committee uses DRs in several different ways.
| In some cases it's "the standard calls for something that's
| unimplementable or inconsistent, so here's a bug fix", and in other
| cases it's "we think the standard called for something that's not a
| good idea, so here's a better redesign."
[...]
| There are some committee issues that ought to be implemented, because
| there are some cases where the standard really is unimplementable,
| vague, meaningless, or contradictory. But at this point there is only
| only official C++ standard, and where that standard is clear and
| consistent our users have a right to expect that we'll follow it.
well, isn't the last sentence in contradiction with the first paragraph? :-)
I believe C++98 + TC1, aka C++03 is a good thresold. Anything
else should fall under -std=c++0x or -std=c++-experimental.
-- Gaby
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-20 21:41 ` Matt Austern
2004-09-20 22:32 ` Gabriel Dos Reis
@ 2004-09-20 22:59 ` Mark Mitchell
2004-09-20 23:12 ` Matt Austern
1 sibling, 1 reply; 22+ messages in thread
From: Mark Mitchell @ 2004-09-20 22:59 UTC (permalink / raw)
To: Matt Austern; +Cc: gcc, Nathan Sidwell, Jason Merrill
Matt Austern wrote:
> On Sep 20, 2004, at 1:04 PM, Mark Mitchell wrote:
>
>> I've been asked to provide my input on the handling of DRs in the C++
>> front end.
>>
>> Unfortunately, I don't have the messages from the original thread, so
>> I'm off starting a new thread.
>>
>> I certainly agree with Matt and Nathan that there's no point in
>> supporting C++98 separately from C++03. I also agree that new
>> features in future revisions of C++ should be supported only under a
>> flag. I think that fixes for existing features, however, should be
>> incorporated into the C++03 mode, even if they don't show up in C++03
>> itself. (A "defect repot", after all, is supposed to refer to a bug
>> in the standard.) I think the threshold for incorporating such fixes
>> should be that the fixes are in WP status, in general, although I'd
>> consider other fixes if it seems clear that the commitee is going to
>> accept the change and the change seems important.
>
>
> I'd be unhappy about taking all "WP" changes unconditionally, either
> CWG or LWG.
...
> My concern is that if we implement all issues in "WP" status we'll be
> back in the bad place we were in the late 90s: tracking an unstable
> document, and claiming to implement a "standard" that hasn't actually
> been standardized.
>
> There are some committee issues that ought to be implemented, because
> there are some cases where the standard really is unimplementable,
> vague, meaningless, or contradictory. But at this point there is only
> only official C++ standard, and where that standard is clear and
> consistent our users have a right to expect that we'll follow it.
Aren't we basically in agreement? I think we both agree that we needn't
bother with C++98 separate from C++03. I said above that new features
should require a flag, which I think is what you want too. If there's a
disagreement, it's probably around exactly which non-feature
modifications we should incorporate by default. (For example, should
the enum thing you mentioned be incorporated by default in our C++03
mode?) I think I'd take those on a case-by-case basis, incorporating
those that looked like they were really fixing silly things in C++03,
and deferring those that are not.
In this particular case, I'd think we should accept it with a warning in
C++03 mode. (I think the intent of C++03 was to make that case invalid,
but the standard failed to actually say that. )
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-20 22:59 ` Mark Mitchell
@ 2004-09-20 23:12 ` Matt Austern
2004-09-20 23:16 ` Mark Mitchell
0 siblings, 1 reply; 22+ messages in thread
From: Matt Austern @ 2004-09-20 23:12 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc, Nathan Sidwell, Jason Merrill
On Sep 20, 2004, at 2:26 PM, Mark Mitchell wrote:
> Matt Austern wrote:
>
>> On Sep 20, 2004, at 1:04 PM, Mark Mitchell wrote:
>>
>>> I've been asked to provide my input on the handling of DRs in the
>>> C++ front end.
>>>
>>> Unfortunately, I don't have the messages from the original thread,
>>> so I'm off starting a new thread.
>>>
>>> I certainly agree with Matt and Nathan that there's no point in
>>> supporting C++98 separately from C++03. I also agree that new
>>> features in future revisions of C++ should be supported only under a
>>> flag. I think that fixes for existing features, however, should be
>>> incorporated into the C++03 mode, even if they don't show up in
>>> C++03 itself. (A "defect repot", after all, is supposed to refer to
>>> a bug in the standard.) I think the threshold for incorporating
>>> such fixes should be that the fixes are in WP status, in general,
>>> although I'd consider other fixes if it seems clear that the
>>> commitee is going to accept the change and the change seems
>>> important.
>>
>>
>> I'd be unhappy about taking all "WP" changes unconditionally, either
>> CWG or LWG.
>
> ...
>
>> My concern is that if we implement all issues in "WP" status we'll be
>> back in the bad place we were in the late 90s: tracking an unstable
>> document, and claiming to implement a "standard" that hasn't actually
>> been standardized.
>>
>> There are some committee issues that ought to be implemented, because
>> there are some cases where the standard really is unimplementable,
>> vague, meaningless, or contradictory. But at this point there is
>> only only official C++ standard, and where that standard is clear and
>> consistent our users have a right to expect that we'll follow it.
>
> Aren't we basically in agreement? I think we both agree that we
> needn't bother with C++98 separate from C++03. I said above that new
> features should require a flag, which I think is what you want too.
> If there's a disagreement, it's probably around exactly which
> non-feature modifications we should incorporate by default. (For
> example, should the enum thing you mentioned be incorporated by
> default in our C++03 mode?) I think I'd take those on a case-by-case
> basis, incorporating those that looked like they were really fixing
> silly things in C++03, and deferring those that are not.
We are in agreement, yes. I misread you; I thought you were suggesting
that our default mode should conform to "C++03 + all issues in WP
status", and I was arguing that it should conform to "C++03 + a few
issues in WP that we've selected on a case-by-case basis because we
believe they are clear bug fixes."
> In this particular case, I'd think we should accept it with a warning
> in C++03 mode. (I think the intent of C++03 was to make that case
> invalid, but the standard failed to actually say that. )
In this particular case there is no issue in WP status that changes
what the C++03 standard says. The only fully resolved issue on this
subject is CWG 132, which reaffirms the strict reading of the C++98
standard.
I expect that CWG issue 389 will be voted to WP status at the Redmond
meeting. If that's correct, then in early 2005 we will have a clear
example where the committee will have made one deliberate choice for
C++03 and a different choice for C++0x. That's a good example of a
place where we'll want our compiler's behavior to depend on a flag that
selects which standard we're conforming to.
--Matt
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-20 23:12 ` Matt Austern
@ 2004-09-20 23:16 ` Mark Mitchell
0 siblings, 0 replies; 22+ messages in thread
From: Mark Mitchell @ 2004-09-20 23:16 UTC (permalink / raw)
To: Matt Austern; +Cc: gcc, Nathan Sidwell, Jason Merrill
Matt Austern wrote:
> I expect that CWG issue 389 will be voted to WP status at the Redmond
> meeting. If that's correct, then in early 2005 we will have a clear
> example where the committee will have made one deliberate choice for
> C++03 and a different choice for C++0x. That's a good example of a
> place where we'll want our compiler's behavior to depend on a flag
> that selects which standard we're conforming to.
I agree. Thank you for educating me with respect to the history of this
particular DR.
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-20 21:04 ` Matt Austern
2004-09-20 21:08 ` Mark Mitchell
2004-09-20 21:36 ` Gabriel Dos Reis
@ 2004-09-20 23:42 ` Joseph S. Myers
2004-09-21 8:28 ` Paolo Bonzini
2 siblings, 1 reply; 22+ messages in thread
From: Joseph S. Myers @ 2004-09-20 23:42 UTC (permalink / raw)
To: Matt Austern
Cc: Mark Mitchell, gcc, Dale Johannesen, Nathan Sidwell, Jason Merrill
On Mon, 20 Sep 2004, Matt Austern wrote:
> Isn't the fundamental problem that we're using pedwarns differently in the C
> and C++ front ends? In the C front end you don't even see pedwarns unless you
> use a special compiler flag, and making them into errors requires an even more
> special compiler flag. It's very odd that it means something so different in
> the C++ front end.
If pedwarn() is executed, you see the diagnostic, for both C and C++ - no
special flag is required. -pedantic is only relevant to if (pedantic)
pedwarn (...).
Every case where "pedantic" is checked represents some form of extension.
Every such case should be documented as an extension, or the conditioning
on pedantic removed.
pedwarn() is used where the standard requires a diagnostic but it hasn't
been decided to make the relevant condition a hard error (or, in C++, it
has been decided to permit the relevant condition under -fpermissive).
Such cases should all also be documented (with details of the semantics
assigned to the cases which the standard says are ill-formed but we
permit) or removed (changed to hard errors). (There may also be some
cases where the standard permits the code to be rejected but does not
require a diagnostic, where pedwarn() has been chosen.)
In both cases, and for both C and C++, one can document or remove any
individual extension without needing to do all the others at the same
time.
The name pedwarn() has been a bit confusing (because it suggests a link to
-pedantic which isn't really there, the link being that -pedantic-errors
turns pedwarns from warnings to errors), but I don't have a good
suggestion for a less confusing name.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 4.0
jsm@polyomino.org.uk (personal mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-20 23:42 ` Joseph S. Myers
@ 2004-09-21 8:28 ` Paolo Bonzini
2004-09-21 8:43 ` Paolo Bonzini
2004-09-21 12:39 ` Joseph S. Myers
0 siblings, 2 replies; 22+ messages in thread
From: Paolo Bonzini @ 2004-09-21 8:28 UTC (permalink / raw)
To: gcc; +Cc: Mark Mitchell, gcc, Dale Johannesen, Nathan Sidwell, Jason Merrill
> The name pedwarn() has been a bit confusing (because it suggests a link to
> -pedantic which isn't really there, the link being that -pedantic-errors
> turns pedwarns from warnings to errors), but I don't have a good
> suggestion for a less confusing name.
-pedantic-errors is itself not very well named... maybe -Wextra-errors
or something like that would be more suited now that -W has become -Wextra.
Paolo
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-21 8:28 ` Paolo Bonzini
@ 2004-09-21 8:43 ` Paolo Bonzini
2004-09-21 12:39 ` Joseph S. Myers
1 sibling, 0 replies; 22+ messages in thread
From: Paolo Bonzini @ 2004-09-21 8:43 UTC (permalink / raw)
To: Joseph S. Myers
Cc: Mark Mitchell, gcc, Dale Johannesen, Nathan Sidwell, Jason Merrill
> The name pedwarn() has been a bit confusing (because it suggests a link to
> -pedantic which isn't really there, the link being that -pedantic-errors
> turns pedwarns from warnings to errors), but I don't have a good
> suggestion for a less confusing name.
-pedantic-errors is itself not very well named... maybe -Wextra-errors
or something like that would be more suited now that -W has become -Wextra.
Paolo
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-21 8:28 ` Paolo Bonzini
2004-09-21 8:43 ` Paolo Bonzini
@ 2004-09-21 12:39 ` Joseph S. Myers
1 sibling, 0 replies; 22+ messages in thread
From: Joseph S. Myers @ 2004-09-21 12:39 UTC (permalink / raw)
To: Paolo Bonzini
Cc: gcc, Mark Mitchell, Dale Johannesen, Nathan Sidwell, Jason Merrill
On Tue, 21 Sep 2004, Paolo Bonzini wrote:
> > The name pedwarn() has been a bit confusing (because it suggests a link to
> > -pedantic which isn't really there, the link being that -pedantic-errors
> > turns pedwarns from warnings to errors), but I don't have a good suggestion
> > for a less confusing name.
>
> -pedantic-errors is itself not very well named... maybe -Wextra-errors or
> something like that would be more suited now that -W has become -Wextra.
-Wextra-errors sounds like it turns the messages from -Wextra into errors.
(The regular form for that in line with other similar options would be
-Werror-extra - and any general warning control scheme would probably lead
to such options corresponding to each warning option - but -Wextra-errors
still sounds too similar to -Werror-extra.)
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 4.0
jsm@polyomino.org.uk (personal mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: DR handling for C++
2004-09-20 20:44 DR handling for C++ Mark Mitchell
` (2 preceding siblings ...)
2004-09-20 21:41 ` Matt Austern
@ 2004-10-18 9:19 ` Jason Merrill
3 siblings, 0 replies; 22+ messages in thread
From: Jason Merrill @ 2004-10-18 9:19 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc, Matt Austern, Nathan Sidwell, Jason Merrill
On Mon, 20 Sep 2004 13:04:48 -0700, Mark Mitchell <mark@codesourcery.com> wrote:
> I think that part of the confusion here comes from the
> -pedwarn/-fpermissive situation. I think -fpermissive should just be
> removed. I think that many of our pedwarns should become errors, many
> should become warnings, -pedantic-errors should be off by default.
-fpermissive was a compromise between the desire for stricter conformance
checking and the desire for backwards compatibility with users' code, so
that users would be able to use newer compiler versions while they update
their code. I still feel strongly that this is an important goal, but I'm
open to other ideas about how to implement it.
Jason
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2004-10-18 4:48 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-20 20:44 DR handling for C++ Mark Mitchell
2004-09-20 20:47 ` Dale Johannesen
2004-09-20 20:55 ` Andrew Pinski
2004-09-20 21:26 ` Dale Johannesen
2004-09-20 21:00 ` Mark Mitchell
2004-09-20 21:04 ` Matt Austern
2004-09-20 21:08 ` Mark Mitchell
2004-09-20 21:36 ` Gabriel Dos Reis
2004-09-20 23:42 ` Joseph S. Myers
2004-09-21 8:28 ` Paolo Bonzini
2004-09-21 8:43 ` Paolo Bonzini
2004-09-21 12:39 ` Joseph S. Myers
2004-09-20 20:54 ` Gabriel Dos Reis
2004-09-20 21:01 ` Mark Mitchell
2004-09-20 21:07 ` Gabriel Dos Reis
2004-09-20 21:14 ` Mark Mitchell
2004-09-20 21:41 ` Matt Austern
2004-09-20 22:32 ` Gabriel Dos Reis
2004-09-20 22:59 ` Mark Mitchell
2004-09-20 23:12 ` Matt Austern
2004-09-20 23:16 ` Mark Mitchell
2004-10-18 9:19 ` Jason Merrill
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).