This is the mail archive of the
mailing list for the GCC project.
Re: DR handling for C++
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
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
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