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, All. I don't know How to regenerate a new
configure file while added new target on config.sub,
and gcc/config.gcc. I am a newcomer in using GCC.
Thank you very much.
___
雅虎邮箱传递新年祝福，个性贺卡送亲朋！
http://cn.mail.yahoo.com/gc/index.
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
On Tue, Jan 08, 2008 at 06:41:37PM -0600, Benjamin Kosnik proposes:
> http://gcc.gnu.org/gcc-4.3/changes.html
>
> would be joined by
>
> http://gcc.gnu.org/gcc-4.3/porting_to.html
>
> This would imply that the porting document would be checked in to
> wwwdocs and available to all the usual GCC c
> Attached is a rough cut of a detailed portability document
I also put this up here temporarily:
http://people.redhat.com/~bkoz/porting_to_gcc43.html
-benjamin
Hello all.
As many know, various linux distributors are working on re-compiling
their distros with GCC mainline in the hopes of helping GCC 4.3
stabilize. As part of this effort, many bugs have been filed in GCC
bugzilla, and many portability issues have been identified.
Attached is a rough cut
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
In rtlanal.c we have these lines:
nregs_ymode = hard_regno_nregs[xregno][ymode];
...
&& (GET_MODE_SIZE (ymode) % nregs_ymode) == 0)
The m32c cc1 crashes here because xregno is 1 and ymode is QI, and
register 1 cannot hold a QI value (there are no QImode ops that take
that register), so
On 08 January 2008 15:36, Dave Korn wrote:
> On 07 January 2008 21:15, Mark Mendell wrote:
>
>> A question was raised: Are side effects in the second parameter guaranteed
>> to be executed? Is it valid for a compiler to ignore any side effects?
>
> That perked up my curiosity:
>
> " The va
On 07 January 2008 21:15, Mark Mendell wrote:
> A question was raised: Are side effects in the second parameter guaranteed
> to be executed? Is it valid for a compiler to ignore any side effects?
That perked up my curiosity:
" The value of C must be a compile-time constant. "
Can a comp
On Tue, Jan 08, 2008 at 02:20:38PM +, Andrew Haley wrote:
> guarantee, but I didn't read it that way. The core problem is that
> the psABI is very badly worded.
Bad wording isn't the only problem :-(. That is why there is an
ia32 psABI discussion group. You can bring up any ia32 psABI
issue
H.J. Lu writes:
> On Tue, Jan 08, 2008 at 01:57:50PM +, Andrew Haley wrote:
> > H.J. Lu writes:
> > > On Mon, Jan 07, 2008 at 06:32:08PM +, Andrew Haley wrote:
> > > >
> > > > So, what now? Can we even agree about what the psABI actually says
> > > > about sign-extending result
On Tue, Jan 08, 2008 at 01:57:50PM +, Andrew Haley wrote:
> H.J. Lu writes:
> > On Mon, Jan 07, 2008 at 06:32:08PM +, Andrew Haley wrote:
> > >
> > > So, what now? Can we even agree about what the psABI actually says
> > > about sign-extending result values? Was what we did before co
H.J. Lu writes:
> On Mon, Jan 07, 2008 at 06:32:08PM +, Andrew Haley wrote:
> >
> > So, what now? Can we even agree about what the psABI actually says
> > about sign-extending result values? Was what we did before correct,
> > or what we do now? I don't believe that it doesn't matter.
23 matches
Mail list logo
