[Bug c++/38761] %s substituted with regular word can't be properly translated
--- Comment #4 from pearly dot zhao at oracle dot com 2009-11-12 08:07 --- The two messages are be split up with and without "template" already at the current trunk. I think it was fixed at revision 149277. Can this bug be closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38761
[Bug fortran/42016] New: default initialization of derived type component not allowed in pure subroutine
gfortran rejects the following code because gfortran -c mod_xyz.f90 mod_xyz.f90:9.42: type(ilist), pointer :: next => null() 1 Error: Initialization of pointer at (1) is not allowed in a PURE procedure My understanding however is that the code is legal (please, see also http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/141265154c2fcc71/628a3487e60395b9?hl=en#628a3487e60395b9 ) gfortran --version GNU Fortran (GCC) 4.5.0 20091105 (experimental) module mod_xyz implicit none contains pure subroutine psub() type ilist type(ilist), pointer :: next => null() integer :: i end type ilist end subroutine psub end module mod_xyz -- Summary: default initialization of derived type component not allowed in pure subroutine Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mrestelli at gmail dot com GCC build triplet: GNU Fortran (GCC) 4.5.0 20091105 (experimental) GCC host triplet: x86_64 AMD Turion(tm) 64 Mobile Technology ML-32 AuthenticAMD GN http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42016
[Bug other/39979] possible wrong code at -O0.
--- Comment #1 from pluto at agmk dot net 2009-11-12 10:39 --- empty thread on libc-help: http://sourceware.org/ml/libc-help/2009-10/msg00043.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39979
[Bug fortran/42016] default initialization of derived type component not allowed in pure subroutine
--- Comment #1 from burnus at gcc dot gnu dot org 2009-11-12 11:21 --- I agree that there is a bug. Especially, that it works as use-/host-associated TYPE declaration but not as local type declaration is wrong. Based on your report and Bader's reply in comp.lang.fortran, I have already filled a PR - though I forgot to reply and state this at the news group. As there is already a report, I mark yours as duplicate of the other. Thanks for reporting! *** This bug has been marked as a duplicate of 42008 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42016
[Bug fortran/42008] Wrongly rejected derived types with default initializers in PURE procedures
--- Comment #2 from burnus at gcc dot gnu dot org 2009-11-12 11:21 --- *** Bug 42016 has been marked as a duplicate of this bug. *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||mrestelli at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42008
[Bug libffi/41908] closures fail for some structure arguments containing floats
--- Comment #4 from rfm at gnu dot org 2009-11-12 11:48 --- I'm a bit disappointed at the lack of activity on this bug report. I've been looking at the libffi code myself (though I'm certainly no expert at this low-level stuff) and have come up with two issues: 1. If I edit libffi-3.0.9rc3/src/x86/ffi64.c and comment out the condition || (n == 2 && SSE_CLASS_P (classes[0]) == SSE_CLASS_P (classes[1])) in ffi_closure_unix64_inner() then this bug goes away (and the change does not appear to break anything in the testsuite). Perhaps someone who understands this stuff could look at this and see why this change appears to fix things (and what it might be breaking). 2. In the classify_argument() function in the same file, there is a comment which reads: /* X86_64_X87UP_CLASS should be preceded by X86_64_X87_CLASS. */ This doesn't match what the code does ... perhaps the code needs to be changed to match the comment... classes[i] = X86_64_X87_CLASS; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41908
[Bug c/42017] New: gcc compiling C for ARM has stopped using r14 in leaf functions?
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).
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;r2http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42017
[Bug lto/41836] LTO and profile-generate is broken
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-11-12 12:34 --- Works for me now with -flto and -fwhopr. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41836
[Bug c++/42018] New: Accepts definition for non-anonymous specialized template method within anonymous namespace
The following code should fail to compile due to ambiguity (the non-template
case properly fails):
template
void foo(void);
template<>
void foo(void);
namespace {
template<>
void foo(void) { return; }
}
int main(int, char **) { foo(); }
--
Summary: Accepts definition for non-anonymous specialized
template method within anonymous namespace
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Simon dot Richter at hogyros dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42018
[Bug tree-optimization/41735] [4.5 Regression] inlined comdat function sometimes is emitted
--- Comment #5 from hubicka at gcc dot gnu dot org 2009-11-12 12:37 --- Fixed by my patch. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41735
[Bug middle-end/41729] Undefined reference with -fPIC -fwhole-program -flto
--- Comment #3 from hubicka at gcc dot gnu dot org 2009-11-12 12:42 --- Fixed by my patch. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41729
[Bug tree-optimization/41589] lto does not eliminate unused variables
--- Comment #8 from hubicka at gcc dot gnu dot org 2009-11-12 13:23 --- There are some bugs on LTO and unused vars elimination, but in this testcase we end up with: main: .LFB2: subq$8, %rsp .LCFI0: movly(%rip), %esi movl$.LC0, %edi xorl%eax, %eax addl$5, %esi movl%esi, y(%rip) callprintf xorl%eax, %eax addq$8, %rsp .LCFI1: ret .LFE2: While GCC might be able to recognize that main is not reentrant and thus computing the static variable is useless, this is bit tricky to do. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41589
[Bug c++/42018] Accepts definition for non-anonymous specialized template method within anonymous namespace
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-12 13:24 ---
It should fail to compile because you are specializing a template which was
never declared, not because it is ambiguous.
namespace {
template<>
void foo(void) { return; }
}
That is a specialization, but there is no matching primary template.
This fails due to ambiguous overloads:
template
void foo(void);
template<>
void foo(void);
namespace {
template
void foo(void) { return; }
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42018
[Bug c++/42018] Accepts definition for non-anonymous specialized template method within anonymous namespace
--- Comment #2 from redi at gcc dot gnu dot org 2009-11-12 13:28 ---
This fails:
template
void foo(void);
template<>
void foo(void);
namespace {
template<>
void foo(void) { return; }
}
int main(int, char **) { foo(); }
ttt.cc:6: error: specialization of 'template void foo()' in different
namespace
ttt.cc:2: error: from definition of 'template void foo()'
But if a valid specialization already exists, the one in the anon namespace is
not rejected. That's a bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42018
[Bug fortran/41936] Memory leakage with allocatables and user-defined operators
--- Comment #1 from pault at gcc dot gnu dot org 2009-11-12 13:50 ---
The testcase segfaults on the a = a + b and the c = c + d on Cygwin. On FC8
i386, valgrind does not show any problem with either and the testprogramme runs
to completion!
However, moving a = a + b to subroutine foo and c = c+ d to subroutine bar
isolates the source of the problem.
bar ()
{
{
integer(kind=4) S.23;
S.23 = 1;
while (1)
{
if (S.23 > 3) goto L.11;
{
struct my_type D.1542;
D.1542 = my_add (&c[S.23 + -1], &d[S.23 + -1]);
my_assign (&c[S.23 + -1], &D.1542);
}
S.23 = S.23 + 1;
}
L.11:;
}
}
foo ()
{
{
struct my_type D.1547;
D.1547 = my_add (&a, &b);
my_assign (&a, &D.1547);
if (D.1547.x.data != 0B)
{
__builtin_free ((void *) D.1547.x.data);
}
D.1547.x.data = 0B;
if (D.1547.y.data != 0B)
{
__builtin_free ((void *) D.1547.y.data);
}
D.1547.y.data = 0B;
if (D.1547.z.data != 0B)
{
__builtin_free ((void *) D.1547.z.data);
}
D.1547.z.data = 0B;
}
}
Most of the right allocating and freeing goes on in 'my_add' and 'my_assign'.
However, whilst 'foo' (scalar) frees the allocatable components of the
temporary D.1547, the same is not true for D.1542 in 'bar' (array).
This loses (n = 3) x (4 bytes) x (3 components) x (dim = 10) = 360 bytes.
The problem, therefore, lies in the scalarization of the elemental call to
'my_add', where the deallocation of the temporary goes walkabout. If I would
hazard a guess, without looking, I would say that the post-block for the scalar
assignment has not been incorporated in the loop body.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-11-12 13:50:59
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41936
[Bug fortran/39334] Recusive parameter kind produces segfault
--- Comment #3 from pault at gcc dot gnu dot org 2009-11-12 13:53 --- I forgot to mark this as fixed. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39334
[Bug libstdc++/42019] New: shared_ptr can not be used with -fno-rtti
The shared_ptr implementation uses typeid and therefore fails to compile with
-fno-rtti.
Perhaps the functionality can be reduced by #ifdef __GCC_RTTI?
testcase:
#include
using namespace std::tr1;
class A {};
int main()
{
shared_ptr spA;
}
gcc info:
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/gcctrunk/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/tom/svn/gcc/configure --prefix=/opt/gcctrunk
--disable-sjlj-exceptions : (reconfigured) /home/tom/svn/gcc/configure
--prefix=/opt/gcctrunk --disable-sjlj-exceptions
Thread model: posix
gcc version 4.5.0 20091105 (experimental) (GCC)
--
Summary: shared_ptr can not be used with -fno-rtti
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tom dot deseyn at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42019
[Bug driver/42007] Make -mfloat-gprs=double the default when compiling for powerpc-linux-gnuspe target
--- Comment #4 from oakad at yahoo dot com 2009-11-12 15:09 --- Indeed so. I've read a roadmap for e200 just minutes after my previous post. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42007
[Bug tree-optimization/41879] [4.5 Regression] 172.mgrid regression, vectorizer prevents predictive commoning
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-11-12 15:17 --- The idea is to call predcom analysis and hook it into the vectorizer as another vectorization form for the cost model. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41879
[Bug middle-end/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c
--- Comment #11 from ro at techfak dot uni-bielefeld dot de 2009-11-12 16:46 --- Subject: Re: [4.5 regression] cc1 SEGV compiling maxval_r16.c Bootstrap finishes with your patch on alpha-dec-osf5.1b; the testsuite is still running. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41930
[Bug libstdc++/42019] shared_ptr can not be used with -fno-rtti
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-12 17:03 --- Seems like a reasonable request, it will disable at least the get_deleter() functionality. I'll work on this when I update shared_ptr to match the latest WP -- redi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |redi at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-12 17:03:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42019
[Bug lto/42020] New: field not merged causes cc1 to be miscompiled
Reducing a cc1 miscompilation when using lto I noticed that the problem was nonoverlapping_component_refs_p returning true because we had two different field_decls for the succs field in basic_block. Rich asked me to put an assert that the field is being merged and reduce more using that assert. To reproduce the issue: *) patch gcc to add the assert *) cc1 -quiet -O2 -flto cfgrtl.i -o cfgrtl.s *) as cfgrtl.s -o cfgrtl.o *) lto1 -quiet -O2 cfgrtl.o -o foo.s -- Summary: field not merged causes cc1 to be miscompiled Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: espindola at gcc dot gnu dot org GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42020
[Bug lto/42020] field not merged causes cc1 to be miscompiled
--- Comment #1 from espindola at gcc dot gnu dot org 2009-11-12 17:05 --- Created an attachment (id=19005) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19005&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42020
[Bug lto/42020] field not merged causes cc1 to be miscompiled
--- Comment #2 from espindola at gcc dot gnu dot org 2009-11-12 17:05 --- Created an attachment (id=19006) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19006&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42020
[Bug translation/40872] String not extracted for translation
--- Comment #19 from joseph at codesourcery dot com 2009-11-12 17:20
---
Subject: Re: String not extracted for translation
On Thu, 12 Nov 2009, pearly dot zhao at oracle dot com wrote:
> Run "make gcc.pot" in objdir/gcc/ can extract both branches of this
> conditional
> expression. That is to say, the ("declared") line is also include at
> objdir/gcc/gcc.pot.
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?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug gcov-profile/42015] gcov reports incorrect branches executed
--- Comment #1 from frodak17 at gmail dot com 2009-11-12 17:21 --- I would have expected the output to report: Branches executed:75.00% of 4 and not Branches executed:100.00% of 4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42015
[Bug target/30315] optimize unsigned-add overflow test on x86 to use cpu flags from addl
--- Comment #18 from jparmele at wildbear dot com 2009-11-12 17:28 --- This bug also still appears in 4.4.2 with --with-arch=pentium3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30315
[Bug lto/42020] field not merged causes cc1 to be miscompiled
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-12 17:52 --- I will have a looksee. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-12 17:52:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42020
[Bug rtl-optimization/38582] excessive time in rename registers
--- Comment #4 from bernds at gcc dot gnu dot org 2009-11-12 18:12 --- Subject: Bug 38582 Author: bernds Date: Thu Nov 12 18:12:09 2009 New Revision: 154123 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154123 Log: PR rtl-opt/38582 * regrename.c (struct du_head): New structure; some elements moved from... (struct du_chain): ... this one. (open_chains, closed_chains): Now of type struct du_head *. (do_replace): Accept du_head argument, not du_chain. All callers changed. Modified code to match new data structures. (build_def_use): Return a list of du_head structures. Modified code to match new data structures. (dump_def_use_chain): Accept du_head argument, not du_chain. All callers changed. Modified code to match new data structures. (merge_overlapping_regs): Accept du_head argument, not du_chain. All callers changed. Modified code to match new data structures. (scan_rtx_reg): Change type of this_regno and this_nregs to unsigned. Allocate a du_head structure as well as a du_chain when creating a new chain. Modified other code to match new data structures. Modified: trunk/gcc/ChangeLog trunk/gcc/regrename.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38582
[Bug c++/42013] cv-qualification of conditional expression type depending on the value of its first expression?!?
--- Comment #4 from jason at gcc dot gnu dot org 2009-11-12 18:26 --- Subject: Bug 42013 Author: jason Date: Thu Nov 12 18:25:42 2009 New Revision: 154124 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154124 Log: PR c++/42013 * call.c (build_conditional_expr): Don't fold a TREE_SIDE_EFFECTS COND_EXPR in unevaluated context. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype19.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42013
[Bug c++/42013] cv-qualification of conditional expression type depending on the value of its first expression?!?
--- Comment #5 from paolo dot carlini at oracle dot com 2009-11-12 18:47 --- Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42013
[Bug c++/42013] cv-qualification of conditional expression type depending on the value of its first expression?!?
--- Comment #6 from jason at gcc dot gnu dot org 2009-11-12 20:26 --- Subject: Bug 42013 Author: jason Date: Thu Nov 12 20:26:36 2009 New Revision: 154129 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154129 Log: PR c++/42013 * call.c (build_conditional_expr): Check specifically for folding to CALL_EXPR rather than TREE_SIDE_EFFECTS. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/g++.dg/cpp0x/decltype19.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42013
[Bug c++/42013] cv-qualification of conditional expression type depending on the value of its first expression?!?
--- Comment #7 from jason at gcc dot gnu dot org 2009-11-12 20:27 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42013
[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|minor |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42017
[Bug c++/42021] New: Misleading error message when inheirited typedefs cause ambiguitiy
The following test case shows code that all compilers seem to reject, but G++
(I've tried several versions) gives a confusing error message.
Here are the error messages given by various compilers:
Visual C++ v8:
>sourceFile.cpp(27) : error C2385: ambiguous access of 'P3'
>could be the 'P3' in base 'C1'
>or could be the 'P3' in base 'B'
(The most clear and helpful error message of the bunch.)
Comeau/EDG:
>"sourceFile.cpp", line 27: error:
> "PolicySelector::P3" is ambiguous
> Policies::P3::doPrint();
>^
G++:
>sourceFile.cpp: In member
> function `void BreadSlicer::print()':
>sourceFile.cpp:27: no type
> named `P3' in `struct PolicySelector'
The G++ message is terribly misleading, since there is in fact not only one
type named P3 in struct PolicySelector, but more than one type with that name.
The code in question is:
BEGIN
struct Policy1 {
static void doPrint() {}
};
struct Policy2 {
static void doPrint() {}
};
struct B {
typedef Policy1 P3;
};
struct C1 : B {
typedef Policy2 P3;
};
struct C2 : B {
};
struct PolicySelector: C1, C2 {
};
struct BreadSlicer {
typedef PolicySelector Policies;
void print () {
Policies::P3::doPrint();
}
};
int main()
{
BreadSlicer bc2;
bc2.print();
}
-END-
--
Summary: Misleading error message when inheirited typedefs cause
ambiguitiy
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: unknown_kev_cat at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42021
[Bug c++/38761] %s substituted with regular word can't be properly translated
--- Comment #5 from goeran at uddeborg dot se 2009-11-12 21:14 --- I took a look at the code in the web svn. The messages as such look fine now. They should be readily translatable. But I don't think xgettext will pick up both strings for translation, when the argument is a conditional expression like that. At least not in a simple test case I made. Only the first string was extracted. But maybe you run xgettext in some more advanced way in the gcc framework? Otherwise, some markers for gettext are probably also necessary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38761
[Bug c++/36406] [4.3/4.4/4.5 regression] ICE with template delete operator
--- Comment #8 from jason at gcc dot gnu dot org 2009-11-12 22:05 --- Fixed for 4.5, not backporting fix for invalid-code bug. -- 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=36406
[Bug c++/37037] [4.3/4.4/4.5 Regression] ICE on template class member function definition after explicit template class instantation
-- 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 Keywords|ice-on-invalid-code |ice-on-valid-code Last reconfirmed|2009-04-16 16:30:01 |2009-11-12 22:17:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37037
[Bug c++/39055] [4.3/4.4/4.5 regression] ICE with questionable default parameter of a member function
--- Comment #9 from jason at gcc dot gnu dot org 2009-11-12 22:47 --- Created an attachment (id=19007) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19007&action=view) patch This patch makes G++ reject the testcase. But I don't see the utility in rejecting it, and since EDG also accepts it I'm raising an issue with the C++ committee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39055
[Bug c++/37037] [4.3/4.4/4.5 Regression] ICE on template class member function definition after explicit template class instantation
--- Comment #8 from jason at gcc dot gnu dot org 2009-11-12 22:50 --- Subject: Bug 37037 Author: jason Date: Thu Nov 12 22:49:59 2009 New Revision: 154131 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154131 Log: PR c++/37037 * decl.c (grokdeclarator): Don't generate a void PARM_DECL. Added: trunk/gcc/testsuite/g++.dg/template/typedef21.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37037
[Bug c++/39560] [4.3/4.4/4.5 Regression] Erroneous warnings 'unused variable' in a templated class method with union
-- 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 21:05:19 |2009-11-12 23:01:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39560
[Bug c++/40085] [4.5 Regression] ICE compiling libmudflap.c++/fail24-frag.cxx
--- Comment #5 from jason at gcc dot gnu dot org 2009-11-12 23:14 --- I'm not seeing this with a cross-compiler. Is it still broken? -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40085
[Bug c++/42022] New: takes segmentation fault at proxy file
/bin/sh ../../../libtool --silent --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../../include -I/usrclude -DBRLCADBUILD=1 -I../../../include -I../../../src/other/openNURBS -Wall -pipe -fno-strict-aliasiommon -fexceptions -g -O3 -c -o libopenNURBS_nil_la-opennurbs_curveproxy.lo `test -f 'opennurbs_curvepro| echo './'`opennurbs_curveproxy.cpp opennurbs_surfaceproxy.h:29: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See https://qa.mandriva.com/> for instructions. make[3]: *** [libopenNURBS_nil_la-opennurbs_curveproxy.lo] Error 1 make[3]: Leaving directory `/home/caelinux/Desktop/brlcad-7.14.8/brlcad-7.14.8/src/other/openNURBS' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/caelinux/Desktop/brlcad-7.14.8/brlcad-7.14.8/src/other' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/caelinux/Desktop/brlcad-7.14.8/brlcad-7.14.8/src' make: *** [all-recursive] Error 1 -- Summary: takes segmentation fault at proxy file Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kholt at joimail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42022
[Bug c++/39560] [4.3/4.4/4.5 Regression] Erroneous warnings 'unused variable' in a templated class method with union
--- Comment #3 from jason at gcc dot gnu dot org 2009-11-12 23:21 --- Subject: Bug 39560 Author: jason Date: Thu Nov 12 23:21:33 2009 New Revision: 154133 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154133 Log: PR c++/39560 * decl2.c (build_anon_union_vars): Set DECL_ARTIFICIAL. Added: trunk/gcc/testsuite/g++.dg/lookup/anon7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39560
[Bug c++/37037] [4.3/4.4/4.5 Regression] ICE on template class member function definition after explicit template class instantation
--- Comment #9 from jason at gcc dot gnu dot org 2009-11-12 23:22 --- Subject: Bug 37037 Author: jason Date: Thu Nov 12 23:21:55 2009 New Revision: 154134 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154134 Log: PR c++/37037 * decl.c (grokdeclarator): Don't generate a void PARM_DECL. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef21.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/decl.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37037
[Bug c++/37037] [4.3/4.4/4.5 Regression] ICE on template class member function definition after explicit template class instantation
--- Comment #10 from jason at gcc dot gnu dot org 2009-11-12 23:22 --- Subject: Bug 37037 Author: jason Date: Thu Nov 12 23:22:10 2009 New Revision: 154135 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154135 Log: PR c++/37037 * decl.c (grokdeclarator): Don't generate a void PARM_DECL. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/typedef21.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/decl.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37037
[Bug c++/42022] takes segmentation fault at proxy file
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-12 23:22 --- GCC 4.1.1 is no longer maintained, please update to at least GCC 4.3.4 and reproduce the problem there. We need preprocessed source to do anything about it if the bug reproduces there. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Summary|takes segmentation fault at |takes segmentation fault at |proxy file |proxy file http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42022
[Bug c++/39560] [4.3/4.4/4.5 Regression] Erroneous warnings 'unused variable' in a templated class method with union
--- Comment #4 from jason at gcc dot gnu dot org 2009-11-12 23:26 --- Fixed for 4.5. Let me know if you'd like it applied to a release branch as well. -- 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=39560
[Bug c++/37037] [4.3/4.4/4.5 Regression] ICE on template class member function definition after explicit template class instantation
--- Comment #11 from jason at gcc dot gnu dot org 2009-11-12 23:27 --- 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=37037
[Bug c++/39560] [4.3/4.4/4.5 Regression] Erroneous warnings 'unused variable' in a templated class method with union
--- Comment #5 from jason at gcc dot gnu dot org 2009-11-12 23:27 --- Fixed for 4.5. Let me know if you'd like it applied to a release branch as well. -- 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=39560
[Bug c++/27078] [4.3/4.4/4.5 Regression] Duplicate error message for ambiguous enum
-- 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-08-06 15:14:28 |2009-11-12 23:31:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27078
[Bug c++/40085] [4.5 Regression] ICE compiling libmudflap.c++/fail24-frag.cxx
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2009-11-12 23:33 --- Subject: Re: [4.5 Regression] ICE compiling libmudflap.c++/fail24-frag.cxx > --- Comment #5 from jason at gcc dot gnu dot org 2009-11-12 23:14 --- > I'm not seeing this with a cross-compiler. Is it still broken? This test is no longer failing on hppa-unknown-linux-gnu based on recent test results. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40085
[Bug lto/41932] LTO ICE when compiling ocaml trunk (incompatible type)
--- Comment #12 from hubicka at gcc dot gnu dot org 2009-11-12 23:52 --- When we use summaries at LTO as well as on WHOPR, we get better testing coverage for the summary streaming code, somewhat faster linktime (avoiding need to produce them) and we should make it possible for LTO to drag in function bodies on demand avoiding the problems with peak memory usage. At LTO it should be possible for IPA pass to compute missing summaries when needed, but we will need bit of infrastructure for it. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41932
[Bug c++/42022] takes segmentation fault at proxy file
--- Comment #2 from kholt at joimail dot com 2009-11-12 23:54 --- Subject: Re: takes segmentation fault at proxy file rguenth at gcc dot gnu dot org wrote: > --- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-12 23:22 > --- > GCC 4.1.1 is no longer maintained, please update to at least GCC 4.3.4 and > reproduce the problem there. We need preprocessed source to do anything > about it if the bug reproduces there. > > > You are quick! Who is watching? This is focal to what development? I can't get any compiler to get it on a 64 bit Intel/AMD how would Linux compile a variant when it can't do a fairly stable release? If the code seg faults anywhere in code execution why blame the compiler with a code dump? How can I upgrade if the compiler was broke? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42022
[Bug c++/27078] [4.3/4.4/4.5 Regression] Duplicate error message for ambiguous enum
--- Comment #13 from jason at gcc dot gnu dot org 2009-11-13 02:20 --- Subject: Bug 27078 Author: jason Date: Fri Nov 13 02:20:41 2009 New Revision: 154139 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154139 Log: PR c++/27078 * parser.c (cp_parser_primary_expression): Don't give a duplicate ambiguity error. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27078
[Bug c++/27078] [4.3/4.4/4.5 Regression] Duplicate error message for ambiguous enum
--- Comment #14 from jason at gcc dot gnu dot org 2009-11-13 02:21 --- 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=27078
[Bug c++/28501] ICE with __real__ and implicit type conversion
--- Comment #6 from paolo dot carlini at oracle dot com 2009-11-13 02:35 --- Not seriously working on this, unassigning (for now at least) -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28501
[Bug translation/40872] String not extracted for translation
--- Comment #20 from pearly dot zhao at oracle dot com 2009-11-13 03:41 --- (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? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug c++/38761] %s substituted with regular word can't be properly translated
--- Comment #6 from pearly dot zhao at oracle dot com 2009-11-13 03:44 --- I have run with gettext 0.14.6 not the latest one 0.17. Bug 40872 meet the same problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38761
spelling errors in comments
libstdc++-v3/libsupc++/cxxabi.h:167: * -1: A memory allocation failiure occurred. libiberty/dyn-string.c:339:/* Appends C to the end of DEST. Returns 1 on success. On failiure, s/failiure/failure/ Index: libstdc++-v3/libsupc++/cxxabi.h === --- libstdc++-v3/libsupc++/cxxabi.h (revision 154140) +++ libstdc++-v3/libsupc++/cxxabi.h (working copy) @@ -164,7 +164,7 @@ * * @param __status @a *__status is set to one of the following values: * 0: The demangling operation succeeded. - * -1: A memory allocation failiure occurred. + * -1: A memory allocation failure occurred. * -2: @a mangled_name is not a valid name under the C++ ABI mangling rules. * -3: One of the arguments is invalid. * Index: libiberty/dyn-string.c === --- libiberty/dyn-string.c (revision 154140) +++ libiberty/dyn-string.c (working copy) @@ -336,7 +336,7 @@ return 1; } -/* Appends C to the end of DEST. Returns 1 on success. On failiure, +/* Appends C to the end of DEST. Returns 1 on success. On failure, if RETURN_ON_ALLOCATION_FAILURE, deletes DEST and returns 0. */ int
[Bug c++/42023] New: Different exists with and without standard output.
Here is my code compiled with "g++ -Wall shell_sort.cpp"
The problem is that the result is different without the standard output in the
shell "shell_sort" function.
Would you please explain why this happens in my program?
#include
using namespace std;
void shell_sort(int *x, int m)
{
int h;
while (h > 0){
for (int i = 0; i < m; i++){
int temp = x[i], j = i;
while ((j >= h) && (x[j-h] > temp)){
x[j] = x[j - h];
j -= h;
}
x[j] = temp;
}
// cout << endl;
if ((h / 2) != 0){
h /= 2;
}else if (h == 1){
h = 0;
}else{
h = 1;
}
}
}
int main()
{
int *x = new int[10];
for (int i = 0; i < 10; i++){
x[i] = 30 - 3*i;
}
std::cout << "Original:" << std::endl;
for (int i = 0; i < 10; i++){
std::cout << x[i] << "\t";
}
std::cout << std::endl;
cout << "Output:"
[Bug c++/42023] Different exists with and without standard output.
--- Comment #1 from chenclf at gmail dot com 2009-11-13 04:09 --- Created an attachment (id=19008) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19008&action=view) the error occured without he the standard output line in the "shell_sort" function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42023
[Bug c++/42023] Different exists with and without standard output.
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-11-13 04:11 ---
int h;
while (h > 0){
You are using h as unitialized.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42023
[Bug c++/42023] Different exists with and without standard output.
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-13 04:12 --- And then h is unitialized through out the first iteration of the for loop too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42023
[Bug c++/40085] [4.5 Regression] ICE compiling libmudflap.c++/fail24-frag.cxx
--- Comment #7 from jason at gcc dot gnu dot org 2009-11-13 05:21 --- Appears to have been fixed at some point. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40085
[Bug c++/11987] [4.3/4.4/4.5 regression] Accepts-invalid with inherited nested type
-- 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|2005-09-04 18:20:23 |2009-11-13 05:26:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11987
[Bug c++/14777] [4.3/4.4/4.5 Regression] typedef doesn't fully expose base class type
--- Comment #13 from jason at gcc dot gnu dot org 2009-11-13 05:41 --- I'm assuming Mark isn't actually working on this bug. Dodji, this looks like something that the template typedef access control code you added for 4.5 could deal with, want to take a look? -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot ||org, dodji at gcc dot gnu ||dot org AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14777
[Bug middle-end/42024] New: [4.5 regression] Revision 154128 caused many failures
On Linux/ia32, revision 154128: http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00349.html caused: NEW g++.sum g++.dg/abi/mangle2.C NEW g++.sum g++.old-deja/g++.other/linkage6.C NEW objc.sum objc.dg/const-str-12.m NEW objc.sum objc.dg/const-str-5.m NEW objc.sum objc.dg/gnu-runtime-2.m NEW objc.sum objc/execute/string1.m NEW objc.sum objc/execute/string2.m NEW objc.sum objc/execute/string3.m NEW objc.sum objc/execute/string4.m -- Summary: [4.5 regression] Revision 154128 caused many failures Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42024
[Bug c++/21008] [4.3/4.4/4.5 Regression] [DR515] Access failure in accessing data member of base class from derived template class
-- 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-29 00:38:13 |2009-11-13 05:55:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008
[Bug c++/35075] [4.3/4.4/4.5 regression] ICE with references in templates
-- 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|2008-02-04 13:40:05 |2009-11-13 06:01:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35075
[Bug middle-end/42024] [4.5 regression] Revision 154128 caused many failures
--- Comment #1 from hp at gcc dot gnu dot org 2009-11-13 06:09 --- ...and cris-elf... -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42024
[Bug middle-end/42025] New: internal compiler error: verify_stmts failed (non-trivial conversion at assignment)
when compiling MONO from svn svn://anonsvn.mono-project.com/source/trunk/mono revision 146112 with GCC trunk gcc version 4.5.0 20091112 (experimental) [trunk revision 154129] I am getting the following errors aot-runtime.c: In function 'decode_patch': aot-runtime.c:3145:1: error: non-trivial conversion at assignment const char * void * # .MEM_174 = VDEF <.MEM_173> *ISRA.208_212(D) = D.32031_18; aot-runtime.c:3145:1: error: non-trivial conversion at assignment const char * void * # .MEM_204 = VDEF <.MEM_203> *ISRA.208_212(D) = D.32078_79; aot-runtime.c:3145:1: error: non-trivial conversion at assignment const char * void * # .MEM_210 = VDEF <.MEM_209> *ISRA.208_212(D) = D.32086_88; aot-runtime.c:3145:1: internal compiler error: verify_stmts failed -- Summary: internal compiler error: verify_stmts failed (non- trivial conversion at assignment) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bstarynk at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42025
[Bug middle-end/42025] internal compiler error: verify_stmts failed (non-trivial conversion at assignment)
--- Comment #1 from bstarynk at gcc dot gnu dot org 2009-11-13 07:44
---
Created an attachment (id=19009)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19009&action=view)
preprocessed testcase (bunzip2-ed)
The preprocessed testcase
gcc-trunk -O2 -c -v aot-runtime.i
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /usr/src/Lang/gcc-trunk-bstarynk/configure
--program-suffix=-trunk --libdir=/usr/local/lib/gcc-trunk
--libexecdir=/usr/local/libexec/gcc-trunk
--with-gxx-include-dir=/usr/local/lib/gcc-trunk/include/c++/ --disable-multilib
--enable-lto --enable-plugins --enable-maintainer-mode
--enable-languages=c,c++,lto --with-mpc=/usr/local : (reconfigured)
/usr/src/Lang/gcc-trunk-bstarynk/configure --program-suffix=-trunk
--libdir=/usr/local/lib/gcc-trunk --libexecdir=/usr/local/libexec/gcc-trunk
--with-gxx-include-dir=/usr/local/lib/gcc-trunk/include/c++/ --disable-multilib
--enable-lto --enable-plugins --enable-maintainer-mode
--enable-languages=c,c++,lto --with-mpc=/usr/local : (reconfigured)
/usr/src/Lang/gcc-trunk-bstarynk/configure --program-suffix=-trunk
--libdir=/usr/local/lib/gcc-trunk --libexecdir=/usr/local/libexec/gcc-trunk
--with-gxx-include-dir=/usr/local/lib/gcc-trunk/include/c++/ --disable-multilib
--enable-lto --enable-plugins --enable-maintainer-mode
--enable-languages=c,c++,lto --with-mpc=/usr/local
Thread model: posix
gcc version 4.5.0 20091112 (experimental) [trunk revision 154129] (GCC)
COLLECT_GCC_OPTIONS='-O2' '-c' '-v' '-mtune=generic'
/usr/local/libexec/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1
-fpreprocessed aot-runtime.i -quiet -dumpbase aot-runtime.i -mtune=generic
-auxbase aot-runtime -O2 -version -o /tmp/ccxTpmV7.s
GNU C (GCC) version 4.5.0 20091112 (experimental) [trunk revision 154129]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20091112 (experimental) [trunk revision
154129], GMP version 4.3.1, MPFR version 2.4.1-p2, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.5.0 20091112 (experimental) [trunk revision 154129]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20091112 (experimental) [trunk revision
154129], GMP version 4.3.1, MPFR version 2.4.1-p2, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 1e95f7c32b82e48df6050d90719a1024
aot-runtime.c: In function 'decode_patch':
aot-runtime.c:3145:1: error: non-trivial conversion at assignment
const char *
void *
# .MEM_174 = VDEF <.MEM_173>
*ISRA.208_212(D) = D.32031_18;
aot-runtime.c:3145:1: error: non-trivial conversion at assignment
const char *
void *
# .MEM_204 = VDEF <.MEM_203>
*ISRA.208_212(D) = D.32078_79;
aot-runtime.c:3145:1: error: non-trivial conversion at assignment
const char *
void *
# .MEM_210 = VDEF <.MEM_209>
*ISRA.208_212(D) = D.32086_88;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42025
[Bug c++/14777] [4.3/4.4/4.5 Regression] typedef doesn't fully expose base class type
--- Comment #14 from dodji at seketeli dot org 2009-11-13 07:55 --- Subject: Re: [4.3/4.4/4.5 Regression] typedef doesn't fully expose base class type > Dodji, this looks like something that the template typedef access control code > you added for 4.5 could deal with, want to take a look? Sure, I'll look at it. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14777
