[Bug target/101908] [12 regression] cray regression with -O2 -ftree-slp-vectorize compared to -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101908 --- Comment #48 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:e3174d6183e5c042e822d9feabb670235b737441 commit r12-7990-ge3174d6183e5c042e822d9feabb670235b737441 Author: liuhongt Date: Wed Mar 30 20:35:55 2022 +0800 Split vector load from parm_del to elemental loads to avoid STLF stalls. Since cfg is freed before machine_reorg, just do a rough calculation of the window according to the layout. Also according to an experiment on CLX, set window size to 64. Currently only handle V2DFmode load since it doesn't need any scratch registers, and it's sufficient to recover cray performance for -O2 compared to GCC11. gcc/ChangeLog: PR target/101908 * config/i386/i386.cc (ix86_split_stlf_stall_load): New function (ix86_reorg): Call ix86_split_stlf_stall_load. * config/i386/i386.opt (-param=x86-stlf-window-ninsns=): New param. gcc/testsuite/ChangeLog: * gcc.target/i386/pr101908-1.c: New test. * gcc.target/i386/pr101908-2.c: New test. * gcc.target/i386/pr101908-3.c: New test.
[Bug c/105156] No diagnostic for `enum { toobig = UINT_MAX }`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105156 --- Comment #4 from Keith Thompson --- OK, that explains the bug. It sounds like the code that suppresses warnings in system headers needs to be a bit more clever. Using UINT_MAX here isn't an error in the header.
[Bug c/105156] No diagnostic for `enum { toobig = UINT_MAX }`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105156 --- Comment #3 from Andrew Pinski --- Add -Wsystem-headers and you will get a warning.
[Bug c/105156] No diagnostic for `enum { toobig = UINT_MAX }`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105156
--- Comment #2 from Keith Thompson ---
Andrew, did you use "-std=c17 -pedantic-errors"? Both gcc and clang
correctly diagnose "enum { toobig = 0x7fff * 2U + 1U };".
I'm seeing weird behavior that I don't understand. Replacing the UINT_MAX
macro by its expansion seems to change the behavior. Perhaps I'm missing
something obvious?
$ gcc --version
gcc (GCC) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat -n c.c
1 #include
2 enum { toobig= (0x7fff * 2U + 1U) };
3 enum { toobigtoo = UINT_MAX };
$ gcc -std=c17 -pedantic-errors -c c.c
c.c:2:20: error: ISO C restricts enumerator values to range of ‘int’
[-Wpedantic]
2 | enum { toobig= (0x7fff * 2U + 1U) };
|^
$ gcc -E c.c | tail -n 6
enum { toobig = (0x7fff * 2U + 1U) };
enum { toobigtoo =
# 3 "c.c" 3 4
(0x7fff * 2U + 1U)
# 3 "c.c"
};
$
[Bug target/104894] [11/12 Regression] ICE with -fno-plt -mcpu=power10 on PowerPC64 LE Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894
--- Comment #8 from Peter Bergner ---
Sorry for the delay, but getting back to this now...
(In reply to Alan Modra from comment #6)
> What I should have said is that -mlongcall code is correct but is
> missing a sibcall optimisation. -fno-plt code (after removing the assert or
> using your patch) is incorrect. A direct call is wrong, because it may
> require a plt call stub. gcc ought to be producing an inline plt call.
First off, is it just me, or does the -fno-plt option seem to slow down
basically all function calls since it forces us to emit a call that uses an
inline plt? Even for functions that don't need it.
> Change the testcase to
>
> void foo();
>
> void bar() {
>foo();
>foo();
> }
>
> to see what I mean. The asm output is
[snip]
> That "b foo@notoc" ought to be
> pld 12,0(0),1
> .reloc .-8,R_PPC64_PLT_PCREL34_NOTOC,foo
> mtctr 12
> .reloc .-4,R_PPC64_PLTSEQ,foo
> .reloc .,R_PPC64_PLTCALL_NOTOC,foo
> bctr
Thanks for the education! The change below gives us that code sequence:
bar:
.LFB0:
.cfi_startproc
.localentry bar,1
mflr 0
std 0,16(1)
stdu 1,-96(1)
.cfi_def_cfa_offset 96
.cfi_offset 65, 16
pld 12,0(0),1
.reloc .-8,R_PPC64_PLT_PCREL34_NOTOC,foo
mtctr 12
.reloc .-4,R_PPC64_PLTSEQ,foo
.reloc .,R_PPC64_PLTCALL_NOTOC,foo
bctrl
pld 12,0(0),1
.reloc .-8,R_PPC64_PLT_PCREL34_NOTOC,foo
addi 1,1,96
.cfi_def_cfa_offset 0
mtctr 12
ld 0,16(1)
mtlr 0
.cfi_restore 65
bctr
How does this look now? I'll go ahead and regtest this.
diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index cb18db06a2d..e045657a2b0 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -25659,11 +25659,21 @@ rs6000_sibcall_aix (rtx value, rtx func_desc, rtx
tlsarg, rtx cookie)
rtx r12 = NULL_RTX;
rtx func_addr = func_desc;
- gcc_assert (INTVAL (cookie) == 0);
-
if (global_tlsarg)
tlsarg = global_tlsarg;
+ /* Handle longcall attributes. */
+ if ((INTVAL (cookie) & CALL_LONG) != 0
+ && GET_CODE (func_desc) == SYMBOL_REF)
+{
+ /* Only PCREL can do a sibling call to a longcall function,
+because we don't need to restore the TOC register. */
+ gcc_assert (rs6000_pcrel_p ());
+ func_desc = rs6000_longcall_ref (func_desc, tlsarg);
+}
+ else
+gcc_assert (INTVAL (cookie) == 0);
+
/* For ELFv2, r12 and CTR need to hold the function address
for an indirect call. */
if (GET_CODE (func_desc) != SYMBOL_REF && DEFAULT_ABI == ABI_ELFv2)
[Bug c/105156] No diagnostic for `enum { toobig = UINT_MAX }`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105156
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Andrew Pinski ---
No compiler (clang, GCC, MSVC and ICC[EDG in GCC comapatibility mode]) I tried
warns about this:
enum { toobig = 0x7fff * 2U + 1U };
[Bug c/105156] New: No diagnostic for `enum { toobig = UINT_MAX }`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105156
Bug ID: 105156
Summary: No diagnostic for `enum { toobig = UINT_MAX }`
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
Target Milestone: ---
Source file:
```
#include
enum { toobig = UINT_MAX };
```
gcc version 11.2.0 on Ubuntu 20.04.4, x86_64
INT_MAX is 2147483647
UINT_MAX is 4294967295
The C11 and C17 standards both have the following constraint in 6.7.2.2:
> The expression that defines the value of an enumeration constant shall
> be an integer constant expression that has a value representable as an int.
"gcc -std=c17 -pedantic-errors -c c.c" does not produce a diagnostic for the
above source file.
If I replace UINT_MAX by 4294967295 I get a correct diagnostic:
c.c:3:18: error: ISO C restricts enumerator values to range of ‘int’
[-Wpedantic]
3 | enum { toobig2 = 4294967295 };
|
"gcc -E" indicates that the macro UINT_MAX expands to (0x7fff * 2U + 1U)
[Bug libstdc++/103650] [9/10 Regression] libstdc++ headers defined LT_OBJDIR and STDC_HEADERS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103650 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Summary|[9/10/11 Regression]|[9/10 Regression] libstdc++ |libstdc++ headers defined |headers defined LT_OBJDIR |LT_OBJDIR and STDC_HEADERS |and STDC_HEADERS Last reconfirmed||2022-04-04
[Bug libstdc++/104542] make_obj_using_allocator and uninitialized_construct_using_allocator lack constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104542 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jonathan Wakely --- Fixed for 11.3
[Bug libstdc++/104098] [11 Regression] bits/stl_iterator.h fails to compile for __cplusplus > 201703L and with __cpp_concepts undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104098 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jonathan Wakely --- Fixed for 11.3
[Bug libstdc++/105027] Missing constraints on std::bit_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105027 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jonathan Wakely --- .
[Bug libstdc++/105027] Missing constraints on std::bit_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105027 --- Comment #6 from Jonathan Wakely --- Fixed for 11.3
[Bug fortran/91728] Accepts array with wrong shape in a structure constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91728 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #3 from anlauf at gcc dot gnu.org --- Should be fixed. Closing.
[Bug sanitizer/105155] New: -fsanitize=signed-integer-overflow failed to check an overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105155
Bug ID: 105155
Summary: -fsanitize=signed-integer-overflow failed to check an
overflow
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
For the following code, I was expecting the sanitizer to warn about the integer
overflow. I checked with clang's UBSAN, which would warn however.
$cat a.c
#include
int foo(int a) {
return INT_MAX + (a>0?1:-1);
}
int main() {
__builtin_printf("%d\n", foo(1));
}
$
$gcc -fsanitize=signed-integer-overflow -w -O0 a.c;./a.out
-2147483648
$
[Bug fortran/105152] [9/10/11/12 Regression] ICE in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.cc:5647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105152 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2022-04-04 Ever confirmed|0 |1 Priority|P3 |P4 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. Actually we fail to diagnose the mismatch between actual and formal args and accepts invalid code. Just remove the bind(c) attribute to f in z2.
[Bug libstdc++/105154] New: std::expected::swap missing reset _M_has_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105154
Bug ID: 105154
Summary: std::expected::swap missing reset _M_has_value
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
#include
#include
int main() {
std::expected v;
std::expected e(std::unexpect);
assert(v.has_value());
assert(!e.has_value());
v.swap(e);
assert(!v.has_value());
assert(e.has_value());
}
https://godbolt.org/z/qzofoqjzh
[Bug libstdc++/105153] New: wrong constraint in std::expected's constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105153
Bug ID: 105153
Summary: wrong constraint in std::expected's constructor
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
std/expected#L970:
template
requires is_void_v<_Tp>
&& is_constructible_v<_Er, const _Gr&>
&& (!__cons_from_expected<_Up, _Gr>)
constexpr explicit(!is_convertible_v<_Gr, _Er>)
expected(expected<_Up, _Gr>&& __x)
noexcept(is_nothrow_constructible_v<_Er, _Gr>)
: _M_void(), _M_has_value(__x._M_has_value)
{
if (!_M_has_value)
std::construct_at(__builtin_addressof(_M_unex),
std::move(__x)._M_unex);
}
Should be is_constructible_v<_Er, _Gr>.
#include
struct E {
E(int&&) = delete;
E(const int&);
};
int main() {
std::expected e(std::expected{});
}
https://godbolt.org/z/KGa4b7aYa
[Bug fortran/105138] [7,8,9,10,11,12,F95] Bogus error when function name does not shadow an intrinsic when RESULT clause is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED Keywords||rejects-valid, wrong-code --- Comment #11 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-April/057731.html
[Bug rtl-optimization/104985] [12 Regression] ICE: SIGSEGV in undo_to_marker / adjust_reg_mode with -Os -frounding-math since r12-4767-g81342e95827f77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104985 --- Comment #16 from Segher Boessenkool --- "machine_mode m" I understand of course. "rtx m" is something different :-) I didn't see the patch yet, sorry, will get to it later today.
[Bug rtl-optimization/104985] [12 Regression] ICE: SIGSEGV in undo_to_marker / adjust_reg_mode with -Os -frounding-math since r12-4767-g81342e95827f77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104985
--- Comment #15 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #14)
> Are you sure this only ever handles pseudos? It is completely broken if not.
Yes, I am.
All the 4 uses of SUBST_MODE look like:
if (regno < FIRST_PSEUDO_REGISTER)
newpat_dest = gen_rtx_REG (compare_mode, regno);
else
{
SUBST_MODE (regno_reg_rtx[regno], compare_mode);
newpat_dest = regno_reg_rtx[regno];
}
> Changing the mode of regno_reg_rtx[...] is always wrong, too.
>
> Patches 2 and 3 look better, but need a lot more explanation. What does "m"
> mean, to start with?
m stands for mode.
enum undo_kind { UNDO_RTX, UNDO_INT, UNDO_MODE, UNDO_LINKS };
...
union { rtx r; int i; machine_mode m; struct insn_link *l; } old_contents;
union { rtx *r; int *i; struct insn_link **l; } where;
There are 2 ways to look at those names, one is that they somehow describe
their type (but for where what they point to), the other is that it
sign the undo_kind (first letter after UNDO_ in lowercase).
In the latter case, UNDO_MODE was the only outlier that used where.r instead of
where.m.
Note, I've posted the patch (last version) to gcc-patches, so patch review can
happen there:
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592450.html
[Bug rtl-optimization/104985] [12 Regression] ICE: SIGSEGV in undo_to_marker / adjust_reg_mode with -Os -frounding-math since r12-4767-g81342e95827f77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104985 --- Comment #14 from Segher Boessenkool --- Are you sure this only ever handles pseudos? It is completely broken if not. Changing the mode of regno_reg_rtx[...] is always wrong, too. Patches 2 and 3 look better, but need a lot more explanation. What does "m" mean, to start with?
[Bug tree-optimization/105150] [9/10/11/12 Regression] ICE with -Ofast: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105150 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 52747 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52747=edit gcc12-pr105150.patch Untested fix.
[Bug ipa/103083] [10/11/12 Regression] Wrong code due to ipa-cp's bits value propagation since r10-5538-gc7ac9a0c7e3916f1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103083 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Martin Jambor : https://gcc.gnu.org/g:4f939ac1e295f38624c82fa75fa798e83d825232 commit r11-9775-g4f939ac1e295f38624c82fa75fa798e83d825232 Author: Martin Jambor Date: Mon Apr 4 19:31:42 2022 +0200 ipa: Careful processing ANCESTOR jump functions and NULL pointers (PR 103083) IPA_JF_ANCESTOR jump functions are constructed also when the formal parameter of the caller is first checked whether it is NULL and left as it is if it is NULL, to accommodate C++ casts to an ancestor class. The jump function type was invented for devirtualization and IPA-CP propagation of tree constants is also careful to apply it only to existing DECLs(*) but as PR 103083 shows, the part propagating "known bits" was not careful about this, which can lead to miscompilations. This patch introduces a flag to the ancestor jump functions which tells whether a NULL-check was elided when creating it and makes the bits propagation behave accordingly, masking any bits otherwise would be known to be one. This should safely preserve alignment info, which is the primary ifnormation that we keep in bits for pointers. (*) There still may remain problems when a DECL resides on address zero (with -fno-delete-null-pointer-checks ...I hope it cannot happen otherwise). I am looking into that now but I think it will be easier for everyone if I do so in a follow-up patch. gcc/ChangeLog: 2022-02-11 Martin Jambor PR ipa/103083 * ipa-prop.h (ipa_ancestor_jf_data): New flag keep_null; (ipa_get_jf_ancestor_keep_null): New function. * ipa-prop.c (ipa_set_ancestor_jf): Initialize keep_null field of the ancestor function. (compute_complex_assign_jump_func): Pass false to keep_null parameter of ipa_set_ancestor_jf. (compute_complex_ancestor_jump_func): Pass true to keep_null parameter of ipa_set_ancestor_jf. (update_jump_functions_after_inlining): Carry over keep_null from the original ancestor jump-function or merge them. (ipa_write_jump_function): Stream keep_null flag. (ipa_read_jump_function): Likewise. (ipa_print_node_jump_functions_for_edge): Print the new flag. * ipa-cp.c (class ipcp_bits_lattice): Make various getters const. New member function known_nonzero_p. (ipcp_bits_lattice::known_nonzero_p): New. (ipcp_bits_lattice::meet_with_1): New parameter drop_all_ones, observe it. (ipcp_bits_lattice::meet_with): Likewise. (propagate_bits_across_jump_function): Simplify. Pass true in drop_all_ones when it is necessary. (propagate_aggs_across_jump_function): Take care of keep_null flag. (ipa_get_jf_ancestor_result): Propagate NULL accross keep_null jump functions. gcc/testsuite/ChangeLog: 2021-11-25 Martin Jambor * gcc.dg/ipa/pr103083-1.c: New test. * gcc.dg/ipa/pr103083-2.c: Likewise. (cherry picked from commit 7ea3a73c195a79e6740ae594ee1a14c8bf7a938d)
[Bug tree-optimization/105150] [9/10/11/12 Regression] ICE with -Ofast: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105150 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2022-04-04 Ever confirmed|0 |1 CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |NEW Target Milestone|--- |9.5 Priority|P3 |P2 Component|c |tree-optimization --- Comment #1 from Jakub Jelinek --- Started with r6-4328-gc53233c660496efed5115ec1f30d3009ecf716d6
[Bug tree-optimization/105149] [9/10/11/12 Regression] ICE in verify_ssa, at tree-ssa.cc:1211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105149 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Last reconfirmed||2022-04-04 Component|c |tree-optimization Ever confirmed|0 |1 Priority|P3 |P2 Target Milestone|--- |9.5 Status|UNCONFIRMED |NEW --- Comment #1 from Jakub Jelinek --- Started with r6-91-gf8e89441bc5518f450b6511c59c17c837859d109
[Bug c/105148] [11/12 Regression] ICE in verify_use, at tree-ssa.cc:881
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105148 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2022-04-04 Status|UNCONFIRMED |ASSIGNED Priority|P3 |P2 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |11.3 CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Started with my r11-5444-ga3ebc13492ff238873f2c6a7a3e51abefec1d052 I'll have a look.
[Bug fortran/105152] New: [9/10/11/12 Regression] ICE in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.cc:5647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105152 Bug ID: 105152 Summary: [9/10/11/12 Regression] ICE in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.cc:5647 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r9 : $ cat z1.f90 program p use iso_c_binding type, bind(c) :: t integer(c_int) :: a end type interface function f(x) bind(c) result(z) import :: c_int, t type(t) :: x(:) integer(c_int) :: z end end interface class(*), allocatable :: y(:) n = f(y) end $ cat z2.f90 program p use iso_c_binding type, bind(c) :: t integer(c_int) :: a end type class(*), allocatable :: y(:) n = f(y) contains function f(x) bind(c) result(z) type(t) :: x(:) integer(c_int) :: z end end $ gfortran-8 -c z1.f90 $ $ gfortran-12-20220403 -c z1.f90 z1.f90:14:11: 14 |n = f(y) | 1 internal compiler error: in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.cc:5647 0x7e2e52 gfc_conv_gfc_desc_to_cfi_desc ../../gcc/fortran/trans-expr.cc:5647 0x7e7042 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.cc:6811 0x7dc7ba gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:9405 0x7edae1 gfc_trans_assignment_1 ../../gcc/fortran/trans-expr.cc:11693 0x7ab6c7 trans_code ../../gcc/fortran/trans.cc:1916 0x7d4b7e gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7654 0x75734e translate_all_program_units ../../gcc/fortran/parse.cc:6669 0x75734e gfc_parse_file() ../../gcc/fortran/parse.cc:6956 0x7a47df gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
[Bug c/105151] New: [12 Regression] ICE in gimple_range_global, at value-query.cc:424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105151
Bug ID: 105151
Summary: [12 Regression] ICE in gimple_range_global, at
value-query.cc:424
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20211121 and 20211128 :
$ cat z1.c
int __GIMPLE () foo ()
{
int _1;
return a_1(D);
}
$ gcc-12-20220403 -c z1.c -fgimple
z1.c: In function 'foo':
z1.c:4:10: error: anonymous SSA name cannot have default definition
4 | return a_1(D);
| ^~~
during GIMPLE pass: walloca
z1.c:1:17: internal compiler error: Segmentation fault
1 | int __GIMPLE () foo ()
| ^~~
0xe0a17f crash_signal
../../gcc/toplev.cc:322
0x1171d57 gimple_range_global(tree_node*)
../../gcc/value-query.cc:424
0x1bc9f4a ranger_cache::get_global_range(irange&, tree_node*) const
../../gcc/gimple-range-cache.cc:925
0x1bc5118 gimple_ranger::export_global_ranges()
../../gcc/gimple-range.cc:474
0x1c11061 pass_walloca::execute(function*)
../../gcc/gimple-ssa-warn-alloca.cc:381
[Bug c/105150] New: [9/10/11/12 Regression] ICE with -Ofast: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105150
Bug ID: 105150
Summary: [9/10/11/12 Regression] ICE with -Ofast: verify_gimple
failed
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to r6, at -Ofast :
$ cat z1.c
#define A(name) __typeof (__builtin_##name (0)) name (); \
float name##1 () { return !name (1); } \
double name##2 () { return name (1.0L); }
#define B(name) A(name) A(name##l)
B (sqrt)
$ gcc-5 -c z1.c -Ofast
$
$ gcc-12-20220403 -c z1.c -Ofast
z1.c: In function 'sqrt1':
z1.c:2:36: warning: 'sqrt' argument 1 type is 'int' where 'double' is expected
in a call to built-in function declared without prototype
[-Wbuiltin-declaration-mismatch]
2 | float name##1 () { return !name (1); } \
|^
z1.c:4:17: note: in expansion of macro 'A'
4 | #define B(name) A(name) A(name##l)
| ^
z1.c:5:1: note: in expansion of macro 'B'
5 | B (sqrt)
| ^
z1.c:5:4: note: built-in 'sqrt' declared here
5 | B (sqrt)
|^~~~
z1.c:1:49: note: in definition of macro 'A'
1 | #define A(name) __typeof (__builtin_##name (0)) name (); \
| ^~~~
z1.c:5:1: note: in expansion of macro 'B'
5 | B (sqrt)
| ^
z1.c: In function 'sqrt2':
z1.c:3:36: warning: 'sqrt' argument 1 type is 'long double' where 'double' is
expected in a call to built-in function declared without prototype
[-Wbuiltin-declaration-mismatch]
3 | double name##2 () { return name (1.0L); }
|^~~~
z1.c:4:17: note: in expansion of macro 'A'
4 | #define B(name) A(name) A(name##l)
| ^
z1.c:5:1: note: in expansion of macro 'B'
5 | B (sqrt)
| ^
z1.c:5:4: note: built-in 'sqrt' declared here
5 | B (sqrt)
|^~~~
z1.c:1:49: note: in definition of macro 'A'
1 | #define A(name) __typeof (__builtin_##name (0)) name (); \
| ^~~~
z1.c:5:1: note: in expansion of macro 'B'
5 | B (sqrt)
| ^
z1.c: In function 'sqrtl1':
z1.c:2:36: warning: 'sqrtl' argument 1 type is 'int' where 'long double' is
expected in a call to built-in function declared without prototype
[-Wbuiltin-declaration-mismatch]
2 | float name##1 () { return !name (1); } \
|^
z1.c:4:25: note: in expansion of macro 'A'
4 | #define B(name) A(name) A(name##l)
| ^
z1.c:5:1: note: in expansion of macro 'B'
5 | B (sqrt)
| ^
z1.c:5:4: note: built-in 'sqrtl' declared here
5 | B (sqrt)
|^~~~
z1.c:1:49: note: in definition of macro 'A'
1 | #define A(name) __typeof (__builtin_##name (0)) name (); \
| ^~~~
z1.c:5:1: note: in expansion of macro 'B'
5 | B (sqrt)
| ^
z1.c: In function 'sqrt1':
z1.c:5:4: error: mismatching comparison operand types
5 | B (sqrt)
|^~~~
z1.c:2:9: note: in definition of macro 'A'
2 | float name##1 () { return !name (1); } \
| ^~~~
z1.c:5:1: note: in expansion of macro 'B'
5 | B (sqrt)
| ^
int
double
if (1 == 0.0) goto ; else goto ;
z1.c:5:4: internal compiler error: 'verify_gimple' failed
5 | B (sqrt)
|^~~~
z1.c:2:9: note: in definition of macro 'A'
2 | float name##1 () { return !name (1); } \
| ^~~~
z1.c:5:1: note: in expansion of macro 'B'
5 | B (sqrt)
| ^
0xe5ecad verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.cc:5213
0xad1ac1 gimplify_body(tree_node*, bool)
../../gcc/gimplify.cc:16438
0xad1d67 gimplify_function_tree(tree_node*)
../../gcc/gimplify.cc:16509
0x8e2d87 cgraph_node::analyze()
../../gcc/cgraphunit.cc:675
0x8e6036 analyze_functions
../../gcc/cgraphunit.cc:1240
0x8e720d symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.cc:2500
[Bug c/105149] New: [9/10/11/12 Regression] ICE in verify_ssa, at tree-ssa.cc:1211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105149
Bug ID: 105149
Summary: [9/10/11/12 Regression] ICE in verify_ssa, at
tree-ssa.cc:1211
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to r6, at -O1+ :
(gcc configured with --enable-checking=yes)
$ cat z1.c
#include
void foo (int size, ...)
{
struct {} d;
va_list ap;
d = va_arg (ap, typeof(d)()) ();
}
$ gcc-5 -c z1.c -O2
$ gcc-12-20220403 -c z1.c
$
$ gcc-12-20220403 -c z1.c -O2
z1.c: In function 'foo':
z1.c:7:1: error: virtual definition of statement not up to date
7 | }
| ^
D.1987 = _1;
during GIMPLE pass: ssa
z1.c:7:1: internal compiler error: verify_ssa failed
0x10a33db verify_ssa(bool, bool)
../../gcc/tree-ssa.cc:1211
0xd01ea7 execute_function_todo
../../gcc/passes.cc:2092
0xd027f2 execute_todo
../../gcc/passes.cc:2139
[Bug c/105148] New: [11/12 Regression] ICE in verify_use, at tree-ssa.cc:881
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105148
Bug ID: 105148
Summary: [11/12 Regression] ICE in verify_use, at
tree-ssa.cc:881
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20201122 and 20201129, at -O2+ :
$ cat z1.c
extern int h (void);
extern int a[7][256];
static int f (int a[7][256], int n)
{
for (int i = 0; i < n; i++) {
int v = h(), a[1][i];
a[n][i] = 0;
}
}
int g (void)
{
return f (a, 5);
}
$ gcc-12-20220403 -c z1.c -O1
$
$ gcc-12-20220403 -c z1.c -O2
during GIMPLE pass: ivopts
z1.c: In function 'g':
z1.c:10:5: internal compiler error: Segmentation fault
10 | int g (void)
| ^
0xe0a17f crash_signal
../../gcc/toplev.cc:322
0x109ebab verify_use
../../gcc/tree-ssa.cc:881
0x10a3942 verify_ssa(bool, bool)
../../gcc/tree-ssa.cc:1164
0xd01ea7 execute_function_todo
../../gcc/passes.cc:2092
0xd027f2 execute_todo
../../gcc/passes.cc:2139
[Bug testsuite/105147] New: New test case gcc.dg/pr105140.c introduced in r12-7979-geaaf77dd85c333 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105147 Bug ID: 105147 Summary: New test case gcc.dg/pr105140.c introduced in r12-7979-geaaf77dd85c333 has excess errors Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:eaaf77dd85c333b116111bb1ae6c080154a4e411, r12-7979-geaaf77dd85c333 make -k check-gcc RUNTESTFLAGS="dg.exp=gcc.dg/pr105140.c" FAIL: gcc.dg/pr105140.c (test for excess errors) # of unexpected failures1 Excess errors: /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr105140.c:16:3: error: AltiVec argument passed to unprototyped function commit eaaf77dd85c333b116111bb1ae6c080154a4e411 (HEAD, refs/bisect/bad) Author: Richard Biener Date: Mon Apr 4 10:20:05 2022 +0200 middle-end/105140 - fix bogus recursion in fold_convertible_p
[Bug libstdc++/105146] New: std::bad_expected_access constructor missing std::move for error type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105146
Bug ID: 105146
Summary: std::bad_expected_access constructor missing std::move
for error type
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
#include
struct E {
E() = default;
E(const E&) = delete;
E& operator=(const E&) = delete;
E(E&&) = default;
E& operator=(E&&) = default;
};
int main() {
std::expected{std::unexpect}.value();
}
https://godbolt.org/z/1hfzYo1cK
[Bug debug/105145] New: dropped DWARF location information at -O1/-O2/-O3 upon ftree-dse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105145
Bug ID: 105145
Summary: dropped DWARF location information at -O1/-O2/-O3 upon
ftree-dse
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: assaiante at diag dot uniroma1.it
Target Milestone: ---
When debugging this minimized C example, pointer variable l_158 appears as
optimized out at every stepped line, including line 14 where it is used to
compute the value of a function call argument. This happens at -O1/O2/O3 but
not at -Og.
Apparently, -ftree-dse makes the DWARF DIE for l_158 drop a location definition
while the ASM stays unchanged. When adding -fno-tree-dse to -O1/O2/O3, the
variable value appears at lines 13 and 14. However, it stays as optimized out
between line 10 (where it is assigned) to 13. We were not able to pinpoint what
may be behind this latter fact, though.
Below we provide details for -O1 on x64 and a quick assessment of prior gcc
versions.
$ cat a.c
int *a;
int **d =
int *e =
int f;
volatile char g;
short h(int b, int c) { return 0; }
int main() {
int ***l_134 = e;
int *l_133 = l_134;
int l_141 = 0;
int *l_158 = _141;
short l_185 = 3;
*d = l_158;
g = ***l_134 + h(f != _158, l_185);
}
GCC and GDB version:
- gcc (GCC) 12.0.0 20211227 (experimental) - commit id: 500d3f0a302
- GNU gdb (GDB) 11.2
GDB trace:
$ gcc -O1 -g a.c -o opt
$ gdb -q opt
root@1f83e51b6153:/tmp# gdb -q opt
Reading symbols from opt...
(gdb) b 14
Breakpoint 1 at 0x4004aa: file a.c, line 14.
(gdb) r
Starting program: /tmp/opt
Breakpoint 1, main () at a.c:14
14g = ***l_134 + h(f != _158, l_185);
(gdb) info locals
l_134 = 0x601030
l_133 = 0x601030
l_141 = 0
l_158 =
l_185 = 3
ASM at -O1:
0040048c :
40048c: 48 8b 05 95 0b 20 00mov0x200b95(%rip),%rax#
601028
400493: c7 44 24 fc 00 00 00movl $0x0,-0x4(%rsp)
40049a: 00
40049b: 48 8d 4c 24 fc lea-0x4(%rsp),%rcx
4004a0: 48 8b 15 89 0b 20 00mov0x200b89(%rip),%rdx#
601030
4004a7: 48 89 0amov%rcx,(%rdx)
4004aa: 48 8b 00mov(%rax),%rax
4004ad: 48 8b 00mov(%rax),%rax
4004b0: 8b 00 mov(%rax),%eax
4004b2: 88 05 88 0b 20 00 mov%al,0x200b88(%rip)#
601040
4004b8: b8 00 00 00 00 mov$0x0,%eax
4004bd: c3 retq
DWARF at -O1:
0x0101: DW_TAG_variable
DW_AT_name("l_158")
DW_AT_decl_file ("/tmp/a.c")
DW_AT_decl_line (11)
DW_AT_decl_column (0x08)
DW_AT_type(0x0041 "int*")
Through some testing we found out that the optimization flag involved in the
issue is likely -ftree-dse. If we add -fno-tree-dse to the compilation command
line used above, the pointer variable l_158 appears in the current frame with
its value correctly shown at line 14.
The DWARF location info is correctly defined for the variable throughout its
whole lifetime.
ASM at -O1 with -fno-tree-dse:
0040048c :
40048c: 48 8b 05 95 0b 20 00mov0x200b95(%rip),%rax#
601028
400493: c7 44 24 fc 00 00 00movl $0x0,-0x4(%rsp)
40049a: 00
40049b: 48 8d 4c 24 fc lea-0x4(%rsp),%rcx
4004a0: 48 8b 15 89 0b 20 00mov0x200b89(%rip),%rdx#
601030
4004a7: 48 89 0amov%rcx,(%rdx)
4004aa: 48 8b 00mov(%rax),%rax
4004ad: 48 8b 00mov(%rax),%rax
4004b0: 8b 00 mov(%rax),%eax
4004b2: 88 05 88 0b 20 00 mov%al,0x200b88(%rip)#
601040
4004b8: b8 00 00 00 00 mov$0x0,%eax
4004bd: c3 retq
DWARF at -O1 with -fno-tree-dse:
0x0101: DW_TAG_variable
DW_AT_name("l_158")
DW_AT_decl_line (11)
DW_AT_decl_column (0x08)
DW_AT_type(0x0041 "int*")
DW_AT_location(0x0020:
[0x0040049b, 0x004004a0): DW_OP_fbreg -12,
DW_OP_stack_value
[0x004004a0, 0x004004b8): DW_OP_reg2 RCX)
DW_AT_GNU_locviews(0x001c)
In short, the ASM of the main function stays identical but we have an accurate
location definition that leads to the correct availability of the value of
l_158 in its usage at line 14.
We have also tested older gcc versions (6.4, 7.5, 8.4, 9.3, 10.3, 11.1) and for
the tested optimization levels the behavior is identical to the git version
originally
[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt with coroutines since r11-7419-g0f161cc8494cf728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328 --- Comment #24 from Avi Kivity --- Many thanks for the patch and the commit. Can we have it backported to 11.x?
[Bug sanitizer/105141] #pragma pack(1) causes incorrect UBSAN warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105141
Ivan Sorokin changed:
What|Removed |Added
CC||vanyacpp at gmail dot com
--- Comment #8 from Ivan Sorokin ---
Note that when __attribute__((packed)) is used GCC produces a warning:
warning: taking address of packed member of '' may result in an
unaligned pointer value [-Waddress-of-packed-member]
10 | int *d =
| ^~~~
Perhaps a similar warning should be reported for #pragma packed structs.
https://godbolt.org/z/Yr13WhbG8
struct
{
char a;
int b;
} __attribute__((packed)) c;
int main()
{
int *d =
__builtin_printf("%d\n", *d);
}
[Bug c++/103852] [10/11/12 Regression] Alias template argument deduction is available in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103852 Jason Merrill changed: What|Removed |Added Target Milestone|10.4|12.0 --- Comment #4 from Jason Merrill --- The patch doesn't affect the testcases, because there the templates are still considered equivalent. Though now I notice that the suggested resolution of DR1286 only considers template equivalence in the context of comparing template arguments; it isn't saying that they're interchangeable in all contexts. So perhaps we should stop using that equivalence in this case.
[Bug c++/101894] [11 Regression] ICE with multiple friend declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101894 Jason Merrill changed: What|Removed |Added Known to work||12.0 Known to fail|12.0| Summary|[11/12 Regression] ICE with |[11 Regression] ICE with |multiple friend |multiple friend |declarations|declarations --- Comment #6 from Jason Merrill --- Fixed for 12 so far.
[Bug c++/101894] [11/12 Regression] ICE with multiple friend declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101894 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:3afc7c4eeada0a04c2c4ededeb0f6ccc724a58ec commit r12-7985-g3afc7c4eeada0a04c2c4ededeb0f6ccc724a58ec Author: Jason Merrill Date: Fri Apr 1 16:18:31 2022 -0400 c++: repeated friend template [PR101894] Since olddecl isn't a definition, it doesn't get DECL_FRIEND_CONTEXT, so we need to copy it from newdecl when we merge the declarations. PR c++/101894 gcc/cp/ChangeLog: * decl.cc (duplicate_decls): Copy DECL_FRIEND_CONTEXT. gcc/testsuite/ChangeLog: * g++.dg/lookup/friend22.C: New test.
[Bug c++/103852] [10/11/12 Regression] Alias template argument deduction is available in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103852 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a11f204e5a30d1dfd2508e3f3014509a0342f604 commit r12-7984-ga11f204e5a30d1dfd2508e3f3014509a0342f604 Author: Jason Merrill Date: Fri Apr 1 15:55:21 2022 -0400 c++: alias-tmpl equivalence and default targs [PR103852] The suggested resolution for CWG1286, which we implemented, ignores default template arguments, but this PR is an example of why that doesn't make sense: the templates aren't functionally equivalent. PR c++/103852 DR 1286 gcc/cp/ChangeLog: * pt.cc (get_underlying_template): Compare default template args. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/alias-decl-dr1286a.C: Default args now matter. * g++.dg/cpp1z/class-deduction-alias1.C: New test.
[Bug target/104049] [12 Regression] vec_select to subreg lowering causes superfluous moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049 --- Comment #15 from Tamar Christina --- (In reply to rsand...@gcc.gnu.org from comment #14) > > So IMO we should fix RTL representation problem that Andrew pointed > out in comment 7 as the P1 fix, then accept the other cases as a P2 > regression caused by bigger improvements elsewhere. Alright, mine then.
[Bug tree-optimization/104639] [12 Regression] Useless loop not fully optimized anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104639 --- Comment #12 from Jakub Jelinek --- (In reply to Aldy Hernandez from comment #11) > I don't know. I thought return's were special. Can there be more than one > per function? I think high gimple (what before lower pass) allows multiple GIMPLE_RETURN stmts, but low gimple does not. But gimple-low.cc comment only says: 3- Multiple identical return statements are grouped into a single return and gotos to the unique return site. so perhaps it isn't guaranteed either.
[Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103147 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #5 from rsandifo at gcc dot gnu.org --- Mine.
[Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103147
--- Comment #4 from Richard Biener ---
I think it makes sense to ignore -fpack-struct for the intrinsic API/ABI
defined types. OTOH using the option in general doesn't make much sense so an
#if __GCC_PACK_STRUCT
#error "do not use -fpack-struct with arm_neon.h"
#endif
in those headers might make sense as well. Alternatively
#pragma GCC push_options
#pragma GCC optimize("no-pack-struct")
...
#pragma GCC pop_options
around the header contents might work as well.
Maybe the simulate_record_decl should ignore -fpack-struct in general.
[Bug fortran/102314] [12 Regression] ICE in verify_ssa, at tree-ssa.c:1076 since r12-1319-gd4d38135b3137f1d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102314 Richard Biener changed: What|Removed |Added Priority|P1 |P4 --- Comment #5 from Richard Biener --- Fortran FE -> P4.
[Bug target/105010] [12 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010 Segher Boessenkool changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/100810] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100810
--- Comment #12 from Richard Biener ---
Testcase from PR102902, since it runtime times-out difficult to adapt to the
testsuite bug fixed by both proposed patches.
[576] % gcctk -O2 small.c; ./a.out
[577] %
[577] % gcctk -O3 small.c
[578] % timeout -s 9 10 ./a.out
Killed
[579] %
[579] % cat small.c
int printf (const char *, ...);
int a, b, c, d, e, f;
int main() {
int g;
short h = 1;
for (; e < 2; e++) {
L1:
f = 1;
while (b > 0 || a > 0) {
g++;
h++;
printf("%d", g);
}
L2:
if (!h && (!c || a))
goto L1;
if (c)
goto L2;
}
return 0;
}
[Bug middle-end/100810] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100810 --- Comment #11 from Richard Biener --- *** Bug 102902 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/102902] [12 Regression] -O3 produces code that uses an uninitialized variable but originally was not used by r12-3876
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102902 Richard Biener changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #10 from Richard Biener --- Confirmed as duplicate, -fno-ivopts fixes it, as does the proposed patch(es) in the duplicate. *** This bug has been marked as a duplicate of bug 100810 ***
[Bug tree-optimization/105142] [12 Regression] Wrong code with -O2 since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105142 Richard Biener changed: What|Removed |Added Attachment #52744|0 |1 is obsolete|| --- Comment #11 from Richard Biener --- Created attachment 52746 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52746=edit patch to rewrite undefined overflow stmts Fixed patch #1 (doesn't fix this testcase). Bootstrapped/tested OK on x86_64, I'm queuing this for stage1 for now.
[Bug target/105144] [12 Regression] Bootstrap + install failure on aarch64 due to aarch64-tune.md likely since r12-7842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug target/105144] [12 Regression] Bootstrap + install failure on aarch64 due to aarch64-tune.md likely since r12-7842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2f0610acbc056052a108e4a46911fc21d0dca2ab commit r12-7983-g2f0610acbc056052a108e4a46911fc21d0dca2ab Author: Jakub Jelinek Date: Mon Apr 4 13:56:32 2022 +0200 aarch64: Restrict aarch64-tune.md regeneration to --enable-maintainer-mode [PR105144] Normally updates to the source directory files are guarded with --enable-maintainer-mode, e.g. we don't regenerate configure, config.h, Makefile.in in directories that use automake etc. unless gcc is configured that way. Otherwise the source tree can't be e.g. stored on a read-only filesystem etc. In gcc/Makefile.in we use @MAINT@ for that but that works because gcc/Makefile is generated by configure. In config/*/t-* files we need to check $(ENABLE_MAINTAINER_RULES): # The following provides the variable ENABLE_MAINTAINER_RULES that can # be used in language Make-lang.in makefile fragments to enable # maintainer rules. So, ENABLE_MAINTAINER_RULES is 'true' in # maintainer mode, and '' otherwise. @MAINT@ ENABLE_MAINTAINER_RULES = true On Mon, Apr 04, 2022 at 11:10:14AM +0100, Richard Sandiford wrote: > I guess the risk is that it will become even easier to forget > to commit an updated aarch64-tune.md. Perhaps we should have a > non-maintainer rule to build aarch64-tune.md locally and check it > against the source-directory version, and fail the build if there's > a mismatch. Or maybe we should just generate aarch64-tune.md in the > build directory and remove the source directory version. I've tried if aarch64-tune.md will be read from the build dir, but it is not. The gen* files can use -I options to add additional directories, but they don't use them. Here is a variant patch which will complain and fail if there is a change and --enable-maintainer-mode is not enabled. 2022-04-04 Jakub Jelinek PR target/105144 * config/aarch64/t-aarch64 (s-aarch64-tune-md): Do move-if-change only if configured with --enable-maintainer-mode, otherwise compare tmp-aarch64-tune.md with $(srcdir)/config/aarch64/aarch64-tune.md and if they differ, emit a message and fail.
[Bug target/105139] [12 Regression] GCC produces vmovw instruction with an incorrect argument for -O3 -march=sapphirerapids since r12-6215-g708b87dcb6e48cb4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105139 --- Comment #6 from Uroš Bizjak --- *movv2qi_internal was not fixed in the same way as *movhi_internal, so: diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md index 29d470bdef2..197f19e4b1a 100644 --- a/gcc/config/i386/mmx.md +++ b/gcc/config/i386/mmx.md @@ -462,7 +462,7 @@ (const_string "TI")) (eq_attr "alternative" "5") (cond [(match_test "TARGET_AVX512FP16") - (const_string "HI") + (const_string "HF") (match_test "TARGET_AVX") (const_string "TI") (ior (not (match_test "TARGET_SSE2"))
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772 --- Comment #44 from Jakub Jelinek --- Rainer, for pr80334.C, have you been able to test the #c43 patch? As for TLS and alignment, to confirm it is a ld bug, can you try #c29 testcase with all of gas + gld, gas + sunld and sunas + sunld (or perhaps just the first and last from these)? If gas + gld works and sunas + sunld don't, it would confirm the sun ld bug. Thanks.
[Bug middle-end/105135] [11/12 Regression] Optimization regression for handrolled branchless assignment since r11-4717-g3e190757fa332d32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105135
--- Comment #3 from Jakub Jelinek ---
Trying to microbenchmark this in a tight loop on i9-7960X shows in this case
cmov probably better (but cmov is really a lottery on x86):
cat pr105135.c
__attribute__((noipa)) char to_lower_1(const char c) { return c + ((c >= 'A' &&
c <= 'Z') * 32); }
__attribute__((noipa)) char to_lower_2(const char c) { return c + (((c >= 'A')
& (c <= 'Z')) * 32); }
__attribute__((noipa)) char to_lower_3(const char c) { if (c >= 'A' && c <=
'Z') return c + 32; return c; }
$ cat pr105135-2.c
__attribute__((noipa)) char to_lower_1(const char c);
__attribute__((noipa)) char to_lower_2(const char c);
__attribute__((noipa)) char to_lower_3(const char c);
#define N 10
int
main ()
{
unsigned long long r = 0;
#ifdef Aa
for (long long i = 0; i < N; i++)
r += to_lower ((i & 1) ? 'A' : 'a');
#else
for (long long i = 0; i < N; i++)
r += to_lower ('A');
#endif
asm volatile ("" : : "r" (r));
}
$ for i in "./cc1 -quiet" "gcc -S"; do for j in 1 2 3; do for k in "" -DAa; do
eval $i -O3 pr105135.c; gcc -Dto_lower=to_lower_$j $k -O3 -o pr105135{,.s}
pr105135-2.c; echo $i $j $k; time ./pr105135; done; done; done
./cc1 -quiet 1
real0m1.230s
user0m1.228s
sys 0m0.001s
./cc1 -quiet 1 -DAa
real0m1.706s
user0m1.703s
sys 0m0.001s
./cc1 -quiet 2
real0m1.222s
user0m1.221s
sys 0m0.000s
./cc1 -quiet 2 -DAa
real0m1.686s
user0m1.683s
sys 0m0.001s
./cc1 -quiet 3
real0m1.232s
user0m1.230s
sys 0m0.000s
./cc1 -quiet 3 -DAa
real0m1.450s
user0m1.447s
sys 0m0.001s
gcc -S 1
real0m1.232s
user0m1.229s
sys 0m0.001s
gcc -S 1 -DAa
real0m1.391s
user0m1.389s
sys 0m0.001s
gcc -S 2
real0m1.233s
user0m1.230s
sys 0m0.001s
gcc -S 2 -DAa
real0m1.398s
user0m1.397s
sys 0m0.000s
gcc -S 3
real0m1.232s
user0m1.229s
sys 0m0.001s
gcc -S 3 -DAa
real0m1.430s
user0m1.428s
sys 0m0.000s
where gcc is GCC 10.x and ./cc1 is current trunk.
Seems for the constant 'A' case it is actually a wash, but with alternating
'A'/'a' cmov is better.
clang seems to emit for the first 2 functions very similar code to gcc, the
only difference is that
shift left and addition are performed using 8-bit rather than 32-bit
instructions, so:
leal-65(%rdi), %eax
cmpb$26, %al
setb%al
shlb$5, %al
addb%dil, %al
and that seems to perform better.
I have tried to use
leal-65(%rdi), %ecx
xorl%eax, %eax
cmpb$25, %cl
setbe %al
sall$5, %eax
addl%edi, %eax
to perform manually what our peephole2 tries to do for setXX instructions but
in this case fails to do as %eax is live in the comparison before it,
that helped a little bit but not as much as the 8-bit instructions do.
But when I disable the
;; Avoid redundant prefixes by splitting HImode arithmetic to SImode.
;; Do not split instructions with mask registers.
(define_split
[(set (match_operand 0 "general_reg_operand")
(match_operator 3 "promotable_binary_operator"
[(match_operand 1 "general_reg_operand")
(match_operand 2 "aligned_operand")]))
(clobber (reg:CC FLAGS_REG))]
"! TARGET_PARTIAL_REG_STALL && reload_completed
&& ((GET_MODE (operands[0]) == HImode
&& ((optimize_function_for_speed_p (cfun) && !TARGET_FAST_PREFIX)
/* ??? next two lines just !satisfies_constraint_K (...) */
|| !CONST_INT_P (operands[2])
|| satisfies_constraint_K (operands[2])))
|| (GET_MODE (operands[0]) == QImode
- && (TARGET_PROMOTE_QImode || optimize_function_for_size_p (cfun"
+ && (0 || optimize_function_for_size_p (cfun"
[(parallel [(set (match_dup 0)
(match_op_dup 3 [(match_dup 1) (match_dup 2)]))
(clobber (reg:CC FLAGS_REG))])]
{
operands[0] = gen_lowpart (SImode, operands[0]);
operands[1] = gen_lowpart (SImode, operands[1]);
if (GET_CODE (operands[3]) != ASHIFT)
operands[2] = gen_lowpart (SImode, operands[2]);
operands[3] = shallow_copy_rtx (operands[3]);
PUT_MODE (operands[3], SImode);
})
splitter so that the code is basically the same as from clang, it is still
slower than the clang version, so it is just weird.
Anyway, the GIMPLE optimization is IMNSHO sound, it is all about how exactly
the backend handles it.
[Bug libstdc++/105027] Missing constraints on std::bit_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105027 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:20f2303b0ce6bbe412e852e6423daabd04c39ebb commit r11-9773-g20f2303b0ce6bbe412e852e6423daabd04c39ebb Author: Jonathan Wakely Date: Wed Mar 23 09:57:20 2022 + libstdc++: Add missing constraints to std::bit_cast [PR105027] Our std::bit_cast was relying on the compiler to check for errors inside __builtin_bit_cast, instead of checking them as constraints. That means std::bit_cast was not SFINAE-friendly. This fix uses a requires-clause, so for old versions of Clang without concepts support the function will still be unconstrained. At some point in future we can remove the #ifdef __cpp_concepts check and rely on all compilers having full concepts support in C++20 mode. libstdc++-v3/ChangeLog: PR libstdc++/105027 * include/std/bit (bit_cast): Add constraints. * testsuite/26_numerics/bit/bit.cast/105027.cc: New test. (cherry picked from commit 4894d69a1f37d54b6a612e58053db477ff5ba832)
[Bug libstdc++/103650] [9/10/11 Regression] libstdc++ headers defined LT_OBJDIR and STDC_HEADERS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103650 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:0811a4dc39d6269f4087c25ed2be497fe027e756 commit r11-9765-g0811a4dc39d6269f4087c25ed2be497fe027e756 Author: Jonathan Wakely Date: Mon Jan 17 11:24:35 2022 + libstdc++: Rename non-reserved macros in config header [PR103650] libstdc++-v3/ChangeLog: PR libstdc++/103650 * include/Makefile.am: Rename LT_OBJDIR and STDC_HEADERS. * include/Makefile.in: Regenerate. * testsuite/17_intro/headers/c++1998/103650.cc: New test. (cherry picked from commit fa092570fbaf3bb4202e518eb8beba146c464d9f)
[Bug libstdc++/104098] [11 Regression] bits/stl_iterator.h fails to compile for __cplusplus > 201703L and with __cpp_concepts undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104098 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f6bf63ff3684c28c3b2c4d3a67a42db738d6342d commit r11-9764-gf6bf63ff3684c28c3b2c4d3a67a42db738d6342d Author: Jonathan Wakely Date: Tue Jan 18 15:34:24 2022 + libstdc++: Use __cpp_lib_concepts in std::reverse_iterator [PR104098] We should not assume that std::iter_value_t etc. are defined unconditionally for C++20 mode. libstdc++-v3/ChangeLog: PR libstdc++/104098 * include/bits/stl_iterator.h (reverse_iterator): Check __cpp_lib_concepts instead of __cplusplus. (cherry picked from commit e13e95bd274148a825bc9527efac49e99080dd64)
[Bug libstdc++/104542] make_obj_using_allocator and uninitialized_construct_using_allocator lack constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104542 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:fe76adc667b4e521705540b30b68ab988c6abbec commit r11-9760-gfe76adc667b4e521705540b30b68ab988c6abbec Author: Jonathan Wakely Date: Tue Feb 15 12:47:39 2022 + libstdc++: Add missing constexpr to uses-allocator construction utilities [PR104542] libstdc++-v3/ChangeLog: PR libstdc++/104542 * include/bits/uses_allocator_args.h (make_obj_using_allocator) (uninitialized_construct_using_allocator): Add constexpr. * testsuite/20_util/uses_allocator/make_obj.cc: Check constexpr. * testsuite/20_util/uses_allocator/uninitialized_construct.cc: New test. (cherry picked from commit 6cfb7ffb659fd6b87a21312021ab023a06e8f6be)
[Bug libstdc++/104301] --enable-cstdio=stdio_pure not passed down to libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104301 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e6503952a2f884917b52d0f4ae2707d25f1a0a39 commit r11-9757-ge6503952a2f884917b52d0f4ae2707d25f1a0a39 Author: Jonathan Wakely Date: Mon Jan 31 11:00:18 2022 + libstdc++: Improve config output for --enable-cstdio [PR104301] Currently we just print "checking for underlying I/O to use... stdio" unconditionally, whether configured to use stdio_pure or stdio_posix. We should make it clear that the user's configure option chose the right thing. libstdc++-v3/ChangeLog: PR libstdc++/104301 * acinclude.m4 (GLIBCXX_ENABLE_CSTDIO): Print different messages for stdio_pure and stdio_posix options. * configure: Regenerate. (cherry picked from commit 19b8946dbda5fda4389ef8e3ea162c3df2b1998d)
[Bug c++/105099] [9/10/11/12 Regression] In lookup of namespace name qualifiers only namespaces should be considered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105099 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |9.5
[Bug fortran/105054] [11/12 Regression] Using one kind of pointer functions causes the compiler to hang since r11-3029-g2b0df0a6ac79b34f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105054
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.3
Priority|P3 |P4
--- Comment #3 from Richard Biener ---
Confirmed for the hang. It hangs in f95-lang.cc:poplevel which does
391 /* Clear out the meanings of the local variables of this level. */
392
393 for (subblock_node = decl_chain; subblock_node;
394subblock_node = DECL_CHAIN (subblock_node))
395 if (DECL_NAME (subblock_node) != 0)
396 /* If the identifier was used or addressed via a local extern
decl,
397 don't forget that fact. */
398 if (DECL_EXTERNAL (subblock_node))
399 {
400 if (TREE_USED (subblock_node))
401 TREE_USED (DECL_NAME (subblock_node)) = 1;
402 if (TREE_ADDRESSABLE (subblock_node))
403 TREE_ADDRESSABLE (DECL_ASSEMBLER_NAME (subblock_node)) = 1;
404 }
and this loop never terminates.
(gdb) p decl_chain
$1 =
(gdb) p decl_chain->common.chain
$2 =
(gdb) p decl_chain->common.chain->common.chain
$3 =
(gdb) p decl_chain->common.chain->common.chain->common.chain
$4 =
[Bug tree-optimization/105142] [12 Regression] Wrong code with -O2 since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105142 --- Comment #10 from Richard Biener --- (In reply to Richard Biener from comment #9) > Created attachment 52745 [details] > avoid combining the conditions > > Like this prototype which fixes the testcase and avoids combining from stmts > defined in the middle BB. It could be enhanced by only considering not > combining from stmts with undefined overflow behavior (or flow-sensitive > info). > > This patch is also incomplete, maybe_fold_and_comparisons and > maybe_fold_or_comparisons is used by if-conversion, ifcombine and reassoc > and more importantly through recursion with itself and related > simplifications > in gimple-fold.cc. It's not clear where to extract the context BB from and > I didn't follow all the flow through the various routines. Esp. > if-conversion > looks susceptible, reassoc might restrict itself to conditions from the same > BB, not sure. surprisingly(?) the patch has no negative effect on the testsuite (OTOH it is incomplete and likely test coverage for vectorizer if-conversion is broader). I'm unsure whether we want to rush things for GCC 12 and to what extent we want to allow combination from the middle-block(s) (exposing, besides undefined overflow, other flow-sensitive info that depends on the outer condition being short-circuiting).
[Bug target/105139] [12 Regression] GCC produces vmovw instruction with an incorrect argument for -O3 -march=sapphirerapids since r12-6215-g708b87dcb6e48cb4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105139 --- Comment #5 from Richard Biener --- (In reply to Martin Liška from comment #3) > @Richi: Are you sure about that your GAS supports that? > > $ cat vmovw.s > vmovw %xmm0, %xmm1 > $ as -v --64 vmovw.s > GNU assembler version 2.38 (x86_64-suse-linux) using BFD version (GNU > Binutils; openSUSE Tumbleweed) 2.38.20220304-3 > vmovw.s: Assembler messages: > vmovw.s:1: Error: operand type mismatch for `vmovw' > > $ ./gas/as-new /home/marxin/Programming/testcases/vmovw.s -v > GNU assembler version 2.37 (x86_64-pc-linux-gnu) using BFD version (GNU > Binutils) 2.37 > /home/marxin/Programming/testcases/vmovw.s: Assembler messages: > /home/marxin/Programming/testcases/vmovw.s:1: Error: no such instruction: > `vmovw %xmm0,%xmm1' oops, I forgot to actually assemble the output
[Bug tree-optimization/105142] [12 Regression] Wrong code with -O2 since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105142 --- Comment #9 from Richard Biener --- Created attachment 52745 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52745=edit avoid combining the conditions Like this prototype which fixes the testcase and avoids combining from stmts defined in the middle BB. It could be enhanced by only considering not combining from stmts with undefined overflow behavior (or flow-sensitive info). This patch is also incomplete, maybe_fold_and_comparisons and maybe_fold_or_comparisons is used by if-conversion, ifcombine and reassoc and more importantly through recursion with itself and related simplifications in gimple-fold.cc. It's not clear where to extract the context BB from and I didn't follow all the flow through the various routines. Esp. if-conversion looks susceptible, reassoc might restrict itself to conditions from the same BB, not sure.
[Bug target/105144] [12 Regression] Bootstrap + install failure on aarch64 due to aarch64-tune.md likely since r12-7842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:376cf6d19cdcb791a4257bc1cafabfae89227683 commit r12-7981-g376cf6d19cdcb791a4257bc1cafabfae89227683 Author: Jakub Jelinek Date: Mon Apr 4 12:09:26 2022 +0200 aarch64: Fix aarch64-tune.md (re)generation [PR105144] As I wrote in the PR, our Fedora trunk gcc builds likely after r12-7842 change are now failing (lto1 crashes). What happens is that when one bootstraps into an empty build directory (or set of them), mddeps.mk doesn't exist yet and so Makefile doesn't include it. When building from an empty dir, that is usually not a big issue, it is enough when various build directory files depend on just $(srcdir)/config/aarch64/aarch64.md, those files don't exist and aarch64.md does, so they are built, so is mddeps.mk. But because the other dependencies aren't there (in particular $(srcdir)/config/aarch64/aarch64-tune.md ), the s-aarch64-tune-md rule isn't invoked to regenerate that file and the r12-7842 commit reordered aarch64-cores.def entries but didn't commit regenerated aarch64-tune.md. Because it is just reordering in aarch64-tune.md, it actually doesn't matter and bootstraps succeeds. But then during make install, mddeps.mk exists already in gcc/ directory, it sees that aarch64-cores.def is newer than aarch64-tune.md (unless gen_update is used, that just touches aarch64-tune.md to make sure it is newer) and regenerates it and as it is different, make install rebuilds a large subset of the *.o files, but this time with the system g++ rather than previous stage one. And during lto linking of it there are differences in LTO bytecode between the compilers and we crash. The following patch fixes that by regenerating aarch64-tune.md (what was forgotten in r12-7842) and by adding a dependency from s-mddeps to s-aarch64-tune-md, which makes sure that even when mddeps.mk doesn't exist yet make sees the dependency and regenerates aarch64-tune.md if needed. 2022-04-04 Jakub Jelinek PR target/105144 * config/aarch64/t-aarch64 (s-mddeps): Depend on s-aarch64-tune-md. * config/aarch64/aarch64-tune.md: Regenerated.
[Bug middle-end/105135] [11/12 Regression] Optimization regression for handrolled branchless assignment since r11-4717-g3e190757fa332d32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105135 Martin Liška changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|[11/12 Regression] |[11/12 Regression] |Optimization regression for |Optimization regression for |handrolled branchless |handrolled branchless |assignment |assignment since ||r11-4717-g3e190757fa332d32 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-04-04 --- Comment #2 from Martin Liška --- Started with r11-4717-g3e190757fa332d32.
[Bug tree-optimization/103035] [meta-bug] YARPGen bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035 Bug 103035 depends on bug 105132, which changed state. Bug 105132 Summary: ICE in in operator[], at vec.h:889 with -march=skylake-avx512 -O3 since r12-7246-g4963079769c99c40 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105132 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/105132] ICE in in operator[], at vec.h:889 with -march=skylake-avx512 -O3 since r12-7246-g4963079769c99c40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105132 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed (maybe a missed optimization remains)
[Bug ipa/105140] [10/11 Regression] ICE: SIGSEGV in fold_convertible_p with conflicting function redeclaration since r10-5112-gfddcfa5b84bf8a06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105140 Richard Biener changed: What|Removed |Added Known to work||12.0 Priority|P3 |P2 Known to fail|12.0| Summary|[10/11/12 Regression] ICE: |[10/11 Regression] ICE: |SIGSEGV in |SIGSEGV in |fold_convertible_p with |fold_convertible_p with |conflicting function|conflicting function |redeclaration since |redeclaration since |r10-5112-gfddcfa5b84bf8a06 |r10-5112-gfddcfa5b84bf8a06
[Bug tree-optimization/105132] ICE in in operator[], at vec.h:889 with -march=skylake-avx512 -O3 since r12-7246-g4963079769c99c40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105132 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:3eda57b4ae50b5fe57c174556f1daf3bd9a46b09 commit r12-7980-g3eda57b4ae50b5fe57c174556f1daf3bd9a46b09 Author: Richard Biener Date: Mon Apr 4 10:31:15 2022 +0200 tree-optimization/105132 - add missing checking in vectorizable_operation The following adds missing verification that the input vectors have the same number of elements for vectorizable_operation. 2022-04-04 Richard Biener PR tree-optimization/105132 * tree-vect-stmts.cc (vectorizable_operation): Check that the input vectors have the same number of elements. * gcc.dg/torture/pr105132.c: New testcase.
[Bug ipa/105140] [10/11/12 Regression] ICE: SIGSEGV in fold_convertible_p with conflicting function redeclaration since r10-5112-gfddcfa5b84bf8a06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105140 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:eaaf77dd85c333b116111bb1ae6c080154a4e411 commit r12-7979-geaaf77dd85c333b116111bb1ae6c080154a4e411 Author: Richard Biener Date: Mon Apr 4 10:20:05 2022 +0200 middle-end/105140 - fix bogus recursion in fold_convertible_p fold_convertible_p expects an operand and a type to convert to but recurses with two vector component types. Fixed by allowing types instead of an operand as well. 2022-04-04 Richard Biener PR middle-end/105140 * fold-const.cc (fold_convertible_p): Allow a TYPE_P arg. * gcc.dg/pr105140.c: New testcase.
[Bug tree-optimization/105142] [12 Regression] Wrong code with -O2 since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105142 --- Comment #8 from Richard Biener --- Created attachment 52744 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52744=edit patch to rewrite undefined overflow stmts Here's the initial patch, not solving the testcase.
[Bug ipa/105140] [10/11/12 Regression] ICE: SIGSEGV in fold_convertible_p with conflicting function redeclaration since r10-5112-gfddcfa5b84bf8a06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105140 Martin Liška changed: What|Removed |Added Summary|[10/11/12 Regression] ICE: |[10/11/12 Regression] ICE: |SIGSEGV in |SIGSEGV in |fold_convertible_p with |fold_convertible_p with |conflicting function|conflicting function |redeclaration |redeclaration since ||r10-5112-gfddcfa5b84bf8a06 CC||rsandifo at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r10-5112-gfddcfa5b84bf8a06.
[Bug d/104740] gdc.dg/simd_ctfe.d etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104740 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Iain Buclaw --- I think all are covered now.
[Bug tree-optimization/105142] [12 Regression] Wrong code with -O2 since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105142 --- Comment #7 from Richard Biener --- (In reply to Richard Biener from comment #4) > Hmm, I think the error happens earlier already when we simplify > > _2 < _16 && (_4 > _2) to _2 < _4 > > I do have a patch to do the rewrite into defined overflow which definitely > fixes a latent issue but not this bug. Which happens through Applying pattern match.pd:6775, gimple-match.cc:54944 Applying pattern match.pd:3153, gimple-match.cc:177685 _2 < _16 & _2 < _4 match.pd:6775 -> _2 < min (_16, _4) and min (_16, _16 + 5713568809962283044) match.pd:3153 -> _16 + 5713568809962283044 (aka _4) which is all "nice" and validates that we can replace the inner condition with itself but it ignores that it only subsumes the outer condition if the outer condition is true. That's a real tough nut to crack. It basically means that we cannot really combine two conditions if the definition chain of the inner condition is under the outer condition (and involves undefined overflow), unless we somehow can decide whether the outer condition tests for overflow of any of the guarded stmts. In practice this means not simplifying interesting cases I guess and likely fold-const.cc code is susceptible to the very same issue. A "simple" workaround would pass in context BBs to maybe_fold_and_comparisons and adjust maybe_fold_comparisons_from_match_pd with a custom follow_all_ssa_edges variant, disallowing (signed) operation expansion from the inner BB. I will experiment with that to see what the fallout would be. Note combining will have similar issues with using flow-sensitive range info from inner BB defined stmts constrained by the outer check.
[Bug target/105139] [12 Regression] GCC produces vmovw instruction with an incorrect argument for -O3 -march=sapphirerapids since r12-6215-g708b87dcb6e48cb4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105139 Martin Liška changed: What|Removed |Added Status|WAITING |NEW Summary|[12 Regression] GCC |[12 Regression] GCC |produces vmovw instruction |produces vmovw instruction |with an incorrect argument |with an incorrect argument |for -O3 |for -O3 |-march=sapphirerapids |-march=sapphirerapids since ||r12-6215-g708b87dcb6e48cb4 CC||uros at gcc dot gnu.org --- Comment #4 from Martin Liška --- Started with r12-6215-g708b87dcb6e48cb4.
[Bug tree-optimization/105142] [12 Regression] Wrong code with -O2 since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105142 --- Comment #6 from Jakub Jelinek --- I mean ... is equivalent to a < c.
[Bug target/105139] [12 Regression] GCC produces vmovw instruction with an incorrect argument for -O3 -march=sapphirerapids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105139 --- Comment #3 from Martin Liška --- @Richi: Are you sure about that your GAS supports that? $ cat vmovw.s vmovw %xmm0, %xmm1 $ as -v --64 vmovw.s GNU assembler version 2.38 (x86_64-suse-linux) using BFD version (GNU Binutils; openSUSE Tumbleweed) 2.38.20220304-3 vmovw.s: Assembler messages: vmovw.s:1: Error: operand type mismatch for `vmovw' $ ./gas/as-new /home/marxin/Programming/testcases/vmovw.s -v GNU assembler version 2.37 (x86_64-pc-linux-gnu) using BFD version (GNU Binutils) 2.37 /home/marxin/Programming/testcases/vmovw.s: Assembler messages: /home/marxin/Programming/testcases/vmovw.s:1: Error: no such instruction: `vmovw %xmm0,%xmm1'
[Bug tree-optimization/105142] [12 Regression] Wrong code with -O2 since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105142 --- Comment #5 from Jakub Jelinek --- If so, that must be still during ifcombine though. Because what I see is that we have effectively MIN_EXPR + large_cst> until threadfull1, which decides to thread it based on the a < c comparison, if a < c, then the result is just a and the addition is optimized away as unused, otherwise effectively MIN_EXPR is done. I believe that is a correct transformation, because for undefined overflow arithmetics (with no wrap around) a < c && a < c + large_cst is equivalent.
[Bug d/104740] gdc.dg/simd_ctfe.d etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104740 --- Comment #3 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:f6b786d749812542dae90db1701a3cfdccfa1e4b commit r12-7978-gf6b786d749812542dae90db1701a3cfdccfa1e4b Author: Iain Buclaw Date: Sun Apr 3 20:42:20 2022 +0200 d: Compile simd_ctfe.d only on avx_runtime or vect_sizes_16B_8B targets PR d/104740 gcc/testsuite/ChangeLog: * gdc.dg/simd_ctfe.d: Compile with target avx_runtime or vect_sizes_16B_8B.
[Bug target/105139] [12 Regression] GCC produces vmovw instruction with an incorrect argument for -O3 -march=sapphirerapids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105139 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- It's rejected with 2.38: $ as -v --64 -o a-pr105139.o a-pr105139.s GNU assembler version 2.38 (x86_64-suse-linux) using BFD version (GNU Binutils; openSUSE Tumbleweed) 2.38.20220304-3 a-pr105139.s: Assembler messages: a-pr105139.s:92: Error: operand type mismatch for `vmovw' Let me bisect GAS.
[Bug tree-optimization/105132] ICE in in operator[], at vec.h:889 with -march=skylake-avx512 -O3 since r12-7246-g4963079769c99c40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105132 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | CC||marxin at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Summary|ICE in in operator[], at|ICE in in operator[], at |vec.h:889 with |vec.h:889 with |-march=skylake-avx512 -O3 |-march=skylake-avx512 -O3 ||since ||r12-7246-g4963079769c99c40 --- Comment #3 from Martin Liška --- Started with r12-7246-g4963079769c99c40.
[Bug tree-optimization/105142] [12 Regression] Wrong code with -O2 since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105142 --- Comment #4 from Richard Biener --- Hmm, I think the error happens earlier already when we simplify _2 < _16 && (_16 + 5713568809962283044 > _2) to _2 < _4 I do have a patch to do the rewrite into defined overflow which definitely fixes a latent issue but not this bug.
[Bug target/105136] [11/12 regression] Missed optimization regression with 32-bit adds and shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105136
--- Comment #2 from Uroš Bizjak ---
The regression in bar: is due to RA regression for:
(insn 28 27 29 2 (parallel [
(set (reg:SI 89)
(plus:SI (reg:SI 92)
(subreg:SI (reg:DI 87) 0)))
(clobber (reg:CC 17 flags))
]) "pr105136.c":4:11 229 {*addsi_1}
(expr_list:REG_DEAD (reg:SI 92)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
gcc-10.3 allocates:
(insn 28 27 29 2 (parallel [
(set (reg:SI 0 ax [89])
(plus:SI (reg:SI 4 si [92])
(reg:SI 5 di [87])))
(clobber (reg:CC 17 flags))
]) "pr105136.c":4:11 185 {*addsi_1}
(nil))
while gcc-12 allocates:
(insn 28 27 29 2 (parallel [
(set (reg:SI 4 si [89])
(plus:SI (reg:SI 4 si [92])
(reg:SI 5 di [87])))
(clobber (reg:CC 17 flags))
]) "pr105136.c":4:11 229 {*addsi_1}
(nil))
(...)
and reloads the output to ax:
(insn 35 29 30 2 (set (reg:SI 0 ax [89])
(reg:SI 4 si [89])) "pr105136.c":4:11 81 {*movsi_internal}
(nil))
(insn 30 35 20 2 (set (reg:SI 0 ax [89])
(if_then_else:SI (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg:SI 5 di [87])
(reg:SI 0 ax [89]))) "pr105136.c":4:11 1201 {*movsicc_noc}
(nil))
The pattern allows r/r/r in alternative 3, so the question is why RA doesn't
consider it:
(define_insn "*add_1"
[(set (match_operand:SWI48 0 "nonimmediate_operand" "=rm,r,r,r")
(plus:SWI48
(match_operand:SWI48 1 "nonimmediate_operand" "%0,0,r,r")
(match_operand:SWI48 2 "x86_64_general_operand" "re,BM,0,le")))
(clobber (reg:CC FLAGS_REG))]
The "l" constraint is user defined register constraint:
(define_register_constraint "l" "INDEX_REGS"
"@internal Any register that can be used as the index in a base+index
memory access: that is, any general register except the stack pointer.")
so perhaps user defined constraint deters RA from using this alternative.
[Bug target/105144] [12 Regression] Bootstrap + install failure on aarch64 due to aarch64-tune.md likely since r12-7842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144 --- Comment #2 from Jakub Jelinek --- Created attachment 52743 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52743=edit gcc12-pr105144-2.patch And incremental fix for 3).
[Bug tree-optimization/105132] ICE in in operator[], at vec.h:889 with -march=skylake-avx512 -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105132 --- Comment #2 from Richard Biener --- So we end up scheduling t.ii:4:6: note: node 0x45e58d0 (max_nunits=16, refcnt=1) vector(8) t.ii:4:6: note: op template: patt_99 = _20 & patt_346; t.ii:4:6: note: stmt 0 patt_99 = _20 & patt_346; t.ii:4:6: note: stmt 1 patt_68 = _94 & patt_59; t.ii:4:6: note: stmt 2 patt_71 = _108 & patt_70; t.ii:4:6: note: stmt 3 patt_2 = _124 & patt_1; t.ii:4:6: note: stmt 4 patt_78 = _140 & patt_45; t.ii:4:6: note: stmt 5 patt_37 = _156 & patt_86; t.ii:4:6: note: stmt 6 patt_40 = _172 & patt_39; t.ii:4:6: note: stmt 7 patt_115 = _188 & patt_114; t.ii:4:6: note: stmt 8 patt_121 = _204 & patt_117; t.ii:4:6: note: stmt 9 patt_132 = _220 & patt_131; t.ii:4:6: note: stmt 10 patt_146 = _236 & patt_137; t.ii:4:6: note: stmt 11 patt_149 = _252 & patt_148; t.ii:4:6: note: stmt 12 patt_163 = _268 & patt_162; t.ii:4:6: note: stmt 13 patt_169 = _284 & patt_165; t.ii:4:6: note: stmt 14 patt_180 = _300 & patt_179; t.ii:4:6: note: stmt 15 patt_194 = _316 & patt_185; t.ii:4:6: note: children 0x45e5958 0x45e5af0 where the children are vectorized with mismatching vector types of vector(16) vs. vector(8) Oddly enough vectorizable_operation nowhere tests for compatible vector types of its operands ...
[Bug target/105144] [12 Regression] Bootstrap + install failure on aarch64 due to aarch64-tune.md likely since r12-7842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144 --- Comment #1 from Jakub Jelinek --- Created attachment 52742 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52742=edit gcc12-pr105144.patch Fix for 1) and 2).
[Bug target/105144] [12 Regression] Bootstrap + install failure on aarch64 due to aarch64-tune.md likely since r12-7842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Priority|P3 |P1 Last reconfirmed||2022-04-04 Ever confirmed|0 |1 Target Milestone|--- |12.0 Status|UNCONFIRMED |ASSIGNED
[Bug target/105144] New: [12 Regression] Bootstrap + install failure on aarch64 due to aarch64-tune.md likely since r12-7842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144
Bug ID: 105144
Summary: [12 Regression] Bootstrap + install failure on aarch64
due to aarch64-tune.md likely since r12-7842
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Latest Fedora package builds fail on aarch64, I believe it is caused by
r12-7842-g9f37d31324f89d0b7b2abac988a976d121ae29c6 (but haven't actually
bisected). See e.g.
https://kojipkgs.fedoraproject.org//work/tasks/8070/85048070/build.log
We are doing a --with-build-config=bootstrap-lto --enable-link-serialization=1
profiledbootstrap with system gcc less than 4 weeks old gcc trunk snapshot.
What I see in the log is that it bootstraps just fine, then during make install
does:
/bin/sh ../../gcc/config/aarch64/gentune.sh \
../../gcc/config/aarch64/aarch64-cores.def > \
tmp-aarch64-tune.md
/bin/sh ../../gcc/../move-if-change tmp-aarch64-tune.md \
../../gcc/config/aarch64/aarch64-tune.md
echo timestamp > s-aarch64-tune-md
which hasn't been done during the bootstrap time, this changes aarch64-tune.md
and so it rebuilds quite a few but not all *.o files but with the system g++
rather than the new compiler and ICEs on lto1 because there were silent changes
in the LTO bytecode between compiler from ~ 4 weeks ago and current one.
There are multiple issues related to this:
1) the r12-7842 change changed aarch64-cores.def (moved neoverse-n2 entry
later)
but didn't regenerate and commit aarch64-tune.md
2) the reason why gentune.sh isn't invoked during bootstrap but is during
install is I believe caused by:
# Dependencies for the md file. The first time through, we just assume
# the md file itself and the generated dependency file (in order to get
# it built). The second time through we have the dependency file.
-include mddeps.mk
MD_DEPS = s-mddeps $(md_file) $(MD_INCLUDES)
s-mddeps: $(md_file) $(MD_INCLUDES) build/genmddeps$(build_exeext)
$(RUN_GEN) build/genmddeps$(build_exeext) $(md_file) > tmp-mddeps
$(SHELL) $(srcdir)/../move-if-change tmp-mddeps mddeps.mk
$(STAMP) s-mddeps
When bootstrapping gcc into a fresh new object directory (well, set of them,
like stage{1,2,3}-gcc, stageprofile-gcc, prev-gcc, gcc etc.),
mddeps.mk doesn't
exist and so isn't included and everything that depends on the *.md file(s)
depends just on s-mddeps that creates the mddeps.mk, on the main $(md_file)
(gcc/config/aarch64/aarch64.md in this case) and that is it. Not a big deal
the first time, as everything is being rebuild. But for aarch64 it means
that gentune.sh which is from:
$(srcdir)/config/aarch64/aarch64-tune.md: s-aarch64-tune-md; @true
s-aarch64-tune-md: $(srcdir)/config/aarch64/gentune.sh \
$(srcdir)/config/aarch64/aarch64-cores.def
$(SHELL) $(srcdir)/config/aarch64/gentune.sh \
$(srcdir)/config/aarch64/aarch64-cores.def > \
tmp-aarch64-tune.md
$(SHELL) $(srcdir)/../move-if-change tmp-aarch64-tune.md \
$(srcdir)/config/aarch64/aarch64-tune.md
$(STAMP) s-aarch64-tune-md
isn't invoked at that point. Next during make install, mddeps.mk already
exists and so it invokes it, regenerates it and as it is different,
move-if-change overwrites it
3) I think it is wrong to change files in $(srcdir) or its subdirs during
build except for --enable-maintainer-mode, users could have the tree
in read-only location etc.
[Bug lto/105121] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105121 --- Comment #7 from rguenther at suse dot de --- On Mon, 4 Apr 2022, dcb314 at hotmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105121 > > David Binderman changed: > >What|Removed |Added > > Resolution|--- |WORKSFORME > Status|WAITING |RESOLVED > > --- Comment #6 from David Binderman --- > (In reply to Richard Biener from comment #5) > > Yes, that could possibly reproduce the issue. Is the ICE happening in the > > WPA process? (add -v so you'd see that) > > It now fails to reproduce. Odd. Maybe the OS upgrade over the weekend > (Fedora 35 to 36 Beta) has something to do with it. > > I am happy to close this one down as not reproducible. No problem - just open a new bug if the issue pops up again.
[Bug lto/105121] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105121 David Binderman changed: What|Removed |Added Resolution|--- |WORKSFORME Status|WAITING |RESOLVED --- Comment #6 from David Binderman --- (In reply to Richard Biener from comment #5) > Yes, that could possibly reproduce the issue. Is the ICE happening in the > WPA process? (add -v so you'd see that) It now fails to reproduce. Odd. Maybe the OS upgrade over the weekend (Fedora 35 to 36 Beta) has something to do with it. I am happy to close this one down as not reproducible. I am not familiar with the WPA process, but I used -v and didn't see it (gcc -v ... 2>&1 | grep -i wpa).
[Bug tree-optimization/105142] [12 Regression] Wrong code with -O2 since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105142
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|NEW |ASSIGNED
Keywords||wrong-code
--- Comment #3 from Richard Biener ---
Let me take a stab at this. We can enhance
if (tree_ssa_ifcombine_bb (bb))
{
/* Clear range info from all stmts in BB which is now executed
conditional on a always true/false condition. */
reset_flow_sensitive_info_in_bb (bb);
cfg_changed |= true;
or adjust bb_no_side_effects_p (which already checks
gimple_uses_undefined_value_p).
[Bug ipa/105140] [10/11/12 Regression] ICE: SIGSEGV in fold_convertible_p with conflicting function redeclaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105140 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |10.4 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-04-04 --- Comment #1 from Richard Biener --- I will have a look.
[Bug target/105139] [12 Regression] GCC produces vmovw instruction with an incorrect argument for -O3 -march=sapphirerapids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105139 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 Status|UNCONFIRMED |WAITING Last reconfirmed||2022-04-04 Ever confirmed|0 |1 Target|X86_64 |x86_64-*-* --- Comment #1 from Richard Biener --- it works for me, it produces vmovw %xmm0, %xmm1 what assembler version are you using? I have 2.37
[Bug target/105136] [11/12 regression] Missed optimization regression with 32-bit adds and shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105136 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.3 Priority|P3 |P2 Ever confirmed|0 |1 Last reconfirmed||2022-04-04 Component|middle-end |target Target||x86_64-*-* Status|UNCONFIRMED |NEW Summary|[11/12] Missed optimization |[11/12 regression] Missed |regression with 32-bit adds |optimization regression |and shifts |with 32-bit adds and shifts --- Comment #1 from Richard Biener --- Confirmed.
[Bug middle-end/105135] [11/12 Regression] Optimization regression for handrolled branchless assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105135 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.3 --- Comment #1 from Richard Biener --- gcc 10 produced cmovnb for all functions, I think setbe is going to be cheaper since cmov is an odd beast. So I believe this is a progression.
[Bug c/105134] tree-vectorize produces error code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105134 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-04-04 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #3 from Richard Biener --- Can you provide preprocessed source of the TU containing sha256_starts and the full compiler command-line used to compile it?
[Bug tree-optimization/105132] ICE in in operator[], at vec.h:889 with -march=skylake-avx512 -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105132 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Keywords||ice-on-valid-code, ||needs-bisection Last reconfirmed||2022-04-04 --- Comment #1 from Richard Biener --- I will have a look.
[Bug middle-end/105126] [9/10/11/12 Regression] Optimization regression gcc inserts not needed movsx when using switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105126 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.5 Priority|P3 |P2
