--- Comment #5 from pault at gcc dot gnu dot org 2006-03-15 08:14 ---
Herve,
> So what ? Is there a patch which I should use to correct this error ? Do
> you need more info to reproduce this ICE ? Please ask and I will try to
> provide all the available info.
> Thanks.
The could you
--- Comment #3 from pault at gcc dot gnu dot org 2006-03-15 08:15 ---
I am working on this one slowly but making progress nonetheless.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
The makefiles for classpath, as included in the libjava tree, run find to
gather lists of specific files (for META-INF etc). The matched files are then
copied to the build tree.
However, the command lines used for the find invocations specifically mention
'CVS' as a directory to exclude; since gcc
/var/abs/base/gcc/src/gcc-3.3.6/obj-avr/gcc/xgcc
-B/var/abs/base/gcc/src/gcc-3.3.6/obj-avr/gcc/ -B/usr/local/avr/avr/bin/
-B/usr/local/avr/avr/lib/ -isystem /usr/local/avr/avr/include -O2 -DIN_GCC
-DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -isystem ./includ
--- Comment #1 from slansky at usa dot net 2006-03-15 09:06 ---
$ /var/abs/base/gcc/src/gcc-3.3.6/obj-avr/gcc/xgcc -v
Using built-in specs.
Configured with: ../configure --target=avr --prefix=/usr/local/avr
--disable-nls --enable-language=c
Thread model: single
gcc version 3.3.6
--
The following invalid OpenMP-C++ code snippet crashes the compiler
when compiled with -fopenmp:
===
struct A
{
A(int);
};
void foo()
{
A a(0);
#pragma omp parallel private (a)
;
}
===
bug.cc: In function 'void fo
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-15 09:57 ---
with powerpc-unknown-linux and 4.1.0 I get (-O1 -fno-pic -mbss-plt)
broken:
cmpwi 7,4,0
beq 7,.L2
lis 9,[EMAIL PROTECTED]
lfd 0,[EMAIL PROTECTED](9)
b .L4
.L2:
lis 9,[
The compiler creates wrong code for the following valid OpenMP-C++
code snippet when compiled with "-fopenmp":
===
#include
struct A
{
int n;
A(int i=3) : n(i) {}
};
int main()
{
A a;
#pragma omp parallel private (a)
std::printf("%d\n", a.n);
--- Comment #4 from dcb314 at hotmail dot com 2006-03-15 10:42 ---
(In reply to comment #0)
> The one liner
>
> void f( int fred, char * fred);
>
> is IMHO illegal code because fred is the name of two parameters.
I just checked gcc 4.2 and it is broken there as well.
Even adding flag
The latest binutils from (linux) kernel.org is:
GNU ld version 2.16.91.0.6
The version test in gcc/configure fails (I think) because it doesn't check for
five digit groups in the version number. I hand-edited configure to add an
extra line that tests for the extra group and that seemed to work.
Th
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 12:27 ---
(In reply to comment #0)
> The latest binutils from (linux) kernel.org is:
> GNU ld version 2.16.91.0.6
Don't use That binutils. That is not an official FSF binutils.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-15 12:33 ---
This comes from the following pattern:
(define_insn "movdf_low_si"
[(set (match_operand:DF 0 "gpc_reg_operand" "=f,!r")
(mem:DF (lo_sum:SI (match_operand:SI 1 "gpc_reg_operand" "b,b")
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 12:58 ---
Hmm, the IR looks fine in .gimple:
struct A a;
__comp_ctor (&a, 3);
#pragma omp parallel private(a)
{
{
int D.2487;
D.2487 = a.n;
printf (&"%d\n"[0], D.2487)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 13:00 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-15 13:09 ---
Hmm, on second thought I think this is a front-end bug.
And here is a self contained testcase:
struct A
{
int n;
A(int i=3) : n(i) {}
};
int main()
{
A a;
#pragma omp parallel private (a)
if (a.n!=3)
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-15 13:13 ---
Fixed by:
2006-03-14 Richard Guenther <[EMAIL PROTECTED]>
* configure: Regenerate with autoconf 2.13.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-15 13:14 ---
*** This bug has been marked as a duplicate of 14149 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-03-15 13:14
---
*** Bug 26689 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
The following invalid code is accepted since GCC 3.4.0:
class A
{
private:
typedef int X;
};
template int foo() { return A::X(); } // A::X is private!
int i=foo<0>();
If I make foo a non-temp
--- Comment #11 from rakdver at gcc dot gnu dot org 2006-03-15 13:21
---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00925.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 13:24 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
template < typename T >
T __add( T x, T y )
{
return x + y;
}
template float __add( float, float );
template double __add( double, double );
template long double __add( long double, long double );
$ g++ add.cpp -O -mabi=ieeelongdouble
cc1plus: warning: Using IEEE extended precision long double
Testcase is short enough:
struct A
{
static void f() {}
};
int main()
{
A a;
a.f;
}
Produces a segfault on the line where "a.f" occurs. It should instead issue the
warning "statement is a reference, not call, to function A::f". gcc 4.1.0 (at
least the experimental
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 14:12 ---
Why are you using ieeelongdouble? It is not really supported at all on
PPC-linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26695
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 14:16 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-15 14:17 ---
Here is the ICE when checking is enabled:
t.cc:9: internal compiler error: tree check: expected field_decl, have baselink
in component_ref_field_offset, at expr.c:5757
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #2 from pluto at agmk dot net 2006-03-15 14:22 ---
(In reply to comment #1)
> Why are you using ieeelongdouble?
just for testing. is it enough reason?
> It is not really supported at all on PPC-linux.
so, for what gcc has such broken feature?
[ cite [EMAIL PROTECTED] ]
`
As seen in the C++ test case here:
http://bugzilla.gnome.org/show_bug.cgi?id=334648
std::time_put<>::put(), with format 'x", shows only the last 2 digits of the
year, and there is no short-date format that shows all 4 digits. I notice that
the en_US and de_DE locales do not have this problem.
Th
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-03-15 15:27
---
Subject: Bug 6634
Author: reichelt
Date: Wed Mar 15 15:27:11 2006
New Revision: 112084
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112084
Log:
PR c++/6634
decl.c (grokdeclarator): Do not
--- Comment #10 from reichelt at gcc dot gnu dot org 2006-03-15 15:29
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-15 15:38 ---
You can expose the bug now with:
real, dimension(12) :: x, y
real:: z
do i = 1, 1000
z = g(x,y)
end do
print *, x
contains
function g(x, y)
real, dimension(:) :: x, y
real g
x = x + y
end functi
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-15 15:50 ---
Can you attach config.log from the gcc subdirectory?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26692
--- Comment #1 from pcarlini at suse dot de 2006-03-15 15:53 ---
We can't do much about that: the underlying locale data is telling us that 'x'
expands in the en_GB locale to %d/%m/%y, note lower case y. In fact, we are
simply using a threadsafe version of strftime, for a behavior totall
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 15:59 ---
Confirmed:
==25829== 68 bytes in 1 blocks are definitely lost in loss record 1 of 1
==25829==at 0x11B1E1FD: calloc (vg_replace_malloc.c:279)
==25829==by 0x11C232E0: gomp_malloc_cleared (alloc.c:48)
==25829==
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-15 16:10 ---
(In reply to comment #5)
> I do not believe that pr24558 is anything to do with this because there are no
> entry's in your code, unless they are in the modules.
Note I was taking about the library in general, not j
/*
The following piece of code should not compile:
According to [12.3.2/1], the conversion function
operator X&() cannot be called. However, its
presence tricks the compiler into thinking that
I has a license to initialize a non-const X& from a
const X&. This is illegal by [8.5.3/5].
--- Comment #3 from dave at datatone dot co dot uk 2006-03-15 16:12 ---
Subject: Re: Build configure misses valid ld in hidden test
pinskia at gcc dot gnu dot org wrote:
> --- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-15 15:50
> ---
> Can you attach config.log fr
Bug description: An object that has only public variables is placed in an
archive. Linking against that archive fails: probably ld doesn't link in the .o
from the archive because it contains only public variables.
gcc -v output: Reading specs from
/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/specs
Con
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 16:16 ---
First this is not a bug.
Lets look at your link line:
cc -o main -L. -ldata main.o
What is saying to the linker is look at libdata first for symbols that are
required already and then look at main.o. Since main.o
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 16:19 ---
Hmm, we used to get a warning in 3.2.3 and before:
t.cc:9: warning: conversion to a reference to the same type will never use a
type conversion operator
And it was rejected in 2.95.3:
t.cc:9: warning: conversion
--- Comment #2 from rmansfield at qnx dot com 2006-03-15 16:20 ---
I looked at the RTL generated to find what pass R1 was first introduced and it
was greg. It appears (I'm not certain since I'm still learning to read RTL) the
that no clobber happens for the divsi3_i4 insn.
Looking at sh
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-03-15 16:22 ---
The g++ tests still fail, see:
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01000.html
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from jb at gcc dot gnu dot org 2006-03-15 16:22 ---
Tentative patch here: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00950.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
--- Comment #12 from sje at cup dot hp dot com 2006-03-15 16:44 ---
At least on IA64, I don't think there is a way to make this test work. I tried
a change similar to yours. I also changed the setting of ndigits (uses the
magic number 27 in a couple of places), changed the number 31 in
--- Comment #8 from pault at gcc dot gnu dot org 2006-03-15 16:49 ---
You will be glad to hear that, at long last, I am putting the finishing touches
to a patch for this. It needs comments and a fine-toothed combing of the code.
I maybe will submit it tomorrow morning.
Paul Thomas
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 16:51 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|
--- Comment #4 from pault at gcc dot gnu dot org 2006-03-15 16:53 ---
You will be glad to hear that, at long last, I am putting the finishing touches
to a patch for transfer. It needs comments and a fine-toothed combing of the
code. I maybe will submit it tomorrow morning.
Paul Thomas
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-15 17:10 ---
Reduced testcase:
subroutine adw_set
implicit none
real*8Adw_xabcd_8(*)
pointer( Adw_xabcd_8_ , Adw_xabcd_8 )
common/ Adw / Adw_xabcd_8_
integer n
Adw_xabcd_8(1:n) =
--- Comment #2 from murrayc at murrayc dot com 2006-03-15 17:10 ---
Thanks. So, can't we just reassign this to glibc then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26697
--- Comment #3 from murrayc at murrayc dot com 2006-03-15 17:11 ---
Oh, and before I submit a time_get function, do we use a glibc function for
time_get too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26697
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-15 17:17 ---
Despite what the original report says, we don't really want to
resolve all entries when compiling.
Also it would be best to avoid any kind of synchronization at all.
One idea would be to 'or' the argument to one of t
--- Comment #4 from pcarlini at suse dot de 2006-03-15 17:17 ---
(In reply to comment #2)
> Thanks. So, can't we just reassign this to glibc then?
If you want, you can certainly file a glibc PR. However, I think you should
first try to understand whether there are real reasons to believ
--- Comment #5 from murrayc at murrayc dot com 2006-03-15 17:20 ---
> I mean, what evidence do you have that the en_GB locale data should be
> different?
I see no reason why en_GB should want to show 2 year digits, while en_US and
en_DE should be happy with 4. 2 digits lead to confusio
--- Comment #6 from pcarlini at suse dot de 2006-03-15 17:22 ---
(In reply to comment #5)
> > I mean, what evidence do you have that the en_GB locale data should be
> > different?
>
> I see no reason why en_GB should want to show 2 year digits, while en_US and
> en_DE should be happy w
--- Comment #5 from kargl at gcc dot gnu dot org 2006-03-15 17:26 ---
(In reply to comment #4)
> You will be glad to hear that, at long last, I am putting the finishing
> touches
> to a patch for transfer. It needs comments and a fine-toothed combing of the
> code. I maybe will submit
--- Comment #7 from murrayc at murrayc dot com 2006-03-15 17:33 ---
Maybe we can just call it an enhancement or improvement then?
(Thought I strongly feel that any date meant for humans to read must have 4
year digits and any use of 2 year digits for a human to read should be a bug,
eve
--- Comment #8 from pcarlini at suse dot de 2006-03-15 17:41 ---
(In reply to comment #7)
> Maybe we can just call it an enhancement or improvement then?
Maybe, if the glibc people agree (and the UK people agree, of course: the issue
boils down to convincing the ISO/POSIX people in UK w
--- Comment #9 from murrayc at murrayc dot com 2006-03-15 17:43 ---
> By the way, can't you just prepare a small function consistently using 'Y',
just a few lines, after all...
I need to support all locales. I may have to special-case en_GB.
--
http://gcc.gnu.org/bugzilla/show_bug.
The attached test case shows that std::time_get<> parses only the first 2
digits of years, and assumes that those are years in the 1900s. This is a loss
of data.
It gives this output, in an en_GB locale:
[EMAIL PROTECTED]:~$ ./a.out
The date as text: 01/02/2003
std::time_get result: day=1, month=
--- Comment #1 from murrayc at murrayc dot com 2006-03-15 17:44 ---
Created an attachment (id=11054)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11054&action=view)
testtimeget.cc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26701
--- Comment #2 from pcarlini at suse dot de 2006-03-15 17:47 ---
I thought it was clear it's really the same issue?!? In the en_GB locale, 'x'
expands to %d/%m/%y, lower case y.
--
pcarlini at suse dot de changed:
What|Removed |Added
--
--- Comment #3 from murrayc at murrayc dot com 2006-03-15 17:51 ---
That's maybe excusable for display, but all the documentation that I can find
for time_get says that it should parse up to 4 year digits. You mention in the
other bug that the locale information is used for parsing, but
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-15 17:56 ---
The only true documentation there is about libstdc++ is the C++ standard.
What documentation have you been looking at?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26701
--- Comment #5 from pcarlini at suse dot de 2006-03-15 17:57 ---
(In reply to comment #3)
> That's maybe excusable for display,
We are not talking about ""excuses"", we are talking about standard conforming
behavior.
but all the documentation that I
--- Comment #6 from murrayc at murrayc dot com 2006-03-15 18:02 ---
Admittedly the libstdc++ time_get::get_date() documentation does say that it
interprets it according to format "X", and now I understand what it meant. I
was looking at the dinkumware and roguewave documentation.
I have
--- Comment #7 from pcarlini at suse dot de 2006-03-15 18:08 ---
(In reply to comment #6)
> Thanks. My disappointment is now with the C++ Standard instead. If only it had
> a bugzilla.
Actually, it has one, sort of. You can send messages with your proposals to the
comp.std.c++ list, man
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-15 18:27 ---
Loop 1 iterates 2 times.
Added canonical iv to loop 1, 2 iterations.
That is wrong, it iterates 3 times at this point (an interation has already
been peeled before the loop).
This is from .ivcanon.
--
http://g
--- Comment #8 from tromey at gcc dot gnu dot org 2006-03-15 18:29 ---
Subject: Bug 26390
Author: tromey
Date: Wed Mar 15 18:29:44 2006
New Revision: 112093
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112093
Log:
gcc/java
PR java/26390:
* class.c (get_interfac
When an object file is compiled by arm-elf-gcc 4.1.0, nm -S 2.16.*
always shows zero as the size of a static variable.
Thanks,
Shaun
$ cat foo.c
int foo;
static int static_foo;
$ arm-elf-gcc -c foo.c
$ arm-elf-readelf -s foo.o | grep foo
1: 0 FILELOCAL DEFAULT ABS foo.c
--- Comment #9 from tromey at gcc dot gnu dot org 2006-03-15 18:31 ---
Oops -- that was the wrong PR number in that patch.
That commit was for PR 26638.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26390
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 18:38 ---
What does the output of -S show? I bet it is just putting static_foo in a BSS
using lcomm but I could be wrong. This might not be a gcc bug.
--
pinskia at gcc dot gnu dot org changed:
What|Remov
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-15 18:40 ---
Hmm, if I change the function to be:
#include
int main(void)
{
int bits = 25;
while (bits) {
printf("bits=%d\n",bits);
if (bits >= 8) {
bits -
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-15 18:45 ---
Subject: Bug 26638
Author: tromey
Date: Wed Mar 15 18:45:02 2006
New Revision: 112094
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112094
Log:
Correctly reference PR java/26638 in ChangeLogs
Modified:
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-15 18:45 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #2 from sjackman at gmail dot com 2006-03-15 18:51 ---
Subject: Re: Size of static variables always zero on arm-elf
On 15 Mar 2006 18:38:46 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> What does the output of -S show? I bet it is just putting static_f
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-15 18:53 ---
No I mean what is the assembly output from GCC which you get by invoking gcc
with -S.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26702
--- Comment #4 from sjackman at gmail dot com 2006-03-15 19:03 ---
Subject: Re: Size of static variables always zero on arm-elf
On 15 Mar 2006 18:53:53 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> No I mean what is the assembly output from GCC which you get by inv
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-15 19:07 ---
Can you try one more thing:
static int static_foo = 1;
And then use readelf -s on the object file?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26702
--- Comment #6 from hjl at lucon dot org 2006-03-15 19:31 ---
Please point out the non-standard code in tonto in detail. I will report it to
our SPEC people.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26106
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #6 from sjackman at gmail dot com 2006-03-15 20:01 ---
Subject: Re: Size of static variables always zero on arm-elf
On 15 Mar 2006 19:07:12 -, pinskia at gcc dot gnu dot org > Can
you try one more thing:
> static int static_foo = 1;
>
> And then use readelf -s on the ob
--- Comment #7 from kargl at gcc dot gnu dot org 2006-03-15 20:01 ---
(In reply to comment #6)
> Please point out the non-standard code in tonto in detail. I will report it to
> our SPEC people.
>
I believe that the code associated with gfortran's error message
is nonstandard at least
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-03-15 20:02 ---
Ok, this is a GCC bug for not outputing .size.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26702
--- Comment #8 from sjackman at gmail dot com 2006-03-15 20:10 ---
Subject: Re: Size of static variables always zero on arm-elf
GCC is not emitting the type or size information for static bss symbols.
-- sdj
$ echo 'static int foo = 1;' >foo.c
$ arm-elf-gcc -S foo.c -odata.s
$ echo '
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-15 20:15 ---
I'm sure Zdenek has an idea...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from hp at gcc dot gnu dot org 2006-03-15 20:17 ---
Well Joern, I fixed the bug in this PR, so whatever happens now is a new bug.
I'm unassigning myself; I'm not sure I should re-close the PR, maybe Joern
wants to pick it up and treat it as the same PR; CC:ed.
--
hp at
--- Comment #8 from hjl at lucon dot org 2006-03-15 20:18 ---
Is that the exact output? I couldn't find similar thing in my log. The
closest things I have are
/usr/gcc-4.2/bin/gfortran -I. -I./GCC-gfortran-on-LINUX/modules -O -c -o
./GCC-gfortran-on-LINUX/objects/intvec.o f95files/intve
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-15 20:19 ---
This was fixed on the trunk by:
2006-02-15 Andrew Haley <[EMAIL PROTECTED]>
* class.c (GEN_TABLE): Don't pushdecl *_SYMS_DECL here.
(make_class_data): pushdecl_top_level TYPE_OTABLE_SYMS_DECL,
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-15 20:26 ---
Now I think we don't need to do anything here.
We already handle the common cases.
For instance, if the target is an interface we will use
the IDT to do this test. This is reasonably fast.
Also if both classes in q
--- Comment #9 from kargl at gcc dot gnu dot org 2006-03-15 20:42 ---
(In reply to comment #8)
> Is that the exact output?
Yes, of course!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26106
--- Comment #3 from joseph at codesourcery dot com 2006-03-15 21:14 ---
Subject: Re: New: -mabi=ieeelongdouble / undefined
reference to _q_add.
On Wed, 15 Mar 2006, pluto at agmk dot net wrote:
> undefined reference to `_q_add'
This function is an ABI-defined function libc should d
Bad:
[EMAIL PROTECTED] g++ -I. -fmudflap -c CLU_message.cpp
CLU_message.cpp: In constructor 'CLU_message::CLU_message(const std::string&)':
CLU_message.cpp:23: internal compiler error: Segmentation fault
.
.
.
[EMAIL PROTECTED]
Good:
[EMAIL PROTECTED] g++ -I. -c CLU_message.cpp
[EMAIL PROTECTED]
--- Comment #1 from rwcrocombe at raytheon dot com 2006-03-15 21:19 ---
Created an attachment (id=11056)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11056&action=view)
Bzipped2 result of g++ -I. -fmudflap -E -save-temps CLU_message.cpp > blob.cpp
--
http://gcc.gnu.org/bugzil
--- Comment #21 from patchapp at dberlin dot org 2006-03-15 22:30 ---
Subject: Bug number PR 19303
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00980.html
--
http://gcc.gnu.org/bugzilla/
This is an issue for both 4.1 branch and trunk.
$ grep GCC_ libjava/classpath/configure
GCC_NO_EXECUTABLES
--
Summary: [4.1/4.2] Unexpanded macro in
libjava/classpath/configure
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 23:00 ---
*** This bug has been marked as a duplicate of 26688 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-15 23:00 ---
*** Bug 26707 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from aph at gcc dot gnu dot org 2006-03-15 23:15 ---
Oh yes, definitely. It was just waiting for the branch to be unfrozen.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26138
1 - 100 of 120 matches
Mail list logo
