--- Comment #5 from anlauf at gmx dot de 2006-03-17 08:06 ---
(In reply to comment #4)
I will, however, suggest that you reconsider using --fast-math with gfortran.
One of my codes works correctly without --fast-math, but it
will generate NaN's with it. I have not tracked down the
--- Comment #4 from aszodi at imp dot univie dot ac dot at 2006-03-17
08:53 ---
Andrew: I could build gcc 4.0.2 on my private iBook (OS X 10.4.4 = Darwin
V8.4.0), but not gcc 4.1.0 -- so the problem is most probably not G5-specific.
Fang: I used the nm that came with the system
--- Comment #5 from ccb at dl dot ac dot uk 2006-03-17 10:13 ---
How do I put this. The apple fenv.h supplied functions work by only setting
bits in mxcsr (not cw), and then only setting bits 1-6. Problem is that the
actual working bits are in 7-12 (as in fpu-387.h). So my little
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-03-17 10:33
---
*sigh*, seems like I opened a can of worms.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC 4.2 revision 112135 failed to compile SPEC cpu2000/197.parser.
Here is the minimal reproducer:
struct Exp_struct {
char type;
unsigned char cost;
};
extern void foo();
void print_expression(struct Exp_struct * n)
{
int i;
if (n-type == 2)
{
for (i=0; in-cost; i++) foo();
=== Cut ===
struct
QValueList
{
QValueList()
{
sh = new int;
}
QValueList operator+= ( QValueList);
int* sh;
};
void
queryIconsByContext()
{
QValueList iconlist[8];
QValueList iconlistResult;
for (int i=0; i8; i++)
iconlistResult+=iconlist[i];
}
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-03-17 11:03
---
For the testcase in comment #6 we fall into the
#ifdef CONSTANT_ALIGNMENT
else if (CONSTANT_CLASS_P (exp))
align = CONSTANT_ALIGNMENT (exp, align);
#endif
path and conclude the alignment is
--- Comment #2 from chris dot pitchford at newsint dot co dot uk
2006-03-17 11:18 ---
Currently the only C compiler on the box is GCC 3.4.2 which was downloaded from
Sunfreeware.com Is this the bootstrap compiler? To be honest this project is
the first time I've tried to compile GCC,
--- Comment #6 from ccb at dl dot ac dot uk 2006-03-17 11:30 ---
Created an attachment (id=11062)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11062action=view)
fpu-387.h based fpe control for mactel
The changes are to the SSE elements. It sets a mask as for the local floating
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-03-17 11:33
---
Currently the only C compiler on the box is GCC 3.4.2 which was downloaded
from Sunfreeware.com Is this the bootstrap compiler?
The bootstrap compiler is the compiler that compiles GCC during stage #1 of the
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-17 11:39 ---
Reduced testcase:
struct QValueList {
QValueList() { sh = new int; }
void foo();
int* sh;
};
void queryIconsByContext()
{
QValueList iconlist[8];
iconlist[7].foo();
}
ivopts generates
bb 2:
--- Comment #2 from mueller at gcc dot gnu dot org 2006-03-17 12:40 ---
one possible workaround would be to lower the ARRAY_REF's to indirect mem refs,
which I don't track
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-17 12:55 ---
For your warning patch another option is to simply only warn in either the
first or the second VRP pass, not in the third which is the only one run after
loop optimizations. Also you could ignore ADDR_EXPR
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-17 13:00 ---
Now I noticed IVOPTs generates a TMR with base == iconlist[1] + ivtmp,
offset -iconlist[0] and offset -4B (ivtmp being iconlist[0] initially).
Which boils down to using simply *ivtmp instead of a TMR. Funny.
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-17 13:17 ---
Simpler testcase:
struct Foo {
Foo() : s(1) {}
int s;
};
void foo(Foo);
void bar(void)
{
Foo x[4];
foo(x[0]);
}
bb 0:
ivtmp.34 = x[1];
L0:;
D.1822 = (int *) x[0];
D.1825 = -x;
MEM[base: D.1822 +
On Fri, 2006-03-17 at 12:40 +, mueller at gcc dot gnu dot org wrote:
--- Comment #2 from mueller at gcc dot gnu dot org 2006-03-17 12:40
---
one possible workaround would be to lower the ARRAY_REF's to indirect mem
refs,
which I don't track
Uh, no.
We are in fact, trying
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-03-17 13:31 ---
Subject: Re: -fivopts producing out of bounds
array refs
On Fri, 2006-03-17 at 12:40 +, mueller at gcc dot gnu dot org wrote:
--- Comment #2 from mueller at gcc dot gnu dot org 2006-03-17 12:40
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-17 14:29 ---
I see the same on ia64 for trunk.
Program received signal SIGSEGV, Segmentation fault.
0x402ed101 in gimplify_cond_expr (expr_p=0x2070aca8,
pre_p=0x607ffe8dc798, fallback=fb_none) at
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-03-17 14:32 ---
Forgot to mention - the ia64 build I was seeing this with was built with -g
-fno-inline and checking enabled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21898
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC target triplet||ia64-unknown-linux-gnu
Keywords|
I was looking through my testsuite results and noticed this fails.
We deinitely don't get a do loop at all:
L7:
addic. r0,r0,-1
add r4,r4,r2
addi r2,r2,1
bne- cr0,L7
L5:
..
blr
L6:
add r5,r5,r2
addi r2,r2,1
bdz L5
add
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26727
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-17 15:20 ---
Confirmed, the problem is:
/* If this expression has side effects, show we don't know it to be a
constant. Likewise if it's a pointer or aggregate type since in
those case we only want literals, since
Hello,
I've got a problem compiling the following source
[EMAIL PROTECTED]:~/tmp/xxx g++ -Wall -O2 b.cpp
b.cpp: In member function ‘void bClsT::DumpItems()’:
b.cpp:15: error: expected `;' before ‘aIter’
When I compile this code with borland's bcc it compiles without complaining.
So I think it
--
rmathew at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
On Mar 17, 2006, at 10:33 AM, Michael Tomuschat wrote:
vectorclass aCls T ::iterator aIter; // tut nicht
You forgot the typename keyword.
It should be:
typename vectorclass aCls T ::iterator aIter;
-- Pinski
Since gcc release 4 it is not possible anymore to call from Fortran a C routine
defined for a variable no. of arguments using the ellips notation.
It used to work on all previous gcc 3 releases,
and it still works on 32-bit machines, like e.g. Intel Pentium with
SUSE Linux 10.0 (gcc 4.0.2)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-17 15:41 ---
This is not valid code at all.
The fortran code assumes it is passing to a non varargs function which is
correct.
You should develop a different solution to this issue.
--
pinskia at gcc dot gnu dot org
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-17 16:11 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01110.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
trivial function using POD constructors says comparison is always 0.
If I remove any of the UInt16 constructors, the warning goes away.
This doesn't seem to happen in gcc-4.1.0
typedef unsigned short UInt16;
UInt16 pipe;
UInt16 cmp ()
{
UInt16 answer;
answer =
UInt16((pipe
--- Comment #1 from apl at alum dot mit dot edu 2006-03-17 16:48 ---
Created an attachment (id=11063)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11063action=view)
g++ -Wall -Werror -Wextra -O2 ...
(almost) trivial test case...
--
This is not the same as bug 11751 as the variable used with ++ is not reused.
Here the simple code:
sadd.i:
# 1 sadd.c
# 1 built-in
# 1 command line
# 1 sadd.c
typedef struct A A;
struct A {
int no;
A *sub;
};
void main()
{ A sub={0, ((void*)0)};
A root={0, sub};
I have worked around the problem. The HashTable methods now have __GCC__ code
that detects when the object has not had its constructor called, and
Performs the same initialization on-demand.
From the lack of responses indicating otherwise, I suppose I will assume this
is a bug in G++. Should
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-17 16:59 ---
pos=pos-sub[pos-no++];
This is undefined. You assign pos and use it without a sequence point.
*** This bug has been marked as a duplicate of 11751 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #64 from pinskia at gcc dot gnu dot org 2006-03-17 16:59
---
*** Bug 26730 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-17 17:00 ---
Fixed in 4.0.0, 3.4.6 was the last release of 3.4.x.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from apl at alum dot mit dot edu 2006-03-17 17:04 ---
Any clue as to the specific patch? We build with -Wall -Wextra -Werror, and
won't be able to upgrade to gcc-4.x for at least another couple of months.
--
apl at alum dot mit dot edu changed:
What
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-17 17:07 ---
Who knows, 3.4.x is dead, I would not doubt it was the merge of the tree-ssa
branch into the mainline which fixed this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
Jump threading causes bad interactions with loops:
int f(int t, int a, int x)
{
int n, g;
if (t)
n = a;
else
n = 4;
for (g=0; gn; g++)
x++;
return x;
}
This should be optimized to:
int f(int t, int a, int x)
{
int n, g;
if (t)
n = a;
else
n = 4;
x+=n;
return x;
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-17 17:32 ---
I almost think this is also the cause for PR 26727.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from rguenth at gcc dot gnu dot org 2006-03-17 17:38
---
Subject: Bug 26721
Author: rguenth
Date: Fri Mar 17 17:38:51 2006
New Revision: 112177
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112177
Log:
2006-03-17 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-03-17 17:39
---
This should be fixed now.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-17 17:52 ---
It also fails on AIX.
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01132.html
This worked in rev 112118 but failed in 112135.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-17 18:01 ---
The bug here is that the code that handles assignments
requiring an accessor method does not understand that
a constant might be subject to a narrowing constant conversion.
Hence it does not (e.g.) convert '0' to
--- Comment #3 from pault at gcc dot gnu dot org 2006-03-17 18:02 ---
I have a patch that fixes this and regtests OK; I will get it ready for
submission tomorrow.
Index: gcc/fortran/interface.c
===
***
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-17 18:06 ---
One potential fix is to call try_builtin_assignconv
in nested_field_access_fix or the like.
I haven't tried this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26720
--- Comment #3 from bkoz at gcc dot gnu dot org 2006-03-17 18:29 ---
Solution is to make
make_exports.pl.in
with NM_FOR_TARGET substition for current uses of 'nm'
This is done with other scripts.
This is low-priority, but this is enough of a hint so that you should be able
to try
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-03-17 18:31 ---
linking tests are native only, because finding all the support objects needed
for all the various platforms (crt.o, etc.) is hard. At least, this is the
traditional objection.
fixing glibcxx_gnu_ld_version still
--- Comment #18 from bkoz at gcc dot gnu dot org 2006-03-17 18:33 ---
is this still an active issue, or was it indicative of some temporary or
transient thing in the gcc sources?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25608
#include stdlib.h
int
bar(baz)
struct { int foo; } baz;
{
return baz.foo;
}
int main (void)
{
struct { int foo; } baz;
baz.foo = 0xdeadbeef;
if (bar(baz) != 0xdeadbeef)
abort();
}
Compiling at O2 results in no error.
compiling at O3 results in the
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-17 18:43 ---
This is invalid code, well undefined at best.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26732
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-17 18:45 ---
Related to PR 22249.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26732
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-17 18:47 ---
This is all:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00772.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26732
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-03-17 19:04 ---
Created an attachment (id=11064)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11064action=view)
example of how to do testcase
Explicitly use __mt_alloc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25409
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-03-17 19:10 ---
I'm closing this. I cannot reproduce it. In addition, the submitted testcase is
not sufficient: it has a complicated directory structure, makefiles, etc etc.
Also, does not demonstrate the so-called bug...
Please
--
Summary: move semantics vs. debug mode
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz
--- Comment #1 from bkoz at gcc dot gnu dot org 2006-03-17 19:15 ---
On libstdcxx_so_7-branch, there is preliminary support for move semantics.
These patches have some issues:
1) _GLIBCXX_STD_MOVE not listed in any ChangeLog entry...
2) new fails in debug mode.
First pointed out
--- Comment #2 from bkoz at gcc dot gnu dot org 2006-03-17 19:16 ---
Created an attachment (id=11065)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11065action=view)
patch to test debug mode
This runs the testsuite with -D_GLIBCXX_DEBUG.
--
--- Comment #3 from pcarlini at suse dot de 2006-03-17 19:48 ---
(In reply to comment #1)
On libstdcxx_so_7-branch, there is preliminary support for move semantics.
These patches have some issues:
1) _GLIBCXX_STD_MOVE not listed in any ChangeLog entry...
2) new fails in debug
--- Comment #4 from joseph at codesourcery dot com 2006-03-17 19:48 ---
Subject: Re: Accepts invalid code at different optimization
levels.
Bug 16876 is a related case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26732
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-17 20:02 ---
Confirmed. Though SCEV should be taught to handle this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The compiler builds but when it tries to build libgcc I get a bunch of ICEs.
Here is a small test case that will not compile with -O2 on ia64-hp-hpux11.23
with the ToT compiler:
extern int c;
long long __negti2 () { return (-c); }
I believe the problem is due to the IA64 speculation changes that
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
$ cat conv-implied-open.f90
program main
implicit none
integer (kind=8) :: i1, i2, i3
write (10) 1_8
close (10)
open (10,status=old, form=unformatted, access=direct, recl=8)
read (10,rec=1) i1
read (10,rec=2) i2
read (10,rec=3) i3
print '(3Z16,1X)',i1,i2,i3
end program main
$
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-03-17 21:12 ---
Following the discussion on comp.lang.fortran on this subject,
I'm tempted to mark this WONTFIX. This feature can cause
a lot of headaches to implement and is of questionable
semantics.
Any objections?
--
--- Comment #1 from mkuvyrkov at gcc dot gnu dot org 2006-03-17 21:16
---
(In reply to comment #0)
The compiler builds but when it tries to build libgcc I get a bunch of ICEs.
Here is a small test case that will not compile with -O2 on ia64-hp-hpux11.23
with the ToT compiler:
On Mar 17, 2006, at 4:16 PM, mkuvyrkov at gcc dot gnu dot org wrote:
Unfortunately, I don't have access to HP-UX and the bug doesn't appear
on
ia64-linux, so can you please provide some more information for the
failure
like backtrace.
A cross compile will most likely reproduce it.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-17 21:19 ---
Subject: Re: [4.2 Regression] GCC cannot bootstrap on IA64 HP-UX
On Mar 17, 2006, at 4:16 PM, mkuvyrkov at gcc dot gnu dot org wrote:
Unfortunately, I don't have access to HP-UX and the bug doesn't appear
on
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-17 21:20 ---
hmm, I get:
options.c:3863: error: `MASK_ILP32' undeclared here (not in a function)
or was there a fix for this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
--- Comment #4 from sje at cup dot hp dot com 2006-03-17 21:25 ---
I already fixed the problem in comment 3 with an 'obvious' checkin to
config/ia64/ia64.opts.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
--- Comment #5 from sje at cup dot hp dot com 2006-03-17 21:47 ---
The debugger shows:
(gdb) p debug_rtx(*unused_listp)
(deps_list 34 (nil) 0 [0x0])
(gdb) p debug_rtx(prev_link)
(UnKnown Unknown)
When I print unused_insn_list I get a long RTL that I couldn't capture.
Here is a
--- Comment #6 from sje at cup dot hp dot com 2006-03-17 22:34 ---
I applied the patch that Maxim created for PR 26725 but it did not seem to help
this problem. I verified the problem happened on ia64-hp-hpux11.23 in LP64
mode as well as ILP32 mode so that makes it more surprising that
bkoz at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| is this still an active issue, or was it indicative of some temporary or
| transient thing in the gcc sources?
Now, I get a segmentation fault -- instead of dead lock.
gcjx is compiled with mainline GCC/g++.
I was trying to compile
--- Comment #19 from gdr at integrable-solutions dot net 2006-03-17 23:37
---
Subject: Re: g++ miscompiles gcjx
bkoz at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| is this still an active issue, or was it indicative of some temporary or
| transient thing in the gcc sources?
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-03-17 23:39 ---
t.c: In function '__negti2':
t.c:4: internal compiler error: in add_forw_dep, at sched-deps.c:1644
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-17 23:57 ---
Confirmed, with a cross compiler.
here is the backtrace:
#1 0x0083e49c in add_forw_dep (to=0x1d1a230, link=0x1db9100) at
../../gcc/sched-deps.c:1644
#2 0x0083e8f4 in compute_forward_dependences (head=0x1d1a640,
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2006-03-18 01:56
---
Subject: Bug 26509
Author: jvdelisle
Date: Sat Mar 18 01:56:07 2006
New Revision: 112198
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112198
Log:
2006-03-17 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2006-03-18 01:59
---
Subject: Bug 26509
Author: jvdelisle
Date: Sat Mar 18 01:59:50 2006
New Revision: 112199
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112199
Log:
2006-03-17 Jerry DeLisle [EMAIL PROTECTED]
PR
The testcase g++.old-deja/g++.pt/friend36.C ICEs on mainline:
friend36.C: In instantiation of 'Sint':
friend36.C:12: instantiated from here
friend36.C:9: error: redefinition of 'templateclass T void f(T)'
friend36.C:4: error: 'templateclass T void f(T)' previously declared here
friend36.C:9:
The following testcases cause ICEs on mainline:
g++.old-deja/g++.bugs/900213_03.C
g++.old-deja/g++.other/pmf2.C
g++.old-deja/g++.other/pmf7.C
They all crash at the same position:
pmf2.C: In function 'void f()':
pmf2.C:17: error: ISO C++ forbids taking the address of a bound member function
to
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 03:08 ---
Grrr. Well confirmed. The reason why this does show up in the testresults is
because of the follow:
fmp = ptr-function_member; // { dg-error }
pmf = pf-f; // { dg-error } not a valid pmf expression
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-18 03:09 ---
So who ever fixes this bug, please also fix the testsuite so the testsuite will
show the ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26740
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 03:11 ---
Confirmed.
friend void f(T) {} // { dg-error } redeclaration
Grrr oh well.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
In testing gfortran's capacity to deal with iso_varying_string, it was found
that the error Specification function 'len_' at (1) must be PURE was produced
- see testcase below. This is obviously incorrect because elemental functions
are pure.
The patch and the testcase appear below.
Paul Thomas
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-18 06:05 ---
Since this worked for me and this is only report of this failure, something
must be up with the source you used. Closing as works for me.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 06:07 ---
We do not support the binaries. Please use the fortran mailing list for these
binaries. [EMAIL PROTECTED] is the place you should be reporting problems.
Note these binaries work for a lot of people.
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-18 06:20 ---
crosstools and the crossgcc list is the best place to ask questions like this
really.
Second sysroot can be changed at runtime now. So this is not a bug and closing
as such.
--
pinskia at gcc dot gnu dot org
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-18 06:22 ---
As I mentioned 4.0.0 works for me so closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 06:25 ---
Since this does not show up in 4.0.0 closing as won't fix as 3.4.6 was the last
release.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 06:30 ---
Was this fixed?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-03-18 06:31
---
I know for sure the binaries do not work on Win98. This was reported before.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25178
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-18 06:33 ---
PR 26161 might had fixed this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-18 06:34 ---
(In reply to comment #4)
I can reproduce it with 3.3.4 (Debian 1:3.3.4-9) on alpha-linux. Seems to be
some kind of memory corruption, trying to reduce the test case fails.
Any news on that reduction?
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 06:36 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-18 06:38 ---
Confirm based on http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01186.html
If PR 26731 gets fixed, this testcase needs to be changed (or removed) as it
will cause the testcase to always fail.
--
pinskia at
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
98 matches
Mail list logo
