[Bug fortran/114859] [14/15 Regression] Seeing new segmentation fault in same_type_as since r14-9752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 --- Comment #12 from Jakub Jelinek --- There is still time, probably until Tuesday morning, so if it is committed say by Monday to trunk, it can be cherry-picked then. I'd prefer to see the whole patch before acking it for 14.1, possibly even build a test rpm which could verify if the package now works again.
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #15 from Jakub Jelinek ---
https://developer.arm.com/documentation/101028/0012/14--M-profile-Vector-Extension--MVE--intrinsics
suggests that it is a UB if all the bits for a single element aren't the same
(i.e. false is all 0s, true is all 1s aka -1, anything else UB).
So the testcase is invalid at runtime, right?
It probably shouldn't error because it can be in dead code, and it certainly
shouldn't ICE, it could emit __builtin_trap or it can just canonicalize it any
way it likes it.
Seems you are canonicalizing that to 1s, given the HW behavior I think it would
be more correct to canonicalize to -1s.
I think you could simply canonicalize on the CONST_INT, so
else if (VALID_MVE_PRED_MODE (mode))
{
if (CONST_INT_P (x) && (mode == V8BImode || mode == V4BImode))
{
/* In V8BI or V4BI each element has 2 or 4 bits, if those
bits aren't all the same, it is UB and gen_lowpart might
ICE. Canonicalize all the 2 or 4 bits to all ones if
any of them is non-zero. */
unsigned HOST_WIDE_INT xi = UINTVAL (xi);
xi |= ((xi & 0x) << 1) | ((xi & 0x) >> 1);
if (mode == V4BImode)
xi |= ((xi & 0x) << 2) | ((xi & 0x) >> 2);
x = gen_int_mode (xi, HImode);
}
else if (SUBREG_P (x))
/* gen_lowpart on a SUBREG can ICE. */
x = force_reg (GET_MODE (x), x);
x = gen_lowpart (mode, x);
}
[Bug fortran/114859] [14/15 Regression] Seeing new segmentation fault in same_type_as since r14-9752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 --- Comment #10 from Jakub Jelinek --- Ah, the following shows what is happening and shows similar IL changes in the *.optimized dump: module m1 type amg_d_base_solver_type contains procedure, pass(sv) :: free => amg_d_base_solver_free end type amg_d_base_solver_type interface subroutine amg_d_base_solver_free(sv,x) import :: amg_d_base_solver_type implicit none class(amg_d_base_solver_type), intent(inout) :: sv integer,intent(inout) :: x end subroutine amg_d_base_solver_free end interface end module m1 module m2 use m1 type amg_d_base_smoother_type class(amg_d_base_solver_type), allocatable :: sv contains procedure, pass(sm) :: free => amg_d_base_smoother_free end type amg_d_base_smoother_type interface subroutine amg_d_base_smoother_free(sm,x) import :: amg_d_base_smoother_type, amg_d_base_solver_type implicit none class(amg_d_base_smoother_type), intent(inout) :: sm integer,intent(inout) :: x end subroutine amg_d_base_smoother_free end interface end module m2 module m3 use m2 type amg_d_onelev_type class(amg_d_base_smoother_type), allocatable :: sm end type amg_d_onelev_type end module m3 subroutine foo (level, save1, info) use m1 use m2 use m3 type(amg_d_onelev_type), intent(inout) :: level class(amg_d_base_smoother_type), allocatable , intent(inout) :: save1 integer,intent(out) :: info info = 0 if (allocated(save1)) then call save1%free(info) if (info == 0) deallocate(save1,stat=info) if (info /= 0) return end if allocate(save1, mold=level%sm,stat=info) end subroutine
[Bug fortran/114859] [14/15 Regression] Seeing new segmentation fault in same_type_as since r14-9752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 --- Comment #9 from Jakub Jelinek --- I see there roughly module m1 type amg_d_base_solver_type contains procedure, pass(sv) :: apply_v => amg_d_base_solver_apply_vect procedure, pass(sv) :: apply_a => amg_d_base_solver_apply end type amg_d_base_solver_type interface subroutine amg_d_base_solver_apply_vect(alpha,sv,x) implicit none class(amg_d_base_solver_type), intent(inout) :: sv integer,intent(inout) :: x real,intent(in) :: alpha end subroutine amg_d_base_solver_apply_vect end interface interface subroutine amg_d_base_solver_apply(alpha,sv,x) implicit none class(amg_d_base_solver_type), intent(inout) :: sv integer,intent(inout) :: x real,intent(in) :: alpha end subroutine amg_d_base_solver_apply end interface end module m1 module m2 use m1 type amg_d_base_smoother_type class(amg_d_base_solver_type), allocatable :: sv contains procedure, pass(sm) :: apply_v => amg_d_base_smoother_apply_vect procedure, pass(sm) :: apply_a => amg_d_base_smoother_apply end type amg_d_base_smoother_type interface subroutine amg_d_base_smoother_apply_vect(alpha,sm,x) implicit none class(amg_s_base_smoother_type), intent(inout) :: sm integer,intent(inout) :: x real,intent(in) :: alpha end subroutine amg_d_base_smoother_apply_vect end interface interface subroutine amg_d_base_smoother_apply(alpha,sm,x) implicit none class(amg_s_base_smoother_type), intent(inout) :: sm integer,intent(inout) :: x real,intent(in) :: alpha end subroutine amg_d_base_smoother_apply end interface end module m2 subroutine foo (save1) use m1, m2 class(amg_d_base_smoother_type), allocatable , intent(inout) :: save1 allocate(save1) end subroutine except that this doesn't compile.
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #13 from Jakub Jelinek ---
(In reply to Christophe Lyon from comment #12)
> (In reply to Jakub Jelinek from comment #11)
> > So, tried this under the debugger. All VALID_MVE_PRED_MODE modes have the
> > same size, 2 bytes, so I'd go with
> > else if (VALID_MVE_PRED_MODE (mode))
> > {
> > /* unsigned short arguments to functions get promoted to int, undo
> > that. */
> > if (GET_MODE_SIZE (x) != GET_MODE_SIZE (HImode))
> > x = gen_lowpart (HImode, x);
> > if (GET_MODE (x) != mode)
> > {
> > /* Nested SUBREGs are invalid. */
> > if (SUBREG_P (x))
> > x = force_reg (GET_MODE (x), x);
> > x = lowpart_subreg (mode, x,
> > GET_MODE (x) == VOIDmode ? HImode : GET_MODE
> > (x));
>
> This still crashes with mode == V*BI, because we reach
> rtx_vector_builder::find_cached_value() where elt is not a supported
> constant.
Ah, I was testing just V16BImode and V8BImode, with V16BImode even just
gen_lowpart
on
(const_int -13108 [0x]) works and gives
(const_vector:V16BI [
(const_int 0 [0]) repeated x2
(const_int 1 [0x1]) repeated x2
(const_int 0 [0]) repeated x2
(const_int 1 [0x1]) repeated x2
(const_int 0 [0]) repeated x2
(const_int 1 [0x1]) repeated x2
(const_int 0 [0]) repeated x2
(const_int 1 [0x1]) repeated x2
])
while for V8BImode it gives
(const_vector:V8BI [
(const_int 0 [0])
(const_int -1 [0x])
(const_int 0 [0])
(const_int -1 [0x])
(const_int 0 [0])
(const_int -1 [0x])
(const_int 0 [0])
(const_int -1 [0x])
])
Now, the question is what these weird B2Imode and B4Imode modes are about.
Are they really 2bit and 4bit booleans, with 0 being false, some value (1 or
all ones?) true, everything else UB? Something else?
The 0x when it is 1 bit per element indeed is what the above V16BImode
CONST_VECTOR is, the 0x with 2 bits per element is 0 or -1 (but, shouldn't
that be UB?),
but with 0x with 4 bits per element it is element 0xc, that doesn't feel
right
for a boolean in any case.
native_decode_vector_rtx for the bool vectors does:
unsigned int bit_index = first_byte * BITS_PER_UNIT + i * elt_bits;
unsigned int byte_index = bit_index / BITS_PER_UNIT;
unsigned int lsb = bit_index % BITS_PER_UNIT;
unsigned int value = bytes[byte_index] >> lsb;
builder.quick_push (gen_int_mode (value, GET_MODE_INNER (mode)));
and kind of expects that gen_int_mode canonicalizes it to some boolean value
(apparently it can handle both all ones and 1 as true, but not other values).
93if (elt == const1_rtx)
94 return CONST1_RTX (m_mode);
95else if (elt == constm1_rtx)
96 return CONSTM1_RTX (m_mode);
97else if (elt == const0_rtx)
98 return CONST0_RTX (m_mode);
99else
100 gcc_unreachable ();
Guess you can get similar ICE for V8BImode if some 2 bit pair is 2 (3 and 1 are
considered true, one of them -1, another 1) and 0 is false;
and for V4BImode obviously far more invalid values.
If the CPU somehow canonicalizes, say any non-zero 2-bit pair (or 4-bit pair)
is considered true (or say decide just based on most significant or least
significant bit), then perhaps you need to do that canonicalization by hand.
[Bug fortran/114859] [14 Regression] Seeing new segmentation fault in same_type_as since r14-9752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 --- Comment #8 from Jakub Jelinek --- The upstream sources are: https://github.com/sfilippone/amg4psblas/archive/refs/tags/v1.1.2.tar.gz https://github.com/sfilippone/psblas3/archive/refs/tags/v3.8.1-2.tar.gz
[Bug fortran/114859] [14 Regression] Seeing new segmentation fault in same_type_as since r14-9752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 --- Comment #7 from Jakub Jelinek --- Created attachment 58047 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58047=edit pr114859-1.tar.xz Another module. Unfortunately, the last module is too large for the 1M limit. It can be grabbed from wget https://kojipkgs.fedoraproject.org/packages/psblas3/3.8.1/5.post2.fc40/x86_64/psblas3-openmpi-devel-3.8.1-5.post2.fc40.x86_64.rpm rpm2cpio psblas3-openmpi-devel-3.8.1-5.post2.fc40.x86_64.rpm | cpio -id it is the usr/lib64/gfortran/modules/openmpi/psblas3/psb_base_mod.mod file.
[Bug fortran/114859] [14 Regression] Seeing new segmentation fault in same_type_as since r14-9752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859
--- Comment #6 from Jakub Jelinek ---
Created attachment 58046
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58046=edit
pr114859.tar.xz
Testcase + one module.
I was using
./f951 -quiet -I . amg_d_hierarchy_bld.f90 -m64 -march=x86-64 -mtune=generic
-mno-omit-leaf-frame-pointer -O2 -fexceptions -fstack-protector-strong
-fno-asynchronous-unwind-tables -fstack-clash-protection -fcf-protection=full
-fno-omit-frame-pointer -fPIC -o amg_d_hierarchy_bld.s
-fdump-tree-{original,gimple}
[Bug fortran/114859] [14 Regression] Seeing new segmentation fault in same_type_as since r14-9752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||pault at gcc dot gnu.org
Priority|P3 |P2
Last reconfirmed||2024-04-26
Target Milestone|--- |14.0
Summary|Seeing new segmentation |[14 Regression] Seeing new
|fault in same_type_as |segmentation fault in
||same_type_as since r14-9752
--- Comment #5 from Jakub Jelinek ---
Bisection shows the only change on that CU in that range is
r14-9752-g35408b3669fac104cd380582b32e32c64a603d8b
and the changes are mostly in the save_smoothers subroutine.
diff -upb on the original dump between r14-9751 and r14-9752 is:
--- amg_d_hierarchy_bld.f90.005t.original_ 2024-04-26 12:41:01.40711
-0400
+++ amg_d_hierarchy_bld.f90.005t.original 2024-04-26 12:42:21.511060046
-0400
@@ -211,9 +211,6 @@ void restore_smoothers (struct amg_d_one
__attribute__((fn spec (". . w w w ")))
void save_smoothers (struct amg_d_onelev_type & restrict level, struct
__class_amg_d_base_smoother_mod_Amg_d_base_smoother_type_a & restrict save1,
struct __class_amg_d_base_smoother_mod_Amg_d_base_smoother_type_a & restrict
save2, integer(kind=4) & restrict info)
{
- {
-integer(kind=4) stat.18;
-
*info = 0;
if (save1->_data != 0B)
{
@@ -328,7 +325,6 @@ void save_smoothers (struct amg_d_onelev
}
if (__builtin_expect ((integer(kind=8)) (stat.18 != 0), 0, 44)) goto L.34;
(struct __vtype_amg_d_base_smoother_mod_Amg_d_base_smoother_type *)
save1->_vptr = (struct __vtype_amg_d_base_smoother_mod_Amg_d_base_smoother_type
*) level->sm._vptr;
-(void) __builtin_memcpy ((void *) save1->_data, (void *)
save1->_vptr->_def_init, (unsigned long) save1->_vptr->_size);
L.34:;
*info = stat.18;
if (*info == 0)
@@ -344,11 +340,11 @@ void save_smoothers (struct amg_d_onelev
}
}
L.36:;
-if (*info == 0 && level->sm2a._data != 0B)
- {
{
integer(kind=4) stat.21;
+if (*info == 0 && level->sm2a._data != 0B)
+ {
if (__builtin_expect ((integer(kind=8)) (save2->_data != 0B), 0,
45))
{
stat.21 = 5014;
@@ -364,7 +360,6 @@ void save_smoothers (struct amg_d_onelev
}
if (__builtin_expect ((integer(kind=8)) (stat.21 != 0), 0, 44)) goto
L.38;
(struct __vtype_amg_d_base_smoother_mod_Amg_d_base_smoother_type *)
save2->_vptr = (struct __vtype_amg_d_base_smoother_mod_Amg_d_base_smoother_type
*) level->sm2a._vptr;
- (void) __builtin_memcpy ((void *) save2->_data, (void *)
save2->_vptr->_def_init, (unsigned long) save2->_vptr->_size);
L.38:;
*info = stat.21;
if (*info == 0)
@@ -384,15 +379,13 @@ void save_smoothers (struct amg_d_onelev
}
L.37:;
return;
- }
}
__attribute__((fn spec (". . . . w ")))
void amg_d_hierarchy_bld (struct psb_dspmat_type & a, struct psb_desc_type &
desc_a, struct __class_amg_d_prec_type_Amg_dprec_type_t & prec, integer(kind=4)
& restrict info)
{
- static void restore_smoothers (struct amg_d_onelev_type &, struct
__class_amg_d_base_smoother_mod_Amg_d_base_smoother_type_a & restrict, struct
__class_amg_d_base_smoother_mod_Amg_d_base_smoother_type_a & restrict,
integer(kind=4) & restrict);
- static void save_smoothers (struct amg_d_onelev_type & restrict, struct
__class_amg_d_base_smoother_mod_Amg_d_base_smoother_type_a & restrict, struct
__class_amg_d_base_smoother_mod_Amg_d_base_smoother_type_a & restrict,
integer(kind=4) & restrict);
+ integer(kind=4) stat.18;
integer(kind=8) D.9689;
integer(kind=8) D.9690;
integer(kind=8) D.9691;
so guess the only significant change is the removal of the two __builtin_memcpy
calls.
[Bug fortran/114859] Seeing new segmentation fault in same_type_as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 --- Comment #4 from Jakub Jelinek --- LTO doesn't seem to make a difference. And without LTO bisection points at openmpi-build/amgprec/impl/amg_d_hierarchy_bld.o when this is compiled with r14-9704 even when all other sources are compiled with the newer compiler, the testcase works, while when this is compiled with r14-9924 and all other sources with the older compiler, it crashes.
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #11 from Jakub Jelinek ---
So, tried this under the debugger. All VALID_MVE_PRED_MODE modes have the same
size, 2 bytes, so I'd go with
else if (VALID_MVE_PRED_MODE (mode))
{
/* unsigned short arguments to functions get promoted to int, undo that.
*/
if (GET_MODE_SIZE (x) != GET_MODE_SIZE (HImode))
x = gen_lowpart (HImode, x);
if (GET_MODE (x) != mode)
{
/* Nested SUBREGs are invalid. */
if (SUBREG_P (x))
x = force_reg (GET_MODE (x), x);
x = lowpart_subreg (mode, x,
GET_MODE (x) == VOIDmode ? HImode : GET_MODE
(x));
}
}
It would surprise me if (subreg:V4BI (reg:SI 116 [ _3 ]) 0) gets through
validation given the differences in sizes, but if you really want to handle
that as before, then just:
else if (VALID_MVE_PRED_MODE (mode))
{
if (GET_CODE (x) == CONST_INT)
x = lowpart_subreg (mode, gen_lowpart (HImode, x), HImode);
else if (GET_MODE (x) != mode)
{
if (SUBREG_P (x))
x = force_reg (GET_MODE (x), x);
x = gen_lowpart (mode, x);
}
}
i.e. use lowpart_subreg on gen_lowpart on CONST_INTs (gen_lowpart effectively
does
lowpart_subreg (HImode, x, DImode) in that case), the force_reg case to avoid
ICEs if say (subreg:SI (reg:DI ...) 0) is passed and gen_lowpart as before.
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #10 from Jakub Jelinek --- (mode == HImode || mode == V16BImode) could be GET_MODE_SIZE (mode) == 2 too.
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #9 from Jakub Jelinek ---
(In reply to Christophe Lyon from comment #7)
> This fails because down the call chain from lowpart_subreg, we reach
> gcc_unreachable in rtx_vector_builder::find_cached_value because m_mode ==
> V4BImode (so is MODE_VECTOR_BOOL), but is not a valid expected boolean
> constant vector.
Ah, so the builtin prototype says the argument is unsigned short (or unsigned
char?)
but mode (as the insn predicate mode) is V*BImode in that case?
Then it would still be passed as SImode, so one would need
if (GET_MODE (x) == SImode || GET_MODE (x) == VOIDmode)
{
x = lowpart_subreg ((mode == HImode || mode == V16BImode) ? HImode :
QImode, x, SImode);
if (mode != HImode)
x = lowpart_subreg (mode, x, mode == V16BImode ? HImode : QImode);
}
Does that second lowpart_subreg create CONST_VECTOR you are looking for?
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #6 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #5)
> So (completely untested):
> --- gcc/config/arm/arm-mve-builtins.cc.jj 2024-03-19 09:51:05.203631194
> +0100
> +++ gcc/config/arm/arm-mve-builtins.cc2024-04-26 15:49:55.380344060
> +0200
> @@ -2100,7 +2100,12 @@ function_expander::add_input_operand (in
>mode = GET_MODE (x);
> }
>else if (VALID_MVE_PRED_MODE (mode))
> -x = gen_lowpart (mode, x);
> +{
> + if (mode == HImode && GET_MODE (x) != HImode)
> + /* GCC promotes QI/HImode arguments to int, undo that
> +here. */
> + x = lowpart_subreg (mode, x, SImode);
Perhaps even
else
gcc_assert (GET_MODE (x) == mode);
here?
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #5 from Jakub Jelinek ---
Guess the primary question is why there is the gen_lowpart call at all.
Is it that normally the mode of x is already right due to the prototypes of the
builtins, with the exception that gcc likes to promote QImode/HImode arguments
of calls to SImode, so is the intent in that case to just narrow down SImode
back to HImode (seems VALID_MVE_PRED_MODE is only true for HImode from scalar
MODE_INT modes)?
If so, best would be to limit the call to just that case.
So (completely untested):
--- gcc/config/arm/arm-mve-builtins.cc.jj 2024-03-19 09:51:05.203631194
+0100
+++ gcc/config/arm/arm-mve-builtins.cc 2024-04-26 15:49:55.380344060 +0200
@@ -2100,7 +2100,12 @@ function_expander::add_input_operand (in
mode = GET_MODE (x);
}
else if (VALID_MVE_PRED_MODE (mode))
-x = gen_lowpart (mode, x);
+{
+ if (mode == HImode && GET_MODE (x) != HImode)
+ /* GCC promotes QI/HImode arguments to int, undo that
+ here. */
+ x = lowpart_subreg (mode, x, SImode);
+}
m_ops.safe_grow (m_ops.length () + 1, true);
create_input_operand (_ops.last (), x, mode);
I'd hope if the argument is a vector mode x already has that mode...
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #4 from Jakub Jelinek --- (In reply to Christophe Lyon from comment #3) > lowpart_subreg does not work either. > > If we put the predicates in a variable in the testcase, then in > function_expander::add_input_operand() x is already a (subreg/s/v:HI (reg:SI > 116 [ _3 ]) 0) so taking gen_lowpart of that is OK (we just want HImode to > get the 16 bits of predicates). If x could be e.g. (subreg:SI (reg:DI ...) ...), then one needs to use for GET_CODE (x) == SUBREG && GET_MODE (x) != mode do a force_reg first. > But when predicates are passed as a constant as in the testcase, we have > x = (const_int -13108 [0x]) > and gen_lowpart (HImode, x) fails on that. Why doesn't lowpart_subreg (mode, x, GET_MODE (x) == VOIDmode ? DImode : GET_MODE (x)); work? I.e. for CONST_INTs assume it is some constant in a mode equal or wider than mode. Unless mode can be TImode or x can be __int128 constants, that is. > I'm trying an approach to convert the constant into a vector of constants > whose mode will V4BImode in this case.
[Bug c++/114456] [C++26] P0609R3 - Attributes for structured bindings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114456 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 58045 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58045=edit gcc15-pr114456.patch Untested implementation.
[Bug libgomp/113867] [14 Regression][OpenMP] Wrong code with mapping pointers in structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P2 --- Comment #6 from Jakub Jelinek --- Per IRC discussions downgrading this to P2, it isn't something used widely in real-world code and while we can get some partial fix soon, a full fix will take likely longer. If it is fixed relatively soon in stage1, we can consider backporting the non-risky parts of the fixes to 14.2.
[Bug middle-end/113724] [14 Regression][OpenMP] ICE (segfault) when mapping a struct in omp_gather_mapping_groups_1 since r14-6515
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P2 --- Comment #10 from Jakub Jelinek --- Per IRC discussions downgrading this to P2, it isn't something used widely in real-world code and while we can get some partial fix soon, a full fix will take likely longer. If it is fixed relatively soon in stage1, we can consider backporting the non-risky parts of the fixes to 14.2.
[Bug fortran/114859] Seeing new segmentation fault in same_type_as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 --- Comment #3 from Jakub Jelinek --- Oh, and start by disabling LTO and see if it makes a difference.
[Bug fortran/114859] Seeing new segmentation fault in same_type_as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 --- Comment #2 from Jakub Jelinek --- If it is Fortran FE, then the possible commits might be r14-9893 r14-9874 r14-9873 r14-9753 r14-9752 r14-9720 r14-9719 r14-9712 Anyway, best would be to try to compile the amg_d_jac_smoother_clone_settings.f90 CU with a different compiler from the rest and see whether that is what changes the testcase, or if not, bisect among *.o files in the package, the *.mod files should be hopefully compatible between the 2 compilers. And when a single CU is known to change the outcome, then bisect it with gcc revisions.
[Bug fortran/114859] Seeing new segmentation fault in same_type_as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The Fedora versions don't provide any information to upstream, 14.0.1-0.13.fc40 is r14-9704 and 14.0.1-0.15.fc40 is r14-9924
[Bug target/114861] LoongArch: ICE building the kernel with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- m for register_operand???
[Bug c++/114858] [11/12/13/14 regression] Compilation Hang and Excessive RAM Consumption in GCC with invalid input since r0-128725
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114858 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13/14 regression]|[11/12/13/14 regression] |Compilation Hang and|Compilation Hang and |Excessive RAM Consumption |Excessive RAM Consumption |in GCC with invalid input |in GCC with invalid input ||since r0-128725 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Seems it started to hang with r0-128725-g5d264d62dc6d381510bea36469d50175fa6a39c2 Before that commit it has been rejected with many errors.
[Bug lto/113208] [15 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|14.0|15.0 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[14 Regression] lto1: |[15 Regression] lto1: |error: Alias and target's |error: Alias and target's |comdat groups differs since |comdat groups differs since |r14-5979-g99d114c15523e0|r14-5979-g99d114c15523e0 --- Comment #35 from Jakub Jelinek --- Should be fixed for 14.1 now. Keeping it open to redo it in stage1 differently as discussed on the mailing list.
[Bug c++/111284] [11/12/13 Regression] Some passing-by-value parameters are mishandled since GCC 9, affecting libstdc++'s constexpr std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[11/12/13/14 Regression]|[11/12/13 Regression] Some |Some passing-by-value |passing-by-value parameters |parameters are mishandled |are mishandled since GCC 9, |since GCC 9, affecting |affecting libstdc++'s |libstdc++'s constexpr |constexpr std::string |std::string | Status|NEW |ASSIGNED --- Comment #11 from Jakub Jelinek --- Should be fixed on the trunk (upcoming 14.1).
[Bug fortran/114825] [11/12/13 Regression] Compiler error using gfortran and OpenMP since r5-1190
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13/14 Regression]|[11/12/13 Regression] |Compiler error using|Compiler error using |gfortran and OpenMP since |gfortran and OpenMP since |r5-1190 |r5-1190 --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug other/114738] [14 Regression] Default DOCUMENTATION_ROOT_URL vs. release branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114738 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug rtl-optimization/114828] [14 Regression] ICE on valid code at -O1 with "-ftree-pre -fselective-scheduling -fsel-sched-pipelining -fschedule-insns" on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114828 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Priority|P3 |P2
[Bug fortran/114825] [11/12/13/14 Regression] Compiler error using gfortran and OpenMP since r5-1190
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 58027 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58027=edit gcc14-pr114825.patch Untested fix.
[Bug c++/114834] New: nontstring attribute vs. references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114834 Bug ID: 114834 Summary: nontstring attribute vs. references Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- We currently allow the nonstring attribute just on pointers and arrays of char/signed char/unsigned char. Shouldn't we allow it also on references to those as well? What about arrays/pointers of std::byte (aka enumeral type with unsigned char as underlying type)?
[Bug rtl-optimization/114810] [14 Regression] internal compiler error: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with -m32 -msta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Jakub Jelinek --- Fixed.
[Bug fortran/114825] [11/12/13/14 Regression] Compiler error using gfortran and OpenMP since r5-1190
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825 --- Comment #3 from Jakub Jelinek --- Yes, and the reason for that is that while in subroutine pr114825(b) type t real, allocatable :: m(:) end type t type(t), allocatable, target :: b(:) type(t), pointer :: d !$omp parallel private(d) d => b(1) !$omp end parallel contains subroutine sub !d => b(1) end subroutine sub end subroutine pr114825 the d in the private clause is the VAR_DECL created by the Fortran FE with DECL_LANG_SPECIFIC, d in the private clause in the testcase without the d => b(1) commented out is a VAR_DECL created by tree-nested.cc: #5 0x0123a64b in build_decl (loc=21312, code=VAR_DECL, name=, type=) at ../../gcc/tree.cc:5379 #6 0x00f4f39e in get_local_debug_decl (info=0x3b871d0, decl=, field=) at ../../gcc/tree-nested.cc:1895 #7 0x00f504c9 in convert_local_omp_clauses (pclauses=0x7fffea134780, wi=0x7fffd9b0) at ../../gcc/tree-nested.cc:2157 Perhaps get_local_debug_decl should also copy DECL_LANG_SPECIFIC? Of course, perhaps it might need e.g. DECL_LANG_FLAG_* too. If decl in there is just a VAR_DECL, we might as well just copy_node it and tweak afterwards, but if it is e.g. a PARM_DECL, that wouldn't be possible.
[Bug fortran/114825] [11/12/13/14 Regression] Compiler error using gfortran and OpenMP since r5-1190
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-04-23 Priority|P3 |P2 Component|libgomp |fortran Ever confirmed|0 |1 Target Milestone|--- |11.5 CC||burnus at gcc dot gnu.org Summary|Compiler error using|[11/12/13/14 Regression] |gfortran and OpenMP |Compiler error using ||gfortran and OpenMP since ||r5-1190 --- Comment #1 from Jakub Jelinek --- Started with r5-1190-g92d28cbb59cc5a611af41342c5b224fbf779a44d Reduced testcase (just -fopenmp needed): subroutine pr114825(b) type t real, allocatable :: m(:) end type t type(t), allocatable, target :: b(:) type(t), pointer :: d !$omp parallel private(d) d => b(1) !$omp end parallel contains subroutine sub d => b(1) end subroutine sub end subroutine pr114825
[Bug rtl-optimization/114810] [14 Regression] internal compiler error: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with -m32 -msta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #13 from Jakub Jelinek --- Created attachment 58013 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58013=edit gcc14-pr114810.patch So like this? Tried hard to reduce the testcase, but it didn't progress at all, so at least tried manually using cvise's clex to rename tokens a little bit.
[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 --- Comment #42 from Jakub Jelinek --- (In reply to Дилян Палаузов from comment #40) > Or when is gcc-bootstrap true and target-libbacktrace-bootstrap false? Whenever --enable-bootstrap (explicitly or by default) and libbacktrace isn't needed by any of the target libraries which are bootstrapped.
[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 --- Comment #41 from Jakub Jelinek --- Fixed for 13.3 too.
[Bug c++/114572] [OpenMP] "internal compiler error: in assign_temp" with assignment operator and lastprivate clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114572 --- Comment #6 from Jakub Jelinek --- Fixed for 13.3 too.
[Bug libquadmath/114533] libquadmath: printf: fix misaligned access on args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533 --- Comment #14 from Jakub Jelinek --- Fixed for 13.3 too.
[Bug middle-end/114552] [13 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r13-990
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114552 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Fixed for 13.3 too.
[Bug c++/114580] Bogus warning on if constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114580 --- Comment #5 from Jakub Jelinek --- Fixed for 13.3 too.
[Bug tree-optimization/114566] [11/12 Regression] Misaligned vmovaps when compiling with stack-protector-strong for znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13 Regression] |[11/12 Regression] |Misaligned vmovaps when |Misaligned vmovaps when |compiling with |compiling with |stack-protector-strong for |stack-protector-strong for |znver4 |znver4 --- Comment #19 from Jakub Jelinek --- Fixed for 13.3 too.
[Bug middle-end/110027] [11/12 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13 regression] Stack |[11/12 regression] Stack |objects with extended |objects with extended |alignments (vectors etc)|alignments (vectors etc) |misaligned on |misaligned on |detect_stack_use_after_retu |detect_stack_use_after_retu |rn |rn --- Comment #25 from Jakub Jelinek --- Fixed for 13.3 too.
[Bug sanitizer/114687] [13 Regression] ICE: in edge_before_returns_twice_call, at gimple-iterator.cc:981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114687 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jakub Jelinek --- Fixed for 13.3 too.
[Bug c++/114634] [11/12 Regression] Crash Issue Encountered in GCC Compilation of Template Code with Aligned Attribute since r9-1745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114634 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13 Regression] Crash |[11/12 Regression] Crash |Issue Encountered in GCC|Issue Encountered in GCC |Compilation of Template |Compilation of Template |Code with Aligned Attribute |Code with Aligned Attribute |since r9-1745 |since r9-1745 --- Comment #7 from Jakub Jelinek --- Fixed for 13.3 too.
[Bug c++/114691] [11/12 Regression] Bogus ignoring loop annotation warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114691 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13 Regression] Bogus |[11/12 Regression] Bogus |ignoring loop annotation|ignoring loop annotation |warning |warning --- Comment #5 from Jakub Jelinek --- Fixed for 13.3 too.
[Bug sanitizer/114743] ICE in build_check_stmt at asan.cc:2707 while compiling gcc.dg/ubsan/pr112709-2.c with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114743 --- Comment #5 from Jakub Jelinek --- Fixed for 13.3 too.
[Bug middle-end/114753] from_chars aborts with -m32 -ftrapv when passed -9223372036854775808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753 --- Comment #11 from Jakub Jelinek --- Fixed for 13.3 too.
[Bug rtl-optimization/114768] Volatile reads can be optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768 --- Comment #11 from Jakub Jelinek --- Fixed for 13.3 too.
[Bug c/114780] Using C23 nullptr as sentinel gives missing sentinel warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114780 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed for 13.3 too.
[Bug ipa/114784] [14 Regression] Inlining fails for always_inline inheriting constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114784 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug rtl-optimization/114810] [14 Regression] internal compiler error: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with -m32 -msta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810 --- Comment #10 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #8) > So, given the known ia32 register starvation, can't we split that first > alternative to > =,r,o with "nox64" isa and =,r,ro with "x64" isa? Better make it a (define_mode_attr andn_ro [(DI "o") (TI "ro")]) and use instead of the first ro (or some better name).
[Bug rtl-optimization/114810] [14 Regression] internal compiler error: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with -m32 -msta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810 --- Comment #8 from Jakub Jelinek --- (In reply to Uroš Bizjak from comment #7) > (define_insn_and_split "*andn3_doubleword_bmi" > [(set (match_operand: 0 "register_operand" "=,r,r") > (and: > (not: (match_operand: 1 "register_operand" "r,0,r")) > (match_operand: 2 "nonimmediate_operand" "ro,ro,0"))) >(clobber (reg:CC FLAGS_REG))] > > where the problematic alternative (=,r,ro) allows a memory input in its > operand 2 constraint. The allocator could spill a DImode value to a stack in > advance and reload the value from the memory in this particular alternative. So, given the known ia32 register starvation, can't we split that first alternative to =,r,o with "nox64" isa and =,r,ro with "x64" isa?
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 66928, which changed state. Bug 66928 Summary: Typos in translatable strings https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66928 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug translation/66928] Typos in translatable strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66928 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Target Milestone|--- |13.0 Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- The subcomand part has been fixed in gcc 13 as PR109297 fix. The endianess and invokations ones in gcc 7 as PR79019 fix.
[Bug c/114808] Qualified void return type is not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114808 --- Comment #3 from Jakub Jelinek --- Oops, I'm blind.
[Bug c/114808] Qualified void return type is not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114808 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I don't see such a sentence in C++17 nor other C++ standards. All compilers I've tried accept it. On the other side, e.g. http://eel.is/c++draft/basic.fundamental#15 talks about functions returning cv void. Similarly http://eel.is/c++draft/stmt.return#2 And https://eel.is/c++draft/dcl.fct#14 explicitly says "The return type shall be a non-array object type, a reference type, or cv void." This is something that was earlier said in [expr.call]/3 (e.g. in C++17, [expr.call]/5 in C++20).
[Bug target/114810] [14 Regression] internal compiler error: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with -m32 -mstackrealign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |14.0 Priority|P3 |P1 CC||jakub at gcc dot gnu.org, ||uros at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started with r14-5109-ga291237b628f419d7f7ac264dd7b42947b565222 which means it was latent before. I need -m32 -mstackrealign -O2 -mbmi -fno-exceptions -fno-plt -fpie -march=x86-64 -w to reproduce.
[Bug target/114801] [14 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Perhaps use lowpart_subreg instead of gen_lowpart?
[Bug c++/114804] [11/12/13/14 Regression] rejects valid code since r11-6815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114804 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Target Milestone|--- |11.5 Last reconfirmed||2024-04-22 Priority|P3 |P2 Summary|rejects valid code |[11/12/13/14 Regression] ||rejects valid code since ||r11-6815 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started to be rejected with r11-6815-g79e1251b642db038df276153c9f2ec6b82e56162
[Bug tree-optimization/114787] [13/14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787 Jakub Jelinek changed: What|Removed |Added Priority|P2 |P1 --- Comment #12 from Jakub Jelinek --- I think this should be still P1, while with -fdump-tree-all-all it miscompiled the testcase already before, most users don't use those options, and on the trunk it is a regression with just -O1.
[Bug ipa/114643] [11/12/13/14 Regression] Call to a template function emitted but without the code for the template function itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114643 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Last reconfirmed||2024-04-22 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Priority|P3 |P2 --- Comment #5 from Jakub Jelinek --- Started with r8-6709-gb9aba9fde536dc3e0293653509f530322ee2753e
[Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants and floating-point constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- FLT_EVAL_METHOD = 0 is on some hw like the pre-SSE2 ia32 extremely expensive, far more so than even the very expensive -ffloat-store. That is certainly not a good default. Plus I'm afraid it would suffer from double rounding, unless the floating point state is switched each time one needs to perform some floating point instruction in a different precision. -fexcess-precision=fast is the old GCC behavior, which certainly doesn't evaluate everything in extended precision, any time anything needs to be spilled from i?87 FPU to memory it is rounded back to the declared precision.
[Bug tree-optimization/114799] [14 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85 with -O2 -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114799 --- Comment #5 from Jakub Jelinek --- _10 is created during pattern recognition: patt_10 = (unsigned short) y.0_1; #0 vect_convert_input (vinfo=0x3a883e0, stmt_info=0x3be5410, type=, unprom=0x7fffcc80, vectype=, subtype=optab_default) at ../../gcc/tree-vect-patterns.cc:926 #1 0x026dcede in vect_convert_inputs (vinfo=0x3a883e0, stmt_info=0x3be5410, n=2, result=0x7fffcc50, type=, unprom=0x7fffcc80, vectype=, subtype=optab_default) at ../../gcc/tree-vect-patterns.cc:977 #2 0x026e35f5 in vect_recog_over_widening_pattern (vinfo=0x3a883e0, last_stmt_info=0x3be5410, type_out=0x7fffce48) at ../../gcc/tree-vect-patterns.cc:3155 #3 0x026f250a in vect_pattern_recog_1 (vinfo=0x3a883e0, recog_func=0x385ae30 , stmt_info=0x3be5410) at ../../gcc/tree-vect-patterns.cc:7181 #4 0x026f29fb in vect_pattern_recog (vinfo=0x3a883e0) at ../../gcc/tree-vect-patterns.cc:7338 #5 0x011663ac in vect_slp_analyze_bb_1 (bb_vinfo=0x3a883e0, n_stmts=9, fatal=@0x7fffd2cb: false, Python Exception : There is no member or method named m_vecpfx. dataref_groups=0x7fffd760) at ../../gcc/tree-vect-slp.cc:7722 #6 0x011668b6 in vect_slp_region (bbs=..., datarefs=..., Python Exception : There is no member or method named m_vecpfx. dataref_groups=0x7fffd760, n_stmts=9, orig_loop=0x0) at ../../gcc/tree-vect-slp.cc:7831 #7 0x0116791f in vect_slp_bbs (bbs=..., orig_loop=0x0) at ../../gcc/tree-vect-slp.cc:8042 Unfortunately, I'm afraid I know next to nothing about SLP handling of patterns, just loop vectorization :(
[Bug ipa/114784] [14 Regression] Inlining fails for always_inline inheriting constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114784 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Created attachment 58006 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58006=edit gcc14-pr114784.patch Adjusted patch. maybe_clone_body currently copies DECL_DISREGARD_INLINE_LIMITS, DECL_DLLIMPORT_P and DECL_VISIBILITY*, should those be copied too? And shouldn't some from the above list be copied in both places?
[Bug tree-optimization/114787] [13/14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787
--- Comment #11 from Jakub Jelinek ---
Seems it is {,likely_}max_loop_iterations_int on the for (; i < 1; i++) loop
which matters (aka loop 3). Given the i = 0 right before it (guess csmith-ism,
don't see why it couldn't be in the for init expression) it estimates that it
loops once.
Then the copyprop2 pass removes the i++ latch and i <= 0 comparison in that
loop header, so from all I can see that loop disappears.
At profile_estimate time, we have loop 1 the b<=0 loop which iterates just once
and then loop 4 f<=0 nested in loop 3 i<=0 nested in loop 2 a>=0, the m loop
doesn't seem to be in loop structure maybe because of the goto into the loop.
After copyprop, the loop 1 b<=0 is gone and the i<=0 loop is as well, but not
in the loop structure, loop 3 in the loop structure (presumably with the cached
number of loop estimates) has the f<=0 header and loop 4 nested in it has a
header testing f<=0 too.
[Bug tree-optimization/114787] [13/14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787
--- Comment #9 from Jakub Jelinek ---
It is the
if (dump_file && (dump_flags & TDF_DETAILS)
&& max_loop_iterations_int (loop) >= 0)
{
fprintf (dump_file,
"Loop %d iterates at most %i times.\n", loop->num,
(int)max_loop_iterations_int (loop));
}
if (dump_file && (dump_flags & TDF_DETAILS)
&& likely_max_loop_iterations_int (loop) >= 0)
{
fprintf (dump_file, "Loop %d likely iterates at most %i times.\n",
loop->num, (int)likely_max_loop_iterations_int (loop));
}
cases which trigger the different code generation with
-fdump-tree-profile_estimate-details -O1, either of them; guess
max_loop_iterations_int and likely_max_loop_iterations_int cache the results
and while it doesn't change the IL from the profile_estimate pass, it changes
the behavior of the cunroll pass later on.
[Bug tree-optimization/114787] [13/14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787 --- Comment #8 from Jakub Jelinek --- Seems it is -fdump-tree-profile_estimate-details that changes the code generation.
[Bug tree-optimization/114787] [13/14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P2 Keywords|needs-bisection | --- Comment #7 from Jakub Jelinek --- With -fdump-tree-all-all it started with r13-3898-gaf96500eea72c674a5686b35c66202ef2bd9688f The assembly with r13-3897 is the same between -O1 and -O1 -fdump-tree-all-all, while with r13-3898 it is different and the testcase hangs.
[Bug rtl-optimization/114788] [13/14 Regression] ICE on valid code at -O{2,3} on x86_64-linux-gnu (during RTL pass: sched2): in move_exprs_to_boundary, at sel-sched.cc:5236
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114788
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-04-22
Target Milestone|--- |13.3
Priority|P3 |P2
Status|UNCONFIRMED |NEW
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
Summary|ICE on valid code at|[13/14 Regression] ICE on
|-O{2,3} on x86_64-linux-gnu |valid code at -O{2,3} on
|(during RTL pass: sched2): |x86_64-linux-gnu (during
|in move_exprs_to_boundary, |RTL pass: sched2): in
|at sel-sched.cc:5236|move_exprs_to_boundary, at
||sel-sched.cc:5236
--- Comment #1 from Jakub Jelinek ---
Started with r13-6945-g429a7a88438cc80e7c58d9f63d44838089899b12, so clearly
must have been latent before.
[Bug ipa/114790] [11/12/13/14 regression] ICE when building intel-compute-runtime (error: direct call to ... speculative call sequence has no speculative flag)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114790 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |11.5 Priority|P3 |P2 CC||jakub at gcc dot gnu.org
[Bug tree-optimization/114792] [14 Regression] ICE on valid code at -O1 with "-fno-tree-ccp -fno-tree-copy-prop" on x86_64-linux-gnu: in get_loop_body, at cfgloop.cc:903
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114792 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Priority|P3 |P1
[Bug tree-optimization/114793] [14 Regression] wrong code at -O1 with "-fschedule-insns2 -fselective-scheduling2" on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114793 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Priority|P3 |P2 Target Milestone|--- |14.0 --- Comment #4 from Jakub Jelinek --- I think sel-sched regressions don't need to be P1.
[Bug rtl-optimization/114796] [11/12/13/14 Regression] wrong code at -O2 with "-fno-tree-fre -fno-inline -fselective-scheduling2" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114796 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Priority|P3 |P2
[Bug tree-optimization/114799] [14 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85 with -O2 -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114799 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | Summary|[14 Regression] ICE: tree |[14 Regression] ICE: tree |check: expected class |check: expected class |'type', have 'exceptional' |'type', have 'exceptional' |(error_mark) in |(error_mark) in |useless_type_conversion_p, |useless_type_conversion_p, |at gimple-expr.cc:85 with |at gimple-expr.cc:85 with |-O2 -fno-vect-cost-model |-O2 -fno-vect-cost-model ||since r14-9316 CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Priority|P3 |P1 --- Comment #4 from Jakub Jelinek --- Started with r14-9316-g7890836de20912bd92afaf5abbeaf9d8c5b86542
[Bug tree-optimization/114787] [14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787 Jakub Jelinek changed: What|Removed |Added Version|unknown |14.0 Last reconfirmed||2024-04-20 CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |14.0 Status|UNCONFIRMED |NEW Summary|wrong code at -O1 on|[14 Regression] wrong code |x86_64-linux-gnu (the |at -O1 on x86_64-linux-gnu |generated code hangs) |(the generated code hangs) Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r14-7138-g05e8ef2a05b477589cae25af3311bad0f68a90fe
[Bug c/114780] Using C23 nullptr as sentinel gives missing sentinel warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114780 --- Comment #3 from Jakub Jelinek --- Fixed for 14.1 so far.
[Bug target/114783] [14 Regression] Equality compares of vector builtins spill one operand to the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114783 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #35 from Jakub Jelinek --- Fixed.
[Bug ipa/114784] [14 Regression] Inlining fails for always_inline inheriting constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114784 --- Comment #4 from Jakub Jelinek --- Guess DECL_UNINLINABLE, maybe DECL_PRESERVE_P, TREE_USED, maybe DECL_USER_ALIGN/DECL_ALIGN, maybe DECL_WEAK, maybe DECL_NO_INSTRUMENT_FUNCTION_ENTRY_EXIT, DECL_NO_LIMIT_STACK. TREE_READONLY, DECL_PURE_P, TREE_THIS_VOLATILE (for const, pure and noreturn attributes) probably makes no sense, DECL_IS_RETURNS_TWICE neither (returns_twice ctor?). What about TREE_NOTHROW? DECL_FUNCTION_SPECIFIC_OPTIMIZATION, DECL_FUNCTION_SPECIFIC_TARGET...
[Bug ipa/114784] [14 Regression] Inlining fails for always_inline inheriting constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114784
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #3 from Jakub Jelinek ---
In the debugger I see it is the missing DECL_DISREGARD_INLINE_LIMITS flag:
(gdb) p $1->function_decl.disregard_inline_limits
$3 = 0
(gdb) p $1->function_decl.declared_inline_flag
$4 = 1
(gdb) p lookup_attribute ("always_inline", $1->decl_common.attributes)
$5 = (tree_node *) 0x7fffea2e5ac8
(gdb) p debug_generic_stmt (decl_assembler_name ($1))
_ZN7VariantCI119VariantConstructorsIS_EEi
--- gcc/cp/method.cc.jj 2024-02-15 09:51:34.474065798 +0100
+++ gcc/cp/method.cc2024-04-19 22:36:06.432859471 +0200
@@ -3309,6 +3309,8 @@ implicitly_declare_fn (special_function_
constexpr_p = DECL_DECLARED_CONSTEXPR_P (inherited_ctor);
/* Also copy any attributes. */
DECL_ATTRIBUTES (fn) = clone_attrs (DECL_ATTRIBUTES (inherited_ctor));
+ DECL_DISREGARD_INLINE_LIMITS (fn)
+ = DECL_DISREGARD_INLINE_LIMITS (inherited_ctor);
}
/* Add the "this" parameter. */
fixes this, the question is what other flags remembered from attributes we
should copy.
[Bug ipa/114784] [14 Regression] Inlining fails for always_inline inheriting constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114784
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
CC||hubicka at gcc dot gnu.org,
||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-04-19
Target Milestone|--- |14.0
--- Comment #2 from Jakub Jelinek ---
Started with r14-2149-gabdf0b6cdff5783b97f35ad61ae31433f0569dfd
That said, if you just fix the warning (i.e. remove the UB from serenity_main
if it would ever return), then it compiles fine. Say by adding return 0;
statement.
But adding [[gnu::cold]] attribute to serenity_main makes it error again.
Honza, I thought always_inline should have precedence over decisions if it
inlines into cold code or not etc.?
Or maybe always_inline attribute is copied over to the inheriting constructors
but DECL_DISREGARD_INLINE_LIMITS is not?
template
struct VariantConstructors {
__attribute__((always_inline)) VariantConstructors(int t) {
base().set(t, {});
}
__attribute__((always_inline)) VariantConstructors(long long t) {
base().set(t, {});
}
Base base();
};
struct Variant : VariantConstructors {
using VariantConstructors::VariantConstructors;
__attribute__((always_inline)) Variant(long long v) : VariantConstructors(v)
{}
template void set(T &&, int);
char m_data;
};
struct ErrorOr {
ErrorOr(int v) : a(v) { }
ErrorOr(long long v) : a(v) { }
Variant a;
};
static ErrorOr run() {
ErrorOr x(0); // compiles with this line removed
ErrorOr y(0LL);
return 0;
}
[[gnu::cold]] int serenity_main() {
run();
return 0;
}
[Bug target/114783] [14 Regression] Equality compares of vector builtins spill one operand to the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114783 --- Comment #3 from Jakub Jelinek --- Created attachment 57991 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57991=edit gcc14-pr114783.patch Full untested patch.
[Bug target/114783] [14 Regression] Equality compares of vector builtins spill one operand to the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114783 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug target/114783] [14 Regression] Equality compares of vector builtins spill one operand to the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114783
--- Comment #2 from Jakub Jelinek ---
@@ -16831,7 +16882,7 @@ (define_insn "*avx2_eq3"
[(set (match_operand:VI_256 0 "register_operand" "=x")
(eq:VI_256
(match_operand:VI_256 1 "nonimmediate_operand" "%x")
- (match_operand:VI_256 2 "nonimmediate_operand" "xm")))]
+ (match_operand:VI_256 2 "nonimmediate_operand" "jm")))]
"TARGET_AVX2 && !(MEM_P (operands[1]) && MEM_P (operands[2]))"
"vpcmpeq\t{%2, %1, %0|%0, %1, %2}"
[(set_attr "type" "ssecmp")
That looks like it was supposed to be xjm.
[Bug target/114783] [14 Regression] Equality compares of vector builtins spill one operand to the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114783 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-04-19 CC||jakub at gcc dot gnu.org Target Milestone|--- |14.0 Ever confirmed|0 |1 Priority|P3 |P1 --- Comment #1 from Jakub Jelinek --- Started with r14-4459-gd77ee4a7f7a80596d91b53c06946ac215614e6c4 or so ( r14-4453-gccdc0f0fcf6f240d5c4f059e6f38547a0cca9723 still emitted the 13 code, and I don't have the revisions in between in the seed, maybe they failed to build?).
[Bug c++/114772] [13/14 Regression] pragma GCC target applied to earlier template function with __attribute__((warn_unused_result)) since r12-6904
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114772 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |13.3 Status|UNCONFIRMED |NEW Last reconfirmed||2024-04-19 Summary|pragma GCC target applied |[13/14 Regression] pragma |to earlier template |GCC target applied to |function with |earlier template function |__attribute__((warn_unused_ |with |result))|__attribute__((warn_unused_ ||result)) since r12-6904 --- Comment #2 from Jakub Jelinek --- Started with r12-6904-g66b86171188dcb61d2d0e0a4a98a7467e58a84a7
[Bug c/114780] Using C23 nullptr as sentinel gives missing sentinel warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114780 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 CC||jakub at gcc dot gnu.org Last reconfirmed||2024-04-19 --- Comment #1 from Jakub Jelinek --- Created attachment 57989 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57989=edit gcc14-pr114780.patch Untested fix.
[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779 --- Comment #5 from Jakub Jelinek --- It isn't about side-effects. It is about it having pointer type. If you change your testcase to uintptr_t psfr_int = (uintptr_t) psfr; if (! __builtin_constant_p (psfr_int)) then it will work. __builtin_constant_p ((uintptr_t) psfr) will not work though, because the folding strips casts and the POINTER_TYPE_P case triggers in that case as well. I am not sure it would be a good idea to change the __builtin_constant_p behavior at this point, a lot of code in the wild might depend on its current behavior.
[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
--- Comment #3 from Jakub Jelinek ---
But in that case the POINTER_TYPE_P case doesn't trigger, because it is
INTEGER_CST and
so
/* If we know this is a constant, emit the constant of one. */
if (CONSTANT_CLASS_P (arg)
|| (TREE_CODE (arg) == CONSTRUCTOR
&& TREE_CONSTANT (arg)))
return integer_one_node;
triggers first.
There is another case where the builtin can return true for a pointer, and that
is
when it is called with a string literal (__builtin_constant_p ("abcd")):
if (TREE_CODE (arg) == ADDR_EXPR)
{
tree op = TREE_OPERAND (arg, 0);
if (TREE_CODE (op) == STRING_CST
|| (TREE_CODE (op) == ARRAY_REF
&& integer_zerop (TREE_OPERAND (op, 1))
&& TREE_CODE (TREE_OPERAND (op, 0)) == STRING_CST))
return integer_one_node;
}
But if you use even in the same function
int volatile *psfr = SFR;
__builtin_constant_p (psfr)
it will fold to 0.
[Bug tree-optimization/114779] __builtin_constant_p does not work in inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- That has nothing to do with inline functions and everything to do with pointer arguments to __builtin_constant_p. The builtin behaved that way since at least 1998. The current version still has /* If this expression has side effects, show we don't know it to be a constant. Likewise if it's a pointer or aggregate type since in those case we only want literals, since those are only optimized when generating RTL, not later. And finally, if we are compiling an initializer, not code, we need to return a definite result now; there's not going to be any more optimization done. */ if (TREE_SIDE_EFFECTS (arg) || AGGREGATE_TYPE_P (TREE_TYPE (arg)) || POINTER_TYPE_P (TREE_TYPE (arg)) || cfun == 0 || folding_initializer || force_folding_builtin_constant_p) return integer_zero_node; What triggers here is the POINTER_TYPE_P (TREE_TYPE (arg)) case. So, the builtin is immediately folded into 0 in that case.
[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574 --- Comment #32 from Jakub Jelinek --- Ah, but get_alias_set has quite special handling of pointers, it finds the ultimately pointed type and uses TYPE_MAIN_VARIANT for it, so it actually ignores TYPE_CANONICAL of the pointer type itself for TYPE_ALIAS_SET decisions.
[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #31 from Jakub Jelinek ---
I've tried to construct a wrong-code testcase, but so far haven't been
successful.
In e.g.
struct S { int s; } s;
struct T { long l; } t;
const struct S *
foo (const struct S **p, const struct T **q)
{
*p =
*q =
return *p;
}
fre1 optimizes the return *p to return
So I've tried
[[gnu::always_inline]] static inline const void *
foo (void *x, bool y)
{
const struct S **p = (const struct S **) x;
struct S { int s; };
static struct S s;
if (y)
*p =
return *p;
}
[[gnu::always_inline]] static inline void
bar (void *x)
{
const struct S **q = (const struct S **) x;
struct S { int s; };
static struct S s;
*q =
}
const void *
baz (void *x, void *y)
{
foo (x, true);
bar (y);
return foo (x, false);
}
where without the posted patch I think the TYPE_CANONICAL on const struct S*
should be wrong in the bar function, but strangely we don't optimize it.
[Bug c++/114709] [12/13/14 Regression] Incorrect handling of inactive union member access via pointer to member in constant evaluated context since r12-6425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114709 Jakub Jelinek changed: What|Removed |Added Summary|[12/13/14 Regression] |[12/13/14 Regression] |Incorrect handling of |Incorrect handling of |inactive union member |inactive union member |access via pointer to |access via pointer to |member in constant |member in constant |evaluated context |evaluated context since ||r12-6425 CC||jakub at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Keywords|needs-bisection | --- Comment #2 from Jakub Jelinek --- This is accepted since r12-6425-gab36b554bd90e8db279d13b133369118814f13fb
[Bug tree-optimization/114769] [14 Regression] Suspicious code in vect_recog_sad_pattern() since r14-1832
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114769 Jakub Jelinek changed: What|Removed |Added Summary|[14 Regression] Suspicious |[14 Regression] Suspicious |code in |code in |vect_recog_sad_pattern()|vect_recog_sad_pattern() ||since r14-1832 CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Added in r14-1832-g710b8dec61a73cb
[Bug rtl-optimization/114768] Volatile reads can be optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jakub Jelinek --- Fixed for 14.1.
[Bug libgcc/114762] wrong code with _BitInt() division by "BITINT_NN_MIN"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114762 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug c/114773] Raw string literals are not supported in C89 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114773
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
-std=gnu89 is meant for really old programs, and the raw string literal support
changes behavior, so it isn't a pure extension on what wasn't valid before,
e.g. consider
#define R
#define b
const char * square(void) {
return R"(a"b"a)";
}
in -std=c89 or -std=gnu89 this is return "(aa)"; while in -std=gnu99 return
"a\"b\"a";
[Bug middle-end/113724] [14 Regression][OpenMP] ICE (segfault) when mapping a struct in omp_gather_mapping_groups_1 since r14-6515
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|[14 Regression][OpenMP] ICE |[14 Regression][OpenMP] ICE |(segfault) when mapping a |(segfault) when mapping a |struct in |struct in |omp_gather_mapping_groups_1 |omp_gather_mapping_groups_1 ||since r14-6515 --- Comment #9 from Jakub Jelinek --- ICE started with r14-6515-g5fdb150cd4bf8f2da335e3f5c3a17aafcbc66dbe
[Bug other/114738] [14 Regression] Default DOCUMENTATION_ROOT_URL vs. release branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114738 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P2 --- Comment #6 from Jakub Jelinek --- Keeping open for discussions on what to do on the release branches after the release, the release itself should be fine with the committed patch.
