From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 706CC3858D28 for ; Tue, 2 Apr 2024 08:03:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 706CC3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 706CC3858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712045021; cv=none; b=o7dTa7HNAW6p85sjjUaFoy9FQe15mfu/kCBOiH46nGoN4WFGfGCEywnHNzddiIbu1SXNyVYPmJU6ruS0k/gaSm/PW7qu+wx1I4CQVFJKHe5ZgMMS2/YvRlQ24RWQ7xXUyi48xMRruCJ6/rvCLiKjfrOUUEBl+lVid9xLfQcg3v0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712045021; c=relaxed/simple; bh=exAn3WyiHhL4dCdcNCy0WATnpQasWxZxO7Dag5jKuLc=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=iZSUCYU96y9+HTdvv3MU+7/jDSo4p+stVzJGcj6KMzXlnXrcBzHD7gnYkUDdwfQqG0rFeavdZ9s2Lqf2A5t9dvu0LdyvPbbdiMbPlXrWrqp+7XeCiOrtHVsPmw44Z+Jsu4JcWQxwimF+Yt7s14m5GgcZrJN9zhsgVZU4Vg6703c= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712045010; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=jh0J7baKLXRCMqpNuVHgt0w7ME4m4fbPddPL5gyJo+c=; b=L69GH9g9wmA4pPBUejJ7utsYhUcy+1o3T4v6cFQHYV2MG1WB6d64V1XvPyunesNd5+fs3b atPX+r3uHj5m+K4xCTW8GVGEfHL9DvpriqGbL1JJy4Pq4GLPNbmhNPGLa7Qah8dkRcIXv1 dvEqN9juEUeJGwp9sWGYcZ/y3NDjn8k= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-663-6RIMYPp7Ow6obw8x1LAhQg-1; Tue, 02 Apr 2024 04:03:27 -0400 X-MC-Unique: 6RIMYPp7Ow6obw8x1LAhQg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 81C4085954E; Tue, 2 Apr 2024 08:03:26 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.14]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2FF121C060A4; Tue, 2 Apr 2024 08:03:26 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 43283KPW3168892 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 2 Apr 2024 10:03:20 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 43283JaQ3168891; Tue, 2 Apr 2024 10:03:19 +0200 Date: Tue, 2 Apr 2024 10:03:19 +0200 From: Jakub Jelinek To: "Kewen.Lin" Cc: Ajit Agarwal , Peter Bergner , Segher Boessenkool , David Edelsohn , Michael Meissner , gcc-patches Subject: Re: [PATCH v2] rs6000: Stackoverflow in optimized code on PPC [PR100799] Message-ID: Reply-To: Jakub Jelinek References: <8e8dad73-43a6-4764-a496-b600e6a220e1@linux.ibm.com> <76307976-77b0-48f0-90b9-6dcec02e3c8f@linux.ibm.com> <6a592b9f-d536-4a0e-aa00-ee8d4a778afc@linux.ibm.com> <5a2e511a-3a29-4cdd-88b1-12a6274d5a79@linux.ibm.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Apr 02, 2024 at 02:12:04PM +0800, Kewen.Lin wrote: > >>>> The old code for the unused hidden parameter (which was the 9th param) would > >>>> fall thru to the "return NULL_RTX;" which would make the callee assume there > >>>> was a parameter save area allocated. Now instead, we'll return a reg rtx, > >>>> probably of r11 (r3 thru r10 are our param regs) and I'm guessing we'll now > >>>> see a copy of r11 into a pseudo like we do for the other param regs. > >>>> Is that a problem? Given it's an unused parameter, it'll probably get deleted > >>>> as dead code, but could it cause any issues? What if we have more than one > > I think Peter raised one good point, not sure it would really cause some issues, > but the assigned reg goes beyond GP_ARG_MAX_REG, at least it is confusing to people > especially without DCE like at -O0. Can we aggressively remove these candidates > from DECL_ARGUMENTS chain? Does it cause any assertion to fail? I'd prefer not to remove DECL_ARGUMENTS chains, they are valid arguments that just some invalid code doesn't pass. By removing them you basically always create an invalid case, this time in the other direction, valid caller passes more arguments than the callee (invalidly) expects. Jakub