--- Additional Comments From ralf dot corsepius at rtems dot org
2005-04-06 06:18 ---
OK to apply this patch to gcc-4.0, too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17822
--- Additional Comments From sstrasser at systemhaus-gruppe dot de
2005-04-06 06:28 ---
the file which has led to the test case above compiles ok, too
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20734
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
06:36 ---
(In reply to comment #2)
\ /var/tmp//ccDSlyQP.s:774:stfiwx instruction is optional for the PowerPC (not
allowed without
-force_cpusubtype_ALL option)
At this point you need to read:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
06:38 ---
(In reply to comment #7)
They don't even bear-out on other x86 platforms -- my older P3 and AMD
boxes don't show the same kind of big improvement (they show a small
improvements). However, both of my
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
06:46 ---
Hmm on powerpc-darwin on the mainline I get:
_foo:
addic. r11,r5,-32
subfic r2,r5,31
srwi r0,r4,1
srw r0,r0,r2
blt- cr0,L2
slw r9,r4,r11
li r10,0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
06:48 ---
(In reply to comment #7)
The fact that something is in a system header does not in general cause the
compiler not to warn about it. G++ does not issue certain pedantic warnings
when in a system header,
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20750
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-04-06
06:56 ---
Richard,
I think we should probably close this one unless we actually get a chip part
that has this failing :)
...or at least get some documentation about what the hardware
limitation actually is. ;)
--- Additional Comments From tsv at solvo dot ru 2005-04-06 07:11 ---
No, it is UP machine. Yes - it crashes at the same place all the time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20775
I just ran two parallel bootstraps of mainline and 4.0,
on a single-processor Athlon XP 2600+.
Configuration was with --prefix=$HOME --enable-languages=c,f95
in both cases.
The 4.0 build, which finished earlier, used
real58m0.437s
user25m1.021s
sys 1m36.735s
The 4.1 build used
--- Additional Comments From stephane dot mutz at philips dot com
2005-04-06 08:07 ---
I understand your point. However, this sometimes results in a significant drop
of performance forcing to revert to MIPS2 / MIPS32. This partly spoils the
usefulness of MIPS16. I think the option of
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-06
08:11 ---
Subject: Bug 17824
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-06 08:10:54
Modified files:
gcc: ChangeLog
gcc/config/c4x :
--- Additional Comments From ralf dot corsepius at rtems dot org
2005-04-06 08:15 ---
OK to apply this patch to 4.0, too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17824
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-06
08:45 ---
I'm not sure, but I guess this one should go away with Thomas' patches for EOR
handling (see PR 20131, comment 5 for a link).
--
What|Removed |Added
float complex c = 1.if; // warning: imaginary constants are a GCC extension
This warning is generated when -pedantic is specified. This creates problems
with perfectly valid standard C99 code such as the following.
double complex d = I;
No particular placement of __extension__ seems to be
--- Additional Comments From gdr at integrable-solutions dot net
2005-04-06 08:59 ---
Subject: Re: operator-(const T, const complexT) vs operator-(const
complexT, const complexT)
pcarlini at suse dot de [EMAIL PROTECTED] writes:
| Gaby, what do you think about this issue? In fact,
#pragma STDC CX_LIMITED_RANGE off
is currently unimplemented, and generates the warning:
warning: ignoring #pragma STDC CX_LIMITED_RANGE
--
Summary: Pragma STDC CX_LIMITED_RANGE unimplemented
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
--- Additional Comments From pcarlini at suse dot de 2005-04-06 09:17
---
I think we need more careful analysis and tracking of both C99, C++ and
LIA-3.
Ok, thanks, I will start on such analysis (in particulat wrt LIA-3). A minor
issue with complex1.patch is that probably unary
--- Additional Comments From pcarlini at suse dot de 2005-04-06 09:27
---
By the way, about the log, now that you mention it, it's really a pity that we
cannot enable and use the builtin due to the namespace issues with the clog
stream. We should really figure out a way to resolve this
The following code is valid:
$ cat aint_mismatch.f
implicit none
real(4) r
r = aint (r,kind=8)
end
$ gfortran aint_mismatch.f
aint_mismatch.f: In function MAIN__:
aint_mismatch.f:3: internal compiler error: in emit_move_insn, at expr.c:3085
The ICE disappears if kind=4
--
What|Removed |Added
BugsThisDependsOn||20786
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-06
09:55 ---
This got fixed today.
*** This bug has been marked as a duplicate of 15959 ***
--
What|Removed |Added
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-06
09:55 ---
*** Bug 20279 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15959
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20279
Just an internal reminder. A couple of notes:
1- I'm pretty sure cannot be implemented in v6, but would be happy to be wrong.
2- Maybe a similar fix is needed also for tr1/unordered_*.
--
Summary: Implement resolution of DR 130 [Ready] in v7-branch
Product: gcc
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From giovannibajo at libero dot it 2005-04-06
10:51 ---
mainline has checking enabled by default. Try bootstrapping it with --disable-
checking before comparing numbers.
Plus there is a regression we already know of, see:
--
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20787
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-06 11:15
---
*** This bug has been marked as a duplicate of 7263 ***
--
What|Removed |Added
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-06 11:15
---
*** Bug 20784 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-06 11:21
---
We know. I'm not sure how much use there is opening PRs for major points listed
as Missing at http://gcc.gnu.org/c99status.html unless there are particular
subtle points which might be missed in
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-06
11:54 ---
Subject: Bug 17245
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-06 11:53:54
Modified files:
gcc: ChangeLog
gcc/config/sparc:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-06
11:56 ---
Subject: Bug 17245
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-06 11:56:34
Modified files:
gcc:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-06
11:59 ---
Subject: Bug 17245
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-04-06 11:59:10
Modified files:
gcc:
--- Additional Comments From aaronavay62 at aaronwl dot com 2005-04-06
12:13 ---
I opened the PR so I would have a tangible place to point to in a FIXME in some
code, saying when this bug is fixed, uncomment this. Perhaps though, for
things of this sort, it would be better to point to
When using a C main program that has in any way loaded libgfortran.so,
redirected C stdin is broken. This is used by the R project
http://www.r-project.org to run scripts, and even occurs even if
the main (C) program has dlopen-ed a DSO with compiled Fortran code
linked against libgfortran.so.
--- Additional Comments From ripley at stats dot ox dot ac dot uk
2005-04-06 12:27 ---
Created an attachment (id=8547)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8547action=view)
Reproduction details, partial fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20788
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-06
12:34 ---
Subject: Re: 64 bit shift by non-constant implemented as
libcall on PPC32
On Wed, 2005-04-06 at 06:46 +, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-06
12:35 ---
Subject: Re: 64 bit shift by non-constant implemented as
libcall on PPC32
On Wed, 2005-04-06 at 06:46 +, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc
--
Summary: segv
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
--- Additional Comments From igodard at pacbell dot net 2005-04-06 12:37
---
Created an attachment (id=8548)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8548action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20789
--- Additional Comments From igodard at pacbell dot net 2005-04-06 12:37
---
Created an attachment (id=8549)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8549action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20789
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-06
12:38 ---
But then, some scientific libraries are using it (I was about to report the same
bug when a search pointed to this one). And since it works on any compiler I
could find (including g77), I'd change that
libjawt.so needs to be renamed libgcj-jawt.so. Because it is installed in the
standard library prefix and has the same name as Sun's AWT Native Interface
implementation library, proprietary JVMs pick up libgcj's libjawt.so and not
Sun's. We can install a symlink in java-gcj-compat so that
--- Additional Comments From prthomas at drfccad dot cea dot fr 2005-04-06
13:22 ---
Subject: RE: parser confused by arithmetic if inside a
n if
But then, some scientific libraries are using it (I was about
to report the same
bug when a search pointed to this one). And
When compiling a source file with -fvisibility=hidden and/or
-fvisibility-inlines-hidden I get the following error for each function in the
file (happens with C and C++ front-end):
C:/DOKUME~1/OSTOEN~2/LOKALE~1/Temp/ccCC.s: Assembler messages:
C:/DOKUME~1/OSTOEN~2/LOKALE~1/Temp/ccCC.s:5:
--
What|Removed |Added
GCC host triplet||i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20791
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-06
13:52 ---
Paul: Before I changed the severity field, it was enhancement.
All: I was a patch for this one, I will polish the testcase a bit and post it in
a few days.
--
What|Removed
If gcc.pot is regenerated on mainline, the help information for options moved to
.opt files, other than those for the current target, are missing from the
generated gcc.pot file. A special version of options.c with the messages for
all languages and targets may need generating for the use of
--- Additional Comments From selecter at spray dot se 2005-04-06 14:01
---
Fixincludes is running on compilation, but I had to patch pthread manually. It's
gentoo problem - they do not support gcc-4.0.0 yet.
--
What|Removed |Added
--- Additional Comments From liu_gw at 163 dot com 2005-04-06 14:10 ---
(From update of attachment 8546)
gcc v3.4.3:
gcc/parser.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-06 14:18
---
gcc.dg/builtin-apply4.c execution test is failing on mainline on ia64-hpux.
gcc-testresults also shows it failing on 4.0 branch on ia64-linux.
--
What|Removed |Added
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-06
14:21 ---
This goes away when --disable-checking is specified for 4.0
and 4.1.
Closing as invalid.
--
What|Removed |Added
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-04-06
14:28 ---
Thanks for the heads-up. Will try to fix this ASAP.
--
What|Removed |Added
When ALLOCATE_INITIAL_VALUE, allocate_initial_values will replace
a pseudo with a machine-defined value, but it won't update the
register liveness information. This can lead to incorrect global
allocations.
An incomplete conflict list can be observed compiling execute/pr17377.c
at -O2 for
extern void abort (void);
typedef int T __attribute__((aligned));
struct S { T a[2]; } s;
void *p[2];
int
main (void)
{
p[0] = s.a[0];
p[1] = s.a[1];
if (p[0] == p[1])
abort ();
return 0;
}
is miscompiled on at least i386, x86_64, ppc32 and ppc64, at all optimization
levels. Works
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
14:52 ---
I want to say this is a middle-end problem as the trees look ok:
p[0] = s.a[0]{lb: 0 sz: 0};
D.1140 = s.a[1]{lb: 0 sz: 0};
p[1] = D.1140;
D.1141 = p[0];
D.1142 = p[1];
if (D.1141 == D.1142) goto
struct S { union {} a; } __attribute__((aligned));
void check (struct S arg)
{
}
ICEs on x86-64 at any optimization level. Works fine in C.
--
Summary: ICE in assign_parms
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-06
14:57 ---
Patch proposed here: http://gcc.gnu.org/ml/fortran/2005-04/msg00104.html
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
14:57 ---
Even though this is only seen with the C++ front-end, I would almost think this
is a middle-end
problem.
--
What|Removed |Added
With -Wunused, this:
struct A { A(int); };
struct S { S(A); };
void f()
{
int i = 0;
S s(A(i));
}
generates a spurious warning:
test.cpp: In function `void f()':
test.cpp:5: warning: unused variable `int i'
(Happens in Debian's 3.3.5-12, 3.4.3-12, 4.0-0pre9)
--
Summary:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
15:03 ---
Did you build GCC your self? If not, did you get the version of binutils that
the person was offering.
And yes we have a check while configuring to enable/disabling visiblity.
--
--- Additional Comments From jakub at gcc dot gnu dot org 2005-04-06 15:05
---
Doesn't need to be in struct, and the requested alignment must be bigger
than sizeof (int) to reproduce.
extern void abort (void);
typedef int T __attribute__((aligned (8)));
T a[2];
void *p[2];
int
main
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-04-06
15:09 ---
Created an attachment (id=8550)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8550action=view)
proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20793
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
15:11 ---
Confirmed, the problem is most likely we are missing a fold_convert somewhere
converting from
double down to float (sorry for using C types but it makes it easier sometimes).
--
What
--- Additional Comments From aph at gcc dot gnu dot org 2005-04-06 15:13
---
This only happens with -O2. -O is a reasonable workaround for the time being.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
15:18 ---
(In reply to comment #26)
(From update of attachment 8546)
gcc v3.4.3:
gcc/parser.c
I should note this bug is suspended. This is because the standard is unclear
at what is the correct
behavior. See
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
15:19 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
15:24 ---
This was fixed in 4.0.0.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
15:31 ---
The following expression does not do what you think it does:
S s(A(i));
It declares a function which returns S as the type and takes an A which is
named i.
--
What|Removed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-06
15:35 ---
Subject: Bug 19312
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-04-06 15:35:33
Modified files:
gcc/cp :
Looking at GCC 4.0 20050318, and configuring as a cross-compiler for ARM/Linux
thusly:
$ mkdir arm-linux ; cd arm-linux
$ ../configure --prefix=/opt/gcc-linux --target=arm-linux-elf
--enable-languages=c,ada
Once the gnat1 binary is built, just type this from the gcc/ada directory.
$
--
What|Removed |Added
Attachment #8548|application/octet-stream|text/plain
mime type||
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-06
15:52 ---
Subject: Bug 20212
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-06 15:52:24
Modified files:
gcc/cp :
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
15:53 ---
This is related to PR 17323.
--
What|Removed |Added
BugsThisDependsOn|
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-06
15:55 ---
Subject: Bug 20212
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-06 15:55:00
Modified files:
gcc/cp : ChangeLog pt.c
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-06
15:56 ---
Fixed in 4.0.
--
What|Removed |Added
Status|ASSIGNED
--
What|Removed |Added
Severity|critical|normal
Component|fortran |libfortran
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
16:26 ---
This was fixed by:
http://www.linux-mips.org/archives/linux-mips/2004-08/msg00176.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20781
--- Additional Comments From jakub at gcc dot gnu dot org 2005-04-06 16:46
---
It actually looks like a x86-64 target bug.
FUNCTION_ARG returns (parallel:BLK [])
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
17:31 ---
Note I don't think it is an inappropiate call to memmove.
--
What|Removed |Added
--- Additional Comments From law at redhat dot com 2005-04-06 17:41 ---
Subject: Re: [meta-bug] Jump threading
related bugs
On Wed, 2005-04-06 at 06:38 +, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
--- Additional Comments From p dot obry at wanadoo dot fr 2005-04-06 18:14
---
(In reply to comment #5)
Ok, the documentation is missing the part where Stdcall is equivalent to
C on UNIX. This is a feature implemented some time ago. Will fix the doc.
So, what about the proposal on #4
--- Additional Comments From federico dot carminati at cern dot ch
2005-04-06 18:17 ---
Builds now succeeds with the new cctools. Thanks a lot.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
18:23 ---
This has been fixed for a while now.
--
What|Removed |Added
Status|NEW
I am linking with gfortran the following valid program
program bug
CHARACTER*2 KSHAP(3)
DATA KSHAP/'A', 2*' '/
end
and I obtain
[/Users/fca] /opt/gcc-4_0/bin/gfortran bug.f -o bug
/var/tmp//ccNLauLD.s:5:Bad Absolute Expression, absolute 0 assumed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
18:26 ---
Fixed in 4.1.0 by:
2005-03-29 Dale Johannesen [EMAIL PROTECTED]
* Makefile.in (value-prof.o): New dependencies on $(DIAGNOSTIC_H)
$(TREE_H) and $(COVERAGE_H).
* coverage.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
18:27 ---
*** This bug has been marked as a duplicate of 20063 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
18:27 ---
*** Bug 20798 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From joel at gcc dot gnu dot org 2005-04-06 18:29
---
I can confirm this for m68k-rtems with gcc 4.0.0 20050303. This looks like the
ICE that happens for us in our pppd stack on the Coldfire.
I also confirm that the small test case in
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-06
18:37 ---
This looks to me (a non fortran person) a duplicate of bug 17192.
--
What|Removed |Added
--
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20791
--- Additional Comments From echristo at redhat dot com 2005-04-06 18:57
---
There's also the problem that the current mechanism for doing unaligned
loads/stores are not valid mips16 instructions, and therefore we couldn't rely
upon the patterns unless we knew that the addresses were
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-04-06
19:02 ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00708.html
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-06
19:11 ---
Subject: Bug 20670
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_3-branch
Changes by: [EMAIL PROTECTED] 2005-04-06 19:11:36
Modified files:
gcc:
--- Additional Comments From law at redhat dot com 2005-04-06 19:21 ---
More info.
It appears that threading one specific jump is responsible for triggering
the big speedup. And it could cause the kind of effects we're seeing.
Basically we're threading a conditional branch to a loop
I try to make a bundle with the the following legal code
#include stdio.h
void *operator new(size_t size)
{ void *vp; return vp;}
void *operator new[](size_t size)
{ return ::operator new(size);}
and I obtain
[/Users/fca/nd] /opt/gcc-4_0/bin/g++ -c NewDelete.cxx
[/Users/fca/nd]
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-04-06
19:26 ---
Subject: Re: Pointers not passed as subroutine arguments
- Original Message -
From: pinskia at gcc dot gnu dot org [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, April 06, 2005 8:37 PM
--
What|Removed |Added
CC||geoffk at gcc dot gnu dot
||org
Severity|critical
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-04-06
19:31 ---
Subject: Re: Pointers not passed as subroutine arguments
I think that it is,. in principle. The examples are a bit strange
though.
Paul
- Original Message -
From: pinskia at gcc dot gnu
1 - 100 of 127 matches
Mail list logo
