Re: Plus Reload
On Wed, Jan 12, 2011 at 8:27 AM, Ian Lance Taylor i...@google.com wrote: Gidi Nave gidi.nav...@gmail.com writes: On Tue, Jan 11, 2011 at 7:22 PM, Ian Lance Taylor i...@google.com wrote: Gidi Nave gidi.nav...@gmail.com writes: On Tue, Jan 11, 2011 at 5:34 PM, Ian Lance Taylor i...@google.com wrote: So why doesn't d1 = d1 + -96 match the last instruction there? because it's: add d,d unsigned we don't have: add d,d signed and in this case we need: d = r + (-96) Addition of signed and unsigned numbers is the same operation at the machine level. Are there limitations on the signed value? If so, is there is a sub instruction? There are limitation for the signed value for D class registers. There is a sub instruction for D registers, but it's limited to U5 (unsigned of 5 bits) which is not the case here. Thanks. Since we don't know the details of your processor, we could be more helpful if you provided this sort of information up front. It sounds like you are saying that there is no way to subtract 96 without using an extra register. Is that correct? If that is the case, then I agree with Jeff that you are going to need to define a secondary reload. Look at TARGET_SECONDARY_RELOAD in the docs. By the way, if the restrictions on addition (which you did not describe) are less severe than the restrictions on subtraction, then you should consider adjusting your frame pointer so that most stack slots are at a positive offset rather than a negative one. I don't know if that is what is going on here, though a negative offset is certainly unusual. Ian Hi Ian, There is no way to subtract 96 without the extra register. The secondary reload worked great !!! Thanks! Regarding the frame pointer - in my case it was the frame pointer but our addition/subtract instructions options are similar (for the same register classes), so adjusting the frame pointer won't do any good. One more question: GCC usually knows how to handle cases which need decomposition of expressions due to architecture limitations. In my case it didn't know. How can I foreseen additional such cases, in order to avoid compilation crush? Thanks, Gidi.
Re: Find a new maintainer for option handling?
On Wed, Jan 12, 2011 at 4:10 AM, Jie Zhang j...@codesourcery.com wrote: Dear Steering Committee: The current listed maintainer for option handling is: option handling Neil Booth n...@daikokuya.co.uk But I'm wondering if Neil is still active. There are no replies to my recent pings from that email address. The last recorded commit from him in GCC was on 2005-01-19, which was nearly 6 years ago. So I guess he might have not worked on GCC. If this is true, how about assigning a new maintainer for option handling? Option handling maintainership should be unified with driver maintainership IMNSHO, as they are closely related. Richard. Regards, -- Jie Zhang
Re: Find a new maintainer for option handling?
On 01/12/2011 06:07 PM, Richard Guenther wrote: On Wed, Jan 12, 2011 at 4:10 AM, Jie Zhangj...@codesourcery.com wrote: Dear Steering Committee: The current listed maintainer for option handling is: option handling Neil Booth n...@daikokuya.co.uk But I'm wondering if Neil is still active. There are no replies to my recent pings from that email address. The last recorded commit from him in GCC was on 2005-01-19, which was nearly 6 years ago. So I guess he might have not worked on GCC. If this is true, how about assigning a new maintainer for option handling? Option handling maintainership should be unified with driver maintainership IMNSHO, as they are closely related. I agree. I think Joseph is the best candidate for the maintainer of the option handling since he made the most changes of gcc/opts-common.c. He is already the maintainer of the driver. If we unify these two maintainerships, we save one line of MAINTAINERS. :-) Regards, -- Jie Zhang
Dumb idea for accelerating FOSS development
First, the problem: I've got a C library I want to share. There are many users who want to use it. This should be as easy as breathing, but it's not! My users and I face what I'm calling GNU/Linux Innovation Red Tape. This library is two files: sonic.c and sonic.h. To share it in Debian, first, I had to learn how to make a clean Debian package. Something like 30 files are involved, and in my case a few days of learning and laboring. Next, I have to grovel on the debian-mentor's list, and pray that Debian Sponsor Gods will take pity on me. No response from the Sponsor Gods so far... maybe I'll have more luck after they've finished the current release. Shouldn't we be ashamed that getting a package into Debian is harder than publishing an app for iPhones? Assuming I find a Debian sponsor, my package will be uploaded to Unstable, then Testing, and after a few years, Stable. Guess where my package has to be before my users are willing to link to it? Debian Stable. We're hosed. There's just no freaking way for my users to use my library. You know what they do? Every one of them bypasses the Innovation Red Tape, and simply copies my source code directly into their application. How's that as a reuse paradigm? My dumb idea for today is a way to break through this red tape. Unfortunately, while I could implement this idea in a few days, the red tape would keep it in limbo so long that I'll likely die of old age before it gets into Debian Stable. Oh, well... here's the dumb idea anyway... In short, support a syntax in gcc like: $ gcc myprog.c -lgit://github/~waywardgeek/sonic=0.1 In theory, this would cause gcc to do the following: - Check and see if the requested library has already been downloaded and built, and still in the cache - If not, download the latest compatible signed version, verify the signature, and compile it - link to the library in the cache A feature like this would make sharing C libraries as easy as breathing. My users wouldn't even have to 'apt-get install libsonic0-dev'. They would stop copying my source code, and just link to my library. Sharing of C libraries in FOSS land might increase dramatically. The year of GNU/Linux on the desktop would finally come, and we'd all march off to Paradise as heroes. Or not. Anyway, just my dumb idea for the day... If through some miracle this particular dumb idea appeals to the GCC Gods, I volunteer to write it. Bill
Re: Dumb idea for accelerating FOSS development
On Wed, Jan 12, 2011 at 06:07:48AM -0500, Bill Cox wrote:
Unfortunately, while I could implement this idea in a few days, the
red tape would keep it in limbo so long that I'll likely die of old
age before it gets into Debian Stable. Oh, well... here's the dumb
idea anyway... In short, support a syntax in gcc like:
$ gcc myprog.c -lgit://github/~waywardgeek/sonic=0.1
In theory, this would cause gcc to do the following:
- Check and see if the requested library has already been
downloaded and built, and still in the cache
- If not, download the latest compatible signed version, verify
the signature, and compile it
- link to the library in the cache
At a first glance, I find your idea crazy but nice (but what about header
files *.h of the requested library?). I would be delighted to have it. Maybe
others don't think that way (in particular, those not working on Linux, and
those not working on a compiler running with a network connection).
Very probably ccache is the better place to implement that, since it already do
some (preprocessed) source code cache. http://ccache.samba.org/
However, my personal feeling is that GCC is quite conservative on the user
features it is accepting. So I won't bet that your idea will be positively
accepted.
Nevertheless, you could propose a patch to GCC to implement what you are
dreaming of. See http://gcc.gnu.org/contribute.html for more (and don't
forget the legal part, i.e. the copyright assignment to FSF).
I do find your idea nice, but I am quite pessimistic on the chances it has
to get accepted into the GCC trunk. Don't expect others to work on it. If
you really want it, work hard to make a patch for it and propose that
working patch.
Besides, what you propose probably need mostly also a support in the build
tools, in particular inside GNU make. Probably, ccache make are a better
place for it.
So while I am intellectually appealed by your idea, I am quite pessimistic
in practice to get it accepted (even within several years), and it probably
belongs more to other tools (make, ccache) than to GCC.
However, to have the GCC Community to consider your idea, you'll have to
first show a patch implementing it.
Maybe, what you are suggesting would be better dealt with a plugin machinery
inside gcc itself (we don't have any plugin hooks inside gcc/gcc.h yet).
Regards.
PS. I would believe most GCC contributors won't be interested.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: kfreebsd-gnu etc. issues
On Wed, 12 Jan 2011, Robert Millan wrote: Hi Joseph I'll look at more detail at the other problems, but first it seems that non-Linux GNU targets are currently broken because many declarations that are not Linux-specific have been added to the Linux-specific sections of config.gcc. I don't think they are necessarily broken - and if they are, it is because of Linux-specific headers being used in non-Linux-specific code, not the other way round. Should I wait untill your patch is merged to fix this? No. Btw, your patch overhauls linux.h but not i386/linux64.h which is in the same situation as you described. Indeed. While the subdirectory */*linux*.h headers that are used by non-Linux-kernel targets need splitting up, and removing from the headers used by non-Linux-kernel targets, separating this from splitting up the architecture-independent header leads to smaller patches such that it is easier for the author and patch reviewer to convince themselves that there are no unintended changes to semantics. Furthermore, it was while looking at splitting up the i386/*.h headers that I found the issues raised in my message you're replying to. And two of those four issues are issues where I am seeking information from someone familiar with the *-kfreebsd-gnu, *-knetbsd-gnu and *-kopensolaris-gnu targets in order to determine which definitions actually belong in Linux-kernel headers and which in GNU-userspace headers. So if you could clarify the answers to my questions regarding PT_GNU_STACK and signal frames for those targets (with or without fixing any bugs for those targets indicated by the answers to those questions), that would help determine the correct division of those headers. In turn, actually stopping non-Linux-kernel targets from using config/linux.h depends on splitting up the subdirectory linux.h files, because of how those interact with config/linux.h. -- Joseph S. Myers jos...@codesourcery.com
Re: kfreebsd-gnu etc. issues
2011/1/12 Joseph S. Myers jos...@codesourcery.com: I don't think they are necessarily broken - and if they are, it is because of Linux-specific headers being used in non-Linux-specific code, not the other way round. Actually, it's a different problem. I'll just prepare a patch and send it, it'll be obvious by reading the patch. So if you could clarify the answers to my questions regarding PT_GNU_STACK and signal frames for those targets (with or without fixing any bugs for those targets indicated by the answers to those questions), that would help determine the correct division of those headers. Ok, I'll answer what I can in your previous mail. -- Robert Millan
Re: Dumb idea for accelerating FOSS development
2011/1/12 Bill Cox waywardg...@gmail.com: $ gcc myprog.c -lgit://github/~waywardgeek/sonic=0.1 You already have this, it's called FUSE. E.g. $ sshfs $publicrepo $tmp $ gcc myprog.c -I$tmp $tmp/sonic.c If you want it to speak GIT protocol, just write a GIT extension, etc. -- Robert Millan
Re: Dumb idea for accelerating FOSS development
Hi, On Wed, Jan 12, 2011 at 01:43:51PM +0100, Basile Starynkevitch wrote: On Wed, Jan 12, 2011 at 06:07:48AM -0500, Bill Cox wrote: Unfortunately, while I could implement this idea in a few days, the red tape would keep it in limbo so long that I'll likely die of old age before it gets into Debian Stable. Oh, well... here's the dumb idea anyway... In short, support a syntax in gcc like: $ gcc myprog.c -lgit://github/~waywardgeek/sonic=0.1 In theory, this would cause gcc to do the following: - Check and see if the requested library has already been downloaded and built, and still in the cache - If not, download the latest compatible signed version, verify the signature, and compile it - link to the library in the cache At a first glance, I find your idea crazy but nice (but what about header files *.h of the requested library?). I would be delighted to have it. Maybe others don't think that way (in particular, those not working on Linux, and those not working on a compiler running with a network connection). Very probably ccache is the better place to implement that, since it already do some (preprocessed) source code cache. http://ccache.samba.org/ However, my personal feeling is that GCC is quite conservative on the user features it is accepting. So I won't bet that your idea will be positively accepted. Well, it is not exactly what you are asking for, but the depot_tools used in the chromium developement might be a solution: http://www.chromium.org/developers/how-tos/depottools The can keep track of different libraries checkout out from svn or git repositories, and calling gclient sync connects to all repositories belonging to the project and verifies that all files are up-to-date. May be that would be a better starting point than using gcc? Axel
Re: Plus Reload
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/12/11 01:45, Gidi Nave wrote: One more question: GCC usually knows how to handle cases which need decomposition of expressions due to architecture limitations. In my case it didn't know. How can I foreseen additional such cases, in order to avoid compilation crush? I'm not sure there is a reasonable way other than experience and intimate knowledge of how reload works. I haven't done any measurements, but I see more questions/issues being raised by developers doing their own ports with regards to reloading than any other part of the compiler. That's no great surprise, since reload is probably the nastiest pass of the compiler and even those of us with significant experience still struggle with corner case reload problems. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNLbGiAAoJEBRtltQi2kC75ngIAKJJhYdYgQV2l0LsZCxUbhb9 OxHXr2CBbEZgpT6VRIrTJnJ51QEjxscLCBo0Ip/ZnpMiulb5S+hmyjrQJxXxEyPI pF64uV6Gla0qcGgABrVkPWi6UEPDpvkrD0mljpcsqdK6tYtPFIww8sYMC+LecdUM GMan7eXcKxgVu51c2xkp57afg9xuVcZXwHAcME74MkYC37vT0KGAPKpRIBum+ues PL+2hOfa7wzQ6SbM9d7sVrU4o029IzWEgPPYwWVrw0NSQlIHbAnOf6Q0V+Y9jeeb M36Vh/ynzExLmFq1kmESTEeOAqEg9r97mwaiaXPK4vYZEc3r9YMjq1rRUhEFO48= =6tO+ -END PGP SIGNATURE-
Re: kfreebsd-gnu etc. issues
2011/1/1 Joseph S. Myers jos...@codesourcery.com: [...] I found several possible problems with the configurations for *-kfreebsd-gnu, *-knetbsd-gnu and *-kopensolaris-gnu. Ok. Unless indicated otherwise, my answers below apply to *-kfreebsd-gnu, which is the only in these 3 systems that is actively maintained. For the other two I wouldn't worry about either guessing or leaving them as-is. If minor breakage happens it's unlikely to bother anyone. * The headers config/kfreebsd-gnu.h etc. override GLIBC_DYNAMIC_LINKER. But the 64-bit configurations x86_64-*-kfreebsd*-gnu and x86_64-*-knetbsd*-gnu do not appear to use any header that would override GLIBC_DYNAMIC_LINKER32 and GLIBC_DYNAMIC_LINKER64, which are what LINK_SPEC in linux64.h actually uses. Thus those configurations would use Linux-specific dynamic linker settings, which seems unlikely to be as intended. It's not as intended. On amd64 we use /lib/ld.so.1 and /lib/ld-kfreebsd-x86-64.so.1. * These configurations use file_end_indicate_exec_stack to use the PT_GNU_STACK convention. While some of the implementation of this is in the GNU linker and glibc, it also requires kernel support for correct operation. Do all these kernels support this convention, or should this code actually be disabled for them in GCC and glibc? I'm not familiar with PT_GNU_STACK. Does a working _dl_make_stack_executable() in glibc [1] indicate it's supported? [1] http://svn.debian.org/viewsvn/glibc-bsd/trunk/glibc-ports/kfreebsd/dl-execstack.c?revision=1685view=markup * The kfreebsd-gnu and knetbsd-gnu configurations use linux-unwind.h (kopensolaris-gnu disables this). They define REG_NAME to adapt linux-unwind.h to their system headers. But linux-unwind.h also contains hardcoded checks for the particular instructions, complete with hardcoded Linux syscall numbers, in Linux signal trampolines. I'm sorry. It seems this would be my fault (I introduced this with the first kfreebsd-gnu port). Do the FreeBSD and NetBSD kernels really use identical instructions? Definitely not. But it's strange we didn't notice, we've been using it for several years. Does this code do anything useful on those systems? If it's useful (possibly with some fixes) then linux-unwind.h ought to be renamed; The only thing I know for sure is that those 2 syscalls don't work. Is there any possibility that linux-unwind.h is useful for GNU/kFreeBSD in its current state? I don't understand this code, but what I can do is confirm that disabling linux-unwind.h doesn't cause any breakage. Then we could disable it untill/unless someone more clued than me ports it to kFreeBSD. Would this be ok? * A minor point: TARGET_VERSION, referring to Linux, is not overridden by these configurations. Perhaps a common (or a fallback) string mentioning GNU and/or glibc would fit. But where's this displayed anyway? -- Robert Millan
Re: Dumb idea for accelerating FOSS development
On Wed, Jan 12, 2011 at 8:43 AM, Axel Freyn axel-fr...@gmx.de wrote: Hi, On Wed, Jan 12, 2011 at 01:43:51PM +0100, Basile Starynkevitch wrote: On Wed, Jan 12, 2011 at 06:07:48AM -0500, Bill Cox wrote: Unfortunately, while I could implement this idea in a few days, the red tape would keep it in limbo so long that I'll likely die of old age before it gets into Debian Stable. Oh, well... here's the dumb idea anyway... In short, support a syntax in gcc like: $ gcc myprog.c -lgit://github/~waywardgeek/sonic=0.1 In theory, this would cause gcc to do the following: - Check and see if the requested library has already been downloaded and built, and still in the cache - If not, download the latest compatible signed version, verify the signature, and compile it - link to the library in the cache At a first glance, I find your idea crazy but nice (but what about header files *.h of the requested library?). I would be delighted to have it. Maybe others don't think that way (in particular, those not working on Linux, and those not working on a compiler running with a network connection). Very probably ccache is the better place to implement that, since it already do some (preprocessed) source code cache. http://ccache.samba.org/ However, my personal feeling is that GCC is quite conservative on the user features it is accepting. So I won't bet that your idea will be positively accepted. Well, it is not exactly what you are asking for, but the depot_tools used in the chromium developement might be a solution: http://www.chromium.org/developers/how-tos/depottools The can keep track of different libraries checkout out from svn or git repositories, and calling gclient sync connects to all repositories belonging to the project and verifies that all files are up-to-date. May be that would be a better starting point than using gcc? Axel Well, after a short nap, the thought of fixing this in gcc seems even dumber to me, though the problem is quite real. Another tool called before gcc could get the header and library files into a place where they could be used. It could even be compiler independent. A bit of Googling reveals Zero Install. Looks like these guys are trying to tackle the problem. Bill
Re: Dumb idea for accelerating FOSS development
On 12/01/2011 12:07, Bill Cox wrote: First, the problem: I've got a C library I want to share. There are many users who want to use it. This should be as easy as breathing, but it's not! My users and I face what I'm calling GNU/Linux Innovation Red Tape. This library is two files: sonic.c and sonic.h. To share it in Debian, first, I had to learn how to make a clean Debian package. Something like 30 files are involved, and in my case a few days of learning and laboring. Next, I have to grovel on the debian-mentor's list, and pray that Debian Sponsor Gods will take pity on me. No response from the Sponsor Gods so far... maybe I'll have more luck after they've finished the current release. Shouldn't we be ashamed that getting a package into Debian is harder than publishing an app for iPhones? Assuming I find a Debian sponsor, my package will be uploaded to Unstable, then Testing, and after a few years, Stable. Guess where my package has to be before my users are willing to link to it? Debian Stable. We're hosed. There's just no freaking way for my users to use my library. You know what they do? Every one of them bypasses the Innovation Red Tape, and simply copies my source code directly into their application. How's that as a reuse paradigm? My dumb idea for today is a way to break through this red tape. Unfortunately, while I could implement this idea in a few days, the red tape would keep it in limbo so long that I'll likely die of old age before it gets into Debian Stable. Oh, well... here's the dumb idea anyway... In short, support a syntax in gcc like: $ gcc myprog.c -lgit://github/~waywardgeek/sonic=0.1 In theory, this would cause gcc to do the following: - Check and see if the requested library has already been downloaded and built, and still in the cache - If not, download the latest compatible signed version, verify the signature, and compile it - link to the library in the cache A feature like this would make sharing C libraries as easy as breathing. My users wouldn't even have to 'apt-get install libsonic0-dev'. They would stop copying my source code, and just link to my library. Sharing of C libraries in FOSS land might increase dramatically. The year of GNU/Linux on the desktop would finally come, and we'd all march off to Paradise as heroes. Or not. Anyway, just my dumb idea for the day... If through some miracle this particular dumb idea appeals to the GCC Gods, I volunteer to write it. Bill I can see the point of your idea, but I think it's too limited, and gcc is the wrong place to put it. Are you familiar with Python? Python has a system called easy_install, which lets you easy download libraries or packages for Python (as Python is interpreted, there is no distinction between development libraries and runtime libraries). If your package were a python library, you would publish it in at one of the commonly used Python package library sites, and users could then type easy_install sonic and use your library. I believe Perl has a similar idea, as does (La)TeX. The reason I think gcc is the wrong place for such a feature, is that there are many parts to a library. Most importantly, there is the headers, the source files, the configuration files, the documentation, the static libraries, and the dynamic libraries. Many of these parts need to be installed before getting as far as the gcc command line. Secondly, git is just one of many ways to get hold of the files. A useful tool would support a range of protocols, including http, svn, mg, etc. Practically speaking, this means a separate tool and plugins. Thirdly, to be truly useful the tool should support searching of a number of standard sites (github, sourceforge, google code, etc.) automatically, to make the job as easy as possible for the user. Fourthly, it should support additional features such as searching, updating, etc. In other words, what I am really suggesting here is a sort of specialised package manager that can be used in addition to the distribution's main package manager. Of course, it is important to consider conflicts with the distribution's libraries - who has priority if there are different versions?
Re: Plus Reload
On Wed, Jan 12, 2011 at 3:50 PM, Jeff Law l...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/12/11 01:45, Gidi Nave wrote: One more question: GCC usually knows how to handle cases which need decomposition of expressions due to architecture limitations. In my case it didn't know. How can I foreseen additional such cases, in order to avoid compilation crush? I'm not sure there is a reasonable way other than experience and intimate knowledge of how reload works. I haven't done any measurements, but I see more questions/issues being raised by developers doing their own ports with regards to reloading than any other part of the compiler. That's no great surprise, since reload is probably the nastiest pass of the compiler and even those of us with significant experience still struggle with corner case reload problems. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNLbGiAAoJEBRtltQi2kC75ngIAKJJhYdYgQV2l0LsZCxUbhb9 OxHXr2CBbEZgpT6VRIrTJnJ51QEjxscLCBo0Ip/ZnpMiulb5S+hmyjrQJxXxEyPI pF64uV6Gla0qcGgABrVkPWi6UEPDpvkrD0mljpcsqdK6tYtPFIww8sYMC+LecdUM GMan7eXcKxgVu51c2xkp57afg9xuVcZXwHAcME74MkYC37vT0KGAPKpRIBum+ues PL+2hOfa7wzQ6SbM9d7sVrU4o029IzWEgPPYwWVrw0NSQlIHbAnOf6Q0V+Y9jeeb M36Vh/ynzExLmFq1kmESTEeOAqEg9r97mwaiaXPK4vYZEc3r9YMjq1rRUhEFO48= =6tO+ -END PGP SIGNATURE- Ok, Thanks for the help! Gidi.
Re: kfreebsd-gnu etc. issues
On Wed, 12 Jan 2011, Robert Millan wrote: * These configurations use file_end_indicate_exec_stack to use the PT_GNU_STACK convention. While some of the implementation of this is in the GNU linker and glibc, it also requires kernel support for correct operation. Do all these kernels support this convention, or should this code actually be disabled for them in GCC and glibc? I'm not familiar with PT_GNU_STACK. Does a working _dl_make_stack_executable() in glibc [1] indicate it's supported? I think the glibc code is necessary but may not be sufficient; whatever kernel support there is or isn't, glibc needs to know how the kernel will have set things up (on Linux, based on PT_GNU_STACK for the dynamic linker, I think) in order to adjust it based on the PT_GNU_STACK of the executable and shared libraries. Probably it's possible to get this right without kernel support (if glibc does the right things at startup), in which case we could consider this a GNU userspace convention. The only thing I know for sure is that those 2 syscalls don't work. Is there any possibility that linux-unwind.h is useful for GNU/kFreeBSD in its current state? I don't see how it can be useful in its current state for any system using different syscall numbers. Maybe the code using a ucontext would be relevant given code checking for different (kernel-dependent) instructions. I don't understand this code, but what I can do is confirm that disabling linux-unwind.h doesn't cause any breakage. Then we could disable it untill/unless someone more clued than me ports it to kFreeBSD. Would this be ok? That makes sense to me. If disabled for non-Linux-kernel targets, the REG_NAME abstraction may as well be removed as not actually being useful at present. * A minor point: TARGET_VERSION, referring to Linux, is not overridden by these configurations. Perhaps a common (or a fallback) string mentioning GNU and/or glibc would fit. But where's this displayed anyway? In collect2 (only, for these targets; mips-tdump and mips-tfile also use it). I've also suggested that we should eliminate TARGET_VERSION completely (probably for 4.7) but while it's there, referring to Linux for these targets is wrong. -- Joseph S. Myers jos...@codesourcery.com
Re: Dumb idea for accelerating FOSS development
On 12 January 2011 14:07, Bill Cox wrote: Well, after a short nap, the thought of fixing this in gcc seems even dumber to me, though the problem is quite real. Another tool called before gcc could get the header and library files into a place where they could be used. It could even be compiler independent. gcc myprog.c $(magic-lib-installer $publicrepo) where magic-lib-installer takes care of any fetching, building and installing of the lib in $tmp, then printing the necessary -I$tmp/include, -L$tmp/lib and -lblah options for use by gcc. However it works, it shouldn't need changes to gcc.
Re: Adding Leon processor to the SPARC list of processors
Hi all, I'm in the early stages of a Leon-based project, and have been trying to put together a cross toolchain for it. I'm having some problems getting it configured and working correctly, and this proposed option would very likely help me a lot. Is there any time scale for implementation, or any plan for which release it'll make it into? Regards, Dave
Proposal for automatic generation of c++ header files
Hello all.
I have a idea for automatic generation of headers in a c++ program.
Having to maintain headers is a very time consuming task, and I think
we will all benefit from such a thing. The idea is the following:
Each time the compiler finds the pragma
#pragma autoinclude(foo.hpp)
it does the following:
1) searches the include path for the header foo.hpp.
2) if the header does not exist, then the compiler searches for the
file 'foo.cpp'
3) if the file 'foo.cpp' is found, then the header 'foo.hpp' is
generated automatically from the the .cpp file.
4) if the header exists, then the compiler compares the file dates of
the header and the implementation files. If the header is older than
the implementation file, then a new header is generated from the
implementation file.
When the compiler finds a declaration in a .cpp file that is 100% the
same as a declaration in a header file, then the declaration in the
implementation file is ignored, because it has been created
automatically in the header by the compiler. If there is a difference,
then an error is declared.
Example:
file main.cpp:
#pragma autoinclude (foo.hpp)
int main() {
Foo *foo = new Foo;
foo-bar();
foos.push_back(foo);
}
file foo.cpp:
#include list
class Foo {
public:
void bar() {
}
};
std::listFoo * foos;
static int data = 0;
The compiler generates the following header:
#ifndef FOO_HPP
#define FOO_HPP
#include list
class Foo {
public:
void bar();
};
extern std::listFoo * foos;
#endif //FOO_HPP
If such a feature existed, it would greatly speed up application
development for c++ applications.
Re: kfreebsd-gnu etc. issues
Robert Millan r...@gnu.org writes: I'm not familiar with PT_GNU_STACK. Does a working _dl_make_stack_executable() in glibc [1] indicate it's supported? [1] http://svn.debian.org/viewsvn/glibc-bsd/trunk/glibc-ports/kfreebsd/dl-execstack.c?revision=1685view=markup PT_GNU_STACK is a program header recognized by the Linux kernel when loading an ELF executable or shared library. If any executable or shared library has a PT_GNU_STACK segment for which the PF_X bit is set in the p_flags field, then the kernel will mark the stack as permitting execution (i.e., will mmap it with PROT_EXEC as well as PROT_READ and PROT_WRITE). _dl_make_stack_executable is a related but distinct mechanism which is used by the dynamic linker to make the stack executable when 1) the stack was loaded as non-executable; 2) there is now some reason to make the stack executable, e.g., a dlopen of a shared library which has a PT_GNU_STACK header indicating that an executable stack is required. As Joseph said, for the specific (and common) case of dynamically linked binaries it's possible to make this work without kernel support, under the assumption that the kernel runs the dynamic linker without an executable stack. However, for statically linked binaries, PT_GNU_STACK is only useful if the kernel supports it. All that said, I see little harm in using a PT_GNU_STACK header on binaries even if the kernel does not fully support them. Except for the small amount of wasted space in every .o file and every executable, but I lost that argument years ago. Ian
Re: Plus Reload
On 12/01/2011 13:50, Jeff Law wrote: On 01/12/11 01:45, Gidi Nave wrote: One more question: GCC usually knows how to handle cases which need decomposition of expressions due to architecture limitations. In my case it didn't know. How can I foreseen additional such cases, in order to avoid compilation crush? I'm not sure there is a reasonable way other than experience and intimate knowledge of how reload works. If your port makes it all the way through the testsuite without any ICEs, you can feel at least /statistically/ re-assured that it's not likely to run into problems during regular day-to-day use. cheers, DaveK
Re: Proposal for automatic generation of c++ header files
On 12/01/2011 16:22, Achilleas Margaritis wrote:
Hello all.
I have a idea for automatic generation of headers in a c++ program.
Having to maintain headers is a very time consuming task, and I think
we will all benefit from such a thing. The idea is the following:
Each time the compiler finds the pragma
#pragma autoinclude(foo.hpp)
it does the following:
1) searches the include path for the header foo.hpp.
2) if the header does not exist, then the compiler searches for the
file 'foo.cpp'
3) if the file 'foo.cpp' is found, then the header 'foo.hpp' is
generated automatically from the the .cpp file.
4) if the header exists, then the compiler compares the file dates of
the header and the implementation files. If the header is older than
the implementation file, then a new header is generated from the
implementation file.
When the compiler finds a declaration in a .cpp file that is 100% the
same as a declaration in a header file, then the declaration in the
implementation file is ignored, because it has been created
automatically in the header by the compiler. If there is a difference,
then an error is declared.
Example:
file main.cpp:
#pragma autoinclude (foo.hpp)
int main() {
Foo *foo = new Foo;
foo-bar();
foos.push_back(foo);
}
file foo.cpp:
#includelist
class Foo {
public:
void bar() {
}
};
std::listFoo * foos;
static int data = 0;
The compiler generates the following header:
#ifndef FOO_HPP
#define FOO_HPP
#includelist
class Foo {
public:
void bar();
};
extern std::listFoo * foos;
#endif //FOO_HPP
If such a feature existed, it would greatly speed up application
development for c++ applications.
I can see how such a feature could be useful, but is there any reason
why it should be part of gcc, rather than a separate program that takes
a cpp file and generates an hpp file? Such a program would be much
easier to develop and maintain than a new gcc pragma, and more flexible
(for example, it could be used with other compilers). Your timestamp
checking features are easily accomplished with make.
Re: Dumb idea for accelerating FOSS development
Bill Cox waywardg...@gmail.com writes: $ gcc myprog.c -lgit://github/~waywardgeek/sonic=0.1 In Go we have a program goinstall which looks at import statements and pulls in required libraries, where the libraries are named based on where the sources live. A similar process could work in the C/C++ world, based on #include statements. http://golang.org/cmd/goinstall/ Ian
Re: Proposal for automatic generation of c++ header files
Achilleas Margaritis axil...@gmail.com writes: I have a idea for automatic generation of headers in a c++ program. Having to maintain headers is a very time consuming task, and I think we will all benefit from such a thing. The idea is the following: Each time the compiler finds the pragma #pragma autoinclude(foo.hpp) it does the following: 1) searches the include path for the header foo.hpp. 2) if the header does not exist, then the compiler searches for the file 'foo.cpp' 3) if the file 'foo.cpp' is found, then the header 'foo.hpp' is generated automatically from the the .cpp file. 4) if the header exists, then the compiler compares the file dates of the header and the implementation files. If the header is older than the implementation file, then a new header is generated from the implementation file. It's an interesting idea. I think you are trying to create a module system for C++. You may want to take a look at www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2073.pdf . I think an approach along those lines might make more sense than inventing header files based on C++ files, and then modifying the language to make those invented header files work correctly. Ian
Re: Adding Leon processor to the SPARC list of processors
On 01/12/2011 09:17 AM, David Paterson wrote: Hi all, I'm in the early stages of a Leon-based project, and have been trying to put together a cross toolchain for it. I'm having some problems getting it configured and working correctly, and this proposed option would very likely help me a lot. Is there any time scale for implementation, or any plan for which release it'll make it into? The leon specific bare metal targets are in the SVN head. If you are using RTEMS, then you can use the RPMs we provide. Regards, Dave -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: Dumb idea for accelerating FOSS development
* Ian Lance Taylor: Bill Cox waywardg...@gmail.com writes: $ gcc myprog.c -lgit://github/~waywardgeek/sonic=0.1 In Go we have a program goinstall which looks at import statements and pulls in required libraries, where the libraries are named based on where the sources live. A similar process could work in the C/C++ world, based on #include statements. Oh. Has anybody tried to implement this for passing the appropriate -L/-l flags to the linker? And why isn't everybody doing this? 8-)
Re: [MIPS] Test case dspr2-MULT is failed
2011/1/7 Chung-Lin Tang clt...@codesourcery.com:
I analyzed this testcase regression a while earlier; the direct cause of
this is due to mips_order_regs_for_local_alloc(), which now serves as
MIPS' ADJUST_REG_ALLOC_ORDER macro.
The mips_order_regs_for_local_alloc() function seems to be written for
the old local-alloc.c, still left as the deprecated
ORDER_REGS_FOR_LOCAL_ALLOC macro after the transition to IRA (actually
not called at all during then), and relatively recently 'revived' after
a patch by Bernd that created the ADJUST_REG_ALLOC_ORDER macro went in.
So you have a local-alloc.c heuristic working in IRA, which seemed to
cause these regressions.
Removing mips_order_regs_for_local_alloc() will let this testcase pass;
of course the real fix should be to review the MIPS reg-ordering logic,
left for you MIPS people...
Chung-Lin
As I can see, mips_order_regs_for_local_alloc() is only used to
reorder $24 (T_REG) for MIPS16. Since current definition of
REG_ALLOC_ORDER for IRA is not {0,1,2,...} any more, the old loop
code,
for (i = 0; i FIRST_PSEUDO_REGISTER; i++)
reg_alloc_order[i] = i;
in mips_order_regs_for_local_alloc() seems inadequate. Because this
will override the definition of REG_ALLOC_ORDER.
Anyway, when I tried to rewrite the function to keep the register
order, the testcase is passed, but I can't see the speedup on my port.
Thanks,
Mingjie
[Bug tree-optimization/47265] New: [4.6 Regression] Error: SSA name in freelist but still referenced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47265
Summary: [4.6 Regression] Error: SSA name in freelist but still
referenced
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com
With GCC 4.6.0 20110108 (experimental):
= foo.c
struct S {
char a[3];
char b[3];
};
void bar(char *dst, const char *src, unsigned n)
{
while (n--)
*dst++ = *src ? *src++ : ' ';
}
void foo(struct S *s)
{
bar(s-a, s-b, 3);
}
$ gcc -S -O3 foo.c
foo.c: In function 'foo':
foo.c:12:6: error: SSA name in freelist but still referenced
D.1961_2
cc1: note: in statement
src_19 = [cond_expr] D.1974_11 != 0 ? src_20 : D.1961_2;
foo.c:12:6: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug fortran/47260] DLLEXPORT attribute requires additional capabilities to be useful
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47260 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-12 09:10:47 UTC --- Odd - I thought that procedures had always external linkage (TREE_PUBLIC) - unless they are internal in Fortran - or static in C. For variables, that's a different issue (cf. also PR 47030). The TREE_PUBLIC should be set (in this case) via gfc_create_function_decl, which calls build_function_decl. That function contains: if (!current_function_decl !sym-attr.entry_master !sym-attr.is_main_program) TREE_PUBLIC (fndecl) = 1; In principle, current_function_decl == NULL as it is not a contained procedure.
[Bug fortran/47266] New: Optimization: Declare PRIVATE module procedures as TREE_PUBLIC = 0 (static function)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47266 Summary: Optimization: Declare PRIVATE module procedures as TREE_PUBLIC = 0 (static function) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Found when thinking about PR 47260. PRIVATE module procedures are by construction not accessible outside the translation unit. Well, one can then simply mark them as static (in the C sense) by not setting TREE_PUBLIC to 1. For procedures one currently calls gfc_create_function_decl, which calls build_function_decl. That function contains: if (!current_function_decl !sym-attr.entry_master !sym-attr.is_main_program) TREE_PUBLIC (fndecl) = 1; Thus, adding !sym-attr.access == ACCESS_PRIVATE should be sufficient. Test case - Expected: With -O2 -c, nm only prints __m_MOD_pub - Current result, nm shows: 001e T __m_MOD_priv T __m_MOD_pub module m implicit none private :: priv public :: pub contains integer function priv() priv = 44 end function priv subroutine pub(a) integer :: a a = priv() end subroutine pub end module m
[Bug objc/46710] fast enumeration tests failing on ia64-suse-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46710 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Severity|critical|major --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-01-12 09:34:44 UTC --- I got access to an ia64-unknown-linux-gnu machine, and tried the failing testcases out there, but found that they are working there. :-( Thanks
[Bug fortran/47267] New: array constructor causing long compile times
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47267 Summary: array constructor causing long compile times Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch The following program needs about 40s to compile (-O0): cat test.f90 IMPLICIT NONE INTEGER, PARAMETER :: wp=8 INTEGER, PARAMETER :: Niter=3000 INTEGER, ALLOCATABLE, DIMENSION(:) :: perm1 INTEGER :: i ALLOCATE(perm1(Niter)) perm1=(/(i,i=1,Niter)/) END Time grows linearly with Niter.
[Bug fortran/47267] array constructor causing long compile times
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47267 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Keywords||compile-time-hog Known to fail||4.3.2, 4.6.0 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-12 09:43:31 UTC --- obviously removing the parameter attribute from niter makes compilation very fast. Presumably something down this call tree should not simplify stuff for too large constructors #0 0x76ca9ad9 in _int_malloc () from /lib64/libc.so.6 #1 0x76cacaa9 in malloc () from /lib64/libc.so.6 #2 0x00d9e9a9 in __gmp_default_allocate (size=8) at ../../gcc/gmp/memory.c:44 #3 0x00da39f5 in __gmpz_init (x=0x14f4038) at ../../../gcc/gmp/mpz/init.c:28 #4 0x004ebc39 in gfc_get_constant_expr (type=BT_INTEGER, kind=4, where=0x136b920) at ../../gcc/gcc/fortran/expr.c:160 #5 0x004ebd6b in gfc_get_int_expr (kind=value optimized out, where=value optimized out, value=0) at ../../gcc/gcc/fortran/expr.c:215 #6 0x004caf17 in gfc_simplify_iterator_var (e=0x14f3f00) at ../../gcc/gcc/fortran/array.c:1401 #7 0x004f06a8 in gfc_simplify_expr (p=0x14f3f00, type=1) at ../../gcc/gcc/fortran/expr.c:1873 #8 0x004c99a6 in expand_constructor (base=value optimized out) at ../../gcc/gcc/fortran/array.c:1540 #9 0x004c9be9 in expand_expr (base=value optimized out) at ../../gcc/gcc/fortran/array.c:1416 #10 expand_expr (base=value optimized out) at ../../gcc/gcc/fortran/array.c:1515 #11 expand_iterator (base=value optimized out) at ../../gcc/gcc/fortran/array.c:1486 #12 expand_constructor (base=value optimized out) at ../../gcc/gcc/fortran/array.c:1524 #13 0x004cb94d in gfc_array_size (array=0x14f4ad0, result=0x7fffd830) at ../../gcc/gcc/fortran/array.c:2190 #14 0x005311eb in expression_shape (e=0x14f4ad0) at ../../gcc/gcc/fortran/resolve.c:4812 #15 expression_rank (e=0x14f4ad0) at ../../gcc/gcc/fortran/resolve.c:4888 #16 0x00538742 in gfc_resolve_expr (e=0x14f4ad0) at ../../gcc/gcc/fortran/resolve.c:6060 #17 0x0054176f in resolve_code (code=0x14f4b90, ns=0x14efed0) at ../../gcc/gcc/fortran/resolve.c:8928 #18 0x0054379f in resolve_codes (ns=0x14efed0) at ../../gcc/gcc/fortran/resolve.c:13478
[Bug fortran/47260] DLLEXPORT: TREE_PUBLIC for procedures lost between trans-decl.c and tree.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47260 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Summary|DLLEXPORT attribute |DLLEXPORT: TREE_PUBLIC for |requires additional |procedures lost between |capabilities to be useful |trans-decl.c and tree.c --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-12 10:17:55 UTC --- Confirmed. On Linux (should be also in Windows), the TREE_PUBLIC in build_function_decl is set. On the other hand, Kai confirmed that in MinGW64 the same error occurs. It seems as if the TREE_PUBLIC is lost in between (the error message is printed in tree.c's handle_dll_attribute). Fails also with: gcc version 4.5.3 20110103 (prerelease) (GCC) thus it is not a regression (Obtainted from: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/ ; the 1.0 builds are for GCC 4.5.) Thus, it does not seem to be an LTO problem or an -fwhole-file issue.
[Bug objc/47262] Better error message upon finding a @property in the instance variable list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47262 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.12 10:24:01 Ever Confirmed|0 |1 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-01-12 10:24:01 UTC --- Confirmed with gcc (GCC) 4.6.0 20110112 (experimental). Thanks
[Bug libfortran/47268] New: Documentation: missing (Optional) keyword for parameters of get_command_argument() and get_environment_variable()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47268 Summary: Documentation: missing (Optional) keyword for parameters of get_command_argument() and get_environment_variable() Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net The argument VALUE of the get_command_argument() intrinsic is correctly marked as optional in the Syntax section, but in the Arguments section the (Optional) keyword is missing. Style issue: For the LENGTH and STATUS arguments the keyword is written as (Option), not (Optional). The arguments VALUE,LENGTH,STATUS,TRIM_NAME of the get_environment_variable() intrinsic are correctly marked as optional in the Syntax section, but in the Arguments section the (Optional) keyword is missing.
[Bug testsuite/33033] FAIL: gcc.dg/20061124-1.c: undefined reference to `__sync_add_and_fetch_2'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33033 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC|ebotcazou at gcc dot| |gnu.org | Component|target |testsuite AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-12 10:35:49 UTC --- Fixing...
[Bug rtl-optimization/47166] [4.5/4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #11 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-12 10:36:39 UTC --- I have now confirmed Richard's patch (http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00548.html) is doing the right thing on 4.5 branch and trunk, for the tests that were previously failing. Thanks very much for debugging this, Bernd. Many thanks for your patch, Richard.
[Bug tree-optimization/47233] IPA reference tends to explode in memory use with -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47233 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-12 10:39:43 UTC --- Author: hubicka Date: Wed Jan 12 10:39:39 2011 New Revision: 168700 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168700 Log: PR tree-optimization/47233 * opts.c (common_handle_option): Disable ipa-reference with profile feedback. Modified: trunk/gcc/ChangeLog trunk/gcc/opts.c
[Bug middle-end/42371] dead code not eliminated during folding with whole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added AssignedTo|hubicka at gcc dot gnu.org |mjambor at suse dot cz --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-12 10:43:13 UTC --- Hi, the last problem was solved, sadly it is not last. We still keep the functions around because we don't see that indirect inlining effectively removes the reference. Martin probably should look into this for 4.7.
[Bug rtl-optimization/47166] [4.5/4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 --- Comment #12 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-12 10:44:11 UTC --- (In reply to comment #9) Created attachment 22945 [details] Test patch Could you try the following? It's a variant of a patch Richard Sandiford recently posted. Just noticed you said this is a variant of Richard's patch. Hopefully the two patches can be reconciled?
[Bug tree-optimization/47233] IPA reference tends to explode in memory use with -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47233 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW Blocks|45375 | AssignedTo|hubicka at gcc dot gnu.org |unassigned at gcc dot ||gnu.org --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-12 10:45:40 UTC --- Workaround comitted, unasigning and removing from list of Mozilla dependencies.
[Bug testsuite/33033] FAIL: gcc.dg/20061124-1.c: undefined reference to `__sync_add_and_fetch_2'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33033 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-12 10:52:28 UTC --- Author: ebotcazou Date: Wed Jan 12 10:52:25 2011 New Revision: 168701 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168701 Log: PR testsuite/33033 * gcc.dg/20061124-1.c: Pass -mcpu=v9 on the SPARC. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/20061124-1.c
[Bug testsuite/33033] FAIL: gcc.dg/20061124-1.c: undefined reference to `__sync_add_and_fetch_2'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33033 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-12 10:53:24 UTC --- Author: ebotcazou Date: Wed Jan 12 10:53:21 2011 New Revision: 168702 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168702 Log: PR testsuite/33033 * gcc.dg/20061124-1.c: Pass -mcpu=v9 on the SPARC. Modified: branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/20061124-1.c
[Bug testsuite/33033] FAIL: gcc.dg/20061124-1.c: undefined reference to `__sync_add_and_fetch_2'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33033 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-12 10:54:01 UTC --- Author: ebotcazou Date: Wed Jan 12 10:53:59 2011 New Revision: 168703 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168703 Log: PR testsuite/33033 * gcc.dg/20061124-1.c: Pass -mcpu=v9 on the SPARC. Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/20061124-1.c
[Bug testsuite/33033] FAIL: gcc.dg/20061124-1.c: undefined reference to `__sync_add_and_fetch_2'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33033 --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-12 10:54:38 UTC --- Author: ebotcazou Date: Wed Jan 12 10:54:36 2011 New Revision: 168704 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168704 Log: PR testsuite/33033 * gcc.dg/20061124-1.c: Pass -mcpu=v9 on the SPARC. Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/20061124-1.c
[Bug testsuite/33033] FAIL: gcc.dg/20061124-1.c: undefined reference to `__sync_add_and_fetch_2'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33033 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.6 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-12 10:56:13 UTC --- At long last.
[Bug lto/47264] [4.6 Regression] Many tests fail with -flto due unaligned load in lto-plugin.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47264 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.12 10:49:43 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-12 10:49:43 UTC --- Ick - what of a bad coding style. I'll fix it.
[Bug lto/47259] LTO and global register variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47259 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||lto Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.12 11:06:55 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-12 11:06:55 UTC --- Confirmed. We probably should reject global register vars for LTO.
[Bug tree-optimization/47255] Missed CSE optimization with inline functions, and __attribute__((const))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47255 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.12 11:10:22 Component|c |tree-optimization Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-12 11:10:22 UTC --- Sure, it is a missed optimization. It's even easy to fix when you accept a general compile-time slowdown (just schedule some CSE passes before inlining). When you want to avoid the compile-time slowdown then it's not so easy (it's a usual trade-off with the case where there is no CSE opportunity but earlier inlining would result in better code). You can force GCC to not inline the function with using __attribute__((const,noinline)) (but it of course will then be not inlined at all).
[Bug objc/46710] fast enumeration tests failing on ia64-suse-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46710 --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-01-12 11:22:35 UTC --- I just noticed that this failure was reported on 9 January 2011, but it is no longer reported on 10 January 2011. What changed ? I asked Matthias Klose if he has more information on his latest reported failure -- http://gcc.gnu.org/ml/gcc-testresults/2011-01/msg00731.html Thanks
[Bug target/46993] Optimization on i386 lead to user-visible traps during floating-point operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46993 --- Comment #1 from Arseny Klimovsky arseny.klimovsky at gmail dot com 2011-01-12 11:59:13 UTC --- This bug is quite similar to another one in Debian BTS http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561611
[Bug target/47246] [4.6 Regression] Invalid immediate offset for Thumb VFP store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47246 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Component|rtl-optimization|target --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-12 11:59:57 UTC --- More of a target problem I think.
[Bug lto/47264] [4.6 Regression] Many tests fail with -flto due unaligned load in lto-plugin.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47264 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-12 12:04:45 UTC --- Author: rguenth Date: Wed Jan 12 12:04:39 2011 New Revision: 168708 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168708 Log: 2011-01-12 Richard Guenther rguent...@suse.de PR lto/47264 * lto-plugin.c (parse_table_entry): Use memcpy to access unaligned fields. Modified: trunk/lto-plugin/ChangeLog trunk/lto-plugin/lto-plugin.c
[Bug rtl-optimization/46894] [4.6 Regression] vector tests fail on powerpc 32-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46894 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Target|powerpc-apple-darwin9 |powerpc-*-* Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.12 12:05:15 Host|powerpc-apple-darwin9 |powerpc-*-* AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org Summary|[4.6 Regression] vector |[4.6 Regression] vector |fails on powerpc-darwin9|tests fail on powerpc ||32-bit Ever Confirmed|0 |1 Build|powerpc-apple-darwin9 |powerpc-*-* --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-12 12:05:15 UTC --- Looking into it.
[Bug c/46946] contradiction in docs for -Ofast and -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46946 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-12 12:07:49 UTC --- Author: rguenth Date: Wed Jan 12 12:07:44 2011 New Revision: 168709 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168709 Log: 2011-01-12 Richard Guenther rguent...@suse.de PR other/46946 * doc/invoke.texi (ffast-math): Document it is turned on with -Ofast. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug c/46946] contradiction in docs for -Ofast and -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46946 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-12 12:08:04 UTC --- Fixed.
[Bug lto/47264] [4.6 Regression] Many tests fail with -flto due unaligned load in lto-plugin.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47264 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-12 12:08:22 UTC --- Fixed.
[Bug tree-optimization/47239] [4.6 Regression] (int)func 3 is always optimized to 0 on some targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47239 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-12 12:10:05 UTC --- Fixed.
[Bug rtl-optimization/47216] [4.6 Regression] gcc.dg/torture/pr43360.c FAILs with -O -fPIC -fgcse -fgcse-sm -fnon-call-exceptions -fno-tree-dse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47216
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||amacleod at redhat dot com,
||law at redhat dot com,
||stevenb.gcc at gmail dot
||com
Component|tree-optimization |rtl-optimization
--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-12
13:03:18 UTC ---
We have in store-motion.c:
static inline bool
store_killed_in_pat (const_rtx x, const_rtx pat, int after)
{
...
/* Check for memory stores to aliased objects. */
if (MEM_P (dest)
!exp_equiv_p (dest, x, 0, true))
{
if (after)
{
if (output_dependence (dest, x))
return true;
}
else
{
if (output_dependence (x, dest))
return true;
}
}
and coming in with
gdb) call debug_rtx (dest)
(mem/s/j:SI (reg/f:DI 67) [0 g_3+0 S4 A32])
(gdb) call debug_rtx (x)
(mem/s/c:SI (reg/f:DI 67) [0 MEM[(int *)g_3]+0 S4 A32])
and exp_equiv_p returns true. But then we seem to completely ignore
that kill(!?), thus we happily sink the first store across the second.
Huh. Doesn't make sense to me unless the SET_SRCs are also equivalent.
Of course it may be that this shouldn't happen because if it does then
the antic sets are not as expected?
I guess it makes sense if you only look at the description for
store_killed_in_pat and adjust it to looking for any loads which
might make the store in X live (loads don't kill anything).
Ultimatively this leads to a wrong answer from store_killed_after.
Simplified situation is like
for (;;)
{
*x = 1;
*x = 2;
}
and store-motion sinks *x = 1 across *x = 2.
svn blame blames steven for store-motion (of course - he split it out).
Steven - do you by any chance have any idea how it works? The code
dates back to
2001-04-09 Andrew MacLeod amacl...@redhat.com
Jeff Law l...@redhat.com
And I'd just do an uninformed
Index: gcc/store-motion.c
===
--- gcc/store-motion.c (revision 168707)
+++ gcc/store-motion.c (working copy)
@@ -367,8 +367,7 @@ store_killed_in_pat (const_rtx x, const_
dest = XEXP (dest, 0);
/* Check for memory stores to aliased objects. */
- if (MEM_P (dest)
- !exp_equiv_p (dest, x, 0, true))
+ if (MEM_P (dest))
{
if (after)
{
[Bug lto/47259] LTO and global register variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47259 --- Comment #3 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-01-12 13:10:07 UTC --- For example, linux uses global reg var esp. As there is no need to reserve this register, can GCC accept it?
[Bug lto/47259] LTO and global register variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47259
--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-12
13:32:32 UTC ---
In 99.% of all cases there is a better way than using a global register
variable.
Also it is not clear to me how to merge translation units where a different
set of registers are used in global register variables. Consider
t1.c:
int g asm(%ecx);
t2.c:
void foo(void)
{
complex-asm-that-needs-many-regs
}
if we make ecx global in t2.c then we'd fail to assign registers to
the complex asm. Thus one solution would be to partition the LTO
program in a way that t1.c is completely contained in its own
partition. But then the user could have compiled t1.c without LTO
which would be my suggested workaround. Thus, emit
sorry: translation units with global register variables need to be compiled
without LTO
[Bug fortran/47260] DLLEXPORT: TREE_PUBLIC for procedures lost between trans-decl.c and tree.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47260 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-12 13:37:53 UTC --- Kai sent a draft patch. The issue is that TREE_PUBLIC/TREE_EXTERNAL should come before setting the attribute - otherwise the decl seems to be inconsistent. I try to submit the patch soon. (If not, please ping.)
[Bug rtl-optimization/37273] [4.4/4.5/4.6 Regression] IRA does not re-materializes addresses (loads from the TOC)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37273 --- Comment #5 from Jeffrey A. Law law at redhat dot com 2011-01-12 13:38:20 UTC --- First I think we need to note that if we allocate the pseudo holding the value for ext in memory that we get some savings (because ext is already sitting in memory waiting to be used). This is very similar to how we recognize some savings from allocating a pseudo to memory when the pseudo represents an argument loaded from its stack slot in ira-costs. Second, in that same code, we're double-counting the cost of allocating the pseudo to memory. If those two problems are fixed, we get the desired PPC code; however, significant benchmarking would be required to determine how this change affects a broader codebase. I'll note there's also a deficiency in caller-saves in that it insists on reloading the value into its original hard reg, even if the hard reg is going to be immediately copied to a different hard reg. I don't want to spend too much time on the caller-save aspects since ultimately I think caller-save needs to go away or at least have another rewrite. It's approaching 2 decades since it's last major revision.
[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823 --- Comment #18 from Martin Jambor jamborm at gcc dot gnu.org 2011-01-12 13:50:11 UTC --- You're right, however in fact all redirections and updates should be taking place already. Either in inline_transform() for calls that are in the function from the beginning of inlining or later when new ones are added in copy_bb(). So I was looking for why this one did not and figured out that they are original calls, cgraph_redirect_edge_call_stmt_to_callee() is called on their edges but it returns immediately because of this condition: cgraph_get_node (decl) == cgraph_get_node (e-callee-decl) It is satisfied because the declaration in the IL is an alias, the function returns and the alias decl stays in the IL. But e-callee is not the node that the alias cgraph_node aliases, it is another inline clone instead. And the aliased node is also scheduled to be inlined. After it is inlined, the node is removed together with its alias nodes and from that point on there is no cgraph_node for the alias declaration and so when it is stumbled on another time, cgraph_node() function creates a new one and the verifier explodes. I therefore propose to remove the quoted condition from cgraph_redirect_edge_call_stmt_to_callee(). It was originally added by Jakub in his fix for PR 42508 with a comment (#4) saying: The cgraphunit.c hunk is only somewhat related, is not necessary to fix this, I've just noticed that the function was still modifying GIMPLE_CALL decl unnecessarily (and confusingly), when e-callee is an inline clone of some cgraph node with same_body aliases and GIMPLE_CALL calls the same_body alias. Nevertheless, my patch in comment #16 is also OK (and would save a bit of unnecessary work) because the call statement is not updated only if it is not necessary because still the same old function is being called, just through an alias of what is now an inline clone. So Honza, what do you prefer?
[Bug fortran/47267] array constructor causing long compile times
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47267 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||dfranke at gcc dot gnu.org, ||jvdelisle at gcc dot ||gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-12 13:51:43 UTC --- You can use -fmax-array-constructor=n to tune this. However, I think currently there is no distinction made between constructors which have to be be run at compile time (a) and those which can be run at compile time (b). n is currently 65535. Example for (a): Parameter array or initialization expression INTEGER, PARAMETER :: Niter=3000 INTEGER, PARAMETER :: ARRAY(Niter) = (/(i,i=1,Niter)/) Example for (b): Assignment to an array INTEGER, PARAMETER :: Niter=3000 INTEGER :: ARRAY(Niter) ARRAY(Niter) = (/(i,i=1,Niter)/)
[Bug lto/47259] LTO and global register variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47259 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-12 14:01:43 UTC --- I have a patch.
[Bug fortran/47260] DLLEXPORT: TREE_PUBLIC for procedures lost between trans-decl.c and tree.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47260 --- Comment #6 from Craig Powers craig.powers at gmail dot com 2011-01-12 14:11:28 UTC --- I also was unable to get the procedure into a DLL with omission of DLLEXPORT, instead attempting to get it in using a .DEF file and either gfortran or dlltool. I'm not sure if that reflects another aspect of the same problem. If I do this: gfortran -shared -o test.dll test.def test.o typedata.o I get: Cannot export _compute_load_...@28: symbol not defined But if I look at the output of nm test.o, I see: T _compute_load_...@28
[Bug tree-optimization/47265] [4.6 Regression] Error: SSA name in freelist but still referenced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47265 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.12 14:21:03 CC||matz at gcc dot gnu.org Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-01-12 14:21:03 UTC --- It is caused by revision 163998: http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00290.html
[Bug middle-end/44440] [4.6 regression] ira_initialization and buitins construction taking too much of startup time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.12 14:40:30 Summary|ira_initialization and |[4.6 regression] |buitins construction taking |ira_initialization and |too much of startup time|buitins construction taking ||too much of startup time Ever Confirmed|0 |1 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-12 14:40:30 UTC --- compiling empty file 100 times takes 3.8s on 4.6, while it takes 2.4s on on gcc 4.3 as well as gcc 4.5. This is 50% regression. User time increases 100%. So we probably do a lot more initialization than before. 2979 9.4936 ggc_internal_alloc_stat 1771 5.6439 ira_init 1539 4.9046 pop_scope 1258 4.0091 init_reg_sets_1 1036 3.3016 ht_lookup_with_hash 986 3.1422 ht_lookup 951 3.0307 decl_attributes 905 2.8841 ix86_hard_regno_mode_ok 852 2.7152 copy_node_stat 750 2.3901 rtx_cost 717 2.2850 bind 635 2.0236 ix86_rtx_costs 633 2.0173 ggc_internal_cleared_alloc_stat 632 2.0141 ix86_memory_move_cost 619 1.9727 c_write_global_declarations_1 566 1.8038 make_node_stat 553 1.7623 htab_find_with_hash 519 1.6540 recog 497 1.5839 iterative_hash
[Bug target/46037] --enable-stage1-languages=c,lto --enable-languages=c,lto --with-build-config=bootstrap-lto fails on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46037 --- Comment #25 from Jack Howarth howarth at nitro dot med.uc.edu 2011-01-12 15:00:11 UTC --- Testresults for lto-bootstrap with revised patch on x86_64-apple-darwin10... http://gcc.gnu.org/ml/gcc-testresults/2011-01/msg01002.html
[Bug lto/47259] LTO and global register variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47259 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-12 15:01:16 UTC --- Author: rguenth Date: Wed Jan 12 15:01:09 2011 New Revision: 168713 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168713 Log: 2011-01-12 Richard Guenther rguent...@suse.de PR lto/47259 * lto-streamer-out.c (output_gimple_stmt): Do not wrap register variables in a MEM_REF. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-out.c
[Bug lto/47259] LTO and global register variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47259 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-12 15:02:22 UTC --- Fixed.
[Bug target/47269] New: DSYMUTIL_SPEC doesn't handle -gtoggle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47269 Summary: DSYMUTIL_SPEC doesn't handle -gtoggle Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu Currently on darwin, DSYMUTIL_SPEC is unaware of the -gtoggle flag. This results in dsymutil not being called as expected when '-g0 -gtoggle' is passed to the compiler despite any resulting object files containing the expected DWARF debug information. It is unclear how we can code for this in DSYMUTIL_SPEC since -gtoggle needs to invert the final accumulative setting of -g.
[Bug lto/47259] LTO and global register variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47259 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-12 15:22:08 UTC --- Author: rguenth Date: Wed Jan 12 15:21:59 2011 New Revision: 168715 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168715 Log: 2011-01-12 Richard Guenther rguent...@suse.de PR lto/47259 * gcc.dg/lto/pr47259_0.c: New testcase. * gcc.dg/lto/pr47259_1.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/lto/pr47259_0.c trunk/gcc/testsuite/gcc.dg/lto/pr47259_1.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/47270] New: [4.4/4.5/4.6 Regression] GCC produces unnecessary/wrong code on -O2 and -O3 levels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47270
Summary: [4.4/4.5/4.6 Regression] GCC produces
unnecessary/wrong code on -O2 and -O3 levels
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
$ cat testcase.c
register int r asm(esi);
void foo(void)
{
if (r)
__asm__(sar\t%0 : +r (r));
__asm__(sar\t%0 : +r (r));
}
^D
$ gcc -O2 -S testcase.c
$ cat testcase.s
[...]
foo:
.LFB0:
xorl%eax, %eax
testl %esi, %esi
je .L2
#APP
# 6 testcase.c 1
sar %esi
# 0 2
#NO_APP
movl%esi, %eax
.L2:
movl%eax, %esi
#APP
# 8 testcase.c 1
sar %esi
# 0 2
#NO_APP
ret
[...]
[Bug driver/47244] [4.6 Regression] plugin linker is used unconditionally
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47244 --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-12 15:47:36 UTC --- Author: hubicka Date: Wed Jan 12 15:47:29 2011 New Revision: 168717 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168717 Log: PR driver/47244 * gcc.c (PLUGIN_COND): Update to disable plugin unless -flto is used. (PLUGIN_COND_CLOSE): New macro. (LINK_COMMAND_SPEC): Update to use PLUGIN_COND_CLOSE. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c
[Bug driver/47244] [4.6 Regression] plugin linker is used unconditionally
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47244 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-12 15:48:22 UTC --- fixed.
[Bug c++/11750] class scope using-declaration lookup not implemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11750
Balakrishnan B balakrishnan.erode at gmail dot com changed:
What|Removed |Added
CC||balakrishnan.erode at gmail
||dot com
--- Comment #6 from Balakrishnan B balakrishnan.erode at gmail dot com
2011-01-12 16:57:07 UTC ---
(In reply to comment #0)
Paragraph 10.3/2 in the C++ standard [ISO/IEC 14882:1998] provides the
following
code example:
quote
struct A {
virtual void f();
};
struct B : virtual A {
virtual void f();
};
struct C : B , virtual A {
using A::f;
};
void foo() {
C c;
c.f(); // calls B::f, the final overrider
c.C::f(); // calls A::f because of the using-declaration
}
/quote
When a similar program is compiled using G++ 3.3, the method call 'c.f()' in
function foo() incorrectly invokes A::f and not B::f as specified in the
standard.
example
code main.cpp
#include iostream
struct A {
virtual void f() { std::cout A::f()\n; }
};
struct B : virtual A {
virtual void f() { std::cout B::f()\n; }
};
struct C : B, virtual A {
using A::f;
};
int main()
{
C c;
c.f(); // ERROR - Incorrectly invokes A::f
c.C::f(); // OK - Invokes A::f
}
/code
build
$ g++ main.cpp
$ ldd a.out
libstdc++.so.5 =
/usr/local/gcc/3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3/libstdc++.so.5
(0x40017000)
libm.so.6 = /lib/tls/libm.so.6 (0x400e4000)
libgcc_s.so.1 =
/usr/local/gcc/3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3/libgcc_s.so.1
(0x40106000)
libc.so.6 = /lib/tls/libc.so.6 (0x4200)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
/build
output
$ ./a.out
A::f()
A::f()
/output
/example
Im using g++ 4.4.5
With the same example with my main function as below,
int main()
{
C c;
c.f() // Calls A::f
C* pc = c;
pc-f() // Calls B::f
}
With the same object when accessed directly produces different results and when
accessed using a pointer of same type produces a different result. Even if gcc
violates standard, there has to be some proper explanation.
[Bug debug/47209] ICE: SIGSEGV in should_emit_struct_debug (dwarf2out.c:627) with -f{no-,}emit-struct-debug-{baseonly,reduced} -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47209 --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org 2011-01-12 17:02:51 UTC --- Author: ktietz Date: Wed Jan 12 17:02:41 2011 New Revision: 168718 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168718 Log: 2011-01-12 Kai Tietz kai.ti...@onevision.com PR debug/47209 * dwarfout2.c (should_emit_struct_debug): Use TYPE_MAIN_VARIANT of type. 2011-01-12 Kai Tietz kai.ti...@onevision.com PR debug/47209 * g++.dg/debug/pr47209.C: New. Added: trunk/gcc/testsuite/g++.dg/debug/pr47209.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug debug/47209] ICE: SIGSEGV in should_emit_struct_debug (dwarf2out.c:627) with -f{no-,}emit-struct-debug-{baseonly,reduced} -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47209 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org 2011-01-12 17:06:15 UTC --- Fixed.
[Bug c++/11750] class scope using-declaration lookup not implemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11750 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-12 17:10:17 UTC --- (In reply to comment #6) With the same object when accessed directly produces different results and when accessed using a pointer of same type produces a different result. Even if gcc violates standard, there has to be some proper explanation. The explanation is it's a bug
[Bug c++/11750] class scope using-declaration lookup not implemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11750
--- Comment #8 from Andrew Schepler aschepler at gmail dot com 2011-01-12
17:16:29 UTC ---
(In reply to comment #6)
struct A {
virtual void f();
};
struct B : virtual A {
virtual void f();
};
struct C : B , virtual A {
using A::f;
};
Im using g++ 4.4.5
With the same example with my main function as below,
int main()
{
C c;
c.f() // Calls A::f
C* pc = c;
pc-f() // Calls B::f
}
With the same object when accessed directly produces different results and
when
accessed using a pointer of same type produces a different result. Even if gcc
violates standard, there has to be some proper explanation.
The reason is that when f is invoked via a pointer or reference, g++ uses the
vtable lookup to call the correct final override. But when the object in the
member access is not a pointer or reference (it is a non-reference identifier
as here, or qualified id, or class member), g++ can usually optimize away the
virtual call and just call the correct member function. In this case the logic
for calling the correct member function for that optimization is incorrect, but
virtual calls still work correctly.
[Bug tree-optimization/47265] [4.6 Regression] Error: SSA name in freelist but still referenced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47265 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Michael Matz matz at gcc dot gnu.org 2011-01-12 17:20:00 UTC --- The underlying problem is that tree-ssa-forwprop.c recursively calls itself on the same statement, updating it in the process. That destroys the imm_use iterator for the outer iteration, making us miss on imm-use. The definition then is removed (under the assumption that all imm-uses are changed), leaving a stale reference to an SSA name in the free list. In detail here's what happens, the situation at first: src_2 = s_1(D)-b; src_20 = src_2 + 1; src_19 = [cond_expr] iftmp.0_11 != 0 ? src_20 : src_2; forward_propagate_addr_expr (src_2) iterates over the imm-uses of src_2. (1) The first is the def of src_20, which itself is a pointer addition. forward_propagate_addr_expr_1 happily tries to look through that one calling forward_propagate_addr_expr recursively on src_20. The imm-use list of src_20 also contains statement src_19, which is now updated via update_stmt. Unfortunately that will clobber the iterator at (1) to not contain the src_19 statement anymore. So when returning the outer loop on imm-uses(src_2) will now exit as if all imm-uses were handled. Caller will remove def(src_2), leaving us with: src_20 = MEM[(void *)s_1(D) + 4B]; src_19 = [cond_expr] iftmp.0_11 != 0 ? src_20 : src_2; Boom. Triggered by my patch perhaps, but latent problem. The underlying problem is statements that can be reached over multiple distinct paths of def-use chains. I'll experiment with totally removing the recursion, it possibly isn't necessary anymore since MEMREF because looking through type-casts and the like isn't necessary. And of course as this one shows it's simply not correct to recurse on forward_propagate_addr_expr, at least as long as the destination statement has more than one operand
[Bug c/47271] New: gcc-4.6 -O1 -ftree-vectorize removes a test (if), the function generates invalid outputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47271 Summary: gcc-4.6 -O1 -ftree-vectorize removes a test (if), the function generates invalid outputs Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: victor.stin...@haypocalc.com I tried to compile Python 3.2 (r87949) with gcc (version 4.6.0 20100908) on AMD64: Python does fail with an assertion error or another strange crash. The problem comes from a loop in Python/peephole.c. Compiled with -O1, it works fine. Compiled with -O1 -ftree-vectorize, the functions generates strange (invalid) outputs. gcc-4.6 -O1: - 0x00480991 +5041: mov%eax,%edx 0x00480993 +5043: sub%esi,%edx 0x00480995 +5045: mov%edx,(%r12,%rax,4) 0x00480999 +5049: movzbl 0x0(%rbp,%rax,1),%edx 0x0048099e +5054: cmp$0x9,%dl 0x004809a1 +5057: jne0x4809a8 PyCode_Optimize+5064 0x004809a3 +5059: add$0x1,%esi 0x004809a6 +5062: jmp0x4809b2 PyCode_Optimize+5074 0x004809a8 +5064: mov$0x3,%ecx 0x004809ad +5069: cmp$0x59,%dl 0x004809b0 +5072: ja 0x4809b7 PyCode_Optimize+5079 0x004809b2 +5074: mov$0x1,%ecx 0x004809b7 +5079: add%rcx,%rax 0x004809ba +5082: cmp%rax,%rdi 0x004809bd +5085: jg 0x480991 PyCode_Optimize+5041 - gcc-4.6 -O1 -ftree-vectorize - 0x00480991 +5041: mov%eax,%ecx 0x00480993 +5043: sub%edx,%ecx 0x00480995 +5045: mov%ecx,(%r12,%rax,4) 0x00480999 +5049: movzbl 0x0(%rbp,%rax,1),%ecx 0x0048099e +5054: lea0x1(%rdx),%esi 0x004809a1 +5057: cmp$0x9,%cl 0x004809a4 +5060: cmovne %edx,%esi 0x004809a7 +5063: cmove %esi,%edx 0x004809aa +5066: setne %cl 0x004809ad +5069: movzbl %cl,%ecx 0x004809b0 +5072: lea0x1(%rax,%rcx,2),%rax 0x004809b5 +5077: cmp%rax,%rdi 0x004809b8 +5080: jg 0x480991 PyCode_Optimize+5041 - Extract of the correct output (-O1): addrmap[0]=0 addrmap[3]=3 addrmap[4]=4 addrmap[7]=7 addrmap[10]=10 addrmap[13]=13 addrmap[16]=16 addrmap[19]=19 addrmap[22]=22 addrmap[23]=22 With -O1 -ftree-vectorize, only addrmap[0] and addrmap[3] are correct: addrmap[0]=0 addrmap[3]=3 addrmap[4]=0 addrmap[7]=32767 addrmap[10]=16777216 addrmap[13]=0 addrmap[16]=469314288 addrmap[19]=32767 addrmap[22]=469315151 addrmap[23]=32767 See also: http://bugs.python.org/issue9880 My setup: * Intel(R) Pentium(R) 4 CPU 3.00GHz * Debian Sid * gcc (Debian 20110106-1) 4.6.0 20110106 (experimental) [trunk revision 168538] * Python 3.2 (r87949)
[Bug c/47271] gcc-4.6 -O1 -ftree-vectorize removes a test (if), the function generates invalid outputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47271 --- Comment #1 from Victor Stinner victor.stinner at haypocalc dot com 2011-01-12 18:54:32 UTC --- Created attachment 22951 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22951 Example to reproduce the bug
[Bug c++/46941] [trans-mem] new/delete operator are unsafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Aldy Hernandez aldyh at gcc dot gnu.org 2011-01-12 19:03:53 UTC --- Fixed http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00776.html
[Bug tree-optimization/47271] gcc-4.6 -O1 -ftree-vectorize removes a test (if), the function generates invalid outputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47271 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-01-12 19:42:38 UTC --- It is caused by revision 160030: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg01089.html
[Bug tree-optimization/47271] gcc-4.6 -O1 -ftree-vectorize removes a test (if), the function generates invalid outputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47271 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||spop at gcc dot gnu.org Target Milestone|--- |4.6.0
[Bug fortran/47240] [F03] segfault with procedure pointer component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240 --- Comment #9 from janus at gcc dot gnu.org 2011-01-12 20:00:37 UTC --- (In reply to comment #8) [macbook] f90/bug% gfc -O2 pr35971_red.f90 pr35971_red.f90: In function 'gp': pr35971_red.f90:67:0: error: non-trivial conversion at assignment void (*T64) (void) void (*T49d) (struct array1_unknown , integer(kind=4), struct array1_integer(kind=4) restrict) __result_gp_72 = make_mess; pr35971_red.f90:67:0: internal compiler error: verify_stmts failed sorry, I can not reproduce this at r168655 (plus patch from comment #7), at least not on x86_64-unknown-linux-gnu. Do you only get this error with the patch, or also with a clean trunk? I would expect that my patch should not have any impact on your test case ...
[Bug target/47272] New: In addition to the bug uncovered in 42751, gcc can't bootstrap using --with-cpu=power7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47272 Summary: In addition to the bug uncovered in 42751, gcc can't bootstrap using --with-cpu=power7 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: target AssignedTo: meiss...@gcc.gnu.org ReportedBy: meiss...@gcc.gnu.org CC: berg...@vnet.ibm.com Depends on: 42751 Host: powerpc64-linux Target: powerpc64-linux Build: powerpc64-linux The VSX support changed to use the VSX form of the instruction if both VSX and Altivec forms existed. Unfortunately, there are differences between the Altivec memory references instructions (LVX/STVX) and the VSX memory reference instructions (LXVW4X/STXVW4X). In particular, the Altivec memory instructions ignore the bottom 3 bits of the address field, and the VSX instructions do not. The altivec code in libcpp/lex.c was coded such that it knew about ignoring the bottom 3 bits of the load. Thus we should modify __builtin_vec_ld and __builtin_vec_st to use the Altivec versions of the instructions, and provide other builtins that can use either the altivec or VSX memory instructions, depending on the switches used. In addition, during testing, I discovered that __builtin_vec_ld and __builtin_vec_st don't support the vector double and vector long long types added with VSX.
[Bug fortran/47240] [F03] segfault with procedure pointer component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240
--- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr
2011-01-12 20:59:31 UTC ---
sorry, I can not reproduce this at r168655 (plus patch from comment #7), at
least not on x86_64-unknown-linux-gnu. Do you only get this error with the
patch, or also with a clean trunk? I would expect that my patch should not
have
any impact on your test case ...
I am rebuilding a clean tree with only the following patch
diff -up ../_clean/gcc/fortran/resolve.c gcc/fortran/resolve.c
--- ../_clean/gcc/fortran/resolve.c2011-01-09 22:13:56.0 +0100
+++ gcc/fortran/resolve.c2011-01-12 21:49:39.0 +0100
@@ -4858,6 +4858,9 @@ expression_rank (gfc_expr *e)
for (ref = e-ref; ref; ref = ref-next)
{
+ if (ref-type == REF_COMPONENT !ref-next)
+rank = ref-u.c.component-as ? ref-u.c.component-as-rank : 0;
+
if (ref-type != REF_ARRAY)
continue;
diff -up ../_clean/gcc/fortran/trans-expr.c gcc/fortran/trans-expr.c
--- ../_clean/gcc/fortran/trans-expr.c2011-01-08 20:18:07.0 +0100
+++ gcc/fortran/trans-expr.c2011-01-12 21:49:39.0 +0100
@@ -3044,7 +3044,8 @@ gfc_conv_procedure_call (gfc_se * se, gf
|| (fsym-attr.proc_pointer
!(e-expr_type == EXPR_VARIABLE
e-symtree-n.sym-attr.dummy))
- || (e-expr_type == EXPR_VARIABLE
+ || (fsym-attr.proc_pointer
+ e-expr_type == EXPR_VARIABLE
gfc_is_proc_ptr_comp (e, NULL))
|| fsym-attr.allocatable))
{
(your patch for trans-expr.c does not apply cleanly with a copypast from
safari, so I hope I got it right).
[Bug bootstrap/47147] gcc 4.6 fails to compile on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47147 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-12 21:17:35 UTC --- Created attachment 22952 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22952 preprocessed source configured with ../gcc-4.6-20110108/configure --prefix=/home/redi/work/sandbox --disable-libgomp --disable-bootstrap --disable-multilib on netbsd-current build fails in libstdc++-v3/libsupc++ with these errors: In file included from ../../../../gcc-4.6-20110108/libstdc++-v3/libsupc++/tinfo.h:31:0, from ../../../../gcc-4.6-20110108/libstdc++-v3/libsupc++/array_type_info.cc:25: /disk/1/archive/tmp/redi/gcc-4.6-20110108/libstdc++-v3/libsupc++/cxxabi.h:70:17: error: 'size_t' was not declared in this scope /disk/1/archive/tmp/redi/gcc-4.6-20110108/libstdc++-v3/libsupc++/cxxabi.h:70:17: note: suggested alternative: /disk/1/archive/tmp/redi/objdir-4.6-20110108/x86_64-unknown-netbsd5.99.43/libstdc++-v3/include/x86_64-unknown-netbsd5.99.43/bits/c++config.h:88:26: note: 'std::size_t' preprocessed source attached I'll look into it more later and try a build without --disable-boostrap too ...
[Bug objc/47231] Commas inside ObjC method invocation can confuse compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47231 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.12 21:21:12 Ever Confirmed|0 |1 Known to fail||4.6.0 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-01-12 21:21:12 UTC --- Yes, confirmed with gcc version 4.6.0 20110112 (experimental) (GCC). Thanks
[Bug tree-optimization/47271] [4.6 Regression] if-conversion removes a test (if), the function generates invalid outputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47271 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.12 21:34:17 Summary|gcc-4.6 -O1 |[4.6 Regression] |-ftree-vectorize removes a |if-conversion removes a |test (if), the function |test (if), the function |generates invalid outputs |generates invalid outputs Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-12 21:34:17 UTC --- Confirmed.
[Bug bootstrap/47147] gcc 4.6 fails to compile on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47147 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-12 21:34:13 UTC --- ./gcc/include/stddef.h is being included, but it doesn't define size_t machine/ansi.h has the header guard _X86_64_ANSI_H_ but it appears that gcc's stddef.h is expecting _MACHINE_ANSI_H_
[Bug bootstrap/47147] gcc 4.6 fails to compile on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47147 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW
[Bug fortran/47240] [F03] segfault with procedure pointer component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240 --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-12 21:49:23 UTC --- (In reply to comment #9) pr35971_red.f90:67:0: internal compiler error: verify_stmts failed I can reproduce this with a clean trunk on x86-64-linux with both -m32 and -m64. I can not reproduce this at r168655 (plus patch from comment #7) How do you configure gfortran? (I did a full bootstrap and did *not* use --enable-checking=release.) * * * Regarding the test case: I think it is invalid: function aux(x) interface subroutine x() bind(C) end subroutine x end interface but you pass as actual argument the function (!) make_mess which take also arguments to aux. (In get_funloc everything is still fine - the actual argument has the proper type: abstract_fun.) I believe that the argument mismatch is invalid. And the compiler has no chance to detect this at (front-end) compile time as you use a dummy external y instead of the explicit interface of aux. Like always: A compiler can tolerate to a certain extend argument mismatches - but especially with higher optimization values, it trusts the user that (s)he knows what he is doing - and that (s)he stays within what the standard allows. (The same is true for alias analysis.)
[Bug target/47272] GCC can't bootstrap on powerpc64-linx using --with-cpu=power7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47272 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.12 21:53:09 Ever Confirmed|0 |1
[Bug target/47272] GCC can't bootstrap on powerpc64-linx using --with-cpu=power7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47272 --- Comment #1 from Michael Meissner meissner at gcc dot gnu.org 2011-01-12 21:54:25 UTC --- Note, the fixes for 47251 will be needed in addition to changes for this bug in order to do a full bootstrap on a power7 system using the --with-cpu=power7 configure option.
[Bug fortran/47240] [F03] segfault with procedure pointer component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240 --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-01-12 22:18:35 UTC --- I can reproduce this with a clean trunk on x86-64-linux with both -m32 and -m64. I confirm that the ICE is not due to the patch. Regarding the test case: I think it is invalid: I have never said that it was valid (it is not mine and you have probably recognized the style!-). Nevertheless there was no ICE at revision 168625 (I saw it at revision 168653) and even invalid codes should not give ICE.
