https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120444
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a8c03f056f4070a618bc59afcae2290cf21456ea
commit r16-1069-ga8c03f056f4070a618bc59afcae2290cf21456ea
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119975
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Robert Dubner ---
> Rainer, I have no way of testing a build on a Mac.
>
> So, please, at your convenience, see if I eliminated this particular problem,
> and let
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116824
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120451
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |16.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120451
--- Comment #5 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:aa935ce40a777eb0b4a4d3d2e03cf2efb4cf9619
commit r16-1067-gaa935ce40a777eb0b4a4d3d2e03cf2efb4cf9619
Author: Andrew Pinski
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116824
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:4756557f5e3262f7f733f583bbbd69387fca8017
commit r16-1068-g4756557f5e3262f7f733f583bbbd69387fca8017
Author: Andrew Pinski
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101139
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116824
--- Comment #3 from Andrew Pinski ---
Patch for the testcase:
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685410.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116824
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120451
--- Comment #4 from Andrew Pinski ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685409.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120514
Bug ID: 120514
Summary: Build failure, possibly with C++
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120514
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-pc-linux-gnu
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120514
Andrew Pinski changed:
What|Removed |Added
Keywords||build
Component|c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118939
Alexandre Oliva changed:
What|Removed |Added
Summary|[14/15/16 Regression] ada: |[14/15 Regression] ada:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120424
--- Comment #6 from GCC Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:2edb50a310896da72710dba7724a3b4a541a1cbb
commit r16-1065-g2edb50a310896da72710dba7724a3b4a541a1cbb
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118939
--- Comment #25 from GCC Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:2edb50a310896da72710dba7724a3b4a541a1cbb
commit r16-1065-g2edb50a310896da72710dba7724a3b4a541a1cbb
Author: Alexandre Oliva
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #7 from Greg Chandler ---
Iterestingly the -plugin in the stack trace shouldn't be there
So trying the no-lto example, the trace behaves the same up to that point, then
switches to this:
access("/usr/lib/gcc/alpha-linux-gnu/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120451
--- Comment #3 from Andrew Pinski ---
Created attachment 61563
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61563&action=edit
Patch which I am testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #6 from Greg Chandler ---
I need to pour over this a bit too, but here is the stack trace for gcc:
fstat64(3, {st_mode=S_IFREG|0644, st_size=15611, ...}) = 0
mmap(NULL, 15611, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2034000
close(3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
--- Comment #14 from H.J. Lu ---
*** Bug 120504 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120504
H.J. Lu changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #8 from H.J. Lu ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #5 from Greg Chandler ---
I've also confirmed that this extends to the g++ binary as well and not just
gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #4 from Greg Chandler ---
I'm not sure if the -plugin error was a red-herring, I just tried this:
root@bigbang:/tmp# gcc -fno-lto 1.c
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> {heap 68
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-06-02
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #2 from Sam James ---
(In reply to Sam James from comment #1)
> Have you replaced your system native gcc with a cross compiler...?
Ah, nevermind this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #1 from Sam James ---
Have you replaced your system native gcc with a cross compiler...?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
Bug ID: 120513
Summary: Possible arch or configure issue
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: plugins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120511
--- Comment #7 from Chris Leonard ---
The function `process_init_element` in source file gcc/c/c-typeck.cc clears
`constructor_zeroinit` if `!integer_zerop (value.value)`.
The problem is triggered by using a floating-point type for the initial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48026
--- Comment #12 from Andrew Pinski ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685396.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120422
Robert Dubner changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120459
--- Comment #4 from Paul-Antoine Arras ---
Insn 2302 is folded into insn 1693 by apply_replacement() in haifa-sched.cc.
But it is not clear to me at which point insn 2302 should be elided.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120511
--- Comment #6 from Chris Leonard ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > >struct test t = {0};
> >
> > Stopped warning in GCC 5. So maybe this is just on accident.
>
> Looks like that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119975
Robert Dubner changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #3 from Robert Dubn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119975
--- Comment #2 from GCC Commits ---
The master branch has been updated by Robert Dubner :
https://gcc.gnu.org/g:8fc9e03a70fd08b54449b05833b00e7f8ad01c25
commit r16-1064-g8fc9e03a70fd08b54449b05833b00e7f8ad01c25
Author: Robert Dubner
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120512
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120511
--- Comment #2 from Chris Leonard ---
Note that the exact same code using an int instead of a double has no warning.
So either the code using int needs a warning, or this code needs no warning.
Elements in an array of structs should be initial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120511
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120509
Greg Chandler changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119695
James K. Lowden changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #4 from James K.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120511
--- Comment #4 from Andrew Pinski ---
>struct test t = {0};
Stopped warning in GCC 5. So maybe this is just on accident.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120511
--- Comment #3 from Chris Leonard ---
(In reply to Chris Leonard from comment #2)
> Note that the exact same code using an int instead of a double has no
> warning. So either the code using int needs a warning, or this code needs
> no warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120512
Bug ID: 120512
Summary: Wmissing-field-initializers mentions C++'s `{}` but
that is also valid for C23 too
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120511
--- Comment #1 from Andrew Pinski ---
I think this is on purpose, here there is an array, so the "universal zero
initializer" is not checked.
Note for C23, you could just use `{}` (the manual needs to be updated for
that).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120511
Bug ID: 120511
Summary: Initializer warning on universal zero initializer for
array element with double member
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120510
Bug ID: 120510
Summary: composite_type produces result not compatible with
arguments
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
--- Comment #13 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:3d287bff14885598c75c1cb16b08e0ba4ba05bce
commit r16-1063-g3d287bff14885598c75c1cb16b08e0ba4ba05bce
Author: Jason Merrill
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120509
--- Comment #6 from Andrew Pinski ---
(In reply to Greg Chandler from comment #5)
> Well, you definitely caught that one with the boostrap being added to
> configure when it wasn't supposed to. (staring at it too long to see it)
>
> So this isn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120509
--- Comment #5 from Greg Chandler ---
Well, you definitely caught that one with the boostrap being added to configure
when it wasn't supposed to. (staring at it too long to see it)
So this isn't a bug afterall, just a mistake on configure on my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120509
Bug ID: 120509
Summary: lto-plugin configure fails on cross compiler build
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120509
--- Comment #4 from Andrew Pinski ---
(In reply to Sam James from comment #1)
> Why are you passing --enable-bootstrap for a cross build?
That too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120509
--- Comment #2 from Greg Chandler ---
(squint) A 2nd pair of eyes always helps...
Let me go and remove that really quickly..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120509
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120509
--- Comment #1 from Sam James ---
Why are you passing --enable-bootstrap for a cross build?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120506
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120506
--- Comment #1 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:49f421a31f63405d3ca466e144d010c550206e72
commit r16-1061-g49f421a31f63405d3ca466e144d010c550206e72
Author: Jason Merrill
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120479
--- Comment #1 from Jeffrey A. Law ---
Paolo, good to hear from you :-)
I don't think that's directly possible.
; c from line (1) in a7; r+1 in t1
seqzt1,t1
and t3,a7,t1 ; t3 = (t1 == 0) ? 0 : a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120501
--- Comment #1 from James K. Lowden ---
fix pending in parser 3ac96109cd4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118903
--- Comment #6 from GCC Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:0ae77a05c416c9f750cb87f1bef0800651168b7e
commit r16-1059-g0ae77a05c416c9f750cb87f1bef0800651168b7e
Author: Iain Sandoe
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48026
--- Comment #11 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #10)
> Created attachment 61562 [details]
> Updated patch
>
> Updated patch with a fixed up changelog and added a generic testcase based
> on PR 118921's example.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48026
--- Comment #10 from Andrew Pinski ---
Created attachment 61562
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61562&action=edit
Updated patch
Updated patch with a fixed up changelog and added a generic testcase based on
PR 118921's exampl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
--- Comment #12 from Jonathan Wakely ---
These were working before, but fail after r16-1054
static_assert( __is_destructible(int&) );
static_assert( __is_destructible(int&&) );
static_assert( __is_destructible(int(&)[1]) );
static_assert( __is_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120508
Bug ID: 120508
Summary: Undefined symbols and relocation truncated to fit
IMAGE_REL_AMD64_ADDR32NB with large translation unit
making heavy use of templates with -O0
Produc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120386
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:ff2e49f444e851b005ba8abcf610a85bc1d7ae3a
commit r16-1056-gff2e49f444e851b005ba8abcf610a85bc1d7ae3a
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116892
--- Comment #7 from uecker at gcc dot gnu.org ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685350.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109345
Paul Thomas changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120444
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120123
Jason Merrill changed:
What|Removed |Added
Summary|[12/13/14/15/16 Regression] |[13 Regression] Implicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120123
--- Comment #9 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:6e10db3be0193514d8a67d1367d8fbe639e03b6a
commit r14-11823-g6e10db3be0193514d8a67d1367d8fbe639e03b6a
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120123
--- Comment #10 from GCC Commits ---
The releases/gcc-15 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:c096341a0809b322ece478f67c5d7be6923a0169
commit r15-9757-gc096341a0809b322ece478f67c5d7be6923a0169
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120444
--- Comment #1 from GCC Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:4e47e2f833732c5d9a3c3e69dc753f99b3a56737
commit r16-1055-g4e47e2f833732c5d9a3c3e69dc753f99b3a56737
Author: Tobias Burnus
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120504
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120123
--- Comment #8 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:8bdbd3b73464f7b12b7d31af91660381be2b5e17
commit r12-11123-g8bdbd3b73464f7b12b7d31af91660381be2b5e17
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
--- Comment #10 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:8a42538f9693a6608bb733860adec75a691f1940
commit r16-1053-g8a42538f9693a6608bb733860adec75a691f1940
Author: Jason Merrill
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
--- Comment #11 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:d7f33a35bffe7b331b0f8475e52c2dcc1c5d2ea8
commit r16-1054-gd7f33a35bffe7b331b0f8475e52c2dcc1c5d2ea8
Author: Jason Merrill
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120506
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
prefix=/repo/gcc-trunk//binary-trunk-20250602084730-r16-1047-gb0dc2324980bbb-checking-yes-rtl-df-extra-armv7a-hardfloat
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250602 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120506
Bug ID: 120506
Summary: [16 Regression] Missing reason for failed constinit
since r16-57
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120231
--- Comment #9 from Jakub Jelinek ---
Apparently we are missing range implementation of casts between different
floating point types as well.
Trying now:
--- gcc/range-op-mixed.h.jj 2025-05-20 08:14:06.520404648 +0200
+++ gcc/range-op-mixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
--- Comment #9 from Jason Merrill ---
Created attachment 61560
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61560&action=edit
regression fixes
Thanks, now testing these fixes for those three issues:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120502
Patrick Palka changed:
What|Removed |Added
Keywords|needs-bisection |
Summary|[15/16 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812
--- Comment #15 from Andreas Schwab ---
I would expect that LTO use the same machinery as the target attribute.
#pragma riscv intrinsic "vector"
int vl;
__attribute__((target("arch=+v"))) void v () { vl = __riscv_vsetvl_e8m8 (0); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119152
--- Comment #4 from GCC Commits ---
The master branch has been updated by Tomasz Kaminski :
https://gcc.gnu.org/g:a2e1c97205063d7550d9b9c32319715961abd73f
commit r16-1051-ga2e1c97205063d7550d9b9c32319715961abd73f
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119152
Tomasz Kamiński changed:
What|Removed |Added
CC||tkaminsk at gcc dot gnu.org
R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339
Bug 110339 depends on bug 119152, which changed state.
Bug 119152 Summary: [C++26] P3019R14 indirect and polymorphic: Vocabulary Types
for Composite Class Design
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119152
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
--- Comment #8 from Jonathan Wakely ---
And for this type but I haven't figured out why:
#include
static_assert( __is_destructible(std::error_category) );
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812
--- Comment #14 from Robin Dapp ---
I managed to have a look now but the whole builtin and LTO machinery is kind of
new to me.
As Andreas mentioned already the issue is that we do not register vector
builtins when the current target is !TARGET_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
--- Comment #7 from Jonathan Wakely ---
The new built-in seems wrong for function types:
static_assert( not __is_destructible(int()) );
static_assert( not __is_nothrow_destructible(int()) );
static_assert( not __is_trivially_destructible(int())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120447
--- Comment #10 from Jennifer Schmitz ---
No, please go ahead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120481
--- Comment #8 from Tomasz Kamiński ---
%D is also affected by %m and %d.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120447
--- Comment #9 from Richard Sandiford ---
I think the ICE is caused by a bad interaction between the AArch64 optimisation
and r16-718, which added more checks for paradoxical subregs. The testcase
works if r16-718 is reverted.
I think the shou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120481
--- Comment #7 from Tomasz Kamiński ---
I am going for '%H' meaning the value of hours unmodified. The '%I' and '%p'
will work in terms of 24hours.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120499
--- Comment #2 from Nathaniel Shead ---
The issue appears to be some confusion over which TU is reponsible for
instantiating the destructor of the existing specialisation 'vector': the
main file thinks that it's already been instantiated because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120447
--- Comment #8 from Richard Sandiford ---
I think we've already got the right condition for partial modes:
/* If the predicate in operands[2] is a patterned SVE PTRUE predicate
with patterns VL1, VL2, VL4, VL8, or VL16 and at most the bo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120481
--- Comment #6 from Jonathan Wakely ---
Ah yes, I thought hh_mm_ss handled times >24h differently, but I misremembered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120481
--- Comment #5 from Tomasz Kamiński ---
> I think it's fine for the output to be unspecified in that case, since it's
> not a meaningful time-of-day.
I do not think that 50h from midnight is unspecified time of day, is 2 am in
next two days. T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120447
--- Comment #7 from Jennifer Schmitz ---
Yes, since the original patch was intended to only apply the transformation for
full SVE data vector modes, I will fix the checks in
aarch64_expand_maskloadstore to exclude partial modes for now (currentl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120447
--- Comment #6 from Richard Sandiford ---
I think a paradoxical VNx4QI subreg of QI is logically ok, but I'd need to
think a bit more about what the exact conditions should be. I don't think we
should rush into an aarch64 workaround.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120193
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120447
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
1 - 100 of 116 matches
Mail list logo
