--- Comment #12 from martin at mpa-garching dot mpg dot de 2006-03-09
07:12 ---
(In reply to comment #11)
> OK, after some discussion on comp.lang.fortran it is clear tha END and EOR are
> not error conditions. They are there to allow for example, reading in a loop
> until the end of a
--- Comment #5 from markfhaigh at sbcglobal dot net 2006-03-09 07:06
---
Created an attachment (id=11005)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11005&action=view)
Fix for trunk (against 2006-03-03 CVS)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26613
--- Comment #4 from markfhaigh at sbcglobal dot net 2006-03-09 07:05
---
Created an attachment (id=11004)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11004&action=view)
Fix for 4.1.x branch (against 2006-03-03 CVS)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26613
--- Comment #3 from markfhaigh at sbcglobal dot net 2006-03-09 07:04
---
Created an attachment (id=11003)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11003&action=view)
Fix for 4.0.x branch (against 2006-03-03 CVS)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26613
--- Comment #2 from markfhaigh at sbcglobal dot net 2006-03-09 07:03
---
Created an attachment (id=11002)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11002&action=view)
Fix for 3.4.x branch (against 2006-03-03 CVS)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26613
--- Comment #1 from markfhaigh at sbcglobal dot net 2006-03-09 07:02
---
Created an attachment (id=11001)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11001&action=view)
Fix for 3.3.x branch (against 2006-03-03 CVS)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26613
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-03-09 06:59
---
I will see if I can fix this. I fear some serious messing with all the
matching routines may be required if it can not be handled in scanner.c
--
jvdelisle at gcc dot gnu dot org changed:
What
When I run "make check" to verify my gcc-4.1.0 build, I get this output:
Fixed: types/vxTypesBase.h
Fixed: unistd.h
Fixed: wchar.h
Fixed: widec.h
Newly fixed header: ia64/sys/getppdp.h
There were fixinclude test FAILURES
make[2]: *** [check] Error 1
make[2]: Leaving directory `/build/gccobj/fixin
The gen_type() function in gcc/c-aux-info.c contains a logic bug that causes
garbage to be output to the file specified by the -aux-info switch.
The crux of the problem is that gen_type() uses a global variable (data_type)
to build parts of the string to be output by -aux-info. However, there are
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-03-09 06:39
---
OK, after some discussion on comp.lang.fortran it is clear tha END and EOR are
not error conditions. They are there to allow for example, reading in a loop
until the end of a file is reached and branching out.
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-03-09 06:08
---
A revised patch has been submitted that does what might be expected and issues
a warning on -pedantic if the ampersand is missing in a continued character
constant.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #5 from pault at gcc dot gnu dot org 2006-03-09 05:52 ---
Subject: Bug 26257
Author: pault
Date: Thu Mar 9 05:52:06 2006
New Revision: 111860
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111860
Log:
2006-03-09 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/26
--- Comment #2 from mckinlay at redhat dot com 2006-03-09 03:16 ---
Can anyone make a test case for this? I was unable to reproduce it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26390
--- Comment #26 from echristo at apple dot com 2006-03-09 03:13 ---
GOFAST was a library shipped for mips that I added a configure option to
continue to allow to compile. I fully doubt that it's in use anywhere now so
can probably be removed.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-09 01:12 ---
I'm closing since it is fixed in the current release.
I haven't found the precise fix so I don't know if a 4.0.x
backport is possible.
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-09 00:54 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #17 from geoffk at gcc dot gnu dot org 2006-03-09 00:53 ---
I made 26612 to track the similar situation with visibility.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10591
In bug 10591, it's pointed out that you can use the ODR rules to clear the
TREE_PUBLIC flag. You can do the same thing to make something have hidden
visibility even though it's not declared so.
In fact, this is a requirement. For example, in bug 19664, I mention that if
the user declares
struct
--- Comment #16 from geoffk at gcc dot gnu dot org 2006-03-09 00:48 ---
Oops! I got confused about visibility vs. TREE_PUBLIC. I think it would be
better to track the visibility stuff under a different bug. The previous
comment does apply when something is in an anonymous namespace, b
--- Comment #15 from geoffk at gcc dot gnu dot org 2006-03-09 00:44 ---
Another case is when someone writes
struct a_struct __attribute__((visibility(hidden)));
void foo(a_struct &) { }
Even though "foo" is not marked hidden it should still be hidden, because it
could be overloaded in
--- Comment #14 from geoffk at gcc dot gnu dot org 2006-03-09 00:37 ---
This is the same original report as bug 25915, which then was generalised as
follows:
Any entity which could be defined more than once (like a class or an inline
function) but whose token stream refers to a function
--- Comment #13 from geoffk at gcc dot gnu dot org 2006-03-09 00:35 ---
*** Bug 25915 has been marked as a duplicate of this bug. ***
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from geoffk at gcc dot gnu dot org 2006-03-09 00:35 ---
*** This bug has been marked as a duplicate of 10591 ***
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
--
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=19546
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-09 00:34 ---
Reopening since the testcase has been xfailed IIRC.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-09 00:33 ---
Fixed in 4.0.0. 3.4.6 has been tagged already and has been released (no
announcement has been made but it is up on the ftp server already).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-09 00:29 ---
Fixed so closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from patchapp at dberlin dot org 2006-03-09 00:25 ---
Subject: Bug number PR25378
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/msg00477.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-08 23:40 ---
Fixed in 4.0.0. 3.4.6 has been tagged already and has been released (no
announcement has been made but it is up on the ftp server already).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-03-08 23:40 ---
Fixed in 4.0.0. 3.4.6 has been tagged already and has been released (no
announcement has been made but it is up on the ftp server already).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-08 23:39 ---
Fixed in 4.0.0. 3.4.6 has been tagged already and has been released (no
announcement has been made but it is up on the ftp server already).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-03-08 23:38
---
Fixed in 4.0.0. 3.4.6 has been tagged already and has been released (no
announcement has been made but it is up on the ftp server already).
--
pinskia at gcc dot gnu dot org changed:
What|Remov
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-03-08 23:37 ---
Fixed in 4.0.0. 3.4.6 has been tagged already and has been released (no
announcement has been made but it is up on the ftp server already).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from bowie dot owens at csiro dot au 2006-03-08 22:39
---
Created an attachment (id=11000)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11000&action=view)
simpler preprocessed C++ code that causes ICE
Removed include of valarray and iostream to produce simpler pre
--- Comment #11 from pcarlini at suse dot de 2006-03-08 22:36 ---
Hum, I see. Therefore c++/21682 is also invalid? And EDG too, apparently ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26605
--- Comment #1 from bowie dot owens at csiro dot au 2006-03-08 22:34
---
Created an attachment (id=10999)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10999&action=view)
preprocessed output from save-temps that triggers ICE
GZIP compressed to make it within the size limit. Will
I consistently get the following ICE on this C++ code.
omp_harness.cpp:39: internal compiler error: in omp_add_variable, at
gimplify.c:4257
The code is not legit and there are several errors but this is because I have
cut down a larger program.
I am using the gomp-branch and gcc -v reports:
Usi
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-03-08 22:28
---
I think the code in Comment #1 is unambiguously invalid.
7.3.3/11 says says that a function declaration in namespace scope may not match
the declaration of a function introduced by a using declaration; i.e., the
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-08 22:21 ---
I should had looked into this one. This is what I was afraid of when this
idea 128bits long double went it. It was not the optimization which I thought
was applied but instead just the compiling of darwin-ldouble.
--- Comment #2 from langel at redhat dot com 2006-03-08 22:18 ---
Created an attachment (id=10998)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10998&action=view)
problem is caused because of the drawImage call in paint. updated test case
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-08 22:07 ---
3.4.6 is frozen and 3.4.x is now retired.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from bergner at vnet dot ibm dot com 2006-03-08 22:03
---
Created an attachment (id=10997)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10997&action=view)
Reduced test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26610
mminimal-toc raid6int8.i
Reading specs from
/home/bergner/install-3_4/lib/gcc/powerpc64-linux/3.4.6/specs
Configured with: /home/bergner/gcc-20060308-3_4/configure
--target=powerpc64-linux --host=powerpc64-linux --build=powerpc64-linux
--with-cpu=default32 --enable-threads=posix --enable-shared
--- Comment #2 from pault at gcc dot gnu dot org 2006-03-08 21:44 ---
I have a patch which is just now regtesting. It does the obvious:
set initial index = 0
if (the max/min condition is met or index = 0)
{
set index to the current position
update the value for comparison
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-08 21:24 ---
Hmm, looking at this again, it looks really like PR 23086.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from langel at redhat dot com 2006-03-08 20:51 ---
Created an attachment (id=10995)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10995&action=view)
roll mouse over text area and choice box
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22163
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-08 19:47 ---
Variable: i, UID 1520, int, is aliased, is addressable, default def: i_3
Variable: j, UID 1521, int, is aliased, is addressable, default def: j_5
Variable: b, UID 1516, int, is aliased, is addressable, call clobber
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-08 19:44 ---
Also this bug which is most likely what is causing there to be too many VOPS in
the current representation which is why I added memory-hog and compile-time-hog
to the keywords.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #1 from dberlin at gcc dot gnu dot org 2006-03-08 19:44 ---
Subject: Re: New: address of local variables
are said to escape even though it is obvious they don't
On Wed, 2006-03-08 at 18:59 +, pinskia at gcc dot gnu dot org wrote:
> Testcase:
> int *d1;
> int g(
On Wed, 2006-03-08 at 18:59 +, pinskia at gcc dot gnu dot org wrote:
> Testcase:
> int *d1;
> int g(int *b)
> {
> d1 = b;
> }
> int f(int a, int b, int c)
> {
> int i, j;
> int *d;
> if (a)
> d = &i;
> else
> d = &j;
> i = 2;
> j = 3;
> g(&b);
> if (i!=2)
>link_err
Testcase:
int h(int *);
struct a1
{
int i[2];
};
void link_error();
int f(struct a1 a, int i,int *c)
{
int b;
void *g = &a.i[i];
*(int*)g = 1;
h(&b);
if (a.i[i] !=1)
link_error();
return b+c[i*2];
}
---
# VUSE ;
# VUSE ;
# VUSE ;
D.1996_14 = *D.1995_13;
That i
--- Comment #8 from igodard at pacbell dot net 2006-03-08 19:29 ---
Well I was really surprised to see this -fpreprocessed option in the -v output,
so I did a little digging. It seems that this option is set by the driver
whenever -save-temps is set. It does not come from my command line
--- Comment #14 from tromey at gcc dot gnu dot org 2006-03-08 19:27 ---
I've been looking into this a bit.
The current problem I see is that the heavyweight lock stuff
relies on the GC. This won't interact well with the current
code in natReference.cc, as those data structures are not
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-08 19:11 ---
This was caused by the 128bit long doubles patches (well really caused by a
secondary patch to work around a code gen issue).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Summary|[4.2 Regression] Illegal|[4.1/4.2 Regr
--- Comment #2 from edmar at freescale dot com 2006-03-08 19:10 ---
Same error observed on gcc-4_1-branch 20060308
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26607
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-08 19:07 ---
Subject: Re: Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
>
>
>
> --- Comment #1 from aldyh at gcc dot gnu dot org 2006-03-08 19:05 ---
> I can reproduce the runtime error, but not
>
>
>
> --- Comment #1 from aldyh at gcc dot gnu dot org 2006-03-08 19:05 ---
> I can reproduce the runtime error, but not the compile error.
>
> pantani:/tmp/2$ type gcc
> gcc is /tmp/2/bin/gcc
> pantani:/tmp/2$ gcc a.c -fopenmp
> pantani:/tmp/2$ ./a.out
> ./a.out: error while loading
--- Comment #1 from aldyh at gcc dot gnu dot org 2006-03-08 19:05 ---
I can reproduce the runtime error, but not the compile error.
pantani:/tmp/2$ type gcc
gcc is /tmp/2/bin/gcc
pantani:/tmp/2$ gcc a.c -fopenmp
pantani:/tmp/2$ ./a.out
./a.out: error while loading shared libraries: libg
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC host triplet|x86_64-unknown-linux-gnu|
Summary|Illegal inlined assembler on|[4.2 Regression] Ill
--- Comment #1 from edmar at freescale dot com 2006-03-08 19:01 ---
Created an attachment (id=10994)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10994&action=view)
Intermediate file for reported bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26607
Testcase:
int *d1;
int g(int *b)
{
d1 = b;
}
int f(int a, int b, int c)
{
int i, j;
int *d;
if (a)
d = &i;
else
d = &j;
i = 2;
j = 3;
g(&b);
if (i!=2)
link_error();
if (j!=3)
link_error();
return *d;
}
int main(void)
{
f(1, 2,3);
return 0;
}
This should link
>
/local/gnu_toolchain/build_area/obj_gcc_gcc-trunk_e500v1/./gcc/xgcc
-B/local/gnu_toolchain/build_area/obj_gcc_gcc-trunk_e500v1/./gcc/
-B/local/gnu_toolchain/install-gcc-trunk-20060308-e500v1/powerpc-unknown-linux-gnuspe/bin/
-B/local/gnu_toolchain/install-gcc-trunk-20060308-e500v1/powerpc-unknown-li
--- Comment #12 from pcarlini at suse dot de 2006-03-08 18:45 ---
(In reply to comment #11)
> I changed the PR component to a historically more probable one, to avoid
> blaming libstdc++, as it seems that's an conclusion you're trying to avoid.
Agreed, *as a miscompilation*, can be a re
--- Comment #3 from mckinlay at redhat dot com 2006-03-08 18:36 ---
Yes. This is fixed in GCC 4.1.
--
mckinlay at redhat dot com changed:
What|Removed |Added
--- Comment #11 from hp at gcc dot gnu dot org 2006-03-08 18:35 ---
Uh, make no mistake, this *is* a regression; see the original description.
There's a revision before which this test worked and a revision after
which it does not work. This happened in 4.1 era, so it's a 4.1 regression
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2006-03-08 18:10
---
Created an attachment (id=10993)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10993&action=view)
Naive fix.
It tweaks 4 (really 3) C source files and is sufficient to overcome the
problem.
But it's probab
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-03-08 17:56
---
Hmm, if I change the reduced testcase from 0 ... -1 to -1 ... 0, it works for
the C testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-03-08 17:55
---
This is a middle-end problem:
~/eric> gcc t.c
t.c: In function 'foo':
t.c:5: warning: empty range specified
t.c:3: internal compiler error: in tree_low_cst, at tree.c:4423
Please submit a full bug report,
with p
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2006-03-08 17:53
---
Created an attachment (id=10992)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10992&action=view)
Reduced C testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18859
--- Comment #7 from bangerth at dealii dot org 2006-03-08 17:21 ---
(In reply to comment #6)
> I'm considering filing a defect report (for a standard clarification) to the
> commitee but I would like to make sure I'm not climbing any trees here... In
> your first reply you said "My under
--- Comment #6 from emilp at mac dot com 2006-03-08 16:47 ---
I'm considering filing a defect report (for a standard clarification) to the
commitee but I would like to make sure I'm not climbing any trees here... In
your first reply you said "My understanding is that this code is in fact
--- Comment #12 from law at redhat dot com 2006-03-08 16:43 ---
*** Bug 26406 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26344
--- Comment #16 from law at redhat dot com 2006-03-08 16:43 ---
C++ version of the problems in 26344. Fixing 26344 will fix this bug as well.
*** This bug has been marked as a duplicate of 26344 ***
--
law at redhat dot com changed:
What|Removed
--- Comment #3 from gbenson at redhat dot com 2006-03-08 16:32 ---
See http://people.redhat.com/gbenson/throwpoint-report.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21891
--
gbenson at redhat dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |gbenson at redhat dot com
|dot org |
--- Comment #3 from allali at univ-mlv dot fr 2006-03-08 16:30 ---
(In reply to comment #2)
> All < 3.4.0 accept the code. Fixed with the new C++ parser.
>
I've checked and you're right. Is there a way to have array elements
initialized by a specific constructor in g++ > 3.4 (to get
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-08 16:30 ---
Isn't this fixed in 4.1?
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-08 16:25 ---
All < 3.4.0 accept the code. Fixed with the new C++ parser.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pcarlini at suse dot de 2006-03-08 16:20 ---
The below also works already (can make for an useful if ugly workaround, in
some cases, e.g., c++/21682):
namespace one
{
template
void
fun(T);
}
namespace two
{
template
void
fun(T);
}
using one::fun
--- Comment #4 from bonzini at gnu dot org 2006-03-08 16:10 ---
Subject: Bug 26500
Author: bonzini
Date: Wed Mar 8 16:10:44 2006
New Revision: 111845
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111845
Log:
2006-03-08 Paolo Bonzini <[EMAIL PROTECTED]>
PR bootstrap/
--- Comment #5 from bonzini at gnu dot org 2006-03-08 16:11 ---
patch committed
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from pcarlini at suse dot de 2006-03-08 16:08 ---
Hardly a regression, considering that ext/pb_assoc has been released for the
first time in 4.1.0 ;)
--
pcarlini at suse dot de changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-08 16:06 ---
Fixed in 4.0.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
Target Milestone|--- |4.1.1
http://gcc
--
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
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25815
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-08 15:57 ---
(In reply to comment #2)
> However, today I discovered that the newer cctools break gcc-3.4.x.
> A zero-sized global variable, e.g. "struct { } unused;", gets translated
> into a ".comm _unused,1" by gcc-4, but gcc-3
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-08 15:52 ---
People have bootstraped and tested on AIX 5.3 without any troubles before and
after this patch has been filed?
What command are you using to bootstrap GCC?
--
pinskia at gcc dot gnu dot org changed:
W
--- Comment #2 from mikpe at csd dot uu dot se 2006-03-08 15:51 ---
I downloaded and installed cctools-590.12, and that did indeed solve the
gcc-4.1.0 bootstrap problem.
However, today I discovered that the newer cctools break gcc-3.4.x.
A zero-sized global variable, e.g. "struct { } un
--- Comment #8 from charlet at gcc dot gnu dot org 2006-03-08 15:27 ---
Given that 4.1.0 has been released and issue is fixed there, closing this
PR.
Arno
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from bangerth at dealii dot org 2006-03-08 15:26 ---
(In reply to comment #4)
> I did come on a bit strong, didn't I? Sorry about that, I'm just a bit
> frustrated since it used to work better in the gcc 3 series :-)
Oh, don't worry. I put a smiley to my remark, just in
--- Comment #4 from emilp at mac dot com 2006-03-08 15:23 ---
I did come on a bit strong, didn't I? Sorry about that, I'm just a bit
frustrated since it used to work better in the gcc 3 series :-)
Do you have a suggestion as to where I could continue this discussion?
--
http://gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.0.3
http://gcc
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-08 15:17 ---
Is there a testcase other than just compile and run nbench with
-ftree-loop-linear?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from charlet at gcc dot gnu dot org 2006-03-08 15:16 ---
Nothing particularly critical in this PR, we've got plenty of other more
worrisome failures to look at.
Arno
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25440
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
Last reconfirmed|2005-11-15 20:22:08 |2006-03-08 15:16:1
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-08 15:13 ---
Any news on the testcase?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
1 - 100 of 135 matches
Mail list logo
