https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598
--- Comment #3 from Jan Kratochvil ---
LLVM has workarounded it by:
https://reviews.llvm.org/rG0e3d7e61867d69721b28e557272bdf4b66010327
template <>
- struct DenseMapInfo> {
+ struct llvm::DenseMapInfo> {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99072
--- Comment #2 from Boris Kolpackov ---
This has something to do with a different .ii file name the second time we
compile the header. Try to make this change to your command lines (notice .so
before .ii):
# second build of string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99050
--- Comment #2 from Boris Kolpackov ---
Can confirm now works for me, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99130
Bug ID: 99130
Summary: Variable template in unevaluated context is wrongly
implicitly instantiated
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99121
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99121
Martin Sebor changed:
What|Removed |Added
Blocks||56456
--- Comment #2 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598
--- Comment #2 from Jan Kratochvil ---
Created attachment 50210
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50210=edit
2j.cpp.xz
gcc-11.0.0-0.19.fc34.x86_64
g++ -c 2j.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598
Jan Kratochvil changed:
What|Removed |Added
CC||jan.kratochvil at redhat dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034
--- Comment #10 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:78a6d0e30d7950216dc0c5be5d65d0cbed13924c
commit r11-7263-g78a6d0e30d7950216dc0c5be5d65d0cbed13924c
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96997
--- Comment #12 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:78a6d0e30d7950216dc0c5be5d65d0cbed13924c
commit r11-7263-g78a6d0e30d7950216dc0c5be5d65d0cbed13924c
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99068
--- Comment #9 from Brian Grayson ---
If I understand correctly, you're saying that it is sometimes preferred for gcc
to avoid update form, but even when the load and addi are next to each other
it's possible to use update form, like in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #26 from Segher Boessenkool ---
Can you show the code you tried in comment 23? It is near impossible to see
what happened there without that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99129
Bug ID: 99129
Summary: missing -Warray-bounds accessing a zero-length member
array of a local struct with a cast
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99068
--- Comment #8 from Segher Boessenkool ---
Using update form instructions constrains register allocation and scheduling.
It is *not* always a good idea.
That is one of the reasons why we currently use update form instructions only
when insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99128
Bug ID: 99128
Summary: Stack used for concatenating values when returning
struct by register
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99127
Kurt Miller changed:
What|Removed |Added
CC||kurt at intricatesoftware dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99127
Bug ID: 99127
Summary: ICE in expand_expr_addr_expr_1, at expr.c:8026 (during
RTL pass: expand) at -O1 or higher on hppa
Product: gcc
Version: 8.4.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99071
--- Comment #1 from Nathan Sidwell ---
Reduced testcase:
// 99071_a.H
template
void begin (T *);
// 99071_b.H
import "99071_a.H";
template
void begin(T &);
./cc1plus -fmodule-header -quiet -std=c++17 99071_a.H
./cc1plus -fmodule-header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96251
Iain Sandoe changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99121
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96251
Iain Sandoe changed:
What|Removed |Added
CC||mail+gnu at tzik dot jp
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98976
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99050
Nathan Sidwell changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126
--- Comment #1 from Andrea Corallo ---
This is the bt of how the C front-end is initializing these
declarations:
#0 set_builtin_decl (implicit_p=,
decl=,
fncode=) at ../../gcc/tree.h:5662
#1 def_builtin_1 (fncode=, name=,
This is the bt of how the C front-end is initializing these
declarations:
#0 set_builtin_decl (implicit_p=,
decl=,
fncode=) at ../../gcc/tree.h:5662
#1 def_builtin_1 (fncode=, name=,
fntype=, libtype=, both_p=,
fallback_p=, nonansi_p=false,
fnattrs=, implicit_p=true,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003
--- Comment #24 from Martin Sebor ---
I see. Yes, if the types are unrelated, that would be a likely bug. I think
could and should be diagnosed by the C++ front end, by some more targeted
warning than -Wnonnull (as requested in pr38557).
But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126
Bug ID: 99126
Summary: Compilation ICE trying insert trap
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99062
Marek Polacek changed:
What|Removed |Added
Summary|[10/11 Regression] ICE in |[10 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99062
--- Comment #6 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:30a4d95bf76b0a0fdb66ac0211589a4434c83af3
commit r11-7259-g30a4d95bf76b0a0fdb66ac0211589a4434c83af3
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99114
--- Comment #7 from pipcet at gmail dot com ---
(In reply to Eric Botcazou from comment #4)
> > I'll try, but please consider investigating this without one. It happens
> > after a very lengthy compilation process (compiling a buggy gcc with a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003
--- Comment #23 from Martin Liška ---
(In reply to Martin Sebor from comment #20)
> Martin, does the code in the packages follow the pattern below?
>
> $ cat t.C && gcc -O2 -S -Wall t.C
> struct A { virtual ~A (); };
> struct B { virtual ~B ();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003
--- Comment #22 from Martin Liška ---
(In reply to Martin Sebor from comment #21)
> Also, how many warnings for this type of code (or other) do you see? If
> there are too many it might be worth revisiting the decision.
I see it only in 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99124
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99125
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99068
--- Comment #7 from Brian Grayson ---
A single lhau instruction is better than two instructions (lha + addi) for many
reasons. Are there reasons that you feel a two-instruction sequence of lha+addi
is *superior* to just an lhau?
On all PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99114
--- Comment #6 from pipcet at gmail dot com ---
Created attachment 50204
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50204=edit
RTL dump of combine pass
(Gzipped because of the file size limit).
The relevant section is around this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99114
pipcet at gmail dot com changed:
What|Removed |Added
CC||pipcet at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2021-02-16
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99123
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96997
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96997
--- Comment #11 from Jakub Jelinek ---
I'd say so, yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96997
--- Comment #10 from Patrick Palka ---
It looks like the problematic hunk from r10-7718 is
* tree.c (build_aggr_init_expr): Set the location of the AGGR_INIT_EXPR to that
of its initializer.
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99121
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2021-02-16
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99125
--- Comment #1 from G. Steinmetz ---
Works with valid code :
$ cat z0.f90
program p
type t
character(:), allocatable :: c(:)
end type
character(8) :: a(2) = '12 45 78'
type(t) :: x
x%c = a
print *, x%c
print *,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99125
Bug ID: 99125
Summary: [9/10/11 Regression] ICE: gimplification failed
(gimplify.c:15068)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99124
Bug ID: 99124
Summary: [9/10/11 Regression] ICE in gfc_get_class_from_expr,
at fortran/trans-expr.c:541
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003
--- Comment #21 from Martin Sebor ---
Also, how many warnings for this type of code (or other) do you see? If there
are too many it might be worth revisiting the decision.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99123
Bug ID: 99123
Summary: ICE in decompose_normal_address, at rtlanal.c:6710
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99120
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003
--- Comment #20 from Martin Sebor ---
Martin, does the code in the packages follow the pattern below?
$ cat t.C && gcc -O2 -S -Wall t.C
struct A { virtual ~A (); };
struct B { virtual ~B (); void f (); };
void f (A *p)
{
if (dynamic_cast(p))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99120
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
Bug ID: 99122
Summary: [10/11 Regression] ICE in force_constant_size, at
gimplify.c:733
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99120
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86096
--- Comment #8 from Alexander Monakov ---
It was fixed on the trunk only, so as the title says it remains an issue on the
gcc-8 branch (which is still open). Bugzilla doesn't have separate resolutions
for different branches, we cannot have this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99121
Bug ID: 99121
Summary: [9/10/11 Regression] ICE tree check: expected
integer_cst, have var_decl in get_len, at tree.h:6037
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15720
seurer at gcc dot gnu.org changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21761
seurer at gcc dot gnu.org changed:
What|Removed |Added
Status|VERIFIED|CLOSED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12738
seurer at gcc dot gnu.org changed:
What|Removed |Added
Status|VERIFIED|CLOSED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96997
--- Comment #9 from Jakub Jelinek ---
No differences in -fdump-tree-original-lineno dump, but it seems the original
dump doesn't really dump any locations for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99120
Bug ID: 99120
Summary: ICE in -Wshadow in templated member function
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
seurer at gcc dot gnu.org changed:
What|Removed |Added
Status|VERIFIED|CLOSED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21460
seurer at gcc dot gnu.org changed:
What|Removed |Added
Known to fail||
Status|VERIFIED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42431
seurer at gcc dot gnu.org changed:
What|Removed |Added
Status|VERIFIED|CLOSED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20780
seurer at gcc dot gnu.org changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96997
--- Comment #8 from Jakub Jelinek ---
The -fdump-tree-gimple-lineno changes between the previous revision and the
above one are:
--- pr96997.ii.005t.gimple_ 2021-02-16 12:04:49.0 -0500
+++ pr96997.ii.005t.gimple 2021-02-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86096
seurer at gcc dot gnu.org changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96997
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #25 from Michael Meissner ---
Created attachment 50201
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50201=edit
Example code for both input and output %m usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #24 from Michael Meissner ---
Obviously I had a small typo in the previous example (using %U0%X0 instead of
%U1%X1) which did not matter, but here is the corrected example:
static int x;
int *p_x =
int get (void)
{
int a;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #23 from Michael Meissner ---
Obviously one approach is to use the recog_data.is_asm field to determine if
the %m constraint is in an asm and restrict it to non-prefixed memory
addresses.
However, this doesn't work, because is_asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99109
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99068
--- Comment #6 from Segher Boessenkool ---
(In reply to Brian Grayson from comment #4)
> (In reply to Segher Boessenkool from comment #3)
> > Then you get
> >
> > addi 9,9,-2
> > lhau 10,2(9)
> > addi 9,9,2
> >
> > which is worse than just
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99118
Martin Liška changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99068
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99118
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|marxin at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99118
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99118
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2021-02-16
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99072
Nathan Sidwell changed:
What|Removed |Added
Last reconfirmed||2021-02-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096
--- Comment #2 from CVS Commits ---
The master branch has been updated by Vladimir Makarov :
https://gcc.gnu.org/g:72d78655a91bb2f89ac4432cfd6374380d6f9987
commit r11-7256-g72d78655a91bb2f89ac4432cfd6374380d6f9987
Author: Vladimir N. Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99106
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96960
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99067
bin cheng changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99119
Marek Polacek changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93383
Marek Polacek changed:
What|Removed |Added
CC||vopl at bk dot ru
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98719
Nathan Sidwell changed:
What|Removed |Added
Last reconfirmed||2021-02-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98998
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98722
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98777
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98720
Nathan Sidwell changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98722
--- Comment #6 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #5)
> Another P1 that looks like it might be fixed. Vlad, can we marked this as
> fixed?
I believe it is fixed and we could close the PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98777
--- Comment #5 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #4)
> Vlad, is this fixed now and we can close it? It's marked as a P1, so would
> be nice to close if fixed.
I believe it is fixed and we could close the PR but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #34 from H.J. Lu ---
This may be related to
https://sourceware.org/pipermail/binutils/2021-February/115395.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99119
Bug ID: 99119
Summary: Class Types in Non-Type Template Parameters - ICE with
templates nested
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #9 from Jonathan Wakely ---
Something like this prevents the miscompilation, at the cost of an extra copy:
--- a/libstdc++-v3/include/std/valarray
+++ b/libstdc++-v3/include/std/valarray
@@ -838,7 +838,13 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #17 from Martin Liška ---
I've got a patch candidate.
Using the patch, make -j128 check-clang takes 6 minutes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99116
Nathan Sidwell changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99111
--- Comment #3 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:ebf9b6c13f0847ddcc22e540a5fcdbf644e85a9c
commit r11-7255-gebf9b6c13f0847ddcc22e540a5fcdbf644e85a9c
Author: Tobias Burnus
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99118
Bug ID: 99118
Summary: ICE in alias_ctad_tweaks, at cp/pt.c:28569
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #100 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:3f16a1678156035bbe73b217fbce4d9c27d1d559
commit r11-7254-g3f16a1678156035bbe73b217fbce4d9c27d1d559
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #8 from rguenther at suse dot de ---
On Tue, 16 Feb 2021, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
>
> --- Comment #7 from Jonathan Wakely ---
> (In reply to Jakub Jelinek from comment
1 - 100 of 122 matches
Mail list logo
