Re: gcc_assert() and inhibit_libc
On 16/08/2021 18:50, Jason Merrill wrote: On Mon, Aug 16, 2021 at 9:51 AM Sebastian Huber wrote: On 16/08/2021 14:33, Martin Liška wrote: On 8/12/21 4:31 PM, Sebastian Huber wrote: This would be suitable for me, however, I am not sure if you want such a customization feature just for a niche operating system. I don't see a reason why not. Please send a patch. Ok, good. I will try to figure out what can be done. One problem is that tsystem.h is included before tm.h. Independent of this Joseph S. Myers said in the recent patch review with respect to the gcov_type size that removing tm.h from the target libraries is a development goal. I guess we have a couple of options. 1. Detect the presence of __assert_func and add the result to tconfig.h. This can't be a link time check, since libgcc is build before Newlib. 2. Use __builtin_trap() instead of abort() if inhibit_libc is defined. I still think this seems the most straightforward approach. I sent a patch for this: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577544.html -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Undelivered Mail Returned to Sender
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)
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
--- Begin Message ---
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 corr
Re: Expensive selftests (was: 'hash_map>')
On Tue, Aug 17, 2021 at 8:40 AM Thomas Schwinge wrote: > > Hi! > > On 2021-08-16T14:10:00-0600, Martin Sebor wrote: > > On 8/16/21 6:44 AM, Thomas Schwinge wrote: > >> [...], to document the current behavior, I propose to > >> "Add more self-tests for 'hash_map' with Value type with non-trivial > >> constructor/destructor", see attached. OK to push to master branch? > >> (Also cherry-pick into release branches, eventually?) > > (Attached again, for easy reference.) > > > Adding more tests sounds like an excellent idea. I'm not sure about > > the idea of adding loopy selftests that iterate as many times as in > > the patch (looks like 1234 times two?) > > Correct, and I agree it's a sensible concern, generally. > > The current 1234 times two iterations is really arbitrary (should > document that in the test case), just so that we trigger a few hash table > expansions. You could lower N_init (the default init is just 13!), even with just 128 inserted elements you'll trigger expansions to 31, 61 and 127 elements. > For 'selftest-c', we've got originally: > > -fself-test: 74775 pass(es) in 0.309299 seconds > -fself-test: 74775 pass(es) in 0.366041 seconds > -fself-test: 74775 pass(es) in 0.356663 seconds > -fself-test: 74775 pass(es) in 0.355009 seconds > -fself-test: 74775 pass(es) in 0.367575 seconds > -fself-test: 74775 pass(es) in 0.320406 seconds > > ..., and with my changes we've got: > > -fself-test: 94519 pass(es) in 0.327755 seconds > -fself-test: 94519 pass(es) in 0.369522 seconds > -fself-test: 94519 pass(es) in 0.355531 seconds > -fself-test: 94519 pass(es) in 0.362179 seconds > -fself-test: 94519 pass(es) in 0.363176 seconds > -fself-test: 94519 pass(es) in 0.318930 seconds > > So it really seems to be all in the noise? Yes. I think the test is OK but it's also reasonable to lower the '1234' times and add a comment as to the count should trigger hashtable expansions "a few times". Richard. > Yet: > > > Selftests run each time GCC > > builds (i.e., even during day to day development). It seems to me > > that it might be better to run such selftests only as part of > > the bootstrap process. > > I'd rather have thought about a '--param self-test-expensive' (or > similar), and then invoke the selftests via a new > 'gcc/testsuite/selftests/expensive.exp' (or similar). > > Or, adapt 'gcc/testsuite/gcc.dg/plugin/expensive_selftests_plugin.c', > that is, invoke them via the GCC plugin mechanism, which also seems to be > easy enough? > > I don't have a strong opinion about where/when these tests get run, so > will happily take any suggestions. > > > Grüße > Thomas > > > - > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 > München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas > Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht > München, HRB 106955
Undelivered Mail Returned to Sender
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) Reporting-MTA: dns; zimbra2.kalray.eu X-Postfix-Queue-ID: 74F4327E036A X-Postfix-Sender: rfc822; gcc@gcc.gnu.org Arrival-Date: Thu, 12 Aug 2021 11:37:47 +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 --- Begin Message --- Hello, I hope things have been awesome! I’m jotting you a quick note to let you know that I’m currently searching for a new career opportunity in Computing Network. For a greater understanding of my professional qualifications, you can find my resume attached to this email. If you hear of anything within your own network that you think might fit the bill, I’d so appreciate if you could send a heads up my way. Let me know if I can ever return the favor. I’m happy to do so! Thanks, To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=e713.6114ebe9.49fce.0&r=benoit.dinechin%40kalray.eu&s=gcc-bounces%2Bbenoit.dinechin%3Dkalray.eu%40gcc.gnu.org&o=Looking+for+a+new+opportunity&verdict=C&c=0bad81bf08e4af905acee02a3e6186e86538b295--- End Message ---
Undelivered Mail Returned to Sender
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) Reporting-MTA: dns; zimbra2.kalray.eu X-Postfix-Queue-ID: 6FFA727E03D4 X-Postfix-Sender: rfc822; gcc@gcc.gnu.org Arrival-Date: Thu, 12 Aug 2021 16:32:39 +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 --- Begin Message --- On Thu, Jul 22, 2021 at 8:18 AM Richard Biener via Gcc wrote: > > On Wed, Jul 21, 2021 at 2:45 PM Sebastian Huber > wrote: > > > > Hello, > > > > while testing this patch > > > > https://www.google.com/search?client=firefox-b-e&q=gcc+enable_runtime_checking > > > > I noticed that __gcov_info_to_gcda() uses abort(). This is due to (from > > tsystem.h): > > > > #ifdef ENABLE_RUNTIME_CHECKING > > #define gcc_assert(EXPR) ((void)(!(EXPR) ? abort (), 0 : 0)) > > #else > > /* Include EXPR, so that unused variable warnings do not occur. */ > > #define gcc_assert(EXPR) ((void)(0 && (EXPR))) > > #endif > > > > In tsystem.h there is this if inhibit_libc is defined: > > > > #ifndef abort > > extern void abort (void) __attribute__ ((__noreturn__)); > > #endif > > > > Who is supposed to define abort here optionally? Can this be defined for > > example by a target configuration header like gcc/config/rtems.h? > > I suppose for inhibit_libc we could use __builtin_trap () (but that might > expand to abort() on some targets) That seems straightforward. Does it address the RTEMS concern? Or, should we suppress ENABLE_RUNTIME_CHECKING when inhibit_libc? Jason To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=629.611530ee.bd5d9.0&r=benoit.dinechin%40kalray.eu&s=gcc-bounces%2Bbenoit.dinechin%3Dkalray.eu%40gcc.gnu.org&o=Re%3A+gcc_assert%28%29+and+inhibit_libc&verdict=C&c=5e42cf8986f6885541f2b3b3f344e42ce71e6acd --- End Message ---
Re: Expensive selftests
On 8/17/21 12:40 AM, Thomas Schwinge wrote: Hi! On 2021-08-16T14:10:00-0600, Martin Sebor wrote: On 8/16/21 6:44 AM, Thomas Schwinge wrote: [...], to document the current behavior, I propose to "Add more self-tests for 'hash_map' with Value type with non-trivial constructor/destructor", see attached. OK to push to master branch? (Also cherry-pick into release branches, eventually?) (Attached again, for easy reference.) Adding more tests sounds like an excellent idea. I'm not sure about the idea of adding loopy selftests that iterate as many times as in the patch (looks like 1234 times two?) Correct, and I agree it's a sensible concern, generally. The current 1234 times two iterations is really arbitrary (should document that in the test case), just so that we trigger a few hash table expansions. For 'selftest-c', we've got originally: -fself-test: 74775 pass(es) in 0.309299 seconds -fself-test: 74775 pass(es) in 0.366041 seconds -fself-test: 74775 pass(es) in 0.356663 seconds -fself-test: 74775 pass(es) in 0.355009 seconds -fself-test: 74775 pass(es) in 0.367575 seconds -fself-test: 74775 pass(es) in 0.320406 seconds ..., and with my changes we've got: -fself-test: 94519 pass(es) in 0.327755 seconds -fself-test: 94519 pass(es) in 0.369522 seconds -fself-test: 94519 pass(es) in 0.355531 seconds -fself-test: 94519 pass(es) in 0.362179 seconds -fself-test: 94519 pass(es) in 0.363176 seconds -fself-test: 94519 pass(es) in 0.318930 seconds So it really seems to be all in the noise? Yet: Selftests run each time GCC builds (i.e., even during day to day development). It seems to me that it might be better to run such selftests only as part of the bootstrap process. I'd rather have thought about a '--param self-test-expensive' (or similar), and then invoke the selftests via a new 'gcc/testsuite/selftests/expensive.exp' (or similar). Or, adapt 'gcc/testsuite/gcc.dg/plugin/expensive_selftests_plugin.c', that is, invoke them via the GCC plugin mechanism, which also seems to be easy enough? I don't have a strong opinion about where/when these tests get run, so will happily take any suggestions. I think the right design is to move all these basic building blocks (at a minimum, all containers, but ultimately even higher level general-purpose APIs) into a standalone library with its own unit tests run independently of GCC. I'm fine with adding these tests if no one else is concerned about the overhead, especially with a lower number of iterations like Richard suggests (as long as it still exercises the expansion, of course). Thanks Martin Grüße Thomas - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Undelivered Mail Returned to Sender
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) Reporting-MTA: dns; zimbra2.kalray.eu X-Postfix-Queue-ID: F20BB27E041C X-Postfix-Sender: rfc822; gcc@gcc.gnu.org Arrival-Date: Fri, 13 Aug 2021 00:37:30 +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 --- Begin Message --- Snapshot gcc-9-20210812 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20210812/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision fe8c4e2be9856a331b2f64f869991e673e6fed0f You'll find: gcc-9-20210812.tar.xzComplete GCC SHA256=ff93938d8e794bb85052c3753c00274f3bfe4d7d9378b119fb01aa057b31eb10 SHA1=a1c8674cdaad61c027fac7a9bcc33e366963647f Diffs from 9-20210805 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way. To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=161db.6115a2a9.25c60.0&r=benoit.dinechin%40kalray.eu&s=gcc-bounces%2Bbenoit.dinechin%3Dkalray.eu%40gcc.gnu.org&o=gcc-9-20210812+is+now+available&verdict=C&c=77ba598c9cf43ed0161c6767c0e20f682cbb2112 --- End Message ---
Undelivered Mail Returned to Sender
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)
Reporting-MTA: dns; zimbra2.kalray.eu
X-Postfix-Queue-ID: 513B827E041D
X-Postfix-Sender: rfc822; gcc@gcc.gnu.org
Arrival-Date: Fri, 13 Aug 2021 01:16: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
--- Begin Message ---
On 8/6/21 10:57 AM, Thomas Schwinge wrote:
Hi!
So I'm trying to do some C++... ;-)
Given:
/* A map from SSA names or var decls to record fields. */
typedef hash_map field_map_t;
/* For each propagation record type, this is a map from SSA names or var
decls
to propagate, to the field in the record type that should be used for
transmission and reception. */
typedef hash_map record_field_map_t;
Thus, that's a 'hash_map>'. (I may do that,
right?) Looking through GCC implementation files, very most of all uses
of 'hash_map' boil down to pointer key ('tree', for example) and
pointer/integer value.
Right. Because most GCC containers rely exclusively on GCC's own
uses for testing, if your use case is novel in some way, chances
are it might not work as intended in all circumstances.
I've wrestled with hash_map a number of times. A use case that's
close to yours (i.e., a non-trivial value type) is in cp/parser.c:
see class_to_loc_map_t. (I don't remember if I tested it for leaks
though. It's used to implement -Wmismatched-tags so compiling
a few tests under Valgrind should show if it does leak.)
Then:
record_field_map_t field_map ([...]); // see below
for ([...])
{
tree record_type = [...];
[...]
bool existed;
field_map_t &fields
= field_map.get_or_insert (record_type, &existed);
gcc_checking_assert (!existed);
[...]
for ([...])
fields.put ([...], [...]);
[...]
}
[stuff that looks up elements from 'field_map']
field_map.empty ();
This generally works.
If I instantiate 'record_field_map_t field_map (40);', Valgrind is happy.
If however I instantiate 'record_field_map_t field_map (13);' (where '13'
would be the default for 'hash_map'), Valgrind complains:
2,080 bytes in 10 blocks are definitely lost in loss record 828 of 876
at 0x483DD99: calloc (vg_replace_malloc.c:762)
by 0x175F010: xcalloc (xmalloc.c:162)
by 0xAF4A2C: hash_table, tree_node*> >::hash_entry, false,
xcallocator>::hash_table(unsigned long, bool, bool, bool, mem_alloc_origin) (hash-table.h:275)
by 0x15E0120: hash_map, tree_node*>
>::hash_map(unsigned long, bool, bool, bool) (hash-map.h:143)
by 0x15DEE87: hash_map, tree_node*> >,
simple_hashmap_traits, hash_map, tree_node*> > > >::get_or_insert(tree_node* const&,
bool*) (hash-map.h:205)
by 0x15DD52C: execute_omp_oacc_neuter_broadcast()
(omp-oacc-neuter-broadcast.cc:1371)
[...]
(That's with '#pragma GCC optimize "O0"' at the top of the 'gcc/*.cc'
file.)
My suspicion was that it is due to the 'field_map' getting resized as it
incrementally grows (and '40' being big enough for that to never happen),
and somehow the non-POD (?) value objects not being properly handled
during that. Working my way a bit through 'gcc/hash-map.*' and
'gcc/hash-table.*' (but not claiming that I understand all that, off
hand), it seems as if my theory is right: I'm able to plug this memory
leak as follows:
--- gcc/hash-table.h
+++ gcc/hash-table.h
@@ -820,6 +820,8 @@ hash_table::expand ()
{
value_type *q = find_empty_slot_for_expand (Descriptor::hash
(x));
new ((void*) q) value_type (std::move (x));
+ //BAD Descriptor::remove (x); // (doesn't make sense and) a ton of
"Invalid read [...] inside a block of size [...] free'd"
+ x.~value_type (); //GOOD This seems to work! -- but does it make
sense?
}
p++;
However, that doesn't exactly look like a correct fix, does it? I'd
expect such a manual destructor call in combination with placement new
(that is being used here, obviously) -- but this is after 'std::move'?
However, this also survives a smoke-test-like run of parts of the GCC
testsuite, bootstrap and complete run now ongoing.
If explicitly calling the dtor on the moved object is the right thing
to do I'd expect to see such invocations elsewhere in hash_table but
I don't. It does seem like removed e
Re: [RFC] Adding a new attribute to function param to mark it as constant
On Fri, 13 Aug 2021 at 22:44, Martin Sebor wrote:
>
> On 8/12/21 2:32 AM, Prathamesh Kulkarni wrote:
> > 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 s
