Re: GCC admin is down. Daily bump is no longer available.

[Jonathan Wakely via Gcc]

On Tue, 3 Aug 2021, 07:36 sotrdg sotrdg via Gcc,  wrote:

> last Daily bump was 5 days ago.


Yes, it's a known issue, see
https://gcc.gnu.org/pipermail/gcc/2021-August/236953.html


Need a fix on Daily bump

Re: Hooks fixed to treat trunk the same as master

[Martin Liška]

On 8/2/21 7:22 PM, Joseph Myers wrote:

Hey.


Some time ago, someone added a git symbolic-ref for refs/heads/trunk
pointing to refs/heads/master.


Great you found out what caused that. We were aware of commits that didn't
pass gcc-verify check but for some reason went in.



A side effect of this was to introduce a loophole in the checks run via
commit hooks, some of which are configured to apply only to master and
release branches and didn't apply if commits were pushed instead to trunk
(this also meant that commits pushed to trunk didn't result in Bugzilla
updates, and the emails to gcc-cvs didn't show the r12- short
identifier for the commit).

In particular, the nightly DATESTAMP and ChangeLog updates have been
broken for the past few nights because of a commit pushed to trunk with
bad ChangeLog entries, which only got detected in the nightly cron job
rather than at the time of the original push.


I'm going to fix that with Jakub. The problematic commit is from Aldy:
2e96b5f14e4025691b57d2301d71aa6092ed44bc:

git gcc-verify 2e96b5f14e4025691b57d2301d71aa6092ed44bc

Checking 2e96b5f14e4025691b57d2301d71aa6092ed44bc: FAILED

ERR: unchanged file mentioned in a ChangeLog: "gcc/Makefile.in"

ERR: unchanged file mentioned in a ChangeLog (did you mean 
"gcc/testsuite/gcc.dg/analyzer/pr94851-2.c"?): 
"gcc/testsuite/dg.dg/analyzer/pr94851-2.c"

ERR: changed file not mentioned in a ChangeLog: 
"gcc/testsuite/gcc.dg/analyzer/pr94851-2.c"


Aldy, can you please verify that you pushed the commit to 'trunk' branch name?



I've now changed the hooks to handle trunk the same as master (this mainly
affects three of the hooks-bin scripts (commit_checker,
commit_email_formatter, email-to-bugzilla-filtered), but I also updated
refs/meta/config:project.config to ensure the rule blocking merge commits
to master is properly applied to pushes to trunk as well).


Nods!



Note that this doesn't fix the broken nightly updates; that will probably
require some special-case handling of the broken commit message in the
scripts; it just stops this particular cause of breakage from occurring in
future.



I'm going to append Aldy's commit once 'Daily bump script' is run manually.

Thanks,
Martin

Re: GCC admin is down. Daily bump is no longer available.

[Martin Liška]

On 8/3/21 9:33 AM, Jonathan Wakely via Gcc wrote:

On Tue, 3 Aug 2021, 07:36 sotrdg sotrdg via Gcc,  wrote:


last Daily bump was 5 days ago.


Thanks for heads up.




Yes, it's a known issue, see
https://gcc.gnu.org/pipermail/gcc/2021-August/236953.html


Need a fix on Daily bump



It's fixed now.

Cheers,
Martin

Re: Hooks fixed to treat trunk the same as master

[Aldy Hernandez via Gcc]

On 8/3/21 9:33 AM, Martin Liška wrote:

On 8/2/21 7:22 PM, Joseph Myers wrote:

Hey.


Some time ago, someone added a git symbolic-ref for refs/heads/trunk
pointing to refs/heads/master.


Great you found out what caused that. We were aware of commits that didn't
pass gcc-verify check but for some reason went in.



A side effect of this was to introduce a loophole in the checks run via
commit hooks, some of which are configured to apply only to master and
release branches and didn't apply if commits were pushed instead to trunk
(this also meant that commits pushed to trunk didn't result in Bugzilla
updates, and the emails to gcc-cvs didn't show the r12- short
identifier for the commit).

In particular, the nightly DATESTAMP and ChangeLog updates have been
broken for the past few nights because of a commit pushed to trunk with
bad ChangeLog entries, which only got detected in the nightly cron job
rather than at the time of the original push.


I'm going to fix that with Jakub. The problematic commit is from Aldy:
2e96b5f14e4025691b57d2301d71aa6092ed44bc:

git gcc-verify 2e96b5f14e4025691b57d2301d71aa6092ed44bc

Checking 2e96b5f14e4025691b57d2301d71aa6092ed44bc: FAILED

ERR: unchanged file mentioned in a ChangeLog: "gcc/Makefile.in"

ERR: unchanged file mentioned in a ChangeLog (did you mean 
"gcc/testsuite/gcc.dg/analyzer/pr94851-2.c"?): 
"gcc/testsuite/dg.dg/analyzer/pr94851-2.c"


ERR: changed file not mentioned in a ChangeLog: 
"gcc/testsuite/gcc.dg/analyzer/pr94851-2.c"



Aldy, can you please verify that you pushed the commit to 'trunk' branch 
name?


Sure, that sounds like me :).  I have some local branches based off of 
trunk.  For some reason I thought they were the same.


Sorry for the problems this has caused, and thanks for amending my commit.

I take it it's now ok to treat trunk and master the same?

Aldy

Re: [RFC] Adding a new attribute to function param to mark it as constant

[Prathamesh Kulkarni via Gcc]

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.

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_nv

Re: [RFC] Adding a new attribute to function param to mark it as constant

[Prathamesh Kulkarni via Gcc]

On Tue, 3 Aug 2021 at 15:41, Prathamesh Kulkarni
 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.
>
> 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)
Oops typo, this should have been int *const 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
> > > > > seco

Re: Any Interest

[Jack moov via Gcc]

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

Re: Hooks fixed to treat trunk the same as master

[Martin Liška]

On 8/3/21 12:03 PM, Aldy Hernandez wrote:



On 8/3/21 9:33 AM, Martin Liška wrote:

On 8/2/21 7:22 PM, Joseph Myers wrote:

Hey.


Some time ago, someone added a git symbolic-ref for refs/heads/trunk
pointing to refs/heads/master.


Great you found out what caused that. We were aware of commits that didn't
pass gcc-verify check but for some reason went in.



A side effect of this was to introduce a loophole in the checks run via
commit hooks, some of which are configured to apply only to master and
release branches and didn't apply if commits were pushed instead to trunk
(this also meant that commits pushed to trunk didn't result in Bugzilla
updates, and the emails to gcc-cvs didn't show the r12- short
identifier for the commit).

In particular, the nightly DATESTAMP and ChangeLog updates have been
broken for the past few nights because of a commit pushed to trunk with
bad ChangeLog entries, which only got detected in the nightly cron job
rather than at the time of the original push.


I'm going to fix that with Jakub. The problematic commit is from Aldy:
2e96b5f14e4025691b57d2301d71aa6092ed44bc:

git gcc-verify 2e96b5f14e4025691b57d2301d71aa6092ed44bc

Checking 2e96b5f14e4025691b57d2301d71aa6092ed44bc: FAILED

ERR: unchanged file mentioned in a ChangeLog: "gcc/Makefile.in"

ERR: unchanged file mentioned in a ChangeLog (did you mean 
"gcc/testsuite/gcc.dg/analyzer/pr94851-2.c"?): 
"gcc/testsuite/dg.dg/analyzer/pr94851-2.c"

ERR: changed file not mentioned in a ChangeLog: 
"gcc/testsuite/gcc.dg/analyzer/pr94851-2.c"


Aldy, can you please verify that you pushed the commit to 'trunk' branch name?


Sure, that sounds like me :).  I have some local branches based off of trunk.  
For some reason I thought they were the same.


All right.



Sorry for the problems this has caused, and thanks for amending my commit.


That happens, it's good knowing how the commits sneaked in.



I take it it's now ok to treat trunk and master the same?


Yes, that's how I understood the Joseph's email.

Martin



Aldy

Re: Failures building glibc with mainline GCC

[Joseph Myers]

On Mon, 2 Aug 2021, Martin Sebor via Gcc wrote:

> On 7/30/21 2:52 PM, Joseph Myers wrote:
> > On Fri, 30 Jul 2021, Aldy Hernandez via Gcc wrote:
> > 
> > > There's a new jump threader in GCC which is much more aggressive, and
> > > may trigger latent problems with other warning passes, especially
> > > -Warray-bounds, -Woverflow, and -Wuninitialized.
> > > 
> > > Do your problems go away if you take out commit 2e96b5f14e?
> > 
> > Reverting that commit fixes all the glibc build failures except for
> > x86_64-linux-gnu, i686-gnu and powerpc64le-linux-gnu.
> > 
> 
> I just built Glibc for x86_64-linux-gnu with the top of trunk and
> got no unexpected warnings.  Can you please share the translation
> units for the files with the warnings?  (Or just open GCC bugs for
> them if you believe they're false positives.)

I still see the same error previously discussed for x86_64-linux-gnu.  
Compile the attached file with -O2 -Wall -Werror.

loadmsgcat.c: In function '_nl_load_domain':
loadmsgcat.c:770:22: error: array subscript 0 is outside array bounds of 
'__seg_fs struct pthread * __seg_fs[0]' [-Werror=array-bounds]

As discussed, this is a bug indicating that the code generating that 
warning fails to check targetm.addr_space.zero_address_valid to determine 
whether zero or small constant addresses are valid in the given address 
space.

-- 
Joseph S. Myers
jos...@codesourcery.com

loadmsgcat.i.gz
Description: application/gzip

Re: daily report on extending static analyzer project [GSoC]

[Ankur Saini via Gcc]

AIM: 

- Transfer the vfunc handling code to region_model::get_fndecl_for_call ()
- Filter out a possible targets of a polymorphic call to only one most porbable 
target

---
PROGRESS :

- I decided to transfer the code of detecting virtual call to 
region_model::get_fndecl_for_call () so that the analyzer kind of 
"devirtualise" polymorphic calls to give a single accurate fn_decl of the 
possible target .
This makes it possible to fix the part where I had to make analyzer assume a 
call to have no side effect when it is a polymorphic call when analysing a call 
stmt.

- The way analyzer is more capable to see through a polymorphic call is the 
fact that state of the expoloded node at the time of call knows what subclass 
the pointer which is being used to call a vfunc is actually pointing to.
( here is an example showing the same https://godbolt.org/z/8MWx58dWo )

- So currently I am working on a way to extract this info from the state and 
use it to find the most accurate target amongst all possible targets of a 
polymorphic call we already have, and let the analyzer only call one function 
at the callsite.
Current idea is to evaluate both's ( the possible fn_decl and the pointee of 
the pointer used to call that is used to call vfunc ) DECL_CONTEXT to see if we 
find a match.

---
STATUS AT THE END OF THE DAY :- 

- Transfer the vfunc handling code to region_model::get_fndecl_for_call () 
(done )
- Filter out a possible targets of a polymorphic call to only one most porbable 
target ( pending )

Thank you
- Ankur

Re: Failures building glibc with mainline GCC

[Martin Sebor via Gcc]

On 8/3/21 9:54 AM, Joseph Myers wrote:

On Mon, 2 Aug 2021, Martin Sebor via Gcc wrote:


On 7/30/21 2:52 PM, Joseph Myers wrote:

On Fri, 30 Jul 2021, Aldy Hernandez via Gcc wrote:


There's a new jump threader in GCC which is much more aggressive, and
may trigger latent problems with other warning passes, especially
-Warray-bounds, -Woverflow, and -Wuninitialized.

Do your problems go away if you take out commit 2e96b5f14e?


Reverting that commit fixes all the glibc build failures except for
x86_64-linux-gnu, i686-gnu and powerpc64le-linux-gnu.



I just built Glibc for x86_64-linux-gnu with the top of trunk and
got no unexpected warnings.  Can you please share the translation
units for the files with the warnings?  (Or just open GCC bugs for
them if you believe they're false positives.)


I still see the same error previously discussed for x86_64-linux-gnu.
Compile the attached file with -O2 -Wall -Werror.

loadmsgcat.c: In function '_nl_load_domain':
loadmsgcat.c:770:22: error: array subscript 0 is outside array bounds of 
'__seg_fs struct pthread * __seg_fs[0]' [-Werror=array-bounds]

As discussed, this is a bug indicating that the code generating that
warning fails to check targetm.addr_space.zero_address_valid to determine
whether zero or small constant addresses are valid in the given address
space.


Yes, we know about that one.  What I'm asking for is the translation
units with the other warnings you showed with the latest GCC (including
the threader patches) on the other targets (including i686 and power).
I don't have an easy way to create them using my setup.

Martin

Re: Hooks fixed to treat trunk the same as master

[Joseph Myers]

On Tue, 3 Aug 2021, Martin Liška wrote:

> On 8/2/21 7:22 PM, Joseph Myers wrote:
> 
> Hey.
> 
> > Some time ago, someone added a git symbolic-ref for refs/heads/trunk
> > pointing to refs/heads/master.
> 
> Great you found out what caused that. We were aware of commits that didn't
> pass gcc-verify check but for some reason went in.

I think one of the previous such cases 
(c2be82058fb40f3ae891c68d185ff53e07f14f45) had a different cause, for 
which I've now filed  
after confirming I could reproduce that case.  (While 
04a040d907a83af54e0a98bdba5bfabc0ef4f700 was a case of a push to trunk.)

-- 
Joseph S. Myers
jos...@codesourcery.com

FYI: New Clang flag "-fnew-infallible" to mark C++ new as "throw()" and "returns_nonnull"

[Modi Mo via Gcc]

Hi all,

I recently committed support for the "-fnew-infallible" flag in Clang 
(https://reviews.llvm.org/D105225) to improve non-exceptional performance for 
code that contains exceptions. Having "new" terminate immediately on failure 
stops upward exception propagation and leads to significantly less landing pads 
generated. Posting here for visibility and to reduce the chance that a similar 
feature may manifest under a different flag for GCC.

Thanks,
Modi

Re: Failures building glibc with mainline GCC

[Samuel Thibault via Gcc]

Joseph Myers, le mar. 03 août 2021 17:21:59 +, a ecrit:
> On Tue, 3 Aug 2021, Martin Sebor via Gcc wrote:
> 
> > Yes, we know about that one.  What I'm asking for is the translation
> > units with the other warnings you showed with the latest GCC (including
> > the threader patches) on the other targets (including i686 and power).
> > I don't have an easy way to create them using my setup.
> 
> I've attached (all gzipped) hurdselect.i (i686-gnu, -O2 -Wall -Werror 
> -Wno-parentheses):
> 
> hurdselect.c: In function '_hurd_select':
> hurdselect.c:555:7: error: 'ss' may be used uninitialized in this function 
> [-Werror=maybe-uninitialized]
> hurdselect.c:70:25: note: 'ss' was declared here

That's a spurious warning, but I have pushed a trivial workaround.

Samuel

Re: [RFC] Adding a new attribute to function param to mark it as constant

[Martin Sebor via Gcc]

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; }

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

Re: FYI: New Clang flag "-fnew-infallible" to mark C++ new as "throw()" and "returns_nonnull"

[Jonathan Wakely via Gcc]

On Tue, 3 Aug 2021 at 18:26, Modi Mo via Gcc  wrote:
>
> Hi all,
>
> I recently committed support for the "-fnew-infallible" flag in Clang 
> (https://reviews.llvm.org/D105225) to improve non-exceptional performance for 
> code that contains exceptions. Having "new" terminate immediately on failure 
> stops upward exception propagation and leads to significantly less landing 
> pads generated. Posting here for visibility and to reduce the chance that a 
> similar feature may manifest under a different flag for GCC.

Thanks for the heads up. This is interesting.

Could you explain this sentence in the commit message:
"Note that the definition of global new is user-replaceable so users
should ensure that the one used follows these semantics."

What happens if operator new does throw? Is that just treated like any
other noexcept function that throws, i.e. std::terminate()? Or is it
undefined behaviour?

And what if you use ::new(std::nothrow) and that fails, returning
null. Is that undefined?

It seems to me that the former case (a potentially-throwing allocation
function) could be turned into a std::terminate call fairly easily
without losing the benefits of this option (you still know that no
call to operator new will propagate exceptions). But for the latter
case the program *must* replace operator new to ensure that the
nothrow form never returns null, otherwise you violate the promise
that the returns_nonnull attribute makes, and have undefined
behaivour. Is that right?

Re: Failures building glibc with mainline GCC

[Segher Boessenkool]

On Tue, Aug 03, 2021 at 10:20:49AM -0600, Martin Sebor via Gcc wrote:
> On 8/3/21 9:54 AM, Joseph Myers wrote:
> >As discussed, this is a bug indicating that the code generating that
> >warning fails to check targetm.addr_space.zero_address_valid to determine
> >whether zero or small constant addresses are valid in the given address
> >space.
> 
> Yes, we know about that one.  What I'm asking for is the translation
> units with the other warnings you showed with the latest GCC (including
> the threader patches) on the other targets (including i686 and power).
> I don't have an easy way to create them using my setup.

But you do have a cfarm account :-)


Segher

Re: Failures building glibc with mainline GCC

[Joseph Myers]

On Tue, 3 Aug 2021, Segher Boessenkool wrote:

> On Tue, Aug 03, 2021 at 10:20:49AM -0600, Martin Sebor via Gcc wrote:
> > On 8/3/21 9:54 AM, Joseph Myers wrote:
> > >As discussed, this is a bug indicating that the code generating that
> > >warning fails to check targetm.addr_space.zero_address_valid to determine
> > >whether zero or small constant addresses are valid in the given address
> > >space.
> > 
> > Yes, we know about that one.  What I'm asking for is the translation
> > units with the other warnings you showed with the latest GCC (including
> > the threader patches) on the other targets (including i686 and power).
> > I don't have an easy way to create them using my setup.
> 
> But you do have a cfarm account :-)

And build-many-glibcs.py is designed to be self-contained (depending only 
on the Python 3 standard library and basic native compilation tools), so 
having got a copy from a glibc checkout, you can do (given /some/where as 
the directory in which you want build-many-glibcs.py to do its checkouts 
and builds):

build-many-glibcs.py /some/where checkout gcc-vcs-mainline
/some/where/src/glibc/scripts/build-many-glibcs.py /some/where host-libraries
/some/where/src/glibc/scripts/build-many-glibcs.py --keep=failed /some/where 
compilers i686-gnu powerpc-linux-gnu powerpc64-linux-gnu

which will check out all the sources needed to build glibc, using mainline 
GCC, build the GMP/MPFR/MPC host libraries needed by GCC, then build cross 
toolchains for the three listed targets, keeping the build directories 
around for build stages that fail (in this case, the glibc build for those 
targets).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [RFC] Adding a new attribute to function param to mark it as constant

[Segher Boessenkool]

Hi!

On Fri, Jul 23, 2021 at 04:23:42PM +0530, Prathamesh Kulkarni via Gcc wrote:
> The constraint here is that, vshl_n intrinsics require that the
> second arg (__b),
> should be an immediate value.

Something that matches the "n" constraint, not necessarily a literal,
but stricter than just "immediate".  It probably is a good idea to allow
only "integer constant expression"s, so that the validity of the source
code does not depend on what the optimisers do with the code.

> As Richard suggested, sth like:
> void foo(int x __attribute__((literal_constant (min_val, max_val)));

The Linux kernel has a macro __is_constexpr to test if something is an
integer constant expression, see  .  That is a much
better idea imo.  There could be a builtin for that of course, but an
attribute is less powerful, less usable, less useful.


Segher

Re: Failures building glibc with mainline GCC

[Segher Boessenkool]

Off-topic...

On Tue, Aug 03, 2021 at 09:00:20PM +, Joseph Myers wrote:
> On Tue, 3 Aug 2021, Segher Boessenkool wrote:
> > But you do have a cfarm account :-)
> 
> And build-many-glibcs.py is designed to be self-contained

[ snip ]

Yes, it's great :-)

> which will check out all the sources needed to build glibc, using mainline 
> GCC, build the GMP/MPFR/MPC host libraries needed by GCC,

It usually is preferred to use the existing host libraries, or to build
these libraries as part of the GCC build (as done with
contrib/download_prerequisites for example).



Segher

Re: New Clang flag "-fnew-infallible" to mark C++ new as "throw()" and "returns_nonnull"

[Modi Mo via Gcc]

On 8/3/21, 1:51 PM, "Jonathan Wakely"  wrote:
>
>Could you explain this sentence in the commit message:
>"Note that the definition of global new is user-replaceable so users
>should ensure that the one used follows these semantics."

AFAICT based on the C++ standard, the user can replace the definition of 
operator new with anything they want. 
In the current implementation we're using an un-enforced "throw()" annotation 
so it's up to the implementation of ::new (in libstdc++/jemalloc etc.) to 
comply properly or risk UB.
Marking ::new as noexcept is more rigid of an enforcement but I believe it's 
implementation defined as to how exception specifications are merged and 
because noexcept is not part of the mangled name link-time replacement would 
encounter the same issue.

>What happens if operator new does throw? Is that just treated like any
>other noexcept function that throws, i.e. std::terminate()? Or is it
>undefined behaviour?

It gets treated like the older "throw()" annotation where it's UB, there's no 
enforcement.

>And what if you use ::new(std::nothrow) and that fails, returning
>null. Is that undefined?

This change doesn't affect ::new(std::nothrow) ATM. Nathan Sidwell suggested 
that we may want to change semantics for non-throwing as well to be truly 
"infallible" but we don't have a use-case for this scenario as of yet.

>It seems to me that the former case (a potentially-throwing allocation
>function) could be turned into a std::terminate call fairly easily
>without losing the benefits of this option (you still know that no
>call to operator new will propagate exceptions). 

Could you elaborate? That would be great if there's a way to do this without 
requiring enforcement on the allocator definition.

>But for the latter case the program *must* replace operator new to ensure 
> that the
>nothrow form never returns null, otherwise you violate the promise
>that the returns_nonnull attribute makes, and have undefined
>behaivour. Is that right?

Yes good insight. That's another tricky aspect to implementing this for 
non-throwing new.

Re: Failures building glibc with mainline GCC

[Martin Sebor via Gcc]

On 8/3/21 11:21 AM, Joseph Myers wrote:

On Tue, 3 Aug 2021, Martin Sebor via Gcc wrote:


Yes, we know about that one.  What I'm asking for is the translation
units with the other warnings you showed with the latest GCC (including
the threader patches) on the other targets (including i686 and power).
I don't have an easy way to create them using my setup.


I've attached (all gzipped) hurdselect.i (i686-gnu, -O2 -Wall -Werror
-Wno-parentheses):


Thanks.



hurdselect.c: In function '_hurd_select':
hurdselect.c:555:7: error: 'ss' may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
hurdselect.c:70:25: note: 'ss' was declared here


This is a false positive caused by the overly restrictive analysis
limits hardwired into GCC (like PR 85872).  I have a patch that
relaxes the limits and that avoids the warning in this case but
it's not yet ready.



and t.61.i (powerpc-linux-gnu, -O2 -Wall -Werror):

In file included from t.61.c:437:
In function 'from_t_61_single',
 inlined from 'gconv' at ../iconv/skeleton.c:568:15:
../iconv/loop.c:440:22: error: writing 1 byte into a region of size 0 
[-Werror=stringop-overflow=]
In file included from t.61.c:437:
../iconv/loop.c: In function 'gconv':
../iconv/loop.c:382:17: note: at offset 2 into destination object 'bytebuf' of 
size 2


This is the same warning as Jeff noted on s390-linux-gnu and that
I explained in my reply:
  https://gcc.gnu.org/pipermail/gcc/2021-July/236943.html
There's nothing the warning alone can do to avoid triggering in these
cases (unrolling too many iterations of a loop).  The unroller does
have code to avoid doing this (infer_loop_bounds_from_undefined) but
it's not good enough.  Using -fno-aggressive-loop-optimizations
prevents the warning.


and dl-tls.i (powerpc64-linux-gnu, -O2 -finline-limit=2000 -Wall -Werror;
the -finline-limit=2000 option is necessary for the error and comes from
sysdeps/powerpc/powerpc64/Makefile):

In file included from ../sysdeps/powerpc/dl-tls.c:20:
In function '_dl_allocate_tls_init',
 inlined from '_dl_allocate_tls' at ../elf/dl-tls.c:621:10:
../elf/dl-tls.c:529:10: error: array subscript -1 is outside array bounds of 
'void[9223372036854775807]' [-Werror=array-bounds]
../elf/dl-tls.c:544:40: error: array subscript -1 is outside array bounds of 
'void[9223372036854775807]' [-Werror=array-bounds]



These warnings are reproducible even with a native x86_64 compiler
and the same option.  It's most likely due to the same root cause
as PR 101600 (the one in comment #0, not comment #2).  I don't have
a fix for it yet but it shouldn't be too hard.

Martin

Re: Failures building glibc with mainline GCC

[Martin Sebor via Gcc]

On 8/3/21 3:00 PM, Joseph Myers wrote:

On Tue, 3 Aug 2021, Segher Boessenkool wrote:


On Tue, Aug 03, 2021 at 10:20:49AM -0600, Martin Sebor via Gcc wrote:

On 8/3/21 9:54 AM, Joseph Myers wrote:

As discussed, this is a bug indicating that the code generating that
warning fails to check targetm.addr_space.zero_address_valid to determine
whether zero or small constant addresses are valid in the given address
space.


Yes, we know about that one.  What I'm asking for is the translation
units with the other warnings you showed with the latest GCC (including
the threader patches) on the other targets (including i686 and power).
I don't have an easy way to create them using my setup.


But you do have a cfarm account :-)


And build-many-glibcs.py is designed to be self-contained (depending only
on the Python 3 standard library and basic native compilation tools), so
having got a copy from a glibc checkout, you can do (given /some/where as
the directory in which you want build-many-glibcs.py to do its checkouts
and builds):

build-many-glibcs.py /some/where checkout gcc-vcs-mainline
/some/where/src/glibc/scripts/build-many-glibcs.py /some/where host-libraries
/some/where/src/glibc/scripts/build-many-glibcs.py --keep=failed /some/where 
compilers i686-gnu powerpc-linux-gnu powerpc64-linux-gnu

which will check out all the sources needed to build glibc, using mainline
GCC, build the GMP/MPFR/MPC host libraries needed by GCC, then build cross
toolchains for the three listed targets, keeping the build directories
around for build stages that fail (in this case, the glibc build for those
targets).



Thanks for the instructions.  I assumed that the purpose of these
automated builders and testers was to help us quickly find and
more easily root cause problems without each of us having to do
builds on all these targets ourselves.  If asking for translation
units to go with the problems your testers uncover is an imposition
I apologize.  In that event, I would suggest to submit bug reports
in Bugzilla instead with the usual details attached there.

Martin

Re: New Clang flag "-fnew-infallible" to mark C++ new as "throw()" and "returns_nonnull"

[Jonathan Wakely via Gcc]

On Tue, 3 Aug 2021, 23:10 Modi Mo, wrote:
>
> On 8/3/21, 1:51 PM, "Jonathan Wakely"  wrote:
> >
> >Could you explain this sentence in the commit message:
> >"Note that the definition of global new is user-replaceable so users
> >should ensure that the one used follows these semantics."
>
> AFAICT based on the C++ standard, the user can replace the definition of 
> operator new with anything they want.


No, they have to meet certain requirements.

If any operator new is potentially throwing (i.e. not declared
noexcept) and it returns null, you get UB. A potentially throwing
operator new *must* return non-null, or throw something they can be
caught by catch(bad_alloc const&), or not return (e.g. terminate).
If any operator new is noexcept, then it reports failure by returning
null instead of throwing.

So if the user replaces the global operator new(size_t), then their
replacement must never return null, because it's declared without
noexcept.


>
> In the current implementation we're using an un-enforced "throw()" annotation 
> so it's up to the implementation of ::new (in libstdc++/jemalloc etc.) to 
> comply properly or risk UB.

That's what I was afraid of. The implementation in libstdc++ cannot
know the user passed -fnew-infallible so has no way of knowing whether
it's allowed to throw, or if it has to terminate on failure. So it
will throw in failure, which will then be undefined.

So it seems the user must either provide a replacement operator new
which terminates, or simply ensure that their program never exceeds
the system's available memory. In the latter case, the
-fnew-infallible option is basically a promise to the compiler that
the system has "infinite" memory (or enough for the program's needs,
if not actually infinite).

> Marking ::new as noexcept is more rigid of an enforcement but I believe it's 
> implementation defined as to how exception specifications are merged

I think it's undefined if two declarations of the same function have
different exception specifications. I might be wrong.


>and because noexcept is not part of the mangled name link-time replacement 
>would encounter the same issue.

Yes.

Making it noexcept would currently mean that the compiler must assume
it can return null, and so adds extra checks to a new-expression so
that if operator new returns null no object is constructed. But if
it's noexcept *and* return_nonnull I guess that check can be elided.


>
> >What happens if operator new does throw? Is that just treated like any
> >other noexcept function that throws, i.e. std::terminate()? Or is it
> >undefined behaviour?
>
> It gets treated like the older "throw()" annotation where it's UB, there's no 
> enforcement.


It's not UB for a throw() function to throw. In C++03 it would call
std::unexpected() which by default calls std::terminate(). So throw()
is effectively the same as noexcept.


>
> >And what if you use ::new(std::nothrow) and that fails, returning
> >null. Is that undefined?
>
> This change doesn't affect ::new(std::nothrow) ATM. Nathan Sidwell suggested 
> that we may want to change semantics for non-throwing as well to be truly 
> "infallible" but we don't have a use-case for this scenario as of yet.

Ah, I see. So it only affects operator new(size_t)?
And operator new(size_t, align_val_t) too?
And the corresponding operator new[] forms?

>
> >It seems to me that the former case (a potentially-throwing allocation
> >function) could be turned into a std::terminate call fairly easily
> >without losing the benefits of this option (you still know that no
> >call to operator new will propagate exceptions).
>
> Could you elaborate? That would be great if there's a way to do this without 
> requiring enforcement on the allocator definition.

Well I meant adding enforcement when calling operator new. The
compiler could treat every call to operator new as though it's done
by:

void* __call_new(size_t n) noexcept ( return operator new(n); }

so that an exception will call std::terminate. But that would add some
overhead (more for Clang than for GCC, due to how noexcept is
enforced), and that overhead is presumably unnecessary if the
intention of the option is to make a promise that operator new won't
ever throw.

>
> >But for the latter case the program *must* replace operator new to 
> > ensure that the
> >nothrow form never returns null, otherwise you violate the promise
> >that the returns_nonnull attribute makes, and have undefined
> >behaivour. Is that right?
>
> Yes good insight. That's another tricky aspect to implementing this for 
> non-throwing new.

If you just treat -fnew-infallible as a promise that operator new
never fails, then ISTM that it's OK to treat failure as undefined (you
said failure was impossible, if it fails, that's your fault). And if
you replace operator new, you can keep your promise by making it
terminate on failure.

But if some enforcement is wanted (maybe via
-fn

Add ops_num to targetm.sched.reassociation_width hook

[Aaron Sawdey via Gcc]

Richard,

So, I’m noticing that in get_reassociation_width() we know how many ops 
(ops_num) are in the expression being considered for parallel reassociation, 
but this is not passed to the target hook. In my testing this seems like it 
might be useful to have. If you determine the maximum width that gives 
additional speedup for a large number of terms, and then use that as the width 
from the target hook, get_reassociation_width() is more aggressive than you 
would like for small expressions with maybe 4-16 terms and produces code that 
is slower than optimal. For example in many cases you want to continue using a 
width of 1 until you get to 16 terms or so. My testing shows this to be the 
case for power8, power9, and power10 processors. 

So, I’m wondering how it might be received if I posted a patch that adds this 
to the reassociation_width target hook (and of course fixes all uses of that 
target hook)?

Thanks!
   Aaron


Aaron Sawdey, Ph.D. saw...@linux.ibm.com
IBM Linux on POWER Toolchain
 

CFI technologies in GCC

[Victor Tong via Gcc]

Hello,

I'm interested in learning about any forward edge control-flow integrity (CFI) 
technologies in GCC. I was able to find information about the Virtual Table 
Verification, Indirect Branch Tracking and Reuse Attack Protector technologies.

Are there any other technologies in GCC to protect indirect calls? I'm 
particularly curious about more general solutions since VTV is limited to 
virtual calls, IBT is limited to x86 and Intel hardware, and RAP requires a 
GRSecurity license.

Thanks,
Victor

Re: New Clang flag "-fnew-infallible" to mark C++ new as "throw()" and "returns_nonnull"

[Modi Mo via Gcc]

On 8/3/21, 4:57 PM, "Jonathan Wakely"  wrote:

> On Tue, 3 Aug 2021, 23:10 Modi Mo, wrote:
> >
> > On 8/3/21, 1:51 PM, "Jonathan Wakely"  wrote:
> > >
> > >Could you explain this sentence in the commit message:
> > >"Note that the definition of global new is user-replaceable so users
> > >should ensure that the one used follows these semantics."
> >
> > AFAICT based on the C++ standard, the user can replace the definition of 
> > operator new with anything they want.
>
>
> No, they have to meet certain requirements.
>
> If any operator new is potentially throwing (i.e. not declared
> noexcept) and it returns null, you get UB. A potentially throwing
> operator new *must* return non-null, or throw something they can be
> caught by catch(bad_alloc const&), or not return (e.g. terminate).
> If any operator new is noexcept, then it reports failure by returning
> null instead of throwing.

Ah right, I found this out when implementing which is the main motivation 
behind using "throw()" as noexcept will categorize all ::new as 
::new(std::nothrow) which isn't what we're after in this implementation.

> So if the user replaces the global operator new(size_t), then their
> replacement must never return null, because it's declared without
> noexcept.
>
>
> >
> > In the current implementation we're using an un-enforced "throw()" 
> > annotation so it's up to the implementation of ::new (in libstdc++/jemalloc 
> > etc.) to comply properly or risk UB.
>
> That's what I was afraid of. The implementation in libstdc++ cannot
> know the user passed -fnew-infallible so has no way of knowing whether
> it's allowed to throw, or if it has to terminate on failure. So it
> will throw in failure, which will then be undefined.
>
> So it seems the user must either provide a replacement operator new
> which terminates, or simply ensure that their program never exceeds
> the system's available memory. In the latter case, the
> -fnew-infallible option is basically a promise to the compiler that
> the system has "infinite" memory (or enough for the program's needs,
> if not actually infinite).

Yeah, there's a disconnect between declaration (what -fnew-infallible does) and 
definition (libstdc++). I don't know of a way to enforce this automatically 
without creating a shim like you suggested. 

> > Marking ::new as noexcept is more rigid of an enforcement but I believe 
> > it's implementation defined as to how exception specifications are merged
>
> I think it's undefined if two declarations of the same function have
> different exception specifications. I might be wrong.

The main reason I didn't do this is as you identified above, marking it 
noexcept from a standard viewpoint changes ::new to : :new(std::nothrow).

> Making it noexcept would currently mean that the compiler must assume
> it can return null, and so adds extra checks to a new-expression so
> that if operator new returns null no object is constructed. But if
> it's noexcept *and* return_nonnull I guess that check can be elided.

I think doing this could work though I feel like there'll be some rough edges 
that have to be filed down. 

> > >What happens if operator new does throw? Is that just treated like any
> > >other noexcept function that throws, i.e. std::terminate()? Or is it
> > >undefined behaviour?
> >
> > It gets treated like the older "throw()" annotation where it's UB, there's 
> > no enforcement.
>
>
> It's not UB for a throw() function to throw. In C++03 it would call
> std::unexpected() which by default calls std::terminate(). So throw()
> is effectively the same as noexcept.

What's getting altered ATM is the implicit declaration of "new" that doesn't 
actually require the header to be copied in:

These implicit declarations introduce only the function names operator new, 
operator new[], opera- tor delete, and operator delete[]. [Note: The implicit 
declarations do not introduce the names std, std::size_t, std::align_val_t, or 
any other names that the library uses to declare these names. 
Thus, a new-expression, delete-expression, or function call that refers to one 
of these functions without importing or including the header  (17.6.1) is 
well-formed.

The definition though doesn't have to abide by this and if it doesn't then UB 
gets triggered. 

> > >And what if you use ::new(std::nothrow) and that fails, returning
> > >null. Is that undefined?
> >
> > This change doesn't affect ::new(std::nothrow) ATM. Nathan Sidwell 
> > suggested that we may want to change semantics for non-throwing as well to 
> > be truly "infallible" but we don't have a use-case for this scenario as of 
> > yet.
>
> Ah, I see. So it only affects operator new(size_t)?
> And operator new(size_t, align_val_t) too?
> And the corresponding operator new[] forms?

Yep.

> > >It seems to me that the former case (a potentially-throwing allocation
> > >function) could be turned into a std::terminate call fairly easily
> > >without losing t

Re: New Clang flag "-fnew-infallible" to mark C++ new as "throw()" and "returns_nonnull"

[Jonathan Wakely via Gcc]

On Wed, 4 Aug 2021, 02:15 Modi Mo,  wrote:

> On 8/3/21, 4:57 PM, "Jonathan Wakely"  wrote:
>
> > On Tue, 3 Aug 2021, 23:10 Modi Mo, wrote:
> > >
> > > On 8/3/21, 1:51 PM, "Jonathan Wakely"  wrote:
> > > >
> > > >Could you explain this sentence in the commit message:
> > > >"Note that the definition of global new is user-replaceable so
> users
> > > >should ensure that the one used follows these semantics."
> > >
> > > AFAICT based on the C++ standard, the user can replace the definition
> of operator new with anything they want.
> >
> >
> > No, they have to meet certain requirements.
> >
> > If any operator new is potentially throwing (i.e. not declared
> > noexcept) and it returns null, you get UB. A potentially throwing
> > operator new *must* return non-null, or throw something they can be
> > caught by catch(bad_alloc const&), or not return (e.g. terminate).
> > If any operator new is noexcept, then it reports failure by returning
> > null instead of throwing.
>
> Ah right, I found this out when implementing which is the main motivation
> behind using "throw()" as noexcept will categorize all ::new as
> ::new(std::nothrow) which isn't what we're after in this implementation.
>

This seems like a clang-specific implementation detail. I think GCC treats
throw() as exactly equivalent to noexcept.

But maybe __attribute__((nothrow,return_nonnull)) would do it for GCC.



> > So if the user replaces the global operator new(size_t), then their
> > replacement must never return null, because it's declared without
> > noexcept.
> >
> >
> > >
> > > In the current implementation we're using an un-enforced "throw()"
> annotation so it's up to the implementation of ::new (in libstdc++/jemalloc
> etc.) to comply properly or risk UB.
> >
> > That's what I was afraid of. The implementation in libstdc++ cannot
> > know the user passed -fnew-infallible so has no way of knowing whether
> > it's allowed to throw, or if it has to terminate on failure. So it
> > will throw in failure, which will then be undefined.
> >
> > So it seems the user must either provide a replacement operator new
> > which terminates, or simply ensure that their program never exceeds
> > the system's available memory. In the latter case, the
> > -fnew-infallible option is basically a promise to the compiler that
> > the system has "infinite" memory (or enough for the program's needs,
> > if not actually infinite).
>
> Yeah, there's a disconnect between declaration (what -fnew-infallible
> does) and definition (libstdc++). I don't know of a way to enforce this
> automatically without creating a shim like you suggested.
>
> > > Marking ::new as noexcept is more rigid of an enforcement but I
> believe it's implementation defined as to how exception specifications are
> merged
> >
> > I think it's undefined if two declarations of the same function have
> > different exception specifications. I might be wrong.
>
> The main reason I didn't do this is as you identified above, marking it
> noexcept from a standard viewpoint changes ::new to : :new(std::nothrow).
>
> > Making it noexcept would currently mean that the compiler must assume
> > it can return null, and so adds extra checks to a new-expression so
> > that if operator new returns null no object is constructed. But if
> > it's noexcept *and* return_nonnull I guess that check can be elided.
>
> I think doing this could work though I feel like there'll be some rough
> edges that have to be filed down.
>
> > > >What happens if operator new does throw? Is that just treated
> like any
> > > >other noexcept function that throws, i.e. std::terminate()? Or is
> it
> > > >undefined behaviour?
> > >
> > > It gets treated like the older "throw()" annotation where it's UB,
> there's no enforcement.
> >
> >
> > It's not UB for a throw() function to throw. In C++03 it would call
> > std::unexpected() which by default calls std::terminate(). So throw()
> > is effectively the same as noexcept.
>
> What's getting altered ATM is the implicit declaration of "new" that
> doesn't actually require the header to be copied in:
>
> These implicit declarations introduce only the function names operator
> new, operator new[], opera- tor delete, and operator delete[]. [Note: The
> implicit declarations do not introduce the names std, std::size_t,
> std::align_val_t, or any other names that the library uses to declare these
> names.
> Thus, a new-expression, delete-expression, or function call that refers to
> one of these functions without importing or including the header 
> (17.6.1) is well-formed.
>


Ah right, yes, it's not enough to adjust , so it needs to be a
compiler flag.


> The definition though doesn't have to abide by this and if it doesn't then
> UB gets triggered.
>
> > > >And what if you use ::new(std::nothrow) and that fails, returning
> > > >null. Is that undefined?
> > >
> > > This change doesn't affect ::new(std::nothrow) ATM. Nathan Sidwell
> suggested that we may want t