[Bug testsuite/114982] New test g++.dg/tree-ssa/cxa_atexit-6.C fails on Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114982 --- Comment #2 from Andrew Pinski --- So I was going for the elf semantics here but Mach-O semantics says the function is NOT replacable unless it was weak. Anyways this is just a dg-skip-if for darwin and I will add it with a note saying locally defined functions are not replacable.
[Bug testsuite/114982] New test g++.dg/tree-ssa/cxa_atexit-6.C fails on Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114982
--- Comment #3 from Andrew Pinski ---
Looks like the testcase should also be skipped for mingw/cygwin too.
```
/* External public symbols, which aren't weakref-s,
have local-binding for PE targets. */
if (DECL_P (exp)
&& !lookup_attribute ("weakref", DECL_ATTRIBUTES (exp))
&& TREE_PUBLIC (exp)
&& DECL_EXTERNAL (exp))
return true;
```
I will double that. Though those targets might not have __cxa_atexit in the
first place so it might be less of an issue. Maybe cygwin does due to its usage
of newlib.
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #12 from LIU Hao ---
testcase:
```
namespace __cxxabiv1
{
extern "C" int __cxa_thread_atexit(void (__thiscall* dtor)(void*), void* obj,
void* dso) noexcept;
}
struct nontrivial
{
nontrivial();
~nontrivial();
};
void*
get_data()
{
thread_local nontrivial nt;
return &nt;
}
```
```
E:\lh_mouse\Desktop>g++ test.cc
: error: conflicting declaration of C function 'int
__cxxabiv1::__cxa_thread_atexit(void (*)(), void*, void*)'
test.cc:3:18: note: previous declaration 'int
__cxxabiv1::__cxa_thread_atexit(void (__attribute__((thiscall)) *)(void*),
void*, void*)'
3 | extern "C" int __cxa_thread_atexit(void (__thiscall* dtor)(void*),
void* obj, void* dso) noexcept;
| ^~~
```
[Bug tree-optimization/112659] missed-optimization: if (exp) return exp; else return 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112659
--- Comment #6 from Andrew Pinski ---
Vector testcase (C++ only) for the missing add case:
```
#define vector4 __attribute__((vector_size(4*sizeof(int
void unopt(vector4 int *v) {
vector4 int t = *v;
vector4 int t1 = t + 8;
*v = (t != -8) ? (t1) : 0;
}
```
Adding it here so I don't lose it (note clang/LLVM does catch it already).
[Bug tree-optimization/112659] missed-optimization: if (exp) return exp; else return 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112659 --- Comment #7 from Andrew Pinski --- This is the pattern I added for the plus case: ``` (for cnd (cond vec_cond) ... /* (a != CST1) ? (a + CST2) : 0 -> (a + CST2) iff CST1 == -CST2 */ (simplify (cnd (ne @0 uniform_integer_cst_p@1) (plus@3 @0 uniform_integer_cst_p@2) integer_zerop) (if (wi::to_wide (uniform_integer_cst_p (@1)) == -wi::to_wide (uniform_integer_cst_p (@2))) @3)) ) ``` The division one is harder, I think I might only handle unsigned. Or maybe decide that division is not a good idea to do ...
[Bug testsuite/109549] [14/15 Regression] Conditional move regressions after r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549 --- Comment #17 from GCC Commits --- The master branch has been updated by Kong Lingling : https://gcc.gnu.org/g:d826f7945609046f922732b138fb90795d5b1985 commit r15-313-gd826f7945609046f922732b138fb90795d5b1985 Author: konglin1 Date: Wed May 8 15:46:10 2024 +0800 x86: Fix cmov cost model issue [PR109549] (if_then_else:SI (eq (reg:CCZ 17 flags) (const_int 0 [0])) (reg/v:SI 101 [ e ]) (reg:SI 102)) The cost is 8 for the rtx, the cost for (eq (reg:CCZ 17 flags) (const_int 0 [0])) is 4, but this is just an operator do not need to compute it's cost in cmov. gcc/ChangeLog: PR target/109549 * config/i386/i386.cc (ix86_rtx_costs): The XEXP (x, 0) for cmov is an operator do not need to compute cost. gcc/testsuite/ChangeLog: * gcc.target/i386/cmov6.c: Fixed.
[Bug testsuite/109549] [14/15 Regression] Conditional move regressions after r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549 kong lingling changed: What|Removed |Added CC||lingling.kong7 at gmail dot com --- Comment #18 from kong lingling --- Fixed.
[Bug fortran/113384] [14/15 Regression] FAIL: gfortran.dg/array_reference_1.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113384 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- Hi David, I don't see any errors for the four testcases that you have fingered - on: Linux pc30.home 6.2.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 16:51:53 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux with: GNU Fortran (GCC) 15.0.0 20240506 (experimental) Regards Paul
[Bug fortran/114535] [13 regression] ICE with elemental finalizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114535 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:9fd6f7e912415f426382099d6aa182fd2b8ebb82 commit r13-8714-g9fd6f7e912415f426382099d6aa182fd2b8ebb82 Author: Paul Thomas Date: Tue Apr 9 15:27:28 2024 +0100 Fortran: Fix ICE in trans-stmt.cc(gfc_trans_call) [PR114535] 2024-04-09 Paul Thomas gcc/fortran PR fortran/114535 * resolve.cc (resolve_symbol): Remove last chunk that checked for finalization of unreferenced symbols. gcc/testsuite/ PR fortran/114535 * gfortran.dg/pr114535d.f90: New test. * gfortran.dg/pr114535iv.f90: Additional source. (cherry picked from commit de82b0cf981e49a0bda957c0ac31146b17407e23)
[Bug fortran/114535] [13 regression] ICE with elemental finalizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114535 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Paul Thomas --- Fixed on 13- through 15-branch. Thanks for the report. Paul
[Bug fortran/113956] [13 Regression] ice in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113956 --- Comment #8 from GCC Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:102d52967bde164d6b99037465688b62d57ae560 commit r13-8715-g102d52967bde164d6b99037465688b62d57ae560 Author: Paul Thomas Date: Tue Apr 9 15:23:46 2024 +0100 Fortran: Fix ICE in gfc_trans_pointer_assignment [PR113956] 2024-04-09 Paul Thomas gcc/fortran PR fortran/113956 * trans-expr.cc (gfc_trans_pointer_assignment): Remove assert causing the ICE since it was unnecesary. gcc/testsuite/ PR fortran/113956 * gfortran.dg/pr113956.f90: New test. (cherry picked from commit 88aea122a7ee639230bf17a9eda4bf8a5eb7e282)
[Bug fortran/113956] [13 Regression] ice in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113956 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Paul Thomas --- Fixed on 13- through 15-branches. Thanks for the report. Paul
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #13 from LIU Hao ---
I am using a modified patch:
```
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 4d6b2b98761..fbd9b4dac2e 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -25799,6 +25799,24 @@ ix86_bitint_type_info (int n, struct bitint_info
*info)
return true;
}
+/* Returns modified FUNCTION_TYPE for cdtor callabi. */
+tree
+ix86_cxx_adjust_cdtor_callabi_fntype (tree fntype)
+{
+fprintf(stderr, "TARGET_64BIT = %d\n", (bool) TARGET_64BIT);
+fprintf(stderr, "TARGET_RTD = %d\n", (bool) TARGET_RTD);
+fprintf(stderr, "ix86_function_type_abi = %d\n", ix86_function_type_abi
(fntype));
+ if (TARGET_64BIT
+ || TARGET_RTD
+ || ix86_function_type_abi (fntype) != MS_ABI)
+return fntype;
+ /* For 32-bit MS ABI add thiscall attribute. */
+ tree attribs = tree_cons (get_identifier ("thiscall"), NULL_TREE,
+ TYPE_ATTRIBUTES (fntype));
+fprintf(stderr, "__thiscall applied!\n");
+ return build_type_attribute_variant (fntype, attribs);
+}
+
/* Implement PUSH_ROUNDING. On 386, we have pushw instruction that
decrements by exactly 2 no matter what the position was, there is no pushb.
```
There is no message when compiling the testcase:
```
E:\lh_mouse\Desktop>g++ test.cc -Wall -Wextra
: error: conflicting declaration of C function 'int
__cxxabiv1::__cxa_thread_atexit(void (*)(), void*, void*)'
test.cc:3:16: note: previous declaration 'int
__cxxabiv1::__cxa_thread_atexit(void (__attribute__((thiscall)) *)(void*),
void*, void*)'
3 | extern "C" int __cxa_thread_atexit(void (__thiscall* dtor)(void*),
void* obj, void* dso) noexcept;
|^~~
```
So I suspect this is a wrong place to look at.. ?
[Bug fortran/93678] [11/12/13 Regression] ICE with TRANSFER and typebound procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Paul Thomas --- Fixed on 13- through 15-branches. Thanks for the report. Paul
[Bug fortran/93678] [11/12/13 Regression] ICE with TRANSFER and typebound procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678 --- Comment #17 from GCC Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:80bb0bda4a96da7e690cb4df572fcb9604f511f8 commit r13-8716-g80bb0bda4a96da7e690cb4df572fcb9604f511f8 Author: Paul Thomas Date: Thu Apr 25 06:56:10 2024 +0100 Fortran: Fix ICE in gfc_trans_create_temp_array from bad type [PR93678] 2024-04-25 Paul Thomas gcc/fortran PR fortran/93678 * trans-expr.cc (gfc_conv_procedure_call): Use the interface, where possible, to obtain the type of character procedure pointers of class entities. gcc/testsuite/ PR fortran/93678 * gfortran.dg/pr93678.f90: New test. (cherry picked from commit c058105bc47a0701e157d1028e60f48554561f9f)
[Bug fortran/89462] [11/12/13 Regression] gfortran loops in code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89462 --- Comment #17 from GCC Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:ff78ffe8f912bc8d2d355f22d32e1ddb9a1169aa commit r13-8717-gff78ffe8f912bc8d2d355f22d32e1ddb9a1169aa Author: Paul Thomas Date: Thu Apr 25 06:52:31 2024 +0100 Fortran: Generate new charlens for shared symbol typespecs [PR89462] 2024-04-25 Paul Thomas Jakub Jelinek gcc/fortran PR fortran/89462 * decl.cc (build_sym): Add an extra argument 'elem'. If 'elem' is greater than 1, gfc_new_charlen is called to generate a new charlen, registered in the symbol namespace. (variable_decl, enumerator_decl): Set the new argument in the calls to build_sym. gcc/testsuite/ PR fortran/89462 * gfortran.dg/pr89462.f90: New test. (cherry picked from commit 1fd5a07444776d76cdd6a2eee7df0478201197a5)
[Bug fortran/89462] [11/12/13 Regression] gfortran loops in code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89462 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #18 from Paul Thomas --- Fixed on 13- through 15-branches. Thanks for the report. Paul
[Bug tree-optimization/110490] tree-ssa/clz-* and tree-ssa/ctz-* fail on s390x with arch14 (expression_expensive_p not handling if there is wider clz/ctz/popcount optab)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110490 Stefan Schulze Frielinghaus changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Stefan Schulze Frielinghaus --- Fixed.
[Bug tree-optimization/114965] [13/14/15 Regression] wrong code generated for Emacs/Gnulib strftime (regression from 13.2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114965
--- Comment #13 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9adec2d91e62a479474ae79df5b455fd4b8463ba
commit r15-315-g9adec2d91e62a479474ae79df5b455fd4b8463ba
Author: Jakub Jelinek
Date: Wed May 8 10:17:32 2024 +0200
reassoc: Fix up optimize_range_tests_to_bit_test [PR114965]
The optimize_range_tests_to_bit_test optimization normally emits a range
test first:
if (entry_test_needed)
{
tem = build_range_check (loc, optype, unshare_expr (exp),
false, lowi, high);
if (tem == NULL_TREE || is_gimple_val (tem))
continue;
}
so during the bit test we already know that exp is in the [lowi, high]
range, but skips it if we have range info which tells us this isn't
necessary.
Also, normally it emits shifts by exp - lowi counter, but has an
optimization to use just exp counter if the mask isn't a more expensive
constant in that case and lowi is > 0 and high is smaller than prec.
The following testcase is miscompiled because the two abnormal cases
are triggered. The range of exp is [43, 43][48, 48][95, 95], so we on
64-bit arch decide we don't need the entry test, because 95 - 43 < 64.
And we also decide to use just exp as counter, because the range test
tests just for exp == 43 || exp == 48, so high is smaller than 64 too.
Because 95 is in the exp range, we can't do that, we'd either need to
do a range test first, i.e.
if (exp - 43U <= 48U - 43U) if ((1UL << exp) & mask1))
or need to subtract lowi from the shift counter, i.e.
if ((1UL << (exp - 43)) & mask2)
but can't do both unless r.upper_bound () is < prec.
The following patch ensures that.
2024-05-08 Jakub Jelinek
PR tree-optimization/114965
* tree-ssa-reassoc.cc (optimize_range_tests_to_bit_test): Don't try
to
optimize away exp - lowi subtraction from shift count unless entry
test is emitted or unless r.upper_bound () is smaller than prec.
* gcc.c-torture/execute/pr114965.c: New test.
[Bug tree-optimization/114872] [13/14/15 Regression] Miscompilation with -O2 after commit r13-8037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872
--- Comment #23 from Sergei Trofimovich ---
At SIGSEGV site the code is an unconditional NULL dereference due to
dereference of `xor %esi,%esi` result from `gdb`.
797 if (op != _Py_NULL) {
0x7f940c871563 <+2563>: cmpq $0x0,-0xc8(%rbp)
0x7f940c87156b <+2571>: je 0x7f940c871583
<__pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__+2595>
242 return _Py_CAST(PY_INT32_T, op->ob_refcnt) < 0;
0x7f940c87156d <+2573>: xor%esi,%esi
=> 0x7f940c87156f <+2575>: mov(%rsi),%rax
In `element-verbose.S` it is:
# /usr/include/python3.12/object.h:797: if (op != _Py_NULL) {
.loc 5 797 8 is_stmt 0 view .LVU65876
cmpq $0, -200(%rbp)<>#, %sfp
je<>.L12727>#,
.loc 5 798 9 is_stmt 1 view .LVU65877
.LVL15705:
.LBB49946:
.LBI49946:
.loc 5 696 37 view .LVU65878
.LBB49947:
.loc 5 700 5 view .LVU65879
.LBB49948:
.LBI49948:
.loc 5 239 36 view .LVU65880
.LBB49949:
.loc 5 242 5 view .LVU65881
# /usr/include/python3.12/object.h:242: return _Py_CAST(PY_INT32_T,
op->ob_refcnt) < 0;
.loc 5 242 12 is_stmt 0 view .LVU65882
xorl %esi, %esi # r
movq (%rsi), %rax # __pyx_t_6_208(ab)->D.11083.ob_refcnt, _991
Looking at other sites in `element-verbose.S` for comparison do try to use
`-0xc8(%rbp)` contents:
# /usr/include/python3.12/object.h:797: if (op != _Py_NULL) {
.loc 5 797 8 is_stmt 0 view .LVU66162
cmpq $0, -200(%rbp) #, %sfp
je .L12782>#,
.loc 5 798 9 is_stmt 1 view .LVU66163
.LVL15760:
.LBB50093:
.LBI50093:
.loc 5 696 37 view .LVU66164
.LBB50094:
.loc 5 700 5 view .LVU66165
.LBB50095:
.LBI50095:
.loc 5 239 36 view .LVU66166
.LBB50096:
.loc 5 242 5 view .LVU66167
# /usr/include/python3.12/object.h:242: return _Py_CAST(PY_INT32_T,
op->ob_refcnt) < 0;
.loc 5 242 12 is_stmt 0 view .LVU66168
movq -200(%rbp), %rdx # %sfp, r
movq (%rdx), %rax # __pyx_t_6_10(ab)->D.11083.ob_refcnt, _1070
Thus my guess is that something clobbered `-200(%rbp)` value across
setjmp()/longjmp().
Trying to trace:
$ gdb -p `pgrep sage-ipython`
(gdb) break __pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__
(gdb) continue
# trigger break with with ` libgap.AbelianGroup(0,0,0)`
(gdb) disassemble
Dump of assembler code for function
__pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__:
=> 0x7f4ed9981b60 <+0>: push %rbp
0x7f4ed9981b61 <+1>: mov%rsp,%rbp
# Populating `%rbp`:
(gdb) nexti
(gdb) nexti
(gdb) disassemble
Dump of assembler code for function
__pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__:
0x7f4ed9981b60 <+0>: push %rbp
0x7f4ed9981b61 <+1>: mov%rsp,%rbp
=> 0x7f4ed9981b64 <+4>: push %r15
(gdb) print $rbp-200
$2 = (void *) 0x7ffd2824c5e8
(gdb) watch *(int*)(void *) 0x7ffd2824c5e8
Hardware watchpoint 2: *(int*)(void *) 0x7ffd2824c5e8
(gdb) continue
Continuing.
Thread 1 "sage-ipython" hit Hardware watchpoint 2: *(int*)(void *)
0x7ffd2824c5e8
Old value = 673498624
New value = 0
0x7f98e609d2a8 in
__pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__ (
__pyx_v_self=__pyx_v_self@entry=0x7f98dfe70dc0,
__pyx_v_args=__pyx_v_args@entry=(, ,
))
at
/usr/src/debug/sci-mathematics/sagemath-standard-10.3/sagemath-standard-10.3-python3_12/build/cythonized/sage/libs/gap/element.c:26192
26192 __pyx_t_6 = NULL;
NULL store.
(gdb) continue
Continuing.
Thread 1 "sage-ipython" hit Hardware watchpoint 2: *(int*)(void *)
0x7ffd2824c5e8
Old value = 0
New value = -538669696
__Pyx_GetItemInt_List_Fast (wraparound=0, boundscheck=1, i=2,
o=[,
,
])
at
/usr/src/debug/sci-mathematics/sagemath-standard-10.3/sagemath-standard-10.3-python3_12/build/cythonized/sage/libs/gap/element.c:38070
38070 Py_INCREF(r);
Create an object?
(gdb) continue
Continuing.
Thread 1 "sage-ipython" received signal SIGABRT, Aborted.
0x7f99428617a7 in __GI_kill () at ../sysdeps/unix/syscall-template.S:120
120 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
Abort.
(gdb) continue
Continuing.
Thread 1 "sage-ipython" received signal SIGSEGV, Segmentation fault.
0x7f98e609c56f in _Py_IsImmortal (op=0x0) at
/usr/include/python3.12/object.h:242
242 return _Py_CAST(PY_INT32_T, op->ob_refcnt) < 0;
SIGSEGV.
Note that all two memory references happen before longjmp() (the ABORT).
Why did `gcc` generate unconditional NULL dereference here? I suspect it
somehow inferred that `__pyx_t_6 = NULL;` in that branch, but not before
comparison.
[Bug tree-optimization/114965] [13 Regression] wrong code generated for Emacs/Gnulib strftime (regression from 13.2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114965 Jakub Jelinek changed: What|Removed |Added Summary|[13/14/15 Regression] wrong |[13 Regression] wrong code |code generated for |generated for Emacs/Gnulib |Emacs/Gnulib strftime |strftime (regression from |(regression from 13.2) |13.2) --- Comment #15 from Jakub Jelinek --- Fixed for 14.2+ and 15.1+.
[Bug tree-optimization/114965] [13/14/15 Regression] wrong code generated for Emacs/Gnulib strftime (regression from 13.2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114965
--- Comment #14 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:d54151df3ba0ee3203e0b8cb8f8fcd168a766c51
commit r14-10184-gd54151df3ba0ee3203e0b8cb8f8fcd168a766c51
Author: Jakub Jelinek
Date: Wed May 8 10:17:32 2024 +0200
reassoc: Fix up optimize_range_tests_to_bit_test [PR114965]
The optimize_range_tests_to_bit_test optimization normally emits a range
test first:
if (entry_test_needed)
{
tem = build_range_check (loc, optype, unshare_expr (exp),
false, lowi, high);
if (tem == NULL_TREE || is_gimple_val (tem))
continue;
}
so during the bit test we already know that exp is in the [lowi, high]
range, but skips it if we have range info which tells us this isn't
necessary.
Also, normally it emits shifts by exp - lowi counter, but has an
optimization to use just exp counter if the mask isn't a more expensive
constant in that case and lowi is > 0 and high is smaller than prec.
The following testcase is miscompiled because the two abnormal cases
are triggered. The range of exp is [43, 43][48, 48][95, 95], so we on
64-bit arch decide we don't need the entry test, because 95 - 43 < 64.
And we also decide to use just exp as counter, because the range test
tests just for exp == 43 || exp == 48, so high is smaller than 64 too.
Because 95 is in the exp range, we can't do that, we'd either need to
do a range test first, i.e.
if (exp - 43U <= 48U - 43U) if ((1UL << exp) & mask1))
or need to subtract lowi from the shift counter, i.e.
if ((1UL << (exp - 43)) & mask2)
but can't do both unless r.upper_bound () is < prec.
The following patch ensures that.
2024-05-08 Jakub Jelinek
PR tree-optimization/114965
* tree-ssa-reassoc.cc (optimize_range_tests_to_bit_test): Don't try
to
optimize away exp - lowi subtraction from shift count unless entry
test is emitted or unless r.upper_bound () is smaller than prec.
* gcc.c-torture/execute/pr114965.c: New test.
(cherry picked from commit 9adec2d91e62a479474ae79df5b455fd4b8463ba)
[Bug driver/114980] [14/15 Regression] -fdiagnostics-urls=never does not suppress URLs in `'-Werror=' argument '-Werror=...' not valid for ...` warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114980 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.2
[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.2 --- Comment #6 from Richard Biener --- https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=471.407.0 shows a recent improvement that then regressed again, maybe you have a similar artifact with the choosing of the snapshots. Try a snapshot from february for comparison for example.
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968 --- Comment #14 from LIU Hao --- I suspect it's because that `get_atexit_fn_ptr_type` is shared by `atexit` and `__cxa_thread_atexit` but the destructors for them do not use the same calling convention .. So I should make a copy of it, as well as `atexit_fn_ptr_type_node`.
[Bug tree-optimization/114872] [13/14/15 Regression] Miscompilation with -O2 after commit r13-8037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872 --- Comment #24 from Richard Biener --- (In reply to Sergei Trofimovich from comment #23) [...] > Why did `gcc` generate unconditional NULL dereference here? I suspect it > somehow inferred that `__pyx_t_6 = NULL;` in that branch, but not before > comparison. That's what happens if we isolate an unreachable path because of a NULL dereference (like if exposed by jump-threading). We make the NULL dereference volatile so it stays but DCE/DSE can cleanup code on the path leading to it. If you run into such path the this might suggest that jump-threading triggered a problem with the setjmp/longjmp, so it's then likely some condition that's evaluated in a wrong way after the longjmp, either because a dependent value wasn't properly preserved or by GCC breaking that. Seeing stack memory arguments used on a call in a previous comment I wondered if POSIX suggests that even non-register variables need to be made volatile and thus whether SRA or FRE might impose problems with code using setjmp/longjmp.
[Bug middle-end/114975] [AVR] Using popcounthi2 for 8-bit values despite popcountqi2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114975 --- Comment #1 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:c8f4bbb824fafecf021a802324cd79e64b03b947 commit r15-317-gc8f4bbb824fafecf021a802324cd79e64b03b947 Author: Georg-Johann Lay Date: Tue May 7 19:39:55 2024 +0200 AVR: target/114975 - Add combine-pattern for __popcountqi2. PR target/114975 gcc/ * config/avr/avr.md: Add combine pattern for 8-bit popcount detection. gcc/testsuite/ * gcc.target/avr/pr114975-popcount.c: New test.
[Bug middle-end/114975] [AVR] Using popcounthi2 for 8-bit values despite popcountqi2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114975 --- Comment #2 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:41bc359c322d45ec1adfb51f7a45c7ef02ce6ca9 commit r15-318-g41bc359c322d45ec1adfb51f7a45c7ef02ce6ca9 Author: Georg-Johann Lay Date: Tue May 7 19:42:30 2024 +0200 AVR: target/114975 - Add combine-pattern for __parityqi2. PR target/114975 gcc/ * config/avr/avr.md: Add combine pattern for 8-bit parity detection. gcc/testsuite/ * gcc.target/avr/pr114975-parity.c: New test.
[Bug target/114975] [AVR] Using popcounthi2 for 8-bit values despite popcountqi2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114975 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Component|middle-end |target Target Milestone|--- |15.0 --- Comment #3 from Georg-Johann Lay --- Fixed in v15.
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968 --- Comment #15 from LIU Hao --- Created attachment 58124 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58124&action=edit proposed patch v2 Update the patch. Did a quick test on i686-w64-mingw32 and seemed to solve the issue. Rebuilding everything now.
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968 --- Comment #16 from Jakub Jelinek --- What is the reason behind /* mingw32 atexit function is safe to use in shared libraries. Use it to register C++ static destructors. */ #define TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT hook_bool_void_true ? Couldn't we just drop that? I mean, when using atexit, GCC needs to emit wrapper functions around the destructors, like __tcf_0: pushq %rbp .seh_pushreg%rbp movq%rsp, %rbp .seh_setframe %rbp, 0 subq$32, %rsp .seh_stackalloc 32 .seh_endprologue leaq_ZZ3foovE1s(%rip), %rax movq%rax, %rcx call_ZN1SD1Ev nop addq$32, %rsp popq%rbp ret while with __cxa_atexit one can just pass the destructor itself to the __cxa_atexit function (indeed with slightly more instructions there because in addition to the function pointer it needs to pass the address of the object and __dso_handle). But it is still smaller. Anyway, if there is some strong reason to keep it, I think it would be better to avoid adding yet another GTY tree, the __cxa_throw last argument type is the same as __cxa_atexit/__cxa_thread_atexit.
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968 Jakub Jelinek changed: What|Removed |Added Attachment #58123|0 |1 is obsolete|| --- Comment #17 from Jakub Jelinek --- Created attachment 58125 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58125&action=edit gcc15-pr114968.patch Here is an updated patch. Note, even when not taking thiscall attribute into consideration, the existing code was wrong on the !targetm.cxx.use_atexit_for_cxa_atexit () targets (aka mingw), because it would happily use the atexit function argument type (aka void (*) ()) for __cxa_thread_atexit.
[Bug target/114936] [14/15 Regression] Typo in aarch64-ldp-fusion.cc:combine_reg_notes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114936 --- Comment #1 from GCC Commits --- The master branch has been updated by Alex Coplan : https://gcc.gnu.org/g:73c8e24b692e691c665d0f1f5424432837bd8c06 commit r15-320-g73c8e24b692e691c665d0f1f5424432837bd8c06 Author: Alex Coplan Date: Fri May 3 14:12:32 2024 + aarch64: Fix typo in aarch64-ldp-fusion.cc:combine_reg_notes [PR114936] This fixes a typo in combine_reg_notes in the load/store pair fusion pass. As it stands, the calls to filter_notes store any REG_FRAME_RELATED_EXPR to fr_expr with the following association: - i2 -> fr_expr[0] - i1 -> fr_expr[1] but then the checks inside the following if statement expect the opposite (more natural) association, i.e.: - i2 -> fr_expr[1] - i1 -> fr_expr[0] this patch fixes the oversight by swapping the fr_expr indices in the calls to filter_notes. In hindsight it would probably have been less confusing / error-prone to have combine_reg_notes take an array of two insns, then we wouldn't have to mix 1-based and 0-based indexing as well as remembering to call filter_notes in reverse program order. This however is a minimal fix for backporting purposes. gcc/ChangeLog: PR target/114936 * config/aarch64/aarch64-ldp-fusion.cc (combine_reg_notes): Ensure insn iN has its REG_FRAME_RELATED_EXPR (if any) stored in FR_EXPR[N-1], thus matching the correspondence expected by the copy_rtx calls.
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968 --- Comment #18 from LIU Hao --- (In reply to Jakub Jelinek from comment #16) > What is the reason behind > /* mingw32 atexit function is safe to use in shared libraries. Use it >to register C++ static destructors. */ > #define TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT hook_bool_void_true > ? > Couldn't we just drop that? I think so. We have a statically linked `atexit()` much like glibc [1]. However we have added `__cxa_atexit()` a couple of years ago, so it might be preferred. As the Windows system library does not provide `__cxa_*` routines, those functions are also linked statically, so they ignore the DSO handle parameter. [1] https://github.com/mingw-w64/mingw-w64/blob/19cf5d171f6df208b27271b40014c66d2b44e38b/mingw-w64-crt/crt/crtdll.c#L205 [2] https://github.com/mingw-w64/mingw-w64/blob/19cf5d171f6df208b27271b40014c66d2b44e38b/mingw-w64-crt/crt/cxa_atexit.c#L11 > while with __cxa_atexit one can just pass the destructor itself to the > __cxa_atexit function (indeed with slightly more instructions there because > in addition to the function pointer it needs to pass the address of the > object and __dso_handle). > But it is still smaller. Can `./configure --enable-__cxa_atexit` be safely used? Documentation says it's only available with glibc [3], but I don't see any stuff specific to glibc. [3] https://gcc.gnu.org/install/configure.html > Anyway, if there is some strong reason to keep it, I think it would be > better to avoid adding yet another GTY tree, the __cxa_throw last argument > type is the same as __cxa_atexit/__cxa_thread_atexit. Maybe it can be kept for backward compatibility.
[Bug target/114936] [14 Regression] Typo in aarch64-ldp-fusion.cc:combine_reg_notes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114936 Alex Coplan changed: What|Removed |Added Summary|[14/15 Regression] Typo in |[14 Regression] Typo in |aarch64-ldp-fusion.cc:combi |aarch64-ldp-fusion.cc:combi |ne_reg_notes|ne_reg_notes --- Comment #2 from Alex Coplan --- Fixed on trunk, will backport to 14 after a week or so.
[Bug c++/114983] New: The -Wsizeof-array-div warning suppression using extra parenthesis (which is even suggested when in the warning itself) doesn't work inside templated code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114983
Bug ID: 114983
Summary: The -Wsizeof-array-div warning suppression using extra
parenthesis (which is even suggested when in the
warning itself) doesn't work inside templated code.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: patryk.ludwikowski.7 at gmail dot com
CC: polacek at redhat dot com
Target Milestone: ---
The -Wsizeof-array-div warning suppression using extra parenthesis (which is
even suggested when in the warning itself) doesn't work inside templated code,
or: the note in the warning is invalid for use in templated code.
Code snippet to reproduce the problem:
```c++
#include
uint16_t samplesBuffer[40];
template
constexpr inline auto getNumberOfSamples()
{
// No matter how much parentheses are added, warnings still persists
return ((sizeof(samplesBuffer)) / (sizeof(T)));
}
int main()
{
// return sizeof(samplesBuffer) / (sizeof(uint8_t)); // Works fine, no
warning
return getNumberOfSamples(); // Results in warning, how to silence
it?
}
```
Tried on Godbolt https://godbolt.org/z/63YK5dW5o with x86-64 gcc trunk. Other
GCC versions (older and other architectures) also seem affected. By the way,
CLANG compiles fine without warning. For the compiler options, the
-Wsizeof-array-div alone is enough to trigger the bug.
I tried it out on my system as well (sorry for Windows and older GCC version),
the same warning:
```
PS D:\Test> gcc -v
Using built-in specs.
COLLECT_GCC=F:\msys64\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=F:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-13.2.0/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/include --libexecdir=/mingw64/lib
--enable-bootstrap --enable-checking=release --with-arch=nocona
--with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-filesystem-ts --enable-libstdcxx-time
--disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-libssp
--disable-multilib --disable-rpath --disable-win32-registry --disable-nls
--disable-werror --disable-symvers --with-libiconv --with-system-zlib
--with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64
--with-isl=/mingw64 --with-pkgversion='Rev6, Built by MSYS2 project'
--with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as
--with-gnu-ld --disable-libstdcxx-debug --enable-plugin
--with-boot-ldflags=-static-libstdc++ --with-stage1-ldflags=-static-libstdc++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (Rev6, Built by MSYS2 project)
PS D:\Test> gcc test.cpp -Wsizeof-array-div
test.cpp: In instantiation of 'constexpr auto getNumberOfSamples() [with T =
unsigned char]':
test.cpp:15:36: required from here
test.cpp:9:41: warning: expression does not compute the number of elements in
this array; element type is 'uint16_t' {aka 'short unsigned int'}, not
'unsigned char' [-Wsizeof-array-div]
9 | return ((sizeof(samplesBuffer)) / (sizeof(T)));
|~^~
test.cpp:9:44: note: add parentheses around 'sizeof (unsigned char)' to silence
this warning
9 | return ((sizeof(samplesBuffer)) / (sizeof(T)));
| ~^~
| ( )
test.cpp:3:10: note: array 'samplesBuffer' declared here
3 | uint16_t samplesBuffer[40];
| ^
```
Please note that the warning is correct, because T is not guaranteed to be the
array element type. IMO it would be nice if the warning was not thrown in this
case, or if there was other way of silencing it. Either way the note about
adding parentheses is wrong in this case for sure.
I added CC to pola...@redhat.com because they seem to be the person who
implemented it (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91741 / mail
thread https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553888.html),
no intention of blaming or anything, just they might be interested, idk.
Workaround by diagnostic macros can be used for GCC:
```c++
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wsizeof-array-div"
return sizeof(samplesBuffer) / (sizeof(T));
#pragma GCC diagnostic pop
```
Let me know if something more is needed, it's my frist bug report here.
[Bug target/114984] New: asm() renaming of symbols inconsistent with dllimport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114984
Bug ID: 114984
Summary: asm() renaming of symbols inconsistent with dllimport
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at martin dot st
Target Milestone: ---
A function declaration can use asm("") to point out that the function actually
exists under a different symbol name. E.g. like this:
$ cat call-bar.c
extern void foo (void) asm("bar");
void call_bar(void)
{ foo(); }
$ x86_64-w64-mingw32-gcc -S -O2 -o - call-bar.c
call_bar:
jmp bar
On i686, where symbols normally have an extra underscore prefix (signaled via
__USER_LABEL_PREFIX__), the symbol name in asm() is taken literally, so one has
to include the underscore prefix manually:
$ cat call-bar.c
extern void foo (void) asm("_bar");
void call_bar(void)
{ foo(); }
$ i686-w64-mingw32-gcc -S -O2 -o - call-bar.c
_call_bar:
jmp _bar
If the renamed function is declared with dllimport, however, GCC suddenly
treats the symbol name given with asm("") as an undecorated one, that gets the
extra implicit underscore added.
$ cat call-bar2.c
extern __declspec(dllimport) void foo1 (void) asm("_bar");
extern __declspec(dllimport) void foo2 (void);
void call_bar(void)
{ foo1(); foo2(); }
$ /usr/bin/i686-w64-mingw32-gcc -S -O2 -o - call-bar2.c -O2
_call_bar:
subl$12, %esp
call*__imp___bar
addl$12, %esp
jmp *__imp__foo2
Regularly, when adding dllimport, it references a symbol named "__imp_"
followed by the symbol name used without dllimport, i.e. a non-dllimport call
to "foo2" would reference "_foo2", while a dllimport call references
"__imp__foo2".
Therefore, it is surprising and inconsistent that dllimport together with asm()
implicitly includes __USER_LABEL_PREFIX__, while asm() without dllimport
doesn't.
This issue was reported already in 2007 in
https://sourceware.org/pipermail/cygwin/2007-February/154845.html, with an
intent to send a patch, but I find no traces of such a patch.
To fully show off all combinations in one example, consider:
$ cat sym-asm.c
void regular(void);
void __declspec(dllimport) imported(void);
void renamed(void) asm("newname");
void __declspec(dllimport) renamedimported(void) asm("newimportedname");
void call(void) {
regular();
imported();
renamed();
renamedimported();
}
$ i686-w64-mingw32-gcc -S -O2 -o - sym-asm.c
_call:
subl$12, %esp
call_regular
call*__imp__imported
callnewname
addl$12, %esp
jmp *__imp__newimportedname
Contrary, Clang does seem to handle this consistently:
$ clang -target i686-w64-mingw32 -S -O2 -o - sym-asm.c
_call:
calll _regular
calll *__imp__imported
calll newname
jmpl*__imp_newimportedname
I.e., when naming the symbol asm("newimportedname"), this singifies the literal
string that would be included after "__imp_", i.e. the user need to include
__USER_LABEL_PREFIX__ within asm("").
[Bug target/114984] asm() renaming of symbols inconsistent with dllimport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114984
--- Comment #1 from Martin Storsjö ---
The suggestion in
https://sourceware.org/pipermail/cygwin/2007-February/154845.html was that for
dllimported symbols, the string passed in asm("") should be entirely literal,
i.e. no implicit "__imp_" prepended.
While I can agree that this would be reasonable, it would differ even more from
what Clang already does (which is self consistent). So I believe the most
consistent and straightforward fix would be to make GCC prepend "__imp_" before
the string from asm(""), for dllimport symbols, instead of "__imp__".
[Bug target/114984] asm() renaming of symbols inconsistent with dllimport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114984
--- Comment #2 from Martin Storsjö ---
To clarify the concern for changing whether "__imp_" is implied for asm("") on
dllimported symbols or not; on all other mingw architectures than i386, there's
no extra symbol prefix, so the current behaviour there works just fine and is
reasonably consistent.
Thus, by only fixing the extra underscore prefix, the only case that changes is
i386 + dllimport + asm(), while if we'd require the whole "__imp_" prefix to be
specified, we'd affect all other architectures as well (which are well off as
they are).
[Bug ipa/92606] [11 Regression][avr] invalid merge of symbols in progmem and data sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606 Richard Biener changed: What|Removed |Added Summary|[11/12/13 Regression][avr] |[11 Regression][avr] |invalid merge of symbols in |invalid merge of symbols in |progmem and data sections |progmem and data sections Priority|P2 |P4 --- Comment #37 from Richard Biener --- Tracking AVR PROGMEM here, the referenced PR is about the general IPA issue.
[Bug rtl-optimization/99015] [11/12/13 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99015 Richard Biener changed: What|Removed |Added Last reconfirmed|2022-01-21 00:00:00 |2024-5-8 Keywords||needs-bisection --- Comment #7 from Richard Biener --- What fixed it?
[Bug rtl-optimization/101188] [11/12/13 Regression] [postreload] Uses content of a clobbered register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/113396] [13 Regression] csmith: differences from -O2 to -O3 since r13-1268-g8c99e307b20c50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #34 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:7baefcb0a358a47a7e2340432d49f29db798a200 commit r13-8718-g7baefcb0a358a47a7e2340432d49f29db798a200 Author: Richard Biener Date: Tue Mar 19 15:25:16 2024 +0100 middle-end/113396 - int128 array index and value-ranges The following fixes bogus truncation of a value-range for an int128 array index when computing the maximum extent for a variable array reference. Instead of possibly slowing things down by using widest_int the following makes sure the range bounds fit within the constraints offset_int were designed for. PR middle-end/113396 * tree-dfa.cc (get_ref_base_and_extent): Use index range bounds only if they fit within the address-range constraints of offset_int. * gcc.dg/torture/pr113396.c: New testcase. (cherry picked from commit 6a55e39bdb1fdb570730c08413ebbe744e493411)
[Bug tree-optimization/112281] [12/13 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-2097-g9f34b780b0461e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112281 --- Comment #13 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:0b409fc34e9b1ff7f90456e73128e38970c1532b commit r13-8720-g0b409fc34e9b1ff7f90456e73128e38970c1532b Author: Richard Biener Date: Mon Nov 20 13:39:52 2023 +0100 tree-optimization/112281 - loop distribution and zero dependence distances The following fixes an omission in dependence testing for loop distribution. When the overall dependence distance is not zero but the dependence direction in the innermost common loop is = there is a conflict between the partitions and we have to merge them. PR tree-optimization/112281 * tree-loop-distribution.cc (loop_distribution::pg_add_dependence_edges): For = in the innermost common loop record a partition conflict. * gcc.dg/torture/pr112281-1.c: New testcase. * gcc.dg/torture/pr112281-2.c: Likewise. (cherry picked from commit 3b34902417259031823bff7f853f615a60464bbd)
[Bug tree-optimization/112961] [13 Regression] middle-end Missed vectorization: failed to vectorize simple reduction max since GCC-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112961 --- Comment #11 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:25add4b65a3bac262685d290a4dc93884a022576 commit r13-8719-g25add4b65a3bac262685d290a4dc93884a022576 Author: Richard Biener Date: Wed Dec 13 08:45:58 2023 +0100 tree-optimization/112991 - re-do PR112961 fix The following does away with the fake edge adding as in the original PR112961 fix and instead exposes handling of entry PHIs as additional parameter of the region VN run. PR tree-optimization/112991 PR tree-optimization/112961 * tree-ssa-sccvn.h (do_rpo_vn): Add skip_entry_phis argument. * tree-ssa-sccvn.cc (do_rpo_vn): Likewise. (do_rpo_vn_1): Likewise, merge with auto-processing. (run_rpo_vn): Adjust. (pass_fre::execute): Likewise. * tree-if-conv.cc (tree_if_conversion): Revert last change. Value-number latch block but disable value-numbering of entry PHIs. * tree-ssa-uninit.cc (execute_early_warn_uninitialized): Adjust. * gcc.dg/torture/pr112991.c: New testcase. * g++.dg/vect/pr112961.cc: Likewise. (cherry picked from commit 93db32a4146afd2a6d90410691351a56768167c9)
[Bug tree-optimization/112991] [14 Regression] ICE during GIMPLE pass: ifcvt on p7zip-17.05 since r14-6457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112991 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:25add4b65a3bac262685d290a4dc93884a022576 commit r13-8719-g25add4b65a3bac262685d290a4dc93884a022576 Author: Richard Biener Date: Wed Dec 13 08:45:58 2023 +0100 tree-optimization/112991 - re-do PR112961 fix The following does away with the fake edge adding as in the original PR112961 fix and instead exposes handling of entry PHIs as additional parameter of the region VN run. PR tree-optimization/112991 PR tree-optimization/112961 * tree-ssa-sccvn.h (do_rpo_vn): Add skip_entry_phis argument. * tree-ssa-sccvn.cc (do_rpo_vn): Likewise. (do_rpo_vn_1): Likewise, merge with auto-processing. (run_rpo_vn): Adjust. (pass_fre::execute): Likewise. * tree-if-conv.cc (tree_if_conversion): Revert last change. Value-number latch block but disable value-numbering of entry PHIs. * tree-ssa-uninit.cc (execute_early_warn_uninitialized): Adjust. * gcc.dg/torture/pr112991.c: New testcase. * g++.dg/vect/pr112961.cc: Likewise. (cherry picked from commit 93db32a4146afd2a6d90410691351a56768167c9)
[Bug middle-end/113396] [13 Regression] csmith: differences from -O2 to -O3 since r13-1268-g8c99e307b20c50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 Richard Biener changed: What|Removed |Added Known to fail||13.2.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Known to work||13.2.1 --- Comment #35 from Richard Biener --- Fixed.
[Bug tree-optimization/112961] [13 Regression] middle-end Missed vectorization: failed to vectorize simple reduction max since GCC-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112961 Richard Biener changed: What|Removed |Added Known to fail||13.2.0 Known to work||13.2.1 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Richard Biener --- Fixed.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 112961, which changed state. Bug 112961 Summary: [13 Regression] middle-end Missed vectorization: failed to vectorize simple reduction max since GCC-13 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112961 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/110116] [12/13 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110116 Richard Biener changed: What|Removed |Added Known to fail||13.2.0 Status|NEW |RESOLVED Known to work||12.3.1, 13.2.1 Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Meanwhile fixed.
[Bug middle-end/111009] [12/13 regression] -fno-strict-overflow erroneously elides null pointer checks and causes SIGSEGV on perf from linux-6.4.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |amacleod at redhat dot com Status|NEW |ASSIGNED --- Comment #13 from Richard Biener --- Andrew - this doesn't pick to gcc-13 because of the following but we should backport the fix somehow. Can you please see to that in time for GCC 13.3 (next week)? /space/rguenther/src/gcc-13-branch/gcc/range-op.cc: In member function ‘virtual bool operator_addr_expr::op1_range(irange&, tree, const irange&, const irange&, relation_trio) const’: /space/rguenther/src/gcc-13-branch/gcc/range-op.cc:4366:8: error: ‘contains_zero_p’ was not declared in this scope if (!contains_zero_p (lhs) && TYPE_OVERFLOW_UNDEFINED (type)) ^~~ /space/rguenther/src/gcc-13-branch/gcc/range-op.cc:4366:8: note: suggested alternative: ‘contains_mem_rtx_p’ if (!contains_zero_p (lhs) && TYPE_OVERFLOW_UNDEFINED (type)) ^~~ contains_mem_rtx_p
[Bug analyzer/107750] [13/14/15 Regression] Many gcc.dg/analyzer/fd-*.c tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107750 --- Comment #6 from Rainer Orth --- David, after your amazing work on PR analyzer/111475, there are only a handful of analyzer failures left on trunk: FAIL: gcc.dg/analyzer/fd-accept.c (test for excess errors) FAIL: gcc.dg/analyzer/fd-accept.c final event at line 58 (test for warnings, line 57) FAIL: gcc.dg/analyzer/fd-accept.c warning (test for warnings, line 57) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 19) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 27) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 32) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 39) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 55) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for excess errors) FAIL: gcc.dg/analyzer/fd-connect.c (test for warnings, line 35) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 13) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 32) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 38) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 50) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 72) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 83) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 86) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 94) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 98) FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for excess errors) FAIL: gcc.dg/analyzer/fd-datagram-socket.c final event at line 110 (test for warnings, line 109) FAIL: gcc.dg/analyzer/fd-datagram-socket.c final event at line 88 (test for warnings, line 87) FAIL: gcc.dg/analyzer/fd-datagram-socket.c warning (test for warnings, line 109) FAIL: gcc.dg/analyzer/fd-datagram-socket.c warning (test for warnings, line 87) FAIL: gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c (test for excess errors) FAIL: gcc.dg/analyzer/fd-listen.c (test for excess errors) FAIL: gcc.dg/analyzer/fd-listen.c final event at line 55 (test for warnings, line 54) FAIL: gcc.dg/analyzer/fd-listen.c warning (test for warnings, line 54) FAIL: gcc.dg/analyzer/fd-socket-misuse.c (test for warnings, line 18) FAIL: gcc.dg/analyzer/fd-socket-misuse.c (test for excess errors) FAIL: gcc.dg/analyzer/fd-socket-misuse.c final event at line 22 (test for warnings, line 21) FAIL: gcc.dg/analyzer/fd-socket-misuse.c warning (test for warnings, line 21) FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line 21) FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line 32) FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line 39) FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line 47) FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for excess errors) FAIL: gcc.dg/analyzer/fd-stream-socket-passive-open.c (test for warnings, line 27) FAIL: gcc.dg/analyzer/fd-stream-socket-passive-open.c (test for warnings, line 35) FAIL: gcc.dg/analyzer/fd-stream-socket-passive-open.c (test for warnings, line 41) FAIL: gcc.dg/analyzer/fd-stream-socket-passive-open.c (test for warnings, line 46) FAIL: gcc.dg/analyzer/fd-stream-socket-passive-open.c (test for excess errors) FAIL: gcc.dg/analyzer/fd-stream-socket.c (test for warnings, line 13) FAIL: gcc.dg/analyzer/fd-stream-socket.c (test for warnings, line 37) FAIL: gcc.dg/analyzer/fd-stream-socket.c (test for warnings, line 70) FAIL: gcc.dg/analyzer/fd-stream-socket.c (test for warnings, line 81) FAIL: gcc.dg/analyzer/fd-stream-socket.c (test for warnings, line 92) As an example, I looked into fd-accept.c, which shows those differences between Linux and Solaris output: --- /homes/ro/fd-accept.out.i.linux 2024-05-08 13:19:07.595246605 +0200 +++ fd-accept.out.i 2024-05-08 13:23:30.986283368 +0200 @@ -23,2 +23,2 @@ -/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-accept.c:57:3: warning: ‘accept’ on datagram socket file descriptor ‘fd’ [-Wanalyzer-fd-type-mismatch] -/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-accept.c:54:12: note: (1) datagram socket created here +/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-accept.c:57:3: warning: ‘accept’ on file descriptor ‘fd’ in wrong phase [CWE-666] [-Wanalyzer-fd-phase-mismatch] +/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-accept.c:54:12: note: (1) socket created here @@ -28 +28 @@ -/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-accept.c:57:3: note: (5) ‘accept’ expects a stream socket file descriptor but ‘fd’ is a datagram socket +/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-accept.c:57:3: note: (5) ‘accept’ expects a listening stream socket
[Bug c++/111356] [13 Regression] Segmentation fault when compiling large static data structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111356 Richard Biener changed: What|Removed |Added Known to work||13.2.1 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- As far as I can see this has been fixed on the branch.
[Bug tree-optimization/111472] [11 Regression] Wrong code at -Os on x86_64-linux-gnu since r11-4563-gd0d8b5d836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111472 Richard Biener changed: What|Removed |Added Known to work||12.3.1, 13.2.1 Known to fail||12.3.0, 13.2.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED Last reconfirmed|2023-09-19 00:00:00 |2024-5-8 Priority|P3 |P2 Summary|[11/12/13 Regression] Wrong |[11 Regression] Wrong code |code at -Os on |at -Os on x86_64-linux-gnu |x86_64-linux-gnu since |since r11-4563-gd0d8b5d836 |r11-4563-gd0d8b5d836| --- Comment #7 from Richard Biener --- Re-confirmed on the 11 branch, fixed/avoided on newer branches by the backport of referenced bug.
[Bug c++/111529] [11/12/13 Regression] ICE on bool conversion in an unrolled loop condition inside template lambda nested in another template scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111529 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED Priority|P3 |P2
[Bug ipa/111571] [13 Regression] ICE in modify_call, at ipa-param-manipulation.cc:656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111571 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Known to work||13.2.1 Known to fail||13.2.0 Status|ASSIGNED|RESOLVED --- Comment #8 from Richard Biener --- Fixed.
[Bug sanitizer/112727] [11/12/13 Regression] UBSAN creates GIMPLE path with uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112727 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #13 from Richard Biener --- Fixed I guess.
[Bug target/113690] [13 Regression] ICE: in as_a, at machmode.h:381 with -O2 -fno-dce -fno-forward-propagate -fno-split-wide-types -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113690 --- Comment #7 from Richard Biener --- I think it's worth backporting if there was no known fallout from the change.
[Bug middle-end/114196] [13 Regression] Fixed length vector ICE: in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9454
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114196 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rdapp at gcc dot gnu.org --- Comment #6 from Richard Biener --- I've recently backported a related change - can you check if the issue is solved on the 13 branch now?
[Bug tree-optimization/114375] [11/12/13 Regression] Wrong vectorization of permuted mask load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114375 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug rtl-optimization/114415] [13 Regression] wrong code with -Oz -fno-dce -fno-forward-propagate -flive-range-shrinkage -fweb since r13-1826
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Known to work||13.2.0 Assignee|unassigned at gcc dot gnu.org |vmakarov at gcc dot gnu.org
[Bug target/114432] [13/14/15 Regression] ICE in connect_traces, at dwarf2cfi.cc:3079 on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114432 Richard Biener changed: What|Removed |Added Summary|[13 Regression] ICE in |[13/14/15 Regression] ICE |connect_traces, at |in connect_traces, at |dwarf2cfi.cc:3079 on|dwarf2cfi.cc:3079 on |s390x-linux-gnu |s390x-linux-gnu Priority|P3 |P2
[Bug target/114432] [13/14/15 Regression] ICE in connect_traces, at dwarf2cfi.cc:3079 on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114432 Richard Biener changed: What|Removed |Added Last reconfirmed|2024-04-17 00:00:00 |2024-05-08 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug lto/112732] during IPA pass: *free_lang_data ICE: 'verify_type' failed: type variant with 'TYPE_ALIAS_SET_KNOWN_P' with -Os -Wstrict-aliasing=2 -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112732 --- Comment #5 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:664ab9c6e8a5d031031596100997e025e5334e86 commit r13-8721-g664ab9c6e8a5d031031596100997e025e5334e86 Author: Richard Biener Date: Tue Nov 28 12:36:21 2023 +0100 middle-end/112732 - stray TYPE_ALIAS_SET in type variant The following fixes a stray TYPE_ALIAS_SET in a type variant built by build_opaque_vector_type which is diagnosed by type checking enabled with -flto. PR middle-end/112732 * tree.cc (build_opaque_vector_type): Reset TYPE_ALIAS_SET of the newly built type. (cherry picked from commit f26d68d5d128c86faaceeb81b1e8f22254ad53df)
[Bug c++/97990] [11/12/13 Regression] ICE: ‘verify_type’ failed with vector types and non-PODs since r6-5222-gba6a6a1d44c17f25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97990 --- Comment #14 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:a0f59eb899d151727ee965f900d57dc0395b47df commit r13-8722-ga0f59eb899d151727ee965f900d57dc0395b47df Author: Andrew Pinski Date: Fri Feb 16 10:55:43 2024 -0800 c++: Add testcase for this PR [PR97990] This testcase was fixed by r14-5934-gf26d68d5d128c8 but we should add one to make sure it does not regress again. Committed as obvious after a quick test on the testcase. PR c++/97990 gcc/testsuite/ChangeLog: * g++.dg/torture/vector-struct-1.C: New test. Signed-off-by: Andrew Pinski (cherry picked from commit 5f1438db419c9eb8901d1d1d7f98fb69082aec8e)
[Bug target/110792] [13 Regression] GCC 13 x86_32 miscompilation of Whirlpool hash function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110792 --- Comment #18 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:3658dafc65a2b64989a0aa3b4007356d638f1bfa commit r13-8723-g3658dafc65a2b64989a0aa3b4007356d638f1bfa Author: Roger Sayle Date: Thu Aug 3 07:12:04 2023 +0100 PR target/110792: Early clobber issues with rot32di2_doubleword on i386. This patch is a conservative fix for PR target/110792, a wrong-code regression affecting doubleword rotations by BITS_PER_WORD, which effectively swaps the highpart and lowpart words, when the source to be rotated resides in memory. The issue is that if the register used to hold the lowpart of the destination is mentioned in the address of the memory operand, the current define_insn_and_split unintentionally clobbers it before reading the highpart. Hence, for the testcase, the incorrectly generated code looks like: salq$4, %rdi// calculate address movqWHIRL_S+8(%rdi), %rdi // accidentally clobber addr movqWHIRL_S(%rdi), %rbp // load (wrong) lowpart Traditionally, the textbook way to fix this would be to add an explicit early clobber to the instruction's constraints. (define_insn_and_split "32di2_doubleword" - [(set (match_operand:DI 0 "register_operand" "=r,r,r") + [(set (match_operand:DI 0 "register_operand" "=r,r,&r") (any_rotate:DI (match_operand:DI 1 "nonimmediate_operand" "0,r,o") (const_int 32)))] but unfortunately this currently generates significantly worse code, due to a strange choice of reloads (effectively memcpy), which ends up looking like: salq$4, %rdi// calculate address movdqa WHIRL_S(%rdi), %xmm0// load the double word in SSE reg. movaps %xmm0, -16(%rsp)// store the SSE reg back to the stack movq-8(%rsp), %rdi // load highpart movq-16(%rsp), %rbp // load lowpart Note that reload's "&" doesn't distinguish between the memory being early clobbered, vs the registers used in an addressing mode being early clobbered. The fix proposed in this patch is to remove the third alternative, that allowed offsetable memory as an operand, forcing reload to place the operand into a register before the rotation. This results in: salq$4, %rdi movqWHIRL_S(%rdi), %rax movqWHIRL_S+8(%rdi), %rdi movq%rax, %rbp I believe there's a more advanced solution, by swapping the order of the loads (if first destination register is mentioned in the address), or inserting a lea insn (if both destination registers are mentioned in the address), but this fix is a minimal "safe" solution, that should hopefully be suitable for backporting. 2023-08-03 Roger Sayle gcc/ChangeLog PR target/110792 * config/i386/i386.md (ti3): For rotations by 64 bits place operand in a register before gen_64ti2_doubleword. (di3): Likewise, for rotations by 32 bits, place operand in a register before gen_32di2_doubleword. (32di2_doubleword): Constrain operand to be in register. (64ti2_doubleword): Likewise. gcc/testsuite/ChangeLog PR target/110792 * g++.target/i386/pr110792.C: New 32-bit C++ test case. * gcc.target/i386/pr110792.c: New 64-bit C test case. (cherry picked from commit 790c1f60a5662b16eb19eb4b81922995863c7571)
[Bug tree-optimization/111268] [11/12/13 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111268 --- Comment #20 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:b0632c06a7f61d3b42170d51aa5b88237a722ae0 commit r13-8725-gb0632c06a7f61d3b42170d51aa5b88237a722ae0 Author: Richard Ball Date: Thu Feb 1 17:18:28 2024 + middle-end: Fix ICE in poly-int.h due to SLP. Adds a check to ensure that the input vector arguments to a function are not variable length. Previously, only the output vector of a function was checked. The ICE in question is within the neon-sve-bridge.c test, and is related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111268 gcc/ChangeLog: PR tree-optimization/111268 * tree-vect-slp.cc (vectorizable_slp_permutation_1): Add variable-length check for vector input arguments to a function. (cherry picked from commit 4571b4d413a4ba5f1e2d429a2623180ad1c73c0f)
[Bug target/110792] [13 Regression] GCC 13 x86_32 miscompilation of Whirlpool hash function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110792 --- Comment #19 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:3367f78ff92971ac21c67c5d82df988863605f84 commit r13-8724-g3367f78ff92971ac21c67c5d82df988863605f84 Author: Roger Sayle Date: Sun Aug 6 23:19:10 2023 +0100 [Committed] Avoid FAIL of gcc.target/i386/pr110792.c My apologies (again), I managed to mess up the 64-bit version of the test case for PR 110792. Unlike the 32-bit version, the 64-bit case contains exactly the same load instructions, just in a different order making the correct and incorrect behaviours impossible to distinguish with a scan-assembler-not. Somewhere between checking that this test failed in a clean tree without the patch, and getting the escaping correct, I'd failed to notice that this also FAILs in the patched tree. Doh! Instead of removing the test completely, I've left it as a compilation test. The original fix is tested by the 32-bit test case. Committed to mainline as obvious. Sorry for the incovenience. 2023-08-06 Roger Sayle gcc/testsuite/ChangeLog PR target/110792 * gcc.target/i386/pr110792.c: Remove dg-final scan-assembler-not. (cherry picked from commit 529909f9e92dd3b0ed0383f45a44d2b5f8a58958)
[Bug c++/97990] [11/12 Regression] ICE: ‘verify_type’ failed with vector types and non-PODs since r6-5222-gba6a6a1d44c17f25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97990 Richard Biener changed: What|Removed |Added Summary|[11/12/13 Regression] ICE: |[11/12 Regression] ICE: |‘verify_type’ failed with |‘verify_type’ failed with |vector types and non-PODs |vector types and non-PODs |since |since |r6-5222-gba6a6a1d44c17f25 |r6-5222-gba6a6a1d44c17f25 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Keywords||ice-checking Status|NEW |ASSIGNED
[Bug target/110792] [13 Regression] GCC 13 x86_32 miscompilation of Whirlpool hash function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110792 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Known to work||13.2.1 Known to fail||13.2.0 Status|ASSIGNED|RESOLVED Priority|P3 |P2 --- Comment #20 from Richard Biener --- Should be fixed.
[Bug tree-optimization/111268] [11/12 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111268 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug tree-optimization/111882] [13 Regression] : internal compiler error: in get_expr_operand in ifcvt with Variable length arrays and bitfields inside a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111882 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Fixed.
[Bug bootstrap/114985] New: [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 Bug ID: 114985 Summary: [15 regression] internal compiler error: in discriminator_fail during stage2 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- I am looking for the source but this is the failure: /home/seurer/gcc/git/build/gcc-trunk-bootstrap/./prev-gcc/xg++ -B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./prev-gcc/ -B/home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/bin/ -nostdinc++ -B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/libsupc++ -L/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -DIN_GCC_FRONTEND -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -fno-PIE -I. -Ic -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/c -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../include -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libcpp/include -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libcody -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./gmp -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gmp -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./mpfr/src -I/home/seurer/gcc/git/gcc-trunk-bootstrap/mpfr/src -I/home/seurer/gcc/git/gcc-trunk-bootstrap/mpc/src -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libdecnumber -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libbacktrace -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./isl/include -I/home/seurer/gcc/git/gcc-trunk-bootstrap/isl/include -o c/c-parser.o -MT c/c-parser.o -MMD -MP -MF c/.deps/c-parser.TPo /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/c/c-parser.cc DISCRIMINATOR FAIL. Dispatch > RO_PPP < during IPA pass: inline In file included from /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/c/c-parser.cc:26971: ./gt-c-c-parser.h:94:2: internal compiler error: in discriminator_fail, at range-op.cc:204 94 | }; | ^ 0x11993d23 range_op_handler::discriminator_fail(vrange const&, vrange const&, vrange const&) const /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/range-op.cc:204 0x11993fff range_op_handler::fold_range(vrange&, tree_node*, vrange const&, vrange const&, relation_trio) const /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/range-op.cc:228 0x13198197 ipa_value_range_from_jfunc(vrange&, ipa_node_params*, cgraph_edge*, ipa_jump_func*, tree_node*) /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/ipa-cp.cc:1743 0x116214e3 evaluate_properties_for_edge(cgraph_edge*, bool, unsigned int*, unsigned int*, ipa_auto_call_arg_values*, bool) /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/ipa-fnsummary.cc:680 0x116567d3 do_estimate_edge_size(cgraph_edge*) /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/ipa-inline-analysis.cc:337 0x11657ab7 estimate_edge_size(cgraph_edge*) /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/ipa-inline.h:79 0x11657ba3 estimate_edge_growth(cgraph_edge*) /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/ipa-inline.h:100 0x11656d0b do_estimate_growth_1 /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/ipa-inline-analysis.cc:436 0x11176bcf cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*, void*), void*, bool) /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/cgraph.h:3429 0x11656fbb estimate_growth(cgraph_node*) /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/ipa-inline-analysis.cc:474 0x131cb18f inline_small_functions /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/ipa-inline.cc:2081 0x131ce89b ipa_inline /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/ipa-inline.cc:2850 0x131cfc6b execute /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/ipa-inline.cc:3248
[Bug rtl-optimization/114924] [11/12/13 Regression] Wrong update of MEM_EXPR by RTL loop unrolling since r11-2963-gd6a05b494b4b71
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114924 --- Comment #3 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:c63704a2d840436797f54e175a2af0cb029889d2 commit r13-8726-gc63704a2d840436797f54e175a2af0cb029889d2 Author: Alex Coplan Date: Fri May 3 09:23:59 2024 +0100 cfgrtl: Fix MEM_EXPR update in duplicate_insn_chain [PR114924] The PR shows that when cfgrtl.cc:duplicate_insn_chain attempts to update the MR_DEPENDENCE_CLIQUE information for a MEM_EXPR we can end up accidentally dropping (e.g.) an ARRAY_REF from the MEM_EXPR and end up replacing it with the underlying MEM_REF. This leads to an inconsistency in the MEM_EXPR information, and could lead to wrong code. While the walk down to the MEM_REF is necessary to update MR_DEPENDENCE_CLIQUE, we should use the outer tree expression for the MEM_EXPR. This patch does that. gcc/ChangeLog: PR rtl-optimization/114924 * cfgrtl.cc (duplicate_insn_chain): When updating MEM_EXPRs, don't strip (e.g.) ARRAY_REFs from the final MEM_EXPR. (cherry picked from commit fe40d525619eee9c2821126390df75068df4773a)
[Bug tree-optimization/114375] [11/12/13 Regression] Wrong vectorization of permuted mask load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114375 --- Comment #5 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:4f2a35a76cca503749c696e7772d2e8eadc77ba5 commit r13-8727-g4f2a35a76cca503749c696e7772d2e8eadc77ba5 Author: Richard Biener Date: Mon Mar 18 12:39:03 2024 +0100 tree-optimization/114375 - disallow SLP discovery of permuted mask loads We cannot currently handle permutations of mask loads in code generation or permute optimization. But we simply drop any permutation on the floor, so the following instead rejects the SLP build rather than producing wrong-code. I've also made sure to reject them in vectorizable_load for completeness. PR tree-optimization/114375 * tree-vect-slp.cc (vect_build_slp_tree_2): Compute the load permutation for masked loads but reject it when any such is necessary. * tree-vect-stmts.cc (vectorizable_load): Reject masked VMAT_ELEMENTWISE and VMAT_STRIDED_SLP as those are not supported. * gcc.dg/vect/vect-pr114375.c: New testcase. (cherry picked from commit 94c3508c5a14d1948fe3bffa9e16c6f3d9c2836a)
[Bug c++/109753] [13/14/15 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 --- Comment #16 from Jason Merrill --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650439.html
[Bug c++/114986] New: Seemingly incorrect "ignoring packed attribute" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114986
Bug ID: 114986
Summary: Seemingly incorrect "ignoring packed attribute"
warning
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
The following program
```
#include
#include
struct uuid
{
std::uint8_t data[ 16 ] = {};
};
struct __attribute__((packed)) X
{
uuid a;
unsigned char b;
unsigned c;
unsigned char d;
};
static_assert( offsetof(X, c) == 17 );
static_assert( sizeof(X) == 22 );
```
(https://godbolt.org/z/WvxjM3eqn)
gives
```
:11:10: warning: ignoring packed attribute because of unpacked non-POD
field 'uuid X::a'
```
However, the attribute is applied, because the static assertions pass.
If `__attribute__((packed))` is removed, the assertions (correctly) fail
(https://godbolt.org/z/hP4oG98fq).
Therefore, the warning seems wrong.
GCC 14, 13, 12 warn; 11 and earlier do not.
[Bug c++/114983] The -Wsizeof-array-div warning suppression using extra parenthesis (which is suggested by in the warning itself) doesn't work inside templated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114983 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Last reconfirmed||2024-05-08 Status|UNCONFIRMED |ASSIGNED
[Bug tree-optimization/81953] Code sinking increases register pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81953 --- Comment #8 from GCC Commits --- The master branch has been updated by Ajit Kumar Agarwal : https://gcc.gnu.org/g:f4b86ab09dfe258c4780fcc7567ca8a275c96e7a commit r15-327-gf4b86ab09dfe258c4780fcc7567ca8a275c96e7a Author: Ajit Kumar Agarwal Date: Wed May 8 09:21:27 2024 -0500 tree-ssa-sink: Improve code sinking pass Currently, code sinking will sink code at the use points with loop having same nesting depth. The following patch improves code sinking by placing the sunk code in begining of the block after the labels. 2024-05-08 Ajit Kumar Agarwal gcc/ChangeLog: PR tree-optimization/81953 * tree-ssa-sink.cc (statement_sink_location):Sink statements at the begining of the basic block after labels. gcc/testsuite/ChangeLog: PR tree-optimization/81953 * gcc.dg/tree-ssa/ssa-sink-21.c: New test.
[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 --- Comment #7 from Chen Chen --- (In reply to Richard Biener from comment #6) > https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=471.407.0 > > shows a recent improvement that then regressed again, maybe you have a > similar artifact with the choosing of the snapshots. Try a snapshot from > february for comparison for example. Thanks for the nice graph! We did more tests on AMD Zen4 CPU R9 7940HS (system: Debian 12) and used similar parameters as yours. The results are following: with parameters "-m64 -g -Ofast -march=native": 13.2.0:30.0 (87.2s) [gcc 13.2 release] 20240121: 29.8 (88.0s) [gcc 14 snapshot] 20240218: 29.8 (88.0s) [gcc 14 snapshot] 20240303: 29.2 (89.8s) [gcc 14 snapshot] 20240310: 31.7 (82.6s) [gcc 14 snapshot] 20240317: 31.7 (82.7s) [gcc 14 snapshot] 20240324: 28.3 (92.5s) [gcc 14 snapshot] 20240430: 28.4 (92.3s) [gcc 14 snapshot, 14.1.0-RC] 14.1.0:28.4 (92.4s) [gcc 14.1 release] with parameters "-m64 -g -Ofast -march=native -flto": 13.2.0:30.5 (85.8s) [gcc 13.2 release] 20240121: 30.5 (85.9s) [gcc 14 snapshot] 20240218: 29.5 (88.7s) [gcc 14 snapshot] 20240303: 30.5 (86.0s) [gcc 14 snapshot] 20240310: 31.6 (82.8s) [gcc 14 snapshot] 20240317: 31.7 (82.7s) [gcc 14 snapshot] 20240324: 28.6 (91.6s) [gcc 14 snapshot] 20240430: 29.1 (89.9s) [gcc 14 snapshot, 14.1.0-RC] 14.1.0:29.1 (90.1s) [gcc 14.1 release] The scores with gcc 14.1 release are 8.2-10.4% lower than those with gcc 14 snapshot 20240317, and 4.6-5.3% lower than those with gcc 13.2 release.
[Bug c/114987] New: floating point vector regression, x86, between gcc 14 and gcc-13 using -O3 and target clones on skylake platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114987
Bug ID: 114987
Summary: floating point vector regression, x86, between gcc 14
and gcc-13 using -O3 and target clones on skylake
platforms
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: colin.king at intel dot com
Target Milestone: ---
Created attachment 58126
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58126&action=edit
reproducer.c source code
I'm seeing a ~10% performance regression in gcc-14 compared to gcc-13, using
gcc on Ubuntu 24.04:
Versions:
gcc version 13.2.0 (Ubuntu 13.2.0-23ubuntu4)
gcc version 14.0.1 20240412 (experimental) [master r14-9935-g67e1433a94f]
(Ubuntu 14-20240412-0ubuntu1)
king@skylake:~$ CFLAGS="" gcc-13 reproducer.c; ./a.out
4.92 secs duration, 2130.379 Mfp-ops/sec
cking@skylake:~$ CFLAGS="" gcc-14 reproducer.c; ./a.out
5.46 secs duration, 1921.799 Mfp-ops/sec
The original issue appeared when regression testing stress-ng vecfp stressor
[1] using the floating point vector 16 add stressor method. I've managed to
extract the attached reproducer (reproducer.c) from the original code.
Salient points to focus on:
1. The issue is dependant on the OPTIMIZE3 macro in the reproducer being
__attribute__((optimize("-O3")))
2. The issue is also dependant on the TARGET_CLONES macro being defined as
__attribute__((target_clones("mmx,avx,default"))) - the avx target clones
seems to be an issue in reproducing this problem.
Attached are the reproducer.c C source and disassembled object code. The
stress_vecfp_float_add_16.avx from gcc-13 is significantly different from the
gcc-14 code.
References: [1]
https://github.com/ColinIanKing/stress-ng/blob/master/stress-vecfp.c
[Bug c/114987] floating point vector regression, x86, between gcc 14 and gcc-13 using -O3 and target clones on skylake platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114987 --- Comment #1 from Colin Ian King --- Created attachment 58127 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58127&action=edit gcc-13 disassembly
[Bug c/114987] floating point vector regression, x86, between gcc 14 and gcc-13 using -O3 and target clones on skylake platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114987 --- Comment #2 from Colin Ian King --- Created attachment 58128 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58128&action=edit gcc-14 disassembly
[Bug bootstrap/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 seurer at gcc dot gnu.org changed: What|Removed |Added Build||powerpc64-linux-gnu, ||powerpc64le-linux-gnu Target||powerpc64-linux-gnu, ||powerpc64le-linux-gnu CC||aldyh at gcc dot gnu.org, ||bergner at gcc dot gnu.org Host||powerpc64-linux-gnu, ||powerpc64le-linux-gnu --- Comment #1 from seurer at gcc dot gnu.org --- Looks like this is the culprit: commit 36e877996936abd8bd08f8b1d983c8d1023a5842 (HEAD) Author: Aldy Hernandez Date: Tue May 7 14:05:50 2024 +0200 Enable prange support.
[Bug c/114987] floating point vector regression, x86, between gcc 14 and gcc-13 using -O3 and target clones on skylake platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114987 --- Comment #3 from Colin Ian King --- perf report from gcc-13 of stress_vecfp_float_add_16.avx of compute loop: 57.93 │200: vaddps 0xc0(%rsp),%ymm3,%ymm5 11.11 │ vaddps 0xe0(%rsp),%ymm2,%ymm6 0.02 │ vmovaps %ymm5,0x60(%rsp) 2.92 │ mov 0x60(%rsp),%rax │ mov 0x68(%rsp),%rdx 0.37 │ vmovaps %ymm6,0x40(%rsp) │ vmovaps %ymm5,0x80(%rsp) 6.30 │ vmovq%rax,%xmm1 4.11 │ mov 0x40(%rsp),%rax │ vmovdqa 0x90(%rsp),%xmm5 │ vmovaps %ymm6,0xa0(%rsp) 3.27 │ vpinsrq $0x1,%rdx,%xmm1,%xmm1 │ mov 0x48(%rsp),%rdx │ vmovdqa 0xb0(%rsp),%xmm6 3.22 │ vmovdqa %xmm1,0xc0(%rsp) 0.42 │ vmovq%rax,%xmm0 │ vmovdqa %xmm5,0xd0(%rsp) 6.80 │ vpinsrq $0x1,%rdx,%xmm0,%xmm0 3.52 │ vmovdqa %xmm0,0xe0(%rsp) │ vmovdqa %xmm6,0xf0(%rsp) │ sub $0x1,%ecx │ ↑ jne 200 perf report from gcc-14 of stress_vecfp_float_add_16.avx of compute loop: 65.79 │200: vaddps 0xc0(%rsp),%ymm3,%ymm5 3.26 │ vaddps 0xe0(%rsp),%ymm2,%ymm6 0.00 │ vmovaps %ymm5,0x60(%rsp) 9.25 │ mov 0x60(%rsp),%rax 0.00 │ mov 0x68(%rsp),%rdx │ vmovaps %ymm6,0x40(%rsp) │ vmovaps %ymm5,0x80(%rsp) 6.49 │ vmovq%rax,%xmm1 0.00 │ mov 0x40(%rsp),%rax 0.00 │ vmovaps %ymm6,0xa0(%rsp) 3.02 │ vpinsrq $0x1,%rdx,%xmm1,%xmm1 │ mov 0x48(%rsp),%rdx 0.35 │ vmovdqa %xmm1,0xc0(%rsp) 0.68 │ vmovq%rax,%xmm0 0.00 │ vmovdqa 0x90(%rsp),%xmm1 5.18 │ vpinsrq $0x1,%rdx,%xmm0,%xmm0 3.00 │ vmovdqa %xmm0,0xe0(%rsp) │ vmovdqa 0xb0(%rsp),%xmm0 │ vmovdqa %xmm1,0xd0(%rsp) │ vmovdqa %xmm0,0xf0(%rsp) │ sub $0x1,%ecx 2.94 │ ↑ jne 200
[Bug c/114988] New: RISC-V: ICE in intrinsic __riscv_vfwsub_wf_f32mf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114988
Bug ID: 114988
Summary: RISC-V: ICE in intrinsic __riscv_vfwsub_wf_f32mf2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
https://godbolt.org/z/ncxrx3fK9
#include
#include
vfloat32mf2_t test_vfwsub_wf_f32mf2(vfloat32mf2_t vs2, _Float16 rs1, size_t vl)
{
return __riscv_vfwsub_wf_f32mf2(vs2, rs1, vl);
}
with -march=rv64gcv -O3:
:6:1: error: unrecognizable insn:
6 | }
| ^
(insn 8 5 12 2 (set (reg:RVVMF2SF 134 [ ])
(if_then_else:RVVMF2SF (unspec:RVVMF64BI [
(const_vector:RVVMF64BI repeat [
(const_int 1 [0x1])
])
(reg/v:DI 137 [ vl ])
(const_int 2 [0x2]) repeated x2
(const_int 0 [0])
(const_int 7 [0x7])
(reg:SI 66 vl)
(reg:SI 67 vtype)
(reg:SI 69 frm)
] UNSPEC_VPREDICATE)
(minus:RVVMF2SF (reg/v:RVVMF2SF 135 [ vs2 ])
(float_extend:RVVMF2SF (vec_duplicate:RVVMF4HF (reg/v:HF 136 [
rs1 ]
(unspec:RVVMF2SF [
(reg:DI 0 zero)
] UNSPEC_VUNDEF))) "":5:10 -1
(nil))
FP16 vector need zvfh, so such intrinsic should be reported as illegal
intrinsic in frontend instead of an ICE.
with -rv64gcv_zvfh:
It can be compiled:
vsetvli zero,a0,e16,mf4,ta,ma
vfwsub.wf v8,v8,fa0
ret
[Bug c/114988] RISC-V: ICE in intrinsic __riscv_vfwsub_wf_f32mf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114988
--- Comment #1 from JuzheZhong ---
Ideally, it should be reported as (-march=rv64gc):
https://godbolt.org/z/3P76YEb9s
: In function 'test_vfwsub_wf_f32mf2':
:4:15: error: return type 'vfloat32mf2_t' requires the V ISA extension
4 | vfloat32mf2_t test_vfwsub_wf_f32mf2(vfloat32mf2_t vs2, _Float16 rs1,
size_t vl) {
| ^
Compiler returned: 1
[Bug bootstrap/114985] [15 regression] internal compiler error: in discriminator_fail during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985 --- Comment #2 from Aldy Hernandez --- Yeah, that's mine. Can you attach a preprocessed file of the offending file?
[Bug tree-optimization/112392] `a == nonnegative ? a : abs` -> abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112392 --- Comment #4 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:5726de79e2154a16d8a045567d2cfad035f7ed19 commit r15-328-g5726de79e2154a16d8a045567d2cfad035f7ed19 Author: Andrew Pinski Date: Mon May 6 23:53:41 2024 -0700 match: `a CMP nonnegative ? a : ABS` simplified to just `ABS` [PR112392] We can optimize `a == nonnegative ? a : ABS`, `a > nonnegative ? a : ABS` and `a >= nonnegative ? a : ABS` into `ABS`. This allows removal of some extra comparison and extra conditional moves in some cases. I don't remember where I had found though but it is simple to add so let's add it. Bootstrapped and tested on x86_64-linux-gnu with no regressions. Note I have a secondary pattern for the equal case as either a or nonnegative could be used. PR tree-optimization/112392 gcc/ChangeLog: * match.pd (`x CMP nonnegative ? x : ABS`): New pattern; where CMP is ==, > and >=. (`x CMP nonnegative@y ? y : ABS`): New pattern. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/phi-opt-41.c: New test. Signed-off-by: Andrew Pinski
[Bug tree-optimization/112392] `a == nonnegative ? a : abs` -> abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112392 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |15.0 Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- Fixed.
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #19 from LIU Hao ---
(In reply to Jakub Jelinek from comment #17)
> Created attachment 58125 [details]
> gcc15-pr114968.patch
>
> Here is an updated patch.
> Note, even when not taking thiscall attribute into consideration, the
> existing
> code was wrong on the !targetm.cxx.use_atexit_for_cxa_atexit () targets (aka
> mingw), because it would happily use the atexit function argument type (aka
> void (*) ()) for __cxa_thread_atexit.
Bootstrapped successfully on {i686,x86_64}-w64-mingw32. Also rebuilt mingw-w64
CRT, binutils, GDB and boost. Everything went well.
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968 --- Comment #20 from Jakub Jelinek --- Thanks, I'll test it myself on x86_64-linux/i686-linux and post if it succeeds.
[Bug target/110066] [13 Regression] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066 --- Comment #27 from GCC Commits --- The releases/gcc-13 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:929b0fffe4d3d836e07e5a398a8e176e65f8b2c2 commit r13-8728-g929b0fffe4d3d836e07e5a398a8e176e65f8b2c2 Author: Andrew Pinski Date: Sat Jul 22 08:52:42 2023 -0700 Fix PR 110066: crash with -pg -static on riscv The problem -fasynchronous-unwind-tables is on by default for riscv linux We need turn it off for crt*.o because it would make __EH_FRAME_BEGIN__ point to .eh_frame data from crtbeginT.o instead of the user-defined object during static linking. This turns it off. OK? libgcc/ChangeLog: * config.host (riscv*-*-linux*): Add t-crtstuff to tmake_file. (riscv*-*-freebsd*): Likewise. * config/riscv/t-crtstuff: New file. (cherry picked from commit bbc1a102735c72e3c5a4dede8ab382813d12b058)
[Bug target/110066] [13 Regression] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #28 from Andrew Pinski --- Fixed.
[Bug target/109762] [12 Regression] gcc/config/aarch64/aarch64-builtins.cc: mismatched sizes for flags variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109762 --- Comment #11 from Andrew Pinski --- The patch does not apply directly to GCC 12.
[Bug libstdc++/110054] stdx::simd masked store should not use non-temporal store instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110054 --- Comment #5 from GCC Commits --- The releases/gcc-12 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:e60ec9b0e02e8647c289d204342e992e91750011 commit r12-10422-ge60ec9b0e02e8647c289d204342e992e91750011 Author: Matthias Kretz Date: Fri Jun 2 13:44:22 2023 +0200 libstdc++: Replace use of incorrect non-temporal store The call to the base implementation sometimes didn't find a matching signature because the _Abi parameter of _SimdImpl* was "wrong" after conversion. It has to call into ::_SimdImpl instead of the current ABI tag's _SimdImpl. This also reduces the number of possible template instantiations. Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/110054 * include/experimental/bits/simd_builtin.h (_S_masked_store): Call into deduced ABI's SimdImpl after conversion. * include/experimental/bits/simd_x86.h (_S_masked_store_nocvt): Don't use _mm_maskmoveu_si128. Use the generic fall-back implementation. Also fix masked stores without SSE2, which were not doing anything before. (cherry picked from commit 27e45b7597d6fb1a71927d658a0294797b720c0a)
[Bug libstdc++/109822] Converting std::experimental::simd masks yields an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109822 --- Comment #10 from GCC Commits --- The releases/gcc-12 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:44df51e5826747d089a08fa1a1378454a8d2d0de commit r12-10423-g44df51e5826747d089a08fa1a1378454a8d2d0de Author: Matthias Kretz Date: Fri Jun 2 21:33:04 2023 +0200 libstdc++: Avoid vector casts while still avoiding PR90424 Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/109822 * include/experimental/bits/simd_builtin.h (_S_store): Rewrite to avoid casts to other vector types. Implement store as succession of power-of-2 sized memcpy to avoid PR90424. (cherry picked from commit 9165ede56ababd6471e7a2ce4eab30f3d5129e14)
[Bug libstdc++/114803] simd conversion to [[gnu::vector_size(N)]] type hits invalid code in experimental/bits/simd_builtin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114803 --- Comment #4 from GCC Commits --- The releases/gcc-12 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:0ab30fb865e6465156f7db10506b56ef2df19648 commit r12-10429-g0ab30fb865e6465156f7db10506b56ef2df19648 Author: Matthias Kretz Date: Mon Apr 22 16:12:34 2024 +0200 libstdc++: Fix conversion of simd to vector builtin Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/114803 * include/experimental/bits/simd_builtin.h (_SimdBase2::operator __vector_type_t): There is no __builtin() function in _SimdWrapper, instead use its conversion operator. * testsuite/experimental/simd/pr114803_vecbuiltin_cvt.cc: New test. (cherry picked from commit 7ef139146a8923a8719873ca3fdae175668e8d63)
[Bug libstdc++/114750] converting load/store of simd fails compilation on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114750 --- Comment #5 from GCC Commits --- The releases/gcc-12 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:b3097e01cd5d32e9825b7b87dff12b3247bd9819 commit r12-10426-gb3097e01cd5d32e9825b7b87dff12b3247bd9819 Author: Matthias Kretz Date: Wed Apr 17 09:11:25 2024 +0200 libstdc++: Avoid ill-formed types on ARM This resolves failing tests in check-simd. Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/114750 * include/experimental/bits/simd_builtin.h (_SimdImplBuiltin::_S_load, _S_store): Fall back to copying scalars if the memory type cannot be vectorized for the target. (cherry picked from commit 0fc7f3c6adc8543f55ec35b309016d9d9c4ddd35)
[Bug middle-end/95351] [11/12 Regression] Comparison with NAN optimizes incorrectly with -ffast-math disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95351 --- Comment #9 from GCC Commits --- The releases/gcc-12 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:d88fe8210e4edc2f4ddf722ba788924452c6f6a0 commit r12-10430-gd88fe8210e4edc2f4ddf722ba788924452c6f6a0 Author: Andrew Pinski Date: Sun Mar 10 22:17:09 2024 + Fold: Fix up merge_truthop_with_opposite_arm for NaNs [PR95351] The problem here is that merge_truthop_with_opposite_arm would use the type of the result of the comparison rather than the operands of the comparison to figure out if we are honoring NaNs. This fixes that oversight and now we get the correct results in this case. Committed as obvious after a bootstrap/test on x86_64-linux-gnu. PR middle-end/95351 gcc/ChangeLog: * fold-const.cc (merge_truthop_with_opposite_arm): Use the type of the operands of the comparison and not the type of the comparison. gcc/testsuite/ChangeLog: * gcc.dg/float_opposite_arm-1.c: New test. Signed-off-by: Andrew Pinski (cherry picked from commit 31ce2e993d09dcad1ce139a2848a28de5931056d)
