[Bug c++/69698] [meta-bug] flexible array members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69698 Bug 69698 depends on bug 88578, which changed state. Bug 88578 Summary: Static C++ objects with flexible array members overlap when initializes are non-const https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88578 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/88578] Static C++ objects with flexible array members overlap when initializes are non-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88578 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Jakub Jelinek --- Fixed.
[Bug c++/70796] [DR 1030] Initialization order with braced-init-lists still broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70796 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Jakub Jelinek --- Fixed.
[Bug middle-end/64888] ubsan doesn't work with openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64888 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Jakub Jelinek --- Fixed.
[Bug testsuite/100422] [12 regression] g++.dg/gomp/clause-3.C fails after r12-438
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100422 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d042fa8e2cfabe5da83634ce05e8130d1010c034 commit r9-10153-gd042fa8e2cfabe5da83634ce05e8130d1010c034 Author: Tobias Burnus Date: Wed May 5 08:50:15 2021 +0200 g++.dg/gomp/clause-3.C: Fix - missing in r12-438-g1580fc7 [PR100422] gcc/testsuite/ PR testsuite/100422 * g++.dg/gomp/clause-3.C: Use 'reduction(&:..)' instead of '...(&&:..)'. (cherry picked from commit af4e4d35f0b84d7c2f57a7b682a09116e9911142)
[Bug sanitizer/105396] [9/10 Regression] missed stack-buffer-overflow by -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105396 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4431014dc2e905a427d1e9dd4f4d494ae2d7ab96 commit r9-10152-g4431014dc2e905a427d1e9dd4f4d494ae2d7ab96 Author: Jakub Jelinek Date: Wed Apr 27 08:34:18 2022 +0200 asan: Fix up asan_redzone_buffer::emit_redzone_byte [PR105396] On the following testcase, we have in main's frame 3 variables, some red zone padding, 4 byte d, followed by 12 bytes of red zone padding, then 8 byte b followed by 24 bytes of red zone padding, then 40 bytes c followed by some red zone padding. The intended content of shadow memory for that is (note, each byte describes 8 bytes of memory): f1 f1 f1 f1 04 f2 00 f2 f2 f2 00 00 00 00 00 f3 f3 f3 f3 f3 left redd mr b middle r c right red zone f1 is left red zone magic f2 is middle red zone magic f3 is right red zone magic 00 when all 8 bytes are accessible 01-07 when only 1 to 7 bytes are accessible followed by inaccessible bytes The -fdump-rtl-expand-details dump makes it clear that it misbehaves: Flushing rzbuffer at offset -160 with: f1 f1 f1 f1 Flushing rzbuffer at offset -128 with: 04 f2 00 00 Flushing rzbuffer at offset -128 with: 00 00 00 f2 Flushing rzbuffer at offset -96 with: f2 f2 00 00 Flushing rzbuffer at offset -64 with: 00 00 00 f3 Flushing rzbuffer at offset -32 with: f3 f3 f3 f3 In the end we end up with f1 f1 f1 f1 00 00 00 f2 f2 f2 00 00 00 00 00 f3 f3 f3 f3 f3 shadow bytes because at offset -128 there are 2 overlapping stores as asan_redzone_buffer::emit_redzone_byte has flushed the temporary 4 byte buffer in the middle. The function is called with an offset and value. If the passed offset is consecutive with the prev_offset + buffer size (off == offset), then we handle it correctly, similarly if the new offset is far enough from the old one (we then flush whatever was in the buffer and if needed add up to 3 bytes of 00 before actually pushing value. But what isn't handled correctly is when the offset isn't consecutive to what has been added last time, but it is in the same 4 byte word of shadow memory (32 bytes of actual memory), like the above case where we have consecutive 04 f2 and then skip one shadow memory byte (aka 8 bytes of real memory) and then want to emit f2. Emitting that as a store of little-endian 0xf204 followed by a store of 0xf200 to the same address doesn't work, we want to emit 0xf200f204. The following patch does that by pushing 1 or 2 00 bytes. Additionally, as a small cleanup, instead of using m_shadow_bytes.safe_push (value); flush_if_full (); in all of if, else if and else bodies it sinks those 2 stmts to the end of function as all do the same thing. 2022-04-27 Jakub Jelinek PR sanitizer/105396 * asan.c (asan_redzone_buffer::emit_redzone_byte): Handle the case where offset is bigger than off but smaller than m_prev_offset + 32 bits by pushing one or more 0 bytes. Sink the m_shadow_bytes.safe_push (value); flush_if_full (); statements from all cases to the end of the function. * gcc.dg/asan/pr105396.c: New test. (cherry picked from commit 9715f10c0651c9549b479b69d67be50ac4bd98a6)
[Bug target/105257] [9/10 regression] ICE in final_scan_insn_1, at final.cc:2811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105257 --- Comment #14 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4f18893fbd53205588c952856184367671b2a880 commit r9-10151-g4f18893fbd53205588c952856184367671b2a880 Author: Jakub Jelinek Date: Tue Apr 19 18:58:59 2022 +0200 sparc: Preserve ORIGINAL_REGNO in epilogue_renumber [PR105257] The following testcase ICEs, because the pic register is (reg:DI 24 %i0 [109]) and is used in the delay slot of a return. We invoke epilogue_renumber and that changes it to (reg:DI 8 %o0) which no longer satisfies sparc_pic_register_p predicate, so we don't recognize the insn anymore. The following patch fixes that by preserving ORIGINAL_REGNO if specified, so we get (reg:DI 8 %o0 [109]) instead. 2022-04-19 Jakub Jelinek PR target/105257 * config/sparc/sparc.c (epilogue_renumber): If ORIGINAL_REGNO, use gen_raw_REG instead of gen_rtx_REG and copy over also ORIGINAL_REGNO. Use return 0; instead of /* fallthrough */. * gcc.dg/pr105257.c: New test. (cherry picked from commit eeca2b8bd03f57c59c6cf48bf6b9bd6dc86924f6)
[Bug c++/105256] [9/10 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #36 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:30895a25ea94e0ba47f97803137f2a0a42af848c commit r9-10150-g30895a25ea94e0ba47f97803137f2a0a42af848c Author: Jakub Jelinek Date: Tue Apr 19 18:27:41 2022 +0200 c++: Fix up CONSTRUCTOR_PLACEHOLDER_BOUNDARY handling [PR105256] The CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit is supposed to separate PLACEHOLDER_EXPRs that should be replaced by one object or subobjects of it (variable, TARGET_EXPR slot, ...) from other PLACEHOLDER_EXPRs that should be replaced by different objects or subobjects. The bit is set when finding PLACEHOLDER_EXPRs inside of a CONSTRUCTOR, not looking into nested CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctors, and we prevent elision of TARGET_EXPRs (through TARGET_EXPR_NO_ELIDE) whose initializer is a CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctor. The following testcase ICEs though, we don't replace the placeholders in there at all, because CONSTRUCTOR_PLACEHOLDER_BOUNDARY isn't set on the TARGET_EXPR_INITIAL ctor, but on a ctor nested in such a ctor. replace_placeholders should be run on the whole TARGET_EXPR slot. So, the following patch fixes it by moving the CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit from nested CONSTRUCTORs to the CONSTRUCTOR containing those (but only if it is closely nested, if there is some other tree sandwiched in between, it doesn't do it). 2022-04-19 Jakub Jelinek PR c++/105256 * typeck2.c (process_init_constructor_array, process_init_constructor_record, process_init_constructor_union): Move CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag from CONSTRUCTOR elements to the containing CONSTRUCTOR. * g++.dg/cpp0x/pr105256.C: New test. (cherry picked from commit eb03e424598d30fed68801af6d6ef6236d32e32e)
[Bug target/105214] [12 Regression] ICE: in connect_traces, at dwarf2cfi.cc:3074 with custom flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105214 --- Comment #10 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:14407aba9fc03b3b29d3ffdf713369cc6a572431 commit r9-10149-g14407aba9fc03b3b29d3ffdf713369cc6a572431 Author: Jakub Jelinek Date: Tue Apr 12 09:19:11 2022 +0200 i386: Fix ICE caused by ix86_emit_i387_log1p [PR105214] The following testcase ICEs, because ix86_emit_i387_log1p attempts to emit something like if (cond) some_code1; else some_code2; and emits a conditional jump using emit_jump_insn (standard way in the file) and an unconditional jump using emit_jump. The problem with that is that if there is pending stack adjustment, it isn't emitted before the conditional jump, but is before the unconditional jump and therefore stack is adjusted only conditionally (at the end of some_code1 above), which makes dwarf2 pass unhappy about it but is a serious wrong-code even if it doesn't ICE. This can be fixed either by emitting pending stack adjust before the conditional jump as the following patch does, or by not using emit_jump (label2); and instead hand inlining what that function does except for the pending stack adjustment, like: emit_jump_insn (targetm.gen_jump (label2)); emit_barrier (); In that case there will be no stack adjustment in the sequence and it will be done later on somewhere else. 2022-04-12 Jakub Jelinek PR target/105214 * config/i386/i386.c (ix86_emit_i387_log1p): Call do_pending_stack_adjust. * gcc.dg/asan/pr105214.c: New test. (cherry picked from commit d481d13786cb84f6294833538133dbd6f39d2e55)
[Bug rtl-optimization/105211] ICE: SIGSEGV in contains_struct_check (tree.h:3570) with -Os -ffast-math and __builtin_roundf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105211
--- Comment #7 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:fd68b02744886b57ce852630c090857db48efd96
commit r9-10148-gfd68b02744886b57ce852630c090857db48efd96
Author: Jakub Jelinek
Date: Tue Apr 12 09:16:06 2022 +0200
builtins: Fix up expand_builtin_int_roundingfn_2 [PR105211]
The expansion of __builtin_iround{,f,l} etc. builtins in some cases
emits calls to a different fallback builtin. To locate the right builtin
it uses mathfn_built_in_1 with the type of the first argument.
If its TYPE_MAIN_VARIANT is {float,double,long_double}_type_node, all is
fine, but on the following testcase, because GIMPLE considers scalar
float conversions between types with the same mode as useless,
TYPE_MAIN_VARIANT of the arg's type is float32_type_node and because there
isn't __builtin_lroundf32 returns NULL and we ICE.
This patch will first try the type of the first argument of the builtin's
prototype (so that say on sizeof(double)==sizeof(long double) target it
honors
whether it was a *l or non-*l call; though even that can't be 100% trusted,
user could incorrectly prototype it) and as fallback the type argument.
If neither works, doesn't fallback.
2022-04-11 Jakub Jelinek
PR rtl-optimization/105211
* builtins.c (expand_builtin_int_roundingfn_2): If
mathfn_built_in_1
fails for TREE_TYPE (arg), retry it with
TREE_VALUE (TYPE_ARG_TYPES (TREE_TYPE (fndecl))) and if even that
fails, emit call normally.
* gcc.dg/pr105211.c: New test.
(cherry picked from commit 91a38e8a848c61b2e23ee277306dc8cd194d135b)
[Bug c++/105186] [9/10 Regression] ICE in canonicalize_attr_name, at attribs.h:146
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105186 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6547662a2afdac90311bcd286f87e98e6bec03d0 commit r9-10147-g6547662a2afdac90311bcd286f87e98e6bec03d0 Author: Jakub Jelinek Date: Mon Apr 11 10:41:07 2022 +0200 c-family: Initialize ridpointers for __int128 etc. [PR105186] The following testcase ICEs with C++ and is incorrectly rejected with C. The reason is that both FEs use ridpointers identifiers for CPP_KEYWORD and value or u.value for CPP_NAME e.g. when parsing attributes or OpenMP directives etc., like: /* Save away the identifier that indicates which attribute this is. */ identifier = (token->type == CPP_KEYWORD) /* For keywords, use the canonical spelling, not the parsed identifier. */ ? ridpointers[(int) token->keyword] : id_token->u.value; identifier = canonicalize_attr_name (identifier); I've tried to change those to use ridpointers only if non-NULL and otherwise use the value/u.value even for CPP_KEYWORDS, but that was a large 10 hunks patch. The following patch instead just initializes ridpointers for the __intNN keywords. It can't be done earlier before we record_builtin_type as there are 2 different spellings and if we initialize those ridpointers early, the second record_builtin_type fails miserably. 2022-04-11 Jakub Jelinek PR c++/105186 * c-common.c (c_common_nodes_and_builtins): After registering __int%d and __int%d__ builtin types, initialize corresponding ridpointers entry. * c-c++-common/pr105186.c: New test. (cherry picked from commit 083e8e66d2e90992fa83a53bfc3553dfa91abda1)
[Bug tree-optimization/105189] [9/10 Regression] Wrong code with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105189 --- Comment #10 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cddca3b79f813f2140f2f485de33ef90d7a03740 commit r9-10146-gcddca3b79f813f2140f2f485de33ef90d7a03740 Author: Jakub Jelinek Date: Fri Apr 8 09:14:44 2022 +0200 fold-const: Fix up make_range_step [PR105189] The following testcase is miscompiled, because fold_truth_andor incorrectly folds (unsigned) foo () >= 0U && 1 into foo () >= 0 For the unsigned comparison (which is useless in this case, as >= 0U is always true, but hasn't been folded yet), previous make_range_step derives exp (unsigned) foo () and +[0U, -] range for it. Next we process the NOP_EXPR. We have special code for unsigned to signed casts, already earlier punt if low or high aren't representable in arg0_type or if it is a narrowing conversion. For the signed to unsigned casts, I think if high is specified we are still fine, as we punt for non-representable values in arg0_type, n_high is then still representable and so was smaller or equal to signed maximum and either low is not present (equivalent to 0U), or low must be smaller or equal to high and so for unsigned exp +[low, high] the signed exp +[n_low, n_high] will be correct. Similarly, if both low and high aren't specified (always true or always false), it is ok too. But if we have for unsigned exp +[low, -] or -[low, -], using +[n_low, -] or -[n_high, -] is incorrect. Because low is smaller or equal to signed maximum and high is unspecified (i.e. unsigned maximum), when signed that range is a union of +[n_low, -] and +[-, -1] which is equivalent to -[0, n_low-1], unless low is 0, in that case we can treat it as [-, -]. 2022-04-08 Jakub Jelinek PR tree-optimization/105189 * fold-const.c (make_range_step): Fix up handling of (unsigned) x +[low, -] ranges for signed x if low fits into typeof (x). * g++.dg/torture/pr105189.C: New test. (cherry picked from commit 5e6597064b0c7eb93b8f720afc4aa970eefb0628)
[Bug rtl-optimization/104985] [12 Regression] ICE: SIGSEGV in undo_to_marker / adjust_reg_mode with -Os -frounding-math since r12-4767-g81342e95827f77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104985 --- Comment #21 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5169f5756e26feac7042a6046e974dd4b650b6ed commit r9-10145-g5169f5756e26feac7042a6046e974dd4b650b6ed Author: Jakub Jelinek Date: Wed Apr 6 18:42:52 2022 +0200 combine: Don't record for UNDO_MODE pointers into regno_reg_rtx array [PR104985] The testcase in the PR fails under valgrind on mips64 (but only Martin can reproduce, I couldn't). But the problem reported there is that SUBST_MODE remembers addresses into the regno_reg_rtx array, then some splitter needs a new pseudo and calls gen_reg_rtx, which reallocates the regno_reg_rtx array and finally undo operation is done and dereferences the old regno_reg_rtx entry. The rtx values stored in regno_reg_rtx array seems to be created by gen_reg_rtx only and since then aren't modified, all we do for it is adjusting its fields (e.g. adjust_reg_mode that SUBST_MODE does). So, I think it is useless to use where.r for UNDO_MODE and store ®no_reg_rtx[regno] in struct undo, we can store just regno_reg_rtx[regno] (i.e. pointer to the REG itself instead of pointer to pointer to REG) or could also store just the regno. The following patch does the latter, and because SUBST_MODE no longer needs to be a macro, changes all SUBST_MODE uses to subst_mode. 2022-04-06 Jakub Jelinek PR rtl-optimization/104985 * combine.c (struct undo): Add where.regno member. (do_SUBST_MODE): Rename to ... (subst_mode): ... this. Change first argument from rtx * into int, operate on regno_reg_rtx[regno] and save regno into where.regno. (SUBST_MODE): Remove. (try_combine): Use subst_mode instead of SUBST_MODE, change first argument from regno_reg_rtx[whatever] to whatever. For UNDO_MODE, use regno_reg_rtx[undo->where.regno] instead of *undo->where.r. (undo_to_marker): For UNDO_MODE, use regno_reg_rtx[undo->where.regno] instead of *undo->where.r. (simplify_set): Use subst_mode instead of SUBST_MODE, change first argument from regno_reg_rtx[whatever] to whatever. (cherry picked from commit 61bee6aed26eb30b798c75b9a595c9d51e080442)
[Bug target/105123] [9/10 Regression] wrong code with -m32 -mtune=i686 and __builtin_shuffle()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105123
--- Comment #9 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:a78199c69f794a4ccacd123adbe1aaa29b077fa1
commit r9-10144-ga78199c69f794a4ccacd123adbe1aaa29b077fa1
Author: Jakub Jelinek
Date: Sun Apr 3 21:50:43 2022 +0200
i386: Fix up ix86_expand_vector_init_general [PR105123]
The following testcase is miscompiled on ia32.
The problem is that at -O0 we end up with:
vector(4) short unsigned int _1;
short unsigned int u.0_3;
...
_1 = {u.0_3, u.0_3, u.0_3, u.0_3};
statement (dead) which is wrongly expanded.
elt is (subreg:HI (reg:SI 83 [ u.0_3 ]) 0), tmp_mode SImode,
so after convert_mode we start with word (reg:SI 83 [ u.0_3 ]).
The intent is to manually broadcast that value to 2 SImode parts,
but because we pass word as target to expand_simple_binop, it will
overwrite (reg:SI 83 [ u.0_3 ]) and we end up with 0:
10: {r83:SI=r83:SI<<0x10;clobber flags:CC;}
11: {r83:SI=r83:SI|r83:SI;clobber flags:CC;}
12: {r83:SI=r83:SI<<0x10;clobber flags:CC;}
13: {r83:SI=r83:SI|r83:SI;clobber flags:CC;}
14: clobber r110:V4HI
15: r110:V4HI#0=r83:SI
16: r110:V4HI#4=r83:SI
as the two ors do nothing and two shifts each by 16 left shift it all
away.
The following patch fixes that by using NULL_RTX target, so we expand it as
10: {r110:SI=r83:SI<<0x10;clobber flags:CC;}
11: {r111:SI=r110:SI|r83:SI;clobber flags:CC;}
12: {r112:SI=r83:SI<<0x10;clobber flags:CC;}
13: {r113:SI=r112:SI|r83:SI;clobber flags:CC;}
14: clobber r114:V4HI
15: r114:V4HI#0=r111:SI
16: r114:V4HI#4=r113:SI
instead.
Another possibility would be to pass NULL_RTX only when word == elt
and word otherwise, where word would necessarily be a pseudo from the first
shift after passing NULL_RTX there once or pass NULL_RTX for the shift and
word for ior.
2022-04-03 Jakub Jelinek
PR target/105123
* config/i386/i386.c (ix86_expand_vector_init_general): Avoid
using word as target for expand_simple_binop when doing ASHIFT and
IOR.
* gcc.target/i386/pr105123.c: New test.
(cherry picked from commit e1a74058b784c845e84a0cf1997b54b984df483d)
[Bug sanitizer/105093] [9/10 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7607 since r6-3529-gf11a7b6d57f6fcba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105093 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:bee22b8bc1974773ec2d0e8bf64ad4fbba738fe4 commit r9-10143-gbee22b8bc1974773ec2d0e8bf64ad4fbba738fe4 Author: Jakub Jelinek Date: Wed Mar 30 10:49:47 2022 +0200 ubsan: Fix ICE due to -fsanitize=object-size [PR105093] The following testcase ICEs, because for a volatile X & RESULT_DECL ubsan wants to take address of that reference. instrument_object_size is called with x, so the base is equal to the access and the var is automatic, so there is no risk of an out of bounds access for it. Normally we wouldn't instrument those because we fold address of the t - address of inner to 0, add constant size of the decl and it is equal to what __builtin_object_size computes. But the volatile results in the subtraction not being folded. The first hunk fixes it by punting if we access the whole automatic decl, so that even volatile won't cause a problem. The second hunk (not strictly needed for this testcase) is similar to what has been added to asan.cc recently, if we actually take address of a decl and keep it in the IL, we better mark it addressable. 2022-03-30 Jakub Jelinek PR sanitizer/105093 * ubsan.c (instrument_object_size): If t is equal to inner and is a decl other than global var, punt. When emitting call to UBSAN_OBJECT_SIZE ifn, make sure base is addressable. * g++.dg/ubsan/pr105093.C: New test. (cherry picked from commit e3e68fa59ead502c24950298b53c637bbe535a74)
[Bug c++/104994] extern thread_local declaration rejected in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104994 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:54bccc8e05f6f9480b50c4edfb2a364d344e72c0 commit r9-10141-g54bccc8e05f6f9480b50c4edfb2a364d344e72c0 Author: Jakub Jelinek Date: Thu Mar 24 10:12:25 2022 +0100 c++: extern thread_local declarations in constexpr [PR104994] C++14 to C++20 apparently should allow extern thread_local declarations in constexpr functions, however useless they are there (because accessing such vars is not valid in a constant expression, perhaps sizeof/decltype). P2242 changed that for C++23 to passing through declaration but https://cplusplus.github.io/CWG/issues/2552.html has been filed for it yesterday. 2022-03-24 Jakub Jelinek PR c++/104994 * constexpr.c (potential_constant_expression_1): Don't diagnose extern thread_local declarations. * decl.c (start_decl): Likewise. * g++.dg/cpp2a/constexpr-nonlit7.C: New test. (cherry picked from commit 72124f487ccb5c8065dd5f7b8fba254600b7e611)
[Bug middle-end/104971] [9/10 Regression] Optimisation for __builtin_ia32_readeflags corrupts the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104971 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c1a8261b7054da31420e5c715e682c1b42e473b5 commit r9-10140-gc1a8261b7054da31420e5c715e682c1b42e473b5 Author: Jakub Jelinek Date: Sat Mar 19 13:53:12 2022 +0100 i386: Don't emit pushf;pop for __builtin_ia32_readeflags_u* with unused lhs [PR104971] __builtin_ia32_readeflags_u* aren't marked const or pure I think intentionally, so that they aren't CSEd from different regions of a function etc. because we don't and can't easily track all dependencies between it and surrounding code (if somebody looks at the condition flags, it is dependent on the vast majority of instructions). But the builtin itself doesn't have any side-effects, so if we ignore the result of the builtin, there is no point to emit anything. There is a LRA bug that miscompiles the testcase which this patch makes latent, which is certainly worth fixing too, but IMHO this change (and maybe ix86_gimple_fold_builtin too which would fold it even earlier when it looses lhs) is worth it as well. 2022-03-19 Jakub Jelinek PR middle-end/104971 * config/i386/i386.c (ix86_expand_builtin) : If ignore, don't push/pop anything and just return const0_rtx. * gcc.target/i386/pr104971.c: New test. (cherry picked from commit b60bc913cca7439d29a7ec9e9a7f448d8841b43c)
[Bug c/104711] Unnecessary -Wshift-negative-value warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711 --- Comment #12 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0e02b8468be6b655c43c6d64fef772678681 commit r9-10139-g0e02b8468be6b655c43c6d64fef772678681 Author: Jakub Jelinek Date: Wed Mar 9 09:15:28 2022 +0100 c, c++, c-family: -Wshift-negative-value and -Wshift-overflow* tweaks for -fwrapv and C++20+ [PR104711] As mentioned in the PR, different standards have different definition on what is an UB left shift. They all agree on out of bounds (including negative) shift count. The rules used by ubsan are: C99-C2x ((unsigned) x >> (uprecm1 - y)) != 0 then UB C++11-C++17 x < 0 || ((unsigned) x >> (uprecm1 - y)) > 1 then UB C++20 and later everything is well defined Now, for C++20, I've in the P1236R1 implementation added an early exit for -Wshift-overflow* warning so that it never warns, but apparently -Wshift-negative-value remained as is. As it is well defined in C++20, the following patch doesn't enable -Wshift-negative-value from -Wextra anymore for C++20 and later, if users want for compatibility with C++17 and earlier get the warning, they still can by using -Wshift-negative-value explicitly. Another thing is -fwrapv, that is an extension to the standards, so it is up to us how exactly we define that case. Our ubsan code treats TYPE_OVERFLOW_WRAPS (type0) and cxx_dialect >= cxx20 the same as only diagnosing out of bounds shift count and nothing else and IMHO it is most sensical to treat -fwrapv signed left shifts the same as C++20 treats them, https://eel.is/c++draft/expr.shift#2 "The value of E1 << E2 is the unique value congruent to E1×2^E2 modulo 2^N, where N is the width of the type of the result. [Note 1: E1 is left-shifted E2 bit positions; vacated bits are zero-filled. â end note]" with no UB dependent on the E1 values. The UB is only "The behavior is undefined if the right operand is negative, or greater than or equal to the width of the promoted left operand." Under the hood (except for FEs and ubsan from FEs) GCC middle-end doesn't consider UB in left shifts dependent on the first operand's value, only the out of bounds shifts. While this change isn't a regression, I'd think it is useful for GCC 12, it doesn't add new warnings, but just removes warnings that aren't appropriate. 2022-03-09 Jakub Jelinek PR c/104711 gcc/ * doc/invoke.texi (-Wextra): Document that -Wshift-negative-value is enabled by it only for C++11 to C++17 rather than for C++03 or later. (-Wshift-negative-value): Similarly (except here we stated that it is enabled for C++11 or later). gcc/c-family/ * c-opts.c (c_common_post_options): Don't enable -Wshift-negative-value from -Wextra for C++20 or later. * c-ubsan.c (ubsan_instrument_shift): Adjust comments. * c-warn.c (maybe_warn_shift_overflow): Use TYPE_OVERFLOW_WRAPS instead of TYPE_UNSIGNED. gcc/c/ * c-fold.c (c_fully_fold_internal): Don't emit -Wshift-negative-value warning if TYPE_OVERFLOW_WRAPS. * c-typeck.c (build_binary_op): Likewise. gcc/cp/ * constexpr.c (cxx_eval_check_shift_p): Use TYPE_OVERFLOW_WRAPS instead of TYPE_UNSIGNED. * typeck.c (cp_build_binary_op): Don't emit -Wshift-negative-value warning if TYPE_OVERFLOW_WRAPS. gcc/testsuite/ * c-c++-common/Wshift-negative-value-1.c: Remove dg-additional-options, instead in target selectors of each diagnostic check for exact C++ versions where it should be diagnosed. * c-c++-common/Wshift-negative-value-2.c: Likewise. * c-c++-common/Wshift-negative-value-3.c: Likewise. * c-c++-common/Wshift-negative-value-4.c: Likewise. * c-c++-common/Wshift-negative-value-7.c: New test. * c-c++-common/Wshift-negative-value-8.c: New test. * c-c++-common/Wshift-negative-value-9.c: New test. * c-c++-common/Wshift-negative-value-10.c: New test. * c-c++-common/Wshift-overflow-1.c: Remove dg-additional-options, instead in target selectors of each diagnostic check for exact C++ versions where it should be diagnosed. * c-c++-common/Wshift-overflow-2.c: Likewise. * c-c++-common/Wshift-overflow-5.c: Likewise. * c-c++-common/Wshift-overflow-6.c: Likewise. * c-c++-common/Wshift-overflow-7.c: Likewise. * c-c++-common/Wshift-overflow-8.c: New test. * c-c++-common/Wshift-overflow-9.c: New test. * c-c++-common/Wshift-overflow-10.c: New test. * c-c++-common/Wshift-overflow-11.c: New test.
[Bug c++/104806] Weird error message: did you mean "__dt "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104806 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2a829a4e85ead3e6dff64fe5a8d465cfdf88f3d2 commit r9-10138-g2a829a4e85ead3e6dff64fe5a8d465cfdf88f3d2 Author: Jakub Jelinek Date: Tue Mar 8 21:41:21 2022 +0100 c++: Don't suggest cdtor or conversion op identifiers in spelling hints [PR104806] On the following testcase, we emit "did you mean '__dt '?" in the error message. "__dt " shows there because it is dtor_identifier, but we shouldn't suggest those to the user, they are purely internal and can't be really typed by the user because of the final space in it. 2022-03-08 Jakub Jelinek PR c++/104806 * search.c (lookup_field_fuzzy_info::fuzzy_lookup_field): Ignore identifiers with space at the end. * g++.dg/spellcheck-pr104806.C: New test. (cherry picked from commit e480c3c06d20874fd7504bfdcca0b829f8000389)
[Bug target/104775] [9/10 Regression] Failure to assemble on s390x with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104775 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e763af00a24765a395762a2c1ccf9c55fa2fad47 commit r9-10137-ge763af00a24765a395762a2c1ccf9c55fa2fad47 Author: Jakub Jelinek Date: Mon Mar 7 11:14:04 2022 +0100 s390: Fix up *cmp_and_trap_unsigned_int constraints [PR104775] The following testcase fails to assemble due to clgte %r6,0(%r1,%r10) insn not being accepted by assembler. My rough understanding is that in the RSY-b insn format the spot in other formats used for index registers is used instead for M3 what kind of comparison it is, so this patch follows what other similar instructions use for constraint (i.e. one without index register). 2022-03-07 Jakub Jelinek PR target/104775 * config/s390/s390.md (*cmp_and_trap_unsigned_int): Use S constraint instead of T in the last alternative. * gcc.target/s390/pr104775.c: New test. (cherry picked from commit 2472dcaa8cb9e02e902f83d419c3ee7e0f3d9041)
[Bug tree-optimization/104675] [9/10 Regression] ICE: in expand_expr_real_2, at expr.cc:9773 at -O with __real__ + __imag__ extraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104675 --- Comment #17 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:870a9a8e82269a4213660459eabf0744d583e0c3 commit r9-10136-g870a9a8e82269a4213660459eabf0744d583e0c3 Author: Jakub Jelinek Date: Fri Feb 25 21:25:12 2022 +0100 match.pd: Further complex simplification fixes [PR104675] Mark mentioned in the PR further 2 simplifications that also ICE with complex types. For these, eventually (but IMO GCC 13 materials) we could support it for vector types if it would be uniform vector constants. Currently integer_pow2p is true only for INTEGER_CSTs and COMPLEX_CSTs and we can't use bit_and etc. for complex type. 2022-02-25 Jakub Jelinek Marc Glisse PR tree-optimization/104675 * match.pd (t * 2U / 2 -> t & (~0 / 2), t / 2U * 2 -> t & ~1): Restrict simplifications to INTEGRAL_TYPE_P. * gcc.dg/pr104675-3.c : New test. (cherry picked from commit f62115c9b770a66c5378f78a2d5866243d560573)
[Bug target/104681] [9/10 Regression] ppc64le -mabi=ieeelongdouble ICE since r9-6460
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104681 --- Comment #10 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5c742d9a7e217746de961da20a39f04e5ec1df25 commit r9-10135-g5c742d9a7e217746de961da20a39f04e5ec1df25 Author: Jakub Jelinek Date: Fri Feb 25 18:58:48 2022 +0100 rs6000: Use rs6000_emit_move in movmisalign expander [PR104681] The following testcase ICEs, because for some strange reason it decides to use movmisaligntf during expansion where the destination is MEM and source is CONST_DOUBLE. For normal mov expanders the rs6000 backend uses rs6000_emit_move to ensure that if one operand is a MEM, the other is a REG and a few other things, but for movmisalign nothing enforced this. The middle-end documents that movmisalign shouldn't fail, so we can't force that through predicates or condition on the expander. 2022-02-25 Jakub Jelinek PR target/104681 * config/rs6000/vector.md (movmisalign): Use rs6000_emit_move. * g++.dg/opt/pr104681.C: New test. (cherry picked from commit 3885a122f817a1b6dca4a84ba9e020d5ab2060af)
[Bug tree-optimization/104675] [9/10 Regression] ICE: in expand_expr_real_2, at expr.cc:9773 at -O with __real__ + __imag__ extraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104675
--- Comment #16 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:ff9fe8ef031ed29247b283201f6cfcf729502e11
commit r9-10134-gff9fe8ef031ed29247b283201f6cfcf729502e11
Author: Jakub Jelinek
Date: Fri Feb 25 10:55:17 2022 +0100
match.pd: Don't create BIT_NOT_EXPRs for COMPLEX_TYPE [PR104675]
We don't support BIT_{AND,IOR,XOR,NOT}_EXPR on complex types,
&/|/^ are just rejected for them, and ~ is parsed as CONJ_EXPR.
So, we should avoid simplifications which turn valid complex type
expressions into something that will ICE during expansion.
2022-02-25 Jakub Jelinek
PR tree-optimization/104675
* match.pd (-A - 1 -> ~A, -1 - A -> ~A): Don't simplify for
COMPLEX_TYPE.
* gcc.dg/pr104675-1.c: New test.
* gcc.dg/pr104675-2.c: New test.
(cherry picked from commit 758671b88b78d7629376b118ec6ca6bcfbabbd36)
[Bug lto/104617] Bug in handling of 64k+ sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104617
--- Comment #6 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:2692cbbc12dd08a9f82411e1baf43d6211329b6c
commit r9-10133-g2692cbbc12dd08a9f82411e1baf43d6211329b6c
Author: Jakub Jelinek
Date: Tue Feb 22 11:32:08 2022 +0100
libiberty: Fix up debug.temp.o creation if *.o has 64K+ sections [PR104617]
On
#define A(n) int foo1##n(void) { return 1##n; }
#define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6)
A(n##7) A(n##8) A(n##9)
#define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6)
B(n##7) B(n##8) B(n##9)
#define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6)
C(n##7) C(n##8) C(n##9)
#define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6)
D(n##7) D(n##8) D(n##9)
E(0) E(1) E(2) D(30) D(31) C(320) C(321) C(322) C(323) C(324) C(325)
B(3260) B(3261) B(3262) B(3263) A(32640) A(32641) A(32642)
testcase with
./xgcc -B ./ -c -g -fpic -ffat-lto-objects -flto -O0 -o foo1.o foo1.c
-ffunction-sections
./xgcc -B ./ -shared -g -fpic -flto -O0 -o foo1.so foo1.o
/tmp/ccTW8mBm.debug.temp.o: file not recognized: file format not recognized
(testcase too slow to be included into testsuite).
The problem is clearly reported by readelf:
readelf: foo1.o.debug.temp.o: Warning: Section 2 has an out of range
sh_link value of 65321
readelf: foo1.o.debug.temp.o: Warning: Section 5 has an out of range
sh_link value of 65321
readelf: foo1.o.debug.temp.o: Warning: Section 10 has an out of range
sh_link value of 65323
readelf: foo1.o.debug.temp.o: Warning: [ 2]: Link field (65321) should
index a symtab section.
readelf: foo1.o.debug.temp.o: Warning: [ 5]: Link field (65321) should
index a symtab section.
readelf: foo1.o.debug.temp.o: Warning: [10]: Link field (65323) should
index a string section.
because simple_object_elf_copy_lto_debug_sections doesn't adjust sh_info
and
sh_link fields in ElfNN_Shdr if they are in between SHN_{LO,HI}RESERVE
inclusive. Not adjusting those is incorrect though, SHN_{LO,HI}RESERVE
range is only relevant to the 16-bit fields, mainly st_shndx in ElfNN_Sym
where if one needs >= SHN_LORESERVE section number, SHN_XINDEX should be
used instead and .symtab_shndx section should contain the real section
index, and in ElfNN_Ehdr e_shnum and e_shstrndx fields, where if >=
SHN_LORESERVE value is needed it should put those into
Shdr[0].sh_{size,link}. But, sh_{link,info} are 32-bit fields which can
contain any section index.
Note, as simple-object-elf.c mentions, binutils from 2.12 to 2.18 (so
before
2011) used to mishandle the > 63.75K sections case and assumed there is a
hole in between the sections, but what
simple_object_elf_copy_lto_debug_sections does wouldn't help in that case
for the debug temp object creation, we'd need to detect the case also in
that routine and take it into account in the remapping etc. I think
it is not worth it given that it is over 10 years, if somebody needs
63.75K or more sections, better use more recent binutils.
2022-02-22 Jakub Jelinek
PR lto/104617
* simple-object-elf.c (simple_object_elf_match): Fix up URL
in comment.
(simple_object_elf_copy_lto_debug_sections): Remap sh_info and
sh_link even if they are in the SHN_LORESERVE .. SHN_HIRESERVE
range (inclusive).
(cherry picked from commit 2f59f067610f22c3f2ec9b1516e24b85836676ed)
[Bug debug/104557] [12 Regression] ICE: in simplify_subreg, at simplify-rtx.cc:7324 with -O -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104557
--- Comment #7 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:eca81c14d525ae86463a522275b7ac8be5cdb626
commit r9-10132-geca81c14d525ae86463a522275b7ac8be5cdb626
Author: Jakub Jelinek
Date: Thu Feb 17 11:14:38 2022 +0100
valtrack: Avoid creating raw SUBREGs with VOIDmode argument [PR104557]
After the recent r12-7240 simplify_immed_subreg changes, we bail on more
simplify_subreg calls than before, e.g. apparently for decimal modes
in the NaN representations we almost never preserve anything except the
canonical {q,s}NaNs.
simplify_gen_subreg will punt in such cases because a SUBREG with VOIDmode
is not valid, but debug_lowpart_subreg wants to attempt even harder, even
if e.g. target indicates certain mode combinations aren't valid for the
backend, dwarf2out can still handle them. But a SUBREG from a VOIDmode
operand is just too much, the inner mode is lost there. We'd need some
new rtx that would be able to represent those cases.
For now, just punt in those cases.
2022-02-17 Jakub Jelinek
PR debug/104557
* valtrack.c (debug_lowpart_subreg): Don't call gen_rtx_raw_SUBREG
if expr has VOIDmode.
* gcc.dg/dfp/pr104557.c: New test.
(cherry picked from commit 1c2b44b52364cb5661095b346de794bc7ff02866)
[Bug c/104510] [9/10 Regression] ICE: 'verify_gimple' failed: mismatching comparison operand types in verify_gimple_in_seq()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104510 --- Comment #10 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b65f562b8f203948ebe1c09d9710184b0a2052bb commit r9-10131-gb65f562b8f203948ebe1c09d9710184b0a2052bb Author: Jakub Jelinek Date: Wed Feb 16 09:25:55 2022 +0100 c-family: Fix up shorten_compare for decimal vs. non-decimal float comparison [PR104510] The comment in shorten_compare says: /* If either arg is decimal float and the other is float, fail. */ but the callers of shorten_compare don't expect anything like failure as a possibility from the function, callers require that the function promotes the operands to the same type, whether the original selected *restype_ptr one or some shortened. So, if we choose not to shorten, we should still promote to the original *restype_ptr. 2022-02-16 Jakub Jelinek PR c/104510 * c-common.c (shorten_compare): Convert original arguments to the original *restype_ptr when mixing binary and decimal float. * gcc.dg/dfp/pr104510.c: New test. (cherry picked from commit 6e74122f0de6748b3fd0ed9183090cd7c61fb53e)
[Bug debug/104517] '-fcompare-debug' failure w/ -O1 -fopenmp -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104517 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:57e0795a44639d1cc84abbdd46c507cc64dfa2f8 commit r9-10129-g57e0795a44639d1cc84abbdd46c507cc64dfa2f8 Author: Jakub Jelinek Date: Tue Feb 15 10:22:30 2022 +0100 openmp: Make finalize_task_copyfn order reproduceable [PR104517] The following testcase fails -fcompare-debug, because finalize_task_copyfn was invoked from splay tree destruction, whose order can in some cases depend on -g/-g0. The fix is to queue the task stmts that need copyfn in a vector and run finalize_task_copyfn on elements of that vector. 2022-02-15 Jakub Jelinek PR debug/104517 * omp-low.c (task_cpyfns): New variable. (delete_omp_context): Don't call finalize_task_copyfn from here. (create_task_copyfn): Push task_stmt into task_cpyfns. (execute_lower_omp): Call finalize_task_copyfn here on entries from task_cpyfns vector and release the vector. (cherry picked from commit 6a0d6e7ca9b9e338e82572db79c26168684a7441)
[Bug c++/104513] [12 Regression] goto cdtor_label failures on arm since r12-5256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104513 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:87cd4bc02f602226922e6c8099a2f4687664bed9 commit r9-10128-g87cd4bc02f602226922e6c8099a2f4687664bed9 Author: Jakub Jelinek Date: Mon Feb 14 16:56:15 2022 +0100 c++: Don't reject GOTO_EXPRs to cdtor_label in potential_constant_expression_1 [PR104513] return in ctors on targetm.cxx.cdtor_returns_this () target like arm is emitted as GOTO_EXPR cdtor_label where at cdtor_label it emits RETURN_EXPR with the this. Similarly, in all dtors regardless of targetm.cxx.cdtor_returns_this () a return is emitted similarly. potential_constant_expression_1 was rejecting these gotos and so we incorrectly rejected these testcases, but actual cxx_eval* is apparently handling these just fine. I was a little bit worried that for the destruction of bases we wouldn't evaluate something we should, but as the testcase shows, that is evaluated through try ... finally and there is nothing after the cdtor_label. For arm there is RETURN_EXPR this; but we don't really care about the return value from ctors and dtors during the constexpr evaluation. I must say I don't see much the point of cdtor_labels at all, I'd think that with try ... finally around it for non-arm we could just RETURN_EXPR instead of the GOTO_EXPR and the try/finally gimplification would DTRT, and we could just add the right return value for the arm case. 2022-02-14 Jakub Jelinek PR c++/104513 * constexpr.c (potential_constant_expression_1) : Don't punt if returns (target). * g++.dg/cpp1y/constexpr-104513.C: New test. (cherry picked from commit 02a981a8e512934a990d1427d14e8e884409fade)
[Bug sanitizer/104449] [9/10 Regression] ICE: verify_gimple failed: dead statement in EH table with -fexceptions -fsanitize=address -fstack-check=generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104449 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:77ee9b906d1c214648230d417b45831b8ef8386a commit r9-10127-g77ee9b906d1c214648230d417b45831b8ef8386a Author: Jakub Jelinek Date: Sat Feb 12 19:17:44 2022 +0100 asan: Fix up address sanitizer instrumentation of __builtin_alloca* if it can throw [PR104449] With -fstack-check* __builtin_alloca* can throw and the asan instrumentation of this builtin wasn't prepared for that case. The following patch fixes that by replacing the builtin with the replacement builtin and emitting any further insns on the fallthru edge. I haven't touched the hwasan code which most likely suffers from the same problem. 2022-02-12 Jakub Jelinek PR sanitizer/104449 * asan.c: Include tree-eh.h. (handle_builtin_alloca): Handle the case when __builtin_alloca or __builtin_alloca_with_align can throw. * gcc.dg/asan/pr104449.c: New test. * g++.dg/asan/pr104449.C: New test. (cherry picked from commit f0c7367b8802c47efaad87b1f2126fe6350d8b47)
[Bug target/104502] [12 Regression] ICE: in extract_constrain_insn, at recog.cc:2670: insn does not satisfy its constraints with -O -flive-range-shrinkage -march=barcelona -fstack-protector-all -mavx5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104502 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cb412e0e881adcc5440ed37a8a415a77fe3df980 commit r9-10126-gcb412e0e881adcc5440ed37a8a415a77fe3df980 Author: Jakub Jelinek Date: Sat Feb 12 11:17:41 2022 +0100 i386: Fix up cvtsd2ss splitter [PR104502] The following testcase ICEs, because AVX512F is enabled, AVX512VL is not, and the cvtsd2ss insn has %xmm0-15 as output operand and %xmm16-31 as input operand. For output operand %xmm16+ the splitter just gives up in such case, but for such input it just emits vmovddup which requires AVX512VL if either operand is EXT_REX_SSE_REG_P (when it is 128-bit). The following patch fixes it by treating that case like the pre-SSE3 output != input case - move the input to output and do everything on the output reg which is known to be < %xmm16. 2022-02-12 Jakub Jelinek PR target/104502 * config/i386/i386.md (cvtsd2ss splitter): If operands[1] is xmm16+ and AVX512VL isn't available, move operands[1] to operands[0] first. * gcc.target/i386/pr104502.c: New test. (cherry picked from commit 0538d42cdd68f6b65d72ed7768f1d00ba44f8631)
[Bug c++/104472] ICE: SIGSEGV in cxx_eval_internal_function with __builtin_convertvector and -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104472 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c7e7ca915dc4c526b1f58a4808c7ec4ceaa30348 commit r9-10125-gc7e7ca915dc4c526b1f58a4808c7ec4ceaa30348 Author: Jakub Jelinek Date: Fri Feb 11 13:52:44 2022 +0100 c++: Fix up constant expression __builtin_convertvector folding [PR104472] The following testcase ICEs, because due to the -frounding-math fold_const_call fails, which is it returns NULL, and returning NULL from cxx_eval* is wrong, all the callers rely on them to either return folded value or original with *non_constant_p = true. The following patch does that, and additionally falls through into the default case where there is diagnostics for the !ctx->quiet case too. 2022-02-11 Jakub Jelinek PR c++/104472 * constexpr.c (cxx_eval_internal_function) : Only return fold_const_call result if it is non-NULL. Otherwise fall through into the default: case to return t, set *non_constant_p and emit diagnostics if needed. * g++.dg/cpp0x/constexpr-104472.C: New test. (cherry picked from commit 84993d94e13ad2ab3aee151bb5a5e767cf75d51e)
[Bug middle-end/104446] [9/10 Regression] ICE in trunc_int_for_mode, at explow.cc:59 since r9-6999
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104446
--- Comment #11 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:ffbe41f14f416dd0660108d78ee550256bdca7ea
commit r9-10124-gffbe41f14f416dd0660108d78ee550256bdca7ea
Author: Jakub Jelinek
Date: Fri Feb 11 11:34:46 2022 +0100
combine: Fix ICE with substitution of CONST_INT into PRE_DEC argument
[PR104446]
The following testcase ICEs, because combine substitutes
(insn 10 9 11 2 (set (reg/v:SI 7 sp [ a ])
(const_int 0 [0])) "pr104446.c":9:5 81 {*movsi_internal}
(nil))
(insn 13 11 14 2 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A32])
(reg:SI 85)) "pr104446.c":10:3 56 {*pushsi2}
(expr_list:REG_DEAD (reg:SI 85)
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil
forming
(insn 13 11 14 2 (set (mem/f:SI (pre_dec:SI (const_int 0 [0])) [0 S4 A32])
(reg:SI 85)) "pr104446.c":10:3 56 {*pushsi2}
(expr_list:REG_DEAD (reg:SI 85)
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil
which is invalid RTL (pre_dec's argument must be a REG).
I know substitution creates various forms of invalid RTL and hopes that
invalid RTL just won't recog.
But unfortunately in this case we ICE before we get to recog, as
try_combine does:
if (n_auto_inc)
{
int new_n_auto_inc = 0;
for_each_inc_dec (newpat, count_auto_inc, &new_n_auto_inc);
if (n_auto_inc != new_n_auto_inc)
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "Number of auto_inc expressions
changed\n");
undo_all ();
return 0;
}
}
and for_each_inc_dec under the hood will do e.g. for the PRE_DEC case:
case PRE_DEC:
case POST_DEC:
{
poly_int64 size = GET_MODE_SIZE (GET_MODE (mem));
rtx r1 = XEXP (x, 0);
rtx c = gen_int_mode (-size, GET_MODE (r1));
return fn (mem, x, r1, r1, c, data);
}
and that code rightfully expects that the PRE_DEC operand has non-VOIDmode
(as it needs to be a REG) - gen_int_mode for VOIDmode results in ICE.
I think it is better not to emit the clearly invalid RTL during
substitution
like we do for other cases, than to adding workarounds for invalid IL
created by combine to rtlanal.cc and perhaps elsewhere.
As for the testcase, of course it is UB at runtime to modify sp that way,
but if such code is never reached, we must compile it, not to ICE on it.
And I don't see why on other targets which use the autoinc rtxes much more
it couldn't happen with other registers.
2022-02-11 Jakub Jelinek
PR middle-end/104446
* combine.c (subst): Don't substitute CONST_INTs into RTX_AUTOINC
operands.
* gcc.target/i386/pr104446.c: New test.
(cherry picked from commit fb76c0ad35f96505ecd9213849ebc3df6163a0f7)
[Bug target/102140] [12 Regression] ICE: in extract_constrain_insn, at recog.c:2670 (insn does not satisfy its constraints) with -Og -fipa-cp -fno-tree-ccp -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102140 --- Comment #10 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8c9f4bafe532508904d4d16379d6882ddedac367 commit r9-10123-g8c9f4bafe532508904d4d16379d6882ddedac367 Author: Jakub Jelinek Date: Tue Feb 8 20:14:30 2022 +0100 rs6000: Fix up vspltis_shifted [PR102140] The following testcase ICEs, because (const_vector:V4SI [ (const_int 0 [0]) repeated x3 (const_int -2147483648 [0x8000]) ]) is recognized as valid easy_vector_constant in between split1 pass and end of RA. The problem is that such constants need to be split, and the only splitter for that is: (define_split [(set (match_operand:VM 0 "altivec_register_operand") (match_operand:VM 1 "easy_vector_constant_vsldoi"))] "VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode) && can_create_pseudo_p ()" There is only a single splitting pass before RA, so after that finishes, if something gets matched in between that and end of RA (after that can_create_pseudo_p () would be no longer true), it will never be successfully split and we ICE at final.cc time or earlier. The i386 backend (and a few others) already use (cfun->curr_properties & PROP_rtl_split_insns) as a test for split1 pass finished, so that some insns that should be split during split1 and shouldn't be matched afterwards are properly guarded. So, the following patch does that for vspltis_shifted too. 2022-02-08 Jakub Jelinek PR target/102140 * config/rs6000/rs6000.c (vspltis_shifted): Return false also if split1 pass has finished already. * gcc.dg/pr102140.c: New test. (cherry picked from commit 0c3e491a4e5ae74bfbed6d167d403d262b5a4adc)
[Bug libgomp/104385] Segmentation fault when using nested dependent tasks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104385 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b7e9d466fcf2f7c44ae31a2b308b0f1e406d1b9f commit r9-10122-gb7e9d466fcf2f7c44ae31a2b308b0f1e406d1b9f Author: Jakub Jelinek Date: Tue Feb 8 09:30:17 2022 +0100 libgomp: Fix segfault with posthumous orphan tasks [PR104385] The following patch fixes crashes with posthumous orphan tasks. When a parent task finishes, gomp_clear_parent clears the parent pointers of its children tasks present in the parent->children_queue. But children that are still waiting for dependencies aren't in that queue yet, they will be added there only when the sibling they are waiting for exits. Unfortunately we were adding those tasks into the queues with the original task->parent which then causes crashes because that task is gone and freed. The following patch fixes that by clearing the parent field when we schedule such task for running by adding it into the queues and we know that the sibling task which is about to finish has NULL parent. 2022-02-08 Jakub Jelinek PR libgomp/104385 * task.c (gomp_task_run_post_handle_dependers): If parent is NULL, clear task->parent. * testsuite/libgomp.c/pr104385.c: New test. (cherry picked from commit 0af7ef050aed9f678d70d79931ede38374fde863)
[Bug preprocessor/104147] [9/10 Regression] C preprocessor may remove the standard required whitespace between the preprocessing tokens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104147
--- Comment #9 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:7157e074472435489963cf6961cd4c2d06804f4d
commit r9-10121-g7157e074472435489963cf6961cd4c2d06804f4d
Author: Jakub Jelinek
Date: Tue Feb 1 20:48:03 2022 +0100
libcpp: Fix up padding handling in funlike_invocation_p [PR104147]
As mentioned in the PR, in some cases we preprocess incorrectly when we
encounter an identifier which is defined as function-like macro, followed
by at least 2 CPP_PADDING tokens and then some other identifier.
On the following testcase, the problem is in the 3rd funlike_invocation_p,
the tokens are CPP_NAME Y, CPP_PADDING (the pfile->avoid_paste shared
token),
CPP_PADDING (one created with padding_token, val.source is non-NULL and
val.source->flags & PREV_WHITE is non-zero) and then another CPP_NAME.
funlike_invocation_p remembers there was a padding token, but remembers the
first one because of its condition, then the next token is the CPP_NAME,
which is not CPP_OPEN_PAREN, so the CPP_NAME token is backed up, but as we
can't easily backup more tokens, it pushes into a new context the padding
token (the pfile->avoid_paste one). The net effect is that when Y is not
defined as fun-like macro, we read Y, avoid_paste, padding_token, Y,
while if Y is fun-like macro, we read Y, avoid_paste, avoid_paste, Y
(the second avoid_paste is because that is how we handle end of a context).
Now, for stringify_arg that is unfortunately a significant difference,
which handles CPP_PADDING tokens with:
if (token->type == CPP_PADDING)
{
if (source == NULL
|| (!(source->flags & PREV_WHITE)
&& token->val.source == NULL))
source = token->val.source;
continue;
}
and later on
/* Leading white space? */
if (dest - 1 != BUFF_FRONT (pfile->u_buff))
{
if (source == NULL)
source = token;
if (source->flags & PREV_WHITE)
*dest++ = ' ';
}
source = NULL;
(and c-ppoutput.cc has similar code).
So, when Y is not fun-like macro, ' ' is added because padding_token's
val.source->flags & PREV_WHITE is non-zero, while when it is fun-like
macro, we don't add ' ' in between, because source is NULL and so
used from the next token (CPP_NAME Y), which doesn't have PREV_WHITE set.
Now, the funlike_invocation_p condition
if (padding == NULL
|| (!(padding->flags & PREV_WHITE) && token->val.source ==
NULL))
padding = token;
looks very similar to that in stringify_arg/c-ppoutput.cc, so I assume
the intent was to prefer do the same thing and pick the right padding.
But there are significant differences. Both stringify_arg and
c-ppoutput.cc
don't remember the CPP_PADDING token, but its val.source instead, while
in funlike_invocation_p we want to remember the padding token that has the
significant information for stringify_arg/c-ppoutput.cc.
So, IMHO we want to overwrite padding if:
1) padding == NULL (remember that there was any padding at all)
2) padding->val.source == NULL (this matches the source == NULL
case in stringify_arg)
3) !(padding->val.source->flags & PREV_WHITE) && token->val.source == NULL
(this matches the !(source->flags & PREV_WHITE) && token->val.source ==
NULL
case in stringify_arg)
2022-02-01 Jakub Jelinek
PR preprocessor/104147
* macro.c (funlike_invocation_p): For padding prefer a token
with val.source non-NULL especially if it has PREV_WHITE set
on val.source->flags. Add gcc_assert that CPP_PADDING tokens
don't have PREV_WHITE set in flags.
* c-c++-common/cpp/pr104147.c: New test.
(cherry picked from commit 95ac5635409606386259d2ff21fb61738858ca4a)
[Bug rtl-optimization/102478] [9/10 Regression] during RTL pass: ce3: ICE: in gen_reg_rtx, at emit-rtl.c:1167 with -O2 -fno-if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102478 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:02da8ea28601e2d85447550cad3429f8127f646b commit r9-10119-g02da8ea28601e2d85447550cad3429f8127f646b Author: Jakub Jelinek Date: Fri Jan 21 11:16:50 2022 +0100 optabs: Don't create pseudos in prepare_cmp_insn when not allowed [PR102478] cond traps can be created during ce3 after reload (and e.g. PR103028 recently fixed some ce3 cond trap related bug, so I think often that works fine and we shouldn't disable cond traps after RA altogether), but it calls prepare_cmp_insn. This function can fail, so I don't see why we couldn't make it work after RA (in most cases it already just works). The first hunk is just an optimization which doesn't make sense after RA, so I've guarded it with can_create_pseudo_p. The second hunk is just a theoretical case, I don't have a testcase for it. prepare_cmp_insn has some other spots that can create pseudos, like when both operands have VOIDmode, or when it is BLKmode comparison, or not OPTAB_DIRECT, but I think none of that applies to ce3, we punt on BLKmode earlier, use OPTAB_DIRECT and shouldn't be comparing two VOIDmode CONST_INTs. 2022-01-21 Jakub Jelinek PR rtl-optimization/102478 * optabs.c (prepare_cmp_insn): If !can_create_pseudo_p (), don't force_reg constants and for -fnon-call-exceptions fail if copy_to_reg would be needed. * gcc.dg/pr102478.c: New test. (cherry picked from commit c2d9159717b474f9c06dde4d32b48b87164deb50)
[Bug middle-end/102860] [12 regression] libgomp.fortran/simd2.f90 ICEs after r12-4526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102860
--- Comment #16 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:95f6eb7ae707482fdeed57b0906dacb8e675385d
commit r9-10118-g95f6eb7ae707482fdeed57b0906dacb8e675385d
Author: Jakub Jelinek
Date: Wed Jan 19 15:03:45 2022 +0100
match.pd, optabs: Avoid vectorization of {FLOOR,CEIL,ROUND}_{DIV,MOD}_EXPR
[PR102860]
power10 has modv4si3 expander and so vectorizes the following testcase
where Fortran modulo is FLOOR_MOD_EXPR.
optabs_for_tree_code indicates that the optab for all the *_MOD_EXPR
variants is umod_optab or smod_optab, but that isn't true, that optab
actually expands just TRUNC_MOD_EXPR. For the other tree codes expmed.cc
has code how to adjust the TRUNC_MOD_EXPR into those by emitting some
extra comparisons and conditional updates. Similarly for *_DIV_EXPR,
except in that case it actually needs both division and modulo.
While it would be possible to handle it in expmed.cc for vectors as well,
we'd need to be sure all the vector operations we need for that are
available, and furthermore we wouldn't account for that in the costing.
So, IMHO it is better to stop pretending those non-truncating (and
non-exact) div/mod operations have an optab. For GCC 13, we should
IMHO pattern match these in tree-vect-patterns.cc and transform them
to truncating div/mod with follow-up adjustments and let the vectorizer
vectorize that. As written in the PR, for signed operands:
r = x %[fl] y;
is
r = x % y; if (r && (x ^ y) < 0) r += y;
and
d = x /[fl] y;
is
r = x % y; d = x / y; if (r && (x ^ y) < 0) --d;
and
r = x %[cl] y;
is
r = x % y; if (r && (x ^ y) >= 0) r -= y;
and
d = /[cl] y;
is
r = x % y; d = x / y; if (r && (x ^ y) >= 0) ++d;
(too lazy to figure out rounding div/mod now). I'll create a PR
for that.
The patch also extends a match.pd optimization that floor_mod on
unsigned operands is actually trunc_mod.
2022-01-19 Jakub Jelinek
PR middle-end/102860
* match.pd (x %[fl] y -> x % y): New simplification for
unsigned integral types.
* optabs-tree.c (optab_for_tree_code): Return unknown_optab
for {CEIL,FLOOR,ROUND}_{DIV,MOD}_EXPR with VECTOR_TYPE.
* gfortran.dg/pr102860.f90: New test.
(cherry picked from commit ffc7f200adbdf47f14b3594d9b21855c19cf797a)
[Bug rtl-optimization/103908] gcc miscompile asm goto for O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103908
--- Comment #11 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:e875dc9f975ee0a1f9468fda9ee29533cca77181
commit r9-10117-ge875dc9f975ee0a1f9468fda9ee29533cca77181
Author: Jakub Jelinek
Date: Thu Jan 6 09:29:34 2022 +0100
ifcvt: Check for asm goto at the end of then_bb/else_bb in ifcvt [PR103908]
On the following testcase, RTL ifcvt sees then_bb
(note 7 6 8 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 8 7 9 3 (set (mem/c:SI (symbol_ref:DI ("b") [flags 0x2] ) [1 b+0 S4 A32])
(const_int 1 [0x1])) "pr103908.c":6:7 81 {*movsi_internal}
(nil))
(jump_insn 9 8 13 3 (parallel [
(asm_operands/v ("# insn 1") ("") 0 []
[]
[
(label_ref:DI 21)
] pr103908.c:7)
(clobber (reg:CC 17 flags))
]) "pr103908.c":7:5 -1
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil))
-> 21)
and similarly else_bb (just with a different asm_operands template).
It checks that those basic blocks have a single successor and
uses last_active_insn which intentionally skips over JUMP_INSNs, sees
both basic blocks contain the same set and merges them (or if the
sets are different, attempts some other noce optimization).
But we can't assume that the jump, even when it has only a single
successor,
has no side-effects.
The following patch fixes it by punting if test_bb ends with a JUMP_INSN
that isn't onlyjump_p.
2022-01-06 Jakub Jelinek
PR rtl-optimization/103908
* ifcvt.c (bb_valid_for_noce_process_p): Punt on bbs ending with
asm goto.
* gcc.target/i386/pr103908.c: New test.
(cherry picked from commit 80ad67e2af0620d58d57d0406dc22693cf5b8ca9)
[Bug preprocessor/89971] [9/10 Regression] ICE: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89971 --- Comment #13 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:86b98701bf927ea438354723932e623557c04e42 commit r9-10116-g86b98701bf927ea438354723932e623557c04e42 Author: Jakub Jelinek Date: Thu Dec 30 22:23:58 2021 +0100 libcpp: Fix up ##__VA_OPT__ handling [PR89971] In the following testcase we incorrectly error about pasting / token with padding token (which is a result of __VA_OPT__); instead we should like e.g. for ##arg where arg is empty macro argument clear PASTE_LEFT flag of the previous token if __VA_OPT__ doesn't add any real tokens (which can happen either because the macro doesn't have any tokens passed to ... (i.e. __VA_ARGS__ expands to empty) or when __VA_OPT__ doesn't have any tokens in between ()s). 2021-12-30 Jakub Jelinek PR preprocessor/89971 libcpp/ * macro.c (replace_args): For ##__VA_OPT__, if __VA_OPT__ expands to no tokens at all, drop PASTE_LEFT flag from the previous token. gcc/testsuite/ * c-c++-common/cpp/va-opt-9.c: New test. (cherry picked from commit 5545d1edcbdb1701443f94dde7ec97c5ce3e1a6c)
[Bug rtl-optimization/103860] [9/10 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103860 --- Comment #14 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5d96fb401e1c03b6b6a6ec2c5276dfdc479bb3e4 commit r9-10115-g5d96fb401e1c03b6b6a6ec2c5276dfdc479bb3e4 Author: Jakub Jelinek Date: Thu Dec 30 14:23:18 2021 +0100 shrink-wrapping: Fix up prologue block discovery [PR103860] The following testcase is miscompiled, because a prologue which contains subq $8, %rsp instruction is emitted at the start of a basic block which contains conditional jump that depends on flags register set in an earlier basic block, the prologue instruction then clobbers those flags. Normally this case is checked by can_get_prologue predicate, but this is done only at the start of the loop. If we update pro later in the loop (because some bb shouldn't be duplicated) and then don't push anything further into vec and the vec is already empty (this can happen when the new pro is already in bb_with bitmask and either has no successors (that is the case in the testcase where that bb ends with a trap) or all the successors are already in bb_with, then the loop doesn't iterate further and can_get_prologue will not be checked. The following simple patch makes sure we call can_get_prologue even after the last former iteration when vec is already empty and only break from the loop afterwards (and only if the updating of pro done because of !can_get_prologue didn't push anything into vec again). 2021-12-30 Jakub Jelinek PR rtl-optimization/103860 * shrink-wrap.c (try_shrink_wrapping): Make sure can_get_prologue is called on pro even if nothing further is pushed into vec. * gcc.dg/pr103860.c: New test. (cherry picked from commit 1820137ba624d7eb2004a10f9632498b6bc1696a)
[Bug rtl-optimization/103837] [9/10 Regression] '-fcompare-debug' failure (length) w/ -Og -fmove-loop-invariants -fnon-call-exceptions -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103837 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d7dbfed37a3622f72a6c2607343fa62ed579fb40 commit r9-10114-gd7dbfed37a3622f72a6c2607343fa62ed579fb40 Author: Jakub Jelinek Date: Tue Dec 28 17:40:17 2021 +0100 loop-invariant: Fix -fcompare-debug failure [PR103837] In the following testcase we have a -fcompare-debug failure, because can_move_invariant_reg doesn't ignore DEBUG_INSNs in its decisions. In the testcase we have due to uninitialized variable: loop_header debug_insn using pseudo84 pseudo84 = invariant insn using pseudo84 end loop and with -g decide not to move the pseudo84 = invariant before the loop header; in this case not resetting the debug insns might be fine. But, we could have also: pseudo84 = whatever loop_header debug_insn using pseudo84 pseudo84 = invariant insn using pseudo84 end loop and in that case not resetting the debug insns would result in wrong-debug. And, we don't really have generally a good substitution on what pseudo84 contains, it could inherit various values from different paths. So, the following patch ignores DEBUG_INSNs in the decisions, and if there are any that previously prevented the optimization, resets them before return true. 2021-12-28 Jakub Jelinek PR rtl-optimization/103837 * loop-invariant.c (can_move_invariant_reg): Ignore DEBUG_INSNs in the decisions whether to return false or continue and right before returning true reset those debug insns that previously caused returning false. * gcc.dg/pr103837.c: New test. (cherry picked from commit 3c5fd3616f73fbcd241cc3a5e09275c2b0c49bd4)
[Bug tree-optimization/103435] [12 Regression] gcc/gimple-ssa-store-merging.c:879:13: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103435 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:790b8d49ebf7c0827c9aeaad3c8c5bf7168ed17b commit r9-10113-g790b8d49ebf7c0827c9aeaad3c8c5bf7168ed17b Author: Jakub Jelinek Date: Sat Nov 27 13:00:55 2021 +0100 bswap: Fix UB in find_bswap_or_nop_finalize [PR103435] On gcc.c-torture/execute/pr103376.c in the following code we trigger UB in the compiler. n->range is 8 because it is 64-bit load and rsize is 0 because it is a bswap sequence with load and known to be 0: /* Find real size of result (highest non-zero byte). */ if (n->base_addr) for (tmpn = n->n, rsize = 0; tmpn; tmpn >>= BITS_PER_MARKER, rsize++); else rsize = n->range; The shifts then shift uint64_t by 64 bits. For this case mask is 0 and we want both *cmpxchg and *cmpnop as 0, the operation can be done as both nop and bswap and callers will prefer nop. 2021-11-27 Jakub Jelinek PR tree-optimization/103435 * gimple-ssa-store-merging.c (find_bswap_or_nop_finalize): Avoid UB if n->range - rsize == 8, just clear both *cmpnop and *cmpxchg in that case. (cherry picked from commit 567d5f3d62fba2a23a9e975f7e7c7b61bb67cf24)
[Bug fortran/103315] Gfortran DW_AT_Rank expression not emitting correct rank value.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103315 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4a3c9aabb05d823e5e459a8ccefc1b18c0817eec commit r9-10112-g4a3c9aabb05d823e5e459a8ccefc1b18c0817eec Author: Jakub Jelinek Date: Sun Nov 21 21:08:04 2021 +0100 fortran, debug: Fix up DW_AT_rank [PR103315] For DW_AT_rank we were emitting .uleb128 0x4# DW_AT_rank .byte 0x97# DW_OP_push_object_address .byte 0x23# DW_OP_plus_uconst .uleb128 0x1c .byte 0x6 # DW_OP_deref on 64-bit and .uleb128 0x4# DW_AT_rank .byte 0x97# DW_OP_push_object_address .byte 0x23# DW_OP_plus_uconst .uleb128 0x10 .byte 0x6 # DW_OP_deref on 32-bit. I think this is wrong, as dtype.rank field in the descriptor has unsigned char type, not pointer type nor pointer sized integral. E.g. if we have a REAL :: a(..) dummy argument, which is passed as a reference to the function descriptor, we want to evaluate a->dtype.rank. The above DWARF expressions perform *(uintptr_t *)(a + 0x1c) and *(uintptr_t *)(a + 0x10) respectively. The following patch changes those to: .uleb128 0x5# DW_AT_rank .byte 0x97# DW_OP_push_object_address .byte 0x23# DW_OP_plus_uconst .uleb128 0x1c .byte 0x94# DW_OP_deref_size .byte 0x1 and .uleb128 0x5# DW_AT_rank .byte 0x97# DW_OP_push_object_address .byte 0x23# DW_OP_plus_uconst .uleb128 0x10 .byte 0x94# DW_OP_deref_size .byte 0x1 which perform *(unsigned char *)(a + 0x1c) and *(unsigned char *)(a + 0x10) respectively. 2021-11-21 Jakub Jelinek PR debug/103315 * trans-types.c (gfc_get_array_descr_info): Use DW_OP_deref_size 1 instead of DW_OP_deref for DW_AT_rank. (cherry picked from commit da17c304e22ba256eba0b03710aa329115163b08)
[Bug c++/70796] [DR 1030] Initialization order with braced-init-lists still broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70796
--- Comment #11 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:547692808b419da9ed33a9259d031cf62c614dfc
commit r9-10111-g547692808b419da9ed33a9259d031cf62c614dfc
Author: Jakub Jelinek
Date: Fri Nov 19 10:05:01 2021 +0100
c++: Fix up -fstrong-eval-order handling of call arguments [PR70796]
For -fstrong-eval-order (default for C++17 and later) we make sure to
gimplify arguments in the right order, but as the following testcase
shows that is not enough.
The problem is that some lvalues can satisfy the is_gimple_val / fb_rvalue
predicate used by gimplify_arg for is_gimple_reg_type typed expressions,
or is_gimple_lvalue / fb_either used for other types.
E.g. in foo we have:
C::C (&p, ++i, ++i)
before gimplification where i is an automatic int variable and without this
patch gimplify that as:
i = i + 1;
i = i + 1;
C::C (&p, i, i);
which means that the ctor is called with the original i value incremented
by 2 in both arguments, while because the call is CALL_EXPR_ORDERED_ARGS
the first argument should be different. Similarly in qux we have:
B::B (&p, TARGET_EXPR ,
TARGET_EXPR )
and gimplify it as:
_1 = A::operator++ (&i);
_2 = A::operator++ (&i);
B::B (&p, MEM[(const struct A &)_1], MEM[(const struct A &)_2]);
but because A::operator++ returns the passed in argument, again we have
the same value in both cases due to gimplify_arg doing:
/* Also strip a TARGET_EXPR that would force an extra copy. */
if (TREE_CODE (*arg_p) == TARGET_EXPR)
{
tree init = TARGET_EXPR_INITIAL (*arg_p);
if (init
&& !VOID_TYPE_P (TREE_TYPE (init)))
*arg_p = init;
}
which is perfectly fine optimization for calls with unordered arguments,
but breaks the ordered ones.
Lastly, in corge, we have before gimplification:
D::foo (NON_LVALUE_EXPR , 3, ++p)
and gimplify it as
p = p + 4;
D::foo (p, 3, p);
which is again wrong, because the this argument isn't before the
side-effects but after it.
The following patch adds cp_gimplify_arg wrapper, which if ordered
and is_gimple_reg_type forces non-SSA_NAME is_gimple_variable
result into a temporary, and if ordered, not is_gimple_reg_type
and argument is TARGET_EXPR bypasses the gimplify_arg optimization.
So, in foo with this patch we gimplify it as:
i = i + 1;
i.0_1 = i;
i = i + 1;
C::C (&p, i.0_1, i);
in qux as:
_1 = A::operator++ (&i);
D.2312 = MEM[(const struct A &)_1];
_2 = A::operator++ (&i);
B::B (&p, D.2312, MEM[(const struct A &)_2]);
where D.2312 is a temporary and in corge as:
p.9_1 = p;
p = p + 4;
D::foo (p.9_1, 3, p);
The is_gimple_reg_type forcing into a temporary should be really cheap
(I think even at -O0 it should be optimized if there is no modification in
between), the aggregate copies might be more expensive but I think e.g. SRA
or FRE should be able to deal with those if there are no intervening
changes. But still, the patch tries to avoid those when it is cheaply
provable that nothing bad happens (if no argument following it in the
strong evaluation order doesn't have TREE_SIDE_EFFECTS, then even VAR_DECLs
etc. shouldn't be modified after it). There is also an optimization to
avoid doing that for this or for arguments with reference types as nothing
can modify the parameter values during evaluation of other argument's
side-effects.
I've tried if e.g.
int i = 1;
return i << ++i;
doesn't suffer from this problem as well, but it doesn't, the FE uses
SAVE_EXPR , SAVE_EXPR << ++i;
in that case which gimplifies the way we want (temporary in the first
operand).
2021-11-19 Jakub Jelinek
PR c++/70796
* cp-gimplify.c (cp_gimplify_arg): New function.
(cp_gimplify_expr): Use cp_gimplify_arg instead of gimplify_arg,
pass true as last argument to it if there are any following
arguments in strong evaluation order with side-effects.
* g++.dg/cpp1z/eval-order11.C: New test.
(cherry picked from commit a84177aff7ca86f501d6aa5ef407fac5e71f56fb)
[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192 --- Comment #25 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1f02d664cdcc8824c56b7d20a98a3aaa8fc6f0f8 commit r9-10110-g1f02d664cdcc8824c56b7d20a98a3aaa8fc6f0f8 Author: Jakub Jelinek Date: Wed Nov 17 14:18:42 2021 +0100 lim: Reset flow sensitive info even for pointers [PR103192] Since 2014 is lim clearing SSA_NAME_RANGE_INFO for integral SSA_NAMEs if moving them from conditional contexts inside of a loop into unconditional before the loop, but as the miscompilation of gimplify.c shows, we need to treat pointers the same, even for them we need to reset whether the pointer can/can't be null or the recorded pointer alignment. This fixes -FAIL: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c (internal compiler error) -FAIL: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c (test for excess errors) -UNRESOLVED: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c compilation failed to produce executable -FAIL: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c (internal compiler error) -FAIL: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c (test for excess errors) -UNRESOLVED: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c compilation failed to produce executable -FAIL: libgomp.c++/target-in-reduction-2.C (internal compiler error) -FAIL: libgomp.c++/target-in-reduction-2.C (test for excess errors) -UNRESOLVED: libgomp.c++/target-in-reduction-2.C compilation failed to produce executable on both x86_64 and i686. 2021-11-17 Jakub Jelinek PR tree-optimization/103192 * tree-ssa-loop-im.c (move_computations_worker): Use reset_flow_sensitive_info instead of manually clearing SSA_NAME_RANGE_INFO and do it for all SSA_NAMEs, not just ones with integral types. (cherry picked from commit 077425c890927eefacb765ab5236060de9859e82)
[Bug target/103205] [9/10 Regression] ICE Segmentation fault since r7-532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103205 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:294682dc23b18341b9ce869a3aa646015d3cd25a commit r9-10109-g294682dc23b18341b9ce869a3aa646015d3cd25a Author: Jakub Jelinek Date: Mon Nov 15 09:30:08 2021 +0100 i386: Fix up x86 atomic_bit_test* expanders for !TARGET_HIMODE_MATH [PR103205] With !TARGET_HIMODE_MATH, the OPTAB_DIRECT expand_simple_binop fail and so we ICE. We don't really care if they are done promoted in SImode instead. 2021-11-15 Jakub Jelinek PR target/103205 * config/i386/sync.md (atomic_bit_test_and_set, atomic_bit_test_and_complement, atomic_bit_test_and_reset): Use OPTAB_WIDEN instead of OPTAB_DIRECT. * gcc.target/i386/pr103205.c: New test. (cherry picked from commit 625eef42e32e65b3da0e65e23a706d228896d01c)
[Bug debug/101378] Negative DW_AT_data_member_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101378
--- Comment #14 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:4b14a4af62368e8b4892c195e4af80be8893bb0b
commit r9-10108-g4b14a4af62368e8b4892c195e4af80be8893bb0b
Author: Jakub Jelinek
Date: Thu Nov 11 10:14:04 2021 +0100
dwarf2out: Fix up field_byte_offset [PR101378]
For PCC_BITFIELD_TYPE_MATTERS field_byte_offset has quite large code
to deal with it since many years ago (see it e.g. in GCC 3.2, although it
used to be on HOST_WIDE_INTs, then on double_ints, now on offset_ints).
But that code apparently isn't able to cope with members with empty class
types with [[no_unique_address]] attribute, because the empty classes have
non-zero type size but zero decl size and so one can end up from the
computation with negative offset or offset 1 byte smaller than it should
be.
For !PCC_BITFIELD_TYPE_MATTERS, we just use
tree_result = byte_position (decl);
which seems exactly right even for the empty classes or anything which is
not a bitfield (and for which we don't add DW_AT_bit_offset attribute).
So, instead of trying to handle those no_unique_address members in the
current already very complicated code, this limits it to bitfields.
stor-layout.c PCC_BITFIELD_TYPE_MATTERS handling also affects only
bitfields, twice it checks DECL_BIT_FIELD and once DECL_BIT_FIELD_TYPE.
As discussed, this patch uses DECL_BIT_FIELD_TYPE check, because
DECL_BIT_FIELD might be cleared for some bitfields with bitsizes
multiple of BITS_PER_UNIT and e.g.
struct S { int e; int a : 1, b : 7, c : 8, d : 16; } s;
struct T { int a : 1, b : 7; long long c : 8; int d : 16; } t;
int
main ()
{
s.c = 0x55;
s.d = 0x;
t.c = 0x55;
t.d = 0x;
s.e++;
}
has different debug info with DECL_BIT_FIELD check.
2021-11-11 Jakub Jelinek
PR debug/101378
* dwarf2out.c (field_byte_offset): Do the PCC_BITFIELD_TYPE_MATTERS
handling only for DECL_BIT_FIELD_TYPE decls.
* g++.dg/debug/dwarf2/pr101378.C: New test.
(cherry picked from commit 10db7573014008ff867098206f51012d501ab57b)
[Bug middle-end/64888] ubsan doesn't work with openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64888 --- Comment #13 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a76e866211798da138c51abea390bcd605b6da02 commit r9-10107-ga76e866211798da138c51abea390bcd605b6da02 Author: Jakub Jelinek Date: Thu Oct 21 10:27:44 2021 +0200 openmp: For default(none) ignore variables created by ubsan_create_data [PR64888] We weren't ignoring the ubsan variables created by c-ubsan.c before gimplification (others are added later). One way to fix this would be to introduce further UBSAN_ internal functions and lower it later (sanopt pass) like other ifns, this patch instead recognizes those magic vars by name/name of type and DECL_ARTIFICIAL and TYPE_ARTIFICIAL. 2021-10-21 Jakub Jelinek PR middle-end/64888 gcc/c-family/ * c-omp.c (c_omp_predefined_variable): Return true also for ubsan_create_data created artificial variables. gcc/testsuite/ * c-c++-common/ubsan/pr64888.c: New test. (cherry picked from commit 40dd9d839e52f679d8eabc1c5ca0ca17a5ccfd14)
[Bug c++/102786] [c++20] virtual pmf sometimes rejected as not a constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102786 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:662de049d63759b731bed62f9df60edb47120658 commit r9-10106-g662de049d63759b731bed62f9df60edb47120658 Author: Jakub Jelinek Date: Tue Oct 19 09:24:57 2021 +0200 c++: Don't reject calls through PMF during constant evaluation [PR102786] The following testcase incorrectly rejects the c initializer, while in the s.*a case cxx_eval_* sees .__pfn reads etc., in the s.*&S::foo case get_member_function_from_ptrfunc creates expressions which use INTEGER_CSTs with type of pointer to METHOD_TYPE. And cxx_eval_constant_expression rejects any INTEGER_CSTs with pointer type if they aren't 0. Either we'd need to make sure we defer such folding till cp_fold but the function and pfn_from_ptrmemfunc is used from lots of places, or the following patch just tries to reject only non-zero INTEGER_CSTs with pointer types if they don't point to METHOD_TYPE in the hope that all such INTEGER_CSTs with POINTER_TYPE to METHOD_TYPE are result of folding valid pointer-to-member function expressions. I don't immediately see how one could create such INTEGER_CSTs otherwise, cast of integers to PMF is rejected and would have the PMF RECORD_TYPE anyway, etc. 2021-10-19 Jakub Jelinek PR c++/102786 * constexpr.c (cxx_eval_constant_expression): Don't reject INTEGER_CSTs with type POINTER_TYPE to METHOD_TYPE. * g++.dg/cpp2a/constexpr-virtual19.C: New test. (cherry picked from commit f45610a45236e97616726ca042898d6ac46a082e)
[Bug c++/102548] [9/10 Regression] ICE with cdecl attribute on a builtin function since r7-4737-g48330c9355e32a41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102548 --- Comment #12 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ee221ea5cc02d628d0b967c007c52e7cac83c008 commit r9-10104-gee221ea5cc02d628d0b967c007c52e7cac83c008 Author: Jakub Jelinek Date: Tue Oct 5 22:28:38 2021 +0200 c++: Fix apply_identity_attributes [PR102548] The following testcase ICEs on x86_64-linux with -m32 due to a bug in apply_identity_attributes. The function is being smart and attempts not to duplicate the chain unnecessarily, if either there are no attributes that affect type identity or there is possibly empty set of attributes that do not affect type identity in the chain followed by attributes that do affect type identity, it reuses that attribute chain. The function mishandles the cases where in the chain an attribute affects type identity and is followed by one or more attributes that don't affect type identity (and then perhaps some further ones that do). There are two bugs. One is that when we notice first attribute that doesn't affect type identity after first attribute that does affect type identity (with perhaps some further such attributes in the chain after it), we want to put into the new chain just attributes starting from (inclusive) first_ident and up to (exclusive) the current attribute a, but the code puts into the chain all attributes starting with first_ident, including the ones that do not affect type identity and if e.g. we have doesn't0 affects1 doesn't2 affects3 affects4 sequence of attributes, the resulting sequence would have affects1 doesn't2 affects3 affects4 affects3 affects4 attributes, i.e. one attribute that shouldn't be there and two attributes duplicated. That is fixed by the a2 -> a2 != a change. The second one is that we ICE once we see second attribute that doesn't affect type identity after an attribute that affects it. That is because first_ident is set to error_mark_node after handling the first attribute that doesn't affect type identity (i.e. after we've copied the [first_ident, a) set of attributes to the new chain) to denote that from that time on, each attribute that affects type identity should be copied whenever it is seen (the if (as && as->affects_type_identity) code does that correctly). But that condition is false and first_ident is error_mark_node, we enter else if (first_ident) and use TREE_PURPOSE /TREE_VALUE/TREE_CHAIN on error_mark_node, which ICEs. When first_ident is error_mark_node and a doesn't affect type identity, we want to do nothing. So that is the && first_ident != error_mark_node chunk. 2021-10-05 Jakub Jelinek PR c++/102548 * tree.c (apply_identity_attributes): Fix handling of the case where an attribute in the list doesn't affect type identity but some attribute before it does. * g++.target/i386/pr102548.C: New test. (cherry picked from commit 737f95bab557584d876f02779ab79fe3cfaacacf)
[Bug sanitizer/102515] UBSAN misses signed division instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102515
--- Comment #12 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:f806bea0a6c1c5b7d517c7aee053c21b4d2155c6
commit r9-10103-gf806bea0a6c1c5b7d517c7aee053c21b4d2155c6
Author: Jakub Jelinek
Date: Fri Oct 1 14:27:32 2021 +0200
ubsan: Use -fno{,-}sanitize=float-divide-by-zero for float division by zero
recovery [PR102515]
We've been using
-f{,no-}sanitize-recover=integer-divide-by-zero to decide on the float
-fsanitize=float-divide-by-zero instrumentation _abort suffix.
This patch fixes it to use -f{,no-}sanitize-recover=float-divide-by-zero
for it instead.
2021-10-01 Jakub Jelinek
Richard Biener
PR sanitizer/102515
gcc/c-family/
* c-ubsan.c (ubsan_instrument_division): Check the right
flag_sanitize_recover bit, depending on which sanitization
is done.
gcc/testsuite/
* c-c++-common/ubsan/float-div-by-zero-2.c: New test.
(cherry picked from commit 9c1a633d96926357155d4702b66f8a0ec856a81f)
[Bug target/102498] [9/10 Regression] Long double constant and non-default rounding mode on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498 --- Comment #15 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8837138d292eb4221a5d5a985d25e487a127539d commit r9-10102-g8837138d292eb4221a5d5a985d25e487a127539d Author: Jakub Jelinek Date: Tue Sep 28 13:02:51 2021 +0200 i386: Don't emit fldpi etc. if -frounding-math [PR102498] i387 has instructions to store some transcedental numbers into the top of stack. The problem is that what exact bit in the last place one gets for those depends on the current rounding mode, the CPU knows the number with slightly higher precision. The compiler assumes rounding to nearest when comparing them against constants in the IL, but at runtime the rounding can be different and so some of these depending on rounding mode and the constant could be 1 ulp higher or smaller than expected. We only support changing the rounding mode at runtime if the non-default -frounding-mode option is used, so the following patch just disables using those constants if that flag is on. 2021-09-28 Jakub Jelinek PR target/102498 * config/i386/i386.c (standard_80387_constant_p): Don't recognize special 80387 instruction XFmode constants if flag_rounding_math. * gcc.target/i386/pr102498.c: New test. (cherry picked from commit 3b7041e8345c2f1030e58620f28e22d64b2c196b)
[Bug c++/102295] ELF symbol sizes for variable-length objects are too small (C++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102295 --- Comment #14 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:bd1562be917d088f8a34a27c4f91091382cbd4ab commit r9-10101-gbd1562be917d088f8a34a27c4f91091382cbd4ab Author: Jakub Jelinek Date: Wed Sep 15 22:21:17 2021 +0200 c++: Fix handling of decls with flexible array members initialized with side-effects [PR88578] > > Note, if the flexible array member is initialized only with non-constant > > initializers, we have a worse bug that this patch doesn't solve, the > > splitting of initializers into constant and dynamic initialization removes > > the initializer and we don't have just wrong DECL_*SIZE, but nothing is > > emitted when emitting those vars into assembly either and so the dynamic > > initialization clobbers other vars that may overlap the variable. > > I think we need keep an empty CONSTRUCTOR elt in DECL_INITIAL for the > > flexible array member in that case. > > Makes sense. So, the following patch fixes that. The typeck2.c change makes sure we keep those CONSTRUCTORs around (although they should be empty because all their elts had side-effects/was non-constant if it was removed earlier), and the varasm.c change is to avoid ICEs on those as well as ICEs on other flex array members that had some initializers without side-effects, but not on the last array element. The code was already asserting that the (index of the last elt in the CONSTRUCTOR + 1) times elt size is equal to TYPE_SIZE_UNIT of the local->val type, which is true for C flex arrays or for C++ if they don't have any side-effects or the last elt doesn't have side-effects, this patch changes that to assertion that the TYPE_SIZE_UNIT is greater than equal to the offset of the end of last element in the CONSTRUCTOR and uses TYPE_SIZE_UNIT (int_size_in_bytes) in the code later on. 2021-09-15 Jakub Jelinek PR c++/88578 PR c++/102295 gcc/ * varasm.c (output_constructor_regular_field): Instead of assertion that array_size_for_constructor result is equal to size of TREE_TYPE (local->val) in bytes, assert that the type size is greater or equal to array_size_for_constructor result and use type size as fieldsize. gcc/cp/ * typeck2.c (split_nonconstant_init_1): Don't throw away empty initializers of flexible array members if they have non-zero type size. gcc/testsuite/ * g++.dg/ext/flexary39.C: New test. * g++.dg/ext/flexary40.C: New test. (cherry picked from commit e5d1af8a07ae9fcc40ea5c781c3ad46d20ea12a6)
[Bug c++/88578] Static C++ objects with flexible array members overlap when initializes are non-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88578 --- Comment #10 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:bd1562be917d088f8a34a27c4f91091382cbd4ab commit r9-10101-gbd1562be917d088f8a34a27c4f91091382cbd4ab Author: Jakub Jelinek Date: Wed Sep 15 22:21:17 2021 +0200 c++: Fix handling of decls with flexible array members initialized with side-effects [PR88578] > > Note, if the flexible array member is initialized only with non-constant > > initializers, we have a worse bug that this patch doesn't solve, the > > splitting of initializers into constant and dynamic initialization removes > > the initializer and we don't have just wrong DECL_*SIZE, but nothing is > > emitted when emitting those vars into assembly either and so the dynamic > > initialization clobbers other vars that may overlap the variable. > > I think we need keep an empty CONSTRUCTOR elt in DECL_INITIAL for the > > flexible array member in that case. > > Makes sense. So, the following patch fixes that. The typeck2.c change makes sure we keep those CONSTRUCTORs around (although they should be empty because all their elts had side-effects/was non-constant if it was removed earlier), and the varasm.c change is to avoid ICEs on those as well as ICEs on other flex array members that had some initializers without side-effects, but not on the last array element. The code was already asserting that the (index of the last elt in the CONSTRUCTOR + 1) times elt size is equal to TYPE_SIZE_UNIT of the local->val type, which is true for C flex arrays or for C++ if they don't have any side-effects or the last elt doesn't have side-effects, this patch changes that to assertion that the TYPE_SIZE_UNIT is greater than equal to the offset of the end of last element in the CONSTRUCTOR and uses TYPE_SIZE_UNIT (int_size_in_bytes) in the code later on. 2021-09-15 Jakub Jelinek PR c++/88578 PR c++/102295 gcc/ * varasm.c (output_constructor_regular_field): Instead of assertion that array_size_for_constructor result is equal to size of TREE_TYPE (local->val) in bytes, assert that the type size is greater or equal to array_size_for_constructor result and use type size as fieldsize. gcc/cp/ * typeck2.c (split_nonconstant_init_1): Don't throw away empty initializers of flexible array members if they have non-zero type size. gcc/testsuite/ * g++.dg/ext/flexary39.C: New test. * g++.dg/ext/flexary40.C: New test. (cherry picked from commit e5d1af8a07ae9fcc40ea5c781c3ad46d20ea12a6)
[Bug c++/102295] ELF symbol sizes for variable-length objects are too small (C++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102295 --- Comment #13 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e13a79211a06c54e67245c664112c15f8bf3de7a commit r9-10100-ge13a79211a06c54e67245c664112c15f8bf3de7a Author: Jakub Jelinek Date: Tue Sep 14 16:56:30 2021 +0200 c++: Update DECL_*SIZE for objects with flexible array members with initializers [PR102295] The C FE updates DECL_*SIZE for vars which have initializers for flexible array members for many years, but C++ FE kept DECL_*SIZE the same as the type size (i.e. as if there were zero elements in the flexible array member). This results e.g. in ELF symbol sizes being too small. Note, if the flexible array member is initialized only with non-constant initializers, we have a worse bug that this patch doesn't solve, the splitting of initializers into constant and dynamic initialization removes the initializer and we don't have just wrong DECL_*SIZE, but nothing is emitted when emitting those vars into assembly either and so the dynamic initialization clobbers other vars that may overlap the variable. I think we need keep an empty CONSTRUCTOR elt in DECL_INITIAL for the flexible array member in that case. 2021-09-14 Jakub Jelinek PR c++/102295 * decl.c (layout_var_decl): For aggregates ending with a flexible array member, add the size of the initializer for that member to DECL_SIZE and DECL_SIZE_UNIT. * g++.target/i386/pr102295.C: New test. (cherry picked from commit 818c505188ff5cd8eb048eb0e614c4ef732225bd)
[Bug c++/102305] [9/10 regression] intrinsic __is_constructible is wrong for templated abstract classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102305 --- Comment #10 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:edb57ecb1bcdcfef4ebc0ee78976d5718fcb00b2 commit r9-10099-gedb57ecb1bcdcfef4ebc0ee78976d5718fcb00b2 Author: Jakub Jelinek Date: Tue Sep 14 16:55:04 2021 +0200 c++: Fix __is_*constructible/assignable for templates [PR102305] is_xible_helper returns error_mark_node (i.e. false from the traits) for abstract classes by testing ABSTRACT_CLASS_TYPE_P (to) early. Unfortunately, as the testcase shows, that doesn't work on class templates that haven't been instantiated yet, ABSTRACT_CLASS_TYPE_P for them is false until it is instantiated, which is done when the routine later constructs a dummy object with that type. The following patch fixes this by calling complete_type first, so that ABSTRACT_CLASS_TYPE_P test will work properly, while keeping the handling of arrays with unknown bounds, or incomplete types where it is done currently. 2021-09-14 Jakub Jelinek PR c++/102305 * method.c (is_xible_helper): Call complete_type on to. * g++.dg/cpp0x/pr102305.C: New test. (cherry picked from commit f008fd3a480e3718436156697ebe7eeb47841457)
[Bug target/102224] [9/10 regession] wrong code for `x * copysign(1.0, x)` since r9-5298-g33142cf9cf82aa1f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224 --- Comment #18 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:45579f290157b62a36752ed6df4fbcb7c742fb08 commit r9-10098-g45579f290157b62a36752ed6df4fbcb7c742fb08 Author: Jakub Jelinek Date: Wed Sep 8 11:25:31 2021 +0200 i386: Fix up @xorsign3_1 [PR102224] As the testcase shows, we miscompile @xorsign3_1 if both input operands are in the same register, because the splitter overwrites op1 before with op1 & mask before using op0. For dest = xorsign op0, op0 we can actually simplify it from dest = (op0 & mask) ^ op0 to dest = op0 & ~mask (aka abs). The expander change is an optimization improvement, if we at expansion time know it is xorsign op0, op0, we can emit abs right away and get better code through that. The @xorsign3_1 is a fix for the case where xorsign wouldn't be known to have same operands during expansion, but during RTL optimizations they would appear. We need to use earlyclobber, we require dest and op1 to be the same but op0 must be different because we overwrite op1 first. 2021-09-08 Jakub Jelinek PR target/102224 * config/i386/i386.md (xorsign3): If operands[1] is equal to operands[2], emit abs2 instead. (@xorsign3_1): Add early-clobber for output operand. * gcc.dg/pr102224.c: New test. * gcc.target/i386/avx-pr102224.c: New test. (cherry picked from commit a7b626d98a9a821ffb33466818d6aa86cac1d6fd)
[Bug debug/101905] [9/10 Regression] Missed debug information for global register variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101905 --- Comment #14 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6aa2e07b4134bceefe0b8be5cecfe9466181 commit r9-10097-g6aa2e07b4134bceefe0b8be5cecfe9466181 Author: Jakub Jelinek Date: Mon Aug 23 11:50:14 2021 +0200 dwarf2out: Emit DW_AT_location for global register vars during early dwarf [PR101905] The following patch emits DW_AT_location for global register variables already during early dwarf, since usually late_global_decl hook isn't even called for those, as nothing needs to be emitted for them. 2021-08-23 Jakub Jelinek PR debug/101905 * dwarf2out.c (gen_variable_die): Add DW_AT_location for global register variables already during early_dwarf if possible. * gcc.dg/guality/pr101905.c: New test. (cherry picked from commit b284053bb75661fc1bf13c275f3ba5364bb17608)
[Bug middle-end/101624] [9/10 Regression] ICE: tree check: expected tree that contains 'decl with RTL' structure, have 'const_decl' in maybe_optimize_ubsan_ptr_ifn, at sanopt.c:495
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101624 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cbf39efadbc9f07b639856f1ee367e3756f8df99 commit r9-10096-gcbf39efadbc9f07b639856f1ee367e3756f8df99 Author: Jakub Jelinek Date: Wed Jul 28 18:43:15 2021 +0200 ubsan: Fix ICEs with DECL_REGISTER tests [PR101624] The following testcase ICEs, because the base is a CONST_DECL for the Fortran parameter, and ubsan/sanopt uses DECL_REGISTER macro on it. /* In VAR_DECL and PARM_DECL nodes, nonzero means declared `register'. */ #define DECL_REGISTER(NODE) (DECL_WRTL_CHECK (NODE)->decl_common.decl_flag_0) while CONST_DECL doesn't satisfy DECL_WRTL_CHECK. The following patch checks explicitly for VAR_DECL/PARM_DECL/RESULT_DECL only before using DECL_REGISTER, assumes other decls aren't DECL_REGISTER. Not really sure about RESULT_DECL but it at least satisfies DECL_WRTL_CHECK... 2021-07-28 Jakub Jelinek PR middle-end/101624 * ubsan.c (maybe_instrument_pointer_overflow, instrument_object_size): Only test DECL_REGISTER on VAR_DECLs, PARM_DECLs or RESULT_DECLs. * sanopt.c (maybe_optimize_ubsan_ptr_ifn): Likewise. * gfortran.dg/ubsan/ubsan.exp: New file. * gfortran.dg/ubsan/pr101624.f90: New test. (cherry picked from commit 49e28c02a95a4bee981e69a80950309869580151)
[Bug rtl-optimization/101562] [9/10 Regression] ICE in insert, at wide-int.cc:682
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101562 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f7200dd27304455d4c96c008c4aac20f23aee5f2 commit r9-10095-gf7200dd27304455d4c96c008c4aac20f23aee5f2 Author: Jakub Jelinek Date: Fri Jul 23 19:55:16 2021 +0200 expmed: Fix store_integral_bit_field [PR101562] Our documentation says that paradoxical subregs shouldn't appear in strict_low_part: '(strict_low_part (subreg:M (reg:N R) 0))' This expression code is used in only one context: as the destination operand of a 'set' expression. In addition, the operand of this expression must be a non-paradoxical 'subreg' expression. but on the testcase below that triggers UB at runtime store_integral_bit_field emits exactly that. The following patch fixes it by ensuring the requirement is satisfied. 2021-07-23 Jakub Jelinek PR rtl-optimization/101562 * expmed.c (store_integral_bit_field): Only use movstrict_optab if the operand isn't paradoxical. * gcc.c-torture/compile/pr101562.c: New test. (cherry picked from commit 8408d34570c9fe9f3d22a25a76df2a4c64f08477)
[Bug middle-end/101535] ICE in lookup_decl, at omp-low.c:412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101535 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3155bb8e475fa4752cc635ed5481b5339283de55 commit r9-10094-g3155bb8e475fa4752cc635ed5481b5339283de55 Author: Jakub Jelinek Date: Wed Jul 21 09:45:02 2021 +0200 openmp: Fix up omp_check_private [PR101535] The target data construct shouldn't affect omp_check_private, unless the decl there is privatized (use_device_* clauses). The routine had some code for that, but it just did continue; in a loop that looped only if the region type is one of selected 4 kinds, so effectively resulted in return false; instead of looping again. And not diagnosing lastprivate (or reduction etc.) on a variable that is private to containing parallel results in ICEs later on, as there is no original list item to which store the last result. The target construct is unclear as it has an implicit parallel region and it is not obvious if the data privatization clauses on the construct shall be treated as data privatization on the implicit parallel or just on the target. For now treat those as privatization on the implicit parallel, but treat map clauses as shared on the implicit parallel. 2021-07-21 Jakub Jelinek PR middle-end/101535 * gimplify.c (omp_check_private): Properly skip ORT_TARGET_DATA contexts in which decl isn't privatized and for ORT_TARGET return false if decl is mapped. * c-c++-common/gomp/pr101535-1.c: New test. * c-c++-common/gomp/pr101535-2.c: New test. (cherry picked from commit b136b7a78774107943fe94051c42b5a968a3ad3f)
[Bug c++/101516] [9/10 Regression] ICE in finish_omp_reduction_clause, at cp/semantics.c:6075
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101516 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:36eef10e03247077cf3e4d2478d00eb0e8fc87d7 commit r9-10093-g36eef10e03247077cf3e4d2478d00eb0e8fc87d7 Author: Jakub Jelinek Date: Wed Jul 21 09:38:59 2021 +0200 c++: Ensure OpenMP reduction with reference type references complete type [PR101516] The following testcase ICEs because we haven't verified if reduction decl has reference type that TREE_TYPE of the reference is a complete type, require_complete_type on the decl doesn't ensure that. 2021-07-21 Jakub Jelinek PR c++/101516 * semantics.c (finish_omp_reduction_clause): Also call complete_type_or_else and return true if it fails. * g++.dg/gomp/pr101516.C: New test. (cherry picked from commit aea199f96cf116ba4c81426207acde371556610c)
[Bug target/101384] [9/10 Regression] wrong code at -Og and above with vector shift/multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101384
--- Comment #13 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:883690ff6bd8e4f16c871b307cebb13d6c14edcb
commit r9-10092-g883690ff6bd8e4f16c871b307cebb13d6c14edcb
Author: Jakub Jelinek
Date: Tue Jul 20 16:41:29 2021 +0200
rs6000: Fix up easy_vector_constant_msb handling [PR101384]
The following gcc.dg/pr101384.c testcase is miscompiled on
powerpc64le-linux.
easy_altivec_constant has code to try construct vector constants with
different element sizes, perhaps different from CONST_VECTOR's mode. But
as
written, that works fine for vspltis[bhw] cases, but not for the vspltisw
x,-1; vsl[bhw] x,x,x case, because that creates always a V16QImode,
V8HImode
or V4SImode constant containing broadcasted constant with just the MSB set.
The vspltis_constant function etc. expects the vspltis[bhw] instructions
where the small [-16..15] or even [-32..30] constant is sign-extended to
the
remaining step bytes, but that is not the case for the 0x80...00 constants,
with step 1 we can't handle e.g.
{ 0x80, 0xff, 0xff, 0xff, 0x80, 0xff, 0xff, 0xff, 0x80, 0xff, 0xff, 0xff,
0x80, 0xff, 0xff, 0xff }
vectors but do want to handle e.g.
{ 0, 0, 0, 0x80, 0, 0, 0, 0x80, 0, 0, 0, 0x80, 0, 0, 0, 0x80 }
and similarly with copies 1 we do want to handle e.g.
{ 0x80808080, 0x80808080, 0x80808080, 0x80808080 }.
This is a simpler version of the fix for backports, which limits the
EASY_VECTOR_MSB case
matching to step == 1 && copies == 1, because that is the only case the
splitter handles correctly.
2021-07-20 Jakub Jelinek
PR target/101384
* config/rs6000/rs6000.c (vspltis_constant): Accept EASY_VECTOR_MSB
only if step and copies are equal to 1.
* gcc.dg/pr101384.c: New test.
(cherry picked from commit dc386b020869ad0095cf58f8c76a40ea457e7a2c)
[Bug middle-end/94366] OpenMP Parallel Reduction with "&&" operator does not compute correct result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94366 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:26c58b164fd78db4ce25f0183ed0225c08018f3f commit r9-10091-g26c58b164fd78db4ce25f0183ed0225c08018f3f Author: Jakub Jelinek Date: Thu Jul 1 08:55:49 2021 +0200 openmp - Fix up && and || reductions [PR94366] As the testcase shows, the special treatment of && and || reduction combiners where we expand them as omp_out = (omp_out != 0) && (omp_in != 0) (or with ||) is not needed just for &&/|| on floating point or complex types, but for all &&/|| reductions - when expanded as omp_out = omp_out && omp_in (not in C but GENERIC) it is actually gimplified into NOP_EXPRs to bool from both operands, which turns non-zero values multiple of 2 into 0 rather than 1. This patch just treats all &&/|| the same and furthermore uses bool type instead of int for the comparisons. 2021-07-01 Jakub Jelinek PR middle-end/94366 gcc/ * omp-low.c (lower_rec_input_clauses): Rename is_fp_and_or to is_truth_op, set it for TRUTH_*IF_EXPR regardless of new_var's type, use boolean_type_node instead of integer_type_node as NE_EXPR type. (lower_reduction_clauses): Likewise. libgomp/ * testsuite/libgomp.c-c++-common/pr94366.c: New test. (cherry picked from commit 91c771ec8a3b649765de3e0a7b04cf946c6649ef)
[Bug c++/101443] [9/10 Regression] internal compiler error: in wide_int_to_tree_1, at tree.c:1519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101443
--- Comment #12 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:c910d7919529b490098319ab84c5c0132e8809f0
commit r9-10089-gc910d7919529b490098319ab84c5c0132e8809f0
Author: Jakub Jelinek
Date: Thu Jul 15 18:53:20 2021 +0200
c++: Optimize away NULLPTR_TYPE comparisons [PR101443]
Comparisons of NULLPTR_TYPE operands cause all kinds of problems in the
middle-end and in fold-const.c, various optimizations assume that if they
see e.g. a non-equality comparison with one of the operands being
INTEGER_CST and it is not INTEGRAL_TYPE_P (which has TYPE_{MIN,MAX}_VALUE),
they can build_int_cst (type, 1) to find a successor.
The following patch fixes it by making sure they don't appear in the IL,
optimize them away at cp_fold time as all can be folded.
Though, I've just noticed that clang++ rejects the non-equality comparisons
instead, foo () > 0 with
invalid operands to binary expression ('decltype(nullptr)' (aka
'nullptr_t') and 'int')
and foo () > nullptr with
invalid operands to binary expression ('decltype(nullptr)' (aka
'nullptr_t') and 'nullptr_t')
Shall we reject those too, in addition or instead of parts of this patch?
If so, wouldn't this patch be still useful for backports, I bet we don't
want to start reject it on the release branches when we used to accept it.
2021-07-15 Jakub Jelinek
PR c++/101443
* cp-gimplify.c (cp_fold): For comparisons with NULLPTR_TYPE
operands, fold them right away to true or false.
* g++.dg/cpp0x/nullptr46.C: New test.
(cherry picked from commit 7094a69bd62a14dfa311eaa2fea468f221c7c9f3)
[Bug go/101407] non-determinism in -fdump-go-spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101407 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:eb253e4148ba1a79789c623a062d43a126ec4c31 commit r9-10088-geb253e4148ba1a79789c623a062d43a126ec4c31 Author: Jakub Jelinek Date: Wed Jul 14 10:22:50 2021 +0200 godump: Fix -fdump-go-spec= reproduceability issue [PR101407] pot_dummy_types is a hash_set from whose traversal the code prints some type lines. hash_set normally uses default_hash_traits which for pointer types (the hash set hashes const char *) uses pointer_hash which hashes the addresses of the pointers except of the least significant 3 bits. With address space randomization, that results in non-determinism in the -fdump-go-specs= generated file, each invocation can have different order of the lines emitted from pot_dummy_types traversal. This patch fixes it by hashing the string contents instead to make the hashes reproduceable. 2021-07-14 Jakub Jelinek PR go/101407 * godump.c (godump_str_hash): New type. (godump_container::pot_dummy_types): Use string_hash instead of ptr_hash in the hash_set. (cherry picked from commit 3be762c2ed79e36b9c8faaea2be04725c967a34e)
[Bug debug/101266] ICE with -g: in loc_list_from_tree_1, at dwarf2out.c:19421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101266 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1df7b899cd854fdda052fb6218c2ff9e8898df42 commit r9-10086-g1df7b899cd854fdda052fb6218c2ff9e8898df42 Author: Jakub Jelinek Date: Thu Jul 1 09:45:02 2021 +0200 dwarf2out: Handle COMPOUND_LITERAL_EXPR in loc_list_from_tree_1 [PR101266] In this case dwarf2out_decl is called from the FEs with GENERIC but not yet gimplified expressions in it. As loc_list_from_tree_1 has an exhaustive list of tree codes it wants to handle and for checking asserts no other codes makes it in, we should handle even GENERIC trees that shouldn't be valid in GIMPLE. The following patch handles COMPOUND_LITERAL_EXPR by hnadling it like the underlying VAR_DECL temporary. Verified the emitted DWARF is correct (but unoptimized, we emit DW_OP_lit1 DW_OP_lit1 DW_OP_minus for the upper bound). 2021-07-01 Jakub Jelinek PR debug/101266 * dwarf2out.c (loc_list_from_tree_1): Handle COMPOUND_LITERAL_EXPR. * gcc.dg/pr101266.c: New test. (cherry picked from commit b0ab968999c9af88d45acf552ca673ef3960306a)
[Bug c++/101210] [9/10 regression] spurious "reference binding to misaligned address" ubsan error for integer comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101210 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:57aeb7f535b9c04ed34ab9479498143ee73fb568 commit r9-10085-g57aeb7f535b9c04ed34ab9479498143ee73fb568 Author: Jakub Jelinek Date: Tue Jun 29 11:24:38 2021 +0200 match.pd: Avoid (intptr_t)x eq/ne CST to x eq/ne (typeof x) CST opt in GENERIC when sanitizing [PR101210] When we have (intptr_t) x == cst where x has REFERENCE_TYPE, this optimization creates x == cst out of it where cst has REFERENCE_TYPE. If it is done in GENERIC folding, it can results in ubsan failures where the INTEGER_CST with REFERENCE_TYPE is instrumented. Fixed by deferring it to GIMPLE folding in this case. 2021-06-29 Jakub Jelinek PR c++/101210 * match.pd ((intptr_t)x eq/ne CST to x eq/ne (typeof x) CST): Don't perform the optimization in GENERIC when sanitizing and x has a reference type. * g++.dg/ubsan/pr101210.C: New test. (cherry picked from commit 53fd7544aff6d0a18869017cb9bb921a7f5dcd04)
[Bug c/101176] valgrind error for c-c++-common/builtin-has-attribute.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101176 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d8e3b3434dd68cea757bee2fedfc72e94ab0804c commit r9-10084-gd8e3b3434dd68cea757bee2fedfc72e94ab0804c Author: Jakub Jelinek Date: Thu Jun 24 15:58:02 2021 +0200 c: Fix up c_parser_has_attribute_expression [PR101176] This function keeps src_range member of the result uninitialized, which at least under valgrind can show up later when those uninitialized location_t's can make it into the IL or location_t hash tables. 2021-06-24 Jakub Jelinek PR c/101176 * c-parser.c (c_parser_has_attribute_expression): Set source range for the result. (cherry picked from commit 178fb8df9315f2f8f45b7fe5faf11a9c2912cc28)
[Bug c/101171] [10 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:3006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101171 --- Comment #12 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:be5f5f6ea368e2b8b9a0012ecbe2e83aeabdf714 commit r9-10083-gbe5f5f6ea368e2b8b9a0012ecbe2e83aeabdf714 Author: Jakub Jelinek Date: Thu Jun 24 15:55:28 2021 +0200 c: Fix C cast error-recovery [PR101171] The following testcase ICEs during error-recovery, as build_c_cast calls note_integer_operands on error_mark_node and that wraps it into C_MAYBE_CONST_EXPR which is unexpected and causes ICE later on. Seems most other callers of note_integer_operands check early if something is error_mark_node and return before calling note_integer_operands on it. The following patch fixes it by not calling on error_mark_node, another possibility would be to handle error_mark_node in note_integer_operands and just return it. 2021-06-24 Jakub Jelinek PR c/101171 * c-typeck.c (build_c_cast): Don't call note_integer_operands on error_mark_node. * gcc.dg/pr101171.c: New test. (cherry picked from commit fdc5522fb04b4a820b28c4d1f16f54897f5978de)
[Bug middle-end/101167] Miscompilation of task_reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101167 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7ce8cb98ef1b6a8de2918b963d22552dae9c commit r9-10082-g7ce8cb98ef1b6a8de2918b963d22552dae9c Author: Jakub Jelinek Date: Wed Jun 23 10:03:28 2021 +0200 openmp: Fix up *_reduction clause handling with UDRs on PARM_DECLs [PR101167] The following testcase FAILs, because the UDR combiner is invoked incorrectly. lower_omp_rec_clauses expects that when it sets DECL_VALUE_EXPR/DECL_HAS_VALUE_EXPR_P for both the placeholder and the var that everything will be properly regimplified, but as the variable in question is a PARM_DECL rather than VAR_DECL, lower_omp_regimplify_p doesn't say that it should be regimplified and so it is not. 2021-06-23 Jakub Jelinek PR middle-end/101167 * omp-low.c (lower_omp_regimplify_p): Regimplify also PARM_DECLs and RESULT_DECLs that have DECL_HAS_VALUE_EXPR_P set. * testsuite/libgomp.c-c++-common/task-reduction-15.c: New test. (cherry picked from commit 679506c3830ea1a93c755413609bfac3538e2cbd)
[Bug c/100785] [9/10 Regression] ICE: in expand_asm_stmt with "m" and bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100785
--- Comment #12 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:21a95d88fe628d1da4d59c4eface53503b29a574
commit r9-10081-g21a95d88fe628d1da4d59c4eface53503b29a574
Author: Jakub Jelinek
Date: Mon Jun 21 13:30:42 2021 +0200
inline-asm: Fix ICE with bitfields in "m" operands [PR100785]
Bitfields, while they live in memory, aren't something inline-asm can
easily
operate on.
For C and "=m" or "+m", we were diagnosing bitfields in the past in the
FE, where c_mark_addressable had:
case COMPONENT_REF:
if (DECL_C_BIT_FIELD (TREE_OPERAND (x, 1)))
{
error
("cannot take address of bit-field %qD", TREE_OPERAND (x,
1));
return false;
}
but that check got moved in GCC 6 to build_unary_op instead and now we
emit an error during expansion and ICE afterwards (i.e. error-recovery).
For "m" it used to be diagnosed in c_mark_addressable too, but since
GCC 6 it is ice-on-invalid.
For C++, this was never diagnosed in the FE, but used to be diagnosed
in the gimplifier and/or during expansion before 4.8.
The following patch does multiple things:
1) diagnoses it in the FEs
2) simplifies during expansion the inline asm if any errors have been
reported (similarly how e.g. vregs pass if it detects errors on
inline-asm either deletes them or simplifies to bare minimum -
just labels), so that we don't have error-recovery ICEs there
2021-06-11 Jakub Jelinek
PR inline-asm/100785
gcc/
* cfgexpand.c (expand_asm_stmt): If errors are emitted,
remove all inputs, outputs and clobbers from the asm and
set template to "".
gcc/c/
* c-typeck.c (c_mark_addressable): Diagnose trying to make
bit-fields addressable.
gcc/cp/
* typeck.c (cxx_mark_addressable): Diagnose trying to make
bit-fields addressable.
gcc/testsuite/
* c-c++-common/pr100785.c: New test.
(cherry picked from commit 644c2cc5f2c09506a7bfef293a7f90efa8d7e5fa)
[Bug middle-end/101062] [10 Regression] wrong code with "-O2 -fno-toplevel-reorder -frename-registers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101062 --- Comment #23 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:80f194b25f573b409ada5761778fb6dfb3cf85e9 commit r9-10080-g80f194b25f573b409ada5761778fb6dfb3cf85e9 Author: Jakub Jelinek Date: Fri Jun 18 11:20:40 2021 +0200 stor-layout: Don't create DECL_BIT_FIELD_REPRESENTATIVE for QUAL_UNION_TYPE [PR101062] > The following patch does create them, but treats all such bitfields as if > they were in a structure where the particular bitfield is the only field. While the patch passed bootstrap/regtest on the trunk, when trying to backport it to 11 branch the bootstrap failed with atree.ads:3844:34: size for "Node_Record" too small errors. Turns out the error is not about size being too small, but actually about size being non-constant, and comes from: /* In a FIELD_DECL of a RECORD_TYPE, this is a pointer to the storage representative FIELD_DECL. */ #define DECL_BIT_FIELD_REPRESENTATIVE(NODE) \ (FIELD_DECL_CHECK (NODE)->field_decl.qualifier) /* For a FIELD_DECL in a QUAL_UNION_TYPE, records the expression, which if nonzero, indicates that the field occupies the type. */ #define DECL_QUALIFIER(NODE) (FIELD_DECL_CHECK (NODE)->field_decl.qualifier) so by setting up DECL_BIT_FIELD_REPRESENTATIVE in QUAL_UNION_TYPE we actually set or modify DECL_QUALIFIER and then construct size as COND_EXPRs with those bit field representatives (e.g. with array type) as conditions which doesn't fold into constant. The following patch fixes it by not creating DECL_BIT_FIELD_REPRESENTATIVEs for QUAL_UNION_TYPE as there is nowhere to store them, Shall we change tree.h to document that DECL_BIT_FIELD_REPRESENTATIVE is valid also on UNION_TYPE? I see: tree-ssa-alias.c- if (TREE_CODE (type1) == RECORD_TYPE tree-ssa-alias.c: && DECL_BIT_FIELD_REPRESENTATIVE (field1)) tree-ssa-alias.c:field1 = DECL_BIT_FIELD_REPRESENTATIVE (field1); tree-ssa-alias.c- if (TREE_CODE (type2) == RECORD_TYPE tree-ssa-alias.c: && DECL_BIT_FIELD_REPRESENTATIVE (field2)) tree-ssa-alias.c:field2 = DECL_BIT_FIELD_REPRESENTATIVE (field2); Shall we change that to || == UNION_TYPE or do we assume all fields are overlapping in a UNION_TYPE already? At other spots (asan, ubsan, expr.c) it is unclear what will happen if they see a QUAL_UNION_TYPE with a DECL_QUALIFIER (or does the Ada FE lower that somehow)? 2021-06-18 Jakub Jelinek PR middle-end/101062 * stor-layout.c (finish_bitfield_layout): Don't add bitfield representatives in QUAL_UNION_TYPE. (cherry picked from commit 3587c2c241eda0f3ab54ea60d46e9caf12d69b5a)
[Bug middle-end/101062] [10 Regression] wrong code with "-O2 -fno-toplevel-reorder -frename-registers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101062 --- Comment #22 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d0b1d8d3b85bb4466fae20e72a8fa35dd7277229 commit r9-10079-gd0b1d8d3b85bb4466fae20e72a8fa35dd7277229 Author: Jakub Jelinek Date: Wed Jun 16 12:17:55 2021 +0200 stor-layout: Create DECL_BIT_FIELD_REPRESENTATIVE even for bitfields in unions [PR101062] The following testcase is miscompiled on x86_64-linux, the bitfield store is implemented as a RMW 64-bit operation at d+24 when the d variable has size of only 28 bytes and scheduling moves in between the R and W part a store to a different variable that happens to be right after the d variable. The reason for this is that we weren't creating DECL_BIT_FIELD_REPRESENTATIVEs for bitfields in unions. The following patch does create them, but treats all such bitfields as if they were in a structure where the particular bitfield is the only field. 2021-06-16 Jakub Jelinek PR middle-end/101062 * stor-layout.c (finish_bitfield_representative): For fields in unions assume nextf is always NULL. (finish_bitfield_layout): Compute bit field representatives also in unions, but handle it as if each bitfield was the only field in the aggregate. * gcc.dg/pr101062.c: New test. (cherry picked from commit b4b50bf2864e09f028a39a3f460222632c4d7348)
[Bug target/101046] ICE: in gen_rtx_CONST_VECTOR, at emit-rtl.c:6031 with -mavx512vbmi -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101046 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2f682080c136412897b5d350abb337e694ad51de commit r9-10076-g2f682080c136412897b5d350abb337e694ad51de Author: Jakub Jelinek Date: Tue Jun 15 11:36:47 2021 +0200 expr: Fix up VEC_PACK_TRUNC_EXPR expansion [PR101046] The following testcase ICEs, because we have a mode mismatch. VEC_PACK_TRUNC_EXPR's operands have different modes from the result (same vector mode size but twice as large element), but we were passing non-NULL subtarget with the mode of the result to the expansion of its arguments, so the VEC_PERM_EXPR in one of the operands which had V8SImode operands and result had V16HImode target. Fixed by clearing the subtarget if we are changing mode. 2021-06-15 Jakub Jelinek PR target/101046 * expr.c (expand_expr_real_2) : Clear subtarget when changing mode. (cherry picked from commit 008153c8435ca3bf587e11654c31f05c0f99b43a)
[Bug middle-end/100898] [9/10 Regression] ICE with -O2: in gimple_call_arg_ptr, at gimple.h:3264
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100898 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:97785bcbc66b11f41030a459f7b170f1e2ed5e50 commit r9-10075-g97785bcbc66b11f41030a459f7b170f1e2ed5e50 Author: Jakub Jelinek Date: Mon Jun 7 09:25:37 2021 +0200 tree-inline: Fix up __builtin_va_arg_pack handling [PR100898] The following testcase ICEs, because gimple_call_arg_ptr (..., 0) asserts that there is at least one argument, while we were using it even if we didn't copy anything just to get a pointer from/to which the zero arguments should be copied. Fixed by guarding the memcpy calls. Also, the code was calling gimple_call_num_args too many times - 5 times instead of 2, so the patch adds two temporaries for those. 2021-06-07 Jakub Jelinek PR middle-end/100898 * tree-inline.c (copy_bb): Only use gimple_call_arg_ptr if memcpy should copy any arguments. Don't call gimple_call_num_args on id->call_stmt or call_stmt more than once. * g++.dg/ext/va-arg-pack-3.C: New test. (cherry picked from commit d66a703c8ba86f3ca04cc10c3071696e6d014de6)
[Bug target/100887] [12 Regression] ICE: in ix86_expand_vector_init_concat, at config/i386/i386-expand.c:14178 with -mavx512f and __builtin_shufflevector()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100887 --- Comment #16 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e7e1ad94007d79b5bae948a03b6c6b57243708bc commit r9-10074-ge7e1ad94007d79b5bae948a03b6c6b57243708bc Author: Jakub Jelinek Date: Fri Jun 4 11:20:02 2021 +0200 x86: Fix ix86_expand_vector_init for V*TImode [PR100887] We have vec_initv4tiv2ti and vec_initv2titi patterns which call ix86_expand_vector_init and assume it works for those modes. For the case of construction from two half-sized vectors, the code assumes it will always succeed, but we have only insn patterns with SImode and DImode element types. QImode and HImode element types are already handled by performing it with same sized vectors with SImode elements and the following patch extends that to V*TImode vectors. 2021-06-04 Jakub Jelinek PR target/100887 * config/i386/i386.c (ix86_expand_vector_init): Handle concatenation from half-sized modes with TImode elements. (cherry picked from commit b7dd2e4eeb44bc8678ecde8a6c7401de85e63561)
[Bug c++/100666] [9/10 Regression] warning: ignoring return value of 'constexpr _Tp&& std::forward(typename std::remove_reference<_Tp>::type&) [with _Tp = std::nullptr_t; ...]', declared with attribut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100666 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6a05023c8739f2848778074e1ea9311cf6825a0f commit r9-10073-g6a05023c8739f2848778074e1ea9311cf6825a0f Author: Jakub Jelinek Date: Tue May 25 17:24:38 2021 +0200 c++: Avoid -Wunused-value false positives on nullptr passed to ellipsis [PR100666] When passing expressions with decltype(nullptr) type with side-effects to ellipsis, we pass (void *)0 instead, but for the side-effects evaluate them on the lhs of a COMPOUND_EXPR. Unfortunately that means we warn about it if the expression is a call to nodiscard marked function, even when the result is really used, just needs to be transformed. Fixed by adding a warning_sentinel. 2021-05-25 Jakub Jelinek PR c++/100666 * call.c (convert_arg_to_ellipsis): For expressions with NULLPTR_TYPE and side-effects, temporarily disable -Wunused-result warning when building COMPOUND_EXPR. * g++.dg/cpp1z/nodiscard8.C: New test. * g++.dg/cpp1z/nodiscard9.C: New test. (cherry picked from commit ad52d89808a947264397e920d7483090d4108f7b)
[Bug c++/2021] Internal error #378.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2021 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8552cfa658dcfbd3ed85db356f0782ba69041d14 commit r9-10072-g8552cfa658dcfbd3ed85db356f0782ba69041d14 Author: Jakub Jelinek Date: Fri May 14 13:24:12 2021 +0200 testsuite: Add testcase for already fixed PR 2021-05-14 Jakub Jelinek * g++.dg/cpp1y/pr88872.C: New test. (cherry picked from commit f05627d404038368b99e92ac4df4c29f4ae4a5fa)
[Bug middle-end/100508] ICE with '-g -O3': in expand_debug_locations, at cfgexpand.c:5618
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100508 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ba374dfb937a8ac1c7c4740913331951a924f88b commit r9-10071-gba374dfb937a8ac1c7c4740913331951a924f88b Author: Jakub Jelinek Date: Wed May 12 10:38:35 2021 +0200 expand: Don't reuse DEBUG_EXPRs with vector type if they have different modes [PR100508] The inliner doesn't remap DEBUG_EXPR_DECLs, so the same decls can appear in multiple functions. Furthermore, expansion reuses corresponding DEBUG_EXPRs too, so they again can be reused in multiple functions. Neither of that is a major problem, DEBUG_EXPRs are just magic value holders and what value they stand for is independent in each function and driven by what debug stmts or DEBUG_INSNs they are bound to. Except for DEBUG_EXPR*s with vector types, TYPE_MODE can be either BLKmode or some vector mode depending on whether current function's enabled ISAs support that vector mode or not. On the following testcase, we expand it first in foo function without AVX2 enabled and so the DEBUG_EXPR is BLKmode, but later the same DEBUG_EXPR_DECL is used in a simd clone with AVX2 enabled and expansion ICEs because of a mode mismatch. The following patch fixes that by forcing recreation of a DEBUG_EXPR if there is a mode mismatch for vector typed DEBUG_EXPR_DECL, DEBUG_EXPRs will be still reused in between functions otherwise and within the same function the mode should be always the same. 2021-05-12 Jakub Jelinek PR middle-end/100508 * cfgexpand.c (expand_debug_expr): For DEBUG_EXPR_DECL with vector type, don't reuse DECL_RTL if it has different mode, instead force creation of a new DEBUG_EXPR. * gcc.dg/gomp/pr100508.c: New test. (cherry picked from commit 19040050aa2c8ee890fc58dda48639fc91bf0af0)
[Bug middle-end/100471] #pragma omp taskloop with custom reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100471 --- Comment #10 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c0844e105880b98e943812770088f51fc37211e6 commit r9-10070-gc0844e105880b98e943812770088f51fc37211e6 Author: Jakub Jelinek Date: Tue May 11 09:07:47 2021 +0200 openmp: Fix up taskloop reduction ICE if taskloop has no iterations [PR100471] When a taskloop doesn't have any iterations, GOMP_taskloop* takes an early return, doesn't create any tasks and more importantly, doesn't create a taskgroup and doesn't register task reductions. But, the code emitted in the callers assumes task reductions have been registered and performs the reduction handling and task reduction unregistration. The pointer to the task reduction private variables is reused, on input it is the alignment and only on output it is the pointer, so in the case taskloop with no iterations the caller attempts to dereference the alignment value as if it was a pointer and crashes. We could in the early returns register the task reductions only to have them looped over and unregistered in the caller, but I think it is better to tell the caller there is nothing to task reduce and bypass all that. 2021-05-11 Jakub Jelinek PR middle-end/100471 * omp-low.c (lower_omp_task_reductions): For OMP_TASKLOOP, if data is 0, bypass the reduction loop including GOMP_taskgroup_reduction_unregister call. * taskloop.c (GOMP_taskloop): If GOMP_TASK_FLAG_REDUCTION and not GOMP_TASK_FLAG_NOGROUP, when doing early return clear the task reduction pointer. * testsuite/libgomp.c/task-reduction-4.c: New test. (cherry picked from commit 98acbb3111fcb5e57d5e63d46c0d92f4e53e3c2a)
[Bug c/105557] New: -Wtautological-compare doesn't warn about bitwise expressions that always evaluate to true or false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105557
Bug ID: 105557
Summary: -Wtautological-compare doesn't warn about bitwise
expressions that always evaluate to true or false
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: garsilva at embeddedor dot com
Target Milestone: ---
Clang[1] emits warnings on the following code, which contains bitwise
expressions that always evaluate to true:
#include
enum Flags {
FLAG_A = 0b001,
FLAG_B = 0b010,
FLAG_C = 0b100,
};
void a();
void b();
void c();
void f(enum Flags f) {
if (!!(f | FLAG_A)) {
a();
} else if (!!(f | FLAG_B)) {
b();
} else if (!!(f | FLAG_C)) {
c();
} else {
abort();
}
}
and it seems that GCC is not able to detect the above tautological expressions.
[1] https://godbolt.org/z/ax6vhczP1
[Bug fortran/105542] [F03] Orthogonal standard-conforming type finalization tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105542 --- Comment #3 from Jerry DeLisle --- This is probably not the right place, but all gfortranners, try fpm if you have not already done so. It makes building and running the tests in this example so easy. Not to mention your own applications.
[Bug fortran/105542] [F03] Orthogonal standard-conforming type finalization tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105542 --- Comment #2 from Damian Rouson --- Thanks for trying this, Jerry. Brad encountered a similar issue, which I think he resolved so I'll I'll ask him to comment here.
[Bug fortran/105542] [F03] Orthogonal standard-conforming type finalization tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105542 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- Yes, it is always usefule to have tests available. I cloned the repository. fpm build is happy. $ fpm test compiler_test.f90 done. usage_test.f90 done. main.f90 done. reference-counter-test done. [100%] Project compiled successfully. Running Tests Test that The compiler finalizes a non-allocatable object on the LHS of an intrinsic assignment finalizes an allocated allocatable LHS of an intrinsic assignment finalizes a target when the associated pointer is deallocated finalizes an object upon explicit deallocation finalizes a non-pointer non-allocatable array object at the END statement finalizes a non-pointer non-allocatable object at the end of a block construct finalizes a function reference on the RHS of an intrinsic assignment finalizes a specification expression function result finalizes an intent(out) derived type dummy argument finalizes an allocatable component object Using a reference-counted object creates a resource when constructed removes the resource when it goes out of scope a copy points to the same resource A total of 13 test cases At line 42 of file test/usage_test.f90 Fortran runtime error: Attempt to DEALLOCATE unallocated 'the_resource' Execution failed for object " reference-counter-test " *cmd_run*:stopping due to failed executions STOP 1 Am I missing a step? This is with gfortran 12.
[Bug tree-optimization/105414] constant folding for fmin/max(snan, snan) is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105414 --- Comment #11 from CVS Commits --- The master branch has been updated by HaoChen Gui : https://gcc.gnu.org/g:344e425340e3c8e4539b43bf8f661e02c5a5b9a0 commit r13-280-g344e425340e3c8e4539b43bf8f661e02c5a5b9a0 Author: Haochen Gui Date: Mon May 9 17:34:23 2022 +0800 This patch skips constant folding for fmin/max when either argument is sNaN. According to C standard, fmin(sNaN, sNaNï¼= qNaN, fmin(sNaN, NaN) = qNaN. gcc/ PR target/105414 * match.pd (minmax): Skip constant folding for fmin/fmax when both arguments are sNaN or one is sNaN and another is NaN. gcc/testsuite/ PR target/105414 * gcc.dg/pr105414.c: New.
[Bug c++/105541] [12/13 Regression] ICE: Segmentation fault when template lambda in requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105541
--- Comment #4 from Jason Merrill ---
Simpler:
static_assert(requires { []{}; });
[Bug c++/105541] [12/13 Regression] ICE: Segmentation fault when template lambda in requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105541 Jason Merrill changed: What|Removed |Added Keywords|rejects-valid |ice-on-valid-code Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org Priority|P3 |P1 Status|NEW |ASSIGNED --- Comment #3 from Jason Merrill --- P1 then. Broken by my r12-7997-g1de6612d994ada.
[Bug middle-end/105539] -ftrivial-auto-var-init=zero happening too late?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539 --- Comment #7 from Kees Cook --- Right, perhaps I should rename this bug? The much more surprising thing is the lack of warning about the uninit use. With or without -ftrivial-auto-var-init, I'd want to have the diagnostic that a UB may have happened.
[Bug target/105546] [11/12/13 Regression] ifconversion introduces many compares with loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105546 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Target||x86_64-linux-gnu Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2022-05-10 Target Milestone|--- |11.4 Summary|load introduction when |[11/12/13 Regression] |initializing a struct |ifconversion introduces ||many compares with loads Component|middle-end |target --- Comment #2 from Andrew Pinski --- This is ifconversion changing: if (g_344.0_1 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 536870912]: [local count: 1073741824]: # _16 = PHI <4499926296329723445(2), -6(3)> # _18 = PHI <3(2), 3409572933270154779(3)> # _20 = PHI <171(2), 161(3)> # _22 = PHI <-1(2), -8(3)> # _24 = PHI <27943(2), 1(3)> # _26 = PHI <2738(2), 65526(3)> Into straight line code but keeps the load around. THis is a target issue.
[Bug target/105556] RA assigns an MMA vector input operand to vs0-vs31 causing an MMA accumulator to be spilled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105556 Peter Bergner changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2022-May/594 ||481.html --- Comment #2 from Peter Bergner --- Patch submitted.
[Bug target/105556] RA assigns an MMA vector input operand to vs0-vs31 causing an MMA accumulator to be spilled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105556 Peter Bergner changed: What|Removed |Added Last reconfirmed||2022-05-10 Ever confirmed|0 |1 Known to fail||12.0, 13.0 Known to work||10.0, 11.0 CC||dje at gcc dot gnu.org, ||segher at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org Target||powerpc*-*-* --- Comment #1 from Peter Bergner --- Mine. I have a patch.
[Bug target/105556] New: RA assigns an MMA vector input operand to vs0-vs31 causing an MMA accumulator to be spilled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105556 Bug ID: 105556 Summary: RA assigns an MMA vector input operand to vs0-vs31 causing an MMA accumulator to be spilled Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bergner at gcc dot gnu.org Target Milestone: --- With current trunk and GCC 12, the MMA optimized dgemm kernel in OpenBLAS is seeing a performance regression compared to GCC 11 and GCC 10. The problem is that the core loop in dgemm uses 8 accumulator variables, which want to use all 8 accumulator registers. Using the 8 accumulators means we should not use the vs0 thru vs31 vector registers for the MMA instruction's normal vector input operands. However with trunk and GCC 12, the register allocator is assigning one vector input to one of the vs0-vs31 registers leading us to spill one of the accumulators and that causes a bad performance loss. The trunk and GCC 12 asm for the core loop looks like: .L5: lxvp 0,0(10) lxv 40,0(9) addi 10,10,64 addi 9,9,64 lxv 41,-48(9) lxv 42,-32(9) lxv 43,-16(9) lxvp 2,32(1) lxvp 32,-32(10) xvf64gerpp 4,0,40 xvf64gerpp 6,0,41 xvf64gerpp 3,0,42 xvf64gerpp 2,0,43 lxvp 0,64(1) xvf64gerpp 5,32,40 xvf64gerpp 7,32,41 xvf64gerpp 1,32,42 xxmtacc 0 xvf64gerpp 0,32,43 xxmfacc 0 stxvp 2,32(1) stxvp 0,64(1) bdnz .L5 Note the use of vs0 in the MMA instructions which forces the spilling of ACC0. The "better" GCC 11 and GCC 10 code looks like: .L5: lxvp 44,0(10) lxvp 32,32(10) addi 9,9,64 addi 10,10,64 lxv 39,-64(9) lxv 40,-48(9) lxv 41,-32(9) lxv 42,-16(9) xvf64gerpp 4,44,39 xvf64gerpp 5,32,39 xvf64gerpp 6,44,40 xvf64gerpp 7,32,40 xvf64gerpp 3,44,41 xvf64gerpp 1,32,41 xvf64gerpp 2,44,42 xvf64gerpp 0,32,42 bdnz .L5
[Bug target/105472] [13 regression] .note.GNU-stack breaks many Solaris/x86 tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105472 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #8 from H.J. Lu --- Fixed.
[Bug c/105555] New: ICE: in fold_offsetof, at c-family/c-common.cc:6815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
Bug ID: 10
Summary: ICE: in fold_offsetof, at c-family/c-common.cc:6815
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhenyang.xu at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.lx931ugYgb-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220510 (experimental) [master -gbb2921ab8] (GCC)
$ cat mutant_93391780_1648415763714.c
a() {
&__imag *(_Complex *)a
$ gcc-trunk -O3 -g -Wall -Wextra -c mutant_93391780_1648415763714.c
mutant_93391780_1648415763714.c:1:1: warning: return type defaults to ‘int’
[-Wimplicit-int]
1 | a() {
| ^
mutant_93391780_1648415763714.c: In function ‘a’:
mutant_93391780_1648415763714.c:2:3: internal compiler error: in fold_offsetof,
at c-family/c-common.cc:6815
2 | &__imag *(_Complex *)a
| ^
0x6dc39a fold_offsetof(tree_node*, tree_node*, tree_code)
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c-family/c-common.cc:6815
0x9c345e build_unary_op(unsigned int, tree_code, tree_node*, bool)
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-typeck.cc:4915
0x9d09fe parser_build_unary_op(unsigned int, tree_code, c_expr)
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-typeck.cc:3771
0x9ec947 c_parser_unary_expression
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:8170
0x9edd6f c_parser_cast_expression
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:8103
0x9ee01f c_parser_binary_expression
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:7906
0x9ef51e c_parser_conditional_expression
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:7606
0x9efdc0 c_parser_expr_no_commas
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:7521
0x9f0051 c_parser_expression
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:10697
0x9f0827 c_parser_expression_conv
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:10736
0xa05ff7 c_parser_statement_after_labels
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:6263
0xa08374 c_parser_compound_statement_nostart
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:5800
0xa08a64 c_parser_compound_statement
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:5609
0xa0a443 c_parser_declaration_or_fndef
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:2544
0xa133e3 c_parser_external_declaration
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:1779
0xa13e4b c_parser_translation_unit
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:1652
0xa13e4b c_parse_file()
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:23357
0xa77029 c_common_parse_file()
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c-family/c-opts.cc:1235
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c/105554] New: ICE: in emit_block_move_hints, at expr.cc:1829
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554
Bug ID: 105554
Summary: ICE: in emit_block_move_hints, at expr.cc:1829
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhenyang.xu at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.lx931ugYgb-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220510 (experimental) [master -gbb2921ab8] (GCC)
$ cat mutant_133870291_1648466141340.c
__attribute__((target_clones("arch=core-avx2", "default")))
a(__attribute__((__vector_size__(4 * sizeof(long long) {}
$ gcc-trunk -O3 -g -Wall -Wextra -c mutant_133870291_1648466141340.c
mutant_133870291_1648466141340.c:2:1: warning: return type defaults to ‘int’
[-Wimplicit-int]
2 | a(__attribute__((__vector_size__(4 * sizeof(long long) {}
| ^
mutant_133870291_1648466141340.c: In function ‘a’:
mutant_133870291_1648466141340.c:2:1: note: the ABI for passing parameters with
32-byte alignment has changed in GCC 4.6
mutant_133870291_1648466141340.c:2:61: warning: control reaches end of non-void
function [-Wreturn-type]
2 | a(__attribute__((__vector_size__(4 * sizeof(long long) {}
| ^
mutant_133870291_1648466141340.c:2:1: warning: AVX vector argument without AVX
enabled changes the ABI [-Wpsabi]
2 | a(__attribute__((__vector_size__(4 * sizeof(long long) {}
| ^
during RTL pass: expand
mutant_133870291_1648466141340.c:2:1: internal compiler error: in
emit_block_move_hints, at expr.cc:1829
0x726cd5 emit_block_move_hints(rtx_def*, rtx_def*, rtx_def*, block_op_methods,
unsigned int, long, unsigned long, unsigned long, unsigned long, bool, bool*,
bool)
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/expr.cc:1829
0xc29395 emit_block_move(rtx_def*, rtx_def*, rtx_def*, block_op_methods)
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/expr.cc:1915
0xc8dc82 assign_parm_setup_block
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/function.cc:3124
0xc8dc82 assign_parms
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/function.cc:3705
0xc8f602 expand_function_start(tree_node*)
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/function.cc:5161
0xafda98 execute
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/cfgexpand.cc:6691
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug libstdc++/105284] missing syncstream and spanstream forward decl. in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105284 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|12.2|11.4 Resolution|--- |FIXED --- Comment #8 from Jonathan Wakely --- Fixed for 11.4 and 12.2, thanks for the report.
[Bug libstdc++/105284] missing syncstream and spanstream forward decl. in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105284 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1572e41d759950e7699d14779aae49b892f12f8b commit r11-9977-g1572e41d759950e7699d14779aae49b892f12f8b Author: Jonathan Wakely Date: Tue May 10 13:03:14 2022 +0100 libstdc++: Add declarations to [PR105284] libstdc++-v3/ChangeLog: PR libstdc++/105284 * include/std/iosfwd: Add declarations for class templates and typedefs. * include/std/syncstream (basic_syncbuf, basic_osyncstream): Remove default template arguments. * testsuite/27_io/headers/iosfwd/synopsis.cc: New test. * testsuite/27_io/headers/iosfwd/types.cc: New test. (cherry picked from commit 1807e07825a86916bbfddca470708c5a8f613612)
[Bug fortran/105230] [9/10/11/12/13 Regression] ICE in find_array_section, at fortran/expr.cc:1634
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105230
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> Started with 22015e77d3e4.
No, it didn't start with that commit. That commit missed the present
situation.
The ICE is pre-existing.
> upper is NULL and later in 1634 it is dereferenced. This patch fixes
> the problem, but the above logic likely needs fixing.
That's right. Shorter fix:
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 86d61fed302..be94c18c836 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -1595,8 +1595,8 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
if ((begin && begin->expr_type != EXPR_CONSTANT)
|| (finish && finish->expr_type != EXPR_CONSTANT)
|| (step && step->expr_type != EXPR_CONSTANT)
- || (!begin && !lower)
- || (!finish && !upper))
+ || !lower
+ || !upper)
{
t = false;
goto cleanup;
[Bug c++/105553] New: Deduction when attempting to create an array with an element type that is an abstract class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105553
Bug ID: 105553
Summary: Deduction when attempting to create an array with an
element type that is an abstract class
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glenjofe at gmail dot com
Target Milestone: ---
Starting with GCC11, the following definition of a trait to check if a type is
abstract no longer works in any standard mode:
template
class is_abstract {
template
static char (&check(U(*)[1]))[2];
template
static char check(...);
public:
static const bool value = sizeof(check(0)) == sizeof(char);
};
struct abstract {
virtual void function() = 0;
};
static_assert(is_abstract::value, "ok");
The static assertion trigger on GCC11 and above, even in older standard modes.
It compiles fine on GCC10 and below.
Various libraries in Boost use the above definition of is_abstract especially
in C++03. The basis was the following wording in [temp.deduct] until C++17:
"Type deduction may fail for the following reasons:
- Attempting to create an array with an element type that is void, a function
type, a reference type, or an abstract class type, or attempting to create an
array with a size that is zero or negative."
The "or an abstract class type" was absent in C++03, added by CWG337.
