https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118835
--- Comment #5 from GCC Commits ---
The releases/gcc-12 branch has been updated by Stefan Schulze Frielinghaus
:
https://gcc.gnu.org/g:b27fa6a7ca86a9b885cb4dbe8a55991e7fb666f0
commit r12-10967-gb27fa6a7ca86a9b885cb4dbe8a55991e7fb666f0
Author:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118949
--- Comment #9 from Jeffrey A. Law ---
I'd kind of lean towards the scheduler to fix this up. I've got an old patch
that I put on ICE that might be helpful.
https://inbox.sourceware.org/gcc-patches/d59x71nu21wx.3ndzz35ya8...@gmail.com/T/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118986
--- Comment #9 from Marek Polacek ---
In cp_fold_r we have:
TARGET_EXPR >>>
so object=D.2701, and init is the expr_stmt. We unwrap the
EXPR_STMT/INIT_EXPR/TARGET_EXPR and end up evaluating the f1 call. f1 returns
c2; the type of D.2701
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118835
Stefan Schulze Frielinghaus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118739
--- Comment #17 from Uroš Bizjak ---
V2 patch at [1]:
[1] https://gcc.gnu.org/pipermail/gcc-patches/2025-February/676494.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118185
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108823
--- Comment #1 from Jonathan Wakely ---
So maybe something like:
--- a/libstdc++-v3/include/bits/ranges_algo.h
+++ b/libstdc++-v3/include/bits/ranges_algo.h
@@ -758,11 +758,21 @@ namespace ranges
_Out __result, _Fp __binary_op,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108823
--- Comment #2 from Jonathan Wakely ---
Is std::min(ranges::size(__r1), ranges::size(__r2)) safe? Probably not,
since we could have iota(0LL, LLONG_MAX) on a 32-bit host where size_t is
32-bit. So I suppose it should be uintmax_t instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108823
--- Comment #3 from Jonathan Wakely ---
Or decltype(ranges::size(r1) + ranges::size(r2)) ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119021
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118953
--- Comment #6 from Jakub Jelinek ---
I think the bug is in irange::union_bitmask
with *this
[irange] long long unsigned int [0, 0][17, 17][25, 25] MASK 0xc000
VALUE 0x2d
and r
[irange] long long unsigned int [0, 0]
r.m_bitmask is MA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118083
--- Comment #3 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:640697f7c2def415db81c84010ae25be0785d867
commit r15-7720-g640697f7c2def415db81c84010ae25be0785d867
Author: Patrick Palka
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118964
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119021
--- Comment #4 from Jakub Jelinek ---
(In reply to Vladimir Makarov from comment #3)
> (In reply to Jakub Jelinek from comment #2)
> > So, either remove that call too, or move it into lra_asm_insn_error before
> > the insn has been deleted. Vla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029
Jonathan Wakely changed:
What|Removed |Added
Keywords||ABI
--- Comment #2 from Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029
--- Comment #3 from Jonathan Wakely ---
The header has:
// For construction of filebuffers for cout, cin, cerr, clog et. al.
// When the init_priority attribute is usable, we do this initialization
// in the compiled library instead (src
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119021
--- Comment #3 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #2)
> So, either remove that call too, or move it into lra_asm_insn_error before
> the insn has been deleted. Vlad, I'll defer this to you.
Sorry for the issues w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116032
--- Comment #6 from Christophe Lyon ---
I mean in this case CONST_VECTOR already has a cost of 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119030
Marek Polacek changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119030
--- Comment #3 from Jakub Jelinek ---
Started with r15-7597-g3768bedf7b5fcdd63a18871ecfce665ae1b8d87e
static inline unsigned
foo (long long tag)
{
return tag & 0x8000;
}
static inline long long
bar (long long tag)
{
if (foo (tag))
retu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #11 from Vincent Lefèvre ---
(In reply to Alejandro Colomar from comment #10)
[about i + 1 == 0 instead of i == -1]
> But this causes readability issues. For error-handling, programmers are
> used to writing ==-1, and doing +1==0 wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jonathan Wakely ---
> Hmm, does this imply we should have a separate baseline files for those two
> configurations?
I'd rather not if it can somehow be avoided.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029
--- Comment #5 from Jakub Jelinek ---
Is _GLIBCXX_USE_INIT_PRIORITY_ATTRIBUTE defined on Solaris when using Solaris
ld and/or when using gld?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119030
Bug ID: 119030
Summary: 15 Regression wrong optimization
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119030
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #10 from Alejandro Colomar ---
(In reply to Vincent Lefèvre from comment #9)
> (In reply to Paul Eggert from comment #8)
> > (In reply to Jakub Jelinek from comment #4)
> > > just use ~(time_t)0 or similar.
> > That has a cast, and p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Jakub Jelinek ---
> Is _GLIBCXX_USE_INIT_PRIORITY_ATTRIBUTE defined on Solaris when using Solaris
> ld and/or when using gld?
On Solaris 11.4, it is always define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Jakub Jelinek ---
> Does it have in that case the desired effect? I mean, does Solaris dynamic
> linker complain with that
> __extension__ __asm (".globl _ZSt21io
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119032
Bug ID: 119032
Summary: Should using brace elison for designated initializer
be reminded under '-pedantic-errors'?
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116032
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #2 from Levi Zim ---
(In reply to Andrew Pinski from comment #1)
> Can you attach the preprocessed source for rust-lex.cc ?
Do you mean re-running the command that produces rust-lex.o but with
-save-temps?
> The big difference betw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118953
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119034
Bug ID: 119034
Summary: Nested using-declaration doesn't do ADL or uses wrong
associated namespace
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: rej
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119034
--- Comment #1 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> If the helper classes are written like this then all compilers are happy:
Actually that's not true, MSVC is still unhappy. I think the adl_func concept
is n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119034
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119034
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> This is odd, doing this:
> ```
> namespace foo
> {
> struct X { };
> void func(X) { }
> }
>
> namespace bar
> {
> int func() = delete;
> template
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #3 from Levi Zim ---
Weird. It seems that I cannot reproduce it outside of our packaging infra.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119033
Sam James changed:
What|Removed |Added
Summary|[13/14/15 regression] |[13/14/15 regression]
|Un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119034
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119033
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119033
--- Comment #2 from Andrew Pinski ---
(In reply to Sam James from comment #1)
> r13-469-g9a53101caadae1 but latent before I guess
No I think that kinda of introdued it, it simplified `((size_t)a == (size_t)b)
? b : a` into just `a`:
phiopt mat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
--- Comment #14 from Andrew Pinski ---
(In reply to avieira from comment #13)
>
> the VECTOR_CST just goes over the elements in the VECTOR_CST and calls this
> recursively, making the change:
> --- a/gcc/fold-const.cc
> +++ b/gcc/fold-const.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
--- Comment #13 from Hongtao Liu ---
(In reply to H.J. Lu from comment #11)
> Created attachment 60590 [details]
> A patch
>
> Can you try this on SPEC CPU?
No big impact for both O2 and Ofast on SPEC2017.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119013
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118442
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> That comes from flow_call_edges_add, see gimple_flow_call_edges_add in
> tree-cfg.cc
Reading the comments in gimple_flow_call_edges_add is interesting because i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118793
--- Comment #2 from urbanjost at comcast dot net ---
I can imagine that different parsing of the input might make this very
difficult but might also be very straight-forward so was hoping for the best.
With small inputs it is not too bad, but err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119021
--- Comment #6 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #4)
> Can't it just look at the present insn and if it is no longer asm but
> NOTE_INSN_DELETED, ignore it?
RA keep erroneous asm goto (for keeping CFG correctnes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119021
--- Comment #5 from GCC Commits ---
The master branch has been updated by Vladimir Makarov :
https://gcc.gnu.org/g:7ce3a8e872d945d537a7e7ba1bd3f45b1cf9a6d2
commit r15-7716-g7ce3a8e872d945d537a7e7ba1bd3f45b1cf9a6d2
Author: Vladimir N. Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318
--- Comment #16 from Martin Jambor ---
(In reply to Jan Hubicka from comment #13)
>
[...]
>
> Here are two calls to + and it is not clear which one triggers the ICE.
> However sum += e->count.ipa (); quite obviously preserves the fact that sum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118953
--- Comment #5 from Jakub Jelinek ---
So, I think this is incorrect handling of the masks/values during range union.
As written earlier, we have
# RANGE [irange] long long unsigned int [0, +INF] MASK 0xc000
VALUE 0x2d
_3 = _2 + 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119033
Bug ID: 119033
Summary: Unsafe FRE of pointer assignment
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112490
Chameleon changed:
What|Removed |Added
CC||gessos.paul at yahoo dot gr
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119002
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:40bf0770563501f4c6d7e92cdaa1fa361caa
commit r15-7717-g40bf0770563501f4c6d7e92cdaa1fa361caa
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114870
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8d22474af76a386eed488b3c66124134f0e41363
commit r15-7718-g8d22474af76a386eed488b3c66124134f0e41363
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119001
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ad2908ed4ec5eff3cad3fd142cde5c1fac4788e9
commit r15-7719-gad2908ed4ec5eff3cad3fd142cde5c1fac4788e9
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119001
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114870
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=119011
--- Comment #13 from Alejandro Colomar ---
(In reply to Paul Eggert from comment #12)
> Plus, i + 1 == 0 does not necessarily work if time_t is 'unsigned short'
> (yes that'd be really weird for time_t, but ISO C and POSIX allow it and
> I try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680
--- Comment #13 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #11)
> If we're discussing derived-type IO, then it is clear from
> Fortran 2023, 12.6.4.8.2, (see p. 255) that the unit number
> has the default integer kind wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #12 from Paul Eggert ---
On 2/26/25 07:29, vincent-gcc at vinc17 dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
>
> --- Comment #11 from Vincent Lefèvre ---
> (In reply to Alejandro Colomar from comment #10)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112490
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #14 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #4)
> If you want to compare against all ones time_t, just use ~(time_t)0 or
> similar.
This one is a bad idea as it may have issues with signed types (when not in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #15 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #14)
> (In reply to Jakub Jelinek from comment #4)
> > If you want to compare against all ones time_t, just use ~(time_t)0 or
> > similar.
>
> This one is a bad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112490
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=119033
Sam James changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67771
--- Comment #6 from John Paul Adrian Glaubitz ---
(In reply to Joseph S. Myers from comment #5)
> Various glibc functions work around this using FIX_INT_FP_CONVERT_ZERO, I
> suppose the new log10f implementation taken from CORE-MATH needs such a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
--- Comment #23 from Jerry DeLisle ---
I have modified gcc.texi here to yield, after make info, the following pasted
out of my terminal viewing with info:
‘-x LANGUAGE’
Specify explicitly the LANGUAGE for the following input files
(ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119020
Andrew Pinski changed:
What|Removed |Added
Keywords||accepts-invalid
--- Comment #1 from And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119020
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #9 from Jakub Jelinek ---
The reason for extended precision by default for _Float16 (and __bf16) on x86
(and most of other targets, I think RISC-V is an exception) is lack of hw
support, same reason as for i387 extended precision.
Ei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #10 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #9)
> The reason for extended precision by default for _Float16 (and __bf16) on
> x86 (and most of other targets, I think RISC-V is an exception) is lack of
> hw supp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108233
--- Comment #2 from GCC Commits ---
The master branch has been updated by Andre Vehreschild :
https://gcc.gnu.org/g:751b37047b2ad3a358d41ac792487b42430e9901
commit r15-7712-g751b37047b2ad3a358d41ac792487b42430e9901
Author: Andre Vehreschild
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119021
Bug ID: 119021
Summary: [15 Regression] RTL checking ICEs after r15-7700
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119015
--- Comment #3 from Adrian Bunk ---
(In reply to Richard Biener from comment #1)
> given -Os isn't affected this is likely triggered by inlining (-fno-inline
> brings down compile-time again).
I can confirm that this is the case on armhf (~ 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119027
Bug ID: 119027
Summary: Problem of 'case' statement not in switch statement
and maybe gcc 10 accepts invalid
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
Sam James changed:
What|Removed |Added
Keywords|needs-reduction |
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100795
Jonathan Wakely changed:
What|Removed |Added
CC||curdeius at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119022
康桓瑋 changed:
What|Removed |Added
CC||hewillk at gmail dot com
--- Comment #2 from 康桓瑋
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119022
--- Comment #3 from Jonathan Wakely ---
Yes, sorry, I was confusing 100070 with Bug 100795 (which depends on 100070).
100795 is about algorithms and already mentions inplace_merge.
*** This bug has been marked as a duplicate of bug 100795 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119022
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100070
Jonathan Wakely changed:
What|Removed |Added
CC||curdeius at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118185
--- Comment #3 from Jonathan Wakely ---
Can this be closed, or do we want to backport to gcc-13 still?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119028
Bug ID: 119028
Summary: Inconsistent behavior across optimization levels in
GCC 14.2.0
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100795
Jonathan Wakely changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118209
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119028
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119027
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106612
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2025-02-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105609
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119016
--- Comment #13 from Sam James ---
Mea culpa. I hope my ratio of valid bugs excuses it a bit ;)
Filed https://marc.info/?l=subversion-dev&m=174056933428992&w=2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119016
--- Comment #10 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #9)
> On Wed, 26 Feb 2025, tnfchris at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119016
> >
> > --- Comment #8 from Tamar Chri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119016
--- Comment #8 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #7)
> On Wed, 26 Feb 2025, tnfchris at gcc dot gnu.org wrote:
>
> > Because of the scalar code doing DI mode loads, and the misalignment being
> > HImode, I do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119016
--- Comment #9 from rguenther at suse dot de ---
On Wed, 26 Feb 2025, tnfchris at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119016
>
> --- Comment #8 from Tamar Christina ---
> (In reply to rguent...@suse.de from c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119016
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119016
--- Comment #7 from rguenther at suse dot de ---
On Wed, 26 Feb 2025, tnfchris at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119016
>
> --- Comment #6 from Tamar Christina ---
> At the start of the second iteration
1 - 100 of 153 matches
Mail list logo
