Manuel López-Ibáñez wrote:
Then, if the warnings are not very useful but are mandated by the
standard, I think that the sensible thing is to make them conditional
on -pedantic. This way, people wanting strict diagnostics for
nonconformant code can get them, while people that don't care about
On 01/04/07, Martin Michlmayr [EMAIL PROTECTED] wrote:
We have some real numbers about these new errors now. I've compiled
the whole Debian archive in the last week for Gelato to test GCC 4.3
on IA64. Out of just slightly under 7000 packages in Debian, we have
the following new failures:
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-04-02 12:58]:
missing newline: 42
error: xxx redefined: 33
Martin, are those programs compiled with -pedantic or -pedantic-errors
enabled?
Nope.
--
Martin Michlmayr
http://www.cyrius.com/
On 02/04/07, Martin Michlmayr [EMAIL PROTECTED] wrote:
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-04-02 12:58]:
missing newline: 42
error: xxx redefined: 33
Martin, are those programs compiled with -pedantic or -pedantic-errors
enabled?
Nope.
Then, if the warnings are not very useful
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-04-02 13:57]:
Just out of curiosity, does any of those programs use -Werror?
No, otherwise the problems would have been found and fixed before.
Remember, there has always been a warning about this, but now it's an
error.
--
Martin Michlmayr
On 02/04/07, Martin Michlmayr [EMAIL PROTECTED] wrote:
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-04-02 13:57]:
Just out of curiosity, does any of those programs use -Werror?
No, otherwise the problems would have been found and fixed before.
Remember, there has always been a warning about
We have some real numbers about these new errors now. I've compiled
the whole Debian archive in the last week for Gelato to test GCC 4.3
on IA64. Out of just slightly under 7000 packages in Debian, we have
the following new failures:
missing newline: 42
error: xxx redefined: 33
extra tokens at
Martin Michlmayr wrote:
...
- The no newline and xxx redfined pedwarnings should be converted
into normal warnings. Rationale: no newline doesn't harm anyone and
there are quite a few programs that would fail because of an error
that many agree is too strict. Redefining something with -D
Zack Weinberg wrote:
Martin Michlmayr wrote:
...
- The no newline and xxx redfined pedwarnings should be converted
into normal warnings. Rationale: no newline doesn't harm anyone and
there are quite a few programs that would fail because of an error
that many agree is too strict.
* Zack Weinberg [EMAIL PROTECTED] [2007-04-01 08:30]:
This therefore needs to stay a pedwarn at least for the case where the
redefinition comes from a #define in the source. It's not clear to me
whether the diagnostics you're talking about are from a redefinition
via -D on the command line.
On 4/1/07, Martin Michlmayr [EMAIL PROTECTED] wrote:
* Zack Weinberg [EMAIL PROTECTED] [2007-04-01 08:30]:
This therefore needs to stay a pedwarn at least for the case where the
redefinition comes from a #define in the source. It's not clear to me
whether the diagnostics you're talking about
Ugh. That puts us in the position of having to decide whether command
line definitions count as previous definitions for 6.10.3p3.
6.10.3p*2*.
zw
Zack Weinberg wrote:
Ugh. That puts us in the position of having to decide whether command
line definitions count as previous definitions for 6.10.3p3. I'm
inclined to think that they do, or rather, that saying they don't
involves more bending of the language than I am comfortable with. I
On 4/1/07, Robert Dewar [EMAIL PROTECTED] wrote:
Zack Weinberg wrote:
It's not bending the language, the standard has nothing whatever to say
about -D. I see no reason not to be completely permissive wrt -D if it
is going to make transition smoother.
The thing is, the standard does not read An
Ian Lance Taylor wrote:
I agree, but what is happening now is that no newline at end of file
is an error even when -pedantic is not specified. I don't think that
is acceptable.
I completely agree.
The convention in the C++ front end is to say:
if (pedantic)
pedwarn (...);
for things
Andrew Pinski [EMAIL PROTECTED] writes:
| On 27 Mar 2007 21:11:56 -0500, Gabriel Dos Reis [EMAIL PROTECTED] wrote:
| | In C, a pedwarn is a warning by default, an error with -pedantic-errors.
| |
| | In C++, a pedwarn is an error by default, a warning with -fpermissive.
|
| You're describing
Gabriel Dos Reis wrote:
I don't understand your statement. The C++ (and the C) standard says
# If a source file that is not empty does not end in a new-line
# character, or ends in a new-line character immediately preceded by a
# backslash character, the behavior is undefined.
The GNU
Zack Weinberg [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
| I don't understand your statement. The C++ (and the C) standard says
|
| # If a source file that is not empty does not end in a new-line
| # character, or ends in a new-line character immediately preceded by a
| #
Between 4.3.0 20070303 and 4.3.0 20070326 the no newline at end of
file warning changed to an error. Interestingly enough, I cannot see
any obvious change to libcpp/lex.c or the ChangeLog.
Does anyone else see this and know whether this was intentional? I
think this change is a bad idea since
On 27 March 2007 11:26, Martin Michlmayr wrote:
Between 4.3.0 20070303 and 4.3.0 20070326 the no newline at end of
file warning changed to an error. Interestingly enough, I cannot see
any obvious change to libcpp/lex.c or the ChangeLog.
Does anyone else see this and know whether this was
It is a pedantic warning. Pedantic warnings are warnings in C and
errors in C++, unless you use -fpermissive.
So if you are seeing this in C++, the change was intentional because
PR24924 was fixed. If you are seeing it in C and you are not using
pedantic-errors, then it is probably a bug.
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 13:13]:
So if you are seeing this in C++, the change was intentional because
PR24924 was fixed. If you are seeing it in C and you are not using
pedantic-errors, then it is probably a bug.
Thanks for the explanation - this explains what I'm
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 13:13]:
So if you are seeing this in C++, the change was intentional because
PR24924 was fixed.
I think it would be worth mentioning this on
http://gcc.gnu.org/gcc-4.3/changes.html since quite a bit of C++ code
is affected by this change.
On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote:
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 13:13]:
So if you are seeing this in C++, the change was intentional because
PR24924 was fixed. If you are seeing it in C and you are not using
pedantic-errors, then it is probably a
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 14:01]:
Thanks for the explanation - this explains what I'm seeing. Is there
a good reason against changing this particular warning from
CPP_DL_PEDWARN to CPP_DL_WARNING? Quite a few packages in Debian fail
to build because of this and it
On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote:
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 13:13]:
So if you are seeing this in C++, the change was intentional because
PR24924 was fixed.
I think it would be worth mentioning this on
http://gcc.gnu.org/gcc-4.3/changes.html since
On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote:
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 14:01]:
Thanks for the explanation - this explains what I'm seeing. Is there
a good reason against changing this particular warning from
CPP_DL_PEDWARN to CPP_DL_WARNING? Quite a few
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 14:08]:
C++ preprocessor emits errors by default for nonconformant code,
following the C++ frot-end default behaviour. Users can use the
-fpermissive option to downgrade these diagnostics from errors to
warnings.
s/frot-end/front-end/
I'm
On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote:
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 14:08]:
C++ preprocessor emits errors by default for nonconformant code,
following the C++ frot-end default behaviour. Users can use the
-fpermissive option to downgrade these
Martin Michlmayr [EMAIL PROTECTED] writes:
| * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 13:13]:
| So if you are seeing this in C++, the change was intentional because
| PR24924 was fixed. If you are seeing it in C and you are not using
| pedantic-errors, then it is probably a bug.
|
Gabriel Dos Reis [EMAIL PROTECTED] writes:
Martin Michlmayr [EMAIL PROTECTED] writes:
| * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 13:13]:
| So if you are seeing this in C++, the change was intentional because
| PR24924 was fixed. If you are seeing it in C and you are not using
* Gabriel Dos Reis [EMAIL PROTECTED] [2007-03-27 09:33]:
-pedantic asks for strict checking of rules. User should accept
correcting their codes (or used codes) with they ask for strict
checking.
They didn't ask for it because G++ does it by default.
--
Martin Michlmayr
http://www.cyrius.com/
On 27 March 2007 16:07, Ian Lance Taylor wrote:
Gabriel Dos Reis [EMAIL PROTECTED] writes:
Martin Michlmayr [EMAIL PROTECTED] writes:
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 13:13]:
So if you are seeing this in C++, the change was intentional because
PR24924 was fixed. If you
On 27/03/07, Dave Korn [EMAIL PROTECTED] wrote:
On 27 March 2007 16:07, Ian Lance Taylor wrote:
Gabriel Dos Reis [EMAIL PROTECTED] writes:
Martin Michlmayr [EMAIL PROTECTED] writes:
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 13:13]:
So if you are seeing this in C++, the change
Ian Lance Taylor [EMAIL PROTECTED] writes:
| Gabriel Dos Reis [EMAIL PROTECTED] writes:
|
| Martin Michlmayr [EMAIL PROTECTED] writes:
|
| | * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 13:13]:
| | So if you are seeing this in C++, the change was intentional because
| | PR24924
Martin Michlmayr [EMAIL PROTECTED] writes:
| * Gabriel Dos Reis [EMAIL PROTECTED] [2007-03-27 09:33]:
| -pedantic asks for strict checking of rules. User should accept
| correcting their codes (or used codes) with they ask for strict
| checking.
|
| They didn't ask for it because G++ does it
* Manuel López-Ibáñez:
C++ preprocessor emits errors by default for nonconformant code,
following the C++ frot-end default behaviour.
Neither the C standard nor the C++ standard imposes any requirements
on concrete source code representation, so it's not quite right to
blame this issue on
Florian Weimer [EMAIL PROTECTED] writes:
| * Manuel López-Ibáñez:
|
| C++ preprocessor emits errors by default for nonconformant code,
| following the C++ frot-end default behaviour.
|
| Neither the C standard nor the C++ standard imposes any requirements
| on concrete source code
Gabriel Dos Reis [EMAIL PROTECTED] writes:
Florian Weimer [EMAIL PROTECTED] writes:
| Neither the C standard nor the C++ standard imposes any requirements
| on concrete source code representation, so it's not quite right to
| blame this issue on nonconformant code.
I don't understand
On Tue, Mar 27, 2007 at 02:23:47PM +0100, Manuel López-Ibáñez wrote:
On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote:
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 14:08]:
C++ preprocessor emits errors by default for nonconformant code,
following the C++ frot-end default
On Tue, Mar 27, 2007 at 02:11:21PM +0100, Manuel López-Ibáñez wrote:
On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote:
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 14:01]:
Thanks for the explanation - this explains what I'm seeing. Is there
a good reason against changing this
* Ian Lance Taylor:
I don't think we necessarily have to change anything.
Yes, I think that the standard does not require a particular approach
to this problem.
But I think that Florian's point is that we don't have to confuse the
concrete implementation with the abstract source
On Tue, Mar 27, 2007 at 09:47:35AM -0700, Joe Buck wrote:
On Tue, Mar 27, 2007 at 02:11:21PM +0100, Manuel López-Ibáñez wrote:
On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote:
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 14:01]:
Thanks for the explanation - this explains what
On Tue, 27 Mar 2007, Michael Meissner wrote:
translation (5.1.1.2 in the C99 standard, should be close in the C90
standard). In particular, in paragraph 3, it says:
A source file shall not end in a partial preprocessing token or a
partial comment...
If there is no
On 27/03/07, Joe Buck [EMAIL PROTECTED] wrote:
On Tue, Mar 27, 2007 at 02:23:47PM +0100, Manuel López-Ibáñez wrote:
On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote:
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27 14:08]:
C++ preprocessor emits errors by default for nonconformant
On 27 Mar 2007 11:53:18 -0500, Gabriel Dos Reis [EMAIL PROTECTED] wrote:
Joe Buck [EMAIL PROTECTED] writes:
| On Tue, Mar 27, 2007 at 02:23:47PM +0100, Manuel López-Ibáñez wrote:
| On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote:
| * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-03-27
Quoting Manuel López-Ibáñez [EMAIL PROTECTED]:
On 27 Mar 2007 11:53:18 -0500, Gabriel Dos Reis [EMAIL PROTECTED] wrote:
Joe Buck [EMAIL PROTECTED] writes:
| On Tue, Mar 27, 2007 at 02:23:47PM +0100, Manuel L=F3pez-Ib=E1=F1ez wro=
te:
| On 27/03/07, Martin Michlmayr [EMAIL PROTECTED] wrote:
On Wed, Mar 28, 2007 at 01:23:45AM +, Joseph S. Myers wrote:
In C, a pedwarn is a warning by default, an error with -pedantic-errors.
In C++, a pedwarn is an error by default, a warning with -fpermissive.
OK, so the change is that pedwarns from the preprocessor were previously
warnings by
On Tue, 27 Mar 2007, [EMAIL PROTECTED] wrote:
my understanding of pedwarn (since over a decade) is I explained.
Now, if we do have some good diagnostics, we should not lose them,
as a matter of restoring the traditional meaning of pedwarns.
Do you have an approximate list of those
Joseph S. Myers [EMAIL PROTECTED] writes:
| On Tue, 27 Mar 2007, [EMAIL PROTECTED] wrote:
|
| my understanding of pedwarn (since over a decade) is I explained.
| Now, if we do have some good diagnostics, we should not lose them,
| as a matter of restoring the traditional meaning of pedwarns.
On 27 Mar 2007 21:11:56 -0500, Gabriel Dos Reis [EMAIL PROTECTED] wrote:
| In C, a pedwarn is a warning by default, an error with -pedantic-errors.
|
| In C++, a pedwarn is an error by default, a warning with -fpermissive.
You're describing a defect, not the intended semantics.
In C, a pedwarn
51 matches
Mail list logo
