Undelivered Mail Returned to Sender

Undelivered Mail Returned to Sender

[MAILER-DAEMON]

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 601 bytes --]

This is the mail system at host fx301.security-mail.net.

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

<marc.poulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550
    5.1.1 <marc.poulhies@kalray.eu>: Recipient address rejected: User unknown
    in virtual mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 467 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 8197 bytes --]

From: Jack moov via Gcc <gcc@gcc.gnu.org>
To: gcc@gcc.gnu.org
Subject: Re: Cost
Date: Tue, 10 Aug 2021 16:34:47 +0530
Message-ID: <AM9P190MB1570DEEF45FF6369968AE26BD5F79@AM9P190MB1570.EURP190.PROD.OUTLOOK.COM>

Hello, Gcc

We are a Mobile app development company. Would you be interested to develop
an App?

We can make any kind of app like:

.         Taxi App

.         Food App

.         Fitness App

.         Dating App

.         Music App

.         Travel App

.         Games App

.         Business App

.         Educational App

.         Web App

.         Hybrid App

PS: If you are interested, then I can send you our past work details,
company information and an affordable quotation with the best offer.

Thanks & Regards,

Jack moov



To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=11651.61125e17.43212.0&r=marc.poulhies%40kalray.eu&s=gcc-bounces%2Bmarc.poulhies%3Dkalray.eu%40gcc.gnu.org&o=Re%3A+Cost&verdict=C&c=a2fb39fb812d3c8a2dc44758c352731299e9bce3

Undelivered Mail Returned to Sender

[Mail Delivery System]

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 521 bytes --]

This is the mail system at host hwsrv-901157.hostwindsdns.com.

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

<gcc@gcc.gnu.org>: host gcc.gnu.org[8.43.85.97] said: 550 5.7.1 Blocked by
    SpamAssassin (in reply to end of DATA command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 374 bytes --]

Undelivered Mail Returned to Sender

[Mail Delivery System]

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 539 bytes --]

This is the mail system at host hwsrv-901157.hostwindsdns.com.

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

<gcc@gcc.gnu.org>: host gcc.gnu.org[2620:52:3:1:0:246e:9693:128c] said: 550
    5.7.1 Blocked by SpamAssassin (in reply to end of DATA command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 374 bytes --]

Undelivered Mail Returned to Sender

[Mail Delivery System]

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 511 bytes --]

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

<bddinechin@kalray.eu>: host zimbra2.kalray.eu[192.168.40.202] said: 452 4.2.2
    Over quota (in reply to end of DATA command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 374 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 10964 bytes --]

From: Martin Sebor via Gcc <gcc@gcc.gnu.org>
To: Thomas Schwinge <thomas@codesourcery.com>, gcc@gcc.gnu.org
Subject: Re: 'hash_map<tree, hash_map<tree, tree>>'
Date: Thu, 12 Aug 2021 17:15:44 -0600
Message-ID: <af8fa221-b555-c192-bd99-6eb73db3935f@gmail.com>

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<tree, tree> 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<tree, field_map_t> record_field_map_t;
> 
> Thus, that's a 'hash_map<tree, hash_map<tree, tree>>'.  (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<hash_map<tree_node*, tree_node*, simple_hashmap_traits<default_hash_traits<tree_node*>, 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*, tree_node*, simple_hashmap_traits<default_hash_traits<tree_node*>, tree_node*> >::hash_map(unsigned long, bool, bool, bool) (hash-map.h:143)
>         by 0x15DEE87: hash_map<tree_node*, hash_map<tree_node*, tree_node*, simple_hashmap_traits<default_hash_traits<tree_node*>, tree_node*> >, simple_hashmap_traits<default_hash_traits<tree_node*>, hash_map<tree_node*, tree_node*, simple_hashmap_traits<default_hash_traits<tree_node*>, 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<Descriptor, Lazy, Allocator>::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 elements ought to be destroyed,
but it also seems like the destruction should go through some traits
class (e.g., call Descriptor::remove and mark_deleted or do some
similar dance), and be called from other member functions that move
elements.

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
> 



To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=9960.6115abaf.e5515.0&r=benoit.dinechin%40kalray.eu&s=gcc-bounces%2Bbenoit.dinechin%3Dkalray.eu%40gcc.gnu.org&o=Re%3A+%27hash_map%3Ctree%2C+hash_map%3Ctree%2C+tree%3E%3E%27&verdict=C&c=5ce25cdf0f1a5a418e600a7ee6f6fd6fdcca4695

Undelivered Mail Returned to Sender

[Mail Delivery System]

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 511 bytes --]

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

<bddinechin@kalray.eu>: host zimbra2.kalray.eu[192.168.40.202] said: 452 4.2.2
    Over quota (in reply to end of DATA command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 374 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 4612 bytes --]

From: GCC Administrator via Gcc <gcc@gcc.gnu.org>
To: gcc@gcc.gnu.org
Subject: gcc-9-20210812 is now available
Date: Thu, 12 Aug 2021 22:37:18 +0000
Message-ID: <20210812223718.B8759385501B@sourceware.org>

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.xz                Complete 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

Undelivered Mail Returned to Sender

[Mail Delivery System]

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 511 bytes --]

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

<bddinechin@kalray.eu>: host zimbra2.kalray.eu[192.168.40.202] said: 452 4.2.2
    Over quota (in reply to end of DATA command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 374 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 7186 bytes --]

From: Jason Merrill via Gcc <gcc@gcc.gnu.org>
To: Richard Biener <richard.guenther@gmail.com>
Cc: GCC Development <gcc@gcc.gnu.org>
Subject: Re: gcc_assert() and inhibit_libc
Date: Thu, 12 Aug 2021 10:31:44 -0400
Message-ID: <CADzB+2mw7XnC=A=y54yBFQwW-AOejyfvi4bekOyPNjvNeh1k1Q@mail.gmail.com>

On Thu, Jul 22, 2021 at 8:18 AM Richard Biener via Gcc <gcc@gcc.gnu.org> wrote:
>
> On Wed, Jul 21, 2021 at 2:45 PM Sebastian Huber
> <sebastian.huber@embedded-brains.de> 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

Undelivered Mail Returned to Sender

[Mail Delivery System]

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 511 bytes --]

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

<bddinechin@kalray.eu>: host zimbra2.kalray.eu[192.168.40.202] said: 452 4.2.2
    Over quota (in reply to end of DATA command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 374 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 5587 bytes --]

From: contact role via Gcc <gcc@gcc.gnu.org>
To: gcc@gcc.gnu.org
Subject: Looking for a new opportunity
Date: Thu, 12 Aug 2021 10:36:07 +0100
Message-ID: <CAATuuCrzjZ+=pmD-kj7GFqk5GQyWRLjvVmWHNuhFx+OvaYO9DQ@mail.gmail.com>

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

Undelivered Mail Returned to Sender

[Mail Delivery System]

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 511 bytes --]

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

<bddinechin@kalray.eu>: host zimbra2.kalray.eu[192.168.40.202] said: 452 4.2.2
    Over quota (in reply to end of DATA command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 374 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 21320 bytes --]

From: Prathamesh Kulkarni via Gcc <gcc@gcc.gnu.org>
To: Martin Sebor <msebor@gmail.com>
Cc: GCC Development <gcc@gcc.gnu.org>, Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
Subject: Re: [RFC] Adding a new attribute to function param to mark it as constant
Date: Thu, 12 Aug 2021 14:02:52 +0530
Message-ID: <CAAgBjMmLBZioui5tQR7Lmkhhxvwro2aAfVYMJSJ+4xHJepo2=g@mail.gmail.com>

On Sat, 7 Aug 2021 at 02:09, Martin Sebor <msebor@gmail.com> 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
> >>>>> <richard.guenther@gmail.com> wrote:
> >>>>>>
> >>>>>> On Mon, Jul 26, 2021 at 11:06 AM Prathamesh Kulkarni via Gcc
> >>>>>> <gcc@gcc.gnu.org> wrote:
> >>>>>>>
> >>>>>>> On Fri, 23 Jul 2021 at 23:29, Andrew Pinski <pinskia@gmail.com>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> On Fri, Jul 23, 2021 at 3:55 AM Prathamesh Kulkarni via Gcc
> >>>>>>>> <gcc@gcc.gnu.org> 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<type> 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

Re: Undelivered Mail Returned to Sender

[Jim Wilson]

Jim Wilson wrote:
> Gabriel Dos Reis wrote:
>> This is the fifth or so message from me, within the last few days,
>> that gets rejected.  What is up? 
> Hmm, I don't see this in the overseers archive.

Because it is sourceware.org not sourceware.com.  I should have noticed 
that before I made the same mistake.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: Undelivered Mail Returned to Sender

[Jim Wilson]

Gabriel Dos Reis wrote:
> This is the fifth or so message from me, within the last few days,
> that gets rejected.  What is up? 

Hmm, I don't see this in the overseers archive.  I don't think it 
reached them.  Maybe it triggered the spam filter for having too many 
capital letters in the subject line.

Anyways, the overseers aren't sure what the problem is, but they are 
testing a newer version of the mailer software in the hope that it will 
fix the problem.

You aren't the only person seeing this problem.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Undelivered Mail Returned to Sender

[Gabriel Dos Reis]

[-- Attachment #1: Type: text/plain, Size: 103 bytes --]


This is the fifth or so message from me, within the last few days,
that gets rejected.  What is up? 


[-- Attachment #2: Type: message/rfc822, Size: 5072 bytes --]

[-- Attachment #2.1.1: Notification --]
[-- Type: text/plain, Size: 487 bytes --]

This is the Postfix program at host kraid.nerim.net.

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 Postfix program

<gcc-patches@gcc.gnu.org>: host gcc.gnu.org[209.132.176.174] refused to talk to
    me: 500 Unrecognized command

[-- Attachment #2.1.2: Delivery report --]
[-- Type: message/delivery-status, Size: 367 bytes --]

[-- Attachment #2.1.3: Undelivered Message --]
[-- Type: message/rfc822, Size: 1601 bytes --]

From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: Volker Reichelt <reichelt@igpm.rwth-aachen.de>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [patch] PR c++/23797: backport to 3.4 branch
Date: 16 Nov 2005 02:47:16 +0100
Message-ID: <m33blx749n.fsf@uniton.integrable-solutions.net>

Volker Reichelt <reichelt@igpm.rwth-aachen.de> writes:

| Here's a backport of Nathan's patch for PR 23797 to the 3.4 branch.
| The backport of the bugfix itself is straightforward.
| The testcases are a little different due to Mark's patch for PR 19253
| (which also got backported to the 3.4 branch).
| 
| Bootstrapped and regtested on i686-pc-linux-gnu.
| Ok for the 3.4 branch?

OK.

-- Gaby

[-- Attachment #3: Type: text/plain, Size: 151 bytes --]



-- 
                                                       Gabriel Dos Reis 
                                           gdr@integrable-solutions.net