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
--- 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-m
--- 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
--
nickpelling at nanodome dot com changed:
What|Removed |Added
Severity|normal |minor
GCC target triplet||ARM
http://g
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=nati
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 b
--- 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
--- 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=42
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;
}
--
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
--- 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 arg
--- 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
---
--- 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
--
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
--- 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
--- 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
--- 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 <
--- 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
--- 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
--- 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
Assigne
--
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
--- 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.or
--- 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
-
--- 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
--- 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 (fallthr
--- 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_s
--- 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_declar
--- 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): G
--- 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.
--- 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|ASSIG
--- 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
--- 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
--- 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 unc
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/i
--- 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.
--- 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|
--
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
--- 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_s
--- 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
---
--- 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 regre
--- 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
-
--- 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
--- 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
--- 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_
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-a
--- 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
--- 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
--- 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
--- 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
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
CC||lmillward at gcc dot gnu dot
|
--- 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
--- 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
--- 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):
--- 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|ASSI
--- 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_s
--- 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
--- 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
--
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
--- 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_p
--- 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_at
--- 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_at
--- 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):
--- 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
--- 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_
--- 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|REOP
--- 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|ASSIG
--- 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|ASSI
--- 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_p
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
--- 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
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/sstr
--- 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
--- 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 progra
--- 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
--- 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
{
i
--- 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 *m
--- 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_p
--- 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
--- 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
--- 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 t
--
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
--- 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
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()
{
--- 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 fu
--- 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 2
--- 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
--- 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
--- 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
--- 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 failur
--- 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
--- 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
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/sstr
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/sstr
--- 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...@gcc1
--- 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
--- 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
--
--- 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
---
--- 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 li
--- 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=42
--- 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
1 - 100 of 120 matches
Mail list logo
