[Bug target/114955] marco DATA_ALIGNMENT may conflict with pragma pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114955 --- Comment #5 from hanwei (K) --- You mean the pragma pack just apply to the inner members of struct, not the first member. The align of struct (first member also) is controlled by __attribute__((aligned(...))). Right?
[Bug sanitizer/114956] [11/12/13/14/15 regression] Segmentation fault with -fsanitize=address -fsanitize=null -O2 when attribute no_sanitize_address is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114956
Sam James changed:
What|Removed |Added
Summary|Segmentation fault with |[11/12/13/14/15 regression]
|-fsanitize=address |Segmentation fault with
|-fsanitize=null -O2 when|-fsanitize=address
|attribute |-fsanitize=null -O2 when
|no_sanitize_address is |attribute
|enabled |no_sanitize_address is
||enabled
--- Comment #1 from Sam James ---
testing on godbolt gives..
gcc 8.2:
```
:2:37: warning: always_inline function might not be inlinable
[-Wattributes]
__attribute__((always_inline)) int *c() {
^
: In function 'd':
:2:37: error: inlining failed in call to always_inline 'c': function
attribute mismatch
:6:61: note: called from here
__attribute__((no_sanitize_address)) static char d() { *a = c(); }
^~~
Compiler returned: 1
```
gcc 8.3:
```
:2:37: warning: always_inline function might not be inlinable
[-Wattributes]
__attribute__((always_inline)) int *c() {
^
during GIMPLE pass: sanopt
: In function 'd':
:6:50: internal compiler error: Segmentation fault
__attribute__((no_sanitize_address)) static char d() { *a = c(); }
^
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug fortran/114739] Ensure no IMPLICIT type errors appear when they should for inquiry references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114739 --- Comment #11 from GCC Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:094f8a36dffea52fe6a64596203b82648a3f6121 commit r13-8689-g094f8a36dffea52fe6a64596203b82648a3f6121 Author: Paul Thomas Date: Mon May 6 08:21:14 2024 +0100 Fortran: Fix ICE and clear incorrect error messages [PR114739] 2024-05-06 Paul Thomas gcc/fortran PR fortran/114739 * primary.cc (gfc_match_varspec): Check for default type before checking for derived types with the right component name. gcc/testsuite/ PR fortran/114739 * gfortran.dg/pr114739.f90: New test. * gfortran.dg/derived_comp_array_ref_8.f90: Add 'implicit none' for consistency with expected error message. * gfortran.dg/nullify_4.f90: ditto * gfortran.dg/pointer_init_6.f90: ditto * gfortran.dg/pr107397.f90: ditto * gfortran.dg/pr88138.f90: ditto
[Bug target/114955] marco DATA_ALIGNMENT may conflict with pragma pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114955 --- Comment #6 from Andrew Pinski --- It is not about the alignment of the first field but rather the alignment of a struct. BUT variable alignment is controlled separately from struct alignment. That is the point I am trying to make. If you want a variable to have a smaller alignment than what the target backend wants to give it, then you need to use the aligned attributes. What pragma pack does is change the alignment of the struct so that if you do: struct f *t; t->field1 = 10; It will be an unaligned access there. But if you have a variable, the alignment will be different and the compiler can increase still to be more efficient.
[Bug fortran/114739] Ensure no IMPLICIT type errors appear when they should for inquiry references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114739 --- Comment #12 from GCC Commits --- The releases/gcc-12 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:3a5acd2583056e8cd0e5fda83e7c34be65415c62 commit r12-10415-g3a5acd2583056e8cd0e5fda83e7c34be65415c62 Author: Paul Thomas Date: Mon May 6 08:21:14 2024 +0100 Fortran: Fix ICE and clear incorrect error messages [PR114739] 2024-05-06 Paul Thomas gcc/fortran PR fortran/114739 * primary.cc (gfc_match_varspec): Check for default type before checking for derived types with the right component name. gcc/testsuite/ PR fortran/114739 * gfortran.dg/pr114739.f90: New test. * gfortran.dg/derived_comp_array_ref_8.f90: Add 'implicit none' for consistency with expected error message. * gfortran.dg/nullify_4.f90: ditto * gfortran.dg/pointer_init_6.f90: ditto * gfortran.dg/pr107397.f90: ditto * gfortran.dg/pr88138.f90: ditto (cherry picked from commit 094f8a36dffea52fe6a64596203b82648a3f6121)
[Bug fortran/114739] Ensure no IMPLICIT type errors appear when they should for inquiry references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114739 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Paul Thomas --- Backported to 12- and 13-branches. Closing Paul
[Bug sanitizer/114956] [11/12/13/14/15 Regression] Segmentation fault with -fsanitize=address -fsanitize=null -O2 when attribute no_sanitize_address is enabled since r9-5742
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114956
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-05-06
Summary|[11/12/13/14/15 regression] |[11/12/13/14/15 Regression]
|Segmentation fault with |Segmentation fault with
|-fsanitize=address |-fsanitize=address
|-fsanitize=null -O2 when|-fsanitize=null -O2 when
|attribute |attribute
|no_sanitize_address is |no_sanitize_address is
|enabled |enabled since r9-5742
Ever confirmed|0 |1
Target Milestone|--- |11.5
Status|UNCONFIRMED |NEW
Priority|P3 |P2
--- Comment #2 from Jakub Jelinek ---
Started with my r9-5742-g6206a883fe7a741dbb9e09d88255a170a75950f5
-O2 -fsanitize=address,null
int **a;
__attribute__((always_inline)) int *
foo (void)
{
int b[1];
(void) b;
}
__attribute__((no_sanitize_address)) static char
bar (void)
{
*a = foo ();
}
void
baz (void)
{
bar ();
}
[Bug analyzer/111475] [14 regression] Many C++ analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475 --- Comment #15 from GCC Commits --- The releases/gcc-14 branch has been updated by Rainer Orth : https://gcc.gnu.org/g:c7b4305f9c0d23a9dfb2cf0855d345ff67e48732 commit r14-10170-gc7b4305f9c0d23a9dfb2cf0855d345ff67e48732 Author: Rainer Orth Date: Mon May 6 10:54:27 2024 +0200 testsuite: c++: Skip g++.dg/analyzer on Solaris [PR111475] Almost 1400 C++ analyzer tests FAIL on Solaris. The patch is too risky to apply so close to the GCC 14.1.0 release, so disable the tests on Solaris instead to reduce the noise. Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11, and x86_64-pc-linux-gnu. 2024-05-05 Rainer Orth gcc/testsuite: PR analyzer/111475 * g++.dg/analyzer/analyzer.exp: Disable on *-*-solaris2.*.
[Bug sanitizer/114956] [11/12/13/14/15 Regression] Segmentation fault with -fsanitize=address -fsanitize=null -O2 when attribute no_sanitize_address is enabled since r9-5742
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114956 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 58106 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58106&action=edit gcc15-pr114956.patch Untested fix.
[Bug tree-optimization/114908] fails to optimize avx2 in-register permute written with std::experimental::simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114908 --- Comment #3 from Matthias Kretz (Vir) --- The stdx::simd implementation in this area is old and mainly tuned to be correct. I can rewrite the split and concat implementation to use __builtin_shufflevector (which wasn't available in GCC at the time when I originally implemented it). Doing so I can resolve this issue. How do you want to handle this? Because it would certainly be nice if the compiler can optimize this in the same way as Clang can. Should I try to come up with a testcase that doesn't need stdx::simd and then improve stdx::simd independently?
[Bug tree-optimization/114908] fails to optimize avx2 in-register permute written with std::experimental::simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114908 --- Comment #4 from rguenther at suse dot de --- On Mon, 6 May 2024, mkretz at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114908 > > --- Comment #3 from Matthias Kretz (Vir) --- > The stdx::simd implementation in this area is old and mainly tuned to be > correct. I can rewrite the split and concat implementation to use > __builtin_shufflevector (which wasn't available in GCC at the time when I > originally implemented it). Doing so I can resolve this issue. > > How do you want to handle this? Because it would certainly be nice if the > compiler can optimize this in the same way as Clang can. Should I try to come > up with a testcase that doesn't need stdx::simd and then improve stdx::simd > independently? Yes, that would be nice (best the testcase w/o stdx::simd being a C testcase even, no C++ abstraction). I do think stdx::simd should be improved to use __builtin_shufflevector though.
[Bug target/112959] install.tex needs updates on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112959 --- Comment #5 from Gerald Pfeifer --- Rainer, do you think the three changes I made - and hence the current state of install.texi on trunk - address all the issues you reported and sufficiently well? (I hope Andrew is going to commit the change to bug #97304, which surely would help as well.) If so, I'll see to get them back into the GCC 14 branch as well.
[Bug rtl-optimization/101523] Huge number of combine attempts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523 --- Comment #64 from rguenther at suse dot de --- On Sat, 4 May 2024, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523 > > --- Comment #61 from Segher Boessenkool --- > We used to do the wrong thing in combine. Now that my fix was reverted, we > still do. This should be undone soonish, As promised I'm going to revert the revert after 14.1 is released (hopefully tomorrow). As for distros I have decided to include my hack posted in https://gcc.gnu.org/pipermail/gcc-patches/2024-April/648725.html for SUSE based distros in GCC 13 and 14 as that seems to improve the problematical memory uses in our build farm.
[Bug rtl-optimization/101523] Huge number of combine attempts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523 --- Comment #65 from Segher Boessenkool --- On Sat, May 04, 2024 at 01:14:18PM +, sarah.kriesch at opensuse dot org wrote: Do not reply to a PR comment in private mail.
[Bug rtl-optimization/101523] Huge number of combine attempts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523 --- Comment #66 from Segher Boessenkool --- (In reply to rguent...@suse.de from comment #64) > As promised I'm going to revert the revert after 14.1 is released > (hopefully tomorrow). Thank you! beer++ > As for distros I have decided to include my > hack posted in > https://gcc.gnu.org/pipermail/gcc-patches/2024-April/648725.html > for SUSE based distros in GCC 13 and 14 as that seems to improve > the problematical memory uses in our build farm. I think this patch may well show some actual regressions :-( We'll see.
[Bug rtl-optimization/101523] Huge number of combine attempts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523 --- Comment #67 from Richard Biener --- (In reply to Segher Boessenkool from comment #66) > (In reply to rguent...@suse.de from comment #64) > > As promised I'm going to revert the revert after 14.1 is released > > (hopefully tomorrow). > > Thank you! beer++ > > > As for distros I have decided to include my > > hack posted in > > https://gcc.gnu.org/pipermail/gcc-patches/2024-April/648725.html > > for SUSE based distros in GCC 13 and 14 as that seems to improve > > the problematical memory uses in our build farm. > > I think this patch may well show some actual regressions :-( We'll see. I'm probably not going to notice - at least I think it should be fine by design, but as we see combine doesn't adhere to it's design, so my milage may vary ;) But yeah, I didn't do any extensive before/after code differences (there should be no difference - fingers crossing ;))
[Bug fortran/110987] [13 Regression] Segmentation fault after finalization of a temporary variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110987 --- Comment #11 from GCC Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:9f204cc695d27d0b8eb69d9a4d266261171185ae commit r13-8690-g9f204cc695d27d0b8eb69d9a4d266261171185ae Author: Paul Thomas Date: Fri Mar 29 07:23:19 2024 + Fortran: Fix a gimplifier ICE/wrong result with finalization [PR36337] 2024-03-29 Paul Thomas gcc/fortran PR fortran/36337 PR fortran/110987 PR fortran/113885 * trans-expr.cc (gfc_trans_assignment_1): Place finalization block before rhs post block for elemental rhs. * trans.cc (gfc_finalize_tree_expr): Check directly if a type has no components, rather than the zero components attribute. Treat elemental zero component expressions in the same way as scalars. gcc/testsuite/ PR fortran/113885 * gfortran.dg/finalize_54.f90: New test. * gfortran.dg/finalize_55.f90: New test. gcc/testsuite/ PR fortran/110987 * gfortran.dg/finalize_56.f90: New test. (cherry picked from commit 3c793f0361bc66d2a6bf0b3e1fb3234fc511e2a6)
[Bug fortran/113885] [13 Regression] ice in gimplify_expr, at gimplify.cc:18658 with finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113885 --- Comment #5 from GCC Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:9f204cc695d27d0b8eb69d9a4d266261171185ae commit r13-8690-g9f204cc695d27d0b8eb69d9a4d266261171185ae Author: Paul Thomas Date: Fri Mar 29 07:23:19 2024 + Fortran: Fix a gimplifier ICE/wrong result with finalization [PR36337] 2024-03-29 Paul Thomas gcc/fortran PR fortran/36337 PR fortran/110987 PR fortran/113885 * trans-expr.cc (gfc_trans_assignment_1): Place finalization block before rhs post block for elemental rhs. * trans.cc (gfc_finalize_tree_expr): Check directly if a type has no components, rather than the zero components attribute. Treat elemental zero component expressions in the same way as scalars. gcc/testsuite/ PR fortran/113885 * gfortran.dg/finalize_54.f90: New test. * gfortran.dg/finalize_55.f90: New test. gcc/testsuite/ PR fortran/110987 * gfortran.dg/finalize_56.f90: New test. (cherry picked from commit 3c793f0361bc66d2a6bf0b3e1fb3234fc511e2a6)
[Bug testsuite/36337] testsuite requires HOSTCC and HOSTCFLAGS from contrib/test_installed script
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36337 --- Comment #3 from GCC Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:9f204cc695d27d0b8eb69d9a4d266261171185ae commit r13-8690-g9f204cc695d27d0b8eb69d9a4d266261171185ae Author: Paul Thomas Date: Fri Mar 29 07:23:19 2024 + Fortran: Fix a gimplifier ICE/wrong result with finalization [PR36337] 2024-03-29 Paul Thomas gcc/fortran PR fortran/36337 PR fortran/110987 PR fortran/113885 * trans-expr.cc (gfc_trans_assignment_1): Place finalization block before rhs post block for elemental rhs. * trans.cc (gfc_finalize_tree_expr): Check directly if a type has no components, rather than the zero components attribute. Treat elemental zero component expressions in the same way as scalars. gcc/testsuite/ PR fortran/113885 * gfortran.dg/finalize_54.f90: New test. * gfortran.dg/finalize_55.f90: New test. gcc/testsuite/ PR fortran/110987 * gfortran.dg/finalize_56.f90: New test. (cherry picked from commit 3c793f0361bc66d2a6bf0b3e1fb3234fc511e2a6)
[Bug fortran/110987] [13 Regression] Segmentation fault after finalization of a temporary variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110987 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Paul Thomas --- Fixed on all affected branches. Thanks for the report. Paul
[Bug fortran/113885] [13 Regression] ice in gimplify_expr, at gimplify.cc:18658 with finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113885 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Paul Thomas --- Fixed on all affected branches. Thanks for the report. Paul
[Bug fortran/112407] [13 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407 --- Comment #12 from GCC Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:f598a1c8a77e678ca009b433fd849b4834594926 commit r13-8691-gf598a1c8a77e678ca009b433fd849b4834594926 Author: Paul Thomas Date: Tue Apr 2 14:19:09 2024 +0100 Fortran: Fix wrong recursive errors and class initialization [PR112407] 2024-04-02 Paul Thomas gcc/fortran PR fortran/112407 * resolve.cc (resolve_procedure_expression): Change the test for for recursion in the case of hidden procedures from modules. (resolve_typebound_static): Add warning for possible recursive calls to typebound procedures. * trans-expr.cc (gfc_trans_class_init_assign): Do not apply default initializer to class dummy where component initializers are all null. gcc/testsuite/ PR fortran/112407 * gfortran.dg/pr112407a.f90: New test. * gfortran.dg/pr112407b.f90: New test. (cherry picked from commit 35408b3669fac104cd380582b32e32c64a603d8b)
[Bug fortran/112407] [13 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Paul Thomas --- Fixed on all affected branches. Thanks for the report. Paul
[Bug fortran/106999] [11/12/13 Regression] ICE tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_class_data_get, at fortran/trans-expr.cc:233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106999 --- Comment #8 from GCC Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:429935510202c4efee933bf907fd9dff816193f2 commit r13-8692-g429935510202c4efee933bf907fd9dff816193f2 Author: Paul Thomas Date: Tue Apr 2 15:53:29 2024 +0100 Fortran: Add error for subroutine passed to a variable dummy [PR106999] 2024-04-02 Paul Thomas gcc/fortran PR fortran/106999 * interface.cc (gfc_compare_interfaces): Add error for a subroutine proc pointer passed to a variable formal. (compare_parameter): If a procedure pointer is being passed to a non-procedure formal arg, and there is an an interface, use gfc_compare_interfaces to check and provide a more useful error message. gcc/testsuite/ PR fortran/106999 * gfortran.dg/pr106999.f90: New test. (cherry picked from commit a7aa9455a8b9cb080649a7357b7360f2d99bcbf1)
[Bug fortran/112407] [13 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407 --- Comment #14 from Tomáš Trnka --- I have been testing my own backport of the master commit on top of current 13 branch for some weeks now and it works great. Our codebase now compiles even without -frecursive without any related warnings/errors. Many thanks for the fix!
[Bug tree-optimization/114908] fails to optimize avx2 in-register permute written with std::experimental::simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114908
--- Comment #5 from Matthias Kretz (Vir) ---
https://godbolt.org/z/P6cfbjT9f
#include
typedef uint64_t T;
typedef T V [[gnu::vector_size(32)]];
typedef struct simd4 {
V data;
} simd4;
typedef struct simd1 {
T data;
} simd1;
typedef struct tup3_1 {
simd4 a;
simd1 b;
} tup3_1;
simd1 load1(const T* ptr) {
simd1 ret = {ptr[0]};
return ret;
}
simd4 load3(const T* ptr) {
simd4 ret = {};
__builtin_memcpy(&ret, ptr, 3 * sizeof(T));
return ret;
}
tup3_1 split3_1(simd4 x) {
const T* ptr = (T*)&x;
tup3_1 ret = {load3(ptr), load1(ptr + 3)};
return ret;
}
simd4 concat1_3(simd1 a, simd4 b) {
simd4 ret = {};
char* ptr = (char*)&ret;
__builtin_memcpy(ptr, &a, sizeof(T));
__builtin_memcpy(ptr + sizeof(T), &b, 3 * sizeof(T));
return ret;
}
simd4 perm(simd4 data) {
tup3_1 carry = split3_1(data);
simd1 zero = {};
return concat1_3(zero, carry.a);
}
[Bug fortran/106999] [11/12/13 Regression] ICE tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_class_data_get, at fortran/trans-expr.cc:233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106999 --- Comment #9 from GCC Commits --- The releases/gcc-12 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:d72e9f90e370538b057690b16c1e65350dbbb75c commit r12-10416-gd72e9f90e370538b057690b16c1e65350dbbb75c Author: Paul Thomas Date: Tue Apr 2 15:53:29 2024 +0100 Fortran: Add error for subroutine passed to a variable dummy [PR106999] 2024-04-02 Paul Thomas gcc/fortran PR fortran/106999 * interface.cc (gfc_compare_interfaces): Add error for a subroutine proc pointer passed to a variable formal. (compare_parameter): If a procedure pointer is being passed to a non-procedure formal arg, and there is an an interface, use gfc_compare_interfaces to check and provide a more useful error message. gcc/testsuite/ PR fortran/106999 * gfortran.dg/pr106999.f90: New test. (cherry picked from commit a7aa9455a8b9cb080649a7357b7360f2d99bcbf1)
[Bug fortran/106999] [11/12/13 Regression] ICE tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_class_data_get, at fortran/trans-expr.cc:233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106999 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Paul Thomas --- Fixed on 12-branch through to mainline. Thanks for the report. Paul
[Bug tree-optimization/114908] fails to optimize avx2 in-register permute written with std::experimental::simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114908
--- Comment #6 from Richard Biener ---
Thanks, and it might be enough to handle
typedef unsigned long V [[gnu::vector_size(32)]];
V load3(const unsigned long* ptr)
{
V ret = {};
__builtin_memcpy(&ret, ptr, 3 * sizeof(unsigned long));
return ret;
}
where with -O2 .optimized still has
[local count: 1073741824]:
ret = { 0, 0, 0, 0 };
__builtin_memcpy (&ret, ptr_3(D), 24);
_5 = ret;
ret ={v} {CLOBBER(eos)};
return _5;
and thus 'ret' not promoted to a register.
[Bug libstdc++/114958] New: use __builtin_shufflevector for std::experimental::simd split and concat (at least the common cases) to enable better optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114958 Bug ID: 114958 Summary: use __builtin_shufflevector for std::experimental::simd split and concat (at least the common cases) to enable better optimizations Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: mkretz at gcc dot gnu.org Reporter: mkretz at gcc dot gnu.org Target Milestone: --- PR114908 presents a missed optimization that would not occur if simd's split and concat would make better use of __builtin_shufflevector.
[Bug tree-optimization/114908] fails to optimize avx2 in-register permute written with std::experimental::simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114908 --- Comment #7 from Matthias Kretz (Vir) --- I suspect resolving this is only one part of it. But I'm happy to be proven wrong. :) I opened PR114958 to track the simd implementation change.
[Bug libstdc++/114958] use __builtin_shufflevector for std::experimental::simd split and concat (at least the common cases) to enable better optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114958
Matthias Kretz (Vir) changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Last reconfirmed||2024-05-06
--- Comment #1 from Matthias Kretz (Vir) ---
Untested patch:
diff --git a/libstdc++-v3/include/experimental/bits/simd.h
b/libstdc++-v3/include/experimental/bits/simd.h
index 6ef9c955cfa..7cfaa84ba9e 100644
--- a/libstdc++-v3/include/experimental/bits/simd.h
+++ b/libstdc++-v3/include/experimental/bits/simd.h
@@ -1651,7 +1651,17 @@ __as_vector(_V __x)
if constexpr (__is_vector_type_v<_V>)
return __x;
else if constexpr (is_simd<_V>::value || is_simd_mask<_V>::value)
- return __data(__x)._M_data;
+ {
+ if constexpr (_V::size() > 1)
+ return __data(__x)._M_data;
+ else
+ {
+ static_assert(is_simd<_V>::value);
+ using _Tp = typename _V::value_type;
+ using _RV [[__gnu__::__vector_size__(sizeof(_Tp))]] = _Tp;
+ return _RV{__data(__x)};
+ }
+ }
else if constexpr (__is_vectorizable_v<_V>)
return __vector_type_t<_V, 2>{__x};
else
@@ -2061,6 +2071,22 @@ __not(_Tp __a) noexcept
return ~__a;
}
+// }}}
+// __vec_shuffle{{{
+template
+ _GLIBCXX_SIMD_INTRINSIC constexpr auto
+ __vec_shuffle(_T0 __x, _T1 __y, index_sequence<_Is...>, _Fun __idx_perm)
+ { return __builtin_shufflevector(__x, __y, [=] {
+constexpr int __j = __idx_perm(_Is);
+static_assert(__j < sizeof...(_Is));
+return __j;
+ }()...); }
+
+template
+ _GLIBCXX_SIMD_INTRINSIC constexpr auto
+ __vec_shuffle(_T0 __x, index_sequence<_Is...>, _Fun __idx_perm)
+ { return __builtin_shufflevector(__x, _T0(), __idx_perm(_Is)...); }
+
// }}}
// __concat{{{
template ,
@@ -3947,7 +3973,7 @@ clamp(const simd<_Tp, _Ap>& __v, const simd<_Tp, _Ap>&
__lo, const simd<_Tp, _Ap
// __extract_part {{{
template
_GLIBCXX_SIMD_INTRINSIC _GLIBCXX_CONST constexpr
- _SimdWrapper<_Tp, _Np / _Total * _Combine>
+ conditional_t<_Np == _Total and _Combine == 1, _Tp, _SimdWrapper<_Tp, _Np /
_Total * _Combine>>
__extract_part(const _SimdWrapper<_Tp, _Np> __x);
template
@@ -4231,47 +4257,28 @@ static_assert(
__split_wrapper(_SL::template _S_pop_front<1>(),
__data(__x).second));
}
-else if constexpr ((!is_same_v> && ...)
- && (!__is_fixed_size_abi_v<
-simd_abi::deduce_t<_Tp, _Sizes>> && ...))
+else if constexpr ((!__is_fixed_size_abi_v> && ...))
{
- if constexpr (((_Sizes * 2 == _Np) && ...))
- return {{__private_init, __extract_part<0, 2>(__data(__x))},
- {__private_init, __extract_part<1, 2>(__data(__x))}};
- else if constexpr (is_same_v<_SizeList<_Sizes...>,
-_SizeList<_Np / 3, _Np / 3, _Np / 3>>)
- return {{__private_init, __extract_part<0, 3>(__data(__x))},
- {__private_init, __extract_part<1, 3>(__data(__x))},
- {__private_init, __extract_part<2, 3>(__data(__x))}};
- else if constexpr (is_same_v<_SizeList<_Sizes...>,
-_SizeList<2 * _Np / 3, _Np / 3>>)
- return {{__private_init, __extract_part<0, 3, 2>(__data(__x))},
- {__private_init, __extract_part<2, 3>(__data(__x))}};
- else if constexpr (is_same_v<_SizeList<_Sizes...>,
-_SizeList<_Np / 3, 2 * _Np / 3>>)
- return {{__private_init, __extract_part<0, 3>(__data(__x))},
- {__private_init, __extract_part<1, 3, 2>(__data(__x))}};
- else if constexpr (is_same_v<_SizeList<_Sizes...>,
-_SizeList<_Np / 2, _Np / 4, _Np / 4>>)
- return {{__private_init, __extract_part<0, 2>(__data(__x))},
- {__private_init, __extract_part<2, 4>(__data(__x))},
- {__private_init, __extract_part<3, 4>(__data(__x))}};
- else if constexpr (is_same_v<_SizeList<_Sizes...>,
-_SizeList<_Np / 4, _Np / 4, _Np / 2>>)
- return {{__private_init, __extract_part<0, 4>(__data(__x))},
- {__private_init, __extract_part<1, 4>(__data(__x))},
- {__private_init, __extract_part<1, 2>(__data(__x))}};
- else if constexpr (is_same_v<_SizeList<_Sizes...>,
-_SizeList<_Np / 4, _Np / 2, _Np / 4>>)
- return {{__private_init, __extract_part<0, 4>(__data(__x))},
- {__private_init, __extract_center(__data(__x))},
- {__private_init, __extract_part<3, 4>(__data(__x))}};
- else if constexpr (((_Size
[Bug libstdc++/114958] use __builtin_shufflevector for std::experimental::simd split and concat (at least the common cases) to enable better optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114958 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I'm not sure the header should use __builtin_shufflevector unconditionally, I think better test it using __has_builtin first. GCC has it since GCC 12 I think, clang indeed much longer, not sure about other compilers (ICC).
[Bug tree-optimization/114937] [11 regression] -ftree-vrp optimizes out range check before conditional increment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114937 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Richard Biener --- I'll see if it's possible to pick the fix, but I won't promise anything since GCC 11 is now quite old.
[Bug tree-optimization/114948] [14/15 Regression] ICE on valid code at -O3 with "-fno-tree-ccp -fno-tree-ch" on x86_64-linux-gnu: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114948 Richard Biener changed: What|Removed |Added Target||x86_64-*-* CC||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- I can't reproduce on the 14 branch head (with checking enabled).
[Bug tree-optimization/114948] [15 Regression] ICE on valid code at -O3 with "-fno-tree-ccp -fno-tree-ch" on x86_64-linux-gnu: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114948 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org Summary|[14/15 Regression] ICE on |[15 Regression] ICE on |valid code at -O3 with |valid code at -O3 with |"-fno-tree-ccp |"-fno-tree-ccp |-fno-tree-ch" on|-fno-tree-ch" on |x86_64-linux-gnu: in|x86_64-linux-gnu: in |check_loop_closed_ssa_def, |check_loop_closed_ssa_def, |at |at |tree-ssa-loop-manip.cc:647 |tree-ssa-loop-manip.cc:647 --- Comment #3 from Sam James --- Nor me, just trunk..
[Bug libstdc++/114958] use __builtin_shufflevector for std::experimental::simd split and concat (at least the common cases) to enable better optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114958 --- Comment #3 from Matthias Kretz (Vir) --- Hmm, it actually fails on Clang because Clang requires the vector width of both arguments to be equal. But yes, I guess I should make __vec_shuffle friendlier to non-GCC compilers. I'm not sure about backporting, maybe GCC 14.2 can get it? I'd be happy for feedback about my dg-* usage, though. It's the first time I try to require a certain optimized outcome. I guess it would be better to scan for the shuffle pattern rather than the selected instruction? I'm a noob on that topic.
[Bug tree-optimization/114959] New: incorrect TBAA for drived types involving function types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114959
Bug ID: 114959
Summary: incorrect TBAA for drived types involving function
types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
The example below shows that aliasing analysis treats some derived types as
incompatible even though they are derived from compatible types char (*)[1] and
char (*)[] and should then be compatible themselves.
The effect type rules are defined in "6.5 Expressions" and allows accesses with
— a type compatible with the effective type of the object,
— a qualified version of a type compatible with the effective type of the
object,
— a type that is the signed or unsigned type corresponding to the effective
type of the object,
— a type that is the signed or unsigned type corresponding to a qualified
version of the effective type of the object,
— an aggregate or union type that includes one of the aforementioned types
among its members
(including, recursively, a member of a subaggregate or contained union), or
— a character type.
The relevant condition is the first which refers to type compatibility.
Type compatibility rules are defined in "6.2.7 Type compatibility and composite
type"
"Two types are compatible types if they are the same. Additional rules for
determining whether two types are compatible are described in 6.7.2 for type
specifiers, in 6.7.3 for type qualifiers, and in 6.7.6 for declarators.58)
Moreover, two complete structure, union, or enumerated types declared..."
In 6.7.6 we then have
"For two pointer types to be compatible, both shall be identically qualified
and both shall be pointers to compatible types."
"For two array types to be compatible, both shall have compatible element
types, and if both size specifiers are present, and are integer constant
expressions, then both size specifiers shall have the same constant value."
"For two function types to be compatible, both shall specify compatible return
types. Moreover, the parameter type lists shall agree in the number of
parameters and in use of the final ellipsis; corresponding parameters shall
have compatible types. In the determination of type compatibility and of a
composite type, each parameter declared with function or array type is taken as
having the adjusted type and each parameter declared with qualified type is
taken as having the unqualified version of its declared type."
So type compatibility builds up recursively and types derived in the same way
from different but compatible types are compatible.
Example:
https://godbolt.org/z/rTsE3PhKc
#define COMPAT
typedef char (*(*t0)())[];
typedef char (*(*t1)())[1];
#ifdef COMPAT
typedef char (*(*t2)())[/*2*/];
#else
typedef char (*(*t2)())[2];
#endif
//[[gnu::noinline]]
t0 foo(t0 *x, t0 *y, t0 u, t0 v)
{
t1 *a = x;
t2 *b = y;
#ifdef COMPAT
_Static_assert(_Generic(*b, typeof(*a): 1, default: 0), "");
#endif
(*a) = u;
// since *a and *b alias and the types are compatible,
// this should overwrite the result
(*b) = v;
return *a;
}
char (*(a()))[1] { return 0; }
char (*(b()))[2] { return 0; }
int main()
{
t0 t;
return &a == foo(&t, &t, &a, &b);
}
[Bug libstdc++/114958] use __builtin_shufflevector for std::experimental::simd split and concat (at least the common cases) to enable better optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114958 --- Comment #4 from Jakub Jelinek --- Strange, the __builtin_shufflevector in GCC has been added for Clang compatibility. __builtin_shuffle is the original native GCC builtin (which Clang doesn't implement).
[Bug target/112959] install.tex needs updates on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112959 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from Gerald Pfeifer --- > Rainer, do you think the three changes I made - and hence the current > state of install.texi on trunk - address all the issues you reported > and sufficiently well? What's there looks good to me. However, one issue mentioned in PR target/112959 is missing, namely the problem of getting a working Ada bootstrap compiler. I have no idea if gnat12 has been fixed since and is now able to build Ada on trunk/the gcc-14 branch. Otherwise, the old GNAT 6.4.1 worked for me, but this isn't easy to find. AFAICS, AdaCore provides no FreeBSD GNAT tarball of any kind.
[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527 --- Comment #6 from Deepthi H --- Created attachment 58107 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58107&action=edit workaround for gcc driver long argument list error
[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527
--- Comment #7 from Deepthi H ---
We've a solution for this issue.
When gcc/g++ is called using the @response-file.rsp syntax, gcc should forward
the argument to its subprocesses. Previously the files were expanded which
could lead to excessively long argument lists and 'cc1: execv: Argument list
too long' errors.
In particular, CMake and Ninja tend to create a lot of '-isystem' include
directories, requiring allowing the forwarding in spec files by using %@{i*}.
In xputenv method, If the ENV variable size greater then 128kb then we split
the ENV variable(i.e COLLECT_GCC_OPTIONS) where each chunk will be 128kb in
length.
GCC passes the entire command line, including expanded @rsp-files to the
collect2 in environment variable COLLECT_GCC_OPTIONS. This can exceed the build
environment's kernel's environment variable length limit. In this workaround,
environment variables longer than 128kb are split into multiple variables and
stitched back together in collect2.
The patch is attached here.
And, the patch output of the example code given in 'Description' as below:
===
sunild@BFT-LPT-I-051:~$ $GCC_PATH/gcc -c a.c -DA=$big_100k_var
-DB=$big_100k_var -v
Using built-in specs.
COLLECT_GCC=/home/sunild/GCC_Driver/bin/home/sunild/GCC_Driver/build/bin/gcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/sunild/GCC_Driver/build
--enable-languages=c --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240426 (experimental) (GCC)
COLLECT_GCC_OPTIONS_0='-c' '-D'
'A=
COLLECT_GCC_OPTIONS_1=0
COLLECT_GCC_OPTIONS_COUNT=2
===
Let us know your comments on this solution. Such a solution is acceptable to
change the gcc driver?
[Bug tree-optimization/114959] incorrect TBAA for drived types involving function types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114959 Richard Biener changed: What|Removed |Added Version|unknown |14.0 Keywords||wrong-code CC||hubicka at gcc dot gnu.org --- Comment #1 from Richard Biener --- alias.c does /* See if the language has special handling for this type. */ set = lang_hooks.get_alias_set (t); if (set != -1) return set; /* There are no objects of FUNCTION_TYPE, so there's no point in using up an alias set for them. (There are, of course, pointers and references to functions, but that's different.) */ else if (TREE_CODE (t) == FUNCTION_TYPE || TREE_CODE (t) == METHOD_TYPE) set = 0; but when handling pointer-to-function we simply create a new alias-set for each distinct (according to TYPE_CANONICAL (TYPE_MAIN_VARIANT ( pointed-to type. It's going to be difficult to canonicalize return and argument types here, so the answer is probably tree.cc:maybe_canonicalize_argtypes and thus reflecting this in the TYPE_CANONICAL of the function type. Note this is also how we handle pointer to structure types, but as structures are real objects those already have TYPE_CANONICAL set up appropriately. So I wonder whether the C frontend doesn't need to do the same for FUNCTION_TYPEs rather than putting the burden on the middle-end here?
[Bug tree-optimization/113622] [11/12/13 Regression] ICE with vectors in named registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622 Richard Biener changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug c++/114275] using std::thread within a templated function in a module fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114275 Adhemerval Zanella changed: What|Removed |Added CC||adhemerval.zanella at linaro dot o ||rg --- Comment #8 from Adhemerval Zanella --- (In reply to GCC Commits from comment #6) > The master branch has been updated by Nathaniel Shead : > > https://gcc.gnu.org/g:b5f6a56940e70838a07e885de03a92e2bd64674a > > commit r15-59-gb5f6a56940e70838a07e885de03a92e2bd64674a > Author: Nathaniel Shead > Date: Mon Apr 29 17:00:13 2024 +1000 > > c++: Fix instantiation of imported temploid friends [PR114275] > > This patch fixes a number of issues with the handling of temploid friend > declarations. > > The primary issue is that instantiations of friend declarations should > attach the declaration to the same module as the befriending class, by > [module.unit] p7.1 and [temp.friend] p2; this could be a different > module from the current TU, and so needs special handling. > > The other main issue here is that we can't assume that just because name > lookup didn't find a definition for a hidden class template, that it > doesn't exist at all: it could be a non-exported entity that we've > nevertheless streamed in from an imported module. We need to ensure > that when instantiating template friend classes that we return the same > TEMPLATE_DECL that we got from our imports, otherwise we will get later > issues with 'duplicate_decls' (rightfully) complaining that they're > different when trying to merge. > > This doesn't appear necessary for function templates due to the existing > name lookup handling already finding these hidden declarations. > > PR c++/105320 > PR c++/114275 > > gcc/cp/ChangeLog: > > * cp-tree.h (propagate_defining_module): Declare. > (lookup_imported_hidden_friend): Declare. > * decl.cc (duplicate_decls): Also check if hidden decls can be > redeclared in this module. > * module.cc (imported_temploid_friends): New. > (init_modules): Initialize it. > (trees_out::decl_value): Write it; don't consider imported > temploid friends as attached to a module. > (trees_in::decl_value): Read it. > (get_originating_module_decl): Follow the owning decl for an > imported temploid friend. > (propagate_defining_module): New. > * name-lookup.cc (get_mergeable_namespace_binding): New. > (lookup_imported_hidden_friend): New. > * pt.cc (tsubst_friend_function): Propagate defining module for > new friend functions. > (tsubst_friend_class): Lookup imported hidden friends. Check > for valid module attachment of existing names. Propagate > defining module for new classes. > > gcc/testsuite/ChangeLog: > > * g++.dg/modules/tpl-friend-10_a.C: New test. > * g++.dg/modules/tpl-friend-10_b.C: New test. > * g++.dg/modules/tpl-friend-10_c.C: New test. > * g++.dg/modules/tpl-friend-10_d.C: New test. > * g++.dg/modules/tpl-friend-11_a.C: New test. > * g++.dg/modules/tpl-friend-11_b.C: New test. > * g++.dg/modules/tpl-friend-12_a.C: New test. > * g++.dg/modules/tpl-friend-12_b.C: New test. > * g++.dg/modules/tpl-friend-12_c.C: New test. > * g++.dg/modules/tpl-friend-12_d.C: New test. > * g++.dg/modules/tpl-friend-12_e.C: New test. > * g++.dg/modules/tpl-friend-12_f.C: New test. > * g++.dg/modules/tpl-friend-13_a.C: New test. > * g++.dg/modules/tpl-friend-13_b.C: New test. > * g++.dg/modules/tpl-friend-13_c.C: New test. > * g++.dg/modules/tpl-friend-13_d.C: New test. > * g++.dg/modules/tpl-friend-13_e.C: New test. > * g++.dg/modules/tpl-friend-13_f.C: New test. > * g++.dg/modules/tpl-friend-13_g.C: New test. > * g++.dg/modules/tpl-friend-14_a.C: New test. > * g++.dg/modules/tpl-friend-14_b.C: New test. > * g++.dg/modules/tpl-friend-14_c.C: New test. > * g++.dg/modules/tpl-friend-14_d.C: New test. > * g++.dg/modules/tpl-friend-9.C: New test. > > Signed-off-by: Nathaniel Shead > Reviewed-by: Jason Merrill This has triggered some regression on aarch64 [1]: Running g++:g++.dg/modules/modules.exp ... FAIL: g++.dg/modules/tpl-friend-4_b.C -std=c++17 (test for errors, line 16) FAIL: g++.dg/modules/tpl-friend-4_b.C -std=c++17 (test for errors, line 19) FAIL: g++.dg/modules/tpl-friend-4_b.C -std=c++17 (internal compiler
[Bug tree-optimization/114551] [14 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-2944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114551 Richard Biener changed: What|Removed |Added Summary|[13 Regression] wrong code |[14 Regression] wrong code |at -O3 on x86_64-linux-gnu |at -O3 on x86_64-linux-gnu |since r14-2944 |since r14-2944 Resolution|--- |FIXED Target Milestone|13.3|14.0 Status|ASSIGNED|RESOLVED --- Comment #9 from Richard Biener --- Too awkward to backport, depend on rewrite_to_defined_overflow API re-org. Fixed in GCC 14.
[Bug tree-optimization/100923] [9 Regression] wrong code at -O2 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100923 --- Comment #11 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:7c469a9fc785505dc350aba60311812c2bb0c1b5 commit r15-204-g7c469a9fc785505dc350aba60311812c2bb0c1b5 Author: Richard Biener Date: Wed Feb 28 10:08:31 2024 +0100 tree-optimization/100923 - re-do VN with contextual PTA info fix The following implements the gist of the PR100923 fix in a leaner (and more complete) way by realizing that all ao_ref_init_from_vn_reference uses need to have an SSA name in the base valueized with availability in mind. Instead of re-valueizing the whole chain of operands we can simply only and always valueize the SSA name we put in the base. This handles also two omitted places in vn_reference_lookup_3. PR tree-optimization/100923 * tree-ssa-sccvn.cc (ao_ref_init_from_vn_reference): Valueize base SSA_NAME. (vn_reference_lookup_3): Adjust vn_context_bb around calls to ao_ref_init_from_vn_reference. (vn_reference_lookup_pieces): Revert original PR100923 fix. (vn_reference_lookup): Likewise.
[Bug tree-optimization/114246] [11/12/13 Regression] ICE: verify_gimple failed: invalid argument to gimple call with __builtin_memcpy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114246 --- Comment #7 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:c4795316b2d92c9edd3d86ffa11425c82d1e379c commit r13-8694-gc4795316b2d92c9edd3d86ffa11425c82d1e379c Author: Richard Biener Date: Wed Mar 6 09:02:31 2024 +0100 tree-optimization/114246 - invalid call argument from DSE The following makes sure to strip type conversions added by build_fold_addr_expr before placing the result in a call argument. PR tree-optimization/114246 * tree-ssa-dse.cc (increment_start_addr): Strip useless type conversions from the adjusted address. * gcc.dg/torture/pr114246.c: New testcase. (cherry picked from commit 0249744a9fe0775c2c895727aeebec4c59fd5f95)
[Bug tree-optimization/113630] [11/12/13 Regression] -fno-strict-aliasing introduces out-of-bounds memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113630 --- Comment #8 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:47cd06042237bf2d4f05b8355362bc038f6fa445 commit r13-8693-g47cd06042237bf2d4f05b8355362bc038f6fa445 Author: Richard Biener Date: Wed Jan 31 11:28:50 2024 +0100 tree-optimization/113630 - invalid code hoisting The following avoids code hoisting (but also PRE insertion) of expressions that got value-numbered to another one that are not a valid replacement (but still compute the same value). This time because the access path ends in a structure with different size, meaning we consider a related access as not trapping because of the size of the base of the access. PR tree-optimization/113630 * tree-ssa-pre.cc (compute_avail): Avoid registering a reference with a representation with not matching base access size. * gcc.dg/torture/pr113630.c: New testcase. (cherry picked from commit 724b64304ff5c8ac08a913509afd6fde38d7b767)
[Bug target/114734] [11/12/13 regression] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl since r8-6047-g65dd1346027bb5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 --- Comment #19 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:20ebcaf826c91ddaf2aac35417ec1e5e6d31ad50 commit r13-8695-g20ebcaf826c91ddaf2aac35417ec1e5e6d31ad50 Author: Richard Biener Date: Fri Apr 26 15:47:13 2024 +0200 middle-end/114734 - wrong code with expand_call_mem_ref When expand_call_mem_ref looks at the definition of the address argument to eventually expand a &TARGET_MEM_REF argument together with a masked load it fails to honor constraints imposed by SSA coalescing decisions. The following fixes this. PR middle-end/114734 * internal-fn.cc (expand_call_mem_ref): Use get_gimple_for_ssa_name to get at the def stmt of the address argument to honor SSA coalescing constraints. (cherry picked from commit 4d3a5618de5a949c61605f545f90e81bc502)
[Bug tree-optimization/114787] [13 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787 --- Comment #19 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:715a1df9082b40cf810283632218258ac9c86773 commit r13-8697-g715a1df9082b40cf810283632218258ac9c86773 Author: Richard Biener Date: Wed Apr 24 08:42:40 2024 +0200 tree-optimization/114787 - more careful loop update with CFG cleanup When CFG cleanup removes a backedge we have to be more careful with loop update. In particular we need to clear niter info and estimates and if we remove the last backedge of a loop we have to also mark it for removal to prevent a following basic block merging to associate loop info with an unrelated header. PR tree-optimization/114787 * tree-cfg.cc (remove_edge_and_dominated_blocks): When removing a loop backedge clear niter info and when removing the last backedge of a loop mark that loop for removal. * gcc.dg/torture/pr114787.c: New testcase. (cherry picked from commit cc48418cfc2e555d837ae9138cbfac23acb3cdf9)
[Bug target/114734] [11/12/13 regression] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl since r8-6047-g65dd1346027bb5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 --- Comment #20 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:4c3011ec4825bf06c9d268361a53f8239bf9564a commit r13-8696-g4c3011ec4825bf06c9d268361a53f8239bf9564a Author: Patrick O'Neill Date: Tue Apr 30 13:26:45 2024 -0700 RISC-V: Add testcase for pr114734 gcc/testsuite/ChangeLog: PR middle-end/114734 * gcc.target/riscv/rvv/autovec/pr114734.c: New test. Signed-off-by: Patrick O'Neill (cherry picked from commit ff4dc8b10a421cdb0c56f7f8c238609de4f9fbe2)
[Bug tree-optimization/114799] [13 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85 with -O2 -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114799 --- Comment #10 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:026ecb914d3d84c6e803cedb8b1677d3e7ddd60f commit r13-8698-g026ecb914d3d84c6e803cedb8b1677d3e7ddd60f Author: Richard Biener Date: Tue Apr 23 08:39:03 2024 +0200 tree-optimization/114799 - SLP and patterns The following plugs a hole with computing whether a SLP node has any pattern stmts which is important to know when we want to replace it by a CTOR from external defs. PR tree-optimization/114799 * tree-vect-slp.cc (vect_get_and_check_slp_defs): Properly update ->any_pattern when swapping operands. * gcc.dg/vect/bb-slp-pr114799.c: New testcase. (cherry picked from commit 18e8e55487238237f37f621668fdee316624981a)
[Bug tree-optimization/114787] [13 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787 Richard Biener changed: What|Removed |Added Known to fail||13.2.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to work||13.2.1 --- Comment #20 from Richard Biener --- Fixed.
[Bug tree-optimization/114799] [13 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85 with -O2 -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114799 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Known to fail||13.2.0 Status|ASSIGNED|RESOLVED --- Comment #11 from Richard Biener --- Fixed for GCC13+.
[Bug tree-optimization/113630] [11/12 Regression] -fno-strict-aliasing introduces out-of-bounds memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113630 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Known to fail||13.2.0 Status|ASSIGNED|NEW Known to work||13.2.1 Summary|[11/12/13 Regression] |[11/12 Regression] |-fno-strict-aliasing|-fno-strict-aliasing |introduces out-of-bounds|introduces out-of-bounds |memory access |memory access Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #9 from Richard Biener --- Backported as far as I want.
[Bug target/114944] Codegen of __builtin_shuffle for an 16-byte uint8_t vector is suboptimal on SSE2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114944 --- Comment #2 from John Platts --- Here is more optimal codegen for SSE2ShuffleI8 on x86_64: SSE2ShuffleI8(long long __vector(2), long long __vector(2)): pandxmm1, XMMWORD PTR .LC0[rip] movaps XMMWORD PTR [rsp-24], xmm0 movdeax, xmm1 movzx eax, al movzx eax, BYTE PTR [rsp-24+rax] movaps XMMWORD PTR [rsp-40], xmm1 movdxmm0, eax movzx eax, BYTE PTR [rsp-39] movzx eax, BYTE PTR [rsp-24+rax] movdxmm2, eax movzx eax, BYTE PTR [rsp-38] punpcklbw xmm0, xmm2 movzx eax, BYTE PTR [rsp-24+rax] movdxmm8, eax movzx eax, BYTE PTR [rsp-37] movzx eax, BYTE PTR [rsp-24+rax] movdxmm2, eax movzx eax, BYTE PTR [rsp-36] punpcklbw xmm8, xmm2 movzx eax, BYTE PTR [rsp-24+rax] punpcklwd xmm0, xmm8 movdxmm5, eax movzx eax, BYTE PTR [rsp-35] movzx eax, BYTE PTR [rsp-24+rax] movdxmm2, eax movzx eax, BYTE PTR [rsp-34] punpcklbw xmm5, xmm2 movzx eax, BYTE PTR [rsp-24+rax] movdxmm7, eax movzx eax, BYTE PTR [rsp-33] movzx eax, BYTE PTR [rsp-24+rax] movdxmm2, eax movzx eax, BYTE PTR [rsp-32] punpcklbw xmm7, xmm2 movzx eax, BYTE PTR [rsp-24+rax] punpcklwd xmm5, xmm7 punpckldq xmm0, xmm5 movdxmm3, eax movzx eax, BYTE PTR [rsp-31] movzx eax, BYTE PTR [rsp-24+rax] movdxmm4, eax movzx eax, BYTE PTR [rsp-30] punpcklbw xmm3, xmm4 movzx eax, BYTE PTR [rsp-24+rax] movdxmm6, eax movzx eax, BYTE PTR [rsp-29] movzx eax, BYTE PTR [rsp-24+rax] movdxmm2, eax movzx eax, BYTE PTR [rsp-28] punpcklbw xmm6, xmm2 movzx eax, BYTE PTR [rsp-24+rax] punpcklwd xmm3, xmm6 movdxmm2, eax movzx eax, BYTE PTR [rsp-27] movzx eax, BYTE PTR [rsp-24+rax] movdxmm4, eax movzx eax, BYTE PTR [rsp-26] punpcklbw xmm2, xmm4 movzx eax, BYTE PTR [rsp-24+rax] movdxmm4, eax movzx eax, BYTE PTR [rsp-25] movzx eax, BYTE PTR [rsp-24+rax] movdxmm1, eax punpcklbw xmm4, xmm1 movdqa xmm1, xmm2 movdqa xmm2, xmm3 punpcklwd xmm1, xmm4 punpckldq xmm2, xmm1 punpcklqdq xmm0, xmm2 ret .LC0: .quad 1085102592571150095 .quad 1085102592571150095
[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 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comment #14 from Sergei Trofimovich --- I reproduced the `SIGSEGV` on Gentoo ~amd64 and ::sage-on-gentoo overlay against sci-mathematics/sagemath-standard package. One of the unusual properties of __pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__() is that it raises 2 signals while it gets executed: - SIGABRT handler uses longjmp() to return to the ~beginning of a function - and then SIGSEGV happens at cleanup when an attempt to dereference the pointer happens. I see no `volatile` annotations anywhere in the __pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__(). My wild guess would be that: 1. `PyObject *__pyx_t_4 = ((void *)0);` gets saved in setjmp() with one value (probably NULL) 2. updated at some point later in the same function to non-NULL that `gcc` can infer and throw away all later `NULL` checks 3. then SIGABRT returns with longjmp() by accidentally resetting I would expect `__pyx_t_4` to require volatile annotation for such an `element.i` definition. Or `longjmp()` should be called from a `((noipa))` function to force register spill/reload on stack. To cite `man setjmp`: """ CAVEATS The compiler may optimize variables into registers, and longjmp() may restore the values of other registers in addition to the stack pointer and program counter. Consequently, the values of automatic variables are unspecified after a call to longjmp() if they meet all the following criteria: • they are local to the function that made the corresponding setjmp() call; • their values are changed between the calls to setjmp() and longjmp(); and • they are not declared as volatile. Analogous remarks apply for siglongjmp(). """ Sounds plausible?
[Bug c++/114867] [modules] name lookup issues when a function overload set is exported from GMF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114867
--- Comment #1 from m.cencora at gmail dot com ---
The unreduced code is actually a regression from gcc-12.
@Jonathan Wakely:
Could you maybe workaround it in libstdc++ by declaring the std::swap overload
for exception_ptr in additional inline namespace in std, like this:
namespace std {
namespace __exception_ptr {
class exception_ptr;
void swap(exception_ptr& a, exception_ptr& b);
}
using __exception_ptr::exception_ptr;
inline namespace __exception_ptr_swap {
using __exception_ptr::swap;
}
}
[Bug middle-end/114907] __trunchfbf2 should be renamed to __extendhfbf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Created attachment 58108 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58108&action=edit gcc15-pr114907.patch In retrospect, it has been a mistake to export __trunchfbf2 rather than __extendhfbf2, but we've done that already. Given that it is an arbitrary name choice (both are wrong), I think it is better to change what gcc emits rather than what functions libgcc exports, because we can backport what gcc emits but can't the libgcc changes.
[Bug target/114960] New: [12/13/14/15 Regression] fails to clean up vector casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114960
Bug ID: 114960
Summary: [12/13/14/15 Regression] fails to clean up vector
casts
Product: gcc
Version: 12.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
#include
__m128i f(__m128i dummy, __m128i x)
{
__v16qi v = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 };
return (__m128i)((__v16qi)x + v);
}
Starting from gcc-12, we get
movdqa .LC0(%rip), %xmm2
paddb %xmm1, %xmm2
movdqa %xmm2, %xmm0
ret
while previously it was
movdqa .LC0(%rip), %xmm0
paddb %xmm1, %xmm0
ret
Diverges in RTL land, starting in combine.
[Bug c++/114961] New: [modules] using imported member functions in constexpr context causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114961
Bug ID: 114961
Summary: [modules] using imported member functions in constexpr
context causes ICE
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jasio.lpn at gmail dot com
Target Milestone: ---
I have custom Vector class that behaves like std::vector - it allocates memory
on heap and frees it in destructor so it can be used in constexpr contexts.
This Vector class is implemented in module interface unit:
// MyVector.cpp
...
export module Vector;
export
template
class Vector
{
...
constexpr Vector(std::size_t initialSize) noexcept
{
...
}
constexpr std::size_t size() const noexcept
{
...
}
};
// end of MyVector.cpp
Now I want to use this is consteval function in main.cpp:
// main.cpp
#include
#include
import MyVector;
consteval auto getArraySize()
{
MyVector vecP(5);
return vecP.size();
}
int main()
{
std::array arr{};
std::cout << "arr size: " << arr.size() << "\n";
}
// end of main.cpp
This code causes ICE:
/usr/local/bin/x86_64-linux-gnu-x86_64-linux-gnu-g++-14 -g -std=gnu++23
-fdiagnostics-color=always -MD -MT /main.cpp.o -MF /main.cpp.o.d
-fmodules-ts -fmodule-mapper=/main.cpp.o.modmap -MD -fdeps-format=p1689r5
-x c++ -o /main.cpp.o -c /main.cpp
/main.cpp:55:1: internal compiler error: in add_to_same_comdat_group, at
symtab.cc:492
55 | }
| ^
0x6adb5d symtab_node::add_to_same_comdat_group(symtab_node*)
../../src/gcc/symtab.cc:492
0x8282c0 maybe_optimize_cdtor(tree_node*)
../../src/gcc/cp/optimize.cc:776
0x7aa967 import_export_decl(tree_node*)
../../src/gcc/cp/decl2.cc:3351
0x7aa967 c_parse_final_cleanups()
../../src/gcc/cp/decl2.cc:5289
0x98da64 c_common_parse_file()
../../src/gcc/c-family/c-opts.cc:1329
GCC version:
gcc version 14.0.1 20240506 (prerelease) (GCC)
[Bug c++/114961] [modules] using imported member functions in constexpr context causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114961 --- Comment #1 from Marcin Nowak --- I typed some typos in main.cpp. There should not be `MyVector` but `Vector`. Anyway this typos does not matter if ICE is caused or not.
[Bug tree-optimization/114959] incorrect TBAA for drived types involving function types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114959 --- Comment #2 from Martin Uecker --- The GCC FE has all the necessary logic to compute type compatibility and this could easily be adapted to compute equivalence classes and then set a TYPE_CANONICAL. All function types in the same class would get the same TYPE_CANONICAL even if a little bit different, i.e. return pointers to compatible but slightly different array types. I think function arguments we need to ignore completely, because T (*f)(); is compatible with all pointers to functions with the same return type. (this is gone in C23 though) Or we special case such functions. What is unclear to me whether function types are the only remaining issue or whether this should then be done for all types (pointers, arrays, etc)?
[Bug target/114944] Codegen of __builtin_shuffle for an 16-byte uint8_t vector is suboptimal on SSE2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114944 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #3 from Alexander Monakov --- Throughput-wise, the code in comment 2 has a significant bottleneck on port 5 on Haswell and Skylake (31 uops out of 70 go to port 5). Straightforward code that does 16x movzx-movzx-movb for each byte should fare better, even considering the load-store penalty for retrieving the vector from memory: pandxmm1, XMMWORD PTR .LC0[rip] movaps XMMWORD PTR [rsp-56], xmm0 movaps XMMWORD PTR [rsp-40], xmm1 movzx eax, BYTE PTR [rsp-40] movzx eax, BYTE PTR [rsp-56+rax] mov BYTE PTR [rsp-24], al movzx eax, BYTE PTR [rsp-39] movzx eax, BYTE PTR [rsp-56+rax] mov BYTE PTR [rsp-23], al movzx eax, BYTE PTR [rsp-38] movzx eax, BYTE PTR [rsp-56+rax] mov BYTE PTR [rsp-22], al movzx eax, BYTE PTR [rsp-37] movzx eax, BYTE PTR [rsp-56+rax] mov BYTE PTR [rsp-21], al movzx eax, BYTE PTR [rsp-36] movzx eax, BYTE PTR [rsp-56+rax] mov BYTE PTR [rsp-20], al movzx eax, BYTE PTR [rsp-35] movzx eax, BYTE PTR [rsp-56+rax] mov BYTE PTR [rsp-19], al movzx eax, BYTE PTR [rsp-34] movzx eax, BYTE PTR [rsp-56+rax] mov BYTE PTR [rsp-18], al movzx eax, BYTE PTR [rsp-33] movzx eax, BYTE PTR [rsp-56+rax] mov BYTE PTR [rsp-17], al movzx eax, BYTE PTR [rsp-32] movzx eax, BYTE PTR [rsp-56+rax] mov BYTE PTR [rsp-16], al movzx eax, BYTE PTR [rsp-31] movzx eax, BYTE PTR [rsp-56+rax] mov BYTE PTR [rsp-15], al movzx eax, BYTE PTR [rsp-30] movzx eax, BYTE PTR [rsp-56+rax] mov BYTE PTR [rsp-14], al movzx eax, BYTE PTR [rsp-29] movzx eax, BYTE PTR [rsp-56+rax] mov BYTE PTR [rsp-13], al movzx eax, BYTE PTR [rsp-28] movzx eax, BYTE PTR [rsp-56+rax] mov BYTE PTR [rsp-12], al movzx eax, BYTE PTR [rsp-27] movzx eax, BYTE PTR [rsp-56+rax] mov BYTE PTR [rsp-11], al movzx eax, BYTE PTR [rsp-26] movzx eax, BYTE PTR [rsp-56+rax] mov BYTE PTR [rsp-10], al movzx eax, BYTE PTR [rsp-25] movzx eax, BYTE PTR [rsp-56+rax] mov BYTE PTR [rsp-9], al movdqa xmm0, XMMWORD PTR [rsp-24] If you want to avoid the load-store forwarding stall, perhaps you can assemble two halves of the shuffled vector on GPRs (e.g. do 'movzx ecx, byte[...]; shl eax, 8; mov al, byte [...+rcx]), then merge two 64-bit GPRs into one 128-bit vector.
[Bug c++/114962] New: For each iteration in static assert fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114962 Bug ID: 114962 Summary: For each iteration in static assert fails to compile Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jdapena at igalia dot com Target Milestone: --- Created attachment 58109 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58109&action=edit Test case The attached example, that allows to make sure all members are defined in a constexpr created std::array, fails in GCC (and works in Clang at least from version 10.x and in current trunk). I am not sure if this is a valid pattern, so reporting a bug to GCC for further analysis.
[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527 --- Comment #8 from Andrew Pinski --- (In reply to Deepthi H from comment #7) > > Let us know your comments on this solution. Such a solution is acceptable to > change the gcc driver? Seems better to place the arguments in a file instead and just pass around that file name instead of passing all arguments via an env variable.
[Bug target/114944] Codegen of __builtin_shuffle for an 16-byte uint8_t vector is suboptimal on SSE2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114944 --- Comment #4 from Alexander Monakov --- Like this: pandxmm1, XMMWORD PTR .LC0[rip] movaps XMMWORD PTR [rsp-40], xmm0 xor eax, eax xor edx, edx movaps XMMWORD PTR [rsp-24], xmm1 movzx ecx, BYTE PTR [rsp-17] mov al, BYTE PTR [rsp-40+rcx] movzx ecx, BYTE PTR [rsp-9] mov dl, BYTE PTR [rsp-40+rcx] movzx ecx, BYTE PTR [rsp-18] sal rax, 8 mov al, BYTE PTR [rsp-40+rcx] movzx ecx, BYTE PTR [rsp-10] sal rdx, 8 mov dl, BYTE PTR [rsp-40+rcx] movzx ecx, BYTE PTR [rsp-19] sal rax, 8 mov al, BYTE PTR [rsp-40+rcx] movzx ecx, BYTE PTR [rsp-11] sal rdx, 8 mov dl, BYTE PTR [rsp-40+rcx] movzx ecx, BYTE PTR [rsp-20] sal rax, 8 mov al, BYTE PTR [rsp-40+rcx] movzx ecx, BYTE PTR [rsp-12] sal rdx, 8 mov dl, BYTE PTR [rsp-40+rcx] movzx ecx, BYTE PTR [rsp-21] sal rax, 8 mov al, BYTE PTR [rsp-40+rcx] movzx ecx, BYTE PTR [rsp-13] sal rdx, 8 mov dl, BYTE PTR [rsp-40+rcx] movzx ecx, BYTE PTR [rsp-22] sal rax, 8 mov al, BYTE PTR [rsp-40+rcx] movzx ecx, BYTE PTR [rsp-14] sal rdx, 8 mov dl, BYTE PTR [rsp-40+rcx] movzx ecx, BYTE PTR [rsp-23] sal rax, 8 mov al, BYTE PTR [rsp-40+rcx] movzx ecx, BYTE PTR [rsp-15] sal rdx, 8 mov dl, BYTE PTR [rsp-40+rcx] movzx ecx, BYTE PTR [rsp-24] sal rax, 8 mov al, BYTE PTR [rsp-40+rcx] movzx ecx, BYTE PTR [rsp-16] sal rdx, 8 mov dl, BYTE PTR [rsp-40+rcx] movqxmm0, rax movqxmm2, rdx punpcklqdq xmm0, xmm2
[Bug c++/114962] For each iteration in static assert fails to compile with pointer to member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114962 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-05-06 --- Comment #1 from Andrew Pinski --- Confirmed, This looks like another "pointer to member function" issue (I changed the array to being int and it works). If we move the static assert/lamdba outside of the class, it works; so it looks like maybe (non-)complete class context issue going on here.
[Bug c++/114962] For each iteration in static assert fails to compile with pointer to member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114962 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- I agree; seems valid to me.
[Bug rtl-optimization/114960] [12/13/14/15 Regression] fails to clean up vector casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114960 Andrew Pinski changed: What|Removed |Added Component|target |rtl-optimization Keywords||missed-optimization, ra --- Comment #1 from Andrew Pinski --- The difference between GCC 11 and 12 is just: (subreg:V16QI (reg:V2DI 84 [ ]) 0) vs (reg:V16QI 88) For the lhs of the plus. This is a RA issue. There are a few bugs about subreg and RA somewhere ...
[Bug c++/114275] using std::thread within a templated function in a module fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114275 --- Comment #9 from Andrew Pinski --- (In reply to Adhemerval Zanella from comment #8) > This has triggered some regression on aarch64 [1]: > > Running g++:g++.dg/modules/modules.exp ... > FAIL: g++.dg/modules/tpl-friend-4_b.C -std=c++17 (test for errors, line 16) > FAIL: g++.dg/modules/tpl-friend-4_b.C -std=c++17 (test for errors, line 19) > FAIL: g++.dg/modules/tpl-friend-4_b.C -std=c++17 (internal compiler error: > in set_originating_module, at cp/module.cc:19236) > FAIL: g++.dg/modules/tpl-friend-4_b.C -std=c++17 (test for excess errors) > > https://ci.linaro.org/job/tcwg_gnu_native_check_gcc--master-aarch64-build/ > 1092/artifact/artifacts/notify/mail-body.txt/*view*/ Yes this is known already see thread starting at https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650315.html . I think there was a new patch submitted already too.
[Bug middle-end/113180] MIPS: bitops on an long long struct uses ins instead dins (or with -mstrict-align on aarch64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113180 --- Comment #3 from YunQiang Su --- The argument `to` of `expand_assignment` differs between `strict-align` and `no-strict-align`. `debug_tree` states that the `strict-align` one has a `MEMREF` RTL, while `no-strict-align` has a `reg` one. Any idea when the RTL is generated from STMT?
[Bug target/112868] GCC passes -many to the assembler for --enable-checking=release builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112868 --- Comment #13 from Niels Möller --- (In reply to Peter Bergner from comment #11) > This is clearly a stage1 patch, so we'll wait until > then before submitting it. I'm not that familiar with gcc development procedures. Do I understand you correctly, that a fix for this bug will not be included in gcc-14 (according to https://gcc.gnu.org/develop.html#timeline, gcc-14 stage1 ended several months ago), it will have to wait for gcc-15?
[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606 --- Comment #32 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:08e752e72363ae7fd5a5fcb70913a0f7b240387b commit r15-207-g08e752e72363ae7fd5a5fcb70913a0f7b240387b Author: Georg-Johann Lay Date: Fri May 3 18:47:50 2024 +0200 AVR: ipa/92606 - Don't optimize PROGMEM data against non-PROGMEM. ipa/92606: Inter-procedural analysis optimizes data across address-spaces and PROGMEM. As of v14, the PROGMEM part is still not fixed (and there is still no target hook as proposed in PR92932). Just disable respective bogus optimization. PR ipa/92606 gcc/ * config/avr/avr.cc (avr_option_override): Set flag_ipa_icf_variables = 0. gcc/testsuite/ * gcc.target/avr/torture/pr92606.c: New test.
[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606 --- Comment #33 from GCC Commits --- The releases/gcc-13 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:287293786d541217e7bf47cab6b8fb522ae9156a commit r13-8699-g287293786d541217e7bf47cab6b8fb522ae9156a Author: Georg-Johann Lay Date: Fri May 3 18:47:50 2024 +0200 AVR: ipa/92606 - Don't optimize PROGMEM data against non-PROGMEM. ipa/92606: Inter-procedural analysis optimizes data across address-spaces and PROGMEM. As of v14, the PROGMEM part is still not fixed (and there is still no target hook as proposed in PR92932). Just disable respective bogus optimization. PR ipa/92606 gcc/ * config/avr/avr.cc (avr_option_override): Set flag_ipa_icf_variables = 0. gcc/testsuite/ * gcc.target/avr/torture/pr92606.c: New test. (cherry picked from commit 08e752e72363ae7fd5a5fcb70913a0f7b240387b)
[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 #15 from Jakub Jelinek --- (In reply to Dmitrii Pasechnik from comment #12) > A colleague disassembled, using ghidra (https://ghidra-sre.org/), the > results of the compilations with, respectively, -O2 and with -O0 flags. > Comparing the results, in the broken (built with -O2) case one sees a > miscompilation of a call to GAP_CallFunc3Args - it is called with one > argument less than it should, three instead of four! > > broken (-O2): > > > plVar9 = (long *)GAP_CallFunc3Args(*(undefined8 *)(param_1 + > > 0x20),local_a0[4], > > local_a8[4]); > > vs. good (-O0): > > < LAB_0013cbd9: > < plVar10 = (long *)GAP_CallFunc3Args(*(undefined8 *)(param_1 + > 0x20),local_a8[4], > < local_a0[4],plVar16[4]); > > And this is despite the prototype for calling GAP_CallFunc3Args() is > found in "gap/libgap-api.h", which is included in example.c as #include > "gap/libgap-api.h", meant to be respected during the compilation. > > I hope this helps in chasing down the obvious compiler bug. Perhaps it can > be also seen without disassembling, simply on the intermediate data > generated by the compiler. Both calls pass 4 arguments, both in optimized -O2 -fPIC GCC 13.2.1 dump and in assembly: movq-88(%rbp), %rdx movq%r12, %rcx movq%r13, %rsi movq%rax, %rdi callGAP_CallFunc3Args@PLT ... movq-88(%rbp), %rdx movq%r12, %rcx movq%r13, %rsi movq%rax, %rdi callGAP_CallFunc3Args@PLT and GAP_CallFunc3Args (_53, _47, __pyx_v_func_54(D), _49); ... _441 = GAP_CallFunc3Args (_98, _97, _96, _95);
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #32 from Christophe Lyon --- Created attachment 58110 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58110&action=edit patch v2 Here is another patch proposal along the lines of what you suggest in #c24
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #33 from Jakub Jelinek --- That is still a hack, but guess can be acceptable for 14.22 and short term trunk if the ARM maintainers approve it. But, for GCC 15+, I think if the behavior is that when the predicate constant/register is used in an instruction, regardless of the element mode it actually performs per-byte predication, then it should be represented as V16BImode, not V8BImode or V4BImode. It is fine if instructions which produce the predicate mask like comparisons produce V8BImode or V4BImode, but what consumes should use subreg of that to V16BImode. At least if the behavior is either perform the operation on all elements and then based on the 16 bits in the predicate choose result between the newly computed result and something else on byte by byte basis. Or perhaps if the operation is performed only on elements where at least one predicate bit for the element is non-zero and then merged. I think it would be useful if you pointed at the docs how the instructions exactly work or tried to explain it here.
[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 #16 from Jakub Jelinek --- (In reply to Sergei Trofimovich from comment #14) > I reproduced the `SIGSEGV` on Gentoo ~amd64 and ::sage-on-gentoo overlay > against sci-mathematics/sagemath-standard package. > > One of the unusual properties of > __pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__() is that > it raises 2 signals while it gets executed: > > - SIGABRT handler uses longjmp() to return to the ~beginning of a function > - and then SIGSEGV happens at cleanup when an attempt to dereference the > pointer happens. > > I see no `volatile` annotations anywhere in the > __pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__(). > > My wild guess would be that: > 1. `PyObject *__pyx_t_4 = ((void *)0);` gets saved in setjmp() with one > value (probably NULL) > 2. updated at some point later in the same function to non-NULL that `gcc` > can infer and throw away all later `NULL` checks > 3. then SIGABRT returns with longjmp() by accidentally resetting > > I would expect `__pyx_t_4` to require volatile annotation for such an > `element.i` definition. Or `longjmp()` should be called from a `((noipa))` > function to force register spill/reload on stack. > > To cite `man setjmp`: > > """ > CAVEATS >The compiler may optimize variables into registers, and > longjmp() may restore the values of other registers in addition to the stack > pointer and program counter. Consequently, the values of automatic >variables are unspecified after a call to longjmp() if they meet all > the following criteria: >• they are local to the function that made the corresponding > setjmp() call; >• their values are changed between the calls to setjmp() and > longjmp(); and >• they are not declared as volatile. >Analogous remarks apply for siglongjmp(). > """ > > Sounds plausible? So, if you can reproduce it, can you: 1) attach your *.s file and state which exact compiler you used (revision) 2) ideally show a gdb session with the important events, which setjmp was it (I see _setjmp and __sigsetjmp calls in the function), which exact function called from the function ended up aborting/doing longjmp in the signal handler and where is the crash 3) is it __pyx_t_6, __pyx_t_4 or some other pointer that triggers it (from the line numbers in #c0 my guess was __pyx_t_6, but you talk about __pyx_t_4) Yes, there are no volatile keywords on any of the vars, but without knowing which setjmp call it is and from where longjmp jumps to it, it is hard to know if the variables have been modified in between (then volatile would be required) or if they are only modified before the setjmp call or after the call that calls longjmp (then volatile might not be required).
[Bug target/114963] New: RISCV -msave-restore -fno-omit-frame-pointer does not emit save/restore library calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114963 Bug ID: 114963 Summary: RISCV -msave-restore -fno-omit-frame-pointer does not emit save/restore library calls Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: craig.topper at gmail dot com Target Milestone: --- It appears that combining -msave-restore and -fno-omit-frame-pointer results in no save/restore library calls being emitted. I also found this blog post that seems to imply it worked at some point, but broke unwinding. https://www.codethink.co.uk/articles/2023/riscv-stack-unwinding-bug/ I checked a few previous versions on compiler explorer and was not able to get the library calls.
[Bug target/98477] aarch64: Unnecessary GPR -> FPR moves for conditional select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98477 --- Comment #10 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650833.html
[Bug c++/114962] For each iteration in static assert fails to compile with pointer to member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114962
Marek Polacek changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #3 from Marek Polacek ---
// PR c++/114962
template struct __array_traits {
using _Type = _Tp[_Nm];
};
template struct array {
typedef _Tp value_type;
typedef value_type *const_iterator;
__array_traits<_Tp, _Nm>::_Type _M_elems;
constexpr const_iterator begin() const { return const_iterator(_M_elems); }
constexpr const_iterator end() const { return const_iterator(); }
constexpr value_type &operator[](long __n) { return _M_elems[__n]; }
};
struct A {
void third();
static constexpr array kArray = [] {
array a;
a[0] = a[1] = a[2] = &A::third;
return a;
}();
static_assert([] {
for (auto item : kArray)
if (item)
return true;
return false;
}(), "");
};
[Bug c/53548] allow flexible array members in unions like zero-length arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548 --- Comment #12 from GCC Commits --- The master branch has been updated by Qing Zhao : https://gcc.gnu.org/g:f27fc59d9f7c735d200fda647a487850144b10eb commit r15-209-gf27fc59d9f7c735d200fda647a487850144b10eb Author: Qing Zhao Date: Mon May 6 16:26:19 2024 + C and C++ FE changes to support flexible array members in unions and alone in structures. Adjust testcases for flexible array member in union and alone in structure extension. PR c/53548 gcc/c/ChangeLog: PR c/53548 * c-decl.cc (finish_struct): Change errors to pedwarns for the cases flexible array members in union or alone in structures. gcc/cp/ChangeLog: PR c/53548 * class.cc (diagnose_flexarrays): Change error to pdewarn for the case flexible array members alone in structures. * decl.cc (grokdeclarator): Change error to pdewarn for the case flexible array members in unions. gcc/ChangeLog: PR c/53548 * stor-layout.cc (place_union_field): Use zero sizes for flexible array member fields. gcc/testsuite/ChangeLog: PR c/53548 * c-c++-common/builtin-clear-padding-3.c: Adjust testcase. * g++.dg/ext/flexary12.C: Likewise. * g++.dg/ext/flexary19.C: Likewise. * g++.dg/ext/flexary2.C: Likewise. * g++.dg/ext/flexary3.C: Likewise. * g++.dg/ext/flexary36.C: Likewise. * g++.dg/ext/flexary4.C: Likewise. * g++.dg/ext/flexary5.C: Likewise. * g++.dg/ext/flexary8.C: Likewise. * g++.dg/torture/pr64280.C: Likewise. * gcc.dg/20050620-1.c: Likewise. * gcc.dg/940510-1.c: Likewise.
[Bug c/53548] allow flexible array members in unions like zero-length arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548
--- Comment #11 from GCC Commits ---
The master branch has been updated by Qing Zhao :
https://gcc.gnu.org/g:adb1c8a0f167c3a1f7593d75f5a10eb07a5d741a
commit r15-208-gadb1c8a0f167c3a1f7593d75f5a10eb07a5d741a
Author: Qing Zhao
Date: Mon May 6 16:25:04 2024 +
Allow flexible array members in unions and alone in structures [PR53548]
The request for GCC to accept that the C99 flexible array member can be
in a union or alone in a structure has been made a long time ago around
2012
for supporting several practical cases including glibc.
A GCC PR has been opened for such request at that time:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548
However, this PR was closed as WONTFIX around 2015 due to the following
reason:
"there is an existing extension that makes the requested functionality
possible"
i.e GCC fully supported that the zero-length array can be in a union or
alone
in a structure for a long time. (though I didn't see any official
documentation
on such extension)
It's reasonable to close PR53548 at that time since zero-length array
extension
can be used for such purpose.
However, since GCC13, in order to improve the C/C++ security, we introduced
-fstrict-flex-arrays=n to gradually eliminate the "fake flexible array"
usages from C/C++ source code. As a result, zero-length arrays eventually
will be replaced by C99 flexiable array member completely.
Therefore, GCC needs to explicitly allow such extensions directly for C99
flexible arrays, since flexable array member in unions or alone in structs
are common code patterns in active use by the Linux kernel (and other
projects).
For example, these do not error by default with GCC:
union one {
int a;
int b[0];
};
union two {
int a;
struct {
struct { } __empty;
int b[];
};
};
But these do:
union three {
int a;
int b[];
};
struct four {
int b[];
}
Clang has supported such extensions since March, 2024
https://github.com/llvm/llvm-project/pull/84428
GCC should also support such extensions. This will allow for
a seamless transition for code bases away from zero-length arrays without
losing existing code patterns.
gcc/ChangeLog:
PR c/53548
* doc/extend.texi: Add documentation for Flexible Array Members in
Unions and Flexible Array Members alone in Structures.
[Bug c/53548] allow flexible array members in unions like zero-length arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548 --- Comment #14 from GCC Commits --- The master branch has been updated by Qing Zhao : https://gcc.gnu.org/g:6634a409124a884ff66b3756568a7daae7d3c295 commit r15-211-g6634a409124a884ff66b3756568a7daae7d3c295 Author: Qing Zhao Date: Mon May 6 16:28:01 2024 + Update the C FE routine "add_flexible_array_elts_to_size" C++ FE routine "layout_var_decl" to handle the cases when the DECL is union. PR c/53548 Add testing cases to test the _bos for flexible array members in unions or alone in structures. gcc/c/ChangeLog: PR c/53548 * c-decl.cc (add_flexible_array_elts_to_size): Handle the cases when the DECL is union. gcc/cp/ChangeLog: PR c/53548 * decl.cc (layout_var_decl): Handle the cases when the DECL is union with a flexible array member initializer. gcc/testsuite/ChangeLog: PR c/53548 * c-c++-common/fam-in-union-alone-in-struct-bos-1.c: New test. * c-c++-common/fam-in-union-alone-in-struct-bos.c: New test.
[Bug c/53548] allow flexible array members in unions like zero-length arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548 --- Comment #13 from GCC Commits --- The master branch has been updated by Qing Zhao : https://gcc.gnu.org/g:93f6a47583f3fa8a1b66856ecb19ec28f26b2ba4 commit r15-210-g93f6a47583f3fa8a1b66856ecb19ec28f26b2ba4 Author: Qing Zhao Date: Mon May 6 16:27:09 2024 + Add testing cases for flexible array members in unions and alone in structures. PR c/53548 gcc/testsuite/ChangeLog: PR c/53548 * c-c++-common/fam-in-union-alone-in-struct-1.c: New testcase. * c-c++-common/fam-in-union-alone-in-struct-2.c: New testcase. * c-c++-common/fam-in-union-alone-in-struct-3.c: New testcase.
[Bug c/53548] allow flexible array members in unions like zero-length arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548 qinzhao at gcc dot gnu.org changed: What|Removed |Added Version|unknown |15.0 Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #15 from qinzhao at gcc dot gnu.org --- Fixed in GCC15
[Bug c++/114962] For each iteration in static assert fails to compile with pointer to member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114962
--- Comment #4 from Andrew Pinski ---
(In reply to Marek Polacek from comment #3)
> // PR c++/114962
Reduced much further and even removing the for loop and the array:
```
struct A {
void third();
using Handler = void (A::*)();
static constexpr Handler kArray = &A::third;
static_assert([] {
return (kArray)!=nullptr;
}(), "");
};
```
Which does point to a Pointer to member function issue.
[Bug c++/114962] For each iteration in static assert fails to compile with pointer to member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114962 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=114031 --- Comment #5 from Andrew Pinski --- Which points to a very similar issue of PR 114031.
[Bug c++/103338] [11/12/13/14/15 Regression] ICE: in tsubst_pack_expansion with invalid template friend and packed expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103338 Simon Martin changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Simon Martin --- The testcase ICEs with 13.2 (https://godbolt.org/z/vv54q97b3) but not trunk (https://godbolt.org/z/f7sK8nTqn). Will check if we need to add a new test case of it's already covered.
[Bug c++/105229] [11/12/13/14/15 Regression] ICE in lookup_template_class_1, at cp/pt.cc:10111
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105229 --- Comment #6 from Simon Martin --- The testcase ICEs with 11.3 (https://godbolt.org/z/qoYqK8zj9) but not 11.4 (https://godbolt.org/z/K8q6qYPba) Will check if we need to add a new test case of it's already covered.
[Bug testsuite/114177] gcc.target/aarch64/sve/loop_add_6.c needs to be fixed for LLP64 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114177 --- Comment #2 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:53026cbf08889d00fed34d8667796d22ef8554cf commit r15-212-g53026cbf08889d00fed34d8667796d22ef8554cf Author: Andrew Pinski Date: Mon May 6 12:20:17 2024 -0700 aarch64: Fix gcc.target/aarch64/sve/loop_add_6.c for LLP64 targets Even though the aarch64-mingw32 support has not been committed yet, we should fix some of the testcases. In this case gcc.target/aarch64/sve/loop_add_6.c is easy to fix. We should use __SIZETYPE__ instead of `unsigned long` for the variables that will be used for pointer plus. Committed as obvious after a quick test on aarch64-linux-gnu. gcc/testsuite/ChangeLog: PR testsuite/114177 * gcc.target/aarch64/sve/loop_add_6.c: Use __SIZETYPE__ instead of `unsigned long` for index and offset variables. Signed-off-by: Andrew Pinski
[Bug testsuite/114177] gcc.target/aarch64/sve/loop_add_6.c needs to be fixed for LLP64 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114177 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fixed.
[Bug target/111501] RISC-V: non-optimal casting when shifting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111501 Christoph Müllner changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |cmuellner at gcc dot gnu.org CC||cmuellner at gcc dot gnu.org --- Comment #3 from Christoph Müllner --- I noticed this a while ago as well (when working on the XTheadB* stuff). This can be addressed with an insn_and_split for zero_extract. I even wrote a patch for that back then, but forgot to send it out. I've rebased/retested it now and will send it once the release is out. Btw, LLVM is catching all of these cases.
[Bug target/111501] RISC-V: non-optimal casting when shifting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111501 --- Comment #4 from Vineet Gupta --- Awesome ! The trunk is open and new stuff, RISC-V certainly, is already landing, so no harm in sending it now ;-)
[Bug target/112868] GCC passes -many to the assembler for --enable-checking=release builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112868 --- Comment #14 from Peter Bergner --- (In reply to Niels Möller from comment #13) > I'm not that familiar with gcc development procedures. Do I understand you > correctly, that a fix for this bug will not be included in gcc-14 (according > to https://gcc.gnu.org/develop.html#timeline, gcc-14 stage1 ended several > months ago), it will have to wait for gcc-15? Correct, I meant waiting for GCC 15 stage1. I want it to burn-in on trunk for a long while, because it had the potential to disrupt distro package builds. It seems clean so far with the practice Gentoo builds, but I'll feel more comfortable when other distros start using it too. That said, Jeevitha, now that we're in stage1, can you please post your patch?
[Bug ada/114964] New: Ada Address_To_Access_Conversions gnat_to_gnu_entity internal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114964 Bug ID: 114964 Summary: Ada Address_To_Access_Conversions gnat_to_gnu_entity internal error Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: ken at pegasoft dot ca CC: dkm at gcc dot gnu.org Target Milestone: --- Sharing a report from SparForte programming language users. I've been unable to duplicate as I'm on GCC 10. The parser_pen.adb package has been unchanged for many years. First reported failing in GCC 13.2.0 in August 2023, but still being reported. Recently seen also in Raspberry Pi Bookworm and Red Hat Fedora. OpenGL statements in the form of: param_ptr := GL_Double_Array_Conv.To_Address( theArray.gl_da ); where package GL_Double_Array_Conv is new system.address_to_access_conversions( double_array ); and type double_array is array( size_t range <> ) of aliased GLdouble; where GLdouble is an Interfaces.C.double and param_ptr : GL_Double_Array_Ptr; which is a renaming of System.Address. Such lines are failing with +===GNAT BUG DETECTED==+ | 13.2.0 (x86_64-raven-freebsd13) GCC error: | | in gnat_to_gnu_entity, at ada/gcc-interface/decl.cc:475 | | Error detected at parser_pen.adb:4017:61 | | Compiling parser_pen.adb | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ SparForte is built with gnatmake -j2 -c -i -O1 -march=athlon64 -we -gnat12 -gnatfaoN -gnatVaep -gnateEeEeF -fstack-protector -c $(INCLUDE) spar Users have been unable to workaround except to delete the offending lines. SparForte is located at https://github.com/kburtch/SparForte I will provide more information as it becomes available to me. If this has been resolved, please advise on a workaround, if one exists, for the users. This is my first bug report. Please excuse any mistakes in etiquette. Thank you. Ken B.
[Bug middle-end/97263] For -ffinite-math-only -OFast is not mentioned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97263 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-May/650 ||841.html --- Comment #3 from Andrew Pinski --- I noticed a few other options have a similar wording that was incorrect since -Ofast was added so I fixed them too. Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650841.html
[Bug middle-end/85559] [meta-bug] Improve conditional move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85559 Bug 85559 depends on bug 78947, which changed state. Bug 78947 Summary: sub-optimal code for (bool)(int ? int : int) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78947 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
