[Bug libstdc++/109261] std::experimental::simd is not usable in several constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261 --- Comment #14 from CVS Commits --- The releases/gcc-13 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:0f9f9c0f79a1a2a1cd6abd86b84dedbd0d263a42 commit r13-7372-g0f9f9c0f79a1a2a1cd6abd86b84dedbd0d263a42 Author: Matthias Kretz Date: Wed May 24 12:50:46 2023 +0200 libstdc++: Fix SFINAE for __is_intrinsic_type on ARM On ARM NEON doesn't support double, so __is_intrinsic_type_v should say false (instead of being ill-formed). Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/109261 * include/experimental/bits/simd.h (__intrinsic_type): Specialize __intrinsic_type and __intrinsic_type in any case, but provide the member type only with __aarch64__. (cherry picked from commit aa8b363171a95b8f867a74f29c75f9577e9087e1)
[Bug libstdc++/109261] std::experimental::simd is not usable in several constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261 --- Comment #15 from CVS Commits --- The releases/gcc-13 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:a51ed14784df49eeceea1813b1d458516031bf52 commit r13-7373-ga51ed14784df49eeceea1813b1d458516031bf52 Author: Matthias Kretz Date: Tue May 23 23:48:49 2023 +0200 libstdc++: Add missing constexpr to simd_neon Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/109261 * include/experimental/bits/simd_neon.h (_S_reduce): Add constexpr and make NEON implementation conditional on not __builtin_is_constant_evaluated. (cherry picked from commit b0a483b0a011f9cbc8b25053eae809c77dae2a12)
[Bug libstdc++/109261] std::experimental::simd is not usable in several constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261 --- Comment #16 from CVS Commits --- The releases/gcc-13 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:dad9abd7daa1d977e79af7ac76c17c91464aca08 commit r13-7375-gdad9abd7daa1d977e79af7ac76c17c91464aca08 Author: Matthias Kretz Date: Thu Mar 23 09:32:58 2023 +0100 libstdc++: Add missing constexpr to simd The constexpr API is only available with -std=gnu++XX (and proposed for C++26). The proposal is to have the complete simd API usable in constant expressions. This patch resolves several issues with using simd in constant expressions. Issues why constant_evaluated branches are necessary: * subscripting vector builtins is not allowed in constant expressions * if the implementation needs/uses memcpy * if the implementation would otherwise call SIMD intrinsics/builtins Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/109261 * include/experimental/bits/simd.h (_SimdWrapper::_M_set): Avoid vector builtin subscripting in constant expressions. (resizing_simd_cast): Avoid memcpy if constant_evaluated. (const_where_expression, where_expression, where) (__extract_part, simd_mask, _SimdIntOperators, simd): Add either _GLIBCXX_SIMD_CONSTEXPR (on public APIs), or constexpr (on internal APIs). * include/experimental/bits/simd_builtin.h (__vector_permute) (__vector_shuffle, __extract_part, _GnuTraits::_SimdCastType1) (_GnuTraits::_SimdCastType2, _SimdImplBuiltin) (_MaskImplBuiltin::_S_store): Add constexpr. (_CommonImplBuiltin::_S_store_bool_array) (_SimdImplBuiltin::_S_load, _SimdImplBuiltin::_S_store) (_SimdImplBuiltin::_S_reduce, _MaskImplBuiltin::_S_load): Add constant_evaluated case. * include/experimental/bits/simd_fixed_size.h (_S_masked_load): Reword comment. (__tuple_element_meta, __make_meta, _SimdTuple::_M_apply_r) (_SimdTuple::_M_subscript_read, _SimdTuple::_M_subscript_write) (__make_simd_tuple, __optimize_simd_tuple, __extract_part) (__autocvt_to_simd, _Fixed::__traits::_SimdBase) (_Fixed::__traits::_SimdCastType, _SimdImplFixedSize): Add constexpr. (_SimdTuple::operator[], _M_set): Add constexpr and add constant_evaluated case. (_MaskImplFixedSize::_S_load): Add constant_evaluated case. * include/experimental/bits/simd_scalar.h: Add constexpr. * include/experimental/bits/simd_x86.h (_CommonImplX86): Add constexpr and add constant_evaluated case. (_SimdImplX86::_S_equal_to, _S_not_equal_to, _S_less) (_S_less_equal): Value-initialize to satisfy constexpr evaluation. (_MaskImplX86::_S_load): Add constant_evaluated case. (_MaskImplX86::_S_store): Add constexpr and constant_evaluated case. Value-initialize local variables. (_MaskImplX86::_S_logical_and, _S_logical_or, _S_bit_not) (_S_bit_and, _S_bit_or, _S_bit_xor): Add constant_evaluated case. * testsuite/experimental/simd/pr109261_constexpr_simd.cc: New test. (cherry picked from commit da579188807ede4ee9466d0b5bf51559c96a0b51)
[Bug libstdc++/109949] new test case experimental/simd/pr109261_constexpr_simd.cc in r12-9647-g3acbaf1b253215 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949 --- Comment #11 from CVS Commits --- The releases/gcc-13 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:0ed75609477ce9e83f8ebc32a7fa0f86380ad22f commit r13-7374-g0ed75609477ce9e83f8ebc32a7fa0f86380ad22f Author: Matthias Kretz Date: Wed May 24 16:43:07 2023 +0200 libstdc++: Fix type of first argument to vec_cntm call Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/109949 * include/experimental/bits/simd.h (__intrinsic_type): If __ALTIVEC__ is defined, map gnu::vector_size types to their corresponding __vector T types without losing unsignedness of integer types. Also prefer long long over long. * include/experimental/bits/simd_ppc.h (_S_popcount): Cast mask object to the expected unsigned vector type. (cherry picked from commit efd2b55d8562c6e80cb7ee8b9b1f9418f0c00cd9)
[Bug libstdc++/108030] `std::experimental::simd` not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030 --- Comment #19 from CVS Commits --- The releases/gcc-11 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:2da5976cf683d84a1857bfa34c5c3d0d661fffbd commit r11-10811-g2da5976cf683d84a1857bfa34c5c3d0d661fffbd Author: Matthias Kretz Date: Sat Jan 14 17:07:59 2023 +0100 libstdc++: Annotate most lambdas with always_inline All of the annotated lambdas are simply a necessary means for implementing these functions and should never result in an actual function call. Many of these lambdas would go away if C++ had better language support for packs. Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/108030 * include/experimental/bits/simd_detail.h: Define _GLIBCXX_SIMD_ALWAYS_INLINE_LAMBDA. * include/experimental/bits/simd.h: Annotate lambdas with _GLIBCXX_SIMD_ALWAYS_INLINE_LAMBDA. * include/experimental/bits/simd_builtin.h: Ditto. * include/experimental/bits/simd_converter.h: Ditto. * include/experimental/bits/simd_fixed_size.h: Ditto. * include/experimental/bits/simd_math.h: Ditto. * include/experimental/bits/simd_neon.h: Ditto. * include/experimental/bits/simd_x86.h: Ditto. (cherry picked from commit 53b55701aed6896f456cdec7997ac6bbef1d6074)
[Bug libstdc++/108030] `std::experimental::simd` not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030 --- Comment #21 from CVS Commits --- The releases/gcc-11 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:0911926f37cf41313c26e1e9d89424d64af972c9 commit r11-10815-g0911926f37cf41313c26e1e9d89424d64af972c9 Author: Matthias Kretz Date: Mon Feb 20 17:49:37 2023 +0100 libstdc++: Always-inline most of non-cmath fixed_size implementation For simd, the inlining behavior should be similar to builtin types. (No operator on buitin types is ever translated into a function call.) Therefore, always_inline is the right choice (i.e. inline on -O0 as well). Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/108030 * include/experimental/bits/simd_fixed_size.h (_SimdImplFixedSize::_S_broadcast): Replace inline with _GLIBCXX_SIMD_INTRINSIC. (_SimdImplFixedSize::_S_generate): Likewise. (_SimdImplFixedSize::_S_load): Likewise. (_SimdImplFixedSize::_S_masked_load): Likewise. (_SimdImplFixedSize::_S_store): Likewise. (_SimdImplFixedSize::_S_masked_store): Likewise. (_SimdImplFixedSize::_S_min): Likewise. (_SimdImplFixedSize::_S_max): Likewise. (_SimdImplFixedSize::_S_complement): Likewise. (_SimdImplFixedSize::_S_unary_minus): Likewise. (_SimdImplFixedSize::_S_plus): Likewise. (_SimdImplFixedSize::_S_minus): Likewise. (_SimdImplFixedSize::_S_multiplies): Likewise. (_SimdImplFixedSize::_S_divides): Likewise. (_SimdImplFixedSize::_S_modulus): Likewise. (_SimdImplFixedSize::_S_bit_and): Likewise. (_SimdImplFixedSize::_S_bit_or): Likewise. (_SimdImplFixedSize::_S_bit_xor): Likewise. (_SimdImplFixedSize::_S_bit_shift_left): Likewise. (_SimdImplFixedSize::_S_bit_shift_right): Likewise. (_SimdImplFixedSize::_S_remquo): Add inline keyword (to be explicit about not always-inline, yet). (_SimdImplFixedSize::_S_isinf): Likewise. (_SimdImplFixedSize::_S_isfinite): Likewise. (_SimdImplFixedSize::_S_isnan): Likewise. (_SimdImplFixedSize::_S_isnormal): Likewise. (_SimdImplFixedSize::_S_signbit): Likewise. (cherry picked from commit e37b04328ae68f91efe1fb2c5de9122be34bc74a)
[Bug libstdc++/108030] `std::experimental::simd` not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030 --- Comment #20 from CVS Commits --- The releases/gcc-11 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:a2a953d11e80ac4b351bbaa4a8fa4e6b76de317c commit r11-10812-ga2a953d11e80ac4b351bbaa4a8fa4e6b76de317c Author: Matthias Kretz Date: Mon Feb 20 11:13:44 2023 +0100 libstdc++: Fix simd build failure on clang Clang does not support __attribute__ on lambdas. Therefore, only set _GLIBCXX_SIMD_ALWAYS_INLINE_LAMBDA if __clang__ is not defined. Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/108030 * include/experimental/bits/simd_detail.h (_GLIBCXX_SIMD_ALWAYS_INLINE_LAMBDA): Define as empty for __clang__. (cherry picked from commit 92c47b15d5af3e7f93d11ad69a45b6d1cb8661c5)
[Bug libstdc++/108856] Increment and decrement on std::experimental::where_expression should optimize better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108856 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:740824717405a30d9ee01c65aac8839926d2 commit r11-10814-g740824717405a30d9ee01c65aac8839926d2 Author: Matthias Kretz Date: Mon Feb 20 16:33:31 2023 +0100 libstdc++: More efficient masked inc-/decrement implementation Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/108856 * include/experimental/bits/simd_builtin.h (_SimdImplBuiltin::_S_masked_unary): More efficient implementation of masked inc-/decrement for integers and floats without AVX2. * include/experimental/bits/simd_x86.h (_SimdImplX86::_S_masked_unary): New. Use AVX512 masked subtract builtins for masked inc-/decrement. (cherry picked from commit 6ce55180d494b616e2e3e68ffedfe9007e42ca06)
[Bug libstdc++/109261] std::experimental::simd is not usable in several constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261 --- Comment #18 from CVS Commits --- The releases/gcc-11 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:ad27280442d7979cf9da03d59268919fecfd12f4 commit r11-10822-gad27280442d7979cf9da03d59268919fecfd12f4 Author: Matthias Kretz Date: Wed May 24 12:50:46 2023 +0200 libstdc++: Fix SFINAE for __is_intrinsic_type on ARM On ARM NEON doesn't support double, so __is_intrinsic_type_v should say false (instead of being ill-formed). Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/109261 * include/experimental/bits/simd.h (__intrinsic_type): Specialize __intrinsic_type and __intrinsic_type in any case, but provide the member type only with __aarch64__. (cherry picked from commit aa8b363171a95b8f867a74f29c75f9577e9087e1)
[Bug libstdc++/109261] std::experimental::simd is not usable in several constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261 --- Comment #17 from CVS Commits --- The releases/gcc-11 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:f2299a4b2769941cd995e3a0530ff243153fcea2 commit r11-10821-gf2299a4b2769941cd995e3a0530ff243153fcea2 Author: Matthias Kretz Date: Tue May 23 23:48:49 2023 +0200 libstdc++: Add missing constexpr to simd_neon Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/109261 * include/experimental/bits/simd_neon.h (_S_reduce): Add constexpr and make NEON implementation conditional on not __builtin_is_constant_evaluated. (cherry picked from commit b0a483b0a011f9cbc8b25053eae809c77dae2a12)
[Bug libstdc++/109949] new test case experimental/simd/pr109261_constexpr_simd.cc in r12-9647-g3acbaf1b253215 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949 --- Comment #12 from CVS Commits --- The releases/gcc-11 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:0860e7d46f7fa4e1bcd373feee3bc673d4260b8b commit r11-10823-g0860e7d46f7fa4e1bcd373feee3bc673d4260b8b Author: Matthias Kretz Date: Wed May 24 16:43:07 2023 +0200 libstdc++: Fix type of first argument to vec_cntm call Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/109949 * include/experimental/bits/simd.h (__intrinsic_type): If __ALTIVEC__ is defined, map gnu::vector_size types to their corresponding __vector T types without losing unsignedness of integer types. Also prefer long long over long. * include/experimental/bits/simd_ppc.h (_S_popcount): Cast mask object to the expected unsigned vector type. (cherry picked from commit efd2b55d8562c6e80cb7ee8b9b1f9418f0c00cd9)
[Bug libstdc++/109261] std::experimental::simd is not usable in several constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261 --- Comment #19 from CVS Commits --- The releases/gcc-11 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:7e289c12ce0da962ef258c992f7c52710198e3a6 commit r11-10824-g7e289c12ce0da962ef258c992f7c52710198e3a6 Author: Matthias Kretz Date: Thu Mar 23 09:32:58 2023 +0100 libstdc++: Add missing constexpr to simd The constexpr API is only available with -std=gnu++XX (and proposed for C++26). The proposal is to have the complete simd API usable in constant expressions. This patch resolves several issues with using simd in constant expressions. Issues why constant_evaluated branches are necessary: * subscripting vector builtins is not allowed in constant expressions * if the implementation needs/uses memcpy * if the implementation would otherwise call SIMD intrinsics/builtins Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/109261 * include/experimental/bits/simd.h (_SimdWrapper::_M_set): Avoid vector builtin subscripting in constant expressions. (resizing_simd_cast): Avoid memcpy if constant_evaluated. (const_where_expression, where_expression, where) (__extract_part, simd_mask, _SimdIntOperators, simd): Add either _GLIBCXX_SIMD_CONSTEXPR (on public APIs), or constexpr (on internal APIs). * include/experimental/bits/simd_builtin.h (__vector_permute) (__vector_shuffle, __extract_part, _GnuTraits::_SimdCastType1) (_GnuTraits::_SimdCastType2, _SimdImplBuiltin) (_MaskImplBuiltin::_S_store): Add constexpr. (_CommonImplBuiltin::_S_store_bool_array) (_SimdImplBuiltin::_S_load, _SimdImplBuiltin::_S_store) (_SimdImplBuiltin::_S_reduce, _MaskImplBuiltin::_S_load): Add constant_evaluated case. * include/experimental/bits/simd_fixed_size.h (_S_masked_load): Reword comment. (__tuple_element_meta, __make_meta, _SimdTuple::_M_apply_r) (_SimdTuple::_M_subscript_read, _SimdTuple::_M_subscript_write) (__make_simd_tuple, __optimize_simd_tuple, __extract_part) (__autocvt_to_simd, _Fixed::__traits::_SimdBase) (_Fixed::__traits::_SimdCastType, _SimdImplFixedSize): Add constexpr. (_SimdTuple::operator[], _M_set): Add constexpr and add constant_evaluated case. (_MaskImplFixedSize::_S_load): Add constant_evaluated case. * include/experimental/bits/simd_scalar.h: Add constexpr. * include/experimental/bits/simd_x86.h (_CommonImplX86): Add constexpr and add constant_evaluated case. (_SimdImplX86::_S_equal_to, _S_not_equal_to, _S_less) (_S_less_equal): Value-initialize to satisfy constexpr evaluation. (_MaskImplX86::_S_load): Add constant_evaluated case. (_MaskImplX86::_S_store): Add constexpr and constant_evaluated case. Value-initialize local variables. (_MaskImplX86::_S_logical_and, _S_logical_or, _S_bit_not) (_S_bit_and, _S_bit_or, _S_bit_xor): Add constant_evaluated case. * testsuite/experimental/simd/pr109261_constexpr_simd.cc: New test. (cherry picked from commit da579188807ede4ee9466d0b5bf51559c96a0b51)
[Bug libstdc++/109949] new test case experimental/simd/pr109261_constexpr_simd.cc in r12-9647-g3acbaf1b253215 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949 Matthias Kretz (Vir) changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Matthias Kretz (Vir) --- Resolved on trunk and gcc-12 (for the other backports I reordered the commits so that the test should never fail on bisect)
[Bug libstdc++/109261] std::experimental::simd is not usable in several constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261 Matthias Kretz (Vir) changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #20 from Matthias Kretz (Vir) --- Resolved on all branches.
[Bug libstdc++/108856] Increment and decrement on std::experimental::where_expression should optimize better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108856 Matthias Kretz (Vir) changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Matthias Kretz (Vir) --- Resolved on all branches.
[Bug libstdc++/108030] `std::experimental::simd` not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030 Matthias Kretz (Vir) changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #22 from Matthias Kretz (Vir) --- Resolved on all branches.
[Bug c/109962] New: gcc/gimple-range-cache.h:140:17: warning: private field 'm_estimate' is not used [-Wunused-private-field]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109962 Bug ID: 109962 Summary: gcc/gimple-range-cache.h:140:17: warning: private field 'm_estimate' is not used [-Wunused-private-field] Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- I just did a build of trunk gcc with clang and got the above warning. This seems to confirm it: $ grep m_estimate *.h *.cc gimple-range-cache.h: phi_analyzer *m_estimate; $
[Bug c++/109963] New: ABI: unexpected layout ordering of `this` pointer in lambda capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109963 Bug ID: 109963 Summary: ABI: unexpected layout ordering of `this` pointer in lambda capture Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: joker.eph at gmail dot com Target Milestone: --- See the discussion here: https://github.com/itanium-cxx-abi/cxx-abi/issues/141 Most recent post at the moment was calling out a possible implementation bug in GCC: > If compilers aren't going to give lambdas internal linkage in these > situations, the ABI needs to define a layout for them. As far as I can tell, > Clang, GCC, and ICC are all trying to use the same layout rule: explicit > captures are added in declaration order, then implicit captures are added in > the source order of their ODR use in the lambda body. The exception which > causes this incompatibility is that GCC seems to order implicit this > arguments (and only implicit ones) after the formal call arguments. I would > argue that that's just a GCC bug, and the this argument should be ordered as > if it were written in source. @jicama, do you agree?
[Bug target/109927] Bootstrap fails for m68k in stage2 compilation of gimple-match.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927 --- Comment #19 from rguenther at suse dot de --- On Wed, 24 May 2023, userm57 at yahoo dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927 > > --- Comment #18 from Stan Johnson --- > $ git clone git://gcc.gnu.org/git/gcc.git > $ cd gcc > $ git checkout master > > I'm testing a manual bootstrap of "gcc version 14.0.0 20230524 (experimental) > (GCC)" now, accessed via git as shown above. > > It will still take about 24 more hours for the bootstrap to finish (I'll send > an update if it fails), but with gimple-match.cc (and generic-match.cc, which > was not affected in my tests) split up, it looks like it will finish ok (it's > currently in about the middle of stage 2 and has successfully compiled all the > gimple-match-n.cc files). > > Note that Gentoo's emerge of gcc-13 behaves a little differently than a manual > bootstrap. I don't know why, since I think I'm using Gentoo's ./configure > options in the manual bootstrap, but in Gentoo's emerge of gcc, they seem to > run cc1plus and "as" simultaneously for each compilation, perhaps aggravating > the memory issue for gimple-match.cc (or maybe not, since the problem is > virtual memory exhausted, not swap space exhausted). Possibly -pipe is used somehow. > Anyway, it looks like the solution was already close. Does anyone know whether > the change will be backported to gcc-12 or gcc-13 available from > ftp.gnu.org/pub/gnu/gcc? That wasn't planned. It's very unlikely to happen for gcc 12, it should be possible for gcc 13 I think.
[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |13.2
[Bug tree-optimization/109950] can array subscripts be assumed to be non-negative?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109950 Richard Biener changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Richard Biener --- a negative 'next' is fine, data[next] is just *(data + next) so we cannot elide the sign-extension either.
[Bug testsuite/109951] [14 Regression] libgomp, testsuite: non-native multilib c++ tests fail on Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109951 Richard Biener changed: What|Removed |Added Version|unknown |14.0 Target Milestone|--- |14.0
[Bug target/109927] Bootstrap fails for m68k in stage2 compilation of gimple-match.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927 --- Comment #20 from Sam James --- When I looked at it, I think I got it to apply to 13 with no hassle and it seemed to work okay, but I didn't test it that hard. It's a considerable win so even if not backported upstream, if you think it's safe enough, let us know if it's ok for us to do it downstream in Gentoo. (That could also serve as a form of testing to do it upstream on releases/gcc-13 if desired.)
[Bug target/109954] x86-64's -m32 does not conform to documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954 Richard Biener changed: What|Removed |Added Keywords||documentation --- Comment #9 from Richard Biener --- Documentation issue.
[Bug target/109927] Bootstrap fails for m68k in stage2 compilation of gimple-match.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927 --- Comment #21 from rguenther at suse dot de --- On Thu, 25 May 2023, sjames at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927 > > --- Comment #20 from Sam James --- > When I looked at it, I think I got it to apply to 13 with no hassle and it > seemed to work okay, but I didn't test it that hard. > > It's a considerable win so even if not backported upstream, if you think it's > safe enough, let us know if it's ok for us to do it downstream in Gentoo. > > (That could also serve as a form of testing to do it upstream on > releases/gcc-13 if desired.) yes, it's safe (unless there are not yet noticed portability issues with the Makefile setup)
[Bug c/109956] GCC reserves 9 bytes for struct s { int a; char b; char t[]; } x = {1, 2, 3};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #11 from Richard Biener ---
(In reply to Alexander Monakov from comment #8)
> (In reply to jos...@codesourcery.com from comment #6)
> > For the standard, dynamically allocated case, you should only need to
> > allocate enough memory to contain the initial part of the struct and the
> > array members being accessed - not any padding after that array. (There
> > were wording problems before C99 TC2; see DR#282.)
>
> I think the following testcase indicates that GCC assumes that tail padding
> is accessible:
>
> struct S {
> int i;
> char c;
> char fam[];
> };
>
> void f(struct S *p, struct S *q)
> {
> *p = *q;
> }
>
> f:
> movq(%rsi), %rax
> movq%rax, (%rdi)
> ret
>
> Sorry for the tangential remark, but there seems to be a contradiction.
Not only accessible but also not used by sth else. That is, a following
'char' variable may not be placed into the padding.
[Bug tree-optimization/109957] Missing loop PHI optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109957 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-05-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I think we have some code doing final value replacement of bit ops now, I suppose that could be enhanced to cover this. Yes, we handle &= ... but not |= ...
[Bug c++/109958] [10/11/12/13/14 Regression] ICE: in build_ptrmem_type, at cp/decl.cc:11066 taking the address of bound static member function brought into derived class by using-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109958 --- Comment #2 from Richard Biener --- so is that invalid code?
[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-05-25
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #5 from Richard Biener --- ifcombine was supposed to handle this but I guess we mess up before it
[Bug tree-optimization/109950] can array subscripts be assumed to be non-negative?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109950 --- Comment #4 from LIU Hao --- Given the fact that GCC is already able to warn about out-of-range indexes for an array, why wouldn't it be possible to infer that `*(data + next)` is always an element of `data`? If the result of `data + next` (after array-to-pointer conversion) does not point to an element of `data` (or the past-the-end position, but that's not the case, as it's not dereferenceable), then the behavior will be undefined.
[Bug libstdc++/109947] std::expected monadic operations do not support move-only error types yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947 --- Comment #6 from Jonathan Wakely --- (In reply to Martin Seemann from comment #5) > Thanks for the clarification! Now I am convinced that it is not a bug in > libstdc++ (although I still doubt that the side-effects were intended when > the committee formulated the "Effects" for monadic operations, but that's > not relevant here). LWG 3843 was resolved after the monadic ops had been specified, and it's possible that we should have altered the monadic ops to use operator*() instead of value(). I'll raise this with the committee.
[Bug target/109174] incorrect intrinsic signature for AVX-512 srai*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109174
--- Comment #2 from CVS Commits ---
The master branch has been updated by Haochen Jiang :
https://gcc.gnu.org/g:4a84a2db2ad7cc57c1674849f845c42ed4ad12ab
commit r14-1234-g4a84a2db2ad7cc57c1674849f845c42ed4ad12ab
Author: Hu, Lin1
Date: Tue May 23 10:08:29 2023 +0800
i386: Fix incorrect intrinsic signature for AVX512 s{lli|rai|rli}
This patch aims to fix incorrect intrinsic signature for
_mm{512|256|}_s{lli|rai|rli}_epi*.
gcc/ChangeLog:
PR target/109173
PR target/109174
* config/i386/avx512bwintrin.h (_mm512_srli_epi16): Change type
from
int to const int or const int to const unsigned int.
(_mm512_mask_srli_epi16): Ditto.
(_mm512_slli_epi16): Ditto.
(_mm512_mask_slli_epi16): Ditto.
(_mm512_maskz_slli_epi16): Ditto.
(_mm512_srai_epi16): Ditto.
(_mm512_mask_srai_epi16): Ditto.
(_mm512_maskz_srai_epi16): Ditto.
* config/i386/avx512fintrin.h (_mm512_slli_epi64): Ditto.
(_mm512_mask_slli_epi64): Ditto.
(_mm512_maskz_slli_epi64): Ditto.
(_mm512_srli_epi64): Ditto.
(_mm512_mask_srli_epi64): Ditto.
(_mm512_maskz_srli_epi64): Ditto.
(_mm512_srai_epi64): Ditto.
(_mm512_mask_srai_epi64): Ditto.
(_mm512_maskz_srai_epi64): Ditto.
(_mm512_slli_epi32): Ditto.
(_mm512_mask_slli_epi32): Ditto.
(_mm512_maskz_slli_epi32): Ditto.
(_mm512_srli_epi32): Ditto.
(_mm512_mask_srli_epi32): Ditto.
(_mm512_maskz_srli_epi32): Ditto.
(_mm512_srai_epi32): Ditto.
(_mm512_mask_srai_epi32): Ditto.
(_mm512_maskz_srai_epi32): Ditto.
* config/i386/avx512vlbwintrin.h (_mm256_mask_srai_epi16): Ditto.
(_mm256_maskz_srai_epi16): Ditto.
(_mm_mask_srai_epi16): Ditto.
(_mm_maskz_srai_epi16): Ditto.
(_mm256_mask_slli_epi16): Ditto.
(_mm256_maskz_slli_epi16): Ditto.
(_mm_mask_slli_epi16): Ditto.
(_mm_maskz_slli_epi16): Ditto.
(_mm_maskz_srli_epi16): Ditto.
* config/i386/avx512vlintrin.h (_mm256_mask_srli_epi32): Ditto.
(_mm256_maskz_srli_epi32): Ditto.
(_mm_mask_srli_epi32): Ditto.
(_mm_maskz_srli_epi32): Ditto.
(_mm256_mask_srli_epi64): Ditto.
(_mm256_maskz_srli_epi64): Ditto.
(_mm_mask_srli_epi64): Ditto.
(_mm_maskz_srli_epi64): Ditto.
(_mm256_mask_srai_epi32): Ditto.
(_mm256_maskz_srai_epi32): Ditto.
(_mm_mask_srai_epi32): Ditto.
(_mm_maskz_srai_epi32): Ditto.
(_mm256_srai_epi64): Ditto.
(_mm256_mask_srai_epi64): Ditto.
(_mm256_maskz_srai_epi64): Ditto.
(_mm_srai_epi64): Ditto.
(_mm_mask_srai_epi64): Ditto.
(_mm_maskz_srai_epi64): Ditto.
(_mm_mask_slli_epi32): Ditto.
(_mm_maskz_slli_epi32): Ditto.
(_mm_mask_slli_epi64): Ditto.
(_mm_maskz_slli_epi64): Ditto.
(_mm256_mask_slli_epi32): Ditto.
(_mm256_maskz_slli_epi32): Ditto.
(_mm256_mask_slli_epi64): Ditto.
(_mm256_maskz_slli_epi64): Ditto.
gcc/testsuite/ChangeLog:
PR target/109173
PR target/109174
* gcc.target/i386/pr109173-1.c: New test.
* gcc.target/i386/pr109174-1.c: Ditto.
[Bug target/109173] incorrect intrinsic signature for _mm_srai_epi64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109173
--- Comment #7 from CVS Commits ---
The master branch has been updated by Haochen Jiang :
https://gcc.gnu.org/g:4a84a2db2ad7cc57c1674849f845c42ed4ad12ab
commit r14-1234-g4a84a2db2ad7cc57c1674849f845c42ed4ad12ab
Author: Hu, Lin1
Date: Tue May 23 10:08:29 2023 +0800
i386: Fix incorrect intrinsic signature for AVX512 s{lli|rai|rli}
This patch aims to fix incorrect intrinsic signature for
_mm{512|256|}_s{lli|rai|rli}_epi*.
gcc/ChangeLog:
PR target/109173
PR target/109174
* config/i386/avx512bwintrin.h (_mm512_srli_epi16): Change type
from
int to const int or const int to const unsigned int.
(_mm512_mask_srli_epi16): Ditto.
(_mm512_slli_epi16): Ditto.
(_mm512_mask_slli_epi16): Ditto.
(_mm512_maskz_slli_epi16): Ditto.
(_mm512_srai_epi16): Ditto.
(_mm512_mask_srai_epi16): Ditto.
(_mm512_maskz_srai_epi16): Ditto.
* config/i386/avx512fintrin.h (_mm512_slli_epi64): Ditto.
(_mm512_mask_slli_epi64): Ditto.
(_mm512_maskz_slli_epi64): Ditto.
(_mm512_srli_epi64): Ditto.
(_mm512_mask_srli_epi64): Ditto.
(_mm512_maskz_srli_epi64): Ditto.
(_mm512_srai_epi64): Ditto.
(_mm512_mask_srai_epi64): Ditto.
(_mm512_maskz_srai_epi64): Ditto.
(_mm512_slli_epi32): Ditto.
(_mm512_mask_slli_epi32): Ditto.
(_mm512_maskz_slli_epi32): Ditto.
(_mm512_srli_epi32): Ditto.
(_mm512_mask_srli_epi32): Ditto.
(_mm512_maskz_srli_epi32): Ditto.
(_mm512_srai_epi32): Ditto.
(_mm512_mask_srai_epi32): Ditto.
(_mm512_maskz_srai_epi32): Ditto.
* config/i386/avx512vlbwintrin.h (_mm256_mask_srai_epi16): Ditto.
(_mm256_maskz_srai_epi16): Ditto.
(_mm_mask_srai_epi16): Ditto.
(_mm_maskz_srai_epi16): Ditto.
(_mm256_mask_slli_epi16): Ditto.
(_mm256_maskz_slli_epi16): Ditto.
(_mm_mask_slli_epi16): Ditto.
(_mm_maskz_slli_epi16): Ditto.
(_mm_maskz_srli_epi16): Ditto.
* config/i386/avx512vlintrin.h (_mm256_mask_srli_epi32): Ditto.
(_mm256_maskz_srli_epi32): Ditto.
(_mm_mask_srli_epi32): Ditto.
(_mm_maskz_srli_epi32): Ditto.
(_mm256_mask_srli_epi64): Ditto.
(_mm256_maskz_srli_epi64): Ditto.
(_mm_mask_srli_epi64): Ditto.
(_mm_maskz_srli_epi64): Ditto.
(_mm256_mask_srai_epi32): Ditto.
(_mm256_maskz_srai_epi32): Ditto.
(_mm_mask_srai_epi32): Ditto.
(_mm_maskz_srai_epi32): Ditto.
(_mm256_srai_epi64): Ditto.
(_mm256_mask_srai_epi64): Ditto.
(_mm256_maskz_srai_epi64): Ditto.
(_mm_srai_epi64): Ditto.
(_mm_mask_srai_epi64): Ditto.
(_mm_maskz_srai_epi64): Ditto.
(_mm_mask_slli_epi32): Ditto.
(_mm_maskz_slli_epi32): Ditto.
(_mm_mask_slli_epi64): Ditto.
(_mm_maskz_slli_epi64): Ditto.
(_mm256_mask_slli_epi32): Ditto.
(_mm256_maskz_slli_epi32): Ditto.
(_mm256_mask_slli_epi64): Ditto.
(_mm256_maskz_slli_epi64): Ditto.
gcc/testsuite/ChangeLog:
PR target/109173
PR target/109174
* gcc.target/i386/pr109173-1.c: New test.
* gcc.target/i386/pr109174-1.c: Ditto.
[Bug libstdc++/109921] c++17/floating_from_chars.cc: compile error: ‘from_chars_strtod’ was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109921
--- Comment #2 from Andreas Ziegler ---
Apart from a small typo
-+ if (rec.ec == errc{})
++ if (res.ec == errc{})
this fixes the build error.
[Bug target/100711] Miss optimization for pandn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711 --- Comment #10 from jbeulich at suse dot com --- (In reply to Hongtao.liu from comment #9) > We don't have single instruction for V8HI/V16QImode broadcast without AVX2, > that's why the first splitter only have VI48_128. Does this matter? The splitters are about subsuming the "not". How the "vec_duplicate" is carried out isn't really relevant here, is it?
[Bug c++/109963] ABI: unexpected layout ordering of `this` pointer in lambda capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109963 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-05-25 --- Comment #1 from Jonathan Wakely --- Repeating the quoted comment, without bugzilla's unhelpful horizontal scrollbar: If compilers aren't going to give lambdas internal linkage in these situations, the ABI needs to define a layout for them. As far as I can tell, Clang, GCC, and ICC are all trying to use the same layout rule: explicit captures are added in declaration order, then implicit captures are added in the source order of their ODR use in the lambda body. The exception which causes this incompatibility is that GCC seems to order implicit this arguments (and only implicit ones) after the formal call arguments. I would argue that that's just a GCC bug, and the this argument should be ordered as if it were written in source. @jicama, do you agree?
[Bug target/100711] Miss optimization for pandn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711 --- Comment #11 from Hongtao.liu --- (In reply to jbeulich from comment #10) > (In reply to Hongtao.liu from comment #9) > > We don't have single instruction for V8HI/V16QImode broadcast without AVX2, > > that's why the first splitter only have VI48_128. > > Does this matter? The splitters are about subsuming the "not". How the > "vec_duplicate" is carried out isn't really relevant here, is it? It's splitted to 2 patterns, but there's no V8HI/V16QImode define_insn for the first pattern w/o AVX2, there will be ICE of unrecognisable insn. 17110 [(set (match_dup 3) 17111(vec_duplicate:VI48_128 (match_dup 1))) 17112 (set (match_dup 0) 17113(and:VI48_128 (not:VI48_128 (match_dup 3)) 17114 (match_dup 2)))]
[Bug target/109173] incorrect intrinsic signature for _mm_srai_epi64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109173 --- Comment #8 from Hongtao.liu --- Fixed for GCC14.
[Bug target/109174] incorrect intrinsic signature for AVX-512 srai*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109174 --- Comment #3 from Hongtao.liu --- Fixed for GCC14.
[Bug libstdc++/109922] : consider removing operator>> for istream >> setfill(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109922 --- Comment #4 from Jonathan Wakely --- (In reply to Jiang An from comment #2) > The requirements was removed by N0958 > (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0958.pdf), and > then setfill and its friends are only required to be usable with operator<<. I don't think the 27-652 change from N0958 was applied to the draft, but 27-651 in https://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0964.pdf changed setfill.
[Bug target/109955] Should be possible to remove vcond{,u,eq} expanders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109955 --- Comment #3 from Richard Biener --- FAIL: gcc.dg/vect/pr109011-3.c -flto -ffat-lto-objects scan-tree-dump-times optimized " = .POPCOUNT (vect" 3 show that when pattern recognition detects t.c:5:21: note: vec_recog_ctz_ffs_pattern: detected: _6 = __builtin_ffs (_4); t.c:5:21: note: created pattern stmt: patt_7 = _4 != 0 ? patt_8 : 0; t.c:5:21: note: ctz_ffs pattern recognized: patt_7 = _4 != 0 ? patt_8 : 0; t.c:5:21: note: extra pattern stmt: patt_18 = -_4; t.c:5:21: note: extra pattern stmt: patt_15 = _4 | patt_18; t.c:5:21: note: extra pattern stmt: patt_14 = .POPCOUNT (patt_15); t.c:5:21: note: extra pattern stmt: patt_8 = 33 - patt_14; we fail: t.c:5:21: note: ==> examining pattern statement: patt_7 = _4 != 0 ? patt_8 : 0; t.c:5:21: note: vect_is_simple_use: operand *_3, type of def: internal t.c:5:21: note: vect_is_simple_use: vectype vector(16) int t.c:5:21: note: vect_is_simple_use: operand 33 - patt_14, type of def: internal t.c:5:21: note: vect_is_simple_use: vectype vector(16) int t.c:5:21: note: vect_is_simple_use: operand 0, type of def: constant t.c:2:1: missed: not vectorized: relevant stmt not supported: patt_7 = _4 != 0 ? patt_8 : 0; t.c:5:21: missed: bad operation or unsupported loop bound. note there's "unconverted" code in pattern recog that creates those "bad" GIMPLE COND_EXPRs with GENERIC compares. I've chickened out "fixing" those because exactly of a similar issue that we're not perfect in supporting vcond vs vcond_mask 1:1. Having only one of them would simplify things. I have a patch for that.
[Bug rtl-optimization/101188] [AVR] Miscompilation and function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188 --- Comment #7 from Georg-Johann Lay --- On branch releases/gcc-5.4.0, the wrong code is since r226119, which is a backport of r225918. Doesn't look like this caused the current PR; maybe that change just unmasked a bug in postreload that's even older.
[Bug libstdc++/109922] : consider removing operator>> for istream >> setfill(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109922 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |14.0 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > I don't think the 27-652 change from N0958 was applied to the draft, but It wasn't applied verbatim, because the proposed resolution only talked about basic_ostream. The final change applied to the draft was corrected to refer to both basic_ostream and basic_istream. > 27-651 in https://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0964.pdf > changed setfill. I wonder if this was just an editing conflict, and the change for 27-651 should actually have included basic_istream, as the change for 27-652 did. Either way, it's not in the standard now and has no useful purpose, so I think we should deprecate it for GCC 14 and remove it in a future release.
[Bug c/103960] Clang's -Wunknown-attributes is more useful than -Wattributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103960 Avi Kivity changed: What|Removed |Added CC||avi at scylladb dot com --- Comment #4 from Avi Kivity --- It would be nice to have -fignore-attribute-namespace=clang, so we can ignore [[clang::very_useful_attribute(blah)]] on gcc and [[gnu::another_good_thing(foo)]] on clang, instead of having to wrap everything with macros. (complicated a little by clang recognizing some attributes in the gnu namespace).
[Bug c/103960] Clang's -Wunknown-attributes is more useful than -Wattributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103960 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- -Wno-attributes=clang:: ?
[Bug c++/109958] [10/11/12/13/14 Regression] ICE: in build_ptrmem_type, at cp/decl.cc:11066 taking the address of bound static member function brought into derived class by using-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109958 --- Comment #3 from Ed Catmur --- B::f is a static member function so yes, it's valid. A class member access expression naming a static member function is an lvalue designating that function, and it shouldn't make any difference that the function was found via a using declaration.
[Bug target/109964] New: auto-vectorization of shift ignores integral promotions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109964 Bug ID: 109964 Summary: auto-vectorization of shift ignores integral promotions Product: gcc Version: 13.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: mkretz at gcc dot gnu.org Target Milestone: --- Target: powerpc64le-*-* Test cases: short: https://godbolt.org/z/oM56Pd19o char: https://godbolt.org/z/f5Tc6TMEd The POWER vector shifts read only 3/4 bits from the rhs vector. Thus, shifts that are valid on int (i.e. >= 8 or >= 16) are translated incorrectly when using the vector shift instructions. If the rhs values are not known to be bounded a fix-up is necessary.
[Bug c/103960] Clang's -Wunknown-attributes is more useful than -Wattributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103960 --- Comment #6 from Avi Kivity --- Ah! thanks.
[Bug target/109955] Should be possible to remove vcond{,u,eq} expanders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109955
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:f97572c2aeddc71b01686993b978895e55890ab6
commit r14-1238-gf97572c2aeddc71b01686993b978895e55890ab6
Author: Richard Biener
Date: Thu May 25 12:55:11 2023 +0200
target/109955 - handle pattern generated COND_EXPR without vcond
The following properly handles pattern matching generated COND_EXPRs
which can still have embedded compares in vectorizable_condition
which will always code generate the masked vector variant. We
were requiring vcond with embedded comparisons instead of also
allowing (as code generated) split compare and VEC_COND_EXPR.
This fixes some of the fallout when removing vcond{,u,eq} expanders
from the x86 backend.
PR target/109955
* tree-vect-stmts.cc (vectorizable_condition): For
embedded comparisons also handle the case when the target
only provides vec_cmp and vcond_mask.
[Bug target/109955] Should be possible to remove vcond{,u,eq} expanders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109955 --- Comment #5 from Richard Biener --- The remaining FAILs are all because of define_insn_and_split no longer working I think. I wonder if these combinations can be handled in generic code somehow.
[Bug libstdc++/109965] New: rename 'Modules' to 'Categories' in tree-view of doxygen-generated libstdc++ documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109965 Bug ID: 109965 Summary: rename 'Modules' to 'Categories' in tree-view of doxygen-generated libstdc++ documentation Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: saifi.khan at nishan dot io Target Milestone: --- Created attachment 55154 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55154&action=edit Tree view as seen by user of documentation and contents under 'Modules'. This relates to doxygen generated 'libstdc++ source documentation' The documentation uses the term 'Modules' on its first page https://softwarehub.sourceforge.io/libstdcxx/api/ and on the said 'Modules' page https://softwarehub.sourceforge.io/libstdcxx/api/modules.html The 'contents' under the 'Modules' tree view are Algorithms Atomics Concurrency Containers Diagnostics Extensions File System I/O Iterators Locales Numerics Random Number Generation Ranges Regular Expressions Strings Technical Specifications Utilities A review of the word 'Modules' here is warranted to avoid confusion with the use of an identical word 'modules' in the context of C++ modules. Perhaps the word 'Modules' may be renamed to 'Categories' as used in the context of an organizing principle.
[Bug target/109964] auto-vectorization of shift ignores integral promotions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109964
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-05-25
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC||rguenth at gcc dot gnu.org,
||rsandifo at gcc dot gnu.org
--- Comment #1 from Richard Biener ---
using V [[gnu::vector_size(16)]] = short;
V f(V s)
{
return V{
short(1) >> s[0],
short(1) >> s[1],
short(1) >> s[2],
short(1) >> s[3],
short(1) >> s[4],
short(1) >> s[5],
short(1) >> s[6],
short(1) >> s[7]
};
}
the frontend gives us
return = {(short int) (1 >> (int) VIEW_CONVERT_EXPR(s)[0]), (short int) (1 >> (int) VIEW_CONVERT_EXPR(s)[1]),
(short int) (1 >> (int) VIEW_CONVERT_EXPR(s)[2]), (short int) (1
>> (int) VIEW_CONVERT_EXPR(s)[3]), (short int) (1 >> (int)
VIEW_CONVERT_EXPR(s)[4]), (short int) (1 >> (int)
VIEW_CONVERT_EXPR(s)[5]), (short int) (1 >> (int)
VIEW_CONVERT_EXPR(s)[6]), (short int) (1 >> (int)
VIEW_CONVERT_EXPR(s)[7])};
and the promotion/demotion stays until eventually basic-block vectorization
vectorizes this without doing the promotion.
t.ii:14:5: note: vect_recog_over_widening_pattern: detected: _3 = 1 >> _2;
t.ii:14:5: note: demoting int to signed short
t.ii:14:5: note: created pattern stmt: patt_36 = 1 >> _1;
I don't think there's any way to query the target about whether vector
shifts "behave".
We end up with
V f (V s)
{
vector(8) signed short vect_patt_36.3;
[local count: 1073741824]:
vect_patt_36.3_62 = { 1, 1, 1, 1, 1, 1, 1, 1 } >> s_33(D);
return vect_patt_36.3_62;
[Bug target/109964] auto-vectorization of shift ignores integral promotions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109964 Richard Biener changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #2 from Richard Biener --- The simplest thing would be to make this a target bug for their vec_shr expander not fulfilling the (undocumented) semantics.
[Bug target/109964] auto-vectorization of shift ignores integral promotions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109964 --- Comment #3 from Richard Biener --- So the bug in the vectorizer is that it does t.ii:14:5: note: can narrow to signed:16 without loss of precision: _31 = 1 >> _30; t.ii:14:5: note: only the low 16 bits of _30 are significant while that's correct that's not the proper constraint to check for in vect_recog_over_widening_pattern I think. That has code to deal with overflow for plus/minus/mult but no defense against shifts (that's also not a vect_truncatable_operation_p, so maybe it should simply check that)
[Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791
--- Comment #14 from Richard Biener ---
So one issue with the unfolding of PHIs is that for example
gcc.dg/warn-sprintf-no-nul.c has
const char a2[][3] = {
"", "1", "12", "123", "123\000"
};
and for
# str_1 = PHI <&a2[2], &a2[3]>
we can determine bounds on the string length of str_1 by unioning the
string lengths of &a2[2] and &a2[3]. But with
# off_2 = PHI <6, 9>
str_1 = &a2 + off_2;
this isn't possible. In fact get_range_strlen doesn't handle POINTER_PLUS_EXPR
and while it might be possible to handle "foo" + off_2 with looking at the
range of off_2 for example the above case of refering to two different
strings rather than offsetting within one string isn't distinguishable.
I've also figured that when one PHI argument has zero offset (aka plain &a2)
then PRE tends to undo the transform since &a2 + 0 is readily available
on that edge and thus it inserts pointer adjustments on the other edges.
So while it looked like the easy way out on the ranger limitation it's
not a viable solution (because it regresses testcases).
[Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791 Richard Biener changed: What|Removed |Added Attachment #55047|0 |1 is obsolete|| --- Comment #15 from Richard Biener --- Created attachment 55155 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55155&action=edit patch unfolding such PHIs Updated PHI unfolding patch. Tests fine besides mentioned diagnostic regressions.
[Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791 Richard Biener changed: What|Removed |Added Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug c++/109966] New: [13.1 Regression] ICE in implify_var_or_parm_decl, à gimplify.cc:3058
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109966 Bug ID: 109966 Summary: [13.1 Regression] ICE in implify_var_or_parm_decl, à gimplify.cc:3058 Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: averne381 at gmail dot com Target Milestone: --- Created attachment 55156 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55156&action=edit Preprocessed reproduction The attached code results in an ICE. It compiled and worked as expected in gcc12. I've tried to reduce as much as I could, but I'm still not sure what causes the issue, sorry for being vague. Godbolt: https://godbolt.org/z/7ndKThnx6 System: gcc version 13.1.1, on arch linux x86_64 Thanks in advance.
[Bug c++/109966] [13/14 Regression] ICE in implify_var_or_parm_decl, à gimplify.cc:3058
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109966
Richard Biener changed:
What|Removed |Added
Known to work||12.3.0
Summary|[13.1 Regression] ICE in|[13/14 Regression] ICE in
|implify_var_or_parm_decl, à |implify_var_or_parm_decl, à
|gimplify.cc:3058|gimplify.cc:3058
Target Milestone|--- |13.2
Priority|P3 |P2
Last reconfirmed||2023-05-25
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Known to fail||13.1.0
Keywords||ice-on-valid-code,
||needs-bisection
--- Comment #1 from Richard Biener ---
#include
#include
template
struct MpvOptionBoundedScalar {
std::string_view name;
T default_value = 0;
T cur_value = default_value;
};
struct OptionHolder {
std::array, 3> video_zoom_options = {
MpvOptionBoundedScalar{"video-zoom", 0},
MpvOptionBoundedScalar{"video-pan-x", 0},
MpvOptionBoundedScalar{"video-pan-y", 0},
};
};
OptionHolder o;
[Bug target/109800] [11/12/13/14 Regression] arm: ICE (segfault) loading double with -mpure-code -mbig-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109800 --- Comment #1 from CVS Commits --- The master branch has been updated by Alex Coplan : https://gcc.gnu.org/g:f5298d9969b4fa34ff3aecd54b9630e22b2984a5 commit r14-1239-gf5298d9969b4fa34ff3aecd54b9630e22b2984a5 Author: Alex Coplan Date: Thu May 25 13:34:46 2023 +0100 arm: Fix ICE due to infinite splitting [PR109800] In r11-966-g9a182ef9ee011935d827ab5c6c9a7cd8e22257d8 we introduce a simplification to emit_move_insn that attempts to simplify moves of the form: (set (subreg:M1 (reg:M2 ...)) (constant C)) where M1 and M2 are of equal mode size. That is problematic for the splitter vfp.md:no_literal_pool_df_immediate in the arm backend, which tries to pun an lvalue DFmode pseudo into DImode and assign a constant to it with emit_move_insn, as the new transformation simply undoes this, and we end up splitting indefinitely. This patch changes things around in the arm backend so that we use a DImode temporary (instead of DFmode) and first load the DImode constant into the pseudo, and then pun the pseudo into DFmode as an rvalue in a reg -> reg move. I believe this should be semantically equivalent but avoids the pathalogical behaviour seen in the PR. gcc/ChangeLog: PR target/109800 * config/arm/arm.md (movdf): Generate temporary pseudo in DImode instead of DFmode. * config/arm/vfp.md (no_literal_pool_df_immediate): Rather than punning an lvalue DFmode pseudo into DImode, use a DImode pseudo and pun it into DFmode as an rvalue. gcc/testsuite/ChangeLog: PR target/109800 * gcc.target/arm/pure-code/pr109800.c: New test.
[Bug target/109964] auto-vectorization of shift ignores integral promotions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109964 --- Comment #4 from rsandifo at gcc dot gnu.org --- (In reply to Richard Biener from comment #3) > So the bug in the vectorizer is that it does > > t.ii:14:5: note: can narrow to signed:16 without loss of precision: _31 = > 1 >> _30; > t.ii:14:5: note: only the low 16 bits of _30 are significant > > while that's correct that's not the proper constraint to check for in > vect_recog_over_widening_pattern I think. That has code to deal with > overflow for plus/minus/mult but no defense against shifts > (that's also not a vect_truncatable_operation_p, so maybe it should simply > check that) Like you say, vect_truncatable_operation_p already checks for operations for which truncation is distributive. But the function is supposed to handle other cases too. E.g. I think the current code is correct for division. But yeah, right shifts are an awkward case, because the defined range of the second operand is much smaller than the range of the type, and yet the defined range depends on the range of the type. Sorry for not thinking about that at the time.
[Bug c++/105541] [12 Regression] ICE: Segmentation fault when template lambda in requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105541 Patrick Palka changed: What|Removed |Added CC||egor.pugin at gmail dot com --- Comment #8 from Patrick Palka --- *** Bug 103212 has been marked as a duplicate of this bug. ***
[Bug c++/103212] requires expression with lambda inside causes a parse error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103212 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Keywords|needs-bisection | Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org --- Comment #4 from Patrick Palka --- Fully fixed for GCC 12.2+ by the fixes for PR101677 / PR105541 it seems. This is close enough to a dup of the latter. *** This bug has been marked as a duplicate of bug 105541 ***
[Bug libstdc++/109965] rename 'Modules' to 'Categories' in tree-view of doxygen-generated libstdc++ documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109965 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2023-05-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- This is Doxygen's terminology, not ours: https://www.doxygen.nl/manual/grouping.html#modules It might be possible to retitle it from "Modules" using a custom layout: https://www.doxygen.nl/manual/customize.html#layout
[Bug tree-optimization/109801] -Wmaybe-uninitialized warning with -O1 on move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109801
Richard Biener changed:
What|Removed |Added
Resolution|--- |INVALID
CC||rguenth at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Richard Biener ---
I see
[local count: 966367642]:
MEM[(struct __as_base &)&container] ={v} {CLOBBER};
MEM[(struct _Vector_impl_data *)&container] ={v} {CLOBBER};
MEM[(struct _Vector_impl_data *)&container]._M_start = _42;
MEM[(struct _Vector_impl_data *)&container]._M_finish = __cur_30;
MEM[(struct _Vector_impl_data *)&container]._M_end_of_storage = _37;
MEM[(struct _Vector_impl_data *)&D.26141]._M_start = 0B;
MEM[(struct _Vector_impl_data *)&D.26141]._M_finish = 0B;
MEM[(struct _Vector_impl_data *)&D.26141]._M_end_of_storage = 0B;
_7 = MEM[(type &)&container + 24]; <-- we diagnose this load
MEM[(int &)&container + 24] = 0;
MEM[(int &)&D.26141 + 24] = _7;
that looks like the std::swap (size_, other.size_) going wrong. Or well,
obviously size_ isn't initialized when
table(table&& other) {
std::swap(buckets_, other.buckets_);
std::swap(size_, other.size_);
}
is run, only other.size_ is. So it's entirely your fault I think.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 109801, which changed state. Bug 109801 Summary: -Wmaybe-uninitialized warning with -O1 on move constructor https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109801 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug target/99195] Optimise away vec_concat of 64-bit AdvancedSIMD operations with zeroes in aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99195 --- Comment #17 from CVS Commits --- The master branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:560bb845321f5ad039a318a081b0e88d9900f5cb commit r14-1241-g560bb845321f5ad039a318a081b0e88d9900f5cb Author: Kyrylo Tkachov Date: Thu May 25 15:00:16 2023 +0100 aarch64: PR target/99195 Annotate complex FP patterns for vec-concat-zero This patch annotates the complex add and mla patterns for vec-concat-zero. Testing showed an interesting bug in our MD patterns where they were defined to match: (plus:VHSDF (match_operand:VHSDF 1 "register_operand" "0") (unspec:VHSDF [(match_operand:VHSDF 2 "register_operand" "w") (match_operand:VHSDF 3 "register_operand" "w") (match_operand:SI 4 "const_int_operand" "n")] FCMLA)) but the canonicalisation rules for PLUS require the more "complex" operand to be first so during combine when the new substituted patterns were attempted to be formed combine/recog would try to match: (plus:V2SF (unspec:V2SF [ (reg:V2SF 100) (reg:V2SF 101) (const_int 0 [0]) ] UNSPEC_FCMLA270) (reg:V2SF 99)) instead. This patch fixes the operands of the PLUS RTX in these patterns. Similar patterns for the dot-product instructions already used the right order. Bootstrapped and tested on aarch64-none-linux-gnu and aarch64_be-none-elf. gcc/ChangeLog: PR target/99195 * config/aarch64/aarch64-simd.md (aarch64_fcadd): Rename to... (aarch64_fcadd): ... This. Fix canonicalization of PLUS operands. (aarch64_fcmla): Rename to... (aarch64_fcmla): ... This. Fix canonicalization of PLUS operands. (aarch64_fcmla_lane): Rename to... (aarch64_fcmla_lane): ... This. Fix canonicalization of PLUS operands. (aarch64_fcmla_laneqv4hf): Rename to... (aarch64_fcmla_laneqv4hf): ... This. Fix canonicalization of PLUS operands. (aarch64_fcmlaq_lane): Fix canonicalization of PLUS operands. gcc/testsuite/ChangeLog: PR target/99195 * gcc.target/aarch64/simd/pr99195_9.c: New test.
[Bug c/109967] New: Wrong code at -O2 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109967
Bug ID: 109967
Summary: Wrong code at -O2 on x86_64-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
For the following code, gcc trunk at -O2 emits the wrong code. This seems to be
a long latent bug since GCC-7 (I tried gcc-7.4 on compiler explorer, which
still emits the wrong result.)
Compiler explorer: https://godbolt.org/z/YGeWedWq7
$ cat a.c
int printf(const char *, ...);
int a, c;
int main() {
long f[2];
int e = 0;
for (; e < 2; e++) {
{
char g[20];
char *b = g;
int d = 48, e = 0;
while (d && e < 5)
b[e++] = d /= 10;
c = e;
}
f[c - 2 + e] = 1;
}
a = f[0];
printf("%d\n", a);
}
$
$ gcc-tk -O0 a.c && ./a.out
1
$ gcc-tk -O2 a.c && ./a.out
4
$
$ gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-8d5f050dabbf6dd3b992c3b46661848dbcf30d9e/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-8d5f050dabbf6dd3b992c3b46661848dbcf30d9e
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230523 (experimental) (GCC)
$
[Bug c++/109966] [13/14 Regression] ICE in implify_var_or_parm_decl, à gimplify.cc:3058
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109966 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Keywords|needs-bisection | Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Oy, started with r13-765: commit 1b661f3f5e712c951e774b3b91fffe4dac734cc7 Author: Marek Polacek Date: Tue Apr 26 15:52:00 2022 -0400 c++: ICE with temporary of class type in DMI [PR100252]
[Bug libstdc++/109965] rename 'Modules' to 'Categories' in tree-view of doxygen-generated libstdc++ documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109965 --- Comment #2 from Saifi Khan --- Yes, you are right. Doxygen has 'Modules' hard-coded everywhere in the code as they have used the word as an organizing principle. It starts with enum Kind defined in LayoutNavEntry https://raw.githubusercontent.com/doxygen/doxygen/master/src/layout.h All the string-literals related to usage of word 'Modules' are hard-coded in this file. https://raw.githubusercontent.com/doxygen/doxygen/master/src/translator_en.h Modules Modules List Modules Index There are additional entries with regard to the usage of the term in Fortran which may be skipped. There are multiple translator files on a per-language (human spoken language) basis. Short of re-compiling the doxygen code with string literal changed to "Components" i can't seem to find any other way.
[Bug libstdc++/109965] rename 'Modules' to 'Categories' in tree-view of doxygen-generated libstdc++ documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109965 --- Comment #3 from Saifi Khan --- Trying the 'custom' layout approach that you suggested. The file modified is /opt/gcc/src/libstdc++-v3/doc/doxygen/DoxygenLayout.xml
[Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791 --- Comment #16 from Andrew Pinski --- (In reply to Richard Biener from comment #15) > Created attachment 55155 [details] > patch unfolding such PHIs > > Updated PHI unfolding patch. Tests fine besides mentioned diagnostic > regressions. I was looking into doing the opposite in forwprop but maybe I can skip addresses.
[Bug libstdc++/109965] rename 'Modules' to 'Categories' in tree-view of doxygen-generated libstdc++ documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109965 --- Comment #4 from Jonathan Wakely --- (In reply to Saifi Khan from comment #2) > Short of re-compiling the doxygen code with string literal changed to > "Components" i can't seem to find any other way. Well if nothing else works, we can just use sed on the generated pages. (In reply to Saifi Khan from comment #3) > The file modified is > /opt/gcc/src/libstdc++-v3/doc/doxygen/DoxygenLayout.xml It needs to be in the directory where doxygen is run, or pointed to by the LAYOUT_FILE config in doc/doxygen/user.cfg.in
[Bug libstdc++/109947] std::expected monadic operations do not support move-only error types yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|SUSPENDED Resolution|INVALID |--- Ever confirmed|0 |1 Last reconfirmed||2023-05-25 --- Comment #7 from Jonathan Wakely --- I've created https://cplusplus.github.io/LWG/issue3938 for this, let's see where that goes.
[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811 AK changed: What|Removed |Added CC||hiraditya at msn dot com --- Comment #4 from AK --- On AArch64 (typically mobile platforms) app developers typically would enable frame pointers by default because it helps with crash reporting.
[Bug c/109968] New: False Warning stringop-overread when -O2 and -fsanitize=address used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109968 Bug ID: 109968 Summary: False Warning stringop-overread when -O2 and -fsanitize=address used Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: davekelly13 at gmail dot com Target Milestone: --- Created attachment 55157 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55157&action=edit Preprocessed source gcc-13 -O2 -fsanitize=address --save-temps x.c -S x.c: In function ‘f’: x.c:17:15: warning: ‘write’ reading 6 bytes from a region of size 4 [-Wstringop-overread] 17 | err = write( 1, (const void *)&(s->s2), 6); | ^~~~ x.c:5:21: note: source object ‘b’ of size 4 5 | int b; | ^ In file included from x.c:1: /usr/include/unistd.h:378:16: note: in a call to function ‘write’ declared with attribute ‘access (read_only, 2, 3)’ 378 | extern ssize_t write (int __fd, const void *__buf, size_t __n) __wur |^ Preprocessed source attached. Removing the "if ( s->s2.b == 1 ) return 0;" resolves the issue. gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 12.2.0-17ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-12-Pa930Z/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-Pa930Z/gcc-12-12.2.0/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (Ubuntu 12.2.0-17ubuntu1)
[Bug c++/109966] [13/14 Regression] ICE in implify_var_or_parm_decl, à gimplify.cc:3058
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109966
--- Comment #3 from Marek Polacek ---
// PR c++/109966
struct M;
template struct __array_traits {
typedef M _Type[_Nm];
};
template struct array {
typename __array_traits<_Nm>::_Type _M_elems;
};
struct basic_string_view {
basic_string_view(const char *);
};
struct M {
basic_string_view name;
int j = 42;
int default_value = j;
};
struct S {
array<3> arr{M{""}, {""}, {""}};
} o;
[Bug tree-optimization/109968] False Warning stringop-overread when -O2 and -fsanitize=address used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109968 --- Comment #1 from Andrew Pinski --- From https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Instrumentation-Options.html#index-fsanitize_003daddress : Note that sanitizers tend to increase the rate of false positive warnings, most notably those around -Wmaybe-uninitialized. We recommend against combining -Werror and [the use of] sanitizers.
[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811 --- Comment #5 from Andrew Pinski --- (In reply to AK from comment #4) > On AArch64 (typically mobile platforms) app developers typically would > enable frame pointers by default because it helps with crash reporting. s/AArch64 (typically mobile platforms)/phone\tablet/ Because aarch64 is also used for servers and network applicances too.
[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811
--- Comment #6 from Jakub Jelinek ---
I think aarch64 defaults to -fno-omit-frame-pointer anyway.
/* Disable fomit-frame-pointer by default. */
{ OPT_LEVELS_ALL, OPT_fomit_frame_pointer, NULL, 0 },
[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811
--- Comment #7 from Florian Weimer ---
(In reply to Jakub Jelinek from comment #6)
> I think aarch64 defaults to -fno-omit-frame-pointer anyway.
> /* Disable fomit-frame-pointer by default. */
> { OPT_LEVELS_ALL, OPT_fomit_frame_pointer, NULL, 0 },
It's required by some (all?) AArch64 ABIs, certainly on GNU/Linux.
[Bug c/109956] GCC reserves 9 bytes for struct s { int a; char b; char t[]; } x = {1, 2, 3};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #12 from Martin Uecker ---
The C standard says "However, when a . (or -> ) operator has a left operand
that is (a pointer to) a structure with a flexible array member and the right
operand names that member, it behaves as if that member were replaced with the
longest array (with the same element type) that would not make the structure
larger than the object being accessed;"
This would imply that also for GCC not all elements can be accessed in the
following structure without invoking UB. For x86_64 'x' has 11 bytes (for clang
9) but a struct with replacement array actually needs 12.
struct foo { int a; short b; char t[]; } x = { .t = { 1, 2, 3 } };
// x has 11 bytes
struct bar { int a; short b; char t[3]; }; // 12 bytes
One can argue that this does not matter for an extension and maybe the C
standard should not be read in this way as itself also contains an example
using the sizeof() + n * sizeof() rule which implies that this amount of
storage is enough for n elements.
But the question is what programmers should use when using memcpy of statically
initialized structs which have a FAM? sizeof() + n * sizeof() works for GCC
but not for clang. sizeof(struct bar) works for neither. One can use
MAX(sizeof(struct foo, offsetof(struct foo, t) + n * sizeof(char)) but I have
not seen anybody use it.
[Bug target/109933] __atomic_test_and_set is broken for BIG ENDIAN riscv targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109933 --- Comment #10 from Rory Bolt --- Tested and verified on little endian too.
[Bug tree-optimization/109968] False Warning stringop-overread at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109968
Andrew Pinski changed:
What|Removed |Added
Summary|False Warning |False Warning
|stringop-overread when -O2 |stringop-overread at -O2
|and -fsanitize=address used |
--- Comment #2 from Andrew Pinski ---
Reduced testcase without -fsanitize=address:
extern int write1 (int __fd, const void *__buf, size_t __n)
__attribute__ ((__access__ (__read_only__, 2, 3)));
typedef struct {
struct {
int b;
int c;
} s2;
} S;
void f1(int *a);
int f(S *s )
{
int err;
f1(&s->s2.b);
err = write1( 1, (const void *)&(s->s2), 6);
return err;
}
[Bug tree-optimization/109968] False Warning stringop-overread at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109968
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Reduced testcase without -fsanitize=address:
Sorry missed one undefined type.
Here is the corrected reduced testcase:
```
extern int write1 (int __fd, const void *__buf, int __n)
__attribute__ ((__access__ (__read_only__, 2, 3)));
typedef struct {
struct {
int b;
int c;
} s2;
} S;
void f1(int *a);
int f(S *s )
{
int err;
f1(&s->s2.b);
err = write1( 1, (const void *)&(s->s2), 6);
return err;
}
```
[Bug rtl-optimization/82931] Missing Optimization for Bit-Transfer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82931 --- Comment #5 from CVS Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:ff0a6900700636ac4c7f40b88490a20d19a68db3 commit r14-1244-gff0a6900700636ac4c7f40b88490a20d19a68db3 Author: Georg-Johann Lay Date: Thu May 25 19:02:34 2023 +0200 target/82931: Make a pattern more generic to match more bit-transfers. There is already a pattern in avr.md that matches single-bit transfers from one register to another one, but it only handled bit 0 of 8-bit registers. This change makes that pattern more generic so it matches more of similar single-bit transfers. gcc/ PR target/82931 * config/avr/avr.md (*movbitqi.0): Rename to *movbit.0-6. Handle any bit position and use mode QISI. * config/avr/avr.cc (avr_rtx_costs_1) [IOR]: Return a cost of 2 insns for bit-transfer of respective style. gcc/testsuite/ PR target/82931 * gcc.target/avr/pr82931.c: New test.
[Bug fortran/104350] ICE in gfc_array_dimen_size(): Bad dimension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104350 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed for gcc-14. Closing. Thanks for the report!
[Bug fortran/103794] ICE in gfc_check_reshape, at fortran/check.c:4727
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103794 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from anlauf at gcc dot gnu.org --- Fixed for gcc-14. Closing. Thanks for the report!
[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811 --- Comment #8 from AK --- Should we enable frame-pointers by default for RISCV64 as well?
[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811 --- Comment #9 from Jakub Jelinek --- Why? It should be enabled by default only if it is effectively mandated by the ABI and/or doesn't affect performance at all (and is actually useful in functions that don't need it like functions with alloca/VLAs; see the PowerPC case).
[Bug rtl-optimization/82931] Missing Optimization for Bit-Transfer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82931 --- Comment #6 from CVS Commits --- The releases/gcc-13 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:a499ab08d18eff4ca9c079cafaee0708d2bcbf20 commit r13-7377-ga499ab08d18eff4ca9c079cafaee0708d2bcbf20 Author: Georg-Johann Lay Date: Thu May 25 19:02:34 2023 +0200 target/82931: Make a pattern more generic to match more bit-transfers. There is already a pattern in avr.md that matches single-bit transfers from one register to another one, but it only handled bit 0 of 8-bit registers. This change makes that pattern more generic so it matches more of similar single-bit transfers. gcc/ PR target/82931 * config/avr/avr.md (*movbitqi.0): Rename to *movbit.0-6. Handle any bit position and use mode QISI. * config/avr/avr.cc (avr_rtx_costs_1) [IOR]: Return a cost of 2 insns for bit-transfer of respective style. gcc/testsuite/ PR target/82931 * gcc.target/avr/pr82931.c: New test.
[Bug target/104327] [12 Regression] Inlining error on s390x since r12-1039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104327 --- Comment #11 from CVS Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:66cc0cb0f44f17049f61af6755043999c4fa5a24 commit r14-1245-g66cc0cb0f44f17049f61af6755043999c4fa5a24 Author: Georg-Johann Lay Date: Tue May 23 14:54:12 2023 +0200 target/104327: Allow more inlining between different optimization levels. avr-common.cc introduces the following options that are set depending on optimization level: -mgas-isr-prologues, -mmain-is-OS-task and -fsplit-wide-types-early. The inliner thinks that different options disallow cross-optimization inlining, so provide can_inline_p. gcc/ PR target/104327 * config/avr/avr.cc (avr_can_inline_p): New static function. (TARGET_CAN_INLINE_P): Define to that function.
[Bug modula2/109969] New: Linking large project causes an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109969 Bug ID: 109969 Summary: Linking large project causes an ICE Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: gaius at gcc dot gnu.org Target Milestone: --- As reported on the gm2 mailing list - linking a large project 80k lines causes an ICE. Brief analysis also highlights a bug in M2LexBuf_OpenSource and GetToken (which sets currenttoken to eoftok) even though the definition module contains correct code. I suspect that fixing this bug will also fix PR 108344 (both reference GetToken - which is due for a re-write).
[Bug target/104327] [12 Regression] Inlining error on s390x since r12-1039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104327 --- Comment #12 from CVS Commits --- The releases/gcc-13 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:6506590e70e57ed8d7fb68ab9443e31c31208fb0 commit r13-7378-g6506590e70e57ed8d7fb68ab9443e31c31208fb0 Author: Georg-Johann Lay Date: Tue May 23 14:54:12 2023 +0200 target/104327: Allow more inlining between different optimization levels. avr-common.cc introduces the following options that are set depending on optimization level: -mgas-isr-prologues, -mmain-is-OS-task and -fsplit-wide-types-early. The inliner thinks that different options disallow cross-optimization inlining, so provide can_inline_p. gcc/ PR target/104327 * config/avr/avr.cc (avr_can_inline_p): New static function. (TARGET_CAN_INLINE_P): Define to that function.
[Bug rtl-optimization/82931] Missing Optimization for Bit-Transfer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82931 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:4d39f68b891ed2ac7aca5ef24119f50976b84c22 commit r12-9654-g4d39f68b891ed2ac7aca5ef24119f50976b84c22 Author: Georg-Johann Lay Date: Thu May 25 19:02:34 2023 +0200 target/82931: Make a pattern more generic to match more bit-transfers. There is already a pattern in avr.md that matches single-bit transfers from one register to another one, but it only handled bit 0 of 8-bit registers. This change makes that pattern more generic so it matches more of similar single-bit transfers. gcc/ PR target/82931 * config/avr/avr.md (*movbitqi.0): Rename to *movbit.0-6. Handle any bit position and use mode QISI. * config/avr/avr.cc (avr_rtx_costs_1) [IOR]: Return a cost of 2 insns for bit-transfer of respective style. gcc/testsuite/ PR target/82931 * gcc.target/avr/pr82931.c: New test.
[Bug target/104327] [12 Regression] Inlining error on s390x since r12-1039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104327 --- Comment #13 from CVS Commits --- The releases/gcc-12 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:0537c71aa7ef88c4ffe754cf7af81e346273b079 commit r12-9655-g0537c71aa7ef88c4ffe754cf7af81e346273b079 Author: Georg-Johann Lay Date: Tue May 23 14:54:12 2023 +0200 target/104327: Allow more inlining between different optimization levels. avr-common.cc introduces the following options that are set depending on optimization level: -mgas-isr-prologues, -mmain-is-OS-task and -fsplit-wide-types-early. The inliner thinks that different options disallow cross-optimization inlining, so provide can_inline_p. gcc/ PR target/104327 * config/avr/avr.cc (avr_can_inline_p): New static function. (TARGET_CAN_INLINE_P): Define to that function.
[Bug modula2/109969] Linking large project causes an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109969 Gaius Mulley changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-05-25 --- Comment #1 from Gaius Mulley --- I've yet to reproduce the ICE as reported - but certainly see a problem with GetToken which fails to obtain the first token in a definition module for a large project.
[Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263 --- Comment #39 from Alexander Klepikov --- > The tst insn is mainly formed by the combine pass, which relies on certain > insn patterns and combinations thereof. See also sh.md, around line 530. I'm sorry, but .md lang is too complicated for me. > You can look at the debug output with the -fdump-rtl-all option to see > what's happening in the RTL passes. It looks like with optimization enabled it converts bitwise AND to right shift and then optimizes again. But SH4 has 'shad' and 'shad' can be optimized to 'tst'. And SH2E has libcall instead of dynamic shift and libcll cannot be converted. It seems that very first optimization spoils things. But when we have numerous 'shar' instructions, optimization joins the game again and converts them to 'tst'. > What your patch is doing is to make it not emit the ashrsi3_n insn for > constant shifts altogether? I guess it will make code that actually needs > those real shifts larger, as it will always emit the whole shift stitching > sequence. That might be a good thing or not. You are absolutely right, the code will be larger when we do right shifts. But there's situations when you can't use library. For exmple, SH7055 engine control unit can barely contain the program. The library just won't fit.
[Bug rtl-optimization/82931] Missing Optimization for Bit-Transfer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82931 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Georg-Johann Lay --- Should work in v12.4 and v13.2+.
