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 ja...@redhat.com 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 ja...@redhat.com 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 ja...@redhat.com 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 ja...@redhat.com 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 ja...@redhat.com 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 pola...@redhat.com 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 ja...@redhat.com 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 kr 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 jwakely@gmail.com 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 richard.guent...@gmail.com wrote: On Wed, Aug 6, 2014 at 12:08 PM, Jonathan Wakely jwakely@gmail.com 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 jwakely@gmail.com 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 jwakely@gmail.com wrote:
On 6 August 2014 11:20, Richard Biener wrote:
On Wed, Aug 6, 2014 at 12:08 PM, Jonathan Wakely jwakely@gmail.com
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 marc.gli...@inria.fr 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 richard.guent...@gmail.com 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 richard.guent...@gmail.com 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 sum_1(4)
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 stdlib.h
#include stdio.h
#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
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 seg...@kernel.crashing.org 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 david.g...@exfo.com 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 david.g...@exfo.com 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 paolo.carl...@oracle.com wrote: Hi, On 08/06/2014 08:48 PM, paul_kon...@dell.com wrote: On Aug 6, 2014, at 2:38 PM, David Gero david.g...@exfo.com 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 david.g...@exfo.com 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, paul_kon...@dell.com 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 amo...@gmail.com 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
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 wangzheyu tony.wang at arm dot com changed: What|Removed |Added CC||tony.wang at arm dot com --- Comment #64 from wangzheyu tony.wang at arm dot com --- Fix: Index: gcc/tree-ssa-loop-ivopts.c === --- gcc/tree-ssa-loop-ivopts.c (revision 213050) +++ gcc/tree-ssa-loop-ivopts.c (working copy) @@ -1704,6 +1704,8 @@ may_be_unaligned_p (tree ref, tree step) return false; unsigned int align = TYPE_ALIGN (TREE_TYPE (ref)); + if (GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))) align) +align = GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))); unsigned HOST_WIDE_INT bitpos; unsigned int ref_align; can you test and apply that patch? Also run into a similar regression on arm target, which will generate unaligned memory access on target which don't support unaligned data access. This patch does fix this regression. Thx
[Bug rtl-optimization/62030] wrong code due to ifcvt merging two stores which have different aliasing sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62030 vries at gcc dot gnu.org changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #2 from vries at gcc dot gnu.org --- I think the test-case is reading an undefined value from n-next, but that's easy enough to fix with an intializer for node. Taking the tentative patch from PR62004, ( https://gcc.gnu.org/bugzilla/attachment.cgi?id=33242action=diff ), with this patch added prevents the if-conversion in this case: ... @@ -2504,7 +2534,9 @@ noce_process_if_block (struct noce_if_info *if_info) if (! insn_b || insn_b != last_active_insn (else_bb, FALSE) || (set_b = single_set (insn_b)) == NULL_RTX - || ! rtx_equal_p (x, SET_DEST (set_b))) + || ! (rtx_equal_p (x, SET_DEST (set_b)) +(GET_CODE (x) != MEM + || mem_interchangeable_p (x, SET_DEST (set_b return FALSE; } else ...
[Bug rtl-optimization/62030] wrong code due to ifcvt merging two stores which have different aliasing sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62030 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to vries from comment #2) I think the test-case is reading an undefined value from n-next, but that's easy enough to fix with an intializer for node. Since node is a global variable, it is zero initialized so there is no reading from an uninitialized area.
[Bug rtl-optimization/62004] dead type-unsafe load replaces type-safe load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62004 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) Heh, interesting set of events ;) I have a store version that fires on mips64 with a modified testcase too, see bug 62030.
[Bug c/62031] New: Different results between O2 and O3 for gcc-4.7.2-5 (Debian 4.7.2-5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031
Bug ID: 62031
Summary: Different results between O2 and O3 for gcc-4.7.2-5
(Debian 4.7.2-5)
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tomasz.ostaszewski at interia dot pl
Created attachment 33255
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33255action=edit
problematic code, preprocessed
Hello,
My little program produces different results when compiled with O2 and O3
options. Turning on/off '-fstrict-aliasing' does not make any difference.
#include stdlib.h
#include stdio.h
#define NUM_OF_STATES 4
typedef unsigned int entry_t[2];
typedef struct entries_item { entry_t metricEntries_[0]; } entries_item_t;
void test_00(size_t numOfStates, entries_item_t* p_bm, const unsigned int*
polyArray,
size_t polyArraySize) {
size_t idx;
unsigned int hlp0, hlp1;
for (idx = 0; idx numOfStates; ++idx) {
size_t idy;
hlp0 = (idx 1) | 0x00;
hlp1 = (idx 1) | 0x01;
p_bm-metricEntries_[idx][0] = 0;
p_bm-metricEntries_[idx][1] = 0;
for (idy = 0; idy polyArraySize; ++idy) {
p_bm-metricEntries_[idx][0] |= __builtin_parity(hlp0
polyArray[idy]) idy;
p_bm-metricEntries_[idx][1] |= __builtin_parity(hlp1
polyArray[idy]) idy;
#if 0
fprintf(stderr, %4.4u : %8.8x %8.8x\n, __LINE__,
p_bm-metricEntries_[idx][0], p_bm-metricEntries_[idx][1]);
#endif
}
}
fprintf(stderr, %4.4u :, __LINE__);
for (idx = 0; idx numOfStates; ++idx) {
fprintf(stderr, %2u:%2u , p_bm-metricEntries_[idx][0],
p_bm-metricEntries_[idx][1]);
}
fprintf(stderr, \n);
}
int main(__attribute__((unused)) int argc, __attribute__((unused)) char** argv)
{
unsigned int polyArray[] = { 0x07, 0x05 };
entries_item_t* pBranchMetrics;
pBranchMetrics = malloc(sizeof(entry_t) * NUM_OF_STATES);
test_00(NUM_OF_STATES, pBranchMetrics, polyArray, sizeof(polyArray) /
sizeof(polyArray[0]));
free(pBranchMetrics);
return 0;
}
When compiled with O2 produces a correct result:
0029 : 0: 3 1: 2 3: 0 2: 1
When compiled with O3 produces an incorrect result:
0029 : 0: 2 0: 2 2: 0 2: 0
Suprisingly, changing #if 0 to #if 1 forces program to produce correct results.
Also adding the 'static' keyword before 'void test_00' also changes program to
produce a correct result. Also, changing zero sized array to fixed array (size
1) also makes the problem go away.
Valgrind does not report any violations in either case (O2/O3). Both gcc-4.6.3
and clang 3.5.0 produce correct results with O3.
problematic gcc version:
$ gcc --verbose
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.7/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --enable-targets=all --with-arch-32=i586
--with-tune=generic --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)
Assembler:
$as --version
GNU assembler (GNU Binutils for Debian) 2.22
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `i486-linux-gnu'.
System:
Linux debian-vm-x86 3.2.0-4-686-pae #1 SMP Debian 3.2.60-1+deb7u3 i686
GNU/Linux
LibC:
/lib/i386-linux-gnu/libc-2.13.so
GNU C Library (Debian EGLIBC 2.13-38+deb7u3) stable release version 2.13, by
Roland McGrath et al.
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.7.
Compiled on a Linux 3.2.57 system on 2014-07-09.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
http://www.debian.org/Bugs/.
[Bug rtl-optimization/62030] wrong code due to ifcvt merging two stores which have different aliasing sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62030 --- Comment #4 from vries at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #3) (In reply to vries from comment #2) I think the test-case is reading an undefined value from n-next, but that's easy enough to fix with an intializer for node. Since node is a global variable, it is zero initialized so there is no reading from an uninitialized area. Ah, right, I thought that only applied to static. Thanks for setting that straight.
[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014 --- Comment #15 from ktkachov at gcc dot gnu.org --- I can't reproduce this with current trunk and 4.9.1. What exact compiler version and options did you use? I used -O2 -mgeneral-regs-only on an aarch64-none-elf compiler gcc version 4.10.0 20140805
[Bug tree-optimization/62032] New: FAIL: vsnprintf-chk.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62032 Bug ID: 62032 Summary: FAIL: vsnprintf-chk.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: amker.cheng at gmail dot com Created attachment 33256 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33256action=edit tarball of dump files Hi, I monitored below failures on both aarch64-none-elf and arm-none-eabi. FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects It's first introduced by r213585, but I am not sure if it's revealed by the change. The corresponding (goodbogus) dump files are attached. arm-none-eabi is configured like: ../gcc/configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-none-eabi --prefix=.../trunk-orig/target/ --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-sysroot=.../trunk-orig/target/arm-none-eabi --with-host-libstdcxx=... --with-mode=thumb --with-arch=armv7-m --disable-multilib --enable-lto --enable-languages=c,c++,lto Thanks.
[Bug c/62031] Different results between O2 and O3 for gcc-4.7.2-5 (Debian 4.7.2-5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Comment #1 from Mikael Pettersson mikpelinux at gmail dot com ---
I can reproduce with 4.8.3 and 4.9.1. -fsanitize={address,undefined} finds
nothing to complain about.
[Bug tree-optimization/62032] FAIL: vsnprintf-chk.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62032 --- Comment #1 from bin.cheng amker.cheng at gmail dot com --- Only fail with lto options.
[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 --- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Aug 6 08:40:19 2014 New Revision: 213652 URL: https://gcc.gnu.org/viewcvs?rev=213652root=gccview=rev Log: PR rtl-optimization/61801 * gcc.target/i386/pr61801.c: Rewritten. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr61801.c
[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 --- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Aug 6 08:44:05 2014 New Revision: 213653 URL: https://gcc.gnu.org/viewcvs?rev=213653root=gccview=rev Log: PR rtl-optimization/61801 * gcc.target/i386/pr61801.c: Rewritten. Modified: branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr61801.c
[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 --- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Aug 6 08:50:12 2014 New Revision: 213654 URL: https://gcc.gnu.org/viewcvs?rev=213654root=gccview=rev Log: PR rtl-optimization/61801 * gcc.target/i386/pr61801.c: Rewritten. Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr61801.c
[Bug tree-optimization/62032] FAIL: vsnprintf-chk.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62032 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.9.1 Keywords||lto Last reconfirmed||2014-08-06 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |4.10.0 Known to fail||4.10.0 --- Comment #2 from ktkachov at gcc dot gnu.org --- confirmed, I've noticed this as well. This seems to appear with LTO
[Bug tree-optimization/62031] [4.8/4.9/4.10 Regression] Different results between O2 and O2 -fpredictive-commoning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.3.4 Keywords||wrong-code Last reconfirmed||2014-08-06 Component|c |tree-optimization CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 Summary|Different results between |[4.8/4.9/4.10 Regression] |O2 and O3 for gcc-4.7.2-5 |Different results between |(Debian 4.7.2-5)|O2 and O2 ||-fpredictive-commoning Target Milestone|--- |4.8.4 Known to fail||4.7.4, 4.9.1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- -O2 -fpredictive-commoning fails as well (thus culprit found).
[Bug lto/62026] [4.9/4.10 Regression] Crash in lto_get_decl_name_mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62026 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.9.2
[Bug tree-optimization/62033] New: okteta 4.13.97 error at -O3 -D_FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62033 Bug ID: 62033 Summary: okteta 4.13.97 error at -O3 -D_FORTIFY_SOURCE=2 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Created attachment 33257 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33257action=edit delta+hand reduced testcase Found on powerpc64le with 4.9, and then with x86_64 4.10.0 20140727 Due to __warn_memset_zero_len reference in object, we get .../bytearraymodel_p.o: In function `memset': .../bits/string3.h:81: warning: memset used with constant zero length parameter; this could be due to transposed parameters collect2: error: ld returned 1 exit status Compile testcase with -O3 -fvisibility=hidden -Werror=return-type -fvisibility-inlines-hidden
[Bug tree-optimization/62033] okteta 4.13.97 error at -O3 -D_FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62033 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- I don't see a bug here as there is one case where addSize can return 0 and with jump threading and basic block copying, we get a zero size passed to memset.
[Bug rtl-optimization/62030] wrong code due to ifcvt merging two stores which have different aliasing sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62030 --- Comment #5 from vries at gcc dot gnu.org --- Created attachment 33258 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33258action=edit Updated tentative patch for if-conversion, including fix for pr62030 Updated tentative patch for if-conversion, including fix for pr62030
[Bug tree-optimization/62033] okteta 4.13.97 error at -O3 -D_FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62033 --- Comment #2 from Alan Modra amodra at gmail dot com --- I can see where you're coming from Andrew, but what is disconcerting about this is that the _FORTIFY_SOURCE warning is plainly incorrect here. How is one supposed to write a string.h memset macro using __builtin_constant_p() to provide a useful _FORTIFY_SOURCE warning, in the face of this sort of optimisation? Users are going to see this as __builtin_constant_p() is broken.
[Bug lto/49571] -flto -Wl,--as-needed drops needed libraries with GNU ld and linker plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49571 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||amodra at gmail dot com Resolution|--- |WORKSFORME --- Comment #3 from Alan Modra amodra at gmail dot com --- Works with BFD ld too.
[Bug lto/52401] lto can't handle ld script
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52401 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||amodra at gmail dot com Resolution|--- |WORKSFORME --- Comment #4 from Alan Modra amodra at gmail dot com --- Works with mainline ld. Has been fixed for quite a while.
[Bug tree-optimization/62031] [4.8/4.9/4.10 Regression] Different results between O2 and O2 -fpredictive-commoning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r175704.
[Bug lto/62034] New: ICE for big statically initialized arrays compiled with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62034
Bug ID: 62034
Summary: ICE for big statically initialized arrays compiled
with LTO
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: enkovich.gnu at gmail dot com
Created attachment 33259
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33259action=edit
Reproducer
I get ICE when try to compile tests with big amount of statically initialized
data.
gcc --version
gcc (GCC) 4.10.0 20140806 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
gcc -flto test.c
gcc: internal compiler error: Segmentation fault (program lto1)
0x405c80 execute
../../gcc-ref/gcc/gcc.c:2900
0x409fe9 do_spec_1
../../gcc-ref/gcc/gcc.c:4704
0x40d475 process_brace_body
../../gcc-ref/gcc/gcc.c:5987
0x40d2b1 handle_braces
../../gcc-ref/gcc/gcc.c:5901
0x40bf9d do_spec_1
../../gcc-ref/gcc/gcc.c:5358
0x40d475 process_brace_body
../../gcc-ref/gcc/gcc.c:5987
0x40d2b1 handle_braces
../../gcc-ref/gcc/gcc.c:5901
0x40bf9d do_spec_1
../../gcc-ref/gcc/gcc.c:5358
0x40c38c do_spec_1
../../gcc-ref/gcc/gcc.c:5473
0x40d475 process_brace_body
../../gcc-ref/gcc/gcc.c:5987
0x40d2b1 handle_braces
../../gcc-ref/gcc/gcc.c:5901
0x40bf9d do_spec_1
../../gcc-ref/gcc/gcc.c:5358
0x409664 do_spec_2
../../gcc-ref/gcc/gcc.c:4405
0x409582 do_spec(char const*)
../../gcc-ref/gcc/gcc.c:4372
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
lto-wrapper: fatal error: gcc-ref-build/bin/gcc returned 4 exit status
compilation terminated.
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
Debugger shows that problem appears when lto_input_tree tries to dig through a
bunch of SCC entries in input stream. Each SCC entry cause two new functions
(lto_input_tree and lto_input_tree_1) in the call stack. With many consequent
SCC entries stack may grow too much (in my case compiler segfaulted with ~600
000 entries in the call stack).
Attached test has a statically initialized array with a million elements.
Bigger data set may be required to break the compiler if you use increased
stack size.
Problem appeared after this commit:
https://gcc.gnu.org/ml/gcc-cvs/2014-07/msg00291.html
Following patch removing recursion helps me to compile my tests:
diff --git a/gcc/lto-streamer-in.c b/gcc/lto-streamer-in.c
index 698f926..25657da 100644
--- a/gcc/lto-streamer-in.c
+++ b/gcc/lto-streamer-in.c
@@ -1345,7 +1345,16 @@ lto_input_tree_1 (struct lto_input_block *ib, struct
data_in *data_in,
tree
lto_input_tree (struct lto_input_block *ib, struct data_in *data_in)
{
- return lto_input_tree_1 (ib, data_in, streamer_read_record_start (ib), 0);
+ enum LTO_tags tag;
+
+ /* Skip SCC entries. */
+ while ((tag = streamer_read_record_start (ib)) == LTO_tree_scc)
+{
+ unsigned len, entry_len;
+ lto_input_scc (ib, data_in, len, entry_len);
+}
+
+ return lto_input_tree_1 (ib, data_in, tag, 0);
}
Did not fully test this patch yet.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #65 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #61 from Eric Botcazou ebotcazou at gcc dot gnu.org --- [...] can you test and apply that patch? I think that it needs to be applied on both mainline and 4.9 branch then. Testing on the 4.9 branch also completed successfully, so from my POV the patch is good to go in both mainline and branch. Thanks. Rainer
[Bug tree-optimization/62031] [4.8/4.9/4.10 Regression] Different results between O2 and O2 -fpredictive-commoning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Mine then.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #66 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Aug 6 11:41:13 2014 New Revision: 213661 URL: https://gcc.gnu.org/viewcvs?rev=213661root=gccview=rev Log: 2014-08-06 Richard Biener rguent...@suse.de PR tree-optimization/61320 * tree-ssa-loop-ivopts.c (may_be_unaligned_p): Properly handle misaligned loads. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #67 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Aug 6 11:42:22 2014 New Revision: 213662 URL: https://gcc.gnu.org/viewcvs?rev=213662root=gccview=rev Log: 2014-08-06 Richard Biener rguent...@suse.de PR tree-optimization/61320 * tree-ssa-loop-ivopts.c (may_be_unaligned_p): Properly handle misaligned loads. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/tree-ssa-loop-ivopts.c
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.10.0, 4.8.3, 4.9.2 Resolution|--- |FIXED Target Milestone|4.10.0 |4.9.2 Known to fail|4.8.3 |4.9.1 --- Comment #68 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/62021] ICE in verify_gimple_assign_single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62021 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- The problem is that get_vectype_for_scalar_type_and_size for pointers just returns vectors of pointer sized integers instead of vectors of pointers. So, either we need to VCE it, or change the simd_clones to instead use vectors of pointer sized integers instead of vectors of pointers for the arguments.
[Bug target/61535] [4.10 Regression] SIGBUS in gen_group_rtx compiling 64-bit gcc.dg/vect/vect-singleton_1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61535 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- I'm seeing the same on the 4.7, 4.8, and 4.9 branches. Also reproducible in i386-pc-solaris2.11 x sparc-solaris2.11 and x86_64-unknown-linux-gnu crosses. Rainer
[Bug lto/62034] ICE for big statically initialized arrays compiled with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62034 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-08-06 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Ah, the issue is that the tail-recursion doesn't work. Mine.
[Bug lto/62034] ICE for big statically initialized arrays compiled with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62034
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Better patch:
Index: gcc/lto-streamer-in.c
===
--- gcc/lto-streamer-in.c (revision 213660)
+++ gcc/lto-streamer-in.c (working copy)
@@ -1325,13 +1325,17 @@ lto_input_tree_1 (struct lto_input_block
}
else if (tag == LTO_tree_scc)
{
- unsigned len, entry_len;
-
- /* Input and skip the SCC. */
- lto_input_scc (ib, data_in, len, entry_len);
+ /* Input and skip SCCs. */
+ do
+ {
+ unsigned len, entry_len;
+ lto_input_scc (ib, data_in, len, entry_len);
+ tag = streamer_read_record_start (ib);
+ }
+ while (tag == LTO_tree_scc);
/* Recurse. */
- return lto_input_tree (ib, data_in);
+ return lto_input_tree_1 (ib, data_in, tag, 0);
}
else
{
[Bug tree-optimization/62021] ICE in verify_gimple_assign_single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62021 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) The problem is that get_vectype_for_scalar_type_and_size for pointers just returns vectors of pointer sized integers instead of vectors of pointers. So, either we need to VCE it, or change the simd_clones to instead use vectors of pointer sized integers instead of vectors of pointers for the arguments. The latter. There are no vectors of pointers. Richard.
[Bug lto/62034] ICE for big statically initialized arrays compiled with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62034
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
Or actually
Index: gcc/lto-streamer-in.c
===
--- gcc/lto-streamer-in.c (revision 213660)
+++ gcc/lto-streamer-in.c (working copy)
@@ -1324,15 +1324,7 @@ lto_input_tree_1 (struct lto_input_block
streamer_tree_cache_append (data_in-reader_cache, result, hash);
}
else if (tag == LTO_tree_scc)
-{
- unsigned len, entry_len;
-
- /* Input and skip the SCC. */
- lto_input_scc (ib, data_in, len, entry_len);
-
- /* Recurse. */
- return lto_input_tree (ib, data_in);
-}
+gcc_unreachable ();
else
{
/* Otherwise, materialize a new node from IB. */
@@ -1345,7 +1337,15 @@ lto_input_tree_1 (struct lto_input_block
tree
lto_input_tree (struct lto_input_block *ib, struct data_in *data_in)
{
- return lto_input_tree_1 (ib, data_in, streamer_read_record_start (ib), 0);
+ enum LTO_tags tag;
+
+ /* Input and skip SCCs. */
+ while ((tag = streamer_read_record_start (ib)) == LTO_tree_scc)
+{
+ unsigned len, entry_len;
+ lto_input_scc (ib, data_in, len, entry_len);
+}
+ return lto_input_tree_1 (ib, data_in, tag, 0);
}
[Bug tree-optimization/62035] New: [4.9 Regresion] wrong code building libapache-mod-perl with -O1, works with -O1 -fno-tree-dse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62035 Bug ID: 62035 Summary: [4.9 Regresion] wrong code building libapache-mod-perl with -O1, works with -O1 -fno-tree-dse Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Created attachment 33260 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33260action=edit test case [forwarded from http://bugs.debian.org/754901] libapache2-mod-perl2 build segfaults in the test suite when built with gcc 4.9 (r213317) with -O1 or higher, building with -O1 -fno-tree-dse works around it. seen at least on x86_64-linux-gnu. attributing one function with __attribute__((optimize(-fno-tree-dse))) modperl_enc.c (modperl_env_table_populate) is enough to avoid the segfaults in the test suite. The diff in the assembler is: --- ok/modperl_env.s2014-08-06 12:42:36.714269110 + +++ bad/modperl_env.s 2014-08-06 12:40:44.441445210 + @@ -118,7 +118,6 @@ .LVL15: movq%rax, %r14 .LVL16: - movq%rax, 40(%rsp) subq$8, %rsp .cfi_def_cfa_offset 120 pushq $0
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874
--- Comment #8 from Uroš Bizjak ubizjak at gmail dot com ---
After lots of debugging...
The problem is with the label that is passed as an argument to
__go_set_defer_retaddr. In function main.$thunk0, in _.179r.cse1 dump, we have:
...
(insn 7 3 8 2 (set (reg:DI 84)
(high:DI (label_ref:DI 47))) rr.go:57 236 {*movdi}
(insn_list:REG_LABEL_OPERAND 47 (nil)))
(insn 8 7 9 2 (set (reg:DI 83)
(lo_sum:DI (reg:DI 84)
(label_ref:DI 47))) rr.go:57 230 {*movdi_er_low_l}
(insn_list:REG_LABEL_OPERAND 47 (expr_list:REG_EQUAL (label_ref:DI 47)
(nil
(insn 9 8 10 2 (set (reg:DI 16 $16)
(reg:DI 83)) rr.go:57 236 {*movdi}
(nil))
(call_insn 10 9 11 2 (parallel [
(set (reg:DI 0 $0)
(call (mem:DI (symbol_ref:DI (__go_set_defer_retaddr) [flags
0x41] function_decl 0x266a900 __go_set_defer_retaddr) [0
__go_set_defer_retaddr S8 A64])
(const_int 0 [0])))
(use (reg:DI 29 $29))
(clobber (reg:DI 26 $26))
]) rr.go:57 357 {*call_value_osf_1_er}
(expr_list:REG_CALL_DECL (symbol_ref:DI (__go_set_defer_retaddr) [flags
0x41] function_decl 0x266a900 __go_set_defer_retaddr)
(nil))
(expr_list:DI (use (reg:DI 16 $16))
(nil)))
...
(call_insn 46 45 47 5 (parallel [
(call (mem:DI (reg/f:DI 80 [ D.1014 ]) [0 *_42 S8 A64])
(const_int 4048 [0xfd0]))
(use (reg:DI 29 $29))
(clobber (reg:DI 26 $26))
]) rr.go:57 210 {*call_osf_1_er}
(expr_list:REG_DEAD (reg/f:DI 80 [ D.1014 ])
(expr_list:REG_DEAD (reg:DI 21 $21)
(expr_list:REG_DEAD (reg:DI 20 $20)
(expr_list:REG_DEAD (reg:DI 19 $19)
(expr_list:REG_DEAD (reg:DI 18 $18)
(expr_list:REG_DEAD (reg:DI 17 $17)
(expr_list:REG_DEAD (reg:DI 16 $16)
(expr_list:REG_CALL_DECL (nil)
(nil)
(expr_list (use (reg:DI 21 $21))
(expr_list (use (reg:DI 20 $20))
(expr_list (use (reg:DI 19 $19))
(expr_list (use (reg:DI 18 $18))
(expr_list (use (reg:DI 17 $17))
(expr_list (use (reg:DI 16 $16))
(expr_list:BLK (use (mem:BLK (reg/f:DI 30 $30) [0
S4048 A64]))
(nil)
;; succ: 6 [100.0%] (FALLTHRU)
;; lr out 15 [$15] 26 [$26] 29 [$29] 30 [$30] 31 [AP] 63 [FP]
;; live out 15 [$15] 29 [$29] 30 [$30] 31 [AP] 63 [FP]
;; basic block 6, loop depth 0, count 0, freq 1, maybe hot
;; prev block 5, next block 7, flags: (REACHABLE, RTL, MODIFIED)
;; pred: 2 [39.0%]
;; 5 [100.0%] (FALLTHRU)
;; bb 6 artificial_defs: { }
;; bb 6 artificial_uses: { u-1(15){ }u-1(29){ }u-1(30){ }u-1(31){ }u-1(63){ }}
;; lr in15 [$15] 26 [$26] 29 [$29] 30 [$30] 31 [AP] 63 [FP]
;; lr use 15 [$15] 29 [$29] 30 [$30] 31 [AP] 63 [FP]
;; lr def 81
;; live in 15 [$15] 29 [$29] 30 [$30] 31 [AP] 63 [FP]
;; live gen 81
;; live kill
(code_label/s 47 46 48 6 2 (retaddr) [5 uses])
(note 48 47 49 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(insn 49 48 52 6 (set (reg:DI 81 [ retval ])
(const_int 0 [0])) rr.go:57 236 {*movdi}
(nil))
succ: 8 [100.0%] (FALLTHRU)
Unfortunatelly, this is not a robust approach, since in a follow-up
_.180r.fwprop1 pass (insn 49) propagates to function return value, leaving:
(code_label/s 47 46 48 6 2 (retaddr) [5 uses])
(note 48 47 52 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
;; succ: 8 [100.0%] (FALLTHRU)
The following 181r.cprop pass removes the label (also updates passed argument
to __go_set_defer_retaddr in (insn 7) and (insn 8)) and merges bb after a thunk
call:
(insn 7 3 8 2 (set (reg/f:DI 84)
(high:DI (label_ref:DI [47 deleted]))) rr.go:57 236 {*movdi}
(insn_list:REG_LABEL_OPERAND 47 (nil)))
(insn 8 7 9 2 (set (reg/f:DI 83)
(lo_sum:DI (reg/f:DI 84)
(label_ref:DI [47 deleted]))) rr.go:57 230 {*movdi_er_low_l}
(expr_list:REG_DEAD (reg/f:DI 84)
(insn_list:REG_LABEL_OPERAND 47 (expr_list:REG_EQUAL (label_ref:DI [47
deleted])
(nil)
...
(call_insn 46 45 47 5 (parallel [
(call (mem:DI (reg/f:DI 80 [ D.1014 ]) [0 *_42 S8 A64])
(const_int 4048 [0xfd0]))
(use (reg:DI 29 $29))
(clobber (reg:DI 26 $26))
]) rr.go:57 210 {*call_osf_1_er}
(expr_list:REG_DEAD (reg/f:DI 80 [ D.1014 ])
(expr_list:REG_DEAD (reg:DI 21 $21)
(expr_list:REG_DEAD (reg:DI 20 $20)
(expr_list:REG_DEAD (reg:DI 19 $19)
(expr_list:REG_DEAD (reg:DI 18 $18)
(expr_list:REG_DEAD (reg:DI 17 $17)
(expr_list:REG_DEAD (reg:DI 16 $16)
[Bug tree-optimization/62035] [4.9 Regresion] wrong code building libapache-mod-perl with -O1, works with -O1 -fno-tree-dse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62035 --- Comment #1 from Matthias Klose doko at gcc dot gnu.org --- seen with r213518 on the trunk as well
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874
--- Comment #9 from Uroš Bizjak ubizjak at gmail dot com ---
To illustrate unreliable approach, please compile following test:
--cut here--
extern void foo (void *);
int test(void)
{
__label__ bla;
foo (bla);
bla:
return 0;
}
--cut here--
gcc -O2:
test:
.L2:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
movl$.L2, (%esp)
callfoo
xorl%eax, %eax
leave
ret
The passed argument doesn't represent return address.
[Bug target/61749] arm_neon.h _lane and _n intrinsics can cause ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61749 --- Comment #3 from ktkachov at gcc dot gnu.org --- vqdmlal_lane_s16 expects an immediate/literal lane number as the fourth argument and the builtin expansion code in aarch64-builtins.c is actually equipped to error out when given a variable (in the SIMD_ARG_CONSTANT case of aarch64_simd_expand_args). However the type qualifiers for vqdmlal_lane_s16 are the QUADOP qualifiers which don't enforce qualifier_immediate on the builtin, thus falling into the SIMD_ARG_COPY_TO_REG and later on failing the CONST_INT_P assert when processing the lane numbers. If I give qualifier_immediate to the 4th argument I get a more helpful: error: incompatible type for argument 4, expected 'const int' message but the compiler still tries to proceed and ends up ICEing anyway.
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874 --- Comment #10 from Andreas Schwab sch...@linux-m68k.org --- If you never use goto *exp in the same function the value of label is undefined.
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874 --- Comment #11 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Andreas Schwab from comment #10) If you never use goto *exp in the same function the value of label is undefined. I did try adding goto bla: just before label, but never managed to get something around return address. Care to post and example, please?
[Bug tree-optimization/62035] [4.9/4.10 Regresion] wrong code building libapache-mod-perl with -O1, works with -O1 -fno-tree-dse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62035 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.2
[Bug lto/62034] ICE for big statically initialized arrays compiled with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62034 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Aug 6 13:53:09 2014 New Revision: 213664 URL: https://gcc.gnu.org/viewcvs?rev=213664root=gccview=rev Log: 2014-08-06 Richard Biener rguent...@suse.de PR lto/62034 * lto-streamer-in.c (lto_input_tree_1): Assert we do not read SCCs here. (lto_input_tree): Pop SCCs here. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-in.c
[Bug lto/62034] ICE for big statically initialized arrays compiled with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62034 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874 --- Comment #12 from Ian Lance Taylor ian at airs dot com --- Thanks for the analysis. See also PR 60406. Dominik sent me a patch for 60406 but 1) he has no copyright assignment; 2) I think that his patch does not work for SJLJ exceptions.
[Bug ipa/61393] [trans-mem] O3 optimization level constant propagation problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61393 --- Comment #7 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Wed Aug 6 13:59:18 2014 New Revision: 213666 URL: https://gcc.gnu.org/viewcvs?rev=213666root=gccview=rev Log: 2014-08-06 Martin Jambor mjam...@suse.cz PR ipa/61393 * cgraphclones.c (cgraph_node::create_clone): Also copy tm_clone. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphclones.c
[Bug ipa/61393] [trans-mem] O3 optimization level constant propagation problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61393 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Jambor jamborm at gcc dot gnu.org --- Hopefully fixed even on trunk.
[Bug c++/62036] New: Braced-init-list issuing -Wsequence-point warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62036
Bug ID: 62036
Summary: Braced-init-list issuing -Wsequence-point warning
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dacamara.cameron at gmail dot com
#include algorithm
#include iostream
#include iterator
#include thread
int main() {
int arr[10];
std::iota(std::begin(arr), std::end(arr), 1);
using itr_t = decltype(std::begin(arr));
// the function that will display each element
auto f = [] (itr_t first, itr_t last) {while (first != last)
std::cout*(first++)' ';};
// we have 3 threads so we need to figure out the ranges for each thread to
show
int increment = std::distance(std::begin(arr), std::end(arr)) / 3;
auto first= std::begin(arr);
auto to = first + increment;
auto last = std::end(arr);
std::thread threads[3] = {
std::thread{f, first, to},
std::thread{f, (first = to), (to += increment)},
std::thread{f, (first = to), last} // go to last here to account for
odd array sizes
};
for (auto t : threads) t.join();
}
I'm getting the sequence point warning with this piece of code and when I
execute it the thread at threads[1] prints nothing whatsoever. This should be
well defined according to the standard (I'm using sec. 8.5.4.4 as reference).
The fact that gcc even issues the -Wsequence-point warning is indicative that
the standard isn't being followed.
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #13 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Ian Lance Taylor from comment #12) Thanks for the analysis. See also PR 60406. Dominik sent me a patch for 60406 but 1) he has no copyright assignment; 2) I think that his patch does not work for SJLJ exceptions. Actually, this remaining problem is the same as PR60406. The original problem is fixed.
[Bug go/60406] reflect.go:test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-06 CC||ubizjak at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- This problem also happens on alpha, please see analysis at [1]. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874#c8
[Bug c/62037] New: cannot pass 'int **' as a 'int const* const*' parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62037 Bug ID: 62037 Summary: cannot pass 'int **' as a 'int const* const*' parameter Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mrolnik at gmail dot com Created attachment 33261 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33261action=edit .i file when I pass 'int **' object as a function parameter declares as 'int const* const*' I get a warning (see below) Using built-in specs. COLLECT_GCC=c:\MinGW\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T Thread model: win32 gcc version 4.8.1 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=pentiumpro' c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/cc1.exe -E -quiet -v -iprefix c:\mingw\bin\../lib/gcc/mingw32/4.8.1/ test.c -mtune=generic -march=pentiumpro -fpch-preprocess -o test.i ignoring duplicate directory c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/include ignoring duplicate directory c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/../../../../include ignoring duplicate directory /mingw/include ignoring duplicate directory c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/include-fixed ignoring duplicate directory c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/../../../../mingw32/include ignoring duplicate directory /mingw/include #include ... search starts here: #include ... search starts here: c:\mingw\bin\../lib/gcc/mingw32/4.8.1/include c:\mingw\bin\../lib/gcc/mingw32/4.8.1/../../../../include c:\mingw\bin\../lib/gcc/mingw32/4.8.1/include-fixed c:\mingw\bin\../lib/gcc/mingw32/4.8.1/../../../../mingw32/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=pentiumpro' c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/cc1.exe -fpreprocessed test.i -quiet -dumpbase test.c -mtune=generic -march=pentiumpro -auxbase test -version -o test.s GNU C (GCC) version 4.8.1 (mingw32) compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.8.1 (mingw32) compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 767202a405449496e68a54c4eee91a28 test.c: In function 'main': test.c:13:2: warning: passing argument 1 of 'foo' from incompatible pointer type [enabled by default] foo(pA); ^ test.c:3:6: note: expected 'const int * const*' but argument is of type 'int **' void foo(const int * const* a) ^ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=pentiumpro' c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/as.exe -v -o test.o test.s GNU assembler version 2.23.2 (mingw32) using BFD version (GNU Binutils) 2.23.2 COMPILER_PATH=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/;c:/mingw/bin/../libexec/gcc/;c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ LIBRARY_PATH=c:/mingw/bin/../lib/gcc/mingw32/4.8.1/;c:/mingw/bin/../lib/gcc/;c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/lib/;c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=pentiumpro' c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/collect2.exe -Bdynamic c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/lib/crt2.o c:/mingw/bin/../lib/gcc/mingw32/4.8.1/crtbegin.o -Lc:/mingw/bin/../lib/gcc/mingw32/4.8.1 -Lc:/mingw/bin/../lib/gcc -Lc:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/lib -Lc:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../.. test.o -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt c:/mingw/bin/../lib/gcc/mingw32/4.8.1/crtend.o
[Bug c/62037] cannot pass 'int **' as a 'int const* const*' parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62037 --- Comment #1 from Michael Rolnik mrolnik at gmail dot com --- Created attachment 33262 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33262action=edit compiler output
[Bug rtl-optimization/61608] [4.10 regression] FAIL: gcc.target/arm/epilog-1.c scan-assembler tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61608 jgreenhalgh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from jgreenhalgh at gcc dot gnu.org --- This looks resolved to me.
