This is the beta release of binutils 2.17.50.0.11 for Linux, which is
based on binutils 2007 0125 in CVS on sourceware.org plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections
On Thu, Jan 25, 2007 at 07:22:46PM -0800, George R Goffe wrote:
> Howdy,
>
> I got an email from Joe Buck who suggested that I fix a clock skew problem
> between 2
> of my systems. I did this but this did not change the "other" problem with
> this
> build effort. A diff of the 2 sets of error me
Howdy,
I got an email from Joe Buck who suggested that I fix a clock skew problem
between 2
of my systems. I did this but this did not change the "other" problem with this
build effort. A diff of the 2 sets of error messages showed that the clock
problem
did in fact disappear.
Any ideas as to h
On Thu, Jan 25, 2007 at 04:21:28PM -0800, George R Goffe wrote:
> Howdy,
>
> I've been seeing this error for the past couple of days. Am I doing something
> wrong
> here?
The following message is worrying:
> make[8]: Warning: File `../../../native/jni/classpath/jcl.lo' has
> modification time
Howdy,
I've been seeing this error for the past couple of days. Am I doing something
wrong
here?
Regards and thanks,
George...
(cd .libs && rm -f libclasspath.la && ln -s ../libclasspath.la libclasspath.la)
make[8]: Leaving directory
`/tools/tools/gcc/obj-i686-pc-linux-gnu/x86_64-unknown-linux
I''l give that a shot. Thanks
On 1/25/07, Mike Stump <[EMAIL PROTECTED]> wrote:
On Jan 25, 2007, at 2:11 PM, Jason Erickson wrote:
> I'm working on a project where every so often one of our games comes
> back and we pull the ram off the game for saving, and sometimes for
> anaylisis. Currently
On Jan 25, 2007, at 2:11 PM, Jason Erickson wrote:
I'm working on a project where every so often one of our games comes
back and we pull the ram off the game for saving, and sometimes for
anaylisis. Currently the only varibles in ram that we can physically
look at are the static members. The in
I'm working on a project where every so often one of our games comes
back and we pull the ram off the game for saving, and sometimes for
anaylisis. Currently the only varibles in ram that we can physically
look at are the static members. The information that we would love to
get to is the heap m
Robert Dewar wrote:
>> So basically you're saying gcc developers should compensate for other
>> people's sloppy engineering? ;-)
>
> Yes I would say! where possible this seems an excellent goal.
I agree: when it's possible to support non-standard legacy semantics
that do not conflict with the s
On 1/25/07, Volker Reichelt <[EMAIL PROTECTED]> wrote:
Hi,
> | Well, there's another serious (wrong-code) bug which should be fixed
IMHO:
> |
> | PR c++/29106 is a C++ front-end issue.
> | It has a one-line fix (plus comment) on the 4.1 branch.
> | Well, actually one should also backport the fix
Ian Lance Taylor wrote on 01/18/07 10:51:
Well, internally, we do have ASSERT_EXPR. It would probably take a
little work to permit the frontends to generate it, but the optimizers
should understand it.
By default, they do not. When I initially implemented VRP, I was adding
ASSERT_EXPRs right
Hi,
> | Well, there's another serious (wrong-code) bug which should be fixed
IMHO:
> |
> | PR c++/29106 is a C++ front-end issue.
> | It has a one-line fix (plus comment) on the 4.1 branch.
> | Well, actually one should also backport the fix for PR c++/28284 then,
> | which is a two-liner.
> I wa
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 25, 2007 1:54 PM
> To: Meissner, Michael
> Cc: gcc@gcc.gnu.org
> Subject: Re: RE: char should be signed by default
>
> > - Original Message -
> > From: "Meissner, Michael" <[EMAIL PRO
On Wed, Jan 24, 2007 at 08:39:47PM -0500, DJ Delorie wrote:
>
> Here's an example of bad assumptions. The current code calculates the
> subreg location BEFORE checking to see if such a subreg is legal.
> This patch moved the legality check before the location calculations.
See also http://gcc
On Wed, Jan 24, 2007 at 04:10:18PM -0500, Andrew J. Hutton wrote:
> > We would like to invite everyone to read over the Call for Papers for
> > the 2007 GCC Developers' Summit located at
> > http://www.gccsummit.org/2007/cfp.php and to consider submitting a
> > proposal for this year.
On Thu,
On Thu, 25 Jan 2007, Joe Buck wrote:
| It might be worth fixing a couple of wrong-code bugs that are already
| fixed in 4.1 and have very trivial fixes. I don't think it's wise,
| though, to backport fixes from the 4.1 branch that are broken in 4.1.1
| unless there's a really strong justification
On Thu, Jan 25, 2007 at 05:42:31PM +0100, Volker Reichelt wrote:
> Hi,
>
> > There were over 250 PRs open against GCC-4.0.4. Almost all of
> > them are "benign" in the sense that we can leave without fixing them
> > in GCC-4.0.4 -- many are already fixed in more recent versions.
> > I'm now givin
On Thu, Jan 25, 2007 at 02:02:47PM -0500, In Cognito wrote:
> Let me try to clarify.
> GCC is allocated more than 512 bytes,
> >0x080483a7 :sub$0x208,%esp
> 0x208= 520 in this case.
>
> Where are those extra 8 bytes? They're in between what
> gcc is considering the start of buf, &buf[0] a
On Thu, 25 Jan 2007, Richard Guenther wrote:
| On 1/25/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > On Thu, 25 Jan 2007, Richard Guenther wrote:
| >
| > | You might want to consider middle-end/28651 given the recent integer
overflow
| > | discussions.
| >
| > Good suggestion!
| >
| > | I c
On 1/25/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
On Thu, 25 Jan 2007, Richard Guenther wrote:
| You might want to consider middle-end/28651 given the recent integer overflow
| discussions.
Good suggestion!
| I can do the backport work if you like.
If you could work out a backport by to
Let me try to clarify.
GCC is allocated more than 512 bytes,
0x080483a7 :sub$0x208,%esp
0x208= 520 in this case.
Where are those extra 8 bytes? They're in between what
gcc is considering the start of buf, &buf[0] and %esp (the top of the stack).
I'm considering those extra 8 bytes to b
> - Original Message -
> From: "Meissner, Michael" <[EMAIL PROTECTED]>
> Date: Wednesday, January 24, 2007 12:49 pm
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of
> > [EMAIL PROTECTED]
> > Sent: Wednesday, January 24, 2007 12:19 AM
> >
> -Original Message-
> From: Gabriel Paubert [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 25, 2007 5:43 AM
> To: Paolo Bonzini
> Cc: Meissner, Michael; [EMAIL PROTECTED]; gcc@gcc.gnu.org
> Subject: Re: [OT] char should be signed by default
>
> On Thu, Jan 25, 2007 at 10:29:29AM +010
On Wed, Jan 24, 2007 at 04:10:18PM -0500, Andrew J. Hutton wrote:
> We would like to invite everyone to read over the Call for Papers for
> the 2007 GCC Developers' Summit located at
> http://www.gccsummit.org/2007/cfp.php and to consider submitting a
> proposal for this year.
>
> This year we'
"Laura Tardivo" <[EMAIL PROTECTED]> writes:
> I whant to know if the enum definition was changed in the last versions of
> gcc because in the ansi C you can not define:
>
> enum COLOR{RED,GREEN,};
>
> the last comma only is correct if you are defining an initialization of a
> variable. But it
On Thursday 25 January 2007 01:43, In Cognito wrote:
> > > 0x080483a7 :sub$0x208,%esp
> > > 0x080483ad :mov0x8(%ebp),%eax
> > > 0x080483b0 : mov%eax,0x4(%esp)
> > > 0x080483b4 : lea0xfe00(%ebp),%eax
> > > 0x080483ba : mov%eax,(%esp)
> > > 0x080483bd : call
I whant to know if the enum definition was changed in the last versions of
gcc because in the ansi C you can not define:
enum COLOR{RED,GREEN,};
the last comma only is correct if you are defining an initialization of a
variable. But it is allowed in gcc 4.1.1
Laura.-
On Thu, 25 Jan 2007, Manuel López-Ibáñez wrote:
| Thanks. I understand that you are busy with the 4.0.4 release, so
| don't need to hurry up!
I was busy with daytime job.
-- Gaby
Volker Reichelt <[EMAIL PROTECTED]> writes:
| Hi,
|
| > There were over 250 PRs open against GCC-4.0.4. Almost all of
| > them are "benign" in the sense that we can leave without fixing them
| > in GCC-4.0.4 -- many are already fixed in more recent versions.
| > I'm now giving attention only to
On 25 Jan 2007 11:17:41 -0600, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
| A summary of what has been proposed so far to clean up Wextra follows.
| Please, your feedback is appreciated. And reviewing patches even more
| ;-)
Thanks for this dig
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
| A summary of what has been proposed so far to clean up Wextra follows.
| Please, your feedback is appreciated. And reviewing patches even more
| ;-)
Thanks for this digest; I'd give your feedback tonight.
-- Gaby
On Thu, 25 Jan 2007, Richard Guenther wrote:
| You might want to consider middle-end/28651 given the recent integer overflow
| discussions.
Good suggestion!
| I can do the backport work if you like.
If you could work out a backport by tomorrow morning (CST), that would
would great.
Thanks!
--
Hi,
> There were over 250 PRs open against GCC-4.0.4. Almost all of
> them are "benign" in the sense that we can leave without fixing them
> in GCC-4.0.4 -- many are already fixed in more recent versions.
> I'm now giving attention only to those PRs marked as blocker or
> critical. I've identifi
On 25 Jan 2007 10:29:27 -0600, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
Hi,
There were over 250 PRs open against GCC-4.0.4. Almost all of
them are "benign" in the sense that we can leave without fixing them
in GCC-4.0.4 -- many are already fixed in more recent versions.
I'm now giving att
Hi,
There were over 250 PRs open against GCC-4.0.4. Almost all of
them are "benign" in the sense that we can leave without fixing them
in GCC-4.0.4 -- many are already fixed in more recent versions.
I'm now giving attention only to those PRs marked as blocker or
critical. I've identified thre
Mark Mitchell wrote on 01/25/07 00:09:
First, I haven't had as much time to put in as RM lately as in past, so
I haven't been nagging people as much.
>
Sure, but this is a trend that started with 3.1 and it's gotten
progressively worse. Granted, we are now dealing with a much bigger
project
Dave Korn wrote:
You mean we should invoke the as-if rule in conjunction with the nasal
demons tradition and /actually/ erase the user's hard-drive at compile time if
they write a signed overflow? ;)
Well I already showed a case where assumptions of undefinedness could
lead to such a r
On 24 January 2007 12:51, Richard Kenner wrote:
>> Your conclusion may well be correct. The question for this group is:
>> what's the best that GCC can do to serve the community/society?
>
> Do all it can to discourage people from writing safety- or
> security-critical code in a language they do
On 1/25/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 1/25/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > >Gcc 4.2 has a serious FP performace issue:
> > >
> > >http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html
> > >
> > >on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it
> > >wi
On 1/25/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
> >Gcc 4.2 has a serious FP performace issue:
> >
> >http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html
> >
> >on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it
> >will be addressed.
>
> As always, the best way to ensure that it is a
On Thu, Jan 25, 2007 at 09:57:45AM -0500, Robert Dewar wrote:
> H. J. Lu wrote:
>
> >Gcc 4.2 has a serious FP performace issue:
> >
> >http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html
> >
> >on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it
> >will be addressed.
>
> As always, t
H. J. Lu wrote:
Gcc 4.2 has a serious FP performace issue:
http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html
on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it
will be addressed.
As always, the best way to ensure that it is addressed if it is
important to you is to address it
On Thu, Jan 25, 2007 at 11:18:34AM +0100, François-Xavier Coudert wrote:
> [sorry for breaking the thread; stupid gmail doesn't want to add
> custom References headers]
>
> >It may be that not too many people pick up 4.2.0. But, if 4.3 isn't
> >looking very stable, there will be a point when peop
Richard Kenner wrote:
> I agree with all the arguments about legacy code, but I'm much less
> tolerant of such arguments for NEW code.
Thanks for clarification. I think legacy code is the big problem here
anyways.
Andreas
Richard Kenner wrote:
You're misrepresenting the argument here. This is not just about newly
written software, but also about software that already has been written.
There are multiple arguments here. That comment of mine was addressing the
claim that somebody (I think you) made that stated t
Steven Bosscher wrote:
>> "It's not my fault if people write buggy software" is a lame excuse
>> for sloppy engineering on the part of gcc.
> So basically you're saying gcc developers should compensate for other
> people's sloppy engineering? ;-)
This might be a little exaggerated, but there's ce
Steven Bosscher wrote:
On 1/25/07, Andreas Bogk <[EMAIL PROTECTED]> wrote:
"It's not my fault if
people write buggy software" is a lame excuse for sloppy engineering on
the part of gcc.
So basically you're saying gcc developers should compensate for other
people's sloppy engineering? ;-)
Ye
> You're misrepresenting the argument here. This is not just about newly
> written software, but also about software that already has been written.
There are multiple arguments here. That comment of mine was addressing the
claim that somebody (I think you) made that stated that it was too much t
On 1/25/07, Andreas Bogk <[EMAIL PROTECTED]> wrote:
"It's not my fault if
people write buggy software" is a lame excuse for sloppy engineering on
the part of gcc.
So basically you're saying gcc developers should compensate for other
people's sloppy engineering? ;-)
Gr.
Steven
Richard Kenner wrote:
> I was addressing the claim that we allegedly have people writing security-
> and/or safety-critical software who don't understand the semantics of that
> language as they relate to safety and security (namely, what overflows do).
> That's a serious problem. Of course, there
On Thu, Jan 25, 2007 at 10:29:29AM +0100, Paolo Bonzini wrote:
>
> >>A given program is written in one or the other of these two dialects.
> >>The program stands a chance to work on most any machine if it is
> >>compiled with the proper dialect. It is unlikely to work at all if
> >>compiled with t
[sorry for breaking the thread; stupid gmail doesn't want to add
custom References headers]
It may be that not too many people pick up 4.2.0. But, if 4.3 isn't
looking very stable, there will be a point when people decide that 4.2.0
is looking very attractive. The worst outcome of trying to do
A given program is written in one or the other of these two dialects.
The program stands a chance to work on most any machine if it is
compiled with the proper dialect. It is unlikely to work at all if
compiled with the wrong dialect.
It depends on the program, and whether or not chars in the
53 matches
Mail list logo
