From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <> Received: from fx409.security-mail.net (smtpout140.security-mail.net [85.31.212.149]) by sourceware.org (Postfix) with ESMTPS id BADD33836010 for ; Tue, 17 Aug 2021 08:49:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BADD33836010 Received: from localhost (localhost [127.0.0.1]) by fx409.security-mail.net (Postfix) with SMTP id 6A7C33238B4 for ; Tue, 17 Aug 2021 10:49:14 +0200 (CEST) Received: from fx409 (localhost [127.0.0.1]) by fx409.security-mail.net (Postfix) with ESMTP id 1AE75323628 for ; Tue, 17 Aug 2021 10:49:14 +0200 (CEST) X-Virus-Scanned: E-securemail Secumail-id: <3587.611b7808.5ca82.0> Received: from zimbra2.kalray.eu (unknown [217.181.231.53]) by fx409.security-mail.net (Postfix) with ESMTPS id 5D84E3238B2 for ; Tue, 17 Aug 2021 10:49:12 +0200 (CEST) Received: by zimbra2.kalray.eu (Postfix) id 441D327E0232; Tue, 17 Aug 2021 10:49:12 +0200 (CEST) Date: Tue, 17 Aug 2021 10:49:12 +0200 (CEST) From: MAILER-DAEMON@zimbra2.kalray.eu (Mail Delivery System) Subject: Undelivered Mail Returned to Sender To: gcc@gcc.gnu.org Auto-Submitted: auto-replied MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="721B127E0334.1629190152/zimbra2.kalray.eu" Content-Transfer-Encoding: 8bit Message-Id: <20210817084912.441D327E0232@zimbra2.kalray.eu> X-Virus-Scanned: by Secumail X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, HTML_MESSAGE, KAM_DMARC_STATUS, KAM_SHORT, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 08:49:26 -0000 This is a MIME-encapsulated message. --721B127E0334.1629190152/zimbra2.kalray.eu Content-Description: Notification Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit This is the mail system at host zimbra2.kalray.eu. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : host zimbra2.kalray.eu[192.168.40.202] said: 452 4.2.2 Over quota (in reply to end of DATA command) --721B127E0334.1629190152/zimbra2.kalray.eu Content-Description: Delivery report Content-Type: message/delivery-status Content-Transfer-Encoding: 8bit Reporting-MTA: dns; zimbra2.kalray.eu X-Postfix-Queue-ID: 721B127E0334 X-Postfix-Sender: rfc822; gcc@gcc.gnu.org Arrival-Date: Thu, 12 Aug 2021 10:34:03 +0200 (CEST) Final-Recipient: rfc822; bddinechin@kalray.eu Original-Recipient: rfc822;benoit.dinechin@kalray.eu Action: failed Status: 4.2.2 Remote-MTA: dns; zimbra2.kalray.eu Diagnostic-Code: smtp; 452 4.2.2 Over quota --721B127E0334.1629190152/zimbra2.kalray.eu Content-Description: Undelivered Message Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from localhost (localhost [127.0.0.1]) by zimbra2.kalray.eu (Postfix) with ESMTP id 721B127E0334 for ; Thu, 12 Aug 2021 10:34:03 +0200 (CEST) Authentication-Results: zimbra2.kalray.eu (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=gcc.gnu.org Received: from zimbra2.kalray.eu ([127.0.0.1]) by localhost (zimbra2.kalray.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9cglFUStgdl for ; Thu, 12 Aug 2021 10:34:03 +0200 (CEST) Received: from fx303.security-mail.net (mxout.security-mail.net [85.31.212.46]) by zimbra2.kalray.eu (Postfix) with ESMTPS id 3FDF927E0310 for ; Thu, 12 Aug 2021 10:34:03 +0200 (CEST) Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) by fx303.security-mail.net (Postfix) with ESMTPS id D6FA71C31C4 for ; Thu, 12 Aug 2021 10:33:53 +0200 (CEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 43604383303B for ; Thu, 12 Aug 2021 08:33:52 +0000 (GMT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id 83401386F832 for ; Thu, 12 Aug 2021 08:33:31 +0000 (GMT) Received: by mail-ed1-x533.google.com with SMTP id q3so4331380edt.5 for ; Thu, 12 Aug 2021 01:33:31 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: E-securemail, by Secumail X-Spam-Status: No, score=-1.939 tagged_above=-1000 required=7.5 tests=[AB_ENVFROM_LONG_40=0.5, AB_FAKE_WORD_1=0.2, AB_IN_REPLY_TO_EXISTS=-1, AB_LONG_SUBJ_30=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-1, DKIM_VALID_AU=-0.1, FAKE_REPLY_SURE_A=1, FAKE_REPLY_SURE_B=1, FSL_RCVD_EX_3=0.01, FSL_RCVD_UT_3=0.01, HEAD_NEWS=-0.5, MISSING_MID=0.14, MM_ENVFROM_BOUNCE=1, RCVD_IN_DNSWL_MED=-1.3, S_FROM_GREY_MINUS_2=-2] autolearn=disabled Authentication-Results: fx303.security-mail.net (amavisd-new); dkim=pass (1024-bit key) header.d=gcc.gnu.org Secumail-id: <19a2.6114dcf1.8d89e.0> DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 43604383303B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1628757232; bh=2DYulImSwtWGcn8fiPUh/ljL3EpztEkZPeM950vErhA=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=n3hShyuxHBv4SHIJ0+Itr9oDnFjUoAceR5vabu9B6gLIf8qR+PRetF8ZTf9+YJ4LY yraUqFCTPY6J6YCXbzGLJtFz7GjolTPAL3gyIzzRWtQMprmM2ywxDS/lAdVsWpwhDK mX9gwMuCfe/AOMPSop7FD/QU0XQbIkwPs7Cc7tgM= X-Original-To: gcc@gcc.gnu.org Delivered-To: gcc@gcc.gnu.org DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 83401386F832 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2DYulImSwtWGcn8fiPUh/ljL3EpztEkZPeM950vErhA=; b=X50Syv8k/9H4EY+mAswCjuga6EgbZLxenj6eiiCz/4GmAYiceHoHKuVTtyYYwo/olN 59WUbZMGnHnM0SCOauCzoZOEFUr6+srjvc7Ai/qTedzbIaiHgpy57NrDki2cG43jcNMm OS0QkKr6UMixPrTk35oV2YplYjCNa9mOubVzM+tPxt8TarOFxda/sc3TLOZrR/PQDO5n YZ1TQ9rsB+BgGnFWThID3lXxDreC0ZM+iT+z3jiFdz6kmM5FQhWHtfI23IOaaLg8vtDq 7ED7Gx07YmA8CSo5ry6uz4rgD752VJfFiNMfzZP7vwkPhaE0nXqIx7/unVvaSXN1q4sZ TCGw== X-Gm-Message-State: AOAM530BFP2F2YLKWz6Dj1pYF/hV2Kid5mVbN/6NNoZVjAl98KjU7v38 oLSJKL94vg4GRWg+xAqD9aCvmIK+4Ua/kM4R6ABMYw== X-Google-Smtp-Source: ABdhPJwWO2YR9hsl29ichFx+bBPgxIfYkfV/T4fgTCtj4+fUuCLHVfJyO1OgxDoOfmaTyjuN7raRMhKvNSFVzRX/rpw= X-Received: by 2002:a50:d795:: with SMTP id w21mr4204075edi.112.1628757210446; Thu, 12 Aug 2021 01:33:30 -0700 (PDT) MIME-Version: 1.0 References: <9587be75-ec2a-a997-3074-1811228245d3@gmail.com> <0cf362fc-328f-5256-d289-e6b6fda838cd@gmail.com> <62f7087a-8adf-0a83-1fdf-d24ac49d04d2@foss.arm.com> <034b8502-73ba-205b-b267-236688df2709@gmail.com> In-Reply-To: <034b8502-73ba-205b-b267-236688df2709@gmail.com> Date: Thu, 12 Aug 2021 14:02:52 +0530 Message-ID: Subject: Re: [RFC] Adding a new attribute to function param to mark it as constant To: Martin Sebor X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Prathamesh Kulkarni via Gcc Reply-To: Prathamesh Kulkarni Cc: GCC Development , Richard Earnshaw Errors-To: gcc-bounces+benoit.dinechin=kalray.eu@gcc.gnu.org Sender: Gcc X-ALTERMIMEV2_in: done Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On Sat, 7 Aug 2021 at 02:09, Martin Sebor wrote: > > On 8/6/21 4:51 AM, Richard Earnshaw wrote: > > > > > > On 06/08/2021 01:06, Martin Sebor via Gcc wrote: > >> On 8/4/21 3:46 AM, Richard Earnshaw wrote: > >>> > >>> > >>> On 03/08/2021 18:44, Martin Sebor wrote: > >>>> On 8/3/21 4:11 AM, Prathamesh Kulkarni via Gcc wrote: > >>>>> On Tue, 27 Jul 2021 at 13:49, Richard Biener > >>>>> wrote: > >>>>>> > >>>>>> On Mon, Jul 26, 2021 at 11:06 AM Prathamesh Kulkarni via Gcc > >>>>>> wrote: > >>>>>>> > >>>>>>> On Fri, 23 Jul 2021 at 23:29, Andrew Pinski > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> On Fri, Jul 23, 2021 at 3:55 AM Prathamesh Kulkarni via Gcc > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> Continuing from this thread, > >>>>>>>>> https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575920.html > >>>>>>>>> The proposal is to provide a mechanism to mark a parameter in a > >>>>>>>>> function as a literal constant. > >>>>>>>>> > >>>>>>>>> Motivation: > >>>>>>>>> Consider the following intrinsic vshl_n_s32 from arrm/arm_neon.h: > >>>>>>>>> > >>>>>>>>> __extension__ extern __inline int32x2_t > >>>>>>>>> __attribute__ ((__always_inline__, __gnu_inline__, > >>>>>>>>> __artificial__)) > >>>>>>>>> vshl_n_s32 (int32x2_t __a, const int __b) > >>>>>>>>> { > >>>>>>>>> return (int32x2_t)__builtin_neon_vshl_nv2si (__a, __b); > >>>>>>>>> } > >>>>>>>>> > >>>>>>>>> and it's caller: > >>>>>>>>> > >>>>>>>>> int32x2_t f (int32x2_t x) > >>>>>>>>> { > >>>>>>>>> return vshl_n_s32 (x, 1); > >>>>>>>>> } > >>>>>>>> > >>>>>>>> Can't you do similar to what is done already in the aarch64 > >>>>>>>> back-end: > >>>>>>>> #define __AARCH64_NUM_LANES(__v) (sizeof (__v) / sizeof (__v[0])) > >>>>>>>> #define __AARCH64_LANE_CHECK(__vec, __idx) \ > >>>>>>>> __builtin_aarch64_im_lane_boundsi (sizeof(__vec), > >>>>>>>> sizeof(__vec[0]), __idx) > >>>>>>>> > >>>>>>>> ? > >>>>>>>> Yes this is about lanes but you could even add one for min/max > >>>>>>>> which > >>>>>>>> is generic and such; add an argument to say the intrinsics name > >>>>>>>> even. > >>>>>>>> You could do this as a non-target builtin if you want and reuse it > >>>>>>>> also for the aarch64 backend. > >>>>>>> Hi Andrew, > >>>>>>> Thanks for the suggestions. IIUC, we could use this approach to > >>>>>>> check > >>>>>>> if the argument > >>>>>>> falls within a certain range (min / max), but I am not sure how it > >>>>>>> will help to determine > >>>>>>> if the arg is a constant immediate ? AFAIK, vshl_n intrinsics > >>>>>>> require > >>>>>>> that the 2nd arg is immediate ? > >>>>>>> > >>>>>>> Even the current RTL builtin checking is not consistent across > >>>>>>> optimization levels: > >>>>>>> For eg: > >>>>>>> int32x2_t f(int32_t *restrict a) > >>>>>>> { > >>>>>>> int32x2_t v = vld1_s32 (a); > >>>>>>> int b = 2; > >>>>>>> return vshl_n_s32 (v, b); > >>>>>>> } > >>>>>>> > >>>>>>> With pristine trunk, compiling with -O2 results in no errors because > >>>>>>> constant propagation replaces 'b' with 2, and during expansion, > >>>>>>> expand_builtin_args is happy. But at -O0, it results in the error - > >>>>>>> "argument 2 must be a constant immediate". > >>>>>>> > >>>>>>> So I guess we need some mechanism to mark a parameter as a > >>>>>>> constant ? > >>>>>> > >>>>>> I guess you want to mark it in a way that the frontend should force > >>>>>> constant evaluation and error if that's not possible? C++ doesn't > >>>>>> allow to declare a parameter as 'constexpr' but something like > >>>>>> > >>>>>> void foo (consteval int i); > >>>>>> > >>>>>> since I guess you do want to allow passing constexpr arguments > >>>>>> in C++ or in C extended forms of constants like > >>>>>> > >>>>>> static const int a[4]; > >>>>>> > >>>>>> foo (a[1]); > >>>>>> > >>>>>> ? But yes, this looks useful to me. > >>>>> Hi Richard, > >>>>> Thanks for the suggestions and sorry for late response. > >>>>> I have attached a prototype patch that implements consteval attribute. > >>>>> As implemented, the attribute takes at least one argument(s), which > >>>>> refer to parameter position, > >>>>> and the corresponding parameter must be const qualified, failing > >>>>> which, the attribute is ignored. > >>>> > >>>> I'm curious why the argument must be const-qualified. If it's > >>>> to keep it from being changed in ways that would prevent it from > >>>> being evaluated at compile-time in the body of the function then > >>>> to be effective, the enforcement of the constraint should be on > >>>> the definition of the function. Otherwise, the const qualifier > >>>> could be used in a declaration of a function but left out from > >>>> a subsequent definition of it, letting it modify it, like so: > >>>> > >>>> __attribute__ ((consteval (1))) void f (const int); > >>>> > >>>> inline __attribute__ ((always_inline)) void f (int i) { ++i; } > >>> > >>> In this particular case it's because the inline function is > >>> implementing an intrinsic operation in the architecture and the > >>> instruction only supports a literal constant value. At present we > >>> catch this while trying to expand the intrinsic, but that can lead to > >>> poor diagnostics because we really want to report against the line of > >>> code calling the intrinsic. > >> > >> Presumably the intrinsics can accept (or can be made to accept) any > >> constant integer expressions, not just literals. E.g., the aarch64 > >> builtin below accepts them. For example, this is accepted in C++: > >> > >> __Int64x2_t void f (__Int32x2_t a) > >> { > >> constexpr int n = 2; > >> return __builtin_aarch64_vshll_nv2si (a, n + 1); > >> } > >> > >> Making the intrinscis accept constant arguments in constexpr-like > >> functions and introducing a constexpr-lite attribute (for C code) > >> was what I was suggesting bythe constexpr comment below. I'd find > >> that a much more general and more powerful design. > >> > > > > Yes, it would be unfortunate if the rule made it impossible to avoid > > idiomatic const-exprs like those you would write in C++, or even those > > you'd write naturally in C: > > > > #define foo (1u << 5) > > > > > >> But my comment above was to highlight that if requiring the function > >> argument referenced by the proposed consteval attribute to be const > >> is necessary to prevent it from being modified then the requirement > >> needs to be enforced not on the declaration but on the definition. > >> > >> You may rightly say: "but we get to define the inline arm function > >> wrappers so we'll make sure to never declare them that way." I don't > >> have a problem with that. What I am saying is that a consteval > >> attribute that required the function argument to be declared const > >> to be effective would be flawed as a general-purpose feature without > >> enforcing the requirement on the definition. > > > > I'm not totally sure I understand what you're saying. But the point of > > putting the attribute on the declaration is to allow for reporting > > errors at the point of invocation, so if I call a function with an > > invalid 'must-be-const-expr' value, I'll get a diagnostic at the point > > in the source where that is done, not at the point in the (presumably > > inlined) function where the value ends up being used. Most of our > > builtins are wrapped into slightly more user-friendly function names so > > that they conform to the ACLE specification, yet ultimately map onto > > names into __builtin namespace per gcc's internal standards. If I have: > > > > __extension__ extern __inline int8x8_t > > __attribute__ ((__always_inline__, __gnu_inline__, __artificial__)) > > vshr_n_s8 (int8x8_t __a, const int __b) > > { > > return (int8x8_t)__builtin_neon_vshrs_nv8qi (__a, __b); > > } > > > > > > and then use that with > > > > extern int8x8_t x; > > extern int y; > > > > f() { > > int8x8_t z = vshr_n_s8 (x, y); // Error y must be a const int expr. > > ... > > } > > > > I want the error to be reported on the line in f() where the problem > > really lies, not on the line in the inline function where the problem > > eventually manifests itself. > > Yes, I understand that. What I'm pointing out is that > the description of the attribute above > > "the attribute takes at least one argument(s), which refer to > parameter position, and the corresponding parameter must be const > qualified, failing which, the attribute is ignored." > > doesn't match the POC patch because it silently accepts the following > two declarations: > > int __attribute__ ((consteval (1))) > f (const int); // attribute consteval accepted... > > int f (int a) // ...even though the argument is not const > { > return ++a; > } > > The attribute handler should check that the const qualifier on > the argument is in the definition of the function. > > I'm also pointing out that from the POV of the user of the attribute, > the const shouldn't be necessary: the attribute consteval alone should > be sufficient. Hence my original question: why must the argument be > const-qualified? (Why can't you print equally good error messages > without it?) Hi Martin, While writing the POC patch, my expectation was to treat consteval param as a more "restricted version" of const param -- in addition to being readonly, it should only be passed compile-time constant values, and so I thought it probably made sense to require it to be const qualified. But if that doesn't seem like a good idea, we can drop it to be const qualified. I was wondering how do we take this forward ? For a start would this be OK ? 1] Since we also need range info, define consteval attribute to take 3 arguments -- param-pos, min-val, max-val. and requiring the parameter to be an integral type (unlike the one implemented in POC patch). 2] Diagnose a function call, if the corresponding argument (after invoking c_fully_fold) is not INTEGER_CST. My intent is to currently accept ICE's that are also acceptable in other language features like case statement. As you suggest above, we could add "constexpr-lite" attribute to C, for accepting more complicated integral constant expressions, that can also be used in other language features that need ICE's. My concern with this approach tho, is that currently we accept ICE's for intrinsics and rely on the optimizer to resolve them into constants before expansion. So code that passes ICE to vshl_n, would get compiled at higher optimization levels but fail to compile with -O0. I am wondering if there's any existing code that relies on this behavior and will fail to compile if we impose the above restriction ? Thanks, Prathamesh > > Martin > > > > > R. > > > >> > >> Martin > >> > >> > >>> > >>> R. > >>>> > >>>> That said, if compile-time function evaluation is the goal then > >>>> a fully general solution is an attribute that applies to the whole > >>>> function, not just a subset of its arguments. That way arguments > >>>> can also be assigned to local variables within the function that > >>>> can then be modified while still evaluated at compile time and > >>>> used where constant expressions are expected. I.e., the design > >>>> goal is [a subset of] C++ constexpr. (Obviously a much bigger > >>>> project.) > >>>> > >>>> A few notes on the prototype patch: conventionally GCC warnings > >>>> about attributes do not mention when an attribute is ignored. > >>>> It may be a nice touch to add to all of them but I'd recommend > >>>> against doing that in individual handlers. Since the attribute > >>>> allows pointer constants the warning issued when an argument is > >>>> not one should be generalized (i.e., not refer to just integer > >>>> constants). > >>>> > >>>> (Other than that, C/C++ warnings should start in lowercase and > >>>> not end in a period). > >>>> > >>>> Martin > >>>> > >>>>> > >>>>> The patch does type-checking for arguments in > >>>>> check_function_consteval_attr, which > >>>>> simply does a linear search to see if the corresponding argument > >>>>> number is included in consteval attribute, > >>>>> and if yes, it checks if the argument is CONSTANT_CLASS_P. > >>>>> > >>>>> This works for simple constants and the intrinsics use-case, but > >>>>> rejects "extended constants" as in your above example. > >>>>> I guess we can special case to detect cases like a[i] where 'a' is > >>>>> const and 'i' is an immediate, > >>>>> but I am not sure if there's a way to force constant evaluation in > >>>>> FE ? > >>>>> I tried using c_fully_fold (argarray[i], false, &maybe_const) but that > >>>>> didn't seem to work. > >>>>> Do you have any suggestions on how to detect those in the front-end ? > >>>>> > >>>>> Example: > >>>>> > >>>>> __attribute__((consteval(1, 2))) > >>>>> void f(const int x, int *p) > >>>>> {} > >>>>> > >>>>> Calling it with: > >>>>> 1) f(0, (int *) 0) is accepted. > >>>>> > >>>>> 2) > >>>>> void g(int *p) > >>>>> { > >>>>> f (0, p); > >>>>> } > >>>>> > >>>>> emits the following error: > >>>>> test.c: In function ‘g’: > >>>>> test.c:7:9: error: argument 2 is not a constant. > >>>>> 7 | f (0, p); > >>>>> | ^ > >>>>> test.c:2:6: note: Function ‘f’ has parameter 2 with consteval > >>>>> attribute. > >>>>> 2 | void f(const int x, int *const p) > >>>>> | ^ > >>>>> > >>>>> Thanks, > >>>>> Prathamesh > >>>>>> > >>>>>> Richard. > >>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Prathamesh > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Andrew Pinski > >>>>>>>> > >>>>>>>>> > >>>>>>>>> The constraint here is that, vshl_n intrinsics require > >>>>>>>>> that the > >>>>>>>>> second arg (__b), > >>>>>>>>> should be an immediate value. > >>>>>>>>> Currently, this check is performed by arm_expand_builtin_args, > >>>>>>>>> and if > >>>>>>>>> a non-constant > >>>>>>>>> value gets passed, it emits the following diagnostic: > >>>>>>>>> > >>>>>>>>> ../armhf-build/gcc/include/arm_neon.h:4904:10: error: argument > >>>>>>>>> 2 must > >>>>>>>>> be a constant immediate > >>>>>>>>> 4904 | return (int32x2_t)__builtin_neon_vshl_nv2si (__a, __b); > >>>>>>>>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>>>>>>>> > >>>>>>>>> However, we're trying to replace builtin calls with gcc's C vector > >>>>>>>>> extensions where > >>>>>>>>> possible (PR66791), because the builtins are opaque to the > >>>>>>>>> optimizers. > >>>>>>>>> > >>>>>>>>> Unfortunately, we lose type checking of immediate value if we > >>>>>>>>> replace > >>>>>>>>> the builtin > >>>>>>>>> with << operator: > >>>>>>>>> > >>>>>>>>> __extension__ extern __inline int32x2_t > >>>>>>>>> __attribute__ ((__always_inline__, __gnu_inline__, > >>>>>>>>> __artificial__)) > >>>>>>>>> vshl_n_s32 (int32x2_t __a, const int __b) > >>>>>>>>> { > >>>>>>>>> return __a << __b; > >>>>>>>>> } > >>>>>>>>> > >>>>>>>>> So, I was wondering if we should have an attribute for a > >>>>>>>>> parameter to > >>>>>>>>> specifically > >>>>>>>>> mark it as a constant value with optional range value info ? > >>>>>>>>> As Richard suggested, sth like: > >>>>>>>>> void foo(int x __attribute__((literal_constant (min_val, > >>>>>>>>> max_val))); > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Prathamesh > >>>> > >> > To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=19a2.6114dcf1.8d89e.0&r=benoit.dinechin%40kalray.eu&s=gcc-bounces%2Bbenoit.dinechin%3Dkalray.eu%40gcc.gnu.org&o=Re%3A+%5BRFC%5D+Adding+a+new+attribute+to+function+param+to+mark+it+as+constant&verdict=C&c=eabda35c404057d7d9e227346ab9ac6da16ad5ce --721B127E0334.1629190152/zimbra2.kalray.eu--