From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <xry111@xry111.site>
Received: from xry111.site (xry111.site [IPv6:2001:470:683e::1])
 by sourceware.org (Postfix) with ESMTPS id 604C43858CDA
 for <gcc-patches@gcc.gnu.org>; Wed, 13 Jul 2022 01:22:01 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 604C43858CDA
Received: from localhost.localdomain (xry111.site [IPv6:2001:470:683e::1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest
 SHA384) (Client did not present a certificate)
 (Authenticated sender: xry111@xry111.site)
 by xry111.site (Postfix) with ESMTPSA id 3BFC566894;
 Tue, 12 Jul 2022 21:21:57 -0400 (EDT)
Message-ID: <9744611e946f4de08739d9311bab6452b6d77a94.camel@xry111.site>
Subject: Re: Mips: Fix kernel_stat structure size
From: Xi Ruoyao <xry111@xry111.site>
To: Dimitrije Milosevic <Dimitrije.Milosevic@Syrmia.com>, Hans-Peter Nilsson
 <hp@bitrange.com>
Cc: Djordje Todorovic <Djordje.Todorovic@syrmia.com>, 
 "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Date: Wed, 13 Jul 2022 09:21:55 +0800
In-Reply-To: <AM0PR03MB4882B70DCC364C186725D87982869@AM0PR03MB4882.eurprd03.prod.outlook.com>
References: <AM0PR03MB488253CF19B1113D56777D3182BD9@AM0PR03MB4882.eurprd03.prod.outlook.com>
 <alpine.BSF.2.20.16.2207082134410.89039@arjuna.pair.com>
 <56af834718d603a4175a10df0a047d92b0b6d139.camel@xry111.site>
 <alpine.BSF.2.20.16.2207091019310.41348@arjuna.pair.com>
 <AM0PR03MB4882B70DCC364C186725D87982869@AM0PR03MB4882.eurprd03.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.3 
MIME-Version: 1.0
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FROM_SUSPICIOUS_NTLD,
 LIKELY_SPAM_FROM, PDS_OTHER_BAD_TLD, 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
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jul 2022 01:22:02 -0000

On Tue, 2022-07-12 at 06:42 +0000, Dimitrije Milosevic wrote:
> Hi Hans-Peter,
> You're right, this is not ok for the O32 ABI. Your change however, broke =
the functionality
> for the N32 ABI. AFAIK, the changes like this should go through LLVM firs=
t (yours didn't),
> so I will send out a review, covering both 32 ABIs, meaning that both O32=
 and N32 ABIs=20
> will be working properly. As for this change, I'm not sure what should be=
 done?=20
> Should this be committed now, while the LLVM change is cherry-picked once=
 it's committed.

I think just get it into LLVM first, then we sync with LLVM.

It seems on o32 sizeof(struct stat) is 144, n32 -> 160, n64 -> 216
(tested on gcc23.fsffrance.org).  "Luckily" we don't support other
strange things like "o64".