Re: gcc will become the best optimizing x86 compiler
Denys Vlasenko wrote: I tend to doubt that odd-byte aligned large memcpys are anywhere near typical. malloc and mmap both return well-aligned buffers (say, 8 byte aligned). Static and on-stack objects are also at least word-aligned 99% of the time. memcpy can just use relatively simple code for copies in which either src or dst is not word aligned. This cuts possibilities down from 16 to 4 (or even 2?). The XMM code is still more than 3 times faster than rep movsl when data are aligned by 4 or 8, but not by 16. Even if odd addresses are rare, they must be supported, but we can put the most common cases first. strcpy and strcat can be implemented efficiently simply by calling strlen and memcpy, since both strlen and memcpy can be optimized very well. This can give unaligned addresses. Dennis Clarke wrote: You forgot to look at PowerPC : http://cvs.opensolaris.org/source/xref/ppc-dev/ppc-dev/usr/src/lib/libc/ppc/gen/memcpy.s is that nice and small ? .. and slow. Why doesn't it use Altivec?
shouldn't every middle-end pass be uniquely named?
Hello All,
Some middle-end passes (those declared in tree-passes.h) are still unnamed.
I tend to believe that it would be helpful (mostly for gcc debugging
purposes) that every struct opt_pass (without exception) should be
uniquely named (and that this should be enforced, eg. in ENABLE_CHECKING
mode (essentially by registering each pass in an hash table in function
next_pass_1 of gcc/passes.c)
What do people think about that?
Except as a habit (which I think is a bad one) is there any reason to
have anonymous passes (those with a null pass-name), or (I don't know
if such beast exists) homonym passes (two different passes with equal
pass-name)?
Regards.
--
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: shouldn't every middle-end pass be uniquely named?
Sent from my iPhone
On Jul 31, 2008, at 1:11, Basile STARYNKEVITCH
[EMAIL PROTECTED] wrote:
Hello All,
Some middle-end passes (those declared in tree-passes.h) are still
unnamed.
I tend to believe that it would be helpful (mostly for gcc debugging
purposes) that every struct opt_pass (without exception) should be
uniquely named (and that this should be enforced, eg. in
ENABLE_CHECKING mode (essentially by registering each pass in an
hash table in function next_pass_1 of gcc/passes.c)
What do people think about that?
Except as a habit (which I think is a bad one) is there any reason
to have anonymous passes (those with a null pass-name), or (I don't
know if such beast exists) homonym passes (two different passes with
equal pass-name)?
Yes. To prevent a dump file. One such example is freeing the internal
data structures. That should not have a dump.
Regards.
--
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: shouldn't every middle-end pass be uniquely named?
Andrew Thomas Pinski wrote:
Sent from my iPhone
Except as a habit (which I think is a bad one) is there any reason to
have anonymous passes (those with a null pass-name), or (I don't know
if such beast exists) homonym passes (two different passes with equal
pass-name)?
Yes. To prevent a dump file. One such example is freeing the internal
data structures. That should not have a dump.
We might add a field (e.g. unsigned avoid_dump) to struct opt_pass for
that, or decide that passes name starting with a star (or whatever
convention people want) do not have any dump file.
In addition of help debugging of GCC, having each pass be named could be
helpful for other reasons. For example, a plugin machinery would be much
simpler (basically a plugin could say add my pass named foo after every
pass named bar).
--
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} ***
Access the BIND_EXPR of a function
Hi, When I encounter a FUNCTION_DECL, I want to access the node BIND_EXPR where I can find the artificial declarations of the current functions that the compiler adds. Following what the documentation says, I use the macro DECL_SAVED_TREE which should point to the node BIND_EXPR (used as follows, DECL_SAVED_TREE (current_function_decl)). Unfortunately, this returns the STATEMENT_LIST node instead. In theory in the GIMPLE, if there are artificial declarations, FUNCTION_DECL has a child called body which points to BIND_EXPR and then BIND_EXPR has a child body which points to STATEMENT_LIST. Btw, I use GCC 4.1. Any ideas for accessing the BIND_EXPR node? Thomas
Re: shouldn't every middle-end pass be uniquely named?
Basile STARYNKEVITCH wrote:
Andrew Thomas Pinski wrote:
Except as a habit (which I think is a bad one) is there any reason to
have anonymous passes (those with a null pass-name), or (I don't
know if such beast exists) homonym passes (two different passes with
equal pass-name)?
Yes. To prevent a dump file. One such example is freeing the internal
data structures. That should not have a dump.
We might add a field (e.g. unsigned avoid_dump) to struct opt_pass for
that, or decide that passes name starting with a star (or whatever
convention people want) do not have any dump file.
I actually proposed a patch on gcc-patches@ which do not dump when the
pass name starts with a dot (better than a star, because following unix
conventions for hidden files)
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg02406.html
regards.
--
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} ***
GCC 4.3.2 Status Report (2008-07-31)
Status == The GCC 4.3 branch is open for commits under normal release branch rules. The 4.3.2 release was expected around 2008-08-06, but as there are still P1s, it might be delayed a little bit. Quality Data Priority # Change from Last Report --- --- P13 - 5 P2 115 - 2 P32 - 1 --- --- Total 120 - 8 As we are approaching the intended release date of 4.3.2 we need to address the P1 bugs or downgrade them accordingly. Two of the P1s have patches posted (more than 3 resp. 2 weeks ago), so they just need reviewing. If you think you have spotted a regression on the branch for a primary or secondary target that does not show up when invoking the Serious regressions link from the GCC homepage please tell one of the RMs. Previous Report === http://gcc.gnu.org/ml/gcc/2008-07/msg00240.html The next report for the 4.3 branch will be sent by Mark.
RE: gcc will become the best optimizing x86 compiler
Agner Fog wrote on 31 July 2008 07:14: Denys Vlasenko wrote: I tend to doubt that odd-byte aligned large memcpys are anywhere near typical. malloc and mmap both return well-aligned buffers (say, 8 byte aligned). Static and on-stack objects are also at least word-aligned 99% of the time. memcpy can just use relatively simple code for copies in which either src or dst is not word aligned. This cuts possibilities down from 16 to 4 (or even 2?). The XMM code is still more than 3 times faster than rep movsl when data are aligned by 4 or 8, but not by 16. Even if odd addresses are rare, they must be supported, but we can put the most common cases first. In the real world, unaligned memcpys are anything but rare. Everything's networked these days, remember? Stuff gets misaligned real quick when you start adding and removing various network layer headers and trailers to unpredictably-sized packets. cheers, DaveK -- Can't think of a witty .sigline today
Re: gcc emit wrong symbols in multiple inheritance case
On Thu, Jul 31, 2008 at 12:48 AM, Brian Dessent [EMAIL PROTECTED] wrote: Benjamin Smedberg wrote: For what it's worth, Bo is my intern in the Google SoC and has traced this back to being a code-generation error (missed stdcall mangling) in the mingw backend. I will work with him to narrow the problem and reformulate the question.. Isn't this http://gcc.gnu.org/PR27067? If so it has regressed as that was supposedly fixed in 4.3. I have test the PR27067's test case, and it indeed works. I mean, gcc 4.3.0 create a correct app. But in Mozilla, the problem is not such simple. The test case is just to compile a single c++ source file to get a exe. There is no shared library and import library. After I compile the test case of PR27067, I examine the object file of the c++ file and I got: U __ZTVN10__cxxabiv117__class_type_infoE U __ZTVN10__cxxabiv120__si_class_type_infoE U __ZTVN10__cxxabiv121__vmi_class_type_infoE 0007 T __ZThn4_N6bottom4fun1Ev U [EMAIL PROTECTED] 0021 T __ZThn4_N6bottom4fun2Ev U [EMAIL PROTECTED] 003b T __ZThn4_N6bottom4fun3Ev U [EMAIL PROTECTED] T __ZThn4_N6bottom4fun5Ev U [EMAIL PROTECTED] T __ZThn4_N6bottomD0Ev T __ZThn4_N6bottomD1Ev T __ZThn8_N6bottom4fun1Ev U [EMAIL PROTECTED] 001a T __ZThn8_N6bottom4fun2Ev U [EMAIL PROTECTED] 0034 T __ZThn8_N6bottom4fun3Ev U [EMAIL PROTECTED] T __ZThn8_N6bottom4fun6Ev U [EMAIL PROTECTED] T __ZThn8_N6bottomD0Ev T __ZThn8_N6bottomD1Ev Take the 0007 T __ZThn4_N6bottom4fun1Ev U [EMAIL PROTECTED] for example. Very similar pattern, yes, it is the same pattern with my test case above. And this this mean that our object file has the definition of bottom:fun1() but not have the definition of __attribute__((__stdcall__)) bottom:fun1(). Obviously, we have definition of __attribute__((__stdcall__)) bottom:fun1(), but the generated object file said it does not have! When we produce an exe from a single c++ file, there is no linking need, so there is no problem. But when we separate the definition and the usage. I mean, we put the definition into a DLL and then use it to generate another exe. This time, we need a linker to link the DLL. Rationally, the linker should search for [EMAIL PROTECTED] (__attribute__((__stdcall__)) bottom:fun1() ), but it only find there is a U [EMAIL PROTECTED] in the library, so a fail occur this way. And Obviously, this is not a linker error, it is the problem gcc generate a U [EMAIL PROTECTED] for indeed existing definition of __attribute__((__stdcall__)) bottom:fun1() . I hope I make the problem clear here. Any question and advice are welcomed! Regards! Bo
RE: configuring in-tree gmp/mpfr with none?
Andrew, Can you explain more why? Why I'm asking again now: I have found another problem because of this (besides the reduced ability to share config.cache files). This exacerbates what looks like a minor bug in gmp's configure. Sometimes, depending on build/host/target, gmp's configure sets M4=m4-not-needed. Setting the processor to none is a good way to get it down the not needed path. Though there might be other ways there, granted. And then gmp/configure runs flex. And then sometimes?always flex tries to run getenv(M4) || m4. Flex fails, sometimes creating lex.yy.c, sometimes not. I haven't tracked down this sometimes. When I run build under Python, no lex.yy.c, outside of Python, ok. I still have to dig in further to find out why. When lex.yy.c is not created, configure fails. It is looking for what file is the output. gmp/configure probably should not be setting M4, at least not when it runs flex. But gcc using processor=none doesn't help. I'll follow up with gmp folks. Thanks, - Jay Date: Wed, 18 Jun 2008 06:53:35 -0400 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: configuring in-tree gmp/mpfr with none? CC: gcc@gcc.gnu.org On Wed, Jun 18, 2008 at 12:40 AM, Jay wrote: Ah, I didn't realize any C or C++ code could be configured for other than a specific processor but I guess that makes sense -- it is Makefile, config.h, and such that are being modified, not the .o files, and they might be the same across many configurations, like if the compiler command lines and #defines can be the same, like if there is no need to know the size of a pointer or the endianness, etc.. I guess more code should work this way if possible. Thanks Andrew. Well gmp/mpfr are special in that they try to do the same thing as -mcpu=native with their configure script and they have some assembly files. Thanks, Andrew Pinski
Re: std::isfinite broken?
Paolo Carlini wrote: Hi ho, ho!! ;) It worked with me. Try a recent gcc (eg, 4.3.x) and you will get the same, actually expected, result of the original poster. Paolo. I believe this is a bug. I agree that -ffast-math will not always comply 100% with IEEE, as advertised. But, if I explicity ask isfinite(), I expect it to work. If it is really intended not to work, then at least documentation should state that.
RE: std::isfinite broken?
Neal Becker wrote on 31 July 2008 12:42: Paolo Carlini wrote: Hi ho, ho!! ;) It worked with me. Try a recent gcc (eg, 4.3.x) and you will get the same, actually expected, result of the original poster. Paolo. I believe this is a bug. I agree that -ffast-math will not always comply 100% with IEEE, as advertised. But, if I explicity ask isfinite(), I expect it to work. If it is really intended not to work, then at least documentation should state that. It does, as was already explained to you; re-read the thread. cheers, DaveK -- Can't think of a witty .sigline today
RE: std::isfinite broken?
Dave Korn wrote on 31 July 2008 12:45: Neal Becker wrote on 31 July 2008 12:42: If it is really intended not to work, then at least documentation should state that. It does, as was already explained to you; re-read the thread. Actually I can be more use than that, I'll show you the relevant bits of the manual: -ffast-math' Sets `-fno-math-errno', `-funsafe-math-optimizations', `-fno-trapping-math', `-ffinite-math-only' and ^^^ `-fno-signaling-nans'. `-ffinite-math-only' Allow optimizations for floating-point arithmetic that assume that arguments and results are not NaNs or +-Infs. So, to address your point: But, if I explicity ask isfinite(), I expect it to work. Fine. But what do you expect to happen if you explicitly tell it that no number in your program will ever be infinite, and then call isinfinite? You told GCC that it could assume isinfinite will always return zero, so it took your word for that and replaced all the calls by a constant zero. What do you want to happen in those circumstances? cheers, DaveK -- Can't think of a witty .sigline today
Re: GCC 4.3.2 Status Report (2008-07-31)
Priority # Change from Last Report --- --- P13 - 5 P2 115 - 2 P32 - 1 --- --- Total 120 - 8 PR35752, which is a P2 regression caused by libtool, is waiting for approval upstream. Should we make an exception to the usual rules and apply the fix on the branch? Paolo
Re: GCC 4.3.2 Status Report (2008-07-31)
As we are approaching the intended release date of 4.3.2 we need to address the P1 bugs or downgrade them accordingly. Two of the P1s have patches posted (more than 3 resp. 2 weeks ago), so they just need reviewing. For the record, these are: http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00722.html reload.c (CCing Ulrich Weigand) http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01305.html dwarf2out.c (CCing Jason Merrill) Paolo
Re: GCC 4.3.2 Status Report (2008-07-31)
Hi Paolo, * Paolo Bonzini wrote on Thu, Jul 31, 2008 at 02:53:21PM CEST: PR35752, which is a P2 regression caused by libtool, is waiting for approval upstream. Should we make an exception to the usual rules and apply the fix on the branch? If by exception to the usual rule, you mean that you would like to apply the patch to GCC before it's accepted in Libtool, then can you give me 24 hours, which may just be enough to not need to bend this particular rule? Thanks, Ralf
Re: GCC 4.3.2 Status Report (2008-07-31)
Ralf Wildenhues wrote: Hi Paolo, * Paolo Bonzini wrote on Thu, Jul 31, 2008 at 02:53:21PM CEST: PR35752, which is a P2 regression caused by libtool, is waiting for approval upstream. Should we make an exception to the usual rules and apply the fix on the branch? If by exception to the usual rule, you mean that you would like to apply the patch to GCC before it's accepted in Libtool And only on the branch. Tomorrow it's a public holiday here, so I wouldn't apply the patch before monday anyway. Paolo
Re: GCC 4.3.2 Status Report (2008-07-31)
On Thu, Jul 31, 2008 at 03:10:46PM +0200, Paolo Bonzini wrote: Ralf Wildenhues wrote: Tomorrow it's a public holiday here, so I wouldn't apply the patch before monday anyway. If the patch is checked in on Monday or Tuesday, that's still fine, no need to use exceptions. Jakub
Re: configuring in-tree gmp/mpfr with none?
Jay wrote: Andrew, Can you explain more why? Because at some point, no released version worked on intel macs. And then gmp/configure runs flex. And then sometimes?always flex tries to run getenv(M4) || m4. Yes, Flex uses m4. gmp/configure probably should not be setting M4 Yes, I think that setting M4=m4-not-needed should be done only for debugging purposes. Otherwise, GMP should always look for m4 in its configure script, and set it to a valid value in the makefile. Paolo
Re: GCC 4.3.2 Status Report (2008-07-31)
Paolo Bonzini wrote: http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01305.html dwarf2out.c (CCing Jason Merrill) That patch went in a while back, but your message led me to the one that still needed reviewing. :) Jason
Re: gcc emit wrong symbols in multiple inheritance case
Bo Yang wrote: When we produce an exe from a single c++ file, there is no linking need, so there is no problem. But when we separate the definition and That's not how it works, the linker is always required to produce an executable. And Obviously, this is not a linker error, it is the problem gcc generate a U [EMAIL PROTECTED] for indeed existing definition of __attribute__((__stdcall__)) bottom:fun1() . The U lines are correct and aren't the problem; those are call sites to the properly mangled symbol name. What's incorrect is that gcc emits the function definitions (the 'T' lines) without the proper stdcall name mangling. If gcc used the proper mangling for the definitions then the undefined call sites would no longer be undefined and would not show up in the objdump output any more. Brian
Re: [Ada] GCC Ada bootstrap suggestion
Arnaud Charlet wrote: For half a year now, I've been working on the GCC Fortran front-end; but I'm also quite interested in Ada as a language. However, I don't quite like the idea that one needs a working Ada compiler to bootstrap the Ada front-end. Well, it's the same with a C compiler to bootstrap GCC, but anyways :D Also, at some point GCC will require C++ to bootstrap, so the same issues will arise there. Well, the point is, I'm using a GNU/Linux system I mainly built from scratch, so there's no easy package-installer available for me and I've to built everything from source (which is, of course, my own fault). My system started out with a gcc C compiler, so I could easily bootstrap and install any newer GCC, including C++, Java or Fortran, as I wanted. And even if gcc eventually moves on to C++, there will still be an older gcc I could bootstrap with a C compiler only and use that version's C++ compiler for the newest release. With Ada, however, I'm at least not aware of another compiler I could bootstrap using my C compiler and use that one subsequentally to bootstrap GNAT. At the moment, I'm trying to bootstrap it using a binary GNAT 3.15p which was also somewhat hard to find on the net; and this does not quite work out at the moment, as the included gcc (2.8.1 IIRC) is far too old and buggy to build even gcc-3.1 with Ada support for bootstrapping the gcc-4.3 release. At least I don't quite find it an easy task to get a recent GNAT build from source... I had the idea, based upon how gfortran works, that one could implement some basic AST-to-C translation component (it would be quite easy for the Fortran AST) that could then be used as a very basic Ada-to-C compiler re-using most of the existing Ada compiler. With this new tool, one could compile the Ada front-end sources to C files. Sure, this could theoretically be done, but so far, there has not been much interest in doing that, given that cross compiling GCC is always available as an option. So you think I should boot into Microsoft Windows, install the cygwin GNAT binaries and use those to cross-compile gcc-4.3 for my GNU/Linux system? Or at least boot up a live-cd that has the option to use a package installer for an existing GNAT and compile GCC with that? At least to me this sounds somewhat disgusting. I believe it would be at least some nice idea to make some binary-distributions easily available (and in a place they can be found). If I give my idea some further thoughts (and finally manage to build GNAT on my system) and it seems to be quite easily doable, are you interested in results of my research and experiments? Cheers, Daniel -- Done: Arc-Bar-Sam-Val-Wiz, Dwa-Elf-Gno-Hum-Orc, Law-Neu-Cha, Fem-Mal Underway: Cav-Dwa-Law-Fem To go:Cav-Hea-Kni-Mon-Pri-Ran-Rog-Tou
Re: [Ada] GCC Ada bootstrap suggestion
Well, the point is, I'm using a GNU/Linux system I mainly built from scratch, so there's no easy package-installer available for me and I've to built everything from source (which is, of course, my own fault). My system started out with a gcc C compiler, so I could easily bootstrap and install any newer GCC, including C++, Java or Fortran, as I wanted. Right, so when building such system from scratch, doing a cross compiler is not really the hardest part. So you think I should boot into Microsoft Windows, install the cygwin GNAT binaries and use those to cross-compile gcc-4.3 for my GNU/Linux system? Or at least boot up a live-cd that has the option to use a package installer for an existing GNAT and compile GCC with that? At least to me this sounds somewhat disgusting. I have no idea what your set up is. I'd suggest using whatever environment you can cross compile from (which includes any standard linux box, or any windows box). I believe it would be at least some nice idea to make some binary-distributions easily available (and in a place they can be found). Sure, there are some binaries available from libre.adacore.com and from some other sites. If I give my idea some further thoughts (and finally manage to build GNAT on my system) and it seems to be quite easily doable, are you interested in results of my research and experiments? Not sure what 'my idea' is here. If you're talking about creating a C generator, that does not fit into the 'quite easily doable' category. Arno
Re: [Ada] GCC Ada bootstrap suggestion
On Thu, 2008-07-31 at 18:42 +0200, Daniel Kraft wrote: With Ada, however, I'm at least not aware of another compiler I could bootstrap using my C compiler and use that one subsequentally to bootstrap GNAT. At the moment, I'm trying to bootstrap it using a binary GNAT 3.15p which was also somewhat hard to find on the net; and this does not quite work out at the moment, as the included gcc (2.8.1 IIRC) is far too old and buggy to build even gcc-3.1 with Ada support for bootstrapping the gcc-4.3 release. At least I don't quite find it an easy task to get a recent GNAT build from source... Most Linux distributions have been packaging GNAT binaries for a while now so you just need to take any recent gcc/gnat (4.1 and above) .deb or .rpm, extract the gcc/gnat binaries following the documented way for the given packaging format (ar and tar for .deb, cpio for rpm) and use them on your system to build your own GCC. Sincerely, Laurent
GNAT build failure on cross
Hi, I seem to have bumped into something. I threw away my svn trunk checkout and did another just in case. There are no Ada multilib patches in this tree. I have checked and am pretty sure I have no changes to anything that is not an RTEMS run-time related file. I can build a native compiler but when using that to build a cross rtems compiler, I get this: make.adb:662:32: expected type Gnat.Strings.String_Access defined at g-string.ads:41 make.adb:662:32: found type System.Strings.String_Access make.adb:663:32: expected type Gnat.Strings.String_Access defined at g-string.ads:41 make.adb:663:32: found type System.Strings.String_Access make.adb:664:32: expected type Gnat.Strings.String_Access defined at g-string.ads:41 make.adb:664:32: found type System.Strings.String_Access make.adb:689:39: Get_Target_Object_Suffix is not visible make.adb:689:39: non-visible declaration at s-os_lib.ads:556 make.adb:1700:19: no candidate interpretations match the actuals: make.adb:1700:19: too many arguments in call to Normalize_Compiler_Switches make.adb:1702:22: expected type System.Strings.String_List_Access make.adb:1702:22: found type Gnat.Strings.String_List_Access defined at g-string.ads:51 make.adb:1702:22: == in call to Normalize_Compiler_Switches at switch-m.ads:45 make.adb:4460:36: expected type System.Os_Lib.File_Descriptor make.adb:4460:36: found type Gnat.Os_Lib.File_Descriptor defined at g-os_lib.ads:160 make.adb:6605:13: expected type System.Os_Lib.File_Descriptor make.adb:6605:13: found type Gnat.Os_Lib.File_Descriptor defined at g-os_lib.ads:160 Any suggestions? -- Joel Sherrill, Ph.D. Director of Research Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
The g++ error output
Hello, i had the following Problem today: I have a class called GUI, that i included and instantiated. Today i extended my Code (among other things) with an enum that had an Element 'GUI'. I didn't knew that this isn't possible and never even thought about it. When i tried to compile my Code, i got an error, of course. g++ tells me that GUI is not a type, and where the error occurs. g++ unfortunately didn't told me, why GUI is not a type. I knew, there is a type called GUI, i defined it. After hours of pondering about my changes to the code, it just came to me: maybe its the newly added enum. If g++ just would've told me that it considers GUI to be an element of that enum, that would've saved me a lot of time. I believe this is a general problem: g++ tells *what* the problem is and *where* the problem occurs (file/line). But it does not tell me *why* there is a problem. Usually that is enough information: I have the information what the problem is and where to look, and i just see why there is a problem. But sometimes it bits me, like today. The enum wasn't even in that file, but in another i included. I hope you don't consider this as flaming or something, just critics to improve this wonderful compiler and make hacking easier for people like me without an expert understanding of C++. Cheers, ingmar
Help with identifing all cost models in GCC to make it adaptable ?..
Dear All, We continue developing adaptable GCC (MILEPOST GCC) and we plan to have more results this fall on selecting good optimization passes and their orders to improve program execution time, reduce code size and compilation time across different architectures automatically using statistical techniques and machine learning. As I mentioned during last GCC Summit, we are now ready to look at a finer-grain level optimizations, i.e. how to automatically tune all GCC optimization cost models within passes to decide whether to apply specific transformations and what should be their parameters. To do that, ideally we need to identify all the cost models within GCC with their dependencies, and add support to our Interactive Compilation Interface to be able to continuously monitor and bias their behavior to automatically (re)tune them on new architectures. I am afraid it will take me ages to find myself all the cost models within GCC, so I would be very grateful for any help in identifying those cost models (with the pass names and places in the source code) particularly that are known to be hard to tune manually or which may have complex interactions with other transformations (we should be able to capture those interactions automatically)! Ideally, we would like to make GCC a fully modular compiler which will be tuned (mostly) automatically to any particular architecture using a given set of related optimizations. We hope that it may simplify evolution of the compiler and it will be much easier to add new optimizations (even by end-user through plugins) since developers will have less problems thinking how to plug them into the current hardwired optimization heuristic. So I hope that with your help we can make GCC a best optimizing compiler, and not only for x86 but for any architecture ;) ... By the way, in case someone is interested, you can find some of our ideas on self-tuning MILEPOST GCC here: http://gcc-ici.sourceforge.net/papers/fmtp2008.pdf Sorry for bothering and looking forward to hearing from you, Grigori P.S. I will be on vacations soon so you can also contact Abid Malik from INRIA (in CC) who will help adding support to GCC-ICI to monitor optimization cost models ... Grigori Fursin, PhD Research Scientist, INRIA Saclay, France http://unidapt.org - tackling the complexity of future computing systems using machine learning
Re: The g++ error output
ingmar wirths [EMAIL PROTECTED] writes: I hope you don't consider this as flaming or something, just critics to improve this wonderful compiler and make hacking easier for people like me without an expert understanding of C++. Thanks for your note. Unfortunately it is too vague for us to know what to change. I would encourage you to file a report at http://gcc.gnu.org/bugzilla/ with a specific example of what g++ does today and what you would like it to do in the future. See also http://gcc.gnu.org/bugs.html. Thanks. Ian
Re: Help with identifing all cost models in GCC to make it adaptable ?..
Grigori, Many of the costs now are handled by GCC parameters. See gcc/params.def accessed in the source code using PARAM_VALUE. Many other cost models use macros with COST in their name, such as TARGET_RTX_COSTS / rtx_cost BRANCH_COST (and LOGICAL_OP_NON_SHORT_CIRCUIT) MEMORY_MOVE_COST REGISTER_MOVE_COST MAX_CONDITIONAL_EXECUTE David
gcc-4.3-20080731 is now available
Snapshot gcc-4.3-20080731 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080731/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 138440 You'll find: gcc-4.3-20080731.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20080731.tar.bz2 C front end and core compiler gcc-ada-4.3-20080731.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20080731.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20080731.tar.bz2 C++ front end and runtime gcc-java-4.3-20080731.tar.bz2 Java front end and runtime gcc-objc-4.3-20080731.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20080731.tar.bz2The GCC testsuite Diffs from 4.3-20080724 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Inconsistent use of allocator wrapper macros in libiberty
Quite a few files in libiberty use XNEWVEC as a replacement for malloc(), but the they are being paired with plain free(); XDELVEC is not being used. Is there some reason for the inconsistency, such as some transitional issue, or should this be fixed?
Re: Inconsistent use of allocator wrapper macros in libiberty
Is there some reason for the inconsistency, Not really. Patches welcome.
RE: Help with identifing all cost models in GCC to make it adaptable ?..
Thanks, David! That's a good start. I will need to find places in GCC where these parameters are used to monitor the behavior of transformations based on these parameters and be able to change the compiler decisions through ICI to learn how to tune those costs based on program execution time/code size... Also, I would prefer to concentrate on only most critical/important costs right now (for example, within register allocation, scheduling, etc) since this research is very time consuming ... Cheers, Grigori Grigori Fursin, PhD Research Scientist, INRIA, France http://fursin.net/research -Original Message- From: David Edelsohn [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 9:44 PM To: Grigori Fursin Cc: 'gcc' Subject: Re: Help with identifing all cost models in GCC to make it adaptable ?.. Grigori, Many of the costs now are handled by GCC parameters. See gcc/params.def accessed in the source code using PARAM_VALUE. Many other cost models use macros with COST in their name, such as TARGET_RTX_COSTS / rtx_cost BRANCH_COST (and LOGICAL_OP_NON_SHORT_CIRCUIT) MEMORY_MOVE_COST REGISTER_MOVE_COST MAX_CONDITIONAL_EXECUTE David
Re: gcc will become the best optimizing x86 compiler
On Thursday 31 July 2008 11:36, Dave Korn wrote: Agner Fog wrote on 31 July 2008 07:14: Denys Vlasenko wrote: I tend to doubt that odd-byte aligned large memcpys are anywhere near typical. malloc and mmap both return well-aligned buffers (say, 8 byte aligned). Static and on-stack objects are also at least word-aligned 99% of the time. memcpy can just use relatively simple code for copies in which either src or dst is not word aligned. This cuts possibilities down from 16 to 4 (or even 2?). The XMM code is still more than 3 times faster than rep movsl when data are aligned by 4 or 8, but not by 16. Even if odd addresses are rare, they must be supported, but we can put the most common cases first. In the real world, unaligned memcpys are anything but rare. Everything's networked these days, remember? Stuff gets misaligned real quick when you start adding and removing various network layer headers and trailers to unpredictably-sized packets. Headers are usually at least rounded to 16-bit multiple. Trailers do not matter to alignment. This happens in kernel space. In kernel space, there are many differences. * memcpy are rarely bigger than a page - this negates any gains from non-temporal MOVs * memcpy cannot use XMM registers (otherwise lazy FPU saving doesn't work) * kernel developers would never accept multi-kilobyte memcpy implementation anyway Not to mention that network packets are ~1500 bytes long, even jumbo packets are only 9k tops. -- vda
Re: gcc emit wrong symbols in multiple inheritance case
On Thu, Jul 31, 2008 at 11:00 PM, Brian Dessent [EMAIL PROTECTED] wrote: Bo Yang wrote: When we produce an exe from a single c++ file, there is no linking need, so there is no problem. But when we separate the definition and That's not how it works, the linker is always required to produce an executable. I am wrong. But how the linker find the __attribute__((__stdcall__)) bottom::fun1() when there is a single source file? There is no such definition in the object file. And Obviously, this is not a linker error, it is the problem gcc generate a U [EMAIL PROTECTED] for indeed existing definition of __attribute__((__stdcall__)) bottom:fun1() . The U lines are correct and aren't the problem; those are call sites to the properly mangled symbol name. What's incorrect is that gcc emits the function definitions (the 'T' lines) without the proper stdcall name mangling. If gcc used the proper mangling for the definitions then the undefined call sites would no longer be undefined and would not show up in the objdump output any more. So, are you sure this bug is identical to PR27067 or not? Regards! Bo
Is there some mistakes in comments of passes.c?
The comments in passes.c at the beginning are identical to toplev.c. -- 此致 敬礼！ 梁��
[Bug c++/36979] New: 'sizeof' wrong when using typedef ... __attribute__((mode(*I))) in a template
This doesn't work: g++-4.3.1
These work: g++-3.4.6 g++-4.1.2 g++-4.2.4
$ g++-4.3.1 -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.1-r1/work/gcc-4.3.1/configure --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.1
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.1
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.1/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.1/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --enable-multilib --enable-libmudflap
--disable-libssp --enable-cld --enable-java-awt=gtk --enable-objc-gc
--enable-languages=c,c++,java,objc,obj-c++,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.1-r1 p1.1'
Thread model: posix
gcc version 4.3.1 (Gentoo 4.3.1-r1 p1.1)
Same results in 4.3.1 with -O2/-O0 and with/without -m32.
I get the size of unsigned, instead of the size of mode(*I).
---
extern C void abort();
templateclass unused
void function()
{
typedef unsigned uint8_t __attribute__((mode(QI)));
typedef unsigned uint16_t __attribute__((mode(HI)));
typedef unsigned uint32_t __attribute__((mode(SI)));
typedef unsigned uint64_t __attribute__((mode(DI)));
//typedef unsigned uint128_t __attribute__((mode(TI)));
if(sizeof(uint8_t) != sizeof((uint8_t)0) ||
sizeof(uint16_t) != sizeof((uint16_t)0) ||
sizeof(uint32_t) != sizeof((uint32_t)0) ||
sizeof(uint64_t) != sizeof((uint64_t)0)
)
abort();
}
int main()
{
functionchar();
}
--
Summary: 'sizeof' wrong when using typedef ...
__attribute__((mode(*I))) in a template
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cyp561 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36979
[Bug middle-end/36980] New: Bootstrap broken with RTL checking on i586
At revision 138355 the compiler configured with RTL checking fails to bootstrap
on i586-suse-linux with:
/home/eric/build/gcc/native32/./gcc/xgcc -B/home/eric/build/gcc/native32/./gcc/
-B/home/eric/install/gcc/i586-suse-linux/bin/
-B/home/eric/install/gcc/i586-suse-linux/lib/ -isystem
/home/eric/install/gcc/i586-suse-linux/include -isystem
/home/eric/install/gcc/i586-suse-linux/sys-include -g -O2 -O2 -g -O2 -DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc
-I/home/eric/svn/gcc/libgcc -I/home/eric/svn/gcc/libgcc/.
-I/home/eric/svn/gcc/libgcc/../gcc -I/home/eric/svn/gcc/libgcc/../include
-I/home/eric/svn/gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS -DUSE_TLS -o crtfastmath.o -MT crtfastmath.o -MD -MP -MF
crtfastmath.dep -msse -minline-all-stringops -c \
/home/eric/svn/gcc/libgcc/../gcc/config/i386/crtfastmath.c
{ /home/eric/build/gcc/native32/./gcc/nm -pg _muldi3_s.o _negdi2_s.o
_lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o
_clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o
_absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o
_mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o
_ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o
_popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o
_paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o
_muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o
_fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o
_fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o
_floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o
_udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o addtf3_s.o
divtf3_s.o eqtf2_s.o getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o
unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o
fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o extendsftf2_s.o
extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o
tf-signs_s.o unwind-dw2_s.o unwind-dw2-fde-glibc_s.o unwind-sjlj_s.o
gthr-gnat_s.o unwind-c_s.o emutls_s.o; echo %%; \
cat /home/eric/svn/gcc/libgcc/../gcc/libgcc-std.ver
/home/eric/svn/gcc/libgcc/../gcc/config/i386/libgcc-glibc.ver \
| sed -e '/^[ ]*#/d' \
-e 's/^%\(if\|else\|elif\|endif\|define\)/#\1/' \
| /home/eric/build/gcc/native32/./gcc/xgcc
-B/home/eric/build/gcc/native32/./gcc/
-B/home/eric/install/gcc/i586-suse-linux/bin/
-B/home/eric/install/gcc/i586-suse-linux/lib/ -isystem
/home/eric/install/gcc/i586-suse-linux/include -isystem
/home/eric/install/gcc/i586-suse-linux/sys-include -g -O2 -O2 -g -O2 -DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc
-I/home/eric/svn/gcc/libgcc -I/home/eric/svn/gcc/libgcc/.
-I/home/eric/svn/gcc/libgcc/../gcc -I/home/eric/svn/gcc/libgcc/../include
-I/home/eric/svn/gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS -DUSE_TLS -E -xassembler-with-cpp -; \
} | gawk -f /home/eric/svn/gcc/libgcc/../gcc/mkmap-symver.awk
tmp-libgcc.map
/home/eric/svn/gcc/libgcc/../gcc/config/i386/crtfastmath.c: In function
'set_fast_math':
/home/eric/svn/gcc/libgcc/../gcc/config/i386/crtfastmath.c:99: internal
compiler error: RTL check: expected code 'reg', have 'mem' in rhs_regno, at
rtl.h:1005
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make[3]: *** [crtfastmath.o] Error 1
make[3]: *** Waiting for unfinished jobs
Starting program: /home/eric/build/gcc/native32/gcc/cc1 crtfastmath.i -O2 -msse
-minline-all-stringops -mtune=i586 -g
warning: Lowest section in system-supplied DSO at 0xe000 is .hash at
e0b4
__get_cpuid_max __get_cpuid set_fast_math
Analyzing compilation unit
Performing interprocedural optimizations
visibility early_local_cleanups summary generate inline static-var
pure-constAssembling functions:
set_fast_math
Breakpoint 2, internal_error (
gmsgid=0x91fd2f4 RTL check: expected code '%s', have '%s' in %s, at
%s:%d) at /home/eric/svn/gcc/gcc/diagnostic.c:633
633 va_start (ap, gmsgid);
(gdb) bt
#0 internal_error (
gmsgid=0x91fd2f4 RTL check: expected code '%s', have '%s' in %s, at
%s:%d) at /home/eric/svn/gcc/gcc/diagnostic.c:633
#1 0x0855aeae in rtl_check_failed_code1 (r=0xf7dfbeb8, code=REG,
file=0x91c9ce1 /home/eric/svn/gcc/gcc/rtl.h, line=1005,
func=0x91c9cd7 rhs_regno) at /home/eric/svn/gcc/gcc/rtl.c:513
#2
[Bug middle-end/36980] [4.4 Regression] Bootstrap broken with RTL checking on i586
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||build, ice-checking, ice-on- ||valid-code Summary|Bootstrap broken with RTL |[4.4 Regression] Bootstrap |checking on i586|broken with RTL checking on ||i586 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36980
[Bug middle-end/36980] [4.4 Regression] Bootstrap broken with RTL checking on i586
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-07-31 06:57 --- Created an attachment (id=15980) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15980action=view) Preprocessed file to be compiled with -msse -g -mtune=i586. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36980
[Bug c++/36490] Attempt to copy a temporary object during passing it to a function as a const reference
--- Comment #1 from fang at csl dot cornell dot edu 2008-07-31 07:00 --- See PR 25950 and all of its dupes. The copy constructor needs to be publicly accessible where the temporary rvalue is bound to a reference parameter. -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36490
[Bug c++/25950] [DR 391] Reference binding and explicit copy constructors
--- Comment #30 from pinskia at gcc dot gnu dot org 2008-07-31 07:03 --- *** Bug 36490 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dervih at interia dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25950
[Bug c++/36490] Attempt to copy a temporary object during passing it to a function as a const reference
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-31 07:03 --- *** This bug has been marked as a duplicate of 25950 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36490
[Bug middle-end/36980] [4.4 Regression] Bootstrap broken with RTL checking on i586
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-31 07:08 --- Yes this code is definitely wrong as on the PPC, we can load the stack pointer from memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36980
[Bug c++/36981] New: Template nested inner classes are not resolved.
Template nested inner classes are not resolved:
template typename T
class A
{
public:
class AA { };
};
template typename T
class B : public AT
{
public:
class BB : public AA { };
//class BB : public AT::AA { }; // Workaround.
};
int main(int argc, char* argv[])
{
Bint b;
return 0;
}
Brings the following error:
error: expected class-name before '{' token
--
Summary: Template nested inner classes are not resolved.
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: 4ekucT at tut dot by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36981
[Bug middle-end/36980] [4.4 Regression] Bootstrap broken with RTL checking on i586
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-07-31 07:16 --- Just to confirm that reverting r138135-r138140 makes the bug vanish. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36980
[Bug c++/36981] Template nested inner classes are not resolved.
--- Comment #1 from 4ekucT at tut dot by 2008-07-31 07:17 --- Created an attachment (id=15981) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15981action=view) Template nested inner classes are not resolved. Compile to reproduce the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36981
[Bug c++/36709] Compiler allows namespace and class to have same name and doesn't generate ambiguous reference error when it should result from this.
--- Comment #1 from fang at csl dot cornell dot edu 2008-07-31 07:19 --- Dupe of PR 30734 (first reported as PR 2708). -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36709
[Bug tree-optimization/36861] [4.3 Regression] boost's compressed avl confuses GCC
--- Comment #21 from aldot at gcc dot gnu dot org 2008-07-31 07:56 --- Lothar, see #10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36861
[Bug preprocessor/36649] [4.3/4.4 Regression] -H option doesn't work as expected
--- Comment #4 from jakub at gcc dot gnu dot org 2008-07-31 08:00 --- Subject: Bug 36649 Author: jakub Date: Thu Jul 31 07:59:18 2008 New Revision: 138360 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138360 Log: PR preprocessor/36649 * c-pch.c (c_common_read_pch): Save and restore line_table-trace_includes across PCH restore. * gcc.dg/pch/cpp-3.c: New test. * gcc.dg/pch/cpp-3.hs: New file. * gcc.dg/pch/cpp-3a.h: New file. * gcc.dg/pch/cpp-3b.h: New file. Added: trunk/gcc/testsuite/gcc.dg/pch/cpp-3.c trunk/gcc/testsuite/gcc.dg/pch/cpp-3.hs trunk/gcc/testsuite/gcc.dg/pch/cpp-3a.h trunk/gcc/testsuite/gcc.dg/pch/cpp-3b.h Modified: trunk/gcc/ChangeLog trunk/gcc/c-pch.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36649
[Bug debug/36278] [4.2/4.3/4.4 Regression] ICE with typedef void in namespace and using the defined type in another when compiling with -g
--- Comment #3 from jakub at gcc dot gnu dot org 2008-07-31 08:02 --- Subject: Bug 36278 Author: jakub Date: Thu Jul 31 08:01:25 2008 New Revision: 138361 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138361 Log: PR debug/36278 * dwarf2out.c (get_context_die): New function. (force_decl_die, force_type_die): Use it. (dwarf2out_imported_module_or_decl): Likewise. If base_type_die returns NULL, force generation of DW_TAG_typedef and put that into DW_AT_import. * g++.dg/debug/namespace2.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/namespace2.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36278
[Bug c/36970] GCC should display a warning when trying to free a static array
--- Comment #1 from jakub at gcc dot gnu dot org 2008-07-31 08:04 --- Subject: Bug 36970 Author: jakub Date: Thu Jul 31 08:02:49 2008 New Revision: 138362 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138362 Log: PR c/36970 * builtins.c (maybe_emit_free_warning): New function. (expand_builtin): Process BUILT_IN_FREE even at -O0. Call maybe_emit_free_warning for BUILT_IN_FREE. * gcc.dg/free-1.c: New test. * gcc.dg/free-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/free-1.c trunk/gcc/testsuite/gcc.dg/free-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36970
[Bug c++/36982] New: Unfolding of template function (in namesspace) using overloads (in same namespace) requires forward declarations
// The following self-contained code (see below, I dont know how to
// attach files to this report) produces the bug (see embedded comments).
//
// The command compiler command line and output is as this:
//
// g++ -c -O2 -I . -DSTATIC_BUILD -Wall x.cpp
// x.cpp: In function bool ReadSpace::Read(const char*,
// std::vectorT, // std::allocator_Tp1 ) [with T = MyType]:
// x.cpp:58: instantiated from here
// x.cpp:34: error: invalid initialization of reference of type
// int from expression of type MyType
// x.cpp:27: error: in passing argument 2 of
// bool ReadSpace::Read(const char*, int)
//
// Source code (x.cpp) ...
//
#include vector
/* - Uncoment this block for GCC 4.3.1 workaround
//
// Forward declarations needed by new GCC 4.3.1 compiler ...
//
// - Not needed by GCC 4.0.2 and previous versions !
// - Not needed by (Windows) MSC 8.0 (VS 2005) and previous versions !
//
// Note furthermore that IF everything is kept in the GLOBAL namespace,
// there is NO error - this, to me, indicates a GCC 4.3.1 compiler bug.
//
// LFN, 2008-07-31
//
struct MyType;
namespace ReadSpace
{
static inline bool Read( const char* Str, MyType v );
};
*/
namespace ReadSpace
{
static inline bool Read( const char* Str, int v )
{ v = 0; return true; }
template class T
static inline bool Read( const char* Str, std::vector T v )
{
T Help;
if ( !Read( Str, Help ) )
return false;
v.push_back( Help );
return true;
}
}
struct MyType
{
int i;
};
namespace ReadSpace // Extend the namespace ...
{
static inline bool Read( const char* Str, MyType v )
{ return Read( Str, v.i ); }
}
using namespace ReadSpace;
int main()
{
std::vector MyType v;
const char* Str = 25;
return Read( Str, v ) ? 0 : 1;
}
--
Summary: Unfolding of template function (in namesspace) using
overloads (in same namespace) requires forward
declarations
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lfn dot privat at mail dot dk
GCC build triplet: Configured with: ../configure --prefix=/usr --with-
local-prefix=
GCC host triplet: gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch
revision
GCC target triplet: Target: i586-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36982
[Bug c++/36981] Template nested inner classes are not resolved.
--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-31 08:34 --- This is standard conforming behavior. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36981
[Bug c++/36709] Compiler allows namespace and class to have same name and doesn't generate ambiguous reference error when it should result from this.
--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-31 08:39 --- *** This bug has been marked as a duplicate of 30734 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36709
[Bug c++/30734] name conflict between class and namespace name is not recognized
--- Comment #6 from paolo dot carlini at oracle dot com 2008-07-31 08:39 --- *** Bug 36709 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||rquabili at princeton dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30734
[Bug preprocessor/36649] [4.3/4.4 Regression] -H option doesn't work as expected
--- Comment #5 from jakub at gcc dot gnu dot org 2008-07-31 08:45 --- Subject: Bug 36649 Author: jakub Date: Thu Jul 31 08:44:24 2008 New Revision: 138368 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138368 Log: PR preprocessor/36649 * c-pch.c (c_common_read_pch): Save and restore line_table-trace_includes across PCH restore. * gcc.dg/pch/cpp-3.c: New test. * gcc.dg/pch/cpp-3.hs: New file. * gcc.dg/pch/cpp-3a.h: New file. * gcc.dg/pch/cpp-3b.h: New file. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pch/cpp-3.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pch/cpp-3.hs branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pch/cpp-3a.h branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pch/cpp-3b.h Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/c-pch.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36649
[Bug debug/36278] [4.2/4.3/4.4 Regression] ICE with typedef void in namespace and using the defined type in another when compiling with -g
--- Comment #4 from jakub at gcc dot gnu dot org 2008-07-31 08:49 --- Subject: Bug 36278 Author: jakub Date: Thu Jul 31 08:48:26 2008 New Revision: 138369 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138369 Log: PR debug/36278 * dwarf2out.c (get_context_die): New function. (force_decl_die, force_type_die): Use it. (dwarf2out_imported_module_or_decl): Likewise. If base_type_die returns NULL, force generation of DW_TAG_typedef and put that into DW_AT_import. * g++.dg/debug/namespace2.C: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/debug/namespace2.C Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/dwarf2out.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36278
[Bug preprocessor/36649] [4.3/4.4 Regression] -H option doesn't work as expected
--- Comment #6 from jakub at gcc dot gnu dot org 2008-07-31 08:51 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36649
[Bug debug/36278] [4.2/4.3/4.4 Regression] ICE with typedef void in namespace and using the defined type in another when compiling with -g
--- Comment #5 from jakub at gcc dot gnu dot org 2008-07-31 08:51 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36278
[Bug c/36970] GCC should display a warning when trying to free a static array
--- Comment #2 from jakub at gcc dot gnu dot org 2008-07-31 08:52 --- Implemented on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36970
[Bug libstdc++/36962] [C++0x] Add constructors / assignment operators from unique_ptr to shared_ptr
--- Comment #5 from paolo dot carlini at oracle dot com 2008-07-31 08:59 --- Hi again. I have essentially only one substantive comment: can you double check the implementation is correct vs 20.7.12.2.1/37 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36962
[Bug middle-end/36983] New: Trunk 138207 miscompiles 172.mgrid on x86-64
$ cat mgrid.f SUBROUTINE RESID(U,V,R,N,A) INTEGER N REAL*8 U(N,N,N),V(N,N,N),R(N,N,N),A(0:3) INTEGER I3, I2, I1 DO 600 I3=2,N-1 DO 600 I2=2,N-1 DO 600 I1=2,N-1 600 R(I1,I2,I3)=V(I1,I2,I3) -A(0)*( U(I1, I2, I3 ) ) -A(1)*( U(I1-1,I2, I3 ) + U(I1+1,I2, I3 ) + U(I1, I2-1,I3 ) + U(I1, I2+1,I3 ) + U(I1, I2, I3-1) + U(I1, I2, I3+1) ) -A(2)*( U(I1-1,I2-1,I3 ) + U(I1+1,I2-1,I3 ) + U(I1-1,I2+1,I3 ) + U(I1+1,I2+1,I3 ) + U(I1, I2-1,I3-1) + U(I1, I2+1,I3-1) + U(I1, I2-1,I3+1) + U(I1, I2+1,I3+1) + U(I1-1,I2, I3-1) + U(I1-1,I2, I3+1) + U(I1+1,I2, I3-1) + U(I1+1,I2, I3+1) ) -A(3)*( U(I1-1,I2-1,I3-1) + U(I1+1,I2-1,I3-1) + U(I1-1,I2+1,I3-1) + U(I1+1,I2+1,I3-1) + U(I1-1,I2-1,I3+1) + U(I1+1,I2-1,I3+1) + U(I1-1,I2+1,I3+1) + U(I1+1,I2+1,I3+1) ) RETURN END $ gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../src/configure --prefix=/home/jye2/rrs/138207/usr --enable-languages=c,c++,fortran --disable-bootstrap Thread model: posix gcc version 4.4.0 20080728 (experimental) [trunk revision 138207] (GCC) $ gfortran -O3 -ffast-math mgrid.f -c mgrid.f: In function 'resid': mgrid.f:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. $ gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../src/configure --prefix=/home/jye2/rrs/138206/usr --enable-languages=c,c++,fortran --disable-bootstrap Thread model: posix gcc version 4.4.0 20080728 (experimental) [trunk revision 138206] (GCC) $ gfortran -O3 -ffast-math mgrid.f -c $ -- Summary: Trunk 138207 miscompiles 172.mgrid on x86-64 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Joey dot ye at intel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36983
[Bug middle-end/36983] Trunk 138207 miscompiles 172.mgrid on x86-64
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-07-31 09:19 --- Works for me. Very likely a dup of PR36967. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC|richard dot guenther at |rguenth at gcc dot gnu dot |gmail dot com |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36983
[Bug tree-optimization/36373] [4.2/4.3 Regression] Wrong code with struct return
--- Comment #9 from jakub at gcc dot gnu dot org 2008-07-31 09:25 --- Downgrading to P2, as the required changes are probably too big and risky for the branches. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36373
[Bug middle-end/36984] New: ICE when gcc 4.4.0-20080730 compile lapack
lapack-lite-3.1.1/TESTING/LIN/schkeq.f gfortran -c schkeq.f -O3 -msse2 -mfpmath=sse -funroll-loops -fbounds-check schkeq.f: In function 'schkeq': schkeq.f:445: internal compiler error: in df_ref_chain_change_bb, at df-scan.c:1828 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. gcc --version gcc (GCC) 4.4.0 20080730 (experimental) -- Summary: ICE when gcc 4.4.0-20080730 compile lapack Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: linuxl4 at sohu dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36984
[Bug fortran/32095] Accepts invalid character(len(a)),dimension(1) :: a
--- Comment #1 from domob at gcc dot gnu dot org 2008-07-31 10:31 --- So the following two lines should give this error, right: subroutine test (a) character(len(a)) :: a end subroutine test subroutine test2 (n, arr) integer :: arr(n), n end subroutine test2 where in test2, reversing the order of the definition of arr(n) and n should make it work again. Did I understand this correctly? In this case, wouldn't it be enough to check that each symbol used in a specification expression already has a type != BT_UNKNOWN to ensure it already was specified? What's about that one, where i has an implicit type of INTEGER (if I'm not mistaken): subroutine test2 (i, arr) integer :: arr(i) end subroutine test2 Is that one allowed or is here an explicit specification of i needed, too? -- domob at gcc dot gnu dot org changed: What|Removed |Added CC||domob at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32095
[Bug c++/36985] New: initialize_flags_in_bb, at tree-into-ssa.c:437
GCC: % /usr/local/gcc-4.3.1/bin/g++-4.3.1 -v Using built-in specs. Target: i386-apple-darwin9.3.0 Configured with: ../gcc-4.3.1/configure --disable-nls --enable-languages=c,c++ --program-suffix=-4.3.1 --prefix=/usr/local/gcc-4.3.1 Thread model: posix gcc version 4.3.1 (GCC) System: Darwin 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386 Command-line: /usr/local/gcc-4.3.1/bin/g++-4.3.1 -o opt -DNDEBUG -O3 -Wall -Wextra test/bench.cc -I . -ltbb -lgmp -lgmpxx -mtune=native -march=native -fipa-cp -fipa-pta -ftree-loop-linear -ftree-loop-im -funswitch-loops -fivopts -ftree-parallelize-loops=2 -ftree-vectorize -funroll-loops -fwhole-program -ffast-math Output: /usr/local/include/boost/variant/variant.hpp: In member function 'typename Visitor::result_type boost::detail::variant::invoke_visitorVisitor::internal_visit(T, int) [with T = const xxx::core::unicity::nodexxx::configuration::uchar_ushort_mono, Visitor = const xxx::util::count_visitorxxx::configuration::uchar_ushort_mono]': /usr/local/include/boost/variant/variant.hpp:804: internal compiler error: in initialize_flags_in_bb, at tree-into-ssa.c:437 -- Summary: initialize_flags_in_bb, at tree-into-ssa.c:437 Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alexandre dot hamez at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36985
[Bug c++/36985] initialize_flags_in_bb, at tree-into-ssa.c:437
--- Comment #1 from alexandre dot hamez at gmail dot com 2008-07-31 10:41 --- I don't how to attach the preprocessed source. The file weight more than 1000k so it is refused by bugzilla. And I think that copy-paste 56000 lines of code is not the right thing to do? At least, it seams that is is related to boost. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36985
[Bug middle-end/36983] Trunk 138207 miscompiles 172.mgrid on x86-64
--- Comment #2 from Joey dot ye at intel dot com 2008-07-31 10:50 --- Yes. Just notice that latest trunk passes. -- Joey dot ye at intel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36983
[Bug libstdc++/36962] [C++0x] Add constructors / assignment operators from unique_ptr to shared_ptr
--- Comment #6 from paolo dot carlini at oracle dot com 2008-07-31 11:03 --- By the way, I'm under the impression that the differences between the TR1 and the C++0x versions are by now too many, way too many macros. At some point we should byte the bullet and separate completely for a great clean-up! (I did that for tuple, for instance, and it paid off immediately in the occasion of the int - size_t change, more changes to the constructors are expected...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36962
[Bug fortran/32095] Accepts invalid character(len(a)),dimension(1) :: a
--- Comment #2 from burnus at gcc dot gnu dot org 2008-07-31 11:14 --- subroutine test2 (n, arr) integer :: arr(n), n end subroutine test2 That example is valid as n is then implicitly typed as integer, which is later confirmed. It only becomes invalid using: implicit none or implicit real(a-z) Note: Code such as subroutine sub(n,array) implicit none real:: array(n) integer :: n end can be found in several real-world codes. Such declarations should be allowed, unless -std=* is given. (It is e.g. allowed by gfortran, ifort, sunf95, g95,...; but not by NAG f95. I think those compilers which allow it also do not warn with -std=*.) where in test2, reversing the order of the definition of arr(n) and n should make it work again. Did I understand this correctly? Yes (with above's implicit statements). Another example, which works with gfortran, but is rejected by other compilers: ifort: hjf.f90(5): error #6361: An array-valued argument is required in this context. [SIZE] integer :: b(size(a)), a(:) ^ hjf.f90(5): error #6435: This name has already been used in a specification expression. [A] integer :: b(size(a)), a(:) -^ NAG: Error: line 3: SIZE of A used before its array declarator g95: Error: Argument of SIZE intrinsic at (1) must be an array (gfortran compiles and gives the expected result.) subroutine sub(a) implicit none real:: b(size(a)), a(:) end I think on should be able to do something like you proposed, but with -std=gnu the above mentioned integer :: arr(n) integer :: n should be still permitted (but it should be rejected with -std=f*). See also: PR 34228. In any case, for the example given in comment 0 we need to give an error (as ifort or g95) or we need to get it working properly (as NAG f95) does. The former solution seems to be cleaner and easier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32095
[Bug c++/36985] initialize_flags_in_bb, at tree-into-ssa.c:437
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-07-31 11:24 --- 1000k compressed? If not, compress it. Otherwise put it on the web somewhere and post the link. We really need it to do anything about it... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36985
[Bug middle-end/36986] New: Trunk 138207 miscompiles 447.dealII
This bug is also caused by 138207, and latest trunk still fails (138353) $ g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../src/configure --disable-bootstrap --enable-languages=c,c++,fortran --enable-checking=assert Thread model: posix gcc version 4.4.0 20080731 (experimental) [trunk revision 138353] (GCC) $ g++ -c -O3 -ffast-math dof_tools.i.cc dof_tools.cc: In static member function 'static void DoFTools::make_flux_sparsity_pattern(const DoFHandlerdim, SparsityPattern, const FullMatrixdouble, const FullMatrixdouble) [with int dim = 3, SparsityPattern = CompressedBlockSparsityPattern]': dof_tools.cc:485: internal compiler error: in gimple_cond_get_ops_from_tree, at gimple.c:493 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: Trunk 138207 miscompiles 447.dealII Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Joey dot ye at intel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36986
[Bug tree-optimization/36978] [4.4 Regression] ICE in gimple_cond_set_lhs for -O2 -funswitch-loops after tuples merge
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-07-31 11:33 --- There is an easy workaround. Just do not fold the re-generated condition. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-07-30 23:53:12 |2008-07-31 11:33:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36978
[Bug middle-end/36986] Trunk 138207 miscompiles 447.dealII
--- Comment #1 from Joey dot ye at intel dot com 2008-07-31 11:33 --- Created an attachment (id=15982) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15982action=view) Preprocessed test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36986
[Bug c++/36985] initialize_flags_in_bb, at tree-into-ssa.c:437
--- Comment #3 from alexandre dot hamez at gmail dot com 2008-07-31 11:33 --- Created an attachment (id=15983) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15983action=view) Preprocessed sources. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36985
[Bug middle-end/36986] Trunk 138207 miscompiles 447.dealII
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-07-31 11:35 --- Note it is not miscompiled, but instead the compiler crashes. *** This bug has been marked as a duplicate of 36978 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36986
[Bug tree-optimization/36978] [4.4 Regression] ICE in gimple_cond_set_lhs for -O2 -funswitch-loops after tuples merge
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-07-31 11:35 --- *** Bug 36986 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||Joey dot ye at intel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36978
[Bug target/36822] [4.4 Regression] ICE in subst_reloads
--- Comment #2 from krebbel at gcc dot gnu dot org 2008-07-31 11:36 --- Fixed. -- krebbel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36822
[Bug target/36806] [4.4 Regression] I/Os hang at rev. 137631 on darwin9
--- Comment #24 from tkoenig at gcc dot gnu dot org 2008-07-31 11:38 --- Is this still an issue after the tuples merge? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36806
[Bug fortran/32095] Accepts invalid character(len(a)),dimension(1) :: a
--- Comment #3 from domob at gcc dot gnu dot org 2008-07-31 11:54 --- Thanks for the quick reply, Tobias. I'll try to get the used but not yet typed part implemented to emit errors for -std != gnu. To fix the problem in this PR, I see those possible solutions: a) Disallow not-yet-typed variables completely inside SIZE/LDBOUND/UBOUND/LEN (and possibly other use-cases). b) Expressively *allow* those with -std=gnu only in a specified set of use-cases, like DATA or as dimension/bound. I think I'd go for b) but I'm not sure to what extend there's code around we want to support with -std=gnu. Any other use-cases we want not-yet-typed variables to be allowed in this case? -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-06-13 20:54:10 |2008-07-31 11:54:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32095
[Bug c++/36478] [4.3/4.4 regression] warning not emitted when code expanded from macro
--- Comment #2 from dodji at gcc dot gnu dot org 2008-07-31 12:22 ---
Created an attachment (id=15984)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15984action=view)
candidate partial fix
This patch fixes the problem patially.
if you have:
void
foo ()
{
#define WARNS while(0)
#define DOES_NOT_WARN while(0);
WARNS; // { dg-warning }
DOES_NOT_WARN;
while (0); // { dg-warning }
}
---
The compiler (augmented with the patch) says:
/home/dodji/devel/src/gcc-bug-test.cc:6: warning: suggest a space before ; or
explicit braces around empty body in while statement
/home/dodji/devel/src/gcc-bug-test.cc:8: warning: suggest a space before ; or
explicit braces around empty body in while statement
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36478
[Bug target/35100] [4.2/4.3/4.4 regression] internal compiler error: in extract_insn, at recog.c:1990
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-31 12:31:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35100
[Bug c/36987] New: Truncated C struct data initializer with variable size trailing array
An initializer for a C struct with a variable sized last component is accepted,
but the data generated excludes the variable sized component.
struct s {
int16_t a,b,c,d;
int16_t y[];
} data = {0,0,0,0, {2,3,4,5}};
results in only the leading four int16_t values in the data segment.
Either the initializer data should be emitted, or the initializer should be
rejected with an error, or the struct declaration should be rejected with an
error, and presumably the first option would be preferable.
--
Summary: Truncated C struct data initializer with variable size
trailing array
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howard dot thomson at dial dot pipex dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36987
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared
--- Comment #59 from bonzini at gnu dot org 2008-07-31 12:44 --- Should be fixed by the patch at http://permalink.gmane.org/gmane.comp.gnu.libtool.patches/8574 which is waiting to be applied upstream. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug c/36987] Truncated C struct data initializer with variable size trailing array
--- Comment #1 from howard dot thomson at dial dot pipex dot com 2008-07-31 12:50 --- Created an attachment (id=15985) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15985action=view) test for unexpected C struct field alteration Due to the variable sized component of the struct initializer not being emitted, assignment to the single element of that initializer results in the following data structure being unexpectedly altered. gcc is 4.0.1 (Apple Computer, Inc. build 5449) on an X86_64 OpenSUSE 10.3 system. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36987
[Bug target/36613] [4.2/4.3/4.4 Regression] likely codegen bug
--- Comment #9 from bonzini at gnu dot org 2008-07-31 12:58 --- Michael, any news? -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36613
[Bug middle-end/36980] [4.4 Regression] Bootstrap broken with RTL checking on i586
--- Comment #4 from hjl dot tools at gmail dot com 2008-07-31 13:16 ---
bash-3.2$ cat /tmp/crtfastmath.i
int __get_cpuid (unsigned int __level,
unsigned int *__eax, unsigned int *__ebx,
unsigned int *__ecx, unsigned int *__edx);
void
__attribute__ ((force_align_arg_pointer))
set_fast_math (void)
{
unsigned int eax, ebx, ecx, edx;
if (!__get_cpuid (1, eax, ebx, ecx, edx))
return;
}
bash-3.2$ ../xgcc -B../ -m32 -mtune=i586 -g /tmp/crtfastmath.i -v -S
Reading specs from ../specs
Target: x86_64-unknown-linux-gnu
Configured with: /export/gnu/src/gcc-work/gcc/configure --enable-languages=c
--disable-bootstrap --enable-checking=all --prefix=/usr/gcc-4.4-work
--with-local-prefix=/usr/local
Thread model: posix
gcc version 4.4.0 20080731 (experimental) [trunk revision 138402] (GCC)
COLLECT_GCC_OPTIONS='-B../' '-m32' '-mtune=i586' '-g' '-v' '-S'
../cc1 -fpreprocessed /tmp/crtfastmath.i -quiet -dumpbase crtfastmath.i -m32
-mtune=i586 -auxbase crtfastmath -g -version -o crtfastmath.s
GNU C (GCC) version 4.4.0 20080731 (experimental) [trunk revision 138402]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.3.0 20080428 (Red Hat 4.3.0-8), GMP version
4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=0 --param ggc-min-heapsize=0
Compiler executable checksum: a7c5eaead017286ce06e49733c7672ac
/tmp/crtfastmath.i: In function set_fast_math:
/tmp/crtfastmath.i:12: internal compiler error: RTL check: expected code 'reg',
have 'mem' in rhs_regno, at rtl.h:1005
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
bash-3.2$
Need to configure gcc with RTL check, like --enable-checking=all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36980
[Bug c++/36394] DR178: new non_POD() is handled incorrectly
--- Comment #1 from jason at gcc dot gnu dot org 2008-07-31 13:16 --- *** This bug has been marked as a duplicate of 11309 *** -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36394
[Bug c++/11309] Testsuite failures in g++.dg/expr/anew1.C (and anew2.C anew3.C anew4.c)
--- Comment #11 from jason at gcc dot gnu dot org 2008-07-31 13:16 --- *** Bug 36394 has been marked as a duplicate of this bug. *** -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11309
[Bug target/35100] [4.2/4.3/4.4 regression] internal compiler error: in extract_insn, at recog.c:1990
--- Comment #10 from jakub at gcc dot gnu dot org 2008-07-31 13:49 --- This got actually fixed by Alan's PR target/36634 fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2008- | |07/msg02434.html| Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35100
[Bug debug/36980] [4.4 Regression] Bootstrap broken with RTL checking on i586
--- Comment #5 from hjl dot tools at gmail dot com 2008-07-31 13:50 --- The analysis and a patch are posted at http://gcc.gnu.org/ml/gcc-patches/2008-07/msg02441.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||07/msg02441.html Component|middle-end |debug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36980
[Bug tree-optimization/36978] [4.4 Regression] ICE in gimple_cond_set_lhs for -O2 -funswitch-loops after tuples merge
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-07-31 14:12 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36978
[Bug tree-optimization/36978] [4.4 Regression] ICE in gimple_cond_set_lhs for -O2 -funswitch-loops after tuples merge
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-07-31 14:13 --- Subject: Bug 36978 Author: rguenth Date: Thu Jul 31 14:12:24 2008 New Revision: 138415 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138415 Log: 2008-07-31 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36978 * tree-ssa-loop-unswitch.c (tree_may_unswitch_on): Do not fold the generated condition. * gcc.dg/torture/pr36978.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr36978.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-unswitch.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36978
[Bug debug/36976] FAIL: g++.dg/torture/stackalign/unwind-2.C
--- Comment #1 from hjl at gcc dot gnu dot org 2008-07-31 14:35 --- Subject: Bug 36976 Author: hjl Date: Thu Jul 31 14:33:43 2008 New Revision: 138416 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138416 Log: 2008-07-31 H.J. Lu [EMAIL PROTECTED] PR debug/36976 * dwarf2out.c (dwarf2out_args_size_adjust): New. (dwarf2out_stack_adjust): Use it. (dwarf2out_frame_debug_expr): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36976
[Bug tree-optimization/36631] [4.3/4.4 Regression] attribute always_inline - sorry, unimplemented: recursive inlining
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-07-31 14:44 --- Richard, there is one problem that is yours. We conclude that call is uninlinable due to type missmatch. This should not happen on C++. This gets misdiagnozed as originally recursive inlning was only reason why inlining of always_inline could've failed on one specific call but not other. Now we have mismatches and the function specific stuff. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36631
[Bug middle-end/36988] New: [4.4 Regression] ICE in gimple_rhs_has_side_effects, at gimple.c:2369
typedef unsigned short __u16;
typedef unsigned int __u32;
typedef __u8 uint8_t;
typedef __u16 uint16_t;
typedef __u32 uint32_t;
typedef struct {
uint8_t mbxCommand;
} MAILBOX_t;
typedef struct lpfcMboxq {
};
int lpfc_sli_brdrestart(struct lpfc_hba * phba)
{
MAILBOX_t *mb;
uint16_t skip_post;
volatile uint32_t word0;
void *to_slim;
mb = (MAILBOX_t *) word0;
mb-mbxCommand = 0x1A;
__writel((*(uint32_t *) mb),(to_slim));
if (skip_post)
(__builtin_constant_p(100) (100)=5)
? (__builtin_constant_p((100)*1000)
? (((100)*1000) 2
? __bad_udelay() : __const_udelay(((100)*1000) * 0x10c7ul))
: __udelay((100)*1000)) : ({ });
}
ICEs with -O because TREE_SIDE_EFFECTS is set on word0.
--
Summary: [4.4 Regression] ICE in gimple_rhs_has_side_effects, at
gimple.c:2369
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36988
[Bug middle-end/36988] [4.4 Regression] ICE in gimple_rhs_has_side_effects, at gimple.c:2369
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-07-31 14:51 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-31 14:51:43 date|| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36988
[Bug c/36989] New: Wrong type for (... ? ... : ...)
With the code below, gcc complains over line 8, but not lines 14 and 17
because it deduces the wrong type for the ?: operator. The type of that
operator's result is dependent on whether something is a null pointer
constant and not. gcc fails to track that properly: it knows that
(const void *)0 is a null pointer constant, but it also thinks that
(void *)(void *)0 and (1 ? (void *)0 : (void *)0) are.
The chapter and verse is C99 6.15.15 #6: if one operand is a null
pointer constant, the result has the type of the other operand;
Null pointer constants are defined in C99 6.3.2.3 #3 to be an integer
constant expression with value zero or such an expression case to
type void *.
For the record, Sun's cc gets the invalid cases right, but also
rejects the valid case.
int
main (int argc, char **argv)
{
int *p;
int n;
/* Invalid: dereferences a void * */
*(n ? p : (const void *)0);
/* Valid since it dereferences an int* */
*(n ? p : (void *)0);
/* Invalid: dereferences a void * */
*(n ? p : (void *)(void *)0);
/* Invalid: dereferences a void * */
*(n ? p : (1 ? (void *)0 : (void *)0));
return 0;
}
--
Summary: Wrong type for (... ? ... : ...)
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terra at gnome dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36989
