[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-10 07:31
---
For the TRANSPOSE case, the generated code shows that the {u,l}bounds simply
aren't set right:
$ cat pr29391.f90
integer :: i(-1:1,-1:1)=0, j(2)
j = lbound(transpose(i))
end
$ cat pr29391.f90.003t.original
MAIN__ ()
{
int4 j[2];
static int4 i[9] = {0, 0, 0, 0, 0, 0, 0, 0, 0};
_gfortran_set_std (70, 127, 0);
{
int8 S.0;
S.0 = 1;
while (1)
{
if (S.0 > 2) goto L.1; else (void) 0;
{
struct array2_int4 atmp.2;
struct array2_int4 parm.1;
parm.1.dtype = 266;
parm.1.dim[0].lbound = -1;
parm.1.dim[0].ubound = 1;
parm.1.dim[0].stride = 1;
parm.1.dim[1].lbound = -1;
parm.1.dim[1].ubound = 1;
parm.1.dim[1].stride = 3;
parm.1.data = (void *) &i[0];
parm.1.offset = 0;
atmp.2.dtype = parm.1.dtype;
atmp.2.dim[0].stride = parm.1.dim[1].stride;
atmp.2.dim[0].lbound = parm.1.dim[1].lbound;
atmp.2.dim[0].ubound = parm.1.dim[1].ubound;
atmp.2.dim[1].stride = parm.1.dim[0].stride;
atmp.2.dim[1].lbound = parm.1.dim[0].lbound;
atmp.2.dim[1].ubound = parm.1.dim[0].ubound;
atmp.2.data = parm.1.data;
atmp.2.offset = parm.1.offset;
j[NON_LVALUE_EXPR + -1] = (int4) atmp.2.dim[S.0 - 1].lbound;
}
S.0 = S.0 + 1;
}
L.1:;
}
}
The following patch ought to fix it:
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (revision 117560)
+++ gcc/fortran/trans-array.c (working copy)
@@ -787,11 +787,17 @@
gfc_add_modify_expr (&se->pre,
gfc_conv_descriptor_lbound (dest, dest_index),
- gfc_conv_descriptor_lbound (src, src_index));
+ gfc_index_one_node);
gfc_add_modify_expr (&se->pre,
gfc_conv_descriptor_ubound (dest, dest_index),
- gfc_conv_descriptor_ubound (src, src_index));
+ build2 (PLUS_EXPR, gfc_array_index_type,
+ gfc_index_one_node,
+ build2 (MINUS_EXPR, gfc_array_index_type,
+ gfc_conv_descriptor_ubound
+(src, src_index),
+ gfc_conv_descriptor_lbound
+(src, src_index;
if (!loop->to[n])
{
One last comment: I'm not sure the stride shouldn't be set to one. The patch
above regtests fine, and can compile correctly everything I threw at it, but
maybe I have not been clever enough to think of something that would trigger a
check on the stride.
Paul, could I have your opinion on the patch and the stride question? After you
comment, I'll go on designing patches for the other functions.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||paulthomas2 at wanadoo dot
||fr
Known to fail||4.2.0 4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug fortran/29216] Derived type components of function results are not initialised
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-10 07:56 --- Paul, I'm not sure, but I think PR29394 is related to that one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216
[Bug other/29405] GCC should include latest GMP/MPFR sources and always build libgmp.a/libmpfr.a
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-10 08:13 --- I'm very interested in that. I think it would really benefit the compiler: the Fortran front-end would gain much in stability (and ease of installation) and the C front-end could also benefit from this (as mentionned in PR29335). What's worrying me a bit is the versioning of MPFR. I'm writing it here because Vincent is in the Cc list of this bug, so maybe he can answer. The last MPFR release is dated 2005-09-09, and since then only patches without version information have been posted. That means we have no way to identify the MPFR library used exactly, to work around potential bugs or require fine-grained minimal version. Vincent, would it be possible that some version number is increased every time a patch is posted, so that the current version would be 2.2.16 or something like that? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29405
[Bug rtl-optimization/29323] [4.0/4.1/4.2 Regression] set_nothrow_function_flags does invalid analysis on weak functions
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-10-10 08:27 --- Subject: Bug 29323 Author: rguenth Date: Tue Oct 10 08:27:02 2006 New Revision: 117598 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117598 Log: 2006-10-10 Richard Guenther <[EMAIL PROTECTED]> PR rtl-optimization/29323 * except.c (set_nothrow_function_flags): For functions that do not bind local bail out early. * decl.c (finish_function): Set TREE_NOTHROW only for functions that bind local. Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/except.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29323
[Bug rtl-optimization/29323] [4.0/4.1 Regression] set_nothrow_function_flags does invalid analysis on weak functions
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-10 08:27 --- Fixed on the mainline. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] |set_nothrow_function_flags |set_nothrow_function_flags |does invalid analysis on|does invalid analysis on |weak functions |weak functions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29323
[Bug c++/29408] [4.1 regression] parse error for valid code
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-10 08:52 --- It's at least accepted by EDG and Comeau in strict-ansi mode. (so, confirmed) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-10 08:52:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29408
[Bug fortran/29410] New: [Optimization] bug with TRANSFER() and -O2
The following code: program chop integer ix, iy real x, y x = 1. y = x ix = transfer(x,ix) iy = transfer(y,iy) print '(2z20.8)', ix, iy if (ix /= iy) call abort end program chop when compiled with -O1 (or below) on PPC OSX 10.3, gives the correct result: 3F803F80 but when compiled with -O2 (or above) gives: 8FE15C3C8FE52E41 This bug does not show up on Linux AMD64, gfortran 4.2.0 20061009. Note 1, if I replace real x, y by real o, t, x, y or real o, t, td, x, y I get (with -O2) respectively: BFFFEFA08FE52E41 or 8FE52E41BFFFEFA0 Note 2, on OSX 10.4, gfortran 4.2.0 20060610, I get 2D44003006D0 TIA Dominique -- Summary: [Optimization] bug with TRANSFER() and -O2 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: 4.2.0 20061007 GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29410
[Bug c++/29236] [4.0/4.1/4.2 Regression] Bogus ambiguity with templates + friend
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Known to fail|3.2.3 3.3.5 3.4.6 4.0.1 |3.2.3 3.3.5 3.4.6 4.0.3 |4.1.1 4.2.0 3.0.4 |4.1.1 4.2.0 3.0.4 Summary|[4.0/4.1/4.2? regression] |[4.0/4.1/4.2 Regression] |Bogus ambiguity with|Bogus ambiguity with |templates + friend |templates + friend Target Milestone|4.2.0 |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29236
[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code
--- Comment #13 from jakub at gcc dot gnu dot org 2006-10-10 09:47 --- Subject: Bug 29272 Author: jakub Date: Tue Oct 10 09:46:59 2006 New Revision: 117599 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117599 Log: PR middle-end/29272 * builtins.c (var_decl_component_p): New function. (fold_builtin_memset, fold_builtin_memory_op): Restrict single entry optimization to variables and components thereof. * gcc.c-torture/execute/20060930-2.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20060930-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29272
[Bug fortran/29387] ICE on character array function of variable length
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-10 09:50 --- FX, There are two problems here; one is specific to LEN and the other is generic to intrinsics and array valued actual arguments: The LEN specific problem is that there is no need to call the function at all, in the particular case concerned. I did a simple modification to gfc_resolve_len, in which I copied the character-length expression from the actual argument to the the result, f. It worked fine; I do not have it here, so will post it on Thursday, when i am back at work. The generic problem is that of the conversion of array valued args., when there is no loop. The giveaway is that this works: PRINT *, PLEN(SUB(3)) CONTAINS FUNCTION SUB(I) CHARACTER(LEN=I) :: SUB(1) END FUNCTION integer function plen(arg) character(*) :: arg (:) plen = len (arg) end function plen END The difference is the way in which array arguments are handled. The intrinsics go straight for gfc_conv_expr_descriptor with nothing prepared. In consequence, the function is called with the observed consequences. What is needed is to build an ss and call gfc_conv_array_parameter, so that the function is called with loop and info built and a temporary presented to the intrinsic. I'll play with it this afternoon. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29387
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #26 from bkoz at gcc dot gnu dot org 2006-10-10 09:54 --- Ok. I think I'll put this in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug c++/29411] New: unique overload sets for extern "C" vs. C++ function pointers
>From comment #7 in 29095 we have:
The technical issue is that in the following code:
extern "C" {
typedef void (*p1)();
}
typedef void (*p2)();
p1 and p2 are distinct types, and, in fact, you can overload based on that.
G++ doesn't implement that distinction; we don't keep track of language linkage
for types (just for functions) but we should, and, at some point, I'm sure
we'll implement that. The reason this is in the standard is so that an
implementation can use different calling conventions for C and C++. So, when
calling through a function pointer you have to know which kind of function
you're calling. (And, yes, name-mangling is supposed to encode the linkage of
the function type, when mangling a pointer-to-function type.)
End of interesting comment.
This was news to me, and a quick perusal of "5.1 External Names (a.k.a.
Mangling)" in the IA64 C++ spec doesn't find any matches. However, I can see
why this might be useful, and am curious as to the behavior of pre-3.0.x GNU
compilers, as well as other ABI's (such as microsoft) or EDG in native mode.
--
Summary: unique overload sets for extern "C" vs. C++ function
pointers
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ABI
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29411
[Bug c++/29411] unique overload sets for extern "C" vs. C++ function pointers
--- Comment #1 from bkoz at gcc dot gnu dot org 2006-10-10 10:09 --- This would be an enhancement to both g++ and the IA64 C++ ABI. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29411
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #27 from bkoz at gcc dot gnu dot org 2006-10-10 10:14 --- Subject: Bug 29118 Author: bkoz Date: Tue Oct 10 10:14:13 2006 New Revision: 117600 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117600 Log: 2006-10-09 Benjamin Kosnik <[EMAIL PROTECTED]> PR libstdc++/29118 * src/locale_init.cc (__get_locale_mutex): New. (locale::locale): Use it. (locale::global): Use it. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/locale_init.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug objc/29412] New: gnustep-base build fails with gcc 3.4.x on HP-UX 11.23 (both ia64 and pa)
Recently I upgraded gcc from 3.3.2(really outdated!) to 3.4.6 on HPUX 11.23 June 2006 update. This build on both ia64 and pa-risc machines. This gcc is built on HPUX 11.23 by using the native ANSI C compiler. # what /opt/ansic/bin/cc /opt/ansic/bin/cc: HP aC++/C for Integrity Servers B3910B A.06.10 [Mar 22 2006] The configure options for gcc are #env PATH=$/usr/local/bin:/opt/OCEK/bin:$PATH CC="/opt/ansic/bin/cc" ../configure --prefix=/opt/OCEK --with-gnu-as --with-as=/opt/OCEK/bin/as --without-gnu-ld --enable-shared=yes --enable-static=yes --enable-threads=posix --enable-languages=c,c++,objc --enable-libstdcxx-v3 --enable-version-specific-runtime-libs #gmake bootstrap #gmake install The compilation is successful and the gcc binaries are available to me on both pa and ia64. But when I try to compile gnustep(versions 1.6.0/1.12.0/1.13.0)with this gcc it fails. The log is available below On PA-risc gmake[1]: Entering directory `/USERSPACE/ocek/gnustep-base/gnustep-base-1.6.0/Source' Making all in subprojects of library libgnustep-base... gmake[2]: Entering directory `/USERSPACE/ocek/gnustep-base/gnustep-base-1.6.0/Source/Additions' Making all for subproject Additions... Compiling file GSObjCRuntime.m ... GSObjCRuntime.m: In function `GSObjCFindVariable': GSObjCRuntime.m:73: warning: dereferencing type-punned pointer will break strict-aliasing rules GSObjCRuntime.m: At top level: GSObjCRuntime.m:636: error: conflicting types for '__objc_exec_class' GSObjCRuntime.m:300: error: previous declaration of '__objc_exec_class' was here gmake[3]: *** [shared_obj/hppa/hpux11.23/gnu-gnu-gnu/GSObjCRuntime.o] Error 1 gmake[2]: *** [Additions.all.subproject.variables] Error 2 gmake[2]: Leaving directory `/USERSPACE/ocek/gnustep-base/gnustep-base-1.6.0/Source/Additions' gmake[1]: *** [libgnustep-base.all.library.variables] Error 2 gmake[1]: Leaving directory `/USERSPACE/ocek/gnustep-base/gnustep-base-1.6.0/Source' gmake: *** [internal-all] Error 2 On HPUX 11.23 ia64 the build fails as follows Making all in subprojects of library libgnustep-base... gmake[2]: Entering directory `/USERSPACE/ocek/gnustep-base/gnustep-base-1.13.0/Source/Additions' Making all for subproject Additions... Compiling file GSCategories.m ... In file included from /usr/include/sys/stdpad.h:23, from /usr/include/sys/sigevent.h:45, from /opt/OCEK/lib/gcc/ia64-hp-hpux11.23/3.4.0/include/sys/time.h:37, from /usr/include/sys/resource.h:50, from /usr/include/sys/wait.h:100, from /opt/OCEK/lib/gcc/ia64-hp-hpux11.23/3.4.0/include/stdlib.h:399, from ../../Headers/Additions/GNUstepBase/preface.h:28, from ../../Headers/Foundation/NSObject.h:160, from ../../Headers/Foundation/NSDebug.h:31, from ../../Headers/Foundation/Foundation.h:32, from GSCategories.m:27: /usr/include/machine/sys/_types.h:65: error: parse error before "__fpreg" /usr/include/machine/sys/_types.h:69: error: parse error before '}' token In file included from /opt/OCEK/lib/gcc/ia64-hp-hpux11.23/3.4.0/include/sys/newsig.h:87, from /usr/include/sys/signal.h:43, from /usr/include/sys/wait.h:141, from /opt/OCEK/lib/gcc/ia64-hp-hpux11.23/3.4.0/include/stdlib.h:399, from ../../Headers/Additions/GNUstepBase/preface.h:28, from ../../Headers/Foundation/NSObject.h:160, from ../../Headers/Foundation/NSDebug.h:31, from ../../Headers/Foundation/Foundation.h:32, from GSCategories.m:27: /usr/include/machine/sys/newsig.h:47: error: parse error before "__opaque128_t" /usr/include/machine/sys/newsig.h:52: error: parse error before "mcontext_t" /usr/include/machine/sys/newsig.h:145: error: parse error before "mcontext_t" In file included from /usr/include/machine/sys/signal.h:59, from /usr/include/sys/signal.h:547, from /usr/include/sys/wait.h:141, from /opt/OCEK/lib/gcc/ia64-hp-hpux11.23/3.4.0/include/stdlib.h:399, from ../../Headers/Additions/GNUstepBase/preface.h:28, from ../../Headers/Foundation/NSObject.h:160, from ../../Headers/Foundation/NSDebug.h:31, from ../../Headers/Foundation/Foundation.h:32, from GSCategories.m:27: /usr/include/machine/sys/sigcontext.h:43: error: field `__uc' has incomplete type In file included from ../../Headers/Additions/GNUstepBase/preface.h:28, from ../../Headers/Foundation/NSObject.h:160, from ../../Headers/Foundation/NSDebug.h:31, from ../../Headers/Foundation/Foundation.h:32, from GSCategories.m:27: /opt/OCEK/lib/gcc/ia64-hp-hpux11.23/3.4.0/include/stdlib.h:573: error: parse error before "int" /opt/OCEK/lib/gcc/ia64-hp-hpux11.23/3.4.0/include/stdlib.h:574: error: parse error before "int" /opt/OCEK/lib/gcc/ia64-hp-hpux11.23/3.4.0/include/stdlib.h:614: error: parse error before "int" /opt/OCEK/lib/gcc/ia64-hp-hpux11.23/3.4.0/include/stdlib.h:615: error: parse error before "int" In file included from ../../Headers/Foundation/Foundation.h:39, from GSCategories.m:27: ../../Headers/Foundation/NSBundle.h:578:1: warning: "__" redefined In file included from /opt/OCEK/lib/gcc/ia64-hp-hpux11.23/3.4.0/include/string.h:15, from GSCategories.m:26: /opt/OCEK/lib/gcc
[Bug tree-optimization/19097] [4.1/4.2 regression] Quadratic behavior with many sets for the same register in VRP
--- Comment #41 from rguenth at gcc dot gnu dot org 2006-10-10 11:19 --- We're still 100% slower than 4.0.3 on the mainline: Execution times (seconds) callgraph construction: 0.21 ( 0%) usr 0.03 ( 2%) sys 0.23 ( 0%) wall 11563 kB (13%) ggc callgraph optimization: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 937 kB ( 1%) ggc ipa reference : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc ipa type escape : 0.03 ( 0%) usr 0.02 ( 1%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc cfg cleanup : 0.57 ( 1%) usr 0.02 ( 1%) sys 0.62 ( 1%) wall 1250 kB ( 1%) ggc trivially dead code : 0.10 ( 0%) usr 0.00 ( 0%) sys 0.11 ( 0%) wall 0 kB ( 0%) ggc life analysis : 0.33 ( 0%) usr 0.01 ( 1%) sys 0.35 ( 0%) wall 1250 kB ( 1%) ggc life info update : 0.13 ( 0%) usr 0.00 ( 0%) sys 0.14 ( 0%) wall 0 kB ( 0%) ggc alias analysis: 0.21 ( 0%) usr 0.00 ( 0%) sys 0.16 ( 0%) wall 1 kB ( 0%) ggc register scan : 0.09 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 0 kB ( 0%) ggc rebuild jump labels : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc preprocessing : 0.11 ( 0%) usr 0.03 ( 2%) sys 0.14 ( 0%) wall 704 kB ( 1%) ggc lexical analysis : 0.07 ( 0%) usr 0.21 (12%) sys 0.20 ( 0%) wall 0 kB ( 0%) ggc parser: 0.09 ( 0%) usr 0.06 ( 3%) sys 0.23 ( 0%) wall 5224 kB ( 6%) ggc integration : 0.08 ( 0%) usr 0.01 ( 1%) sys 0.08 ( 0%) wall 0 kB ( 0%) ggc tree gimplify : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 625 kB ( 1%) ggc tree eh : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc tree CFG construction : 0.12 ( 0%) usr 0.03 ( 2%) sys 0.15 ( 0%) wall 14606 kB (16%) ggc tree CFG cleanup : 0.67 ( 1%) usr 0.01 ( 1%) sys 0.65 ( 1%) wall 0 kB ( 0%) ggc tree VRP : 40.92 (46%) usr 0.24 (13%) sys 41.26 (46%) wall 10356 kB (11%) ggc tree copy propagation : 0.09 ( 0%) usr 0.00 ( 0%) sys 0.09 ( 0%) wall 0 kB ( 0%) ggc tree store copy prop : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc tree find ref. vars : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree PTA : 0.09 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 6 kB ( 0%) ggc tree alias analysis : 0.14 ( 0%) usr 0.10 ( 6%) sys 0.21 ( 0%) wall 0 kB ( 0%) ggc tree SSA rewrite : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 0 kB ( 0%) ggc tree SSA other: 0.02 ( 0%) usr 0.01 ( 1%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc tree SSA incremental : 0.07 ( 0%) usr 0.01 ( 1%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc tree operand scan : 0.29 ( 0%) usr 0.17 ( 9%) sys 0.35 ( 0%) wall 2306 kB ( 3%) ggc dominator optimization: 0.47 ( 1%) usr 0.01 ( 1%) sys 0.52 ( 1%) wall 7031 kB ( 8%) ggc tree STORE-CCP: 0.05 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc tree CCP : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc tree PHI const/copy prop: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc tree reassociation: 0.05 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall 0 kB ( 0%) ggc tree PRE : 0.09 ( 0%) usr 0.01 ( 1%) sys 0.10 ( 0%) wall 0 kB ( 0%) ggc tree FRE : 0.05 ( 0%) usr 0.01 ( 1%) sys 0.07 ( 0%) wall 0 kB ( 0%) ggc tree code sinking : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc tree linearize phis : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc tree forward propagate: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree conservative DCE : 0.09 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 0 kB ( 0%) ggc tree aggressive DCE : 0.08 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 0 kB ( 0%) ggc tree DSE : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall 0 kB ( 0%) ggc PHI merge : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree loop init: 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc tree copy headers : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc tree SSA uncprop : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc tree SSA to normal: 0.05 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc tree rename SSA copies: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc dominance frontiers : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc dominance computation : 0.48
[Bug tree-optimization/23346] [4.1/4.2 Regression] FRE before DCE makes a mess of loads or need to sink loads
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-10-10 11:58
---
On mainline we now have
f:
xorl%eax, %eax
movla, %edx
cmpl$0, 4(%esp)
movlb, %ecx
jne .L4
movl%edx, %eax
sarl$31, %edx
idivl %ecx
.L4:
rep ; ret
which still loads a and b unconditionally, but it looks less "messy". 4.1.1
is the mess as in comment #1.
We end up with
f (bool1)
{
int c1;
int c;
int b.1;
int a.0;
:
# VUSE ;
a.0_3 = a;
# VUSE ;
b.1_5 = b;
if (bool1_7 != 0) goto ; else goto ;
:;
c1_6 = a.0_3 / b.1_5;
# c_1 = PHI <0(2), c1_6(3)>;
:;
return c_1;
}
where the best thing would be to sink the loads to the single-use a.0_3 and
b.1_5 into the conditional BB. It looks like TER has code to deal with this
case and could replace a.0_3 and b.1_5 with a and b, but this doesn't happen.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||amacleod at redhat dot com
Last reconfirmed|2006-07-05 09:35:27 |2006-10-10 11:58:07
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23346
[Bug fortran/29407] namelist: overriding the host association does not work (rejects valid code)
--- Comment #1 from pault at gcc dot gnu dot org 2006-10-10 12:40 --- Created an attachment (id=12402) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12402&action=view) Fix for this PR Regtested on FC5/Athlon Will submit asap. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29407
[Bug fortran/29373] implicit type declaration and contained function clash
--- Comment #4 from pault at gcc dot gnu dot org 2006-10-10 12:41 --- Created an attachment (id=12403) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12403&action=view) Fix for the problem Regtested on FC5/Athlon Will submit asap. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29373
[Bug fortran/29373] implicit type declaration and contained function clash
--- Comment #5 from pault at gcc dot gnu dot org 2006-10-10 12:47 --- (In reply to comment #4) > Created an attachment (id=12403) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12403&action=view) [edit] > Fix for the problem Sorry, I should have said that this gets rid of the TWO problems that prevent this from responding in the same way as removing the IMPLICIT NONE: pr29373.f90:8: fatal error: gfc_todo: Not Implemented: complex character array constructors compilation terminated. I will submit asap and will submit a new PR for this latter. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29373
[Bug fortran/29216] Derived type components of function results are not initialised
--- Comment #4 from pault at gcc dot gnu dot org 2006-10-10 12:48 --- (In reply to comment #3) > Paul, > > I'm not sure, but I think PR29394 is related to that one. > Yes, I already verified that yesterday but forgot to make a note of it. I'm just gearing up to an afternoon of gfortran submits - I am doing garde-enfant duty. Thanks Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216
[Bug other/29405] GCC should include latest GMP/MPFR sources and always build libgmp.a/libmpfr.a
--- Comment #3 from vincent at vinc17 dot org 2006-10-10 13:53 --- (In reply to comment #2) > What's worrying me a bit is the versioning of MPFR. Note that GMP is similar. > Vincent, would it be possible that some version number is increased every > time a patch is posted, so that the current version would be 2.2.16 or > something like that? There has been a very short discussion about that last year: http://sympa.loria.fr/wwsympa/arc/mpfr/2005-12/msg00049.html The problem is that it is not that simple. First, for some reasons, not all patches committed to the 2.2 branch are put on the 2.2.0 web page, so that the future 2.2.1 version will not just be 2.2.0 + the patches provided on the web page. We could provide another way to identify the patches, but as said in the cited URL, this could be done only as of MPFR 2.3.0 (possibly except if one decides just to add a macro to mpfr.h for this purpose). The main problem is that one may want to apply some patches, but not others, or identify builds from the Subversion repository... For instance, the macro could contain a group of tags (e.g. the name of the patches and possibly some other information). But how would this macro be used by gcc and other software? Would a group of tags be useful, or too complex? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29405
[Bug target/25519] [4.0/4.1/4.2 Regression] Intel (SSE/MMX) intrinsics should only be mentioned instead of the builtins
--- Comment #5 from patchapp at dberlin dot org 2006-10-10 13:55 --- Subject: Bug number PR25519 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/2006-10/msg00542.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25519
[Bug tree-optimization/23346] [4.1/4.2 Regression] FRE before DCE makes a mess of loads or need to sink loads
--- Comment #14 from amacleod at redhat dot com 2006-10-10 14:03 --- TER acts only within a basic block, and that will probably not change. Its primary function is simply to mash trees back together so the expander gets a better look. This is more likely to handled by the RABLET work eventually... Either by the register pressure reduction code, or the merge with expand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23346
[Bug target/27440] [4.0/4.1/4.2 regression] code quality regression due to ivopts
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-10-10 14:06 --- Confirmed (as in comment #1). With -Os instead of -O2 we even produce .L3: movl%ebx, -4(%edx) incl%eax .L2: addl$4, %edx cmpl%ecx, %eax jb .L3 (because loop header copying is disabled there). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||3.4.6 Last reconfirmed|-00-00 00:00:00 |2006-10-10 14:06:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27440
[Bug c/29413] New: -EB / -EL don't properly affect gcc predefined symbols
$ mips-linux-gcc -EL -dM -E -C -x c /dev/null | grep MIPSE #define MIPSEB 1 #define __MIPSEB__ 1 #define _MIPSEB 1 #define __MIPSEB 1 $ mipsel-linux-gcc -EB -dM -E -C -x c /dev/null | grep MIPSE #define __MIPSEL__ 1 #define MIPSEL 1 #define _MIPSEL 1 #define __MIPSEL 1 $ mips64el-linux-gcc -EB -dM -E -C -x c /dev/null | grep MIPSE #define __MIPSEL__ 1 #define MIPSEL 1 #define _MIPSEL 1 #define __MIPSEL 1 $ mips64-linux-gcc -EL -dM -E -C -x c /dev/null | grep MIPSE #define MIPSEB 1 #define __MIPSEB__ 1 #define _MIPSEB 1 #define __MIPSEB 1 $ Tested with gcc 4.1.0 but given the (incomplete) hacks the Linux/MIPS kernel has for this I would assume it is broken since a very, very long time. -- Summary: -EB / -EL don't properly affect gcc predefined symbols Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ralf at linux-mips dot org GCC target triplet: mips*-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29413
[Bug c++/29008] Fails to accept templated constructor
--- Comment #4 from igodard at pacbell dot net 2006-10-10 14:17 --- Yes, there IS something you can do about it. The compiler already checks whether a template is resolved by its data arguments (the message is something like "nothing of foo depends on any template argument and so ..."), so this construction can be and should be diagnosed at point of declaration of the constructor. Please reopen and change to a diagnostic issue. If for some reason the error cannot be diagnosed at the constructor, then fix the existing error messoge to something just a *bit* more enlightening :-) Ivan -- igodard at pacbell dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29008
[Bug c++/29236] [4.0/4.1/4.2 Regression] Bogus ambiguity with templates + friend
--- Comment #6 from bangerth at dealii dot org 2006-10-10 14:25 --- (In reply to comment #5) > foo should not have been injected by the friend. True, but that's irrelevant here. We get a tentative declaration that we simply have to unify with the later real declaration. > Note the Priority should be only changed by the release manager. We've been over that before, Andrew. It has always been the case that bugmasters do the initial triage, including setting an initial priority. We've done that at least back to 2002, when we were still using GNATS instead of bugzilla. It is also true that the RM has the prerogative to downgrade priorities if he doesn't deem things that important. I maintain that it is important to raise the priority of PRs that are rejects-valid so that they get some visibility, and in particular of regressions. If someone higher up in the food chain thinks otherwise wants to downgrade things, that's fine by me. But it's not productive if bugmasters quarrel among themselves if something should be a P2 or a P3 ... W. -- bangerth at dealii dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29236
[Bug tree-optimization/28230] [4.2 Regression] -O2 -fwrapv miscompiles gcc, binutils, gzip.
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-10-10 14:32
---
No, it's extract_range_from_binary_expr operating on [0, +INF] + [0, 65535] and
blindly using int_const_binop to compute the resulting range...
I believe the following is completely bogus and we cannot ignore overflows
in range arithmetic for wrapv either.
static inline tree
vrp_int_const_binop (enum tree_code code, tree val1, tree val2)
{
tree res;
if (flag_wrapv)
return int_const_binop (code, val1, val2, 0);
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2006-09-21 03:31:17 |2006-10-10 14:32:50
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
[Bug target/27440] [4.0/4.1/4.2 regression] code quality regression due to ivopts
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-10 14:06:28 |2006-10-10 14:36:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27440
[Bug java/29414] New: Issues building GNU java on Solaris2.10 X64
Issues building GNU java on Solaris2.10 X64: Configured to use: GNU as, SUN linker, pthreads, java-awt=xlib * SUN's /bin/sh is broken... set CONFIGURE_SHELL to /bin/ksh or /bin/bash * SUN tools like sed, grep, tar, find are also deficit. Use GNU tools. * the java build requires a version of jar with GNU extensions. If SUN java is in the search patch, the SUN jar utility will be selected, which causes the build to fail. Since fastjar is built as part of the java build, it should be used by default. * The version of boehm-gc shipped with 4.1.1 does not build. * The version of boehm-gc shipped with the latest gcc-4.2.x SVN code [9oct06] builds but does not test. * the current boehm-gc CVS code [bdwgc.cvs.sourceforge.net] builds and tests. -Joseph -- Summary: Issues building GNU java on Solaris2.10 X64 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsacco at ydl dot net GCC build triplet: i386-pc-solaris2.10 GCC host triplet: i386-pc-solaris2.10 GCC target triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29414
[Bug target/27440] [4.0/4.1/4.2 regression] code quality regression due to ivopts
--- Comment #7 from uros at kss-loka dot si 2006-10-10 14:48 --- (In reply to comment #6) > Confirmed (as in comment #1). With -Os instead of -O2 we even produce > > .L3: > movl%ebx, -4(%edx) The -4(...) part comes from PR 24669. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27440
[Bug middle-end/29390] Bogus symbol inserted into valid C++ code at low optimization level
--- Comment #10 from mi at aldan dot algebra dot com 2006-10-10 14:52 --- (In reply to comment #9) > finding the relevant patch using a binary search of the subversion archive > between the revision numbers of the 3.4 branchpoint and the 4.0 release That's the problem -- how can I, who has never seen the internals of the GNU compiler, figure out, which patch is "the relevant" one? For you, the developers, it is, probably, indeed faster, than writing another explanation, why you "have no resources" to do it... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29390
[Bug middle-end/29390] Bogus symbol inserted into valid C++ code at low optimization level
--- Comment #11 from bangerth at dealii dot org 2006-10-10 14:56 --- (In reply to comment #10) > For you, the developers, it is, probably, indeed faster, than writing another > explanation, why you "have no resources" to do it... No, it will actually take significant time, since one has to do lots of bootstraps. We as a group decided that our time would be better spent on maintaining 2 release branches + one development mainline. But that aside, it's just a matter of fact that very few of us actually have FreeBSD systems we could try this on. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29390
[Bug middle-end/29390] Bogus symbol inserted into valid C++ code at low optimization level
--- Comment #12 from mi at aldan dot algebra dot com 2006-10-10 15:13 --- In comment #9: shouldn't be too hard. In comment #11: No, it will actually take significant time If the explanation for the above discrepancy is simply not having access to a FreeBSD machine, such an access can be arranged in an hour or so. Just send me (by private e-mail) your ssh public key (~/.ssh/id_dsa.pub) and the /etc/passwd line for your account information (without the actual password). Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29390
[Bug middle-end/29390] Bogus symbol inserted into valid C++ code at low optimization level
--- Comment #13 from bangerth at dealii dot org 2006-10-10 15:18 --- (In reply to comment #12) > In comment #9: shouldn't be too hard. > In comment #11: No, it will actually take significant time It's a long and boring process. It's not complicated, it just takes time. > If the explanation for the above discrepancy is simply not having access to a > FreeBSD machine, such an access can be arranged in an hour or so. No, you don't understand. I have no intention of doing this. I believe my time is better spent working on bugs that haven't been fixed on any current release branch yet. I have no interest in working on things that have been sorted out long ago. If you really want to see this fixed, you will have to find a volunteer who is willing to spend the necessary time and who has access to the relevant machines. That's just not me, sorry. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29390
[Bug tree-optimization/29415] New: [4.2] bad code reordering around inline asm block
Using gcc 4.2 snapshot 20061007 on x86, the compiler is miscompiling glibc 2.5
(see http://sourceware.org/bugzilla/show_bug.cgi?id=3328)
What is happening is that a test of a variable after an inline asm block is
moved around so that the load of the struct member is moved above the asm block
even though it should not do that.
The miscompilation only seems to appear in that particular constellation, all
tries to reproduce the problem using a simpler hand-made test case have failed.
So I've attached the whole preprocessed source file.
Compiler simply called with "gcc -O2 -o test.o -c pthread_mutex_lock.c".
The problem appears in the function __pthread_mutex_lock. There's a switch
statement with some common stuff in the different cases which the compiler
seems to optimize. The case in question (the most common one):
switch (__builtin_expect (mutex->__data.__kind, PTHREAD_MUTEX_TIMED_NP)) {
...
case PTHREAD_MUTEX_TIMED_NP:
simple:
/* Normal mutex. */
LLL_MUTEX_LOCK (mutex->__data.__lock);
assert (mutex->__data.__owner == 0);
break;
...
}
The LLL_MUTEX_LOCK is a macro with an inline assembler statement (cmpxchg and a
conditional jump to another section) that is annotated to tell the compiler
that it clobbers memory, so gcc should never move loads around the inline asm
block. But in this case the load from mutex->__data.__owner (for the assertion)
is executed above LLL_MUTEX_LOCK and the register content is tested below
LLL_MUTEX_LOCK. The content will have changed, but the old value in the
register is wrong and the assertion triggers.
The broken generated code looks like (note that the jump to <_L_mutex_lock_78>
is just an out-of-line call to another function that can wait for some time,
modify the mutex->__data.__owner = 0x8(%ebx) here, and then jump back):
loading mutex->__data.__owner (into %edx):
2f: 8b 53 08mov0x8(%ebx),%edx
lll_mutex_lock:
32: 31 c0 xor%eax,%eax
34: b9 01 00 00 00 mov$0x1,%ecx
39: f0 0f b1 0b lock cmpxchg %ecx,(%ebx)
3d: 0f 85 f3 05 00 00 jne636 <_L_mutex_lock_78>
testing mutex->__data.__owner (%edx from above!):
43: 85 d2 test %edx,%edx
45: 0f 85 7f 04 00 00 jne4ca <__pthread_mutex_lock+0x4ca>
-> __assert_fail
In constrast, gcc 4.1.1 generated the following correct piece of code:
acquiring mutex (lll_mutex_lock):
3d: 31 c0 xor%eax,%eax
3f: b9 01 00 00 00 mov$0x1,%ecx
44: f0 0f b1 0b lock cmpxchg %ecx,(%ebx)
48: 0f 85 ed 05 00 00 jne63b <_L_mutex_lock_86>
loading and testing owner:
4e: 8b 43 08mov0x8(%ebx),%eax
51: 85 c0 test %eax,%eax
53: 0f 85 71 05 00 00 jne5ca <__pthread_mutex_lock+0x5ca>
-> __assert_fail
--
Summary: [4.2] bad code reordering around inline asm block
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christophe at saout dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug tree-optimization/29415] [4.2] bad code reordering around inline asm block
--- Comment #1 from christophe at saout dot de 2006-10-10 15:40 --- Created an attachment (id=12404) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12404&action=view) preprocessed pthread_mutex_lock.c causing the miscompiled code Call with "gcc -O2 -o test.o -c pthread_mutex_lock.c" on i686 and look at the beginning of the generated __pthread_mutex_lock function, around the first cmpxchg call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug c++/29417] New: link fails with debug and anonymous namespace
This is with:
gcc (GCC) 4.2.0 20061007 (experimental)
On x86 Debian and under Fedora Core 3.
Using the lamba part of the boost library, the following is seen:
/tmp/ccNdhcXx.o:(.debug_info+0xec9): undefined reference to
`boost::lambda::(anonymous namespace)::free2'
/tmp/ccNdhcXx.o:(.debug_info+0xed8): undefined reference to
`boost::lambda::(anonymous namespace)::free3'
/tmp/ccNdhcXx.o:(.debug_info+0x47f2): undefined reference to
`boost::lambda::(anonymous namespace)::free2'
/tmp/ccNdhcXx.o:(.debug_info+0x4806): undefined reference to
`boost::lambda::(anonymous namespace)::free3'
I don't think the fault is in the boost library. Here is the code in question:
namespace {
// These are constants types and need to be initialised
boost::lambda::placeholder1_type free1 = boost::lambda::placeholder1_type();
boost::lambda::placeholder2_type free2 = boost::lambda::placeholder2_type();
boost::lambda::placeholder3_type free3 = boost::lambda::placeholder3_type();
boost::lambda::placeholder1_type& _1 = free1;
boost::lambda::placeholder2_type& _2 = free2;
boost::lambda::placeholder3_type& _3 = free3;
// _1, _2, ... naming scheme by Peter Dimov
} // unnamed
To trigger the problem requires at least -O and -g2. My C++ isn't good enough
to comment further. I attach a minimal preprocessed case. compile with:
g++-4.2 test.ii -O -g2
This works correctly on previous GCC versions, and with -g1.
--
Summary: link fails with debug and anonymous namespace
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peter at chocky dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29417
[Bug c++/29417] link fails with debug and anonymous namespace
--- Comment #1 from peter at chocky dot org 2006-10-10 16:17 --- Created an attachment (id=12405) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12405&action=view) minimal test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29417
[Bug c++/29236] [4.0/4.1/4.2 Regression] Bogus ambiguity with templates + friend
--- Comment #7 from mark at codesourcery dot com 2006-10-10 16:23 --- Subject: Re: [4.0/4.1/4.2 Regression] Bogus ambiguity with templates + friend bangerth at dealii dot org wrote: > We've been over that before, Andrew. It has always been the case that > bugmasters do the initial triage, including setting an initial priority. > We've done that at least back to 2002, when we were still using GNATS instead > of bugzilla. It is also true that the RM has the prerogative to downgrade > priorities if he doesn't deem things that important. I have asked that all bugs be left at P3, and that I set their initial priority. I also welcome input about what the priority should be, ideally in the audit trail for the PR itself. But, looking at P3 bugs is how I see what the new bugs are. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29236
[Bug target/29409] Avr-gcc 4.1.1 build fails
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-10 16:27 --- Already fixed for 4.1.2. *** This bug has been marked as a duplicate of 26504 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29409
[Bug target/26504] [4.1/4.2 Regression] compute_frame_pointer_to_cfa_displacement error for avr target with --with-dwarf2
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-10-10 16:27 --- *** Bug 29409 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rumjantsev at papillon dot ||ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26504
[Bug c++/29408] [4.1 regression] parse error for valid code
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-10 16:30 --- (In reply to comment #3) > It's at least accepted by EDG and Comeau in strict-ansi mode. (so, confirmed) Don't take EDG/Comeau as conforming to the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29408
[Bug c++/2316] g++ fails to overload on language linkage
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-10-10 16:33 --- *** Bug 29411 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bkoz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
[Bug c++/29411] unique overload sets for extern "C" vs. C++ function pointers
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-10 16:33 --- This is really a dup of bug 2316. I forgot to mention that in PR 29095. Oh and this is not an enhancement because you can have wrong code and also rejects valid testcases see the dup bug report about those cases. *** This bug has been marked as a duplicate of 2316 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29411
[Bug objc/29412] gnustep-base build fails with gcc 3.4.x on HP-UX 11.23 (both ia64 and pa)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-10 16:35 --- Why do you think this is a GCC bug and not a GNUStep bug? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|gnustep-base build fails|gnustep-base build fails |with gcc 3.4.x on HP-UX |with gcc 3.4.x on HP-UX |11.23 (both ia64 and pa)|11.23 (both ia64 and pa) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29412
[Bug c++/29008] Fails to accept templated constructor
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29008
[Bug tree-optimization/29415] [4.2] bad code reordering around inline asm block
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-10 16:46 --- __asm __volatile ( "call *_dl_sysinfo\n\t" : "=a" (__status) : "0" (240), "b" (&mutex->__data.__lock), "S" (0), "c" (0), "d" (_val), "i" (__builtin_offsetof (tcbhead_t, sysinfo)) : "memory"); I think what you are doing here is invalid, you cannot change the control flow via an inline-asm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug c++/29417] [4.2 Regression] link fails with debug and anonymous namespace
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |critical Keywords||link-failure Summary|link fails with debug and |[4.2 Regression] link fails |anonymous namespace |with debug and anonymous ||namespace Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29417
[Bug libgcj/29205] lib/pkgconfig/libgcj.pc needs to become version dependent
--- Comment #3 from tromey at gcc dot gnu dot org 2006-10-10 17:19 --- Testing a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-02 17:51:47 |2006-10-10 17:19:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29205
[Bug c++/29408] [4.1 regression] parse error for valid code
--- Comment #5 from debian-gcc at lists dot debian dot org 2006-10-10 18:04 --- 20060928 works Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29408
[Bug c++/29408] [4.1 regression] parse error for valid code
--- Comment #6 from debian-gcc at lists dot debian dot org 2006-10-10 18:25 --- r117410 is the first version showing the failure. r117410 | mmitchel | 2006-10-03 20:06:00 +0200 (Di, 03 Okt 2006) | 12 lines PR c++/29138 * decl2.c (grokfield): Don't handle access declarations here. * parser.c (cp_parser_using_declaration): Handle access declarations too. (cp_parser_block_declaration): Adjust calls to cp_parser_using_declaration. (cp_parser_member_declaration): Likewise. Use cp_parser_using_declaration to look for access_declarations. PR c++/29138 * g++.dg/inherit/access8.C: New test. * g++.dg/template/dtor4.C: Tweak error messages. -- debian-gcc at lists dot debian dot org changed: What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29408
[Bug libgcj/29205] lib/pkgconfig/libgcj.pc needs to become version dependent
--- Comment #4 from tromey at gcc dot gnu dot org 2006-10-10 18:44 --- Subject: Bug 29205 Author: tromey Date: Tue Oct 10 18:44:06 2006 New Revision: 117610 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117610 Log: PR libgcj/29205: * Makefile.in: Rebuilt. * Makefile.am (install-data-local): Install the .pc file. (pkgconfig_DATA): Removed. Modified: trunk/libjava/ChangeLog trunk/libjava/Makefile.am trunk/libjava/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29205
[Bug libgcj/29205] lib/pkgconfig/libgcj.pc needs to become version dependent
--- Comment #5 from tromey at gcc dot gnu dot org 2006-10-10 18:45 --- I've checked in the fix on the trunk. Do we need this in 4.1? I assume not on the theory that now the file names won't clash... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29205
[Bug tree-optimization/29415] [4.2] bad code reordering around inline asm block
--- Comment #3 from jakub at gcc dot gnu dot org 2006-10-10 18:55 --- No, that's perfectly valid, you can't jump out of an asm or jump into it, but if you enter the asm and exit it, it doesn't matter what branches or calls were used inside it (of course if the function you call inside it is written in C you need to add used attribute to it to make sure it is not optimized out if it is not otherwise referenced). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug xml/29362] NullPointerException in gnu.xml.transform.TransformerImpl.strip(libgcj.so.7rh)
--- Comment #6 from tromey at gcc dot gnu dot org 2006-10-10 19:32 --- Subject: Bug 29362 Author: tromey Date: Tue Oct 10 19:31:56 2006 New Revision: 117612 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117612 Log: PR classpath/29362: * gnu/xml/transform/TransformerImpl.java (transform): Only strip if there is a stylesheet. Modified: trunk/libjava/classpath/ChangeLog.gcj trunk/libjava/classpath/gnu/xml/transform/TransformerImpl.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
[Bug xml/29362] NullPointerException in gnu.xml.transform.TransformerImpl.strip(libgcj.so.7rh)
--- Comment #7 from jjohnstn at redhat dot com 2006-10-10 19:35 --- I am confirming that the patch does fix the problem. With patch, the original Eclipse CDT problems have gone away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
--- Comment #3 from pault at gcc dot gnu dot org 2006-10-10 19:36 --- (In reply to comment #2) > One last comment: I'm not sure the stride shouldn't be set to one. The patch > above regtests fine, and can compile correctly everything I threw at it, but > maybe I have not been clever enough to think of something that would trigger a > check on the stride. Sorry, which stride? The inversion of the strides is what allows MATMUL to do neat thing with a*.b - I think that it's a horrible kludge but there we are. It is more efficient and I nearly bust myself getting MATMUL right! > > Paul, could I have your opinion on the patch and the stride question? After > you > comment, I'll go on designing patches for the other functions. Don't nest the build2's like that - use a temporary; you might find that fold_build2 gives a better account of itself for index calculations; cf the discussion on the list about the loop reverser for the scalarizer. Ar you sure that this renormalization of the bounds is required? After all: (i) indices should always be realtive to lbound, whatever it is; and (ii) why would anybody be interested to do this? After all, the temporary could be assigned to a variable with any lbound at all. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug xml/29362] NullPointerException in gnu.xml.transform.TransformerImpl.strip(libgcj.so.7rh)
--- Comment #8 from tromey at gcc dot gnu dot org 2006-10-10 19:38 --- Subject: Bug 29362 Author: tromey Date: Tue Oct 10 19:37:52 2006 New Revision: 117613 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117613 Log: PR classpath/29362: * gnu/xml/transform/TransformerImpl.java (transform): Only strip if there is a stylesheet. Modified: branches/redhat/gcc-4_1-branch/libjava/classpath/ChangeLog.gcj branches/redhat/gcc-4_1-branch/libjava/classpath/gnu/xml/transform/TransformerImpl.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
[Bug xml/29362] NullPointerException in gnu.xml.transform.TransformerImpl.strip(libgcj.so.7rh)
--- Comment #9 from tromey at gcc dot gnu dot org 2006-10-10 19:39 --- I checked this in. I'd still appreciate a review from Chris though. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |0.93 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
[Bug target/29421] New: gcc.dg/tree-ssa/ivopts-2.c scan-tree-dump-not \n candidates .*,.*,.*\n[^\n]*\nFinal cost fails
FAIL: gcc.dg/tree-ssa/ivopts-2.c scan-tree-dump-not \n candidates .*,.*,.*\n[^\n]*\nFinal cost appeared on mainline between 20060924 and 20060925 on hppa64-hp-hpux11.11 (this is a new test assertion so probably not a regression). -- Summary: gcc.dg/tree-ssa/ivopts-2.c scan-tree-dump-not \n candidates .*,.*,.*\n[^\n]*\nFinal cost fails Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org GCC target triplet: hppa64-*-hpux* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29421
[Bug c++/2316] g++ fails to overload on language linkage
--- Comment #12 from bkoz at gcc dot gnu dot org 2006-10-10 20:07 --- adding ABI keyword as implementing this may change mangling for "C" functions. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Keywords||ABI http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
[Bug fortran/29216] Derived type components of function results are not initialised
--- Comment #5 from pault at gcc dot gnu dot org 2006-10-10 20:49 --- Created an attachment (id=12406) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12406&action=view) A development of the previous patch (ie. it works!). This now regtests, apart from alloc_comp_basics_1.f90, which is upset by further allocates and deallocates - it runs but its accounting is thrown. As FX mentions, this patch can also fix PR29394 and others of its ilk. It is also a model for default initialization of all variables that are not otherwise initialized. For this reason, I am going to sit on this for a little while yet, so that I can develop these features. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Attachment #12397|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216
[Bug java/29150] [win32] java.library.path broken
--- Comment #2 from mtrudel at gmx dot ch 2006-10-10 21:20 --- Fixed... The path separator was set to ":" on all platforms instead of ";" for windows. -- mtrudel at gmx dot ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29150
[Bug fortran/29422] New: ICE with allocatable
The following code (derived from allocatable_1.f90) Type drv Integer::i Integer,allocatable::arr(:) End type drv print *, fun1() contains Function fun1 () Type(drv)::fun1 Fun1%i=10 end function fun1 end gives allocatable_1_db.f90: In function MAIN__: allocatable_1_db.f90:12: 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. Cheers Dominique -- Summary: ICE with allocatable Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: 4.2.0 20061009 GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29422
[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-10 22:04 --- (In reply to comment #3) > Are you sure that this renormalization of the bounds is required? After all: > (i) indices should always be realtive to lbound, whatever it is; and > (ii) why would anybody be interested to do this? After all, the temporary > could be assigned to a variable with any lbound at all. I'm not sure I understand. The following code: INTEGER :: I(-1:1,-1:1)=0 WRITE(6,*) LBOUND(I) WRITE(6,*) LBOUND(I(:,:)) WRITE(6,*) LBOUND(TRANSPOSE(I)) END ought to output -1 -1 1 1 1 1 and not like we currently do: -1 -1 1 1 -1 -1 That's because of F95 13.14.53: Case (i): For an array section or for an array expression other than a whole array or array structure component, LBOUND(ARRAY, DIM) has the value 1. For a whole array or array structure component, LBOUND(ARRAY, DIM) has the value: (a) equal to the lower bound for subscript DIM of ARRAY if dimension DIM of ARRAY does not have extent zero or if ARRAY is an assumed-size array of rank DIM, or (b) 1 otherwise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug target/26504] [4.1/4.2 Regression] compute_frame_pointer_to_cfa_displacement error for avr target with --with-dwarf2
--- Comment #18 from aesok at gcc dot gnu dot org 2006-10-10 22:18 ---
Subject: Bug 26504
Author: aesok
Date: Tue Oct 10 22:18:06 2006
New Revision: 117616
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117616
Log:
* config/avr/predicates.md: New file.
* config/avr/avr.md: Include it.
(REG_SP): New constant.
(peepholes): Use predicates.
(sbrx_branch, sbrx_and_branchhi, sbrx_and_branchsi, branch, rvbranch,
difficult_branch, difficult_rvbranch, cbi, sbi, sbix_branch,
sbix_branch_bit7, sbix_branch_tmp, sbix_branch_tmp_bit7): Ditto.
PR target/26504
* config/avr/avr.h (FRAME_POINTER_CFA_OFFSET): Define.
Added:
trunk/gcc/config/avr/predicates.md (with props)
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.md
Propchange: trunk/gcc/config/avr/predicates.md
('svn:executable' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26504
[Bug libfortran/29423] New: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 and intrinsic_spacing.f90
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran -B /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../ /test/gnu/gcc/gcc/gcc/testsui te/gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 -w -O0 -L/test/g nu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/h ppa2.0w-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux 11.11/./libiberty -lm -o /test/gnu/gcc/objdir/gcc/testsuite/gfortran/intrinsi c_rrspacing.x(timeout = 300) /usr/ccs/bin/ld: Unsatisfied symbols: _gfortran_rrspacing_r4 (first referenced in /var/tmp//ccSkcell.o) (code) collect2: ld returned 1 exit status compiler exited with status 1 output is: /usr/ccs/bin/ld: Unsatisfied symbols: _gfortran_rrspacing_r4 (first referenced in /var/tmp//ccSkcell.o) (code) collect2: ld returned 1 exit status FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 compilation, -O0 UNTESTED: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 execution, - O0 -- Summary: FAIL: gfortran.fortran- torture/execute/intrinsic_rrspacing.f90 and intrinsic_spacing.f90 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29423
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #28 from danglin at gcc dot gnu dot org 2006-10-10 22:26 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug libfortran/29423] FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 and intrinsic_spacing.f90
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-10 22:34 --- Update your source directory and rebuild in a clean obj directory. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29423
[Bug c++/29209] ICE optimizing passing long double to abstract method while in other abstract's impl
--- Comment #4 from danglin at gcc dot gnu dot org 2006-10-10 23:00 --- This bug is still present on trunk: -bash-2.05b$ /test/gnu/gcc/objdir/gcc/g++ -B/test/gnu/gcc/objdir/gcc/ -S -O2 p> pr29209.cc: In member function 'void DataOutputStream_impl::_ZTv0_n12_N21DataOutputStream_impl16write_longdoubleEe(long double)': pr29209.cc:21: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6506 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. xxx.sh 2>&1 Breakpoint 1, expand_expr_addr_expr_1 (exp=0x0, target=0x76, tmode=1431655765, modifier=118) at ../../gcc/gcc/expr.c:6458 6458 if (TREE_CODE (exp) == CONSTRUCTOR (gdb) bt #0 expand_expr_addr_expr_1 (exp=0x0, target=0x76, tmode=1431655765, modifier=118) at ../../gcc/gcc/expr.c:6458 #1 0x0028b014 in expand_expr_real_1 (exp=0x7ae69760, target=0x0, tmode=SImode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc/gcc/expr.c:6593 #2 0x002941fc in expand_expr_real (exp=0x7ae69760, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc/gcc/expr.c:6706 #3 0x00240e9c in expand_call (exp=0x7adc07f8, target=0x0, ignore=1) at ../../gcc/gcc/expr.h:499 #4 0x0028c054 in expand_expr_real_1 (exp=0x7adc07f8, target=0x7adb5210, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc/gcc/expr.c:7671 #5 0x00294110 in expand_expr_real (exp=0x7adc07f8, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc/gcc/expr.c:6700 #6 0x003322dc in expand_expr_stmt (exp=0x7adc07f8) at ../../gcc/gcc/stmt.c:1356 #7 0x00530f8c in expand_gimple_basic_block (bb=0x7adcc990) at ../../gcc/gcc/cfgexpand.c:1199 #8 0x005323ac in tree_expand_cfg () at ../../gcc/gcc/cfgexpand.c:1644 #9 0x0037136c in execute_one_pass (pass=0x40018070) at ../../gcc/gcc/passes.c:870 ---Type to continue, or q to quit--- #10 0x0037150c in execute_pass_list (pass=0x40018070) at ../../gcc/gcc/passes.c:917 #11 0x001c69f8 in tree_rest_of_compilation (fndecl=0x7ae60310) at ../../gcc/gcc/tree-optimize.c:463 #12 0x00121ca4 in expand_body (fn=0x7ae60310) at ../../gcc/gcc/cp/semantics.c:3068 #13 0x00117a8c in use_thunk (thunk_fndecl=0x7ae60310, emit_p=0 '\0') at ../../gcc/gcc/cp/method.c:524 #14 0x00121c2c in expand_body (fn=0x7ae602a0) at ../../gcc/gcc/cp/semantics.c:3021 #15 0x00397624 in cgraph_expand_function (node=0x7ae603f0) at ../../gcc/gcc/cgraphunit.c:1233 #16 0x0039aaf4 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1298 #17 0x000bdcbc in cp_finish_file () at ../../gcc/gcc/cp/decl2.c:3344 #18 0x0002d2ac in finish_file () at ../../gcc/gcc/cp/cp-lang.c:144 #19 0x00191cc4 in c_common_parse_file (set_yydebug=2061227104) at ../../gcc/gcc/c-opts.c:1176 #20 0x0033d49c in toplev_main (argc=1073937672, argv=0x1) at ../../gcc/gcc/toplev.c:1033 #21 0x001a2b24 in main (argc=2061227104, argv=0x0) at ../../gcc/gcc/main.c:35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29209
[Bug libgcj/29424] New: FAIL: events output
Executing on host: /home/dave/gcc-4.2/objdir/hppa-linux/libjava/testsuite/../lib tool --silent --tag=GCJ --mode=link /home/dave/gcc-4.2/objdir/gcc/gcj -B/home/da ve/gcc-4.2/objdir/hppa-linux/libjava/ -B/home/dave/gcc-4.2/objdir/gcc/ --encodin g=UTF-8 -B/home/dave/gcc-4.2/objdir/hppa-linux/libjava/testsuite/../ /home/dave/ gcc-4.2/gcc/libjava/testsuite/libjava.jvmti/events.java natevents.o -no-instal l --main=events -g -L/home/dave/gcc-4.2/objdir/hppa-linux/./libjava/.libs -lm -o events(timeout = 300) PASS: linking events set_ld_library_path_env_vars: ld_library_path=.:/home/dave/gcc-4.2/objdir/hppa-l inux/./libjava/.libs:/home/dave/gcc-4.2/objdir/gcc Setting LD_LIBRARY_PATH to .:/home/dave/gcc-4.2/objdir/hppa-linux/./libjava/.lib s:/home/dave/gcc-4.2/objdir/gcc:.:/home/dave/gcc-4.2/objdir/hppa-linux/./libjava /.libs:/home/dave/gcc-4.2/objdir/gcc:.:/home/dave/gcc-4.2/objdir/hppa-linux/./li bjava/.libs:/home/dave/gcc-4.2/objdir/gcc:/home/dave/gcc-4.2/objdir/hppa-linux/l ibstdc++-v3/.libs:/home/dave/gcc-4.2/objdir/hppa-linux/libmudflap/.libs:/home/da ve/gcc-4.2/objdir/hppa-linux/libssp/.libs:/home/dave/gcc-4.2/objdir/hppa-linux/l ibgomp/.libs:/home/dave/gcc-4.2/objdir/./gcc:/home/dave/gcc-4.2/objdir/./prev-gc c JVMTI event notification tests - enable tests - created JVMTI environment #0 created JVMTI environment #1 created JVMTI environment #2 setting callbacks for envs RequestedEvents: enable VM_INIT for env0, env1, env2 RequestedEvents: VMInit, enable VM_DEATH for env1,env2 RequestedEvents: VMInit,VMDeath, enable THREAD_END for env2 RequestedEvents: VMInit,VMDeath,ThreadEnd, disposing of env1 RequestedEvents: VMInit,VMDeath,ThreadEnd, disposing of env0 RequestedEvents: VMInit,VMDeath,ThreadEnd, disable VMInit in env2 RequestedEvents: VMDeath,ThreadEnd, clear VMDeath callback in env2 RequestedEvents: ThreadEnd, sending VMInit sending ThreadEnd ThreadEndCB jni_env=0x5678 thread=0x1234 sending VMDeath disposing of env2 RequestedEvents: - callback arg tests - RequestedEvents: VMInit,VMDeath,ThreadStart,ThreadEnd,ClassFileLoadHook,ClassLoa d,ClassPrepare,VMStart,Exception,ExceptionCatch,SingleStep,FramePop,Breakpoint,F ieldAccess,FieldModification,MethodEntry,MethodExit,NativeMethodBind,CompiledMet hodLoad,CompiledMethodUnload,DynamicCodeGenerated,DataDumpRequest,MonitorWait,Mo nitorWaited,MonitorContendedEnter,MonitorContendedEntered,GarbageCollectionStart ,GarbageCollectionFinish,ObjectFree,VMObjectAlloc, VMInitCB jni_env=0x1 thread=0x2 VMDeathCB jni_env=0x1 ThreadStartCB jni_env=0x1 thread=0x2 ThreadEndCB jni_env=0x1 thread=0x2 ClassFileLoadHookCB jni_env=0x1 class_being_redefined=0x2 loader=0x3 name=4 prot ection_domain=0x5 class_data_len=6 class_data=0x7 new_class_data_len=0x8 new_cla ss_data=0x9 ClassLoadCB jni_env=0x1 thread=0x2 klass=0x3 ClassPrepareCB jni_env=0x1 thread=0x2 klass=0x3 VMStartCB jni_env=0x1 ExceptionCB jni_env=0x1 thread=0x2 method=0x3 location=0x4 exception=0x5 catch_m ethod=0x6 catch_location=0x436459d4 ExceptionCatchCB jni_env=0x1 thread=0x2 method=0x3 location=0x4 exception=0x5 SingleStepCB jni_env=0x1 thread=0x2 method=0x3 location=0x4 FramePopCB jni_env=0x1 thread=0x2 method=0x3 was_pooped_by_exception=1 BreakpointCB jni_env=0x1 thread=0x2 method=0x3 location=0x4 FieldAccessCB jni_env=0x1 thread=0x2 method=0x3 location=0x4 field_klass=0x5 obj ect=0x6 field=0x7 FieldModificationCB jni_env=0x1 thread=0x2 method=0x3 location=0x4 field_klass= 0x5 object=0x6 field=0x7 signature_type=8 new_value=1127144256 MethodEntryCB jni_env=0x1 thread=0x2 method=0x3 MethodExitCB jni_env=0x1 thread=0x2 method=0x3 was_popped_by_exception=1 return_ value=6 NativeMethodBindCB jni_env=0x1 thread=0x2 method=0x3 address=0x4 new_address_ptr =0x5 CompiledMethodLoadCB method=0x1 code_size=0x2 code_addr=0x3 map_length=4 map=0x5 compile_info=0x6 CompiledMethodUnloadCB method=0x1 code_addr=0x2 DynamicCodeGeneratedCB name=1 address=0x2 length=3 DataDumpRequestCB MonitorWaitCB jni_env=0x1 thread=0x2 object=0x3 timeout=4 MonitorWaitedCB jni_env=0x1 thread=0x2 object=0x3 timed_out=1 MonitorContendedEnterCB jni_env=0x1 thread=0x2 object=0x3 MonitorContendedEnteredCB jni_env=0x1 thread=0x2 object=0x3 GarbageCollectionStartCB GarbageCollectionFinishCB ObjectFreeCB tag=1 VMObjectAllocCB jni_env=0x1 thread=0x2 object=0x3 object_klass=0x4 size=5 FAIL: events output -- Summary: FAIL: events output Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29424
[Bug c++/29425] New: template template + default parameter = selection failure
Maybe you've got this already but I don't see it. The following fails
to compile (reports an ambiguity) in g++ 4.0.3:
#include
template
class two { };
template
struct print {
void operator()(void) const
{ std::cout << "1" << std::endl; }
};
template class T, class A>
struct print< T > {
void operator()(void) const
{ std::cout << "2" << std::endl; }
};
template class T, class A, class B>
struct print< T > {
void operator()(void) const
{ std::cout << "3" << std::endl; }
};
int main(void)
{
print< two >()();
}
Two other compilers I've tried, Portland Group and Intel, compile
the code; the executables print "3". That's what I'd have expected.
If class B isn't defaulted in class template "two," there's no
problem.
Martin
--
Summary: template template + default parameter = selection
failure
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mstaley at lanl dot gov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29425
[Bug objc/29412] gnustep-base build fails with gcc 3.4.x on HP-UX 11.23 (both ia64 and pa)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-11 00:42 --- Can you attach the preprocessed source? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29412
[Bug c++/29425] template template + default parameter = selection failure
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-11 00:43 --- Fixed for 4.2.0. This is also a dup of bug 9737. *** This bug has been marked as a duplicate of 9737 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29425
[Bug c++/9737] [DR150] Partial template specialisation selection failure involving template parameter defaults
--- Comment #24 from pinskia at gcc dot gnu dot org 2006-10-11 00:43 --- *** Bug 29425 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mstaley at lanl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9737
[Bug middle-end/29415] [4.2] bad code reordering around inline asm block
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|tree-optimization |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug tree-optimization/29415] [4.2 regression] ] bad code reordering around inline asm block
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |tree-optimization Keywords||alias, wrong-code Summary|[4.2] bad code reordering |[4.2 regression] ] bad code |around inline asm block |reordering around inline asm ||block Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug tree-optimization/29415] [4.2 regression] ] bad code reordering around inline asm block
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-11 01:05 ---
(In reply to comment #3)
> No, that's perfectly valid, you can't jump out of an asm or jump into it,
> but if you enter the asm and exit it, it doesn't matter what branches or calls
> were used inside it (of course if the function you call inside it is written
> in C you need to add used attribute to it to make sure it is not optimized
> out if it is not otherwise referenced).
Not really, it is still questionable but it is unrelated to the problem as far
as I can tell. The problem is related to struct aliasing, here is a short
testcase which shows the problem (for PPC):
typedef struct
{
int t;
} pthread_mutex_t;
int t;
int f(pthread_mutex_t *a)
{
a->t = 1;
asm("stw%X0 %1,%0" ::"r"(a->t) :"r"(3) : "memory");
return a->t + t;
}
int main(void)
{
pthread_mutex_t a;
if (f(&a)!=3)
__builtin_abort ();
}
We should not get 1+t but a->t + t in the .final_cleanup as the asm can clober
memory.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||dberlin at gcc dot gnu dot
||org, pinskia at gcc dot gnu
||dot org
Severity|normal |blocker
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-10-11 01:05:16
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug c++/29417] [4.2 Regression] link fails with debug and anonymous namespace
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-11 01:21 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29417
[Bug tree-optimization/29415] [4.2 regression] ] bad code reordering around inline asm block
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-11 02:35 ---
(In reply to comment #4)
> asm("stw%X0 %1,%0" ::"r"(a->t) :"r"(3) : "memory");
This is what I get for making a runtime testcase in the bug report.
That asm should be:
asm("stw%X0 %1,%0" ::"r"(a->t) ,"r"(3) : "memory");
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug tree-optimization/29415] [4.2 regression] ] bad code reordering around inline asm block
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-11 02:37 ---
(In reply to comment #5)
> (In reply to comment #4)
> > asm("stw%X0 %1,%0" ::"r"(a->t) :"r"(3) : "memory");
> This is what I get for making a runtime testcase in the bug report.
> That asm should be:
> asm("stw%X0 %1,%0" ::"r"(a->t) ,"r"(3) : "memory");
Grrr, lets try that again, this time for the correct PPC asm:
asm("stw %1,0(%0)" ::"r"(a->t) ,"r"(3) : "memory");
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug tree-optimization/29415] [4.2 regression] ] bad code reordering around inline asm block
--- Comment #7 from dberlin at gcc dot gnu dot org 2006-10-11 02:43 --- Actually, AFAICT this is a variant of the struct aliasing bug zdenek reported. The real problem is that we eliminate the false aliases and because their is no real addressable variable here, the asm's miss out on the SMT's. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug tree-optimization/29415] [4.2 regression] ] bad code reordering around inline asm block
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-10-11 02:46 --- I've verified my fix for the other two bugs will fix this (sorry that one is taking so long). -- dberlin at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-10-11 01:05:16 |2006-10-11 02:46:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug c++/29417] [4.2 Regression] link fails with debug and anonymous namespace
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-11 02:48 ---
Reduced testcase:
template
struct lambda_functor
{
lambda_functor() {}
};
namespace {
lambda_functor<2 > free2;
lambda_functor<3 > free3;
lambda_functor<3 > & _3 = free3;
}
int main (void){}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-10-11 02:48:51
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29417
[Bug c++/29417] [4.2 Regression] link fails with debug and anonymous namespace
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-11 02:50 --- I think this is related to PR 27657. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||27657 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29417
[Bug libstdc++/29426] New: static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
The concurrence.h mutex lock/unlock changes of 13 Sept have caused
failure of all C++ testcases using std::cout on mingw32, iff -mthreads
(enabling __gthread_active_p) option is added to RUNTESTFLAGS.
Originally, the failures were of the form"
"terminate called after throwing an instance of 'std::runtime_error'
what(): __mutex::lock"
and resulted from the target __gthread_mutex_lock being handed an invalid
mutex.
Its a Good Thing the error checking had been turned on by the same
patchset :)
Its a Bad Thing that I haven't been testing with -mthreads
turned on more frequently :(
This patch
2006-10-09 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libstdc++/29118
* src/locale_init.cc (__get_locale_mutex): New.
(locale::locale): Use it.
(locale::global): Use it.
.
got rid of those errors, but they were replaced by:
"terminate called after throwing an instance of 'std::runtime_error'
what(): __recursive_mutex::lock"
^
(mingw32 uses __GTHREAD_MUTEX_INIT_FUNCTION)
These can be fixed by reverting this part of the 13 Sept patch
* libsupc++/guard.cc (static_mutex): Subsume into and fixup for...
* include/ext/concurrence.h (__recursive_mutex): ...this.
like so:
Index: guard.cc
===
--- guard.cc(revision 117613)
+++ guard.cc(working copy)
@@ -42,8 +42,49 @@
#ifdef __GTHREADS
namespace
{
- // A single mutex controlling all static initializations.
- __gnu_cxx::__recursive_mutex static_mutex;
+ // static_mutex is a single mutex controlling all static initializations.
+ // This is a static class--the need for a static initialization function
+ // to pass to __gthread_once precludes creating multiple instances, though
+ // I suppose you could achieve the same effect with a template.
+ class static_mutex
+ {
+static __gthread_recursive_mutex_t mutex;
+
+#ifdef __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
+static void init();
+#endif
+
+ public:
+static void lock();
+static void unlock();
+ };
+
+ __gthread_recursive_mutex_t static_mutex::mutex
+#ifdef __GTHREAD_RECURSIVE_MUTEX_INIT
+ = __GTHREAD_RECURSIVE_MUTEX_INIT
+#endif
+ ;
+
+#ifdef __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
+ void static_mutex::init()
+ {
+__GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION (&mutex);
+ }
+#endif
+
+ void static_mutex::lock()
+ {
+#ifdef __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
+static __gthread_once_t once = __GTHREAD_ONCE_INIT;
+__gthread_once (&once, init);
+#endif
+__gthread_recursive_mutex_lock (&mutex);
+ }
+
+ void static_mutex::unlock ()
+ {
+__gthread_recursive_mutex_unlock (&mutex);
+ }
}
#ifndef _GLIBCXX_GUARD_TEST_AND_ACQUIRE
@@ -144,12 +185,12 @@
bool unlock;
mutex_wrapper (): unlock(true)
{
- static_mutex.lock();
+ static_mutex::lock ();
}
~mutex_wrapper ()
{
if (unlock)
- static_mutex.unlock();
+ static_mutex::unlock ();
}
} mw;
@@ -172,7 +213,7 @@
recursion_pop (g);
#ifdef __GTHREADS
if (__gthread_active_p ())
- static_mutex.unlock();
+ static_mutex::unlock ();
#endif
}
@@ -183,7 +224,7 @@
_GLIBCXX_GUARD_SET_AND_RELEASE (g);
#ifdef __GTHREADS
if (__gthread_active_p ())
- static_mutex.unlock();
+ static_mutex::unlock ();
#endif
}
}
--
Summary: static __recursive_mutex init vs
__GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
[Bug libstdc++/29426] [4.2 Regression] static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker Summary|static __recursive_mutex|[4.2 Regression] static |init vs|__recursive_mutex init vs |__GTHREAD_RECURSIVE_MUTEX_IN|__GTHREAD_RECURSIVE_MUTEX_IN |IT_FUNCTION |IT_FUNCTION Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
[Bug c++/28450] [4.0 regression] ICE with new and complex/vector types
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-10-11 03:10 --- Subject: Bug 28450 Author: pinskia Date: Wed Oct 11 03:10:25 2006 New Revision: 117627 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117627 Log: 2006-10-10 Andrew Pinski <[EMAIL PROTECTED]> PR C++/28450 * cp/init.c (build_zero_init): Handle VECTOR_TYPE and COMPLEX_TYPEs. 2006-10-10 Andrew Pinski <[EMAIL PROTECTED]> PR C++/28450 * g++.dg/ext/vector4.C: New test. * g++.dg/ext/complex1.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/ext/complex1.C - copied unchanged from r116341, trunk/gcc/testsuite/g++.dg/ext/complex1.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/ext/vector4.C - copied unchanged from r116341, trunk/gcc/testsuite/g++.dg/ext/vector4.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/init.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28450
[Bug c++/28450] [4.0 regression] ICE with new and complex/vector types
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-10-11 03:12 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28450
[Bug c++/29008] Fails to accept templated constructor
--- Comment #5 from bangerth at dealii dot org 2006-10-11 03:35 --- Um, the error message says `foo' is not a template which is about as accurate as can be. That said, the request for a warning for constructors that can't be called is ok. Would you mind opening a new report only about this issue and closing the present one, so as to keep the audit trail of PRs as non-confusing as possible? Thanks W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-11 03:35:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29008
[Bug c++/29164] Overloaded operator delete[] doesn't get called
--- Comment #4 from bangerth at dealii dot org 2006-10-11 03:43 --- Confirmed. 12.5/4 reads to me as if myclass::operator delete[] should be called. Indeed icc doesn't call either user defined operator in the array case. I think that's just a convergence of bugs, though. This appears to have been broken since at least 2.95. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||2.95.3 3.3.6 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-10-11 03:43:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29164
[Bug c++/29427] New: uncallable constructor template should be warned.
class foo {
public:
template
foo(int i) : j(i) {}
template
void bar(int i) { j = i; }
template
static
void baz(int i) {}
int j;
};
int main() {
foo::baz(3);
foo* p; p->bar(3);
new foo(3);
return 0;
}
gets you:
~/ootbc/chips$ g++ foo.cc
foo.cc: In function âint main()â:
foo.cc:8: error: âfooâ is not a template
foo.cc:8: error: no matching function for call to âfoo::foo(int)â
foo.cc:1: note: candidates are: foo::foo(const foo&)
The problem is that the constructor was declared as a template, hence cannot be
called (see bug# 29008). This can be detected at the declaration and a warning
should issue.
OK.
--
Summary: uncallable constructor template should be warned.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29427
[Bug c++/29008] Fails to accept templated constructor
--- Comment #6 from igodard at pacbell dot net 2006-10-11 05:36 --- Done -- igodard at pacbell dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29008
[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
--- Comment #5 from paulthomas2 at wanadoo dot fr 2006-10-11 06:11 --- Subject: Re: LBOUND(TRANSPOSE(I)) doesn't work FX, > >That's because of F95 13.14.53: > >Case (i): For an array section or for an array expression other than a whole >array or array structure component, LBOUND(ARRAY, DIM) has the value 1. For a >whole array or array structure component, LBOUND(ARRAY, DIM) has the value: >(a) equal to the lower bound for subscript DIM of ARRAY if dimension DIM of >ARRAY does not have extent zero or if ARRAY is an assumed-size array of rank >DIM, or >(b) 1 otherwise. > > > > That's what I was asking. OK, we have a problem with allocatable components too. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug driver/19353] Faulty handling of (some) user specified specs
--- Comment #7 from gschafer at zip dot com dot au 2006-10-11 06:18 --- The root cause of this bug is obvious after studying gcc.c. Essentially, the user specified specs are read _way_ too late in the process. The sequence is roughly this: 1 - search for default specs file, if found load it 2 - set up the standard search paths "Look for executables and startfiles in the standard places" 3 - process any user specified specs from the command line It never used to be like this! The user specified specs used to be processed immediately after the default specs were loaded (which was much saner). The behavior was changed back in 1999 for the benefit of the Java front end which wants to use "-specs=libgcj.spec" and have the specs file found automatically: http://gcc.gnu.org/ml/gcc-patches/1999-06n/msg00511.html gcc.c has evolved much since then so currently it's impossible for the user to override on the command line a few specs that appear in step (2) above, namely: "sysroot_suffix_spec", "sysroot_hdrs_suffix_spec", "startfile_prefix_spec", "md_startfile_prefix" and "md_startfile_prefix_1". Reverting the 1999 patch fixes the bug but of course breaks linking of Java user programs. In retrospect, Java should probably have implemented something a bit less fragile than this "solution" IMHO. Just removing "startfile_prefix_spec" is not the correct action because as mentioned above, other specs are also affected. Not only that, some folks (LFS in particular) have latched onto that spec and rely on it for their build procedures, even tho' it is completely *undocumented* and its usefulness is questionable. Re-titling bug to reflect reality. -- gschafer at zip dot com dot au changed: What|Removed |Added Summary|Faulty handling of |Faulty handling of (some) |startfile_prefix_spec |user specified specs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353
[Bug fortran/29428] New: Error in allocatable component function calls
program test implicit none type A integer, allocatable :: j(:) end type A type(A):: x x=f() contains function f() type(A):: f print *,"I'm only called once in the fortran!" f = A((/1,2/)) end function f end program calls the function twice! The code produced shows that the assignment nullifies the data field of the function, which results in it's being called a second time. Paul -- Summary: Error in allocatable component function calls Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: pault at gcc dot gnu dot org ReportedBy: pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29428
