https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98776
Richard Earnshaw changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99836
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773
--- Comment #4 from Richard Earnshaw ---
(In reply to Christophe Lyon from comment #3)
> I tried changing TARGET_HARD_FLOAT_SUB in arm.h to:
> #define TARGET_HARD_FLOAT_SUB (arm_float_abi != ARM_FLOAT_ABI_SOFT\
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773
--- Comment #1 from Richard Earnshaw ---
-march=armv8.1-m.main+mve -mfloat-abi=hard should use the VFP registers for
passing any FP arguments so the build attribute for Tag_ABI_VFP_args should be
set to show that.
It's true that soft-float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99724
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2021-03-23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99551
--- Comment #1 from Richard Earnshaw ---
probably one of the if-conversion passes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99271
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99271
Richard Earnshaw changed:
What|Removed |Added
Summary|[10/11 regression] Wrong|[10 regression] Wrong code
||2021-02-25
Status|UNCONFIRMED |NEW
Priority|P3 |P1
Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
Target: arm
The code fragment:
typedef void (*f)(int) __attribute__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2021-01-29
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98681
--- Comment #5 from Richard Earnshaw ---
Patch looks generally sensible, but I think all the INTVALs in that expression
should be converted to UINTVAL. The mask, in particular, is unsigned and it is
weird that one moment we're using a unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98759
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94993
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95908
--- Comment #1 from Richard Earnshaw ---
I'm sure the code we generate doesn't match your expectations. What's more, I
don't think it's really practical to meet them.
To do so would require emitting a mask operation after practically every
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97534
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97534
--- Comment #5 from Richard Earnshaw ---
No, I don't think it's related to that, in fact, I think this is just a latent
bug that's been in the code for a long time.
At one point we have a 32-bit signed integer containing INT_MIN, which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
--- Comment #8 from Richard Earnshaw ---
(In reply to emilie.feral from comment #7)
> Hello,
> Any news on the subject?
> Would you advise in the meantime to discard the LTO (with the -fno-lto
> option) on the compilation unit containing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96939
--- Comment #6 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #4)
> Doesn't seem to be related to me, in the other PR everything is compiled
> with one set of options and no target attribute is involved either.
No, that's a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96939
--- Comment #5 from Richard Earnshaw ---
I batted my head against this when reworking the command line options stuff a
couple of years back, but the documentation on how the different hooks should
interact (especially for LTO and streaming) is,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
--- Comment #6 from Richard Earnshaw ---
Yes, the problem is related to returning values in memory and the ABI variants
we have. If we have hardware floating-point we generally use registers to
return values; if we don't, then we have to return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
Richard Earnshaw changed:
What|Removed |Added
Target||arm
--- Comment #4 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #3 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96768
--- Comment #3 from Richard Earnshaw ---
Note that the switch table is in the .rodata section, so that's not a problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96751
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2020-08-25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96313
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95676
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95651
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94995
Richard Earnshaw changed:
What|Removed |Added
Priority|P3 |P5
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95122
--- Comment #4 from Richard Earnshaw ---
Don't use -mhard-float or -msoft-float. Instead, you should be using
-mfloat-abi=[hard|softfp|soft] as appropriate. Also, rather than encoding this
into various sets of flags you should configure the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #14 from Richard Earnshaw ---
(In reply to Christophe Lyon from comment #13)
> But, in general (non-interrupt) code, what is supposed to happen if you
> compile for a d32 VFP and run on d16 one ? (and the code uses the extra
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #12 from Richard Earnshaw ---
(In reply to Christophe Lyon from comment #11)
> (In reply to Richard Earnshaw from comment #10)
> > (In reply to Christophe Lyon from comment #9)
> > > > My initial thoughts are along the lines of...
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #10 from Richard Earnshaw ---
(In reply to Christophe Lyon from comment #9)
> > My initial thoughts are along the lines of...
> > Only try to save FP registers that this function directly clobbers.
> What's the point of saving these
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #7 from Richard Earnshaw ---
well, __aeabi_memcpy is required not to clobber the FP state. Sadly, GCC does
not know about it...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #5 from Richard Earnshaw ---
This is made more complex due to the fact that the existence of the top 16 D
registers depends on the hardware you have, so saving them might require a d32
variant of the ISA, but we can't (quickly) tell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94763
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94748
--- Comment #1 from Richard Earnshaw ---
A BTI that's not immediately after a label looks wrong. Either it should be
removed entirely, or it should be merged with the preceding BTI.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2020-04-22
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
--- Comment #5 from Richard Earnshaw ---
(In reply to Richard Biener from comment #2)
> Note in another bug it was said that libgfortran requires a C99 runtime,
> when that's not available you should disable gfortran build. GCC (or
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
Richard Earnshaw changed:
What|Removed |Added
Resolution|FIXED |---
Summary|[8/9/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94502
Richard Earnshaw changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #7 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94220
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
|when optimizing for size|when optimizing for size
Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
--- Comment #1 from Richard Earnshaw ---
Mine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94236
--- Comment #8 from Richard Earnshaw ---
(In reply to Andrew Pinski from comment #6)
> Note for Threos OS, please don't reuse the same target triplet as elf or
> linux; use your own triplet. Also adding long calls is not hard and such.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94172
--- Comment #4 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #3)
> Can't reproduce on the trunk, neither on x86_64-linux with -Os -g3
> -fshort-enums, nor on arm-linux-gnueabi with -Os -g3 -fshort-enums
> -mcpu=cortex-m0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91913
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90311
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90311
--- Comment #11 from Richard Earnshaw ---
Looks like this was fixed with r10-1963. Testing that as a backport.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90311
--- Comment #10 from Richard Earnshaw ---
Initial commit in the series was r10-3970 but there were certainly follow-ups
after that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90311
Richard Earnshaw changed:
What|Removed |Added
Summary|[9/10 Regression] wrong |[9 Regression] wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90378
--- Comment #6 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #5)
> (In reply to Vladimir Makarov from comment #4)
> > > Miscompilation occurs in same configuration: arm-linux-gnueabihf at -O2
> > > -flto.
> > >
> >
> > I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90378
--- Comment #5 from Richard Earnshaw ---
(In reply to Vladimir Makarov from comment #4)
> > Miscompilation occurs in same configuration: arm-linux-gnueabihf at -O2
> > -flto.
> >
>
> I don't see how these two patches *directly* resulted in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #14 from Richard Earnshaw ---
With the simpler test case we see
Breakpoint 1, try_combine (i3=0x764d33c0, i2=0x764d3380, i1=0x0,
i0=0x0, new_direct_jump_p=0x7fffd850,
last_combined_insn=0x764d33c0)
at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
--- Comment #5 from Richard Earnshaw ---
I'm seeing it on AArch64 for master. Adding an enum value with an initializer
of -1 causes the problem to go away. So it looks like the 'unsigned'
conversion is happening too soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91913
--- Comment #4 from Richard Earnshaw ---
Main bug fixed with https://gcc.gnu.org/ml/gcc-cvs/2020-02/msg02312.html
Awaiting commit of testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548
--- Comment #11 from Richard Earnshaw ---
I don't think so, since the write back will update the timestamp. It would
only rerun it once per make anyway.
Also, the timestamp approach is really designed for files in the build area,
not those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548
Richard Earnshaw changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #7 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93548
Richard Earnshaw changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93235
Richard Earnshaw changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93341
--- Comment #5 from Richard Earnshaw ---
(In reply to Andrew Pinski from comment #3)
> /* We should be able to reverse all conditions. */
> gcc_assert (inv_cond_code != UNKNOWN);
>
> Obvious this code is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92071
--- Comment #7 from Richard Earnshaw ---
(In reply to Richard Biener from comment #6)
> Agreed. Did anybody bisect what caused this?
It only came to light when we added a check in the backend. So I'm not sure a
bisect will be that helpful,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93188
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93188
--- Comment #4 from Richard Earnshaw ---
Author: rearnsha
Date: Fri Jan 10 16:50:15 2020
New Revision: 280123
URL: https://gcc.gnu.org/viewcvs?rev=280123=gcc=rev
Log:
backport: arm: Fix rmprofile multilibs when architecture includes +mp or +sec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93188
Richard Earnshaw changed:
What|Removed |Added
Summary|[9/10-regression] a-profile |[9 regression] a-profile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93188
--- Comment #2 from Richard Earnshaw ---
Author: rearnsha
Date: Wed Jan 8 09:29:02 2020
New Revision: 279993
URL: https://gcc.gnu.org/viewcvs?rev=279993=gcc=rev
Log:
arm: Fix rmprofile multilibs when architecture includes +mp or +sec (PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93188
Richard Earnshaw changed:
What|Removed |Added
Target||arm
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93005
--- Comment #8 from Richard Earnshaw ---
(In reply to Joel Holdsworth from comment #7)
> > Did you test it with big-endian?
>
> Good question. It seems to do the right thing in both cases:
> https://godbolt.org/z/7rDzAm
foo2(long*,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93005
--- Comment #6 from Richard Earnshaw ---
(In reply to Joel Holdsworth from comment #5)
> I found that if I make modified versions of the intrinsics in arm_neon.h
> that are designed more along the lines of the x86_64 SSE intrinsics defined
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93119
--- Comment #3 from Richard Earnshaw ---
(In reply to Andrew Pinski from comment #2)
> Simplier patch, change PTR to P instead. Mine then.
>
> That is:
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36117
--- Comment #6 from Richard Earnshaw ---
Comment #5 was really for PR36177
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70786
--- Comment #9 from Richard Earnshaw ---
comment 8 should be for pr70876.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37377
--- Comment #17 from Richard Earnshaw ---
last patch was for pr37577.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92071
--- Comment #5 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #4)
> I'd say this should be fixed in the arm backend, instead of asserts it
> should check whether operands are aligned and if not, perform unaligned load
> or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314
--- Comment #28 from Richard Earnshaw ---
The last release of gcc-7 has now been made, so it's end-of-life and no further
fixes for it will be made.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92342
--- Comment #9 from Richard Earnshaw ---
(In reply to Segher Boessenkool from comment #7)
> I think the IF_THEN_ELSE version should be canonical, and it should be
> formed in simplify_rtx, not at random spots in combine.
Why? The and/ior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92342
--- Comment #6 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #5)
> So if the AND-based idiom is now preferred, shouldn't the if-then-else
> variant be transformed into it? Similarly for IOR, when we get
>
> (IOR (NEG ())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92342
--- Comment #5 from Richard Earnshaw ---
So if the AND-based idiom is now preferred, shouldn't the if-then-else variant
be transformed into it? Similarly for IOR, when we get
(IOR (NEG ()) (reg))
from
(IF_THEN_ELSE ()
(reg)
(const_int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92308
--- Comment #7 from Richard Earnshaw ---
Reload also had a hook TARGET_LEGITIMIZE_RELOAD_ADDRESS as well. But it had
the same problems - lack of context leading to guesswork and therefore too
local or too general fix-ups.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92308
--- Comment #6 from Richard Earnshaw ---
(In reply to rguent...@suse.de from comment #5)
> On Mon, 4 Nov 2019, rearnsha at gcc dot gnu.org wrote:
> I suspect TARGET_LEGITIMIZE_ADDRESS is only applied during
> reload/LRA, correct?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92308
--- Comment #4 from Richard Earnshaw ---
So taking the example I posted in the initial report and compiling with trunk
for arm -mcpu=cortex-m4 -mthumb -Os, we get:
ldr r3, .L2
movsr2, #1
str r2, [r3, #2060]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92308
--- Comment #2 from Richard Earnshaw ---
Very few micro-architectures would benefit from auto-inc style addressing in a
sequence like this. With modern super-scaler systems you want to use offset
addressing where possible (from a common base).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92281
--- Comment #5 from Richard Earnshaw ---
(In reply to Segher Boessenkool from comment #4)
> (In reply to Richard Earnshaw from comment #2)
> > Yes, but since
> > (A - B) - C = A - B - C = A - C - B = (A - C) - B
> > we can clearly swap the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294
--- Comment #1 from Richard Earnshaw ---
Things go wrong in the forward-prop 1 pass.
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
Consider this testcase which was mentioned in
https://gcc.gnu.org/ml/gcc-help/2019-10/msg00122.html.
#define BB_ADDRESS 0x43fe1800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92281
--- Comment #3 from Richard Earnshaw ---
As for 'special' regs and their ordering, I'm not sure. I would suggest that
if we have a commutative operation with two registers and one of the registers
is marked as a pointer, then it should appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92281
--- Comment #2 from Richard Earnshaw ---
(In reply to Segher Boessenkool from comment #1)
> (In reply to Richard Earnshaw from comment #0)
>
> > Failed to match this instruction:
> > (set (reg:SI 125 [+4 ])
> > (minus:SI (minus:SI (reg:SI
-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
Given:
t f1(t a, t b) { return a + ~b; }
if t is of type int64_t
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
CC: segher at kernel dot crashing.org
Target Milestone: ---
Here are two combine attempts from a simple testcase:
arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77882
--- Comment #5 from Richard Earnshaw ---
(In reply to Elad Lahav from comment #4)
> Created attachment 47119 [details]
> Proposed implementation of naked functions for aarch64
>
> The change is quite simple (see the proposed patch). I hope it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #63 from Richard Earnshaw ---
We need to reach closure on this, but there's nothing really concrete to make
such a decision. Which of the tests originally reported are still failing?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88656
Bug 88656 depends on bug 88167, which changed state.
Bug 88167 Summary: [7/8/9 regression] [ARM] Function __builtin_return_address
returns invalid address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167
Richard Earnshaw changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88656
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
301 - 400 of 1283 matches
Mail list logo
