--- 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 t
r/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
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: n
--- 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|
--
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
--
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
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 o
--- 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
--
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 #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
---
--- 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
--- 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
--
--- 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/bugzill
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
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
=
--- 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
--- 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
--- 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
--- 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|ASSI
--- 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_expre
--- 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
--- 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 dr
--- 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
--
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 #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
---
--- 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
--- 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
---
--- 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
--- 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 ge
--- 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 gen
--- 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): S
/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
'openn
--- 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
-
--
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 #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 gen
--- 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
--
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 #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
--- 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 conditiona
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'
--
nickpelling at nanodome dot com changed:
What|Removed |Added
Severity|minor |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42017
--- 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
--- 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): C
--- 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
--- 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): D
--- 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)
--- 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
Assi
--- 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
--- 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
--- 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.
--- 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
--- 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
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.
--- 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
--- 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=4
--- 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
--- 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
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.
COL
--- 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
--- 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 a
--- 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
--- 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 n
--- 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
--- 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
Stat
--- 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
Stat
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-a
--- 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
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 (bo
--- 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.
--- 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
-
--- 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
--- 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
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 leg
--- 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=3876
74 matches
Mail list logo
