Mark Mitchell wrote:
GCC 4.1.1 has been released.
This release is a bug-fix release for problems in GCC 4.0.2. GCC
4.1.1 contains changes to correct regressions from previous releases,
but no new features.
This release is available from the FTP servers listed here:
You won't be able to. You're going to need to write your own code that,
during the conversion of the tree to RTL, creates RTL expressions which
indicate that the memory references use segment registers. This probably
won't be easy since there are a lot of contexts where your far pointer
can be
Dear List,
do you all remember this?
Look back to http://gcc.gnu.org/ml/gcc/2006-03/msg00759.html
if your memory needs to be jogged.
two months and a few hours on... has anything changed? Is
Gabriel Dos Reis still looking into this, or has he been hit
by a bus?
Bernard Leak
--
On 26 May 2006 11:10, Bernard Leak wrote:
Dear List,
do you all remember this?
Look back to http://gcc.gnu.org/ml/gcc/2006-03/msg00759.html
if your memory needs to be jogged.
two months and a few hours on... has anything changed? Is
Gabriel Dos Reis still looking into this,
Dave,
don't forget to send a mail to gcc-announce. No announce has been sent yet:
http://gcc.gnu.org/ml/gcc-announce/2006/
http://gcc.gnu.org/ml/gcc-announce/2005/
Cheers,
Manuel.
On 26/05/06, Dave Korn [EMAIL PROTECTED] wrote:
On 26 May 2006 11:10, Bernard Leak wrote:
Dear List,
On 26 May 2006 12:16, Manuel López-Ibáñez wrote:
Dave,
don't forget to send a mail to gcc-announce. No announce has been sent yet:
http://gcc.gnu.org/ml/gcc-announce/2006/
http://gcc.gnu.org/ml/gcc-announce/2005/
Cheers,
Manuel.
Don't know if I have the authority to do that.
Roberto Bagnara wrote:
Mark Mitchell wrote:
GCC 4.1.1 has been released.
This release is a bug-fix release for problems in GCC 4.0.2. GCC
[...]
Do you mean a bug-fix release for problems in GCC 4.1.0?
Yup.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
I've got a bug with gcc-3.4.6 (also with 3.3.2, 3.3.6, probably
anything inbetween), target sh-elf. Unfortunately, the test case is
huge, convoluted and proprietary, so I can't send it for now.
When reloading insn 2780:
Breakpoint 3, reload_as_needed (live_known=1)
at
Hi Maxim and Vlad,
I just tracked an ICE while building glibc for ARM to this patch,
which introduced --param max-sched-extend-regions-iters with a default
of two:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00998.html
The testcase is attached; an arm-linux-gnueabi compiler should be able to
On 26 May 2006 16:23, Momchil Velikov wrote:
Now r3 is stored at [r14 + 160], which is incorrect. The reason is
that when substituting the reload register into insn 2780, the insn
22942 is modified also, because they share the following rtx: (plus:SI
(reg/f:SI 14 r14) (const_int 124
I am trying to compile the source for gcc, but do not yet have gcc.
I am on a fc1 machine and have been googling for hours at the clients
site, trying to find out what I need and where to get it.
can anyone help me in figuring out how to get a compiler onto a fc1
machine with _no_compiler?
On 26 May 2006 15:48, Dude VanWinkle wrote:
I am trying to compile the source for gcc, but do not yet have gcc.
I am on a fc1 machine and have been googling for hours at the clients
site, trying to find out what I need and where to get it.
can anyone help me in figuring out how to get a
Hi all,
I've stumbled across a small problem.
As you may know, cygwin attempts to give the user a free choice of using the
winsock API, with SOCKETs being handles not fds, and ioctlsocket and
closesocket and so on, or using the posix sockets API, and having sockets
being fds just like
Has anyone seen
http://sources.redhat.com/bugzilla/show_bug.cgi?id=2701
It looks like the result of merging of intl from gcc. It doesn't work
for me in gcc either:
make[2]: Leaving directory
`/export/build/gnu/gcc/build-i686-linux/intl'
Doing install-info in intl
make[2]: Entering directory
This is the beta release of binutils 2.17.50.0.2 for Linux, which is
based on binutils 2006 0526 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
--- Comment #2 from mirko dot bruzzone at primeur dot com 2006-05-26 07:33
---
(In reply to comment #1)
Good morning,
I tried to compile the gcc version 4.0.3 on this platform:
UNIX_SV ulisse 4.0 3.0 3425/3482/3485 Pentium III(TM)-ISA/PCI
On the system there is an old gcc
--- Comment #6 from bonzini at gnu dot org 2006-05-26 07:46 ---
There are indeed differences in the generated code.
aj_f_times2 is equal without and with the patch.
aj_d_times2 has this (left = old, right = patched):
movsd %xmm0, -40(%rbp) | movsd %xmm0,
I know that the ABI calling convention require that function results are
returned as integers, even if the function result is known as
(short)byte-value.
But if a function with its return is inlined, i can't see any reason to
(over)fullfill this convention. At least with optimizing compilation
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2006-05-26 08:31
---
(In reply to comment #18)
This patch is beyond my current understanding, so someone else needs to look
at
it.
I think our best chance here is to find the exact patch that broke it. You said
it's between
--- Comment #1 from familie dot glaser at web dot de 2006-05-26 08:34
---
Created an attachment (id=11513)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11513action=view)
preprocessed c++-example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27771
--- Comment #2 from familie dot glaser at web dot de 2006-05-26 08:37
---
Created an attachment (id=11514)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11514action=view)
assembler-listing with markup-comments
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27771
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-05-26 09:53 ---
Subject: Bug 27743
Author: rguenth
Date: Fri May 26 09:53:01 2006
New Revision: 114128
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114128
Log:
2006-05-26 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-05-26 09:53 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from aph at gcc dot gnu dot org 2006-05-26 10:20 ---
I have found the real cause of these weird non-nested variable ranges.
It's because ecj reorganizes for loops in this way:
for (a; b; c)
{
foo;
}
becomes
goto barf;
do
{
foo;
c;
barf:
a;
if (!b)
goto
--- Comment #6 from aph at gcc dot gnu dot org 2006-05-26 10:23 ---
Err, I mean:
a;
goto barf;
do
{
foo;
c;
barf:
if (!b)
goto x;
} forever;
x:
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27756
I get testsuite failures in mpfr compiling for s390 with
/usr/lib/gcc/s390-suse-linux/4.1.0/cc1 -fpreprocessed mul.i -quiet -dumpbase
mul.c -march=z900 -mtune=z9-109 -m31 -mesa -auxbase mul -O2 -Wall -version
-fmessage-length=0 -fPIC -o mul.s
s390z27:/usr/src/packages/BUILD/mpfr-2.2.0/tests#
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-26 10:32 ---
Created an attachment (id=11515)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11515action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27772
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-26 11:00 ---
Works for me without all the volatile crap.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from berndtrog at yahoo dot com 2006-05-26 11:15 ---
This bug is target independent.
I see the same behaviour for --target=mingw32.
Workaround (for avr only):
Index: mlib-utl.adb
===
--- mlib-utl.adb
--- Comment #2 from lcampbel at akamai dot com 2006-05-26 11:37 ---
Any chance this will get fixed any time soon? I think all you have to do is to
change a NULL to _objc_thread_attribs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19850
--- Comment #5 from falk at gcc dot gnu dot org 2006-05-26 12:29 ---
Subject: Bug 27571
Author: falk
Date: Fri May 26 12:28:40 2006
New Revision: 114130
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114130
Log:
PR target/27571
* config/alpha/alpha.c
--- Comment #6 from falk at debian dot org 2006-05-26 12:30 ---
Fixed.
--
falk at debian dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from uweigand at gcc dot gnu dot org 2006-05-26 12:58
---
This looks like a source-code problem. The assembler instruction
union {DItype __ll; struct {USItype __h, __l;} __i; } __x;
__asm__ (lr %N0,%1\n\tmr %0,%2 : =r (__x.__ll)
: r
With the attached source, gcc version 4.2.0 20060524 (experimental) gets:
/usr/snp/bin/gfortran -S -O2 -ffast-math imhdiff4_pp.f
imhdiff4_pp.f: In function 'imhdiff4':
imhdiff4_pp.f:1: internal compiler error: in find_lattice_value, at
tree-complex.c:133
Note the use of -ffast-math - without
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2006-05-26
13:02 ---
Created an attachment (id=11516)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11516action=view)
Source file showing the wrong behaviour
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27773
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2006-05-26
13:06 ---
Changed summary to indicate this bug is a 4.2 regression.
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
--- Comment #7 from aph at gcc dot gnu dot org 2006-05-26 13:52 ---
Subject: Bug 27756
Author: aph
Date: Fri May 26 13:52:18 2006
New Revision: 114131
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114131
Log:
2006-05-25 Andrew Haley [EMAIL PROTECTED]
PR java/27756
--- Comment #8 from aph at gcc dot gnu dot org 2006-05-26 13:54 ---
What am I supposed to write here, anyway? It's fixed because I fixed it.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from dje at gcc dot gnu dot org 2006-05-26 14:07 ---
The patch you reference enables section anchors by default. Neither AIX nor
PPC Linux show new Gfortran testsuite failures from the use of section anchors.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
--- Comment #8 from jakub at gcc dot gnu dot org 2006-05-26 14:17 ---
Subject: Bug 25758
Author: jakub
Date: Fri May 26 14:17:47 2006
New Revision: 114132
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114132
Log:
PR target/27758
Backported from mainline
--- Comment #4 from jakub at gcc dot gnu dot org 2006-05-26 14:17 ---
Subject: Bug 27758
Author: jakub
Date: Fri May 26 14:17:47 2006
New Revision: 114132
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114132
Log:
PR target/27758
Backported from mainline
--- Comment #5 from jakub at gcc dot gnu dot org 2006-05-26 14:19 ---
Subject: Bug 27758
Author: jakub
Date: Fri May 26 14:19:16 2006
New Revision: 114133
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114133
Log:
PR target/27758
* gcc.dg/pr27758.c: New test.
--- Comment #1 from bangerth at dealii dot org 2006-05-26 14:56 ---
This didn't fail with 4.0.2pre, so it must be a regression on a release branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27722
--- Comment #21 from konqueror at gmx dot de 2006-05-26 14:58 ---
Can this please get backportet to the 4.1 branch? This bug is still holding
back some Java stuff on Debian/ia64 from being working.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
--- Comment #1 from bangerth at dealii dot org 2006-05-26 14:59 ---
Confirmed. A regression.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:00 ---
Confirmed. A regression.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #4 from bangerth at dealii dot org 2006-05-26 15:04 ---
(In reply to comment #1)
I think GCC 4.2.0 is correct in saying the function call is ambiguous, bar is
still a template class.
Most definitely, fooint::bar is not a template class, and the only
thing the call to f()
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:04 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:06 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:06 ---
Confirmed..
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:08 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from bangerth at dealii dot org 2006-05-26 15:14 ---
Confirmed. Though it is worth mentioning that icc has the same problem.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:16 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:18 ---
This works fine with 4.0.2, and 4.1-pre and 4.2-pre snapshots I have here.
Could you check that it works for you as well with a recent snapshot?
Thanks
W.
--
bangerth at dealii dot org changed:
What
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:21 ---
template class A
void f(A, vector A, int);
You meant __vector here.
Certainly, the expectation is that the vector attribute will apply to the
type only after instantiation. Whether that is feasible is a different
--- Comment #1 from bangerth at dealii dot org 2006-05-26 14:57 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from bangerth at dealii dot org 2006-05-26 14:58 ---
Just for completeness' sake: confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:26 ---
gcc parses this as
template class T
typename AT ()() ::I foo (T) { return 0; }
i.e. as meaning that the argument is not an integer, but a function that
returns an integer.
A simpler testcase is this (icc accepts it,
--- Comment #1 from bangerth at dealii dot org 2006-05-26 15:28 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:29 ---
Confirmed, but low priority. One should just follow the first error message.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:37 ---
Confirmed. We should not be calling the conversion operator.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2006-05-26 15:38 ---
As mentioned before, this is legal code.
--
bangerth at dealii dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-26 16:15 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-26 16:31 ---
D.1024_166 = COMPLEX_EXPR zkq_165, 0.0;
D.1025_167 = 1.0e+0 - D.1024_166;
That is wrong, that 1.0 should be complex_cst 1.0e+0, 0.0
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from tneumann at pi3 dot informatik dot uni-mannheim dot de
2006-05-26 16:35 ---
This still happens with gcc-4.0-20060518, see the error message below. The
gcc-4.[12] branches presumably work, I only tried 4.1.
./gcc4/bin/g++ -c foo.cpp
foo.cpp: In member function
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-26 16:38 ---
More reduced testcase:
subroutine imhdiff4(qhat, zkq)
complex qhat
real zkq
qhat = qhat - zkq*qhat
end
--
Trying to get a C testcase.
--
pinskia at gcc dot gnu dot org
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-26 16:41 ---
C testcase:
_Complex float f(_Complex float a, float b)
{
return a - a*b;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-26 16:44 ---
This has been failing since 4.2.0 20060131.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27773
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-26 16:59 ---
Woops what did I do to make this assign this to myself.
Anyways I am no way at all working on this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
I got
[EMAIL PROTECTED] build-i686-linux]$ make install-info DESTDIR=../release
make[1]: Entering directory `/export/build/gnu/gcc/build-i686-linux'
Doing info in gcc
make[2]: Entering directory `/export/build/gnu/gcc/build-i686-linux/gcc'
make[2]: Nothing to be done for `info'.
make[2]: Leaving
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-26 17:35 ---
Missing a couple of pieces of info.
How did you configure GCC?
Did you do a build before doing make install-info?
By the way a relative path for DESTDIR will not work so why are you trying to
do that in the first
4.2.0 20060526 (experimental)
[dranta:~/tests/gfortran-D] dir% cat write_logical.f90
! PR 14334, L edit descriptor does not work
!
! this test uses L1 and L4 to print TRUE and FALSE
logical true,false
character*10 b
true = .TRUE.
false = .FALSE.
b
--- Comment #2 from hjl at lucon dot org 2006-05-26 17:57 ---
make install-info doesn't work in gcc/intl in 3.4, 4.0, 4.1. But it used to
work in src/intl. After merging intl from gcc to src, make install-info no
longers in src/intl.
--
hjl at lucon dot org changed:
What
--- Comment #22 from pinskia at gcc dot gnu dot org 2006-05-26 17:58
---
(In reply to comment #21)
It is rev 113395 that is causing the problem. I backed out that change and
built today's version of gfortran - it now correctly runs one of the tests
that has been failing -
I had
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-26 17:59 ---
What about 3.3.x? gcc/intl changed in 3.4.x?
Also you still have not said how you configured.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from neroden at gcc dot gnu dot org 2006-05-26 18:34
---
I'm afraid I've become very busy and my priorities have changed; I'm not going
to get this bug fixed. Unassigning.
--
neroden at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from janis at gcc dot gnu dot org 2006-05-26 18:36 ---
A regression hunt on powerpc-linux using the testcase from comment #5 with
--ffast-math identified the following patch:
http://gcc.gnu.org/viewcvs?view=revrev=107218
r107218 | rguenth | 2005-11-19 11:29:10
--- Comment #13 from mueller at gcc dot gnu dot org 2006-05-26 18:39
---
It also causes bootstrap failures (see PR18058)
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-26 18:41 ---
The problem is here with that patch:
+ if (!FLOAT_TYPE_P (type))
+ arg11 = build_int_cst (type, 1);
+ else
+ arg11 = build_real (type, dconst1);
--
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-05-26 18:43
---
(In reply to comment #13)
It also causes bootstrap failures (see PR18058)
Can you try bootstrapping with a newer GCC as that problem should have been
fixed (though the orginally problem in that bug still remains
--- Comment #4 from hjl at lucon dot org 2006-05-26 18:49 ---
I didn't see intl in my gcc 3.3. My gcc is configured with
/net/gnu-13/export/gnu/src/gcc/gcc/configure \
\
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld \
\
--enable-shared
--- Comment #23 from dir at lanl dot gov 2006-05-26 19:36 ---
Here is the good and the bad -
[dranta:~/tests/gfortran-D] dir% gfortran -O1 -save-temps -o write_logical2
write_logical2.f90
[dranta:~/tests/gfortran-D] dir% write_logical2
At line 9 of file write_logical2.f90
Fortran
We are a team of private investors, with years of good experience
http://209.200.152.115
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-05-26 19:53 ---
Subject: Bug 23151
Author: tkoenig
Date: Fri May 26 19:53:18 2006
New Revision: 114138
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114138
Log:
2006-05-26 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #5 from uweigand at gcc dot gnu dot org 2006-05-26 20:22
---
Subject: Bug 27661
Author: uweigand
Date: Fri May 26 20:21:53 2006
New Revision: 114141
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114141
Log:
PR rtl-optimization/27661
* reload.c
--- Comment #24 from pinskia at gcc dot gnu dot org 2006-05-26 20:51
---
Looks like .const sections are merged, I will deal with this (it is an one
liner).
Dale thanks for the assembly of both the good and bad.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #25 from pinskia at gcc dot gnu dot org 2006-05-26 20:52
---
I had wished Apple would care more about the FSF GCC than they are right now.
I still don't understand why an employee of SCEA has to fix their bugs for
them. Maybe Apple should pay me for work I do.
--
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-26 21:18
---
Subject: Bug 27524
Author: fxcoudert
Date: Fri May 26 21:18:45 2006
New Revision: 114142
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114142
Log:
PR fortran/27524
* trans-array.c
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.1.2
Known to work||4.2.0
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
The test-case:
// testcase: -
struct A
{
struct B
{
};
};
struct C : A, A::B
{
void foo(B b);
void bar(B* pb);
};
//
==
The error:
foo.cc:11: error: reference to 'B' is ambiguous
foo.cc:5: error:
--- Comment #26 from pinskia at gcc dot gnu dot org 2006-05-27 02:27
---
Actually this is a dup of bug 26427. I had forgot about this issue until now.
*** This bug has been marked as a duplicate of 26427 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-27 02:27 ---
*** Bug 27683 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-05-27 02:35
---
The following patch causes no regressions. I can't reproduce the problem here,
but I have a hunch.
Ray, can you try this and see if it resolves the problem?
Thanks for tests and reports.
Index: io/transfer.c
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-27 04:11 ---
Created an attachment (id=11517)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11517action=view)
patch which fixes part of the problem
This fixes the C testcase but it does not fix the Fortran issue but I
--- Comment #3 from patchapp at dberlin dot org 2006-05-27 04:30 ---
Subject: Bug number PR25058
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-05/msg01385.html
--
--- Comment #14 from pault at gcc dot gnu dot org 2006-05-27 05:03 ---
(In reply to comment #12)
Are you using Tonto in SPEC CPU 2006? It is slightly different from Tonto 1.0
on SF. The problem in Tonto in SPEC CPU 2006 is it uses something like
Ah, sorry HJ. You are right.
But
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-05-27 05:10
---
Here is some good news. I came up with a test case that fails with gfortran
and passes with intel. The bad news is that I have not fixed it yet. At least
I have something to work with now and its ugly.
99 matches
Mail list logo
