Re: cloog(-parma) 0.16 and ppl 0.11 in infrastructure?
On Fri, Dec 31, 2010 at 12:40 AM, Jack Howarth howa...@bromo.med.uc.edu wrote: Sebastian, It appears that the official tarballs are now posted at http://www.cloog.org/ for cloog and cloog-parma 0.16. Do you plan on placing those both in the infrastructure directory at gcc.gnu.org's ftp site? If so, the newer ppl 0.11 tarball should be added as well. If those files are updated, we should be set to switch gcc trunk to require ppl = 0.11, cloog = 0.16 and the default cloog backend from legacy cloog-ppl to cloog-isl. I don't think this is a very good idea at this point. Richard. Jack
Re: [wwwdocs] PATCH for Re: rsync'd repo size
On Fri, Dec 31, 2010 at 8:07 PM, Mike Stump mikest...@comcast.net wrote: On Dec 31, 2010, at 8:27 AM, Gerald Pfeifer wrote: On Wed, 8 Dec 2010, DJ Delorie wrote: http://gcc.gnu.org/rsync.html says 17 Gb. I just did it, and it's up to 22 Gb. Thanks for the heads up, DJ! I had a look, and it is, in fact, 184 Gb as of today, or 23 GB. (SCNR. :-) You can replace it with a equation that has a year in it, that way, you don't have to fix it as often... :-) Or just use a date instead of today. Or say more than 23 GB which also stays true ;) Richard.
development stage timeline
Is there an expected date for when stage 3 should end, or some other measure of pressure? The 4.6.0 status report link on gcc.gnu.org does not seem to tell (and I'm not sure whether it usually does or not). It would be good to get Libtool updated before, but I'm not sure I can finish it this weekend. Thanks (and sorry for not following irc, and happy gnu year!), Ralf
Re: Behavior change of driver on multiple input assembly files
On Fri, Dec 31, 2010 at 9:40 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, Dec 31, 2010 at 5:08 AM, Jie Zhang j...@codesourcery.com wrote:
On 12/31/2010 01:07 PM, Jie Zhang wrote:
I just found a behavior change of driver on multiple input assembly
files. Previously (before r164357), for the command line
gcc -o t t1.s t2.s
, the driver will call assembler twice, once for t1.s and once for t2.s.
After r164357, the driver will only call assembler once for t1.s and
t2.s. Then if t1.s and t2.s have same symbol, assembler will report an
error, like:
t2.s: Assembler messages:
t2.s:1: Error: symbol `.L1' is already defined
I read the discussion on the mailing list starting by the patch email of
r164357.[1] It seems that this behavior change is not the intention of
that patch. And I think the previous behavior is more useful than the
current behavior. So it's good to restore the previous behavior, isn't?
For a minimal fix, I propose to change combinable fields of assembly
languages in default_compilers[] to 0. See the attached patch
gcc-not-combine-assembly-inputs.diff. I don't know why the combinable
fields were set to 1 when --combine option was introduced. There is no
explanation about that in that patch email.[2] Does anyone still remember?
For an aggressive fix, how about removing the combinable field from
struct compiler? If we change combinable fields of assembly languages
in default_compilers[] to 0, only .go and @cpp-output set combinable
to 1. I don't see any reason for difference between @cpp-output and
.i. So if we can set combinable to 0 for .go, we have 0 for all
compilers in default_compilers[], thus we can remove that field. Is
there a reason to set 1 for .go?
I also attached the aggressive patch gcc-remove-combinable-field.diff.
Either patch is not tested. Which way should we go?
The minimal fix has no regressions. But the aggressive one has a lot of
regressions.
[1] http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01322.html
[2] http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01880.html
I opened:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47137
This simple patch also works for me.
--
H.J.
---
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 69bf033..0d633a4 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -6582,7 +6582,7 @@ warranty; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.\n\n
explicit_link_files = XCNEWVEC (char, n_infiles);
- combine_inputs = have_o || flag_wpa;
+ combine_inputs = flag_wpa;
That probably fails with -flto-partition=none (thus, old -flto mode).
Combining .s files might be necessary when continuing a -save-temps
LTO compile with the assembly output of the compiler (thus assembler
files with LTO object code).
Richard.
for (i = 0; (int) i n_infiles; i++)
{
Re: development stage timeline
On Sun, Jan 2, 2011 at 5:01 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Is there an expected date for when stage 3 should end, or some other measure of pressure? The 4.6.0 status report link on gcc.gnu.org does not seem to tell (and I'm not sure whether it usually does or not). It would be good to get Libtool updated before, but I'm not sure I can finish it this weekend. It's expected to end as soon as one of the RMs manages to do a status report. Which means very likely (early) this week. Richard. Thanks (and sorry for not following irc, and happy gnu year!), Ralf
Re: cloog(-parma) 0.16 and ppl 0.11 in infrastructure?
On Fri, Dec 31, 2010 at 12:40 AM, Jack Howarth howa...@bromo.med.uc.edu wrote: Sebastian, It appears that the official tarballs are now posted at http://www.cloog.org/ for cloog and cloog-parma 0.16. Do you plan on placing those both in the infrastructure directory at gcc.gnu.org's ftp site? If so, the newer ppl 0.11 tarball should be added as well. If those files are updated, we should be set to switch gcc trunk to require ppl = 0.11, cloog = 0.16 and the default cloog backend from legacy cloog-ppl to cloog-isl. I don't think this is a very good idea at this point. I think ppl is in a stae of change and between releases. I have not yet seen it compile cleanly once with any version of GCC on Solaris. It certainly never passes its own testsuites without a coredump or some significant failure. Roberto Bagnara is aware of this and I am going to work with him on this to get something valid in the POSIX/UNIX world and hopefully a new release of ppl will come out that is solid for integration into GCC. As for ClooG, I have no data at this time. This is merely an observation from someone that tries to be very very careful with testing and with testsuite results. -- Dennis Clarke dcla...@opensolaris.ca - Email related to the open source Solaris dcla...@blastwave.org - Email related to open source for Solaris ps: thus far GCC 4.5.2 is beautiful on Solaris however on Debian Squeeze it seems to be a nightmare. Testsuite has been running for three days on Intel i7 with many many failures. I'll report data when I have it.
Re: Behavior change of driver on multiple input assembly files
On Sun, Jan 2, 2011 at 8:03 AM, Richard Guenther richard.guent...@gmail.com wrote: On Fri, Dec 31, 2010 at 9:40 PM, H.J. Lu hjl.to...@gmail.com wrote: On Fri, Dec 31, 2010 at 5:08 AM, Jie Zhang j...@codesourcery.com wrote: On 12/31/2010 01:07 PM, Jie Zhang wrote: I just found a behavior change of driver on multiple input assembly files. Previously (before r164357), for the command line gcc -o t t1.s t2.s , the driver will call assembler twice, once for t1.s and once for t2.s. After r164357, the driver will only call assembler once for t1.s and t2.s. Then if t1.s and t2.s have same symbol, assembler will report an error, like: t2.s: Assembler messages: t2.s:1: Error: symbol `.L1' is already defined I read the discussion on the mailing list starting by the patch email of r164357.[1] It seems that this behavior change is not the intention of that patch. And I think the previous behavior is more useful than the current behavior. So it's good to restore the previous behavior, isn't? For a minimal fix, I propose to change combinable fields of assembly languages in default_compilers[] to 0. See the attached patch gcc-not-combine-assembly-inputs.diff. I don't know why the combinable fields were set to 1 when --combine option was introduced. There is no explanation about that in that patch email.[2] Does anyone still remember? For an aggressive fix, how about removing the combinable field from struct compiler? If we change combinable fields of assembly languages in default_compilers[] to 0, only .go and @cpp-output set combinable to 1. I don't see any reason for difference between @cpp-output and .i. So if we can set combinable to 0 for .go, we have 0 for all compilers in default_compilers[], thus we can remove that field. Is there a reason to set 1 for .go? I also attached the aggressive patch gcc-remove-combinable-field.diff. Either patch is not tested. Which way should we go? The minimal fix has no regressions. But the aggressive one has a lot of regressions. [1] http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01322.html [2] http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01880.html I opened: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47137 This simple patch also works for me. -- H.J. --- diff --git a/gcc/gcc.c b/gcc/gcc.c index 69bf033..0d633a4 100644 --- a/gcc/gcc.c +++ b/gcc/gcc.c @@ -6582,7 +6582,7 @@ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\n explicit_link_files = XCNEWVEC (char, n_infiles); - combine_inputs = have_o || flag_wpa; + combine_inputs = flag_wpa; That probably fails with -flto-partition=none (thus, old -flto mode). Combining .s files might be necessary when continuing a -save-temps LTO compile with the assembly output of the compiler (thus assembler files with LTO object code). Well, how does it work without -o foo, i.e., with the default output, a.out? -- H.J.
Re: Behavior change of driver on multiple input assembly files
On Sun, Jan 2, 2011 at 8:31 AM, H.J. Lu hjl.to...@gmail.com wrote: On Sun, Jan 2, 2011 at 8:03 AM, Richard Guenther richard.guent...@gmail.com wrote: On Fri, Dec 31, 2010 at 9:40 PM, H.J. Lu hjl.to...@gmail.com wrote: On Fri, Dec 31, 2010 at 5:08 AM, Jie Zhang j...@codesourcery.com wrote: On 12/31/2010 01:07 PM, Jie Zhang wrote: I just found a behavior change of driver on multiple input assembly files. Previously (before r164357), for the command line gcc -o t t1.s t2.s , the driver will call assembler twice, once for t1.s and once for t2.s. After r164357, the driver will only call assembler once for t1.s and t2.s. Then if t1.s and t2.s have same symbol, assembler will report an error, like: t2.s: Assembler messages: t2.s:1: Error: symbol `.L1' is already defined I read the discussion on the mailing list starting by the patch email of r164357.[1] It seems that this behavior change is not the intention of that patch. And I think the previous behavior is more useful than the current behavior. So it's good to restore the previous behavior, isn't? For a minimal fix, I propose to change combinable fields of assembly languages in default_compilers[] to 0. See the attached patch gcc-not-combine-assembly-inputs.diff. I don't know why the combinable fields were set to 1 when --combine option was introduced. There is no explanation about that in that patch email.[2] Does anyone still remember? For an aggressive fix, how about removing the combinable field from struct compiler? If we change combinable fields of assembly languages in default_compilers[] to 0, only .go and @cpp-output set combinable to 1. I don't see any reason for difference between @cpp-output and .i. So if we can set combinable to 0 for .go, we have 0 for all compilers in default_compilers[], thus we can remove that field. Is there a reason to set 1 for .go? I also attached the aggressive patch gcc-remove-combinable-field.diff. Either patch is not tested. Which way should we go? The minimal fix has no regressions. But the aggressive one has a lot of regressions. [1] http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01322.html [2] http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01880.html I opened: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47137 This simple patch also works for me. -- H.J. --- diff --git a/gcc/gcc.c b/gcc/gcc.c index 69bf033..0d633a4 100644 --- a/gcc/gcc.c +++ b/gcc/gcc.c @@ -6582,7 +6582,7 @@ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\n explicit_link_files = XCNEWVEC (char, n_infiles); - combine_inputs = have_o || flag_wpa; + combine_inputs = flag_wpa; That probably fails with -flto-partition=none (thus, old -flto mode). Combining .s files might be necessary when continuing a -save-temps LTO compile with the assembly output of the compiler (thus assembler files with LTO object code). Well, how does it work without -o foo, i.e., with the default output, a.out? If you can show me a real usage for -save-temps and LTO, I can find a way to make it work. -- H.J.
Re: Behavior change of driver on multiple input assembly files
On Sun, Jan 2, 2011 at 5:31 PM, H.J. Lu hjl.to...@gmail.com wrote: On Sun, Jan 2, 2011 at 8:03 AM, Richard Guenther richard.guent...@gmail.com wrote: On Fri, Dec 31, 2010 at 9:40 PM, H.J. Lu hjl.to...@gmail.com wrote: On Fri, Dec 31, 2010 at 5:08 AM, Jie Zhang j...@codesourcery.com wrote: On 12/31/2010 01:07 PM, Jie Zhang wrote: I just found a behavior change of driver on multiple input assembly files. Previously (before r164357), for the command line gcc -o t t1.s t2.s , the driver will call assembler twice, once for t1.s and once for t2.s. After r164357, the driver will only call assembler once for t1.s and t2.s. Then if t1.s and t2.s have same symbol, assembler will report an error, like: t2.s: Assembler messages: t2.s:1: Error: symbol `.L1' is already defined I read the discussion on the mailing list starting by the patch email of r164357.[1] It seems that this behavior change is not the intention of that patch. And I think the previous behavior is more useful than the current behavior. So it's good to restore the previous behavior, isn't? For a minimal fix, I propose to change combinable fields of assembly languages in default_compilers[] to 0. See the attached patch gcc-not-combine-assembly-inputs.diff. I don't know why the combinable fields were set to 1 when --combine option was introduced. There is no explanation about that in that patch email.[2] Does anyone still remember? For an aggressive fix, how about removing the combinable field from struct compiler? If we change combinable fields of assembly languages in default_compilers[] to 0, only .go and @cpp-output set combinable to 1. I don't see any reason for difference between @cpp-output and .i. So if we can set combinable to 0 for .go, we have 0 for all compilers in default_compilers[], thus we can remove that field. Is there a reason to set 1 for .go? I also attached the aggressive patch gcc-remove-combinable-field.diff. Either patch is not tested. Which way should we go? The minimal fix has no regressions. But the aggressive one has a lot of regressions. [1] http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01322.html [2] http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01880.html I opened: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47137 This simple patch also works for me. -- H.J. --- diff --git a/gcc/gcc.c b/gcc/gcc.c index 69bf033..0d633a4 100644 --- a/gcc/gcc.c +++ b/gcc/gcc.c @@ -6582,7 +6582,7 @@ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\n explicit_link_files = XCNEWVEC (char, n_infiles); - combine_inputs = have_o || flag_wpa; + combine_inputs = flag_wpa; That probably fails with -flto-partition=none (thus, old -flto mode). Combining .s files might be necessary when continuing a -save-temps LTO compile with the assembly output of the compiler (thus assembler files with LTO object code). Well, how does it work without -o foo, i.e., with the default output, a.out? I don't know. The driver is quite a mess. (but it does work, and I didn't try your patch, it just looks that the above is incomplete - maybe have_o is set to a.out?) Richard. -- H.J.
Re: Behavior change of driver on multiple input assembly files
On Sun, Jan 2, 2011 at 8:37 AM, Richard Guenther richard.guent...@gmail.com wrote: On Sun, Jan 2, 2011 at 5:31 PM, H.J. Lu hjl.to...@gmail.com wrote: On Sun, Jan 2, 2011 at 8:03 AM, Richard Guenther richard.guent...@gmail.com wrote: On Fri, Dec 31, 2010 at 9:40 PM, H.J. Lu hjl.to...@gmail.com wrote: On Fri, Dec 31, 2010 at 5:08 AM, Jie Zhang j...@codesourcery.com wrote: On 12/31/2010 01:07 PM, Jie Zhang wrote: I just found a behavior change of driver on multiple input assembly files. Previously (before r164357), for the command line gcc -o t t1.s t2.s , the driver will call assembler twice, once for t1.s and once for t2.s. After r164357, the driver will only call assembler once for t1.s and t2.s. Then if t1.s and t2.s have same symbol, assembler will report an error, like: t2.s: Assembler messages: t2.s:1: Error: symbol `.L1' is already defined I read the discussion on the mailing list starting by the patch email of r164357.[1] It seems that this behavior change is not the intention of that patch. And I think the previous behavior is more useful than the current behavior. So it's good to restore the previous behavior, isn't? For a minimal fix, I propose to change combinable fields of assembly languages in default_compilers[] to 0. See the attached patch gcc-not-combine-assembly-inputs.diff. I don't know why the combinable fields were set to 1 when --combine option was introduced. There is no explanation about that in that patch email.[2] Does anyone still remember? For an aggressive fix, how about removing the combinable field from struct compiler? If we change combinable fields of assembly languages in default_compilers[] to 0, only .go and @cpp-output set combinable to 1. I don't see any reason for difference between @cpp-output and .i. So if we can set combinable to 0 for .go, we have 0 for all compilers in default_compilers[], thus we can remove that field. Is there a reason to set 1 for .go? I also attached the aggressive patch gcc-remove-combinable-field.diff. Either patch is not tested. Which way should we go? The minimal fix has no regressions. But the aggressive one has a lot of regressions. [1] http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01322.html [2] http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01880.html I opened: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47137 This simple patch also works for me. -- H.J. --- diff --git a/gcc/gcc.c b/gcc/gcc.c index 69bf033..0d633a4 100644 --- a/gcc/gcc.c +++ b/gcc/gcc.c @@ -6582,7 +6582,7 @@ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\n explicit_link_files = XCNEWVEC (char, n_infiles); - combine_inputs = have_o || flag_wpa; + combine_inputs = flag_wpa; That probably fails with -flto-partition=none (thus, old -flto mode). Combining .s files might be necessary when continuing a -save-temps LTO compile with the assembly output of the compiler (thus assembler files with LTO object code). Well, how does it work without -o foo, i.e., with the default output, a.out? I don't know. The driver is quite a mess. (but it does work, and I didn't try your patch, it just looks that the above is incomplete - maybe have_o is set to a.out?) No, it doesn't. See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47137 That is how I found the problem. -- H.J.
Re: Behavior change of driver on multiple input assembly files
On Sun, Jan 2, 2011 at 5:41 PM, H.J. Lu hjl.to...@gmail.com wrote: On Sun, Jan 2, 2011 at 8:37 AM, Richard Guenther richard.guent...@gmail.com wrote: On Sun, Jan 2, 2011 at 5:31 PM, H.J. Lu hjl.to...@gmail.com wrote: On Sun, Jan 2, 2011 at 8:03 AM, Richard Guenther richard.guent...@gmail.com wrote: On Fri, Dec 31, 2010 at 9:40 PM, H.J. Lu hjl.to...@gmail.com wrote: On Fri, Dec 31, 2010 at 5:08 AM, Jie Zhang j...@codesourcery.com wrote: On 12/31/2010 01:07 PM, Jie Zhang wrote: I just found a behavior change of driver on multiple input assembly files. Previously (before r164357), for the command line gcc -o t t1.s t2.s , the driver will call assembler twice, once for t1.s and once for t2.s. After r164357, the driver will only call assembler once for t1.s and t2.s. Then if t1.s and t2.s have same symbol, assembler will report an error, like: t2.s: Assembler messages: t2.s:1: Error: symbol `.L1' is already defined I read the discussion on the mailing list starting by the patch email of r164357.[1] It seems that this behavior change is not the intention of that patch. And I think the previous behavior is more useful than the current behavior. So it's good to restore the previous behavior, isn't? For a minimal fix, I propose to change combinable fields of assembly languages in default_compilers[] to 0. See the attached patch gcc-not-combine-assembly-inputs.diff. I don't know why the combinable fields were set to 1 when --combine option was introduced. There is no explanation about that in that patch email.[2] Does anyone still remember? For an aggressive fix, how about removing the combinable field from struct compiler? If we change combinable fields of assembly languages in default_compilers[] to 0, only .go and @cpp-output set combinable to 1. I don't see any reason for difference between @cpp-output and .i. So if we can set combinable to 0 for .go, we have 0 for all compilers in default_compilers[], thus we can remove that field. Is there a reason to set 1 for .go? I also attached the aggressive patch gcc-remove-combinable-field.diff. Either patch is not tested. Which way should we go? The minimal fix has no regressions. But the aggressive one has a lot of regressions. [1] http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01322.html [2] http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01880.html I opened: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47137 This simple patch also works for me. -- H.J. --- diff --git a/gcc/gcc.c b/gcc/gcc.c index 69bf033..0d633a4 100644 --- a/gcc/gcc.c +++ b/gcc/gcc.c @@ -6582,7 +6582,7 @@ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n\n explicit_link_files = XCNEWVEC (char, n_infiles); - combine_inputs = have_o || flag_wpa; + combine_inputs = flag_wpa; That probably fails with -flto-partition=none (thus, old -flto mode). Combining .s files might be necessary when continuing a -save-temps LTO compile with the assembly output of the compiler (thus assembler files with LTO object code). Well, how does it work without -o foo, i.e., with the default output, a.out? I don't know. The driver is quite a mess. (but it does work, and I didn't try your patch, it just looks that the above is incomplete - maybe have_o is set to a.out?) No, it doesn't. See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47137 That is how I found the problem. Hm, well. I left the combine_inputs thing in as LTO re-uses it. Your small patch removing have_o || is ok I guess. Thanks, Richard. -- H.J.
gcc-4.3-20110102 is now available
Snapshot gcc-4.3-20110102 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20110102/ 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 168407 You'll find: gcc-4.3-20110102.tar.bz2 Complete GCC (includes all of below) MD5=03f96256c175836d6e4420a9e03e707f SHA1=567fc8cb89f04c0770838f999a01e3ff5f92544b gcc-core-4.3-20110102.tar.bz2C front end and core compiler MD5=50fcd9d6c6efb5add23d5b2f378150a8 SHA1=a85a2ff41697929bd1cc0ec0db06a1c25152594f gcc-ada-4.3-20110102.tar.bz2 Ada front end and runtime MD5=9cf1967bb4c2bdd26799535ee2971e2b SHA1=f9cb3fb5aa86fa182da12ddc21e1b3003f381b0f gcc-fortran-4.3-20110102.tar.bz2 Fortran front end and runtime MD5=df38e5930b0ebdcdbc62bba5a01c6627 SHA1=36b7d83b2521d392e7186f9c7a4219b6a8e36147 gcc-g++-4.3-20110102.tar.bz2 C++ front end and runtime MD5=d3c7d47f229465cfcf6b6a5ed46e4f66 SHA1=23bcd028d357d2543cc1c4677d90b85f441bd84a gcc-go-4.3-20110102.tar.bz2 Go front end and runtime MD5=86e7cfa204401a42ba7404904bb323eb SHA1=029552da024d30b89b279ae78e1c75fc4e70a683 gcc-java-4.3-20110102.tar.bz2Java front end and runtime MD5=6f6f165153d9785a77907e7d9db0e08e SHA1=967e9f4edea3fcb9822067de9f05f2238e662320 gcc-objc-4.3-20110102.tar.bz2Objective-C front end and runtime MD5=2f181b35a422545fe5a4fd470b25b7e0 SHA1=45d4bee14b268a0f5417cb3bbcb71df3f52e168c gcc-testsuite-4.3-20110102.tar.bz2 The GCC testsuite MD5=8f74fc58a618da7c8e2927944e42b4d0 SHA1=b39c409a552cc88856b065daf619f6ad3c12f043 Diffs from 4.3-20101226 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.
Re: kfreebsd-gnu etc. issues
Hi Joseph, 2011/1/1 Joseph S. Myers jos...@codesourcery.com: I'm trying to stop non-Linux GCC targets from using config/linux.h and other headers whose names indicate they relate to the Linux kernel, separating GNU-userspace and Linux-kernel configuration more cleanly. http://gcc.gnu.org/ml/gcc-patches/2010-12/msg02055.html is the initial patch in this series, and in the course of working on the corresponding changes for i386/linux.h and i386/linux64.h Thank you for doing this. As the person who introduced this kind of use, I intended to propose something along these lines myself, but never got the time to do it. I found several possible problems with the configurations for *-kfreebsd-gnu, *-knetbsd-gnu and *-kopensolaris-gnu. [...] I can't review these problems right now, but I'll have a bit more time in 1 or 2 weeks. I'll get back to you. -- Robert Millan
Re: Behavior change of driver on multiple input assembly files
Richard Guenther richard.guent...@gmail.com writes: Your small patch removing have_o || is ok I guess. Wait. That will change the behaviour of gcc -o foo.o -c f1.c f2.c f3.c Is that what we want? Also, right now the gccgo driver depends on the -o behaviour to combine inputs. If that changes, the driver will need to provide some other way to let the frontend force inputs to be combined. Ian
Re: cloog(-parma) 0.16 and ppl 0.11 in infrastructure?
On Sun, Jan 02, 2011 at 04:55:09PM +0100, Richard Guenther wrote: On Fri, Dec 31, 2010 at 12:40 AM, Jack Howarth howa...@bromo.med.uc.edu wrote: Sebastian, It appears that the official tarballs are now posted at http://www.cloog.org/ for cloog and cloog-parma 0.16. Do you plan on placing those both in the infrastructure directory at gcc.gnu.org's ftp site? If so, the newer ppl 0.11 tarball should be added as well. If those files are updated, we should be set to switch gcc trunk to require ppl = 0.11, cloog = 0.16 and the default cloog backend from legacy cloog-ppl to cloog-isl. I don't think this is a very good idea at this point. Richard, My understanding is the Sebastian intended to at least switch graphite from legacy cloog-ppl to cloog.org (cloog-isl) for gcc 4.6. This has the advantage of decoupling cloog from ppl and thus elimimating the problem of the ppl 0.11 ABI change. I've confirmed on darwin that if gcc's graphite is built under the older 0.10.4 ABI and cloog is built against the newer ppl 0.11 ABI that there is graphite testsuite breakage. Using cloog.org eliminates this issue entirely since the cloog-isl is in use (eliminating the need to synchronize which ppl is in use for graphite and cloog). Jack Richard. Jack
Re: Behavior change of driver on multiple input assembly files
On Sun, Jan 2, 2011 at 9:24 PM, Ian Lance Taylor i...@google.com wrote: Richard Guenther richard.guent...@gmail.com writes: Your small patch removing have_o || is ok I guess. Wait. That will change the behaviour of gcc -o foo.o -c f1.c f2.c f3.c Is that what we want? Does it? I don't think so. Most of the combine handling was removed by the patch that caused the regression, so -o and -c doesn't combine anymore (with multiple sources). Also, right now the gccgo driver depends on the -o behaviour to combine inputs. If that changes, the driver will need to provide some other way to let the frontend force inputs to be combined. For go it isn't equivalent to do gcgo -c t1.go; gcgo -c t2.go; gcgo t1.o t2.o compared to gcgo t1.go t2.go? Richard. Ian
Re: Behavior change of driver on multiple input assembly files
On Sun, Jan 2, 2011 at 12:24 PM, Ian Lance Taylor i...@google.com wrote: Richard Guenther richard.guent...@gmail.com writes: Your small patch removing have_o || is ok I guess. Wait. That will change the behaviour of gcc -o foo.o -c f1.c f2.c f3.c Is that what we want? No. We always do [i...@gnu-1 gcc]$ gcc -o foo.o -c t1.c t2.c gcc: cannot specify -o with -c, -S or -E with multiple files [i...@gnu-1 gcc]$ ./xgcc -B./ -o foo.o -c t1.c t2.c xgcc: fatal error: cannot specify -o with -c, -S or -E with multiple files compilation terminated. [i...@gnu-1 gcc]$ -- H.J.
Re: Behavior change of driver on multiple input assembly files
Richard Guenther richard.guent...@gmail.com writes: On Sun, Jan 2, 2011 at 9:24 PM, Ian Lance Taylor i...@google.com wrote: Richard Guenther richard.guent...@gmail.com writes: Your small patch removing have_o || is ok I guess. Wait. That will change the behaviour of gcc -o foo.o -c f1.c f2.c f3.c Is that what we want? Does it? I don't think so. Most of the combine handling was removed by the patch that caused the regression, so -o and -c doesn't combine anymore (with multiple sources). Sorry, you're right. The difference is that @c has 0 for the combinable field, and @assembler has 1. Before H.J.'s change, this worked gcc -c -o f.o f1.s f2.s After his change, it does not. That is probably not a big deal. I wonder why @assembler has 1 for combinable? It seems to have been set to 1 when the combinable field was added in 2004-04-05 with -combine. Now that -combine has been removed, if the combinable field for @assembler were 0, it seems to me that H.J.'s problem would also be fixed. And it seems to me that it should be 0. Also, right now the gccgo driver depends on the -o behaviour to combine inputs. If that changes, the driver will need to provide some other way to let the frontend force inputs to be combined. For go it isn't equivalent to do gcgo -c t1.go; gcgo -c t2.go; gcgo t1.o t2.o compared to gcgo t1.go t2.go? No, it is not. All .go input files must be passed to go1 at once. H.J.'s patch has indeed broken gccgo. Ian
Re: Behavior change of driver on multiple input assembly files
On Sun, 02 Jan 2011 13:18:22 -0800
Ian Lance Taylor i...@google.com wrote:
No, it is not. All .go input files must be passed to go1 at once.
H.J.'s patch has indeed broken gccgo.
I can confirm that. I just tried to svn merge trunk 168407 into the GCC MELT
branch (which, appart from the MELT stuff, is exactly the trunk), and I've got
libtool: compile: /usr/src/Lang/_Obj_Gcc_Melt/./gcc/gccgo
-B/usr/src/Lang/_Obj_Gcc_Melt/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include -minline-all-stringops -O2 -g
-I . -c -fgo-prefix=libgo_runtime
/usr/src/Lang/basile-melt-gcc/libgo/go/runtime/debug.go
/usr/src/Lang/basile-melt-gcc/libgo/go/runtime/error.go
/usr/src/Lang/basile-melt-gcc/libgo/go/runtime/extern.go
/usr/src/Lang/basile-melt-gcc/libgo/go/runtime/sig.go
/usr/src/Lang/basile-melt-gcc/libgo/go/runtime/softfloat64.go
/usr/src/Lang/basile-melt-gcc/libgo/go/runtime/type.go version.go -fPIC -o
runtime/.libs/libruntime.a.o
gccgo: fatal error: cannot specify -o with -c, -S or -E with multiple files
compilation terminated.
make[4]: *** [runtime/libruntime.a] Error 1
make[4]: Leaving directory
`/usr/src/Lang/_Obj_Gcc_Melt/x86_64-unknown-linux-gnu/libgo'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/usr/src/Lang/_Obj_Gcc_Melt/x86_64-unknown-linux-gnu/libgo'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/usr/src/Lang/_Obj_Gcc_Melt/x86_64-unknown-linux-gnu/libgo'
make[1]: *** [all-target-libgo] Error 2
make[1]: Leaving directory `/usr/src/Lang/_Obj_Gcc_Melt'
make: *** [all] Error 2
BTW, I will try the same merge -from trunk to MELT- tomorrow.
Cheers, and happy new year to every one!
--
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 mine, sont seulement les miennes} ***
Re: Behavior change of driver on multiple input assembly files
On Sun, Jan 2, 2011 at 1:18 PM, Ian Lance Taylor i...@google.com wrote:
Richard Guenther richard.guent...@gmail.com writes:
On Sun, Jan 2, 2011 at 9:24 PM, Ian Lance Taylor i...@google.com wrote:
Richard Guenther richard.guent...@gmail.com writes:
Your small patch removing have_o || is ok I guess.
Wait. That will change the behaviour of
gcc -o foo.o -c f1.c f2.c f3.c
Is that what we want?
Does it? I don't think so. Most of the combine handling was removed by
the patch that caused the regression, so -o and -c doesn't combine anymore
(with multiple sources).
Sorry, you're right. The difference is that @c has 0 for the combinable
field, and @assembler has 1. Before H.J.'s change, this worked
gcc -c -o f.o f1.s f2.s
After his change, it does not. That is probably not a big deal.
I wonder why @assembler has 1 for combinable? It seems to have been set
to 1 when the combinable field was added in 2004-04-05 with -combine.
Now that -combine has been removed, if the combinable field for
@assembler were 0, it seems to me that H.J.'s problem would also be
fixed. And it seems to me that it should be 0.
Also, right now the gccgo driver depends on the -o behaviour to combine
inputs. If that changes, the driver will need to provide some other way
to let the frontend force inputs to be combined.
For go it isn't equivalent to do gcgo -c t1.go; gcgo -c t2.go; gcgo t1.o t2.o
compared to gcgo t1.go t2.go?
No, it is not. All .go input files must be passed to go1 at once.
H.J.'s patch has indeed broken gccgo.
Can you try this patch?
Thanks.
--
H.J.
---
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 0d633a4..d0b2c96 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -6582,7 +6582,20 @@ warranty; not even for MERCHANTABILITY or FITNESS FOR A P
ARTICULAR PURPOSE.\n\n
explicit_link_files = XCNEWVEC (char, n_infiles);
+ /* Check if we should combine inputs. */
combine_inputs = flag_wpa;
+ if (!combine_inputs)
+for (i = 1; i decoded_options_count; i++)
+ {
+ if (decoded_options[i].opt_index == OPT_x)
+ {
+ struct compiler *compiler
+ = lookup_compiler (NULL, 0, decoded_options[i].arg);
+ if (compiler)
+ combine_inputs = compiler-combinable;
+ break;
+ }
+ }
for (i = 0; (int) i n_infiles; i++)
{
Re: Behavior change of driver on multiple input assembly files
On Sun, Jan 2, 2011 at 10:18 PM, Ian Lance Taylor i...@google.com wrote: Richard Guenther richard.guent...@gmail.com writes: On Sun, Jan 2, 2011 at 9:24 PM, Ian Lance Taylor i...@google.com wrote: Richard Guenther richard.guent...@gmail.com writes: Your small patch removing have_o || is ok I guess. Wait. That will change the behaviour of gcc -o foo.o -c f1.c f2.c f3.c Is that what we want? Does it? I don't think so. Most of the combine handling was removed by the patch that caused the regression, so -o and -c doesn't combine anymore (with multiple sources). Sorry, you're right. The difference is that @c has 0 for the combinable field, and @assembler has 1. Before H.J.'s change, this worked gcc -c -o f.o f1.s f2.s After his change, it does not. That is probably not a big deal. I wonder why @assembler has 1 for combinable? It seems to have been set to 1 when the combinable field was added in 2004-04-05 with -combine. Now that -combine has been removed, if the combinable field for @assembler were 0, it seems to me that H.J.'s problem would also be fixed. And it seems to me that it should be 0. That was another proposed patch. I wondered if that would break gcc -o t -flto -flto-partition=none t1.c t2.c -save-temps -v (repeating the generation of t1.s, we overwrite this with lto1 output ...) gcc -o t -flto -flto-partition=none t1.s t2.s where t1.s and t2.s contain LTO bytecode from the -save-temps invocation (thus the driver is expected to assemble both files and then combine the resulting objects). flag_wpa is not set at any time for -flto-partition=none (only flag_lto is, but that is set a well at compile-time). trying the above it doesn't seem to work, we exit with xgcc: fatal error: cannot specify -o with -c, -S or -E with multiple files because flag_wpa isn't set now either. xgcc invoked with -xlto -c -B . -flto-partition=none -v -save-temps -mtune=generic -march=pentiumpro -dumpdir ./ -dumpbase t -o /tmp/ccZPZLA0.lto.o t1.o t2.o So that's sth to fix as well (HJs change is the cause for the appearant problem but before his patch we tried to combine the .s files resulting in assembler errors). So maybe the patch removing combinable .s is the better fix after all. Also, right now the gccgo driver depends on the -o behaviour to combine inputs. If that changes, the driver will need to provide some other way to let the frontend force inputs to be combined. For go it isn't equivalent to do gcgo -c t1.go; gcgo -c t2.go; gcgo t1.o t2.o compared to gcgo t1.go t2.go? No, it is not. All .go input files must be passed to go1 at once. H.J.'s patch has indeed broken gccgo. Interesting. Do we have a testcase that is now broken? It seems to me that gcgo should force combining sources, even if no output file is given (and a.out is the default output). Thanks, Richard.
Re: Behavior change of driver on multiple input assembly files
On Sun, Jan 2, 2011 at 2:40 PM, Richard Guenther richard.guent...@gmail.com wrote: Interesting. Do we have a testcase that is now broken? It seems to me See: http://gcc.gnu.org/ml/gcc-regression/2011-01/msg00011.html -- H.J.
Re: Behavior change of driver on multiple input assembly files
On Sun, Jan 2, 2011 at 2:05 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sun, Jan 2, 2011 at 1:18 PM, Ian Lance Taylor i...@google.com wrote:
Richard Guenther richard.guent...@gmail.com writes:
On Sun, Jan 2, 2011 at 9:24 PM, Ian Lance Taylor i...@google.com wrote:
Richard Guenther richard.guent...@gmail.com writes:
Your small patch removing have_o || is ok I guess.
Wait. That will change the behaviour of
gcc -o foo.o -c f1.c f2.c f3.c
Is that what we want?
Does it? I don't think so. Most of the combine handling was removed by
the patch that caused the regression, so -o and -c doesn't combine anymore
(with multiple sources).
Sorry, you're right. The difference is that @c has 0 for the combinable
field, and @assembler has 1. Before H.J.'s change, this worked
gcc -c -o f.o f1.s f2.s
After his change, it does not. That is probably not a big deal.
I wonder why @assembler has 1 for combinable? It seems to have been set
to 1 when the combinable field was added in 2004-04-05 with -combine.
Now that -combine has been removed, if the combinable field for
@assembler were 0, it seems to me that H.J.'s problem would also be
fixed. And it seems to me that it should be 0.
Also, right now the gccgo driver depends on the -o behaviour to combine
inputs. If that changes, the driver will need to provide some other way
to let the frontend force inputs to be combined.
For go it isn't equivalent to do gcgo -c t1.go; gcgo -c t2.go; gcgo t1.o
t2.o
compared to gcgo t1.go t2.go?
No, it is not. All .go input files must be passed to go1 at once.
H.J.'s patch has indeed broken gccgo.
Can you try this patch?
Thanks.
--
H.J.
---
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 0d633a4..d0b2c96 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -6582,7 +6582,20 @@ warranty; not even for MERCHANTABILITY or FITNESS FOR
A P
ARTICULAR PURPOSE.\n\n
explicit_link_files = XCNEWVEC (char, n_infiles);
+ /* Check if we should combine inputs. */
combine_inputs = flag_wpa;
+ if (!combine_inputs)
+ for (i = 1; i decoded_options_count; i++)
+ {
+ if (decoded_options[i].opt_index == OPT_x)
+ {
+ struct compiler *compiler
+ = lookup_compiler (NULL, 0, decoded_options[i].arg);
+ if (compiler)
+ combine_inputs = compiler-combinable;
+ break;
+ }
+ }
for (i = 0; (int) i n_infiles; i++)
{
This doesn't work for go since -xgo isn't used with gccgo. Is there
a way to tell what the default language is for a gcc driver?
--
H.J.
Re: Behavior change of driver on multiple input assembly files
On Sun, Jan 2, 2011 at 3:03 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sun, Jan 2, 2011 at 2:05 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sun, Jan 2, 2011 at 1:18 PM, Ian Lance Taylor i...@google.com wrote:
Richard Guenther richard.guent...@gmail.com writes:
On Sun, Jan 2, 2011 at 9:24 PM, Ian Lance Taylor i...@google.com wrote:
Richard Guenther richard.guent...@gmail.com writes:
Your small patch removing have_o || is ok I guess.
Wait. That will change the behaviour of
gcc -o foo.o -c f1.c f2.c f3.c
Is that what we want?
Does it? I don't think so. Most of the combine handling was removed by
the patch that caused the regression, so -o and -c doesn't combine anymore
(with multiple sources).
Sorry, you're right. The difference is that @c has 0 for the combinable
field, and @assembler has 1. Before H.J.'s change, this worked
gcc -c -o f.o f1.s f2.s
After his change, it does not. That is probably not a big deal.
I wonder why @assembler has 1 for combinable? It seems to have been set
to 1 when the combinable field was added in 2004-04-05 with -combine.
Now that -combine has been removed, if the combinable field for
@assembler were 0, it seems to me that H.J.'s problem would also be
fixed. And it seems to me that it should be 0.
Also, right now the gccgo driver depends on the -o behaviour to combine
inputs. If that changes, the driver will need to provide some other way
to let the frontend force inputs to be combined.
For go it isn't equivalent to do gcgo -c t1.go; gcgo -c t2.go; gcgo t1.o
t2.o
compared to gcgo t1.go t2.go?
No, it is not. All .go input files must be passed to go1 at once.
H.J.'s patch has indeed broken gccgo.
Can you try this patch?
Thanks.
--
H.J.
---
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 0d633a4..d0b2c96 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -6582,7 +6582,20 @@ warranty; not even for MERCHANTABILITY or FITNESS FOR
A P
ARTICULAR PURPOSE.\n\n
explicit_link_files = XCNEWVEC (char, n_infiles);
+ /* Check if we should combine inputs. */
combine_inputs = flag_wpa;
+ if (!combine_inputs)
+ for (i = 1; i decoded_options_count; i++)
+ {
+ if (decoded_options[i].opt_index == OPT_x)
+ {
+ struct compiler *compiler
+ = lookup_compiler (NULL, 0, decoded_options[i].arg);
+ if (compiler)
+ combine_inputs = compiler-combinable;
+ break;
+ }
+ }
for (i = 0; (int) i n_infiles; i++)
{
This doesn't work for go since -xgo isn't used with gccgo. Is there
a way to tell what the default language is for a gcc driver?
I am testing this patch with Go and LTO.
--
H.J.
---
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 0d633a4..6e26b1d 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -2817,6 +2817,10 @@ static int n_infiles_alloc;
static bool combine_inputs;
+/* Default language. */
+
+static struct cl_decoded_option *default_language;
+
/* This counts the number of libraries added by lang_specific_driver, so that
we can tell if there were any user supplied any files or libraries. */
@@ -3714,6 +3718,9 @@ process_command (unsigned int decoded_options_count,
for (j = 1; j decoded_options_count; j++)
{
+ if (decoded_options[j].opt_index == OPT_x)
+ default_language = decoded_options[j];
+
if (decoded_options[j].opt_index == OPT_SPECIAL_input_file)
{
const char *arg = decoded_options[j].arg;
@@ -6582,7 +6589,15 @@ warranty; not even for MERCHANTABILITY or FITNESS FOR A P
ARTICULAR PURPOSE.\n\n
explicit_link_files = XCNEWVEC (char, n_infiles);
+ /* Check if we should combine inputs. */
combine_inputs = flag_wpa;
+ if (!combine_inputs default_language)
+{
+ struct compiler *compiler
+ = lookup_compiler (NULL, 0, default_language-arg);
+ if (compiler)
+ combine_inputs = compiler-combinable;
+}
for (i = 0; (int) i n_infiles; i++)
{
diff --git a/gcc/go/gospec.c b/gcc/go/gospec.c
index 7d21ace..926dec1 100644
--- a/gcc/go/gospec.c
+++ b/gcc/go/gospec.c
@@ -214,7 +214,7 @@ lang_specific_driver (struct cl_decoded_option **in_decoded_
options,
#endif
/* Make sure to have room for the trailing NULL argument. */
- num_args = argc + need_math + shared_libgcc + (library 0) * 5 + 5;
+ num_args = argc + need_math + shared_libgcc + (library 0) * 5 + 6;
new_decoded_options = XNEWVEC (struct cl_decoded_option, num_args);
i = 0;
@@ -223,6 +223,10 @@ lang_specific_driver (struct cl_decoded_option **in_decoded
_options,
/* Copy the 0th argument, i.e., the name of the program itself. */
new_decoded_options[j++] = decoded_options[i++];
+ /* Add -xgo. */
+ generate_option (OPT_x, go, 1, CL_DRIVER, new_decoded_options[j]);
+ j++;
+
/* If we are linking, pass -fsplit-stack if it is supported. */
#ifdef TARGET_CAN_SPLIT_STACK
if (library = 0)
Re: Behavior change of driver on multiple input assembly files
On Sun, Jan 2, 2011 at 3:03 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sun, Jan 2, 2011 at 2:05 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sun, Jan 2, 2011 at 1:18 PM, Ian Lance Taylor i...@google.com wrote:
Richard Guenther richard.guent...@gmail.com writes:
On Sun, Jan 2, 2011 at 9:24 PM, Ian Lance Taylor i...@google.com wrote:
Richard Guenther richard.guent...@gmail.com writes:
Your small patch removing have_o || is ok I guess.
Wait. That will change the behaviour of
gcc -o foo.o -c f1.c f2.c f3.c
Is that what we want?
Does it? I don't think so. Most of the combine handling was removed by
the patch that caused the regression, so -o and -c doesn't combine anymore
(with multiple sources).
Sorry, you're right. The difference is that @c has 0 for the combinable
field, and @assembler has 1. Before H.J.'s change, this worked
gcc -c -o f.o f1.s f2.s
After his change, it does not. That is probably not a big deal.
I wonder why @assembler has 1 for combinable? It seems to have been set
to 1 when the combinable field was added in 2004-04-05 with -combine.
Now that -combine has been removed, if the combinable field for
@assembler were 0, it seems to me that H.J.'s problem would also be
fixed. And it seems to me that it should be 0.
Also, right now the gccgo driver depends on the -o behaviour to combine
inputs. If that changes, the driver will need to provide some other way
to let the frontend force inputs to be combined.
For go it isn't equivalent to do gcgo -c t1.go; gcgo -c t2.go; gcgo t1.o
t2.o
compared to gcgo t1.go t2.go?
No, it is not. All .go input files must be passed to go1 at once.
H.J.'s patch has indeed broken gccgo.
Can you try this patch?
Thanks.
--
H.J.
---
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 0d633a4..d0b2c96 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -6582,7 +6582,20 @@ warranty; not even for MERCHANTABILITY or FITNESS FOR
A P
ARTICULAR PURPOSE.\n\n
explicit_link_files = XCNEWVEC (char, n_infiles);
+ /* Check if we should combine inputs. */
combine_inputs = flag_wpa;
+ if (!combine_inputs)
+ for (i = 1; i decoded_options_count; i++)
+ {
+ if (decoded_options[i].opt_index == OPT_x)
+ {
+ struct compiler *compiler
+ = lookup_compiler (NULL, 0, decoded_options[i].arg);
+ if (compiler)
+ combine_inputs = compiler-combinable;
+ break;
+ }
+ }
for (i = 0; (int) i n_infiles; i++)
{
This doesn't work for go since -xgo isn't used with gccgo. Is there
a way to tell what the default language is for a gcc driver?
I am testing this patch with all languages on Linux/x86-64.
--
H.J.
---
gcc/
2011-01-02 H.J. Lu hongjiu...@intel.com
PR driver/47137
* gcc.c (default_language): New.
(main): Lookup compiler to check if we should combine inputs.
* gcc.h (default_language): New.
gcc/go/
2011-01-02 H.J. Lu hongjiu...@intel.com
PR driver/47137
* gospec.c (lang_specific_driver): Set default_language if
needed.
gcc/
2011-01-02 H.J. Lu hongjiu...@intel.com
PR driver/47137
* gcc.c (default_language): New.
(main): Lookup compiler to check if we should combine inputs.
* gcc.h (default_language): New.
gcc/go/
2011-01-02 H.J. Lu hongjiu...@intel.com
PR driver/47137
* gospec.c (lang_specific_driver): Set default_language if
needed.
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 0d633a4..dc09937 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -2810,6 +2810,10 @@ static struct infile *infiles;
int n_infiles;
+/* Default language. */
+
+const char *default_language;
+
static int n_infiles_alloc;
/* True if multiple input files are being compiled to a single
@@ -6582,7 +6586,23 @@ warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.\n\n
explicit_link_files = XCNEWVEC (char, n_infiles);
+ /* Check if we should combine inputs. */
combine_inputs = flag_wpa;
+ if (!combine_inputs)
+{
+ struct compiler *compiler = NULL;
+ for (i = 1; i decoded_options_count; i++)
+ if (decoded_options[i].opt_index == OPT_x)
+ {
+ compiler = lookup_compiler (NULL, 0,
+ decoded_options[i].arg);
+ break;
+ }
+ if (!compiler default_language)
+ compiler = lookup_compiler (NULL, 0, default_language);
+ if (compiler)
+ combine_inputs = compiler-combinable;
+}
for (i = 0; (int) i n_infiles; i++)
{
diff --git a/gcc/gcc.h b/gcc/gcc.h
index 091d9c8..7bad86b 100644
--- a/gcc/gcc.h
+++ b/gcc/gcc.h
@@ -49,6 +49,8 @@ extern int lang_specific_pre_link (void);
extern int n_infiles;
+extern const char *default_language;
+
/* Number of extra output files that lang_specific_pre_link may generate. */
extern int lang_specific_extra_outfiles;
diff --git
Really poor 4.5.2 results on Debian Squeeze with Intel i7
For reasons unknown I ran the testsuite for well over three days before finally giving up. This is a quad core Intel i7 with 8G of meemory and the bootstrap took forever and the testsuite .. well the results below speak for themselves. Any idea why these results would be so poor ? zaphod $ gas --version GNU assembler (GNU Binutils) 2.21 Copyright 2010 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-unknown-linux-gnu'. zaphod $ zaphod $ which gld /usr/local/bin/gld zaphod $ zaphod $ gld --version GNU ld (GNU Binutils) 2.21 Copyright 2010 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. zaphod $ zaphod $ grep -E processor|vendor_id|model\ name|core\ id /proc/cpuinfo processor : 0 vendor_id : GenuineIntel model name : Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz core id : 0 processor : 1 vendor_id : GenuineIntel model name : Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz core id : 1 processor : 2 vendor_id : GenuineIntel model name : Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz core id : 2 processor : 3 vendor_id : GenuineIntel model name : Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz core id : 3 processor : 4 vendor_id : GenuineIntel model name : Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz core id : 0 processor : 5 vendor_id : GenuineIntel model name : Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz core id : 1 processor : 6 vendor_id : GenuineIntel model name : Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz core id : 2 processor : 7 vendor_id : GenuineIntel model name : Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz core id : 3 zaphod $ zaphod $ cat /proc/version Linux version 2.6.32-5-amd64 (Debian 2.6.32-29) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Fri Dec 10 15:35:08 UTC 2010 zaphod $ which gcc /usr/bin/gcc zaphod $ gcc --version gcc (Debian 4.4.5-8) 4.4.5 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. zaphod $ ../gcc-4.5.2/contrib/test_summary cat 'EOF' | LAST_UPDATED: Obtained from SVN: tags/gcc_4_5_2_release revision 167946 Native configuration is x86_64-pc-linux-gnu === g++ tests === Running target unix WARNING: program timed out. FAIL: tmpdir-g++.dg-struct-layout-1/t001 cp_compat_y_tst.o compile UNRESOLVED: tmpdir-g++.dg-struct-layout-1/t001 cp_compat_x_tst.o-cp_compat_y_tst.o link UNRESOLVED: tmpdir-g++.dg-struct-layout-1/t001 cp_compat_x_tst.o-cp_compat_y_tst.o execute WARNING: program timed out. FAIL: tmpdir-g++.dg-struct-layout-1/t002 cp_compat_y_tst.o compile UNRESOLVED: tmpdir-g++.dg-struct-layout-1/t002 cp_compat_x_tst.o-cp_compat_y_tst.o link UNRESOLVED: tmpdir-g++.dg-struct-layout-1/t002 cp_compat_x_tst.o-cp_compat_y_tst.o execute WARNING: program timed out. FAIL: tmpdir-g++.dg-struct-layout-1/t003 cp_compat_y_tst.o compile UNRESOLVED: tmpdir-g++.dg-struct-layout-1/t003 cp_compat_x_tst.o-cp_compat_y_tst.o link UNRESOLVED: tmpdir-g++.dg-struct-layout-1/t003 cp_compat_x_tst.o-cp_compat_y_tst.o execute WARNING: program timed out. FAIL: tmpdir-g++.dg-struct-layout-1/t024 cp_compat_y_tst.o compile UNRESOLVED: tmpdir-g++.dg-struct-layout-1/t024 cp_compat_x_tst.o-cp_compat_y_tst.o link UNRESOLVED: tmpdir-g++.dg-struct-layout-1/t024 cp_compat_x_tst.o-cp_compat_y_tst.o execute WARNING: program timed out. FAIL: tmpdir-g++.dg-struct-layout-1/t025 cp_compat_y_tst.o compile UNRESOLVED: tmpdir-g++.dg-struct-layout-1/t025 cp_compat_x_tst.o-cp_compat_y_tst.o link UNRESOLVED: tmpdir-g++.dg-struct-layout-1/t025 cp_compat_x_tst.o-cp_compat_y_tst.o execute WARNING: program timed out. FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_y_tst.o compile UNRESOLVED: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_x_tst.o-cp_compat_y_tst.o link UNRESOLVED: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_x_tst.o-cp_compat_y_tst.o execute WARNING: program timed out. FAIL: tmpdir-g++.dg-struct-layout-1/t027 cp_compat_y_tst.o compile UNRESOLVED: tmpdir-g++.dg-struct-layout-1/t027 cp_compat_x_tst.o-cp_compat_y_tst.o link UNRESOLVED: tmpdir-g++.dg-struct-layout-1/t027 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: g++.dg/cpp0x/lambda/lambda-mangle.C (internal compiler error) FAIL: g++.dg/cpp0x/lambda/lambda-mangle.C (test for excess errors) ERROR: g++.dg/cpp0x/lambda/lambda-mangle.C: error executing dg-final: couldn't open
Re: Really poor 4.5.2 results on Debian Squeeze with Intel i7
On Sun, Jan 2, 2011 at 7:04 PM, Dennis Clarke dcla...@blastwave.org wrote: For reasons unknown I ran the testsuite for well over three days before finally giving up. This is a quad core Intel i7 with 8G of meemory and the bootstrap took forever and the testsuite .. well the results below speak for themselves. Any idea why these results would be so poor ? At one time, I had a machine with the wrong BIOS setting. It was S slow. I would check BIOS first. -- H.J.
Re: Behavior change of driver on multiple input assembly files
On Sun, Jan 2, 2011 at 6:52 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sun, Jan 2, 2011 at 3:03 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sun, Jan 2, 2011 at 2:05 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sun, Jan 2, 2011 at 1:18 PM, Ian Lance Taylor i...@google.com wrote:
Richard Guenther richard.guent...@gmail.com writes:
On Sun, Jan 2, 2011 at 9:24 PM, Ian Lance Taylor i...@google.com wrote:
Richard Guenther richard.guent...@gmail.com writes:
Your small patch removing have_o || is ok I guess.
Wait. That will change the behaviour of
gcc -o foo.o -c f1.c f2.c f3.c
Is that what we want?
Does it? I don't think so. Most of the combine handling was removed by
the patch that caused the regression, so -o and -c doesn't combine anymore
(with multiple sources).
Sorry, you're right. The difference is that @c has 0 for the combinable
field, and @assembler has 1. Before H.J.'s change, this worked
gcc -c -o f.o f1.s f2.s
After his change, it does not. That is probably not a big deal.
I wonder why @assembler has 1 for combinable? It seems to have been set
to 1 when the combinable field was added in 2004-04-05 with -combine.
Now that -combine has been removed, if the combinable field for
@assembler were 0, it seems to me that H.J.'s problem would also be
fixed. And it seems to me that it should be 0.
Also, right now the gccgo driver depends on the -o behaviour to combine
inputs. If that changes, the driver will need to provide some other way
to let the frontend force inputs to be combined.
For go it isn't equivalent to do gcgo -c t1.go; gcgo -c t2.go; gcgo t1.o
t2.o
compared to gcgo t1.go t2.go?
No, it is not. All .go input files must be passed to go1 at once.
H.J.'s patch has indeed broken gccgo.
Can you try this patch?
Thanks.
--
H.J.
---
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 0d633a4..d0b2c96 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -6582,7 +6582,20 @@ warranty; not even for MERCHANTABILITY or FITNESS
FOR A P
ARTICULAR PURPOSE.\n\n
explicit_link_files = XCNEWVEC (char, n_infiles);
+ /* Check if we should combine inputs. */
combine_inputs = flag_wpa;
+ if (!combine_inputs)
+ for (i = 1; i decoded_options_count; i++)
+ {
+ if (decoded_options[i].opt_index == OPT_x)
+ {
+ struct compiler *compiler
+ = lookup_compiler (NULL, 0, decoded_options[i].arg);
+ if (compiler)
+ combine_inputs = compiler-combinable;
+ break;
+ }
+ }
for (i = 0; (int) i n_infiles; i++)
{
This doesn't work for go since -xgo isn't used with gccgo. Is there
a way to tell what the default language is for a gcc driver?
I am testing this patch with all languages on Linux/x86-64.
--
H.J.
---
gcc/
2011-01-02 H.J. Lu hongjiu...@intel.com
PR driver/47137
* gcc.c (default_language): New.
(main): Lookup compiler to check if we should combine inputs.
* gcc.h (default_language): New.
gcc/go/
2011-01-02 H.J. Lu hongjiu...@intel.com
PR driver/47137
* gospec.c (lang_specific_driver): Set default_language if
needed.
Here is the result:
http://gcc.gnu.org/ml/gcc-testresults/2011-01/msg00160.html
--
H.J.
gcc interprets C++0x initialization construct as function declaration
Hello,
For the following code:
struct S
{
int a;
float b;
};
struct T
{
T(S s) {}
};
int main()
{
T t(S{1, 0.1}); // ERROR HERE
}
gcc 4.6 trunk gives the following errors (with the --std=c++0x option):
decl.cpp: In function 'int main()':
decl.cpp:14:10: error: expected ')' before '{' token
decl.cpp:14:10: error: a function-definition is not allowed here before '{'
token
decl.cpp:14:18: error: expected primary-expression before ')' token
decl.cpp:14:18: error: expected ';' before ')' token
It seems gcc is interpreting the statement as a function declaration.
Is this the desired behaviour?
Regards,
Nate.
Re: Really poor 4.5.2 results on Debian Squeeze with Intel i7
Any idea why these results would be so poor ? Because of your bootstrap settings, more precisely --enable-checking=all. -- Eric Botcazou
[Bug target/47148] [4.6 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47148 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-02 11:29:08 UTC --- Created attachment 22879 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22879 gcc46-pr47148.patch Untested fix on the fnsplit side.
[Bug fortran/47051] [4.6 Regression] Wrong reallocate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47051 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Keywords||wrong-code Summary|Wrong reallocate|[4.6 Regression] Wrong ||reallocate --- Comment #10 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-02 11:54:52 UTC --- The testcase in comment #0 is just Fortran95 (i.e. is well defined without reallocation), and works fine with all versions of gfortran prior to 4.6. It is thus a regression, and a quite serious one IMO since it can affect any code using array assignment. It was found with CP2K, if that matters.
[Bug c++/47151] New: Parsing error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47151
Summary: Parsing error
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: chaturvedi.kuld...@gmail.com
Created attachment 22880
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22880
The revstr.ii file that contains the complete code which the g++ compiler has
generated
I have created a recursive function but forgot to place a semi-colon at the end
of return statement. The compiler, in fact, did not raise any syntactical
errors.
Here is the fragment of the code.
void revstr_recursive(char * str, int start, int end) {
if (start end)
revstr_recursive(str, start + 1, end - 1);
else
return
swap(str[start], str[end]);
}
[Bug c++/47151] Parsing error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47151
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-01-02
12:11:03 UTC ---
Your snippet is perfectly legal, like, eg:
void foo() { }
void bar()
{ return foo(); }
[Bug fortran/47136] [OOP] possible name resolution problems between MODULE and INTERFACE?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47136 --- Comment #2 from janus at gcc dot gnu.org 2011-01-02 13:25:37 UTC --- Here is a variant which gives the same error message: MODULE a TYPE, ABSTRACT :: t CONTAINS PROCEDURE, NOPASS :: pp = s END TYPE CONTAINS SUBROUTINE s() END SUBROUTINE END MODULE MODULE s USE a END MODULE
[Bug fortran/47136] [OOP] possible name resolution problems between MODULE and INTERFACE?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47136 --- Comment #3 from janus at gcc dot gnu.org 2011-01-02 13:33:50 UTC --- Some related non-OOP examples: module a contains subroutine s() end subroutine end module module s use a contains subroutine sub() call s end subroutine end gives: call s 1 Error: Name 's' at (1) is an ambiguous reference to 's' from current program unit Example #2: module a contains subroutine s() end subroutine end module module m use a contains subroutine s() end subroutine end gives: subroutine s() 1 test.f90:8.7: use a 2 Error: Procedure 's' at (1) is already defined at (2) Are these examples actually valid or invalid? Can someone give the relevant quotes from the standard?
[Bug fortran/47136] [OOP] possible name resolution problems between MODULE and INTERFACE?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47136 --- Comment #4 from Daniel Franke dfranke at gcc dot gnu.org 2011-01-02 13:47:41 UTC --- (In reply to comment #3) Some related non-OOP examples: [...] Are these examples actually valid or invalid? Can someone give the relevant quotes from the standard? Lahey's online source checker rejects both examples with similar messages. It doesn't know OOP to test, but one could think that my initial example is invalid after all?!
[Bug libgomp/39939] MinGW 4.3.0 fails to link sample programme.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39939 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||INVALID --- Comment #14 from Kai Tietz ktietz at gcc dot gnu.org 2011-01-02 14:05:53 UTC --- Well, this bug is configure/environment related and not a bug of gcc AFAICS. So I close this as invalid.
[Bug c++/46589] struct member function not declared global
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46589
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org 2011-01-02 14:29:18
UTC ---
(In reply to comment #3)
I'm not sure if [basic.link] paragraph 5 means S::f should have external
linkage or not. Paragraph 4 (third bullet) means that S has external linkage.
Paragraph 5 refers to the name of the class and in this case the class has no
name, but it has the typedef name for linkage purposes. I'm not sure if that
means S::f should or should not have external linkage.
As far as I understand specificiation (C++ Standard - ANSI ISO IEC 14882 2003)
3.5 Program and linkage 3 Basic concepts
--- an object or reference that is explicitly declared const and neither
explicitly declared extern nor
previously declared to have external linkage; or
--- a data member of an anonymous union.
4 A name having namespace scope has external linkage if it is the name of
--- an object or reference, unless it has internal linkage; or
--- a function, unless it has internal linkage; or
--- a named class (clause 9), or an unnamed class defined in a typedef
declaration in which the class has the
typedef name for linkage purposes (7.1.3); or
--- a named enumeration (7.2), or an unnamed enumeration defined in a typedef
declaration in which the
enumeration has the typedef name for linkage purposes (7.1.3); or
--- an enumerator belonging to an enumeration with external linkage; or
--- a template, unless it is a function template that has internal linkage
(clause 14); or
--- a namespace (7.3), unless it is declared within an unnamed namespace.
5 In addition, a member function, static data member, class or enumeration of
class scope has external linkage
if the name of the class has external linkage.
7.1.3
...
If the typedef declaration defines an unnamed class (or enum), the first
typedef-name declared by the declaration
to be that class type (or enum type) is used to denote the class type (or enum
type) for linkage purposes
only (3.5).
[Example:]
typedef struct { } *ps, S; // S is the class name for linkage purposes
[end example]
...
So S becomes here class name and the class S has external linkage. So member
functions of it, too. Just explicit constructor/destructors aren't possible
here, as S() would be a normal method and needs a return type.
Kai
[Bug fortran/47136] [OOP] possible name resolution problems between MODULE and INTERFACE?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47136 --- Comment #5 from janus at gcc dot gnu.org 2011-01-02 14:46:34 UTC --- (In reply to comment #4) (In reply to comment #3) Some related non-OOP examples: [...] Are these examples actually valid or invalid? Can someone give the relevant quotes from the standard? Lahey's online source checker rejects both examples with similar messages. So do openf95 and pathf95. It doesn't know OOP to test, but one could think that my initial example is invalid after all?! I agree that it may be invalid, but one should check the exact wording in the standard.
[Bug fortran/47136] [OOP] possible name resolution problems between MODULE and INTERFACE?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47136 --- Comment #6 from janus at gcc dot gnu.org 2011-01-02 15:19:10 UTC --- (In reply to comment #5) It doesn't know OOP to test, but one could think that my initial example is invalid after all?! I agree that it may be invalid, but one should check the exact wording in the standard. Yes, after a look in the standard I would say that is invalid according to F08, chapter 16.3.1, sentence #2: Within its scope, a local identifier of an entity of class (1) or class (4) shall not be the same as a global identifier used in that scope unless [...] Class (1) contains all sorts of named variables and procedures, including abstract interfaces. The exceptions which I elided in the above statement do not apply. The only question is whether a module counts as used in it's own scope, which I would answer with yes. Therefore I think already the following reduction of comment #0 is invalid: MODULE a ABSTRACT INTERFACE SUBROUTINE s() END SUBROUTINE END INTERFACE END MODULE MODULE s USE a END MODULE Within the scope of module a everything is fine, since the module s is not used. Within the scope of module s, however, the subroutine s is a local identifier (by means of use association) and conflicts with the global identifier of module s itself. Right?
[Bug fortran/47136] [OOP] possible name resolution problems between MODULE and INTERFACE?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47136 janus at gcc dot gnu.org changed: What|Removed |Added Keywords|rejects-valid |accepts-invalid --- Comment #7 from janus at gcc dot gnu.org 2011-01-02 15:21:34 UTC --- (In reply to comment #6) Within the scope of module a everything is fine, since the module s is not used. Within the scope of module s, however, the subroutine s is a local identifier (by means of use association) and conflicts with the global identifier of module s itself. Right? By this reasoning the PR is actually of the type accepts-invalid and not rejects-valid.
[Bug fortran/47136] local identifier shall not be the same as a global identifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47136 janus at gcc dot gnu.org changed: What|Removed |Added Summary|[OOP] possible name |local identifier shall not |resolution problems between |be the same as a global |MODULE and INTERFACE? |identifier --- Comment #8 from janus at gcc dot gnu.org 2011-01-02 15:24:10 UTC --- (In reply to comment #7) (In reply to comment #6) Within the scope of module a everything is fine, since the module s is not used. Within the scope of module s, however, the subroutine s is a local identifier (by means of use association) and conflicts with the global identifier of module s itself. Right? By this reasoning the PR is actually of the type accepts-invalid and not rejects-valid. ... and unrelated to OOP.
[Bug fortran/46408] [OOP] Segfault when running gfortran.dg/class_allocate_6.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46408
--- Comment #4 from janus at gcc dot gnu.org 2011-01-02 15:58:13 UTC ---
Reduced test case:
type t
end type
type, extends(t) :: t2
integer, allocatable :: a
end type
class(t), allocatable :: x, y
allocate(t2 :: x)
allocate(y, source=x)
end
As far as I can see, the copying routine itself is alright. The problem seems
to be with the default initialization of x%a. From the dump:
MAIN__ ()
{
static struct t __def_init_MAIN___t;
static struct t2 __def_init_MAIN___t2 = {};
static struct __vtype_MAIN___t __vtab_MAIN___t = {._hash=6232021, ._size=0,
._extends=0B, ._def_init=__def_init_MAIN___t, ._copy=__copy_MAIN___t};
static struct __vtype_MAIN___t2 __vtab_MAIN___t2 = {._hash=43807140,
._size=8, ._extends=__vtab_MAIN___t, ._def_init=__def_init_MAIN___t2,
._copy=__copy_MAIN___t2};
static struct __class_MAIN___t_a x = {};
static struct __class_MAIN___t_a y = {};
static void __copy_MAIN___t (struct t restrict, struct t restrict);
static void __copy_MAIN___t2 (struct t2 restrict, struct t2 restrict);
try
{
x._data = 0B;
y._data = 0B;
! [ ... allocation of x._data ... ]
(void) __builtin_memcpy ((void *) x._data, (void *) x._vptr-_def_init,
(unnamed-unsigned:64) x._vptr-_size);
! [ ... allocation of y.data ... ]
x._vptr-_copy (x._data, y._data);
(struct __vtype_MAIN___t *) y._vptr = (struct __vtype_MAIN___t *)
x._vptr;
}
finally
{
[...]
}
}
x%a should get default-initialized to NULL via the memcpy call from
x._vptr-_def_init. The memcpy itself is done alright, but apparently the
_def_init variable is not properly initialized (is it?):
static struct t2 __def_init_MAIN___t2 = {};
[Bug fortran/46408] [OOP] Segfault when running gfortran.dg/class_allocate_6.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46408
--- Comment #5 from janus at gcc dot gnu.org 2011-01-02 16:24:00 UTC ---
(In reply to comment #4)
x%a should get default-initialized to NULL via the memcpy call from
x._vptr-_def_init. The memcpy itself is done alright, but apparently the
_def_init variable is not properly initialized (is it?):
static struct t2 __def_init_MAIN___t2 = {};
No, it's not. The problem is: __def_init_MAIN___t2 is declared as SAVE in
gfc_find_derived_vtab. Therefore it's allocatable components do not get
default-initialized to NULL. However, if we don't give it the SAVE attribute,
we get:
Error: Pointer initialization target at (1) must have the SAVE attribute
Because the def_init symbol is used as pointer init target for the vtab.
:(
[Bug rtl-optimization/47028] [4.6 Regression] gcc.dg/tree-ssa/tailrecursion-[57].c FAIL with -foptimize-sibling-calls -fno-forward-propagate -fno-tree-copy-prop -fno-tree-dominator-opts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47028 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-02 17:07:18 UTC --- Author: jakub Date: Sun Jan 2 17:07:15 2011 New Revision: 168401 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168401 Log: PR rtl-optimization/47028 * cfgexpand.c (gimple_expand_cfg): Insert entry edge insertions after parm_birth_insn instead of at the beginning of first bb. * gcc.dg/pr47028.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr47028.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/47140] [4.6 Regression] error: conversion of register to a different size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47140 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-02 17:09:11 UTC --- Author: jakub Date: Sun Jan 2 17:09:08 2011 New Revision: 168402 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168402 Log: PR tree-optimization/47140 * tree-ssa-ccp.c (evaluate_stmt): For binary assignments, use TREE_TYPE (lhs) instead of TREE_TYPE (rhs1) as second argument to bit_value_binop. * gcc.c-torture/compile/pr47140.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr47140.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c
[Bug c/46926] Paired sin() cos() calls optimized to sincos() call.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46926 Andrew Haley aph at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.02 17:19:22 CC||aph at gcc dot gnu.org Ever Confirmed|0 |1
[Bug c++/46589] struct member function not declared global
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46589 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2011-01-02 17:23:42 UTC --- ICC generates: T _ZN1L1GEv
[Bug rtl-optimization/47028] [4.6 Regression] gcc.dg/tree-ssa/tailrecursion-[57].c FAIL with -foptimize-sibling-calls -fno-forward-propagate -fno-tree-copy-prop -fno-tree-dominator-opts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47028 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-02 17:24:00 UTC --- Fixed.
[Bug tree-optimization/47140] [4.6 Regression] error: conversion of register to a different size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47140 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-02 17:24:32 UTC --- Fixed.
[Bug rtl-optimization/47138] backport r158175: replace dominated uses in loop-invariant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47138 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-02 17:50:02 UTC --- The rev. doesn't have a testcase (and it didn't fix a bug?). If you have a testcase that shows this patch fixes a regression it is ok to backport. If it fixes a wrong-code bug then it is also ok to backport if you have a testcase.
[Bug fortran/46408] [OOP] Segfault when running gfortran.dg/class_allocate_6.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46408 janus at gcc dot gnu.org changed: What|Removed |Added CC||sfilippone at uniroma2 dot ||it --- Comment #6 from janus at gcc dot gnu.org 2011-01-02 17:51:39 UTC --- *** Bug 47085 has been marked as a duplicate of this bug. ***
[Bug fortran/47085] [OOP] Problem in allocate( SOURCE=) for polymorphic component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47085 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #4 from janus at gcc dot gnu.org 2011-01-02 17:51:39 UTC --- With the ICE-on-invalid problem solved, this is really just a duplicate of PR46408. *** This bug has been marked as a duplicate of bug 46408 ***
[Bug driver/47137] [4.6 Regression] gcc incorrectly combines assembly inputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47137 --- Comment #3 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-01-02 17:54:24 UTC --- Author: hjl Date: Sun Jan 2 17:54:22 2011 New Revision: 168407 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168407 Log: Don't check have_o when settting combine_inputs. 2011-01-02 H.J. Lu hongjiu...@intel.com PR driver/47137 * gcc.c (main): Don't check have_o when settting combine_inputs. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c
[Bug driver/47137] [4.6 Regression] gcc incorrectly combines assembly inputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47137 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2011-01-02 17:55:04 UTC --- Fixed.
[Bug target/46942] x86_64 parameter passing unnecessary sign/zero extends
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46942 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Depends on||42324 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2011-01-02 17:58:18 UTC --- I proposed to update x86-64 psABI with --- When a value of type _Bool is returned in a register, bit 0 contains the truth value and bits 1 to 7 shall be zero. When an argument of type _Bool is passed in a register or on the stack, bit 0 contains the truth value and bits 1 to 31 shall be zero. When a value of type signed/unsigned char or short is returned in a register, bits 0 to 7 for char and bits 0 to 15 for short contain the value and other bits are left unspecified. When an argument of signed/unsigned type char or short is passed in a register or on the stack, it shall be sign/zero extended to signed/unsigned int. ---
[Bug target/46942] x86_64 parameter passing unnecessary sign/zero extends
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46942 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug rtl-optimization/47138] backport r158175: replace dominated uses in loop-invariant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47138 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-02 18:18:23 UTC --- The rev. doesn't have a testcase (and it didn't fix a bug?). See http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00056.html
[Bug middle-end/47152] New: ice in try_head_merge_bb at cfgcleanup.c:2177
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47152 Summary: ice in try_head_merge_bb at cfgcleanup.c:2177 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: ae...@gcc.gnu.org Host: x86_64-unknown-linux-gnu Target: cris-axis-elf Hello. make[4]: Entering directory `/home/aesok/cris/build/cris-elf/v10/libgcc' # If this is the top-level multilib, build all the other # multilibs. /home/aesok/cris/build/./gcc/xgcc -B/home/aesok/cris/build/./gcc/ -B/home/aesok/ cross-local/cris-elf/cris-elf/bin/ -B/home/aesok/cross-local/cris-elf/cris-elf/l ib/ -isystem /home/aesok/cross-local/cris-elf/cris-elf/include -isystem /home/ae sok/cross-local/cris-elf/cris-elf/sys-include --sysroot=/home/aesok/cross-local /cris-elf -g -O2 -march=v10 -mbest-lib-options -O2 -g -O2 -DIN_GCC -DCROSS_DI RECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmi ssing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 - D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -I. -I. -I../../.././gcc -I../../ ../../gcc/libgcc -I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc -I.. /../../../gcc/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _addsub_df.o -MT _addsub_df.o -MD -MP -MF _addsub_df.dep -DFINE_GRAINED_LIBRARIES -DL_addsub_df - c ../../.././gcc/dp-bit.c ../../.././gcc/dp-bit.c: In function '_fpadd_parts': ../../.././gcc/dp-bit.c:730: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. make[4]: *** [_addsub_df.o] Error 1 This GDB was configured as x86_64-linux-gnu. (gdb) file /home/aesok/cris/build/./gcc/cc1 Reading symbols from /home/aesok/cris/build/gcc/cc1...done. (gdb) run -fpreprocessed dp-bit.i -melf -ffunction-sections -fdata-sections -quiet -dumpbase dp-bit.c -march=v10 -mbest-lib-options -auxbase-strip _addsub_df.o -g -g -g -O2 -O2 -O2 -Wextra -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fno-stack-protector -o dp-bit.s Starting program: /home/aesok/cris/build/gcc/cc1 -fpreprocessed dp-bit.i -melf -ffunction-sections -fdata-sections -quiet -dumpbase dp-bit.c -march=v10 -mbest-lib-options -auxbase-strip _addsub_df.o -g -g -g -O2 -O2 -O2 -Wextra -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fno-stack-protector -o dp-bit.s GNU C (GCC) version 4.6.0 20110102 (experimental) [trunk revision 152933] (cris-elf) compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.6.0 20110102 (experimental) [trunk revision 152933] (cris-elf) compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: d661c5447d50525e7c2e92079814b9be Program received signal SIGSEGV, Segmentation fault. try_head_merge_bb (bb=0x77635888) at ../../gcc/gcc/cfgcleanup.c:2177 2177 while (!NONDEBUG_INSN_P (curr)); (gdb) bt #0 try_head_merge_bb (bb=0x77635888) at ../../gcc/gcc/cfgcleanup.c:2177 #1 0x009ff29e in cleanup_cfg (mode=2) at ../../gcc/gcc/cfgcleanup.c:2480 #2 0x00a17f47 in rest_of_handle_stack_adjustments () at ../../gcc/gcc/combine-stack-adj.c:554 #3 0x0072d34f in execute_one_pass (pass=0xe8b0e0) at ../../gcc/gcc/passes.c:1553 #4 0x0072d645 in execute_pass_list (pass=0xe8b0e0) at ../../gcc/gcc/passes.c:1608 #5 0x0072d65d in execute_pass_list (pass=0xe86880) at ../../gcc/gcc/passes.c:1609 #6 0x0072d65d in execute_pass_list (pass=0xe86820) at ../../gcc/gcc/passes.c:1609 #7 0x0080f556 in tree_rest_of_compilation (fndecl=0x775c8400) at ../../gcc/gcc/tree-optimize.c:422 #8 0x00994110 in cgraph_expand_function (node=0x775c6580) at ../../gcc/gcc/cgraphunit.c:1508 #9 0x00996f29 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1567 #10 0x0099735d in cgraph_finalize_compilation_unit () at ../../gcc/gcc/cgraphunit.c:1031 #11 0x0047a4b4 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:9843 #12 0x007b299f in toplev_main (argc=30, argv=0x7fffe5b8) at ../../gcc/gcc/toplev.c:591 #13 0x7766a1a6 in __libc_start_main () from /lib/libc.so.6 #14 0x00469a19 in _start () (gdb) Anatoly.
[Bug middle-end/47152] ice in try_head_merge_bb at cfgcleanup.c:2177
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47152 --- Comment #1 from aesok at gcc dot gnu.org 2011-01-02 18:28:10 UTC --- Created attachment 22881 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22881 dp-bit.i
[Bug rtl-optimization/47138] backport r158175: replace dominated uses in loop-invariant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47138 --- Comment #4 from Peter A. Bigot bigotp at acm dot org 2011-01-02 18:33:21 UTC --- Exactly: this problem also occurs with the TI msp430 target machine description, currently maintained as a fork on the mspgcc project on sourceforge. I don't know how to provide a test case other than a tar file and patch that adds that target, and a demonstration that without the referenced change build of libgcc fails with unrecognized instruction patterns (a parallel clobber didn't get updated, and the assert at the bottom of cfgrtl.c:patch_jump_insn gets hit when redirect_jump fails on a target that isn't an exit block). On further reflection, since this is fixed in trunk and the msp430 target wouldn't be back-ported into your repository for an existing release series, I'm ok with closing this as not-worth-fixing. I did, however, want an upstream problem report on which to hang the patches that I'll be maintaining.
[Bug middle-end/47152] ice in try_head_merge_bb at cfgcleanup.c:2177
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47152 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-01-02 18:44:21 UTC --- (In reply to comment #0) Hello. make[4]: Entering directory `/home/aesok/cris/build/cris-elf/v10/libgcc' # If this is the top-level multilib, build all the other # multilibs. /home/aesok/cris/build/./gcc/xgcc -B/home/aesok/cris/build/./gcc/ -B/home/aesok/ cross-local/cris-elf/cris-elf/bin/ -B/home/aesok/cross-local/cris-elf/cris-elf/l ib/ -isystem /home/aesok/cross-local/cris-elf/cris-elf/include -isystem /home/ae sok/cross-local/cris-elf/cris-elf/sys-include --sysroot=/home/aesok/cross-local /cris-elf -g -O2 -march=v10 -mbest-lib-options -O2 -g -O2 -DIN_GCC -DCROSS_DI RECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmi ssing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 - D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -I. -I. -I../../.././gcc -I../../ ../../gcc/libgcc -I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc -I.. /../../../gcc/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _addsub_df.o -MT _addsub_df.o -MD -MP -MF _addsub_df.dep -DFINE_GRAINED_LIBRARIES -DL_addsub_df - c ../../.././gcc/dp-bit.c ../../.././gcc/dp-bit.c: In function '_fpadd_parts': ../../.././gcc/dp-bit.c:730: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. make[4]: *** [_addsub_df.o] Error 1 This GDB was configured as x86_64-linux-gnu. (gdb) file /home/aesok/cris/build/./gcc/cc1 Reading symbols from /home/aesok/cris/build/gcc/cc1...done. (gdb) run -fpreprocessed dp-bit.i -melf -ffunction-sections -fdata-sections -quiet -dumpbase dp-bit.c -march=v10 -mbest-lib-options -auxbase-strip _addsub_df.o -g -g -g -O2 -O2 -O2 -Wextra -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fno-stack-protector -o dp-bit.s Starting program: /home/aesok/cris/build/gcc/cc1 -fpreprocessed dp-bit.i -melf -ffunction-sections -fdata-sections -quiet -dumpbase dp-bit.c -march=v10 -mbest-lib-options -auxbase-strip _addsub_df.o -g -g -g -O2 -O2 -O2 -Wextra -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fno-stack-protector -o dp-bit.s GNU C (GCC) version 4.6.0 20110102 (experimental) [trunk revision 152933] Are you sure your GCC tree is up to date?
[Bug target/46942] x86_64 parameter passing unnecessary sign/zero extends
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46942 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-02 19:01:58 UTC --- And upper 32 bits are undefined if the argument is 8/16/32 bit (i.e. callee must sign/zero extend, instead of caller)?
[Bug fortran/46408] [OOP] Segfault when running gfortran.dg/class_allocate_6.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46408
--- Comment #7 from janus at gcc dot gnu.org 2011-01-02 19:02:31 UTC ---
(In reply to comment #5)
(In reply to comment #4)
x%a should get default-initialized to NULL via the memcpy call from
x._vptr-_def_init. The memcpy itself is done alright, but apparently the
_def_init variable is not properly initialized (is it?):
static struct t2 __def_init_MAIN___t2 = {};
No, it's not. The problem is: __def_init_MAIN___t2 is declared as SAVE in
gfc_find_derived_vtab. Therefore it's allocatable components do not get
default-initialized to NULL.
However, if I add a static initializer for this guy, i.e.
static struct t2 __def_init_MAIN___t2 = {.a=0B};
I still get the same valgrind error. What the hell?
Conclusion: The error must come from the second part of the copying routine's
dump:
if (D.1545.a != 0B)
{
__builtin_free ((void *) D.1545.a);
}
D.1545.a = 0B;
Here D.1545 is the old value of the destination. Since this was just freshly
allocated before calling the copy routine, it's technically undefined (unless
the malloc zeroes it). Now, that really is it!
Two possible solutions:
1) Initialize with _def_init, before calling _copy (which means extra work
since we initialize twice).
2) Forget about freeing the old value of 'dst' (which is fine as long as we
only call _copy on allocation, where dst is undefined; this is currently the
case).
[Bug ada/47056] [4.6 Regression] 10 Ada ACATS tests fail to link with undefined reference on ia64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47056 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-02 19:14:22 UTC --- The problem is that CCP turns: pr47056___alignment.46_308 = pr47056___alignment; D.2264_309 = MEM[(struct *)pr47056___alignment.46_308].D.227; into D.2264_309 = MEM[(struct *)pr47056___alignment].D.227; (pr47056___alignment being a function) and while walk_stmt_load_store_addr_ops recognizes the former as an address-of pattern (the is implicit for functions), it doesn't for the latter (unlike for TARGET_MEM_REF) so build_cgraph_edges is fooled and missed the reference to pr47056___alignment. Richard, I presume that the latter form must be deemed invalid GIMPLE?
[Bug fortran/46408] [OOP] Segfault when running gfortran.dg/class_allocate_6.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46408 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | --- Comment #8 from janus at gcc dot gnu.org 2011-01-02 19:23:55 UTC --- (In reply to comment #7) 2) Forget about freeing the old value of 'dst' (which is fine as long as we only call _copy on allocation, where dst is undefined; this is currently the case). This is definitely the proper thing to do: We only need _copy for ALLOCATE with SOURCE. And the best thing is, it's really easily done: Index: gcc/fortran/class.c === --- gcc/fortran/class.c(revision 168379) +++ gcc/fortran/class.c(working copy) @@ -548,7 +548,7 @@ gfc_find_derived_vtab (gfc_symbol *derived) copy-formal-next-sym = dst; /* Set up code. */ sub_ns-code = gfc_get_code (); - sub_ns-code-op = EXEC_ASSIGN; + sub_ns-code-op = EXEC_INIT_ASSIGN; sub_ns-code-expr1 = gfc_lval_expr_from_sym (dst); sub_ns-code-expr2 = gfc_lval_expr_from_sym (src); /* Set initializer. */ It took me a long while to see this, but in the end it's completely trivial. I'll commit after regtesting.
[Bug fortran/46313] [OOP] class container naming collisions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313 --- Comment #17 from janus at gcc dot gnu.org 2011-01-02 19:28:33 UTC --- (In reply to comment #15) Maybe it is really time to use hashed strings? One could void them for strings which are shorter and only hash for longer strings (starting with, e.g, a capital letter to avoid clashes with non-hashed strings). This has been implemented as a fix for PR46971.
[Bug c++/47153] New: g++ with -O3 enters infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47153 Summary: g++ with -O3 enters infinite loop Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: panagopoulosalexand...@hotmail.com Created attachment 22882 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22882 The program for which the bug applies. $ x86_64-redhat-linux-g++ sudoku_solver_single.cpp -O3 -o sudoku_solver_single $ ./sudoku_solver_single .923.8.1...1.7.4...658.6.5.2...4.7.9. The program seems to enter an infinite loop inside solve, even though found_one is set to true. The expected behaviour is observed when -O2 is used instead.
[Bug c++/47153] g++ with -O3 enters infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47153 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.01.02 20:44:28 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-02 20:44:28 UTC --- (In reply to comment #0) Created attachment 22882 [details] The program for which the bug applies. Apparently not: $ ./a.out Usage: ./a.out sudoku puzzle or -f sudoku file Show unknown boxes with . or 0 Please provide a reproducible testcase.
[Bug c++/47153] g++ with -O3 enters infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47153 Zdenek Sojka zsojka at seznam dot cz changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #2 from Zdenek Sojka zsojka at seznam dot cz 2011-01-02 20:45:50 UTC --- Please upload minimal testcase that reproduces the problem. I am not able to reproduce the problem by the steps you provided: $ x86_64-pc-linux-gnu-g++-4.5.2 sudoku_solver_single.cpp -O3 -o sudoku_solver_single $ ./sudoku_solver_single Usage: ./sudoku_solver_single sudoku puzzle or -f sudoku file Show unknown boxes with . or 0 However, if found_one is true, the loop is expected to never finish: } while(found_one); maybe missing ! ?
[Bug middle-end/47152] ice in try_head_merge_bb at cfgcleanup.c:2177
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47152 --- Comment #3 from aesok at gcc dot gnu.org 2011-01-02 20:47:22 UTC --- GNU C (GCC) version 4.6.0 20110102 (experimental) [trunk revision 152933] Are you sure your GCC tree is up to date? Yes. ~/cris2/gcc$ svn update At revision 168408. ~/cris2/gcc$ cd ../build ~/cris2/build$ make make[4]: Entering directory `/home/aesok/cris2/build/cris-elf/v10/libgcc' # If this is the top-level multilib, build all the other # multilibs. /home/aesok/cris2/build/./gcc/xgcc -B/home/aesok/cris2/build/./gcc/ -B/home/aeso k/cross-local/cris-elf/cris-elf/bin/ -B/home/aesok/cross-local/cris-elf/cris-elf /lib/ -isystem /home/aesok/cross-local/cris-elf/cris-elf/include -isystem /home/ aesok/cross-local/cris-elf/cris-elf/sys-include --sysroot=/home/mstein/cross-loc al/cris-elf -g -O2 -march=v10 -mbest-lib-options -O2 -g -O2 -DIN_GCC -DCROSS_ DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -W missing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -I. -I. -I../../.././gcc -I../. ./../../gcc/libgcc -I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc -I ../../../../gcc/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _addsub_df.o -M T _addsub_df.o -MD -MP -MF _addsub_df.dep -DFINE_GRAINED_LIBRARIES -DL_addsub_df -c ../../.././gcc/dp-bit.c ../../.././gcc/dp-bit.c: In function '_fpadd_parts': ../../.././gcc/dp-bit.c:730: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. ~/cris2/build$ /home/aesok/cris2/build/./gcc/xgcc --version xgcc (GCC) 4.6.0 20110102 (experimental) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ~/cris2/build$ /home/aesok/cris2/build/./gcc/cc1 -version GNU C (GCC) version 4.6.0 20110102 (experimental) (cris-elf) compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Anatoly.
[Bug rtl-optimization/46755] ICE: in calc_dfs_tree, at dominance.c:395 with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46755
John Regehr regehr at cs dot utah.edu changed:
What|Removed |Added
CC||regehr at cs dot utah.edu
--- Comment #8 from John Regehr regehr at cs dot utah.edu 2011-01-02 20:48:22
UTC ---
Not sure if this is still useful, but here's a fairly small failure-inducing
testcase for this bug for today's GCC.
[reg...@gamow tmp437]$ current-gcc -O2 -c small.c
small.c: In function 'func':
small.c:32:1: internal compiler error: in calc_dfs_tree, at dominance.c:395
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[reg...@gamow tmp437]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r168402-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r168402-install
--program-prefix=r168402- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20110102 (experimental) (GCC)
[reg...@gamow tmp437]$ cat small.c
static int
foo (int si1, short si2)
{
return ((si1 ^ si2) ((si1 ^ (si1 ^ si2) ~2147483647) - si2 ^ si2))
0 ? si1 : si1 - si2;
}
struct S0
{
const unsigned f3:1;
const unsigned f8:1;
};
struct S0 g_111 = {
1
};
struct S0 g_139 = {
1
};
unsigned long int g_22;
void safe (int);
int func_42 (void);
void func (void)
{
safe (foo (func_42 () != (g_139.f3 | g_111.f8), -1L));
for (g_22 = 0; g_22; g_22 = 1)
{
}
}
[Bug target/46942] x86_64 parameter passing unnecessary sign/zero extends
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46942 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2011-01-02 20:53:12 UTC --- (In reply to comment #5) And upper 32 bits are undefined if the argument is 8/16/32 bit (i.e. callee must sign/zero extend, instead of caller)? If callee wants 64bit, it has to sign/zero extend it to 64bit.
[Bug fortran/46408] [OOP] Segfault when running gfortran.dg/class_allocate_6.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46408 --- Comment #9 from janus at gcc dot gnu.org 2011-01-02 21:01:53 UTC --- Author: janus Date: Sun Jan 2 21:01:50 2011 New Revision: 168409 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168409 Log: 2011-01-02 Janus Weil ja...@gcc.gnu.org PR fortran/46408 * class.c (gfc_find_derived_vtab): Use EXEC_INIT_ASSIGN for __copy_ routine. 2011-01-02 Janus Weil ja...@gcc.gnu.org PR fortran/46408 * gfortran.dg/class_19.f03: Adjust counting of __builtin_free. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/class_19.f03
[Bug fortran/46408] [OOP] Segfault when running gfortran.dg/class_allocate_6.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46408 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from janus at gcc dot gnu.org 2011-01-02 21:20:33 UTC --- Fixed with r168409. Closing.
[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827 --- Comment #43 from janus at gcc dot gnu.org 2011-01-02 21:27:48 UTC --- Hans, does r168302 fix the problem for you, or do you still get Component not found errors?
[Bug libfortran/47154] New: [4.6 Regression] END= does not work in namelist read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47154 Summary: [4.6 Regression] END= does not work in namelist read Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org Original test case by Lawrence Doctors, from http://gcc.gnu.org/ml/fortran/2011-01/msg0.html Reduced test case: i...@linux-fd1f:~/Krempel/Lawr/TST cat tst.f program foo real :: a namelist /b/a open(10,status=scratch) read (10,nml=b,end=100) 100 continue end i...@linux-fd1f:~/Krempel/Lawr/TST gfortran tst.f i...@linux-fd1f:~/Krempel/Lawr/TST ./a.out At line 5 of file tst.f (unit = 10, file = '/tmp/gfortrantmpeSWNTR') Fortran runtime error: `8,� Works with 4.4.
[Bug libfortran/47154] [4.6 Regression] END= does not work in namelist read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47154 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug fortran/45338] Failure on interfacing a function passed as an argument as a custom operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45338 --- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-01-02 21:58:06 UTC --- Author: tkoenig Date: Sun Jan 2 21:58:03 2011 New Revision: 168410 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168410 Log: 2011-02-01 Thomas Koenig tkoe...@gcc.gnu.org Backport from mainline PR fortran/45338 * resolve.c (resolve_operator): Mark function for user-defined operator as referenced. 2011-02-01 Thomas Koenig tkoe...@gcc.gnu.org Backport from mainline PR fortran/45338 * gfortran.dg/userdef_operator_2.f90: New test case. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/userdef_operator_2.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/resolve.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug fortran/45338] Failure on interfacing a function passed as an argument as a custom operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45338 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-01-02 21:59:12 UTC --- Fixed on trunk and 4.5. Closing.
[Bug driver/47137] [4.6 Regression] gcc incorrectly combines assembly inputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47137 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2011-01-02 22:07:25 UTC --- It breaks LTO: [...@gnu-6 gcc]$ cat /tmp/lto.args -xlto -c -B /export/build/gnu/gcc/build-x86_64-linux/gcc/ -w -O2 -flto-partition=none -fno-builtin-abs -v -save-temps -mtune=generic -march=x86-64 -dumpdir /export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gcc/ -dumpbase abs-1.x6 -o /tmp/lto.o abs-1.o abs-1-lib.o main.o [...@gnu-6 gcc]$ ../../xgcc @/tmp/lto.args Reading specs from /export/build/gnu/gcc/build-x86_64-linux/gcc/specs COLLECT_GCC=../../xgcc COLLECT_LTO_WRAPPER=/export/build/gnu/gcc/build-x86_64-linux/gcc/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /export/gnu/import/git/gcc/configure --enable-languages=c --disable-bootstrap --prefix=/usr/gcc-4.6.0 --with-local-prefix=/usr/local --with-fpmath=sse Thread model: posix gcc version 4.6.0 20110102 (experimental) (GCC) xgcc: fatal error: cannot specify -o with -c, -S or -E with multiple files compilation terminated. [...@gnu-6 gcc]$
[Bug fortran/47051] [4.6 Regression] Wrong reallocate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47051 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Blocks||32834 --- Comment #11 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-01-02 22:17:32 UTC --- Joost, you're right.
[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 Keywords||build Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.02 22:41:11 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-02 22:41:11 UTC --- I can't verify it myself but I've had this reported to me in private too, so am going to confirm it. Please provide your full configure command, thanks
[Bug driver/47137] [4.6 Regression] gcc incorrectly combines assembly inputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47137 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-02 22:43:38 UTC --- Yes, flag_wpa is not set (as I said) for non-WHOPR mode. We don't have a flag to identify non-WHOPR link-time.
[Bug rtl-optimization/46755] ICE: in calc_dfs_tree, at dominance.c:395 with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46755
--- Comment #9 from H.J. Lu hjl.tools at gmail dot com 2011-01-02 23:12:46
UTC ---
(In reply to comment #8)
Not sure if this is still useful, but here's a fairly small failure-inducing
testcase for this bug for today's GCC.
[reg...@gamow tmp437]$ current-gcc -O2 -c small.c
small.c: In function 'func':
small.c:32:1: internal compiler error: in calc_dfs_tree, at dominance.c:395
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[reg...@gamow tmp437]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r168402-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r168402-install
--program-prefix=r168402- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20110102 (experimental) (GCC)
[reg...@gamow tmp437]$ cat small.c
static int
foo (int si1, short si2)
{
return ((si1 ^ si2) ((si1 ^ (si1 ^ si2) ~2147483647) - si2 ^ si2))
0 ? si1 : si1 - si2;
}
struct S0
{
const unsigned f3:1;
const unsigned f8:1;
};
struct S0 g_111 = {
1
};
struct S0 g_139 = {
1
};
unsigned long int g_22;
void safe (int);
int func_42 (void);
void func (void)
{
safe (foo (func_42 () != (g_139.f3 | g_111.f8), -1L));
for (g_22 = 0; g_22; g_22 = 1)
{
}
}
This is caused by revision 164431:
http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00727.html
[Bug fortran/37131] inline matmul for small matrix sizes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131 --- Comment #14 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-01-02 23:20:07 UTC --- Created attachment 22883 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22883 matmul loops that vectorize Here's how we could make the different matmul loops look like for different transpose cases. The inner loops vectorize, at least with --fast-math. The last one needs a different temp strategy for vectorization.
[Bug c++/47153] g++ with -O3 enters infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47153 --- Comment #3 from panagopoulosalexandrou at hotmail dot com 2011-01-03 01:52:09 UTC --- Sorry, forget about the found_one thing. Maybe the prompt is confusing; the .923.8.1...1.7.4...658.6.5.2...4.7.9. is actually an argument to the program, not its output. Apparently, it didn't fit on a single line that's why it's printed underneath the execution of the program. $ ./sudoku_solver_single .923..,etc.
[Bug c++/47153] g++ with -O3 enters infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47153 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW Known to work||4.1.2, 4.2.4, 4.3.4 Known to fail||4.4.5, 4.5.2, 4.6.0 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-03 02:17:18 UTC --- thanks for clarifying - I can reproduce it at -O3 with g++ 4.4 and later
[Bug c++/47153] g++ with -O3 enters infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47153
--- Comment #5 from Zdenek Sojka zsojka at seznam dot cz 2011-01-03 02:36:27
UTC ---
You are accessing an array out of bounds:
--- sudoku_solver_single.cpp2011-01-03 03:30:35.0 +0100
+++ sudoku_solver_single2.cpp 2011-01-03 03:33:28.0 +0100
@@ -159,6 +159,7 @@
for(x = left_box; x left_box + 3; x++)
for(y = up_box; y up_box + 3; y++) {
if(solved[x][y]) {
+ if (!resolve(x, y)) __builtin_abort();
status[resolve(x, y) - 1] = 2;
continue;
}
aborts
[Bug c/47155] New: likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47155
Summary: likely wrong code bug
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu
[reg...@gamow tmp438]$ current-gcc -O0 small.c -o small
[reg...@gamow tmp438]$ ./small
1
[reg...@gamow tmp438]$ current-gcc -O1 small.c -o small
[reg...@gamow tmp438]$ ./small
0
[reg...@gamow tmp438]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r168402-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r168402-install
--program-prefix=r168402- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20110102 (experimental) (GCC)
[reg...@gamow tmp438]$ cat small.c
static unsigned int g_1;
static signed char g_2 = 0x81;
int printf(const char *format, ...);
static unsigned char foo(unsigned char p1, unsigned char p2)
{
return p1 * p2;
}
int main (void)
{
int l_5[2];
int i;
for (i = 0; i 2; i++)
l_5[i] = 1;
g_1 = g_2 = foo(-6, l_5[0]);
printf(%u\n, g_1);
return 0;
}
[Bug objc++/47156] New: obj-c++.dg/try-catch-[2|9].mm -fgnu-runtime failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47156 Summary: obj-c++.dg/try-catch-[2|9].mm -fgnu-runtime failures Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/ia32, revision 168408 gave spawn -ignore SIGHUP /export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/obj-c++/../../g++ -B/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/obj-c++/../../ /export/gnu/import/git/gcc/gcc/testsuite/obj-c++.dg/try-catch-2.mm -nostdinc++ -I/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/include -I/export/gnu/import/git/gcc/libstdc++-v3/libsupc++ -I/export/gnu/import/git/gcc/libstdc++-v3/include/backward -I/export/gnu/import/git/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -fgnu-runtime -fobjc-exceptions -I/export/gnu/import/git/gcc/gcc/testsuite/../../libobjc -B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libiberty -B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libobjc/.libs -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libobjc/.libs -lobjc -lm -m32 -o ./try-catch-2.exe^M /tmp/ccnV72SW.o:(.gcc_except_table+0x18): undefined reference to `typeinfo for Frob*'^M collect2: ld returned 1 exit status^M compiler exited with status 1 output is: /tmp/ccnV72SW.o:(.gcc_except_table+0x18): undefined reference to `typeinfo for Frob*'^M collect2: ld returned 1 exit status^M XFAIL: obj-c++.dg/try-catch-2.mm -fgnu-runtime (test for excess errors) Excess errors: /tmp/ccnV72SW.o:(.gcc_except_table+0x18): undefined reference to `typeinfo for Frob*' WARNING: obj-c++.dg/try-catch-2.mm -fgnu-runtime compilation failed to produce executable spawn -ignore SIGHUP /export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/obj-c++/../../g++ -B/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/obj-c++/../../ /export/gnu/import/git/gcc/gcc/testsuite/obj-c++.dg/try-catch-9.mm -nostdinc++ -I/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/include -I/export/gnu/import/git/gcc/libstdc++-v3/libsupc++ -I/export/gnu/import/git/gcc/libstdc++-v3/include/backward -I/export/gnu/import/git/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -fgnu-runtime -fobjc-exceptions -O2 -I/export/gnu/import/git/gcc/gcc/testsuite/../../libobjc -B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libiberty -B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libobjc/.libs -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libobjc/.libs -lobjc -lm -m32 -o ./try-catch-9.exe^M /tmp/cc6JaJgi.o:(.gcc_except_table+0x34): undefined reference to `typeinfo for Object*'^M collect2: ld returned 1 exit status^M compiler exited with status 1 output is: /tmp/cc6JaJgi.o:(.gcc_except_table+0x34): undefined reference to `typeinfo for Object*'^M collect2: ld returned 1 exit status^M XFAIL: obj-c++.dg/try-catch-9.mm -fgnu-runtime (test for excess errors) Excess errors: /tmp/cc6JaJgi.o:(.gcc_except_table+0x34): undefined reference to `typeinfo for Object*' WARNING: obj-c++.dg/try-catch-9.mm -fgnu-runtime compilation failed to produce executable
[Bug libfortran/47154] [4.6 Regression] END= does not work in namelist read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47154 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Known to work||4.5.3 Known to fail||4.6.0 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-01-03 07:34:54 UTC --- Also works with 4.5.3.
