[Bug fortran/32555] [4.3 Regression] Miscompilation of NIST testsuite
--- Comment #2 from burnus at gcc dot gnu dot org 2007-06-30 06:49 --- > FM403.f, FM900.f, and FM903.f fail to compile. > I have confirmed this regression is caused by. > > 2050 FORMAT(2PF8.3,-2PE9.4,F9.4,0PF9.4,9X,-2PE9.4,F9.4) > 1 > Error: Unexpected element in format string at (1) The problem is that the big case block in check_format was checking only for FMT_POSINT and (for "k P", Fortran2003: R1011/R1012) for FMT_SIGNED_INT; however, format_lex can return another state: FMT_ZERO. But due to a bug it was never returned. As P seems to be the only element where zero is allowed, I did the patch as follows. I'm not sure I can submit the patch in the coming days; feel free to submit it. Index: gcc/fortran/io.c === --- gcc/fortran/io.c(Revision 126114) +++ gcc/fortran/io.c(Arbeitskopie) @@ -487,6 +487,7 @@ format_item_1: goto format_item; case FMT_SIGNED_INT: +case FMT_ZERO: /* Signed integer can only precede a P format. */ t = format_lex (); if (t != FMT_P) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-30 06:49:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32555
[Bug fortran/32555] [4.3 Regression] Miscompilation of NIST testsuite
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-06-30 05:14 --- Examples: FM403.f:859.35: 2050 FORMAT(2PF8.3,-2PE9.4,F9.4,0PF9.4,9X,-2PE9.4,F9.4) 1 Error: Unexpected element in format string at (1) FM403.f:860.20: READ(IRVI,2050)EP1S(16),EP1S(17),EP1S(18), EP1S(19), 1 Error: FORMAT label 2050 at (1) not defined FM900.f:651.35: 02126 FORMAT(2PF8.3,-2PE9.4,F9.4,0PG9.4,D9.4,-2PE9.4,F9.4,D9.4,2PG9.4) 1 Error: Unexpected element in format string at (1) FM900.f:652.21: READ(IRVI,02126)BVC, CHAVC, BC2D(1,4), A1C(1), BC2D(2,1), DPAVD 1 Error: FORMAT label 2126 at (1) not defined -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32555
[Bug fortran/32555] New: [4.3 Regression] Miscompilation of NIST testsuite
FM403.f, FM900.f, and FM903.f fail to compile. I have confirmed this regression is caused by. http://gcc.gnu.org/viewcvs?view=rev&revision=126107 Adding Tobias to cc list -- Summary: [4.3 Regression] Miscompilation of NIST testsuite Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32555
[Bug fortran/32554] [4.3 regression] Bug in P formatting
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-06-30 05:03 --- There is an off by 1 error in the calculation of the number of digits. This is a latent bug uncovered by Janne's patch. Patch is on its way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32554
[Bug fortran/30940] Fortran 2003: Scalar CHARACTER supplied to array dummy
--- Comment #4 from patchapp at dberlin dot org 2007-06-30 03:10 --- Subject: Bug number PR30940 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-06/msg02128.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30940
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #37 from ghazi at gcc dot gnu dot org 2007-06-30 02:22 ---
Run this in a.17.1.i targetted to sparc-sun-solaris2.10 with
--enable-checking=yes,fold and:
cc1 -fpreprocessed a.17.1.i -quiet -dumpbase a.17.1.c -mcpu=v9 -auxbase-strip
a.17.1.s -version -fopenmp -fno-show-column -o a.17.1.s
That should show the error.
# 1
"/tmp/kg/basel/egcc-SVN20070627/gcc/testsuite/gcc.dg/gomp/appendix-a/a.17.1.c"
# 1 ""
# 1 ""
# 1
"/tmp/kg/basel/egcc-SVN20070627/gcc/testsuite/gcc.dg/gomp/appendix-a/a.17.1.c"
void
a17_1_wrong ()
{
union
{
int n;
float x;
} u;
#pragma omp parallel
{
#pragma omp atomic
u.n++;
#pragma omp atomic
u.x += 1.0;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug rtl-optimization/30024] segfault with gcc.c-torture/compile/20000804-1.c on spu-elf
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-06-30 02:22 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30024
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #36 from ghazi at gcc dot gnu dot org 2007-06-30 02:16 --- I tried --enable-checking=yes,fold on sparc-sun-solaris2.10, bootstrap works but I'm still getting a few extra failures. Here are two testresults from the same checkout, one regular and one with fold checking turned on: http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg01217.html http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg01270.html The differences are: > FAIL: g++.dg/gomp/atomic-10.C (internal compiler error) > FAIL: g++.dg/gomp/atomic-4.C (internal compiler error) > FAIL: gcc.dg/gomp/appendix-a/a.17.1.c (internal compiler error) > FAIL: gcc.dg/gomp/atomic-10.c (internal compiler error) > FAIL: gcc.dg/gomp/atomic-4.c (internal compiler error) > FAIL: libgomp.c/shared-1.c (internal compiler error) > FAIL: libgomp.c++/pr27337.C -O0 (internal compiler error) > FAIL: libgomp.c++/pr27337.C -O1 (internal compiler error) > FAIL: libgomp.c++/pr27337.C -O2 (internal compiler error) > FAIL: libgomp.c++/pr27337.C -O3 -fomit-frame-pointer (internal compiler > error) > FAIL: libgomp.c++/pr27337.C -O3 -fomit-frame-pointer -funroll-loops > (internal compiler error) > FAIL: libgomp.c++/pr27337.C -O3 -fomit-frame-pointer -funroll-all-loops > -finline-functions (internal compiler error) > FAIL: libgomp.c++/pr27337.C -O3 -g (internal compiler error) > FAIL: libgomp.c++/pr27337.C -Os (internal compiler error) > FAIL: libgomp.c++/shared-1.C -O (internal compiler error) All of the failures are of the form: internal compiler error: in fold_checksum_tree, at fold-const.c:12890 I'll create a testcase for one of them. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-01-16 04:52:08 |2007-06-30 02:16:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug target/32552] Runtime failure in SPEC CPU2000 benchmark fma3d and applu
--- Comment #3 from zadeck at naturalbridge dot com 2007-06-30 02:10 --- I was wondering if we could do something like: /* If we have a definition of INCOMING_RETURN_ADDR_RTX, assume that the rest of the DWARF 2 frame unwind support is also provided. */ #if !defined (DWARF2_UNWIND_INFO) && defined (INCOMING_RETURN_ADDR_RTX) && !defined (ARCH_DOES_NOT_USE_DWARF2) #define DWARF2_UNWIND_INFO 1 #endif and then define ARCH_DOES_NOT_USE_DWARF2 in the right place in the ia-64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552
[Bug target/32552] Runtime failure in SPEC CPU2000 benchmark fma3d and applu
--- Comment #2 from zadeck at naturalbridge dot com 2007-06-30 02:05 --- Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index] Message Nav:[Date Prev] [Date Next] [Thread Prev] [Thread Next] Other format: [Raw text] Re: Fwd: INCOMING_RETURN_ADDR_RTX in ia64.h * From: Jim Wilson * To: "Seongbae Park (박성배, 朴成培)" * Cc: GCC Mailing List , Maxim Kuvyrkov * Date: Fri, 29 Jun 2007 14:46:55 -0700 * Subject: Re: Fwd: INCOMING_RETURN_ADDR_RTX in ia64.h * References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Seongbae Park (박성배, 朴成培) wrote: > Here, because INCOMING_RETURN_ADDR_RTX is ultimately undef'ed, > dataflow doesn't see any definition of the return address register, > and happily treats b0 as not live throughout the function body. > Then, global allocator, guided by this information, allocates > b0 for something else - leading to the return address corruption. The problem here is that defining INCOMING_RETURN_ADDR_RTX automatically enables the DWARF2_UNWIND_INFO support. See defaults.h which does: /* If we have a definition of INCOMING_RETURN_ADDR_RTX, assume that the rest of the DWARF 2 frame unwind support is also provided. */ #if !defined (DWARF2_UNWIND_INFO) && defined (INCOMING_RETURN_ADDR_RTX) #define DWARF2_UNWIND_INFO 1 #endif The DWARF2_UNWIND_INFO support happens not to work on IA-64 for various reasons. This doesn't matter, as IA-64 has its own unwind info format that we use instead of the DWARF2 info, as required by the ABI. Emitting DWARF2 unwind info would just bloat the object files unnecessarily. Since we didn't need INCOMING_RETURN_ADDR_RTX for other reasons, and because we don't want gcc to emit the DWARF2 unwind info, the simple solution was just to not define INCOMING_RETURN_ADDR_RTX. Since the dataflow stuff now needs INCOMING_RETURN_ADDR_RTX, I think the right solution is to uncouple DWARF2_UNWIND_INFO and INCOMING_RETURN_ADDR_RTX so that we can have the latter without the former. The first easy step is to put #define DWARF2_UNWIND_INFO 0 in the config/ia64/ia64.h file. The second harder step is to fix everyplace in the compiler that uses DWARF2_UNWIND_INFO to check its value instead of just checking to see if it is defined. So for instance, in final.c, instead of #if defined (DWARF2_UNWIND_INFO) if (dwarf2out_do_frame ()) dwarf2out_frame_debug (insn, false); #endif we would have #if defined (DWARF2_UNWIND_INFO) if (DWARF2_UNWIND_INFO && dwarf2out_do_frame ()) dwarf2out_frame_debug (insn, false); #endif or something like that. There are some things we can't avoid though. There are a lot of functions in dwarf2out.c that get included in cc1 when DWARF2_UNWIND_INFO is defined, and these will now be included in the IA-64 cc1 even though they will never be called, which is unfortunate. An alternative solution would be to delete the 3 lines of code in defaults.h that set DWARF2_UNWIND_INFO when INCOMING_RETURN_ADDR_RTX is defined, then add a definition of DWARF2_UNWIND_INFO to all targets that need it. This is a better solution from an IA-64 point of view, since it presents us from defining a lot of functions we don't need or want. Unfortunately, finding and fixing all target header files that now need to define DWARF2_UNWIND_INFO will be error prone. Unless maybe we just assume that all targets except IA-64 should define it, which is easy enough. I would not be able to test such a patch though, as I do not have access to all targets that would be modified. Yet another solution would be to add another macro INCOMING_RETURN_ADDR_RTX_2 which acts like INCOMING_RETURN_ADDR_RTX, except that it doesn't enable the unwanted and undesirable DWARF2_UNWIND_INFO as a side-effect. Not very elegant, but it would be a simpler change. -- Jim Wilson, GNU Tools Support, http://www.specifix.com -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552
[Bug fortran/32554] [4.3 regression] Bug in P formatting
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-06-30 00:50 --- I agree, that's why I said I was not sure. I am thinking this is pretty odd. I am going to test snprintf to see if its broken. sprintf works fine as is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32554
[Bug fortran/32554] [4.3 regression] Bug in P formatting
--- Comment #4 from kargl at gcc dot gnu dot org 2007-06-30 00:32 --- (In reply to comment #3) > This appears to fix it but I am not sure yet. More testing. > > */ > #ifdef HAVE_SNPRINTF > - snprintf (buffer, sizeof (buffer), "%+-#" STR(MIN_FIELD_WIDTH) ".*" > + snprintf (buffer, sizeof (buffer)+1, "%+-#" STR(MIN_FIELD_WIDTH) ".*" >GFC_REAL_LARGEST_FORMAT "e", ndigits - 1, value); Are you sure? That looks like a buffer overflow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32554
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #26 from pinskia at gcc dot gnu dot org 2007-06-30 00:30 --- As mentioned many times, libgcc is correct and the issue with the libgcc is a kernel issue. Yes GCC should not be emitting udivid3 in the case of the loop but that is a different bug which is still open. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #25 from pinskia at gcc dot gnu dot org 2007-06-30 00:29 --- Hello anyone in here? I guess you did not see my comment about the code gen issue is going to be fixed. The issue with the library is a different problem and not really an GCC issue and that if the programer uses long long, he either has to use libgcc or create a library which has the same API which means implementing udivid3 also; if they don't then they don't have a way to have a compliant freestanding compiler. I never said Segher was a kernel maintainer, only a kernel hacker. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #24 from malitzke at metronets dot com 2007-06-30 00:22 --- Mr. Torvalds has already answered in comment 1 -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
[Bug fortran/32554] [4.3 regression] Bug in P formatting
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-06-30 00:20 --- This appears to fix it but I am not sure yet. More testing. Index: write.c === --- write.c (revision 126131) +++ write.c (working copy) @@ -546,7 +546,7 @@ output_float (st_parameter_dt *dtp, cons * digits; if the value is zero, the exponent is 00. */ #ifdef HAVE_SNPRINTF - snprintf (buffer, sizeof (buffer), "%+-#" STR(MIN_FIELD_WIDTH) ".*" + snprintf (buffer, sizeof (buffer)+1, "%+-#" STR(MIN_FIELD_WIDTH) ".*" GFC_REAL_LARGEST_FORMAT "e", ndigits - 1, value); #else sprintf (buffer, "%+-#" STR(MIN_FIELD_WIDTH) ".*" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32554
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #23 from malitzke at metronets dot com 2007-06-30 00:18 --- Segher was mentioned twice. First, according to my research he is not a kernel maintainer as implied in comments 4 and 9. He is actuallu Segher Boessenkool, a GCC maintainer, inactive since 2005-02-01, his latest email address is kernel.crashing.org; earlier it was de.ibm.com. I cannot quote him because he has rather offensively forbidden me to do so. Maybe Mr Pinski can quote him. Now to comment 19, What is violated are my rights as a programmer in transforming a carefully circumscribed subtraction into a division. Just repeating the C99 standard writers: Trust the programmer. Don't prevent the programmer from doing what needs to be done. Keep the language small and simple. Provide only one way to do an operation. All I am asking is an effective way to impede the utterly inane and counterproductive (also mentioned as cunning) subtraction to division transformation. Just give me a flag or attribute that works without having use -O0. having to use -O0 would make gcc-4.3 utterly irrelevant to programmers and negate: We strive to provide regular, high quality releases, which we want to work well on a variety of native and cross targets (including GNU/Linux); Anybody recognize this? -- malitzke at metronets dot com changed: What|Removed |Added CC||segher at kernel dot ||crashing dot org, schwab at ||gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
[Bug fortran/32554] [4.3 regression] Bug in P formatting
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-06-30 00:05 --- I have traced to this patch, the change in write.c: http://gcc.gnu.org/viewcvs?view=rev&revision=125100 Added Janne to cc -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32554
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #22 from pinskia at gcc dot gnu dot org 2007-06-29 23:57 --- When I am saying GCC is doing the correct thing, I am talking about the library issue and not about the code gen issue (the code gen issue is filed in a different bug and will be fixed, it just takes time though your rants make it harder to fix stuff because we have to take time out to respond to them). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #21 from pinskia at gcc dot gnu dot org 2007-06-29 23:55 --- How many times do I and others, GCC is doing the correct thing? If you want to ping someone, go talk to Linus. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #20 from malitzke at metronets dot com 2007-06-29 23:53 --- Ping -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
[Bug fortran/17711] Wrong operator name in error message
--- Comment #7 from dfranke at gcc dot gnu dot org 2007-06-29 23:51 --- Think I got all the pieces for this one ... -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-11-22 19:49:21 |2007-06-29 23:51:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17711
[Bug fortran/32554] [4.3 regression] Bug in P formatting
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-06-29 23:41 --- Confirmed. I will take this one. Hmm. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-29 23:41:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32554
[Bug fortran/32554] New: [4.3 regression] Bug in P formatting
Hi, the following code: program gfcbug66 real(8) :: x = 1.0e-100_8 write (*,'(1X,2E12.3)')x, 2 * x write (*,'(1X,1P,2E12.3)') x, 2 * x ! Second printed number is wrong end program gfcbug66 produces: 0.100E-99 0.200E-99 1.000-100 2.000E-10 but it should be 0.100E-99 0.200E-99 1.000-100 2.000-100 This used to work before and with 4.2. Cheers, -ha -- Summary: [4.3 regression] Bug in P formatting Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32554
[Bug fortran/32545] Give an (compile time) error not a warning for wrong edit format statements
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-06-29 23:23 --- Currently inline_1.f90 in gfortran.fortran-torture/compile is passing because the error in the print statement is only giving a warning. Patch testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32545
[Bug tree-optimization/32553] New: missed optimization to eliminate duplicate expressions
In this example:
int g(void);
void f(int *p, int i)
{
p[i] = g();
p[i + 2] = g();
p[i + 10] = g();
p[i + 100] = g();
}
the common expression of (p + i * 4) isn't completely eliminated.
It works with the current stable Debian release (gcc (GCC) 4.1.2 20061115), but
anything later misses this opportunity.
--
Summary: missed optimization to eliminate duplicate expressions
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zippel at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32553
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #19 from schwab at suse dot de 2007-06-29 22:34 --- There is no violation of any C standard. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #18 from malitzke at metronets dot com 2007-06-29 22:19 --- As I am clearly rejected by the GCC insiders in my attempts to help make the C compiler more attuned to the spirit of the C99 committee; I am now forced to alert the user community of what is happening with a near monopoly. And why is a GCC maintainer, with priveledged access to GCC's bugzilla, and hence a spokesperson for the GCC community claiming again and again on GCC's bugzilla that Mr Linus Torvalds is wrong, instead of having the guts to confront Mr torvalds directly. I do not work for Mr Torvalds nor am I part of the the kernel community to deliver an inane message to somebody of the stature of Mr Torvalds. Actually it is evidently clear that Mr Linus Torvalds and Mr Andrew Morton do not need my help. I am actually pursuing this on my own as part of a larger picture. As an outsider GCC's bugzilla is the equivalent to the leads of the good old EE black box. You use use the tools available. The bugzilla.kernel.org thread started by myself is 8501. It was my ignorance at the time that led to a poor title. Actually the linux-kernel had for many years the udivdi3 algorithm. Udivdi3 originally came from BSD. Udividi3 was removed, under some controversy, from kernel-2.6.x. There must have been a good reason, which I as an outsider ignore. However having examined the algorithm in libgcc I thorougly applaud the removal. I would never use udivdi3 in a real time executive and I, as a project engineer, would fire for cause some programmer , who slipped it in against my edict and made it hidden from ldd to avoid detection. Again I am not speaking for Mr. Torvalds. -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
[Bug fortran/24886] different character length in actual and formal argument not detected
--- Comment #7 from burnus at gcc dot gnu dot org 2007-06-29 22:09 --- [Compile-time checking] I think this was fixed a while ago - at least for contained procedures. If not it is then definitely fixed (for contained procedures) by my patch for PR30940: "Character length of actual argument shorter than of dummy argument 'y' (10/20) at (1)" To get it working with the original example, we need whole-file checking which is planned but not implemented. Run-time checking would be nice too. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24886
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #17 from pinskia at gcc dot gnu dot org 2007-06-29 21:45 --- 1) The compiler needs a support library to implement all required features in the standard. 2) That library is libgcc. 3) Linux kernel has its own support library for these functions 4) The linux kernel support library for C is not complete. So where is the GCC bug if the linux support library not complete? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #16 from malitzke at metronets dot com 2007-06-29 21:42 --- A treaty is a bilateral agreement. No something shoved down one Side throat. The worse I look the more I accomplish for others than GCC fanatics -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
[Bug target/32552] Runtime failure in SPEC CPU2000 benchmark fma3d and applu
--- Comment #1 from spark at gcc dot gnu dot org 2007-06-29 21:41 --- Below is the email I sent to Jim Wilson asking for help with the analysis of the bug. Hi Jim, This is an analysis of a correctness bug on ia64, which root cause has to do with your code. After dataflow merge, Richard Guenther reported two runtime failures in SPEC CPU2000 programs on ia64. It turned out to be related to the following code you wrote (or at least committed, according to svn). From ia64.h: 928 /* A C expression whose value is RTL representing the location of the incoming 929return address at the beginning of any function, before the prologue. This 930RTL is either a `REG', indicating that the return value is saved in `REG', 931or a `MEM' representing a location in the stack. This enables DWARF2 932unwind info for C++ EH. */ 933 #define INCOMING_RETURN_ADDR_RTX gen_rtx_REG (VOIDmode, BR_REG (0)) 934 935 /* ??? This is not defined because of three problems. 9361) dwarf2out.c assumes that DWARF_FRAME_RETURN_COLUMN fits in one byte. 937The default value is FIRST_PSEUDO_REGISTER which doesn't. This can be 938worked around by setting PC_REGNUM to FR_REG (0) which is an otherwise 939unused register number. 9402) dwarf2out_frame_debug core dumps while processing prologue insns. We 941need to refine which insns have RTX_FRAME_RELATED_P set and which don't. 9423) It isn't possible to turn off EH frame info by defining DWARF2_UNIND_INFO 943to zero, despite what the documentation implies, because it is tested in 944a few places with #ifdef instead of #if. */ 945 #undef INCOMING_RETURN_ADDR_RTX Here, because INCOMING_RETURN_ADDR_RTX is ultimately undef'ed, dataflow doesn't see any definition of the return address register, and happily treats b0 as not live throughout the function body. Then, global allocator, guided by this information, allocates b0 for something else - leading to the return address corruption. Removing the undef leads to an ICE in dwarf2out.c (probably due to 2 in your comment ?). Certainly from the new dataflow point of view, we need this macro to be defined, because, otherwise, the use of b0 in the return is considered a use without def. Previously, flow() didn't consider uninitialized registers and just having a use of b0 in the return was sufficient, as it made b0 live across the entire function thanks to flow's backward only live analysis. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552
[Bug target/32552] New: Runtime failure in SPEC CPU2000 benchmark fma3d and applu
SPEC CPU2000 applu and fma3d fail at runtime when compiled with -O3. -- Summary: Runtime failure in SPEC CPU2000 benchmark fma3d and applu Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: spark at gcc dot gnu dot org GCC host triplet: ia64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552
[Bug fortran/32551] incorrect output obtained from nested parallelism that is serialized
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-29 21:28 --- Seems to be fixed in trunk: $> gfortran-svn -g -Wall -fopenmp pr32551.f90 && ./a.out omp_get_nested()= F 2 2 2 2 $> gfortran-svn -v gcc version 4.3.0 20070628 (experimental) As I am not 100% sure whether I fully understand your testcase (e.g. why expect 2 as a result, not somethinig from 2-5, depending on the thread hitting the innermost parallel-region first?), I won't close it yet. Maybe Jakub has something to say on this?! -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org, jakub at gcc dot gnu ||dot org GCC build triplet|x86_64-suse-linux | GCC host triplet|x86_64-suse-linux | GCC target triplet|x86_64-suse-linux | Keywords||openmp Summary|INCORRECT OUTPUT OBTAINED |incorrect output obtained |FROM NESTED PARALLELISM THAT|from nested parallelism that |IS SERIALIZED |is serialized Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32551
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-06-29 21:20 --- > A standard is a __treaty__ (contract) between implementor and programmer. And in our implementation, there is a library for support functions. If you don't see that, then please stop your rants. Your rants actually make you look bad. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
[Bug c/32494] gcc-4.3.x _32-bit_ becoming irrelevant to kernel
--- Comment #14 from malitzke at metronets dot com 2007-06-29 21:14 --- The first two sentences of your comment was never disputed by either myself nor from how I read Mr Torvald's comment. The only thing under dispute is the completely unwarrented trnasformation of a subtraction into a division. I am not speaking for the kernel people here but for myself; their subtraction just started me off. There are vey good reasons to avoid ligcc, like atomicity, reentrancy or plain orneryness. If I clearly specify a subtraction any C compiler worthy of its name has no right transform that subtraction into a division and then claim that substitution of entitles GCC to ram libgcc down my throat. In freestanding program I do not want, and apparently the linux kernel, does not want libgcc painted any color. It is our prerogative to specify the operations we want. In hosted programs it might not be worthwhile fighting aganst the under-handed way libgcc is dragged (remember ldd does not show its use). Even the US Supreme Court looks at the drafting process preceeding the Constitution and any laws passed by Congress. Now the below Is what boud the C99 committee in drafting the standard. If this is what bound the standardization committee it is certainly binding on myself the GCC apparently feels differently. The Xfree86-xorg inspires me to believe that reason will prevail one way or another. The original X3J11 charter clearly mandated codifying common existing practice, and the C89 Committee held fast to precedent wherever that was clear and unambiguous. The vast majority of the language defined by C89 was precisely the same as defined in Appendix A of the first edition of The C Programming Language by Brian Kernighan and Dennis Ritchie, and as was implemented in almost all C translators of the time. (That document is hereinafter referred to asK&R.) K&R was not the only source of existing practice. Much work had been done over the years to improve the C language by addressing its weaknesses, and the C89 Committee formalized enhancements of proven value which had become part of the various dialects of C. This practice has continued in the present Committee. Existing practice, however, has not always been consistent. Various dialects of C have approached problems in different and sometimes diametrically opposed ways. This divergence has happened for several reasons. First, K&R, which once served as the language specification for almost all C translators, is imprecise in some areas (thereby allowing divergent interpretations), and it does not address some issues (such as a complete specification of a library) important for code portability. Second, as the language has matured over the years, various extensions have been added in different dialects to address limitations and weaknesses of the language; but these extensions have not been consistent across dialects. One of the C89 Committee's goals was to consider such areas of divergence and to establish a set of clear, unambiguous rules consistent with the rest of the language. This effort included the consideration of extensions made in various C dialects, the specification of a complete set of required library functions, and the development of a complete, correct syntax for C. Much of the Committee's work has always been in large part a balancing act. The C89 Committee tried to improve portability while retaining the definition of certain features of C as machine-dependent, it attempted to incorporate valuable new ideas without disrupting the basic structure and fabric of the language, and it tried to develop a clear and consistent language without invalidating existing programs. All of the goals were important and each decision was weighed in the light of sometimes contradictory requirements in an attempt to reach a workable compromise. In specifying a standard language, the C89 Committee used several principles which continue to guide our deliberations today. The most important of these are: Existing code is important, existing implementations are not. A large body of C code exists of considerable commercial value. Every attempt has been made to ensure that the bulk of this code will be acceptable to any implementation conforming to the Standard. The C89 Committee did not want to force most programmers to modify their C programs just to have them accepted by a conforming translator. On the other hand, no one implementation was held up as the exemplar by which to define C. It was assumed that all existing implementations must change somewhat to conform to the Standard. C code can be portable. Although the C language was originally born with the UNIX operating system on the PDP-11, it has since been implemented on a wide variety of computers and operating systems. It has also seen considerable use in cross-compilation of code for embedded systems to be executed in a free-standing environment. The C89 Committee attempted to specify the langu
[Bug target/32335] libgcc build failure, ICE in cselib_record_set, at cselib.c:1508
--- Comment #17 from rask at sygehus dot dk 2007-06-29 21:10 --- Fixed for both m32c and avr, so closing. -- rask at sygehus dot dk changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32335
[Bug rtl-optimization/32372] [4.3 Regression] ICE in df_refs_verify, at df-scan.c:4065
--- Comment #7 from zadeck at naturalbridge dot com 2007-06-29 21:02 --- Subject: Re: [4.3 Regression] ICE in df_refs_verify, at df-scan.c:4065 hubicka at gcc dot gnu dot org wrote: > --- Comment #6 from hubicka at gcc dot gnu dot org 2007-06-29 20:15 > --- > Paolo's rumor is correct, Indeed. I somehow lost track in patches that was or > wasn't approved or tested. I've comited the fix now. > > > thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32372
[Bug fortran/32550] openmp: COPYPRIVATE of pointer variables fails
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-29 21:00 --- Bill, thanks for your report! Here's a slightly simplified testcase: $> cat pr32550.f90 integer, pointer, save :: ptr integer, target :: targ !$omp threadprivate(ptr) !$omp parallel shared(targ) !$omp single ptr => targ !$omp end single copyprivate(ptr) !$omp end parallel END The testcase compiles, but crashes on execution (SIGSEGV). If the COPYPRIVATE-clause or the pointer/target attributes are removed, the resulting binary does not crash. Output from gdb is not very helpful, but valgrind gives: ==32677== Thread 2: ==32677== Invalid write of size 4 ==32677==at 0x80486FE: MAIN__.omp_fn.0 (pr32550.f90:9) ==32677==by 0x40FAFFC: gomp_thread_start (team.c:108) ==32677==by 0x410F2C0: start_thread (in /lib/libpthread-2.5.so) ==32677==by 0x41D8FAD: clone (in /lib/libc-2.5.so) ==32677== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==32677== ==32677== Process terminating with default action of signal 11 (SIGSEGV) ==32677== Access not within mapped region at address 0x0 ==32677==at 0x80486FE: MAIN__.omp_fn.0 (pr32550.f90:9) ==32677==by 0x40FAFFC: gomp_thread_start (team.c:108) ==32677==by 0x410F2C0: start_thread (in /lib/libpthread-2.5.so) ==32677==by 0x41D8FAD: clone (in /lib/libc-2.5.so) Adding Jakub as CC. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org, jakub at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-suse-linux | GCC host triplet|x86_64-suse-linux | GCC target triplet|x86_64-suse-linux | Keywords||openmp Known to fail||4.2.1 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-06-29 21:00:42 date|| Summary|THE COPYPRIVATE CLAUSE FAILS|openmp: COPYPRIVATE of |TO COPY THE PTR AT THE END |pointer variables fails |OF A 'SINGLE' CONSTRUCT | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32550
[Bug c++/31724] [4.3 Regression] More "same canonical type node" fun
--- Comment #13 from dgregor at gcc dot gnu dot org 2007-06-29 20:25 --- Fixed on mainline -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Priority|P1 |P3 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31724
[Bug c++/31724] [4.3 Regression] More "same canonical type node" fun
--- Comment #12 from dgregor at gcc dot gnu dot org 2007-06-29 20:21 --- Subject: Bug 31724 Author: dgregor Date: Fri Jun 29 20:21:41 2007 New Revision: 126124 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126124 Log: 2007-06-29 Douglas Gregor <[EMAIL PROTECTED]> PR c++/31724 * init.c (build_new_1): Use structural equality on the copy of the array type. 2007-06-29 Douglas Gregor <[EMAIL PROTECTED]> * g++.dg/other/canon-31724.C: New. Added: trunk/gcc/testsuite/g++.dg/other/canon-31724.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31724
[Bug rtl-optimization/32504] [4.3 Regression] internal compiler error: in df_refs_verify, at df-scan.c:4058
--- Comment #3 from hubicka at gcc dot gnu dot org 2007-06-29 20:19 --- The testcase works for me on current mainline with sharing checking patch on x86_64-linux, but since the target triplet is not specified, can you double check, please, that the bug is gone? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32504
[Bug rtl-optimization/32372] [4.3 Regression] ICE in df_refs_verify, at df-scan.c:4065
--- Comment #6 from hubicka at gcc dot gnu dot org 2007-06-29 20:15 --- Paolo's rumor is correct, Indeed. I somehow lost track in patches that was or wasn't approved or tested. I've comited the fix now. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32372
[Bug target/32335] libgcc build failure, ICE in cselib_record_set, at cselib.c:1508
--- Comment #16 from aesok at gcc dot gnu dot org 2007-06-29 20:15 --- Fixed for avr target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32335
[Bug rtl-optimization/32372] [4.3 Regression] ICE in df_refs_verify, at df-scan.c:4065
--- Comment #5 from hubicka at gcc dot gnu dot org 2007-06-29 20:13 --- Subject: Bug 32372 Author: hubicka Date: Fri Jun 29 20:13:41 2007 New Revision: 126122 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126122 Log: PR middle-end/32372 * cse.c (cse_insn): Avoid invalid sharing in between register note and the insn pattern. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr32372.c Modified: trunk/gcc/ChangeLog trunk/gcc/cse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32372
[Bug target/32335] libgcc build failure, ICE in cselib_record_set, at cselib.c:1508
--- Comment #15 from aesok at gcc dot gnu dot org 2007-06-29 20:06 --- Subject: Bug 32335 Author: aesok Date: Fri Jun 29 20:05:56 2007 New Revision: 126121 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126121 Log: PR target/32335 * config/avr/avr.c: Include dataflow header file. (expand_prologue): Adjust for prologue insn change. * config/avr/avr.md (call_prologue_saves): Only modify REG_SP once inside a insn. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32335
[Bug fortran/32545] Give an (compile time) error not a warning for wrong edit format statements
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-06-29 20:05 --- Since I partly discovered this, I will see what I can do. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-29 20:05:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32545
[Bug c++/32549] Wrong template instance resolution among multiple object files.
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-29 19:45 ---
I don't think this is a bug.
So we have in one TU:
typedef struct {
char x[10];
} Argument;
And in the other:
typedef struct {
char x[20];
} Argument;
--- cut ---
IIRC from my reading of the C++ standard, that Argument here has to be same
types accross TUs (the One Definition Rule).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32549
[Bug bootstrap/31020] [4.3 Regression] cannot write in
--- Comment #6 from jsm28 at gcc dot gnu dot org 2007-06-29 19:43 --- Yes, this is fixed. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31020
[Bug libfortran/32456] IO error message should show Unit/Filename
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-06-29 19:39 --- Subject: Bug 32456 Author: jvdelisle Date: Fri Jun 29 19:39:21 2007 New Revision: 126119 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126119 Log: 2007-06-29 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/32456 * io/unit.c (filename_from_unit): Don't use find_unit, instead search for unit directly. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/unit.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32456
[Bug target/30058] [4.3 regression] bootstrap broken on i386-unknown-netbsdelf2.0.2
-- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|geoffk at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30058
[Bug rtl-optimization/32372] [4.3 Regression] ICE in df_refs_verify, at df-scan.c:4065
--- Comment #4 from zadeck at naturalbridge dot com 2007-06-29 19:34 --- there is a rumor being circulated by bonzini that one of honza's unsharing patches fixes this. However, this fails on the current truck. One positive note is that if you add in honza's illegal sharing detector, it triggers that rather than the verify error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32372
[Bug tree-optimization/32527] [4.3 Regression] ICE in build2_stat, at tree.c:3074
--- Comment #5 from mark at codesourcery dot com 2007-06-29 19:29 --- Subject: Re: [4.3 Regression] ICE in build2_stat, at tree.c:3074 pinskia at gcc dot gnu dot org wrote: > --- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-29 19:27 > --- > Mark, > Even though this has only showed up in Fortran code correctly. I could make > a C testcase where it fails. The Fortran code looks simplier because of > arrays > in Fortran are way simplier than in C. > Do you want a C example to be able to mark this as a P1? Yes. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32527
[Bug tree-optimization/32527] [4.3 Regression] ICE in build2_stat, at tree.c:3074
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-29 19:27 --- Mark, Even though this has only showed up in Fortran code correctly. I could make a C testcase where it fails. The Fortran code looks simplier because of arrays in Fortran are way simplier than in C. Do you want a C example to be able to mark this as a P1? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32527
[Bug rtl-optimization/32372] [4.3 Regression] ICE in df_refs_verify, at df-scan.c:4065
--- Comment #3 from bonzini at gnu dot org 2007-06-29 19:26 --- CCing Honza, he had a patch for this bug. -- bonzini at gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32372
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #17 from bonzini at gnu dot org 2007-06-29 19:25 --- And that's why I left it assigned to me. I'll work on it next week. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug libfortran/32456] IO error message should show Unit/Filename
--- Comment #8 from andreast at gcc dot gnu dot org 2007-06-29 19:16 --- With the patch referenced in #7 results on i686-darwin === gfortran Summary === # of expected passes18372 # of unexpected failures16 # of expected failures 8 # of unsupported tests 38 Thanks Jerry! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32456
[Bug fortran/31580] Better error message for not-found operator
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-06-29 19:09 --- Fixed in trunk, no backport. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31580
[Bug fortran/31580] Better error message for not-found operator
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-06-29 19:06 --- Subject: Bug 31580 Author: dfranke Date: Fri Jun 29 19:05:58 2007 New Revision: 126117 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126117 Log: gcc/fortran: 2007-06-29 Daniel Franke <[EMAIL PROTECTED]> PR fortran/31580 * resolve.c (resolve_operator): Added check whether a user defined operator is available. gcc/testsuite: 2007-06-29 Daniel Franke <[EMAIL PROTECTED]> PR fortran/31580 * gfortran.dg/operator_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/operator_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31580
[Bug target/32457] [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize)
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #16 from echristo at apple dot com 2007-06-29 19:00 --- No, we shouldn't close it until we can get the compiler building on ppc with -mdynamic-no-pic. -- echristo at apple dot com changed: What|Removed |Added CC||echristo at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug tree-optimization/32540] [4.3 Regression] Exponential time behavior in PRE
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32540
[Bug fortran/32551] New: INCORRECT OUTPUT OBTAINED FROM NESTED PARALLELISM THAT IS SERIALIZED
Description: This test case tries to show that the following statement found in the OpenMP API Version 2.5 May 2005 on p.29 lines 21-24 is true: "When a thread executing inside an active parallel region encounters a parallel construct, the new team which is created will consist of only the encountering thread, when any of the following conditions hold: * nested parallelism is disabled." > gfortran -v Using built-in specs. Target: x86_64-suse-linux Configured with: ../xt-gcc-4.2.0/configure --prefix=/opt/gcc/4.2.0/snos --disable-nls --libdir=/opt/gcc/4.2.0/snos/lib --enable-languages=c,c++,fortran --with-gxx-include-dir=/opt/gcc/4.2.0/snos/include/g++ --with-slibdir=/opt/gcc/4.2.0/snos/lib --with-system-zlib --enable-shared --enable-__cxa_atexit x86_64-suse-linux Thread model: posix gcc version 4.2.0 20070514 (rpm:4) > cat bug2837.f90 ! Derived from OpenMP test omp1/F2_2_9g.f90 use omp_lib implicit none integer, parameter :: NT = 4 integer :: nThreads(NT) integer :: tmp = 0 !$call omp_set_dynamic(.false.) !$call omp_set_num_threads(NT) print *, 'omp_get_nested()=',omp_get_nested() !$omp parallel default(private) shared(nThreads) tmp = 1 !$omp parallel default(shared) !$omp atomic tmp = tmp + omp_get_thread_num() + 1 !$omp end parallel nThreads(omp_get_thread_num()+1) = tmp !$omp end parallel print *, nThreads END > ftn -O3 -fopenmp -o x bug2837.f90 > aprun -n 1 ./x omp_get_nested()= F 1 1 1 1 Application 4711 resources: utime 0, stime 0 Expected output (from PGI compilation): > ftn -o x -O3 -mp -Mconcur=nonuma bug2837.f90 bug2837.f90: > aprun -n 1 ./x Warning: omp_set_num_threads (4) greater than available cpus (1) omp_get_nested()= F 2222 Application 4712 resources: utime 0, stime 0 -- Note: ftn is an alias for: /opt/gcc/4.2.0/bin/../snos/bin/gfortran -static -v -I/opt/xt-mpt/2.1/mpich2-64/GP/include -I/opt/xt-mpt/2.1/mpich2-64/GP/include -L/opt/xt-mpt/2.1/mpich2-64/GP/lib -I/opt/acml/3.6.1/gnu64/include -I/opt/xt-libsci/10.1.0/gnu/snos64/include -I/opt/xt-libsci/10.1.0/gnu/snos64/include/superlu -I/opt/xt-mpt/2.1/sma/P/include -L/opt/acml/3.6.1/gnu64/lib -L/opt/xt-libsci/10.1.0/gnu/snos64/lib -L/opt/xt-mpt/2.1/sma/P/lib -lmpichf90 -lsci -lacml -lsma -lmpichf90 -lmpich -lrt -D__CRAYXT_COMPUTE_LINUX_TARGET -D__TARGET_LINUX__ -fno-second-underscore -I/notbackedup/users/rsrel/rs64.DEV.070604.Mon/install/include -I/opt/xt-catamount/2.1/catamount/linux/include -I/opt/xt-service/2.1/include -L/notbackedup/users/rsrel/rs64.DEV.070604.Mon/install/lib/snos64 -L/opt/xt-pe/2.1/cnos/linux/64/lib -L/opt/xt-mpt/2.1/lib/snos64 -L/opt/xt-service/2.1/lib/snos64 -Wl,--start -lpct -lalpslli -lalpsutil -lportals -lpthread -Wl,--end -lgfortranbegin -lgfortran -lm -- Summary: INCORRECT OUTPUT OBTAINED FROM NESTED PARALLELISM THAT IS SERIALIZED Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: longb at cray dot com GCC build triplet: x86_64-suse-linux GCC host triplet: x86_64-suse-linux GCC target triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32551
[Bug tree-optimization/32527] [4.3 Regression] ICE in build2_stat, at tree.c:3074
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32527
[Bug target/32522] [4.3 Regression] Bootstrap failure on Alpha due to pointer-plus changes
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32522
[Bug middle-end/32441] [4.3 Regression] ICE in expand_expr_real_1, at expr.c:7109
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-06-29 18:52 --- There is nothing wrong with langhooks per se. The problem is langhooks that influence the interpretation of the IR, not langhooks that are used to *create* the IR. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32441
[Bug target/32431] [4.3 Regression] ICE in df_refs_verify, at df-scan.c:4066
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32431
[Bug fortran/31580] Better error message for not-found operator
--- Comment #2 from patchapp at dberlin dot org 2007-06-29 18:50 --- Subject: Bug number PR31580 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-06/msg02115.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31580
[Bug middle-end/32399] [4.3 Regression] ICE in build2_stat, at tree.c:3074
--- Comment #9 from mmitchel at gcc dot gnu dot org 2007-06-29 18:49 --- Andrew, do you want to convert to sizetype or to ptrdiff_t? Does it matter? -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
[Bug fortran/31580] Better error message for not-found operator
-- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-04-16 13:37:26 |2007-06-29 18:49:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31580
[Bug regression/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
[Bug c++/32385] [4.1/4.2/4.3 regression] ICE with struct in default argument of template function
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32385
[Bug c++/32384] [4.1/4.2/4.3 regression] Pseudo-dtor in template class rejected
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32384
[Bug rtl-optimization/32372] [4.3 Regression] ICE in df_refs_verify, at df-scan.c:4065
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32372
[Bug middle-end/32370] [4.3 Regression] Segfault after rejecting bogus assembler
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32370
[Bug fortran/32550] New: THE COPYPRIVATE CLAUSE FAILS TO COPY THE PTR AT THE END OF A 'SINGLE' CONSTRUCT
Description: The test case checks that the following statement found in the section 2.8.4.2 copyprivate clause of the OpenMP API Version 2.5 May 2005 (p. 86 lines 22-24) will work: "If the list item is a pointer, then in all other threads in the team, the list item becomes pointer associated (as if by pointer assignment) with the corresponding list itme in the thread that executed the structure block." associated with the single construct. Currently the test case fails with a "Killed" message that is probably due to a bad address when handling the copyprivate directive after completing the structured block of the single construct. > gfortran -v Using built-in specs. Target: x86_64-suse-linux Configured with: ../xt-gcc-4.2.0/configure --prefix=/opt/gcc/4.2.0/snos --disable-nls --libdir=/opt/gcc/4.2.0/snos/lib --enable-languages=c,c++,fortran --with-gxx-include-dir=/opt/gcc/4.2.0/snos/include/g++ --with-slibdir=/opt/gcc/4.2.0/snos/lib --with-system-zlib --enable-shared --enable-__cxa_atexit x86_64-suse-linux Thread model: posix gcc version 4.2.0 20070514 (rpm:4) > cat bug2836.f90 ! Derived from OpenMP test omp1/F2_6_2_8_5ze.f90 use omp_lib implicit none integer, parameter :: NT = 4 integer :: nThreads(NT) integer, pointer,save :: ptr integer, target :: targ !$omp threadprivate(ptr) !$call omp_set_dynamic(.false.) !$call omp_set_num_threads(NT) targ = 0 nThreads = 0 !$omp parallel shared(targ) !$omp single print *, 'begin single PE=',omp_get_thread_num() ptr => targ targ = 1 print *, 'end single PE=',omp_get_thread_num() !$omp end single copyprivate(ptr) print *, 'after single PE=',omp_get_thread_num() !$omp barrier nThreads(omp_get_thread_num()+1) = ptr !$omp end parallel print *, nThreads END > ftn -O3 -fopenmp -o x bug2836.f90 > aprun -n 1 ./x begin single PE= 0 end single PE= 0 Application 4396 exit signals: Killed Application 4396 resources: utime 0, stime 0 Expected output using the PGI compiler: > ftn -o x -O3 -mp -Mconcur=nonuma bug2836.f90 bug2836.f90: > aprun -n 1 ./x Warning: omp_set_num_threads (4) greater than available cpus (1) begin single PE=1 end single PE=1 after single PE=0 after single PE=1 after single PE=2 after single PE=3 1111 Application 4399 resources: utime 0, stime 0 -- Note: ftn is an alias for: /opt/gcc/4.2.0/bin/../snos/bin/gfortran -static -v -I/opt/xt-mpt/2.1/mpich2-64/GP/include -I/opt/xt-mpt/2.1/mpich2-64/GP/include -L/opt/xt-mpt/2.1/mpich2-64/GP/lib -I/opt/acml/3.6.1/gnu64/include -I/opt/xt-libsci/10.1.0/gnu/snos64/include -I/opt/xt-libsci/10.1.0/gnu/snos64/include/superlu -I/opt/xt-mpt/2.1/sma/P/include -L/opt/acml/3.6.1/gnu64/lib -L/opt/xt-libsci/10.1.0/gnu/snos64/lib -L/opt/xt-mpt/2.1/sma/P/lib -lmpichf90 -lsci -lacml -lsma -lmpichf90 -lmpich -lrt -D__CRAYXT_COMPUTE_LINUX_TARGET -D__TARGET_LINUX__ -fno-second-underscore -I/notbackedup/users/rsrel/rs64.DEV.070604.Mon/install/include -I/opt/xt-catamount/2.1/catamount/linux/include -I/opt/xt-service/2.1/include -L/notbackedup/users/rsrel/rs64.DEV.070604.Mon/install/lib/snos64 -L/opt/xt-pe/2.1/cnos/linux/64/lib -L/opt/xt-mpt/2.1/lib/snos64 -L/opt/xt-service/2.1/lib/snos64 -Wl,--start -lpct -lalpslli -lalpsutil -lportals -lpthread -Wl,--end -lgfortranbegin -lgfortran -lm -- Summary: THE COPYPRIVATE CLAUSE FAILS TO COPY THE PTR AT THE END OF A 'SINGLE' CONSTRUCT Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: longb at cray dot com GCC build triplet: x86_64-suse-linux GCC host triplet: x86_64-suse-linux GCC target triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32550
[Bug target/32338] [4.3 Regression] Error: .prologue within prologue
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32338
[Bug target/32337] [4.3 Regression] Error: Register number out of range 0..1
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32337
[Bug middle-end/32304] [4.3 Regression] ICE in set_mem_attributes_minus_bitpos
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32304
[Bug tree-optimization/32303] [4.3 Regression] SPEC2006 447.dealII miscompiled at -O2
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32303
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug c/32295] [4.1/4.2/4.3 Regression] An invalid c code causes an ICE in create_tmp_var, at gimplify.c:489
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32295
[Bug middle-end/32269] [4.3 Regression] 403.gcc miscompiled
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32269
[Bug c++/32260] [4.3 Regression] too many warning: dereferencing type-punned pointer will break strict-aliasing rules
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32260
[Bug c++/32253] [4.3 regression] ICE with variadic templates and function pointers
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32253
[Bug c++/32252] [4.3 regression] ICE with variadic templates and arrays
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32252
[Bug c++/32251] [4.1/4.2/4.3 regression] ICE on delete operator with ellipsis
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32251
[Bug fortran/32242] [4.3 Regression] internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:386
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32242
[Bug c++/32241] [4.1/4.2/4.3 regression] ICE trying to call x.~X(); in a template
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32241
[Bug fortran/32238] [4.3 Regression] ICE in gfc_conv_constant (where() with complex arrays)
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32238
[Bug c++/32232] [4.1/4.2/4.3 Regression] ICE in resolve_overloaded_unification
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32232
[Bug tree-optimization/32230] [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
[Bug fortran/32222] [4.3 Regression] ICE in gfc_trans_assignment_1
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
[Bug middle-end/32135] [4.3 Regression] bogus array-ref fold triggering array overflow warning
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32135
[Bug c++/32128] [4.3 regression] ICE on variadic template with two parameter packs
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32128
[Bug c++/32127] [4.3 regression] ICE with invalid static member in variadic template
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32127
[Bug c++/32126] [4.3 regression] ICE with invalid definition of variadic template
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32126
[Bug c++/32125] [4.3 regression] ICE with invalid specialization of variadic template
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32125
