From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpout35.security-mail.net (smtpout35.security-mail.net [85.31.212.35]) by sourceware.org (Postfix) with ESMTPS id 8B15F3858D3C for ; Fri, 12 Jan 2024 10:15:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8B15F3858D3C Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=kalrayinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kalrayinc.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8B15F3858D3C Authentication-Results: server2.sourceware.org; arc=fail smtp.remote-ip=85.31.212.35 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1705054521; cv=fail; b=ieLa3v/9WyjHCafmFhHuOHKAwa+DoOvRYIZgbT05arasLf/vPj3MfgYuLjuRfZ39zsWG2suLRybm8wJcXL1CNv6Gr03uMXB6MmT5i3Re9qUbZrJh4yCgGdn+uQMoI9RZuZrBCuZBPROfkvHsh2W+7Bgu96F0jI2ySXtJHjffGhQ= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1705054521; c=relaxed/simple; bh=ULn4uhUq+X7hPA2vVqLmy2sqCnkiaUVY7eLb0rWsDyI=; h=DKIM-Signature:DKIM-Signature:Date:From:To:Subject:Message-ID: MIME-Version; b=xpsZC+I96QLjMdmj/kpCl6kUri+mbclfCJdy6xiK8a8K1bIne5Yq10gLBnXqHvXtTqqjSUePqzeKqAh0h6vNFPNFpn5iSm0GMb9r7o/+neUXTjAyFlImdfd+tX/9ECQFg19sADxyxAw6G7vY30zJNa8hnvitlrKNACUERxt/dUo= ARC-Authentication-Results: i=2; server2.sourceware.org Received: from localhost (localhost [127.0.0.1]) by fx304.security-mail.net (Postfix) with ESMTP id 64DE8910F00 for ; Fri, 12 Jan 2024 11:15:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kalrayinc.com; s=sec-sig-email; t=1705054516; bh=ULn4uhUq+X7hPA2vVqLmy2sqCnkiaUVY7eLb0rWsDyI=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=b2n0lzEufdLqPjYrVC8PVMOFAxZ6v/ivpw9NSnvzqN52FZbHW08rc24vFC7xHmSa3 Z+zG3678iWXPR7+OxTsKMo50kCHYYGClaMRQCEAFv3ZOCVmtUdHRg0sXdpRU+JpTO4 XXQLRDaCBPYbzOwimKG/+1bEjef+OSeNZVEUvhk4= Received: from fx304 (localhost [127.0.0.1]) by fx304.security-mail.net (Postfix) with ESMTP id 3C57F90FFFF; Fri, 12 Jan 2024 11:15:16 +0100 (CET) Received: from FRA01-PR2-obe.outbound.protection.outlook.com (mail-pr2fra01on0101.outbound.protection.outlook.com [104.47.24.101]) by fx304.security-mail.net (Postfix) with ESMTPS id BBF1E91099D; Fri, 12 Jan 2024 11:15:15 +0100 (CET) Received: from MR1P264MB2482.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:33::22) by MRZP264MB2363.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:1c::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7181.21; Fri, 12 Jan 2024 10:15:13 +0000 Received: from MR1P264MB2482.FRAP264.PROD.OUTLOOK.COM ([fe80::bc00:fb42:2cd9:a178]) by MR1P264MB2482.FRAP264.PROD.OUTLOOK.COM ([fe80::bc00:fb42:2cd9:a178%4]) with mapi id 15.20.7181.022; Fri, 12 Jan 2024 10:15:13 +0000 X-Virus-Scanned: E-securemail Secumail-id: ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=abs9KUErNTbI+Bd6n83nkN97lKXEhjiVW2XTWmqPk1FJtsTRku5jTUsH25K1y29S2COJgJ9z4OvqRnIxlpS44ff5lF1+Wqog16LPuelPoG25uNIb0z7+enKILYsWi2hNwCNsR2FyLqS1F6K8VkSGcRfvHDR5QmwqFs68M40mKxvyIeZhCRVNidnQM7fJro9BzXyEaB9s2U55Uza4318aBOeiP4T7nj6C3kLMi+wV/YCSPQXs4FzKrpc+YBNms3CFUMwz8eBSc6SAmgFeFaRW6xKsApUR39bcsuBbi/ixba0HdDCjX+knVlMGAw7yEu0TJ+TJttu2fvS3flLaBdPB8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Nc5FfLRXmDU5Kn2gKiBRmkAivlch3GQWO1jJvkqjibY=; b=ej54nmbl0ozHXXzxb8cPF29bbkK5WrmcRbOPKLtL0pGhKUo9CFcSnCYFu8EgUsm7qms6qzKWgSDHSdJUUurpY1AAPM2k/qd9NE0k19DJfjFUNKXRr5l68AGj6AbZplLa7vNtYHilQ7dzctHlsB65a4CZF4O8yLtGDw8TaQQXSZeR6EH0uNJZe4giBKWfK2QVckcMw1HyZbmkUV3OaxH1P0pQ3Nfj4H+2ltD43+mreK+yL2J8vuuHbTr3fqtnlUCdrEVqLHYSGigdPsafBPQe00TFgCKtSOvYy6KeWiXHVv69gJnyQabh9J7Wej7NI7T1HyFLfH5KM0sRYnXiI7q9aQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=kalrayinc.com; dmarc=pass action=none header.from=kalrayinc.com; dkim=pass header.d=kalrayinc.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kalrayinc.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Nc5FfLRXmDU5Kn2gKiBRmkAivlch3GQWO1jJvkqjibY=; b=DezRFMp5Cg9TlQSD5CkGTCWsMn+9Jl5C1En1DlsH4ofv0n+d1F4cK63+AOXpbRmLveacTvR69oRN/QT6GGLJ/bigIJP4ZjERV4btAUlCIn7KlzcrERcTj4IK+W8fis+eYGwYFQJ9ODYvua28f6eMMqwE79ov5ij3NjN2VYDyGmeGq7arIgfQctcasmZXWY4sGKiHElWK6Y9IR9axtcCCxk9jByTzh4g+YzcFrBm3D5zHe1pIpRndX3QhQnTv1/EROmacc2mbaPxrXadabUDsAuoNZqyKOwEqjnekl3A/EDA+Nhb+hsj4h8iB/hlFjA/qsEmDoIq3dgilBjy6SRSoMA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=kalrayinc.com; Date: Fri, 12 Jan 2024 11:15:11 +0100 From: Paul Iannetta To: Jeff Law Cc: gcc@gcc.gnu.org Subject: Re: The macro STACK_BOUNDARY may overflow Message-ID: <20240112101511.ju3hpxxxv2bygzeo@kalrayinc.com> References: <20230324134850.teu6k2b4g33o4zsp@ws2202.lin.mbt.kalray.eu> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 X-ClientProxiedBy: AM9P192CA0030.EURP192.PROD.OUTLOOK.COM (2603:10a6:20b:21d::35) To MR1P264MB2482.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:33::22) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MR1P264MB2482:EE_|MRZP264MB2363:EE_ X-MS-Office365-Filtering-Correlation-Id: 761232a2-f212-4997-609b-08dc13575d68 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: bPdUWAZ9+uJa6dNAjP/ydbMYRZf6niuhcX6so401ddTdIUbsI93E56AtnwTSJF89RZKN8brNmnm64yxh8707W8NYfxvKfO8o54ARPluB96JibrLSpf68gAPQFzHiQX94ww9ToO7u/WLxfw10ZD9N38t1FVtBR34ZF7XJSWjm//XqgNg+9pz9TyV5H9/EPatiTy4ReEH3vmRYMDW2PF/IXpJE8Ve3iH+ckJ13Tq1HWlhjwbB0kuH1t+5i8WalSaaNRDiYj1Xi9cIDZ34KqtuyjQlpOK5TjQQz25P0hDE+Fx3R2B0DvnArBC2tRSKoIUhWQ3LcrPw/81wwgzNVnGhzN2O9UrYRGos/mTdxhbe1c7nMPTyUDup+E4rFuhssh5NE85Q1cMhaFDhkMBSDNK2KyEIebalDKFAaV5mma+ieslmHNhLfhPZfX3Dw6YmpQaKt26RDQvuP+jbeA/AklKqUIT7eblXP6Mnx3GkrnLJD4uaKQWCWk8G8zTDaU012mOv/KHvykU4TcJB9NmPlcCUO9tzm/INwFH11Rlt7xdqPgBPpO+o25nP0Jj/Uryv5UPbq X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MR1P264MB2482.FRAP264.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230031)(376002)(366004)(136003)(346002)(396003)(39850400004)(230922051799003)(64100799003)(186009)(1800799012)(451199024)(1076003)(26005)(2616005)(83380400001)(6506007)(86362001)(36756003)(38100700002)(5660300002)(4326008)(53546011)(6512007)(6916009)(66556008)(316002)(66476007)(66946007)(478600001)(8676002)(41300700001)(8936002)(6486002)(2906002);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: WtqrDlFW8KCgPXNt+7Wz3R3rEhiJI1wTN5NNASg5tIz81fWChqRZ0YQ79qvSLcCalQhNLW8l+51dkzfcivZM3I3Xvi/jNOk6/uvIaLPWnB2OEHrNHK8xF+VYMt24yyj4wp3Ji93+WRUWozO4rglvfibzrTkf+ZSf4iBaAS7ovQMqZG03gkIJnAp0G+lz4eUuiqy+LeUtJujrMcRxyOygox3ySonBd1JCnp1kcNOgkOqp8qQIckfgNSnoak8QdtwPf4OhvwqTR6gYeLw9C8sMaPXwlePh6VfW9kz2jdUWr/LxG1sVw/RsnCQbPgdAcytUIPJyrAMoMbsht2AZ9pq216YY2MRKVTki/o4FOPdgii2kP+li1sWhcjSG0/caE6erFpebxFS7I0M6hLDqgcr0GizG4HsbCfLVZK2yWG5c90S75c6lhhXznMnrW0IhseYx0K9NGSFXQg0H/PLshw66ZI8MWdWKqYopc7i5T5uxbzK+RFZ69xQS1VEDO6otgxm2W3vaitK1b8CqE21pvAc948QgWzO8Bt6Fa0l20rVofTPbjU9AaoVLYF5DQdfNq2bFZwVZw/zsKrTS+K9tdrK9MVtuqiWWuZeZ3i1scOq/I3YHwHScodkNMqQXtXM++3hyVYFr0L+CuBzWDgvZ1CPDlhFxIXOLJ/1EiiixKgpqStfji1IP7K1Hx8KObWULTVkq6QrBcRwnZybVamKRHsBkBDh+B4w9bOTDAh7tOwej0U5twntWfOIw/E5/2aSiUg3s3JRXr/r+vIzlVP7FRrqiNoMAukqxFuytKg8Kh0UxbHR9ryBP3cOymE6D2DdBmrIWVYSeJD+7x65+WC4G61KYR9Fs9S72fFA0Ykbsr/7uiCLgt8WmU2ipBnB0tD6eFe9xvVRaMKqJLFVyJzqEhcj0VPeD6mWZhH375JVBEN4ItmkBnukC2dcq6+1lxr17sH5n 8MM9u5i7noTV+L1VOBp9y8jaWfHqF80FJ7sxOPRqbit8X4lX3S367w/fXHU/QJaDp61t297rpVdv70h87BIEPWKdFdKN4sBlELUIn9ao8z0BL5WfsHn5AdTNK6CCTTkYQlLF/1eKNzzY7k2GGiDlaEw26nQebGIGc5keYj7lUI5mf2rEPc5RWm7IBD0ZQLDd41J/XWtJnP2wP6hcfbOGmMGZUkUVhO+rlfjh35qGROQZ9FcGaV2HFLQiqgeOqUJay4zQd+vBfrkQKlmKiaq808iy/rd44uT6PPdN+vCDOaPemz/wL1bzIuj7n90yX87ypUwMAYlm8ezegFbUTDS1U6Ym9Os9dF5jTz2i1hyVqUwklm1S0cF0ORGPOuUNB8BPTdFayJWT5vAIfz5MJwwTlMCPlLT2ewNdnbzypu6zjzXHpT17c5uioRfNuk6DaOSHTdwzp8fNxdY7Gsm8Hj4nb+2PGHefzmQ2KYKJ98O0P5O3+RfTEar36TApRfubsUIDnpHQkB9RhV+EqBpbKyVDriY5n3Hwtag/KB66Qcor0mWyxgbDOo4DqD1fxosvynLzemOHI/fjdlsQGOckctRwG078VOHisu6Fq+k+HKl5ffhu83vRgNvMKDw3b8RybsufT8xCT0QF6JkVSoX8/b1jOw== X-OriginatorOrg: kalrayinc.com X-MS-Exchange-CrossTenant-Network-Message-Id: 761232a2-f212-4997-609b-08dc13575d68 X-MS-Exchange-CrossTenant-AuthSource: MR1P264MB2482.FRAP264.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2024 10:15:13.2420 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8931925d-7620-4a64-b7fe-20afd86363d3 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Ia4aHR9dv1jgVNB+iGaghTvZWgBjg4tc43Sv3sO1doBf0DnQ06cf60Fv1OsYArQSiGgldtHkutW9gGDBJpNxqw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MRZP264MB2363 Content-Transfer-Encoding: 8bit X-ALTERMIMEV2_out: done X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 Sat, Mar 25, 2023 at 10:28:02AM -0600, Jeff Law via Gcc wrote: > On 3/24/23 07:48, Paul Iannetta via Gcc wrote: > > Hi, > > > > Currently, the macro STACK_BOUNDARY is defined as > > > > Macro: STACK_BOUNDARY > > Define this macro to the minimum alignment enforced by hardware for > > the stack pointer on this machine. The definition is a C > > expression for the desired alignment (measured in bits). This > > value is used as a default if 'PREFERRED_STACK_BOUNDARY' is not > > defined. On most machines, this should be the same as > > 'PARM_BOUNDARY'. > > > > with no mentions about its type and bounds. However, at some point, the value > > of this macro gets assigned to the field "regno_pointer_align" of "struct > > emit_status" which points to an "unsigned char", hence if STACK_BOUNDARY gets > > bigger than 255, it will overflow... Thankfully, the backend which defines the > > highest value is microblaze with 128 < 255. > > > > The assignment happens in "emit-rtl.c" through the REGNO_POINTER_ALIGN macro: > > > > in function.h: > > #define REGNO_POINTER_ALIGN(REGNO) (crtl->emit.regno_pointer_align[REGNO]) > > in emit-rtl.cc: > > REGNO_POINTER_ALIGN (STACK_POINTER_REGNUM) = STACK_BOUNDARY; > > [...] > > REGNO_POINTER_ALIGN (VIRTUAL_OUTGOING_ARGS_REGNUM) = STACK_BOUNDARY; > > > > Would it be possible to, either add an explicit bound to STACK_BOUNDARY in the > > manual, and/or use an "unsigned int *" rather than and "unsigned char *" for > > the field "regno_pointer_align". > Feel free to send a suitable patch to gcc-patches. THe alignment data isn't > held in the RTX structures, so it's not critical that it be kept as small as > possible. We don't want to waste space, so an unsigned short might be > better. A char was good for 30 years, so we don't need to go crazy here. > > The alternative would be to change the representation to store the log2 of > the alignment. That would be a much larger change and would trade off > runtime for memory consumption. I would have suggested this approach if the > data were in the RTX structures amd space at a premium. > > While I do see a trend in processor design to reduce/remove the misalignment > penalties (thus eliminating the driver for increasing data alignment), > that's been primarily in high end designs. > > jeff Hi, Here is a patch that changes the type of the variable holding the alignment to unsigned short for the reasons outlined above. Should I also mention the new upper bound for STACK_BOUNDARY in the documentation or keep it silent? Thanks, Paul ---->8-------------------------------------------------------8<---- From: Paul Iannetta Date: Fri, 12 Jan 2024 10:18:34 +0100 Subject: [PATCH] make regno_pointer_align a unsigned short* This changes allows to align values greater than 128 to be used for alignment. * emit-rtl.cc (emit_status::ensure_regno_capacity): Change unsigned char* to unsigned short* (init_emit): Likewise. * function.h (struct GTY): Likewise. --- gcc/emit-rtl.cc | 6 +++--- gcc/function.h | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/gcc/emit-rtl.cc b/gcc/emit-rtl.cc index 1856fa4884f..f0f0ad193b5 100644 --- a/gcc/emit-rtl.cc +++ b/gcc/emit-rtl.cc @@ -1231,9 +1231,9 @@ emit_status::ensure_regno_capacity () while (reg_rtx_no >= new_size) new_size *= 2; - char *tmp = XRESIZEVEC (char, regno_pointer_align, new_size); + short *tmp = XRESIZEVEC (short, regno_pointer_align, new_size); memset (tmp + old_size, 0, new_size - old_size); - regno_pointer_align = (unsigned char *) tmp; + regno_pointer_align = (unsigned short *) tmp; rtx *new1 = GGC_RESIZEVEC (rtx, regno_reg_rtx, new_size); memset (new1 + old_size, 0, (new_size - old_size) * sizeof (rtx)); @@ -5972,7 +5972,7 @@ init_emit (void) crtl->emit.regno_pointer_align_length = LAST_VIRTUAL_REGISTER + 101; crtl->emit.regno_pointer_align - = XCNEWVEC (unsigned char, crtl->emit.regno_pointer_align_length); + = XCNEWVEC (unsigned short, crtl->emit.regno_pointer_align_length); regno_reg_rtx = ggc_cleared_vec_alloc (crtl->emit.regno_pointer_align_length); diff --git a/gcc/function.h b/gcc/function.h index 2d775b877fc..c4a20060844 100644 --- a/gcc/function.h +++ b/gcc/function.h @@ -72,7 +72,7 @@ struct GTY(()) emit_status { /* Indexed by pseudo register number, if nonzero gives the known alignment for that pseudo (if REG_POINTER is set in x_regno_reg_rtx). Allocated in parallel with x_regno_reg_rtx. */ - unsigned char * GTY((skip)) regno_pointer_align; + unsigned short * GTY((skip)) regno_pointer_align; };