From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id 51E1D3858C2A for ; Wed, 6 Dec 2023 11:32:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 51E1D3858C2A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 51E1D3858C2A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=68.232.137.180 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701862378; cv=none; b=Nw2mEbn6zRRy0RcNieqX9WAY68Q02RjrzGEE03F3yh3Dw8vGgjo1N54Bi7ybP2LBHoYP9D3Z8ae0Dzq94M4pzvhe4DnupmBKJx/IHRY7kNhSPQhekruivvphCRl2jHvap/s/fA7Sf1GaxEbsGE0iqiAz6HqyeHRmuytihLdhyaU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701862378; c=relaxed/simple; bh=UQcBTN59PSXOKGBUO7XfcT5ST6vxJa0B1TBdvvB9I5c=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=ODA+UvxiScLCOYToftNGZ+aIrHUsHeJvZ/sKvdrUCdSMAPcFw9XzdIM4r1Aj7xbd/xX9I914G7eRpEuVJiJoDwz5dGGpN7xWtDKzBNZZ9gELuENTeCnfM/bO6GyimKB/G1iBBesZ+ZrqMz4/vAiqqdc93WkrGtXWYKn+x336hT4= ARC-Authentication-Results: i=1; server2.sourceware.org X-CSE-ConnectionGUID: WdFn7/YxToaYTcGsUFKSXQ== X-CSE-MsgGUID: tqyBhSEzQj64iBXzjbDbMA== X-IronPort-AV: E=Sophos;i="6.04,255,1695715200"; d="scan'208";a="24618365" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 06 Dec 2023 03:32:54 -0800 IronPort-SDR: 7/sT2kKrt2zsnQ6LMhPbAQXZZ5OPj8+4oyQ+sA1PKuKd+bFm7vYO4BYFlRmslawCsWcdftGoeO M77/iFOVjkrG5Uzou0a8vBJH5xp5xBR6UDcPsL1tIW+KYHz+Ro93no6UY0aV6I42e6YH4N00dY exiMRHVv74Ygl3qNJggDChcCbL2PUWaIYJwscbaX9OiVu+DpewAO2TF4l9Wede1/3nDihlbcx3 BSFOygRYJnId3Bp45ADLwOcgRieJ4AOvz/ExysOluwlSprOZmfsznHpHcG86jgFF9kq/mBI47L AZM= From: Thomas Schwinge To: Alexandre Oliva CC: Tobias Burnus , Richard Biener , , Jeremy Bennett , Craig Blackmore , Graham Markall , Martin Jambor , "Jan Hubicka" , Jim Wilson , Jeff Law , Jakub Jelinek , Tom de Vries Subject: Re: Causes to nvptx bootstrap fail: [PATCH v5] Introduce strub: machine-independent stack scrubbing In-Reply-To: References: User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/28.2 (x86_64-pc-linux-gnu) Date: Wed, 6 Dec 2023 12:32:46 +0100 Message-ID: <87lea7sh0h.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-14.mgc.mentorg.com (139.181.222.14) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Alexandre! On 2023-12-06T09:36:33+0100, Tobias Burnus wrote: > FYI the newly added file libgcc/strub.c of this patch (aka commit r14-620= 1-gf0a90c7d7333fc ) > causes that nvptx does not bootstrap, failing with: ('s%bootstrap%build'.) > ./gcc/as -v -o strub.o strub.s > Verifying sm_30 code with sm_50 code generation. > ptxas -c -o /dev/null strub.o --gpu-name sm_50 -O0 > ptxas strub.o, line 22; error : Arguments mismatch for instruction 'st' > ptxas strub.o, line 22; error : Unknown symbol '%frame' > [...] Per commit r14-6201-gf0a90c7d7333fc7f554b906245c84bdf04d716d7 "Introduce strub: machine-independent stack scrubbing", we have: A function associated with @code{at-calls} @code{strub} mode (@code{strub("at-calls")}, or just @code{strub}) undergoes interface changes. Its callers are adjusted to match the changes, and to scrub (overwrite with zeros) the stack space used by the called function afte= r it returns. As I understand things, this cannot be implemented (at the call site) for nvptx, given that the callee's stack is not visible there: PTX is unusual in that the concept of a "standard" stack isn't exposed. Instead of allowing "strub" pieces that can be implemented, should this whole machinery generally be disabled (forced '-fstrub=3Ddisable', or via a new target hook?)? The libgcc functions should then not get defined (thus, linker error upon accidental use), or should just '__builtin_trap' if that makes more sense? Need an effective-target for the test cases. Alternatively, we may also leave the generic middle end handling alive, and 'sorry' (or similar) in the nvptx back end, as necessary? Gr=C3=BC=C3=9Fe Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955