--- Comment #5 from rob1weld at aol dot com 2009-03-18 06:19 ---
Nearly perfect results: (better than the Trunk last week)
Results for 4.4.0 20090313 (experimental) [melt-branch revision 144923] (GCC)
testsuite on i686-unknown-linux-gnu
Consider the following function declaration:
int f(int a, int (*b)(int a));
When compiled with g++ trunk using -Wshadow, some new, probably useless,
warnings appear:
shadow.h:2: warning: declaration of 'int a' shadows a parameter
shadow.h:2: warning: shadowed declaration is here
It seems to be
--- Comment #4 from mark_r_eggleston at yahoo dot co dot uk 2009-03-18
08:59 ---
Subject: Re: Can not resolve PUT between String and Character versions.
Sam,
Thank you that make complete sense and explains why I could only reproduce this
problem with integers ans its sub types as
--- Comment #1 from jakub at gcc dot gnu dot org 2009-03-18 09:00 ---
*** This bug has been marked as a duplicate of 38022 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2009-03-18 09:00 ---
*** Bug 39487 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2009-03-18 08:56 ---
Created an attachment (id=17483)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17483action=view)
gcc44-pr39485.patch
Self inflicted pain I'd say, if you don't want something in register, don't use
a register
--- Comment #19 from falk at debian dot org 2009-03-18 09:06 ---
(In reply to comment #18)
I can't imagine an implementation of memcpy that would break when the two
addresses are the same, it just doesn't work if one is offset but
overlapping.
So the valgrind warning is
The compilation with gfortran 4.3 on i486 processors seems to produces a module
with an error. Further include of that module produces an overflow message and
aborts the compilation.
The same module compiles without problems with gfortran 4.3.2 on x86_64
processors.
I'm not sure what further
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-18 09:43 ---
a is promoted to unsigned int because the enum is unsigned.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39488
--- Comment #2 from algrant at acm dot org 2009-03-18 09:45 ---
No, the enum is signed, see AAPCS 7.1.3: the container type is int
unless the upper bound is greater than 2147483647.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39488
--- Comment #1 from dominiq at lps dot ens dot fr 2009-03-18 09:46 ---
I'm not sure what further information I should submit...
Submit a reduced test case showing the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39489
--- Comment #21 from rguenth at gcc dot gnu dot org 2009-03-18 09:47
---
For
struct A
{
int i[200];
};
struct A *p1, *p2;
void f()
{
*p1 = *p2;
}
we are sure that either p1 == p2 or *p1 and *p2 do not overlap because
otherwise there would be an alias violation.
--
gfortran accepts the following syntax for the assignment of character objects:
CHARACTER(14) :: prop(4) = (/'name', 'data_file_name', 'Ho_units',
'mpolar_units'/)
Although this is convenient, is not according to the Fortran standard that
requires that all of the elements of a constructor be the
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-03-18 10:01 ---
It's hard to tell without a code example, really ...
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from jakub at gcc dot gnu dot org 2009-03-18 10:11 ---
The problem with that is that in most cases you won't be able to prove it and
memmove is certainly more expensive than memcpy and usually isn't even expanded
inline (unless it is optimized into memcpy by proving
On hppa-linux-gnu the symbol __signb...@glibcxx_3.4 isn't exported anymore (4.4
20090317 built using binutils 2.19.1 and glibc-2.9)
--
Summary: [4.4 regression] symbol __signb...@glibcxx_3.4 in
libstdc++ not exported anymore
Product: gcc
--- Comment #1 from dominiq at lps dot ens dot fr 2009-03-18 11:17 ---
Confirmed on 4.3.3, trunk gives:
pr39490.f90:1.36:
CHARACTER(14) :: prop(4) = (/'name', 'data_file_name', 'Ho_units', 'mpolar_unit
1
Error: Different CHARACTER lengths (4/14) in
With ARM ABI variant selected by -fno-short-enums the compare shouldn't
be optimized away:
enum RC { X, Y, Z };
int check_error(enum RC a) { return a 0; }
C 6.3#2 guarantees that any value of the compatible type can be assigned
to and from values of the enumerator type with no change to the
--- Comment #3 from rearnsha at gcc dot gnu dot org 2009-03-18 11:49
---
No feedback in over a year. Presumed fixed in 4.3.0.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from fpbeekhof at gmail dot com 2009-03-18 09:56 ---
Subject: Re: generated memcpy causes trouble in assignment
jakub at gcc dot gnu dot org wrote:
--- Comment #20 from jakub at gcc dot gnu dot org 2009-03-18 09:10
---
So let's use memmove on alpha and
--- Comment #23 from fpbeekhof at gmail dot com 2009-03-18 10:04 ---
My last comment (#22) of course does not address issues pointed out by jason in
#18.
Even if we know that we are sure that either p1 == p2 or *p1 and *p2 do not
overlap because otherwise there would be an alias
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-18 10:59 ---
BTW, related, we only generate DW_AT_prototyped attributes for DW_LANG_C89,
shouldn't we generate them also for DW_LANG_C99, DW_LANG_ObjC?
As lang_hooks are const, we can't modify lang_hooks.name depending on
--- Comment #3 from jsm28 at gcc dot gnu dot org 2009-03-18 12:25 ---
The enum is unsigned by present GNU C rules. This is a bug (that I was
already aware of, but may be hard to fix) in the AAPCS implementation,
not a front-end bug.
--
jsm28 at gcc dot gnu dot org changed:
--- Comment #5 from gnu at the-meissners dot org 2009-03-18 12:48 ---
Subject: Re: New: [power7-meissner] unable to find a
register to spill in class 'LINK_OR_CTR_REGS'
If possible, please send mail on power7 to meiss...@linux.vnet.ibm.com. I
don't read mail on my home
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-18 12:52 ---
Created an attachment (id=17484)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17484action=view)
gcc44-pr38757.patch
Fix which will allow later on similar differentiation between C++98 and C++0x
or say Fortran
If two parallel GCC compilation processes, which use different PCH files, run
on Windows NT version 5 or newer (e.g. Win2K, WinXP, Vista) in the same session
then a race condition occurs, which most likely leads to Access Denied error.
This may happen even if different toolchains are used or
--- Comment #21 from sliwa at cft dot edu dot pl 2009-03-18 13:25 ---
Yes, yes, using gcc has to be pain in the neck.
You are reluctant to fix an obvious mistake and instead of saying sorry are
keeping it broken.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
Mips ABI specifies to let the space for 4 arguments in stack when calling a
function. This is not respected when accessing tls variable with a dynamic
model: gcc implicitely calls __get_tls_addr without making rooms for the
arguments. The top of the stack is then likely to be erase.
Here is an
--- Comment #1 from joel dot porquet at gmail dot com 2009-03-18 14:06
---
Created an attachment (id=17485)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17485action=view)
Makefile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39493
--- Comment #2 from joel dot porquet at gmail dot com 2009-03-18 14:06
---
Created an attachment (id=17486)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17486action=view)
Example C file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39493
Sent from my iPhone
On Mar 18, 2009, at 7:05 AM, joel dot porquet at gmail dot com gcc-bugzi...@gcc.gnu.org
wrote:
Mips ABI specifies to let the space for 4 arguments in stack when
calling a
function. This is not respected when accessing tls variable with a
dynamic
model: gcc
--- Comment #3 from pinskia at gmail dot com 2009-03-18 14:22 ---
Subject: Re: New: [Mips] No space for arguments when implicitely calling
__get_tls_addr
Sent from my iPhone
On Mar 18, 2009, at 7:05 AM, joel dot porquet at gmail dot com
gcc-bugzi...@gcc.gnu.org
wrote:
Mips
--- Comment #4 from joseph at codesourcery dot com 2009-03-18 14:27 ---
Subject: Re: [Mips] No space for arguments when implicitely
calling __get_tls_addr
On Wed, 18 Mar 2009, pinskia at gmail dot com wrote:
__get_tls_addr is a special function and does not have to follow that
--- Comment #6 from joel at gcc dot gnu dot org 2009-03-18 14:27 ---
OK. I decided to look at this in more detail in the simulator. The failing
instruction is:
2001358: d0 07 bf fc ld [ %fp + -4 ], %o0
and when I run with a breakpoint there, a dump of the registers shows
I'm sorry...I don't know what triplet means. There was nothing about it in
the FAQ. I took my best guess.
g++ -v --version prints
g++ (Debian 4.3.2-1.1) 4.3.2
cat /proc/version prints
Linux version 2.6.26-1-686 (Debian 2.6.26-13) (wa...@debian.org) (gcc version
4.1.3 20080704 (prerelease)
--- Comment #1 from james dot ashley at gmail dot com 2009-03-18 14:33
---
Created an attachment (id=17487)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17487action=view)
Smallest example I could come up with
Sorry, like I said in the description, I wasn't sure I'd have a chance
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-18 14:56 ---
This means that a reference to an abstract function is emitted which should
have been cloned. EDG accepts this testcase so I qualify this as wrong-code
bug.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #4 from hjl at gcc dot gnu dot org 2009-03-18 14:57 ---
Subject: Bug 39425
Author: hjl
Date: Wed Mar 18 14:56:45 2009
New Revision: 144932
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144932
Log:
gcc/cp/
2009-03-18 H.J. Lu hongjiu...@intel.com
PR
--- Comment #5 from hjl at gcc dot gnu dot org 2009-03-18 15:00 ---
Subject: Bug 39425
Author: hjl
Date: Wed Mar 18 15:00:32 2009
New Revision: 144933
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144933
Log:
gcc/cp/
2009-03-18 H.J. Lu hongjiu...@intel.com
Backport
--- Comment #3 from n dot pinhao at netvisao dot pt 2009-03-18 15:06
---
Created an attachment (id=17488)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17488action=view)
Streamlined module files reproducing the error
See the README for compilation instructions
--
--- Comment #4 from n dot pinhao at netvisao dot pt 2009-03-18 15:08
---
The code was tested only with gfortran 4.3.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39489
--- Comment #5 from dominiq at lps dot ens dot fr 2009-03-18 15:44 ---
On powerpc-apple-darwin9 with gfortran 4.3.3 (with or without -m64) I get:
[karma] Downloads/gftest% gfortran -c MpkBase.f95
MpkBase.f95:831.17:
END MODULE pkBase
1
Internal Error at (1):
--- Comment #3 from hjl dot tools at gmail dot com 2009-03-18 16:16 ---
Icc ia32 generates:
_ZTV7Derived:
.type _ZTV7Derived,@object
.size _ZTV7Derived,12
.long 0
.long _ZTI7Derived
.long __cxa_pure_virtual
Gcc generates:
--- Comment #6 from dfranke at gcc dot gnu dot org 2009-03-18 16:35 ---
With 4.3.4 (20090318) I get:
$ gfortran-4.3 -o test MpkCommon.f95 MpkBase.f95 MpkData.f95 teste.f95
MpkBase.f95:831.17:
END MODULE pkBase
1
Internal Error at (1):
write_atom(): Writing negative
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2009-03-18 16:56
---
OK. I decided to look at this in more detail in the simulator. The failing
instruction is:
2001358: d0 07 bf fc ld [ %fp + -4 ], %o0
and when I run with a breakpoint there, a dump of the
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-18 17:06 ---
Subject: Bug 39485
Author: jakub
Date: Wed Mar 18 17:06:15 2009
New Revision: 144939
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144939
Log:
PR debug/39485
* function.c
--- Comment #8 from joel at gcc dot gnu dot org 2009-03-18 17:12 ---
(In reply to comment #7)
OK. I decided to look at this in more detail in the simulator. The failing
instruction is:
2001358: d0 07 bf fc ld [ %fp + -4 ], %o0
and when I run with a breakpoint
--- Comment #7 from n dot pinhao at netvisao dot pt 2009-03-18 17:44
---
Created an attachment (id=17489)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17489action=view)
Streamlined module files reproducing the error (2)
Test files with a corrected version of MpkData.f95.
With
--- Comment #2 from eric dot weddington at atmel dot com 2009-03-18 17:47
---
Confirmed with gcc 4.3.2.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #8 from n dot pinhao at netvisao dot pt 2009-03-18 17:48
---
The code compiles with gfortran 4.2 without problems.
--
n dot pinhao at netvisao dot pt changed:
What|Removed |Added
--- Comment #8 from spop at gcc dot gnu dot org 2009-03-18 17:48 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jan dot kratochvil at redhat dot com 2009-03-18 18:01
---
I see I messed it up, in some way was gcc-4.4 more correct than gcc-4.3
Thanks for the fix although now I would not probably bugreport it at all.
It turned PASS-XFAIL.
But in fact PASS means
--- Comment #9 from joel at gcc dot gnu dot org 2009-03-18 18:18 ---
Jiri Gaisler confirms there is no ta 3 handler in RTEMS currently. He will
be adding it to RTEMS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35180
--- Comment #4 from jakub at gcc dot gnu dot org 2009-03-18 18:48 ---
Anyway, I consider this fixed. If gdb wants to test also what happens with
such classes in registers, it can always use -O1 or above.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2009-03-18 18:54
---
Subject: Bug 35180
Author: ebotcazou
Date: Wed Mar 18 18:54:31 2009
New Revision: 144942
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144942
Log:
PR target/35180
* config/sparc/sparc.md
--- Comment #2 from burnus at gcc dot gnu dot org 2009-03-18 19:12 ---
Confirmed on 4.3.3
Well, I get also with 4.3.x an error with -std=f95.
The question is rather: Is is on purpose that it is rejected with -std=gnu with
4.4, while 4.2/4.3 accept it. (g95, sunf95 and NAG f95 reject
% cat test.c
#include stdlib.h
#include omp.h
void foo(unsigned ub, unsigned *array)
{
unsigned i;
// test passes for N = 1
#define N 0
#pragma omp for
for (i = ub; i N; i -=2) {
array[i] = i;
}
}
% gcc -fopenmp -c test.c
test.c: In function #915;Çÿfoo#915;ÇÖ:
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-18 20:49 ---
This is likely because fold canonicalizes i 0 to i != 0 for unsigned i which
is a predicate not handled by c_finish_omp_for. Likely the same issue exists
for other frontends.
--
rguenth at gcc dot gnu dot org
On Linux/x86-64, I got
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c: In function encode_decimal32:
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c:142: warning: dereferencing
type-punned pointer will break strict-aliasing rules
/export/gnu/import/svn/gcc-model/gcc/gcc/dfp.c: In function
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-03-18 21:14 ---
even though the standard IA-32 calling conventions pass the
first argument on the stack
I thought this was disabled at -O0. At -O1 this should be enabled.
--
pinskia at gcc dot gnu dot org changed:
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Component|middle-end |bootstrap
Target Milestone|--- |4.4.0
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-18 21:16 ---
Related to PR 37897.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
with: ../gcc/configure --prefix=/home/jimb/gcc
--enable-languages=c,c++
Thread model: posix
gcc version 4.4.0 20090318 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-O0' '-g' '-o' 'jsobj' '-save-temps' '-shared-libgcc'
'-mtune=generic'
/home/jimb/gcc/libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1plus
--- Comment #1 from jimb at red-bean dot com 2009-03-18 21:11 ---
Created an attachment (id=17490)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17490action=view)
Test case
This is the same test case used in the transcript; attached just for
convenience.
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-18 21:24 ---
A patch to build dfp.c with -fno-strict-aliasing is pre-approved (just use the
dfp.o-warn variable in Makefile.in)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39497
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-03-18 21:32 ---
Confirmed. In 3.3 this worked (was probably not implemented).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-03-18 21:33 ---
Confirmed. dfp.c is crap.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
I see the ACATS test c94001c failing in revision 144928 on i686-pc-linux-gnu,
in revision 144811 it was okay.
--
Summary: [4.4 Regression] ACATS test c94001c fails
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-18 21:55 ---
It works here:
http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg01891.html
can you reproduce it?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-03-18 21:56 ---
/* Use register calling convention for local functions when possible. */
if (decl TREE_CODE (decl) == FUNCTION_DECL
!profile_flag)
That should include !optimize I think.
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-03-18 21:57 ---
We used to check flag_unit_at_a_time in this function:
/* Use register calling convention for local functions when possible. */
if (decl TREE_CODE (decl) == FUNCTION_DECL
flag_unit_at_a_time
--- Comment #1 from bje at gcc dot gnu dot org 2009-03-18 22:11 ---
Invoking gcc with every possible argument to -msdata, I see:
eabi
./as -mppc -many -Qy -memb -o foo.o /tmp/ccVvv3TA.s
sysv
./as -mppc -many -Qy -o foo.o /tmp/ccdORyjE.s
default
./as -mppc -many -Qy -o foo.o
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-18 22:19 ---
-- THIS TEST CONTAINS SHARED VARIABLES AND RACE CONDITIONS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39498
--- Comment #3 from laurent at guerby dot net 2009-03-18 22:22 ---
One ACTS test fail are usually due to some race, could you look at the exact
message related to the FAIL in build/gcc/testsuite/ada/acats/acats.log?
--
laurent at guerby dot net changed:
What|Removed
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-03-18 22:24
---
Please post the failure message when you report failures.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from hp at gcc dot gnu dot org 2009-03-18 22:24 ---
(In reply to comment #11)
I think you may need a frame pointer for
if (cfun-calls_alloca
|| cfun-has_nonlocal_label
|| crtl-has_nonlocal_goto)
That should be covered by the generic code, not the
--- Comment #13 from hp at gcc dot gnu dot org 2009-03-18 22:29 ---
Noticed bug in middle-end (reload1.c:set_label_offsets) changing to middle-end.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
+++ This bug was initially created as a clone of Bug #38609 +++
See PR38609 comment 12.
I noticed that reload1.c:set_label_offsets assumes that all labels reachable
from indirect jumps are assumed to be at their initial elimination offsets,
which fails if there's an alloca call or similar
--- Comment #1 from hp at gcc dot gnu dot org 2009-03-18 23:42 ---
Whoops. Summary improved.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
autopar fails auto-parallelization with the code below:
int X[1000];
int main(void)
{
int i;
for (i = 0; i 100; i++)
X[i] = X[i+100];
return 0;
}
--
Summary: autopar fails to parallel
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
--- Comment #1 from nemokingdom at gmail dot com 2009-03-19 01:27 ---
(In reply to comment #0)
autopar fails auto-parallelization with the code below:
int X[1000];
int main(void)
{
int i;
for (i = 0; i 100; i++)
X[i] = X[i+100];
return 0;
}
This bug
--- Comment #2 from spop at gcc dot gnu dot org 2009-03-19 02:06 ---
The patch looks good. I'm bootstrapping and testing it, and then I will apply
it to trunk.
Thanks,
Sebastian
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from spop at gcc dot gnu dot org 2009-03-19 02:07 ---
I will take care of this one.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from nemokingdom at gmail dot com 2009-03-19 02:46 ---
(In reply to comment #3)
I will take care of this one.
I add test case for this situation.
Index: testsuite/gcc.dg/autopar/pr39500-1.c
===
---
--- Comment #5 from sebpop at gmail dot com 2009-03-19 02:52 ---
Subject: Re: autopar fails to parallel
On Wed, Mar 18, 2009 at 20:46, nemokingdom at gmail dot com
gcc-bugzi...@gcc.gnu.org wrote:
I add test case for this situation.
Yes, indeed this is a good idea.
Thanks for the
--- Comment #6 from sebpop at gmail dot com 2009-03-19 02:53 ---
Subject: Re: autopar fails to parallel
What |Removed |Added
Component|middle-end
--- Comment #14 from hp at gcc dot gnu dot org 2009-03-19 03:53 ---
Subject: Bug 38609
Author: hp
Date: Thu Mar 19 03:52:58 2009
New Revision: 144951
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144951
Log:
PR middle-end/38609
* config/cris/cris.h
--- Comment #15 from hp at gcc dot gnu dot org 2009-03-19 04:17 ---
Follow-up to 39499.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
88 matches
Mail list logo
