https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #11 from Richard Biener ---
Yes, they should compare equal. Integer constant ranges do not need a type.
Not even FP constant ranges. Symbolic ranges need a type, but then the
endpoints in their symbolic form have one (and those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108651
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108651
kargl at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108650
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
--- Comment #18 from Richard Biener ---
OK, thanks for the info. These kind of testcases are quite useful in that they
are not done for the purpose of breaking the compiler and they show algorithmic
deficiencies in GCC. GCC aims to be able to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
--- Comment #4 from Jerry DeLisle ---
Well folks, I like to document my thought process.
>From the 2022 draft standard we have:
R781 ac-value is expr or ac-implied-do
R782 ac-implied-do is ( ac-value-list , ac-implied-do-control )
In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108185
--- Comment #5 from JuzheZhong ---
Revise the testcase, it has a bug here:
void foo5_3 (int32_t * restrict in, int32_t * restrict out, size_t n, int cond)
{
vint8m1_t v = *(vint8m1_t*)in;
*(vint8m1_t*)out = v;
vbool8_t v3 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
--- Comment #3 from Jerry DeLisle ---
I have a copy of the standard so I will answer my own question. This is a
comment:
In a situation like this:
print *, [integer :: ([1.0])] ** 2
My brain wants to say reject it because 1.0 is not an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649
Jerry DeLisle changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108641
--- Comment #2 from weilomg ---
(In reply to Andrew Pinski from comment #1)
> >Fatal Error: Wrong module version '6' (expected '5') for file 'sizes.mod'
> >opened at (1)
>
>
> This means the modules you are using was compiled with a newer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409
--- Comment #19 from Rama Malladi ---
Thanks @Sebastian and @Martin J. I will get another bisect between GCC 7-and-8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108645
--- Comment #2 from Andrew Pinski ---
>Tested with both clang and gcc trunk, so it seems to be a library level issue.
I tested clang with -stdlib=libc++ and it produces the same results as without
that option (which is it uses gcc's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
--- Comment #24 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #23)
> I also suspect many of these new warnings we are doing in recent years
> really should not be part of -Wall because of how many false positives we
> have.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649
--- Comment #5 from Scott Boyce ---
Comment on attachment 54395
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54395
Source Part 1
This is a part 1 of a 3 part zip file created with 7zip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108652
Bug ID: 108652
Summary: type-bound procedure that returns integer used to
allocate character on stack
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108651
Bug ID: 108651
Summary: Array Constructor with [type-spec:: fails to apply to
all values, eg x = [integer(int64):: 1,2,3,4]
Product: gcc
Version: 11.3.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108650
Bug ID: 108650
Summary: Error: IMPORT statement only permitted in an INTERFACE
body | but it should be allowed in any contained
routine to control scope
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649
--- Comment #4 from Scott Boyce ---
Created attachment 54397
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54397=edit
Source Part 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649
--- Comment #3 from Scott Boyce ---
Created attachment 54396
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54396=edit
Source Part 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649
--- Comment #2 from Scott Boyce ---
Created attachment 54395
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54395=edit
Source Part 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649
--- Comment #1 from Scott Boyce ---
Missing attachment in first post
I was unable to compress the source code to 1MB.
So I will make it into a mutlipart zip over the next three posts.
If you want to download a single zip file, it is located
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649
Bug ID: 108649
Summary: allocation segmentation fault for pointer derive type
and ICE for final-binding
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
--- Comment #23 from Andrew Pinski ---
The patch which would have "fixed" this was reverted as there was too many
false positives and that happens when you do optimization based warnings ...
I don't know if we want to keep this open or close
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507
Bug 95507 depends on bug 95515, which changed state.
Bug 95515 Summary: missing --Wnonnull on a straightforward call with a null
pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95515
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
--- Comment #22 from Andrew Pinski ---
*** Bug 95515 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95515
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108648
Bug ID: 108648
Summary: -Wanalyzer-fd-leak false positives seen on haproxy's
proto_tcp.c
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95515
Andrew Pinski changed:
What|Removed |Added
CC||jg at jguk dot org
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108646
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108637
Li Shaohua changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108637
--- Comment #2 from Li Shaohua ---
(In reply to Andrew Pinski from comment #1)
> PRE removes the load/stores from/to *f .
> Basically the compiler is able to remove the use-after-scope usage with -O2
> and above.
Well, this makes sense to me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409
Sebastian Pop changed:
What|Removed |Added
CC||spop at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
Bug ID: 108647
Summary: [13 Regression] ICE in upper_bound, at
value-range.h:950 with -O3
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108645
--- Comment #1 from Evan Teran ---
To further experiment, i factored out `std::accumulate`:
```
#include
#include
#include
#include
void print_v(const char *rem, const std::vector ) {
std::cout << rem;
for (const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #7 from Hans-Peter Nilsson ---
(In reply to Hans-Peter Nilsson from comment #6)
> IMHO these tests and AFAICT the underlying issue has seen no attention for
> months and should be xfailed. On it...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108453
--- Comment #5 from CVS Commits ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:936fdf056944989c49dc4fff399ca5dc0d0213ee
commit r12-9101-g936fdf056944989c49dc4fff399ca5dc0d0213ee
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108646
Bug ID: 108646
Summary: nonnull attribute does not detect variables that are
NULL being passed
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108645
Bug ID: 108645
Summary: Change in behavior, std::accumulate doesn't always
work as expected in C++20 builds
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
--- Comment #2 from Mikael Pettersson ---
Happens with 11.3.0, 10.4.0, and 9.5.0 too, so shouldn't be related to the CC0
conversion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644
--- Comment #2 from Andrew Pinski ---
h8300.cc should be using HOST_WIDE_INT_PRINT_DEC instead.
Can you file that issue seperately?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644
--- Comment #1 from Andrew Pinski ---
The lto-plugin warnings are not a GCC issue really.
../../../gcc/lto-plugin/lto-plugin.c:501:19: warning: 'I' flag used with '%x'
gnu_printf format [-Wformat=]
Those are done correctly and using the right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255
Scott Boyce changed:
What|Removed |Added
CC||Boyce at engineer dot com
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644
Bug ID: 108644
Summary: Format string warnings related to longs under
MigW-W64/MSYS2 on Windows 10
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #10 from Jakub Jelinek ---
Ok then.
I won't test my patch then, the testcases from it were:
--- gcc/testsuite/gcc.c-torture/compile/pr108638.c.jj 2022-11-21
10:04:00.210677046 +0100
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108085
--- Comment #5 from Andrew Pinski ---
The difference between the two front-ends is at the original.
The C++ front-end adds a BLOCK around the loop while the C front-end does not.
This difference changes where the ASAN_MARK is placed with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
--- Comment #1 from Mikael Pettersson ---
I can reproduce. Doesn't happen with the m68k-linux-gnu target though.
> cross-m68k-uclinux/bin/m68k-unknown-uclinux-uclibc-gcc -Os -c /tmp/ls.i
during RTL pass: final
coreutils/ls.c: In function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108085
--- Comment #4 from Andrew Pinski ---
Hmm, using the C++ front-end, the use-after-scope still happens at -O3 but not
with the C front-end.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108637
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #9 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #8)
> (In reply to Aldy Hernandez from comment #5)
> > (In reply to Jakub Jelinek from comment #3)
> > > Created attachment 54391 [details]
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104866
--- Comment #4 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:502fd5575bfe0793ef4dc90dd714755e9878f308
commit r11-10497-g502fd5575bfe0793ef4dc90dd714755e9878f308
Author: Detlef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104866
Jonathan Wakely changed:
What|Removed |Added
Known to fail||11.1.0
Known to work|11.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #8 from Jakub Jelinek ---
(In reply to Aldy Hernandez from comment #5)
> (In reply to Jakub Jelinek from comment #3)
> > Created attachment 54391 [details]
> > gcc13-pr108639.patch
> >
> > Untested fix.
>
> I think the problem is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108641
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107574
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #7 from Aldy Hernandez ---
Jakub, take a look and see if you agree. I've fired off some tests.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #6 from Aldy Hernandez ---
Created attachment 54393
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54393=edit
untested patch for irange::operator==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
--- Comment #17 from dhekir at gmail dot com ---
To be honest, the "real" test case is very similar to the last one I sent: it's
a semi-generated code, with some initialization of the data in the beginning,
and then a lot of statements which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108636
Jonathan Wakely changed:
What|Removed |Added
Summary|C++20 undefined reference |[10/11/12 Regression] C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108642
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> Which of course is not documented ...
They are documented but not in a decent way:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108642
--- Comment #4 from David Spickett ---
Of course, I was just looking at at assembly output in compiler explorer and
then locally I didn't link the object. That's why it seemed to work.
Compiling and linking I get:
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108642
--- Comment #3 from Andrew Pinski ---
GCC has a builtin already for getting fpsr already too:
__builtin_aarch64_get_fpsr
Which of course is not documented ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108642
--- Comment #2 from Andrew Pinski ---
Note the ACLE does not require "fpsr" to be supported either only
"o0:op1:CRn:CRm:op2" format is listed there ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108642
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-02-02
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108643
Bug ID: 108643
Summary: Initializing parameter by ref in coroutine function
causes memory corruption
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108642
Bug ID: 108642
Summary: ACLE function __arm_wsr missing when compiling in C++
mode for AArch64
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108636
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:db8d6fc572ec316ccfcf70b1dffe3be0b1b37212
commit r13-5662-gdb8d6fc572ec316ccfcf70b1dffe3be0b1b37212
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512
Jason Merrill changed:
What|Removed |Added
Resolution|WORKSFORME |---
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108384
--- Comment #13 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611194.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106170
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107897
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104647
Andrew Pinski changed:
What|Removed |Added
Target Milestone|10.5|13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108638
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
Jakub Jelinek changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104647
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
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=108641
Bug ID: 108641
Summary: Hooking MS-MPI system into the NONMEM installation
failed
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
Jakub Jelinek changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108086
--- Comment #17 from CVS Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:cd41085a37b8288dbdfe0f81027ce04b978578f1
commit r13-5658-gcd41085a37b8288dbdfe0f81027ce04b978578f1
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108508
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:f4e1b46618ef3bd7933992ab79f663ab9112bb80
commit r13-5657-gf4e1b46618ef3bd7933992ab79f663ab9112bb80
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
Bug ID: 108640
Summary: ICE compiling busybox for m68k in change_address_1, at
emit-rtl.cc:2283
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
Jakub Jelinek changed:
What|Removed |Added
Version|unknown |13.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108626
--- Comment #8 from Marat Radchenko ---
Also, quote from C17 standard:
Like string literals, const-qualified compound literals can be placed into
read-only memory and *can even be shared*. (6.5.2.5 p 13).
/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
--with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.1 20230202 (experimental) [master r13-5642-g66d700af5bb] (GCC)
[539] %
[539] % gcctk -O1 small.c
small.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108633
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108633
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:d84dc419e692d42c3b1e0c82e972c8a6f4c71389
commit r13-5655-gd84dc419e692d42c3b1e0c82e972c8a6f4c71389
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
--- Comment #16 from Richard Biener ---
(In reply to Richard Biener from comment #14)
> Martin, can you look at the SRA issue? Do you want me to create a separate
> bugreport for this? The IL into SRA looks like
>
>:
> s2D.2755 = {};
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108636
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108638
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108638
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108636
--- Comment #1 from Jonathan Wakely ---
Trunk has some additional errors:
/usr/bin/ld: /tmp/ccXeUWH9.o: in function
`std::filesystem::__cxx11::directory_iterator::operator==(std::default_sentinel_t)
const':
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108626
--- Comment #7 from Marat Radchenko ---
While playing with it more, I found that clang behaves in a very strange way.
While they do combine `const char* const` + `const char[]`, the DO NOT combine
two `const char[]` together. I don't have any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108638
Bug ID: 108638
Summary: Another ice in decompose, at wide-int.h:984
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108484
--- Comment #7 from Sam James ---
Could you add 108463 to See Also? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108484
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1 - 100 of 143 matches
Mail list logo
