[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:88ff2eb5cc2c1af2ae751c02997d0b5667662782 commit r11-9594-g88ff2eb5cc2c1af2ae751c02997d0b5667662782 Author: Jakub Jelinek Date: Fri Jan 28 11:48:18 2022 +0100 cfgrtl: Fix up locus comparison in unique_locus_on_edge_between_p [PR104237] The testcase in the PR (not included for the testsuite because we don't have an (easy) way to -fcompare-debug LTO, we'd need 2 compilations/linking, one with -g and one with -g0 and -fdump-rtl-final= at the end of lto1 and compare that) has different code generation for -g vs. -g0. The difference appears during expansion, where we have a goto_locus that is at -O0 compared to the INSN_LOCATION of the previous and next insn across an edge. With -g0 the locations are equal and so no nop is added. With -g the locations aren't equal and so a nop is added holding that location. The reason for the different location is in the way how we stream in locations by lto1. We have lto_location_cache::apply_location_cache that is called with some set of expanded locations, qsorts them, creates location_t's for those and remembers the last expanded location. lto_location_cache::input_location_and_block when read in expanded_location is equal to the last expanded location just reuses the last location_t (or adds/changes/removes LOCATION_BLOCK in it), when it is not queues it for next apply_location_cache. Now, when streaming in -g input, we can see extra locations that don't appear with -g0, and if we are unlucky enough, those can be sorted last during apply_location_cache and affect what locations are used from the single entry cache next. In particular, second apply_location_cache with non-empty loc_cache in the testcase has 14 locations with -g0 and 16 with -g and those 2 extra ones sort both last (they are the same). The last one from -g0 then appears to be input_location_and_block sourced again, for -g0 triggers the single entry cache, while for -g it doesn't and so apply_location_cache will create for it another location_t with the same content. The following patch fixes it by comparing everything we care about the location instead (well, better in addition) to a simple location_t == location_t check. I think we don't care about the sysp flag for debug info... 2022-01-28 Jakub Jelinek PR lto/104237 * cfgrtl.c (loc_equal): New function. (unique_locus_on_edge_between_p): Use it. (cherry picked from commit 430dca620fa3d03e53f6771a2b61d3f0ebb73756)
[Bug tree-optimization/104263] [10/11 Regression] '-fcompare-debug' failure (length) w/ -O2 -fnon-call-exceptions -fno-inline-small-functions since r10-3575-g629387a6586a7531
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104263 --- Comment #12 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:73b30d18a04bd6efa7e25c28dac1c863dc1cb06e commit r11-9595-g73b30d18a04bd6efa7e25c28dac1c863dc1cb06e Author: Jakub Jelinek Date: Fri Jan 28 19:02:26 2022 +0100 store-merging: Fix up a -fcompare-debug bug in get_status_for_store_merging [PR104263] As mentioned in the PRthe following testcase fails, because the last stmt of a bb with -g is a debug stmt and get_status_for_store_merging uses gimple_seq_last_stmt (bb_seq (bb)) when testing if it is valid for store merging. The debug stmt isn't valid, while a stmt at that position with -g0 is valid and so the divergence. As we walk the whole bb already, this patch just remembers the last non-debug stmt, so that we don't need to skip backwards debug stmts at the end of the bb to find last real stmt. 2022-01-28 Jakub Jelinek PR tree-optimization/104263 * gimple-ssa-store-merging.c (get_status_for_store_merging): For cfun->can_throw_non_call_exceptions && cfun->eh test whether last non-debug stmt in the bb is store_valid_for_store_merging_p rather than last stmt. * gcc.dg/pr104263.c: New test. (cherry picked from commit a591c71b41e18e4ff86852a974592af4962aef57)
[Bug tree-optimization/104307] [11 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104307 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c81d1a061e5cfab6bd276c5be4cd6161b11e6d44 commit r11-9596-gc81d1a061e5cfab6bd276c5be4cd6161b11e6d44 Author: Jakub Jelinek Date: Tue Feb 1 16:02:54 2022 +0100 veclower: Fix up -fcompare-debug issue in expand_vector_comparison [PR104307] The following testcase fails -fcompare-debug, because expand_vector_comparison since r11-1786-g1ac9258cca8030745d3c0b8f63186f0adf0ebc27 sets vec_cond_expr_only when it sees some use other than VEC_COND_EXPR that uses the lhs in its condition. Obviously we should ignore debug stmts when doing so, e.g. by not pushing them to uses. That would be a 2 liner change, but while looking at it, I'm also worried about VEC_COND_EXPRs that would use the lhs in more than one operand, like VEC_COND_EXPR or VEC_COND_EXPR (sure, they ought to be folded, but what if they weren't). Because if something like that happens, then FOR_EACH_IMM_USE_FAST would push the same stmt multiple times and expand_vector_condition can return true even when it modifies it (for vector bool masking). And lastly, it seems quite wasteful to safe_push statements that will just cause vec_cond_expr_only = false; and break; in the second loop, both for cases like 1000 immediate non-VEC_COND_EXPR uses and for cases like 999 VEC_COND_EXPRs with lhs in cond followed by a single non-VEC_COND_EXPR use. So this patch only pushes VEC_COND_EXPRs there. 2022-02-01 Jakub Jelinek PR middle-end/104307 * tree-vect-generic.c (expand_vector_comparison): Don't push debug stmts to uses vector, just set vec_cond_expr_only to false for non-VEC_COND_EXPRs instead of pushing them into uses. Treat VEC_COND_EXPRs that use lhs not just in rhs1, but rhs2 or rhs3 too like non-VEC_COND_EXPRs. * gcc.target/i386/pr104307.c: New test. (cherry picked from commit e9bf6d6b0e1d67df6dcee042fbe37ab72c3a38d7)
[Bug preprocessor/104147] [9/10/11 Regression] C preprocessor may remove the standard required whitespace between the preprocessing tokens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104147
--- Comment #6 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:7c442c8897163888e1d9e367b85565f61e0d3136
commit r11-9598-g7c442c8897163888e1d9e367b85565f61e0d3136
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 libgomp/104385] Segmentation fault when using nested dependent tasks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104385 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:312a10bdf6ba86d0e32641f5d8f0b6df76810da0 commit r11-9599-g312a10bdf6ba86d0e32641f5d8f0b6df76810da0 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 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 #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:bc87b6d859941794072c5a970174d22466eca33d commit r11-9600-gbc87b6d859941794072c5a970174d22466eca33d 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 middle-end/104446] [9/10/11 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 #8 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:25de6af07994e57626a16a91fa5d3944ba8ddcde
commit r11-9601-g25de6af07994e57626a16a91fa5d3944ba8ddcde
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 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 #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:784deb1671629734322640520a7421106194f20a commit r11-9602-g784deb1671629734322640520a7421106194f20a 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 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 #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:615419d60327a0712d9a54d7993bb2d2988e461a commit r11-9603-g615419d60327a0712d9a54d7993bb2d2988e461a 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 sanitizer/104449] [9/10/11 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 #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8a97d7bdb38285a7954f67172013098b61548870 commit r11-9604-g8a97d7bdb38285a7954f67172013098b61548870 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 debug/104517] '-fcompare-debug' failure w/ -O1 -fopenmp -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104517 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:14f0b450f7976f824428f0d35b4e7e6dc162f708 commit r11-9606-g14f0b450f7976f824428f0d35b4e7e6dc162f708 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. * gcc.dg/gomp/pr104517.c: New test. (cherry picked from commit 6a0d6e7ca9b9e338e82572db79c26168684a7441)
[Bug c/104510] [9/10/11 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 #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3a543eb7982ae6ccfb6ea2027ad4c71d5fcaf92a commit r11-9608-g3a543eb7982ae6ccfb6ea2027ad4c71d5fcaf92a 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 rtl-optimization/104544] [10/11 Regression] '-fcompare-debug' failure (length) w/ -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104544
--- Comment #6 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:cdebe6f777a24ae4c8fe520302a7cc52ca6620c4
commit r11-9609-gcdebe6f777a24ae4c8fe520302a7cc52ca6620c4
Author: Jakub Jelinek
Date: Wed Feb 16 14:48:30 2022 +0100
combine: Fix up -fcompare-debug issue in the combiner [PR104544]
On the following testcase on aarch64-linux, we behave differently
with -g and -g0.
The problem is that on:
(insn 10011 10010 10012 2 (set (reg:CC 66 cc)
(compare:CC (reg:DI 105)
(const_int 0 [0]))) "pr104544.c":18:3 407 {cmpdi}
(expr_list:REG_DEAD (reg:DI 105)
(nil)))
(insn 10012 10011 10013 2 (set (reg:SI 109)
(eq:SI (reg:CC 66 cc)
(const_int 0 [0]))) "pr104544.c":18:3 444 {aarch64_cstoresi}
(expr_list:REG_DEAD (reg:CC 66 cc)
(nil)))
(insn 10013 10012 10016 2 (set (reg:DI 110)
(zero_extend:DI (reg:SI 109))) "pr104544.c":18:3 111
{*zero_extendsidi2_aarch64}
(expr_list:REG_DEAD (reg:SI 109)
(nil)))
(insn 10016 10013 10017 2 (parallel [
(set (reg:CC 66 cc)
(compare:CC (const_int 0 [0])
(reg:DI 110)))
(set (reg:DI 111)
(neg:DI (reg:DI 110)))
]) "pr104544.c":18:3 281 {negdi_carryout}
(expr_list:REG_DEAD (reg:DI 110)
(nil)))
...
(debug_insn 6 5 7 2 (var_location:SI y (debug_expr:SI D#5))
"pr104544.c":18:3 -1
(nil))
(debug_insn 7 6 10033 2 (debug_marker) "pr104544.c":11:3 -1
(nil))
(insn 10033 7 10034 2 (set (reg:DI 117 [ _14 ])
(ior:DI (reg:DI 111)
(reg:DI 112))) "pr104544.c":11:6 496 {iordi3}
(expr_list:REG_DEAD (reg:DI 112)
(expr_list:REG_DEAD (reg:DI 111)
(nil
we successfully split 3 insns into two:
Trying 10011, 10013 -> 10016:
10011: cc:CC=cmp(r105:DI,0)
REG_DEAD r105:DI
10013: r110:DI=cc:CC==0
REG_DEAD cc:CC
10016: {cc:CC=cmp(0,r110:DI);r111:DI=-r110:DI;}
REG_DEAD r110:DI
Failed to match this instruction:
(parallel [
(set (reg:CC 66 cc)
(compare:CC (reg:DI 105)
(const_int 0 [0])))
(set (reg:DI 111)
(neg:DI (eq:DI (reg:DI 105)
(const_int 0 [0]
])
Failed to match this instruction:
(parallel [
(set (reg:CC 66 cc)
(compare:CC (reg:DI 105)
(const_int 0 [0])))
(set (reg:DI 111)
(neg:DI (eq:DI (reg:DI 105)
(const_int 0 [0]
])
Successfully matched this instruction:
(set (reg:DI 111)
(neg:DI (eq:DI (reg:DI 105)
(const_int 0 [0]
Successfully matched this instruction:
(set (reg:CC 66 cc)
(compare:CC (reg:DI 105)
(const_int 0 [0])))
Successfully matched this instruction:
(set (reg:DI 112)
(neg:DI (eq:DI (reg:CC 66 cc)
(const_int 0 [0]
allowing combination of insns 10011, 10013 and 10016
original costs 4 + 4 + 4 = 16
replacement costs 4 + 4 = 12
deferring deletion of insn with uid = 10011.
but the code that searches forward for insns to update their log
links (before the change there is a link from insn 10033 to insn 10016
for pseudo 111) only finds insn 10033 and updates the log link if
-g isn't enabled, otherwise it stops earlier because there are debug insns
in between. So, with -g LOG_LINKS of 10033 isn't updated, points
eventually
to NOTE_INSN_DELETED and so we do not attempt to combine 10033 with other
insns, while with -g0 we do.
The following patch fixes that by instead ignoring debug insns during the
searching. We can still check BLOCK_FOR_INSN (insn) on those, because
if we notice DEBUG_INSN in a following basic block, necessarily there won't
be any further normal insns in the current block after it.
2022-02-16 Jakub Jelinek
PR rtl-optimization/104544
* combine.c (try_combine): When looking for insn whose links
should be updated from i3 to i2, don't stop on debug insns, instead
skip over them.
* gcc.dg/pr104544.c: New test.
(cherry picked from commit f997eef5654f782bedb985c9285862c4d76b3209)
[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 #5 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:3eecfec27666b16b2ef855f32ba3f975e087dec1
commit r11-9611-g3eecfec27666b16b2ef855f32ba3f975e087dec1
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 target/104448] [10/11/12 Regression] ICE: in initialize, at function-abi.cc:108 with -mavx5124vnniw / -mavx5124fmaps -mno-xsave -mabi=ms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104448 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4dd24152c8cb5bca5fff1ddabb897c9452aab6a8 commit r11-9610-g4dd24152c8cb5bca5fff1ddabb897c9452aab6a8 Author: Jakub Jelinek Date: Wed Feb 16 17:03:58 2022 +0100 testsuite: Add testcase for already fixed PR [PR104448] This PR has been fixed with r12-7147-g2f9ab267e725ddf2. 2022-02-16 Jakub Jelinek PR target/104448 * gcc.target/i386/pr104448.c: New test. (cherry picked from commit f9c4917f01692a10f122f5ad56e559ba27751ace)
[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 #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:14f79acb6214108ce8e44a767e7eeabb456440fe commit r11-9605-g14f79acb6214108ce8e44a767e7eeabb456440fe 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. * g++.dg/cpp2a/constexpr-dtor12.C: New test. (cherry picked from commit 02a981a8e512934a990d1427d14e8e884409fade)
[Bug sanitizer/102656] [11/12 Regression] ICE on coroutines on -fsanitize=address -O1 since r11-1613-g788b962aa00959e8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102656
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9e3bbb4a8024121eb0fa675cb1f074218c1345a6
commit r12-7300-g9e3bbb4a8024121eb0fa675cb1f074218c1345a6
Author: Jakub Jelinek
Date: Sat Feb 19 09:03:57 2022 +0100
asan: Mark instrumented vars addressable [PR102656]
We ICE on the following testcase, because the asan1 pass decides to
instrument
.x = 0;
and does that by
_13 = &.x;
.ASAN_CHECK (7, _13, 4, 4);
.x = 0;
and later sanopt pass turns that into:
_39 = (unsigned long) &.x;
_40 = _39 >> 3;
_41 = _40 + 2147450880;
_42 = (signed char *) _41;
_43 = *_42;
_44 = _43 != 0;
_45 = _39 & 7;
_46 = (signed char) _45;
_47 = _46 + 3;
_48 = _47 >= _43;
_49 = _44 & _48;
if (_49 != 0)
goto ; [0.05%]
else
goto ; [99.95%]
[local count: 536864]:
__builtin___asan_report_store4 (_39);
[local count: 1073741824]:
.x = 0;
The problem is during expansion, isn't marked TREE_ADDRESSABLE,
even when we take its address in (unsigned long) &.x.
Now, instrument_derefs has code to avoid the instrumentation altogether
if we can prove the access is within bounds of an automatic variable in the
current function and the var isn't TREE_ADDRESSABLE (or we don't instrument
use after scope), but we do it solely for VAR_DECLs.
I think we should treat RESULT_DECLs exactly like that too, which is what
the following patch does. I must say I'm unsure about PARM_DECLs, those
can
have different cases, either they are fully or partially passed in
registers, then if we take parameter's address, they are in a local copy
inside of a function and so work like those automatic vars. But if they
are fully passed in memory, we typically just take address of the slot
and in that case they live in the caller's frame. It is true we don't
(can't) put any asan padding in between the arguments, so all asan could
detect in that case is if caller passes fewer on stack arguments or smaller
arguments than callee accepts. Anyway, as I'm unsure, I haven't added
PARM_DECLs to that case.
And another thing is, when we actually build_fold_addr_expr, we need to
mark_addressable the inner if it isn't addressable already.
2022-02-19 Jakub Jelinek
PR sanitizer/102656
* asan.cc (instrument_derefs): If inner is a RESULT_DECL and access
is
known to be within bounds, treat it like automatic variables.
If instrumenting access and inner is {VAR,PARM,RESULT}_DECL from
current function and !TREE_STATIC which is not TREE_ADDRESSABLE,
mark
it addressable.
* g++.dg/asan/pr102656.C: New test.
[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jakub Jelinek --- Fixed for 11.3+ too.
[Bug tree-optimization/104263] [10 Regression] '-fcompare-debug' failure (length) w/ -O2 -fnon-call-exceptions -fno-inline-small-functions since r10-3575-g629387a6586a7531
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104263 Jakub Jelinek changed: What|Removed |Added Summary|[10/11 Regression] |[10 Regression] |'-fcompare-debug' failure |'-fcompare-debug' failure |(length) w/ -O2 |(length) w/ -O2 |-fnon-call-exceptions |-fnon-call-exceptions |-fno-inline-small-functions |-fno-inline-small-functions |since |since |r10-3575-g629387a6586a7531 |r10-3575-g629387a6586a7531 --- Comment #13 from Jakub Jelinek --- Fixed for 11.3+ too.
[Bug tree-optimization/104307] [11 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104307 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jakub Jelinek --- Fixed for 11.3+ too.
[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 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in |trunc_int_for_mode, at |trunc_int_for_mode, at |explow.cc:59 since r9-6999 |explow.cc:59 since r9-6999 --- Comment #9 from Jakub Jelinek --- Fixed for 11.3+ too.
[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 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED Summary|[9/10/11 Regression] C |[9/10 Regression] C |preprocessor may remove the |preprocessor may remove the |standard required |standard required |whitespace between the |whitespace between the |preprocessing tokens|preprocessing tokens --- Comment #7 from Jakub Jelinek --- Fixed for 11.3+ too.
[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 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11 Regression] ICE: |[9/10 Regression] ICE: |verify_gimple failed: dead |verify_gimple failed: dead |statement in EH table with |statement in EH table with |-fexceptions|-fexceptions |-fsanitize=address |-fsanitize=address |-fstack-check=generic |-fstack-check=generic --- Comment #9 from Jakub Jelinek --- Fixed for 11.3+ too.
[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 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11 Regression] ICE: |[9/10 Regression] ICE: |'verify_gimple' failed: |'verify_gimple' failed: |mismatching comparison |mismatching comparison |operand types in|operand types in |verify_gimple_in_seq() |verify_gimple_in_seq() --- Comment #8 from Jakub Jelinek --- Fixed for 11.3+ too.
[Bug rtl-optimization/104544] [10 Regression] '-fcompare-debug' failure (length) w/ -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104544 Jakub Jelinek changed: What|Removed |Added Summary|[10/11 Regression] |[10 Regression] |'-fcompare-debug' failure |'-fcompare-debug' failure |(length) w/ -O2 |(length) w/ -O2 --- Comment #7 from Jakub Jelinek --- Fixed for 11.3+ too.
[Bug sanitizer/102656] [11 Regression] ICE on coroutines on -fsanitize=address -O1 since r11-1613-g788b962aa00959e8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102656 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] ICE on |[11 Regression] ICE on |coroutines on |coroutines on |-fsanitize=address -O1 |-fsanitize=address -O1 |since |since |r11-1613-g788b962aa00959e8 |r11-1613-g788b962aa00959e8 --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/104604] [12 Regression]wrong code with -O2 VRP Complex integer division issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104604
Andrew Pinski changed:
What|Removed |Added
Known to work||11.2.0
Target Milestone|--- |12.0
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Summary|wrong code with -O2 |[12 Regression]wrong code
|-fconserve-stack|with -O2 VRP Complex
|--param=vrp1-mode=ranger|integer division issue
Last reconfirmed||2022-02-19
--- Comment #1 from Andrew Pinski ---
Confirmed, reduced testcase which shows the problem even at just -O2:
typedef unsigned char u8;
u8 g;
__attribute__((noipa))
u8 foo (_Complex unsigned c)
{
_Complex unsigned t = 3;
t /= c;
u8 v = g;
return v + t;
}
int
main (void)
{
u8 x = foo (7);
if (x)
__builtin_abort ();
return 0;
}
[Bug tree-optimization/104601] [11/12 Regression] Invalid branch elimination at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104601 --- Comment #6 from Jakub Jelinek --- -O2 -fno-ipa-pure-const helps though and the patch affected both.
[Bug libstdc++/104605] New: _GLIBCXX_USE_C99_STDINT_TR1 macro is not defined for canadian cross freestanding C++ toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104605
Bug ID: 104605
Summary: _GLIBCXX_USE_C99_STDINT_TR1 macro is not defined for
canadian cross freestanding C++ toolchain
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: unlvsur at live dot com
Target Milestone: ---
#include
int main()
{
std::uintptr_t p{};
}
This code works on x86_64-elf cross toolchain on linux, but fails to work after
i perform Canadian cross-compilation from linux to windows since
_GLIBCXX_USE_C99_STDINT_TR1 is not defined.
Also stdint.h in GCC is not correctly defined without -ffreestanding flag.
I believe it can be trivialized as just do this
#if __has_include_next()
# include_next
#else
# include "stdint-gcc.h"
#endif
[Bug libstdc++/104605] _GLIBCXX_USE_C99_STDINT_TR1 macro is not defined for canadian cross freestanding C++ toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104605
--- Comment #1 from cqwrteur ---
D:\hg\fast_io\.tmp>x86_64-elf-g++ -c canada.cc -std=c++23
canada.cc: In function 'int main()':
canada.cc:5:14: error: 'uintptr_t' is not a member of 'std'; did you mean
'uintmax_t'?
5 | std::uintptr_t p{};
| ^
| uintmax_t
D:\hg\fast_io\.tmp>x86_64-elf-g++ -v
Using built-in specs.
COLLECT_GCC=x86_64-elf-g++
COLLECT_LTO_WRAPPER=d:/x86_64-windows-gnu/baremetal/x86_64-elf/bin/../libexec/gcc/x86_64-elf/12.0.1/lto-wrapper.exe
Target: x86_64-elf
Configured with: ../../../../gcc/configure --disable-nls --disable-werror
--disable-hosted-libstdcxx --without-headers --disable-shared
--target=x86_64-elf
--prefix=/home/cqwrteur/toolchains/gnu/x86_64-w64-mingw32/x86_64-elf
--host=x86_64-w64-mingw32 --enable-multilib --disable-libssp
--disable-libquadmath
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220219 (experimental) (GCC)
[Bug tree-optimization/104601] [11/12 Regression] Invalid branch elimination at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104601 --- Comment #7 from Jakub Jelinek --- And it ICEs again with -O2 -fno-ipa-pure-const if I add [[gnu::const]] or [[gnu::pure]] attribute to f. The function seems to be const in that it only returns the result and doesn't access any other memory, but the return value does not have a gimple reg type (but is returned in registers on x86_64): _Z1fi: movl$1, -8(%rsp) movb$1, -4(%rsp) movq-8(%rsp), %rax ret And we really should do something to make it movabsq $4294967297, %rax ret or so.
[Bug libstdc++/104605] _GLIBCXX_USE_C99_STDINT_TR1 macro is not defined for canadian cross freestanding C++ toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104605 --- Comment #2 from cqwrteur --- I just upload the toolchain to github. https://github.com/tearosccebe/x86_64-elf-baremetal-toolchain
[Bug go/104290] [12 Regression] trunk 20220214 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #24 from Svante Signell --- Thanks Ian, Hopefully someone knows hot to modify Makefile.tpl/Makefile.def to generate the correct dependencies in Makefile.in. Another patch that is not applied: gcc_config_gnu.h.diff. Who will commit that patch? It is not directly relating to libgo, but gotools fails to build later on without it. Thanks!
[Bug libstdc++/104602] std::source_location::current uses cast from void*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104602 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-02-19 --- Comment #2 from Jonathan Wakely --- But we can certainly move the cast into the default argument.
[Bug libstdc++/104602] std::source_location::current uses cast from void*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104602 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Can't we make it static consteval source_location current(decltype (__builtin_source_location ()) __p = __builtin_source_location()) noexcept ?
[Bug libstdc++/104606] New: Regression in comparison operator resolution with std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104606
Bug ID: 104606
Summary: Regression in comparison operator resolution with
std::optional
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: julien.philippon at epitech dot eu
Target Milestone: ---
Created attachment 52480
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52480&action=edit
Preprocessed file trigering the regression
This code used to compile with G++ 11.1 but does not anymore with G++ 11.2 :
```
#include
#include
#include
struct Value : public std::variant> {
using variant::variant;
};
struct Comparator {
template
bool operator<=(const T &rhs)
{
return true;
}
};
int main()
{
auto test = Comparator() <= Value{1};
auto test2 = Comparator() <= std::make_optional(Value{1});
}
```
In GCC 11.1 the comparison correctly deduced in the two cases that the lower or
equal operator of Comparator should be used, but in GCC 11.2, the second
comparison which involve an optional fails to compile.
It looks like GCC is trying to instantiate the three-way comparison operator of
Value, instead of using the operator of Comparator.
Output from g++ -v :
```
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-linker-build-id --enable-lto
--enable-multilib --enable-pgo-build=lto --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror --with-build-config=bootstrap-lto
--enable-link-serialization=1 gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)
```
[Bug libstdc++/104606] Regression in comparison operator resolution with std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104606 --- Comment #1 from julien.philippon at epitech dot eu --- I forgot to add that the bug triggers only when using C++ 20. When compiling with `g++ comparison_bug.cxx` the code compiles, but when compiling with `g++ -std=c++20 comparison_bug.cxx` this bug happens.
[Bug c/104607] New: Struct padding not initialized when all members are provided initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104607
Bug ID: 104607
Summary: Struct padding not initialized when all members are
provided initializers
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pascal_cuoq at hotmail dot com
Target Milestone: ---
In the GCC versions available as 11.2 and as “trunk” (as of this writing) on
Compiler Explorer, the following C code is translated to the following X86-64
assembly, with options “-O2 -std=c17”
CE link: https://gcc.godbolt.org/z/4oeh6d7vY
void g(void*);
int f(void) {
struct s { char c; long long m64;} s12 = {1,2}, s1 = {1};
g(&s1);
g(&s12);
}
f:
subq$40, %rsp
pxor%xmm0, %xmm0
leaq16(%rsp), %rdi
movaps %xmm0, 16(%rsp)
movb$1, (%rsp)
movq$2, 8(%rsp)
movb$1, 16(%rsp)
callg
movq%rsp, %rdi
callg
addq$40, %rsp
ret
Please note that GCC initializes all of s1 with “movaps %xmm0, 16(%rsp)” and
that initializing only s1.m64 to 0 in addition to initializing s1.c to 1 would
have resulted in fewer, shorter instructions.
However, s12 is not initialized this way, and indeed the padding of s12 is not
initialized at all.
The requirement to initialize padding is a change that was introduced between
C99 and C11. The relevant clauses are in C99:
https://port70.net/~nsz/c/c99/n1256.html#6.7.8p10
If an object that has automatic storage duration is not initialized explicitly,
its value is indeterminate. If an object that has static storage duration is
not initialized explicitly, then:
if it has pointer type, it is initialized to a null pointer;
if it has arithmetic type, it is initialized to (positive or unsigned) zero;
if it is an aggregate, every member is initialized (recursively) according to
these rules;
if it is a union, the first named member is initialized (recursively) according
to these rules.
https://port70.net/~nsz/c/c99/n1256.html#6.7.8p19
The initialization shall occur in initializer list order, each initializer
provided for a particular subobject overriding any previously listed
initializer for the same subobject;132) all subobjects that are not initialized
explicitly shall be initialized implicitly the same as objects that have static
storage duration.
In C11 the clause that was numbered 6.7.8:10 in C99 becomes 6.7.9:10 and the
text is changed as follows:
If an object that has automatic storage duration is not initialized explicitly,
its value is indeterminate. If an object that has static or thread storage
duration is not initialized explicitly, then:
if it has pointer type, it is initialized to a null pointer;
if it has arithmetic type, it is initialized to (positive or unsigned) zero;
if it is an aggregate, every member is initialized (recursively) according to
these rules, and any padding is initialized to zero bits;
if it is a union, the first named member is initialized (recursively) according
to these rules, and any padding is initialized to zero bits;
Now, I agree that it's possible to read the change in a way that only forces
the initialization of partially initialized structs. But can this have been the
intention of the standardization committee when they went to the trouble of
making an explicit change to C11? The concern was likely to address some
security issues with information leaks. If structs with initializers for every
members do not have their padding initialized, then security issues with
information leaks remain for structs with initializers for every members. Why
would the committee have fixed only half of the problem?
[Bug libstdc++/104605] _GLIBCXX_USE_C99_STDINT_TR1 macro is not defined for canadian cross freestanding C++ toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104605 --- Comment #3 from cqwrteur --- (In reply to cqwrteur from comment #2) > I just upload the toolchain to github. > https://github.com/tearosccebe/x86_64-elf-baremetal-toolchain link dead. sorry. https://bitbucket.org/ejsvifq_mabmip/x86_64-elf-baremetal-toolchain
[Bug c/104607] Struct padding not initialized when all members are provided initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104607 Eric Botcazou changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org --- Comment #1 from Eric Botcazou --- There is no requirement in any version of the ISO C standard that padding be initialized.
[Bug c/104607] Struct padding not initialized when all members are provided initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104607 --- Comment #2 from Pascal Cuoq --- Well that's a quick resolution to a bug report that contained that actual phrase “and any padding is initialized to zero bits”, and this in a quote from the C11 standard, but I guess one of us can't read then.
[Bug c/104607] Struct padding not initialized when all members are provided initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104607 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|UNCONFIRMED --- Comment #3 from Andrew Pinski --- .
[Bug c++/104606] [11/12 Regression] comparison operator resolution with std::optional and -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104606 Andrew Pinski changed: What|Removed |Added Component|libstdc++ |c++ Target Milestone|--- |11.3 Keywords||rejects-valid Summary|Regression in comparison|[11/12 Regression] |operator resolution with|comparison operator |std::optional |resolution with ||std::optional and ||-std=c++20 --- Comment #2 from Andrew Pinski --- I am suspecting a front-end change caused this. clang accepts the same code with libstdc++ which is another reason why I think it might be a front-end issue.
[Bug c++/104606] [11/12 Regression] comparison operator resolution with std::optional and -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104606 --- Comment #3 from Jakub Jelinek --- With preprocessed source from 11.1 even latest 11.2.1 compiles it fine with -std=c++20 (and also trunk).
[Bug c/104607] Struct padding not initialized when all members are provided initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104607 Eric Botcazou changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Eric Botcazou --- > Well that's a quick resolution to a bug report that contained that actual > phrase “and any padding is initialized to zero bits”, and this in a quote > from the C11 standard, but I guess one of us can't read then. The phrase starts with " If an object that has static or thread storage duration is not initialized explicitly, then:" so it does not apply to automatic storage duration, which is the case of your example.
[Bug c++/104606] [11/12 Regression] comparison operator resolution with std::optional and -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104606 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Just wild guess, perhaps the PR98842 changes between 11.1 and 11.2?
[Bug libstdc++/104606] [10/11/12 Regression] comparison operator resolution with std::optional and -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104606 Andrew Pinski changed: What|Removed |Added Known to work||10.3.0 Summary|[11/12 Regression] |[10/11/12 Regression] |comparison operator |comparison operator |resolution with |resolution with |std::optional and |std::optional and |-std=c++20 |-std=c++20 Component|c++ |libstdc++ Target Milestone|11.3|10.4 --- Comment #5 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #4) > Just wild guess, perhaps the PR98842 changes between 11.1 and 11.2? That would mean it is a bug in GCC 10.4 also :(.
[Bug tree-optimization/104595] unvectorized loop due to bool condition loaded from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104595 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/104595] unvectorized loop due to bool condition loaded from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104595 --- Comment #3 from Andrew Pinski --- IR in the bool case: _1 = pb[i_13]; iftmp.0_7 = a[i_13]; iftmp.0_6 = b[i_13]; iftmp.0_3 = _1 ? iftmp.0_7 : iftmp.0_6; c[i_13] = iftmp.0_3; IR in the char case: _1 = pc[i_13]; iftmp.1_7 = a[i_13]; iftmp.1_6 = b[i_13]; iftmp.1_3 = _1 == 0 ? iftmp.1_6 : iftmp.1_7; c[i_13] = iftmp.1_3; details in the bool case: /app/example.cpp:12:21: note: ==> examining statement: iftmp.0_3 = _1 ? iftmp.0_7 : iftmp.0_6; /app/example.cpp:12:21: note: vect_is_simple_use: operand pb[i_13], type of def: internal /app/example.cpp:12:21: note: vect_is_simple_use: vectype vector(32) unsigned char /app/example.cpp:11:6: missed: not vectorized: relevant stmt not supported: iftmp.0_3 = _1 ? iftmp.0_7 : iftmp.0_6; details in the char case: /app/example.cpp:17:21: note: ==> examining statement: iftmp.1_3 = _1 == 0 ? iftmp.1_6 : iftmp.1_7; /app/example.cpp:17:21: note: vect_is_simple_use: operand pc[i_13], type of def: internal /app/example.cpp:17:21: note: vect_is_simple_use: vectype vector(32) char /app/example.cpp:17:21: note: vect_is_simple_use: operand b[i_13], type of def: internal /app/example.cpp:17:21: note: vect_is_simple_use: vectype vector(32) char /app/example.cpp:17:21: note: vect_is_simple_use: operand a[i_13], type of def: internal /app/example.cpp:17:21: note: vect_is_simple_use: vectype vector(32) char /app/example.cpp:17:21: note: vect_model_simple_cost: inside_cost = 4, prologue_cost = 4 . It should not be too hard to if we had _1 ? : to change it to _1 != 0 right?
[Bug sanitizer/101978] thread sanitizer false positive when condition variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101978
Daniel Adamski changed:
What|Removed |Added
CC||danregister at poczta dot fm
--- Comment #3 from Daniel Adamski ---
(g++ (Debian 11.2.0-14) 11.2.0)
I believe it is wait_for() in particular. This works fine:
#include
#include
#include
#include
using namespace std::chrono_literals;
std::mutex mtx;
std::condition_variable cv;
void run1() {
std::unique_lock lck{mtx};
cv.wait(lck);
}
void run2() {
std::unique_lock lck{mtx};
std::this_thread::sleep_for(500ms);
cv.notify_all();
}
int main() {
std::jthread th1{ run1 };
std::jthread th2{ run2 };
}
But replace:
-cv.wait(lck);
+cv.wait_for(lck, 1s);
and you get "double lock":
==
WARNING: ThreadSanitizer: double lock of a mutex (pid=644005)
#0 pthread_mutex_lock
../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4240
(libtsan.so.0+0x4f30a)
#1 __gthread_mutex_lock
/usr/include/x86_64-linux-gnu/c++/11/bits/gthr-default.h:749 (a.out+0x27bf)
#2 std::mutex::lock() /usr/include/c++/11/bits/std_mutex.h:100
(a.out+0x2844)
#3 std::unique_lock::lock()
/usr/include/c++/11/bits/unique_lock.h:139 (a.out+0x422d)
#4 std::unique_lock::unique_lock(std::mutex&)
/usr/include/c++/11/bits/unique_lock.h:69 (a.out+0x3ce2)
#5 run2() /tmp/tsanmy.cpp:16 (a.out+0x241d)
#6 void std::__invoke_impl(std::__invoke_other, void
(*&&)()) /usr/include/c++/11/bits/invoke.h:61 (a.out+0x5550)
#7 std::__invoke_result::type std::__invoke(void
(*&&)()) /usr/include/c++/11/bits/invoke.h:96 (a.out+0x54b5)
#8 void std::thread::_Invoker
>::_M_invoke<0ul>(std::_Index_tuple<0ul>)
/usr/include/c++/11/bits/std_thread.h:253 (a.out+0x541a)
#9 std::thread::_Invoker >::operator()()
/usr/include/c++/11/bits/std_thread.h:260 (a.out+0x53c4)
#10 std::thread::_State_impl >
>::_M_run() /usr/include/c++/11/bits/std_thread.h:211 (a.out+0x537e)
#11 (libstdc++.so.6+0xd38f3)
Location is global 'mtx' of size 40 at 0x56501849e160 (a.out+0x9160)
Mutex M10 (0x56501849e160) created at:
#0 pthread_mutex_lock
../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4240
(libtsan.so.0+0x4f30a)
#1 __gthread_mutex_lock
/usr/include/x86_64-linux-gnu/c++/11/bits/gthr-default.h:749 (a.out+0x27bf)
#2 std::mutex::lock() /usr/include/c++/11/bits/std_mutex.h:100
(a.out+0x2844)
#3 std::unique_lock::lock()
/usr/include/c++/11/bits/unique_lock.h:139 (a.out+0x422d)
#4 std::unique_lock::unique_lock(std::mutex&)
/usr/include/c++/11/bits/unique_lock.h:69 (a.out+0x3ce2)
#5 run1() /tmp/tsanmy.cpp:11 (a.out+0x2392)
#6 void std::__invoke_impl(std::__invoke_other, void
(*&&)()) /usr/include/c++/11/bits/invoke.h:61 (a.out+0x5550)
#7 std::__invoke_result::type std::__invoke(void
(*&&)()) /usr/include/c++/11/bits/invoke.h:96 (a.out+0x54b5)
#8 void std::thread::_Invoker
>::_M_invoke<0ul>(std::_Index_tuple<0ul>)
/usr/include/c++/11/bits/std_thread.h:253 (a.out+0x541a)
#9 std::thread::_Invoker >::operator()()
/usr/include/c++/11/bits/std_thread.h:260 (a.out+0x53c4)
#10 std::thread::_State_impl >
>::_M_run() /usr/include/c++/11/bits/std_thread.h:211 (a.out+0x537e)
#11 (libstdc++.so.6+0xd38f3)
SUMMARY: ThreadSanitizer: double lock of a mutex
/usr/include/x86_64-linux-gnu/c++/11/bits/gthr-default.h:749 in
__gthread_mutex_lock
[Bug c++/71789] atomic_int incompatibility warning between C and C++ [-Wlto-type-mismatch]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71789 --- Comment #3 from Andrew Pinski --- This mentioned in this twitter thread: https://twitter.com/mcclure111/status/1495287879756562436
[Bug libstdc++/104606] [10/11/12 Regression] comparison operator resolution with std::optional and -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104606
--- Comment #6 from Jakub Jelinek ---
I've confirmed that removing those 2 lines:
template
-requires (!__is_optional_v<_Up>)
- && three_way_comparable_with<_Tp, _Up>
constexpr compare_three_way_result_t<_Tp, _Up>
operator<=>(const optional<_Tp>& __x, const _Up& __v)
{ return bool(__x) ? *__x <=> __v : strong_ordering::less; }
makes it accepted again.
That doesn't mean it doesn't need to be a FE bug, or it could not be a bug at
all, we need some C++ lawyer for that.
[Bug libstdc++/104606] [10/11/12 Regression] comparison operator resolution with std::optional and -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104606 --- Comment #7 from Jakub Jelinek --- Because what libstdc++ does there seems to match the standard: https://eel.is/c++draft/optional.comp.with.t#25
