This is the beta release of binutils 2.16.91.0.7 for Linux, which is
based on binutils 2006 0317 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
> Joe Buck writes:
Ben> Please specify exactly what you want, and who at the FSF I talk to.
Joe> If you have messages giving past discussions of the issue, all the better.
If you have a message from the FSF approving the current
situation, it would be extremely helpful if you either
On Fri, 17 Mar 2006, Steve Ellcey wrote:
> So when we finally do move to a newer libtool we will move to the
> unreleased libtool main line? I guess I was assuming we would move to a
Yes, unless we decide to audit local changes (since libtool 2.0 branched)
for those not on libtool 2.0 branch an
On 3/18/06, Jie Zhang <[EMAIL PROTECTED]> wrote:
> Jie Zhang wrote:
> > Hi,
> >
> > In gcc.c-torture/execute/builtins/lib/chk.c, vsnprintf () is defined
> > using vsprintf (). While vsnprintf () in uClibc is defined using
> ^ Sorry, should be vsprintf
> > vsnprin
This is an incomplete report; I'm very busy at the moment, so it will
not be until next week that I can take stock more completely.
However, I want to address the fact that Stage 2 is scheduled to end
tomorrow.
Because I have failed to warn people, I will extend that date for a
week: until March
> Apart from the autoconf issues, while it's GCC policy that all changes to
> the local libtool fork must have equivalents in libtool CVS first, that
> means libtool CVS mainline - not 1.5 or 2.0 branches. If we move to one
> of those release branches, we need to check a lot of local changes to
Ross Ridge wrote:
> Richard Guenther wrote:
>> /*
>> *
>> * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
>> *
>> * Developed at SunPro, a Sun Microsystems, Inc. business.
>> * Permission to use, copy, modify, and distrib
On Fri, 17 Mar 2006, Steve Ellcey wrote:
> I could fix this on the 1.4 branch but I am guessing that libtool
> doesn't really want 1.4 fixes anymore and the problem is already handled
> on the 1.5 branch so I was wondering if there are plans to move GCC to
> a 1.5 libtool.
Apart from the autoconf
On Mar 17, 2006, at 6:25 PM, Steve Ellcey wrote:
Or is the problem over in binutils and with combined/merged source
trees?
Combined source tree.
Plus this was just discussed this week in fact:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00880.html
-- Pinski
On Fri, Mar 17, 2006 at 05:09:17PM -0600, Benjamin Kosnik wrote:
>
> > As previously stated, if there is contrary information from FSF lawyers,
> > then please gather it and present it to the FSF.
>
> Please specify exactly what you want, and who at the FSF I talk to.
I am not Mark, but I sugges
Benjamin Kosnik wrote:
>> As previously stated, if there is contrary information from FSF lawyers,
>> then please gather it and present it to the FSF.
>
> Please specify exactly what you want, and who at the FSF I talk to.
I don't want anything in particular. I can assure you that my idea of a
g
> On Fri, Mar 17, 2006 at 02:59:26PM -0800, Steve Ellcey wrote:
> >
> > I was wondering if there are any plans to move the libtool that is in
> > the GCC tree to 1.5? The current libtool in GCC appears to be based on
> > the 1.4 version and the real libtool project is currently shipping
> > libto
Richard Guenther wrote:
> /*
> *
> * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
> *
> * Developed at SunPro, a Sun Microsystems, Inc. business.
> * Permission to use, copy, modify, and distribute this
> * software is
> As previously stated, if there is contrary information from FSF lawyers,
> then please gather it and present it to the FSF.
Please specify exactly what you want, and who at the FSF I talk to.
Please do so on-list.
-benjamin
On Fri, Mar 17, 2006 at 03:05:17PM -0800, Mark Mitchell wrote:
> Benjamin Kosnik wrote:
> >>> The STL files in libstdc++-v3 need to be clearly marked as not part of
> >>> GCC. Benjamin, will you please take care of that, by modifying the
> >>> libstdc++-v3/README to indicate that the files origina
Mark Mitchell wrote:
> Benjamin Kosnik wrote:
The STL files in libstdc++-v3 need to be clearly marked as not part of
GCC. Benjamin, will you please take care of that, by modifying the
libstdc++-v3/README to indicate that the files originally from HP are
not part of GCC, and spe
Benjamin Kosnik wrote:
>>> The STL files in libstdc++-v3 need to be clearly marked as not part of
>>> GCC. Benjamin, will you please take care of that, by modifying the
>>> libstdc++-v3/README to indicate that the files originally from HP are
>>> not part of GCC, and specifically list those files?
On Fri, Mar 17, 2006 at 02:59:26PM -0800, Steve Ellcey wrote:
>
> I was wondering if there are any plans to move the libtool that is in
> the GCC tree to 1.5? The current libtool in GCC appears to be based on
> the 1.4 version and the real libtool project is currently shipping
> libtool 1.5.22.
I was wondering if there are any plans to move the libtool that is in
the GCC tree to 1.5? The current libtool in GCC appears to be based on
the 1.4 version and the real libtool project is currently shipping
libtool 1.5.22.
The reason I am interested in this is that I have some bugs that I
belie
> > The STL files in libstdc++-v3 need to be clearly marked as not part of
> > GCC. Benjamin, will you please take care of that, by modifying the
> > libstdc++-v3/README to indicate that the files originally from HP are
> > not part of GCC, and specifically list those files?
Huh? What are you
Snapshot gcc-4.1-20060317 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060317/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Richard Guenther wrote:
> I'll try my best. And I take it as granted that I can turn to RMS in the case
> we only get the usual reactions like
> http://sourceware.org/ml/libc-alpha/2005-07/msg8.html
Yes, I think RMS would like FSF maintainers to behave civilly. He did
explicitly indicate in
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Richard Guenther wrote:
|
| > Remembering the patches from Joseph these were from a different part
| > of GLIBC than I imported. I imported parts of sysdeps/ieee754/flt-32 and
| > dbl-64 which contain C implementations of C99 math intrinsics such as
|
On 17 Mar 2006 23:27:35 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
> | Gabriel Dos Reis wrote:
> |
> | > I am confused. My interest in libgcc-math is that it helps solve
> | > thorny issues with libstdc++-v3 and my expectation is that we can ma
On Wed, Mar 15, 2006 at 08:10:41PM -0800, Alexey Starovoytov wrote:
> 1st choice (the best):
> - change the default for all sparc platforms
NetBSD/sparc still supports sun4c, so default cannot be changed there.
--
Aaron J. Grier | Frye Electronics, Tigard, OR | [EMAIL PROTECTED]
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| > I am confused. My interest in libgcc-math is that it helps solve
| > thorny issues with libstdc++-v3 and my expectation is that we can make
| > modification to libgcc-math so that we can't advantage of it. Now, I
| > unde
On 3/17/06, Mike Stump <[EMAIL PROTECTED]> wrote:
> On Mar 17, 2006, at 2:07 PM, Mark Mitchell wrote:
> > So, I think you should remove the dbl-64 code until this is
> > resolved, or at least prevent it
> > from being compiled by removing whatever Makefile bits compile it
>
> :-( At the outside, I
On 3/17/06, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> > Remembering the patches from Joseph these were from a different part
> > of GLIBC than I imported. I imported parts of sysdeps/ieee754/flt-32 and
> > dbl-64 which contain C implementations of C99 math intrinsics s
On Mar 17, 2006, at 2:07 PM, Mark Mitchell wrote:
So, I think you should remove the dbl-64 code until this is
resolved, or at least prevent it
from being compiled by removing whatever Makefile bits compile it
:-( At the outside, I'd say that in 7 days it should not be in
mainline nor any r
Richard Guenther wrote:
> Remembering the patches from Joseph these were from a different part
> of GLIBC than I imported. I imported parts of sysdeps/ieee754/flt-32 and
> dbl-64 which contain C implementations of C99 math intrinsics such as
> sin and cos. The flt-32 parts are public domain as i
Joe Buck wrote:
> On Fri, Mar 17, 2006 at 01:23:36PM -0800, Mark Mitchell wrote:
>> Richard Guenther wrote:
>>> Do I understand this correctly that the upstream GLIBC versions of the
>>> files will get their license changed, or will this happen only in the GCC
>>> copy?
>> Only in the GCC copy.
>
Richard Guenther wrote:
> I understand it in the way that we should modify the imported parts
> upstream (or not), while we can for sure add glues and wrappers or
> other thinks to libgcc-math.
Yes, you can add glue/wrappers.
> So this discussion only affects flt-32
> and dbl-64 directories. I
Gabriel Dos Reis wrote:
> I am confused. My interest in libgcc-math is that it helps solve
> thorny issues with libstdc++-v3 and my expectation is that we can make
> modification to libgcc-math so that we can't advantage of it. Now, I
> understand that we cannot make modification to libgcc-math
On 17 Mar 2006 22:44:37 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | >> Because RMS has approved the use of GLIBC's software floating-point code
> | >> in GCC's runtime libraries, using GPL + exception, the correct thing for
> | >> J
Mark Mitchell <[EMAIL PROTECTED]> writes:
[...]
| >> Because RMS has approved the use of GLIBC's software floating-point code
| >> in GCC's runtime libraries, using GPL + exception, the correct thing for
| >> Joseph Myers to do with his recent patch is to mark those files as not
| >> part of GCC,
On 3/17/06, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
> > On 3/17/06, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> >> Because RMS has approved the use of GLIBC's software floating-point code
> >> in GCC's runtime libraries, using GPL + exception, the correct thing for
> >> Jo
On Fri, Mar 17, 2006 at 01:23:36PM -0800, Mark Mitchell wrote:
> Richard Guenther wrote:
> > Do I understand this correctly that the upstream GLIBC versions of the
> > files will get their license changed, or will this happen only in the GCC
> > copy?
>
> Only in the GCC copy.
Maybe we should che
Richard Guenther wrote:
> On 3/17/06, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> Richard Guenther, would you please add a README to libgcc-math
>> explaining that it that the GLIBC code is not part of GCC, as per the
>> web page above? Also, please document that all of the GLIBC files are
>
> I
On 3/17/06, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther, would you please add a README to libgcc-math
> explaining that it that the GLIBC code is not part of GCC, as per the
> web page above? Also, please document that all of the GLIBC files are
I will do so.
> not to be changed,
There has recently been extensive discussion on the GCC Steering
Committee list about the manner in which we're handling imports of
source code from other projects.
The FSF's guidelines permit us to import code (assuming it's free
software, of course), but, as specified here:
http://www.gnu.org/p
> Date: Thu, 16 Mar 2006 18:51:59 -0800 (PST)
> From: Alexey Starovoytov <[EMAIL PROTECTED]>
>
> On Thu, 16 Mar 2006, Joel Sherrill wrote:
> It seems everybody agreed that solaris 10+ can be changed to -mcpu=v9 default.
> Great!
> What are the thoughts about Solaris 7,8,9 ?
>
> They don't run on
On Tue, 2006-03-14 at 03:16 +0100, Waldek Hebisch wrote:
> I think that it is easy for back end to make good use of
> TYPE_MIN_VALUE/TYPE_MAX_VALUE. Namely, consider the assignment
>
> x := y + z * w;
>
> where variables y, z and w have values in the interval [0,7] and
> x have values in [0,1000
On Fri, 2006-03-17 at 15:07 +0100, Waldek Hebisch wrote:
> Robert Dewar wrote:
> > Laurent GUERBY wrote:
> > > On Mon, 2006-03-13 at 15:31 -0700, Jeffrey A Law wrote:
> > >> On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote:
> > >>
> > >>> What do you mean by "abuse"? TYPE_MAX_VALUE means ma
Does anyone know a good reason not to allow modes such as V2PDI? The
Blackfin has dual multiply accumulate to 40 bit registers, and of all
the iffy ways to describe that, something involving 2x40 bit vectors
seems the least ugly.
Or does anyone have a better idea about handling 40 bit modes i
On Wed, Mar 15, 2006 at 08:10:41PM -0800, Alexey Starovoytov wrote:
> 2nd:
> - change the default for Solaris 7+ and linux
Why not 2.6+? Because 7+ does 64-bit?
--
albert chin ([EMAIL PROTECTED])
Jie Zhang wrote:
Hi,
In gcc.c-torture/execute/builtins/lib/chk.c, vsnprintf () is defined
using vsprintf (). While vsnprintf () in uClibc is defined using
^ Sorry, should be vsprintf
vsnprintf (). When testing on uClinux with uClibc, pr23484-chk.c
failed beca
Hi,
In gcc.c-torture/execute/builtins/lib/chk.c, vsnprintf () is defined
using vsprintf (). While vsnprintf () in uClibc is defined using
vsnprintf (). When testing on uClinux with uClibc, pr23484-chk.c
failed because these two functions will call each other recursively
and finally overflow the st
Robert Dewar wrote:
> Laurent GUERBY wrote:
> > On Mon, 2006-03-13 at 15:31 -0700, Jeffrey A Law wrote:
> >> On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote:
> >>
> >>> What do you mean by "abuse"? TYPE_MAX_VALUE means maximal value
> >>> allowed by given type.
> >> As long as you're *abso
Hi,
I want to introduce a __int40 data type in my port for 40 bits integers. I
do:
type = make_signed_type(40);
lang_hooks.types.register_builtin_type(type, "__int40");
The result is that __int40 variables are mapped on DImode with all kinds of
shifts and ands to obtain a 40 bits data type.
Alexey Starovoytov <[EMAIL PROTECTED]> writes:
> It seems everybody agreed that solaris 10+ can be changed to -mcpu=v9 default.
Indeed.
> What are the thoughts about Solaris 7,8,9 ?
>
> They don't run on embedded sparcs and the legacy of sun4c, sun4m, sun4d
> systems can now be found mostly on
> It seems everybody agreed that solaris 10+ can be changed to -mcpu=v9
> default. Great!
> What are the thoughts about Solaris 7,8,9 ?
Go ahead, post the patch for Solaris 7+ on gcc-patches@, I'll install it.
--
Eric Botcazou
51 matches
Mail list logo
