Given this input as an example:
cat enderr.f90
program test
character(len=10) :: str
str = '123'
read( str, *, end=10 ) i,x
10 continue
print*,i, x
end program test
gfortran -fdump-tree-original gives the following with two garbage characters
right after the __st_parameter_dtquire as
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2005-12-28 07:21
---
Subject: Bug 25550
Author: jvdelisle
Date: Wed Dec 28 07:21:20 2005
New Revision: 109102
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109102
Log:
2005-12-28 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2005-12-28 07:20
---
Subject: Bug 25550
Author: jvdelisle
Date: Wed Dec 28 07:20:19 2005
New Revision: 109101
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109101
Log:
2005-12-28 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2005-12-28 07:00
---
Subject: Bug 25419
Author: jvdelisle
Date: Wed Dec 28 07:00:47 2005
New Revision: 109100
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109100
Log:
2005-12-28 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2005-12-28 06:59
---
Subject: Bug 25419
Author: jvdelisle
Date: Wed Dec 28 06:59:35 2005
New Revision: 109099
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109099
Log:
2005-12-28 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-28 06:27 ---
Do we need this any more after svn as svn automatically does patch sets and
doing a diff for a patch set ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1634
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-28 06:18 ---
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
Status|REOPENED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7580
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8108
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-28 06:04 ---
The STATEMENT_LIST printing out instead of what it really should be is because
GCC uses print_generic_expr instead of print_generic_stmt.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23872
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net
|dot org
--- Comment #3 from amodra at bigpond dot net dot au 2005-12-28 04:52
---
Adding
if (no_new_pseudos)
regs_ever_live[TOC_REGISTER] = 1;
to rs6000.c:create_TOC_reference fixes this problem. There seems to be
precedent for such chicanery: eg. rs6000_got_register and a number of plac
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-28
04:18 ---
Subject: Re: FAIL: gfortran.dg/cray_pointers_2.f90 at -O2 and above
> (In reply to comment #6)
> > It I'm reading this correctly, we appear to have the sum of two
> > real4* pointers in the MEM.
>
> You
--- Comment #2 from amodra at bigpond dot net dot au 2005-12-28 03:03
---
Happens at -O0 too. At -O0, r30 is used for the first time when reload decides
that the asm_operands in the following needs reloading. regs_ever_live[30]
isn't set.
(insn 8 6 10 3 (set (mem/c/i:DI (plus:DI (reg
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-28 00:37 ---
(In reply to comment #6)
> It I'm reading this correctly, we appear to have the sum of two
> real4* pointers in the MEM.
You are reading this correctly. PRE is only run at -O2 but I don't think this
is a PRE bug.
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-28
00:25 ---
Subject: Re: FAIL: gfortran.dg/cray_pointers_2.f90 at -O2 and above
> Can you attach the dump from -fdump-tree-vars? I suspect that cray_pointers
> are a bit weird on targets like HPPA since we might not
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-28
00:16 ---
Subject: Re: FAIL: gfortran.dg/cray_pointers_2.f90 at -O2 and above
Here's the dump.
Dave
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-28
00:16 ---
Created an attachment
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-28
00:13 ---
Subject: Re: FAIL: gfortran.dg/cray_pointers_2.f90 at -O2 and above
> Can you attach the dump from -fdump-tree-vars? I suspect that cray_pointers
> are a bit weird on targets like HPPA since we might not
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-28 00:00 ---
This is not a dup of bug 25041.
This has been fixed since at least 4.1.0 20051112.
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 2005-12-27 23:50 ---
There is not enough information to figure out what is going wrong here.
Can you attach the preprocesed source (if you can since this is SPEC) or at
least find the simplified example.
--
pinskia at gcc dot gnu dot
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[3.4] failure in i386-sse- |[3.4 only] failure in i386-
|2.c on x86_64-unknown-
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-27 23:47 ---
Can you attach the dump from -fdump-tree-vars? I suspect that cray_pointers
are a bit weird on targets like HPPA since we might not record if it is a
pointer or not in the integer.
--
http://gcc.gnu.org/bugzill
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-27 23:44 ---
Confirmed, only a 3.4 regression, related to PR 25242.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from danglin at gcc dot gnu dot org 2005-12-27 23:40 ---
These fails don't occur on 4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25586
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-27 23:32 ---
*** This bug has been marked as a duplicate of 25579 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-27 23:32 ---
*** Bug 25582 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25579
Executing on host: /test/gnu/gcc-4.1/objdir/gcc/testsuite/../gfortran
-B/test/gn
u/gcc-4.1/objdir/gcc/testsuite/../
/test/gnu/gcc-4.1/gcc/gcc/testsuite/gfortran.
dg/cray_pointers_2.f90 -O2 -fcray-pointer
-L/test/gnu/gcc-4.1/objdir/hppa64-
hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc-4.1/
I got
apsi_base.o2(3621): unaligned access to 0x6fffb03c,
ip=0x4002b0a0
apsi_base.o2(3621): unaligned access to 0x6fffb03c,
ip=0x4002b361
apsi_base.o2(3621): unaligned access to 0x6fffb03c,
ip=0x4001bbe1
apsi_base.o2(3621): unaligned access to 0x6000
This internal compiler error seems to occur when a mixture of double precision
and integer variables are present in a statement function
$cat abc123.F
subroutine abcd1234
integer x
double precision funcxi
funcxi(x) =
$ (x-1)*2d0
end
$ gfortran -c -v abc123
--- Comment #6 from javadi82 at yahoo dot com 2005-12-27 23:22 ---
I'll post this bug at the bugzilla database for glibc. Meanwhile, am changing
this bug status to WontFix.
Thanks and sorry for the waste of time.
--
javadi82 at yahoo dot com changed:
What|Removed
--- Comment #1 from rstancha at cse dot wustl dot edu 2005-12-27 23:20
---
Created an attachment (id=10558)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10558&action=view)
test case
Minimal test case exhibiting bug on my system.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
I get an internal compiler error when compiling without optimizations on the
following code:
/
#include
int buggy(double val1, double val2){
__m128d t1 = _mm_load_sd( &val1 );
__m128d t2 = _mm_load_sd( &val2 );
__m128d r = _mm_c
I get a corrupt memory stack error with reference to glibc - with one of my
program that uses pointers. This is my first bug report. So kindly excuse(the
lack of clarity).
--
Summary: Corrupt memory stack
Product: gcc
Version: unknown
Status: UNCONF
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-27 23:01 ---
If you supply the source to your program, we might be able to help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25579
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-27 22:59 ---
*** Bug 25581 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25579
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-27 22:59 ---
*** This bug has been marked as a duplicate of 25579 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
I get a corrupt memory stack error with reference to glibc - with one of my
program that uses pointers. This is my first bug report. So kindly excuse(the
lack of clarity).
--
Summary: Corrupt memory stack
Product: gcc
Version: unknown
Status: UNCONF
--- Comment #21 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-27
22:35 ---
Subject: Re: [4.1 Regression] (short) ((int)(unsigned short) + (int)) is done
in the wrong type
> However, I'm getting different tree code with the x86 cross.
I can't reproduce this problem. Maybe I for
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-27 22:28 ---
Oh, one more thing, glibc is not part of the GCC project.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25579
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-27 22:27 ---
*** This bug has been marked as a duplicate of 25579 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-27 22:27 ---
*** Bug 25580 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25579
I get a corrupt memory stack error with reference to glibc - with one of my
program that uses pointers. This is my first bug report. So kindly excuse(the
lack of clarity).
--
Summary: Corrupt memory stack
Product: gcc
Version: unknown
Status: UNCONF
--- Comment #10 from eedelman at gcc dot gnu dot org 2005-12-27 22:09
---
(In reply to comment #9)
> Fixed on 4.1. Not yet fixed on 4.0, because it depends on PR 15326 which
> hasn't been fixed for 4.0.
PR 15326 will not be fixed for 4.0, I presume, so neither will this. Thus I
consid
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-27 21:58 ---
This was fixed by the patch which fixed PR 19239 so closing as fixed for 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-27 21:54 ---
And why do you think this is a bug in GCC and not your code?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from eedelman at gcc dot gnu dot org 2005-12-27 21:53
---
(In reply to comment #5)
> Never mind. I managed to reduce it to something that doesn't depend on any
> modules.
The reduced testcase is here:
SUBROUTINE MATIERE()
REAL :: XSNAK(2)
XSNAK((/ 1, 2 /)) = 0
I get a corrupt memory stack error with reference to glibc - with one of my
program that uses pointers. This is my first bug report. So kindly excuse(the
lack of clarity).
--
Summary: Corrupt memory stack
Product: gcc
Version: unknown
Status: UNCONF
--- Comment #3 from dir at lanl dot gov 2005-12-27 21:46 ---
This was after a complete new download and rebuild.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25578
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconf
--- Comment #5 from eedelman at gcc dot gnu dot org 2005-12-27 21:31
---
(In reply to comment #4)
>
> It seems to me that the .mod-file is corrupted. Could you send the source
> code
> of the module too, instead of just the .mod file?
>
Never mind. I managed to reduce it to someth
-*-*
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2005-12-27 21:13:33
date||
Summary|gfortran version 4.2.0 |[4.2 Regression] gfortran
|20051227 - 144 new testsuite
--- Comment #1 from sgk at troutmask dot apl dot washington dot edu
2005-12-27 20:58 ---
If you've only updated the source in gcc/fortran and libgfortran, then you
need to do
cd gcc/testsuite
svn update
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25578
--- Comment #4 from ghazi at gcc dot gnu dot org 2005-12-27 20:08 ---
Subject: Bug 25444
Author: ghazi
Date: Tue Dec 27 20:08:39 2005
New Revision: 109084
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109084
Log:
* g++.dg/rtti/tinfo1.C: Scan for ".global" also.
--- Comment #3 from ghazi at gcc dot gnu dot org 2005-12-27 20:08 ---
Subject: Bug 25442
Author: ghazi
Date: Tue Dec 27 20:08:39 2005
New Revision: 109084
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109084
Log:
* g++.dg/rtti/tinfo1.C: Scan for ".global" also.
--- Comment #4 from ghazi at gcc dot gnu dot org 2005-12-27 20:08 ---
Subject: Bug 25441
Author: ghazi
Date: Tue Dec 27 20:08:39 2005
New Revision: 109084
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109084
Log:
* g++.dg/rtti/tinfo1.C: Scan for ".global" also.
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-12-27 19:58 ---
Subject: Bug 25442
Author: ghazi
Date: Tue Dec 27 19:58:28 2005
New Revision: 109083
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109083
Log:
* g++.dg/rtti/tinfo1.C: Scan for ".global" also.
--- Comment #3 from ghazi at gcc dot gnu dot org 2005-12-27 19:58 ---
Subject: Bug 25444
Author: ghazi
Date: Tue Dec 27 19:58:28 2005
New Revision: 109083
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109083
Log:
* g++.dg/rtti/tinfo1.C: Scan for ".global" also.
--- Comment #3 from ghazi at gcc dot gnu dot org 2005-12-27 19:58 ---
Subject: Bug 25441
Author: ghazi
Date: Tue Dec 27 19:58:28 2005
New Revision: 109083
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109083
Log:
* g++.dg/rtti/tinfo1.C: Scan for ".global" also.
--- Comment #4 from eedelman at gcc dot gnu dot org 2005-12-27 19:41
---
(In reply to comment #2)
> Created an attachment (id=10467)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10467&action=view) [edit]
> m_mb_control.mod
>
> Fortran module needed by matiere.f
When I try to co
The 20051227 version of gfortran has 144 new testsuite failures as compared to
the 2005121 version -
Test Run By dir on Tue Dec 27 11:07:49 2005
Native configuration is powerpc-apple-darwin8.3.0
=== gfortran tests ===
Schedule of variations:
unix
Running target unix
Using
--- Comment #20 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-27
19:27 ---
Subject: Re: [4.1 Regression] (short) ((int)(unsigned short) + (int)) is done
in the wrong type
> > I am having tough time building the compiler for hppa2.0w-hp-hpux11.11.
> > These days gcc won't even al
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-12-27 19:26
---
Confirmed.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-12-27 17:42 ---
*** Bug 25134 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23101
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-27 17:42 ---
(In reply to comment #3)
> /home/fmr/MYLIB # libtool --mode compile g++ -maix64 $CXXFLAGS -I./ -c
> libshl.c
That is a libtool bug and not a GCC bug. Anyways this is still a dup of bug
23101 since it is the same f
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-12-27 17:19
---
Fixed in 4.1.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #12 from mmitchel at gcc dot gnu dot org 2005-12-27 17:19
---
Fixed in 4.1.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #19 from mmitchel at gcc dot gnu dot org 2005-12-27 17:18
---
Fixed in 4.1.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-12-27 17:18
---
Subject: Bug 25417
Author: mmitchel
Date: Tue Dec 27 17:18:05 2005
New Revision: 109081
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109081
Log:
PR c++/23171, c++/23172, c++/25417.
* c-de
--- Comment #11 from mmitchel at gcc dot gnu dot org 2005-12-27 17:18
---
Subject: Bug 23172
Author: mmitchel
Date: Tue Dec 27 17:18:05 2005
New Revision: 109081
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109081
Log:
PR c++/23171, c++/23172, c++/25417.
* c-d
--- Comment #18 from mmitchel at gcc dot gnu dot org 2005-12-27 17:18
---
Subject: Bug 23171
Author: mmitchel
Date: Tue Dec 27 17:18:05 2005
New Revision: 109081
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109081
Log:
PR c++/23171, c++/23172, c++/25417.
* c-d
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-27
17:06 ---
Subject: Re: [4.1 Regression] (short) ((int)(unsigned short) + (int)) is done
in the wrong type
> I am having tough time building the compiler for hppa2.0w-hp-hpux11.11.
> These days gcc won't even allow
--- Comment #18 from kazu at gcc dot gnu dot org 2005-12-27 16:59 ---
Dave,
I am having tough time building the compiler for hppa2.0w-hp-hpux11.11.
These days gcc won't even allow you to build cc1 without an assembler and such.
How do you build your compiler? Using the native assembler
gfortran routine mvbits returns wrong answer (Absoft shows the correct answer)
-
[dranta:~/tests/gfortran-D] dir% gfortran -o sage02 sage02.f90
[dranta:~/tests/gfortran-D] dir% sage02
0
1F 0
[dranta:~/tests/gfortran-D] dir%
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-12-27 15:37 ---
The particular checking type exposing the failure is "gc" checking. That
forces the garbage collection parameters to be:
--param ggc-min-expand=30 --param ggc-min-heapsize=4096
Using those parameters to compile the t
--- Comment #1 from ghazi at gcc dot gnu dot org 2005-12-27 15:22 ---
Running f951 under gdb, I get:
(gdb) run
/tmp/kg/40/egcc-4.0-SVN20051226/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_eoshift.f90
-quiet -dumpbase intrinsic_eoshift.f90 -mtune=k8 -auxbase intrinsic_eoshif
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-27
15:00 ---
Subject: Re: [4.1 Regression] (short) ((int)(unsigned short) + (int)) is done
in the wrong type
> Re. comments #14 and #15 -- Dave you really should also say what compiler you
> used, or people will just
I'm getting a gfortran failure which only appears with checking turned on the
gcc-4.0.x branch:
http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00417.html
It does not happen in 4.1/mainline. It does not happen if I target i686.
To repeat configure with --target=x86_64-unknown-linux-gnu
--enable
--- Comment #6 from aldot at gcc dot gnu dot org 2005-12-27 14:54 ---
The patch does fix it, the behaviour of line-length-none is documented and
expected.
trunk with the patch gives:
$ gfortran-4.2-HEAD -o pr25486 gfortran.pr25486.f
$ ./pr25486
1234567
--- Comment #1 from laurent at guerby dot net 2005-12-27 14:43 ---
Confirmed the bug on 4.0.2 on x86-linux. This is fixed on 4.1 and trunk.
--
laurent at guerby dot net changed:
What|Removed |Added
--
--- Comment #5 from aldot at gcc dot gnu dot org 2005-12-27 13:15 ---
I'm bootstrapping and will test the patch below (gcc.gfortran.pr25486.0.diff).
I'm uncertain on the expected results of the testcase above for
-ffixed-line-length-none, so i'm not changing the behaviour for this case (
--- Comment #5 from toon at moene dot indiv dot nluug dot nl 2005-12-27
12:24 ---
This is not a g77 error. The following C routine's compilation
fails in the same way - deep down in the middle world:
main()
{
__complex c[1] = { 0.0 };
}
--
toon at moene dot indiv dot nluug dot
--- Comment #1 from steven at gcc dot gnu dot org 2005-12-27 12:22 ---
That happens because data flow information is used to find uninitialized
variables. Some folks argue that this by itself is a bug, and that it should
be entirely up to the front end to diagnose uninitialized variable
Hello,
see example:
>
$ cat warning.c
int main()
{
int i;
return i;
}
$ gcc -Wall warning.c
$ gcc -Wall -O0 warning.c
$ gcc -Wall -O warning.c
warning.c: In function âmainâ:
warning.c:4: warning: âiâ is used uninitialized in this function
warning.c
$ gcc -Wall -O1 warning.c
warnin
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2005-12-27
12:11 ---
Fixed in 3.4.6.
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
--- Comment #16 from steven at gcc dot gnu dot org 2005-12-27 11:16 ---
Re. comments #14 and #15 -- Dave you really should also say what compiler you
used, or people will just have to make a guess. They'd probably conclude you
are testing GCC 3.3 in this case ;-)
Anyway, if the initial
--- Comment #9 from steven at gcc dot gnu dot org 2005-12-27 11:11 ---
The patch that Janis identified in comment #5 fixed bug 19497, which is only an
"accepts-invalid". Bug 19497 was not fixed on the GCC 4.0 branch. Perhaps
that patch to fix it for GCC 4.1 should just be reverted if a
--- Comment #8 from steven at gcc dot gnu dot org 2005-12-27 11:08 ---
Nathan, tomorrow is more than a month ago. Ping!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24824
--- Comment #3 from michele_mazza at hotmail dot com 2005-12-27 11:05
---
We need to build a C++ library on AIX and we would like to use gcc compiler to
keep the library multiplatform (we can run on Linux also).
The C interface of our library is used by SAS (that will soon be 64bit).
Th
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-12-27 09:05
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-12-27 09:05
---
Subject: Bug 25439
Author: mmitchel
Date: Tue Dec 27 09:05:17 2005
New Revision: 109079
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109079
Log:
PR c++/25439
* decl.c (grokdeclarator): Re
90 matches
Mail list logo
