https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Component|rtl-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114268
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105533
--- Comment #13 from David Binderman ---
Seems fixed to me.
I built a bootstrap with ASAN and UBSAN
for languages C, C++ and Fortran and changed the usual
-O2 for -O3 -march=znver3 and the bootstrap passed.
I hadn't realised a bootstrap was s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105533
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 105533, which changed state.
Bug 105533 Summary: UBSAN: gcc/expmed.cc:3272:26: runtime error: signed integer
overflow: -9223372036854775808 - 1 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114270
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113802
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:3ecc5071797c4ceb6da67a6c2b2527a046091de2
commit r14-9384-g3ecc5071797c4ceb6da67a6c2b2527a046091de2
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113918
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:05109b1bd5ef4ee9d78fe17d4563889694a26d05
commit r14-9385-g05109b1bd5ef4ee9d78fe17d4563889694a26d05
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #46 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a307a26e8b392ba65edfdae15489556b7701db81
commit r14-9387-ga307a26e8b392ba65edfdae15489556b7701db81
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114280
Bug ID: 114280
Summary: ASSOCIATE fails with inquiry references when selector
function not yet parsed.
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367
--- Comment #5 from René Rebe ---
latest version:
https://svn.exactcode.de/t2/trunk/package/develop/gcc/hotfix-g5-power4.patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113918
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113802
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114270
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #6 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114281
Bug ID: 114281
Summary: [14 Regression] Multiple 2-10% exec time regressions
of 465.tonto since r14-9193-ga0b1798042d033
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #9 from Uroš Bizjak ---
The offending insn is emitted in general_scalar_chain::convert_op due to
preloading, but I have no idea how EH should be adjusted. There is another
instance in timode_scalar_chain::convert_op.
emit_insn_befo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114281
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
--- Comment #2 from Xi Ruoyao ---
*** Bug 114281 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 114281, which changed state.
Bug 114281 Summary: [14 Regression] Multiple 2-10% exec time regressions of
465.tonto since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114281
What|Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #16 from Richard Biener ---
(In reply to Andrew Macleod from comment #12)
>
> all VRP passes are the same now. so just schedule EVRP. in theory, you
> could schedule the fast vrp pass I added, but its not heavily tested... but
> y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110826
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-03-08
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114281
--- Comment #2 from Filip Kastl ---
> Please don't open more tickets unless you are assuming they do *not* have the
> same cause.
Alright, noted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #10 from Richard Biener ---
The easiest fix would be to refuse applying STV to a insn that
can_throw_internal () (that's an insn that has associated EH info). Updating
in this case would require splitting the BB or at least moving t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #10 from Jonathan Wakely ---
GetSystemTimePreciseAsFileTime gives UTC, so would need adjustment for leap
seconds to turn it into a sys_time. That's doable though.
Alternatively, we could use it to implement a high performance
chrono:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #8)
> Is this still an issue in 2022?
>
> Using a mingw-w64 cross-compiler and running under Wine I get:
>
> CLOCK_REALTIME: 0,100
> CLOCK_MONOTONIC: 0,100
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #17 from Tamar Christina ---
> So doing in the vectorizer sth like the following should get us the best
> possible ranges? Ah, probably only global ranges since the SCEV query
> itself would still lack context sensitive info (but as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114277
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
--- Comment #3 from Richard Biener ---
good (base) vs. bad (peak) on Zen2 with -Ofast -march=native shows
Samples: 654K of event 'cycles', Event count (approx.): 743149709374
Overhead Samples Command Shared Object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240
--- Comment #6 from Jonathan Wakely ---
Actually the standard does support Howard's intended behaviour:
"If the parse fails to decode a valid date, is.setstate(ios_base::failbit) is
called and tp is not modified."
It says "date", not "time poi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114137
--- Comment #6 from Alexandre Oliva ---
Thanks for the report.
Something's very rotten here. cfrvisited is an automatic variable, why oh why
would we have GOTOFF unspecs for it?!?
I'd be interested in a preprocessed testcase that will trigger
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114074
--- Comment #10 from Richard Biener ---
Some thoughts on the CHREC folding, in the context of the many reported
optimization regressions.
We try to handle { a, +, b } * c as { a * c, +, b * c } and the issue is
cases of undefined overflow this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938
--- Comment #10 from Alexandre Oliva ---
Thanks, yeah, I can duplicate the problem using the original testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114279
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |13.3
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #12 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #10)
> GetSystemTimePreciseAsFileTime gives UTC, so would need adjustment for leap
> seconds to turn it into a sys_time. That's doable though.
Doable, but it woul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #9 from Chris Elrod ---
> Interestingly this seems to be only reproducible on Arch Linux. Other gcc
> 13.1.1 builds, Fedora for instance, seem to behave correctly.
I haven't tried that reproducer on Fedora with gcc 13.2.1, which c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114282
Bug ID: 114282
Summary: [OpenMP] Implicit mapping of function/procedure
pointers should use 'firstprivate'
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
--- Comment #4 from Richard Biener ---
The following is a C testcase for a case where ranges will not help:
void foo (int *a, long js, long je, long is, long ie, long ks, long ke, long
xi, long xj)
{
for (long j = js; j < je; ++j)
for (lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114278
--- Comment #1 from Jakub Jelinek ---
This is execute_update_addresses_taken trying to drop address taken from a
large/huge _BitInt variable and rewriting it back to SSA. That is undesirable
when
(cfun->curr_properties & PROP_gimple_lbitint) !=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307
--- Comment #7 from Raffael Casagrande ---
@Jonathan Wakely Thanks very much for the detailed analysis. But there is one
point which I don't understand:
> BUT, the self-referential pointer is set to the address of the range_ member
> before th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
Uroš Bizjak changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114283
Bug ID: 114283
Summary: [OpenMP] Dummy procedures/proc pointers and
'defaultmap', 'default', 'firstprivate' etc.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #12 from Richard Biener ---
(In reply to Uroš Bizjak from comment #11)
> (In reply to Richard Biener from comment #10)
> > The easiest fix would be to refuse applying STV to a insn that
> > can_throw_internal () (that's an insn that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114284
Bug ID: 114284
Summary: [14 Regression] arm: Load of volatile short gets
miscompiled (loaded twice)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #13 from Uroš Bizjak ---
(In reply to Richard Biener from comment #12)
> > But I think, we could do better. Adding CC.
>
> We sure could, but I doubt it's too important? Maybe for Go/Ada.
Preloading stuff is simply loading from t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114284
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
Richard Biener changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114278
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Eve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285
Bug ID: 114285
Summary: Use of uninitialized value when copying a struct field
by field
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
--- Comment #5 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:018ddc86b928514d7dfee024dcdeb204d5dcdd61
commit r14-9391-g018ddc86b928514d7dfee024dcdeb204d5dcdd61
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114074
--- Comment #11 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:018ddc86b928514d7dfee024dcdeb204d5dcdd61
commit r14-9391-g018ddc86b928514d7dfee024dcdeb204d5dcdd61
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 114269, which changed state.
Bug 114269 Summary: [14 Regression] Multiple 3-27% exec time regressions of
434.zeusmp since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
What|R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #13 from Vadim Zeitlin ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to Jonathan Wakely from comment #8)
> > Is this still an issue in 2022?
> >
> > Using a mingw-w64 cross-compiler and running under Wine I get:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114238
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 114238, which changed state.
Bug 114238 Summary: [14 regression] Multiple 554.roms_r run-time regressions
(4%-20%) since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114238
What|Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113996
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #18 from Richard Biener ---
r14-9391-g018ddc86b92851 doesn't seem to make a difference for this aarch64
IVOPTs case. It might be that tree-affine.cc needs similar handling. I'm
going to dig into that on Monday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285
--- Comment #1 from Richard Biener ---
Given GCC considers memory to be initialized when you write to it and
copying from A to B involves a write to B the uninit info would be lost if
A is uninitialized. So IMO it's reasonable to diagnose a cop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233
--- Comment #6 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8263a4b6505f84973c2ed2fb8d4f2036ca335ff3
commit r14-9392-g8263a4b6505f84973c2ed2fb8d4f2036ca335ff3
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #27 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8263a4b6505f84973c2ed2fb8d4f2036ca335ff3
commit r14-9392-g8263a4b6505f84973c2ed2fb8d4f2036ca335ff3
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109668
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:64273a7e6bd8ba60058174d147521dd65d705637
commit r14-9393-g64273a7e6bd8ba60058174d147521dd65d705637
Author: Sam James
Date: Fri M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307
--- Comment #8 from Jonathan Wakely ---
I explained this in PR 109945 comment 25
There is no guaranteed copy elision for objects with a trivial copy constructor
and trivial (or deleted) destructor. The compiler is allowed to make temporary
copi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114284
Jakub Jelinek changed:
What|Removed |Added
Summary|[14 Regression] arm: Load |[14 Regression] arm: Load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307
--- Comment #9 from Jonathan Wakely ---
Ironically, writing a user-provided (and so non-trivial) copy constructor which
fixes up the self-referential pointer (or iterator, in your case) will restore
guaranteed elision, and that copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #14 from Jonathan Wakely ---
Thanks!
So does that mean mingw-w64 fixed the issue by improving the resolution of
CLOCK_REALTIME?
In that case, this bug could be closed WORKSFORME.
Or maybe the testcase makes invalid assumptions and i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #15 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #14)
> Or maybe the testcase makes invalid assumptions and isn't really measuring
> what it thinks it's measuring?
e.g. maybe clock_getres says 100ns even though
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #7 from Robin Dapp ---
I built executables with and without the commit (-Ofast -march=znver4 -flto).
There is no difference so it must really be something that happens with PGO.
I'd really need access to a zen4 box or the pgo execut
cc-trunk//binary-trunk-r14-9382-20240308082802-g0bd04d9ae2d-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240308 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114287
Bug ID: 114287
Summary: [13.2.1 Regression] 416.gamess in SPEC CPU 2006
miscompiled
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802
--- Comment #8 from Martin Jambor ---
I have proposed an improved patch on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6r0gkzvi4@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114254
--- Comment #1 from Martin Jambor ---
I have proposed a patch on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6r0gkzvi4@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288
Bug ID: 114288
Summary: [14 regression] ICE when building binutils-2.41 on
hppa (extract_constrain_insn, at recog.cc:2713)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288
--- Comment #1 from Sam James ---
'gcc -c alpha.i -O2' is enough for me to reproduce.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113777
--- Comment #1 from Alexandre Oliva ---
Eric, I think this is yours.
It fails while trying to add a reversed version of the hbool type to the
context of the struct, but the struct doesn't have children yet, and
add_child_die_after requires the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114284
--- Comment #3 from Alex Coplan ---
I think this has been fixed by
r14-9379-ga0e945888d973fc1a4a9d2944aa7e96d2a4d7581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114284
--- Comment #4 from Jakub Jelinek ---
+propagating insn 6 into insn 8, replacing:
+(parallel [
+(set (reg:SI 114 [ ])
+(sign_extend:SI (subreg:HI (reg:SI 117 [ x ]) 0)))
+(clobber (scratch:SI))
+])
+successfully
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #16 from Vadim Zeitlin ---
(In reply to Jonathan Wakely from comment #15)
> (In reply to Jonathan Wakely from comment #14)
> > Or maybe the testcase makes invalid assumptions and isn't really measuring
> > what it thinks it's measurin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
--- Comment #16 from GCC Commits ---
The master branch has been updated by Wilco Dijkstra :
https://gcc.gnu.org/g:5119c7927c70b02ab9768b30f40564480f556432
commit r14-9394-g5119c7927c70b02ab9768b30f40564480f556432
Author: Wilco Dijkstra
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114284
--- Comment #5 from Jakub Jelinek ---
(In reply to Alex Coplan from comment #3)
> I think this has been fixed by
> r14-9379-ga0e945888d973fc1a4a9d2944aa7e96d2a4d7581
Maybe the volatile MEM case yes, but I don't see how it would avoid the
undesi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285
--- Comment #2 from David Malcolm ---
(In reply to Antoni from comment #0)
> Created attachment 57655 [details]
> Reproducer for the bug
[...]
> I tried to reproduce in C and I attached the reproducer.
Trunk with -fanalyzer: https://godbolt.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114275
--- Comment #3 from Patrick Palka ---
PR105320 seems similar.
Another maybe related testcase:
$ cat testcase.C
export module M;
template struct A {
template friend struct B;
};
A a;
template struct B { };
$ cat testcase.C | g++ -fmodules-ts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307
--- Comment #10 from Raffael Casagrande ---
(In reply to Jonathan Wakely from comment #9)
Thanks very much! I missed the part with the trivial copy constructor and
learned again an important lesson. That explains why it works when I defined
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114287
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114059
--- Comment #1 from Alexandre Oliva ---
ISTM that -fharden-control-flow-redundancy is only instrumental to trigger the
latent problem, but the real problem is in the back end: aarch64_restore_za
emits a aarch64_cbnedi1 unconditionally, but insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114286
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114280
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114278
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114275
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114274
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110540
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110538
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110503
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110502
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110458
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110414
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113790
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110361
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
CC|
1 - 100 of 222 matches
Mail list logo
