--- Comment #7 from patchapp at dberlin dot org 2006-03-08 07:35 ---
Subject: Bug number PR19101
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/msg00415.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2006-03-08 06:56
---
Fixed on 4.1.1 and 4.2.0
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-03-08 06:54
---
Subject: Bug 26554
Author: jvdelisle
Date: Wed Mar 8 06:54:46 2006
New Revision: 111841
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111841
Log:
2006-03-07 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #4 from igodard at pacbell dot net 2006-03-08 06:21 ---
I tried to do so before submission (as I usually do) but wasn't able to do so.
Attempts to write a test case wouldn't fail. Sorry.
Ivan
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26278
--- Comment #6 from igodard at pacbell dot net 2006-03-08 06:16 ---
We don't use pre-compiled headers ourselves. Any precompiles are third-party or
standard library, and actually I was unaware that they were used. Can you tell
me the files that the header contained? Then I can identify w
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-03-08 06:04
---
Subject: Bug 26554
Author: jvdelisle
Date: Wed Mar 8 06:04:22 2006
New Revision: 111840
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111840
Log:
2006-03-07 Jerry DeLisle <[EMAIL PROTECTED]>
An example (which I got from looking a little at varasm.c):
struct a
{
int i;
};
int f(int *);
int g(struct a *b)
{
struct a *b1 =b;
int t = 0;
for(;b < b1+3;b++)
{
if (b==0) return 1;
int *c = &b->i;
if (c == 0) return 1;
t+=f(c);
}
return t;
}
---
--- Comment #3 from bangerth at dealii dot org 2006-03-08 05:14 ---
Your compiler simply runs out of memory. Don't do code like this. It will
also not be very efficient.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
---
--- Comment #2 from bangerth at dealii dot org 2006-03-08 05:11 ---
Without going into details with the different points, I agree that the
dump of the tree is unreadable and not helpful. I know Gaby disagrees,
but I take the liberty to confirm this report.
W.
--
bangerth at dealii d
--- Comment #4 from bangerth at dealii dot org 2006-03-08 05:09 ---
I agree with Richard and Andrew. I don't see why we should issue different
diagnostics for essentially the same case.
W.
--
bangerth at dealii dot org changed:
What|Removed |Adde
--- Comment #4 from bangerth at dealii dot org 2006-03-08 05:07 ---
I think we can confirm the problem. I doubt anyone will come around to
actually taking this on anytime soon, though...
W.
--
bangerth at dealii dot org changed:
What|Removed |Adde
--- Comment #1 from bangerth at dealii dot org 2006-03-08 05:04 ---
This is how it is supposed to be. Note that access control (i.e. whether
you can or cannot use a name) is not implemented by "hiding" the name.
The name of private members is always available, you may simply not
access i
--- Comment #5 from bangerth at dealii dot org 2006-03-08 05:02 ---
Confirmed. These two lines should behave the same, but don't:
--
extern bool flag;
int main()
{
char* p;
p = (true ? "a" : "lalala" );
p = (flag ? "a" : "lalala" );
}
--
g/x> /home/bangert
--- Comment #3 from bangerth at dealii dot org 2006-03-08 04:57 ---
Can you try to come up with a reasonably sized example code?
Thanks
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
---
--- Comment #3 from r_ovidius at eml dot cc 2006-03-08 04:56 ---
Yes, I just compiled 4.1 on linux and the testcase works there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25593
--- Comment #5 from bangerth at dealii dot org 2006-03-08 04:55 ---
I see you used precompiled headers. Does the same ICE happen if you
don't do that?
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--
--- Comment #1 from bangerth at dealii dot org 2006-03-08 04:52 ---
My understanding is that this code is in fact invalid (and icc
agrees with me). You may consider this part of the standard
gratuitously unfriendly, but remember that namespace aliases form
a directed graph and proving th
--- Comment #11 from bangerth at dealii dot org 2006-03-08 04:49 ---
This is indeed invalid under the present rules:
---
typedef std::map M;
namespace std {
extern std::ostream &operator <<(std::ostream &f, const M::value_type &p);
};
void f()
{
M m;
std::cop
--- Comment #10 from bangerth at dealii dot org 2006-03-08 04:43 ---
(In reply to comment #4)
> I looked at your link and at issue 197. I don't see how this applies to my bug
> report, especially in connection with _user defined_ types. What I don't
> understand is, why does g++ handle b
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-08 03:06 ---
Hmm, this works in "4.1.1 20060304" on x86_64 with -m32.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26600
--- Comment #17 from janis at gcc dot gnu dot org 2006-03-08 01:34 ---
A regression hunt on powerpc-linux using the testcase from comment #16
identified this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=101269
r101269 | jason | 2005-06-23 14:44:21 + (Thu, 23 Jun 2005)
--
htt
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-03-08 01:16
---
*** Bug 26595 has been marked as a duplicate of this bug. ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-03-08 01:16
---
Yes it is. See my comments there. I am working this issue.
*** This bug has been marked as a duplicate of 26509 ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-03-08 01:13
---
I think the votes are starting to come in on this one. I am going to get an
opinion from com.lang.fortran and then proceed. I do not thing the standards
disallow the desired behavior. Gfortran does the minimum
--- Comment #10 from tromey at gcc dot gnu dot org 2006-03-08 00:54 ---
Actually, Robin, could you send your current patch for this?
It seems like we should simply put it in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from wilson at gcc dot gnu dot org 2006-03-08 00:51 ---
Created an attachment (id=10989)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10989&action=view)
unfinished untested patch to fix stf_spill bug in ia64 libffi port
This is unfinished. It needs to be a bit cl
--- Comment #10 from wilson at gcc dot gnu dot org 2006-03-08 00:46 ---
I missed the denorm angle obviously. And the answer to the question about what
is different between native and interpreted execution would of course be
libffi, which took me far longer to remember than it should hav
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-08 00:37 ---
I looked and as far as I can see, this bug is fixed in 4.1.
PersistentByteMap.close now throws IOException.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
---
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26495
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.0 |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23706
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-08 00:11 ---
Fixed. Thanks Aldy for this documention.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from janis at gcc dot gnu dot org 2006-03-08 00:07 ---
A regression hunt on powerpc64-linux using the C test case from comment #4
identified this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=110705
r110705 | law | 2006-02-07 18:31:27 + (Tue, 07 Feb 2006)
That dat
--- Comment #32 from pinskia at gcc dot gnu dot org 2006-03-08 00:01
---
And now profiledbootstrap is broken a different way on the mainline so I am not
fixing this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from billingd at gcc dot gnu dot org 2006-03-07 23:55
---
Fixed by patch.
--
billingd at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #2 from billingd at gcc dot gnu dot org 2006-03-07 23:51
---
Subject: Bug 26588
Author: billingd
Date: Tue Mar 7 23:51:34 2006
New Revision: 111824
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111824
Log:
2006-03-08 David Billinghurst <[EMAIL PROTECTED]>
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-07 23:00 ---
Defining these types seems ok to me.
It would be nice if there were front end documentation
explaining that front ends are required to, though.
FWIW Alexandre Oliva has a patch to bug 8620
the "other way" -- by changi
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-07 22:49 ---
I tried this test case with my 4.1 build and it seemed to work fine.
opsy. gij HServer &
[1] 21044
opsy. gij HClient
READ: 224
READ: 12
opsy. java.net.SocketException: Socket Closed
at HServer$1.run (HServer.java:
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-07 22:44 ---
Testing a patch.
I think this bug report is a bit wrong, in that we don't actually
need to link the JNI library into libgcj. loadLibrary seems appropriate
here, particularly given that this code is seldom used.
--
--- Comment #7 from amylaar at gcc dot gnu dot org 2006-03-07 22:42 ---
(In reply to comment #6)
> Yes, if you need to detect loops, call the routine to detect natural loops.
> This is the way of the future.
> LOOP_NOTES are not.
Is flow_loops_find and the data that it initailizes a sta
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-07 22:41 ---
I believe this was fixed a while back.
The test cases work for me with 4.1.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
---
Hi,
Following is the list of benchmarks failed to compile/link using
--fwhole-program --combine option with GCC,
$/opt/gcc-nightly/4.1-20060228/bin/gcc -v
Using built-in specs.
Target: powerpc64-linux
Configured with: /home/gccbuild/gcc_4.1_anonsvn/4.1/configure
--prefix=/opt/gcc-nightly/4.1-20060
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26041
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-03-07 22:33 ---
Created an attachment (id=10987)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10987&action=view)
partial patch
This is a partial proof-of-concept patch that only deals
with minloc. The test should be fairly
--- Comment #6 from gchernis11 at msn dot com 2006-03-07 22:33 ---
(In reply to comment #5)
> Reducing.
What does it mean? How do i change status to active?
--
gchernis11 at msn dot com changed:
What|Removed |Added
---
--- Comment #13 from hjl at lucon dot org 2006-03-07 22:32 ---
Fixed.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|NEW
--- Comment #12 from hjl at gcc dot gnu dot org 2006-03-07 22:31 ---
Subject: Bug 26041
Author: hjl
Date: Tue Mar 7 22:30:58 2006
New Revision: 111822
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111822
Log:
2006-03-07 H.J. Lu <[EMAIL PROTECTED]>
PR fortran/26041
--- Comment #14 from hjl at gcc dot gnu dot org 2006-03-07 22:31 ---
Subject: Bug 26064
Author: hjl
Date: Tue Mar 7 22:30:58 2006
New Revision: 111822
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111822
Log:
2006-03-07 H.J. Lu <[EMAIL PROTECTED]>
PR fortran/26041
--- Comment #11 from hjl at gcc dot gnu dot org 2006-03-07 22:29 ---
Subject: Bug 26041
Author: hjl
Date: Tue Mar 7 22:29:32 2006
New Revision: 111821
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111821
Log:
2006-03-07 H.J. Lu <[EMAIL PROTECTED]>
PR fortran/26041
--- Comment #13 from hjl at gcc dot gnu dot org 2006-03-07 22:29 ---
Subject: Bug 26064
Author: hjl
Date: Tue Mar 7 22:29:32 2006
New Revision: 111821
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111821
Log:
2006-03-07 H.J. Lu <[EMAIL PROTECTED]>
PR fortran/26041
void fdct_int32()
{
int tmp4, tmp5, tmp7;
int z1, z2, z3, z4, z5;
int *dataptr;
int i;
for (i = 0; i < 8; i++) {
tmp7 = dataptr[0];
z3 = tmp4;
z4 = tmp5 + tmp7;
z5 = (z3 + z4) * ((int) 9633);
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-03-07 21:50 ---
(In reply to comment #5)
> (In reply to comment #4)
> > Actually there is nothing that uses LOOP_NOTEs other than the old RTL loop
> > optimizer. At least, nothing that _should_ use it. Wanna know about
> > loops?
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-07 21:41 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-07 21:39 ---
Subject: Bug 26103
Author: tromey
Date: Tue Mar 7 21:39:44 2006
New Revision: 111820
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111820
Log:
PR libgcj/26103:
* java/lang/ClassLoader.java (
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-07 21:34 ---
Subject: Bug 26103
Author: tromey
Date: Tue Mar 7 21:34:46 2006
New Revision: 111819
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111819
Log:
PR libgcj/26103:
* java/lang/ClassLoader.java (
The tm.h and m668k-none.c TRAGET_CPU_DEFAULT seem to be strange. Looks like
the #if TARGET_CPU_DEFAULT == xxx will never match.
--
Summary: Unable to build a mc68332 target
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-03-07 21:06
---
New reduced testcase:
struct s_3 { short s[3]; } z_3, s_3;
struct s_3 add_struct_3 (struct s_3 s){}
wack_struct_3 (void)
{
int i; register struct s_3 u = z_3;
u = add_struct_3 (u);
}
--
http://gcc.gnu.org/
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-03-07 21:02
---
The reduced testcase in this bug is fixed but the full testcase in the gdb
testsuite.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-03-07 20:52 ---
(In reply to comment #4)
> Actually there is nothing that uses LOOP_NOTEs other than the old RTL loop
> optimizer. At least, nothing that _should_ use it. Wanna know about loops?
> Find natural loops instead of de
--- Comment #7 from tom dot browder at fwb dot srs dot com 2006-03-07
20:37 ---
(In reply to comment #6)
> While I completely agree with you, I don't see a way to do that with the
> current framework. On the other hand, when (or if) we switch to cpplib, it
How does the current framewo
--- Comment #1 from pault at gcc dot gnu dot org 2006-03-07 20:19 ---
It seems that we have temporarily, at least, exhausted the supply of this genre
of bug!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-03-07 19:55
---
Janis could you figure out which patch fixed this on the mainline if it was
ever broken on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-03-07 19:52
---
This is fixed on the mainline how I don't know.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-07 19:47 ---
*** Bug 26597 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-07 19:47 ---
Here is the relevant section of the standard (TC1,
section 9.4.2, paragraph 4):
If a 'static' data member is of 'const' integral or 'const' enumeral type,
its declaration in the class definition can specify a '
--- Comment #3 from aldyh at gcc dot gnu dot org 2006-03-07 19:20 ---
Subject: Bug 26238
Author: aldyh
Date: Tue Mar 7 19:20:32 2006
New Revision: 111818
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111818
Log:
PR gomp/26238
* doc/passes.texi (Tree-SSA passes)
Consider the following code:
=== bug.cpp ===
struct Test {
static const int number=5;
int test(const int n);
};
int Test::test(const int n)
{
int max = number > n ? number : n;
return max;
}
int main()
{
Test t;
t.test(6);
return 0;
}
I get the following linker error:
/tmp/ccW
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-07 18:52 ---
Testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
--- Comment #3 from patchapp at dberlin dot org 2006-03-07 18:45 ---
Subject: Bug number PR libgcj/26522
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/msg00374.html
--
http://gcc.gnu.org/bug
--- Comment #32 from ebotcazou at gcc dot gnu dot org 2006-03-07 18:33
---
Created an attachment (id=10984)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10984&action=view)
Reduced testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
--- Comment #6 from daney at gcc dot gnu dot org 2006-03-07 18:29 ---
Should be fixed by the patch I just committed.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-07 18:16 ---
I think this was just fixed by David Daney:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111815
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26073
--- Comment #2 from pmcilroy at gmail dot com 2006-03-07 17:14 ---
Subject: Re: Optimizer hangs on conditional expression
OK, thanks very much.
I will let them know.
- Peter
On Mar 6, 2006, at 8:43 PM, pinskia at gcc dot gnu dot org wrote:
>
>
> --- Comment #1 from pinskia
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-07 17:08 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-07 17:07 ---
Subject: Bug 26351
Author: tromey
Date: Tue Mar 7 17:07:37 2006
New Revision: 111814
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111814
Log:
2006-03-07 fexx <[EMAIL PROTECTED]>
PR libgcj/26351:
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-07 16:58 ---
3.4.x is closed, we won't be putting any bug fixes on that branch.
(I think the next 3.4.x release will be the last one ever.)
This bug does seem to appear on the 4.0 branch.
I think I'll check in your patch, it seem
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-03-07 16:49
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-07 16:37 ---
I'm testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Assigned
--- Comment #8 from dir at lanl dot gov 2006-03-07 16:30 ---
Here are the ABSOFT and IBM xlf results -
[dranta:~/tests/gfortran-D] dir% f90 -o write30 write30.f
[dranta:~/tests/gfortran-D] dir% write30
read error occurred
[dranta:~/tests/gfortran-D] dir% xlf90 -o write30 write30.f
** d
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-03-07 16:26
---
Subject: Bug 26587
Author: rguenth
Date: Tue Mar 7 16:26:14 2006
New Revision: 111809
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111809
Log:
2006-03-07 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-03-07 16:23
---
Subject: Bug 26587
Author: rguenth
Date: Tue Mar 7 16:23:38 2006
New Revision: 111808
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111808
Log:
2006-03-07 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-07 16:16 ---
Does this stop the build? I think this error can safely be ignored.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-07 16:14 ---
It would be helpful to have a stack trace for the exception.
Or, Anthony, if you know more about the problem, could you update
this PR?
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-03-07 15:54
---
Here's an example where the code is invalid, but is accepted because
of the for-scope-warning machinery:
==
namespace N
{
int i;
}
int i;
void foo()
{
for (int i=0; i<10;
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-07 15:52 ---
Hmm, I almost want to say this is a dup of bug 26509.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #35 from pinskia at gcc dot gnu dot org 2006-03-07 15:50
---
*** Bug 26596 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-07 15:50 ---
*** This bug has been marked as a duplicate of 11341 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2006-03-07 15:42
---
(In reply to comment #15)
> I did manage to get GCC-4.1.0 Fortran to build, I simple 'reworked'
> GMP/MPFR...
OK. I'm closing this PR since it's not a bug in gfortran, but a mis-compilation
in GMP/MPFR.
> I bui
--- Comment #16 from diskman at kc dot rr dot com 2006-03-07 15:38 ---
Oh one other thing, I just wanted to thank everyone for pointing me in the
right direction and taking the time to help me out... To everyone, thank you!
--
diskman at kc dot rr dot com changed:
What
--- Comment #15 from diskman at kc dot rr dot com 2006-03-07 15:31 ---
The closest would be the "AlphaServer DS20", mine is the EV56 [PCA56] and the
DS20 is the EV6 [the very next generation].
I did manage to get GCC-4.1.0 Fortran to build, I simple 'reworked' GMP/MPFR...
I built GMP wi
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-07 15:16 ---
Now I think the idea in comment #3 is incorrect.
I looked at implementing it today, and I realized that
it will also cause a super() constructor call to
throw an exception.
The idea in comment #1 may still work. I'd
When precompiling stdc++.h during a bootstrap (make boostrap), the c++ compiler
crashes with an ICE. Here is the relevant part of the log:
...
make[2]: Entering directory
`/home/arend/tmp/build-gcc/i686-pc-cygwin/libstdc++-v3/include'
sed -e
'/^#/s/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_][ABCDEFGHIJKLMNOPQ
The second read should jump to the label with out comment.
[dranta:~/tests/gfortran-D] dir% gfortran -o write29 write29.f
[dranta:~/tests/gfortran-D] dir% write29
At line 7 of file write29.f
Fortran runtime error: End of file
[dranta:~/tests/gfortran-D] dir% cat write29.f
program test
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-03-07 14:26
---
Patches posted.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedT
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-07 13:35 ---
Hmm, shouldn't libgcjawt built even without the peers selected as someone might
have their own peers to install after GCJ was install? (this is directed
towards the reporter)
--
pinskia at gcc dot gnu dot org cha
--- Comment #1 from bero at arklinux dot org 2006-03-07 13:06 ---
Created an attachment (id=10980)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10980&action=view)
Build libgcjawt when using Qt peers
Attaching patch, currently tested only in a "It compiles, therefore it
works(R)"
Currently, libgcjawt (used, among other things, by OpenOffice.org) is built
only if the gtk peers are used.
Looks like the classpath guys have already fixed it to work with other peers,
but the Makefiles need updating.
--
Summary: libgcjawt should be built even if the gtk peers aren'
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-03-07 12:28
---
*** Bug 26591 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-07 12:28 ---
*** This bug has been marked as a duplicate of 26004 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-03-07 12:26
---
*** Bug 26592 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-03-07 12:26
---
I already entered your previous report into the database,
but forgot to notify you, sorry.
*** This bug has been marked as a duplicate of 26577 ***
--
reichelt at gcc dot gnu dot org changed:
What
1 - 100 of 110 matches
Mail list logo
