From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by sourceware.org (Postfix) with ESMTPS id D61853858D20 for ; Sat, 25 Mar 2023 16:28:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D61853858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x102c.google.com with SMTP id fy10-20020a17090b020a00b0023b4bcf0727so4423691pjb.0 for ; Sat, 25 Mar 2023 09:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679761684; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=yKItHnI/AiAH8PVTxOzNyM19C0exB/MqowoERCVUfAI=; b=oHlrnWAmXOynwlsUlRoxaNw3kcbgDg8z9lV1+6uQ5sp8XZ53CvYISwHzFJ8HgBena+ nVwQw1Y6yy3j44djodJtdprP5vZTIJmxZ/goMB2PyhIx4grZaHnOI4lHXJDdiW4iDT4v /jhAvTAWlBMSIQpb655lFoBy3BxO6bguwQKKNqlyGAT2aL++lD1j+ukwY1DMEKph7bXH /ftjS4YvHa6/swsdlwJb8jHmssEBXBPRXf5R+Px3Jo+WNAj6ogc340GdmRvN9/Mv9r7A tjQF7lrpStZ9pIxdG6Gh3a+qY2yGJ3jOQJHmohQCUJV6RMqapPueytT5hDoDp0k71Y7+ wVVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679761684; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yKItHnI/AiAH8PVTxOzNyM19C0exB/MqowoERCVUfAI=; b=zEM5VbP74gqCZlTRrGDwwro9z3PvF6vJ1UKFt3PRne3xsOACH+C+nSjmmt4QIw42KG FSdZgRyPiTKdibkINCsnwfkDM3ds75nd2gqMIWR1CpT8HtqUtgoPpZV7IMq2FMdLBtS0 V77qdtvmEUj5GWvM/QNIljX6qa47ymhPr0N6zEYjIF+HfgqoYQbpFUlpT+f+XJDx4Pw9 Iu0hYFGmS71bW6mSrdH8YTU01Tl/ZLRHwLJAsTsA3doqZiSt8JO8JtF4qLxslqL5JcyY 01ynCa6mFTKCspDjlZtVTluiCnRmatYBKBGF47NkZTOu89FuU5WjbvsCcR+g2QRH835V aoYQ== X-Gm-Message-State: AO0yUKU1/oXDxuI2vxpFMdfL/+VoH0K6lenGlhZ8VkiK/7XZswt02QKy aWSvAFznhTBrzvGyGzb8w9OvgNmTvzM= X-Google-Smtp-Source: AK7set/51aGE7HPFSR3u1yxt+lS29rLBwEx2dsmOHzIzJ2eRgHhfMAJHagnqwWoR9j84dPKkzaz8DA== X-Received: by 2002:a05:6a20:be09:b0:cb:e735:65a5 with SMTP id ge9-20020a056a20be0900b000cbe73565a5mr5843255pzb.40.1679761683893; Sat, 25 Mar 2023 09:28:03 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id t23-20020aa79397000000b00627df889420sm14394666pfe.173.2023.03.25.09.28.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Mar 2023 09:28:03 -0700 (PDT) Message-ID: Date: Sat, 25 Mar 2023 10:28:02 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: The macro STACK_BOUNDARY may overflow Content-Language: en-US To: gcc@gcc.gnu.org References: <20230324134850.teu6k2b4g33o4zsp@ws2202.lin.mbt.kalray.eu> From: Jeff Law In-Reply-To: <20230324134850.teu6k2b4g33o4zsp@ws2202.lin.mbt.kalray.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 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