https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #19 from Segher Boessenkool ---
Documenting that GCC behaves differently is just documenting a bug :-(
It should not be hard to detect this and give an error somewhere?
Saying "the user did something wrong" is true of course, but th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #21 from Segher Boessenkool ---
register float foo asm ("xmm0") = 0.99f;
asm volatile("movl %0, %%r8d\n\t"
"vmcall\n\t"
:: "g" (foo));
The user said operands[0] should go i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #23 from Segher B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #27 from Segher Boessenkool ---
(In reply to Alexander Monakov from comment #24)
> Segher, did you really mean to mark the bug resolved/fixed?
No, if I did that, I have no idea how :-)
> Given that the only supported use of local re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #28 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #25)
> Even if we wanted to do something about it (which I disagree with, e.g.
> given that the implementation matches the documentation), you run into the
> prob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #29 from Segher Boessenkool ---
(In reply to Richard Biener from comment #26)
> So it would need to be diagnosed in the FE (only), making a + 0 valid and
> a not. Eh.
We do not *have* to diagnose anything, certainly not things that
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
When compiling something like
#define O +
long x4(long x, long a, long b, long c, long d) { return x O a O b O c O d; }
we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97784
--- Comment #2 from Segher Boessenkool ---
No, it is exactly the same with unsigned types :-(
Use -Dlong="unsigned long" or use #define O ^ (as in my original test).
I forgot about this signed thing, but it has nothing to do with it (that
ma
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
int isfinite(double x) { return __builtin_isfinite (x); }
int isinf(double x) { return __builtin_isinf (x); }
int isinf_sign(double x) { return __builtin_isinf_sign (x); }
int isnan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97784
--- Comment #6 from Segher Boessenkool ---
(In reply to Richard Biener from comment #3)
> There is targetm.sched.reassociation_width which specifies how re-assocation
> should make such sequence "wide".
Ah cool, thank you :-)
> Andrew is correc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97847
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #1 from Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97847
--- Comment #3 from Segher Boessenkool ---
I can now reproduce it, with a compiler built yesterday (previous was a
few days older), and -O0.
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97847
--- Comment #4 from Segher Boessenkool ---
This was caused (or exposed) by e3b3b59683c1:
commit e3b3b59683c1e7d31a9d313dd97394abebf644be
Author: Vladimir N. Makarov
Date: Fri Nov 13 12:45:59 2020 -0500
[PATCH] Implementation of asm goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97926
--- Comment #1 from Segher Boessenkool ---
Confirmed (needs -O0).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #15 from Segher Boessenkool ---
Why does that compiler default to -mcpu=power10?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #16 from Segher Boessenkool ---
Oh, it's a different testcase, in comment 6. Yeah a new PR would
have been better ;-/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97972
--- Comment #2 from Segher Boessenkool ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #19 from Segher Boessenkool ---
(In reply to Arseny Solokha from comment #17)
> (In reply to Segher Boessenkool from comment #16)
> > Oh, it's a different testcase, in comment 6. Yeah a new PR would
> > have been better ;-/
>
> Do y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #20 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #18)
> So why don't we default to the Altivec ABI with -m32 on cpus that have
> Altivec and VSX units???
History. I'm not sure all our ABIs are compatible with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97972
--- Comment #3 from Segher Boessenkool ---
#0 moving_insn_creates_bookkeeping_block_p (through_insn=0x3fffb5b23138,
insn=0x3fffb5b736c0) at /home/segher/src/gcc/gcc/sel-sched.c:2031
It crashes here because the insn is not in any BB; which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #23 from Segher Boessenkool ---
Changing the ABI (silently, even!) is never an expected thing. All of the
four 32-bit ABIs we support have an AltiVec variant that isn't fully
compatible to the non-AltiVec base variant. It would be a
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
/home/segher/src/gcc/gcc/testsuite/gcc.dg/pr97954.c: In function 'foo':
/home/segher/src/gcc/gcc/testsuite/gcc.dg/pr97954.c:12:1: error: too man
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98178
--- Comment #3 from Segher Boessenkool ---
Yup, this is true in general, we almost never say why we don't combine so
far. Patches welcome! (Make sure you use TDF_DETAILS for such prints).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98020
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #18 from Segher Boessenkool ---
Why is it correct to convert the double x to single precision here?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #20 from Segher Boessenkool ---
Yes, that is clear... But we have ***double*** x in that example even,
as the declared type of the parameter, so converting that to float is
almost certainly a bad idea?
|1
Status|UNCONFIRMED |NEW
CC||segher at gcc dot gnu.org
--- Comment #3 from Segher Boessenkool ---
At least as far back as GCC 5 we report D-L1 size 64kB (for most CPUs,
not just p9). Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
--- Comment #5 from Segher Boessenkool ---
So both the cache line size and the cache size are wrong for GCC 10
and before, but okay on trunk, on all compiler I tested (I tested on
Linux only so far).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
--- Comment #6 from Segher Boessenkool ---
(In reply to Fangrui Song from comment #5)
> Please read my first comment why copy relocs is a bad name.
Since I reply to some of that (namely, your argument 1)), you could assume I
have read your comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #4 from Segher Boessenkool ---
"m" is already handled differently for inline asm, so perhaps we can just
extend that? ("m" in machine descriptions is "m<>" in asm, for example).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #6 from Segher Boessenkool ---
You cannot look at the instruction, ever. The inline asm template is
just text, nothing else. You cannot assume it is valid instructions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #8 from Segher Boessenkool ---
Yes, "m" can not allow PC-relative, in inline asm (just think of all existing
code that uses "m").
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #11 from Segher Boessenkool ---
(In reply to Bill Schmidt from comment #10)
> But it seems we would also need a new constraint that does permit
> PC-relative addresses, since new code will/may not have a TOC.
How could that work? Yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98645
--- Comment #1 from Segher Boessenkool ---
(In reply to Michael Meissner from comment #0)
> I am tuning up the final patches for providing support to enable the PowerPC
> server compilers to change the default long double from using the IBM
> 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98643
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2021-01-13
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #16 from Segher Boessenkool ---
No, this cannot be fixed in this hook, or in any other hook. The compiler
can never see *at all* what instructions there are, the template is just a
piece of text to it (there could be assembler macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #17 from Segher Boessenkool ---
(What i was referring to in Comment 4 was asm_operand_ok in recog.c --
it may need some surgery if we need to hook into that).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
Segher Boessenkool changed:
What|Removed |Added
Priority|P1 |P4
--- Comment #3 from Segher Boess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #5 from Segher Boessenkool ---
The "warninb" says
warning: ‘void* memcpy(void*, const void*, long unsigned int)’ writing 32
bytes into a region of size 8 overflows the destination [-Wstringop-overflow=]
It says it is wrong, so it i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #4 from Segher Boessenkool ---
Are you sure that target is correct?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
Segher Boessenkool changed:
What|Removed |Added
CC||acsawdey at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #9 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #6)
> The warning often warns on dead code.
> But even if the warning is right, that doesn't make it ice-on-invalid-code.
> The code may have UB at runtime, but th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #10 from Segher Boessenkool ---
(And that new test case is full of obvious invalid code as well, fwiw.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
--- Comment #2 from Segher Boessenkool ---
Can't we use ".text%name" for -ffunction-sections, like we did originally,
in 1996? See cf4403481dd6. This does not conflict with other section
names, and does not have all the problems you get from do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #12 from Segher Boessenkool ---
for (long i; i != compress_n_blocks; ++i)
"i" is uninitialized; accessing it is UB. So this is ice-on-invalid.
I have no doubt there is an actual bug somewhere here. We just do not
have valid code y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #14 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #13)
> For UB at runtime, we can warn, but shouldn't error because the code might
> never be invoked at runtime.
As far as I can see at least the C standard disa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #16 from Segher Boessenkool ---
Needs -mcpu=power8. Confirmed with that (and the given options).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #17 from Segher Boessenkool ---
(In reply to jos...@codesourcery.com from comment #15)
> Only if the undefined behavior is a property of the program, or of all
> possible executions of the program, as opposed to a property of a
> pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #18 from Segher Boessenkool ---
Created attachment 49996
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49996&action=edit
Patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
Segher Boessenkool changed:
What|Removed |Added
Attachment #49996|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #19 from Segher Boessenkool ---
We cannot allow "m" to allow pcrel memory accesses, because most
existing inline assembler code will break then. So we then need
some way to tell the compiler that some instruction *does* allow
pcrel m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98092
--- Comment #3 from Segher Boessenkool ---
Created attachment 50040
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50040&action=edit
Patch
Patch in testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
--- Comment #6 from Segher Boessenkool ---
I was under the impression this unique section thing needed the trailing
dot thing. This probably is not true.
I still think the old "%" thing is much superior to the trailing dot thing,
but that then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
--- Comment #8 from Segher Boessenkool ---
I say nothing like that. I say that
.text.hot.
is nasty (is easily mistaken for .text.hot).
I also say that and that named-per-function sections are better as
.text%name
than as
.text.name
(just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960
--- Comment #26 from Segher Boessenkool ---
(In reply to Richard Biener from comment #23)
> (that combine number prevails on trunk as well, I can't spot any code
> that disables combine on large BBs so not sure what goes on here)
There is no suc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98210
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053
--- Comment #11 from Segher Boessenkool ---
Please open a separate bug for x86 problems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98093
--- Comment #6 from Segher Boessenkool ---
(In reply to Martin Liška from comment #5)
> It's fixed on master, can we close it now or do we need a backport to active
> branches?
If someone filled in the known-to-work / known-to-fail fields we wou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #22 from Segher Boessenkool ---
Don't replace the constraints. For one thing, this is very hard to do
correctly. Just make the "m" constraint not allow prefixed memory in
asms, like I said above. (So all "general_operand" even!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98952
--- Comment #2 from Segher Boessenkool ---
And after that it always copies r4 bytes, too (rounded down to a multiple
of four bytes).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986
--- Comment #2 from Segher Boessenkool ---
I agree it makes sense to have the one arm with vec_duplicate first in the
canonical order. Problem is that this is deep in the arms, but it can be
done of course.
Autogenerating part of combine? Nono
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041
--- Comment #4 from Segher Boessenkool ---
combine always asks recog(), so that must have said it is okay?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041
--- Comment #5 from Segher Boessenkool ---
(As Jakub said; I'm just slow).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #15 from Segher Boessenkool ---
(In reply to Will Schmidt from comment #14)
> The _restgpr* and _savegpr* functions are not referenced when the test is
> built at other optimization levels. (I've looked at disassembly from -O0 ..
> -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #16 from Segher Boessenkool ---
(In reply to Mark Wielaard from comment #13)
> ==25741== Use of uninitialised value of size 8
> ==25741==at 0x1504: main (pr9862.C:16)
r4 is argv here
>0x14f0 <+16>: ld r3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #23 from Segher Boessenkool ---
savegpr/restgpr are special ABI-defined functions that do not have all the same
ABI
calling conventions as normal functions. They indeed write into the parent's
frame
(red zone, in this case).
Maybe y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #24 from Segher Boessenkool ---
I do see the problems for savegpr/restgpr with that suggestion, but maybe
something
in that vein can be done.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986
--- Comment #5 from Segher Boessenkool ---
(In reply to rsand...@gcc.gnu.org from comment #3)
> FWIW, another similar thing I've wanted in the past is to try
> recognising multiple possible constants in an (and X (const_int N))
> when X is known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986
--- Comment #6 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #4)
> So this is where the "autogenerated" part comes in. We should have
> an idea what might be useful and what isn't even worth trying by
> looking at the m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041
--- Comment #7 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #6)
> The mma_assemble_pair/mma_assemble_acc patterns both generate lxv or lxvp
> at, which both use a DQ offset and we already have function to
> test for that.
|--- |INVALID
CC||segher at gcc dot gnu.org
--- Comment #1 from Segher Boessenkool ---
Because it would be incorrect? lhau is pre-modify (like all update
form instructions).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99048
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99048
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98468
--- Comment #3 from Segher Boessenkool ---
git tag -l 'releases*' --contains 8d2d39587d94
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=99068
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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 jus
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=98181
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93353
--- Comment #4 from Segher Boessenkool ---
I cannot get the reduced testcase to fail. Are any special options needed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99293
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93353
--- Comment #8 from Segher Boessenkool ---
(In reply to Arseny Solokha from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > I cannot get the reduced testcase to fail. Are any special options needed?
>
> If you've been asking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93353
--- Comment #9 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #7)
> if (low_int >= 0x8000 - extra)
> is not true and 0x7fff - -1 is 0x8000 (with UB on the compiler side).
These are HWIs, so there is no UB.
> B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
--- Comment #3 from Segher Boessenkool ---
Ah, thank you. Well except there is no keyword called that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100169
--- Comment #1 from Segher Boessenkool ---
The SMS pass is notorious for slight changes making its cost model decide
too do things the other way around. Is that what is happening here? Was
SMS' decision a good decision (or at least reasonable)
|--- |FIXED
Status|NEW |RESOLVED
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
--- Comment #16 from Segher Boessenkool ---
I overhauled the Power machine-specific constraints documentation in
e01975f97cbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100622
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100694
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2021-05-20
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100693
--- Comment #1 from Segher Boessenkool ---
Confirmed. The define_insn for it is for SImode only as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100693
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
See https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570728.html (needed to
resolve PR99888).
We need some new hook(s) and/or refactoring of the generic code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
2401 - 2500 of 3229 matches
Mail list logo
