Hi,
31bit Ada executables segfault when built on a 64bit system with gcc 4.x.
The 31bit libgnat library is installed in /usr/lib. When I build an 31bit
executable with -m31 using a 64bit gcc executing the result failes with
a segfault in the gnatbind generated adainit function. Further
Returning to a single system.ads as before is not an option here because the
split was done for a good reason:
Right, definitely not an option. In particular since there are potentially
many other files that will be different between configurations.
Ada currently does not have built-in support
[Sorry for the delay]
That's an old problem, which has already been discussed IIRC: should
TYPE_MAX_VALUE/TYPE_MIN_VALUE be constrained by TYPE_PRECISION and
TYPE_UNSIGNED?
My feeling? Absolutely, TYPE_MIN_VALUE and TYPE_MAX_VALUE should
represent the set of values that an object of the
-20060228/irun
--enable-languages=c,fortran --host=i386-linux
--with-gmp=/cosmic/coudert/tmp/gfortran-20060228/gfortran_libs
Thread model: posix
gcc version 4.2.0 20060228 (experimental)
/tmpdir/opt/gfortran/gfortran-20060228/bin/../libexec/gcc/i386-linux/4.2.0/f951
omp_hello.f -ffixed-form -quiet
Hi,
Ada currently does not have built-in support for multilibs (there's a related
PR I believe).
#5911 I suppose.
Instead, it has another (similar but different) mechanism via the --RTS
make/compile/bind switch, which require manual build/install of several
gnatlib via calls to make -C gcc
I believe you that this is not an easy job. Maybe it is eased a bit by the
recent toplevel bootstrap changes?!
I do not think so. The situation wrt multilib has not changed AFAIK.
And in any case, this toplevel bootstrap change is still incomplete wrt
Ada (missing passing flags to Ada
On Tue, 2006-02-28 at 12:06 +0100, Eric Botcazou wrote:
[Sorry for the delay]
No worries.
I was actually referring to explicit constraints on TYPE_MAX_VALUE and
TYPE_MIN_VALUE derived from TYPE_PRECISION and TYPE_UNSIGNED, for example
that ceil(log2(TYPE_MAX_VALUE - TYPE_MIN_VALUE)) must be
Eric Botcazou wrote:
This problem was already raised when Diego contributed the VRP pass and Diego
ajusted it to cope with Ada. AFAIK Ada and VRP work fine on the 4.1 branch.
Which doesn't mean that Ada is DTRT. On the contrary, Ada ought to be
fixed. It's an ugly hack in
On 2/28/06, Diego Novillo [EMAIL PROTECTED] wrote:
Eric Botcazou wrote:
This problem was already raised when Diego contributed the VRP pass and
Diego
ajusted it to cope with Ada. AFAIK Ada and VRP work fine on the 4.1 branch.
Which doesn't mean that Ada is DTRT. On the contrary, Ada
I've a IA-32 backend question on the intended behaviour of the functions
ix86_binary_operator_ok and ix86_fixup_binary_operands.
My confusion is that these functions currently allow arithmetic
operations of the form reg = op(mem,immed) even though this
shape isn't supported by x86 ISA. For
Basically with the way Ada's setting of TYPE_MIN_VALUE/TYPE_MAX_VALUE
effectively makes them useless as we can not rely on them to
actually reflect the set of values allowed in an object.
Sorry, but why are you saying we can not rely on them to actually reflect the
set of values allowed in an
It's an ugly hack in extract_range_from_assert:
/* Special handling for integral types with super-types. Some FEs
construct integral types derived from other types and restrict
the range of values these new types may take.
It may happen that LIMIT is actually smaller than
Hi all,
in my tests gcc 4.1.0-RC{1,2} install headers into a root (/) include directory:
# cut -f 2- fl_wrapper.wlog | grep '^\/include\/' | cut -d / -f 1-4 | uniq
/include/c++
/include/c++/gcj
/include/c++/gnu
/include/c++/java
/include/c++/javax
/include/c++/org
/include/c++/java
René Rebe wrote:
Hi all,
in my tests gcc 4.1.0-RC{1,2} install headers into a root (/) include
directory:
Are you sure? The log you show is presumably from your build log; have
you verified that this is where the files are placed in the filesystem?
--prefix=/usr --bindir=/usr/bin
Hi,
On Tuesday 28 February 2006 19:50, Mark Mitchell wrote:
René Rebe wrote:
Hi all,
in my tests gcc 4.1.0-RC{1,2} install headers into a root (/) include
directory:
Are you sure? The log you show is presumably from your build log; have
you verified that this is where the files
René Rebe wrote:
Hi,
On Tuesday 28 February 2006 19:50, Mark Mitchell wrote:
René Rebe wrote:
Hi all,
in my tests gcc 4.1.0-RC{1,2} install headers into a root (/) include
directory:
Are you sure? The log you show is presumably from your build log; have
you verified that this is where
Hi again,
On Tuesday 28 February 2006 20:19, Mark Mitchell wrote:
It's too late to fix this for 4.1.0, but it's not too late for me to
include information in the release announcement. If you look in
$objdir/libjava/Makefile, what is the value of gxx_include_dir? I'm
assuming it's empty.
The current gcc only generates ELF type info for undefined symbol for
HPUX. This information is useful for linker to detect possible run-time
problems at link-time. Here is an example:
[EMAIL PROTECTED] mismatch]$ cat foo.c
#include stdio.h
extern void bar (void);
int times;
int
main ()
{
On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote:
Jeffrey A Law wrote:
My suspicions appear to be correct. This never triggers except for
Ada code and it's relatively common in Ada code. No surprise since
I don't think any other front-end abuses TYPE_MAX_VALUE in the way
the Ada
[ gcc-patches - gcc ]
On Tue, 28 Feb 2006, Mark Mitchell wrote:
That said, I guess it's fine to ignore the ones with makeinfo 4.5,
but based on my checks I'd be rather hesitant for us to require
anything later than 4.6.
I don't think we should tie our own hands in this way. Building GCC
Snapshot gcc-3.4-20060228 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20060228/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Tue, 2006-02-28 at 18:42 +0100, Eric Botcazou wrote:
Basically with the way Ada's setting of TYPE_MIN_VALUE/TYPE_MAX_VALUE
effectively makes them useless as we can not rely on them to
actually reflect the set of values allowed in an object.
Sorry, but why are you saying we can not rely
On Tue, 2006-02-28 at 18:50 +0100, Eric Botcazou wrote:
It's an ugly hack in extract_range_from_assert:
/* Special handling for integral types with super-types. Some FEs
construct integral types derived from other types and restrict
the range of values these new types may
Jeffrey A Law wrote:
Diego -- do you recall what code actually triggered this problem?
Not sure, exactly.
However, in figuring out what this code was working around, I remembered
this thread from Kenner where he fixed this particular FE bug:
On Tue, 2006-02-28 at 17:51 -0500, Diego Novillo wrote:
Jeffrey A Law wrote:
Diego -- do you recall what code actually triggered this problem?
Not sure, exactly.
However, in figuring out what this code was working around, I remembered
this thread from Kenner where he fixed this
in __libc_start_main ()
#5 0x08048141 in _start ()
PS: Some details on the static linking failure:
Driving: gfortran -fopenmp omp_hello.f -static -v -lgfortranbegin
-lgfortran -lm
Using built-in specs.
Target: i386-linux
Configured with: ../gcc/configure
--prefix=/cosmic/coudert/tmp/gfortran-20060228/irun
GCC 4.1 RC2 is now available from:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.0-20060223
Still OK on SPARC/Solaris:
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01558.html
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01557.html
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01556.html
On Tue, Feb 28, 2006 at 03:40:37PM -0700, Jeffrey A Law wrote:
Here's a great example from uintp.adb (which is the cause of the
testsuite hang FWIW)
We have a loop with the following termination code in uintp.num_bits
# BLOCK 8
# PRED: 5 [100.0%] (fallthru,exec) 6
Mark Mitchell wrote:
This will be the final patch for GCC 4.1.0. I plan to work through the
release checklist tonight. As always, the official announcement will
follow after the release has had time to make it to the mirrors.
Just a word of warning about this patch for unsuspecting
With clean sources on x86_64-linux-gnu, I am getting almost all tests
for running gij to fail. Does anyone know what is going on here?
Thanks,
Andrew Pinski
Basically with the way Ada's setting of TYPE_MIN_VALUE/TYPE_MAX_VALUE
effectively makes them useless as we can not rely on them to
actually reflect the set of values allowed in an object.
As we've all told you numerous times before, TYPE_MIN_VALUE/TYPE_MAX_VALUE
are meant *precisely*
Which doesn't mean that Ada is DTRT. On the contrary, Ada ought to be
fixed. It's an ugly hack in extract_range_from_assert:
It wasn't a bug in the Ada front end, but in fold, which was long-ago
fixed. I thought this was removed a long time ago?
We have a loop with the following termination code in uintp.num_bits
This sure looks like a bug in Num_Bits to me, not in the compilation
of the front-end.
The relevant code is:
function Num_Bits (Input : Uint) return Nat is
Bits : Nat;
Num : Nat;
begin
if
Hi! I'm attempting to build a iWMMXt/Linux EABI toolchain using gcc HEAD. I'm
using the target xscale-iwmmxt-linux-gnueabi, I've added support for this
target to binutils and built a cross linker etc.
I've proceeded to add a suitable target in config.gcc which supports EABI,
xscale and Linux
Hello,
during a recent discussion, it was pointed to my attention that
update_stmt is performance critical. I wondered why; this is the number
of update_stmt calls for combine.i (all the other passes have less then
1000 calls):
tree VRP : 17543 (10%)
tree copy propagation :
On Wed, Mar 01, 2006 at 04:27:48AM +, Steven Newbury wrote:
Hi! I'm attempting to build a iWMMXt/Linux EABI toolchain using gcc HEAD. I'm
using the target xscale-iwmmxt-linux-gnueabi, I've added support for this
target to binutils and built a cross linker etc.
I've proceeded to add a
On Feb 28, 2006, at 11:31 PM, Zdenek Dvorak wrote:
I have a patch that decreases number of update_stmt calls in tree alias
analysis to 46525; still, is it really that useful to run
pass_may_alias
*six* times during compilation? Obviously, we need the initial one,
and
there are comments
On Feb 28, 2006, at 11:31 PM, Zdenek Dvorak wrote:
tree FRE : 2060 ( 1%)
I bet the reason why this is so high is because we really don't
remove useless casts before going into SSA so it pills up.
-- Pinski
On Tue, Feb 28, 2006 at 10:02:03PM +0100, Gerald Pfeifer wrote:
That said, I don't really disagree about enforcing proper prerequisites to
build GCC and its documentation, my question in this case, and in general,
just is: Can the issue which we encountered be worked around in a simple
way
On Wed, 2006-03-01 at 05:31 +0100, Zdenek Dvorak wrote:
Hello,
during a recent discussion, it was pointed to my attention that
update_stmt is performance critical. I wondered why; this is the number
of update_stmt calls for combine.i (all the other passes have less then
1000 calls):
--- Daniel Jacobowitz [EMAIL PROTECTED] wrote:
On Wed, Mar 01, 2006 at 04:27:48AM +, Steven Newbury wrote:
Hi! I'm attempting to build a iWMMXt/Linux EABI toolchain using gcc HEAD.
I'm
using the target xscale-iwmmxt-linux-gnueabi, I've added support for this
target to binutils and
On Wed, Mar 01, 2006 at 04:57:03AM +, Steven Newbury wrote:
Thanks for the quick response!
I'm sure it seems I like to make hard wok for myself! It gets worse, I'm
porting Gentoo Linux to iWMMXt with pure EABI kernel and userspace. I'm not
concerned about being able to run old binaries.
--- Daniel Jacobowitz [EMAIL PROTECTED] wrote:
On Wed, Mar 01, 2006 at 04:57:03AM +, Steven Newbury wrote:
Thanks for the quick response!
I'm sure it seems I like to make hard wok for myself! It gets worse, I'm
porting Gentoo Linux to iWMMXt with pure EABI kernel and userspace. I'm
Hi,
I'm a big fan of Zack's over-my-dead-body motto when it comes to ditching
bootstrap with non-GCC compilers. :-) It turns out that bootstrap is again
broken on mainline for them (at least Sun CC) and that the problem is another
instance of PR bootstrap/18058.
Now the problem is
Gcc puts the section markers incorrect, resulting in a basically dummy effect
Take this simple example:
void simple_test(int X)
{
if (__builtin_expect((X==3),0))
call_slowpath_function();
else
call_fastpath_function();
}
this leads to the following
--- Comment #11 from dorit at il dot ibm dot com 2006-02-28 08:26 ---
Created an attachment (id=10935)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10935action=view)
tentative patch
I get a similar error message when trying to bootstrap mainline with
vectorization enabled:
--- Comment #23 from gdr at gcc dot gnu dot org 2006-02-28 08:43 ---
Fixed in 4.0 and higher.
Won't fix for 3.4.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #40 from gdr at gcc dot gnu dot org 2006-02-28 08:46 ---
Fixed in 4.1. and up.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from gdr at gcc dot gnu dot org 2006-02-28 08:47 ---
Fixed im 4.0 and up.
Won't fix for 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from gdr at gcc dot gnu dot org 2006-02-28 08:49 ---
No interest in fixing for 3.4.6.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from gdr at gcc dot gnu dot org 2006-02-28 08:51 ---
Fixed in 4.0 and up.
Won't fix for 3.4.5
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from gdr at gcc dot gnu dot org 2006-02-28 08:52 ---
Fixed in 4.0.
Won't fix in 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from gdr at gcc dot gnu dot org 2006-02-28 08:53 ---
Fixed in 4.0. and up.
Won't fix in 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from gdr at gcc dot gnu dot org 2006-02-28 08:54 ---
Fixed in 4.0. Won't fix for 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from gdr at integrable-solutions dot net 2006-02-28 09:02
---
Subject: Re: [3.4 only] Use of 'mov' may violate WAW dependency 'GR%, % in 1 -
127' (impliedf), specific resource number is 14
wilson at gcc dot gnu dot org [EMAIL PROTECTED] writes:
[...]
| As a
--- Comment #9 from gdr at gcc dot gnu dot org 2006-02-28 09:13 ---
Fixed in 3.4.6 too.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from gdr at gcc dot gnu dot org 2006-02-28 09:14 ---
Fixed in 4.0 and up. Won't fix for 3.4.6.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from gdr at gcc dot gnu dot org 2006-02-28 09:15 ---
Fixed in 4.0 and up. Won't fix for 3.4.6.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from gdr at gcc dot gnu dot org 2006-02-28 09:17 ---
Works in 4.0 and up. Won't fix for 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from gdr at gcc dot gnu dot org 2006-02-28 09:19 ---
Fxed in 4.0.2.
Won't fix for 3.4.6.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from gdr at gcc dot gnu dot org 2006-02-28 09:22 ---
Fixed in 4.0 and higher. Won't fix for 3.4.6.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from Ralf dot Wildenhues at gmx dot de 2006-02-28 09:23
---
Regarding the hardcoding problem, the HP-UX 11 ld option '+nodefaultrpath'
looks like it might be useful. It seems to be used for ia64 but not
hppa*64*, or hppa in general on hpux11.
I can not find
--- Comment #10 from gdr at gcc dot gnu dot org 2006-02-28 09:23 ---
won't fix for 3.4.6.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from gdr at gcc dot gnu dot org 2006-02-28 09:24 ---
Fixed in 4.0 and up.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from gdr at gcc dot gnu dot org 2006-02-28 09:25 ---
won't fix for 3.4.6.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from gdr at gcc dot gnu dot org 2006-02-28 09:27 ---
Fixed in 4.2 and up.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from gdr at gcc dot gnu dot org 2006-02-28 09:28 ---
Fixed in 4.0 and up.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from gdr at gcc dot gnu dot org 2006-02-28 09:29 ---
Fixed in 4.0 and up. Won't fix in 3.4.6.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from gdr at gcc dot gnu dot org 2006-02-28 09:30 ---
won't fix in 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from gdr at gcc dot gnu dot org 2006-02-28 09:32 ---
Fixed in 4.0 and up. Won't fix for 3.4.6.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #30 from gdr at gcc dot gnu dot org 2006-02-28 09:34 ---
Fixed in 4.0 and up.
Won't fix for 3.4.6.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from gdr at gcc dot gnu dot org 2006-02-28 09:35 ---
Fixed in 4.1.0. won't fix for 3.4.6.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from gdr at gcc dot gnu dot org 2006-02-28 09:36 ---
won't fix for 3.4.6.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from gdr at gcc dot gnu dot org 2006-02-28 09:37 ---
won't fix for 3.4.6.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from gdr at gcc dot gnu dot org 2006-02-28 09:38 ---
won't fix for 3.4.6.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from gdr at gcc dot gnu dot org 2006-02-28 09:39 ---
Fixed in 4.0 and higher. Won't fix in 3.4.6.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from gdr at gcc dot gnu dot org 2006-02-28 09:40 ---
won't fix for 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #7 from gdr at gcc dot gnu dot org 2006-02-28 09:40 ---
Fixed in 4.0.x and up.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from gdr at gcc dot gnu dot org 2006-02-28 09:41 ---
not cirtical.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from gdr at gcc dot gnu dot org 2006-02-28 09:41 ---
Fixed in 4.0. Won't fix for 3.4.6.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from gdr at gcc dot gnu dot org 2006-02-28 09:43 ---
won't fix.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from gdr at gcc dot gnu dot org 2006-02-28 09:44 ---
won't fix for 3.4.6.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from gdr at gcc dot gnu dot org 2006-02-28 09:44 ---
won't fix for 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from gdr at gcc dot gnu dot org 2006-02-28 09:45 ---
won't fix for 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from gdr at gcc dot gnu dot org 2006-02-28 09:46 ---
Fixed in 4.0 and up
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #4 from gdr at gcc dot gnu dot org 2006-02-28 09:47 ---
won't fix for 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from gdr at gcc dot gnu dot org 2006-02-28 09:47 ---
won't fix for 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from gdr at gcc dot gnu dot org 2006-02-28 09:48 ---
won't fix for 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #12 from gdr at gcc dot gnu dot org 2006-02-28 09:49 ---
Fixed in 4.0 and up.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from gdr at gcc dot gnu dot org 2006-02-28 09:50 ---
Fixed in 4.0.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from gdr at gcc dot gnu dot org 2006-02-28 09:50 ---
won't fix for 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from gdr at gcc dot gnu dot org 2006-02-28 09:52 ---
Fixed in 4.1 and up.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from yuri at tsoft dot com 2006-02-28 09:53 ---
So there should be no performance-related bugs reported any more since you only
care about correctness?
This IS a performance-related problem in gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17332
--- Comment #3 from gdr at gcc dot gnu dot org 2006-02-28 09:53 ---
fixed for 4.1.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #14 from gdr at gcc dot gnu dot org 2006-02-28 09:54 ---
Fixed in 4.0.0
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #9 from gdr at gcc dot gnu dot org 2006-02-28 09:54 ---
fixed for 4.0.0
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from gdr at gcc dot gnu dot org 2006-02-28 09:55 ---
won't fix.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from gdr at gcc dot gnu dot org 2006-02-28 09:58 ---
Fixed in 4.0.0
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from gdr at gcc dot gnu dot org 2006-02-28 09:59 ---
won't fix for 3.4.6.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from gdr at gcc dot gnu dot org 2006-02-28 09:59 ---
won't fix for 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
1 - 100 of 343 matches
Mail list logo
