[Bug c++/42026] New: g++ violate [basic.lookup.argdep]
In the following example:
namespace NS {
class T { };
void g(T, int) { }
}
NS::T parm;
void g(NS::T, float) { }
int main() {
extern void g(NS::T, float);
g(parm, 1);
}
program should call void ::g(NS::T, float), but g++ calls NS::g(T, int).
--
Summary: g++ violate [basic.lookup.argdep]
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pi3orama at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42026
[Bug testsuite/42001] LTO tests fail with non multilib targets (but still not --disable-multilib )
--- Comment #11 from uros at gcc dot gnu dot org 2009-11-13 09:05 --- Subject: Bug 42001 Author: uros Date: Fri Nov 13 09:05:18 2009 New Revision: 154145 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154145 Log: PR testsuite/42001 * g++.dg/lto/lto.exp: Pass no-mathlib to lto_init. Call lto_finish at the end. * gfortran.dg/lto/lto.exp: Ditto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/lto/lto.exp trunk/gcc/testsuite/gfortran.dg/lto/lto.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42001
[Bug testsuite/42001] LTO tests fail with non multilib targets (but still not --disable-multilib )
--- Comment #12 from ubizjak at gmail dot com 2009-11-13 09:11 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42001
[Bug target/42017] gcc compiling C for ARM has stopped using r14 in leaf functions?
-- nickpelling at nanodome dot com changed: What|Removed |Added Severity|normal |minor GCC target triplet||ARM http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42017
[Bug tree-optimization/42027] New: Performance regression in convolution loop optimization
GCC trunk rev. 154141 seems to handle less efficiently a convolution code than
previous stable releases, it was also spotted in revision 153048.
Here are some average timings on an Intel E5320 clocked at 1.86 GHz with 4 MB
of L2 cache, Debian GNU/Linux with a 2.6.26 kernel.
* with -O2 -march=native
GCC 4.3.2 8239 ms
GCC-4.4.2 8102 ms
GCC-snapshot-20091105 9347 ms
GCC-trunk-r154141 9343 ms
* with -O2
GCC 4.3.2 8128 ms
GCC-4.4.2 8158 ms
GCC-snapshot-20091105 9824 ms
GCC-trunk-r154141 9828 ms
* with -O1
GCC 4.3.2 20926 ms
GCC-4.4.2 8277 ms
GCC-snapshot-20091105 9369 ms
GCC-trunk-r154141 9375 ms
* with -O0
GCC 4.3.2 34061 ms
GCC-4.4.2 34241 ms
GCC-snapshot-20091105 34903 ms
GCC-trunk-r154141 34910 ms
GCC compiled with : configure --prefix=/export/home/nicolas/gcc/trunk-install
--enable-languages=c --disable-multilib --disable-bootstrap
--enable-checking=release
I haven't been able to track down the origin of the performance difference.
Note that data are not initialized in the attached code, as the slowdown is
observed wether they are or not.
---BEGIN code---
#define N 1024*512
#define M 512
#define ITER 16
double in[N];
double H[M];
double vH[N];
int main ( int argc,
char **argv )
{
int i, j, k;
for ( i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=42027
[Bug bootstrap/42028] New: Bootstrap fails for mpfr/gmp not in LD_LIBRARY_PATH
Bootstrapping of gcc-4.4.2 fails on my machine because the stage 1 compiler has a runtime dependency on mpfr and gmp, which are not in my LD_LIBRARY_PATH because I only built them in order to compile gcc. Using --with-gmp, --with-mpfr and --with-build-libsubdir at configure time lets it compile but doesn't help it run. Given that the inputs to configure make it pretty clear mpfr and gmp are not in standard locations, and the finished compiler won't have any dependencies on those libraries, I would expect the build system to ensure they are accessible to any dependent intermediate binaries it runs. The workaround is to set up an LD_LIBRARY_PATH, so this is more annoyance than anything else. -- Summary: Bootstrap fails for mpfr/gmp not in LD_LIBRARY_PATH Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: scovich at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42028
[Bug tree-optimization/42027] Performance regression in convolution loop optimization
--- Comment #1 from nbenoit at tuxfamily dot org 2009-11-13 09:51 --- Created an attachment (id=19010) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19010&action=view) Source file with a convolution loop pattern. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42027
[Bug c++/42026] g++ violate [basic.lookup.argdep]
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-13 10:03 --- Can you be more specific? Ordinary unqualified lookup finds ::g and lookup in the associated namespace finds NS::g, the latter is a better match for the arguments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42026
[Bug middle-end/42029] New: [4.5 Regression] ICE with complex data type and openmp for reduction clause
The following valid code snippet triggers in ICE on trunk:
==
void foo()
{
int i;
_Complex int c = 0;
#pragma omp parallel for private(i) reduction(+:c)
for (i = 0; i < 8; ++i)
c += 0;
}
==
bug.c: In function 'foo.omp_fn.0':
bug.c:8:7: error: invalid rhs for gimple memory store
D.2747
*D.2746_13;
D.2747 = *D.2746_13;
bug.c:8:7: internal compiler error: verify_stmts failed
Please submit a full bug report, [etc.]
--
Summary: [4.5 Regression] ICE with complex data type and openmp
for reduction clause
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored, openmp
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42029
[Bug middle-end/42029] [4.5 Regression] ICE with complex data type and openmp for reduction clause
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42029
[Bug c++/42026] g++ violate [basic.lookup.argdep]
--- Comment #2 from pi3orama at gmail dot com 2009-11-13 10:10 ---
This is an example in C++ language standard. The version is N2960. It said (at
page 47, [basic.lookup.argdep]/3):
Let X be the lookup set produced by unqualified lookup (3.4.1) and let Y be the
lookup set produced by argument dependent lookup (defined as follows). If X
contains
¡ª a declaration of a class member, or
¡ª a block-scope function declaration that is not a using-declaration, or
¡ª a declaration that is neither a function or a function template
then Y is empty. Otherwise Y is the set of declarations found in the namespaces
associated with the argument types as described below. The set of declarations
found by the lookup of the name is the union of X and Y. [ Note: the namespaces
and classes associated with the argument types can include namespaces and
classes already considered by the ordinary unqualified lookup. ¡ªend note ]
and following is example:
namespace NS {
class T { };
void f(T);
void g(T, int);
}
NS::T parm;
void g(NS::T, float);
int main() {
f(parm); // OK: calls NS::f
extern void g(NS::T, float);
g(parm, 1); // OK: calls g(NS::T, float)
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42026
[Bug c++/42026] g++ violate [basic.lookup.argdep]
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-13 10:24 --- Ah yes, this is DR 239 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#239 -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-13 10:24:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42026
[Bug bootstrap/42028] Bootstrap fails for mpfr/gmp not in LD_LIBRARY_PATH
--- Comment #1 from scovich at gmail dot com 2009-11-13 10:35 --- Hmm.. it seems the final executable depends on mpfr and gmp as well... I could have sworn the docs said it was a build-time dependency only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42028
[Bug c++/14777] [4.3/4.4/4.5 Regression] typedef doesn't fully expose base class type
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-09-10 02:26:30 |2009-11-13 10:37:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14777
[Bug middle-end/42025] [4. Regression] ICE verify_stmts failed (non-trivial conversion at assignment)
--- Comment #2 from reichelt at gcc dot gnu dot org 2009-11-13 10:45
---
Confirmed. Reduced testcase (compile with -O2):
typedef void* Ptr;
struct A
{
int i;
union
{
Ptr p;
char *q;
} u;
};
static void foo(struct A *p, char *q)
{
if (p->i)
p->u.p = 0;
else
p->u.q = q;
}
void bar(struct A *p, char *q)
{
foo(p, q);
}
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code, monitored
Last reconfirmed|-00-00 00:00:00 |2009-11-13 10:45:15
date||
Summary|internal compiler error:|[4. Regression] ICE
|verify_stmts failed (non- |verify_stmts failed (non-
|trivial conversion at |trivial conversion at
|assignment) |assignment)
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42025
[Bug c++/42011] linker error with typedef struct
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-13 10:59 --- A::B should have external linkage according to [basic.link] but the definition of A::B::foo() is a local symbol: $ nm A.o t _ZN1A1B3fooEv U __gxx_personality_v0 -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-13 10:59:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42011
[Bug middle-end/40281] [4.4/4.5 Regression] -fprefetch-loop-arrays: ICE: in initialize_matrix_A, at tree-data-ref.c:1887
--- Comment #7 from reichelt at gcc dot gnu dot org 2009-11-13 12:32
---
Even shorter testcase (crashes with "-O -fprefetch-loop-arrays"):
===
void foo(int);
void bar(int n)
{
int a[2], i, j = 0;
for (i = 0; i < 2; i += j+1)
for (j = 0; j < (n ? 1 : 2); ++j)
foo(a[i] + a[j]);
}
===
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40281
[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."
--- Comment #8 from dominiq at lps dot ens dot fr 2009-11-13 13:22 --- Between revisions 154095 and 154111, fifteen new failures appeared on the test performed by regress (see http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01028.html): ... FAIL: gcc.dg/torture/complex-sign-add.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/complex-sign-mixed-add.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/complex-sign-mixed-div.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/complex-sign-mul-minus-one.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/complex-sign-mul-one.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/complex-sign-mul.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/complex-sign-sub.c -O3 -g (test for excess errors) ... FAIL: gcc.dg/vmx/3b-10.c -O3 -g (test for excess errors) FAIL: gcc.dg/vmx/bug-3.c -O3 -g (test for excess errors) FAIL: gcc.dg/vmx/gcc-bug-e.c -O3 -g (test for excess errors) FAIL: gcc.dg/vmx/gcc-bug-i.c -O3 -g (test for excess errors) FAIL: gcc.dg/vmx/sn7153.c -O3 -g (test for excess errors) FAIL: gcc.dg/vmx/varargs-1.c -O3 -g (test for excess errors) FAIL: gcc.dg/vmx/x-04.c -O3 -g (test for excess errors) FAIL: gcc.misc-tests/gcov-2.c (test for excess errors) ... A quick look at http://gcc.gnu.org/regtest/HEAD/native-logsum/gcc/testsuite/gcc/gcc.log.gzip shows that these failures come from: Executing on host: /Users/regress/tbox/native/build/gcc/xgcc -B/Users/regress/tbox/native/build/gcc/ /Users/regress/tbox/svn-gcc/gcc/testsuite/gcc.misc-tests/gcov-2.c -fprofile-arcs -ftest-coverage -g -o ./gcov-2.exe(timeout = 300) Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-49/source/DWARFdSYM.cpp, line 3157. xgcc: Internal error: Abort trap (program dsymutil) Note that I don't see these failure on my build for powerpc-apple-darwin9 [trunk revision 154131]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug translation/40872] String not extracted for translation
--- Comment #21 from joseph at codesourcery dot com 2009-11-13 13:26 --- Subject: Re: String not extracted for translation On Fri, 13 Nov 2009, pearly dot zhao at oracle dot com wrote: > (In reply to comment #19) > > Subject: Re: String not extracted for translation > > > > It didn't do so when I last ran it (gettext 0.17). Are you using another > > version? Maybe there need to be stricter version requirements on gettext? > > > You are right. When I ran with gettext 0.17, only the first string of > conditional string can be pick up for translation. But I have run with gettext > 0.14.6 before. It can extracted both the conditional expression strings for > translation. > So do the codes need match with the latest gettext and improve the version > warning to xgettext at exgettext? One possibility would certainly be to improve the current development version of gettext, get a new release out, and then require the new version (or later) in exgettext and install.texi. That supposes this was not a deliberate change in gettext but a bug that can be safely fixed there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug middle-end/42025] [4.5 Regression] ICE verify_stmts failed (non-trivial conversion at assignment)
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-13 13:42 --- I will have a look. -- 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|2009-11-13 10:45:15 |2009-11-13 13:42:43 date|| Summary|[4. Regression] ICE |[4.5 Regression] ICE |verify_stmts failed (non- |verify_stmts failed (non- |trivial conversion at |trivial conversion at |assignment) |assignment) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42025
[Bug middle-end/42024] [4.5 regression] Revision 154128 caused many failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42024
[Bug middle-end/42024] [4.5 regression] Revision 154128 caused many failures
--- Comment #2 from hubicka at ucw dot cz 2009-11-13 13:40 --- Subject: Re: New: [4.5 regression] Revision 154128 caused many failures These are frontend bugs caught by sanity check I accidentally comitted. I posted objc fix and C++ part is in testing. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42024
[Bug tree-optimization/42027] [4.5 Regression] Performance regression in convolution loop optimization
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-13 13:49 --- It looks like it is induction variable related. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Summary|Performance regression in |[4.5 Regression] Performance |convolution loop|regression in convolution |optimization|loop optimization Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42027
[Bug middle-end/42029] [4.5 Regression] ICE with complex data type and openmp for reduction clause
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-13 13:52 --- some DECL_GIMPLE_REG_P is missing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42029
[Bug rtl-optimization/41697] ICE on gcc.c-torture/compile/20090917-1.c
--- Comment #3 from abel at gcc dot gnu dot org 2009-11-13 14:33 --- Subject: Bug 41697 Author: abel Date: Fri Nov 13 14:32:52 2009 New Revision: 154148 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154148 Log: PR rtl-optimization/41697 * sel-sched-ir.c (fallthru_bb_of_jump): Bail out when a block with a conditional jump has a single successor. Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched-ir.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41697
[Bug c++/21008] [4.3/4.4/4.5 Regression] [DR515] Access failure in accessing data member of base class from derived template class
--- Comment #15 from jason at gcc dot gnu dot org 2009-11-13 14:41 --- Subject: Bug 21008 Author: jason Date: Fri Nov 13 14:40:22 2009 New Revision: 154150 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154150 Log: PR c++/21008, DR 515 * semantics.c (finish_non_static_data_member): Don't check derivation in a template. Added: trunk/gcc/testsuite/g++.dg/template/inherit4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/lookup/scoped8.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008
[Bug c++/11987] [4.3/4.4/4.5 regression] Accepts-invalid with inherited nested type
--- Comment #15 from jason at gcc dot gnu dot org 2009-11-13 14:40 --- Subject: Bug 11987 Author: jason Date: Fri Nov 13 14:40:13 2009 New Revision: 154149 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154149 Log: PR c++/11987 * parser.c (cp_parser_direct_declarator): Give helpful error about trying to define member of a dependent typedef. * pt.c (resolve_typename_type): Don't resolve a typedef typename. * tree.c (typedef_variant_p): New. * cp-tree.h: Declare it. Added: trunk/gcc/testsuite/g++.dg/parse/typename11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/crash48.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11987
[Bug c++/35075] [4.3/4.4/4.5 regression] ICE with references in templates
--- Comment #8 from jason at gcc dot gnu dot org 2009-11-13 14:41 --- Subject: Bug 35075 Author: jason Date: Fri Nov 13 14:40:32 2009 New Revision: 154151 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154151 Log: PR c++/35075 * pt.c (convert_nontype_argument): Give helpful error about reference variable argument to reference template parameter. Added: trunk/gcc/testsuite/g++.dg/template/ref5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35075
[Bug c++/11987] [4.3/4.4/4.5 regression] Accepts-invalid with inherited nested type
--- Comment #16 from jason at gcc dot gnu dot org 2009-11-13 14:41 --- Fixed for 4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.5 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11987
[Bug c++/35075] [4.3/4.4/4.5 regression] ICE with references in templates
--- Comment #9 from jason at gcc dot gnu dot org 2009-11-13 14:42 --- Fixed for 4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.3.5 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35075
[Bug c++/11987] [4.3/4.4/4.5 regression] Accepts-invalid with inherited nested type
--- Comment #17 from jason at gcc dot gnu dot org 2009-11-13 14:42 --- . -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11987
[Bug ada/41912] FAIL: gnat.dg/null_pointer_deref1.adb execution test
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-11-13 14:20 --- Subject: Re: FAIL: gnat.dg/null_pointer_deref1.adb execution test > I see that it fails on HP-UX as well. That's probably because there is > something missing in the fallback routines in config/pa, namely: > > fs->signal_frame = 1; > > just before > > return _URC_NO_REASON; This is an interesting suggestion. However, the results in doing this are mixed. It fixes the current testcase on hpux but not linux. It fixes three libjava fails on linux. However, it introduces four fails on both hpux and linux. For example, Executing on host: /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/ ../libtool --silent --tag=GCJ --mode=link /test/gnu/gcc/objdir/./gcc/gcj -B/test /gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/ -B/test/gnu/gcc/objdir/./gcc/ -B/ opt/gnu/gcc/gcc-4.5.0/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.5.0/hppa2. 0w-hp-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.5.0/hppa2.0w-hp-hpux11.11/inclu de -isystem /opt/gnu/gcc/gcc-4.5.0/hppa2.0w-hp-hpux11.11/sys-include --encodi ng=UTF-8 -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/../ /tes t/gnu/gcc/gcc/libjava/testsuite/libjava.lang/Array_3.jar -w -no-install --main =Array_3 -g -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs -lm -o /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/Array_3.exe ( timeout = 300) PASS: Array_3 compilation from source set_ld_library_path_env_vars: ld_library_path=.:/test/gnu/gcc/objdir/hppa2.0w-hp -hpux11.11/./libjava/.libs invoke: /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/Array_3.exe Setting LD_LIBRARY_PATH to .:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjav a/.libs:.:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs Exception in thread "main" java.lang.NullPointerException at Array_3.main(Array_3.java:30) FAIL: Array_3 execution - source compiled test UNTESTED: Array_3 output - source compiled test Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41912
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-11-13 14:26 --- I tried the patch from comment 3 on x86_64-apple-darwin9.8.0 and the gcj crashes still occur. I wonder if this change only makes the bug potentially go latent on certain hardware for intel darwin. It is unclear why this change would really fix an unwinder issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug c/42030] New: collect2: ld returned 1 exit status
When I attempt to compile the 11/12/09 snapshot of gcc 4.5 on an HP-PA workstation under Debian Linux 5.0 I get the message: /home/mrichmon/gcc-4.5-20091112/g95/./prev-gcc/xgcc -B/home/mrichmon/gcc-4.5-20091112/g95/./prev-gcc/ -B/home/mrichmon/irun/hppa1.1-unknown-linux-gnu/bin/ -B/home/mrichmon/irun/hppa1.1-unknown-linux-gnu/bin/ -B/home/mrichmon/irun/hppa1.1-unknown-linux-gnu/lib/ -isystem /home/mrichmon/irun/hppa1.1-unknown-linux-gnu/include -isystem /home/mrichmon/irun/hppa1.1-unknown-linux-gnu/sys-include -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -o cc1 c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o \ cc1-checksum.o main.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a-lmpfr -lgmp -rdynamic -ldl -L../zlib -lz collect2: ld returned 1 exit status make[3]: *** [cc1] Error 1 -- Summary: collect2: ld returned 1 exit status Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov GCC build triplet: hppa1.1-unknown-linux-gnu GCC host triplet: hppa1.1-unknown-linux-gnu GCC target triplet: hppa1.1-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42030
[Bug c++/14777] [4.3/4.4/4.5 Regression] typedef doesn't fully expose base class type
--- Comment #15 from mark at codesourcery dot com 2009-11-13 15:07 --- Subject: Re: [4.3/4.4/4.5 Regression] typedef doesn't fully expose base class type jason at gcc dot gnu dot org wrote: > I'm assuming Mark isn't actually working on this bug. Sad, but true. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14777
[Bug debug/41988] [4.5 Regression] FAIL: g++.dg/debug/*.C -gdwarf-2 -g1 (internal compiler error)
--- Comment #2 from ubizjak at gmail dot com 2009-11-13 15:10 --- Adding CC. -- ubizjak at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41988
[Bug c++/26965] [4.3/4.4/4.5 Regression] Unnecessary debug info for unused consts in C++
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-04-02 08:22:16 |2009-11-13 15:36:29 date|| Target Milestone|4.3.5 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26965
[Bug c++/21008] [4.3/4.4/4.5 Regression] [DR515] Access failure in accessing data member of base class from derived template class
--- Comment #16 from jason at gcc dot gnu dot org 2009-11-13 15:37 --- Subject: Bug 21008 Author: jason Date: Fri Nov 13 15:37:29 2009 New Revision: 154153 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154153 Log: PR c++/21008, DR 515 * semantics.c (finish_non_static_data_member): Don't check derivation in a template. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/inherit4.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/semantics.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/g++.dg/lookup/scoped8.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008
[Bug c++/39055] [4.3/4.4/4.5 regression] ICE with questionable default parameter of a member function
--- Comment #10 from jason at gcc dot gnu dot org 2009-11-13 16:16 --- Bumping down the priority since it doesn't ICE on 4.4+ and it's unclear whether or not the code should be valid. -- jason at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39055
[Bug debug/41988] [4.5 Regression] FAIL: g++.dg/debug/*.C -gdwarf-2 -g1 (internal compiler error)
--- Comment #3 from hjl dot tools at gmail dot com 2009-11-13 16:45 --- (In reply to comment #1) > This was more likely caused by HJL's stack alignment patches based on the > context of the ICE. > > I had also saw this the last time I ran the testsuite on x86-darwin. > Is this a regression or a new test? They are OK on Linux. BTW, stack alignment was checked in a long time ago. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41988
[Bug middle-end/42025] [4.5 Regression] ICE verify_stmts failed (non-trivial conversion at assignment)
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-11-13 16:36 --- This seems to be IPA SRA and thus mine. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42025
[Bug c++/27425] [4.3/4.4/4.5 regression] ICE with invalid template-template-parameter
--- Comment #7 from jason at gcc dot gnu dot org 2009-11-13 16:56 --- No longer ICEs in 4.3+. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27425
[Bug debug/41988] [4.5 Regression] FAIL: g++.dg/debug/*.C -gdwarf-2 -g1 (internal compiler error)
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-11-13 16:56 --- (In reply to comment #3) > Is this a regression or a new test? They are OK on Linux. > > BTW, stack alignment was checked in a long time ago. The tests are old, they are from 2003 :). The patch which I was talking about was: 2009-10-30 H.J. Lu PR target/40838 * cfgexpand.c (expand_stack_alignment): Call update_stack_boundary first. Move assert on stack_alignment_estimated just before setting stack_realign_needed. (gimple_expand_cfg): Initialize stack_alignment_estimated to 0. Don't call update_stack_boundary. * config/i386/i386.c (ix86_minimum_incoming_stack_boundary): New. (verride_options): Don't check ix86_force_align_arg_pointer here. (ix86_function_ok_for_sibcall): Use it. (ix86_update_stack_boundary): Likewise. * config/i386/i386.h (STACK_REALIGN_DEFAULT): Update comments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41988
[Bug debug/41988] [4.5 Regression] FAIL: g++.dg/debug/*.C -gdwarf-2 -g1 (internal compiler error)
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-11-13 16:57 --- One should note on darwin we have: /* On Darwin, the stack is 128-bit aligned at the point of every call. Failure to ensure this will lead to a crash in the system libraries or dynamic loader. */ #undef STACK_BOUNDARY #define STACK_BOUNDARY 128 #undef MAIN_STACK_BOUNDARY #define MAIN_STACK_BOUNDARY 128 /* Since we'll never want a stack boundary less aligned than 128 bits we need the extra work here otherwise bits of gcc get very grumpy when we ask for lower alignment. We could just reject values less than 128 bits for Darwin, but it's easier to up the alignment if it's below the minimum. */ #undef PREFERRED_STACK_BOUNDARY #define PREFERRED_STACK_BOUNDARY\ MAX (STACK_BOUNDARY, ix86_preferred_stack_boundary) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41988
[Bug target/42031] New: Thumb2 ICE - spill failure.
The patch here http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00515.html breaks
CSibe builds at Os for thumb2. I've attached a reduced testcase with this bug
report. This was reduced from linux-2.4.23/fs/nfs/read.c .
Building with -fno-schedule-insns works.
Command Line options used -mcpu=cortex-a8 -mthumb -Os.
besttry.c:75:1: error: unable to find a register to spill in class 'LO_REGS'
besttry.c:75:1: error: this is the insn:
(insn 28 32 29 3 besttry.c:52 (parallel [
(set (reg:DI 162)
(plus:DI (zero_extend:DI (reg:SI 161 [ req_6(D)->wb_offset ]))
(reg:DI 173 [orig:158 D.2071 ] [158])))
(clobber (reg:CC 24 cc))
]) 3 {*adddi_zesidi_di} (expr_list:REG_DEAD (reg:SI 161 [
req_6(D)->wb_offset ])
(expr_list:REG_UNUSED (reg:CC 24 cc)
(expr_list:REG_EQUIV (mem/s:DI (reg:SI 133 [ D.2071 ]) [7
0B->args.offset+0 S8 A64])
(nil)
besttry.c:75:1: internal compiler error: in spill_failure, at reload1.c:2141
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
--
Summary: Thumb2 ICE - spill failure.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana at gcc dot gnu dot org
GCC build triplet: x86_64-linux
GCC host triplet: x86_64 linux gnu
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42031
[Bug target/42031] Thumb2 ICE - spill failure.
--- Comment #1 from ramana at gcc dot gnu dot org 2009-11-13 17:23 --- Created an attachment (id=19011) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19011&action=view) Reduced testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42031
[Bug target/42017] gcc compiling C for ARM has stopped using r14 in leaf functions?
--- Comment #1 from ramana at gcc dot gnu dot org 2009-11-13 17:32 ---
(In reply to comment #0)
> In gcc4.2.1 targeting ARM processors, pure leaf functions were able to make
> use
> of r14 / lr (the link register). However, in gcc4.3.2 and gcc4.4.1 (and
> presumably since then, since I can't find it mentioned in any gcc bug
> reports),
> this now uses the stack instead rather than this spare register (boo, hiss).
Can you post specifically what output you got with 4.2.1, what you get with 4.3
and what you get with 4.4 ?
Presumably you are targetting Thumb1 but you need to make that explicit.
>
> Here's some C test code: when compiled with the -O3 option, this uses lr on
> gcc4.2.1 but [sp] on gcc4.3.2 and gcc4.4.1.
>
> int foo(int r0) {
> int r1,r2,r3,r4,r5,r6,r7,r8,r9,r10,r11,r12,r13,r14;
>
> r1 = 0;
>
> for(r2=0;r2 for(r3=0;r3 for(r4=0;r4 for(r5=0;r5 for(r6=0;r6 for(r7=0;r7 for(r8=0;r8 for(r9=0;r9 for(r10=0;r10 for(r11=0;r11 for(r12=0;r12 for(r13=0;r13 for(r14=0;r14 r1++;
>
> return r1;
> }
>
> PS: my guess is that this might have got broken when Thumb2 and ARMv7 support
> was added in (round about gcc4.3)...
>
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42017
[Bug ada/41912] FAIL: gnat.dg/null_pointer_deref1.adb execution test
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-11-13 17:37 --- > This is an interesting suggestion. However, the results in doing > this are mixed. It fixes the current testcase on hpux but not linux. Yes, you additionally need this for Linux: 2009-11-12 Eric Botcazou Laurent GUERBY * init.c (GNU/Linux Section): Enable for all architectures. > It fixes three libjava fails on linux. However, it introduces four > fails on both hpux and linux. Interesting. gnat.dg/null_pointer_deref1.adb is the ultimate test for this null pointer thing because the EH region contains exactly 1 instruction: .LEHB1: stw %r19,0(%r28) .LEHE1: so the unwinder must be extremely accurate when comparing return addresses. Setting fs->signal_frame = 1 will instruct it not to subtract 1 anymore to determine whether the RA belongs to an active EH region. See the very similar code in libjava/exception.cc and ada/raise-gcc.c around _Unwind_GetIPInfo. Not clear what is happening though. Could you attach the assembly code for one Java test that used to fail and now passes and for another Java test with the opposite behavior? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41912
[Bug c++/27425] [4.3/4.4/4.5 regression] ICE with invalid template-template-parameter
--- Comment #8 from paolo dot carlini at oracle dot com 2009-11-13 17:45 --- Jason, see Comment #3, it still ICEs for me... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27425
[Bug c++/29363] [4.3/4.4/4.5 regression] ICE throwing undeclared object
-- jason at gcc dot gnu dot org changed: What|Removed |Added CC||lmillward at gcc dot gnu dot ||org AssignedTo|lmillward at gcc dot gnu dot|jason at gcc dot gnu dot org |org | Status|NEW |ASSIGNED Last reconfirmed|2008-08-16 23:20:22 |2009-11-13 17:51:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29363
[Bug c++/27425] [4.3/4.4/4.5 regression] ICE with invalid template-template-parameter
--- Comment #9 from jason at gcc dot gnu dot org 2009-11-13 17:52 --- Oops. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27425
[Bug ada/41912] FAIL: gnat.dg/null_pointer_deref1.adb execution test
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-11-13 17:55 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-11-02 19:34:21 |2009-11-13 17:55:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41912
[Bug c++/26965] [4.3/4.4/4.5 Regression] Unnecessary debug info for unused consts in C++
--- Comment #18 from jason at gcc dot gnu dot org 2009-11-13 17:59 --- Subject: Bug 26965 Author: jason Date: Fri Nov 13 17:59:26 2009 New Revision: 154157 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154157 Log: PR debug/26965 * dwarf2out.c (gen_variable_die): Don't worry about DECL_COMDAT. Don't emit a second declaration at any scope. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/static-data-member2.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26965
[Bug c++/26965] [4.3/4.4/4.5 Regression] Unnecessary debug info for unused consts in C++
--- Comment #19 from jason at gcc dot gnu dot org 2009-11-13 18:02 --- Fixed for 4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26965
[Bug c++/21008] [4.3/4.4/4.5 Regression] [DR515] Access failure in accessing data member of base class from derived template class
--- Comment #17 from jason at gcc dot gnu dot org 2009-11-13 18:03 --- Subject: Bug 21008 Author: jason Date: Fri Nov 13 18:03:31 2009 New Revision: 154158 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154158 Log: PR c++/21008, DR 515 * semantics.c (finish_non_static_data_member): Don't check derivation in a template. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/inherit4.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/semantics.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/g++.dg/lookup/scoped8.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008
[Bug c++/21008] [4.3/4.4/4.5 Regression] [DR515] Access failure in accessing data member of base class from derived template class
--- Comment #18 from jason at gcc dot gnu dot org 2009-11-13 18:03 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008
[Bug bootstrap/41996] lto-elf.c fails to compile on IRIX 6.5
--- Comment #1 from ro at gcc dot gnu dot org 2009-11-13 18:08 --- Richard, any preferences on how to fix this? The approach outlined in the report doesn't work since intl/loadmsgcat.c uses this definition of PRId64 # define PRId64 (sizeof (long) == 8 ? "ld" : "lld") which doesn't mix with string concatenation. Obviously just using #if !defined PRId64 || PRI_MACROS_BROKEN # undef PRId64 # define PRId64 "lld" #endif works (if one adds the autoconf test for PRI_MACROS_BROKEN). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41996
[Bug c++/34274] [4.3/4.4/4.5 regression] Broken diagnostic: 'template_template_parm' not supported by dump_decl
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-12-02 21:19:07 |2009-11-13 18:21:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34274
[Bug target/41900] call *%esp shouldn't be generated because of CPU errata
--- Comment #6 from uros at gcc dot gnu dot org 2009-11-13 18:33 --- Subject: Bug 41900 Author: uros Date: Fri Nov 13 18:33:37 2009 New Revision: 154160 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154160 Log: 2009-11-13 Uros Bizjak PR target/41900 (*call_pop_1, *call_1, *call_value_pop_1, *call_value_1): Use "lsm" as operand 1 constraint. * config/i386/predicates.md (call_insn_operand): Depend on index_register_operand to avoid %esp register. 2009-11-13 Uros Bizjak Revert: 2009-11-03 Uros Bizjak PR target/41900 * config/i386/i386.h (ix86_arch_indices) : New. (TARGET_CALL_ESP): New define. * config/i386/i386.c (initial_ix86_tune_features): Initialize X86_ARCH_CALL_ESP. * config/i386/i386.md (*call_pop_1_esp, *call_1_esp, *call_value_pop_1_esp, *call_value_1_esp): Rename from *call_pop_1, *call_1, *call_value_pop_1 and *call_value_1. Depend on TARGET_CALL_ESP. (*call_pop_1, *call_1, *call_value_pop_1, *call_value_1): New patterns, use "lsm" as operand 1 constraint. * config/i386/predicates.md (call_insn_operand): Depend on index_register_operand for !TARGET_CALL_ESP to avoid %esp register. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/i386.md trunk/gcc/config/i386/predicates.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41900
[Bug middle-end/42029] [4.5 Regression] ICE with complex data type and openmp for reduction clause
--- Comment #2 from jakub at gcc dot gnu dot org 2009-11-13 18:38 --- Subject: Bug 42029 Author: jakub Date: Fri Nov 13 18:38:36 2009 New Revision: 154161 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154161 Log: PR middle-end/42029 * gimplify.c (gimplify_omp_atomic): Set DECL_GIMPLE_REG_P on tmp_load if needed. * libgomp.c/pr42029.c: New test. Added: trunk/libgomp/testsuite/libgomp.c/pr42029.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42029
[Bug middle-end/42029] [4.5 Regression] ICE with complex data type and openmp for reduction clause
--- Comment #3 from jakub at gcc dot gnu dot org 2009-11-13 18:42 --- Subject: Bug 42029 Author: jakub Date: Fri Nov 13 18:42:32 2009 New Revision: 154162 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154162 Log: PR middle-end/42029 * gimplify.c (gimplify_omp_atomic): Set DECL_GIMPLE_REG_P on tmp_load if needed. * libgomp.c/pr42029.c: New test. Added: branches/gcc-4_4-branch/libgomp/testsuite/libgomp.c/pr42029.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/gimplify.c branches/gcc-4_4-branch/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42029
[Bug c++/29363] [4.3/4.4/4.5 regression] ICE throwing undeclared object
--- Comment #14 from jason at gcc dot gnu dot org 2009-11-13 18:46 --- Subject: Bug 29363 Author: jason Date: Fri Nov 13 18:46:39 2009 New Revision: 154163 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154163 Log: PR c++/29363 * decl.c (create_implicit_typedef): Set TYPE_STUB_DECL here. (cxx_init_decl_processing): Not here. * name-lookup.c (pushtag): Or here. * pt.c (lookup_template_class): Or here. Added: trunk/gcc/testsuite/g++.dg/template/error43.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29363
[Bug c++/27425] [4.3/4.4/4.5 regression] ICE with invalid template-template-parameter
--- Comment #10 from jason at gcc dot gnu dot org 2009-11-13 18:47 --- Subject: Bug 27425 Author: jason Date: Fri Nov 13 18:46:47 2009 New Revision: 154164 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154164 Log: PR c++/27425 PR c++/34274 * pt.c (expand_template_argument_pack): Handle null arg gracefully. (convert_template_argument): Use %T for type. Added: trunk/gcc/testsuite/g++.dg/template/arg7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27425
[Bug c++/34274] [4.3/4.4/4.5 regression] Broken diagnostic: 'template_template_parm' not supported by dump_decl
--- Comment #7 from jason at gcc dot gnu dot org 2009-11-13 18:47 --- Subject: Bug 34274 Author: jason Date: Fri Nov 13 18:46:47 2009 New Revision: 154164 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154164 Log: PR c++/27425 PR c++/34274 * pt.c (expand_template_argument_pack): Handle null arg gracefully. (convert_template_argument): Use %T for type. Added: trunk/gcc/testsuite/g++.dg/template/arg7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34274
[Bug c++/27425] [4.3/4.4/4.5 regression] ICE with invalid template-template-parameter
--- Comment #11 from jason at gcc dot gnu dot org 2009-11-13 18:47 --- Fixed for 4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Target Milestone|4.3.5 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27425
[Bug c++/34274] [4.3/4.4/4.5 regression] Broken diagnostic: 'template_template_parm' not supported by dump_decl
--- Comment #8 from jason at gcc dot gnu dot org 2009-11-13 18:48 --- Fixed for 4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.3.5 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34274
[Bug c++/29363] [4.3/4.4/4.5 regression] ICE throwing undeclared object
--- Comment #15 from jason at gcc dot gnu dot org 2009-11-13 18:48 --- Fixed for 4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.3.5 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29363
[Bug target/41900] call *%esp shouldn't be generated because of CPU errata
--- Comment #7 from uros at gcc dot gnu dot org 2009-11-13 19:13 --- Subject: Bug 41900 Author: uros Date: Fri Nov 13 19:13:16 2009 New Revision: 154169 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154169 Log: 2009-11-13 Uros Bizjak PR target/41900 (*call_pop_1, *call_1, *call_value_pop_1, *call_value_1): Use "lsm" as operand 1 constraint. * config/i386/predicates.md (call_insn_operand): Depend on index_register_operand to avoid %esp register. 2009-11-13 Uros Bizjak Revert: 2009-11-04 Uros Bizjak PR target/41900 * config/i386/i386.h (ix86_arch_indices) : New. (TARGET_CALL_ESP): New define. * config/i386/i386.c (initial_ix86_tune_features): Initialize X86_ARCH_CALL_ESP. * config/i386/i386.md (*call_pop_1_esp, *call_1_esp, *call_value_pop_1_esp, *call_value_1_esp): Rename from *call_pop_1, *call_1, *call_value_pop_1 and *call_value_1. Depend on TARGET_CALL_ESP. (*call_pop_1, *call_1, *call_value_pop_1, *call_value_1): New patterns, use "lsm" as operand 1 constraint. * config/i386/predicates.md (call_insn_operand): Depend on index_register_operand for !TARGET_CALL_ESP to avoid %esp register. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/i386/i386.c branches/gcc-4_4-branch/gcc/config/i386/i386.h branches/gcc-4_4-branch/gcc/config/i386/i386.md branches/gcc-4_4-branch/gcc/config/i386/predicates.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41900
[Bug c++/42032] New: Aliasing errors in stl_tree.h
I'm seeing the following error:
In function int main():
cc1plus: warning: dereferencing pointer does break
strict-aliasing
rules
/usr/lib/gcc/i386-redhat-linux/4.4.0/../../../../include/c++/4.4.0/bits/stl_tree.h:184:
note: initialized from here
I'm unsure of these are legitimate warnings i.e. if stl_tree.h is genuinely
faulty or if it's a false positive from g++. This appears to be similar to
issue 39207.
This problem was originally encountered in chromium (dev.chromium.org) but I
have produced a much reduced test case below. I'm not expecting the reduced
test case to run of course but compilation would be nice :)
Compile with -O2 -Wall
[begin main.cc]
#include
#include
class MyClass {
public:
typedef std::list MyList;
typedef std::map MyMap;
MyClass() {}
~MyClass() {}
void Fail(const int key) {
MyMap::iterator map_iter = map_.find(key);
// this doesn't fail
MyList::iterator list_iter = map_iter->second;
// this does
list_.erase(map_iter->second);
}
MyList list_;
MyMap map_;
};
int main(void)
{
MyClass myclass;
myclass.Fail(5);
return 0;
}
[end main.cc]
Please let me know if you need a save-temps version too.
Thank you!
$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran --disable-libgcj
--with-tune=generic --with-arch=i586 --build=i386-redhat-linux
Thread model: posix
gcc version 4.4.0 20090310 (Red Hat 4.4.0-0.24) (GCC)
--
Summary: Aliasing errors in stl_tree.h
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: craig dot schlenter at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42032
[Bug bootstrap/42030] collect2: ld returned 1 exit status
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-13 19:24 --- Which binutils version do you have installed? You might want to try a newer version of binutils since that includes ld. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42030
[Bug c++/42033] New: libstdc++ seems to miss std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator
Hi, compiling tramp3d with -fwhole-program leads to: /home/jh/gcc-install/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64/libstdc++.a(sstream-inst.o): In function `std::basic_stringbuf, std::allocator >::str() const': /home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:129: undefined reference to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' /home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:127: undefined reference to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' /home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:129: undefined reference to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' /home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:127: undefined reference to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' /home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:129: undefined reference to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' /home/jh/gcc-install/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64/libstdc++.a(sstream-inst.o):/home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:127: more undefined references to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' follow I suppose this is because normally tramp3d exports the function as comdat and as a result of -fwhole-program we bring it local (since we know address is not taken and making it local enable more optimization) while libstdc++ reference the function but does not provide COMDAT version of it. I think this is not valid, or is this C++ ABI feature? -- Summary: libstdc++ seems to miss std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hubicka at gcc dot gnu dot org GCC host triplet: x86_64-linux GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42033
[Bug c++/42032] Aliasing errors in stl_tree.h
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-13 19:25 --- Might be related to PR 39390. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42032
[Bug bootstrap/42030] collect2: ld returned 1 exit status
--- Comment #2 from michael dot a dot richmond at nasa dot gov 2009-11-13 19:34 --- The version of binutils provided by Debian is not the latest: mrich...@msc545ux:~$ ld --version GNU ld (GNU Binutils for Debian) 2.18.0.20080103 Copyright 2007 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42030
[Bug c++/42032] Aliasing errors in stl_tree.h
--- Comment #2 from craig dot schlenter at gmail dot com 2009-11-13 19:34 --- (In reply to comment #1) > Might be related to PR 39390. Would it be possible for someone to test the code from the description section with trunk please .. if error messages were removed, the problem should be gone :) I unfortunately don't have easy access to a more modern gcc than 4.4.0 to test with. Thank you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42032
[Bug middle-end/42025] [4.5 Regression] ICE verify_stmts failed (non-trivial conversion at assignment)
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-11-13 19:34 ---
Yep, this is definitely mine. Even though I have a fix for the above
testcase, it unfortunately does not work for my all-time favorite
one-filed structures, e.g.:
typedef struct
{
void *p;
} Ptr;
struct A
{
int i;
union
{
Ptr p;
char *q;
} u;
};
extern Ptr get_stuff (void);
extern void use_stuff (char *);
static void foo(struct A p, char *q)
{
if (p.i)
p.u.p = get_stuff ();
else
p.u.q = q;
use_stuff (p.u.q);
}
void bar(struct A *p, char *q)
{
foo(*p, q);
}
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|rguenth at gcc dot gnu dot |jamborm at gcc dot gnu dot
|org |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42025
[Bug c++/42032] Aliasing errors in stl_tree.h
--- Comment #3 from evan at chromium dot org 2009-11-13 19:49 ---
I brought this up on the Google-internal C list. They reduced it further:
$ cat main.cc
#include
int main(void)
{
typedef std::map MyMap2;
MyMap2 map2_;
MyMap2::iterator map_iter2 = map2_.find(5);
return *map_iter2->second;
}
$ g++ -O3 -Wall -c main.cc
main.cc: In function 'int main()':
main.cc:8: warning: dereferencing pointer '' does break
strict-aliasing rules
/opt/local/include/gcc44/c++/bits/stl_tree.h:179: note: initialized from here
$ g++ -v
Using built-in specs.
Target: i386-apple-darwin9
Configured with: ../gcc-4.4.1/configure --prefix=/opt/local
--build=i386-apple-darwin9
--enable-languages=c,c++,objc,obj-c++,java,fortran
--libdir=/opt/local/lib/gcc44 --includedir=/opt/local/include/gcc44
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-mp-4.4
--with-gxx-include-dir=/opt/local/include/gcc44/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local
Thread model: posix
gcc version 4.4.1 (GCC)
--
evan at chromium dot org changed:
What|Removed |Added
CC||evan at chromium dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42032
[Bug target/41900] call *%esp shouldn't be generated because of CPU errata
--- Comment #8 from uros at gcc dot gnu dot org 2009-11-13 19:52 --- Subject: Bug 41900 Author: uros Date: Fri Nov 13 19:51:52 2009 New Revision: 154171 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154171 Log: 2009-11-13 Uros Bizjak PR target/41900 (*call_pop_1, *call_1, *call_value_pop_1, *call_value_1): Use "lsm" as operand 1 constraint. * config/i386/predicates.md (call_insn_operand): Depend on index_register_operand to avoid %esp register. 2009-11-13 Uros Bizjak Revert: 2009-11-05 Uros Bizjak PR target/41900 * config/i386/i386.h (ix86_arch_indices) : New. (TARGET_CALL_ESP): New define. * config/i386/i386.c (initial_ix86_tune_features): Initialize X86_ARCH_CALL_ESP. * config/i386/i386.md (*call_pop_1_esp, *call_1_esp, *call_value_pop_1_esp, *call_value_1_esp): Rename from *call_pop_1, *call_1, *call_value_pop_1 and *call_value_1. Depend on TARGET_CALL_ESP. (*call_pop_1, *call_1, *call_value_pop_1, *call_value_1): New patterns, use "lsm" as operand 1 constraint. * config/i386/predicates.md (call_insn_operand): Depend on index_register_operand for !TARGET_CALL_ESP to avoid %esp register. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/i386/i386.c branches/gcc-4_3-branch/gcc/config/i386/i386.h branches/gcc-4_3-branch/gcc/config/i386/i386.md branches/gcc-4_3-branch/gcc/config/i386/predicates.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41900
[Bug c++/42032] Aliasing errors in stl_tree.h
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-11-13 19:54 --- It may be related to PR41316, I suspected that the library might contain similar patterns in other containers besides forward_list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42032
[Bug bootstrap/42030] collect2: ld returned 1 exit status
--- Comment #3 from michael dot a dot richmond at nasa dot gov 2009-11-13 19:56 --- The error was caused by a full disk. I apologize for wasting your time. -- michael dot a dot richmond at nasa dot gov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42030
[Bug c++/42032] Aliasing errors in stl_tree.h
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-11-13 20:02 --- There are definitely a lot of casts like static_cast<_Link_type>(_M_node) in stl_list.h. If _M_node is ever not a rb_tree_node but only a rb_tree_node_base (which probably is the case again for the head of the tree) then this is an alias violation. Note that 4.5 will no longer warn for this because I removed the warning code as it wasn't aware of the concept of C++ dynamic types and thus lead to many false positives. There is no replacement for it, so you'll need to do code review to catch all cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42032
[Bug c++/13950] [DR176] lookup of dependent base name
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-04-16 16:40:38 |2009-11-13 20:08:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13950
[Bug c++/42033] libstdc++ seems to miss std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator
--- Comment #1 from jason at gcc dot gnu dot org 2009-11-13 20:08 --- libstdc++ does define that function, in string-inst.cc. And it shouldn't be defined anywhere else. I don't know what would be causing that error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42033
[Bug c++/42034] New: "'type name' declared as function returning a function" with operator()
The program below demonstrates an incorrect error on an expression involving
operator(). The error incorrectly reported is "error: 'type name' declared as
function returning a function".
#include
struct T {
int operator()(int) const { printf("hello\n"); return 1; }
};
int main()
{
if ( T()(int()) ) ; // OK, no error
if ((T()(int( ; // incorrect error on this line
return 0;
}
--
Summary: "'type name' declared as function returning a function"
with operator()
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sc09q4 at bullseye dot com
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42034
[Bug c++/42034] "'type name' declared as function returning a function" with operator()
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-13 20:21 --- I don't think this is a bug. There is an ambiguous in the syntax in figuring out if T() (int()) is a function declaration or a calling the operator() on a newly created T. The C++ standard resolves it as being a function declaration which is why you are getting an error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42034
[Bug debug/41988] [4.5 Regression] FAIL: g++.dg/debug/*.C -gdwarf-2 -g1 (internal compiler error)
--- Comment #6 from hjl dot tools at gmail dot com 2009-11-13 20:22 --- (In reply to comment #4) > (In reply to comment #3) > > Is this a regression or a new test? They are OK on Linux. > > > > BTW, stack alignment was checked in a long time ago. > > The tests are old, they are from 2003 :). > The patch which I was talking about was: > 2009-10-30 H.J. Lu > Well, revision 152615: http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00264.html was on 2009-10-10, which was before my patch. I don't see how my patch on 2009-10-30 is the cause :-(. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41988
[Bug debug/41988] [4.5 Regression] FAIL: g++.dg/debug/*.C -gdwarf-2 -g1 (internal compiler error)
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-11-13 20:31 --- Well I know it appeared between revision 152380 and 153960. I don't have a narrower revision right now though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41988
[Bug debug/41988] [4.5 Regression] FAIL: g++.dg/debug/*.C -gdwarf-2 -g1 (internal compiler error)
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-11-13 20:35 --- The only other change that might have caused it as far as I can tell is the IFC changes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41988
[Bug c++/42033] libstdc++ seems to miss std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-13 20:37 --- It's normally exported from the *.so, just grep it: 000a90d0 W std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42033
[Bug debug/41988] [4.5 Regression] FAIL: g++.dg/debug/*.C -gdwarf-2 -g1 (internal compiler error)
--- Comment #9 from hjl dot tools at gmail dot com 2009-11-13 20:38 --- (In reply to comment #7) > Well I know it appeared between revision 152380 and 153960. I don't have a > narrower revision right now though. > Please read Since at least revision 152615, I see the following failures on i686-apple-darwin9 in 32 bit mode (see http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00699.html): in THIS bug report. So you can narrow it down to between revision 152380 and 152615. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41988
[Bug debug/41988] [4.5 Regression] FAIL: g++.dg/debug/*.C -gdwarf-2 -g1 (internal compiler error)
--- Comment #10 from dominiq at lps dot ens dot fr 2009-11-13 20:43 --- > So you can narrow it down to between revision 152380 and 152615. My bracket is 152431 (no failures) and 152615 (failures). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41988
[Bug c++/42032] Aliasing errors in stl_tree.h
--- Comment #6 from paolo dot carlini at oracle dot com 2009-11-13 20:51 --- Note that, as far as I have been told by Richard, the warning itself doesn't point to an actual miscompilation in 4.4, because (PRE, etc.) aren't strong enough. Thus, first people should double check that, and in case we could backport to 4.4. the warning suppression bits (in any case, that warnings are emitted from system headers is a bug, per se). Then, as regards mainline, we should, again, check whether actual miscompilations are taking place, I'm not aware of any. At the time of PR41316, I went quickly through the code and didn't find any problematic series of up and down casts outside (the still very experimental, I'm working on it while we are speaking) forward_list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42032
[Bug c++/42035] New: libstdc++ seems to miss std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator
Hi, compiling tramp3d with -fwhole-program leads to: /home/jh/gcc-install/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64/libstdc++.a(sstream-inst.o): In function `std::basic_stringbuf, std::allocator >::str() const': /home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:129: undefined reference to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' /home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:127: undefined reference to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' /home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:129: undefined reference to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' /home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:127: undefined reference to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' /home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:129: undefined reference to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' /home/jh/gcc-install/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64/libstdc++.a(sstream-inst.o):/home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:127: more undefined references to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' follow I suppose this is because normally tramp3d exports the function as comdat and as a result of -fwhole-program we bring it local (since we know address is not taken and making it local enable more optimization) while libstdc++ reference the function but does not provide COMDAT version of it. I think this is not valid, or is this C++ ABI feature? -- Summary: libstdc++ seems to miss std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hubicka at gcc dot gnu dot org GCC host triplet: x86_64-linux GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42035
[Bug c++/42036] New: libstdc++ seems to miss std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator
Hi, compiling tramp3d with -fwhole-program leads to: /home/jh/gcc-install/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64/libstdc++.a(sstream-inst.o): In function `std::basic_stringbuf, std::allocator >::str() const': /home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:129: undefined reference to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' /home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:127: undefined reference to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' /home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:129: undefined reference to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' /home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:127: undefined reference to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' /home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:129: undefined reference to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' /home/jh/gcc-install/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64/libstdc++.a(sstream-inst.o):/home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:127: more undefined references to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' follow I suppose this is because normally tramp3d exports the function as comdat and as a result of -fwhole-program we bring it local (since we know address is not taken and making it local enable more optimization) while libstdc++ reference the function but does not provide COMDAT version of it. I think this is not valid, or is this C++ ABI feature? -- Summary: libstdc++ seems to miss std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hubicka at gcc dot gnu dot org GCC host triplet: x86_64-linux GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42036
[Bug c++/42033] libstdc++ seems to miss std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator
--- Comment #3 from hubicka at ucw dot cz 2009-11-13 21:01 --- Subject: Re: libstdc++ seems to miss std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&) This fails with --static only: j...@gcc17:~/gcc-install/lib64$ nm -C libstdc++.so | less j...@gcc17:~/gcc-install/lib64$ fgrep 'std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' j...@gcc17:~/gcc-install/lib64$ nm -C libstdc++.so | fgrep 'std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' 000a3bf0 W std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&) 000a3a50 W std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&) j...@gcc17:~/gcc-install/lib64$ nm -C libstdc++.a | fgrep 'std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' U std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&) U std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&) W std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&) W std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&) j...@gcc17:~/trunk/build5$ ~/gcc-install/bin/g++ a.o --static /home/jh/gcc-install/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64/libstdc++.a(sstream-inst.o): In function `std::basic_stringbuf, std::allocator >::str() const': /home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:129: undefined reference to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' /home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:127: undefined reference to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' /home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:129: undefined reference to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' /home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:127: undefined reference to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' /home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:129: undefined reference to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' /home/jh/gcc-install/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64/libstdc++.a(sstream-inst.o):/home/jh/trunk/build5/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:127: more undefined references to `std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' follow collect2: ld returned 1 exit status j...@gcc17:~/trunk/build5$ ~/gcc-install/bin/g++ a.o j...@gcc17:~/trunk/build5$ LD_LIBRARY_PATH=/home//jh/gcc-install/lib64/:$LD_LIBRARY_PATH ./a.out Usage: tramp3d-v4 --help|-h|-?show this command line help --num-iter|-n number of iterations to perform [Inf] --end-t|-t time to stop simulation [Inf] --cfl cfl number [0.6] --dtconstant timestep, used with cfl number [off] --min-dtminimum timestep allowed --max-dtmaximum timestep allowed --blocks nx ny nz processor setup [automatic] --cartvis nr av artificial viscosity NR AV [off] --eos n choose eos --rhomin rhodensity floor [off] --blocking-expressions set blocking expressions [off] --domain x y z computational vertex domain [64x64x64] A particularly benchmarky and checky command-line includes both artificial viscosity and density minimum via f.i. ./tramp3d-v4 --cartvis 1.0 0.0 --rhomin 1e-8 (reverse-i-search)`fg': fg j...@gcc17:~/trunk/build5$ nm -C a.o | fgrep 'std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)' t std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&) j...@gcc17:~/trunk/build5$ Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42033
[Bug c++/42034] "'type name' declared as function returning a function" with operator()
--- Comment #2 from sc09q4 at bullseye dot com 2009-11-13 21:04 --- Let's look at these tokens "T()(int())" in detail. (1) Yes "T()" looks like a function declarator: T()(int()) 111 (2) Then follows something in parenthesis, which looks a lot like C++03 direct-declarator rule #2, also indicating a function declarator: T()(int()) 1112 2 (3) But what about the tokens inside those parenthesis - "int()"? That is not a valid parameter-declaration-clause: T()(int()) 111232 So these tokens do not form a declarator at all. The problem is not semantic but rather syntactic. (4) Now consider the context. The tokens above, appear inside an if-statement, inside extra parenthesis: if (( T()(int()) )) 44 44 111232 44 There is no C++ grammar rule that allows a declarator inside "if(( ))". It must be an expression. Now consider the discrepancy of how GCC handles these two statements: if ( T()(int()) ) ; if ((T()(int( ; The first compiles successfully. The tokens in the if-statement condition are understood as an expression. But in the second statement, an error is reported. But the only difference is that expression is parenthesized. Merely parenthesizing an expression ought not cause a compiler to complain that expression is not a valid type. Still not convinced? Consider the behavior of some other compilers. I tested with Microsoft C++ v15, Intel C++ v9, PC-Lint v9, and GCC v3.4.6. They all compile this program without error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42034
[Bug c++/42034] "'type name' declared as function returning a function" with operator()
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-13 21:07 --- *** This bug has been marked as a duplicate of 29234 *** -- 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=42034
[Bug c++/29234] Call to operator() of temporary object wrongly parsed
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-13 21:07 --- *** Bug 42034 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||sc09q4 at bullseye dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29234
[Bug c++/42033] libstdc++ seems to miss std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator
--- Comment #4 from paolo dot carlini at oracle dot com 2009-11-13 21:10 --- I see. Seems a compiler problem indeed, because, as Jason mentioned, the template is explicitly instantiated in string-inst.cc and marked to be exported in the linker script for the *.so. I have no idea what libstdc++ could do to fix this... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42033
[Bug middle-end/42025] [4.5 Regression] ICE verify_stmts failed (non-trivial conversion at assignment)
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-11-13 21:13 --- Created an attachment (id=19012) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19012&action=view) Proposed fix. Proposed fix I am currently bootstrapping. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42025
[Bug c++/42033] libstdc++ seems to miss std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator
--- Comment #5 from hubicka at ucw dot cz 2009-11-13 21:16 --- Subject: Re: libstdc++ seems to miss std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&) > I see. Seems a compiler problem indeed, because, as Jason mentioned, the > template is explicitly instantiated in string-inst.cc and marked to be > exported > in the linker script for the *.so. I have no idea what libstdc++ could do to > fix this... I am confused why I get link error given that even my *.a exports the symbol... Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42033
