--- Comment #9 from burnus at gcc dot gnu dot org 2009-07-03 06:40 ---
(In reply to comment #8)
Please try with a newer version of gfortran. Literally, hundreds of
bugs and changes have occurred since version 4.3.0 was released.
I believe this bug is a duplicate of
--- Comment #1 from raeburn at raeburn dot org 2009-07-03 06:45 ---
(In reply to comment #0)
, but it does not seem to recognize that the following is also a valid
prototype:
int count * ( demo_counter * self, int count_amt );
It isn't.
Following the traditional right-then-left
In assignments, such as
string = trim(string)
string(n1:n2) = trim(string)
the trim has no effect and can be optimized away.
(Note: With Fortran 2003 and allocatable strings with len=:, the first
version cannot be optimized as on length mismatch the LHS is reallocated.)
Such code can easily
The following code (inspired from host_assoc_function_1.f90) breaks f951:
MODULE m
REAL :: x
CONTAINS
SUBROUTINE s
CONTAINS
SUBROUTINE inner
y = x(1, 1)
END SUBROUTINE
FUNCTION x(n, m)
END FUNCTION
END SUBROUTINE
END MODULE
I have an internal compiler error with
--- Comment #1 from dominiq at lps dot ens dot fr 2009-07-03 08:18 ---
Confirmed on i686-apple-darwin9. More precisely, I get:
pr40629.f90:12.10:
END MODULE
1
Error: Symbol 'x' at (1) has already been host associated
f951: internal compiler error: Bus error
--
--- Comment #17 from ubizjak at gmail dot com 2009-07-03 08:46 ---
(In reply to comment #16)
One of the cases SCEV is confused about pointer-plus offsets being sizetype:
Do we have a solution for this problem...?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
--- Comment #2 from jakub at gcc dot gnu dot org 2009-07-03 09:00 ---
Jason, am I correct that this is now valid rather than invalid?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40341
--- Comment #18 from rguenther at suse dot de 2009-07-03 09:08 ---
Subject: Re: [4.3/4.4/4.5 Regression] 10% performance
regression since Nov 1 on Polyhedron's NF on AMD64
On Fri, 3 Jul 2009, ubizjak at gmail dot com wrote:
--- Comment #17 from ubizjak at gmail dot com
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-03 09:57 ---
int count * ( demo_counter * self, int count_amt );
is not a valid prototype.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-07-03 09:57
---
Fixed I suppose.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from rguenth at gcc dot gnu dot org 2009-07-03 10:00
---
One issue is that
ISET = MINLOC (DTEMP)
will cause GCC to assume that DTEMP is clobbered.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
--- Comment #10 from rogermc at iinet dot net dot au 2009-07-03 10:01
---
I updated gfortran as suggested and now abavrml.F compiles OK.
Bug seems resolved.
Thanks for advice.
gfortran -v now responds with:
Using built-in specs.
Target: i386-apple-darwin8.10.1
Configured with:
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-03 10:13 ---
Confirmed. One first gets the error message from gfc_get_sym_tree (already been
host associated), followed by the segfault, which happens at
==12785== Use of uninitialised value of size 8
==12785==at 0x500F17:
/n/51/guerby/build/./prev-gcc/xgcc -B/n/51/guerby/build/./prev-gcc/
-B/mnt/lemote/home/loongson/install-trunk-149181/mips64el-unknown-linux-gnu/bin/
-B/mnt/lemote/home/loongson/install-trunk-149181/mips64el\
-unknown-linux-gnu/bin/
--- Comment #8 from dave at treblig dot org 2009-07-03 11:03 ---
Note there are two slightly different things being asked for here:
1) Showing the horizontal position in the line
2) show the preprocessed line rather than the raw line (which was my 40228
that just got marked as a
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-07-03 11:05
---
In fact, in this case we have the C equivalent
int i;
long j = (long)(i - 1);
vs.
long j = (long)i - 1;
which I believe are equivalent if overflow is undefined (or i - 1 does not
wrap).
It is just that
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-07-03 11:14
---
Before:
Time for setup 0.139
Time per iteration 0.271
Total Time 6.649
Time for setup 0.136
Time per iteration 0.265
Total Time 10.210
Time for setup
--- Comment #21 from rguenth at gcc dot gnu dot org 2009-07-03 11:22
---
Created an attachment (id=18133)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18133action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
On one hand it needs a new attribute, which needs some checking that the
contiguity is not violated. It also needs the contiguous flag of the reworked
descriptor.
One place where it can be used is:
a) In functions calls
b) In assignments of the type (cf. PR 40551)
array = function()
c) In
--- Comment #12 from burnus at gcc dot gnu dot org 2009-07-03 11:33 ---
Michael Matz fixed that for allocatable arrays, but the patch needs to be
extended to nonallocatable arrays, cf.
http://gcc.gnu.org/ml/fortran/2009-07/msg4.html
Actually, there it already works. Left is only
The following code produces an internal compiler error:
template typename T
struct wrap {
enum class E { val };
};
Note that there is no problem supplying a fixed-base for a 'classic' enum, this
is purely an issue with the enum class keyword combination.
Tested under MinGW 4.4.0
--
On Debian (and probably other), if I execute:
tar xf ../update/gcc-4.4.0.tar.bz2
cd gcc-4.4.0/
tar xf ../../update/mpfr-2.4.1.tar.bz2
tar xf ../../update/gmp-4.3.1.tar.bz2
tar xf ../../update/binutils-2.19.1.tar.bz2
mv gmp-4.3.1 gmp
mv mpfr-2.4.1 mpfr
mv binutils-2.19.1 binutils
mkdir -v
The following test case produces a 'may be used uninitialized' warning that
refers to a variable that isn't in scope at the point of the warning:
cat nntpinit.c
struct hostent {
char **h_addr_list;
};
struct hostent *gethostbyname(const char*);
int socket(void);
int close(int);
int
--- Comment #23 from rguenth at gcc dot gnu dot org 2009-07-03 12:19
---
We are not able to vectorize the loop in
program main
implicit none
integer, volatile, dimension(1) :: n
real, allocatable :: a(:)
integer :: i
real :: t1, t2
allocate (a(100))
call
GCC 4.5.0 20090702
Build failed because the static const structures in config/i386/msformat-c.c
(mingw_format_attribute_overrides and mingw_format_attributes) were optimized
out.
Also solaris target can be affected (solaris_format_types).
--
Summary: Build failed with
--- Comment #7 from vmakarov at redhat dot com 2009-07-03 12:38 ---
Thanks for reporting this. I started to work on the PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40587
--- Comment #24 from burnus at gcc dot gnu dot org 2009-07-03 12:40 ---
One issue is that
ISET = MINLOC (DTEMP)
will cause GCC to assume that DTEMP is clobbered.
The problem is that while MINLOC is pure, we cannot use DECL_PURE_P as the
result is passed by reference:
(void)
--- Comment #25 from rguenth at gcc dot gnu dot org 2009-07-03 12:57
---
Btw, the inlined minloc
D.1570 = a.dim[0].lbound;
D.1571 = a.dim[0].ubound;
pos.0 = 0;
{
integer(kind=8) S.3;
({ S.3 =
--- Comment #26 from burnus at gcc dot gnu dot org 2009-07-03 13:07 ---
has a superfluous check || (pos.0 == 0 (*D.1568)[S.3 + D.1569] == limit.2)
at least for flag_finite_math_only. If the array cannot contain Inf or NaN
then it either has all elements == FLT_MAX, so pos will stay
On trunk revision 149204:
/home/guerby/build/./prev-gcc/xgcc -B/home/guerby/build/./prev-gcc/
-B/n/40/guerby/install-trunk/powerpc64-unknown-linux-gnu/bin/
-B/n/40/guerby/install-trunk/powerpc64-unknown-linux-gnu/bin/
-B/n/40/guerby/install-trunk/powerpc64-unknown-linux-gnu/lib/ -isystem
--- Comment #1 from laurent at guerby dot net 2009-07-03 13:26 ---
powerpc 32 bits Ada bootstraps and testresults are fine:
http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg00181.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40637
I find this hard to believe but a g77 code that has been in use for years
crashed at the first OPEN statement when compiled with gfortran 4.3.1. Attached
15 line test program reproduces the effect, stops at line 8 with the error
message:
At line 8 of file testlun.f
Fortran runtime error: Unit
--- Comment #22 from rguenth at gcc dot gnu dot org 2009-07-03 14:11
---
Subject: Bug 34163
Author: rguenth
Date: Fri Jul 3 14:11:14 2009
New Revision: 149207
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149207
Log:
2009-07-03 Richard Guenther rguent...@suse.de
PR
--- Comment #23 from rguenth at gcc dot gnu dot org 2009-07-03 14:11
---
Fixed on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
In C++0x mode, enums are allowed to specify an integral type for the base
representation. If the enum is inside a class template, it may be a
type-dependant expression that should not evaluate and potentially error until
instantiation time.
Example code:
--- Comment #11 from kargl at gcc dot gnu dot org 2009-07-03 14:15 ---
Closing. Bug is fixed in newer versions of gfortran.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jason at gcc dot gnu dot org 2009-07-03 14:18 ---
Yes.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-03 14:19 ---
gfortran 4.3.1. Attached 15 line test program reproduces the effect
Can you attach the program?
I assume you compiled it with gfortran -Wall testfile.f and no further option
such a -malign-double or similar?
Can
--- Comment #2 from dtprice at shaw dot ca 2009-07-03 14:20 ---
Created an attachment (id=18134)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18134action=view)
Contains simple demo program and input file. Input file is not really needed
because program never opens it!
--
--- Comment #3 from kargl at gcc dot gnu dot org 2009-07-03 14:40 ---
Upgrade your compiler. The bug appears to fixed in at least trunk
while the bug is present in 4.3.3. I can't test 4.4.0 at the moment.
troutmask:sgk[203] gfc4x -o z testlun.f
troutmask:sgk[204] ./z
--- Comment #3 from dj2con at gmail dot com 2009-07-03 14:42 ---
(In reply to comment #1)
(In reply to comment #0)
, but it does not seem to recognize that the following is also a valid
prototype:
int count * ( demo_counter * self, int count_amt );
It isn't.
Following
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-03 14:49
---
Adding Jason in CC for this one too.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from dtprice at shaw dot ca 2009-07-03 14:54 ---
Sorry. In the middle of uploading the attachment I had a power cut! To respond
to your queries: Program and input file are now uploaded.
Yes it was compiled with
gfortran -Wall testfile.f
and no further options. I have
--- Comment #5 from dtprice at shaw dot ca 2009-07-03 15:06 ---
I stated earlier
Identical code runs fine with same gfortran installed on a system
equipped with an earlier Intel chip
Turns out this was wrong. The version on that system is 4.2.0
Interesting that using default
--- Comment #4 from ubizjak at gmail dot com 2009-07-03 15:19 ---
For the interested reader: see [1].
[1]: http://ieng9.ucsd.edu/~cs30x/rt_lt.rule.html
Unfortunately:
--quote--
First, symbols. Read
* as pointer to - always on the left side
[]
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-07-03 15:20
---
I will add that I suspect that the bug may be latent in 4.5 since I did change
the error code when I added NEWUNIT to 4.5. After we get to the bottom of it,
we need to consider backporting a fix to 4.4 since
gcc (GCC) 4.5.0 20090702 (experimental) [trunk revision 149195]
building gdb head as of today. preprocessed file and coming in next update
gcc -c -g -O2 -DDEFAULT_INLINE=PSIM_INLINE_LOCALS
-DWITH_HOST_BYTE_ORDER=LITTLE_ENDIAN -DWITH_SMP=5-DWITH_TRACE=1
-DHAVE_TERMIOS_STRUCTURE
--- Comment #1 from joel at gcc dot gnu dot org 2009-07-03 15:24 ---
Created an attachment (id=18135)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18135action=view)
preprocessed test case (hw_opic.c
preprocessed version of gdb/sim/ppc/hw_opic.c
FAILS: gcc -O2 -c t.c
PASSES: gcc
--- Comment #5 from dj2con at gmail dot com 2009-07-03 15:29 ---
I was still curious, so I re-read section 6.7.5.3 of the standard. And having
re-read it, I would like to apologize for troubling everyone -- upon re-reading
6.7.5.3, it now seems obvious that I was mis-applying the
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-07-03 15:16
---
I can reproduce the problem on 4.3 and 4.4.
I would like to investigate further, especially regarding 4.4 and what did we
change between 4.4 and 4.5 to fix this.
--
jvdelisle at gcc dot gnu dot org changed:
This is a bug report from an OpenWrt user that I have also noticed myself.
uClibc requires its syscalls to be inlined and therefore the attribute
always_inline was added to ensure inlining.
When gcc is called with -Os the always_inline attribute is not honored,
resulting in a non working uClibc
--- Comment #1 from florian at openwrt dot org 2009-07-03 16:16 ---
Created an attachment (id=18136)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18136action=view)
ldso.Os.i preprocessed file
This file is the preprocessed file which causes problems.
--
=/home/bangerth/bin/x86/gcc-mainline
Thread model: posix
gcc version 4.5.0 20090703 (experimental) [trunk revision 149208] (GCC)
--
Summary: [4.5 regression] ICE with -fprofile-generate
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-03 17:24 ---
Does -fno-ipa-cp fix it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40641
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-03 17:32 ---
Btw, with a cross I cannot seem to reproduce the problem. How do non-inlined
calls look like with mips?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40641
--- Comment #8 from kargl at gcc dot gnu dot org 2009-07-03 17:44 ---
(In reply to comment #7)
I will add that I suspect that the bug may be latent in 4.5 since I did change
the error code when I added NEWUNIT to 4.5. After we get to the bottom of it,
we need to consider backporting
Per IEEE 754:2008, one has max(x,NaN) == max(NaN,x) == x. Gfortran's inline
version of maxloc, maxval and max (ditto for min*) follows this. However, the
libgfortran version does not:
real :: r(4), z
z = 0.0
r = (/ z/z, -1., -42., 849. /)
print *,r
print *, minloc(r), minval(r)
print *,
Try compiling the attached program with the following options (they differ only
in -march specification)
1. gcc -std=c99 -march=i486 -funroll-loops -fprefetch-loop-arrays
-ftree-vectorize -O3 -o gen_weyl_group gen_weyl_group.c
2. gcc -std=c99 -march=i686 -funroll-loops -fprefetch-loop-arrays
--- Comment #1 from aanisimov at inbox dot ru 2009-07-03 18:28 ---
Created an attachment (id=18137)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18137action=view)
Sample program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40644
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-03 18:55 ---
Try -march=pentium-m -mtune=generic. Pentium-M never received any special
tuning (it is the same as for pentium-pro). So is -march=i686 btw, but
i686 does not have SSE, so it is likely vectorization and/or
--- Comment #3 from aanisimov at inbox dot ru 2009-07-03 19:12 ---
Try disabling prefetching.
Indeed, removing -fprefetch-loop-arrays made the program run in 37.534 seconds,
exactly like one compiled for i686.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40644
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-03 19:26 ---
Reducing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|c
--- Comment #1 from jakub at gcc dot gnu dot org 2009-07-03 19:30 ---
Even the inline version is wrong I think.
real :: r(4), z
z = 0.0
r = (/ z/z, z/z, z/z, z/z /)
print *,r
print *, minloc(r,dim=1), minval(r,dim=1)
print *, maxloc(r,dim=1), maxval(r,dim=1)
end
Not sure what
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-03 19:42 ---
Confirmed.
enum { gcr0_8259_bit = 0x2000, gcr0_reset_bit = 0x8000 };
void decode_opic_address(int *);
void hw_opic_io_read_buffer(int index)
{
unsigned reg = 0;
decode_opic_address(index);
switch
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-07-03 19:49 ---
switch-conversion triggers this, but it looks like a VRP issue after all.
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-03 20:04 ---
(gdb) call debug_tree (limit)
integer_cst 0xb7d5ac40 type integer_type 0xb7d2aee0 constant 0
(gdb) call vrp_val_is_max (limit)
$6 = 1 '\001'
(gdb) call vrp_val_is_min (limit)
$7 = 1 '\001'
err ...
(gdb) call
--- Comment #6 from raeburn at raeburn dot org 2009-07-03 20:06 ---
Subject: Re: not following right-then-left rule when compiling function
pointers
On Jul 3, 2009, at 10:42, dj2con at gmail dot com wrote:
I don't know where you've been hiding for these past twenty years,
Ken.
--- Comment #8 from vmakarov at redhat dot com 2009-07-03 21:30 ---
The problem was in usage of df_get_live_out in ira.c::build_insn_chain instead
of DF_LR_OUT. Later contains r58 (assigned to st0 register) and it creates
restore insn for st0 after the call and prevents reg-stack
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-07-03 22:09 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-07-03 22:09 ---
Subject: Bug 40640
Author: rguenth
Date: Fri Jul 3 22:09:12 2009
New Revision: 149211
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149211
Log:
2009-07-03 Richard Guenther rguent...@suse.de
PR
--- Comment #9 from vmakarov at gcc dot gnu dot org 2009-07-03 22:36
---
Subject: Bug 40587
Author: vmakarov
Date: Fri Jul 3 22:36:31 2009
New Revision: 149212
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149212
Log:
2009-07-03 Vladimir Makarov vmaka...@redhat.com
--- Comment #10 from vmakarov at gcc dot gnu dot org 2009-07-03 22:46
---
Subject: Bug 40587
Author: vmakarov
Date: Fri Jul 3 22:46:30 2009
New Revision: 149213
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149213
Log:
2009-07-03 Vladimir Makarov vmaka...@redhat.com
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2009-07-03 23:24
---
Yes, I have the patch already. Its a one liner.
Index: trans-io.c
===
--- trans-io.c (revision 149123)
+++ trans-io.c (working copy)
@@ -471,7
$ gcc -v
Using built-in specs.
Target: sparc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib
This code is undefined because of alignment requirments differences
for the structs and the union.
Sent from my iPhone
On Jul 3, 2009, at 6:33 PM, dentongosnell at yahoo dot com gcc-bugzi...@gcc.gnu.org
wrote:
$ gcc -v
Using built-in specs.
Target: sparc-linux-gnu
Configured with:
--- Comment #1 from pinskia at gmail dot com 2009-07-04 01:38 ---
Subject: Re: New: Bus error caused by ldd/std instructions in struct copy.
This code is undefined because of alignment requirments differences
for the structs and the union.
Sent from my iPhone
On Jul 3, 2009, at
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2009-07-04 03:07
---
Subject: Bug 40638
Author: jvdelisle
Date: Sat Jul 4 03:07:12 2009
New Revision: 149218
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149218
Log:
2009-07-03 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2009-07-04 04:05
---
Subject: Bug 40638
Author: jvdelisle
Date: Sat Jul 4 04:05:19 2009
New Revision: 149219
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149219
Log:
2009-07-03 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2009-07-04 04:17
---
Subject: Bug 40638
Author: jvdelisle
Date: Sat Jul 4 04:16:59 2009
New Revision: 149220
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149220
Log:
2009-07-03 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-07-04 04:20
---
Subject: Bug 40638
Author: jvdelisle
Date: Sat Jul 4 04:20:24 2009
New Revision: 149221
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149221
Log:
2009-07-03 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2009-07-04 04:25
---
Subject: Bug 40638
Author: jvdelisle
Date: Sat Jul 4 04:25:20 2009
New Revision: 149222
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149222
Log:
2009-07-03 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2009-07-04 04:28
---
Fixed on 4.3 and 4.4. Added new test case to 4.5 as well as 4.3 and 4.4
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jason at gcc dot gnu dot org 2009-07-04 04:34 ---
Subject: Bug 40619
Author: jason
Date: Sat Jul 4 04:34:03 2009
New Revision: 149223
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149223
Log:
PR c++/40619
* cp-tree.h (struct lang_decl_parm):
84 matches
Mail list logo
