Re: [PATCH RFC] Fix ICE due to shared BLOCK node in coroutine generation [PR103328]

On 3/17/22 07:37, Benno Evers via Gcc-patches wrote: The coroutine transformation moves the original function body into a newly created actor function, but the block of the `current_binding_level` still points into the original function, causing the block to be shared between the two functions if

Remove mysterious '-# Defining these options here in addition to common.opt is necessary' command-line option (was: [PATCH v2 1/2] add -Wuse-after-free)

Hi! On 2022-01-15T17:00:11-0700, Martin Sebor via Gcc-patches wrote: > On 1/11/22 15:40, Jason Merrill wrote: >> On 11/30/21 17:32, Martin Sebor via Gcc-patches wrote: >>> [default setting of the option] >> Let's put =2 in -Wall for now. > I've adjusted [...] and pushed r12-6605 [...] Pushed

RE: [PATCH] Ignore (possible) signed zeros in operands of FP comparisons.

Hi Aldy, The proposed frange implementation looks cool. The one technical tweak is that if x is not NaN and not +Inf/-Inf, then x*0.0 is [-0.0,0.0]. It's because this result is a range and not a constant that it can’t normally be constant folded, unless it appears in a context where the sign of

Re: [PATCH] fortran: Fix up initializers of param(0) PARAMETERs [PR103691]

> Am 26.03.2022 um 12:28 schrieb Thomas Koenig : > > On 25.03.22 12:34, Jakub Jelinek via Fortran wrote: >> What is the behavior with a RANGE_EXPR when one has { [0..10] = ++i; >> }, is that applying the side-effects 11 times or once ? > > For side effects during the evaluation of expression,

Re: [PATCH] middle-end/100786 - constant folding from incompatible alias

Hi Richard, The patch for PR100786 introduced a testcase that systematically fails on darwin: FAIL: gcc.dg/torture/pr100786.c -O0 (test for excess errors) FAIL: gcc.dg/torture/pr100786.c -O1 (test for excess errors) FAIL: gcc.dg/torture/pr100786.c -O2 (test for excess errors) FAIL: gcc.

[committed] analyzer: fix ICE on memset of untracked region [PR105057]

In r12-7809-g5f6197d7c197f9d2b7fb2e1a19dac39a023755e8 I added an optimization to avoid tracking the state of certain memory regions in the store. Unfortunately, I didn't cover every way in which store::get_or_create_cluster can be called for a base region, leading to assertion failure ICEs in -fan

Re: [PATCH] fortran: Fix up initializers of param(0) PARAMETERs [PR103691]

On 25.03.22 12:34, Jakub Jelinek via Fortran wrote: What is the behavior with a RANGE_EXPR when one has { [0..10] = ++i; }, is that applying the side-effects 11 times or once ? For side effects during the evaluation of expression, Fortran has a clear "if you depend on it, it's your fault" rule.