Monday 14 January 2008 12:34:03 tarihinde Paolo Bonzini şunları yazmıştı:
> Why not fixing the handful of packages with a /^#define PACKAGE/d,
> instead of adding -fpermissive to the 50 users of those broken packages?
That simple fix won't work, there might be installed headers which depend on
de
Ismail Dönmez wrote:
Sunday 13 January 2008 18:03:20 tarihinde Andreas Schwab şunları yazmıştı:
Ismail Dönmez <[EMAIL PROTECTED]> writes:
That was just an example, real life testcase shows that problem stems
from autoconf and its config.h. Projects end up defining things like
HAVE_STDLIB_H twic
On 14/01/2008, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> On 13/01/2008, Jonathan Wakely wrote:
> >
> > I think all others should change to permerrors.
>
> I only meant all others in cp/decl.c of course - here are the remaining files.
> Again I've only listed the ones that should remain as pedwar
On 13/01/2008, Jonathan Wakely wrote:
>
> I think all others should change to permerrors.
I only meant all others in cp/decl.c of course - here are the remaining files.
Again I've only listed the ones that should remain as pedwarns and
other special cases - most change to permerrors.
In cp/error.
On 13/01/2008, Ismail Dönmez <[EMAIL PROTECTED]> wrote:
>
> So we should should just let Manu finish up his patch and get a review as C++
> FE maintainers agreed as well.
>
Patch sent for approval: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00583.html
Extra testing is welcome in case I missed so
On 13/01/2008, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> On 12/01/2008, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> > On 12/01/2008, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> > >
> > > Here is an initial patch implementing some of your proposals. I used
> > > pederror as the name of
On Sun, 13 Jan 2008, Ismail Dönmez wrote:
| Sunday 13 January 2008 18:40:25 tarihinde Gabriel Dos Reis sunlar? yazm?st?:
| > | real life testcase shows that problem stems from
| > | autoconf and its config.h. Projects end up defining things like
| > | HAVE_STDLIB_H twice which is not harmful at al
Sunday 13 January 2008 18:40:25 tarihinde Gabriel Dos Reis şunları yazmıştı:
> | real life testcase shows that problem stems from
> | autoconf and its config.h. Projects end up defining things like
> | HAVE_STDLIB_H twice which is not harmful at all but now causes an error
> | if g++ is used.
>
> T
On Sun, 13 Jan 2008, Ismail Dönmez wrote:
| Sunday 13 January 2008 17:41:03 tarihinde Gabriel Dos Reis sunlar? yazm?st?:
| > Ismail Dönmez <[EMAIL PROTECTED]> writes:
| > | Hi again,
| > |
| > | Wednesday 09 January 2008 00:28:54 tarihinde Manuel López-Ibáñez sunlar?
| > |
| > | yazm?st?:
| > | >
Sunday 13 January 2008 18:10:00 tarihinde Richard Guenther şunları yazmıştı:
> On Jan 13, 2008 5:10 PM, Ismail Dönmez <[EMAIL PROTECTED]> wrote:
> > Sunday 13 January 2008 18:03:20 tarihinde Andreas Schwab şunları yazmıştı:
> > > Ismail Dönmez <[EMAIL PROTECTED]> writes:
> > > > That was just an ex
On Jan 13, 2008 5:10 PM, Ismail Dönmez <[EMAIL PROTECTED]> wrote:
> Sunday 13 January 2008 18:03:20 tarihinde Andreas Schwab şunları yazmıştı:
> > Ismail Dönmez <[EMAIL PROTECTED]> writes:
> > > That was just an example, real life testcase shows that problem stems
> > > from autoconf and its config
Sunday 13 January 2008 18:03:20 tarihinde Andreas Schwab şunları yazmıştı:
> Ismail Dönmez <[EMAIL PROTECTED]> writes:
> > That was just an example, real life testcase shows that problem stems
> > from autoconf and its config.h. Projects end up defining things like
> > HAVE_STDLIB_H twice which is
Ismail Dönmez <[EMAIL PROTECTED]> writes:
> That was just an example, real life testcase shows that problem stems from
> autoconf and its config.h. Projects end up defining things like HAVE_STDLIB_H
> twice which is not harmful at all but now causes an error if g++ is used.
Redefinitions with t
Sunday 13 January 2008 17:41:03 tarihinde Gabriel Dos Reis şunları yazmıştı:
> Ismail Dönmez <[EMAIL PROTECTED]> writes:
> | Hi again,
> |
> | Wednesday 09 January 2008 00:28:54 tarihinde Manuel López-Ibáñez şunları
> |
> | yazmıştı:
> | > For your particular example, you could open a regression bu
Ismail Dönmez <[EMAIL PROTECTED]> writes:
| Hi again,
|
| Wednesday 09 January 2008 00:28:54 tarihinde Manuel López-Ibáñez şunları
| yazmıştı:
| > For your particular example, you could open a regression bug against
| > 4.3 that says:
| > * '"foo' redefined" is not mandated by the standard or it
On 12/01/2008, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> On 12/01/2008, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> >
> > Here is an initial patch implementing some of your proposals. I used
> > pederror as the name of the function. That is, it is an error unless
> > fpermissive is given.
>
On 12/01/2008, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
>
> Here is an initial patch implementing some of your proposals. I used
> pederror as the name of the function. That is, it is an error unless
> fpermissive is given.
Ah, very fast! :-)
I was just starting somethign similar, I provisio
On 12/01/2008, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> On 11/01/2008, Mark Mitchell wrote:
> >
> > Exactly so. I think that we have two kinds of pedwarns: those that are
> > pedantic in the sense we use for C (like, that there cannot be a naked
> > semicolon at the top-level of a file, or tha
On 11/01/2008, Mark Mitchell wrote:
>
> Exactly so. I think that we have two kinds of pedwarns: those that are
> pedantic in the sense we use for C (like, that there cannot be a naked
> semicolon at the top-level of a file, or that "long long" is not in
> C++98) and those that refer to semanticall
Joe Buck wrote:
> Mark Mitchell wrote:
>>> I don't see any a priori problem with changing to match the C front end.
>>> We could of course change some of the pedwarns into errors if we really
>>> think they ought to be errors. Or, some of them could be ordinary
>>> warnings when not -pedantic, and
Mark Mitchell wrote:
> >I don't see any a priori problem with changing to match the C front end.
> > We could of course change some of the pedwarns into errors if we really
> >think they ought to be errors. Or, some of them could be ordinary
> >warnings when not -pedantic, and pedwarns when -peda
Mark Mitchell wrote:
> I think Jason's input would be helpful. I remember having a discussion
about this years ago (1998?), but I don't remember the complete
rationale. I think the idea was that we wanted many of these things
(ugly old ARM-era C++ things) to be errors, but didn't want to make
Ian Lance Taylor wrote:
> "Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
>
>> Of course there is a third option:
>>
>> * Make pedwarns warnings by default unless -Werror or
>> --pedantic-errors are given (just like the C front-end).
>
> This makes sense to me. I have never understood why it i
Andrew Pinski wrote:
> constaint
*consistent*
Paolo.
On 1/9/08, Benjamin Kosnik <[EMAIL PROTECTED]> wrote:
> Me too. The current error behavior just seems gratuitous. What was the
> rationale for this change to error instead of warn? I am having
> problems locating this discussion on gcc-patches.
The recent preprocessor change or the older front-end
>> Of course there is a third option:
>> * Make pedwarns warnings by default unless -Werror or
>> --pedantic-errors are given (just like the C front-end).
>This makes sense to me. I have never understood why it is a good idea
>for the C++ and C frontends to differ in this way.
Me too. The curre
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
> Of course there is a third option:
>
> * Make pedwarns warnings by default unless -Werror or
> --pedantic-errors are given (just like the C front-end).
This makes sense to me. I have never understood why it is a good idea
for the C++ and C fro
Not at all!!! -fpermissive can (in weird cases, agreed) change code
generation. I'm pretty sure you don't want to risk that only to silence
an error.
What? That doesn't make any sense. And it is certainly not documented
in the manual. I will be very interested in an example, no matter how
wei
On 09/01/2008, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> Andrew Pinski wrote:
> > On 1/8/08, Ismail Dönmez <[EMAIL PROTECTED]> wrote:
> >> Oh that clears up my confusion. So the right fix would be downgrading this
> >> redefinition problem to be pedwarn instead. But I see no point in creating
> >
Andrew Pinski wrote:
On 1/8/08, Ismail Dönmez <[EMAIL PROTECTED]> wrote:
Oh that clears up my confusion. So the right fix would be downgrading this
redefinition problem to be pedwarn instead. But I see no point in creating a
bug report if its just gonna be closed as invalid, so I hope we can dis
On 09/01/2008, Ismail Dönmez <[EMAIL PROTECTED]> wrote:
>
> Looks like this is actually mandated by standard :-( , thats what I am told on
> #gcc anyway :)
>
Not surprising since it is a pedwarn. It would be nice to point to the
relevant sections of the standard in the code as a comment, if you
kn
Hi again,
Wednesday 09 January 2008 00:28:54 tarihinde Manuel López-Ibáñez şunları
yazmıştı:
> For your particular example, you could open a regression bug against
> 4.3 that says:
> * '"foo' redefined" is not mandated by the standard or it is not
> serious enough, so it should not be a pedwarn j
Wednesday 09 January 2008 00:51:32 tarihinde şunları yazmıştınız:
> > Oh that clears up my confusion. So the right fix would be downgrading
> > this redefinition problem to be pedwarn instead. But I see no point in
> > creating a bug report if its just gonna be closed as invalid, so I hope
> > we c
On 08/01/2008, Ismail Dönmez <[EMAIL PROTECTED]> wrote:
>
> Oh that clears up my confusion. So the right fix would be downgrading this
> redefinition problem to be pedwarn instead. But I see no point in creating a
> bug report if its just gonna be closed as invalid, so I hope we can discuss
> if it
On 1/8/08, Ismail Dönmez <[EMAIL PROTECTED]> wrote:
> Oh that clears up my confusion. So the right fix would be downgrading this
> redefinition problem to be pedwarn instead. But I see no point in creating a
> bug report if its just gonna be closed as invalid, so I hope we can discuss
> if its feas
Hi Manuel,
Wednesday 09 January 2008 00:28:54 tarihinde Manuel López-Ibáñez şunları
yazmıştı:
> I implemented the change as the fix to a bug that was reported by
> fellow (and more senior) GCC developers. Let me try to explain
> (although, I hoped that it will be fairly clear from
> gcc.gnu.org/g
On 08/01/2008, Ismail Dönmez <[EMAIL PROTECTED]> wrote:
> Tuesday 08 January 2008 23:34:13 tarihinde Joe Buck şunları yazmıştı:
>
> > Since people have already built whole distros with the gcc from the trunk,
> > clearly theyare managing to build C++ applications that use
> > Python,libmp4v2, libj
On 1/8/08, Ismail Dönmez <[EMAIL PROTECTED]> wrote:
> Tuesday 08 January 2008 23:34:13 tarihinde Joe Buck şunları yazmıştı:
> > There's certainly an argument that this change is ill-advised. However,
> > your statements in the last paragraph aren't true: most quality open
> > source projects have a
Tuesday 08 January 2008 23:34:13 tarihinde Joe Buck şunları yazmıştı:
> There's certainly an argument that this change is ill-advised. However,
> your statements in the last paragraph aren't true: most quality open
> source projects have a "no warnings" rule (or at least try to eliminate
> warning
On Jan 8, 2008 10:34 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 08, 2008 at 11:28:22PM +0200, Ismail Dönmez wrote:
> > Hi all,
> >
> > Looks like gcc 4.3 has some rather inconvenient changes in C++ FE, with the
> > latest trunk. Lets see with an example :
> >
> > [~]> cat test.cpp
> > #d
On Tue, Jan 08, 2008 at 11:28:22PM +0200, Ismail Dönmez wrote:
> Hi all,
>
> Looks like gcc 4.3 has some rather inconvenient changes in C++ FE, with the
> latest trunk. Lets see with an example :
>
> [~]> cat test.cpp
> #define foo bar
> #define foo baz
>
> [~]> g++ -c test.cpp
> test.cpp:2:1:
Hi all,
Looks like gcc 4.3 has some rather inconvenient changes in C++ FE, with the
latest trunk. Lets see with an example :
[~]> cat test.cpp
#define foo bar
#define foo baz
[~]> g++ -c test.cpp
test.cpp:2:1: error: "foo" redefined
test.cpp:1:1: error: this is the location of the previous defi
42 matches
Mail list logo
