[Bug libfortran/101305] New: Bind(C): Problems with incorrect kinds/sizes in ISO_Fortran_binding.h and CFI_establish
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101305 Bug ID: 101305 Summary: Bind(C): Problems with incorrect kinds/sizes in ISO_Fortran_binding.h and CFI_establish Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org CC: burnus at gcc dot gnu.org, jrfsousa at gcc dot gnu.org Target Milestone: --- ISO_Fortran_binding.h incorrectly hard-codes literal data sizes into the CFI_type_* macros that are only appropriate on a 64-bit target, such as CFI_type_ptrdiff_t having the same kind (8) as CFI_type_int64_t. Even on x86_64-linux-gnu, CFI_type_int_fast16_t and CFI_type_int_fast32_t have kinds that are inconsistent with the sizes of the corresponding types as defined in the system headers. In addition, the standard says: "If a C type is not interoperable with a Fortran type and kind supported by the Fortran processor, its macro shall evaluate to a negative value." ISO_Fortran_binding.h doesn't handle that (I think this mainly affects the 128-bit types GCC supports as an extension on some targets). There are related problems in CFI_establish in filling in the elem_len in the descriptor from the kind. It incorrectly ends up giving zero elem_len to CFI_type_cptr and CFI_type_cfunptr, and explicitly gives size 64(!) to long double kind 10. It should probably reject unsupported types with CFI_INVALID_TYPE. There are test cases in the WIP TS 29113 testsuite: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574115.html interoperability/typecodes-array.f90 interoperability/typecodes-array-ext.f90 interoperability/typecodes-scalar.f90 interoperability/typecodes-scalar-ext.f90 library/establish.f90 This issue has some overlap with the set of bugs addressed by this patch from José (PR fortran/100906/100907/100911/100914/100915/100916): https://gcc.gnu.org/pipermail/fortran/2021-June/056154.html but that patch is focused on the Fortran side of things rather than the C side. Tobias and I both have WIP patches for this issue that need to be merged (his is for handling detection of Fortran processor support, mine is to use sizeof instead of hard-coding sizes). Probably all 3 pieces need to be in place for this to work correctly.
[Bug tree-optimization/101039] Some simple fold_cond_expr_with_comparison with CMP 0 is not simplified if expanded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101039 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-07-03 --- Comment #1 from Andrew Pinski --- Mine, I had forgot I filed this bug when I submitted the patches for this. Patch submitted here: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573785.html I guess I should add a few testcases to the patch.
[Bug tree-optimization/100848] Cases that require -fallow-store-data-races aren't vectorised with IFN_MASK_LOAD/STORE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100848 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/100846] Different vector handling for strided IVs and modulo conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100846 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug fortran/101304] New: Bind(C): CONTIGUOUS attribute not handled correctly in Fortran routines called from C with discontiguous argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101304 Bug ID: 101304 Summary: Bind(C): CONTIGUOUS attribute not handled correctly in Fortran routines called from C with discontiguous argument Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- Section 18.3.6 of the Fortran 2018 standard says: "When an interoperable Fortran procedure that is invoked from C has a dummy argument with the CONTIGUOUS attribute or that is an assumed-length CHARACTER explicit-shape or assumed-size array, and the actual argument is the address of a C descriptor for a discontiguous object, the Fortran processor shall handle the difference in contiguity." This is not working properly. The bug is exposed by test cases interoperability/contiguous-2.f90 and interoperability/contiguous-3.f90 from the WIP TS29113 testsuite: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574115.html It looks like ftest1 is getting an array that starts at the correct offset of the discontiguous section but has lost the non-unit sm from the base array. Calling ftest1 and ftest2 directly from Fortran with a discontiguous array section works correctly.
[Bug modula2/101259] error: the file containing the definition module 'getopt' cannot be found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101259 Matthias Klose changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|MOVED |--- --- Comment #2 from Matthias Klose --- please keep those open, we created the component for the bug tracker to get these tracked while the merge is ongoing.
[Bug modula2/101259] error: the file containing the definition module 'getopt' cannot be found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101259 Andrew Pinski changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- I think you should report this directly to the GM2 folks. GM2 has not been merged yet; it is in the process of being merged though.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #5 from ofv at wanadoo dot es --- Taken from config.log: ac_cs_config=" '--prefix=/mingw32' '--with-local-prefix=/mingw32/local' '--build=i686-w64-mingw32' '--host=i686-w64-mingw32' '--target=i686-w64-mingw32' '--with-native-system-header-dir=/mingw32/i686-w64-mingw32/include' '--libexecdir=/mingw32/lib' '--enable-bootstrap' '--enable-checking=release' '--with-arch=i686' '--with-tune=generic' '--enable-shared' '--enable-static' '--enable-libatomic' '--enable-threads=posix' '--enable-graphite' '--enable-fully-dynamic-string' '--enable-libstdcxx-filesystem-ts' '--enable-libstdcxx-time' '--disable-libstdcxx-pch' '--disable-libstdcxx-debug' '--enable-lto' '--enable-libgomp' '--disable-multilib' '--disable-rpath' '--disable-win32-registry' '--disable-nls' '--disable-werror' '--disable-symvers' '--with-libiconv' '--with-system-zlib' '--with-gmp=/mingw32' '--with-mpfr=/mingw32' '--with-mpc=/mingw32' '--with-isl=/mingw32' '--with-pkgversion=Rev1, Built by MSYS2 project' '--with-bugurl=https://github.com/msys2/MINGW-packages/issues' '--with-gnu-as' '--with-gnu-ld' '--with-boot-ldflags=-pipe -Wl,--dynamicbase,--nxcompat,--no-seh -Wl,--large-address-aware -Wl,--disable-dynamicbase -static-libstdc++ -static-libgcc' 'LDFLAGS_FOR_TARGET=-pipe -Wl,--dynamicbase,--nxcompat,--no-seh -Wl,--large-address-aware' '--enable-linker-plugin-flags=LDFLAGS=-static-libstdc++\\ -static-libgcc\\ -pipe\\ -Wl,--dynamicbase,--nxcompat,--no-seh\\ -Wl,--large-address-aware\\ -Wl,--stack,12582912' '--disable-sjlj-exceptions' '--with-dwarf2' 'build_alias=i686-w64-mingw32' 'host_alias=i686-w64-mingw32' 'target_alias=i686-w64-mingw32' 'CC=gcc' 'CFLAGS=-march=i686 -mtune=generic -O2 -pipe' 'LDFLAGS=-pipe -Wl,--dynamicbase,--nxcompat,--no-seh -Wl,--large-address-aware -Wl,--disable-dynamicbase' 'CPPFLAGS=-D__USE_MINGW_ANSI_STDIO=1' 'CXX=g++' 'CXXFLAGS=-march=i686 -mtune=generic -O2 -pipe' '--enable-languages=c,ada,c++,fortran,jit,lto,objc,obj-c++'"
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #4 from ofv at wanadoo dot es --- (In reply to Eric Botcazou from comment #3) > We definitely cannot investigate this without more information, in > particular the configure line. Barring that, you might want to try with the > current gcc-11 branch where a very recent change could help. Which change? 014e6aa467b1648d09eab9897ca367bfec5e6b76 ? Applying that on top of gcc 11.1 makes no difference. Sorry for not providing the configure line yet. I'll try to setup a local build environment ASAP.
[Bug gcov-profile/101193] [GCOV] Bit operation leads to wrong coverage information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101193 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- (In reply to Martin Liška from comment #1) > Confirmed, we have quite some similar issues. It's not related to bitfields > but to fact that the following expression is split among multiple lines: > > return in.bfval.f0 | (in.bfval.f1 << 8) | (in.bfval.f2 << 16) | (in.bfval.f3 > << 24); Actually I suspect it is more related to bitfields and spread across multiple lines. There is an optimization done early (before GCOV) in fold-const which combines the above to use and afterwards. I have a few set of patches which allows to get rid of most of the optimization in fold-const dealing with this but not all; This is something which I am going to work towards for GCC 12 but after the current phiopt work.
[Bug d/101282] d: RHS value lost when a target_expr modifies LHS in a cond_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101282 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Iain Buclaw --- Fixed.
[Bug d/101282] d: RHS value lost when a target_expr modifies LHS in a cond_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101282 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:f67d7f9416be37c34c4188866fb3d10c1dbc7a2a commit r11-8686-gf67d7f9416be37c34c4188866fb3d10c1dbc7a2a Author: Iain Buclaw Date: Sat Jul 3 00:13:29 2021 +0200 d: RHS value lost when a target_expr modifies LHS in a cond_expr To prevent the RHS of an assignment modifying the LHS before the assignment proper, a target_expr is forced so that function calls that return with slot optimization modify the temporary instead. This did not work for conditional expressions however, to give one example. So now the RHS is always forced to a temporary. PR d/101282 gcc/d/ChangeLog: * d-codegen.cc (build_assign): Force target_expr on RHS for non-POD assignment expressions. gcc/testsuite/ChangeLog: * gdc.dg/torture/pr101282.d: New test. (cherry picked from commit c77230856eac2d28eb7bf10985846885c3c8727b)
[Bug d/101282] d: RHS value lost when a target_expr modifies LHS in a cond_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101282 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:c77230856eac2d28eb7bf10985846885c3c8727b commit r12-1993-gc77230856eac2d28eb7bf10985846885c3c8727b Author: Iain Buclaw Date: Sat Jul 3 00:13:29 2021 +0200 d: RHS value lost when a target_expr modifies LHS in a cond_expr To prevent the RHS of an assignment modifying the LHS before the assignment proper, a target_expr is forced so that function calls that return with slot optimization modify the temporary instead. This did not work for conditional expressions however, to give one example. So now the RHS is always forced to a temporary. PR d/101282 gcc/d/ChangeLog: * d-codegen.cc (build_assign): Force target_expr on RHS for non-POD assignment expressions. gcc/testsuite/ChangeLog: * gdc.dg/torture/pr101282.d: New test.
[Bug middle-end/98871] Cannot silence -Wmaybe-uninitialized at declaration site
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98871 --- Comment #6 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:6feb628a706e86eb3f303aff388c74bdb29e7381 commit r12-1992-g6feb628a706e86eb3f303aff388c74bdb29e7381 Author: Martin Sebor Date: Fri Jul 2 16:16:31 2021 -0600 Improve warning suppression for inlined functions [PR98512]. Resolves: PR middle-end/98871 - Cannot silence -Wmaybe-uninitialized at declaration site PR middle-end/98512 - #pragma GCC diagnostic ignored ineffective in conjunction with alias attribute gcc/ChangeLog: PR middle-end/98871 PR middle-end/98512 * diagnostic.c (get_any_inlining_info): New. (update_effective_level_from_pragmas): Handle inlining context. (diagnostic_enabled): Same. (diagnostic_report_diagnostic): Same. * diagnostic.h (struct diagnostic_info): Add ctor. (struct diagnostic_context): Add new member. * tree-diagnostic.c (set_inlining_locations): New. (tree_diagnostics_defaults): Set new callback pointer.
[Bug tree-optimization/98512] [11/12 Regression] “#pragma GCC diagnostic ignored” ineffective in conjunction with alias attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98512 --- Comment #11 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:6feb628a706e86eb3f303aff388c74bdb29e7381 commit r12-1992-g6feb628a706e86eb3f303aff388c74bdb29e7381 Author: Martin Sebor Date: Fri Jul 2 16:16:31 2021 -0600 Improve warning suppression for inlined functions [PR98512]. Resolves: PR middle-end/98871 - Cannot silence -Wmaybe-uninitialized at declaration site PR middle-end/98512 - #pragma GCC diagnostic ignored ineffective in conjunction with alias attribute gcc/ChangeLog: PR middle-end/98871 PR middle-end/98512 * diagnostic.c (get_any_inlining_info): New. (update_effective_level_from_pragmas): Handle inlining context. (diagnostic_enabled): Same. (diagnostic_report_diagnostic): Same. * diagnostic.h (struct diagnostic_info): Add ctor. (struct diagnostic_context): Add new member. * tree-diagnostic.c (set_inlining_locations): New. (tree_diagnostics_defaults): Set new callback pointer.
[Bug c++/84027] new-expression does not accept an attribute-specifier-seq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84027 Andrew Pinski changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- *** Bug 101302 has been marked as a duplicate of this bug. ***
[Bug c++/101302] attribute-specifier-seq in noptr-new-declarator not parsed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101302 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 84027. *** This bug has been marked as a duplicate of bug 84027 ***
[Bug tree-optimization/101223] [11 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101223 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED Summary|[11/12 Regression] evrp |[11 Regression] evrp |produces wrong code since |produces wrong code since |r11-3685-gfcae5121154d1c33 |r11-3685-gfcae5121154d1c33 --- Comment #13 from Andrew Pinski --- Reopening since it was only fixed on the trunk and it was a regression in GCC 11.
[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860 --- Comment #58 from David Binderman --- (In reply to Martin Liška from comment #57) > Can you please build options-save.c with -O0 and debug it: Good idea, but I have run out of time on this issue. Another 40 or so interesting commits have appeared in gcc trunk. It only seems to affect bdver2 and you've had multiple failures to reproduce, so I am happy to put this one on hold for a week. I plan to do another full -O3 -march=native bootstrap in a week. I will look into this problem then. I am happy for someone else to pick this one up. Sorry I can't do more, but then that's the nature of volunteer work.
[Bug tree-optimization/101256] [12 Regression] Wrong code with -O3 since r12-1841-g9fe9c45ae33a2df7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101256
--- Comment #6 from Andrew Pinski ---
And here is a self-contained testcase:
template
const T& max(const T& a, const T& b)
{
return (a < b) ? b : a;
}
signed char var_5 = -128;
unsigned int var_11 = 2144479212U;
unsigned long long int arr [22];
void
__attribute__((noipa))
test(signed char var_5, unsigned var_11) {
for (short i_61 = 0; i_61 < var_5 + 149; i_61 += 1)
arr[i_61] = max((signed char)0, var_5) ? max((signed char)1, var_5) :
var_11;
}
int main() {
for (size_t i_0 = 0; i_0 < 22; ++i_0)
arr [i_0] = 11834725929543695741ULL;
test(var_5, var_11);
if (arr [0] != 2144479212ULL && arr [0] != 11834725929543695741ULL)
__builtin_abort ();
return 0;
}
[Bug c/101297] Spurious comma accepted at the end of #pragma omp atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101297 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2ca89394280da4afad6074ec3cb7136b6142af7b commit r12-1990-g2ca89394280da4afad6074ec3cb7136b6142af7b Author: Jakub Jelinek Date: Fri Jul 2 21:57:24 2021 +0200 openmp: Reject #pragma omp atomic update, [PR101297] I've noticed that we allow a trailing comma on OpenMP atomic construct if there is at least one clause. Commas should be only allowed to separate the clauses (or in OpenMP 5.1 to separate directive name from the clauses). 2021-07-02 Jakub Jelinek PR c/101297 * c-parser.c (c_parser_omp_atomic): Consume comma only if it appears before a CPP_NAME. * parser.c (cp_parser_omp_atomic): Consume comma only if it appears before a CPP_NAME. * c-c++-common/gomp/atomic-24.c: New test.
[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #23 from David Malcolm --- Fixed on branch (for gcc 11.2) by above commits; marking as resolved.
[Bug analyzer/100615] analyzer failed to report leak in rxtxcpu's parse_cpu_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100615 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from David Malcolm --- Fixed on branch (for gcc 11.2) by above commit; marking as resolved.
[Bug analyzer/100244] [11 Regression] ICE: Segmentation fault (in describe_state_change)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100244 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from David Malcolm --- Fixed on branch (for gcc 11.2) by above commit; marking as resolved.
[Bug middle-end/101300] -fsanitize=undefined suppresses -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101300 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Target Milestone|--- |12.0 Keywords||patch Status|NEW |ASSIGNED Known to fail||10.3.0, 11.1.0, 12.0, 9.3.0 --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574385.html
[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 --- Comment #22 from CVS Commits --- The releases/gcc-11 branch has been updated by David Malcolm : https://gcc.gnu.org/g:21b470a9c976f3db7cce6d58a07c58a58676f93c commit r11-8681-g21b470a9c976f3db7cce6d58a07c58a58676f93c Author: David Malcolm Date: Fri Jul 2 15:19:46 2021 -0400 analyzer: fix bitfield endianness issues [PR99212,PR101082] Looks like my patch for PR analyzer/99212 implicitly assumed little-endian, which the following patch fixes. Fixes bitfields-1.c on: - armeb-none-linux-gnueabihf - cris-elf - powerpc64-darwin - s390-linux-gnu gcc/analyzer/ChangeLog: PR analyzer/99212 PR analyzer/101082 * engine.cc: Include "target.h". (impl_run_checkers): Log BITS_BIG_ENDIAN, BYTES_BIG_ENDIAN, and WORDS_BIG_ENDIAN. * region-model-manager.cc (region_model_manager::maybe_fold_binop): Move support for masking via ARG0 & CST into... (region_model_manager::maybe_undo_optimize_bit_field_compare): ...this new function. Flatten by converting from nested conditionals to a series of early return statements to reject failures. Reject if type is not unsigned_char_type_node. Handle BYTES_BIG_ENDIAN when determining which bits are bound in the binding_map. * region-model.h (region_model_manager::maybe_undo_optimize_bit_field_compare): New decl. * store.cc (bit_range::dump): New function. * store.h (bit_range::dump): New decl. Signed-off-by: David Malcolm
[Bug analyzer/101082] new test case gcc.dg/analyzer/bitfields-1.c from r12-1303 fails on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101082 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by David Malcolm : https://gcc.gnu.org/g:21b470a9c976f3db7cce6d58a07c58a58676f93c commit r11-8681-g21b470a9c976f3db7cce6d58a07c58a58676f93c Author: David Malcolm Date: Fri Jul 2 15:19:46 2021 -0400 analyzer: fix bitfield endianness issues [PR99212,PR101082] Looks like my patch for PR analyzer/99212 implicitly assumed little-endian, which the following patch fixes. Fixes bitfields-1.c on: - armeb-none-linux-gnueabihf - cris-elf - powerpc64-darwin - s390-linux-gnu gcc/analyzer/ChangeLog: PR analyzer/99212 PR analyzer/101082 * engine.cc: Include "target.h". (impl_run_checkers): Log BITS_BIG_ENDIAN, BYTES_BIG_ENDIAN, and WORDS_BIG_ENDIAN. * region-model-manager.cc (region_model_manager::maybe_fold_binop): Move support for masking via ARG0 & CST into... (region_model_manager::maybe_undo_optimize_bit_field_compare): ...this new function. Flatten by converting from nested conditionals to a series of early return statements to reject failures. Reject if type is not unsigned_char_type_node. Handle BYTES_BIG_ENDIAN when determining which bits are bound in the binding_map. * region-model.h (region_model_manager::maybe_undo_optimize_bit_field_compare): New decl. * store.cc (bit_range::dump): New function. * store.h (bit_range::dump): New decl. Signed-off-by: David Malcolm
[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 --- Comment #21 from CVS Commits --- The releases/gcc-11 branch has been updated by David Malcolm : https://gcc.gnu.org/g:fa92642b26ee236098ed51752feecc7cf5711f8c commit r11-8678-gfa92642b26ee236098ed51752feecc7cf5711f8c Author: David Malcolm Date: Fri Jul 2 15:19:45 2021 -0400 analyzer: bitfield fixes [PR99212] This patch verifies the previous fix for bitfield sizes by implementing enough support for bitfields in the analyzer to get the test cases to pass. The patch implements support in the analyzer for reading from a BIT_FIELD_REF, and support for folding BIT_AND_EXPR of a mask, to handle the cases generated in tests. The existing bitfields tests in data-model-1.c turned out to rely on undefined behavior, in that they were assigning values to a signed bitfield that were outside of the valid range of values. I believe that that's why we were seeing target-specific differences in the test results (PR analyzer/99212). The patch updates the test to remove the undefined behaviors. gcc/analyzer/ChangeLog: PR analyzer/99212 * region-model-manager.cc (region_model_manager::maybe_fold_binop): Add support for folding BIT_AND_EXPR of compound_svalue and a mask constant. * region-model.cc (region_model::get_rvalue_1): Implement BIT_FIELD_REF in terms of... (region_model::get_rvalue_for_bits): New function. * region-model.h (region_model::get_rvalue_for_bits): New decl. * store.cc (bit_range::from_mask): New function. (selftest::test_bit_range_intersects_p): New selftest. (selftest::assert_bit_range_from_mask_eq): New. (ASSERT_BIT_RANGE_FROM_MASK_EQ): New macro. (selftest::assert_no_bit_range_from_mask_eq): New. (ASSERT_NO_BIT_RANGE_FROM_MASK): New macro. (selftest::test_bit_range_from_mask): New selftest. (selftest::analyzer_store_cc_tests): Call the new selftests. * store.h (bit_range::intersects_p): New. (bit_range::from_mask): New decl. (concrete_binding::get_bit_range): New accessor. (store_manager::get_concrete_binding): New overload taking const bit_range &. gcc/testsuite/ChangeLog: PR analyzer/99212 * gcc.dg/analyzer/bitfields-1.c: New test. * gcc.dg/analyzer/data-model-1.c (struct sbits): Make bitfields explicitly signed. (test_44): Update test values assigned to the bits to ones that fit in the range of the bitfield type. Remove xfails. (test_45): Remove xfails. Signed-off-by: David Malcolm
[Bug analyzer/100615] analyzer failed to report leak in rxtxcpu's parse_cpu_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100615 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by David Malcolm : https://gcc.gnu.org/g:8d58bfb78c8dc6f5bdf7786b96f26329e0d36b80 commit r11-8671-g8d58bfb78c8dc6f5bdf7786b96f26329e0d36b80 Author: David Malcolm Date: Fri Jul 2 15:19:43 2021 -0400 analyzer: fix missing leak after call to strsep [PR100615] PR analyzer/100615 reports a missing leak diagnostic. The issue is that the code calls strsep which the analyzer doesn't have special knowledge of, and so conservatively assumes that it could free the pointer, so drops malloc state for it. Properly "teaching" the analyzer about strsep would require it to support bifurcating state at a call, which is currently fiddly to do, so for now this patch notes that strsep doesn't affect the malloc state machine, allowing the analyzer to correctly detect the leak. gcc/analyzer/ChangeLog: PR analyzer/100615 * sm-malloc.cc: Include "analyzer/function-set.h". (malloc_state_machine::on_stmt): Call unaffected_by_call_p and bail on the functions it recognizes. (malloc_state_machine::unaffected_by_call_p): New. gcc/testsuite/ChangeLog: PR analyzer/100615 * gcc.dg/analyzer/pr100615.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/100244] [11 Regression] ICE: Segmentation fault (in describe_state_change)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100244 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by David Malcolm : https://gcc.gnu.org/g:1187f297f7ef6a3dc86103b642d463f7a7bd6096 commit r11-8670-g1187f297f7ef6a3dc86103b642d463f7a7bd6096 Author: David Malcolm Date: Fri Jul 2 15:19:43 2021 -0400 analyzer: fix ICE on NULL change.m_expr [PR100244] PR analyzer/100244 reports an ICE on a -Wanalyzer-free-of-non-heap due to a case where free_of_non_heap::describe_state_change can be passed a NULL change.m_expr for a suitably complicated symbolic value. Bulletproof it by checking for change.m_expr being NULL before dereferencing it. gcc/analyzer/ChangeLog: PR analyzer/100244 * sm-malloc.cc (free_of_non_heap::describe_state_change): Bulletproof against change.m_expr being NULL. gcc/testsuite/ChangeLog: PR analyzer/100244 * g++.dg/analyzer/pr100244.C: New test. Signed-off-by: David Malcolm
[Bug c++/101303] ICE from modified lambda-generic-100362.C test case from bug 100362
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101303 --- Comment #1 from Edward Nolan --- Some godbolt-ing shows that this test case is an ICE in GCC versions 9, 10, 11, and 12, and rejects-valid in GCC 8.
[Bug c++/101303] New: ICE from modified lambda-generic-100362.C test case from bug 100362
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101303
Bug ID: 101303
Summary: ICE from modified lambda-generic-100362.C test case
from bug 100362
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: enolan at alumni dot cmu.edu
Target Milestone: ---
When I was checking whether the fix for bug 100362 worked, I noticed that
although it fixed the minimal test case I provided, the original code from
which I'd minified it still crashed GCC. After some diffing I discovered that
the following slight modification of the gcc test case,
lambda-generic-100362.C, still caused an ICE. The cpp file I used is as
follows:
template
struct Qux {
struct A { } a_;
A f();
void AsyncOp() {
[this](auto) {
using Foo = decltype(a_);
struct local : Foo {};
local ptr;
}(0);
}
};
void corge() {
Qux qux;
qux.AsyncOp();
}
The changes from the original test case are that "struct local" inherits with a
"using" declaration instead of inheriting from "decltype(a_)" directly, and
that the lambda captures "this".
Although the version details included below are from a build of gcc from the
latest master, I also tested this with GCC 9.3.0, and it ICEd that version as
well.
> the exact version of GCC
I used Spack to build GCC from commit hash 58b735. (I accidentally tagged it
"11.1.0.58b735" even though it's 12.0.0.)
gcc version 12.0.0 20210701 (experimental) (Spack GCC)
> the system type
Ubuntu 21.04
> the options given when GCC was configured/built
Configured with:
/tmp/enolan/spack-stage/spack-stage-gcc-11.1.0.58b735-lfokficgbii3qo3wxptqa6cpavixfdwb/spack-src/configure
--prefix=/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/gcc-11.1.0.58b735-lfokficgbii3qo3wxptqa6cpavixfdwb
--with-pkgversion='Spack GCC'
--with-bugurl=https://github.com/spack/spack/issues --disable-multilib
--enable-languages=c,c++,fortran --disable-nls --with-system-zlib
--with-zstd-include=/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/zstd-1.4.9-g5e5ekytpmwt4p2s2whwo5n23uezvaau/include
--with-zstd-lib=/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/zstd-1.4.9-g5e5ekytpmwt4p2s2whwo5n23uezvaau/lib
--with-mpfr-include=/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/mpfr-4.1.0-wkdcn7axxshpddf24rlmrgbnl4b5x4uj/include
--with-mpfr-lib=/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/mpfr-4.1.0-wkdcn7axxshpddf24rlmrgbnl4b5x4uj/lib
--with-gmp-include=/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/gmp-6.2.1-y5nxi6djabr65jjm4pquijfju46tioyl/include
--with-gmp-lib=/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/gmp-6.2.1-y5nxi6djabr65jjm4pquijfju46tioyl/lib
--with-mpc-include=/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/mpc-1.1.0-v6jniwtyay66af7sk43c75njjrsoyjns/include
--with-mpc-lib=/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/mpc-1.1.0-v6jniwtyay66af7sk43c75njjrsoyjns/lib
--without-isl
--with-stage1-ldflags='-Wl,-rpath,/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/gcc-11.1.0.58b735-lfokficgbii3qo3wxptqa6cpavixfdwb/lib
-Wl,-rpath,/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/gcc-11.1.0.58b735-lfokficgbii3qo3wxptqa6cpavixfdwb/lib64
-Wl,-rpath,/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/gmp-6.2.1-y5nxi6djabr65jjm4pquijfju46tioyl/lib
-Wl,-rpath,/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/mpfr-4.1.0-wkdcn7axxshpddf24rlmrgbnl4b5x4uj/lib
-Wl,-rpath,/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/mpc-1.1.0-v6jniwtyay66af7sk43c75njjrsoyjns/lib
-Wl,-rpath,/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/zlib-1.2.11-xfc275gqwmrd3cwbjnqbnqx2u5gz444l/lib
-Wl,-rpath,/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/zstd-1.4.9-g5e5ekytpmwt4p2s2whwo5n23uezvaau/lib'
--with-boot-ldflags='-Wl,-rpath,/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/gcc-11.1.0.58b735-lfokficgbii3qo3wxptqa6cpavixfdwb/lib
-Wl,-rpath,/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/gcc-11.1.0.58b735-lfokficgbii3qo3wxptqa6cpavixfdwb/lib64
-Wl,-rpath,/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/gmp-6.2.1-y5nxi6djabr65jjm4pquijfju46tioyl/lib
-Wl,-rpath,/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/mpfr-4.1.0-wkdcn7axxshpddf24rlmrgbnl4b5x4uj/lib
-Wl,-rpath,/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/mpc-1.1.0-v6jniwtyay66af7sk43c75njjrsoyjns/lib
-Wl,-rpath,/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/zlib-1.2.11-xfc275gqwmrd3cwbjnqbnqx2u5gz444l/lib
-Wl,-rpath,/home/enolan/spack/opt/spack/linux-ubuntu21.04-zen3/gcc-11.0.1/zstd-1.4.9-g5e5ekytpmwt4p2s2whwo5n23uezvaau/lib
-static-libstdc++ -static-libgcc'
> the
[Bug c++/101247] ICE when using static constexpr bool defined in parent-class in nested class constructor requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101247 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:e3528ce197f8886869f95e8a8f901861a319851c commit r12-1989-ge3528ce197f8886869f95e8a8f901861a319851c Author: Patrick Palka Date: Fri Jul 2 13:54:57 2021 -0400 c++: unqualified member template in constraint [PR101247] Here any_template_parm_r is failing to mark the template parameters implicitly used by the unqualified use of 'd' inside the constraint because the code to do so assumes each level of a template parameter list points to the corresponding primary template, but here the parameter level for A in the out-of-line definition of A::B does not (nor do the parameter levels for A and C in the definition of A::C), which causes us to overlook the sharing. So it seems we can't in general depend on the TREE_TYPE of a template parameter level being non-empty here. This patch partially fixes this by rewriting the relevant part of any_template_parm_r to not depend on the TREE_TYPE of outer levels. We still depend on the innermost level to point to the innermost primary template, so we still crash on the commented out line in the below testcase. PR c++/101247 gcc/cp/ChangeLog: * pt.c (any_template_parm_r) : Rewrite to use common_enclosing_class and to not depend on the TREE_TYPE of outer levels pointing to the corresponding primary template. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-memtmpl4.C: New test.
[Bug middle-end/101300] -fsanitize=undefined suppresses -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101300 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2021-07-02 Blocks||24639 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Component|sanitizer |middle-end --- Comment #1 from Martin Sebor --- Confirmed. The sanitization interferes with the logic at -O0. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug libstdc++/101274] [11/12 Regression] std::execution::seq has incorrect behaviour under GCC 11.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101274 --- Comment #6 from Thomas Rodgers --- It does raise an issue which I'm going to follow up on separately on the SG1 (concurrency and parallelism study group) mailing list. While it is indeed the case that standard says you can't count on deterministic sequencing for std::reduce(), I can't find any wording that directly supports the wording on cppreference.com std::execution::sequenced_policy, though that wording is consistent with my recollection of SG1's discussions regarding execution policies. There is wording that says 'Unless otherwise specified, the semantics of ExecutionPolicy algorithm overloads are identical to their overloads without." The wording for std::for_each() for the non-execution policy overload the standard says - Effects: Applies f to the result of dereferencing every iterator in the range [first, last), starting from first and proceeding to last - 1. And for one that takes an execution policy - Effects: Applies f to the result of dereferencing every iterator in the range [first, last). So it omits the ordering constraint, which makes sense, but I wonder if we shouldn't be more explicit in the documentation of the policies themselves.
[Bug c++/101302] New: attribute-specifier-seq in noptr-new-declarator not parsed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101302
Bug ID: 101302
Summary: attribute-specifier-seq in noptr-new-declarator not
parsed
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
I think the gnu::packed attribute should be on the int[10] array type and
clang++ accepts it, but g++ rejects it with
attr4.C: In function ‘void foo()’:
attr4.C:4:27: error: ‘gnu’ was not declared in this scope
4 | auto a = new int [10] [[gnu::packed]];
| ^~~
attr4.C:4:30: error: expected ‘,’ before ‘::’ token
4 | auto a = new int [10] [[gnu::packed]];
| ^~
| ,
attr4.C:4:30: error: expected identifier before ‘::’ token
4 | auto a = new int [10] [[gnu::packed]];
| ^~
attr4.C: In lambda function:
attr4.C:4:39: error: expected ‘{’ before ‘]’ token
4 | auto a = new int [10] [[gnu::packed]];
| ^
attr4.C: In function ‘void foo()’:
attr4.C:4:26: error: expression in new-declarator must have integral or
enumeration type
4 | auto a = new int [10] [[gnu::packed]];
| ^
void
foo ()
{
auto a = new int [10] [[gnu::packed]];
}
[Bug sanitizer/100439] stack overflow running ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439
--- Comment #12 from Florin Iucha ---
Actually, it gets even better - no clang needed. Just build GCC 11-20210626
Snapshot and build the example using the Google test recipe:
#
# Makefile
#
ALL: bin/test_hello
.PHONY: clean
CXX=/opt/gcc11-for-tng/bin/g++-11
CXXFLAGS=-m64 -g -std=c++20 -fsanitize=undefined -fno-omit-frame-pointer
LDFLAGS=-L/opt/gcc11-for-tng/lib64 -Wl,-rpath,/opt/gcc11-for-tng/lib64
-fsanitize=undefined
GOOGLE_TEST_PATH=googletest/googletest
GOOGLE_TEST_OBJECTS=obj/gtest.o obj/gtest_main.o obj/gtest-port.o
obj/gtest-filepath.o obj/gtest-death-test.o obj/gtest-test-part.o
obj/gtest-printers.o
obj/test_hello.o: test_hello.cpp
$(CXX) $(CXXFLAGS) -o $@ -I$(GOOGLE_TEST_PATH)/include -c $<
obj/gtest.o: $(GOOGLE_TEST_PATH)/src/gtest.cc
$(CXX) $(CXXFLAGS) -o $@ -I$(GOOGLE_TEST_PATH)/include
-I$(GOOGLE_TEST_PATH) -c $<
obj/gtest%.o: $(GOOGLE_TEST_PATH)/src/gtest%.cc
$(CXX) $(CXXFLAGS) -o $@ -I$(GOOGLE_TEST_PATH)/include
-I$(GOOGLE_TEST_PATH) -c $<
bin/test_hello: obj/test_hello.o $(GOOGLE_TEST_OBJECTS)
$(CXX) -o $@ $(LDFLAGS) $^ -lpthread
clean:
$(RM) bin/test_hello obj/*.o
#
# test_hello.cpp
#
#include
#include
TEST(Hello, World)
{
ASSERT_EQ(43, std::stoi("42"));
}
--
After build:
$ ldd bin/test_hello
linux-vdso.so.1 (0x7ffc551ee000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f387908d000)
libstdc++.so.6 => /opt/gcc11-for-tng/lib64/libstdc++.so.6
(0x7f3878ce4000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f3878b95000)
libubsan.so.1 => /opt/gcc11-for-tng/lib64/libubsan.so.1
(0x7f387803c000)
libgcc_s.so.1 => /opt/gcc11-for-tng/lib64/libgcc_s.so.1
(0x7f3877e29000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f3877c37000)
/lib64/ld-linux-x86-64.so.2 (0x7f387933a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f3877c2f000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f3877c24000)
$ gdb bin/test_hello
...
...
Program received signal SIGSEGV, Segmentation fault.
0x76f4f555 in HandleDynamicTypeCacheMiss (Data=0x557a49a0,
Pointer=140737353637960, Hash=3327454538508686025, Opts=...)
at ../../../../gcc/libsanitizer/ubsan/ubsan_handlers_cxx.cpp:36
36 ../../../../gcc/libsanitizer/ubsan/ubsan_handlers_cxx.cpp: No such file
or directory.
...
(gdb) bt
#44921 0x76f50516 in __ubsan::checkDynamicType
(Object=Object@entry=0x77f87588 >,
Type=0x77f860b8 , Hash=8146310091054124745) at
../../../../gcc/libsanitizer/ubsan/ubsan_type_hash_itanium.cpp:233
#44922 0x76f4f55a in HandleDynamicTypeCacheMiss (Data=0x557a49a0,
Pointer=140737353643400, Hash=, Opts=...) at
../../../../gcc/libsanitizer/ubsan/ubsan_handlers_cxx.cpp:36
#44923 0x76f4fa92 in __ubsan::__ubsan_handle_dynamic_type_cache_miss
(Data=, Pointer=, Hash=) at
../../../../gcc/libsanitizer/ubsan/ubsan_handlers_cxx.cpp:87
#44924 0x5567addd in std::type_info::operator== (this=0x77f87588
>, __arg=...) at
/opt/gcc11-for-tng/include/c++/11.1.1/typeinfo:122
#44925 0x77c9beec in __cxxabiv1::__vmi_class_type_info::__do_dyncast
(this=0x77f87588 >, src2dst=0,
access_path=__cxxabiv1::__class_type_info::__contained_public,
dst_type=0x77f87588 >, obj_ptr=0x77f93e00
<(anonymous namespace)::ctype_c>, src_type=0x77f86298 , src_ptr=0x77f93e00 <(anonymous namespace)::ctype_c>,
result=...) at ../../../../gcc/libstdc++-v3/libsupc++/vmi_class_type_info.cc:91
#44926 0x77c999e9 in __cxxabiv1::__dynamic_cast (src_ptr=0x77f93e00
<(anonymous namespace)::ctype_c>, src_type=0x77f86298 , dst_type=0x77f87588 >,
src2dst=0) at ../../../../gcc/libstdc++-v3/libsupc++/dyncast.cc:74
#44927 0x77cdfd6d in std::has_facet > (__loc=...) at
/home/fiucha/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/include/bits/locale_classes.tcc:110
#44928 0x77cd6fcf in std::basic_ios
>::_M_cache_locale (this=this@entry=0x557cc988 ,
__loc=...) at
/home/fiucha/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_ios.tcc:159
#44929 0x77cd7263 in std::basic_ios
>::init (this=this@entry=0x557cc988 ,
__sb=__sb@entry=0x77f92460 <__gnu_internal::buf_cout_sync>) at
/home/fiucha/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_ios.tcc:132
#44930 0x77ce72db in std::basic_ostream
>::basic_ostream (__sb=, __vtt_parm=0x0, __in_chrg=1,
this=0x557cc980 ) at
/home/fiucha/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/include/ostream:85
#44931 std::basic_ostream >::basic_ostream
(this=0x557cc980 , __sb=0x77f92460
<__gnu_internal::buf_cout_sync>) at
/home/fiucha/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/include/ostream:85
#44932 0x77ca39c3 in std::ios_base::Init::Init (this=)
at /home/fiucha/tools/gcc/libstdc++-v3/libsupc++/new:175
#44933
[Bug sanitizer/100439] stack overflow running ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439
--- Comment #11 from Florin Iucha ---
Updated Makefile for clang12:
#---
ALL: bin/test_hello
.PHONY: clean
CXX=/opt/clang12-for-tng/bin/clang++
CXXFLAGS=-m64 -g -std=c++20 --gcc-toolchain=/opt/gcc11-for-tng
-fsanitize=undefined -fno-omit-frame-pointer
LDFLAGS=-L/opt/gcc11-for-tng/lib64 -Wl,-rpath,/opt/gcc11-for-tng/lib64
-fsanitize=undefined
GOOGLE_TEST_PATH=googletest/googletest
GOOGLE_TEST_OBJECTS=obj/gtest.o obj/gtest_main.o obj/gtest-port.o
obj/gtest-filepath.o obj/gtest-death-test.o obj/gtest-test-part.o
obj/gtest-printers.o
obj/test_hello.o: test_hello.cpp
$(CXX) $(CXXFLAGS) -o $@ -I$(GOOGLE_TEST_PATH)/include -c $<
obj/gtest.o: $(GOOGLE_TEST_PATH)/src/gtest.cc
$(CXX) $(CXXFLAGS) -o $@ -I$(GOOGLE_TEST_PATH)/include
-I$(GOOGLE_TEST_PATH) -c $<
obj/gtest%.o: $(GOOGLE_TEST_PATH)/src/gtest%.cc
$(CXX) $(CXXFLAGS) -o $@ -I$(GOOGLE_TEST_PATH)/include
-I$(GOOGLE_TEST_PATH) -c $<
bin/test_hello: obj/test_hello.o $(GOOGLE_TEST_OBJECTS)
$(CXX) -o $@ $(LDFLAGS) $^ -lpthread
clean:
$(RM) bin/test_hello obj/*.o
# -
The content of the test file:
#include
#include
TEST(Hello, World)
{
ASSERT_EQ(43, std::stoi("42"));
}
[Bug sanitizer/100439] stack overflow running ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439 --- Comment #10 from Florin Iucha --- I am able to reproduce something similar by building GCC11 from snapshot 11-20210626 (96358cbbe6e6447519a155301b6acb1624c0) and then using Clang12 (12.0.1-rc4) ubsan: #234 0x7f9769d39670 in __cxxabiv1::__si_class_type_info::__do_dyncast(long, __cxxabiv1::__class_type_info::__sub_kind, __cxxabiv1::__[0/48169] e_info const*, void const*, __cxxabiv1::__class_type_info const*, void const*, __cxxabiv1::__class_type_info::__dyncast_result&) const /home/fiuch a/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/libsupc++/../../../../gcc/libstdc++-v3/libsupc++/si_class_type_info.cc:52:13 #235 0x7f9769d379e8 in __dynamic_cast /home/fiucha/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/libsupc++/../../../../gcc/libstdc++-v3/libsu pc++/dyncast.cc:74:28 #236 0x5dd0b6 in __ubsan::checkDynamicType(void*, void*, unsigned long) /home/fiucha/tools/llvm12/compiler-rt/lib/ubsan/ubsan_type_hash_itaniu m.cpp:233:5 #237 0x5dbf11 in HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*, unsigned long, unsigned long, __ubsan::ReportOptions) /home/fiucha/tools/llvm12/compiler-rt/lib/ubsan/ubsan_handlers_cxx.cpp:36:7 #238 0x5dbee9 in __ubsan_handle_dynamic_type_cache_miss /home/fiucha/tools/llvm12/compiler-rt/lib/ubsan/ubsan_handlers_cxx.cpp:87:3 #239 0x60b931 in std::type_info::operator==(std::type_info const&) const /opt/gcc11-for-tng/lib/gcc/x86_64-linux-gnu/11.1.1/../../../../include/c++/11.1.1/typeinfo:122:16 #240 0x7f9769d39670 in __cxxabiv1::__si_class_type_info::__do_dyncast(long, __cxxabiv1::__class_type_info::__sub_kind, __cxxabiv1::__class_type_info const*, void const*, __cxxabiv1::__class_type_info const*, void const*, __cxxabiv1::__class_type_info::__dyncast_result&) const /home/fiucha/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/libsupc++/../../../../gcc/libstdc++-v3/libsupc++/si_class_type_info.cc:52:13 #241 0x7f9769d379e8 in __dynamic_cast /home/fiucha/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/libsupc++/../../../../gcc/libstdc++-v3/libsu pc++/dyncast.cc:74:28 #242 0x5dd0b6 in __ubsan::checkDynamicType(void*, void*, unsigned long) /home/fiucha/tools/llvm12/compiler-rt/lib/ubsan/ubsan_type_hash_itaniu m.cpp:233:5 #243 0x5dbf11 in HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*, unsigned long, unsigned long, __ubsan::ReportOptions) /home/fi ucha/tools/llvm12/compiler-rt/lib/ubsan/ubsan_handlers_cxx.cpp:36:7 #244 0x5dbee9 in __ubsan_handle_dynamic_type_cache_miss /home/fiucha/tools/llvm12/compiler-rt/lib/ubsan/ubsan_handlers_cxx.cpp:87:3 #245 0x60b931 in std::type_info::operator==(std::type_info const&) const /opt/gcc11-for-tng/lib/gcc/x86_64-linux-gnu/11.1.1/../../../../includ e/c++/11.1.1/typeinfo:122:16 #246 0x7f9769d39670 in __cxxabiv1::__si_class_type_info::__do_dyncast(long, __cxxabiv1::__class_type_info::__sub_kind, __cxxabiv1::__class_typ e_info const*, void const*, __cxxabiv1::__class_type_info const*, void const*, __cxxabiv1::__class_type_info::__dyncast_result&) const /home/fiuch a/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/libsupc++/../../../../gcc/libstdc++-v3/libsupc++/si_class_type_info.cc:52:13 #247 0x7f9769d379e8 in __dynamic_cast /home/fiucha/tools/gcc.objdir/x86_64-linux-gnu/libstdc++-v3/libsupc++/../../../../gcc/libstdc++-v3/libsu pc++/dyncast.cc:74:28 #248 0x5dd0b6 in __ubsan::checkDynamicType(void*, void*, unsigned long) /home/fiucha/tools/llvm12/compiler-rt/lib/ubsan/ubsan_type_hash_itaniu m.cpp:233:5 #249 0x5dbf11 in HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*, unsigned long, unsigned long, __ubsan::ReportOptions) /home/fi ucha/tools/llvm12/compiler-rt/lib/ubsan/ubsan_handlers_cxx.cpp:36:7 SUMMARY: AddressSanitizer: stack-overflow /home/fiucha/tools/llvm12/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cpp:278 in __sanitize r::IsAccessibleMemoryRange(unsigned long, unsigned long) ==2162813==ABORTING This doesn't fail on a simple hello_ub.cpp example - but on a complex module using Google test, again.
[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101223 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #12 from Andrew Macleod --- Fixed.
[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101223 --- Comment #11 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:84f7bab89279ca1234fef88929c74caeda8cb55e commit r12-1986-g84f7bab89279ca1234fef88929c74caeda8cb55e Author: Andrew MacLeod Date: Wed Jun 30 14:15:53 2021 -0400 Fix build_gt and build_lt for signed 1 bit values. Signed 1 bit values have a range of [-1, 0] but neither (0 - 1) nor (-1 + 1) can be represented. For signed values, add or subtract -1 as appropriate. PR tree-optimization/101223 gcc/ * range-op.cc (build_lt): Add -1 for signed values. (built_gt): Subtract -1 for signed values. gcc/testsuite/ * gcc.dg/pr101223.c: New.
[Bug tree-optimization/101301] New: Improving sparse switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101301
Bug ID: 101301
Summary: Improving sparse switch statement
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The following two functions do the same thing:
int foo(int x)
{
switch (x) {
case 1: return 1;
case 2: return 2;
case 3: return 3;
case 4: return 4;
case 5: return 5;
case 6: return 6;
case 7: return 7;
case 8: return 8;
case 9: return 9;
default: return 0;
}
}
int foo2(int n)
{
if (n >= 5)
{
if (n >= 7)
{
if (n == 7)
return 7;
if (n == 8)
return 8;
if (n == 9)
return 9;
return 0;
}
else
{
if (n == 5)
return 5;
if (n == 6)
return 6;
return 0;
}
}
else
{
if (n >= 3)
{
if (n == 3)
return 3;
if (n == 4)
return 4;
return 0;
}
else
{
if (n == 1)
return 1;
if (n == 2)
return 2;
return 0;
}
}
}
but foo2 is translated into code with fewer conditional branches
on average. Considering how expensive a mispredicted branch
can be, translating foo like foo2 could be an improvement.
[Bug middle-end/101294] [12 Regression] ICE: in maybe_legitimize_operand, at optabs.c:7614 with -mavx since r12-1958-gedafb35bdadf309e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101294
--- Comment #4 from rguenther at suse dot de ---
On July 2, 2021 4:03:34 PM GMT+02:00, "hjl.tools at gmail dot com"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101294
>
>--- Comment #3 from H.J. Lu ---
>This works:
>
>diff --git a/gcc/expr.c b/gcc/expr.c
>index 025033c9ecf..bd85bbfdd6f 100644
>--- a/gcc/expr.c
>+++ b/gcc/expr.c
>@@ -7078,7 +7078,8 @@ store_constructor (tree exp, rtx target, int
>cleared,
>poly_int64 size,
> && eltmode == GET_MODE_INNER (mode)
> && ((icode = optab_handler (vec_duplicate_optab, mode))
> != CODE_FOR_nothing)
>- && (elt = uniform_vector_p (exp)))
>+ && (elt = uniform_vector_p (exp))
>+ && !VECTOR_TYPE_P (TREE_TYPE (elt)))
> {
> class expand_operand ops[2];
> create_output_operand ([0], target, mode);
I guess that's reasonable.
[Bug debug/101283] Several tests fail on Darwin with -gctf/gbtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283 --- Comment #9 from Iain Sandoe --- (In reply to Iain Sandoe from comment #8) > we are now left with (where I suspect that the remaining fails are an > artefact of the way in which Darwin represents offsets instead of > relocations in DWARF debug sections): on a bit more looking, that is probably not the reason - I guess we will have to look at what the represented structures are and why they have different renderings for Darwin.
[Bug target/97827] bootstrap error building the amdgcn-amdhsa offload compiler with LLVM 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97827 Andrew Stubbs changed: What|Removed |Added CC||xw111luoye at gmail dot com --- Comment #17 from Andrew Stubbs --- *** Bug 95023 has been marked as a duplicate of this bug. ***
[Bug target/95023] Offloading AMD GCN wiki cannot be followed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95023 Andrew Stubbs changed: What|Removed |Added CC||ams at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Stubbs --- The second problem in this bug is reported in 97827. *** This bug has been marked as a duplicate of bug 97827 ***
[Bug sanitizer/101300] New: -fsanitize=undefined suppresses -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101300
Bug ID: 101300
Summary: -fsanitize=undefined suppresses -Wuninitialized
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: llvm at rifkin dot dev
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
The following code should produce a Wuninitialized warning.
int foo() {
int n = 4;
char b[n];
return b[2];
}
The compiler identifies the uninitialized access when compiled -Wall however it
does not when compiled with -Wall -fsanitize=undefined.
It does warn properly when compiled with -Wall -fsanitize=undefined -O1 (or any
optimization flag other than -O0).
https://godbolt.org/z/4rrKK5MYj
[Bug middle-end/101292] [12 Regression] recent valgrind error in warning-control.cc since r12-1804-g65870e75616ee4359d1c13b99be794e6a577bc65
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101292 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101204 --- Comment #4 from Martin Sebor --- Looks like the garbage collection markups either aren't correct for the hash_map the code uses or aren't working correctly despite r12-1096. The problem might be related to pr101204.
[Bug debug/101283] Several tests fail on Darwin with -gctf/gbtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283 --- Comment #8 from Iain Sandoe --- we are now left with (where I suspect that the remaining fails are an artefact of the way in which Darwin represents offsets instead of relocations in DWARF debug sections): Running target unix/-m64 Running /src-local/gcc-master/gcc/testsuite/gcc.dg/debug/btf/btf.exp ... FAIL: gcc.dg/debug/btf/btf-bitfields-1.c scan-assembler-times [\t ]0xa20[\t ]+[^\n]*btm_offset 1 FAIL: gcc.dg/debug/btf/btf-bitfields-1.c scan-assembler-times [\t ]0x72a[\t ]+[^\n]*btm_offset 1 FAIL: gcc.dg/debug/btf/btf-bitfields-1.c scan-assembler-times [\t ]0x1340[\t ]+[^\n]*btm_offset 1 FAIL: gcc.dg/debug/btf/btf-bitfields-2.c scan-assembler-times [\t ]0x2020[\t ]+[^\n]*btm_offset 1 FAIL: gcc.dg/debug/btf/btf-bitfields-3.c scan-assembler-times [\t ]0x2[\t ]+[^\n]*btm_type 1 FAIL: gcc.dg/debug/btf/btf-bitfields-4.c scan-assembler-times [\t ]0x403[\t ]+[^\n]*btt_info 1 FAIL: gcc.dg/debug/btf/btf-cvr-quals-1.c scan-assembler-times [\t ]0xb00[\t ]+[^\n]*btt_info 2 Running /src-local/gcc-master/gcc/testsuite/gcc.dg/debug/ctf/ctf.exp ... FAIL: gcc.dg/debug/ctf/ctf-attr-mode-1.c scan-assembler-times [\t ]0x3[\t ]+[^\n]*ctv_typeidx 1 FAIL: gcc.dg/debug/ctf/ctf-cvr-quals-1.c scan-assembler-times [\t ]0[\t ]+[^\n]*ctt_name 7 FAIL: gcc.dg/debug/ctf/ctf-cvr-quals-1.c scan-assembler-times [\t ]0x3600[\t ]+[^\n]*ctt_info 2 Running /src-local/gcc-master/gcc/testsuite/gcc.dg/debug/debug.exp ... === gcc Summary for unix/-m64 === # of expected passes1214 # of unexpected failures10 # of unsupported tests 24 Running target unix/-m32 Running /src-local/gcc-master/gcc/testsuite/gcc.dg/debug/btf/btf.exp ... FAIL: gcc.dg/debug/btf/btf-bitfields-1.c scan-assembler-times [\t ]0xa20[\t ]+[^\n]*btm_offset 1 FAIL: gcc.dg/debug/btf/btf-bitfields-1.c scan-assembler-times [\t ]0x72a[\t ]+[^\n]*btm_offset 1 FAIL: gcc.dg/debug/btf/btf-bitfields-1.c scan-assembler-times [\t ]0x1340[\t ]+[^\n]*btm_offset 1 FAIL: gcc.dg/debug/btf/btf-bitfields-2.c scan-assembler-times [\t ]0x2020[\t ]+[^\n]*btm_offset 1 FAIL: gcc.dg/debug/btf/btf-bitfields-3.c scan-assembler-times [\t ]0x2[\t ]+[^\n]*btm_type 1 FAIL: gcc.dg/debug/btf/btf-bitfields-4.c scan-assembler-times [\t ]0x403[\t ]+[^\n]*btt_info 1 FAIL: gcc.dg/debug/btf/btf-cvr-quals-1.c scan-assembler-times [\t ]0xb00[\t ]+[^\n]*btt_info 2 Running /src-local/gcc-master/gcc/testsuite/gcc.dg/debug/ctf/ctf.exp ... FAIL: gcc.dg/debug/ctf/ctf-attr-mode-1.c scan-assembler-times [\t ]0x3[\t ]+[^\n]*ctv_typeidx 1 FAIL: gcc.dg/debug/ctf/ctf-cvr-quals-1.c scan-assembler-times [\t ]0[\t ]+[^\n]*ctt_name 7 FAIL: gcc.dg/debug/ctf/ctf-cvr-quals-1.c scan-assembler-times [\t ]0x3600[\t ]+[^\n]*ctt_info 2 Running /src-local/gcc-master/gcc/testsuite/gcc.dg/debug/debug.exp ... === gcc Summary for unix/-m32 === # of expected passes1214 # of unexpected failures10 # of unsupported tests 24 === gcc Summary === # of expected passes2428 # of unexpected failures20 # of unsupported tests 48
[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 --- Comment #18 from sandra at gcc dot gnu.org --- The short answer re the TS 29113 thing is that it's what the customer who's funding the work asked us to do. :-)
[Bug debug/101283] Several tests fail on Darwin with -gctf/gbtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283 --- Comment #7 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:85017431068251628478f38346c273418c71209b commit r12-1983-g85017431068251628478f38346c273418c71209b Author: Iain Sandoe Date: Fri Jul 2 09:51:57 2021 +0100 Darwin, CTF, BTF: Do not run the DWARF debug link for BTF/CTF [PR101283]. Darwin uses an efficient two-stage process for debug linking. The static linker (ld64) notes the inputs required but does not link the debug. When required / on demand the debug is linked into a separate package by the debug linker (dsymutil). At present none of the Darwin tools consume or understand BTF/CTF. The static linker silently accepts the sections (but will not act on them as containing anything to be processed). However, the debug linker produces a warning that it has been presented with input with no [DWARF] debug content: warning: no debug symbols in executable (-arch x86_64). This causes several testsuite fails with excess errors. Signed-off-by: Iain Sandoe PR debug/101283 - Several tests fail on Darwin with -gctf/gbtf PR debug/101283 gcc/ChangeLog: * config/darwin.h (DSYMUTIL_SPEC): Do not try to run dsymutil for BTF/CTF.
[Bug debug/101283] Several tests fail on Darwin with -gctf/gbtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283 --- Comment #6 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:eb817f27e82769aef545d580a0c47a3aa50d1ec4 commit r12-1982-geb817f27e82769aef545d580a0c47a3aa50d1ec4 Author: Iain Sandoe Date: Fri Jul 2 09:44:59 2021 +0100 Darwin, BTF: Provide a suitable section name for BTF [PR101283]. In a similar manner to r12-1960-gcc8453012f75d, this provides a placeholder section name for BTF data. This change groups BTF and CTF debug formats in the same segment, but keeps them in separate sections. As per the CTF section designation, this should be agreed or amended to an agreed form before GCC 12 ships. Signed-off-by: Iain Sandoe PR debug/101283 - Several tests fail on Darwin with -gctf/gbtf PR debug/101283 gcc/ChangeLog: * config/darwin.h (CTF_INFO_SECTION_NAME): Update the segment to include BTF. (BTF_INFO_SECTION_NAME): New.
[Bug testsuite/101299] New: bb-slp-74.c fails on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101299 Bug ID: 101299 Summary: bb-slp-74.c fails on arm Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- The test added with r12-1949 fails on arm: gcc.dg/vect/bb-slp-74.c: pattern found 0 times FAIL: gcc.dg/vect/bb-slp-74.c scan-tree-dump-times slp2 " [^ ]+ = VEC_PERM_EXPR" 1 gcc.dg/vect/bb-slp-74.c -flto -ffat-lto-objects : pattern found 0 times FAIL: gcc.dg/vect/bb-slp-74.c -flto -ffat-lto-objects scan-tree-dump-times slp2 " [^ ]+ = VEC_PERM_EXPR" 1
[Bug middle-end/101294] [12 Regression] ICE: in maybe_legitimize_operand, at optabs.c:7614 with -mavx since r12-1958-gedafb35bdadf309e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101294
--- Comment #3 from H.J. Lu ---
This works:
diff --git a/gcc/expr.c b/gcc/expr.c
index 025033c9ecf..bd85bbfdd6f 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -7078,7 +7078,8 @@ store_constructor (tree exp, rtx target, int cleared,
poly_int64 size,
&& eltmode == GET_MODE_INNER (mode)
&& ((icode = optab_handler (vec_duplicate_optab, mode))
!= CODE_FOR_nothing)
- && (elt = uniform_vector_p (exp)))
+ && (elt = uniform_vector_p (exp))
+ && !VECTOR_TYPE_P (TREE_TYPE (elt)))
{
class expand_operand ops[2];
create_output_operand ([0], target, mode);
[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101223 --- Comment #10 from rsandifo at gcc dot gnu.org --- > How can one write 0 - 1 in 1-bit signed though? 1 isn't in the range... > One can only do 0 + -1 which doesn't overflow, or 0 - -1 which does. Ah, yeah, of course. So the issue that 1 doesn't even exist as a representation for 1-bit signed. Sorry for the noise…
[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101223 --- Comment #9 from Jakub Jelinek --- (In reply to rsand...@gcc.gnu.org from comment #8) > (In reply to Andrew Macleod from comment #7) > > wi::sub sets the overflow flag for 0 - 1 with 1 bit signed... so the > > comparison ends up being undefined, and we then make incorrect choices > > because we think we can. > Isn't that a bug in wi::sub though? I think we should fix it rather > than work around it in callers. How can one write 0 - 1 in 1-bit signed though? 1 isn't in the range... One can only do 0 + -1 which doesn't overflow, or 0 - -1 which does.
[Bug preprocessor/101298] New: Inclusion of a file without trailing newline breaks -fdirectives-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101298 Bug ID: 101298 Summary: Inclusion of a file without trailing newline breaks -fdirectives-only Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: boris at kolpackov dot net Target Milestone: --- cattest.hxx g++ -E -fdirectives-only -o test.ii test.cxx In file included from test.cxx:1: test.hxx:1:1: error: unterminated comment echo -n "void f () {}" >test.hxx g++ -E -fdirectives-only -o test.ii test.cxx grep "void f () {}" test.ii void f () {}# 2 "test.cxx" 2 g++ -c -fdirectives-only test.ii In file included from test.cxx:1: test.hxx:1:13: error: stray ‘#’ in program This used to work fine prior to GCC 11. I believe this issue is similar but not the same as bug #100646.
[Bug middle-end/101294] [12 Regression] ICE: in maybe_legitimize_operand, at optabs.c:7614 with -mavx since r12-1958-gedafb35bdadf309e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101294
H.J. Lu changed:
What|Removed |Added
Component|target |middle-end
--- Comment #2 from H.J. Lu ---
The bug is latent before r12-1958. store_constructor has
/* Try using vec_duplicate_optab for uniform vectors. */
if (!TREE_SIDE_EFFECTS (exp)
&& VECTOR_MODE_P (mode)
&& eltmode == GET_MODE_INNER (mode)
&& ((icode = optab_handler (vec_duplicate_optab, mode))
!= CODE_FOR_nothing)
&& (elt = uniform_vector_p (exp)))
{
class expand_operand ops[2];
create_output_operand ([0], target, mode);
create_input_operand ([1], expand_normal (elt), eltmode);
expand_insn (icode, 2, ops);
if (!rtx_equal_p (target, ops[0].value))
emit_move_insn (target, ops[0].value);
break;
}
(gdb) call debug_tree (exp)
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea0f1930 precision:64 min max
pointer_to_this >
unsigned V4DI
size
unit-size
align:256 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea22ab28 nunits:4 context >
constant length:4
val
unsigned V1DI size unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea22a9d8 nunits:1 context >
constant npatterns:1 nelts-per-pattern:1
elt:0: >
val
constant npatterns:1 nelts-per-pattern:1 elt:0: >
val
constant npatterns:1 nelts-per-pattern:1 elt:0: >
val
constant npatterns:1 nelts-per-pattern:1 elt:0: >>
(gdb) call debug_tree (elt)
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea0f1930 precision:64 min max
pointer_to_this >
unsigned V1DI size unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea22a9d8 nunits:1 context >
constant npatterns:1 nelts-per-pattern:1
elt:0: constant 0>>
(gdb) p eltmode
$11 = E_DImode
(gdb)
DImode != V1DImode.
[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101223 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #8 from rsandifo at gcc dot gnu.org --- (In reply to Andrew Macleod from comment #7) > wi::sub sets the overflow flag for 0 - 1 with 1 bit signed... so the > comparison ends up being undefined, and we then make incorrect choices > because we think we can. Isn't that a bug in wi::sub though? I think we should fix it rather than work around it in callers.
[Bug c/101297] Spurious comma accepted at the end of #pragma omp atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101297 --- Comment #1 from Jakub Jelinek --- Created attachment 51102 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51102=edit gcc12-pr101297.patch Untested fix.
[Bug target/101296] Addition of x86 addsub SLP patterned slowed down 433.milc by 12% on znver2 with -Ofast -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101296
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Last reconfirmed||2021-07-02
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Richard Biener ---
I will have a look next week. A quick look shows FMAs being used and addsub
can break FMA detection until we get general optab support for fmaddsub
and friends. So it might be { fma, fms } + blend compared to addsub + mul
where the former maybe has lower latency though Agner says FMA (5c) + blend
(1c)
vs ADDSUB (3c) + MUL (3c). As said, I have to look into this in more detail.
double a[4], b[4], c[4];
void foo ()
{
c[0] = a[0] - b[0] * c[0];
c[1] = a[1] + b[1] * c[1];
c[2] = a[2] - b[2] * c[2];
c[3] = a[3] + b[3] * c[3];
}
vmovapd a(%rip), %ymm2
vmovapd b(%rip), %ymm1
vmovapd b(%rip), %ymm0
vfmadd132pd c(%rip), %ymm2, %ymm1
vfnmadd132pdc(%rip), %ymm2, %ymm0
vshufpd $10, %ymm1, %ymm0, %ymm0
vmovapd %ymm0, c(%rip)
vs.
vmovapd b(%rip), %ymm1
vmovapd a(%rip), %ymm2
vmulpd c(%rip), %ymm1, %ymm0
vaddsubpd %ymm0, %ymm2, %ymm0
vmovapd %ymm0, c(%rip)
[Bug c/101297] Spurious comma accepted at the end of #pragma omp atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101297 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-07-02 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug c/101297] New: Spurious comma accepted at the end of #pragma omp atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101297
Bug ID: 101297
Summary: Spurious comma accepted at the end of #pragma omp
atomic
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
int i;
void
foo (void)
{
#pragma omp atomic update,/* { dg-error "expected end of line before ','
token" } */
i++;
#pragma omp atomic update,, /* { dg-error "expected end of line before ','
token" } */
i++;
}
diagnoses with -fopenmp only the second error and not the first one (seems both
clang and ICC suffer from the same bug though).
[Bug target/101296] New: Addition of x86 addsub SLP patterned slowed down 433.milc by 12% on znver2 with -Ofast -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101296 Bug ID: 101296 Summary: Addition of x86 addsub SLP patterned slowed down 433.milc by 12% on znver2 with -Ofast -flto Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux Target: x86_64-linux Commit g:7a6c31f0f84 (Add x86 addsub SLP pattern) has slowed down 433.milc from SPECFP 2006 by 12% on a znver2 based machine when compiled with -Ofast -flto -march=native. Note however that the master branch has afterwards recovered some of these losses and today's bc8f0ed7042 is only 6% slower than what it was before the addsub addition. Nevertheless, this effect of this particular change may be worth looking at. LNT tracking graph is available for example here: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=289.70.0
[Bug libstdc++/101274] [11/12 Regression] std::execution::seq has incorrect behaviour under GCC 11.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101274 --- Comment #5 from yhf8377 --- Thank you Thomas for the detailed information and links to the references. I guess I will need to move this bug report into our own bug tracker. :-) This is indeed a bug in our code as we had incorrect assumptions on how `std::reduce()` and `std::execution::seq` work. Thanks again!
[Bug tree-optimization/99728] code pessimization when using wrapper classes around SIMD types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728 Bug 99728 depends on bug 101293, which changed state. Bug 101293 Summary: LIM ref canonicalization incomplete https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101293 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/101293] LIM ref canonicalization incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101293 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Richard Biener --- Fixed.
[Bug tree-optimization/101293] LIM ref canonicalization incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101293 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:4546f423ecff96f223adfbec4963d2ff17f27c7b commit r12-1977-g4546f423ecff96f223adfbec4963d2ff17f27c7b Author: Richard Biener Date: Fri Jul 2 12:57:06 2021 +0200 tree-optimization/101293 - further enhance LIMs ref canonicalization This makes sure to handle MEM[p + 4] and MEM[p].j with j at offset 4 as the same ref in store motion. For hashing we need to be more restrictive in what we handle since there's no poly-int handlers for inchash. For comparison we can compare poly_offsets directly. 2021-07-02 Richard Biener PR tree-optimization/101293 * tree-ssa-loop-im.c (mem_ref_hasher::equal): Compare MEM_REF bases with combined offsets. (gather_mem_refs_stmt): Hash MEM_REFs as if their offset were combined with the rest of the offset. * gcc.dg/tree-ssa/ssa-lim-15.c: New testcase.
[Bug tree-optimization/100778] [11 Regression] Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100778 --- Comment #13 from Gabrielle Hugo --- >Yes, we're usually waiting a bit to see if fallout is detected by >autotesters before backporting to release branches. Oki thanks!
[Bug tree-optimization/100778] [11 Regression] Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100778 --- Comment #12 from rguenther at suse dot de --- On Fri, 2 Jul 2021, gabrielle.hugo at cern dot ch wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100778 > > --- Comment #11 from Gabrielle Hugo --- > Awesome, thanks a lot Richard! > > > Applying your patch in tree-vect-slp.c to gcc 11, I now get the vectorized > division divpd after the if as expected: > > if (norm .gt. 1.D+00) then > 400826: 76 7b jbe4008a3 > 400828: 66 0f 28 d0 movapd %xmm0,%xmm2 > x = x / norm > y = y / norm > write (*, '(A,F5.3)') 'Normalized x and y.', norm > 40082c: 48 8b 05 c5 01 00 00mov0x1c5(%rip),%rax# > 4009f8 > > 400833: 48 8d 6c 24 10 lea0x10(%rsp),%rbp > 400838: 48 c7 44 24 18 78 09movq $0x400978,0x18(%rsp) > 40083f: 40 00 > 400841: 66 0f 14 d2 unpcklpd %xmm2,%xmm2 > 400845: 48 89 efmov%rbp,%rdi > 400848: c7 44 24 20 1d 00 00movl $0x1d,0x20(%rsp) > 40084f: 00 > x = x / norm > 400850: 66 0f 5e ca divpd %xmm2,%xmm1 > > > So if I understand correctly the fix in SLP vectorization > (is_a (vinfo)), > when there are possibly trapping operations > (gimple_could_trap_p (stmt_info->stmt)), > is to explicitely constrain them to come from the same BB > (special handling when gimple_bb (last_stmt) != gimple_bb (stmt_info->stmt) ). Yes. > Do I understand correctly that trunk is basically gcc 12.0, which will > eventually end up being released as gcc 12.1 ? Yes. > What about gcc 11, will this fix also make its way to the next gcc 11 release? Yes, we're usually waiting a bit to see if fallout is detected by autotesters before backporting to release branches.
[Bug libstdc++/101271] [12 Regression] error: ‘static constexpr decltype ... used before its definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101271 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jonathan Wakely --- Should be fixed
[Bug libstdc++/101236] [12 Regression] bits/unique_ptr.h:658:48: error: invalid use of incomplete type ‘class llvm::APFloat’ since r12-1778-g17bc3848e065c0980523e1a1592f2f03b24b4f1c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101236 --- Comment #8 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:bc8f0ed7042280282035168428f6afc839997cf0 commit r12-1976-gbc8f0ed7042280282035168428f6afc839997cf0 Author: Jonathan Wakely Date: Fri Jul 2 08:46:18 2021 +0100 libstdc++: Revert changes to std::unique_ptr::operator[] [PR 101271] This reverts the changes in r12-1778 which added a noexcept-specifier to std::unique_ptr::operator[], and the changes in r12-1844 which tried to make it work with incomplete types (for PR 101236). The noexcept-specifier is not required by the standard, and is causing regressions, so just remove it. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/101271 * include/bits/unique_ptr.h (unique_ptr::operator[]): Remove noexcept-specifier. (unique_ptr::_S_nothrow_deref): Remove. * testsuite/20_util/unique_ptr/lwg2762.cc: Remove checks for operator[].
[Bug libstdc++/101271] [12 Regression] error: ‘static constexpr decltype ... used before its definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101271 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:bc8f0ed7042280282035168428f6afc839997cf0 commit r12-1976-gbc8f0ed7042280282035168428f6afc839997cf0 Author: Jonathan Wakely Date: Fri Jul 2 08:46:18 2021 +0100 libstdc++: Revert changes to std::unique_ptr::operator[] [PR 101271] This reverts the changes in r12-1778 which added a noexcept-specifier to std::unique_ptr::operator[], and the changes in r12-1844 which tried to make it work with incomplete types (for PR 101236). The noexcept-specifier is not required by the standard, and is causing regressions, so just remove it. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/101271 * include/bits/unique_ptr.h (unique_ptr::operator[]): Remove noexcept-specifier. (unique_ptr::_S_nothrow_deref): Remove. * testsuite/20_util/unique_ptr/lwg2762.cc: Remove checks for operator[].
[Bug target/101294] [12 Regression] ICE: in maybe_legitimize_operand, at optabs.c:7614 with -mavx since r12-1958-gedafb35bdadf309e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101294 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug tree-optimization/100778] [11 Regression] Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100778 --- Comment #11 from Gabrielle Hugo --- Awesome, thanks a lot Richard! Applying your patch in tree-vect-slp.c to gcc 11, I now get the vectorized division divpd after the if as expected: if (norm .gt. 1.D+00) then 400826: 76 7b jbe4008a3 400828: 66 0f 28 d0 movapd %xmm0,%xmm2 x = x / norm y = y / norm write (*, '(A,F5.3)') 'Normalized x and y.', norm 40082c: 48 8b 05 c5 01 00 00mov0x1c5(%rip),%rax# 4009f8 400833: 48 8d 6c 24 10 lea0x10(%rsp),%rbp 400838: 48 c7 44 24 18 78 09movq $0x400978,0x18(%rsp) 40083f: 40 00 400841: 66 0f 14 d2 unpcklpd %xmm2,%xmm2 400845: 48 89 efmov%rbp,%rdi 400848: c7 44 24 20 1d 00 00movl $0x1d,0x20(%rsp) 40084f: 00 x = x / norm 400850: 66 0f 5e ca divpd %xmm2,%xmm1 So if I understand correctly the fix in SLP vectorization (is_a (vinfo)), when there are possibly trapping operations (gimple_could_trap_p (stmt_info->stmt)), is to explicitely constrain them to come from the same BB (special handling when gimple_bb (last_stmt) != gimple_bb (stmt_info->stmt) ). Do I understand correctly that trunk is basically gcc 12.0, which will eventually end up being released as gcc 12.1 ? What about gcc 11, will this fix also make its way to the next gcc 11 release?
[Bug tree-optimization/99728] code pessimization when using wrapper classes around SIMD types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728 --- Comment #14 from Richard Biener --- With the hack and PR101293 fixed we're still left with Memory reference 13: *d_28(D).lam1.v Memory reference 14: VIEW_CONVERT_EXPR(*d_28(D).lam1) because the access types are incompatible (v4df vs v32qi). Possible to hack around but the initial hack creating the V_C_E has issues enough (though handling the aggregate copy in LIM will inevitably run into incomaptible types compared to other refs as well). How I love the fun of C++ and all the abstraction when using it ... :/
[Bug target/101294] [12 Regression] ICE: in maybe_legitimize_operand, at optabs.c:7614 with -mavx since r12-1958-gedafb35bdadf309e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101294 Martin Liška changed: What|Removed |Added CC||hjl at gcc dot gnu.org, ||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Summary|[12 Regression] ICE: in |[12 Regression] ICE: in |maybe_legitimize_operand, |maybe_legitimize_operand, |at optabs.c:7614 with -mavx |at optabs.c:7614 with -mavx ||since ||r12-1958-gedafb35bdadf309e Last reconfirmed||2021-07-02 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r12-1958-gedafb35bdadf309e.
[Bug c++/101295] New: constexpr destructor: ''result_decl' not supported by dump_expr' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101295
Bug ID: 101295
Summary: constexpr destructor: ''result_decl' not supported by
dump_expr' is not a constant
expression
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: markus.kuehni at triviso dot ch
Target Milestone: ---
Trying to conceptualize a constexpr capable, optimizer friendly linked list
reference tracking smart pointer, I get this error:
: In function 'int main()':
:49:16: in 'constexpr' expansion of 'test()'
:49:16: in 'constexpr' expansion of
'(&)->myptr::~myptr()'
:49:16: error: ''result_decl' not supported by dump_expr' is not a constant expression
49 | return test();
...
I'm not sure whether the code is standards compliant, but the error message is
broken anyway, it seems.
The same code works as I expect on clang, but creates an ICE on msvc. I tried
to create a minimal example that still shows the intention of the code.
https://godbolt.org/z/sod6oYE8T
```
// Minimized code of a linked list reference tracking smart pointer.
template
struct myptr {
private:
T * p;
myptr * next;
public:
constexpr myptr(T * p) noexcept : p(p), next(p ? p->first : nullptr) {
if (p) {
p->first = this;
}
}
constexpr myptr(const myptr & other) noexcept : myptr(other.p) {}
constexpr ~myptr() noexcept {
if (p) {
myptr ** pnext = &(p->first);
while (*pnext != this) {
pnext = &((*pnext)->next);
}
*pnext = next;
next = nullptr;
if (!p->first) {
delete p;
}
p = nullptr;
}
}
};
struct Obj {
private:
struct myptr * first{};
friend struct myptr;
};
constexpr myptr fun() {
myptr obj(new Obj);
return obj;
}
// Force consteval to prove the myptr is constexpr capable.
consteval int test() {
fun();
return 42;
}
int main() {
return test();
}
```
[Bug target/101294] New: [12 Regression] ICE: in maybe_legitimize_operand, at optabs.c:7614 with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101294
Bug ID: 101294
Summary: [12 Regression] ICE: in maybe_legitimize_operand, at
optabs.c:7614 with -mavx
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 51101
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51101=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -mavx testcase.c
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:7:3: internal compiler error: in maybe_legitimize_operand, at
optabs.c:7614
7 | __builtin_shufflevector ((U){}, (V){}, 3);
| ^~~
0x6f80cd maybe_legitimize_operand
/repo/gcc-trunk/gcc/optabs.c:7614
0x6f80cd maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
/repo/gcc-trunk/gcc/optabs.c:7751
0xf562c9 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
/repo/gcc-trunk/gcc/optabs.c:7770
0xf63f68 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/repo/gcc-trunk/gcc/optabs.c:7813
0xf63f68 expand_insn(insn_code, unsigned int, expand_operand*)
/repo/gcc-trunk/gcc/optabs.c:7844
0xcfc2ab store_constructor
/repo/gcc-trunk/gcc/expr.c:7086
0xcfd995 expand_constructor
/repo/gcc-trunk/gcc/expr.c:8563
0xce9e8a expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/repo/gcc-trunk/gcc/expr.c:10748
0xcf71cc store_expr(tree_node*, rtx_def*, int, bool, bool)
/repo/gcc-trunk/gcc/expr.c:5994
0xcf898d expand_assignment(tree_node*, tree_node*, bool)
/repo/gcc-trunk/gcc/expr.c:5729
0xbb1377 expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.c:3943
0xbb1377 expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.c:4041
0xbb7b8b expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.c:6083
0xbb9ab7 execute
/repo/gcc-trunk/gcc/cfgexpand.c:6809
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-1975-20210702102426-g496e1d6a1f9-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-1975-20210702102426-g496e1d6a1f9-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210702 (experimental) (GCC)
[Bug tree-optimization/101293] LIM ref canonicalization incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101293 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2021-07-02 Ever confirmed|0 |1 Keywords||missed-optimization Status|UNCONFIRMED |ASSIGNED Blocks||99728 --- Comment #1 from Richard Biener --- Mine. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728 [Bug 99728] code pessimization when using wrapper classes around SIMD types
[Bug tree-optimization/101293] New: LIM ref canonicalization incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101293
Bug ID: 101293
Summary: LIM ref canonicalization incomplete
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
We fail to apply store-motion to
struct X { int i; int j; };
void foo(struct X *x, int n)
{
for (int i = 0; i < n; ++i)
{
int *p = >j;
int tem = *p;
x->j += tem * i;
}
}
because we end up with two distinct memory references:
Memory reference 1: MEM[(int *)x_7(D) + 4B]
Memory reference 2: x_7(D)->j
[Bug tree-optimization/99728] code pessimization when using wrapper classes around SIMD types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug tree-optimization/99728] code pessimization when using wrapper classes around SIMD types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728 --- Comment #13 from Richard Biener --- Created attachment 51100 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51100=edit hack The attached tries to rewrite the aggregate assignments into a load/store sequence producing _33 = VIEW_CONVERT_EXPR(d_42(D)->lam2D.32702); VIEW_CONVERT_EXPR(d_42(D)->lam1D.32701) = _33; from originally d_42(D)->lam1D.32701 = d_42(D)->lam2D.32702; that's a bit ugly but still falls short of doing the full store-motion but at least now moves all but the above store: ... _35 = _36 + val$v_63; _30 = VIEW_CONVERT_EXPR(_56); VIEW_CONVERT_EXPR(*d_28(D).lam1D.32701) = _30; *d_28(D).lam2D.32702.vD.32579 = _35; il_33 = il_69 + 1; l_34 = l_68 + 2; if (lmax_26(D) >= l_34) goto ; [89.00%] else goto ; [11.00%] [local count: 850510901]: goto ; [100.00%] [local count: 105119324]: # _84 = PHI <_30(3)> # _85 = PHI <_35(3)> # d__v_lsm.37_86 = PHI # d__v_lsm.38_87 = PHI # d__v_lsm.39_88 = PHI # d__v_lsm.40_89 = PHI MEM[(struct TvsimpleD.32577 *)d_28(D) + 192B].vD.32579 = d__v_lsm.37_86; MEM[(struct TvsimpleD.32577 *)d_28(D) + 224B].vD.32579 = d__v_lsm.38_87; MEM[(struct TvsimpleD.32577 *)d_28(D) + 256B].vD.32579 = d__v_lsm.39_88; MEM[(struct TvsimpleD.32577 *)d_28(D) + 288B].vD.32579 = d__v_lsm.40_89; VIEW_CONVERT_EXPR(*d_28(D).lam1D.32701) = _84; *d_28(D).lam2D.32702.vD.32579 = _85; the dependence analysis of store-motion considers the last stores (ref 14 and 15) dependent: Querying dependency of refs 2 and 15: dependent. Querying RAW dependencies of ref 2 in loop 1: dependent Querying dependency of refs 13 and 14: dependent. Querying RAW dependencies of ref 13 in loop 1: dependent Querying dependency of refs 14 and 13: dependent. Querying SM WAR dependencies of ref 14 in loop 1: dependent Querying dependency of refs 15 and 2: dependent. Querying SM WAR dependencies of ref 15 in loop 1: dependent That's the usual issue of LIM needing to identify "identical" refs but appearanlty failing to do so for: Memory reference 2: MEM[(const struct Tvsimple *)d_28(D) + 128B].v Memory reference 15: *d_28(D).lam2.v which is because we don't factor the MEM_REF contained offset. I'll see to do that independently of the "hack" (which I'm not sure is an appropriate way of avoiding to change LIM to deal with aggregates ...)
[Bug middle-end/101292] [12 Regression] recent valgrind error in warning-control.cc since r12-1804-g65870e75616ee4359d1c13b99be794e6a577bc65
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101292
--- Comment #3 from Martin Liška ---
Reduced test-case:
--- /tmp/x.ii ---
struct type_info {
void operator==(type_info) { ((__name) || (0)); }
char __name;
};
enum byte : char;
void operator>>(byte, int) { ((0)); }
struct __class_type_info {
enum __sub_kind {
__contained_virtual_mask,
__contained_mask,
__contained_public
};
struct __dyncast_result;
};
__class_type_info::__sub_kind __do_dyncast_base_access;
struct __vmi_class_type_info : __class_type_info {
int __flags;
enum { __non_diamond_repeat_mask, __diamond_shaped_mask };
bool __do_dyncast(__dyncast_result &) const;
};
bool virtual_p(__class_type_info::__sub_kind access_path) {
(access_path & __class_type_info::__contained_virtual_mask);
((access_path & __class_type_info::__contained_public) ==
__class_type_info::__contained_public);
((access_path & __class_type_info::__contained_public) ==
__class_type_info::__contained_mask);
}
struct __class_type_info::__dyncast_result {
void *dst_ptr;
int whole_details;
__dyncast_result(int);
};
bool __vmi_class_type_info::__do_dyncast(__dyncast_result ) const {
result = (0);
(__do_dyncast_base_access |
(__non_diamond_repeat_mask | __diamond_shaped_mask));
(__non_diamond_repeat_mask);
(0) || (result.dst_ptr) || (0);
(!(result.whole_details));
(0) && (0 || (__flags)) || (__flags & __diamond_shaped_mask);
}
$ gcc x.ii -c
x.ii: In function ‘bool virtual_p(__class_type_info::__sub_kind)’:
x.ii:27:1: warning: no return statement in function returning non-void
[-Wreturn-type]
27 | }
| ^
x.ii: In member function ‘bool
__vmi_class_type_info::__do_dyncast(__class_type_info::__dyncast_result&)
const’:
x.ii:40:62: internal compiler error: in copy_warning, at warning-control.cc:194
40 | (0) && (0 || (__flags)) || (__flags & __diamond_shaped_mask);
| ^
0x1508cce void copy_warning(tree_node*, tree_node
const*)
/home/marxin/Programming/gcc/gcc/warning-control.cc:194
0x9e3467 cp_fold
/home/marxin/Programming/gcc/gcc/cp/cp-gimplify.c:2718
0x9e53f0 cp_fold_maybe_rvalue(tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/cp-gimplify.c:2109
0x9ecebf cp_convert_and_check(tree_node*, tree_node*, int)
/home/marxin/Programming/gcc/gcc/cp/cvt.c:666
0xbdd417 cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
/home/marxin/Programming/gcc/gcc/cp/typeck.c:5876
0x97efea build_new_op_1
/home/marxin/Programming/gcc/gcc/cp/call.c:6760
0x97fb81 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
/home/marxin/Programming/gcc/gcc/cp/call.c:6806
0xbcf21f build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node**, int)
/home/marxin/Programming/gcc/gcc/cp/typeck.c:4330
0xae1c44 cp_parser_binary_expression
/home/marxin/Programming/gcc/gcc/cp/parser.c:10023
0xae244c cp_parser_assignment_expression
/home/marxin/Programming/gcc/gcc/cp/parser.c:10161
0xae3aea cp_parser_expression
/home/marxin/Programming/gcc/gcc/cp/parser.c:10331
0xae7188 cp_parser_expression_statement
/home/marxin/Programming/gcc/gcc/cp/parser.c:12075
0xaf34f6 cp_parser_statement
/home/marxin/Programming/gcc/gcc/cp/parser.c:11871
0xaf453e cp_parser_statement_seq_opt
/home/marxin/Programming/gcc/gcc/cp/parser.c:12223
0xaf4630 cp_parser_compound_statement
/home/marxin/Programming/gcc/gcc/cp/parser.c:12172
0xb12ff7 cp_parser_function_body
/home/marxin/Programming/gcc/gcc/cp/parser.c:24238
0xb12ff7 cp_parser_ctor_initializer_opt_and_function_body
/home/marxin/Programming/gcc/gcc/cp/parser.c:24289
0xb14bea cp_parser_function_definition_after_declarator
/home/marxin/Programming/gcc/gcc/cp/parser.c:30248
0xb1605d cp_parser_function_definition_from_specifiers_and_declarator
/home/marxin/Programming/gcc/gcc/cp/parser.c:30164
0xb1605d cp_parser_init_declarator
/home/marxin/Programming/gcc/gcc/cp/parser.c:21810
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/101291] turns infinite loop into finite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101291 --- Comment #8 from Richard Biener --- The vectorizer sets loop constraints, looks like we forget to clear it in the versioning code. I'll have a look next week unless somebody beats me to it.
[Bug middle-end/101292] [12 Regression] recent valgrind error in warning-control.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101292 --- Comment #2 from Martin Liška --- Started with r12-1804-g65870e75616ee4359d1c13b99be794e6a577bc65, one can see it with: diff --git a/gcc/warning-control.cc b/gcc/warning-control.cc index ec8ed232763..6b1e5f26c8a 100644 --- a/gcc/warning-control.cc +++ b/gcc/warning-control.cc @@ -191,6 +191,7 @@ void copy_warning (ToType to, FromType from) if (!nowarn_map) nowarn_map = xint_hash_map_t::create_ggc (32); + gcc_assert (*from_map != 0xa5a5a5a5); nowarn_map->put (to_key, *from_map); set_no_warning_bit (to, true); }
[Bug debug/101283] Several tests fail on Darwin with -gctf/gbtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283 --- Comment #5 from Iain Sandoe --- (In reply to Richard Biener from comment #4) > It might make sense to provide targets a means to opt-out of CTF/BTF support > and thus diagnose -gctf as unsupported on them. In the short-term, I've got fixes for the invocation-related issues, which I'll commit today. A new debug format is clearly a vast undertaking - requiring buy-in from many organisations - in the case of Darwin, it will mean amendment to ld64 (to recognise and deal with relocation-less offsets) and dsymutil (to handle linking the debug) and then lldb / gdb / backtrace etc. to deal with common consumers. Releases for these tools are controlled by Apple - clearly one can self-build hacked version, but that's extremely unlikely to reach the larger majority of Darwin/macOS developers. == for opt out. It would be a simple matter to add a driver self-spec to reject '-gctf' and '-gbtf' (which can be arranged to give an error) and then, I guess, to add opt-out to the testsuite selectors? In any event, opt-out is likely the only sensible action for older platforms where "rebuild the world" is not an option; how can this interoperate with existing libraries etc. using DWARF debug?
[Bug tree-optimization/101291] turns infinite loop into finite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101291 --- Comment #7 from Jiu Fu Guo --- When generates doloop.xxx in ivopts, gimple looks like: [local count: 21023864]: _38 = val_4(D) - start_3(D); _29 = _38 / 16; doloop.15_35 = _29 + 1; [local count: 191126041]: # cnt_17 = PHI <0(13), cnt_19(10)> # doloop.15_28 = PHI cnt_19 = cnt_17 + 1; doloop.15_23 = doloop.15_28 - 1; if (doloop.15_23 != 0) goto ; [89.00%] else goto ; [11.00%] [local count: 170102176]: goto ; [100.00%] Before it [local count: 21023864]: [local count: 191126041]: # cnt_17 = PHI <0(13), cnt_19(10)> # i_18 = PHI cnt_19 = cnt_17 + 1; i_20 = i_18 + 16; if (val_4(D) >= i_20) goto ; [89.00%] else goto ; [11.00%] [local count: 170102176]: goto ; [100.00%] [local count: 118111600]: # cnt_11 = PHI return cnt_11; --- In number_of_iterations_exit_assumptions, there is code: if (!integer_zerop (niter->assumptions) && loop_constraint_set_p (loop, LOOP_C_FINITE)) niter->assumptions = boolean_true_node; At here niter->assumptions was reset to true. And then doloop.xx is generated as if niter is always ok.
[Bug tree-optimization/101291] turns infinite loop into finite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101291 --- Comment #6 from Richard Biener --- Hmm, the support is in GCC 9 as well and the niter analysis is the same so there's sth else going on. Btw, the assumptions are Analyzing # of iterations of loop 1 exit condition [start_3(D) + 16, + , 16] <= val_4(D) bounds on difference of bases: -16 ... 4294967295 result: under assumptions val_4(D) <= 4294967279 && start_3(D) + 16 > 14 # of iterations (val_4(D) - start_3(D)) / 16, bounded by 268435456 on trunk and Analyzing # of iterations of loop 1 exit condition [start_3(D) + 16, + , 16] <= val_4(D) bounds on difference of bases: -16 ... 4294967295 result: under assumptions val_4(D) <= 4294967279 && start_3(D) + 16 > 14 # of iterations (val_4(D) - start_3(D)) / 16, bounded by 268435456 on the GCC 9 branch. On trunk the scalar loop fallback is misoptimized by IVOPTs I think. -fno-ivopts makes it work on trunk at least. That said, ->assumptions is likely still at fault here.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #3 from Eric Botcazou --- We definitely cannot investigate this without more information, in particular the configure line. Barring that, you might want to try with the current gcc-11 branch where a very recent change could help.
[Bug tree-optimization/101291] turns infinite loop into finite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101291 --- Comment #5 from Martin Liška --- Likely started with r10-1057-g2778a719bebf7a32.
[Bug tree-optimization/101291] turns infinite loop into finite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101291 --- Comment #4 from Richard Biener --- The trigger is the vectorizer versioning on niter->assumptions and that being wrong. That feature is new in GCC 10 thus GCC 9 appears to be fine (but likely niter->assumptions is still wrong).
[Bug tree-optimization/99728] code pessimization when using wrapper classes around SIMD types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728 --- Comment #12 from Martin Reinecke --- Any hope of addressing this for gcc 12? I have a real-world test case where this effect causes roughly 15-20% slowdown, and I expect that with the wider availability of std::simd types more people will encounter this soon. (And the workaround pretty much defeats the purpose of having such convenient functionality as std::simd in the first place...) I'm happy to help out in any way I can, but unfortunately I'm more of a numerics guy than a compiler expert.
[Bug tree-optimization/101291] turns infinite loop into finite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101291 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-07-02 CC||amker at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||wrong-code --- Comment #3 from Richard Biener --- Confirmed with -O3 -fno-finite-loops (both C and C++ FE).
[Bug middle-end/101292] [12 Regression] recent valgrind error in warning-control.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101292 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 Component|c |middle-end Summary|recent valgrind error in|[12 Regression] recent |warning-control.cc |valgrind error in ||warning-control.cc CC||msebor at gcc dot gnu.org
[Bug tree-optimization/101291] turns infinite loop into finite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101291 --- Comment #2 from Kewen Lin --- (In reply to Kewen Lin from comment #1) > Hi Jeff, what's the option and stanza? The reason why I asked is that I can't simply reproduce it locally at O2, with C compiler it likely runs forever. I guess what you tested is the C++ stanza, so it turns on -ffinite-loops by default as the doc and the loop can stop.
[Bug c/101292] recent valgrind error in warning-control.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101292 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-07-02 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Confirmed, I'm reducing that right now.
[Bug tree-optimization/101291] turns infinite loop into finite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101291 Kewen Lin changed: What|Removed |Added CC||linkw at gcc dot gnu.org --- Comment #1 from Kewen Lin --- Hi Jeff, what's the option and stanza?
[Bug target/101286] [12 Regression] ICE: in ix86_expand_vector_move, at config/i386/i386-expand.c:574 with -mavx2 and __int128 vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101286 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f7cad1a0ffe9f003ec347521dfd33f320f4c2b04 commit r12-1974-gf7cad1a0ffe9f003ec347521dfd33f320f4c2b04 Author: Jakub Jelinek Date: Fri Jul 2 10:06:56 2021 +0200 i386: Punt on broadcasts from TImode integers [PR101286] ix86_expand_vector_init_duplicate doesn't handle TImode -> V2TImode or TImode -> V4TImode broadcasts, so I think we should punt on TImode inner mode in ix86_broadcast_from_integer_constant, otherwise we ICE in ix86_expand_vector_move when ix86_broadcast_from_integer_constant returns non-NULL and ix86_expand_vector_init_duplicate returns false. In theory TImode element broadcasts could be handled by some permutations, but I'm not sure it is worth it. 2021-07-02 Jakub Jelinek PR target/101286 * config/i386/i386-expand.c (ix86_broadcast_from_integer_constant): Return nullptr for TImode inner mode. * gcc.target/i386/avx2-pr101286.c: New test.
[Bug c/101292] New: recent valgrind error in warning-control.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101292 Bug ID: 101292 Summary: recent valgrind error in warning-control.cc Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Recent gcc trunk build does: /home/dcb/gcc/working.valgrind/./gcc/xgcc -shared-libgcc -B/home/dcb/gcc/working.valgrind/./gcc -nostdinc++ -L/home/dcb/gcc/working.valgrind/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/dcb/gcc/working.valgrind/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/dcb/gcc/working.valgrind/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/dcb/gcc/results.20210701.valgrind/x86_64-pc-linux-gnu/bin/ -B/home/dcb/gcc/results.20210701.valgrind/x86_64-pc-linux-gnu/lib/ -isystem /home/dcb/gcc/results.20210701.valgrind/x86_64-pc-linux-gnu/include -isystem /home/dcb/gcc/results.20210701.valgrind/x86_64-pc-linux-gnu/sys-include-x c++-header -nostdinc++ -g -O3 -D_GNU_SOURCE -I/home/dcb/gcc/working.valgrind/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/home/dcb/gcc/working.valgrind/x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/dcb/gcc/trunk.git/libstdc++-v3/libsupc++ -O2 -g /home/dcb/gcc/trunk.git/libstdc++-v3/include/precompiled/extc++.h -o x86_64-pc-linux-gnu/bits/extc++.h.gch/O2g.gch ==29810== Invalid read of size 4 ==29810==at 0x114F9C0: put (hash-map.h:179) ==29810==by 0x114F9C0: copy_warning (warning-control.cc:194) ==29810==by 0x114F9C0: copy_warning(tree_node*, tree_node const*) (warning-control.cc:213) ==29810==by 0x6C0F5F: cp_fold(tree_node*) (cp-gimplify.c:2718) This is for git hash 91c771ec8a3b6497. This error did not occur last time I tried this build with git hash b4e21c80462682c4.
