[Bug middle-end/109707] naked attribute should imply the no_instrument_function attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109707 --- Comment #4 from Fangrui Song --- (In reply to Andrew Pinski from comment #2) > As a workaround, you could add the attribute no_instrument_function. Yes. I thought of this possibility, but pcc's reply on https://github.com/llvm/llvm-project/issues/62504 makes sense to me: the only one reasonable way is probably to skip naked functions. The Linux kernel ran into this combination in 2009 and they switched to use __attribute__((naked)) and __attribute__((__no_instrument_function__)) together in https://git.kernel.org/linus/446c92b2901bedb3725d29b4e73def8aba623ffc > #define __naked __attribute__((naked)) notrace > > > (before hotpatch/patchable_function_entry) #define notrace > __attribute__((__no_instrument_function__))
[Bug middle-end/109707] naked attribute should imply the no_instrument_function attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109707 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > As a workaround, you could add the attribute no_instrument_function. Which is documented here: https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Common-Function-Attributes.html#index-no_005finstrument_005ffunction-function-attribute
[Bug middle-end/109707] naked attribute should imply the no_instrument_function attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109707 Andrew Pinski changed: What|Removed |Added Component|target |middle-end Summary|Skip __attribute__((naked)) |naked attribute should |functions for -pg and |imply the |-finstrument-functions |no_instrument_function ||attribute --- Comment #2 from Andrew Pinski --- As a workaround, you could add the attribute no_instrument_function.
[Bug c/109707] Skip __attribute__((naked)) functions for -pg and -finstrument-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109707 --- Comment #1 from Fangrui Song --- I came here from a PR for Clang: https://github.com/llvm/llvm-project/issues/62504
[Bug c/109707] New: Skip __attribute__((naked)) functions for -pg and -finstrument-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109707
Bug ID: 109707
Summary: Skip __attribute__((naked)) functions for -pg and
-finstrument-functions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
The asm in a naked function may reasonably expect the argument registers and
the
return address register (if present) to be live.
When using -pg and -finstrument-functions, functions are instrumented by adding
a function call to mcount/__cyg_profile_func_enter, which will clobber these
registers.
If the return address register is clobbered, the function will be unable to
return to the caller, possibly causing an infinite loop.
% riscv64-linux-gnu-gcc a.c -finstrument-functions
-Wl,--dynamic-linker=/usr/riscv64-linux-gnu/lib/ld-linux-riscv64-lp64d.so.1
-Wl,-rpath=/usr/riscv64-linux-gnu/lib
% ./a.out # infinite loop
% riscv64-linux-gnu-gcc a.c -pg
-Wl,--dynamic-linker=/usr/riscv64-linux-gnu/lib/ld-linux-riscv64-lp64d.so.1
-Wl,-rpath=/usr/riscv64-linux-gnu/lib
% ./a.out # infinite loop
% arm-linux-gnueabihf-gcc a.c -finstrument-functions
-Wl,--dynamic-linker=/usr/arm-linux-gnueabihf/lib/ld-linux-armhf.so.3
-Wl,-rpath=/usr/arm-linux-gnueabihf/lib
% ./a.out # infinite loop
arm -pg uses `push {lr}; bl __gnu_mcount_nc`, so a naked function works with
-pg, but this appears to be a rare exception.
% arm-linux-gnueabihf-gcc a.c -pg
-Wl,--dynamic-linker=/usr/arm-linux-gnueabihf/lib/ld-linux-armhf.so.3
-Wl,-rpath=/usr/arm-linux-gnueabihf/lib
% ./a.out # good
[Bug c++/69836] compilation error with constexpr in template types with redeclared methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69836 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #7 from Jason Merrill --- Fixed for GCC 14.
[Bug c++/109692] [12/13/14 Regression] ICE on concept as default template parameter to iife lambda in fold expression in static member template function since r12-8110-ge2c7070ac77405
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109692 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.4
[Bug tree-optimization/109691] Takes until forwprop2 to remove !a sometimes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109691 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > Still working on this but I ran into an issue where we now remove a dead > load but that load has an exception edge (due to -fnon-call-exceptions) and > we don't cleanup the eh edge and get an ICE due to that. > > FAIL: g++.dg/pr55263.C -std=gnu++14 (internal compiler error: > verify_flow_info failed) > > FAIL: g++.dg/tree-ssa/pr36766.C -std=gnu++14 (internal compiler error: > verify_flow_info failed) I have a fix, it was simplier than expected.
[Bug libstdc++/109703] [12/13/14 Regression] __builtin_unreachable() reached since r13-6915-gbf78b43873b0b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109703 Andrew Pinski changed: What|Removed |Added CC||tchaikov at gmail dot com --- Comment #2 from Andrew Pinski --- *** Bug 109706 has been marked as a duplicate of this bug. ***
[Bug libstdc++/109706] basic_string runs into __builtin_unreachable() when constructing from istringstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109706 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 109703. *** This bug has been marked as a duplicate of bug 109703 ***
[Bug libstdc++/109706] New: basic_string runs into __builtin_unreachable() when constructing from istringstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109706
Bug ID: 109706
Summary: basic_string runs into __builtin_unreachable() when
constructing from istringstream
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: tchaikov at gmail dot com
Target Milestone: ---
We copy from source range to the local buffer, and then reallocate
to larger one if necessary, when disposing the old buffer. And the
old buffer could be provisioned by the local buffer or an allocated
buffer. _M_is_local() is used to tell if the buffer is the local one
or not. In addition to comparing the buffer address with the local buffer,
this function also performs the sanity check if _M_string_length is
greater than _S_local_capacity, if the check fails
__builtin_unreachable() is called. But we failed to set _M_string_length
in this constructor is specialized for std::input_iterator. So,
if UBSan is enabled when compiling the source, there are chances that
the uninitialized data in _M_string_length is greater than
_S_local_capacity, and the application aborts a runtime error or
exception emitted by the UBSan.
a minimal reproducer is like:
#include
#include
#include
int main() {
unsigned char buf[sizeof(std::string)] ;
std::memset(buf, 0xff, sizeof(buf));
const char s[] = "1234567890abcdefg";
std::istringstream in{s};
std::istreambuf_iterator it{in}, end;
auto* p = new (buf) std::string(it, end);
return 0;
}
see https://godbolt.org/z/7q4nG68xn
a patch has been posted to the related mailing list. see
https://gcc.gnu.org/pipermail/libstdc++/2023-May/055895.html
[Bug testsuite/109705] New: [14 regression] gcc.dg/vect/pr25413a.c fails after r14-333-g6d4b59a9356ac4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705 Bug ID: 109705 Summary: [14 regression] gcc.dg/vect/pr25413a.c fails after r14-333-g6d4b59a9356ac4 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:6d4b59a9356ac4df7f4ae370495dc3366d0daa55, r14-333-g6d4b59a9356ac4 make -k check-gcc RUNTESTFLAGS="vect.exp=gcc.dg/vect/pr25413a.c" FAIL: gcc.dg/vect/pr25413a.c scan-tree-dump-times vect "vectorized 2 loops" 1 FAIL: gcc.dg/vect/pr25413a.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 2 loops" 1 # of expected passes4 # of unexpected failures2 commit 6d4b59a9356ac4df7f4ae370495dc3366d0daa55 (HEAD, refs/bisect/bad) Author: Richard Biener Date: Wed Jan 18 10:59:52 2023 +0100 Add emulated scatter capability to the vectorizer * gcc.dg/vect/pr25413a.c: Un-XFAIL everywhere. This fails on power 8 and 9 LE but is OK on BE and on power 10. Perhaps there is some LE optimization missing previous to power 10?
[Bug tree-optimization/109691] Takes until forwprop2 to remove !a sometimes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109691 --- Comment #2 from Andrew Pinski --- Still working on this but I ran into an issue where we now remove a dead load but that load has an exception edge (due to -fnon-call-exceptions) and we don't cleanup the eh edge and get an ICE due to that. FAIL: g++.dg/pr55263.C -std=gnu++14 (internal compiler error: verify_flow_info failed) FAIL: g++.dg/tree-ssa/pr36766.C -std=gnu++14 (internal compiler error: verify_flow_info failed) Also still have to update a few other testcases. FAIL: gcc.dg/pr81192.c scan-tree-dump-times pre "(?n)find_duplicates: duplicate of " 1 FAIL: c-c++-common/goacc/kernels-alias-8.c scan-tree-dump-times ealias "clique 1 base 1" 2 kernels-alias-8.c is because we also dce a load I have to double check how to handle that one but -fno-tree-ccp might work ... gcc.dg/pr81192.c might need a similar thing now too but I am not 100% sure. pr81192.c should really be a Gimple testcase but gimple testcases were not around when the testcase was added.
[Bug tree-optimization/109702] [14 Regression] Wrong code with if and __builtin_bswap and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109702 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fixed.
[Bug tree-optimization/109702] [14 Regression] Wrong code with if and __builtin_bswap and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109702 --- Comment #2 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:8702ab1456eee07d07ac1a8bc005c690cf6dbcf0 commit r14-413-g8702ab1456eee07d07ac1a8bc005c690cf6dbcf0 Author: Andrew Pinski Date: Tue May 2 11:03:02 2023 -0700 tree-optimization: [PR109702] MATCH: Fix a ? func(a) : N patterns I accidently messed up these patterns so the comparison against 0 and the arguments was not matching up when they need to be. I committed this as obvious after a bootstrap/test on x86_64-linux-gnu PR tree-optimization/109702 gcc/ChangeLog: * match.pd: Fix "a != 0 ? FUNC(a) : CST" patterns for FUNC of POPCOUNT BSWAP FFS PARITY CLZ and CTZ. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/phi-opt-25b.c: New test.
[Bug preprocessor/109704] #pragma {push,pop}_macro broken for identifiers that contain dollar signs at nonfirst positions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109704 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > Well $ is an extension and MSVC does not support $, push_macro/pop_macro > were for compatibility for MSVC too. Well they don't support $ in their C front-end but does in their C++ front-end.
[Bug preprocessor/109704] #pragma {push,pop}_macro broken for identifiers that contain dollar signs at nonfirst positions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109704 --- Comment #1 from Andrew Pinski --- Well $ is an extension and MSVC does not support $, push_macro/pop_macro were for compatibility for MSVC too.
[Bug target/109657] (a ? -1 : 0) | b could be optimized better for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109657 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED --- Comment #4 from Andrew Pinski --- Fixed.
[Bug preprocessor/109704] New: #pragma {push,pop}_macro broken for identifiers that contain dollar signs at nonfirst positions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109704
Bug ID: 109704
Summary: #pragma {push,pop}_macro broken for identifiers that
contain dollar signs at nonfirst positions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
This following dollarsign-less example compiles fine as expected:
#define MACRO 1
_Static_assert(MACRO,"");
#pragma push_macro("MACRO")
#undef MACRO
#define MACRO 0
_Static_assert(!MACRO,"");
#pragma pop_macro("MACRO")
_Static_assert(MACRO,""); //OK
Substituting $MACRO for MACRO still works, but with MACRO$ or M$CRO the final
assertions fail: https://godbolt.org/z/n1EoGao74
[Bug target/109657] (a ? -1 : 0) | b could be optimized better for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109657 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:7cc33d12dca84befde69259a17fab8224e2e4025 commit r14-412-g7cc33d12dca84befde69259a17fab8224e2e4025 Author: Andrew Pinski Date: Fri Apr 28 05:22:34 2023 + target: [PR109657] (a ? -1 : 0) | b could be optimized better for aarch64 There is no canonical form for this case defined. So the aarch64 backend needs a pattern to match both of these forms. The forms are: (set (reg/i:SI 0 x0) (if_then_else:SI (eq (reg:CC 66 cc) (const_int 0 [0])) (reg:SI 97) (const_int -1 [0x]))) and (set (reg/i:SI 0 x0) (ior:SI (neg:SI (ne:SI (reg:CC 66 cc) (const_int 0 [0]))) (reg:SI 102))) Currently the aarch64 backend matches the first form so this patch adds a insn_and_split to match the second form and convert it to the first form. OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions PR target/109657 gcc/ChangeLog: * config/aarch64/aarch64.md (*cmov_insn_m1): New insn_and_split pattern. gcc/testsuite/ChangeLog: * gcc.target/aarch64/csinv-2.c: New test.
[Bug preprocessor/105608] [11/12/13/14 Regression] ICE: in linemap_add with a really long defined macro on the command line r11-338-g2a0225e47868fbfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608 --- Comment #2 from Lewis Hyatt --- When a PCH file is restored, the global line_maps instance is replaced with the one that was stored in the PCH file. Hence any locations that were generated prior to restoring the PCH file need to be added back to it. Currently, the only such locations that can arise will be from preprocessor directives, such as #define. The save/restore process is handled by libcpp/pch.cc and, looking over this now, it doesn't seem it makes any effort to assign valid locations when re-adding the saved macros. If the just-restored line map is at depth=0, as it is after processing the empty pch, then it produces the ICE noted here in case the first line map added is of type LC_RENAME, which happens if an ad-hoc location is needed due to the long line. However you can see the invalid locations without an ICE as well, for instance in this simpler example: $ echo -n > h.h $ cat > a.cpp #define HELLO #include "h.h" $ gcc -x c++-header -c h.h $ gcc -x c++ -c a.cpp -Wunused-macros h.h:2: warning: macro "HELLO" is not used [-Wunused-macros] Note that the warning is emitted with the wrong filename and the wrong line number. If the PCH is absent, it will be correct, but when the definition of HELLO is processed the second time after PCH restore, it comes out wrong. Fixing this issue will also fix the ICE reported here; I think it will be needed to add some more infrastructure in libcpp/pch.cc so that it can add to the line map with proper locations. I can look into it sometime. This was always incorrect AFAIK, and did not regress with r11-338-g2a0225e47868fbfc specifically; that commit did make the line number change from 1 to 2, because it handles EOF differently, and I think that caused Sergei's test case to ICE rather than be silently wrong. BTW, the issue can also be papered over by moving these 2 lines: diff --git a/gcc/c-family/c-pch.cc b/gcc/c-family/c-pch.cc index 2f014fca210..9ee6f179002 100644 --- a/gcc/c-family/c-pch.cc +++ b/gcc/c-family/c-pch.cc @@ -342,6 +342,8 @@ c_common_read_pch (cpp_reader *pfile, const char *name, gt_pch_restore (f); cpp_set_line_map (pfile, line_table); rebuild_location_adhoc_htab (line_table); + line_table->trace_includes = saved_trace_includes; + linemap_add (line_table, LC_ENTER, 0, saved_loc.file, saved_loc.line); timevar_push (TV_PCH_CPP_RESTORE); if (cpp_read_state (pfile, name, f, smd) != 0) @@ -355,9 +357,6 @@ c_common_read_pch (cpp_reader *pfile, const char *name, fclose (f); - line_table->trace_includes = saved_trace_includes; - linemap_add (line_table, LC_ENTER, 0, saved_loc.file, saved_loc.line); - /* Give the front end a chance to take action after a PCH file has been loaded. */ if (lang_post_pch_load) = With that change, you still get wrong locations for the restored macros, but the line_map state is sufficiently improved that the ICE is avoided. (The locations get assigned, as if all the macros were defined on the line following the PCH include.)
[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695 --- Comment #7 from Andrew Macleod --- Created attachment 54973 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54973=edit Patch to fix the issue The problem was exposed by the newly increased size of int_range_max. (We may want to address that elsewhere) It has grown an order of magnitude in size with wide-int To avoid massive stack growth, range_of_stmt uses prefill_stmt_dependencies() to do the same thing as a set of nested recursive calls to range_of_stmt, just managing it via a stack of ssa-names instead of actual calls. Once all the dependencies have been resolved, then we invoke fold_stmt and evaluate the stmt, and set the result. The problem is that while processing a series of PHIs, some ssa-names occur multiple times, and setting the result was unconditionally done. In this case, it was really simple: _1947 = 77; _1947 was used in multiple phi arguments, as well as other stmts which then fed long series of PHIs. it always came up as [77, 77], but when the global value was set again, it changes the temporal timestamp. The next time it was seen, it was "newer" than the previously calculated value, and we therefore thought we had to go and prefetch things again. It effectively un-did much of the pre-fetching, and we'd end up with very long call chains again. With the increased size of int_range_max, it blew up the stack in this testcase. The fix is to simply check if the new value is different than the previous value, and not set it if so. This would be appropriate to put into gcc13 as well. Patch is currently undergoing testing
[Bug libstdc++/109703] [12/13/14 Regression] __builtin_unreachable() reached since r13-6915-gbf78b43873b0b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109703 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-05-02 --- Comment #1 from Jonathan Wakely --- See https://gcc.gnu.org/pipermail/libstdc++/2023-May/055903.html
[Bug c++/109678] [13/14 Regression] exponential time behavior on std::variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109678 --- Comment #5 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a43f3616c0069541b1f465eea67285eeeff36785 commit r14-410-ga43f3616c0069541b1f465eea67285eeeff36785 Author: Jason Merrill Date: Mon May 1 21:03:45 2023 -0400 c++: look for empty base at specific offset [PR109678] While looking at the empty base handling for 109678, it occurred to me that we ought to be able to look for an empty base at a specific offset, not just in general. PR c++/109678 gcc/cp/ChangeLog: * cp-tree.h (lookup_base): Add offset parm. * constexpr.cc (cxx_fold_indirect_ref_1): Pass it. * search.cc (struct lookup_base_data_s): Add offset. (dfs_lookup_base): Handle it. (lookup_base): Pass it.
[Bug c++/109678] [13/14 Regression] exponential time behavior on std::variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109678 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:4b8d0d4d7fd245ef85c7801e7838845502a5a61d commit r14-409-g4b8d0d4d7fd245ef85c7801e7838845502a5a61d Author: Jason Merrill Date: Mon May 1 17:41:44 2023 -0400 c++: std::variant slow to compile [PR109678] Here, when dealing with a class with a complex subobject structure, we would try and fail to find the relevant FIELD_DECL for an empty base before giving up. And we would do this at each level, in a combinatorially problematic way. Instead, we should check for an empty base first. PR c++/109678 gcc/cp/ChangeLog: * constexpr.cc (cxx_fold_indirect_ref_1): Handle empty base first. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/variant1.C: New test.
[Bug c++/108099] [12/13 Regression] ICE with type alias with `signed __int128_t`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099 --- Comment #27 from CVS Commits --- The releases/gcc-13 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a713aa4f47ac1efbfe2338790b0b5e94a233fb99 commit r13-7277-ga713aa4f47ac1efbfe2338790b0b5e94a233fb99 Author: Jason Merrill Date: Tue Apr 18 21:32:07 2023 -0400 c++: fix 'unsigned typedef-name' extension [PR108099] In the comments for PR108099 Jakub provided some testcases that demonstrated that even before the regression noted in the patch we were getting the semantics of this extension wrong: in the unsigned case we weren't producing the corresponding standard unsigned type but another distinct one of the same size, and in the signed case we were just dropping it on the floor and not actually returning a signed type at all. The former issue is fixed by using c_common_signed_or_unsigned_type instead of unsigned_type_for, and the latter issue by adding a (signed_p && typedef_decl) case. This patch introduces a failure on std/ranges/iota/max_size_type.cc due to the latter issue, since the testcase expects 'signed rep_t' to do something sensible, and previously we didn't. Now that we do, it exposes a bug in the __max_diff_type::operator>>= handling of sign extension: when we evaluate -1000 >> 2 in __max_diff_type we keep the MSB set, but leave the second-most-significant bit cleared. PR c++/108099 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Don't clear typedef_decl after 'unsigned typedef' pedwarn. Use c_common_signed_or_unsigned_type. Also handle 'signed typedef'. gcc/testsuite/ChangeLog: * g++.dg/ext/int128-8.C: New test. * g++.dg/ext/unsigned-typedef2.C: New test. * g++.dg/ext/unsigned-typedef3.C: New test.
[Bug c++/109678] [13/14 Regression] exponential time behavior on std::variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109678 --- Comment #3 from CVS Commits --- The releases/gcc-13 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:275e059dd7542f0d45adba74de18296134ac0d15 commit r13-7279-g275e059dd7542f0d45adba74de18296134ac0d15 Author: Jason Merrill Date: Tue May 2 15:03:57 2023 -0400 Revert "c++: *this folding in constexpr call" The earlier commit wasn't fixing a known bug, so let's revert it on the branch. PR c++/109678 This reverts commit 1189c03859cefef4fc4fd44d57eb3d4d3348b562.
[Bug c++/109666] [13/14 Regression] Segmentation fault with std::array using gcc 13 since r13-6788
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109666 --- Comment #6 from CVS Commits --- The releases/gcc-13 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:0a2c771910e888c9a26db319122230144789b9bf commit r13-7278-g0a2c771910e888c9a26db319122230144789b9bf Author: Jason Merrill Date: Mon May 1 10:57:20 2023 -0400 c++: array DMI and member fn [PR109666] Here it turns out I also needed to adjust cfun when stepping out of the member function to instantiate the DMI. But instead of adding that tweak, let's unify with instantiate_body and just push_to_top_level instead of trying to do the minimum subset of it. There was no measurable change in compile time on stdc++.h. This should also resolve 109506 without yet another tweak. PR c++/109666 gcc/cp/ChangeLog: * name-lookup.cc (maybe_push_to_top_level) (maybe_pop_from_top_level): Split out... * pt.cc (instantiate_body): ...from here. * init.cc (maybe_instantiate_nsdmi_init): Use them. * name-lookup.h: Declare them.. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/nsdmi-array2.C: New test.
[Bug other/109306] The strstr implementation in libiberty might have undefined behavior (out of bounds mem access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109306
--- Comment #10 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:83fe692a373f6e6738f4bdc6661d1d58e4bf95c6
commit r11-10733-g83fe692a373f6e6738f4bdc6661d1d58e4bf95c6
Author: Jakub Jelinek
Date: Sun Apr 2 20:05:31 2023 +0200
libiberty: Make strstr.c in libiberty ANSI compliant
On Fri, Nov 13, 2020 at 11:53:43AM -0700, Jeff Law via Gcc-patches wrote:
>
> On 5/1/20 6:06 PM, Seija Kijin via Gcc-patches wrote:
> > The original code in libiberty says "FIXME" and then says it has not
been
> > validated to be ANSI compliant. However, this patch changes the
function to
> > match implementations that ARE compliant, and such code is in the
public
> > domain.
> >
> > I ran the test results, and there are no test failures.
>
> Thanks. This seems to be the standard "simple" strstr implementation.
> There's significantly faster implementations available, but I doubt it's
> worth the effort as the version in this file only gets used if there is
> no system strstr.c.
Except that PR109306 says the new version is non-compliant and
is certainly slower than what we used to have. The only problem I see
on the old version (sure, it is not very fast version) is that for
strstr ("abcd", "") it returned "abcd"+4 rather than "abcd" because
strchr in that case changed p to point to the last character and then
strncmp returned 0.
The question reported in PR109306 is whether memcmp is required not to
access characters beyond the first difference or not.
For all of memcmp/strcmp/strncmp, C17 says:
"The sign of a nonzero value returned by the comparison functions memcmp,
strcmp, and strncmp
is determined by the sign of the difference between the values of the first
pair of characters (both
interpreted as unsigned char) that differ in the objects being compared."
but then in memcmp description says:
"The memcmp function compares the first n characters of the object pointed
to by s1 to the first n
characters of the object pointed to by s2."
rather than something similar to strncmp wording:
"The strncmp function compares not more than n characters (characters that
follow a null character
are not compared) from the array pointed to by s1 to the array pointed to
by
s2."
So, while for strncmp it seems clearly well defined when there is zero
terminator before reaching the n, for memcmp it is unclear if say
int
memcmp (const void *s1, const void *s2, size_t n)
{
int ret = 0;
size_t i;
const unsigned char *p1 = (const unsigned char *) s1;
const unsigned char *p2 = (const unsigned char *) s2;
for (i = n; i; i--)
if (p1[i - 1] != p2[i - 1])
ret = p1[i - 1] < p2[i - 1] ? -1 : 1;
return ret;
}
wouldn't be valid implementation (one which always compares all characters
and just returns non-zero from the first one that differs).
So, shouldn't we just revert and handle the len == 0 case correctly?
I think almost nothing really uses it, but still, the old version
at least worked nicer with a fast strchr.
Could as well strncmp (p + 1, s2 + 1, len - 1) if that is preferred
because strchr already compared the first character.
2023-04-02 Jakub Jelinek
PR other/109306
* strstr.c: Revert the 2020-11-13 changes.
(strstr): Return s1 if len is 0.
(cherry picked from commit 1719fa40c4ee4def60a2ce2f27e17f8168cf28ba)
[Bug tree-optimization/109410] [13/14 Regression] ICE: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109410 --- Comment #16 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e61e70fbfdcc99cbd23a02a1c789d3290b58d5a8 commit r11-10735-ge61e70fbfdcc99cbd23a02a1c789d3290b58d5a8 Author: Jakub Jelinek Date: Wed Apr 12 16:55:15 2023 +0200 reassoc: Fix up another ICE with returns_twice call [PR109410] The following testcase ICEs in reassoc, unlike the last case I've fixed there here SSA_NAME_USED_IN_ABNORMAL_PHI is not the case anywhere. build_and_add_sum places new statements after the later appearing definition of an operand but if both operands are default defs or constants, we place statement at the start of the function. If the very first statement of a function is a call to returns_twice function, this doesn't work though, because that call has to be the first thing in its basic block, so the following patch splits the entry successor edge such that the new statements are added into a different block from the returns_twice call. I think we should in stage1 reconsider such placements, I think it unnecessarily enlarges the lifetime of the new lhs if its operand(s) are used more than once in the function. Unless something sinks those again. Would be nice to place it closer to the actual uses (or where they will be placed). 2023-04-12 Jakub Jelinek PR tree-optimization/109410 * tree-ssa-reassoc.c (build_and_add_sum): Split edge from entry block if first statement of the function is a call to returns_twice function. * gcc.dg/pr109410.c: New test. (cherry picked from commit 51856718a82ce60f067910d9037ca255645b37eb)
[Bug target/109276] [11 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276 --- Comment #22 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:623245bc3f4eed25db80dd5f5650c18cd7314b39 commit r11-10731-g623245bc3f4eed25db80dd5f5650c18cd7314b39 Author: Jakub Jelinek Date: Tue Mar 28 10:43:08 2023 +0200 i386: Require just 32-bit alignment for SLOT_FLOATxFDI_387 -m32 -mpreferred-stack-boundary=2 DImode temporaries [PR109276] The following testcase ICEs since r11-2259 because assign_386_stack_local -> assign_stack_local -> ix86_local_alignment now uses 64-bit alignment for DImode temporaries rather than 32-bit as before. Most of the spots in the backend which ask for DImode temporaries are during expansion and those apparently are handled fine with -m32 -mpreferred-stack-boundary=2, we dynamically realign the stack in that case (most of the spots actually don't need that alignment but at least one does), then 2 spots are in STV which I assume also work correctly. But during splitting we can create a DImode slot which doesn't need to be 64-bit alignment (it is nicer for performance though), when we apparently aren't able to detect it for dynamic stack realignment purposes. The following patch just makes the slot 32-bit aligned in that rare case. 2023-03-28 Jakub Jelinek PR target/109276 * config/i386/i386.c (assign_386_stack_local): For DImode with SLOT_FLOATxFDI_387 and -m32 -mpreferred-stack-boundary=2 pass align 32 rather than 0 to assign_stack_local. * gcc.target/i386/pr109276.c: New test. (cherry picked from commit 4b5ef857f5faf09f274c0a95c67faaa80d198124)
[Bug tree-optimization/109176] [11 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109176 --- Comment #21 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3384fb5024e05cfd429e2fb619ae8d51eba69661 commit r11-10729-g3384fb5024e05cfd429e2fb619ae8d51eba69661 Author: Jakub Jelinek Date: Thu Mar 23 10:02:25 2023 +0100 tree-vect-generic: Fix up expand_vector_condition [PR109176] The following testcase ICEs on aarch64-linux, because expand_vector_condition attempts to piecewise lower SVE d_3 = a_1(D) < b_2(D); _5 = VEC_COND_EXPR ; which isn't possible - nunits_for_known_piecewise_op ICEs but the rest of the code assumes constant number of elements too. expand_vector_condition attempts to find if a (rhs1) is a SSA_NAME for comparison and calls expand_vec_cond_expr_p (type, TREE_TYPE (a1), code) where a1 is one of the operands of the comparison and code is the comparison code. That one indeed isn't supported here, but what aarch64 SVE supports are the individual statements, comparison (expand_vec_cmp_expr_p) and expand_vec_cond_expr_p (type, TREE_TYPE (a), SSA_NAME), the latter because that function starts with if (VECTOR_BOOLEAN_TYPE_P (cmp_op_type) && get_vcond_mask_icode (TYPE_MODE (value_type), TYPE_MODE (cmp_op_type)) != CODE_FOR_nothing) return true; In an earlier version of the patch (in the PR), we did this if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (a)) && expand_vec_cond_expr_p (type, TREE_TYPE (a), ERROR_MARK)) return true; before the code == SSA_NAME handling plus some further tweaks later. While that fixed the ICE, it broke quite a few tests on x86 and some on aarch64 too. The problem is that expand_vector_comparison doesn't lower comparisons which aren't supported and only feed VEC_COND_EXPR first operand and expand_vector_condition succeeds for those, so with the above mentioned change we'd verify the VEC_COND_EXPR is implementable using optab alone, but nothing would verify the tcc_comparison which relied on expand_vector_condition to verify. So, the following patch instead queries whether optabs can handle the comparison and VEC_COND_EXPR together (if a (rhs1) is a comparison; otherwise as before it checks only the VEC_COND_EXPR) and if that fails, also checks whether the two operations could be supported individually and only if even that fails does the piecewise lowering. 2023-03-23 Jakub Jelinek PR tree-optimization/109176 * tree-vect-generic.c (expand_vector_condition): If a has vector boolean type and is a comparison, also check if both the comparison and VEC_COND_EXPR could be successfully expanded individually. * gcc.target/aarch64/sve/pr109176.c: New test. (cherry picked from commit 484c41c747d95f9cee15a33b75b32ae2e7eb45f3)
[Bug target/105554] [10/11 Regression] ICE: in emit_block_move_hints, at expr.cc:1829 since r9-5509-g5928bc2ec06dd4e7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554
--- Comment #25 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:40a9f3d335da7e1977beff2357afac39c500650f
commit r11-10727-g40a9f3d335da7e1977beff2357afac39c500650f
Author: Jakub Jelinek
Date: Fri Mar 17 18:59:56 2023 +0100
tree-inline: Fix up multiversioning with vector arguments [PR105554]
The following testcase ICEs, because we call tree_function_versioning from
old_decl which has target attributes not supporting V4DImode and so
DECL_MODE of DECL_ARGUMENTS is BLKmode, while new_decl supports those.
tree_function_versioning initially copies DECL_RESULT and DECL_ARGUMENTS
from old_decl to new_decl, then calls initialize_cfun to create cfun
and only when the cfun is created it can later actually remap_decl
DECL_RESULT and DECL_ARGUMENTS etc.
The problem is that initialize_cfun -> push_struct_function ->
allocate_struct_function calls relayout_decl on DECL_RESULT and
DECL_ARGUMENTS, which clobbers DECL_MODE of old_decl and we then ICE
because
of it.
In particular, allocate_struct_function does:
if (!abstract_p)
{
/* Now that we have activated any function-specific attributes
that might affect layout, particularly vector modes, relayout
each of the parameters and the result. */
relayout_decl (result);
for (tree parm = DECL_ARGUMENTS (fndecl); parm;
parm = DECL_CHAIN (parm))
relayout_decl (parm);
/* Similarly relayout the function decl. */
targetm.target_option.relayout_function (fndecl);
}
if (!abstract_p && aggregate_value_p (result, fndecl))
{
#ifdef PCC_STATIC_STRUCT_RETURN
cfun->returns_pcc_struct = 1;
#endif
cfun->returns_struct = 1;
}
Now, in the case of tree_function_versioning, I believe all that we need
from these is possibly the
targetm.target_option.relayout_function (fndecl);
call (arm only), we will remap DECL_RESULT and DECL_ARGUMENTS later on
and copy_decl_for_dup_finish in that case will handle all we need:
/* For vector typed decls make sure to update DECL_MODE according
to the new function context. */
if (VECTOR_TYPE_P (TREE_TYPE (copy)))
SET_DECL_MODE (copy, TYPE_MODE (TREE_TYPE (copy)));
We don't need the cfun->returns_*struct either, because we override it
in initialize_cfun a few lines later:
/* Copy items we preserve during cloning. */
...
cfun->returns_struct = src_cfun->returns_struct;
cfun->returns_pcc_struct = src_cfun->returns_pcc_struct;
So, to avoid the clobbering of DECL_RESULT/DECL_ARGUMENTS of old_decl,
the following patch arranges allocate_struct_function to be called with
abstract_p true and calls targetm.target_option.relayout_function (fndecl);
by hand.
The removal of DECL_RESULT/DECL_ARGUMENTS copying at the start of
initialize_cfun is removed because the only caller -
tree_function_versioning, does that unconditionally before.
2023-03-17 Jakub Jelinek
PR target/105554
* function.h (push_struct_function): Add ABSTRACT_P argument
defaulted
to false.
* function.c (push_struct_function): Add ABSTRACT_P argument, pass
it
to allocate_struct_function instead of false.
* tree-inline.c (initialize_cfun): Don't copy DECL_ARGUMENTS
nor DECL_RESULT here. Pass true as ABSTRACT_P to
push_struct_function. Call targetm.target_option.relayout_function
after it.
(tree_function_versioning): Formatting fix.
* gcc.target/i386/pr105554.c: New test.
(cherry picked from commit 24c06560a7fa39049911eeb8777325d112e0deb9)
[Bug c/109151] UBsan misses a divide-by-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109151 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7d9f6140f0fdd59be002a2efb1d61939b29b450f commit r11-10726-g7d9f6140f0fdd59be002a2efb1d61939b29b450f Author: Jakub Jelinek Date: Fri Mar 17 16:10:14 2023 +0100 c, ubsan: Instrument even shortened divisions [PR109151] On the following testcase, the C FE decides to shorten the division because it has a guarantee that INT_MIN / -1 division won't be encountered, the first operand is widened from narrower unsigned and/or the second operand is a constant other than all ones (in this case both are true). The problem is that the narrower type in this case is _Bool and ubsan_instrument_division only instruments it if op0's type is INTEGER_TYPE or REAL_TYPE. Strangely this doesn't happen in C++ FE. Anyway, we only shorten divisions if the INT_MIN / -1 case is impossible, so I think we should be fine even with -fstrict-enums in C++ in case it shortened to ENUMERAL_TYPEs. The following patch just instruments those on the ubsan_instrument_division side. Perhaps only the first hunk and testcase might be needed because we shouldn't shorten if the other case could be triggered. 2023-03-17 Jakub Jelinek PR c/109151 * c-ubsan.c (ubsan_instrument_division): Handle all scalar integral types rather than just INTEGER_TYPE. * c-c++-common/ubsan/div-by-zero-8.c: New test. (cherry picked from commit 103d423f6ce72ccb03d55b7b1dfa2dabd5854371)
[Bug c++/109164] wrong code with thread_local reference, loops and -ftree-pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109164 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6a4942ac236ce46499073daed7ebb8fa272aa7fa commit r11-10728-g6a4942ac236ce46499073daed7ebb8fa272aa7fa Author: Jakub Jelinek Date: Mon Mar 20 20:29:47 2023 +0100 c++: Drop TREE_READONLY on vars (possibly) initialized by tls wrapper [PR109164] The following two testcases are miscompiled, because we keep TREE_READONLY on the vars even when they are (possibly) dynamically initialized by a TLS wrapper function. Normally cp_finish_decl drops TREE_READONLY from vars which need dynamic initialization, but for TLS we do this kind of initialization upon every access to those variables. Keeping them TREE_READONLY means e.g. PRE can hoist loads from those before loops which contain the TLS wrapper calls, so we can access the TLS variables before they are initialized. 2023-03-20 Jakub Jelinek PR c++/109164 * cp-tree.h (var_needs_tls_wrapper): Declare. * decl2.c (var_needs_tls_wrapper): No longer static. * decl.c (cp_finish_decl): Clear TREE_READONLY on TLS variables for which a TLS wrapper will be needed. * g++.dg/tls/thread_local13.C: New test. * g++.dg/tls/thread_local13-aux.cc: New file. * g++.dg/tls/thread_local14.C: New test. * g++.dg/tls/thread_local14-aux.cc: New file. (cherry picked from commit 0a846340b99675d57fc2f2923a0412134eed09d3)
[Bug middle-end/108685] [10/11 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:38812e9e87c4d42f1d9916788c92f17273d772dc commit r11-10725-g38812e9e87c4d42f1d9916788c92f17273d772dc Author: Jakub Jelinek Date: Fri Mar 17 08:46:28 2023 +0100 openmp: Fix up handling of doacross loops with noreturn body in loops [PR108685] The following patch fixes an ICE with doacross loops which have a single entry no exit body, at least one of the ordered > collapse loops isn't guaranteed to have at least one iteration and the whole doacross loop is inside some other loop. The OpenMP constructs aren't represented by struct loop until the omp expansions, so for a normal doacross loop which doesn't have a noreturn body the entry_bb with the GOMP_FOR statement and the first bb of the body typically have the same loop_father, and if the doacross loop isn't inside of some other loop and the body is noreturn as well, both are part of loop 0. The problematic case is when the entry_bb is inside of some deeper loop, but the body, because it falls through into EXIT, has loop 0 as loop_father. l0_bb is created by splitting the entry_bb fallthru edge into l1_bb, and because the two basic blocks have different loop_father, a common loop is found for those (which is loop 0). Now, if the doacross loop has collapse == ordered or all the ordered > collapse loops are guaranteed to iterate at least once, all is still fine, because all enter the l1_bb (body), which doesn't return and so doesn't loop further either. But, if one of those loops could loop 0 times, the user written body wouldn't be reached at all, so unlike the expectations the whole construct actually wouldn't be noreturn if entry_bb is encountered and decides to handle at least one iteration. In this case, we need to fix up, move the l0_bb into the same loop as entry_bb (initially) and for the extra added loops put them as children of that same loop, rather than of loop 0. 2023-03-17 Jakub Jelinek PR middle-end/108685 * omp-expand.c (expand_omp_for_ordered_loops): Add L0_BB argument, use its loop_father rather than BODY_BB's loop_father. (expand_omp_for_generic): Adjust expand_omp_for_ordered_loops caller. If broken_loop with ordered > collapse and at least one of those extra loops aren't guaranteed to have at least one iteration, change l0_bb's loop_father to entry_bb's loop_father. Set cont_bb's loop_father to l0_bb's loop_father rather than l1_bb's. * c-c++-common/gomp/doacross-8.c: New test. (cherry picked from commit 713fa5db8ceb4ba8783a0d690ceb4c07f2ff03d0)
[Bug c++/16965] [3.4/4.0 regression] Confusing mismatch in error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16965 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9d98f84ca37a154a24f3f2b2950bfb450cbe6316 commit r11-10719-g9d98f84ca37a154a24f3f2b2950bfb450cbe6316 Author: Jakub Jelinek Date: Fri Mar 3 00:40:13 2023 +0100 libquadmath: Assorted libquadmath strtoflt128 fixes [PR87204, PR94756] This patch cherry-pickx 8 commits from glibc which fix various strtod_l bugs. 2023-03-03 niXman Jakub Jelinek PR libquadmath/87204 PR libquadmath/94756 * strtod/strtod_l.c (round_and_return): Cherry-pick glibc 9310c284ae9 BZ #16151, 4406c41c1d6 BZ #16965 and fcd6b5ac36a BZ #23279 fixes. (STRTOF_INTERNAL): Cherry-pick glibc b0debe14fcf BZ #23007, 5556d30caee BZ #18247, 09555b9721d and c6aac3bf366 BZ #26137 and d84f25c7d87 fixes. (cherry picked from commit df63f4162c78ef799d4ea9dec3443d5e9c51e5aa)
[Bug target/18247] [4.0 regression] ada runtime bootstrap failure on powerpc-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18247 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9d98f84ca37a154a24f3f2b2950bfb450cbe6316 commit r11-10719-g9d98f84ca37a154a24f3f2b2950bfb450cbe6316 Author: Jakub Jelinek Date: Fri Mar 3 00:40:13 2023 +0100 libquadmath: Assorted libquadmath strtoflt128 fixes [PR87204, PR94756] This patch cherry-pickx 8 commits from glibc which fix various strtod_l bugs. 2023-03-03 niXman Jakub Jelinek PR libquadmath/87204 PR libquadmath/94756 * strtod/strtod_l.c (round_and_return): Cherry-pick glibc 9310c284ae9 BZ #16151, 4406c41c1d6 BZ #16965 and fcd6b5ac36a BZ #23279 fixes. (STRTOF_INTERNAL): Cherry-pick glibc b0debe14fcf BZ #23007, 5556d30caee BZ #18247, 09555b9721d and c6aac3bf366 BZ #26137 and d84f25c7d87 fixes. (cherry picked from commit df63f4162c78ef799d4ea9dec3443d5e9c51e5aa)
[Bug c++/109096] __has_unique_object_representations does not account for unnamed bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109096 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:66d35a0cb88f83f085b2ba4c46d0429ba0cfe574 commit r11-10724-g66d35a0cb88f83f085b2ba4c46d0429ba0cfe574 Author: Jakub Jelinek Date: Tue Mar 14 16:17:32 2023 +0100 c++: Treat unnamed bitfields as padding for __has_unique_object_representations [PR109096] As reported in the PR, for __has_unique_object_representations we were treating unnamed bitfields as named ones, which is wrong, they are actually padding. THe following patch fixes that. 2023-03-14 Jakub Jelinek PR c++/109096 * tree.c (record_has_unique_obj_representations): Ignore unnamed bitfields. * g++.dg/cpp1z/has-unique-obj-representations3.C: New test. (cherry picked from commit c35cf160a0ed81570cff6600dba465cf95fa80fa)
[Bug libquadmath/94756] strtoflt128 assigns some subnormals incorrectly on MS Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756 --- Comment #21 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9d98f84ca37a154a24f3f2b2950bfb450cbe6316 commit r11-10719-g9d98f84ca37a154a24f3f2b2950bfb450cbe6316 Author: Jakub Jelinek Date: Fri Mar 3 00:40:13 2023 +0100 libquadmath: Assorted libquadmath strtoflt128 fixes [PR87204, PR94756] This patch cherry-pickx 8 commits from glibc which fix various strtod_l bugs. 2023-03-03 niXman Jakub Jelinek PR libquadmath/87204 PR libquadmath/94756 * strtod/strtod_l.c (round_and_return): Cherry-pick glibc 9310c284ae9 BZ #16151, 4406c41c1d6 BZ #16965 and fcd6b5ac36a BZ #23279 fixes. (STRTOF_INTERNAL): Cherry-pick glibc b0debe14fcf BZ #23007, 5556d30caee BZ #18247, 09555b9721d and c6aac3bf366 BZ #26137 and d84f25c7d87 fixes. (cherry picked from commit df63f4162c78ef799d4ea9dec3443d5e9c51e5aa)
[Bug c++/16151] Poor diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16151 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9d98f84ca37a154a24f3f2b2950bfb450cbe6316 commit r11-10719-g9d98f84ca37a154a24f3f2b2950bfb450cbe6316 Author: Jakub Jelinek Date: Fri Mar 3 00:40:13 2023 +0100 libquadmath: Assorted libquadmath strtoflt128 fixes [PR87204, PR94756] This patch cherry-pickx 8 commits from glibc which fix various strtod_l bugs. 2023-03-03 niXman Jakub Jelinek PR libquadmath/87204 PR libquadmath/94756 * strtod/strtod_l.c (round_and_return): Cherry-pick glibc 9310c284ae9 BZ #16151, 4406c41c1d6 BZ #16965 and fcd6b5ac36a BZ #23279 fixes. (STRTOF_INTERNAL): Cherry-pick glibc b0debe14fcf BZ #23007, 5556d30caee BZ #18247, 09555b9721d and c6aac3bf366 BZ #26137 and d84f25c7d87 fixes. (cherry picked from commit df63f4162c78ef799d4ea9dec3443d5e9c51e5aa)
[Bug middle-end/106190] [10/11 Regression] ICE in expand_builtin_eh_common with -fnon-call-exceptions -fsanitize=address,undefined -fno-sanitize-recover=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106190
--- Comment #13 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:b6d67e397215fbfc408d0282be4522895717bf74
commit r11-10732-gb6d67e397215fbfc408d0282be4522895717bf74
Author: Jakub Jelinek
Date: Tue Mar 28 10:56:44 2023 +0200
sanopt: Return TODO_cleanup_cfg if any .{UB,HWA,A}SAN_* calls were lowered
[PR106190]
The following testcase ICEs, because without optimization eh lowering
decides not to duplicate finally block of try/finally and so we end up
with variable guarded cleanup. The sanopt pass creates a cfg that ought
to be cleaned up (some IFN_UBSAN_* functions are lowered in this case with
constant conditions in gcond and when not allowing recovery some bbs which
end with noreturn calls actually have successor edges), but the cfg cleanup
is actually (it is -O0) done only during the optimized pass. We notice
there that the d[1][a] = 0; statement which has an EH edge is unreachable
(because ubsan would always abort on the out of bounds d[1] access), remove
the EH landing pad and block, but because that block just sets a variable
and jumps to another one which tests that variable and that one is
reachable
from normal control flow, the __builtin_eh_pointer (1) later in there is
kept in the IL and we ICE during expansion of that statement because the
EH region has been removed.
The following patch fixes it by doing the cfg cleanup already during
sanopt pass if we create something that might need it, while the EH
landing pad is then removed already during sanopt pass, there is ehcleanup
later and we don't ICE anymore.
2023-03-28 Jakub Jelinek
PR middle-end/106190
* sanopt.c (pass_sanopt::execute): Return TODO_cleanup_cfg if any
of the IFN_{UB,HWA,A}SAN_* internal fns are lowered.
* gcc.dg/asan/pr106190.c: New test.
(cherry picked from commit 39a43dc336561e0eba0de477b16c7355f19d84ee)
[Bug c++/107558] [10/11 Regression] ICE in fld_incomplete_type_of with -fmerge-all-constants and openmp and LTO since r11-16-ga2f32550a085984f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107558
--- Comment #7 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:17125f2f898828bd21e6215d9063dbca094c7a04
commit r11-10723-g17125f2f898828bd21e6215d9063dbca094c7a04
Author: Jakub Jelinek
Date: Fri Mar 10 20:38:13 2023 +0100
c++: Don't clear TREE_READONLY for -fmerge-all-constants for non-aggregates
[PR107558]
The following testcase ICEs, because OpenMP lowering for shared clause
on l variable with REFERENCE_TYPE creates POINTER_TYPE to REFERENCE_TYPE.
The reason is that the automatic variable has non-trivial construction
(reference to a lambda) and -fmerge-all-constants is on and so
TREE_READONLY
isn't set - omp-low will handle automatic TREE_READONLY vars in shared
specially and only copy to the construct and not back, while !TREE_READONLY
are assumed to be changeable.
The PR91529 change rationale was that the gimplification can change
some non-addressable automatic variables to TREE_STATIC with
-fmerge-all-constants and therefore TREE_READONLY on them is undesirable.
But, the gimplifier does that only for aggregate variables:
switch (TREE_CODE (type))
{
case RECORD_TYPE:
case UNION_TYPE:
case QUAL_UNION_TYPE:
case ARRAY_TYPE:
and not for anything else. So, I think clearing TREE_READONLY for
automatic integral or reference or pointer etc. vars for
-fmerge-all-constants only is unnecessary.
2023-03-10 Jakub Jelinek
PR c++/107558
* decl.c (cp_finish_decl): Don't clear TREE_READONLY on
automatic non-aggregate variables just because of
-fmerge-all-constants.
* g++.dg/gomp/pr107558.C: New test.
(cherry picked from commit 60b6f5c0a334db3f8f6dffaf0b9aab42fd5c54a2)
[Bug libquadmath/87204] strtoflt128 produces different results for subnormals with -m32 and -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87204 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9d98f84ca37a154a24f3f2b2950bfb450cbe6316 commit r11-10719-g9d98f84ca37a154a24f3f2b2950bfb450cbe6316 Author: Jakub Jelinek Date: Fri Mar 3 00:40:13 2023 +0100 libquadmath: Assorted libquadmath strtoflt128 fixes [PR87204, PR94756] This patch cherry-pickx 8 commits from glibc which fix various strtod_l bugs. 2023-03-03 niXman Jakub Jelinek PR libquadmath/87204 PR libquadmath/94756 * strtod/strtod_l.c (round_and_return): Cherry-pick glibc 9310c284ae9 BZ #16151, 4406c41c1d6 BZ #16965 and fcd6b5ac36a BZ #23279 fixes. (STRTOF_INTERNAL): Cherry-pick glibc b0debe14fcf BZ #23007, 5556d30caee BZ #18247, 09555b9721d and c6aac3bf366 BZ #26137 and d84f25c7d87 fixes. (cherry picked from commit df63f4162c78ef799d4ea9dec3443d5e9c51e5aa)
[Bug ipa/105685] [10/11 Regression] Bogus `-Wsuggest-attribute=cold` on function already marked as `__attribute__((cold))`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105685 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c448f0d85c778eade1d8ae597744f6455285346f commit r11-10730-gc448f0d85c778eade1d8ae597744f6455285346f Author: Jakub Jelinek Date: Sun Mar 26 20:15:05 2023 +0200 predict: Don't emit -Wsuggest-attribute=cold warning for functions which already have that attribute [PR105685] In the following testcase, we predict baz to have cold entry regardless of the user supplied attribute (as it call unconditionally a cold function), but still issue a -Wsuggest-attribute=cold warning despite it having that attribute already. The following patch avoids that. 2023-03-26 Jakub Jelinek PR ipa/105685 * predict.c (compute_function_frequency): Don't call warn_function_cold if function already has cold attribute. * c-c++-common/cold-2.c: New test. (cherry picked from commit 7eca91d4781bb3df941f25c30b971dac66ba1b3d)
[Bug c/107465] [10/11 Regression] Bogus warning: promoted bitwise complement of an unsigned value is always nonzero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107465
--- Comment #15 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:043793b1c11c51975d80454e99f0f3842e8ab2db
commit r11-10721-g043793b1c11c51975d80454e99f0f3842e8ab2db
Author: Jakub Jelinek
Date: Sat Mar 4 10:18:37 2023 +0100
c-family: Fix up -Wsign-compare BIT_NOT_EXPR handling [PR107465]
The following patch fixes multiple bugs in warn_for_sign_compare related to
the BIT_NOT_EXPR related warnings.
My understanding is that what those 3 warnings are meant to warn (since
1995
apparently) is the case where we have BIT_NOT_EXPR of a zero-extended
value, so in result_type the value is something like:
0b (e.g. ~ of a 8->16 bit zero extension)
0b (e.g. ~ of a 8->16 bit zero extension
then zero extended to 32 bits)
0b (e.g. ~ of a 8->16 bit zero extension
then sign extended to 32 bits)
and the intention of the warning is to warn when this is compared against
something that has some 0 bits at the place where the above has guaranteed
1 bits, either ensured through comparison against constant where we know
the bits exactly, or through zero extension from some narrower type where
again we know at least some upper bits are zero extended.
The bugs in the warning code are:
1) misunderstanding of the {,c_common_}get_narrower APIs - the unsignedp
it sets is only meaningful if the function actually returns something
narrower (in that case it says whether the narrower value is then
sign (0) or zero (1) extended to the originally passed value.
Though op0 or op1 at this point might be already narrower than
result_type, and if the function doesn't return anything narrower,
it all depends on whether the passed in op{0,1} had TYPE_UNSIGNED
type or not
2) the code didn't check at all whether the BIT_NOT_EXPR operand
was actually zero extended (i.e. that it was narrower and unsignedp
was set to 1 for it), all it did is check that unsignedp from the
call was 1. But that isn't well defined thing, if the argument
is returned as is, the function sets unsignedp to 0, but if there
is e.g. a useless cast to the same or compatible type in between,
it can return 1 if the cast is unsigned; now, if BIT_NOT_EXPR
operand is not zero extended, we know nothing at all about any bits
in the operand containing BIT_NOT_EXPR, so there is nothing to warn
about
3) the code was actually testing both operands after calling
c_common_get_narrower on them and on the one with BIT_NOT_EXPR
again for constants; I think that is just wrong in case the BIT_NOT_EXPR
operand wouldn't be fully folded, the warning makes sense only if the
other operand not having BIT_NOT_EXPR in it is constant
4) as can be seen from the above bit pattern examples, the upper bits above
(in the patch arg0) aren't always all 1s, there could be some zero
extension
above it and from it one would have 0s, so that needs to be taken into
account for the choice which constant bits to test for being always set
otherwise warning is emitted, or for the zero extension guaranteed zero
bits
5) the patch also simplifies the handling, we only do it if one but not
both operands are BIT_NOT_EXPR after first {,c_common_}get_narrower,
so we can just use std::swap to ensure it is the first one
6) the code compared bits against HOST_BITS_PER_LONG, which made sense
back in 1995 when the values were stored into long, but now that they
are HOST_WIDE_INT should test HOST_BITS_PER_WIDE_INT (or we could
rewrite
the stuff to wide_int, not done in the patch)
2023-03-04 Jakub Jelinek
PR c/107465
* c-warn.c (warn_for_sign_compare): If c_common_get_narrower
doesn't return a narrower result, use TYPE_UNSIGNED to set
unsignedp0
and unsignedp1. For the one BIT_NOT_EXPR case vs. one without,
only check for constant in the non-BIT_NOT_EXPR operand, use
std::swap
to simplify the code, only warn if BIT_NOT_EXPR operand is extended
from narrower unsigned, fix up computation of mask for the constant
cases and for unsigned other operand case handle differently
BIT_NOT_EXPR result being sign vs. zero extended.
* c-c++-common/Wsign-compare-2.c: New test.
* c-c++-common/pr107465.c: New test.
(cherry picked from commit daaf74a714c41c8dbaf9954bcc58462c63062b4f)
[Bug target/100758] __builtin_cpu_supports does not (always) detect "sse2"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
--- Comment #26 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:7fce881241b4f6492d8d321322fcb3412dea2137
commit r11-10713-g7fce881241b4f6492d8d321322fcb3412dea2137
Author: Jakub Jelinek
Date: Thu Feb 9 17:43:19 2023 +0100
i386: Call get_available_features for all CPUs with max_level >= 1
[PR100758]
get_available_features doesn't depend on cpu_model2->__cpu_{family,model}
and just sets stuff up based on CPUID leaf 1, or some extended ones,
so I wonder why are we calling it separately for Intel, AMD and Zhaoxin
and not for all other CPUs too? I think various programs in the wild
which aren't using __builtin_cpu_{is,supports} just check the various CPUID
leafs and query bits in there, without blacklisting unknown CPU vendors,
so I think even __builtin_cpu_supports ("sse2") etc. should be reliable
if those VENDOR_{CENTAUR,CYRIX,NSC,OTHER} CPUs set those bits in CPUID leaf
1 or some extended ones. Calling it for all CPUs also means it can be
inlined because there will be just a single caller.
I have tested it on Intel and Martin tested it on AMD, but can't test it
on non-Intel/AMD; for Intel/AMD/Zhaoxin it should be really no change in
behavior.
2023-02-09 Jakub Jelinek
PR target/100758
* common/config/i386/cpuinfo.h (cpu_indicator_init): Call
get_available_features for all CPUs with max_level >= 1, rather
than just Intel or AMD.
(cherry picked from commit b24e9c083093a9e1b1007933a184c02f7ff058db)
[Bug debug/108716] [10/11 Regression] Incorrect DW_AT_decl_{line,column} in DW_TAG_imported_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108716 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2a6b112404837a3119985b58b886f63a88ec2cab commit r11-10718-g2a6b112404837a3119985b58b886f63a88ec2cab Author: Jakub Jelinek Date: Thu Mar 2 19:17:52 2023 +0100 c++, debug: Fix up locus of DW_TAG_imported_module [PR108716] Before IMPORTED_DECL has been introduced in PR37410, we used to emit correct DW_AT_decl_line on DW_TAG_imported_module on the testcase below, after that change we haven't emitted it at all for a while and after some time started emitting incorrect locus, in particular the location of } closing the function. The problem is that while we have correct EXPR_LOCATION on the USING_STMT, when genericizing that USING_STMT into IMPORTED_DECL we don't copy the location to DECL_SOURCE_LOCATION, so it gets whatever input_location happens to be when it is created. 2023-03-02 Jakub Jelinek PR debug/108716 * cp-gimplify.c (cp_genericize_r) : Set DECL_SOURCE_LOCATION on IMPORTED_DECL to expression location of USING_STMT or input_location. * g++.dg/debug/dwarf2/pr108716.C: New test. (cherry picked from commit 4d82022bfd15d36717bf60a11e75e9ea02204269)
[Bug c++/108474] static structured binding undefined reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108474
--- Comment #5 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:bc75dd303c8f8aa6191670ce3725d26e8011f5ac
commit r11-10712-gbc75dd303c8f8aa6191670ce3725d26e8011f5ac
Author: Jakub Jelinek
Date: Tue Jan 24 11:28:00 2023 +0100
c++: Handle structured bindings like anon unions in initializers [PR108474]
As reported by Andrew Pinski, structured bindings (with the exception
of the ones using std::tuple_{size,element} and get which are really
standalone variables in addition to the binding one) also use
DECL_VALUE_EXPR and needs the same treatment in static initializers.
On Sun, Jan 22, 2023 at 07:19:07PM -0500, Jason Merrill wrote:
> Though, actually, why not instead fix expand_expr_real_1 (and staticp) to
> look through DECL_VALUE_EXPR?
Doing it when emitting the initializers seems to be too late to me,
we in various spots try to put parts of the static var DECL_INITIAL
expressions
into the IL, or e.g. for varpool purposes remember which vars are
referenced
there.
This patch moves it to record_reference, which is called from
varpool_node::analyze
and so about the same time as gimplification of the bodies which also
replaces DECL_VALUE_EXPRs.
2023-01-24 Jakub Jelinek
PR c++/108474
* cp-gimplify.c (cp_fold_r): Handle structured bindings
vars like anon union artificial vars.
* g++.dg/cpp1z/decomp57.C: New test.
* g++.dg/cpp1z/decomp58.C: New test.
(cherry picked from commit b84e21115700523b4d0ac44275443f7b9c670344)
[Bug target/108881] "__builtin_ia32_cvtne2ps2bf16_v16hi" compiled only with option -mavx512bf16 report ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108881 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:37c61035d754f4e4c074a8fd5cc996ffee34 commit r11-10715-g37c61035d754f4e4c074a8fd5cc996ffee34 Author: Jakub Jelinek Date: Fri Feb 24 10:12:44 2023 +0100 i386: Fix up builtins used in avx512bf16vlintrin.h [PR108881] The builtins used in avx512bf16vlintrin.h implementation need both avx512bf16 and avx512vl ISAs, which the header ensures for them, but the builtins weren't actually requiring avx512vl, so when used by hand with just -mavx512bf16 -mno-avx512vl it resulted in ICEs. Fixed by adding OPTION_MASK_ISA_AVX512VL to their BDESC. 2023-02-24 Jakub Jelinek PR target/108881 * config/i386/i386-builtin.def (__builtin_ia32_cvtne2ps2bf16_v16hi, __builtin_ia32_cvtne2ps2bf16_v16hi_mask, __builtin_ia32_cvtne2ps2bf16_v16hi_maskz, __builtin_ia32_cvtne2ps2bf16_v8hi, __builtin_ia32_cvtne2ps2bf16_v8hi_mask, __builtin_ia32_cvtne2ps2bf16_v8hi_maskz, __builtin_ia32_cvtneps2bf16_v8sf_mask, __builtin_ia32_cvtneps2bf16_v8sf_maskz, __builtin_ia32_cvtneps2bf16_v4sf_mask, __builtin_ia32_cvtneps2bf16_v4sf_maskz, __builtin_ia32_dpbf16ps_v8sf, __builtin_ia32_dpbf16ps_v8sf_mask, __builtin_ia32_dpbf16ps_v8sf_maskz, __builtin_ia32_dpbf16ps_v4sf, __builtin_ia32_dpbf16ps_v4sf_mask, __builtin_ia32_dpbf16ps_v4sf_maskz): Require also OPTION_MASK_ISA_AVX512VL. * gcc.target/i386/avx512bf16-pr108881.c: New test. (cherry picked from commit 0ccfa3884f638816af0f5a3f0ee2695e0771ef6d)
[Bug debug/108967] [11 Regression] internal compiler error: in expand_debug_expr, at cfgexpand.cc:5450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108967
--- Comment #11 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:54b240621d372e63d8fcacae591e39b36634ac18
commit r11-10717-g54b240621d372e63d8fcacae591e39b36634ac18
Author: Jakub Jelinek
Date: Wed Mar 1 10:26:46 2023 +0100
cfgexpand: Handle WIDEN_{PLUS,MINUS}_EXPR and
VEC_WIDEN_{PLUS,MINUS}_{HI,LO}_EXPR in expand_debug_expr [PR108967]
When these tree codes were introduced, expand_debug_expr hasn't been
updated to handle them. For the VEC_*_EXPR we currently mostly punt, the
non-vector ones can be handled easily. In release compilers this doesn't
ICE, but with checking we ICE so that we make sure to handle all the needed
tree codes there.
2023-03-01 Jakub Jelinek
PR debug/108967
* cfgexpand.c (expand_debug_expr): Handle WIDEN_{PLUS,MINUS}_EXPR
and VEC_WIDEN_{PLUS,MINUS}_{HI,LO}_EXPR.
* g++.dg/debug/pr108967.C: New test.
(cherry picked from commit 520403f324a6ed8b527f39239709dd0841b992e2)
[Bug libstdc++/109703] [12/13/14 Regression] __builtin_unreachable() reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109703 Andrew Pinski changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/108854] [10/11 Regression] tbb-2021.8.0 fails on i686-linux (32-bit), internal compiler error: in expand_expr_real_1, at expr.c:10281 since r10-4511-g6cf67b62c8cda035dccac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108854 --- Comment #17 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cc83670c07ff3e0b55e04b64975eb6d4dbfeff5f commit r11-10716-gcc83670c07ff3e0b55e04b64975eb6d4dbfeff5f Author: Jakub Jelinek Date: Fri Feb 24 11:05:27 2023 +0100 cgraphclones: Don't share DECL_ARGUMENTS between thunk and its artificial thunk [PR108854] The following testcase ICEs on x86_64-linux with -m32. The problem is we create an artificial thunk and because of -fPIC, ia32 and thunk destination which doesn't bind locally can't use a mi thunk. The ICE is because during expansion to RTL we see SSA_NAME for a PARM_DECL, but the PARM_DECL doesn't have DECL_CONTEXT of the current function. This is because duplicate_thunk_for_node creates a new DECL_ARGUMENTS chain only if some arguments need modification. The following patch fixes it by copying the DECL_ARGUMENTS list even if the arguments can stay as is, to update DECL_CONTEXT on them. While for mi thunks it doesn't really matter because we don't use those arguments in any way, for other thunks it is important. 2023-02-23 Jakub Jelinek PR middle-end/108854 * cgraphclones.c (duplicate_thunk_for_node): If no parameter changes are needed, copy at least DECL_ARGUMENTS PARM_DECL nodes and adjust their DECL_CONTEXT. * g++.dg/opt/pr108854.C: New test. (cherry picked from commit 2f1691be517fcdcabae9cd671ab511eb0e08b1d5)
[Bug c/107465] [10/11 Regression] Bogus warning: promoted bitwise complement of an unsigned value is always nonzero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107465 --- Comment #16 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c61635e87903797b7e5b71683be93534290118e2 commit r11-10722-gc61635e87903797b7e5b71683be93534290118e2 Author: Jakub Jelinek Date: Sat Mar 4 10:21:45 2023 +0100 c-family: Incremental fix for -Wsign-compare BIT_NOT_EXPR handling [PR107465] There can be too many extensions and seems I didn't get everything right in the previously posted patch. The following incremental patch ought to fix that. The code can deal with quite a few sign/zero extensions at various spots and it is important to deal with all of them right. On the argument that contains BIT_NOT_EXPR we have: MSB bits#4 bits#3 BIT_NOT_EXPR bits#2 bits#1 LSB where bits#1 is one or more bits (TYPE_PRECISION (TREE_TYPE (arg0)) at the end of the function) we don't know anything about, for the purposes of this warning it is VARYING that is inverted with BIT_NOT_EXPR to some other VARYING bits; bits#2 is one or more bits (TYPE_PRECISION (TREE_TYPE (op0)) - TYPE_PRECISION (TREE_TYPE (arg0)) at the end of the function) which are known to be 0 before the BIT_NOT_EXPR and 1 after it. bits#3 is zero or more bits from the TYPE_PRECISION (TREE_TYPE (op0)) at the end of function to the TYPE_PRECISION (TREE_TYPE (op0)) at the end of the function to TYPE_PRECISION (TREE_TYPE (op0)) at the start of the function, which are either zero extension or sign extension. And bits#4 is zero or more bits from the TYPE_PRECISION (TREE_TYPE (op0)) at the start of the function to TYPE_PRECISION (result_type), which again can be zero or sign extension. Now, vanilla trunk as well as the previously posted patch mishandles the case where bits#3 are sign extended (as bits#2 are known to be all set, that means bits#3 are all set too) but bits#4 are zero extended and are thus all 0. The patch fixes it by tracking the lowest bit which is known to be clear above the known to be set bits (if any, otherwise it is precision of result_type). 2023-03-04 Jakub Jelinek PR c/107465 * c-warn.c (warn_for_sign_compare): Don't warn for unset bits above innermost zero extension of BIT_NOT_EXPR result. * c-c++-common/Wsign-compare-2.c (f18): New test. (cherry picked from commit 3ec9a8728086ad86a2d421e067329f305f40e005)
[Bug middle-end/108435] [13 Regression] ICE in as_a, at is-a.h:242 since r13-142-g705bcedf6eae2d7c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108435
--- Comment #9 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:8dbd2cd0729f928cbb0d71d0cebcc8891185d771
commit r11-10707-g8dbd2cd0729f928cbb0d71d0cebcc8891185d771
Author: Jakub Jelinek
Date: Thu Feb 2 09:54:18 2023 +0100
nested, openmp: Wrap OMP_CLAUSE_*_GIMPLE_SEQ into GIMPLE_BIND for
declare_vars [PR108435]
When gimplifying OMP_CLAUSE_{LASTPRIVATE,LINEAR}_STMT, we wrap it always
into a GIMPLE_BIND, but when putting statements directly into
OMP_CLAUSE_{LASTPRIVATE,LINEAR}_GIMPLE_SEQ, we do it only if needed (there
are any temporaries that need to be declared in the sequence).
convert_nonlocal_omp_clauses was relying on the GIMPLE_BIND to be there
always
because it called declare_vars on it.
The following patch wraps it into GIMPLE_BIND in tree-nested if we need to
declare_vars on it on demand.
2023-02-02 Jakub Jelinek
PR middle-end/108435
* tree-nested.c (convert_nonlocal_omp_clauses)
: If info->new_local_var_chain and
*seq
is not a GIMPLE_BIND, wrap the sequence into a new GIMPLE_BIND
before calling declare_vars.
(convert_nonlocal_omp_clauses) : Merge
with the OMP_CLAUSE_LASTPRIVATE handling except for whether
seq is initialized to _CLAUSE_LASTPRIVATE_GIMPLE_SEQ (clause)
or _CLAUSE_LINEAR_GIMPLE_SEQ (clause).
* gcc.dg/gomp/pr108435.c: New test.
(cherry picked from commit 0f349928e16fdc7dba52561e8d40347909f9f0ff)
[Bug testsuite/108973] [10/11 Regression] Sufficiently narrow terminal window causes selftest failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108973 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8b564ac2db506189c87b2871d9fc0fb994b809a5 commit r11-10720-g8b564ac2db506189c87b2871d9fc0fb994b809a5 Author: Jakub Jelinek Date: Sat Mar 4 09:48:17 2023 +0100 diagnostics: Fix up selftests with $COLUMNS < 42 [PR108973] As mentioned in the PR, GCC's diagnostics self-tests fail if $COLUMNS < 42. Guarding each self-test with if (get_terminal_width () > 41) or similar would be a maintainance nightmare (PR has a patch to do so without reformatting to make it work for $COLUMNS in [30, 41] inclusive, but I'm afraid going down to $COLUMNS 1 would mean marking everything). Furthermore, the self-tests don't really emit stuff to the terminal, but into a buffer, so using get_terminal_width () for it seems inappropriate. The following patch makes sure test_diagnostic_context constructor uses exactly 80 columns wide caret max width, of course some tests override it already if they want to test for behavior in narrower cases. 2023-03-04 Jakub Jelinek PR testsuite/108973 * selftest-diagnostic.c (test_diagnostic_context::test_diagnostic_context): Set caret_max_width to 80. (cherry picked from commit 739e7ebb3d378ece25d64b39baae47c584253498)
[Bug tree-optimization/108692] [11 Regression] Miscompilation of orc_test.c since r11-5160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108692
--- Comment #8 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:eadc8fd8d7fd509b001fcdbe160e2d6862c745a4
commit r11-10709-geadc8fd8d7fd509b001fcdbe160e2d6862c745a4
Author: Jakub Jelinek
Date: Wed Feb 8 18:41:21 2023 +0100
vect-patterns: Fix up vect_widened_op_tree [PR108692]
The following testcase is miscompiled on aarch64-linux since r11-5160.
Given
[local count: 955630225]:
# i_22 = PHI
# r_23 = PHI
...
a.0_5 = (unsigned char) a_15;
_6 = (int) a.0_5;
b.1_7 = (unsigned char) b_17;
_8 = (int) b.1_7;
c_18 = _6 - _8;
_9 = ABS_EXPR ;
r_19 = _9 + r_23;
...
where SSA_NAMEs 15/17 have signed char, 5/7 unsigned char and rest is int
we first pattern recognize c_18 as
patt_34 = (a.0_5) w- (b.1_7);
which is still correct, 5/7 are unsigned char subtracted in wider type,
but then vect_recog_sad_pattern turns it into
SAD_EXPR
which is incorrect, because 15/17 are signed char and so it is
sum of absolute signed differences rather than unsigned sum of
absolute unsigned differences.
The reason why this happens is that vect_recog_sad_pattern calls
vect_widened_op_tree with MINUS_EXPR, WIDEN_MINUS_EXPR on the
patt_34 = (a.0_5) w- (b.1_7); statement's vinfo and vect_widened_op_tree
calls vect_look_through_possible_promotion on the operands of the
WIDEN_MINUS_EXPR, which looks through the further casts.
vect_look_through_possible_promotion has careful code to stop when there
would be nested casts that need to be preserved, but the problem here
is that the WIDEN_*_EXPR operation itself has an implicit cast on the
operands already - in this case of WIDEN_MINUS_EXPR the unsigned char
5/7 SSA_NAMEs are widened to unsigned short before the subtraction,
and vect_look_through_possible_promotion obviously isn't told about that.
Now, I think when we see those WIDEN_{MULT,MINUS,PLUS}_EXPR codes, we had
to look through possible promotions already when creating those and so
vect_look_through_possible_promotion again isn't really needed, all we need
to do is arrange what that function will do if the operand isn't result
of any cast. Other option would be let
vect_look_through_possible_promotion
know about the implicit promotion from the WIDEN_*_EXPR, but I'm afraid
that would be much harder.
2023-02-08 Jakub Jelinek
PR tree-optimization/108692
* tree-vect-patterns.c (vect_widened_op_tree): If rhs_code is
widened_code which is different from code, don't call
vect_look_through_possible_promotion but instead just check op is
SSA_NAME with integral type for which vect_is_simple_use is true
and call set_op on this_unprom.
* gcc.dg/pr108692.c: New test.
(cherry picked from commit 6ad1c1027628f094260037536f6b6fcdb63b5add)
[Bug other/108560] builtin_va_arg_pack_len is documented to return size_t, but actually returns int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108560 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4dd44d0c899897da041d2dcc088bed6e11abd80a commit r11-10703-g4dd44d0c899897da041d2dcc088bed6e11abd80a Author: Jakub Jelinek Date: Fri Jan 27 11:17:35 2023 +0100 doc: Fix up return type of __builtin_va_arg_pack_len [PR108560] __builtin_va_arg_pack_len as implemented returned int since its introduction in 2007. The initial documentation didn't mention any return type, which changed in 2010 in r0-103077-gab940b73bfabe2cec4 during some documentation formatting cleanups https://gcc.gnu.org/legacy-ml/gcc-patches/2010-09/msg01632.html I can understand that for formatting some type was needed there but what exactly hasn't been really discussed. So, I think we should change documentation to match the implementation, rather than change implementation to match the documentation. Most people don't use more than 2147483647 arguments to inline functions, and on poor targets with 16-bit ints I bet even having more than 65535 arguments to inline functions would be highly unexpected. 2023-01-27 Jakub Jelinek PR other/108560 * doc/extend.texi: Fix up return type of __builtin_va_arg_pack_len from size_t to int. (cherry picked from commit 16f30680f403891556da2ad6329fcef9dc9b47db)
[Bug tree-optimization/108688] [13 Regression] error: ‘bit_field_ref’ of non-mode-precision operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108688 --- Comment #14 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d87adfe1a6455025eb3ae787a6da245a62cdb446 commit r11-10710-gd87adfe1a6455025eb3ae787a6da245a62cdb446 Author: Andrew Pinski Date: Thu Feb 9 16:03:54 2023 +0100 match.pd: When simplifying BFR of an insert, require a mode precision integral type [PR108688] The same problem as PR 88739 has crept in but this time in match.pd when simplifying bit_field_ref of an bit_insert. That is we are generating a BIT_FIELD_REF of a non-mode-precision integral type. PR tree-optimization/108688 * match.pd (bit_field_ref [bit_insert]): Avoid generating BIT_FIELD_REFs of non-mode-precision integral operands. * gcc.c-torture/compile/pr108688-1.c: New test. (cherry picked from commit 44f308e59bfa0f93ae05b17e257d8563c12399fd)
[Bug target/26137] Cannot connect to target board h8 using GDB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26137 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9d98f84ca37a154a24f3f2b2950bfb450cbe6316 commit r11-10719-g9d98f84ca37a154a24f3f2b2950bfb450cbe6316 Author: Jakub Jelinek Date: Fri Mar 3 00:40:13 2023 +0100 libquadmath: Assorted libquadmath strtoflt128 fixes [PR87204, PR94756] This patch cherry-pickx 8 commits from glibc which fix various strtod_l bugs. 2023-03-03 niXman Jakub Jelinek PR libquadmath/87204 PR libquadmath/94756 * strtod/strtod_l.c (round_and_return): Cherry-pick glibc 9310c284ae9 BZ #16151, 4406c41c1d6 BZ #16965 and fcd6b5ac36a BZ #23279 fixes. (STRTOF_INTERNAL): Cherry-pick glibc b0debe14fcf BZ #23007, 5556d30caee BZ #18247, 09555b9721d and c6aac3bf366 BZ #26137 and d84f25c7d87 fixes. (cherry picked from commit df63f4162c78ef799d4ea9dec3443d5e9c51e5aa)
[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:658156714de37163d570ace3a868f23900b0efe9 commit r11-10708-g658156714de37163d570ace3a868f23900b0efe9 Author: Jakub Jelinek Date: Fri Feb 3 21:37:27 2023 +0100 fortran: Fix up hash table usage in gfc_trans_use_stmts [PR108451] The first testcase in the PR (which I haven't included in the patch because it is unclear to me if it is supposed to be valid or not) ICEs since extra hash table checking has been added recently. The problem is that gfc_trans_use_stmts does tree *slot = entry->decls->find_slot_with_hash (rent->use_name, hash, INSERT); if (*slot == NULL) and later on doesn't store anything into *slot and continues. Another spot a few lines later correctly clears the slot if it decides not to use the slot, so the following patch does the same. 2023-02-03 Jakub Jelinek PR fortran/108451 * trans-decl.c (gfc_trans_use_stmts): Call clear_slot before doing continue. (cherry picked from commit 76f7f0eddcb7c418d1ec3dea3e2341ca99097301)
[Bug tree-optimization/88739] [7 Regression] Big-endian union bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739 --- Comment #66 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d87adfe1a6455025eb3ae787a6da245a62cdb446 commit r11-10710-gd87adfe1a6455025eb3ae787a6da245a62cdb446 Author: Andrew Pinski Date: Thu Feb 9 16:03:54 2023 +0100 match.pd: When simplifying BFR of an insert, require a mode precision integral type [PR108688] The same problem as PR 88739 has crept in but this time in match.pd when simplifying bit_field_ref of an bit_insert. That is we are generating a BIT_FIELD_REF of a non-mode-precision integral type. PR tree-optimization/108688 * match.pd (bit_field_ref [bit_insert]): Avoid generating BIT_FIELD_REFs of non-mode-precision integral operands. * gcc.c-torture/compile/pr108688-1.c: New test. (cherry picked from commit 44f308e59bfa0f93ae05b17e257d8563c12399fd)
[Bug tree-optimization/108498] [11 Regression] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498 --- Comment #29 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ac66ee8147cc1501ce71324aea1c71f9498134af commit r11-10702-gac66ee8147cc1501ce71324aea1c71f9498134af Author: Jakub Jelinek Date: Wed Jan 25 10:50:27 2023 +0100 store-merging: Disable string_concatenate mode if start or end aren't byte aligned [PR108498] The first of the following testcases is miscompiled on powerpc64-linux -O2 -m64 at least, the latter at least on x86_64-linux -m32/-m64. Since GCC 11 store-merging has a separate string_concatenation mode which turns stores into setting a MEM_REF from a STRING_CST. This mode is triggered if at least one of the to be merged stores is a STRING_CST store and either the first store (to earliest address) is that STRING_CST store or the first store is 8-bit INTEGER_CST store and then there are some rules when to turn that mode off or not merge further stores into it. The problem with these 2 testcases is that the actual implementation relies on start/width of the store to be at byte boundaries, as it simply creates a char array, MEM_REF can be only on byte boundaries and the char array too, plus obviously STRING_CST as well. But as can be easily seen in the second testcase, nothing verifies this, while the first store has to be a STRING_CST (which will be aligned) or 8-bit INTEGER_CST, that 8-bit INTEGER_CST store could be a bitfield store, nothing verifies any stores in between whether they actually are 8-bit and aligned, the only major requirement is that all the stores are consecutive. For GCC 14 I think we should reconsider this, simply treat STRING_CST stores during the merging like INTEGER_CST stores and deal with it only during split_group where we can create multiple parts, this part would be a normal store, this part would be STRING_CST store, this part another normal store etc. But that is quite a lot of work, the following patch just disables the string_concatenate mode if boundaries aren't byte aligned in the spot where we disable it if it is too short too. If that happens, we'll just try to do the merging using normal 1/2/4/8 etc. byte stores as usually with RMW masking for any bits that shouldn't be touched or punt if we end up with too many stores compared to the original. Note, an original STRING_CST store will count as one store in that case, something we might want to reconsider later too (but, after all, CONSTRUCTOR stores (aka zeroing) already have the same problem, they can be large and expensive and we still count them as one store). 2023-01-25 Jakub Jelinek PR tree-optimization/108498 * gimple-ssa-store-merging.c (class store_operand_info): End coment with full stop rather than comma. (split_group): Likewise. (merged_store_group::apply_stores): Clear string_concatenation if start or end aren't on a byte boundary. * gcc.c-torture/execute/pr108498-1.c: New test. * gcc.c-torture/execute/pr108498-2.c: New test. (cherry picked from commit 617be7ba436bcbf9d7b883968c6b3c011206b56c)
[Bug c++/108607] [12 Regression] ICE in potential_constant_expression_1, at cp/constexpr.cc:10003
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108607
--- Comment #6 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:c5956b8cea7bf9b383a31af83e71f7cfc1a56bf1
commit r11-10705-gc5956b8cea7bf9b383a31af83e71f7cfc1a56bf1
Author: Jakub Jelinek
Date: Wed Feb 1 10:38:46 2023 +0100
c++, openmp: Handle some OMP_*/OACC_* constructs during constant expression
evaluation [PR108607]
While potential_constant_expression_1 handled most of OMP_* codes (by
saying that
they aren't potential constant expressions), OMP_SCOPE was missing in that
list.
I've also added OMP_SCAN, though that is less important (similarly to
OMP_SECTION
it ought to appear solely inside of OMP_{FOR,SIMD} resp. OMP_SECTIONS).
As the testcase shows, it isn't enough, potential_constant_expression_1
can catch only some cases, as soon as one uses switch or ifs where at least
one of the possible paths could be constant expression, we can run into the
same codes during cxx_eval_constant_expression, so this patch handles those
there as well.
2023-02-01 Jakub Jelinek
PR c++/108607
* constexpr.c (cxx_eval_constant_expression): Handle OMP_*
and OACC_* constructs as non-constant.
(potential_constant_expression_1): Handle OMP_SCAN.
* g++.dg/gomp/pr108607.C: New test.
(cherry picked from commit bfc070595bfb00abef88a002eee5d9117f5b86a7)
[Bug c++/108365] [10/11 Regression] Wrong code with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108365
--- Comment #11 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:77df8c7fc78b4ea7dc340f9f0fc239032ce0f9dd
commit r11-10711-g77df8c7fc78b4ea7dc340f9f0fc239032ce0f9dd
Author: Jakub Jelinek
Date: Sat Jan 14 10:17:14 2023 +0100
c++: Avoid incorrect shortening of divisions [PR108365]
The following testcase is miscompiled, because we shorten the division
in a case where it should not be shortened.
Divisions (and modulos) can be shortened if it is unsigned division/modulo,
or if it is signed division/modulo where we can prove the dividend will
not be the minimum signed value or divisor will not be -1, because e.g.
on sizeof(long long)==sizeof(int)*2 && __INT_MAX__ == 0x7fff targets
(-2147483647 - 1) / -1 is UB
but
(int) (-2147483648LL / -1LL) is not, it is -2147483648.
The primary aim of both the C and C++ FE division/modulo shortening I
assume
was for the implicit integral promotions of {,signed,unsigned} {char,short}
and because at this point we have no VRP information etc., the shortening
is done if the integral promotion is from unsigned type for the divisor
or if the dividend is an integer constant other than -1.
This works fine for char/short -> int promotions when char/short have
smaller precision than int - unsigned char -> int or unsigned short -> int
will always be a positive int, so never the most negative.
Now, the C FE checks whether orig_op0 is TYPE_UNSIGNED where op0 is either
the same as orig_op0 or that promoted to int, I think that works fine,
if it isn't promoted, either the division/modulo common type will have the
same precision as op0 but then the division/modulo is unsigned and so
without UB, or it will be done in wider precision (e.g. because op1 has
wider precision), but then op0 can't be minimum signed value. Or it has
been promoted to int, but in that case it was again from narrower type and
so never minimum signed int.
But the C++ FE was checking if op0 is a NOP_EXPR from TYPE_UNSIGNED.
First of all, not sure if the operand of NOP_EXPR couldn't be non-integral
type where TYPE_UNSIGNED wouldn't be meaningful, but more importantly,
even if it is a cast from unsigned integral type, we only know it can't be
minimum signed value if it is a widening cast, if it is same precision or
narrowing cast, we know nothing.
So, the following patch for the NOP_EXPR cases checks just in case that
it is from integral type and more importantly checks it is a widening
conversion.
2023-01-14 Jakub Jelinek
PR c++/108365
* typeck.c (cp_build_binary_op): For integral division or modulo,
shorten if type0 is unsigned, or op0 is cast from narrower unsigned
integral type or stripped_op1 is INTEGER_CST other than -1.
* g++.dg/opt/pr108365.C: New test.
* g++.dg/warn/pr108365.C: New test.
(cherry picked from commit 5b3a88640f962d4ffca31ae651bed2d8672f1a8c)
[Bug rtl-optimization/108596] [10/11 Regression] error: EDGE_CROSSING missing across section boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108596 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9a2302a2d268c5cd0b1016d916493d7cf78f495d commit r11-10704-g9a2302a2d268c5cd0b1016d916493d7cf78f495d Author: Jakub Jelinek Date: Tue Jan 31 09:46:35 2023 +0100 bbpart: Fix up ICE on asm goto [PR108596] On the following testcase we have asm goto in hot block with 2 successors, one cold to which it both falls through and has one of the label pointing to it and another hot successor with another label. Now, during bbpart we want to ensure that no blocks from one partition fall through into a block in a different partition. fix_up_fall_thru_edges does that by temporarily clearing the EDGE_CROSSING on the fallthrough edge, calling force_nonfallthru and then depending on whether it created a new bb either set EDGE_CROSSING on the single successor edge from the new bb (the new bb is kept in the same partition as the predecessor block), or if no new bb has been created setting EDGE_CROSSING back on the fallthru edge which has been forced non-EDGE_FALLTHRU. For asm goto this doesn't always work, force_nonfallthru can create a new bb and change the fallthrough edge to point to that, but if the original fallthru destination block has its label referenced among the asm goto labels, it will create a new non-fallthru edge for the label(s). But because we've temporarily cheated and cleared EDGE_CROSSING on the edge, it is cleared on the new edge as well, then the caller sees we've created a new bb and just sets EDGE_CROSSING on the single fallthru edge from the new bb. But the direct edge from cur_bb to fallthru edge's destination isn't handled and fails afterwards consistency checks, because it crosses partitions. The following patch notes the case and sets EDGE_CROSSING on that edge too. 2023-01-31 Jakub Jelinek PR rtl-optimization/108596 * bb-reorder.c (fix_up_fall_thru_edges): Handle the case where cur_bb ends with asm goto and has a crossing fallthrough edge to the same bb that contains at least one of its labels by restoring EDGE_CROSSING flag even on possible edge from cur_bb to new_bb successor. * gcc.c-torture/compile/pr108596.c: New test. (cherry picked from commit 603a6fbcaac1e80aa90d1d26318c881a53473066)
[Bug middle-end/108237] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 at -O since r13-1085-g90467f0ad649d081
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108237
--- Comment #10 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:e7496d6571624547b52264b80469bd071217ae02
commit r11-10697-ge7496d6571624547b52264b80469bd071217ae02
Author: Jakub Jelinek
Date: Wed Jan 4 10:54:38 2023 +0100
generic-match-head: Don't assume GENERIC folding is done only early
[PR108237]
We ICE on the following testcase, because a valid V2DImode
!= comparison is folded into an unsupported V2DImode > comparison.
The match.pd pattern which does this looks like:
/* Transform comparisons of the form (X & Y) CMP 0 to X CMP2 Z
where ~Y + 1 == pow2 and Z = ~Y. */
(for cst (VECTOR_CST INTEGER_CST)
(for cmp (eq ne)
icmp (le gt)
(simplify
(cmp (bit_and:c@2 @0 cst@1) integer_zerop)
(with { tree csts = bitmask_inv_cst_vector_p (@1); }
(if (csts && (VECTOR_TYPE_P (TREE_TYPE (@1)) || single_use (@2)))
(with { auto optab = VECTOR_TYPE_P (TREE_TYPE (@1))
? optab_vector : optab_default;
tree utype = unsigned_type_for (TREE_TYPE (@1)); }
(if (target_supports_op_p (utype, icmp, optab)
|| (optimize_vectors_before_lowering_p ()
&& (!target_supports_op_p (type, cmp, optab)
|| !target_supports_op_p (type, BIT_AND_EXPR, optab
(if (TYPE_UNSIGNED (TREE_TYPE (@1)))
(icmp @0 { csts; })
(icmp (view_convert:utype @0) { csts; })
and that optimize_vectors_before_lowering_p () guarded stuff there
already deals with this problem, not trying to fold a supported comparison
into a non-supported one. The reason it doesn't work in this case is that
it isn't GIMPLE folding which does this, but GENERIC folding done during
forwprop4 - forward_propagate_into_comparison ->
forward_propagate_into_comparison_1
-> combine_cond_expr_cond -> fold_binary_loc -> generic_simplify
and we simply assumed that GENERIC folding happens only before
gimplification.
The following patch fixes that by checking cfun properties instead of
always returning true in those cases.
2023-01-04 Jakub Jelinek
PR middle-end/108237
* generic-match-head.c: Include tree-pass.h.
(canonicalize_math_p, optimize_vectors_before_lowering_p): Define
to false if cfun and cfun->curr_properties has PROP_gimple_opt_math
resp. PROP_gimple_lvec property set.
* gcc.c-torture/compile/pr108237.c: New test.
(cherry picked from commit 345dffd0d4ebff7e705dfff1a8a72017a167120a)
[Bug debug/108573] [13 Regression] '-fcompare-debug' failure (length) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108573 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c8aee6e44b5829ce3baafd358d2ff9f30ee7e88b commit r11-10706-gc8aee6e44b5829ce3baafd358d2ff9f30ee7e88b Author: Jakub Jelinek Date: Wed Feb 1 12:52:52 2023 +0100 ree: Fix -fcompare-debug issues in combine_reaching_defs [PR108573] The PR78437 r7-4871 changes made combine_reaching_defs punt on WORD_REGISTER_OPERATIONS targets if a setter of smaller than word register has wider uses. This unfortunately breaks -fcompare-debug, because if such a use appears only in DEBUG_INSN(s), while all other uses aren't wider than the setter, we can REE optimize it without -g and not with -g. Such decisions shouldn't be based on debug instructions. We could try to reset them or adjust in some other way after we decide to perform the change, but at least on the testcase which used to fail on riscv64-linux the (debug_insn 8 7 9 2 (var_location:HI s (minus:HI (subreg:HI (and:DI (reg:DI 10 a0 [160]) (const_int 1 [0x1])) 0) (subreg:HI (ashiftrt:DI (reg/v:DI 9 s1 [orig:151 l ] [151]) (debug_expr:SI D#1)) 0))) "pr108573.c":12:5 -1 (nil)) clearly doesn't care about the upper bits and I have hard time imaging how could one end up with DEBUG_INSN which actually cares about those upper bits. So, the following patch just ignores uses on DEBUG_INSNs in this case, if we run into something where we'd need to do something further later on, let's deal with it when we have a testcase for it. 2023-02-01 Jakub Jelinek PR debug/108573 * ree.c (combine_reaching_defs): Don't return false for paradoxical subregs in DEBUG_INSNs. * gcc.dg/pr108573.c: New test. (cherry picked from commit e4473d7cf871c8ddf8f22d105c5af6375ebe37bf)
[Bug middle-end/108264] [11 Regression] ICE compiling guacamole-server on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108264 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4e41fedf81fb08aa2204e16f2341c74711e022ae commit r11-10696-g4e41fedf81fb08aa2204e16f2341c74711e022ae Author: Jakub Jelinek Date: Tue Jan 3 12:13:24 2023 +0100 expr: Fix up store_expr into SUBREG_PROMOTED_* target [PR108264] The following testcase ICEs on s390x-linux (e.g. with -march=z13). The problem is that target is (subreg/s/u:SI (reg/v:DI 66 [ x+-4 ]) 4) and we call convert_move from temp to the SUBREG_REG of that, expecting to extend the value properly. That works nicely if temp has some scalar integer mode (or partial one), but ICEs when temp has V4QImode on the assertion that from and to modes have the same bitsize. store_expr generally allows say store from V4QI to SI target because they have the same size and if temp is a CONST_INT, we already have code to convert the constant properly, so the following patch just adds handling of non-scalar integer modes by converting them to the mode of target first before convert_move extends them. 2023-01-03 Jakub Jelinek PR middle-end/108264 * expr.c (store_expr): For stores into SUBREG_PROMOTED_* targets from source which doesn't have scalar integral mode first convert it to outer_mode. * gcc.dg/pr108264.c: New test. (cherry picked from commit 226a498733e7919de72eb6f1bf3e16883ad159f6)
[Bug bootstrap/90543] Build failure on MINGW for gcc-9.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90543 --- Comment #17 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:549331a55f88e338cb84890b2252c554b07c59ce commit r11-10701-g549331a55f88e338cb84890b2252c554b07c59ce Author: Eric Biggers Date: Tue Jan 24 11:54:41 2023 +0100 options: fix cl_target_option_print_diff() with strings Fix an obvious copy-and-paste error where ptr1 was used instead of ptr2. This bug caused the dump file produced by -fdump-ipa-inline-details to not correctly show the difference in target options when a function could not be inlined due to a target option mismatch. gcc/ChangeLog: PR bootstrap/90543 * optc-save-gen.awk: Fix copy-and-paste error. Signed-off-by: Eric Biggers (cherry picked from commit 9f0cb3368af735e95776769c4f28fa9cbb60eaf8)
[Bug middle-end/108459] [OpenMP] ICE during GIMPLE pass: ompexp (segfault) in expand_omp_for_init_counts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108459 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:23d16b36eb41366841af052c35f335f35ee203cc commit r11-10699-g23d16b36eb41366841af052c35f335f35ee203cc Author: Jakub Jelinek Date: Thu Jan 19 21:00:08 2023 +0100 openmp: Fix up OpenMP expansion of non-rectangular loops [PR108459] expand_omp_for_init_counts was using for the case where collapse(2) inner loop has init expression dependent on non-constant multiple of the outer iterator and the condition upper bound expression doesn't depend on the outer iterator fold_unary (NEGATE_EXPR, ...). This will just return NULL if it can't be folded, we need fold_build1 instead. 2023-01-19 Jakub Jelinek PR middle-end/108459 * omp-expand.c (expand_omp_for_init_counts): Use fold_build1 rather than fold_unary for NEGATE_EXPR. * testsuite/libgomp.c/pr108459.c: New test. (cherry picked from commit 46644ec99cb355845b23bb1d02775c057ed8ee88)
[Bug c++/53932] [10/11 Regression] C++ reference variable to member of anonymous union in global is error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53932 --- Comment #15 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:bd34d694f4c060c92aee0e09edf4c7e1d83807e5 commit r11-10700-gbd34d694f4c060c92aee0e09edf4c7e1d83807e5 Author: Jakub Jelinek Date: Thu Jan 19 23:27:34 2023 +0100 c++: Fix up handling of references to anon union members in initializers [PR53932] For anonymous union members we create artificial VAR_DECLs which have DECL_VALUE_EXPR for the actual COMPONENT_REF. That works just fine inside of functions (including global dynamic constructors), because during gimplification such VAR_DECLs are gimplified as their DECL_VALUE_EXPR. This is also done during regimplification. But references to these artificial vars in DECL_INITIAL expressions aren't ever replaced by the DECL_VALUE_EXPRs, so we end up either with link failures like on the testcase below, or worse ICEs with LTO. The following patch fixes those during cp_fully_fold_init where we already walk all the trees (!data->genericize means that function rather than cp_fold_function). 2023-01-19 Jakub Jelinek PR c++/53932 * cp-gimplify.c (cp_fold_r): During cp_fully_fold_init replace DECL_ANON_UNION_VAR_P VAR_DECLs with their corresponding DECL_VALUE_EXPR. * g++.dg/init/pr53932.C: New test. (cherry picked from commit 9b9a989adc042b304572fd6d4ade46b47be6ccb8)
[Bug rtl-optimization/108193] [13 Regression] ICE in do_SUBST, at combine.cc:700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108193 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:eaf236a4ca097727f721443b082d620b1503e61c commit r11-10694-geaf236a4ca097727f721443b082d620b1503e61c Author: Jakub Jelinek Date: Thu Dec 22 12:44:13 2022 +0100 cse: Fix up CSE const_anchor handling [PR108193] The following testcase ICEs on aarch64, because insert_const_anchor inserts invalid CONST_INT into the CSE tables - 0x8000 for SImode. The second hunk of the patch fixes that, the first one is to avoid triggering undefined behavior at compile time during compute_const_anchors computations - performing those additions and subtractions in HOST_WIDE_INT means it can overflow for certain constants. 2022-12-22 Jakub Jelinek PR rtl-optimization/108193 * cse.c (compute_const_anchors): Change n type to unsigned HOST_WIDE_INT, adjust comparison against it to avoid warnings. Formatting fix. (insert_const_anchor): Use gen_int_mode instead of GEN_INT. * gfortran.dg/pr108193.f90: New test. (cherry picked from commit 0cb5d7cdbab8e5f8359764ef5f62d93c2bc88552)
[Bug fortran/108349] LTO mismatch for __builtin_realloc between glibc and gfortran frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108349
--- Comment #8 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:d67efd5a4ff7ef0992c641b04b009195d872f7bd
commit r11-10698-gd67efd5a4ff7ef0992c641b04b009195d872f7bd
Author: Jakub Jelinek
Date: Wed Jan 11 10:40:54 2023 +0100
fortran: Fix up function types for realloc and sincos{,f,l} builtins
[PR108349]
As reported in the PR, the FUNCTION_TYPE for __builtin_realloc in the
Fortran FE is wrong since r0-100026-gb64fca63690ad which changed
- tmp = tree_cons (NULL_TREE, pvoid_type_node, void_list_node);
- tmp = tree_cons (NULL_TREE, size_type_node, tmp);
- ftype = build_function_type (pvoid_type_node, tmp);
+ ftype = build_function_type_list (pvoid_type_node,
+size_type_node, pvoid_type_node,
+NULL_TREE);
gfc_define_builtin ("__builtin_realloc", ftype, BUILT_IN_REALLOC,
"realloc", false);
The return type is correct, void *, but the first argument should be
void * too and only second one size_t, while the above change changed
realloc to be void *__builtin_realloc (size_t, void *);
I went through all other changes from that commit and found that
__builtin_sincos{,f,l} got broken as well, instead of the former
void __builtin_sincos{,f,l} (ftype, ftype *, ftype *);
where ftype is {double,float,long double} it is now incorrectly
void __builtin_sincos{,f,l} (ftype *, ftype *);
The following patch fixes that, plus some formatting issues around
the spots I've changed.
2023-01-11 Jakub Jelinek
PR fortran/108349
* f95-lang.c (gfc_init_builtin_function): Fix up function types
for BUILT_IN_REALLOC and BUILT_IN_SINCOS{F,,L}. Formatting fixes.
(cherry picked from commit 0986c351aa8a9f08b3cb614baec13564dd62c114)
[Bug testsuite/108151] gcc.dg/pr64536.c stores pointers in a long, broken for llp64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108151 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1de8310dd2c276eb9546a831b392a896e0ef5d89 commit r11-10691-g1de8310dd2c276eb9546a831b392a896e0ef5d89 Author: Jakub Jelinek Date: Mon Dec 19 13:49:52 2022 +0100 testsuite: Fix up pr64536.c for LLP64 targets [PR108151] The test casts a pointer to long, which is ok for ilp32 and lp64 targets but not for llp64 targets. Nothing reads the values later, it is a link test, so all we care about is that it is the same cast on s390x-linux where it used to fail before the PR64536 fix, and that we don't warn about it. 2022-12-19 Jakub Jelinek PR testsuite/108151 * gcc.dg/pr64536.c (bar): Use casts to __INTPTR_TYPE__ rather than long when casting pointer to integral type. (cherry picked from commit ea37e96a37b50dad17b91d46edc518bbb9132d8e)
[Bug c++/108180] [OpenMP] Passing a class member variable to firstprivate() erroneously calls its dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108180 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9eed31b91ce73a9499297bf8ef2c2b7ce4c8d79b commit r11-10693-g9eed31b91ce73a9499297bf8ef2c2b7ce4c8d79b Author: Jakub Jelinek Date: Wed Dec 21 09:05:27 2022 +0100 openmp: Don't try to destruct DECL_OMP_PRIVATIZED_MEMBER vars [PR108180] DECL_OMP_PRIVATIZED_MEMBER vars are artificial vars with DECL_VALUE_EXPR of this->field used just during gimplification and omp lowering/expansion to privatize individual fields in methods when needed. As the following testcase shows, when not in templates, they were handled right, but in templates we actually called cp_finish_decl on them and that can result in their destruction, which is obviously undesirable, we should only destruct the privatized copies of them created in omp lowering. Fixed thusly. 2022-12-21 Jakub Jelinek PR c++/108180 * pt.c (tsubst_expr): Don't call cp_finish_decl on DECL_OMP_PRIVATIZED_MEMBER vars. * testsuite/libgomp.c++/pr108180.C: New test. (cherry picked from commit 1119902b6c7c1c50123ed85ec1def8be4772d68c)
[Bug c++/107065] GCC treats rvalue as an lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107065 --- Comment #17 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:200854895c55ec999f38fce9086e711173a4a01a commit r11-10689-g200854895c55ec999f38fce9086e711173a4a01a Author: Jakub Jelinek Date: Thu Dec 15 19:17:45 2022 +0100 c++: Ensure !!var is not an lvalue [PR107065] The TRUTH_NOT_EXPR case in cp_build_unary_op is one of the spots where we somewhat fold immediately using invert_truthvalue_loc. I've tried using return build1_loc (location, TRUTH_NOT_EXPR, boolean_type_node, arg); in there instead, but unfortunately that regressed Wlogical-not-parentheses-*.c pr49706.c pr62199.c pr65120.c sequence-pt-1.C tests, so at least for backporting that doesn't seem to be a way to go. So, this patch instead wraps it into NON_LVALUE_EXPR if needed (which also need a tweak for some tests in the pr47906.c test, but nothing major), with the intent to make it backportable, and later I'll try to do further steps to avoid folding here prematurely. Most of the problems with build1 TRUTH_NOT_EXPR are that it doesn't even invert comparisons as most common case and lots of warning code isn't able to deal with ! around comparisons; so perhaps one way to do this would be fold by hand only invertable comparisons and for the rest create TRUTH_NOT_EXPR. 2022-12-15 Jakub Jelinek PR c++/107065 gcc/cp/ * typeck.c (cp_build_unary_op) : If invert_truthvalue_loc returns obvalue_p, wrap it into NON_LVALUE_EXPR. * parser.c (cp_parser_binary_expression): Don't call warn_logical_not_parentheses if current.lhs is a NON_LVALUE_EXPR of a decl with boolean type. gcc/testsuite/ * g++.dg/cpp0x/pr107065.C: New test. (cherry picked from commit 8b775b4c48a3cc4ef5c50e56144aea02da2e9cc6)
[Bug tree-optimization/108068] [10/11 Regression] decimal floating point signed zero is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108068 --- Comment #15 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d8f95474581843c605bb97ba83d482d642da3a1b commit r11-10695-gd8f95474581843c605bb97ba83d482d642da3a1b Author: Jakub Jelinek Date: Fri Dec 23 16:12:21 2022 +0100 tree-ssa-dom: can_infer_simple_equiv fixes [PR108068] As reported in the PR, tree-ssa-dom.cc uses real_zerop call to find if a floating point constant is zero and it shouldn't try to infer equivalences from comparison against it if signed zeros are honored. This doesn't work at all for decimal types, because real_zerop always returns false for them (one can have different representations of decimal zero beyond -0/+0), and it doesn't work for vector compares either, as real_zerop checks if all elements are zero, while we need to avoid infering equivalences from comparison against vector constants which have at least one zero element in it (if signed zeros are honored). Furthermore, as mentioned by Joseph, for decimal types many other values aren't singleton. So, this patch stops infering anything if element mode is decimal, and otherwise uses instead of real_zerop a new function, real_maybe_zerop, which will work even for decimal types and for complex or vector will return true if any element is or might be zero (so it returns true for anything but constants for now). 2022-12-23 Jakub Jelinek PR tree-optimization/108068 * tree.h (real_maybe_zerop): Declare. * tree.c (real_maybe_zerop): Define. * tree-ssa-dom.c (record_edge_info): Use it instead of real_zerop or TREE_CODE (op1) == SSA_NAME || real_zerop. Always set can_infer_simple_equiv to false for decimal floating point types. * gcc.dg/dfp/pr108068.c: New test. (cherry picked from commit fd1b0aefda5b65f3f841ca6e61ccea6a72daa060)
[Bug testsuite/108151] gcc.dg/pr64536.c stores pointers in a long, broken for llp64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108151 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ab03e6bdc590393a36d62cf14fe0280529c933ae commit r11-10692-gab03e6bdc590393a36d62cf14fe0280529c933ae Author: Jakub Jelinek Date: Mon Dec 19 15:05:16 2022 +0100 testsuite: Fix up pr64536.c for LLP64 targets [PR108151] Apparently llp64 had 2 further warnings, fixed thusly. 2022-12-19 Jakub Jelinek PR testsuite/108151 * gcc.dg/pr64536.c (bar): Cast long to __INTPTR_TYPE__ before casting to long *. (cherry picked from commit 6e85f89a7d59a99a3395b6e153b99262a58b2f6c)
[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997 --- Comment #15 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5a0fd69bb3aa1709f0bea5d6b91fb30ca226c1ed commit r11-10687-g5a0fd69bb3aa1709f0bea5d6b91fb30ca226c1ed Author: Jakub Jelinek Date: Sat Dec 10 16:50:39 2022 +0100 ivopts: Fix IP_END handling for asm goto [PR107997] The following testcase ICEs, because the latch bb ends with asm goto which has both fallthrough to the header and one or more labels in the header too. In that case there is just a single edge out of the latch block, but still the asm goto is stmt_ends_bb_p statement, yet ivopts decides to emit an IV bump at the IP_END position and inserts it into the same bb as the asm goto after it, which then fails verification (control flow in the middle of bb). The following patch fixes it by splitting the latch -> header edge in that case and inserting into the newly created bb, where split_edge -> redirect_edge_and_branch is able to deal with this case correctly. 2022-12-10 Jakub Jelinek PR tree-optimization/107997 * tree-ssa-loop-ivopts.c: Include cfganal.h. (create_new_iv) : If ip_end_pos bb is non-empty and ends with a stmt which ends bb, instead of adding iv update after it split the latch edge and insert iterator into the new latch bb. * gcc.c-torture/compile/pr107997.c: New test. (cherry picked from commit 7676235f690e624b7ed41a22b22ce8ccfac1492f)
[Bug tree-optimization/108095] powerpc-linux / powerpc64-linux: ICEs when building Linux's arch/powerpc/kernel/align.c (asm goto)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108095
--- Comment #11 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:9b580f5d7cb3c23866cdbd19e3c1bfc407e9e9c5
commit r11-10688-g9b580f5d7cb3c23866cdbd19e3c1bfc407e9e9c5
Author: Jakub Jelinek
Date: Thu Dec 15 09:26:44 2022 +0100
into-ssa: Fix emitting debug stmts after asm goto [PR108095]
The following testcase ICEs, because ccp1 replaced
s.0_1 =
__asm__ goto("" : "=r" MEM[(T *)s.0_1] : : : "lab" lab);
with
__asm__ goto("" : "=r" s : : : "lab" lab);
and because s is no longer addressable, we are rewriting it into
ssa and want
__asm__ goto("" : "=r" s_7 : : : "lab" lab);
plus debug stmt
# DEBUG s => s_7
The code assumes that there is at most one non-EH edge in that
case, but with the addition of outputs to asm goto that is no longer the
case, we can have many outgoing edges.
The patch keeps the checking assertion that there is at most one such
edge for everything but asm goto, but moves the addition of the debug
stmt into the loop, so that it can be added on all edges where it is
possible, not just one of them.
Furthermore, looking at gsi_insert_on_edge_immediate
-> gimple_find_edge_insert_loc, the conditions to insert stmt there
to the destination block are
if (single_pred_p (dest)
&& gimple_seq_empty_p (phi_nodes (dest))
&& dest != EXIT_BLOCK_PTR_FOR_FN (cfun))
(plus there is code to insert it in the previous block but that is
never true when the pred is known to be stmt_ends_bb_p), while
mayube_register_def was just checking
if (ef && single_pred_p (ef->dest)
&& ef->dest != EXIT_BLOCK_PTR_FOR_FN (cfun))
so if for whatever reason ef->dest had any PHIs, we'd split the
edge for -g and not for -g0, something we must avoid for -fcompare-debug
stability. So, I've added the no phi_nodes check too.
2022-12-15 Jakub Jelinek
PR tree-optimization/108095
* tree-into-ssa.c (maybe_register_def): Insert debug stmt
on all non-EH edges from asm goto if they have a single
predecessor rather than asserting there is at most one such edge.
Test whether there are no PHI nodes next to the single predecessor
test.
* gcc.dg/pr108095.c: New test.
(cherry picked from commit bf3ce6f84a7a994a0fc87419b383b9ce4efed442)
[Bug rtl-optimization/106751] [10/11 Regression] internal compiler error: in purge_dead_edges with inline-asm goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106751 --- Comment #16 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:945edfa2d24e310bf3549a16f2ea4c881a9a138a commit r11-10690-g945edfa2d24e310bf3549a16f2ea4c881a9a138a Author: Jakub Jelinek Date: Fri Dec 16 10:19:22 2022 +0100 loop-invariant: Split preheader edge if the preheader bb ends with jump [PR106751] The RTL loop passes only request simple preheaders, but don't require fallthru preheaders, while move_invariant_reg apparently assumes the latter, that it can just append instruction(s) to the end of the preheader basic block. The following patch fixes that by splitting the preheader edge if the preheader bb ends with a JUMP_INSN (asm goto in this case). Without that we get control flow in the middle of a bb. 2022-12-16 Jakub Jelinek PR rtl-optimization/106751 * loop-invariant.c (move_invariant_reg): If preheader bb ends with a JUMP_INSN, split the preheader edge and emit invariants into the new preheader basic block. * gcc.c-torture/compile/pr106751.c: New test. (cherry picked from commit ddcaa60983b50378bde1b7e327086fe0ce101795)
[Bug target/106875] [11 Regression] ICE in ix86_emit_outlined_ms2sysv_save with -mabi=ms -mcall-ms2sysv-xlogues and "#pragma GCC target" since r11-3183-gba948b37768c99cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106875
--- Comment #7 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:511b878b6a808c3d46dccf806223a851e63ad562
commit r11-10685-g511b878b6a808c3d46dccf806223a851e63ad562
Author: Jakub Jelinek
Date: Mon Nov 28 10:13:43 2022 +0100
i386: Fix up ix86_abi handling [PR106875]
The following testcase fails since my changes to make also
opts_set saved/restored upon function target/optimization changes
(before it has been acting as "has this option be ever explicit
anywhere?").
The problem is that for ix86_abi we depend on the opts_set
value for it in ix86_option_override_internal:
SET_OPTION_IF_UNSET (opts, opts_set, ix86_abi, DEFAULT_ABI);
but as it is a TargetSave, the backend code is required to
save/restore it manually (it does that) and since gcc 11 also
to save/restore the opts_set bit for it (which isn't done).
We don't do that for various other TargetSave which
ix86_function_specific_{save,restore} saves/restores, but as long
as we never test opts_set for it, it doesn't really matter.
One possible fix would be to introduce some new TargetSave into
which ix86_function_specific_{save,restore} would save/restore a bitmask
of the opts_set bits. The following patch uses an easier fix, by
making it a TargetVariable instead the saving/restoring is handled
by the generated code.
The differences in options.h are just slight movements on where
*ix86_abi stuff appears in it, ditto for options.cc, the real
differences are just in options-save.cc, where cl_target_option_save
gets:
+ ptr->x_ix86_abi = opts->x_ix86_abi;
...
+ if (opts_set->x_ix86_abi) mask |= HOST_WIDE_INT_1U << 3;
(plus adjustments of following TargetVariables mask related stuff),
cl_target_option_restore gets:
+ opts->x_ix86_abi = ptr->x_ix86_abi;
...
+ opts_set->x_ix86_abi = static_cast((mask & 1) != 0);
+ mask >>= 1;
plus the movements in other functions too. So, by it being a
TargetVariable, the only thing that changed is that we don't need to
handle it manually in ix86_function_specific_{save,restore} because it
is handled automatically including the opts_set stuff.
2022-11-28 Jakub Jelinek
PR target/106875
* config/i386/i386.opt (x_ix86_abi): Remove TargetSave.
(ix86_abi): Replace it with TargetVariable.
* config/i386/i386-options.c (ix86_function_specific_save,
ix86_function_specific_restore): Don't save and restore x_ix86_abi.
* g++.target/i386/pr106875.C: New test.
(cherry picked from commit ee629d242d9f93a38e49bed904bb334bbe15dde1)
[Bug debug/106719] [10/11 Regression] '-fcompare-debug' failure w/ -O2 since r10-6038-ge5e07b68187b9a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106719
--- Comment #8 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:f187d4c17546df91c3b6b9c0912403d14c6eb3c8
commit r11-10686-gf187d4c17546df91c3b6b9c0912403d14c6eb3c8
Author: Jakub Jelinek
Date: Thu Dec 8 14:57:22 2022 +0100
cfgbuild: Fix DEBUG_INSN handling in find_bb_boundaries [PR106719]
The following testcase FAILs on aarch64-linux. We have some atomic
instruction followed by 2 DEBUG_INSNs (if -g only of course) followed
by NOTE_INSN_EPILOGUE_BEG followed by some USE insn.
Now, split3 pass replaces the atomic instruction with a code sequence
which ends with a conditional jump and the split3 pass calls
find_many_sub_basic_blocks.
For -g0, find_bb_boundaries sees the flow_transfer_insn (the new
conditional
jump), then NOTE_INSN_EPILOGUE_BEG which can live in between basic blocks
and then the USE insn, so splits block after the NOTE_INSN_EPILOGUE_BEG
and puts the NOTE in between the blocks.
For -g, if sees a DEBUG_INSN after the flow_transfer_insn, so sets
debug_insn to it, then walks over another DEBUG_INSN,
NOTE_INSN_EPILOGUE_BEG
until it finally sees the USE insn, and triggers the:
rtx_insn *prev = PREV_INSN (insn);
/* If the first non-debug inside_basic_block_p insn after a
control
flow transfer is not a label, split the block before the debug
insn instead of before the non-debug insn, so that the debug
insns are not lost. */
if (debug_insn && code != CODE_LABEL && code != BARRIER)
prev = PREV_INSN (debug_insn);
code I've added for PR81325. If there are only DEBUG_INSNs, that is
the right thing to do, but if in between debug_insn and insn there are
notes which can stay in between basic blocks or simnilarly JUMP_TABLE_DATA
or their associated CODE_LABELs, it causes -fcompare-debug differences.
The following patch fixes it by clearing debug_insn if JUMP_TABLE_DATA
or associated CODE_LABEL is seen (I'm afraid there is no good answer
what to do with DEBUG_INSNs before those; the code then removes them:
/* Clean up the bb field for the insns between the blocks.
*/
for (x = NEXT_INSN (flow_transfer_insn);
x != BB_HEAD (fallthru->dest);
x = next)
{
next = NEXT_INSN (x);
/* Debug insns should not be in between basic blocks,
drop them on the floor. */
if (DEBUG_INSN_P (x))
delete_insn (x);
else if (!BARRIER_P (x))
set_block_for_insn (x, NULL);
}
but if there are NOTEs, the patch just reorders the NOTEs and DEBUG_INSNs,
such that the NOTEs come first (so that they stay in between basic blocks
like with -g0) and DEBUG_INSNs after those (so that bb is split before
them, so they will be in the basic block after NOTE_INSN_BASIC_BLOCK).
2022-12-08 Jakub Jelinek
PR debug/106719
* cfgbuild.c (find_bb_boundaries): If there are NOTEs in between
debug_insn (seen after flow_transfer_insn) and insn, move NOTEs
before all the DEBUG_INSNs and split after NOTEs. If there are
other insns like jump table data, clear debug_insn.
* gcc.dg/pr106719.c: New test.
(cherry picked from commit d9f9d5d30feb33c359955d7030cc6be50ef6dc0a)
[Bug middle-end/107317] [10/11 Regression] ICE in emit_redzone_byte, at asan.cc:1508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107317 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:07b397d7720c062d91669d49fbfb644fb3eb81d8 commit r11-10684-g07b397d7720c062d91669d49fbfb644fb3eb81d8 Author: Jakub Jelinek Date: Thu Nov 24 11:29:54 2022 +0100 asan: Fix up error recovery for too large frames [PR107317] asan_emit_stack_protection and functions it calls have various asserts that verify sanity of the stack protection instrumentation. But, that verification can easily fail if we've diagnosed a frame offset overflow. asan_emit_stack_protection just emits some extra code in the prologue, if we've reported errors, we aren't producing assembly, so it doesn't really matter if we don't include the protection code, compilation is going to fail anyway. 2022-11-24 Jakub Jelinek PR middle-end/107317 * asan.c: Include diagnostic-core.h. (asan_emit_stack_protection): Return NULL early if seen_error (). * gcc.dg/asan/pr107317.c: New test. (cherry picked from commit b6330a7685476fc30b8ae9bbf3fca1a9b0d4be95)
[Bug c/107127] [11 Regression] Long compile times on code with C complex since r11-3299-gcba079f354a55363
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107127
--- Comment #13 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:21ffe7bc50422bbf2fc844f4e69a16d7e8d35698
commit r11-10683-g21ffe7bc50422bbf2fc844f4e69a16d7e8d35698
Author: Jakub Jelinek
Date: Thu Nov 24 10:33:00 2022 +0100
testsuite: Fix up broken testcase [PR107127]
I've added { dg-options "" } line manually in the patch but
forgot to adjust the number of added lines.
2022-11-24 Jakub Jelinek
PR c/107127
* gcc.dg/pr107127.c (foo): Add missing closing }.
(cherry picked from commit add0f941be18cdf962a0f300019acacbf2325d41)
[Bug c/107127] [11 Regression] Long compile times on code with C complex since r11-3299-gcba079f354a55363
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107127 --- Comment #12 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:21d09955d2b7755db7d5ba3cd4a314930b470da7 commit r11-10682-g21d09955d2b7755db7d5ba3cd4a314930b470da7 Author: Jakub Jelinek Date: Wed Nov 23 19:09:31 2022 +0100 c: Fix compile time hog in c_genericize [PR107127] The complex multiplications result in deeply nested set of many SAVE_EXPRs, which takes even on fast machines over 5 minutes to walk. This patch fixes that by using walk_tree_without_duplicates where it is instant. 2022-11-23 Andrew Pinski Jakub Jelinek PR c/107127 * c-gimplify.c (c_genericize): Use walk_tree_without_duplicates instead of walk_tree for c_genericize_control_r. * gcc.dg/pr107127.c: New test. (cherry picked from commit 8a0fce6a51915c29584427fd376b40073c328090)
[Bug libstdc++/109703] [12/13/14 Regression] __builtin_unreachable() reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109703 Andrew Pinski changed: What|Removed |Added Target Milestone|13.2|12.3 Summary|[13/14 Regression] |[12/13/14 Regression] |__builtin_unreachable() |__builtin_unreachable() |reached |reached
[Bug libstdc++/109703] [13/14 Regression] __builtin_unreachable() reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109703 Andrew Pinski changed: What|Removed |Added Summary|__builtin_unreachable() |[13/14 Regression] |reached |__builtin_unreachable() ||reached Target Milestone|--- |13.2
[Bug target/89835] The RISC-V target uses amoswap.w for relaxed stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89835 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick O'Neill : https://gcc.gnu.org/g:6a2383f47ae70c31f91775142b9fb03f697741c2 commit r14-403-g6a2383f47ae70c31f91775142b9fb03f697741c2 Author: Patrick O'Neill Date: Wed Apr 5 09:56:33 2023 -0700 RISC-V: Strengthen atomic stores This change makes atomic stores strictly stronger than table A.6 of the ISA manual. This mapping makes the overall patchset compatible with table A.7 as well. 2023-04-27 Patrick O'Neill PR target/89835 gcc/ChangeLog: * config/riscv/sync.md (atomic_store): Use simple store instruction in combination with fence(s). gcc/testsuite/ChangeLog: * gcc.target/riscv/pr89835.c: New test. Signed-off-by: Patrick O'Neill
[Bug c++/109671] Spurious dangling reference warning in GCC 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109671 --- Comment #4 from CVS Commits --- The releases/gcc-13 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:6b927b1297e66e26e62e722bf15c921dcbbd25b9 commit r13-7276-g6b927b1297e66e26e62e722bf15c921dcbbd25b9 Author: Marek Polacek Date: Tue May 2 15:48:40 2023 -0400 c++: Move -Wdangling-reference to -Wextra [PR109642] Sadly, -Wdangling-reference generates false positives for std::span-like user classes, and it seems imprudent to attempt to improve the heuristic in GCC 13. Let's move the warning to -Wextra, that will hopefully reduce the number of false positives the users have been seeing with 13. I'm leaving the warning in -Wall in 14 where I think I can write code to detect std::span-like classes. PR c++/109642 PR c++/109640 PR c++/109671 gcc/c-family/ChangeLog: * c.opt (Wdangling-reference): Move from -Wall to -Wextra. gcc/ChangeLog: * doc/invoke.texi: Document that -Wdangling-reference is enabled by -Wextra.
[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642 --- Comment #7 from CVS Commits --- The releases/gcc-13 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:6b927b1297e66e26e62e722bf15c921dcbbd25b9 commit r13-7276-g6b927b1297e66e26e62e722bf15c921dcbbd25b9 Author: Marek Polacek Date: Tue May 2 15:48:40 2023 -0400 c++: Move -Wdangling-reference to -Wextra [PR109642] Sadly, -Wdangling-reference generates false positives for std::span-like user classes, and it seems imprudent to attempt to improve the heuristic in GCC 13. Let's move the warning to -Wextra, that will hopefully reduce the number of false positives the users have been seeing with 13. I'm leaving the warning in -Wall in 14 where I think I can write code to detect std::span-like classes. PR c++/109642 PR c++/109640 PR c++/109671 gcc/c-family/ChangeLog: * c.opt (Wdangling-reference): Move from -Wall to -Wextra. gcc/ChangeLog: * doc/invoke.texi: Document that -Wdangling-reference is enabled by -Wextra.
[Bug c++/109640] Spurious Wdangling-reference for argument to temporary lambda cast to rvalue reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109640 --- Comment #4 from CVS Commits --- The releases/gcc-13 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:6b927b1297e66e26e62e722bf15c921dcbbd25b9 commit r13-7276-g6b927b1297e66e26e62e722bf15c921dcbbd25b9 Author: Marek Polacek Date: Tue May 2 15:48:40 2023 -0400 c++: Move -Wdangling-reference to -Wextra [PR109642] Sadly, -Wdangling-reference generates false positives for std::span-like user classes, and it seems imprudent to attempt to improve the heuristic in GCC 13. Let's move the warning to -Wextra, that will hopefully reduce the number of false positives the users have been seeing with 13. I'm leaving the warning in -Wall in 14 where I think I can write code to detect std::span-like classes. PR c++/109642 PR c++/109640 PR c++/109671 gcc/c-family/ChangeLog: * c.opt (Wdangling-reference): Move from -Wall to -Wextra. gcc/ChangeLog: * doc/invoke.texi: Document that -Wdangling-reference is enabled by -Wextra.
[Bug fortran/109701] I have a MWE where an omp reduction breaks if I add the option for GPU offloading (even if it isn't used).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109701 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to Thomas Meltzer from comment #1) > Could be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928 but I > am not sure. In my case the GPU offloading should be ignored. Replacing the line !$omp target teams if(is_GPU) !< comment this by !$omp target teams if(is_GPU) map(max_diff) seems to make a difference for me. So it might be related to pr99928.
[Bug c++/109680] [13/14 Regression] is_convertible incorrectly true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109680
--- Comment #7 from Marek Polacek ---
Ah, I think I see what's going on here. Once again, the problem is that this
assert no longer passes:
#include
static_assert (!std::is_convertible_v , "");
std::is_convertible does
To test() { return std::declval(); }
here, From is 'int () const'.
std::declval is defined as:
template
typename std::add_rvalue_reference::type declval() noexcept;
Now, std::add_rvalue_reference is defined as "If T is a function type that has
no cv- or ref- qualifier or an object type, provides a member typedef type
which is T&&, otherwise type is T."
In our case, T is cv-qualified, so the result is T, so we end up with
int () const declval() noexcept;
which is invalid. In other words:
using T = int () const;
T fn1(); // bad, fn returning a fn
T& fn2(); // bad, cannot declare reference to qualified function type
T* fn3(); // bad, cannot declare pointer to qualified function type
using U = int ();
U fn4(); // bad, fn returning a fn
U& fn5(); // OK
U* fn6(); // OK
So the check we're looking for is probably
if (TREE_CODE (type) == FUNCTION_TYPE
&& (type_memfn_quals (type) != TYPE_UNQUALIFIED
|| type_memfn_rqual (type) != REF_QUAL_NONE))
but I think it should be put wherever we simulate declval().
[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||13.1.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #25 from anlauf at gcc dot gnu.org --- Fixed in gcc-13.
[Bug sanitizer/109700] ICE with address sanitizer after declaring __builtin_alloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109700 --- Comment #6 from James Legg --- Yes, declaring bulitin functions is bad, but I didn't expect the ICE. It wasn't done intentionally. glibc's alloca.h defines a alloca(s) macro as __builtin_alloca(s). I had some code defining _alloca as alloca for compatibility with code written to use MSC's _alloca function, and some code intended to build with MSC that attempted to declare _alloca instead of including the appropriate header, but due to macro expansion it was actually declaring __builtin_alloca.
[Bug libstdc++/109703] New: __builtin_unreachable() reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109703
Bug ID: 109703
Summary: __builtin_unreachable() reached
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: christian.morales.vega at gmail dot com
Target Milestone: ---
This
(https://github.com/gcc-mirror/gcc/commit/bf78b43873b0b7e8f9a430df38749b8b61f9c9b8#diff-c8a656ef205ec6452ef0bed111a387dc9e7eb2404fb3222a48f9f93b2460bd55R278)
__builtin_unreachable() is reached using this code
--
#include
#include
int main() {
auto lower = std::string{"0123456789ABCDEF"};
auto upper = boost::algorithm::to_upper_copy(lower);
}
--
with Boost 1.82.
Doing "g++ -O1 -fsanitize=undefined -o main main.cpp && ./main" results in
/usr/include/c++/13/bits/basic_string.h:278:29: runtime error: execution
reached an unreachable program point
This is with gcc-13.1.1-1.fc38.x86_64 from Fedora 38.
AFAICT the bug is in libstdc++.
During the first iteration, is not until
https://github.com/gcc-mirror/gcc/blob/releases/gcc-13.1.0/libstdc%2B%2B-v3/include/bits/basic_string.tcc#L201
that the data pointer is replaced from the SSO to the heap one; but one line
before, in
https://github.com/gcc-mirror/gcc/blob/releases/gcc-13.1.0/libstdc%2B%2B-v3/include/bits/basic_string.tcc#L200
https://github.com/gcc-mirror/gcc/blob/releases/gcc-13.1.0/libstdc%2B%2B-v3/include/bits/basic_string.h#L293
https://github.com/gcc-mirror/gcc/blob/releases/gcc-13.1.0/libstdc%2B%2B-v3/include/bits/basic_string.h#L275
, it checks whether it should destroy the data based on whether _M_data() ==
_M_local_data().
[Bug fortran/109701] I have a MWE where an omp reduction breaks if I add the option for GPU offloading (even if it isn't used).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109701 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||openmp --- Comment #2 from anlauf at gcc dot gnu.org --- If I compile the code with -g -fsanitize=thread, I see a data race in the second loop nest pointing to a possible issue with the reduction.
[Bug sanitizer/109700] ICE with address sanitizer after declaring __builtin_alloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109700 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-05-02 --- Comment #5 from Andrew Pinski --- Note GCC 9.x ICEs even without checking enabled. It just happens GCC 10.x-12.x does not. Anyways don't declare __builtin_alloca; it is NOT needed.
