From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B60E53858CDA; Thu, 21 Mar 2024 09:35:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B60E53858CDA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1711013733; bh=GWD6eqJrZHsMiDLiUVjw/GFDh8SYjmwEQG1n2tTFUb0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Up4IzJp7CZ3R/IrqBqBU/x5sEtpVidebqHZ0B3eKqTj95uJf7sT3Tl1btvf1Lf4tk 2xjJVUBuFDknxRHo9EHdq4HRWBokIPwcPkoFx3ZIpK3QKARRubgNg7RJkUY5bvNtWd MGnAzbQfdf8kk39r9updOGKeaT4VLp/4H5q6YI98= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug analyzer/114408] [13/14 Regression] ICE when invoking strcmp multiple times with -fsanitize=undefined -O1 -fanalyzer -flto Date: Thu, 21 Mar 2024 09:35:32 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: analyzer X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: ice-on-valid-code, link-failure, lto, rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: dmalcolm at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cf_known_to_work target_milestone assigned_to short_desc cc bug_status cf_known_to_fail component everconfirmed cf_reconfirmed_on Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114408 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Known to work| |12.3.0 Target Milestone|--- |13.3 Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot= gnu.org Summary|ICE when invoking strcmp |[13/14 Regression] ICE when |multiple times with |invoking strcmp multiple |-fsanitize=3Dundefined -O1 |times with |-fanalyzer -flto |-fsanitize=3Dundefined -O1 | |-fanalyzer -flto CC| |dmalcolm at gcc dot gnu.org Status|UNCONFIRMED |NEW Known to fail| |13.2.1 Component|ipa |analyzer Ever confirmed|0 |1 Last reconfirmed| |2024-03-21 --- Comment #1 from Richard Biener --- Confirmed also with GCC 13, works with GCC 12. The diagnostic is because of UBSAN instrumentation, it's already visible without -flto. The issue with the ICE is likely that the sanitizer computes dominance info= at IPA time but fails to release it? I see in sm-malloc.cc: /* Reject the warning if the deref's BB doesn't dominate that of the check, so that we don't warn e.g. for shared cleanup code that checks a pointer for NULL, when that code is sometimes used before a deref and sometimes after. Using the dominance code requires setting cfun. */ auto_cfun sentinel (m_deref_enode->get_function ()); calculate_dominance_info (CDI_DOMINATORS); if (!dominated_by_p (CDI_DOMINATORS, m_check_enode->get_supernode ()->m_bb, m_deref_enode->get_supernode ()->m_bb)) return false; return ctxt.warn ("check of %qE for NULL after already" " dereferencing it", m_arg); but no free_dominance_info anywhere. It would of course be quite expensive to re-compute all dominance info every time here, so analyzer needs to loop over all functions releasing dominance info when done.=