Re: changing the SPARC default
> 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
Re: changing the SPARC default
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 ebay alongside 8bit ISA video card. > Really, solaris gcc users of sun4c rarity can always configure gcc with > --with_cpu=v7 or v8. Most of the solaris gcc users are on ultra2 and 3 > and should see immediate benefit of better default. > I guess it's worth to sacrifice the convenience of the default install > for sun4c users, so the rest solaris gcc users can have better performance. Agreed for sun4c, but judging from the discussions on comp.unix.solaris and opensolaris.org, it seems there's a considerable user base with sun4m systems that (have to) stay at Solaris 8 and 9, so for their benefit one could think about going to an -mcpu=v8 default on Solaris 7-9. Rainer -- - Rainer Orth, Faculty of Technology, Bielefeld University
40 bit integer type
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. Is there a way to avoid this? I want to allocate these __int40 data to dedicated 40 bits registers. I tried to add some peepholes to remove the redundant shifts and ands but that does not help in all cases. It is also not a nice solution for this problem. So does anyone know a better solution? I also tried to use the partial DI mode type but that did not work well. Jan
Re: Ada subtypes and base types
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 *absolutely* clear that a variable with a > >> restricted range can never hold a value outside that the > >> restricted range in a conforming program, then I'll back off > >> the "abuse" label and merely call it pointless :-) > > > > Variables in a non erroneous Ada program all have their value between > > their type bounds from the optimizer perspective (the special 'valid > > case put aside). > > Not quite right. If you have an uninitialized variable, the value is > invalid and may be out of bounds, but this is a bounded error situation, > not an erroneous program. So the possible effects are definitely NOT > unbounded, and the use of such values cannot turn a program erroneous. > (that's an Ada 95 change, this used to be erroneous in Ada 83). > What about initializing _all_ variables? If we allow out of range values at one place than we loose usefull invariant. I see no way that a frontend could allow out of range values and simultaneously use TYPE_MAX_VALUE for optimization. Also, out of range values would make TYPE_MAX_VALUE of little use to backend. I see two drawbacks if we initialize all variables: 1) bigger program and lower runtime efficienecy 2) we loose diagnostics about uninitialized variables I would guess that cost of extra initializiations will be small, because backend will remove unused variables and obviously redundant initializations so only tricky cases will remain. Also, extra initializiatin is likely to be cheaper then extra tests which are needed otherwise. I am more concerned about loss of diagnostics. That could be resolved if forntend could mark generated initializations so that backend will generate code to initialize variable, but also issue diagnostics if such initializatin can not be removed (yes, I understand that it is conceptually a small change but it would probably require largish change to backend code). -- Waldek Hebisch [EMAIL PROTECTED]
Object size checking builtin test case and uClibc
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 stack. How can this problem be fixed, In the test case or in uClibc? Thanks, Jie
Re: Object size checking builtin test case and uClibc
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 because these two functions will call each other recursively and finally overflow the stack. How can this problem be fixed, In the test case or in uClibc? Jie
Re: changing the SPARC default
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])
2x40 bit vector modes...
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 in general than using PDImode? Bernd
Re: Ada subtypes and base types
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 maximal value > > >>> allowed by given type. > > >> As long as you're *absolutely* clear that a variable with a > > >> restricted range can never hold a value outside that the > > >> restricted range in a conforming program, then I'll back off > > >> the "abuse" label and merely call it pointless :-) > > > > > > Variables in a non erroneous Ada program all have their value between > > > their type bounds from the optimizer perspective (the special 'valid > > > case put aside). > > > > Not quite right. If you have an uninitialized variable, the value is > > invalid and may be out of bounds, but this is a bounded error situation, > > not an erroneous program. So the possible effects are definitely NOT > > unbounded, and the use of such values cannot turn a program erroneous. > > (that's an Ada 95 change, this used to be erroneous in Ada 83). > > > > What about initializing _all_ variables? In Ada this is the effect of the configuration pragma Normalize_Scalars << H.1 Pragma Normalize_Scalars 1 This pragma ensures that an otherwise uninitialized scalar object is set to a predictable value, but out of range if possible. 1.a Discussion: The goal of the pragma is to reduce the impact of a bounded error that results from a reference to an uninitialized scalar object, by having such a reference violate a range check and thus raise Constraint_Error. Syntax 2 The form of a pragma Normalize_Scalars is as follows: 3 pragma Normalize_Scalars; >> Laurent
Re: Ada subtypes and base types
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]. Pascal converts the above to the > following C like code: > > int tmp = (int) y + (int) z * (int) w; > x = (tmp < 0 || tmp > 1000)? (Range_Check_Error (), 0) : tmp; > > I expect VRP to deduce that tmp will have values in [0..56] and > eliminate range check. Also, it should be clear that in the > assigment above artithmetic can be done using any convenient > precision. VRP can certainly do this -- I added the ability to see through more typecasts a while back. In general, I've tried to improve the ability of our optimizers to eliminate or at least "see through" some typecasts. However, that capability is often very limited and the ability to see through type casts is not pervasive in the optimization pipeline. What I seriously doubt is that you have enough cases of the nature you posted to matter in practice. I would expect that for the vast majority of cases that the source and destination operands are going to have the same ranges. And in that case exposing the tighter min/max data on your ranges does you no good. It just creates a lot of silly nop-casts which waste memory and will tend to inhibit optimizations. > In principle Pascal front end could deduce more precise types (ranges), > but that would create some extra type conversions and a lot > of extra types. Moreover, I assume that VRP can do better job > at tracking ranges then Pascal front end. I'm not suggesting the FEs deduce more types and track ranges; that would be rather absurd. What I'm saying is that exposing these types outside the FE is most likely costing you both on the compile-time side and on the run-time side. You'd present far cleaner code to the optimizers if you just did *everything* in the object's base type. You'd generate far fewer nodes, saving compile-time and memory and the optimizers will have a much better opportunity to optimize the code. But that's your decision to make -- I think we've all agreed that as long as you don't allow values outside the min/max range to be stored into variables with these types, then it should be safe to continue to do things the way you're doing them. jeff
Re: changing the SPARC default
> 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 embedded sparcs and the legacy of sun4c, sun4m, sun4d > systems can now be found mostly on ebay alongside 8bit ISA video card. A datapoint: Solaris 7 runs on sun4c systems. In fact, it is the *LAST* Solaris released with support for the sun4c architecture. > Really, solaris gcc users of sun4c rarity can always configure gcc with > --with_cpu=v7 or v8. Most of the solaris gcc users are on ultra2 and 3 > and should see immediate benefit of better default. > I guess it's worth to sacrifice the convenience of the default install > for sun4c users, so the rest solaris gcc users can have better performance. > > Alex. David
FSF Policy re. inclusion of source code from other projects in GCC
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/prep/maintain/html_node/External-Libraries.html#External-Libraries we're discouraged from doing so gratuitously. To quote RMS: > If someone signs an assignment for GCC, and has made contributions > to package Z which is not part of GCC, he has no reason to believe that > his assignment covers his changes to Z. > > If subsequently we include Z in GCC, that can hardly count as a > justification to claim, retroactively, that he had assign his code in > Z to us. There are two different situations that we need to distinguish: imports, where we then make no modifications subsequently, except to import newer versions, and imports where we do make subsequent modifications. The first situation is less problematic than the second, so we want to avoid the second situation if at all possible. Packages imported from an externally maintained source must be mentioned in the "Upstream packages" section of the "GCC Coding Conventions" page. This must say where the code came from, and how it will be maintained. See http://gcc.gnu.org/codingconventions.html#upstream libgcc-math should be mentioned here. A recent example of a mis-handled situation is the inclusion of libgcc-math. This code appears to be based largely on code from GLIBC. It's OK to include it in our repository, but it needs to be documented as not being part of GCC. Before we approve these kinds of changes, we need to be cognizant of the copyright issues. I know that Richard Henderson meant no harm by approving the inclusion of this library, and I don't think most of the maintainers were aware of the implications until now, but we need to avoid making the same mistake in future, and we need to fix this mistake now. 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 not to be changed, except by reimporting from GLIBC. If any of the GLIBC files have been changed from their upstream sources, please submit those changes to the GLIBC maintainers ASAP. 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, but rather as part of GLIBC, and adjust the copyright notice to be GPL + exception. Joseph should also document (in a README or similar) that these files are not to be changed, except by import from upstream GLIBC. RMS says: > The GLIBC developers should accept some conditionals into their > source, so that we do not have two diverging versions. We should all > talk together to make this happen. So, while the criteria they should use is not merely whether or not the changes are good for GLIBC, we should of course respect their position as GLIBC maintainers. The inclusion of fastjar long ago was also probably a mistake, because fastjar is not assigned to the FSF, and because it's a tool for use with GCC, not a part of GCC. It's a logically separate tool, in the same way that the GNU Binary Utilities are separate. The FSF and GCC SC have decided to move fastjar to savannah, and stop including it in future GCC releases, which will clarify this situation. Will someone please volunteer to migrate fastjar out of our repository? 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? RMS has given us permission not to set up a separate repository for the STL files. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: FSF Policy re. inclusion of source code from other projects in GCC
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, except by reimporting from GLIBC. If any of the > GLIBC files have been changed from their upstream sources, please submit > those changes to the GLIBC maintainers ASAP. I will try to get the (minor) changes accepted upstream. > 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, but rather as part of GLIBC, and adjust the copyright > notice to be GPL + exception. Joseph should also document (in a README > or similar) that these files are not to be changed, except by import > from upstream GLIBC. 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? Thanks, Richard.
Re: FSF Policy re. inclusion of source code from other projects in GCC
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 will do so. Thank you. >> 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, but rather as part of GLIBC, and adjust the copyright >> notice to be GPL + exception. Joseph should also document (in a README >> or similar) that these files are not to be changed, except by import >> from upstream GLIBC. > > 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. I don't understand enough about libgcc-math to know what should happen there; I don't even know what bits of GLIBC you used. RMS has given explicit permission to use GPL + exception for the software floating-point emulation code, but not for any other part of GLIBC. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: FSF Policy re. inclusion of source code from other projects in GCC
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 check that question with RMS. After all, RMS is the one who doesn't want us to fork imported code; aren't we talking about forking at least the license? There would be two distinct copies of certain files, differing only in the license text. > I don't understand enough about libgcc-math to know what should happen > there; I don't even know what bits of GLIBC you used. RMS has given > explicit permission to use GPL + exception for the software > floating-point emulation code, but not for any other part of GLIBC. Maybe the answer, then, should be that only the files involved in floating-point emulation should get the new license. But I guess we need to ask what the FSF wants to do here.
Re: FSF Policy re. inclusion of source code from other projects in 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 > >> Joseph Myers to do with his recent patch is to mark those files as not > >> part of GCC, but rather as part of GLIBC, and adjust the copyright > >> notice to be GPL + exception. Joseph should also document (in a README > >> or similar) that these files are not to be changed, except by import > >> from upstream GLIBC. > > > > 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. > > I don't understand enough about libgcc-math to know what should happen > there; I don't even know what bits of GLIBC you used. RMS has given > explicit permission to use GPL + exception for the software > floating-point emulation code, but not for any other part of GLIBC. 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 in /* * * 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 freely granted, provided that this notice * is preserved. * */ while the dbl-64 parts are LGPL and so subject to the change to GPL + exception. I don't know if these parts of GLIBC are covered by RMS's permission, it is probably advisable to ask. Modifications local to GCC happened to fix issues with the build environment, namely that the glibc files assume they are built in an environment which has glibc available, while GCC needs to build on hosts with other C89 conforming environments. I think these changes are safe to be included upstream and I will try to get them accepted. Thanks, Richard.
Re: FSF Policy re. inclusion of source code from other projects in GCC
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, but rather as part of GLIBC, and adjust the copyright | >> notice to be GPL + exception. Joseph should also document (in a README | >> or similar) that these files are not to be changed, except by import | >> from upstream GLIBC. | > | > 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. | | I don't understand enough about libgcc-math to know what should happen | there; I don't even know what bits of GLIBC you used. RMS has given | explicit permission to use GPL + exception for the software | floating-point emulation code, but not for any other part of GLIBC. 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 without modifying GLIBC? Is that correct. -- Gaby
Re: FSF Policy re. inclusion of source code from other projects in GCC
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 > | >> Joseph Myers to do with his recent patch is to mark those files as not > | >> part of GCC, but rather as part of GLIBC, and adjust the copyright > | >> notice to be GPL + exception. Joseph should also document (in a README > | >> or similar) that these files are not to be changed, except by import > | >> from upstream GLIBC. > | > > | > 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. > | > | I don't understand enough about libgcc-math to know what should happen > | there; I don't even know what bits of GLIBC you used. RMS has given > | explicit permission to use GPL + exception for the software > | floating-point emulation code, but not for any other part of GLIBC. > > 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 without > modifying GLIBC? Is that correct. 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. So this discussion only affects flt-32 and dbl-64 directories. I don't think this will make the libstdc++-v3 issues impossible - maybe a little harder. If there will be a point where a true fork is inevitable, we can politely ask again. Richard.
Re: FSF Policy re. inclusion of source code from other projects in GCC
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 without > modifying GLIBC? Is that correct. Yes, that is correct. It would take additional special dispensation from the FSF to modify the GLIBC code. RMS wants such modifications to be submitted upstream first, to avoid forks. You could ask RMS for that additional permission, if you want. Please do not ask me to interpret or justify all of the rules; I don't understand the issues sufficiently well. I am just passing along the results of a long discussion with RMS on the SC list. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: FSF Policy re. inclusion of source code from other projects in GCC
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 don't think this will make the libstdc++-v3 > issues impossible - maybe a little harder. If there will be a point where > a true fork is inevitable, we can politely ask again. Indeed. However, RMS has indicated the first approach should be to approach the GLIBC folks, and that they should be willing to accomodate reasonable changes, even if those changes aren't directly beneficial to GLIBC itself. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: FSF Policy re. inclusion of source code from other projects in GCC
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. > > Maybe we should check that question with RMS. After all, RMS is the one > who doesn't want us to fork imported code; aren't we talking about forking > at least the license? There would be two distinct copies of certain > files, differing only in the license text. Yes, but they will have to differ anyhow so that they can proclaim that they are not part of GCC. So, I think it is clear what the files should say in the GCC repository. I will ask RMS if the files should change in the GLIBC repository as well, but it doesn't need to affect Joseph's (as of yet unreviewed) patch. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: FSF Policy re. inclusion of source code from other projects in GCC
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 in > > /* > * > * 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 freely granted, provided that this notice > * is preserved. > * > */ > > while the dbl-64 parts are LGPL and so subject to the change to GPL > + exception. I don't know if these parts of GLIBC are covered by RMS's > permission, it is probably advisable to ask. I think that we need to ask RMS specifically about this. Would you please send a message to RMS, and copy the SC list (is that address public? I'm not sure if I'm supposed to give it out, ask me privately if you don't know it) on the mail. Explain the situation, including what code you're importing and why you want an exception. My guess is that it's OK to include the Sun code, since it's in the public domain. My guess is also that, without explicit permission from RMS, you have to leave the LGPL on the dbl-64 code, since it doesn't sound like that is covered by "software floating-point emulation". That means that people who linked with this library would find that the LGPL applies, which is contrary to our general policy that binaries produced by GCC are not subject to GPL/LGPL issues. 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. My experience is that it usually takes some time for RMS to grant a license exception, and that he may not choose to do it. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: FSF Policy re. inclusion of source code from other projects in GCC
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 release branch if permission isn't secured.
Re: FSF Policy re. inclusion of source code from other projects in GCC
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 such as > > sin and cos. The flt-32 parts are public domain as in > > > > /* > > * > > * 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 freely granted, provided that this notice > > * is preserved. > > * > > */ > > > > while the dbl-64 parts are LGPL and so subject to the change to GPL > > + exception. I don't know if these parts of GLIBC are covered by RMS's > > permission, it is probably advisable to ask. > > I think that we need to ask RMS specifically about this. Would you > please send a message to RMS, and copy the SC list (is that address > public? I'm not sure if I'm supposed to give it out, ask me privately > if you don't know it) on the mail. Explain the situation, including > what code you're importing and why you want an exception. > > My guess is that it's OK to include the Sun code, since it's in the > public domain. My guess is also that, without explicit permission from > RMS, you have to leave the LGPL on the dbl-64 code, since it doesn't > sound like that is covered by "software floating-point emulation". That > means that people who linked with this library would find that the LGPL > applies, which is contrary to our general policy that binaries produced > by GCC are not subject to GPL/LGPL issues. 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. My > experience is that it usually takes some time for RMS to grant a license > exception, and that he may not choose to do it. I will do so early next week and send a patch to disable dbl-64 compilation for now. Richard.
Re: FSF Policy re. inclusion of source code from other projects in GCC
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'd say that in 7 days it should not be in > mainline nor any release branch if permission isn't secured. If there is consensus that the source should be (temporarily) removed then that is fine with me, though I'd prefer to just disable the makefile bits to give RMS some more time than 7 days. Also I won't have much time to dedicate to this problem until in two weeks, apart from emergency stuff like requested. Richard.
Re: FSF Policy re. inclusion of source code from other projects in GCC
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 | > understand that we cannot make modification to libgcc-math without | > modifying GLIBC? Is that correct. | | Yes, that is correct. It would take additional special dispensation | from the FSF to modify the GLIBC code. RMS wants such modifications to | be submitted upstream first, to avoid forks. You could ask RMS for that | additional permission, if you want. Thanks for the clarification. | Please do not ask me to interpret or justify all of the rules; I don't | understand the issues sufficiently well. I am just passing along the | results of a long discussion with RMS on the SC list. I understand :-) Did I know this implication, and given past difficulty to communicate with GLIBC people, I'm not sure I did the right thing (e.g. being enthousiastic about libgcc-math). -- Gaby
Re: changing the SPARC default
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]
Re: FSF Policy re. inclusion of source code from other projects in GCC
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 make > | > modification to libgcc-math so that we can't advantage of it. Now, I > | > understand that we cannot make modification to libgcc-math without > | > modifying GLIBC? Is that correct. > | > | Yes, that is correct. It would take additional special dispensation > | from the FSF to modify the GLIBC code. RMS wants such modifications to > | be submitted upstream first, to avoid forks. You could ask RMS for that > | additional permission, if you want. > > Thanks for the clarification. > > | Please do not ask me to interpret or justify all of the rules; I don't > | understand the issues sufficiently well. I am just passing along the > | results of a long discussion with RMS on the SC list. > > I understand :-) > > Did I know this implication, and given past difficulty to communicate > with GLIBC people, I'm not sure I did the right thing (e.g. being > enthousiastic about libgcc-math). 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 (not that I didn't try to avoid creating libgcc-math in the first place...) Richard.
Re: FSF Policy re. inclusion of source code from other projects in GCC
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 | > sin and cos. The flt-32 parts are public domain as in | > | > /* | > * | > * 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 freely granted, provided that this notice | > * is preserved. | > * | > */ | > | > while the dbl-64 parts are LGPL and so subject to the change to GPL | > + exception. I don't know if these parts of GLIBC are covered by RMS's | > permission, it is probably advisable to ask. | | I think that we need to ask RMS specifically about this. Would you | please send a message to RMS, and copy the SC list (is that address | public? I'm not sure if I'm supposed to give it out, ask me privately | if you don't know it) on the mail. Explain the situation, including | what code you're importing and why you want an exception. | | My guess is that it's OK to include the Sun code, since it's in the | public domain. My guess is also that, without explicit permission from | RMS, you have to leave the LGPL on the dbl-64 code, since it doesn't | sound like that is covered by "software floating-point emulation". That | means that people who linked with this library would find that the LGPL | applies, which is contrary to our general policy that binaries produced | by GCC are not subject to GPL/LGPL issues. 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. My | experience is that it usually takes some time for RMS to grant a license | exception, and that he may not choose to do it. That even further clarify the issue for me. I believe, without the change of license, libgcc-math wouold not be as useful (to libstdc++-v3) as I understood it the previous place :-( -- Gaby
Re: FSF Policy re. inclusion of source code from other projects in GCC
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 this case that the GLIBC maintainers should be willing to accommodate reasonable requests, although obviously reasonableness is in the eye of the beholder. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
gcc-4.1-20060317 is now available
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/gcc-4_1-branch revision 112188 You'll find: gcc-4.1-20060317.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20060317.tar.bz2 C front end and core compiler gcc-ada-4.1-20060317.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20060317.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20060317.tar.bz2 C++ front end and runtime gcc-java-4.1-20060317.tar.bz2 Java front end and runtime gcc-objc-4.1-20060317.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20060317.tar.bz2The GCC testsuite Diffs from 4.1-20060310 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: FSF Policy re. inclusion of source code from other projects in GCC
> > 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 smoking dude? Doing this would contradict past legal advice, given from actual lawyers no less, both at the FSF and Red Hat. I believe there has been a simple mistake here, or perhaps a generalization drawn too loosely. The current GNU libstdc+ + STL sources started diverging from the SGI sources (who had taken over maintainer-ship of the HP sources) as of 3.13, seven years ago. Since that time, there has been nothing to merge back to, and those source are unmaintained. This can be considered a permanent fork. All changes since then have been contributed under the GPL and copyright FSF, for which the FSF has assignments on file. -benjamin
GCC & libtool - plans for moving to libtool 1.5?
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 believe are due to the old libtool and would go away if we updated. For the ia64-hp-hpux11.23 target, libtool 1.4 uses ld to build shared libraries whereas libtool 1.5 uses 'gcc -shared' if the compiler is GCC and 'cc -b' if the compiler is HP. This ensures that the shared library has the necessary dependent libraries linked in to it when it is built. 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. Steve Ellcey [EMAIL PROTECTED]
Re: GCC & libtool - plans for moving to libtool 1.5?
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. This is still blocked on the move to a newer autoconf in all subdirectories. Or, on someone figuring out whether we can migrate some subdirectories to a newer libtool without breaking others. -- Daniel Jacobowitz CodeSourcery
Re: FSF Policy re. inclusion of source code from other projects in GCC
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? > > Huh? What are you smoking dude? Nothing; I don't smoke. As already stated, all I am doing is passing along information from the FSF. RMS personally approved the message that I sent, including the discussion of the STL files. As previously stated, if there is contrary information from FSF lawyers, then please gather it and present it to the FSF. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: FSF Policy re. inclusion of source code from other projects in GCC
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 specifically list those files? >> Huh? What are you smoking dude? > > Nothing; I don't smoke. To be clear: in the case of the STL files, I specifically noted that we do not have to move them out of our repository. However, it is also clear that RMS believes (now) that these files should not have been treated as they were. I don't have permission to quote his messages on the topic, so I don't think I should, but I think it's clear that your understanding of the situation does not match his. So, I think you need to find the evidence of the permission that was obtained, so that we can resolve the situation. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: FSF Policy re. inclusion of source code from other projects in GCC
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 originally from HP are > >>> not part of GCC, and specifically list those files? > > > > Huh? What are you smoking dude? > > Nothing; I don't smoke. > > As already stated, all I am doing is passing along information from the > FSF. RMS personally approved the message that I sent, including the > discussion of the STL files. > > As previously stated, if there is contrary information from FSF lawyers, > then please gather it and present it to the FSF. Please, no one panic yet. I recall the facts as Ben stated them, but I can't lay hands on the old emails. I think that we can convince RMS that the STL usage in libstdc++ isn't a problem, and it's best to do that offline.
Re: FSF Policy re. inclusion of source code from other projects in GCC
> 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
Re: FSF Policy re. inclusion of source code from other projects in GCC
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 freely granted, provided that this notice > * is preserved. > * > */ Mark Mitchell wrote: >My guess is that it's OK to include the Sun code, since it's in the >public domain. This may just be nit-picking, but the above notice doesn't put the code into the public domain. Sun still owns the copyright of the software. Ross Ridge
Re: GCC & libtool - plans for moving to libtool 1.5?
> 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. > > This is still blocked on the move to a newer autoconf in all > subdirectories. Or, on someone figuring out whether we can > migrate some subdirectories to a newer libtool without breaking > others. > > -- > Daniel Jacobowitz > CodeSourcery Do you know what subdirectories those are? The only configure script I can find in the GCC source tree that isn't generated by 2.59 is the top level one. Or is the problem over in binutils and with combined/merged source trees? Steve Ellcey [EMAIL PROTECTED]
Re: FSF Policy re. inclusion of source code from other projects in GCC
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 good time is not to spend hours drafting and redrafting emails about license issues. I volunteered to do that because RMS asked someone on the SC to do it, and nobody else volunteered. You will have to ask the FSF what they need to confirm the situation as you understand it. I would imagine that the ideal piece of evidence would be email from the FSF saying "It's OK to consider the STL files as part of GCC, you can modify them as you see fit, and it's OK to put FSF copyright notices on them." The right person to contact is RMS directly: [EMAIL PROTECTED] He generally responds to email within forty-eight hours, as the outside. I would suggest copying the GCC SC, since as the SC is the official maintainer of GCC, the SC needs to understand the outcome. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: FSF Policy re. inclusion of source code from other projects in GCC
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 suggest that you talk to RMS. If you have messages giving past discussions of the issue, all the better. I suggested off-list so we don't waste time on-list with a flame war when we can probably get the problem solved. I would prefer to have the current situation blessed, so we don't have to do anything.
Re: GCC & libtool - plans for moving to libtool 1.5?
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
Re: GCC & libtool - plans for moving to libtool 1.5?
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 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 see whether they have equivalents on the release branch, and backport the equivalents from mainline libtool if not. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: FSF Policy re. inclusion of source code from other projects in GCC
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 distribute this >> * software is freely granted, provided that this notice >> * is preserved. >> * >> */ > > Mark Mitchell wrote: >> My guess is that it's OK to include the Sun code, since it's in the >> public domain. > > This may just be nit-picking, but the above notice doesn't put the code > into the public domain. Sun still owns the copyright of the software. True! I believe I relied on Richard's words, but you're definitely correct. I still believe use of this code should be non-problematic, though. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC & libtool - plans for moving to libtool 1.5?
> 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 see > whether they have equivalents on the release branch, and backport the > equivalents from mainline libtool if not. > > -- > Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ > [EMAIL PROTECTED] (personal mail) > [EMAIL PROTECTED] (CodeSourcery mail) > [EMAIL PROTECTED] (Bugzilla assignments and CCs) 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 stable released libtool, but that was just an assumption on my part. Steve Ellcey [EMAIL PROTECTED]
GCC 4.2 Status Report (2006-03-17)
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 25th. Even after Stage 2 ends, patches submitted before the end of Stage 2 can be applied in Stage 3, until we decide otherwise. So, wrap up those last contributions, submit them, review other people's patches, and then prepare to start fixing bugs for 4.2. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Object size checking builtin test case and uClibc
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 > > vsnprintf (). When testing on uClinux with uClibc, pr23484-chk.c > > failed because these two functions will call each other recursively > > and finally overflow the stack. How can this problem be fixed, In the > > test case or in uClibc? > > I removed snprintf () and vsnprintf () from gcc.c-torture/execute/builtins/lib/chk.c. All the test cases in builtins.exp pass for bfin port gcc 4.1 on uClinux. Can we remove these two non-_chk versions from chk.c and use the ones from C libraries? Thanks, Jie
Re: GCC & libtool - plans for moving to libtool 1.5?
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 and use 2.0 branch with some backported patches. I don't think using 1.5 branch will be a plausible option. I don't know what upstream libtool policy is on what patches can go on 2.0 branch. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: FSF Policy re. inclusion of source code from other projects in GCC
> 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 included that in the "Upstream Packages" stanza of the Coding Conventions page, provided a link to the public email message, or summarized the agreement and provided a point of contact who has the original message. The GCC SC needs to be able to find out the disposition of pieces of GCC to answer questions from RMS, the FSF, and others. The best way to avoid this type of confusion in the future is to keep the information in Upstream Packages up to date so that the GCC SC and everyone can answer these types of questions definitively. We need the cooperation of GCC maintainers and reviewers to ensure that this all runs smoothly. Thanks, David
The Linux binutils 2.16.91.0.7 is released
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 monitor which works with both old and new x86_64 assemblers. They should generate the same opcode. The new i386/x86_64 assemblers no longer accept instructions for moving between a segment register and a 32bit memory location, i.e., movl (%eax),%ds movl %ds,(%eax) To generate instructions for moving between a segment register and a 16bit memory location without the 16bit operand size prefix, 0x66, mov (%eax),%ds mov %ds,(%eax) should be used. It will work with both new and old assemblers. The assembler starting from 2.16.90.0.1 will also support movw (%eax),%ds movw %ds,(%eax) without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are available at http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch The ia64 assembler is now defaulted to tune for Itanium 2 processors. To build a kernel for Itanium 1 processors, you will need to add ifeq ($(CONFIG_ITANIUM),y) CFLAGS += -Wa,-mtune=itanium1 AFLAGS += -Wa,-mtune=itanium1 endif to arch/ia64/Makefile in your kernel source tree. Please report any bugs related to binutils 2.16.91.0.7 to [EMAIL PROTECTED] and http://www.sourceware.org/bugzilla/ If you don't use # rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2 to compile the Linux binutils, please read patches/README in source tree to apply Linux patches if there are any. Changes from binutils 2.16.91.0.6: 1. Update from binutils 2006 0317. 2. Support Intel Merom New Instructions in assembler/disassembler. 3. Support Intel new instructions in Montecito. 4. Fix linker "--as-needed" (PR 2434). 5. Fix linker "-s" regression (PR 2462). 6. Fix REP prefix for string instructions in x86 disassembler (PR 2428). 7. Fix the weak undefined symbols in PIE (PR 2218). 8. Fix 2 DWARF reader bugs (PRs 2443, 2338). 9. Improve ELF linker error message (PR 2322). 10. Avoid abort with dynamic symbols in >64K sections (PR 2411). 11. Handle mismatched symbol types for executables (PR 2404). 12. Avoid a linker linkonce regression (PR 2342). Changes from binutils 2.16.91.0.5: 1. Update from binutils 2006 0212. 2. Correct Linux linker search order for DT_NEEDED entries (PR 2290). 3. Fix the x86-64 disassembler for control/debug register moves. 4. Properly handle ELF strip/objcopy with unmodified program header (PR 2258). 5. Improve ELF linker error handling when there are not enough room for program headers (PR 2322). 6. Properly handle weak undefined symbols in PIE (PR 2218). 7. Support new i386/x86-64 TLS relocations. 8. Fix addr2line for linux kernel (PR 2096). 9. Fix an assembler memory leak with --statistics. 10. Avoid an ia64 assembler regression (PR 2117). Changes from binutils 2.16.91.0.4: 1. Update from binutils 2005 1219. 2. Fix a MIPS linker regression (PR 1932). 3. Fix an objcopy bug for ia64 (PR 1991). 4. Fix a linker crash on bad input (PR 2008). 5. Fix 64bit monitor and mwait (PR 1874). Changes from binutils 2.16.91.0.3: 1. Update from binutils 2005 . 2. Fix ELF orphan section handling (PR 1467) 3. Fix ELF section attribute handleing (PR 1487). 4. Fix IA64 unwind info dump for relocatable files. (PR 1436). 5. Add DWARF info dump to objdump. 6. Fix SHF_LINK_ORDER handling (PR 1321). 7. Don't allow "ld --just-symbols" on DSO (PR 1263). 8. Fix a "ld -u" crash on TLS symbol (PR 1301). 9. Fix an IA64 linker crash (PR 1247). 10. Fix a MIPS linker bug (PR 1150). 11. Fix a M68K linker bug (PR 1775). 12. Fix an ELF symbol versioning linker bug (PR 1540). 13. Improve linker error handling (PR 1208). 14. Add new SPARC processors to SunOS for objcopy (PR 1472). 15. Add "@file" to read options from a file. 16. Add assembler weakref support. Changes from binutils 2.16.91.0.2: 1. Update from binutils 2005 0821. 2. Support x86-64 medium model. 3. Fix "objdump -S --adjust-vma=xxx" (PR 1179). 4. Reduce R_IA64_NONE relocations from R_IA64_LDXMOV relaxation. 5. Fix x86 linker regression for dosemu. 6. Add "readelf -t/--section-details" to display section details. 7. Fix "as -al=file" regression (PR 1118). Changes from binutils 2.16.91.0.1: 1. Update from binutils 2005 0720. 2. Add Intel VMX support. 3. Add AMD SVME support. 4. Add x86-64 new relocations for medium model. 5. Fix a PIE regression (PR 975). 6. Fix an x86_64 signed 32bit displacement regression. 7. Fix PPC PLT (PR 1004). 8. Improve empty section removal. Changes from binutils 2.16.90.0.3: 1. Update from binutils 2005 0622. 2. Fix a linker versioning bug exposed by gcc 4 (PR 1022/1023/1025). 3. Optimize ia64 br->brl relaxation (PR 834). 4. Improve linker empty section removal. 5. Fix DWARF 2 l
