--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
06:00 ---
Most likely libiberty (the pex* functions) is being miscompiled.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
06:03 ---
I almost want to say this was caused by:
2005-04-05 Andrew MacLeod [EMAIL PROTECTED]
* lambda-code.c (lambda_loopnest_to_gcc_loopnest): Use update_stmt.
Use immediate use iterator.
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19014
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19106
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Last reconfirmed|2005-01-09
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
06:30 ---
Confirmed, looks like someone is forgetting to call fold somewhere:
int4 C.465 = 1 - 1;
int4 C.464 = 2;
--
What|Removed |Added
The option -ggdb3 has stopped working recently. The following example does not
compile any more
[/Users/fca] cat junk.c
#include stdio.h
main () {
float a=0;
printf(%f\n,a);
}
[/Users/fca] /opt/gcc-4_0/bin/gcc -ggdb3 junk.c -o junk.o
junk.c:5: internal compiler error: Bus error
--
What|Removed |Added
Component|c |debug
Keywords||ice-on-valid-code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
06:34 ---
Confirmed, this just started to happen in the last three days too.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
06:38 ---
This was caused by:
2005-04-09 Caroline Tice [EMAIL PROTECTED]
* dwarf2out.c (COLD_TEXT_SECTION_LABEL): New macro.
..
(output_line_info): Get cold section
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
06:40 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From jason at redhat dot com 2005-04-11 07:49
---
Subject: Re: [4.1 Regression] removing a temporary return
value when we cannot
Have you tested the 4.0 branch with the temporary fix I applied?
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
--- Additional Comments From federico dot carminati at cern dot ch
2005-04-11 07:49 ---
This fix has not yet been merged to the head. Any news?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20799
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-11
07:51 ---
Patch from: http://gcc.gnu.org/ml/fortran/2005-04/msg00283.html applied to
mainline. Waiting for 4.0 to reopen.
--
What|Removed |Added
--
What|Removed |Added
Summary|BLK ptr's loosing original |BLK ptr's losing original
|ptr's static-constant |ptr's static-constant
(8,'(/2i2)')n,m
write(*,*)n,m
end
$ gfortran -v
Using built-in specs.
Target: i386-linux
Configured with: ../gcc/configure --prefix=/tmp/gfortran-20050411/irun
--enable-languages=c,f95 --host=i386-linux
Thread model: posix
gcc version 4.1.0 20050411 (experimental)
$ gfortran pr17992.f
This case came to light making service provider property files for
GNU JAXP: org.xml.sax.driver etc. These should be created in the
META-INF/services path of the JAR. Reproduce this error by creating a
META-INF/services directory at the root of your compiled class hierarchy and
adding one or
--- Additional Comments From phil at mkdoc dot com 2005-04-11 08:11 ---
Created an attachment (id=8583)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8583action=view)
SAX driver service provider file
Driver class: gnu.xml.aelfred2.SAXDriver
--
Have not seen this reported yet...
Bootstrap of mainline 4.1 compiler failed at ia32/IPF/x86_64 Linux due to jc1
segmentation fault in 'in_unlikely_text_section'.
/bootstrap/bld/./gcc/gcj -B/bootstrap/bld/./gcc/ -B/bootstrap/usr/i586-suse-
linux/bin/ -B/bootstrap/usr/i586-suse-linux/lib/
--- Additional Comments From phil at mkdoc dot com 2005-04-11 08:56 ---
Created an attachment (id=8584)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8584action=view)
Test case for org.xml.sax.driver service provider property
First checks any service provider configuration using
--- Additional Comments From pluto at pld-linux dot org 2005-04-11 08:59
---
(In reply to comment #26)
Subject: Re: [4.1 Regression] removing a temporary return
value when we cannot
Have you tested the 4.0 branch with the temporary fix I applied?
Jason
I applied a temporary
--- Additional Comments From phil at mkdoc dot com 2005-04-11 09:13 ---
Created an attachment (id=8585)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8585action=view)
GNU JAXP pure Java source, no natives
GNU JAXP source classes, compile using the attached script.
--
--- Additional Comments From phil at mkdoc dot com 2005-04-11 09:18 ---
Created an attachment (id=8586)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8586action=view)
GCJ compile script for GNU JAXP
Compiles GNU JAXP source to classes. Requires environment variables $mk_home, a
--- Additional Comments From phil at mkdoc dot com 2005-04-11 09:21 ---
Created an attachment (id=8587)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8587action=view)
Fastjar archive script for GNU JAXP
Creates a JAR of the compiled GNU JAXP classes. Requires environment variables
--- Additional Comments From phil at mkdoc dot com 2005-04-11 09:23 ---
Created an attachment (id=8588)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8588action=view)
Check you have the necessary environment variables
Checks the $mk_home and $mk_build environment variables are set.
The following command line produces a warning even if it behaves correctly
[/Users/fca] cat bug.F
subroutine bug_bug
end
[/Users/fca] /opt/gcc-4_0/bin/gfortran -c bug.F ; nm bug.o
T _bug_bug__
[/Users/fca] /opt/gcc-4_0/bin/gfortran -fno-second-underscore -c bug.F ; nm
--- Additional Comments From phil at mkdoc dot com 2005-04-11 09:47 ---
Lots of attachments, but it's simple really:
1. Set two environment variables: $mk_home, a path in which the source is at
$mk_home/lib-src/jaxp, and $mk_build, which is a temporary build directory
2. Put all the
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-11
09:47 ---
Zdenek,
the ICE with the testcase from comment #12 reappeared on mainline.
Could you please have a look?
--
What|Removed |Added
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-11
10:32 ---
The new failure (which is a segfault, btw) was caused by
http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01363.html
--
What|Removed |Added
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-04-11 10:41 ---
Subject: Re: internal compiler error: in spill_failure, at reload1.c:1880
(-fspeculative-prefetching)
Hello,
the ICE with the testcase from comment #12 reappeared on mainline.
When I compile ACE 5.4.2 with the actual snapshot of gcc41 (gcc-4.1-20050410)
I get an ICE:
g++41 -O2 -c -o .shobj/Synch_Invocation.o Synch_Invocation.ii
Conflict s_4 and s_78 across an abnormal edge from BB40-BB43
Synch_Invocation.cpp: In member function 'TAO::Invocation_Status
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-11
11:33 ---
This one is certainly going to annoy lots of people (when 4.0 is released, I
think we will get bug-reports by the ton).
This should be easy to solve for someone who knows the interactions between GCC
--- Additional Comments From micis at gmx dot de 2005-04-11 11:37 ---
Created an attachment (id=8589)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8589action=view)
preprocessd source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20944
--- Additional Comments From tobi at gcc dot gnu dot org 2005-04-11 12:05
---
It is annoying enough that the preprocessor is invoked via cc1. Is there a
reason for this, besides that it is the example given in the specfiles?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
On Sun, Apr 10, 2005 at 09:53:00PM -0400, Andrew Pinski wrote:
Could you try the patch in PR 20934 and see if it fixed the
bootstrap problem on i686-linux?
It does. What's the status of that patch? It almost looks
obvious to me.
Diego.
--- Additional Comments From joern dot rennecke at st dot com 2005-04-11
12:36 ---
Subject: Re: TRULY_NOOP_TRUNCATION ignored
echristo at redhat dot com wrote:
--- Additional Comments From echristo at redhat dot com 2005-04-10 19:02
---
I think I'm ok with this, but I'd
--- Additional Comments From rolf dot ebert dot gcc at gmx dot de
2005-04-11 12:37 ---
Created an attachment (id=8590)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8590action=view)
patch to fix PR20822 in 4.0.0-RC1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20822
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
12:44 ---
*** This bug has been marked as a duplicate of 20934 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
12:44 ---
*** Bug 20942 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
12:47 ---
*** This bug has been marked as a duplicate of 18452 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
12:47 ---
*** Bug 20943 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
12:48 ---
(In reply to comment #5)
It is annoying enough that the preprocessor is invoked via cc1. Is there a
reason for this, besides that it is the example given in the specfiles?
Besides that is the only
--- Additional Comments From giovannibajo at libero dot it 2005-04-11
12:48 ---
I have a very naive question: if LABEL_REFS should always be generated with
Pmode, can't we add an assert if gen_rtx_LABEL_REF is called with a different
mode? Or better, remove the mode argument
--- Additional Comments From jason at redhat dot com 2005-04-11 12:48
---
Subject: Re: [4.1 Regression] removing a temporary return
value when we cannot
On 11 Apr 2005 08:59:58 -, pluto at pld-linux dot org [EMAIL PROTECTED]
wrote:
Have you tested the 4.0 branch with the
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
12:50 ---
I want to say this is a dup of bug 20920 which has a patch referenced, could
you try with that patch
applied?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20944
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20777
--
What|Removed |Added
Component|java|libgcj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20941
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-04-11
13:01 ---
*** This bug has been marked as a duplicate of 20920 ***
--
What|Removed |Added
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-04-11
13:01 ---
*** Bug 20944 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pluto at pld-linux dot org 2005-04-11 13:08
---
Problem still exists in 4.0.0-20050409 snap.
I've checked the i386.o and caller-save.o from stage2/3.
They have the same size but diff. instructions in several places.
--- stage2-i386.o.txt 2005-04-11
--- Additional Comments From joern dot rennecke at st dot com 2005-04-11
13:16 ---
Subject: Re: VOIDmode LABEL_REFs are generated
giovannibajo at libero dot it wrote:
--- Additional Comments From giovannibajo at libero dot it 2005-04-11
12:48 ---
I have a very naive
fortran 4.0 shows perfomance regression (with -O2 option) in comparison with
g77 from 3.4.2 on IA32 with attached test. This test is obtained from
cpu2000/mgrid test.
It consists of calling of two functions: PSINV and RESID.
Instrumental control (gprof) shows that most part of time spends in
--enable-checking=yes,fold fails on the mainline because when we get a
SSA_NAME, we checksum the
whole use-def chain which is wrong.
--
Summary: --enable-checking=yes,fold fails on the mainline
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
13:20 ---
I am testing a fix right now, this is blocking my patch for PR 20931.
--
What|Removed |Added
--- Additional Comments From denis dot nagorny at intel dot com 2005-04-11
13:20 ---
Created an attachment (id=8591)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8591action=view)
Test for results reproducing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20945
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-04-11
13:21 ---
The patch has been posted here:
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01157.html
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
13:28 ---
I know that gfortran has some issue with inlining.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20945
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
13:30 ---
And TREE_LIST too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20946
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
14:05 ---
(In reply to comment #2)
And TREE_LIST too.
Actually it related to how TREE_LIST is handle, I change the recusiveness of
fold_checksum_tree for
TREE_LIST is that we no longer use recusion but a loop
When I compile GSL 1.5 with the actual snapshot of gcc41 (gcc-4.1-20050410) I
get an ICE:
gcc41 -O2 -fpeel-loops -ftree-vectorize -c permute.i -o permute.o
permute_source.c: In function 'gsl_permute_complex_inverse':
permute_source.c:87: internal compiler error: in check_loop_closed_ssa_use, at
--- Additional Comments From micis at gmx dot de 2005-04-11 14:30 ---
Created an attachment (id=8592)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8592action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20947
--
What|Removed |Added
Keywords||ice-on-valid-code
Summary|ICE in |[4.1 Regression] ICE in
--- Additional Comments From micis at gmx dot de 2005-04-11 14:33 ---
My gcc is patched with the patch for bug20920
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20947
This is what I get during a gmake bootstrap:
mv 'libgcc/./tmp-libgcc.map' libgcc/./libgcc.map
./xgcc -B./ -B/opt/gcc-4.0/i386-pc-solaris2.10/bin/ -isystem
/opt/gcc-4.0/i386-pc-solaris2.10/include -isystem
/opt/gcc-4.0/i386-pc-solaris2.10/sys-include
-L/var/tmp/gcc-4.0.0-20050410/obj/gcc/../ld -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
14:37 ---
This means you installation of binutils is wrong:
/usr/sfw/bin/gld: cannot open linker script file ldscripts/elf_i386.xsc: No such
file or directory
Can you compile binutils and try again since this is not
**
[1] konqueror (kdebase-3.4.0).
(gdb) bt
#0 ~QIconSet (this=0x8209614) at qshared.h:50
~QIconSet (this=0x8209614) at qshared.h:50
50 bool deref(){ return !--count; }
(gdb) print this
$1 = (QIconSet
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
14:43 ---
I think this was caused by:
2005-04-08 Diego Novillo [EMAIL PROTECTED]
Merge from tree-cleanup-branch: VRP, store CCP, store
copy-prop, incremental SSA updating of FUD chains
--- Additional Comments From pluto at pld-linux dot org 2005-04-11 14:43
---
(In reply to comment #28)
Subject: Re: [4.1 Regression] removing a temporary return
value when we cannot
On 11 Apr 2005 08:59:58 -, pluto at pld-linux dot org
[EMAIL PROTECTED] wrote:
Have you
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
14:44 ---
Well without a test, there is still nothing we can do anyways because they
could be invoking undefined
behavior :).
Also do they fail when compiled with -O0?
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
14:50 ---
Actually if anything is miscompile it would be make_temp_file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20933
--- Additional Comments From brett dot albertson at stratech dot com
2005-04-11 14:57 ---
(In reply to comment #1)
This means you installation of binutils is wrong:
/usr/sfw/bin/gld: cannot open linker script file ldscripts/elf_i386.xsc: No
such
file or directory
Can you compile
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-11
15:06 ---
Subject: Bug 20920
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-11 15:05:50
Modified files:
gcc: ChangeLog tree-pretty-print.c
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-04-11
15:09 ---
Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01050.html
--
What|Removed |Added
On Sun, Apr 10, 2005 at 09:47:25PM -0400, Diego Novillo wrote:
On Sun, Apr 10, 2005 at 05:38:31PM -0400, Andrew Pinski wrote:
This fixes the bootstrap problem for me on powerpc-darwin.
Thanks. I will commit as soon as I get a clean bootstrap.
Got a clean bootstrap and test run using
--- Additional Comments From amacleod at redhat dot com 2005-04-11 15:13
---
Why would you say that? I get the same failure with a build from April 1 before
immuses was checked in.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20926
--- Additional Comments From brett dot albertson at stratech dot com
2005-04-11 15:21 ---
(In reply to comment #2)
I'm restarting the bootstrap now using Sun's linker (/usr/ccs/bin/ld). I'll
reply when it is finished.
It successfully bootstrapped using Sun's ld and Gnu's as, as
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-11
15:26 ---
I believe ivopts is doing funky things with copying vops and whatnot without
taking into account subvars that is screwing us up.
The error existed before 04/01, AFAICT
--
$ cat fc112.f
character*20 c
inquire (33, sequential = c)
print *, c
end
$ ./bin/gfortran -static fc112.f ./a.out
zsh: segmentation fault ./a.out
With gdb:
Program received signal SIGSEGV, Segmentation fault.
inquire_via_unit (u=0x0) at
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From micis at gmx dot de 2005-04-11 15:49 ---
The patch for bug20920 solves this problem.
Michael Cieslinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20944
--- Additional Comments From pluto at pld-linux dot org 2005-04-11 15:58
---
(In reply to comment #1)
Well without a test, there is still nothing we can do anyways because they
could be invoking undefined
behavior :).
Also do they fail when compiled with -O0?
arts crashes
--
What|Removed |Added
CC||mmazur at kernel dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20949
The program below fails to compile with gcc on EM64T. I believe the program is
well-formed based on 7.15.1.1 of C99, Footnote 212 (I am aware that footnotes
are not normative).
The second program below uses va_copy to get around the compilation error in the
first case fails to compile with the
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-11
16:55 ---
Mine
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dberlin at gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
17:07 ---
Nope this is invalid, see PR 14557 for more discussion about this issue.
va is equivalent to va[0] on x86_64 since va_list is defined as an array on
x86_64.
*** This bug has been marked as a duplicate of
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
17:07 ---
*** Bug 20951 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
17:12 ---
http://gcc.gnu.org/ml/gcc/2005-04/msg00514.html
--
What|Removed |Added
CC|
--- Additional Comments From bkoz at redhat dot com 2005-04-11 17:14
---
Subject: Re: builtins for atomic operations needed
I'm working on atomic builtins, but this will *not* resolve the problem of
compiling for i386 and i486+. Indeed, it could easily make it worse because
you
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
17:16 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01193.html.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
17:16 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01193.html.
--
What|Removed |Added
--- Additional Comments From Tobias dot Schlueter at physik dot
uni-muenchen dot de 2005-04-11 17:16 ---
Subject: Re: -fno-second-underscore induces warning for
fortran that needs preprocessing
pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
17:20 ---
(In reply to comment #8)
We're using the traditional preprocessor. This is a separate executable, cpp,
which is built separately. So the question remains: why do we run cc1?
cpp just calls cc1.
There
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
17:24 ---
Created an attachment (id=8594)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8594action=view)
patch which Caroline sent me to attach
I mistakenly assumed that if current_function_decl
was defined,
--- Additional Comments From sebor at roguewave dot com 2005-04-11 17:33
---
(In reply to comment #1)
Right. I understand why it doesn't compile and how to work around it (with gcc
at least). What I'm still not convinced of is that it's not a strict conformance
bug. The same point was
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
17:35 ---
(In reply to comment #2)
Do you happen to know whether there's a C99 issue to fix the footnote?
If you read that bug's comment, you will see in comment #8:
My recollection from last time we were
--- Additional Comments From Tobias dot Schlueter at physik dot
uni-muenchen dot de 2005-04-11 17:39 ---
Subject: Re: -fno-second-underscore induces warning for
fortran that needs preprocessing
pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-04-11
17:41 ---
Testing fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20933
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-04-11
17:49 ---
The error existed before 04/01, AFAICT
I don't believe so - I have a gcc build of 20050129 that does not do this; see
my posting on the fortran list.
Further evidence, if it helps, is that the code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11
17:51 ---
(In reply to comment #7)
The error existed before 04/01, AFAICT
I don't believe so - I have a gcc build of 20050129 that does not do this; see
my posting on the fortran list.
He means April 1st and
1 - 100 of 184 matches
Mail list logo
