From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B18A43858D35; Mon, 6 Jul 2020 20:31:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B18A43858D35 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1594067500; bh=vP2duoduv5XHpIUcLL566E1Q5a4yV+2ugdOmufEVU/A=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZWoQmxRqD8u7Oodi/z8j+0KaYYqBupzsuZpEJrnrM3juuVCS2XYm5amodgQwl425Y /YtC8/gK0K/Zrj5tPIYjgKRqhyEtP4dnWwYRCxVyynxcAYZrV2lQp7E36cEZ+JBV+o NdroXhykYok/7WAcZnlCQR21P5rhwU49VJqXjacc= From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa Date: Mon, 06 Jul 2020 20:31:40 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 10.1.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: law at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.2 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 20:31:40 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D96015 --- Comment #33 from Jeffrey A. Law --- Have I mentioned before that I think __builtin_unreachable is fundamentally broken/wrong :-) I could argue that the BARRIER in the IL is wrong because it doesn't actual= ly line up with the semantics of the instruction stream. But that's probably a losing battle with those who think that __builtin_unreachable's current behavior is sensible. One thought would be to turn a conditional jump followed by a barrier into = an unconditional jump in jump.c. But I fear that just papers over the problem= and that we'd see the same issue raise its head again in a slightly perturbed f= orm that wasn't recognized by jump.c, but tripped the same code as we have now = in reorg.c. Another thought would be to detect this in relax_delay_slots and twiddle the transformation to avoid the problematic behavior. I think we could detect = just by seeing if there's a barrier after INSN in the same hunk of code that Eric quoted and changing the behavior slightly when that's detected. I hate special casing things like that and there's a reasonable chance other parts of GCC are affected by the same problem. That may argue for implemen= ting both approaches. But I'd really just like to change how __builtin_unreachable works. Eric, thoughts? jeff=