https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57076
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57076
--- Comment #7 from Francois-Xavier Coudert ---
Updated patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557728.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57076
Francois-Xavier Coudert changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97864
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97864
--- Comment #12 from Francois-Xavier Coudert ---
I would bet that it's the same issue that was fixed by:
https://github.com/gcc-mirror/gcc/commit/81372618277bfae682434fcdc80b311ee6007476
2020-11-11 Jakub Jelinek
PR fortran/97768
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97864
--- Comment #13 from Francois-Xavier Coudert ---
And the backtrace is identical, too. It's a duplicated of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97864
--- Comment #15 from Francois-Xavier Coudert ---
> you can take it temporarily on HB 10.x if needed?
Unless it's a real blocker (like the Big Sur backport I did), we ship released
versions unpatched.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98805
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98805
Francois-Xavier Coudert changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98805
--- Comment #5 from Francois-Xavier Coudert ---
Here is what g++-10 -v gives during compilation:
rmeur /tmp $ g++-10 a.cpp -v
Using built-in specs.
COLLECT_GCC=g++-10
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104799
Bug ID: 104799
Summary: Header issue with x86_64-linux-musl based
cross-compiler
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104799
--- Comment #1 from Francois-Xavier Coudert ---
Should have added a link to the original report:
https://github.com/iains/gcc-darwin-arm64/issues/84
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78415
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
Francois-Xavier Coudert changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106435
Bug ID: 106435
Summary: constructor of thread_local static member is not
called
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106435
Francois-Xavier Coudert changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106435
--- Comment #5 from Francois-Xavier Coudert ---
> there was a change made to support cross-TU static inits for TLS
For what it's worth, putting everything in a single cpp file makes it work as
expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
--- Comment #3 from Francois-Xavier Coudert ---
The module in the runtime library is compiled only once, unless the library is
multilib (one libgfortran compiled for IBM double double, one libgfortran
compiled for IEEE quad).
My goal would be t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
Bug ID: 106805
Summary: Undue optimisation of floating-point comparisons
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107062
Francois-Xavier Coudert changed:
What|Removed |Added
Last reconfirmed||2022-09-28
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107062
Francois-Xavier Coudert changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |fxcoudert at gcc dot
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107062
--- Comment #3 from Francois-Xavier Coudert ---
Hum, that one test for FMA is really unreliable. I think I need to remove it
altogether, it fails on x86 as well for float and double, if it also fails on
powerpc for long double, then let's get ri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071
Bug ID: 107071
Summary: gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071
Francois-Xavier Coudert changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071
--- Comment #5 from Francois-Xavier Coudert ---
Right now the code to test support is indeed like this for glibc targets except
x86/x86_64 (libgfortran/config/fpu-glibc.h):
int
support_fpu_rounding_mode (int mode)
{
switch (mode)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071
--- Comment #7 from Francois-Xavier Coudert ---
@Richard The test in gfortran.dg/ieee/modes_1.f90 is not doing that. It is
checking that the floating-point modes (rounding mode, underflow mode, and
halting modes) can be set and restored. It is n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071
--- Comment #9 from Francois-Xavier Coudert ---
OK so there are three things tested here:
- underflow mode
- rounding mode
- trapping mode
For glibc targets, underflow control is only marked as supported for the float
and double types on __alp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107062
--- Comment #5 from Francois-Xavier Coudert ---
Fixed on trunk:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=31d7c8bc2630e1b5a35ccce97ac862c4920ba582
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107062
Francois-Xavier Coudert changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53962
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79724
Francois-Xavier Coudert changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79724
--- Comment #2 from Francois-Xavier Coudert ---
It's puzzling, because although I've never read any Ada code, I can see there
is some logic in place that should deal with it. In make.adb there is:
Gcc : String_Access := Program_Name ("gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79724
--- Comment #4 from Francois-Xavier Coudert ---
The current situation is the result of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=864
Comment 20 by Dave Korn (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=864#c20)
is spot on:
> ... means that i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103817
Bug ID: 103817
Summary: Bootstrap broken on x86_64-apple-darwin21
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103817
Francois-Xavier Coudert changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100854
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103822
Bug ID: 103822
Summary: libbacktrace make check fails with GNU Make 3.81
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103822
--- Comment #1 from Francois-Xavier Coudert ---
Oops wrong type of quotes, needs double quotes:
diff --git a/libbacktrace/Makefile.am b/libbacktrace/Makefile.am
index 8874f41338a..d200e3a9433 100644
--- a/libbacktrace/Makefile.am
+++ b/libbackt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103823
Bug ID: 103823
Summary: g++.dg/torture/pr31863.C fails on darwin with "using
serial compilation of 2 LTRANS jobs"
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936
--- Comment #6 from Francois-Xavier Coudert ---
At the same time, they appear to show up only intermittently in linux test
results, and haven't been fixed on the 11 branch either. Are C++ modules
considered experimental, or generally buggy?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103823
--- Comment #3 from Francois-Xavier Coudert ---
Any reason not to move the test to the lto testsuite?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98076
--- Comment #8 from Francois-Xavier Coudert ---
Patch posted at https://gcc.gnu.org/pipermail/fortran/2021-December/057219.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99191
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81986
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81986
Francois-Xavier Coudert changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99191
Francois-Xavier Coudert changed:
What|Removed |Added
Target Milestone|--- |12.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 99191, which changed state.
Bug 99191 Summary: sanitizer detects undefined behaviour in libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99191
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103828
Bug ID: 103828
Summary: Type generated for CHARACTER(C_CHAR), VALUE arguments
is wrong
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103828
--- Comment #1 from Francois-Xavier Coudert ---
The condition for being treated as a special CHARACTER case in gfc_sym_type()
is:
if (sym->ts.type == BT_CHARACTER
&& ((sym->attr.function && sym->attr.is_bind_c)
|| (sym->attr.r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98076
--- Comment #9 from Francois-Xavier Coudert ---
After my patch, measurements seem to indicate the output of integers is mostly
bound the library overhead. Inspection of the various itoa/btoa/otoa/xtoa
functions seems to show they're reasonably ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103828
--- Comment #2 from Francois-Xavier Coudert ---
So, even modifying gfc_sym_type() in trans-types.c to emit the proper type does
not fix the issue. Why? Because the rug is pulled under our feet later. Turns
out there is a function that deals with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103828
--- Comment #3 from Francois-Xavier Coudert ---
Created attachment 52062
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52062&action=edit
Patch, v1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103828
--- Comment #4 from Francois-Xavier Coudert ---
Wait, there is more, lower in gfc_conv_scalar_char_value():
/* If we have a constant character expression, make it into an
integer. */
if ((*expr)->expr_type == EXPR_CONSTANT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32732
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103823
--- Comment #7 from Francois-Xavier Coudert ---
Did not work: I think it's because it's lto-wrapper not lto1.
Executing on host: /private/tmp/ibin/gcc/testsuite/g++/../../xg++
-B/private/tmp/ibin/gcc/testsuite/g++/../../ /tmp/gcc-darwin-arm6
4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103823
--- Comment #8 from Francois-Xavier Coudert ---
Created attachment 52064
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52064&action=edit
Revised patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103828
Francois-Xavier Coudert changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103823
--- Comment #10 from Francois-Xavier Coudert ---
Posted at https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587376.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98076
--- Comment #11 from Francois-Xavier Coudert ---
Hi Rainer,
Apologies for that, apparently I got confused between the keyword and the macro
form. Can you confirm that bootstrapped is fixed if you change it to
static_assert(sizeof(GFC_UINTE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57042
Francois-Xavier Coudert changed:
What|Removed |Added
Keywords|ice-on-valid-code |diagnostic
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91690
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82968
--- Comment #3 from Francois-Xavier Coudert ---
Created attachment 52084
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52084&action=edit
Tentative patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82968
--- Comment #4 from Francois-Xavier Coudert ---
Specifying specific alignment in Fortran code is not directly possibly, sadly.
The only way I see how of this is to make that variable an integer, instead of
char array.
Eric, could you kindly test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89639
--- Comment #10 from Francois-Xavier Coudert ---
Created attachment 52086
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52086&action=edit
adjust testcase
David, could you kindly test the attached patch, to see if it fixes things?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103823
Francois-Xavier Coudert changed:
What|Removed |Added
Target Milestone|--- |12.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47334
Francois-Xavier Coudert changed:
What|Removed |Added
Target Milestone|--- |12.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103822
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644
Francois-Xavier Coudert changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |fxcoudert at gcc dot
gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644
--- Comment #15 from Francois-Xavier Coudert ---
Created attachment 52094
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52094&action=edit
Tentative patch, adding IEEE_FMA and IEEE_SIGNBIT
I am attaching a tentative patch for the issue. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207
--- Comment #14 from Francois-Xavier Coudert ---
Created attachment 52101
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52101&action=edit
First attempt at a patch
This is a first version of a patch for support of signalling NaNs. What it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103883
Bug ID: 103883
Summary: Signaling NaN is not handled correctly on typedef'd
floating-point type
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207
Francois-Xavier Coudert changed:
What|Removed |Added
Attachment #52101|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89639
Francois-Xavier Coudert changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644
Francois-Xavier Coudert changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103828
Francois-Xavier Coudert changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79724
Francois-Xavier Coudert changed:
What|Removed |Added
Keywords||patch
--- Comment #6 from Fran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207
--- Comment #16 from Francois-Xavier Coudert ---
Part 1/3 committed: IEEE_CLASS now recognises signaling NaNs on targets that
provide the issignaling macro (from TS 18661-1:2014).
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=492954263e39346287a5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82968
Francois-Xavier Coudert changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207
Francois-Xavier Coudert changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042
Bug ID: 104042
Summary: Four memcpy/memset analyzer failures on darwin
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104220
Francois-Xavier Coudert changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104220
Francois-Xavier Coudert changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104233
--- Comment #1 from Francois-Xavier Coudert ---
If __FLT128_IS_IEC_60559__ is defined, does it mean that the associated type is
accessible as _Float128?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104233
--- Comment #2 from Francois-Xavier Coudert ---
Created attachment 52289
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52289&action=edit
Tentative patch
Does the attached patch fix the issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104233
--- Comment #4 from Francois-Xavier Coudert ---
> Shouldn't the __float128 stuff be guarded with
> defined(GFC_REAL_16_IS_FLOAT128) || defined(HAVE_GFC_REAL_17)
We could. My goal was for that header not to depend on libgfortran macros
(meaning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104233
--- Comment #7 from Francois-Xavier Coudert ---
Pushed the fix as logical after checking on aarch64-apple-darwin.
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8769f32b645eb08b9f07ec3171cc21c3420f8616
Please let me know if this fixes SPARC/Sola
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207
Francois-Xavier Coudert changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104233
Francois-Xavier Coudert changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103828
--- Comment #8 from Francois-Xavier Coudert ---
I'm not sure if it really counts as an ABI change, given that I know no
existing target where this resulted in an actual change in the argument passing
convention. (i.e., where that test actually f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936
--- Comment #9 from Francois-Xavier Coudert ---
Most likely this:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=db84f382ae3dc238b1c3e3a18b786bca5bd38a14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #30 from Francois-Xavier Coudert ---
(In reply to Iain Sandoe from comment #29)
> I've posted a fix for this (it is the fix for darwin21 DTORs in general)
Yes I've seen the patch, thanks!
> however CAVEAT : there is No guarantee gi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #32 from Francois-Xavier Coudert ---
(In reply to Jürgen Reuter from comment #31)
> Does this now mean that this is fixed within the gcc trunk/master? Or just in
> a branch which has yet to be merged into the master?
The patch was p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #37 from Francois-Xavier Coudert ---
OS bug confirmed to be still present on macOS 12.1 (darwin 21.2.0), at least on
Intel. I don't have a non-patched compiler on ARM right now to confirm, but I
don't expect it to be arch-dependent.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
1 - 100 of 248 matches
Mail list logo
