Re: GCC version bikeshedding
> What do you propose that we do? Probably just jump to 5.0 (or 5.1) without the subsequent acceleration. > Step 1: We agree that the current major revision number conveys no > information, and therefore we will change the major revision number > with every release. (I understand that you do not agree with this.) Yes. > Step 2: Assuming we agree about step 1, what should the next version > number be? Well, the current version is 4.9. Therefore, the next > version should be 5.0. That seems entirely natural to me. Having the > next release be 10.0 would make no sense to anybody who is not an > active GCC developer. I also disagree with the last assertion (for example Sun did that for Solaris) but that's probably too much bikeshedding at this point. -- Eric Botcazou
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 09:25:48AM +0200, Eric Botcazou wrote: > > What do you propose that we do? > > Probably just jump to 5.0 (or 5.1) without the subsequent acceleration. That was my preference too. Jakub
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 09:42:23AM +0200, Jakub Jelinek wrote: > On Wed, Aug 06, 2014 at 09:25:48AM +0200, Eric Botcazou wrote: > > > What do you propose that we do? > > > > Probably just jump to 5.0 (or 5.1) without the subsequent acceleration. > > That was my preference too. FWIW, me too. This way we'll get in a few years to 10.0 that was also suggested. So please, can we finally settle on something? :) Marek
Re: GCC version bikeshedding
On Wed, Aug 6, 2014 at 9:42 AM, Jakub Jelinek wrote: > On Wed, Aug 06, 2014 at 09:25:48AM +0200, Eric Botcazou wrote: >> > What do you propose that we do? >> >> Probably just jump to 5.0 (or 5.1) without the subsequent acceleration. > > That was my preference too. What singles out 5.0 to warrant an increase in the major number? If we don't change then please stay at 4.10, 4.11, 4.12, etc. Richard. > Jakub
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 10:44:11AM +0200, Richard Biener wrote: > On Wed, Aug 6, 2014 at 9:42 AM, Jakub Jelinek wrote: > > On Wed, Aug 06, 2014 at 09:25:48AM +0200, Eric Botcazou wrote: > >> > What do you propose that we do? > >> > >> Probably just jump to 5.0 (or 5.1) without the subsequent acceleration. > > > > That was my preference too. > > What singles out 5.0 to warrant an increase in the major number? > > If we don't change then please stay at 4.10, 4.11, 4.12, etc. - libstdc++ ABI changes (it is a significant user visible change, if you rebuild everything, no extra effort is needed, but otherwise if you want some C++ code built with older compilers work together with code built with newer compilers, it might require source code changes (the abi_tag attribute additions where needed and warning suggest to put those at), at least that is my current understanding of the plans - likely libgfortran ABI changes (different array descriptors) Jakub
Re: GCC version bikeshedding
On Wed, Aug 6, 2014 at 10:48 AM, Jakub Jelinek wrote: > On Wed, Aug 06, 2014 at 10:44:11AM +0200, Richard Biener wrote: >> On Wed, Aug 6, 2014 at 9:42 AM, Jakub Jelinek wrote: >> > On Wed, Aug 06, 2014 at 09:25:48AM +0200, Eric Botcazou wrote: >> >> > What do you propose that we do? >> >> >> >> Probably just jump to 5.0 (or 5.1) without the subsequent acceleration. >> > >> > That was my preference too. >> >> What singles out 5.0 to warrant an increase in the major number? >> >> If we don't change then please stay at 4.10, 4.11, 4.12, etc. > > - libstdc++ ABI changes (it is a significant user visible change, > if you rebuild everything, no extra effort is needed, but otherwise > if you want some C++ code built with older compilers work together > with code built with newer compilers, it might require source code > changes (the abi_tag attribute additions where needed and warning > suggest to put those at), at least that is my current understanding > of the plans But that's only with -std=c++11? Which had no compatibility guarantees before? > - likely libgfortran ABI changes (different array descriptors) Let's wait and see ... We'll find a good reason to bump the major with every release. Like for 4.9 LTO defaults to slim-objects, or C++ rejecting even more invalid code, or libstdc++ header re-orgs, or defaulting to dwarf4+ (or even support for it), or VTA, or ... Where do we set the barrier? GCC isn't a C++ (or Fortran) compiler only. So if we change to 5.1 (please not .0) then let's switch the default optimization level to -O2! _That's_ a user-visible change across the board. Richard. > Jakub
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote: > > - libstdc++ ABI changes (it is a significant user visible change, > > if you rebuild everything, no extra effort is needed, but otherwise > > if you want some C++ code built with older compilers work together > > with code built with newer compilers, it might require source code > > changes (the abi_tag attribute additions where needed and warning > > suggest to put those at), at least that is my current understanding > > of the plans > > But that's only with -std=c++11? Which had no compatibility > guarantees before? No, AFAIK it is also -std=c++98. At least my understanding was that std::list and std::string are going to change ABI (and get new abi_tag) in all C++ modes. Jonathan/Jason/Paolo, is that right? Jakub
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote: > On Wed, Aug 6, 2014 at 10:48 AM, Jakub Jelinek wrote: > > - libstdc++ ABI changes (it is a significant user visible change, > > if you rebuild everything, no extra effort is needed, but otherwise > > if you want some C++ code built with older compilers work together > > with code built with newer compilers, it might require source code > > changes (the abi_tag attribute additions where needed and warning > > suggest to put those at), at least that is my current understanding > > of the plans > > But that's only with -std=c++11? Which had no compatibility > guarantees before? > > > - likely libgfortran ABI changes (different array descriptors) > > Let's wait and see ... > > We'll find a good reason to bump the major with every release. > Like for 4.9 LTO defaults to slim-objects, or C++ rejecting even more > invalid code, or libstdc++ header re-orgs, or defaulting to dwarf4+ > (or even support for it), or VTA, or ... > > Where do we set the barrier? GCC isn't a C++ (or Fortran) compiler > only. > > So if we change to 5.1 (please not .0) then let's switch the default > optimization level to -O2! _That's_ a user-visible change across > the board. I'm planning to move the default C standard from gnu90 to gnu11 (Currently it's blocked on the -Wc90-c99-compat warning). That's a pretty big user-visible change as well, I suppose. Marek
Re: GCC version bikeshedding
> On Aug 6, 2014, at 2:10 AM, Marek Polacek wrote: > >> On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote: >>> On Wed, Aug 6, 2014 at 10:48 AM, Jakub Jelinek wrote: >>> - libstdc++ ABI changes (it is a significant user visible change, >>> if you rebuild everything, no extra effort is needed, but otherwise >>> if you want some C++ code built with older compilers work together >>> with code built with newer compilers, it might require source code >>> changes (the abi_tag attribute additions where needed and warning >>> suggest to put those at), at least that is my current understanding >>> of the plans >> >> But that's only with -std=c++11? Which had no compatibility >> guarantees before? >> >>> - likely libgfortran ABI changes (different array descriptors) >> >> Let's wait and see ... >> >> We'll find a good reason to bump the major with every release. >> Like for 4.9 LTO defaults to slim-objects, or C++ rejecting even more >> invalid code, or libstdc++ header re-orgs, or defaulting to dwarf4+ >> (or even support for it), or VTA, or ... >> >> Where do we set the barrier? GCC isn't a C++ (or Fortran) compiler >> only. >> >> So if we change to 5.1 (please not .0) then let's switch the default >> optimization level to -O2! _That's_ a user-visible change across >> the board. > > I'm planning to move the default C standard from gnu90 to gnu11 > (Currently it's blocked on the -Wc90-c99-compat warning). > That's a pretty big user-visible change as well, I suppose. I don't think this is a good move due to extern inline and a lot of code is still k&r c and not even c90. Thanks, Andrew > >Marek
Re: GCC version bikeshedding
On Wed, 6 Aug 2014, Jakub Jelinek wrote: - libstdc++ ABI changes It seems unlikely to be in the next release, it is too late in the cycle. Chances to break the ABI don't come often, and rushing one at the end of stage1 would be wasting a good opportunity. -- Marc Glisse
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 11:20:01AM +0200, Marc Glisse wrote: > On Wed, 6 Aug 2014, Jakub Jelinek wrote: > > >- libstdc++ ABI changes > > It seems unlikely to be in the next release, it is too late in the cycle. > Chances to break the ABI don't come often, and rushing one at the end of > stage1 would be wasting a good opportunity. AFAIK it has been planned for two or more years, so I would not say it is rushed. Jakub
Re: GCC version bikeshedding
On 6 August 2014 10:06, Jakub Jelinek wrote: > On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote: >> > - libstdc++ ABI changes (it is a significant user visible change, >> > if you rebuild everything, no extra effort is needed, but otherwise >> > if you want some C++ code built with older compilers work together >> > with code built with newer compilers, it might require source code >> > changes (the abi_tag attribute additions where needed and warning >> > suggest to put those at), at least that is my current understanding >> > of the plans >> >> But that's only with -std=c++11? Which had no compatibility >> guarantees before? > > No, AFAIK it is also -std=c++98. At least my understanding was that > std::list and std::string are going to change ABI (and get new abi_tag) > in all C++ modes. Jonathan/Jason/Paolo, is that right? Correct. We want C++03 code to continue to be able to interoperate with C++11 code. It's an ABI change for all modes (but not a SONAME change because the old and new definitions will both be present in the .so).
Re: GCC version bikeshedding
On Wed, Aug 6, 2014 at 12:08 PM, Jonathan Wakely wrote: > On 6 August 2014 10:06, Jakub Jelinek wrote: >> On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote: >>> > - libstdc++ ABI changes (it is a significant user visible change, >>> > if you rebuild everything, no extra effort is needed, but otherwise >>> > if you want some C++ code built with older compilers work together >>> > with code built with newer compilers, it might require source code >>> > changes (the abi_tag attribute additions where needed and warning >>> > suggest to put those at), at least that is my current understanding >>> > of the plans >>> >>> But that's only with -std=c++11? Which had no compatibility >>> guarantees before? >> >> No, AFAIK it is also -std=c++98. At least my understanding was that >> std::list and std::string are going to change ABI (and get new abi_tag) >> in all C++ modes. Jonathan/Jason/Paolo, is that right? > > Correct. We want C++03 code to continue to be able to interoperate > with C++11 code. > > It's an ABI change for all modes (but not a SONAME change because the > old and new definitions will both be present in the .so). Ugh. That's going to be a nightmare to support. Is there a configure switch to change the default ABI used? That is, on a legacy system can I upgrate to 5.0 and get code that interoperates fine with code built with 4.8? (including ABI boundaries using the affected classes? I suspect APIs with std::string passing are _very_ common, not sure about std::list) What's the failure mode the user will see when linking against a 4.8 compiled library with a std::string interface using 5.0? Thanks, Richard.
Re: GCC version bikeshedding
On Wed, Aug 6, 2014 at 12:20 PM, Richard Biener wrote: > On Wed, Aug 6, 2014 at 12:08 PM, Jonathan Wakely > wrote: >> On 6 August 2014 10:06, Jakub Jelinek wrote: >>> On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote: > - libstdc++ ABI changes (it is a significant user visible change, > if you rebuild everything, no extra effort is needed, but otherwise > if you want some C++ code built with older compilers work together > with code built with newer compilers, it might require source code > changes (the abi_tag attribute additions where needed and warning > suggest to put those at), at least that is my current understanding > of the plans But that's only with -std=c++11? Which had no compatibility guarantees before? >>> >>> No, AFAIK it is also -std=c++98. At least my understanding was that >>> std::list and std::string are going to change ABI (and get new abi_tag) >>> in all C++ modes. Jonathan/Jason/Paolo, is that right? >> >> Correct. We want C++03 code to continue to be able to interoperate >> with C++11 code. >> >> It's an ABI change for all modes (but not a SONAME change because the >> old and new definitions will both be present in the .so). > > Ugh. That's going to be a nightmare to support. Is there a configure > switch to change the default ABI used? That is, on a legacy system > can I upgrate to 5.0 and get code that interoperates fine with code > built with 4.8? (including ABI boundaries using the affected classes? > I suspect APIs with std::string passing are _very_ common, not > sure about std::list) > > What's the failure mode the user will see when linking against a > 4.8 compiled library with a std::string interface using 5.0? And how do libraries with such an API avoid silently changing their ABI dependent on the compiler used to compile them? That is, I suppose those need to change their SONAME dependent on the compiler version used?! Richard. > Thanks, > Richard.
Re: GCC version bikeshedding
On 6 August 2014 11:20, Richard Biener wrote: > On Wed, Aug 6, 2014 at 12:08 PM, Jonathan Wakely > wrote: >> On 6 August 2014 10:06, Jakub Jelinek wrote: >>> On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote: > - libstdc++ ABI changes (it is a significant user visible change, > if you rebuild everything, no extra effort is needed, but otherwise > if you want some C++ code built with older compilers work together > with code built with newer compilers, it might require source code > changes (the abi_tag attribute additions where needed and warning > suggest to put those at), at least that is my current understanding > of the plans But that's only with -std=c++11? Which had no compatibility guarantees before? >>> >>> No, AFAIK it is also -std=c++98. At least my understanding was that >>> std::list and std::string are going to change ABI (and get new abi_tag) >>> in all C++ modes. Jonathan/Jason/Paolo, is that right? >> >> Correct. We want C++03 code to continue to be able to interoperate >> with C++11 code. >> >> It's an ABI change for all modes (but not a SONAME change because the >> old and new definitions will both be present in the .so). > > Ugh. That's going to be a nightmare to support. Is there a configure > switch to change the default ABI used? You'll need to define a macro to get the old versions of the affected classes, we can add a configure switch to make that the default. > That is, on a legacy system > can I upgrate to 5.0 and get code that interoperates fine with code > built with 4.8? (including ABI boundaries using the affected classes? > I suspect APIs with std::string passing are _very_ common, not > sure about std::list) > > What's the failure mode the user will see when linking against a > 4.8 compiled library with a std::string interface using 5.0? There will be a linker error as the types and the interface functions will have different mangled names.
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 12:20:04PM +0200, Richard Biener wrote: > >> No, AFAIK it is also -std=c++98. At least my understanding was that > >> std::list and std::string are going to change ABI (and get new abi_tag) > >> in all C++ modes. Jonathan/Jason/Paolo, is that right? > > > > Correct. We want C++03 code to continue to be able to interoperate > > with C++11 code. > > > > It's an ABI change for all modes (but not a SONAME change because the > > old and new definitions will both be present in the .so). > > Ugh. That's going to be a nightmare to support. Is there a configure > switch to change the default ABI used? That is, on a legacy system > can I upgrate to 5.0 and get code that interoperates fine with code > built with 4.8? (including ABI boundaries using the affected classes? > I suspect APIs with std::string passing are _very_ common, not > sure about std::list) Generally, if you just pass std::string or std::list or & or && or * to it around, things will be just mangled differently, so worst case you'll get linker errors or dynamic linker errors. The problematic case is if you embed std::string or std::list in your classes and pass that around in between projects compiled with one compiler and another compiler, in that case it doesn't affect the mangling, yet is an ABI change nevertheless. In such cases, one needs to add abi_tag to your structures, and there is some g++ warning that can suggest you where to add it. Of course, if you are not using such structures/classes in between packages, it is just fine not to do anything about that. Jakub
Re: GCC version bikeshedding
On Wed, Aug 6, 2014 at 12:25 PM, Jonathan Wakely wrote:
> On 6 August 2014 11:20, Richard Biener wrote:
>> On Wed, Aug 6, 2014 at 12:08 PM, Jonathan Wakely
>> wrote:
>>> On 6 August 2014 10:06, Jakub Jelinek wrote:
On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote:
> > - libstdc++ ABI changes (it is a significant user visible change,
> > if you rebuild everything, no extra effort is needed, but otherwise
> > if you want some C++ code built with older compilers work together
> > with code built with newer compilers, it might require source code
> > changes (the abi_tag attribute additions where needed and warning
> > suggest to put those at), at least that is my current understanding
> > of the plans
>
> But that's only with -std=c++11? Which had no compatibility
> guarantees before?
No, AFAIK it is also -std=c++98. At least my understanding was that
std::list and std::string are going to change ABI (and get new abi_tag)
in all C++ modes. Jonathan/Jason/Paolo, is that right?
>>>
>>> Correct. We want C++03 code to continue to be able to interoperate
>>> with C++11 code.
>>>
>>> It's an ABI change for all modes (but not a SONAME change because the
>>> old and new definitions will both be present in the .so).
>>
>> Ugh. That's going to be a nightmare to support. Is there a configure
>> switch to change the default ABI used?
>
> You'll need to define a macro to get the old versions of the affected
> classes, we can add a configure switch to make that the default.
>
>> That is, on a legacy system
>> can I upgrate to 5.0 and get code that interoperates fine with code
>> built with 4.8? (including ABI boundaries using the affected classes?
>> I suspect APIs with std::string passing are _very_ common, not
>> sure about std::list)
>>
>> What's the failure mode the user will see when linking against a
>> 4.8 compiled library with a std::string interface using 5.0?
>
> There will be a linker error as the types and the interface functions
> will have different mangled names.
Ok, so the problematical case is
struct X { std::string s; };
void foo (X&);
then. OTOH I remember that then mangling of X changes as well?
Is there a documented way to build a shared library with both
variants? Or isn't there a good way to automate that? Like
building the library objects twice once with the new and once
with the old ABI and then simply link both into the shared library?
(of course that doesn't work - but maybe use -ffunction-sections
-fdata-sections and then use the union of all sections discarding
duplicates?)
Richard.
Re: GCC version bikeshedding
On Wed, 6 Aug 2014, Richard Biener wrote: It's an ABI change for all modes (but not a SONAME change because the old and new definitions will both be present in the .so). Ugh. That's going to be a nightmare to support. Yes. And IMO a waste of effort compared to a clean .so.7 break, but well... Is there a configure switch to change the default ABI used? That is, on a legacy system can I upgrate to 5.0 and get code that interoperates fine with code built with 4.8? (including ABI boundaries using the affected classes? I suspect APIs with std::string passing are _very_ common, not sure about std::list) What's the failure mode the user will see when linking against a 4.8 compiled library with a std::string interface using 5.0? In good cases, a linker error about a missing symbol (different mangling). In less good cases, a warning at compile-time about using a class marked with abi_tag in a class not marked with it. In worse cases (passing through void* for instance), a runtime crash. And how do libraries with such an API avoid silently changing their ABI dependent on the compiler used to compile them? That is, I suppose those need to change their SONAME dependent on the compiler version used?! Yes, just like a move to .so.7 would entail. -- Marc Glisse
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 12:31:57PM +0200, Richard Biener wrote:
> Ok, so the problematical case is
>
> struct X { std::string s; };
> void foo (X&);
Yeah.
> then. OTOH I remember that then mangling of X changes as well?
Only if you add abi_tag attribute to X.
I hope the libstdc++ folks will add some macro which will
include the right abi_tag attribute for the std::list/std::string
cases, so you'd in the end just add
#ifndef _GLIBCXX_ABI_TAG_SOMETHING
#define _GLIBCXX_ABI_TAG_SOMETHING
#endif
...
struct X _GLIBCXX_ABI_TAG_SOMETHING { std::string s; };
void foo (X&);
or similar.
Jakub
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 12:35:02PM +0200, Marc Glisse wrote: > >>>It's an ABI change for all modes (but not a SONAME change because the > >>>old and new definitions will both be present in the .so). > >> > >>Ugh. That's going to be a nightmare to support. > > Yes. And IMO a waste of effort compared to a clean .so.7 break, but well... A clean .so.7 break would be significantly worse nightmare. We've been there many years ago, e.g. 3.2/3.3 vs. 3.4, there has been significantly fewer C++ plugins etc. in packages and it still it was unsolvable. With the abi_tag stuff, you have the option to make stuff interoperable when mixing compiler, either with no effort at all, or some limited effort. With .so.7, you have no option, nothing will be interoperable. Jakub
Re: GCC version bikeshedding
On Wed, 6 Aug 2014, Jakub Jelinek wrote:
On Wed, Aug 06, 2014 at 12:31:57PM +0200, Richard Biener wrote:
Ok, so the problematical case is
struct X { std::string s; };
void foo (X&);
Yeah.
then. OTOH I remember that then mangling of X changes as well?
Only if you add abi_tag attribute to X.
Note that -Wabi-tag can tell you where it is needed.
struct __attribute__((abi_tag("marc"))) X {};
struct Y { X x; };
a.cc:2:8: warning: 'Y' does not have the "marc" abi tag that 'X' (used in
the type of 'Y::x') has [-Wabi-tag]
struct Y { X x; };
^
a.cc:2:14: note: 'Y::x' declared here
struct Y { X x; };
^
a.cc:1:41: note: 'X' declared here
struct __attribute__((abi_tag("marc"))) X {};
^
I hope the libstdc++ folks will add some macro which will
include the right abi_tag attribute for the std::list/std::string
cases, so you'd in the end just add
#ifndef _GLIBCXX_ABI_TAG_SOMETHING
#define _GLIBCXX_ABI_TAG_SOMETHING
#endif
...
struct X _GLIBCXX_ABI_TAG_SOMETHING { std::string s; };
void foo (X&);
or similar.
So we only need to patch every project out there...
A clean .so.7 break would be significantly worse nightmare. We've been
there many years ago, e.g. 3.2/3.3 vs. 3.4, there has been significantly
fewer C++ plugins etc. in packages and it still it was unsolvable.
With the abi_tag stuff, you have the option to make stuff interoperable
when mixing compiler, either with no effort at all, or some limited
effort. With .so.7, you have no option, nothing will be interoperable.
I disagree that it is worse, but you have more experience, I guess we
will see the results in a few years...
--
Marc Glisse
Re: GCC version bikeshedding
On Wed, Aug 6, 2014 at 12:50 PM, Marc Glisse wrote:
> On Wed, 6 Aug 2014, Jakub Jelinek wrote:
>
>> On Wed, Aug 06, 2014 at 12:31:57PM +0200, Richard Biener wrote:
>>>
>>> Ok, so the problematical case is
>>>
>>> struct X { std::string s; };
>>> void foo (X&);
>>
>>
>> Yeah.
>>
>>> then. OTOH I remember that then mangling of X changes as well?
>>
>>
>> Only if you add abi_tag attribute to X.
>
>
> Note that -Wabi-tag can tell you where it is needed.
>
> struct __attribute__((abi_tag("marc"))) X {};
> struct Y { X x; };
>
> a.cc:2:8: warning: 'Y' does not have the "marc" abi tag that 'X' (used in
> the type of 'Y::x') has [-Wabi-tag]
> struct Y { X x; };
> ^
> a.cc:2:14: note: 'Y::x' declared here
> struct Y { X x; };
> ^
> a.cc:1:41: note: 'X' declared here
> struct __attribute__((abi_tag("marc"))) X {};
>
> ^
>
>> I hope the libstdc++ folks will add some macro which will
>> include the right abi_tag attribute for the std::list/std::string
>> cases, so you'd in the end just add
>> #ifndef _GLIBCXX_ABI_TAG_SOMETHING
>> #define _GLIBCXX_ABI_TAG_SOMETHING
>> #endif
>> ...
>> struct X _GLIBCXX_ABI_TAG_SOMETHING { std::string s; };
>> void foo (X&);
>> or similar.
>
>
> So we only need to patch every project out there...
I wonder if the linker could not do the propagation for us ...
(ok, it needs to rewrite all symbols and typeinfos, etc., but
certainly doable, no?)
That said, if the public API merely has a forward declaration
class X;
and always passes that by reference the ABI doesn't change.
Of course it now _would_ change if you'd change the mangling
of X ...
abigail to the rescue?
>> A clean .so.7 break would be significantly worse nightmare. We've been
>> there many years ago, e.g. 3.2/3.3 vs. 3.4, there has been significantly
>> fewer C++ plugins etc. in packages and it still it was unsolvable.
>> With the abi_tag stuff, you have the option to make stuff interoperable
>> when mixing compiler, either with no effort at all, or some limited
>> effort. With .so.7, you have no option, nothing will be interoperable.
>
>
> I disagree that it is worse, but you have more experience, I guess we
> will see the results in a few years...
Indeed.
Richard.
> --
> Marc Glisse
Re: Missing tags in the Git mirror
On 5 August 2014 19:32, Роман Донченко wrote: > Hello, > > Tags for the following releases are not in the Git mirror repository: > > * 3.3 > * 3.3.1 > * 3.3.5 > * 3.3.6 > * 4.7.4 > * 4.8.3 > * 4.9.1 > > I figure this is the place to report it? Yes, this is the right place, thanks. The tags in the Git mirror have to be added manually, they don't propagate from the svn repo.
Re: [GNU Tools Cauldron 2014] GCC Re-architecture BOF
On 08/05/2014 10:21 AM, Prathamesh Kulkarni wrote: Hi, I have written notes on "GCC re-architecture BOF" presented at the Cauldron. I would be grateful if you would review it for me. Seems to cover the core parts well... all subject to change as we go tho :-) initial focus wlll be the types, then we'll see about the decls... trees may never be fully removed, we'll see if that has any merit after types and maybe decls are done... Im on vacation so wont be able to respond for a couple of more weeks after this. Andrew
Re: GCC version bikeshedding
On 6 August 2014 11:31, Richard Biener wrote:
> Ok, so the problematical case is
>
> struct X { std::string s; };
> void foo (X&);
Wouldn't it be even more troublesome with an application that dynloads
dsos depending on user input.
The install script might check if the dso with the right soname is present,
but then you still get dynamic linker errors when the user tries to
do something with the application, which could be an arbitrary time after
the upgrade.
Re: Build failure for sparc-sun-solaris2.10
Hi Art, > I tried the '--without-gnu-ld --with-ld=/usr/ccs/bin/ld' configure options > and my build failed again as my GNU 'ld' binary was again being found. So strange: I'd have expected for gcc to honor a full path in --with-ld (and --with-ls for that matter). But then I never tried this before myself. > the next step was to rename my installed GNU 'ld' to 'ld-2.24' and adjust > my $PATH so that the directory where it was installed wouldn't be found, and > rebuild. I'm happy to report this build was a success: > > $ gcc -v > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/export/home/arth/local/libexec/gcc/sparc-sun-solaris2.10/4.10.0/lto-wrapper > Target: sparc-sun-solaris2.10 > Configured with: /export/home/arth/src/gcc.git/configure > --prefix=/export/home/arth/local --enable-languages=c,c++,objc > --disable-nls --with-gmp=/export/home/arth/local > --with-mpfr=/export/home/arth/local --with-mpc=/export/home/arth/local > --enable-checking=release --with-as=/export/home/arth/local/bin/as > --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld > Thread model: posix > gcc version 4.10.0 20140804 (experimental) [master revision > 0549e5a:2217af7:347a47cbf5f8ee0bc7e11dc97703b318d3ff259c] (GCC) > $ > > Thanks for your help in resolving this and maintaining the Solaris port. My pleasure, glad we could get this working. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 12:33:42PM +0100, Joern Rennecke wrote:
> On 6 August 2014 11:31, Richard Biener wrote:
> > Ok, so the problematical case is
> >
> > struct X { std::string s; };
> > void foo (X&);
>
> Wouldn't it be even more troublesome with an application that dynloads
> dsos depending on user input.
> The install script might check if the dso with the right soname is present,
> but then you still get dynamic linker errors when the user tries to
> do something with the application, which could be an arbitrary time after
> the upgrade.
Now, if you do the same with libstdc++.so.7, you have exactly the same issue
(need to think what you do with SONAMEs of libraries built with C++), but
furthermore whenever you get both libstdc++.so.6 and libstdc++.so.7 loaded
into the same process, most probably nothing will work at all, there will be
no mangling differences between so.6 and so.7 symbols, etc.
Jakub
Re: [GNU Tools Cauldron 2014] libgccjit.so
On Tue, 2014-08-05 at 03:18 +0530, Prathamesh Kulkarni wrote: > Hi, >Please find attached my notes on "libgccjit.so - An experimental > JIT library using GCC as backend". I would be grateful if you would > review it for me. Looks good to me Dave
Re: [GNU Tools Cauldron 2014] A proposal for type-safe RTL
On Tue, 2014-08-05 at 03:20 +0530, Prathamesh Kulkarni wrote: > Hi, > Please find attached my notes on "A proposal on type-safe RTL". > I would be grateful if you would review it for me. > > Thanks, > Prathamesh > > A proposal for type-safe RTL > > Author: David Malcolm > >RTL is a low-level intermediate langauge used in GCC to perform > machine-dependent optimziations and > code generation. The current RTL data strucutures (rtx), is not > type-safe, and type checking > cannot be performed during build-time. Not quite: there is an option ENABLE_RTL_CHECKING to do this, but it's so expensive that AIUI it's rarely used. > The motivation of this project is to make RTL type-safe, so that type > errors can be caught at build-time, > and to increase readability of code that operates on RTL. Note that to "make RTL type-safe" could be ambiguous: I'm looking at typesafety of GCC's own types, rather than the user's. My plans involving making a distinction between RTL instructions vs expressions i.e. the types of GCC's own implementation. AIUI, by the time we reach rtx most of the higher-level types in the *code being compiled* don't really exist anymore; we're just working with bit patterns of varying lengths - and it's not my intention to change the latter. > Representation using C++ class heirarchy: > Currently rtx is used to represent all RTL-types - instructions, > expressions, etc. > The idea is to convert rtx into C++ class heirarchy, with rtx_def > being base type, rtx_insn representing > instructions, etc. Using C++ class heirarchy makes it type-safe and > enables type-errors to be caught at > build-time > > Planned Class herirarchy: > > class rtx_def; > class rtx_insn; /* (INSN_P (X) || NOTE_P (X) > || JUMP_TABLE_DATA_P (X) || BARRIER_P (X) > || LABEL_P (X)) */ > class rtx_real_insn; /* INSN_P (X) */ > class rtx_debug_insn; /* DEBUG_INSN_P (X) */ > class rtx_nonjump_insn;/* NONJUMP_INSN_P (X) */ > class rtx_jump_insn; /* JUMP_P (X) */ > class rtx_call_insn; /* CALL_P (X) */ > class rtx_jump_table_data; /* JUMP_TABLE_DATA_P (X) */ > class rtx_barrier; /* BARRIER_P (X) */ > class rtx_code_label;/* LABEL_P (X) */ > class rtx_note; /* NOTE_P (X) */ > > Patch-series can be seen at: > http://dmalcolm.fedorapeople.org/gcc/patch-backups/rtx-classes/ > > Merge proposal for next GCC release: > - rtx_insn to represent RTL "instructions", subclass of rtx_def. > rtx_insn would be a big gain in type-safety. (nods) I've been cleaning up and testing the patch series (currently at 236 patches) and hope to post it for review later today.
[GNU Tools Cauldron 2014] MAGEEC
Hi, These are my notes for "Machine guided energy efficient compilation" presented at Cauldron. Machine guided energy efficient compilation. Author: Jeremy Bennett MAGEEC (Machine guided energy efficient compilation), is a plugin for GCC and other compilers, which includes a machine learning system, to tune compiler optimizations to optimize code for energy efficiency for any particular program and architecture. Highlights of the talk: - MAGEEC will initally look to target both GCC and LLVM. - Implemented as a compiler plugin, which performs feature extraction and allows output of machine learning algorithm, to change execution of pass sequence. - Fractional Factorial Design is used to reduce exploration of optimization space. - MAGEEC has their own benchmark suite BEEBS (Bristol/Embecosm Embedded Benchmark Suite) with currently 93 benchmarks. BEEBS 2.0 will have a much wider range of benchmarks and is scheduled to release on 31st August 2014. - The project has produced a low cost energy measurement board. A live demo was presented - run a benchmark on the development board and find the number of mJ consumed. - It would be useful for MAGEEC for GCC plugin API to be more stable. - Turning passes on and off arbitrarily can result in ICE's. The machine learning algorithm should be enhanced to understand the pass dependencies and there possibly needs to be better documentation on pass dependencies in GCC. - Currently, cannot achieve better results than -O2, but this is expected to change over time. Thanks, Prathamesh
[GNU Tools Cauldron 2014] libabigail
Hi, I have written notes for "libabigail - Towards Better ABI compatibility checking" presented at Cauldron. I would be grateful if you would review it for me. libabigail - Towards Better ABI compatibility checking Author: Dodji Seketeli libabigail (Library for ABI generic analysis and instrumentation) offers for ABI compatibility checking and reporting differences between two versions of a given library, and provide an API for tools that want to build on it's capabilities. The talk presents work done on libabigail since it's introduction at Cauldron 2013, and future directions, the project will take. A first official release is available at: https://sourceware.org/libabigail/ libabigail is useful for - Shared library developer: Do my changes break applications linking to previous version of library ? - Shared library user - Is my application still compatible with the new version of the library ? libabigail consists of DWARF reader, XML reader, Comparison engine, XML writer and tools that are built using libabigail's API, for instance bidiff. Future directions: - bicompat: Tool for application author to determine if their application A is still compatible with an updated version of library L, by examining undefined symbols of A that are resolved by L. - easier for automation: Friendly enough to be used from build-systems. - Support for uninstantiated templates. Thanks, Prathamesh
[GNU Tools Cauldron 2014] GNU C library BOF
Hi, I have written notes for "GNU C library" BOF presented at Cauldron. I would be grateful if you would review it for me. GNU C library BOF Author: Carlos O'Donell glibc (GNU C library) is available on most GNU systems with the Linux kernel. It follows all relevant standards including ISO C11 and POSIX.1-2008. It's designed to be a portable and high performance library. Highlights of BOF: - Planning for glibc 2.21 and what work needs to be done between the August -> January 2015 timeframe - Discussions on issues regarding fmemopen, fd locking, Wundef. Alternate libm implementations: - Red Hat is working on supporting alternate libm implementation, with support for low precision and high precision. - Intel is looking to add math functions that work on small vectors. Address Sanitizer: - glibc has been built with address sanitizer. Efforts are being made to integrate it with the build system. - Mentor Graphics planning to port glibc to NIOS II. It shall have to wait until Linux kernel patches are in a kernel release. - AArch64 ILP32 ABI: Kernel patches currently in review. Work related to compiler is done. - Port to OpenRISC. - Port to NaCl (nptl) Thanks, Prathamesh
[gomp4] openacc kernels directive support
Jakub,
I've looked into how to implement the openacc kernels directive in gcc.
In order to map the loopnests marked by the kernels directive efficiently on
accelerator hardware, we need parallelization and vectorization.
Focussing on paralellization for the moment, a possibility for paralellization
is to use the parloops pass. The parloops pass identifies loops that can be
parallelized with a factor n, splits off the n-reduced loop into a function and
issues the function in n parallel threads.
A problem with using parloops for the kernels directive is that the parloops
pass is placed after lto's gimple-stream read/write point, so the parloops pass
is executed during the accelerator-specific compilation. So while the resulting
function with the reduced loop is compiled for the accelerator as required, also
the code issuing the function in parallel threads is generated for the
accelerator. While f.i. newer cuda with dynamic parallelism supports launching
accelerator kernels from within accelerator kernels, I guess that that might not
hold in general.
I've investigated moving the parloops pass up in the pass list, using attached
example kernels.c. It contains 4 loops; 2 loops that set arrays, one loop that
does a vector addition, and one loop that does a reduction
First, I compile the example using upstream trunk:
...
$ gcc -ftree-parallelize-loops=32 -fdump-tree-all-all -O2 kernels.c -std=c99
-Wl,-rpath,$(pwd -P)/lean-c/install/lib64
$ ./a.out ; echo $?
sum: 4293394432
0
...
All 4 loops are recognized as parallel by parloops:
...
$ egrep 'SUCCES|FAIL' kernels.c.*parloops
SUCCESS: may be parallelized
SUCCESS: may be parallelized
SUCCESS: may be parallelized
SUCCESS: may be parallelized
...
Using attached patch, I manage the same with parloops placed after
pass_build_ealias, with some additional passes inbetween:
...
NEXT_PASS (pass_build_ealias);
NEXT_PASS (pass_ch);
NEXT_PASS (pass_ccp);
NEXT_PASS (pass_lim_aux);
NEXT_PASS (pass_parallelize_loops);
...
The pass_lim_aux in front is needed because otherwise the loads of pointers a, b
and c stay in the loop and prevent parallelization.
The pass_ccp is to get rid of:
...
phi is i_5 = PHI <0(3)>
arg of phi to exit: value 0 used outside loop
checking if it a part of reduction pattern:
FAILED: it is not a part of reduction.
...
The pass_tree_ch is to get rid of:
...
phi is sum_3 = PHI
arg of phi to exit: value sum_1 used outside loop
checking if it a part of reduction pattern:
FAILED: it is not a part of reduction.
...
The place after build_ealias is early enough to be before the lto-stream
write/read. I don't see how we can do this earlier. Before ealias, there's no
alias info, and one of the loops fails to be recognized as parallel.
Furthermore, pass_ch, pass_ccp, pass_lim_aux and pass_parloops are written to
work on cfg/ssa code, which we don't have at omp_low/omp_exp time.
We could insert a pass-group here that only deals with functions that have the
kernels directive, and do the auto-par thing in a pass_oacc_kernels (which
should share the majority of the infrastructure with the parloops pass):
...
NEXT_PASS (pass_build_ealias);
INSERT_PASSES_AFTER/WITHIN (passes_oacc_kernels)
NEXT_PASS (pass_ch);
NEXT_PASS (pass_ccp);
NEXT_PASS (pass_lim_aux);
NEXT_PASS (pass_oacc_par);
POP_INSERT_PASSES ()
...
Any comments, ideas or suggestions ?
Thanks,
- Tom
#include
#include
#define N (1024 * 512)
#define N_REF 4293394432
unsigned int *__restrict a;
unsigned int *__restrict b;
unsigned int *__restrict c;
void
init_input (void)
{
for (unsigned int i = 0; i < N; i++)
a[i] = i * 2;
for (unsigned int i = 0; i < N; i++)
b[i] = i * 4;
}
void
check_output (void)
{
unsigned int sum = 0;
for (unsigned int i = 0; i < N; i++)
sum += c[i];
printf ("sum: %u\n", sum);
if (sum != N_REF)
abort ();
}
int
main (void)
{
unsigned int i;
a = malloc (N * sizeof (unsigned int));
b = malloc (N * sizeof (unsigned int));
c = malloc (N * sizeof (unsigned int));
init_input ();
for (int ii = 0; ii < N; ii++)
c[ii] = a[ii] + b[ii];
check_output ();
free (a);
free (b);
free (c);
return 0;
}
diff --git a/gcc/passes.def b/gcc/passes.def
index f13df6c..b501d2f 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -72,6 +72,10 @@ along with GCC; see the file COPYING3. If not see
/* pass_build_ealias is a dummy pass that ensures that we
execute TODO_rebuild_alias at this point. */
NEXT_PASS (pass_build_ealias);
+ NEXT_PASS (pass_ch);
+ NEXT_PASS (pass_ccp);
+ NEXT_PASS (pass_lim_aux);
+ NEXT_PASS (pass_parallelize_loops);
NEXT_PASS (pass_fre);
NEXT_PASS (pass_merge_phi);
NEXT_PASS (pass_cd_dce);
@@ -159,7 +163,6 @@ along with GCC; see the file COPYING3. If not see
NEXT_PASS (pass_tree_if
Mrs Sarah... Waitng
Dear How are you? I have a very Lucrative and Life Changing Business Opportuinity for you. You can also check on my Biography from this link as well ( http://bank.hangseng.com/1/2/about-us/directors-organisation/board-of-directors ). This is my email:sarah.legg...@gmail.com I hope to hear from you soon Regard Mrs Sarah Catherine LEGG
Re: Reload generate invalid instruction on ppc64
I found the root cause. In function rs6000_preferred_reload_class, it specifically check the case that reload 0 into a VSX register, then the target reload class is VSX register. VSX instructions can't load a constant into VSX registers directly, I guess the author wanted to use a SUB or XOR instruction to get a 0 value. Then function gen_reload calls gen_move_insn to generate the reload instruction, which actually generates a movdi_internal64 insn, and it doesn't contain a constraint to handle the 0->VSX register case, and causes ICE. So it can be fixed by adding a new constraint to movdi_internal64 to load 0 to VSX register. thanks Guozhi Wei On Tue, Aug 5, 2014 at 1:38 PM, Segher Boessenkool wrote: > On Tue, Aug 05, 2014 at 01:32:00PM +0930, Alan Modra wrote: >> On Mon, Aug 04, 2014 at 05:54:04PM -0700, Carrot Wei wrote: >> > Another problem is in the definition of insn pattern "*movdi_internal64". >> > >> > (define_insn "*movdi_internal64" >> > [(set (match_operand:DI 0 "nonimmediate_operand" >> > "=Y,r,r,r,r,r,?m,?*d,?*d,r,*h,*h,r,?*wg,r,?*wm") >> > (match_operand:DI 1 "input_operand" >> > "r,Y,r,I,L,nF,d,m,d,*h,r,0,*wg,r,*wm,r"))] >> > "TARGET_POWERPC64 >> >&& (gpc_reg_operand (operands[0], DImode) >> >|| gpc_reg_operand (operands[1], DImode))" >> > >> > The predicates of this insn pattern allow the moving of an integer to >> > VSX register, but there is no constraint allow this case. Can this >> > cause problem in reload? >> >> Probably, just as you found with fprs. The underlying issue is that >> the operand predicates don't match the operand constraints. What's >> more, you can't make them match without breaking up the insn, or >> adding a whole lot of extra alternatives. > > Can you disallow this in the condition of the pattern, just like it > already requires at least one of the operands to be gpc_reg_operand? > > > Segher
ViewVC is broken on your web site
Accessing https://gcc.gnu.org/viewvc/gcc/trunk/ Says it is showing 38 files. But in fact, it shows only the first 25. As an example, libstdc++-v3 is missing. Same thing happens in other parts of the tree. I checked the HTML page source, and the files simply aren't there. David
Re: ViewVC is broken on your web site
On Aug 6, 2014, at 2:38 PM, David Gero wrote: > Accessing https://gcc.gnu.org/viewvc/gcc/trunk/ > > Says it is showing 38 files. But in fact, it shows only the first 25. As an > example, libstdc++-v3 is missing. > > Same thing happens in other parts of the tree. > > I checked the HTML page source, and the files simply aren't there. The same on https://gcc.gnu.org/viewvc/gcc/trunk/gcc/ — except in that case it claims there should be 712 files, and here too is only shows 25 lines. Time to revert whatever change was made that broke this; as it stands the website is completely unuseable. paul
Re: ViewVC is broken on your web site
Hi, On 08/06/2014 08:48 PM, paul_kon...@dell.com wrote: On Aug 6, 2014, at 2:38 PM, David Gero wrote: Accessing https://gcc.gnu.org/viewvc/gcc/trunk/ Says it is showing 38 files. But in fact, it shows only the first 25. As an example, libstdc++-v3 is missing. Same thing happens in other parts of the tree. I checked the HTML page source, and the files simply aren't there. The same on https://gcc.gnu.org/viewvc/gcc/trunk/gcc/ — except in that case it claims there should be 712 files, and here too is only shows 25 lines. Time to revert whatever change was made that broke this; as it stands the website is completely unuseable. Thus, the widget on top of the page, meant to select the page the user wants to see (eg, 30 pages overall for ../gcc/trunk) does *not* work for you?!? It works perfectly well for me. Paolo.
Re: ViewVC is broken on your web site
On Aug 6, 2014, at 2:59 PM, Paolo Carlini wrote: > Hi, > > On 08/06/2014 08:48 PM, paul_kon...@dell.com wrote: >> On Aug 6, 2014, at 2:38 PM, David Gero wrote: >> >>> Accessing https://gcc.gnu.org/viewvc/gcc/trunk/ >>> >>> Says it is showing 38 files. But in fact, it shows only the first 25. As >>> an example, libstdc++-v3 is missing. >>> >>> Same thing happens in other parts of the tree. >>> >>> I checked the HTML page source, and the files simply aren't there. >> The same on https://gcc.gnu.org/viewvc/gcc/trunk/gcc/ — except in that case >> it claims there should be 712 files, and here too is only shows 25 lines. >> >> Time to revert whatever change was made that broke this; as it stands the >> website is completely unuseable. > Thus, the widget on top of the page, meant to select the page the user wants > to see (eg, 30 pages overall for ../gcc/trunk) does *not* work for you?!? It > works perfectly well for me. It doesn’t work because I didn’t see it, and when I looked at it some more I had no clue what it’s for. This is not a good way of designing a UI. It’s cryptic, it’s hard to find, the default is questionable, and it doesn’t offer a “see everything” feature. There is no visual indication (other than the “wrong” value of the files count) that the display is incomplete. At the very least, it needs to say “more entries” or “..." before and/or after the subset that is displayed, if a subset is displayed. But the preferred answer in my mind is to get rid of this thing and go back to displaying the whole page. If you do want to keep the subset thing, at least make it NOT the default. paul
RE: ViewVC is broken on your web site
>Hi, > >On 08/06/2014 08:48 PM, paul_kon...@dell.com wrote: >> On Aug 6, 2014, at 2:38 PM, David Gero wrote: >> >>> Accessing https://gcc.gnu.org/viewvc/gcc/trunk/ >>> >>> Says it is showing 38 files. But in fact, it shows only the first 25. As >>> an example, libstdc++-v3 is missing. >>> >>> Same thing happens in other parts of the tree. >>> >>> I checked the HTML page source, and the files simply aren't there. >> The same on https://gcc.gnu.org/viewvc/gcc/trunk/gcc/ - except in that case >> it claims there should be 712 files, and here too is only shows 25 lines. >> >> Time to revert whatever change was made that broke this; as it stands the >> website is completely unuseable. > >Thus, the widget on top of the page, meant to select the page the user wants >to see (eg, 30 pages overall for ../gcc/trunk) does *not* work for you?!? It >works perfectly well for me. > >Paolo. Wow. What an amazingly unintuitive widget. I looked all over the page for a "Next 25 files" button. A "Go To" button that doesn't talk about next 25 files meant nothing. ViewVC used to display all the files. This is a giant leap backward in the User Interface. David
Re: ViewVC is broken on your web site
Hi, On 08/06/2014 09:19 PM, David Gero wrote: Wow. What an amazingly unintuitive widget. I looked all over the page for a "Next 25 files" button. A "Go To" button that doesn't talk about next 25 files meant nothing. ViewVC used to display all the files. This is a giant leap backward in the User Interface. AFAIK the tool is neither part of GCC neither part of the GNU Project, GCC is simply using it. Thus my guess would be that somebody installed an updated version which, together with a number of improvements, has also this questionable change. Personally, I don't have a strong opinion, but since you guys have one, I would recommend getting in contact with the authors of the tool, contribute ideas, maybe code too. Paolo.
Re: ViewVC is broken on your web site
On Wed, 2014-08-06 at 21:34 +0200, Paolo Carlini wrote: > Hi, > > On 08/06/2014 09:19 PM, David Gero wrote: > > Wow. What an amazingly unintuitive widget. I looked all over the page > > for a "Next 25 files" button. A "Go To" button that doesn't talk about > > next 25 files meant nothing. ViewVC used to display all the files. > > This is a giant leap backward in the User Interface. > AFAIK the tool is neither part of GCC neither part of the GNU Project, > GCC is simply using it. Thus my guess would be that somebody installed > an updated version which, together with a number of improvements, has > also this questionable change. Personally, I don't have a strong > opinion, but since you guys have one, I would recommend getting in > contact with the authors of the tool, contribute ideas, maybe code too. It seems this behavior can be configured 'use_pagesize = 0' See also: http://oss.segetech.com/bugz-svn-wiki/viewvc.conf This page limit thing is really ... argh ... Cheers, Oleg
Re: ViewVC is broken on your web site
On 6 August 2014 20:12, wrote: > But the preferred answer in my mind is to get rid of this thing and go back > to displaying the whole page. If you do want to keep the subset thing, at > least make it NOT the default. IIRC that causes timeouts when the site is busy, because it has to fetch a lot of information about a lot of files. Only showing a subset of files is an OK compromise, but the UI could be much better. Complaining about it here is pointless though.
gcc-4.9-20140806 is now available
Snapshot gcc-4.9-20140806 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140806/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 213683 You'll find: gcc-4.9-20140806.tar.bz2 Complete GCC MD5=15b7e719773e7f6a4b983ab453f955ab SHA1=bd87edd995a192c8b3499445abcb2a5083a388c9 Diffs from 4.9-20140730 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 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: LTO and version scripts
On Tue, Aug 05, 2014 at 08:18:06PM -0400, Ulrich Drepper wrote:
> On Tue, Aug 5, 2014 at 12:57 AM, Alan Modra wrote:
> > What version linker? In particular, do you have the fix for PR12975?
>
> The Fedora 19 version. I think it hasn't changed since then which
> means it is 2.23.88.0.1-13 (from the RPM version number). No idea
> whether that fix is included and unfortunately won't have time to try
> before the weekend.
Both Fedora 19 and 20 have the patch needed for this to work. Hmm, I
suppose the other thing necessary is a gcc that implements
LDPT_GET_SYMBOLS_V2. You may be lacking that. Here's what I see with
mainline gcc and ld.
cat > ltoshare.c <<\EOF
int
cond (void)
{
return 0;
}
extern void something (void);
int
main (void)
{
if (cond ())
something ();
return 0;
}
EOF
cat > ltoshare.ver <<\EOF
{
global: main;
local: *;
};
EOF
~/build/gcc-current/gcc/xgcc -B ~/build/gcc-current/gcc/ -B ld/tmpdir/ld -O2
-fPIC -flto -c ltoshare.c
~/build/gcc-current/gcc/xgcc -B ~/build/gcc-current/gcc/ -B ld/tmpdir/ld
-shared -flto -o ltoshare.so ltoshare.o
nm -D ltoshare.so | grep something
U something
~/build/gcc-current/gcc/xgcc -B ~/build/gcc-current/gcc/ -B ld/tmpdir/ld
-shared -flto -o ltoshare.so ltoshare.o -Wl,--version-script=ltoshare.ver
nm -D ltoshare.so | grep something
--
Alan Modra
Australia Development Lab, IBM
Re: Help w/ PR61538?
On 07/28/2014 17:38, Matthew Fortune wrote: > I'll switch to replying on PR61538. I had not read all the ticket > previously and although I may have found a problem it seems it may not > be the cause of this failure. > > The generated code differences after the patches seem significant but > I may not get chance to look at the differences in detail for a little > while. For my own information, what's the cutoff date for fixes to regressions like this to make it into gcc-4.9.1? -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
