Hi,
I'm posting this announce to this list as GCC now uses MPFR...
The release of MPFR 2.2.1 is imminent. Please help to make this
release as good as possible by downloading and testing this
release candidate:
http://www.mpfr.org/mpfr-2.2.1/mpfr-2.2.1-rc1.tar.bz2
Vladimir Yanovsky wrote:
That comment was about SMS. Last time when I tried SMS for Itanium on
SPEC2000 a few monts ago, a lot of tests did not work. As RCSP I don't
think we need this. It is too complicated algorithm. Mainstream
approach is modulo scheduling. I hope people from ISP
I am working on a ARM backend for LLVM. The problemis that llvm-gcc is
currently based on gcc 4.0 and I would like to use the new EABI.
I have started to back port the ABI from 4.1 to 4.0. The first attempt
was to just copy the gcc/config/arm directory and try to fix build
errors. This proved
Maybe this is not the right list for such question?
Should I directly use gcc bugzilla?
Thanks,
Francesco
Francesco Montorsi ha scritto:
Hi all,
I'm getting a lot of warnings of type:
warning: type attributes are honored only at type definition
when building a library which uses the
On Nov 21, 2006, at 11:06 AM, Doug Gregor wrote:
Make DEPTH=6, we get an 85% speedup:
Yes, this mirrors the type of speed up I expect for _some_ types of
template code. I'd love to see us go in this direction. Anyway, I
endorse this type of work.
Anyway, on to the review...
Any
To the gcc packagers:
Shall libgomp/libgomp.info ever be distributed, i.e. is there any reason to
add the --enable-generated-files-in-srcdir flag from gcc/configure.ac to
libgomp/configure.ac as well?
The tarball of 4.1.1 includes fastjar/fastjar.info, but not
libiberty/libiberty.info. The
On Wed, 2006-11-22 at 22:52 +0100, Daniel Franke wrote:
The tarball of 4.1.1 includes fastjar/fastjar.info, but not
libiberty/libiberty.info. The config file fastjar/configure.ac has the
enable-...-srcdir flag, libiberty/configure.ac does not.
This is because libiberty's API is all internal
This is because libiberty's API is all internal really and is always
changing and never stable. It is not really a well defined library
unlike say libgomp.
... although we do try to keep backward compatiblity when possible, so
that newer libiberties work with older gcc/binutils/gdb/whatever.
I tried to install gcc-4.2-20061121 and gcc-4.3-20061118. Both failed at
exactly the same point. The steps I used to install them were:
# cd /common/src
# tar xjf gcc-4.2-20061121.tar.bz2
# cd /common/compilers/linux/gcc-4.2
# /common/src/gcc-4.2-20061121/configure
Hello,
I have a proc file which I compile with the proc compiler and link it with
gcc.
The .pc file as well as makefile is same in two m/c's.
In one m/c with gcc3.3.3 installed, I have no problem in compiling and
linking.
In another m/c with gcc4.0.0 installed, I was getting the following
Hi.
I've a reduced test case showing that a function like:
struct x {
uint8_t a;
uint16_t b;
};
f(struct x *y)
...
will expect that 'y' is correctly aligned: it uses 'ldrh' to access y-b and
ldrh documentation says if the memory is not halfworld-aligned and no data
abort occurs, the value
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-11-22 10:50
---
The compiler expects 'y' to be correctly aligned because the ABI says that it
can expect this to be so. If you write a program that then provides an
unaligned value, then the behaviour is undefined and you can
--- Comment #27 from irar at il dot ibm dot com 2006-11-22 11:15 ---
I committed the patch that enables vectorization of strided accesses
(http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01679.html), and now bootstrap
with vectorization fails also on x86 with the same error as in comment
--- Comment #2 from bernard dot fouche at kuantic dot com 2006-11-22 11:32
---
Subject: Re: [3.4.4/3.4.6/4.1.1] ARM structure pointer alignment
problem with optimization
rearnsha at gcc dot gnu dot org wrote:
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-11-22 10:50
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-11-22 12:39
---
Created an attachment (id=12666)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12666action=view)
testcase run through uninclude
unincluded so it's 64bit clean also.
--
--- Comment #7 from pault at gcc dot gnu dot org 2006-11-22 13:42 ---
I have just submitted a patch to the gfortran list.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from patchapp at dberlin dot org 2006-11-22 13:45 ---
Subject: Bug number PR29912
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-11/msg01561.html
--
Rvalue references as described in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html were voted
into the C++0x working draft at the 2006 Portland meeting, and I'd like to use
them.
--
Summary: Please implement rvalue references
Product: gcc
--- Comment #5 from kkojima at gcc dot gnu dot org 2006-11-22 14:20 ---
Sorry for my slow reply. I have no easy way to look this
issue quickly. I'd like to revert the reorg part of 118746
to fix the build failure on hppa.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29891
--- Comment #4 from tobi at gcc dot gnu dot org 2006-11-22 14:48 ---
A possible solution is to add entries for the symbolic forms (e.g. '==') of the
intrinsic operators to the enum gfc_intrinsic_op, and then use them
interchangeably, except when matching the operators, and when printing
--- Comment #5 from hjl at lucon dot org 2006-11-22 14:50 ---
Another testcase:
[EMAIL PROTECTED] build_base_o2.]$ cat bar.f90
SUBROUTINE foo(DPRS,LBOT,LTOP,KTS,KTE)
IMPLICIT NONE
INTEGER,INTENT(IN) :: KTS,KTE
INTEGER,INTENT(OUT) :: LBOT,LTOP
--- Comment #3 from s__nakayama at infoseek dot jp 2006-11-22 14:57 ---
(In reply to comment #2)
(In reply to comment #2)
What exactly do you expect the code to do?
fooint ()();
leads to an instantiation of fooT with
T= int()()
i.e. reference to no-arg function returning int.
--- Comment #3 from tobi at gcc dot gnu dot org 2006-11-22 15:01 ---
I have a one-line patch for this.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
This program compiles:
#include iostream
int main()
{
std::cout _S std::endl;
return 0;
}
If started, it outputs : 8
output of my g++ -v:
Reading specs from /opt/csw/gcc4/lib/gcc/i386-pc-solaris2.8/4.0.2/specs
Target: i386-pc-solaris2.8
Configured with:
--- Comment #1 from boris dot breidenbach at physik dot uni-erlangen dot de
2006-11-22 15:05 ---
Created an attachment (id=12667)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12667action=view)
output of g++ -E
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29940
--- Comment #1 from fang at csl dot cornell dot edu 2006-11-22 15:07
---
There was some (suspended) discussion about support for rvalue references in PR
24803. Is there a plan for them somewhere in the pipeline?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-22
15:11 ---
Subject: Re: [4.3 Regression] libgcc2.c: In function '__gcc_bcmp': ICE:
Segmentation fault
Sorry for my slow reply. I have no easy way to look this
issue quickly. I'd like to revert the reorg part of
With this subroutine:
subroutine whatever(str)
character(len=*), dimension(*) :: str
integer :: i
i = len(str)
end subroutine whatever
gfortran reports:
i = len(str)
1
Error: The upper bound in the last dimension must appear in the reference to
the assumed size array 'str' at (1)
The
The following code produce a compilation error at the unique line of the
function named visit below (it is a basic implementation of a visitor
pattern) :
# 1 test.cpp
# 1 interne
# 1 ligne de commande
# 1 test.cpp
template typename T
struct Toto
{
template typename T2
void visit(T2 * o)
--- Comment #4 from bangerth at dealii dot org 2006-11-22 15:31 ---
(In reply to comment #3)
I expected that the compiler reject it.
But Comeau compiler also accepted this code.
As does icc.
I can't see why the code would be invalid if one accepts that
T bar;
is the declaration
--- Comment #7 from kkojima at gcc dot gnu dot org 2006-11-22 15:40 ---
Indeed. I've reverted it now. Sorry again for the breakage.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29891
--- Comment #4 from jakub at gcc dot gnu dot org 2006-11-22 15:58 ---
Too old glibc or configured without TLS support? Try building gcc with
--disable-tls. Works just fine here.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hhinnant at apple dot com 2006-11-22 16:21 ---
If there is a plan, I don't know about it.
Russell Yanofsky has a prototype implementation here:
http://russ.yanofsky.org/rref/
I haven't looked at it enough to know how complete it is. It was done a couple
of years
--- Comment #1 from hjl at lucon dot org 2006-11-22 16:32 ---
Please try
# make -j5 bootstrap-lean
--
hjl at lucon dot org changed:
What|Removed |Added
The following example(reduced from glibc) compiles differently for ppc target
when using gcc 4.2 as compared to gcc 4.1
It generates the alias symbol as a real symbol instead of creating it as alias.
I get this correct using gcc 4.2 for arm so the problem seems to be affecting
only ppc. This also
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-22 16:42 ---
/common/compilers/linux/gcc-4.2//x86_64-unknown-linux-gnu/sys-include -m32
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C
compiled
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-22 16:45 ---
_S is in the reserved identifiers for implemenation so ...
Closing as invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-22 16:47 ---
Instead of:
o-evalT();
You want:
o-template evalT();
Which is required by the C++ standard.
read:
http://gcc.gnu.org/gcc-3.4/changes.html
--
pinskia at gcc dot gnu dot org changed:
--- Comment #6 from hjl at lucon dot org 2006-11-22 16:56 ---
A simpler testcase:
[EMAIL PROTECTED] 29921]$ cat bar.f90
SUBROUTINE foo(DPRS,FPK,LBOT,LTOP,KTS,KTE)
IMPLICIT NONE
INTEGER,INTENT(IN) :: KTS,KTE
INTEGER,INTENT(OUT) :: LBOT,LTOP
At the moment, we only do biv (basic induction variable) widening when we
can argue that overflow cuases undefined behaviour, as in:
int
f (int start, int end, int x, int y)
{
short i;
for (i = start; i end; i++)
x = y;
return x;
}
However, for -ftrapv, we get the wrong result (it
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-11-22 19:23 ---
Created an attachment (id=12668)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12668action=view)
3.4.3 patch
For illustration, this patch implements this optimization in a 3.4.3 based
compiler.
Because the
The code from libgfortran ICEs:
extern const char *__ctype_ptr;
parse_real (unsigned char c)
{
if ((__ctype_ptr[c]04) c != '.')
unget_char ( c);
}
-
t.c: In function 'parse_real':
t.c:6: internal compiler error: in simplify_subreg, at simplify-rtx.c:4470
Please
--- Comment #7 from hjl at lucon dot org 2006-11-22 19:34 ---
Reduced:
[EMAIL PROTECTED] 29921]$ cat bar.f90
SUBROUTINE foo(DPRS,DEN,LBOT,LTOP,KTS,KTE)
IMPLICIT NONE
INTEGER,INTENT(IN) :: KTS,KTE
INTEGER,INTENT(OUT) :: LBOT,LTOP
When profile based feedback indicates that a loop has a low iteration
count, it will often refuse to unroll even though unrolling is still
useful. Moreover, while it knows about the average loop iteration
count, it lacks the concept of a prevalent iteration count.
In particular, the header
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-22 19:49 ---
With the introduction of the new loop unroller in 4.0,
I think you mean 3.4.0 because the new unroller was in 3.4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29946
--- Comment #8 from hjl at lucon dot org 2006-11-22 20:02 ---
A testcase in C:
int
foo (float *array, int end)
{
int i;
float sum1, sum2;
sum2=0;
for (i=0; i end; i++)
sum2=sum2+array[i];
sum2=1./sum2;
sum1 =0.;
for (i=0; i end; i++)
sum1=sum1+array[i];
sum1
--- Comment #3 from dkouroun at cc dot uoi dot gr 2006-11-22 20:07 ---
Subject: Re: bootstrap failure on Linux AMD64
Quoting pinskia at gcc dot gnu dot org [EMAIL PROTECTED]:
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-22 16:42
---
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-11-22 20:10 ---
(In reply to comment #1)
With the introduction of the new loop unroller in 4.0,
I think you mean 3.4.0 because the new unroller was in 3.4.0.
You're right, it was introduced then. Although the old loop
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-22 20:14 ---
(In reply to comment #3)
what else can I do to check manually the glibc libraries?
I never learned how can somebody check the version of glibc installed
on his system. How can I do that?
for one where does
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-22 20:16 ---
I have a fix.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dkouroun at cc dot uoi dot gr 2006-11-22 20:18 ---
Subject: Re: bootstrap failure on Linux AMD64
# ls /usr/ -l
total 72
lrwxrwxrwx 1 root root 6 Nov 21 12:59 X11R6 - ../usr
drwxr-xr-x 2 root root 16384 Nov 22 17:21 bin
drwxr-xr-x 61 root root 8192 Nov 22
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-11-22 20:48 ---
(In reply to comment #0)
The following example should give an EOR error.
This is one of the things that the programmer has to
get right, a processor may do anything (including
silently ignoring the error, as
--- Comment #1 from burnus at gcc dot gnu dot org 2006-11-22 21:04 ---
Confirmed.
Accepted without warning by NAG f95, g95,sunf95 and ifort.
In order to determine the length of a character array, the size or shape of the
array does not matter.
--
burnus at gcc dot gnu dot org
--- Comment #6 from dkouroun at cc dot uoi dot gr 2006-11-22 21:23 ---
Subject: Re: bootstrap failure on Linux AMD64
--- Comment #1 from hjl at lucon dot org 2006-11-22 16:32 ---
Please try
# make -j5 bootstrap-lean
again it stops at the same point as it did initially.
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-11-22 21:27 ---
(In reply to comment #5)
Subject: Re: bootstrap failure on Linux AMD64
hope this helps
Yes gentoo is installing libc in the wrong directory. lib should be a symbol
link (or really what is currently lib32) to
--- Comment #8 from dkouroun at cc dot uoi dot gr 2006-11-22 21:39 ---
Subject: Re: bootstrap failure on Linux AMD64
Quoting pinskia at gcc dot gnu dot org [EMAIL PROTECTED]:
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-11-22 21:27
---
(In reply to comment
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-11-22 21:44 ---
(In reply to comment #8)
I do not think that the directory is wrong. I think you mean that it
install's in a directory which is not the one gcc expects it to be.
So I guess that gcc expects the 32bit libraries to
--- Comment #10 from dkouroun at cc dot uoi dot gr 2006-11-22 21:47 ---
Subject: Re: bootstrap failure on Linux AMD64
Quoting pinskia at gcc dot gnu dot org [EMAIL PROTECTED]:
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-11-22 21:44
---
(In reply to comment
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-11-22 21:58
---
Again this is a bug in the distro and not a bug in GCC, if gentoo wants that
directory layout, they are not going to be compatible with any other distros or
even most newer closed source software.
--
The following test program works as expected when compiled without -fopenmp.
In some cases, such as shown below, it fails when the loop termination
condition is already satisfied on entry:
[EMAIL PROTECTED] tmp]$ uname -a
Linux carmenere.cfa.harvard.edu 2.6.18-1.2200.fc5 #1 SMP Sat Oct 14
--- Comment #4 from tobi at gcc dot gnu dot org 2006-11-22 22:09 ---
Subject: Bug 29441
Author: tobi
Date: Wed Nov 22 22:09:14 2006
New Revision: 119101
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119101
Log:
fortran/
PR fortran/29441
* intrinsic.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-22 22:11 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
When compiling kmail with Debian's dpkg-buildpackage, cc1plus is killed by the
kernel due to memory shortage. This shows when using either g++ 4.0 or 4.1.
Files (including .ii files) are on the following URL:
http://errors.linuxonly.nl/gcc/
G++ version:
g++-4.0 (GCC) 4.0.4 20060904 (prerelease)
--- Comment #1 from amodra at bigpond dot net dot au 2006-11-22 22:21
---
relevant -O2 assembly is
.globl _dl_argv
.globl _dl_argv_internal
.hidden _dl_argv_internal
.set_dl_argv_internal,_dl_argv
.section.data.rel.ro,aw,@progbits
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-22 22:24 ---
Can you report what options you are using to compile?
Actually just copy and paste the exact command that is running out of memory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29948
--- Comment #9 from hjl at lucon dot org 2006-11-22 22:26 ---
Is HONOR_NANS missing somwhere?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29921
--- Comment #2 from amodra at bigpond dot net dot au 2006-11-22 22:27
---
Removing __attribute__ ((section (.data.rel.ro))) from _dl_argv_internal also
generates good code.
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
--- Comment #2 from sjoerd-gcc at linuxonly dot nl 2006-11-22 22:27 ---
Command line:
g++ -save-temps -DHAVE_CONFIG_H -I.
-I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./kmail -I..
-I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./libkmime
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-22 22:30 ---
.data.rel.ro, isn't that a special section?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
--- Comment #4 from amodra at bigpond dot net dot au 2006-11-22 22:41
---
Not particularly. s/.data.rel.ro/.mysect/ does the same thing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
Arguments for omp_set_num_threads/OMP_NUM_THREADS are used without checking for
validity, i.e.
$ cat omp_set_num_threads.f90
PROGRAM main
USE OMP_LIB
CALL omp_set_num_threads(-3)
!$OMP PARALLEL
WRITE(*,*) thread:, omp_get_thread_num()
!$OMP END PARALLEL
END PROGRAM
$ gfortran-4.3 -g
I noticed that sizes of functions in generated code change when I do simple
unrelated changes. Example:
# diff -u vi_small.c vi_big.c
--- vi_small.c 2006-11-22 23:35:39.0 +0100
+++ vi_big.c2006-11-22 23:35:42.0 +0100
@@ -3414,6 +3414,8 @@
} sockaddr_inet;
extern int
--- Comment #1 from vda dot linux at googlemail dot com 2006-11-22 22:57
---
Created an attachment (id=12669)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12669action=view)
Visual comparison of assembly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29950
--- Comment #2 from vda dot linux at googlemail dot com 2006-11-22 22:58
---
Created an attachment (id=12670)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12670action=view)
Complete testcase with .c, .o and .s files
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29950
--- Comment #10 from rakdver at gcc dot gnu dot org 2006-11-22 23:11
---
Subject: Bug 29921
Author: rakdver
Date: Wed Nov 22 23:11:15 2006
New Revision: 119102
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119102
Log:
PR tree-optimization/29921
* fold-const.c
--- Comment #1 from franke dot daniel at gmail dot com 2006-11-22 23:12
---
Correction: checks are already implemented for environment variables.
In above report OMP_NUM_THREADS is not affected, but omp_set_num_threads still
is.
--
--- Comment #11 from rakdver at gcc dot gnu dot org 2006-11-22 23:43
---
(In reply to comment #9)
Is HONOR_NANS missing somwhere?
Not really, it is basically the same problem as the one with -0 -- for some
time, ccp may believe that there might be a NaN (due to division by zero in
--- Comment #6 from jsm28 at gcc dot gnu dot org 2006-11-23 00:16 ---
Patch was discussed at
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00451.html
and had some objections from Geoff Keating.
I've come across another problem case and am testing another possible patch to
address both
--- Comment #2 from danglin at gcc dot gnu dot org 2006-11-23 00:25 ---
Introduced by r118475. However, it wasn't fixed by Andrew's fwprop.c
patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29840
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|build/genconditions |[4.3 Regression]
--- Comment #5 from patchapp at dberlin dot org 2006-11-23 00:35 ---
Subject: Bug number PR17711
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-11/msg01590.html
--
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-11-23 02:10
---
Actually the problem was that gfortran was failing to set the record length to
the value requested in the OPEN statement. Now as far as emitting an error or
warning I have a concern.
If the user specifies a
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net
|dot org
--- Comment #5 from dje at gcc dot gnu dot org 2006-11-23 02:31 ---
If GCC is not creating the alias correctly, that is a bug. However, we
previously agreed in PR 28598 that changing sections behind GCC's back is not
guaranteed to work.
--
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-11-23 03:12 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-23 03:13 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from richard at codesourcery dot com 2006-11-23 05:04
---
Subject: Re: [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
amodra at bigpond dot net dot au [EMAIL PROTECTED] writes:
AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot
90 matches
Mail list logo