[Bug tree-optimization/102451] Suspicious null-pointer dereference in delete_dead_or_redundant_call

[fxue at os dot amperecomputing.com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102451

Feng Xue  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Feng Xue  ---
Fixed

[Bug tree-optimization/102400] Field might miss initialization in vn_reference_insert_pieces()

[fxue at os dot amperecomputing.com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102400

Feng Xue  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Feng Xue  ---
Fixed

[Bug tree-optimization/102400] Field might miss initialization in vn_reference_insert_pieces()

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102400

--- Comment #3 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Feng Xue :

https://gcc.gnu.org/g:210c3901749a245dc45f04da3dac70ef126e6762

commit r11-9030-g210c3901749a245dc45f04da3dac70ef126e6762
Author: Feng Xue 
Date:   Thu Sep 23 09:14:33 2021 +0800

Fix value uninitialization in vn_reference_insert_pieces [PR102400]

2021-09-23  Feng Xue  

gcc/
PR tree-optimization/102400
* tree-ssa-sccvn.c (vn_reference_insert_pieces): Initialize
result_vdef to zero value.

[Bug tree-optimization/102451] Suspicious null-pointer dereference in delete_dead_or_redundant_call

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102451

--- Comment #4 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Feng Xue :

https://gcc.gnu.org/g:03a8d9ab4cea24a945bb283c580d53a134221b9b

commit r11-9029-g03a8d9ab4cea24a945bb283c580d53a134221b9b
Author: Feng Xue 
Date:   Thu Sep 23 08:47:45 2021 +0800

Fix null-pointer dereference in delete_dead_or_redundant_call [PR102451]

2021-09-23  Feng Xue  

gcc/
PR tree-optimization/102451
* tree-ssa-dse.c (delete_dead_or_redundant_call): Record bb of stmt
before removal.

Re: [PATCH] Enable auto-vectorization at O2 with very-cheap cost model.

[Hongtao Liu via Gcc-patches]

On Thu, Sep 23, 2021 at 11:18 PM Martin Sebor  wrote:
>
> On 9/23/21 12:30 AM, Richard Biener wrote:
> > On Thu, 23 Sep 2021, Hongtao Liu wrote:
> >
> >> On Thu, Sep 23, 2021 at 9:48 AM Hongtao Liu  wrote:
> >>>
> >>> On Wed, Sep 22, 2021 at 10:21 PM Martin Sebor  wrote:
> 
>  On 9/21/21 7:38 PM, Hongtao Liu wrote:
> > On Mon, Sep 20, 2021 at 4:13 AM Martin Sebor  wrote:
>  ...
> > diff --git a/gcc/testsuite/c-c++-common/Wstringop-overflow-2.c 
> > b/gcc/testsuite/c-c++-common/Wstringop-overflow-2.c
> > index 1d79930cd58..9351f7e7a1a 100644
> > --- a/gcc/testsuite/c-c++-common/Wstringop-overflow-2.c
> > +++ b/gcc/testsuite/c-c++-common/Wstringop-overflow-2.c
> > @@ -1,7 +1,7 @@
> > /* PR middle-end/91458 - inconsistent warning for writing past 
> > the end
> >of an array member
> >{ dg-do compile }
> > -   { dg-options "-O2 -Wall -Wno-array-bounds -fno-ipa-icf" } */
> > +   { dg-options "-O2 -Wall -Wno-array-bounds -fno-ipa-icf 
> > -fno-tree-vectorize" } */
> 
>  The testcase is large - what part requires this change?  Given the
>  testcase was added for inconsistent warnings do they now become
>  inconsistent again as we enable vectorization at -O2?
> 
>  That said, the testcase adjustments need some explaining - I suppose
>  you didn't just slap -fno-tree-vectorize to all of those changing
>  behavior?
> 
> >>> void ga1_ (void)
> >>> {
> >>>  a1_.a[0] = 0;
> >>>  a1_.a[1] = 1; // { dg-warning 
> >>> "\\\[-Wstringop-overflow" }
> >>>  a1_.a[2] = 2; // { dg-warning 
> >>> "\\\[-Wstringop-overflow" }
> >>>
> >>>  struct A1 a;
> >>>  a.a[0] = 0;
> >>>  a.a[1] = 1;   // { dg-warning 
> >>> "\\\[-Wstringop-overflow" }
> >>>  a.a[2] = 2;   // { dg-warning 
> >>> "\\\[-Wstringop-overflow" }
> >>>  sink ();
> >>> }
> >>>
> >>> It's supposed to be 2 warning for a.a[1] = 1 and a.a[2] = 1 since
> >>> there are 2 accesses, but after enabling vectorization, there's only
> >>> one access, so one warning is missing which causes the failure.
> 
>  With the stores vectorized, is the warning on the correct line or
>  does it point to the first store, the one that's in bounds, as
>  it does with -O3?  The latter would be a regression at -O2.
> >>> For the upper case, It points to the second store which is out of
> >>> bounds, the third store warning is missing.
> 
> >>
> >> I would find it preferable to change the test code over disabling
> >> optimizations that are on by default.  My concern is that the test
> >> would no longer exercise the default behavior.  (The same goes for
> >> the -fno-ipa-icf option.)
> > Hmm, it's a middle-end test, for some backend, it may not do
> > vectorization(it depends on TARGET_VECTOR_MODE_SUPPORTED_P and
> > relative cost model).
> 
>  Yes, there are quite a few warning tests like that.  Their main
>  purpose is to verify that in common GCC invocations (i.e., without
>  any special options) warnings are a) issued when expected and b)
>  not issued when not expected.  Otherwise, middle end warnings are
>  known to have both false positives and false negatives in some
>  invocations, depending on what optimizations are in effect.
>  Indiscriminately disabling common optimizations for these large
>  tests and invoking them under artificial conditions would
>  compromise this goal and hide the problems.
> 
>  If enabling vectorization at -O2 causes regressions in the quality
>  of diagnostics (as the test failure above indicates seems to be
>  happening) we should investigate these and open bugs for them so
>  they can be fixed.  We can then tweak the specific failing test
>  cases to avoid the failures until they are fixed.
> >>> There are indeed cases of false positives and false negatives
> >>> .i.e.
> >>> // Verify warning for access to a definition with an initializer that
> >>> // initializes the one-element array member.
> >>> struct A1 a1i_1 = { 0, { 1 } };
> >>>
> >>> void ga1i_1 (void)
> >>> {
> >>>a1i_1.a[0] = 0;
> >>>a1i_1.a[1] = 1;   // { dg-warning 
> >>> "\\\[-Wstringop-overflow" }
> >>>a1i_1.a[2] = 2;   // { dg-warning 
> >>> "\\\[-Wstringop-overflow" }
> >>>
> >>>struct A1 a = { 0, { 1 } }; --- false positive here.
> >>>a.a[0] = 1;
> >>>a.a[1] = 2;   // { dg-warning
> >>> "\\\[-Wstringop-overflow" } false negative here.
> >>>a.a[2] = 3;   // { dg-warning
> >>> "\\\[-Wstringop-overflow" } false negative here.
> >>>sink ();
> >>> }
> >> Similar for
> >> * gcc.dg/Warray-bounds-51.c.
> >> * 

[Bug tree-optimization/102400] Field might miss initialization in vn_reference_insert_pieces()

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102400

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Feng Xue :

https://gcc.gnu.org/g:29c92857039d0a105281be61c10c9e851aaeea4a

commit r12-3875-g29c92857039d0a105281be61c10c9e851aaeea4a
Author: Feng Xue 
Date:   Thu Sep 23 09:14:33 2021 +0800

Fix value uninitialization in vn_reference_insert_pieces [PR102400]

2021-09-23  Feng Xue  

gcc/
PR tree-optimization/102400
* tree-ssa-sccvn.c (vn_reference_insert_pieces): Initialize
result_vdef to zero value.

[Bug tree-optimization/102451] Suspicious null-pointer dereference in delete_dead_or_redundant_call

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102451

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Feng Xue :

https://gcc.gnu.org/g:f91b11eb8891f3ae910eb3b2e4a48e2d7d670d2d

commit r12-3874-gf91b11eb8891f3ae910eb3b2e4a48e2d7d670d2d
Author: Feng Xue 
Date:   Thu Sep 23 08:47:45 2021 +0800

Fix null-pointer dereference in delete_dead_or_redundant_call [PR102451]

2021-09-23  Feng Xue  

gcc/
PR tree-optimization/102451
* tree-ssa-dse.c (delete_dead_or_redundant_call): Record bb of stmt
before removal.

Re: [PATCH] AVX512FP16: Support cond_op for HFmode

[Hongtao Liu via Gcc-patches]

On Fri, Sep 24, 2021 at 10:16 AM Hongyu Wang via Gcc-patches
 wrote:
>
> > >This patch extend the expanders for cond_op to support vector HF modes.
> > >bootstraped and regtested on x86_64-pc-linux-gnu{-m32,}.
> > Do runtime tests passe on sde{-m32,}?
>
> Yes, forgot to mention this.
>
> Liu, Hongtao via Gcc-patches  于2021年9月23日周四 下午5:31写道：
>
> >
> >
> >
> > >-Original Message-
> > >From: Wang, Hongyu 
> > >Sent: Thursday, September 23, 2021 5:16 PM
> > >To: Liu, Hongtao 
> > >Cc: gcc-patches@gcc.gnu.org
> > >Subject: [PATCH] AVX512FP16: Support cond_op for HFmode
> > >
> > >Hi,
> > >
> > >This patch extend the expanders for cond_op to support vector HF modes.
> > >bootstraped and regtested on x86_64-pc-linux-gnu{-m32,}.
> > Do runtime tests passe on sde{-m32,}?
> > >Ok for master?
Ok.
> > >
> > >gcc/ChangeLog:
> > >
> > >   * config/i386/sse.md (cond_): Extend to support
> > >   vector HFmodes.
> > >   (cond_mul): Likewise.
> > >   (cond_div): Likewise.
> > >   (cond_): Likewise.
> > >   (cond_fma): Likewise.
> > >   (cond_fms): Likewise.
> > >   (cond_fnma): Likewise.
> > >   (cond_fnms): Likewise.
> > >
> > >gcc/testsuite/ChangeLog:
> > >
> > >   * gcc.target/i386/cond_op_addsubmuldiv__Float16-1.c: New test.
> > >   * gcc.target/i386/cond_op_addsubmuldiv__Float16-2.c: Ditto.
> > >   * gcc.target/i386/cond_op_fma__Float16-1.c: Ditto.
> > >   * gcc.target/i386/cond_op_fma__Float16-2.c: Ditto.
> > >   * gcc.target/i386/cond_op_maxmin__Float16-1.c: Ditto.
> > >   * gcc.target/i386/cond_op_maxmin__Float16-2.c: Ditto.
> > >---
> > > gcc/config/i386/sse.md| 112 +-
> > > .../i386/cond_op_addsubmuldiv__Float16-1.c|   9 ++
> > > .../i386/cond_op_addsubmuldiv__Float16-2.c|   7 ++
> > > .../gcc.target/i386/cond_op_fma__Float16-1.c  |  20 
> > > .../gcc.target/i386/cond_op_fma__Float16-2.c  |   7 ++
> > > .../i386/cond_op_maxmin__Float16-1.c  |   8 ++
> > > .../i386/cond_op_maxmin__Float16-2.c  |   6 +
> > > 7 files changed, 113 insertions(+), 56 deletions(-)  create mode 100644
> > >gcc/testsuite/gcc.target/i386/cond_op_addsubmuldiv__Float16-1.c
> > > create mode 100644
> > >gcc/testsuite/gcc.target/i386/cond_op_addsubmuldiv__Float16-2.c
> > > create mode 100644 gcc/testsuite/gcc.target/i386/cond_op_fma__Float16-1.c
> > > create mode 100644 gcc/testsuite/gcc.target/i386/cond_op_fma__Float16-2.c
> > > create mode 100644
> > >gcc/testsuite/gcc.target/i386/cond_op_maxmin__Float16-1.c
> > > create mode 100644
> > >gcc/testsuite/gcc.target/i386/cond_op_maxmin__Float16-2.c
> > >
> > >diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md index
> > >1ca95984afc..c2eeb7b1517 100644
> > >--- a/gcc/config/i386/sse.md
> > >+++ b/gcc/config/i386/sse.md
> > >@@ -2118,12 +2118,12 @@
> > >   [(set_attr "isa" "noavx,noavx,avx,avx")])
> > >
> > > (define_expand "cond_"
> > >-  [(set (match_operand:VF 0 "register_operand")
> > >-  (vec_merge:VF
> > >-(plusminus:VF
> > >-  (match_operand:VF 2 "vector_operand")
> > >-  (match_operand:VF 3 "vector_operand"))
> > >-(match_operand:VF 4 "nonimm_or_0_operand")
> > >+  [(set (match_operand:VFH 0 "register_operand")
> > >+  (vec_merge:VFH
> > >+(plusminus:VFH
> > >+  (match_operand:VFH 2 "vector_operand")
> > >+  (match_operand:VFH 3 "vector_operand"))
> > >+(match_operand:VFH 4 "nonimm_or_0_operand")
> > > (match_operand: 1 "register_operand")))]
> > >   " == 64 || TARGET_AVX512VL"
> > > {
> > >@@ -2207,12 +2207,12 @@
> > >(set_attr "mode" "")])
> > >
> > > (define_expand "cond_mul"
> > >-  [(set (match_operand:VF 0 "register_operand")
> > >-  (vec_merge:VF
> > >-(mult:VF
> > >-  (match_operand:VF 2 "vector_operand")
> > >-  (match_operand:VF 3 "vector_operand"))
> > >-(match_operand:VF 4 "nonimm_or_0_operand")
> > >+  [(set (match_operand:VFH 0 "register_operand")
> > >+  (vec_merge:VFH
> > >+(mult:VFH
> > >+  (match_operand:VFH 2 "vector_operand")
> > >+  (match_operand:VFH 3 "vector_operand"))
> > >+(match_operand:VFH 4 "nonimm_or_0_operand")
> > > (match_operand: 1 "register_operand")))]
> > >   " == 64 || TARGET_AVX512VL"
> > > {
> > >@@ -2322,12 +2322,12 @@
> > > })
> > >
> > > (define_expand "cond_div"
> > >-  [(set (match_operand:VF 0 "register_operand")
> > >-  (vec_merge:VF
> > >-(div:VF
> > >-  (match_operand:VF 2 "register_operand")
> > >-  (match_operand:VF 3 "vector_operand"))
> > >-(match_operand:VF 4 "nonimm_or_0_operand")
> > >+  [(set (match_operand:VFH 0 "register_operand")
> > >+  (vec_merge:VFH
> > >+(div:VFH
> > >+  (match_operand:VFH 2 "register_operand")
> > >+  (match_operand:VFH 3 "vector_operand"))
> > >+(match_operand:VFH 4 "nonimm_or_0_operand")
> > > (match_operand: 1 

Re: [PATCH] AVX512FP16: Support cond_op for HFmode

[Hongyu Wang via Gcc-patches]

> >This patch extend the expanders for cond_op to support vector HF modes.
> >bootstraped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Do runtime tests passe on sde{-m32,}?

Yes, forgot to mention this.

Liu, Hongtao via Gcc-patches  于2021年9月23日周四 下午5:31写道：

>
>
>
> >-Original Message-
> >From: Wang, Hongyu 
> >Sent: Thursday, September 23, 2021 5:16 PM
> >To: Liu, Hongtao 
> >Cc: gcc-patches@gcc.gnu.org
> >Subject: [PATCH] AVX512FP16: Support cond_op for HFmode
> >
> >Hi,
> >
> >This patch extend the expanders for cond_op to support vector HF modes.
> >bootstraped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Do runtime tests passe on sde{-m32,}?
> >Ok for master?
> >
> >gcc/ChangeLog:
> >
> >   * config/i386/sse.md (cond_): Extend to support
> >   vector HFmodes.
> >   (cond_mul): Likewise.
> >   (cond_div): Likewise.
> >   (cond_): Likewise.
> >   (cond_fma): Likewise.
> >   (cond_fms): Likewise.
> >   (cond_fnma): Likewise.
> >   (cond_fnms): Likewise.
> >
> >gcc/testsuite/ChangeLog:
> >
> >   * gcc.target/i386/cond_op_addsubmuldiv__Float16-1.c: New test.
> >   * gcc.target/i386/cond_op_addsubmuldiv__Float16-2.c: Ditto.
> >   * gcc.target/i386/cond_op_fma__Float16-1.c: Ditto.
> >   * gcc.target/i386/cond_op_fma__Float16-2.c: Ditto.
> >   * gcc.target/i386/cond_op_maxmin__Float16-1.c: Ditto.
> >   * gcc.target/i386/cond_op_maxmin__Float16-2.c: Ditto.
> >---
> > gcc/config/i386/sse.md| 112 +-
> > .../i386/cond_op_addsubmuldiv__Float16-1.c|   9 ++
> > .../i386/cond_op_addsubmuldiv__Float16-2.c|   7 ++
> > .../gcc.target/i386/cond_op_fma__Float16-1.c  |  20 
> > .../gcc.target/i386/cond_op_fma__Float16-2.c  |   7 ++
> > .../i386/cond_op_maxmin__Float16-1.c  |   8 ++
> > .../i386/cond_op_maxmin__Float16-2.c  |   6 +
> > 7 files changed, 113 insertions(+), 56 deletions(-)  create mode 100644
> >gcc/testsuite/gcc.target/i386/cond_op_addsubmuldiv__Float16-1.c
> > create mode 100644
> >gcc/testsuite/gcc.target/i386/cond_op_addsubmuldiv__Float16-2.c
> > create mode 100644 gcc/testsuite/gcc.target/i386/cond_op_fma__Float16-1.c
> > create mode 100644 gcc/testsuite/gcc.target/i386/cond_op_fma__Float16-2.c
> > create mode 100644
> >gcc/testsuite/gcc.target/i386/cond_op_maxmin__Float16-1.c
> > create mode 100644
> >gcc/testsuite/gcc.target/i386/cond_op_maxmin__Float16-2.c
> >
> >diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md index
> >1ca95984afc..c2eeb7b1517 100644
> >--- a/gcc/config/i386/sse.md
> >+++ b/gcc/config/i386/sse.md
> >@@ -2118,12 +2118,12 @@
> >   [(set_attr "isa" "noavx,noavx,avx,avx")])
> >
> > (define_expand "cond_"
> >-  [(set (match_operand:VF 0 "register_operand")
> >-  (vec_merge:VF
> >-(plusminus:VF
> >-  (match_operand:VF 2 "vector_operand")
> >-  (match_operand:VF 3 "vector_operand"))
> >-(match_operand:VF 4 "nonimm_or_0_operand")
> >+  [(set (match_operand:VFH 0 "register_operand")
> >+  (vec_merge:VFH
> >+(plusminus:VFH
> >+  (match_operand:VFH 2 "vector_operand")
> >+  (match_operand:VFH 3 "vector_operand"))
> >+(match_operand:VFH 4 "nonimm_or_0_operand")
> > (match_operand: 1 "register_operand")))]
> >   " == 64 || TARGET_AVX512VL"
> > {
> >@@ -2207,12 +2207,12 @@
> >(set_attr "mode" "")])
> >
> > (define_expand "cond_mul"
> >-  [(set (match_operand:VF 0 "register_operand")
> >-  (vec_merge:VF
> >-(mult:VF
> >-  (match_operand:VF 2 "vector_operand")
> >-  (match_operand:VF 3 "vector_operand"))
> >-(match_operand:VF 4 "nonimm_or_0_operand")
> >+  [(set (match_operand:VFH 0 "register_operand")
> >+  (vec_merge:VFH
> >+(mult:VFH
> >+  (match_operand:VFH 2 "vector_operand")
> >+  (match_operand:VFH 3 "vector_operand"))
> >+(match_operand:VFH 4 "nonimm_or_0_operand")
> > (match_operand: 1 "register_operand")))]
> >   " == 64 || TARGET_AVX512VL"
> > {
> >@@ -2322,12 +2322,12 @@
> > })
> >
> > (define_expand "cond_div"
> >-  [(set (match_operand:VF 0 "register_operand")
> >-  (vec_merge:VF
> >-(div:VF
> >-  (match_operand:VF 2 "register_operand")
> >-  (match_operand:VF 3 "vector_operand"))
> >-(match_operand:VF 4 "nonimm_or_0_operand")
> >+  [(set (match_operand:VFH 0 "register_operand")
> >+  (vec_merge:VFH
> >+(div:VFH
> >+  (match_operand:VFH 2 "register_operand")
> >+  (match_operand:VFH 3 "vector_operand"))
> >+(match_operand:VFH 4 "nonimm_or_0_operand")
> > (match_operand: 1 "register_operand")))]
> >   " == 64 || TARGET_AVX512VL"
> > {
> >@@ -2660,12 +2660,12 @@
> >(set_attr "mode" "HF")])
> >
> > (define_expand "cond_"
> >-  [(set (match_operand:VF 0 "register_operand")
> >-  (vec_merge:VF
> >-(smaxmin:VF
> >-  (match_operand:VF 2 "vector_operand")
> >-  

Re: [PATCH] [GCC12] Mention Intel AVX512-FP16 and _Float16 support.

[H.J. Lu via Gcc-patches]

On Thu, Sep 23, 2021 at 6:58 PM Hongtao Liu  wrote:
>
> On Fri, Sep 24, 2021 at 9:42 AM H.J. Lu  wrote:
> >
> > On Thu, Sep 23, 2021 at 6:38 PM Hongtao Liu  wrote:
> > >
> > > On Fri, Sep 24, 2021 at 9:20 AM H.J. Lu  wrote:
> > > >
> > > > On Thu, Sep 23, 2021 at 6:17 PM liuhongt  wrote:
> > > > >
> > > > > Updated, mention _Float16 support.
> > > > >
> > > > > ---
> > > > >  htdocs/gcc-12/changes.html | 13 -
> > > > >  1 file changed, 12 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
> > > > > index 81f62fe3..f19c6718 100644
> > > > > --- a/htdocs/gcc-12/changes.html
> > > > > +++ b/htdocs/gcc-12/changes.html
> > > > > @@ -165,7 +165,18 @@ a work-in-progress.
> > > > >
> > > > >  
> > > > >
> > > > > -
> > > > > +IA-32/x86-64
> > > > > +
> > > > > +  New ISA extension support for Intel AVX512-FP16 was added to 
> > > > > GCC.
> > > > > +  AVX512FP16 intrinsics are available via the 
> > > > > -mavx512fp16
> > > > > +  compiler switch.
> > > > > +  
> > > > > +  For both C and C++, The _Float16 type is 
> > > > > supported on
> > > > > +  x86 systems with SSE2 enabled. Without 
> > > > > {-mavx512fp16},
> > > > > +  _Float16 type is storage only, all operations 
> > > > > will be
> > > >
> > > > I don't think _Float16 is storage only without AVX512FP16.
> > > >
> > > I guess you're meaning that psABI is available for _Float16 even w/o
> > > AVX512-FP16.
> > >
> > > How about
> > >
> > > +  For both C and C++, The _Float16 type is supported on
> > > +  x86 systems with SSE2 enabled. Without {-mavx512fp16},
> > > +  no real AVX512-FP16 instructions are generated, all operations 
> > > will be
> >
> > No need for "no real AVX512-FP16 instructions are generated".
> Updated.
>
> -
> +IA-32/x86-64
> +
> +  New ISA extension support for Intel AVX512-FP16 was added to GCC.
> +  AVX512FP16 intrinsics are available via the -mavx512fp16
> +  compiler switch.
> +  
> +  For both C and C++, The _Float16 type is supported on
> +  x86 systems with SSE2 enabled. Without {-mavx512fp16},
> +  all operations will be emulated by software emulation and the
> +  float instructions.
> +  
> +

LGTM.

Thanks.

> >
> > > +  emulated by software emulation and the float 
> > > instructions.
> > > +  
> > >
> > > > > +  emulated by software emulation and the float 
> > > > > instructions.
> > > > > +  
> > > > > +
> > > > >
> > > > >  
> > > > >
> > > > > --
> > > > > 2.18.1
> > > > >
> > > >
> > > >
> > > > --
> > > > H.J.
> > >
> > >
> > >
> > > --
> > > BR,
> > > Hongtao
> >
> >
> >
> > --
> > H.J.
>
>
>
> --
> BR,
> Hongtao



-- 
H.J.

Re: [PATCH] [GCC12] Mention Intel AVX512-FP16 and _Float16 support.

[Hongtao Liu via Gcc-patches]

On Fri, Sep 24, 2021 at 9:42 AM H.J. Lu  wrote:
>
> On Thu, Sep 23, 2021 at 6:38 PM Hongtao Liu  wrote:
> >
> > On Fri, Sep 24, 2021 at 9:20 AM H.J. Lu  wrote:
> > >
> > > On Thu, Sep 23, 2021 at 6:17 PM liuhongt  wrote:
> > > >
> > > > Updated, mention _Float16 support.
> > > >
> > > > ---
> > > >  htdocs/gcc-12/changes.html | 13 -
> > > >  1 file changed, 12 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
> > > > index 81f62fe3..f19c6718 100644
> > > > --- a/htdocs/gcc-12/changes.html
> > > > +++ b/htdocs/gcc-12/changes.html
> > > > @@ -165,7 +165,18 @@ a work-in-progress.
> > > >
> > > >  
> > > >
> > > > -
> > > > +IA-32/x86-64
> > > > +
> > > > +  New ISA extension support for Intel AVX512-FP16 was added to GCC.
> > > > +  AVX512FP16 intrinsics are available via the 
> > > > -mavx512fp16
> > > > +  compiler switch.
> > > > +  
> > > > +  For both C and C++, The _Float16 type is supported 
> > > > on
> > > > +  x86 systems with SSE2 enabled. Without 
> > > > {-mavx512fp16},
> > > > +  _Float16 type is storage only, all operations will 
> > > > be
> > >
> > > I don't think _Float16 is storage only without AVX512FP16.
> > >
> > I guess you're meaning that psABI is available for _Float16 even w/o
> > AVX512-FP16.
> >
> > How about
> >
> > +  For both C and C++, The _Float16 type is supported on
> > +  x86 systems with SSE2 enabled. Without {-mavx512fp16},
> > +  no real AVX512-FP16 instructions are generated, all operations will 
> > be
>
> No need for "no real AVX512-FP16 instructions are generated".
Updated.

-
+IA-32/x86-64
+
+  New ISA extension support for Intel AVX512-FP16 was added to GCC.
+  AVX512FP16 intrinsics are available via the -mavx512fp16
+  compiler switch.
+  
+  For both C and C++, The _Float16 type is supported on
+  x86 systems with SSE2 enabled. Without {-mavx512fp16},
+  all operations will be emulated by software emulation and the
+  float instructions.
+  
+

>
> > +  emulated by software emulation and the float 
> > instructions.
> > +  
> >
> > > > +  emulated by software emulation and the float 
> > > > instructions.
> > > > +  
> > > > +
> > > >
> > > >  
> > > >
> > > > --
> > > > 2.18.1
> > > >
> > >
> > >
> > > --
> > > H.J.
> >
> >
> >
> > --
> > BR,
> > Hongtao
>
>
>
> --
> H.J.



-- 
BR,
Hongtao

Reporting lto bugs

[Eugene Rozenfeld via Gcc]

I ran into a bug with lto: no line number info gets emitted when building my 
project with -flto and -g (with gcc 8.2). I'd like to provide a repro in the 
bug report but I don't know if there is an easy way to collect everything.
The instructions at https://gcc.gnu.org/bugs/ seem to cover non-lto 
compilations.
For MSVC there is an easy way to collect linker repro files for ltcg: 
https://docs.microsoft.com/en-us/cpp/overview/how-to-report-a-problem-with-the-visual-cpp-toolset?view=msvc-160#link-repros
Is there something similar for GCC?

Thanks,

Eugene

Re: [PATCH] [GCC12] Mention Intel AVX512-FP16 and _Float16 support.

[H.J. Lu via Gcc-patches]

On Thu, Sep 23, 2021 at 6:38 PM Hongtao Liu  wrote:
>
> On Fri, Sep 24, 2021 at 9:20 AM H.J. Lu  wrote:
> >
> > On Thu, Sep 23, 2021 at 6:17 PM liuhongt  wrote:
> > >
> > > Updated, mention _Float16 support.
> > >
> > > ---
> > >  htdocs/gcc-12/changes.html | 13 -
> > >  1 file changed, 12 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
> > > index 81f62fe3..f19c6718 100644
> > > --- a/htdocs/gcc-12/changes.html
> > > +++ b/htdocs/gcc-12/changes.html
> > > @@ -165,7 +165,18 @@ a work-in-progress.
> > >
> > >  
> > >
> > > -
> > > +IA-32/x86-64
> > > +
> > > +  New ISA extension support for Intel AVX512-FP16 was added to GCC.
> > > +  AVX512FP16 intrinsics are available via the 
> > > -mavx512fp16
> > > +  compiler switch.
> > > +  
> > > +  For both C and C++, The _Float16 type is supported on
> > > +  x86 systems with SSE2 enabled. Without {-mavx512fp16},
> > > +  _Float16 type is storage only, all operations will be
> >
> > I don't think _Float16 is storage only without AVX512FP16.
> >
> I guess you're meaning that psABI is available for _Float16 even w/o
> AVX512-FP16.
>
> How about
>
> +  For both C and C++, The _Float16 type is supported on
> +  x86 systems with SSE2 enabled. Without {-mavx512fp16},
> +  no real AVX512-FP16 instructions are generated, all operations will be

No need for "no real AVX512-FP16 instructions are generated".

> +  emulated by software emulation and the float instructions.
> +  
>
> > > +  emulated by software emulation and the float 
> > > instructions.
> > > +  
> > > +
> > >
> > >  
> > >
> > > --
> > > 2.18.1
> > >
> >
> >
> > --
> > H.J.
>
>
>
> --
> BR,
> Hongtao



-- 
H.J.

Re: [PATCH] [GCC12] Mention Intel AVX512-FP16 and _Float16 support.

[Hongtao Liu via Gcc-patches]

On Fri, Sep 24, 2021 at 9:20 AM H.J. Lu  wrote:
>
> On Thu, Sep 23, 2021 at 6:17 PM liuhongt  wrote:
> >
> > Updated, mention _Float16 support.
> >
> > ---
> >  htdocs/gcc-12/changes.html | 13 -
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
> > index 81f62fe3..f19c6718 100644
> > --- a/htdocs/gcc-12/changes.html
> > +++ b/htdocs/gcc-12/changes.html
> > @@ -165,7 +165,18 @@ a work-in-progress.
> >
> >  
> >
> > -
> > +IA-32/x86-64
> > +
> > +  New ISA extension support for Intel AVX512-FP16 was added to GCC.
> > +  AVX512FP16 intrinsics are available via the -mavx512fp16
> > +  compiler switch.
> > +  
> > +  For both C and C++, The _Float16 type is supported on
> > +  x86 systems with SSE2 enabled. Without {-mavx512fp16},
> > +  _Float16 type is storage only, all operations will be
>
> I don't think _Float16 is storage only without AVX512FP16.
>
I guess you're meaning that psABI is available for _Float16 even w/o
AVX512-FP16.

How about

+  For both C and C++, The _Float16 type is supported on
+  x86 systems with SSE2 enabled. Without {-mavx512fp16},
+  no real AVX512-FP16 instructions are generated, all operations will be
+  emulated by software emulation and the float instructions.
+  

> > +  emulated by software emulation and the float 
> > instructions.
> > +  
> > +
> >
> >  
> >
> > --
> > 2.18.1
> >
>
>
> --
> H.J.



-- 
BR,
Hongtao

Re: [PATCH] [GCC12] Mention Intel AVX512-FP16 and _Float16 support.

[H.J. Lu via Gcc-patches]

On Thu, Sep 23, 2021 at 6:17 PM liuhongt  wrote:
>
> Updated, mention _Float16 support.
>
> ---
>  htdocs/gcc-12/changes.html | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
> index 81f62fe3..f19c6718 100644
> --- a/htdocs/gcc-12/changes.html
> +++ b/htdocs/gcc-12/changes.html
> @@ -165,7 +165,18 @@ a work-in-progress.
>
>  
>
> -
> +IA-32/x86-64
> +
> +  New ISA extension support for Intel AVX512-FP16 was added to GCC.
> +  AVX512FP16 intrinsics are available via the -mavx512fp16
> +  compiler switch.
> +  
> +  For both C and C++, The _Float16 type is supported on
> +  x86 systems with SSE2 enabled. Without {-mavx512fp16},
> +  _Float16 type is storage only, all operations will be

I don't think _Float16 is storage only without AVX512FP16.

> +  emulated by software emulation and the float instructions.
> +  
> +
>
>  
>
> --
> 2.18.1
>


-- 
H.J.

[PATCH] [GCC12] Mention Intel AVX512-FP16 and _Float16 support.

[liuhongt via Gcc-patches]

Updated, mention _Float16 support.

---
 htdocs/gcc-12/changes.html | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 81f62fe3..f19c6718 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -165,7 +165,18 @@ a work-in-progress.
   
 
 
-
+IA-32/x86-64
+
+  New ISA extension support for Intel AVX512-FP16 was added to GCC.
+  AVX512FP16 intrinsics are available via the -mavx512fp16
+  compiler switch.
+  
+  For both C and C++, The _Float16 type is supported on
+  x86 systems with SSE2 enabled. Without {-mavx512fp16},
+  _Float16 type is storage only, all operations will be
+  emulated by software emulation and the float instructions.
+  
+
 
 
 
-- 
2.18.1

Re: [PATCH] PR fortran/102458 - ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136

[Jerry D via Gcc-patches]

Harald,

Looks good. OK and thanks for your time and efforts.

Jerry

On 9/23/21 12:47 PM, Harald Anlauf via Fortran wrote:

Dear Fortranners,

we missed certain intrinsics as being disallowed in constant expressions,
which lead to an ICE when these intrinsics were used in a specification
expression with an initializer.  The intrinsics in question are listed in
F2018:10.1.2.

As discussed in the PR, Steve recommended to omit TRANSFER from that list,
as it is special and might need separate treatment.  I also could not come
up with a case where TRANSFER should not have simplified to a constant and
we would run into an issue.  (We could leave that job to Gerhard... ;-).

However, in testing I encountered a case involving TRANSFER that is not
properly simplified, which seems orthogonal to the present case.  I would
like to handle this separately.  This case is mentioned in the testcase,
but commented out.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald

Re: [PATCH] c++: fix wrong fixit hints for misspelled typedef [PR77565]

[Michel Morin via Gcc-patches]

On Fri, Sep 24, 2021 at 5:29 AM Jason Merrill  wrote:
>
> On Wed, Sep 22, 2021 at 7:05 PM Michel Morin  wrote:
>
> On Thu, Sep 23, 2021 at 5:09 AM Jason Merrill  wrote:
>  >
>  > On 9/21/21 20:53, Michel Morin wrote:
>  > > On Tue, Sep 21, 2021 at 5:24 AM Jason Merrill
>  wrote:
>  > >>
>  > >> On 9/17/21 13:31, Michel Morin wrote:
>  > >>> On Fri, Sep 17, 2021 at 3:23 AM Jason Merrill
>  wrote:
>  > 
>  >  On 9/16/21 11:50, Michel Morin wrote:
>  > > On Thu, Sep 16, 2021 at 5:44 AM Jason Merrill
>  wrote:
>  > >>
>  > >> On 9/14/21 04:29, Michel Morin via Gcc-patches wrote:
>  > >>> On Tue, Sep 14, 2021 at 7:14 AM David Malcolm
>  wrote:
>  > 
>  >  On Tue, 2021-09-14 at 03:35 +0900, Michel Morin via
> Gcc-patches wrote:
>  > > Hi,
>  > >
>  > > PR77565 reports that, with the code `typdef int Int;`,
> GCC emits
>  > > "did you mean 'typeof'?" instead of "did you mean
> 'typedef'?".
>  > >
>  > > This happens because the typo corrector determines that
> `typeof` is a
>  > > candidate for suggestion (through
>  > > `cp_keyword_starts_decl_specifier_p`),
>  > > but `typedef` is not.
>  > >
>  > > This patch fixes the issue by adding `typedef` as a
> candidate. The
>  > > patch
>  > > additionally adds the `inline` specifier and
> cv-specifiers as a
>  > > candidate.
>  > > Here is a patch (tests `make check-gcc` pass on darwin):
>  > 
>  >  Thanks for this patch (and for reporting the bug in the
> first place).
>  > 
>  >  I notice that, as well as being used for fix-it hints by
>  >  lookup_name_fuzzy (indirectly via suggest_rid_p),
>  >  cp_keyword_starts_decl_specifier_p is also used by
>  >  cp_lexer_next_token_is_decl_specifier_keyword, which is
> used by
>  >  cp_parser_lambda_declarator_opt and
> cp_parser_constructor_declarator_p.
>  > >>>
>  > >>> Ah, you're right! Thank you for pointing this out.
>  > >>> I failed to grep those functions somehow.
>  > >>>
>  > >>> One thing that confuses me is that
> cp_keyword_starts_decl_specifier_p
>  > >>> misses many keywords that can start decl-specifiers (e.g.
>  > >>> typedef/inline/cv-qual and friend/explicit/virtual).
>  > >>> So let's wait C++ frontend maintainers ;)
>  > >>
>  > >> That is strange.  Let's add all the rest of them as well.
>  > >
>  > > Done. Thanks for your help!
>  > >
>  > > One more thing — cp_keyword_starts_decl_specifier_p
> includes RID_ATTRIBUTE
>  > > (from the beginning; see https://gcc.gnu.org/PR28261 ), but
> attributes are
>  > > not decl-specifiers. Would it be reasonable to remove this?
>  > 
>  >  It looks like the place that PR28261 used
>  >  cp_lexer_next_token_is_decl_specifier_keyword specifically
> exempts
>  >  attributes:
>  > 
>  > > &&
> (!cp_lexer_next_token_is_decl_specifier_keyword (parser->lexer)
>  > > /* GNU attributes can actually appear both
> at the start of
>  > >a parameter and parenthesized declarator.
>  > >S (__attribute__((unused)) int);
>  > >is a constructor, but
>  > >S (__attribute__((unused)) foo) (int);
>  > >is a function declaration.  */
>  > > || (cp_parser_allow_gnu_extensions_p (parser)
>  > > &&
> cp_next_tokens_can_be_gnu_attribute_p (parser)))
>  > 
>  >  So yes, let's remove RID_ATTRIBUTE and the || clause there.
> I'd keep
>  >  the comment, but move it to go with the test for C++11
> attributes below.
>  > >>>
>  > >>> Done. No regressions introduced.
>  > >>>
>  > > One more thing — cp_keyword_starts_decl_specifier_p
> includes RID_ATTRIBUTE
>  > > (from the beginning; see https://gcc.gnu.org/PR28261 ), but
> attributes are
>  > > not decl-specifiers.
>  > >>>
>  > >>> Oh, this is wrong. I thought that, since C++11 attributes are
> not a
>  > >>> decl-specifier, neither are GNU attributes. But the comment
> just before
>  > >>> cp_parser_decl_specifier_seq says that GNU attributes are
> considered as a
>  > >>> decl-specifier. So I'm not confident about the removal of
> RID_ATTRIBUTE in
>  > >>> cp_keyword_starts_decl_specifier_p...
>  > >>
>  > >> GNU attributes can appear in lots of places, and the only two
>

[Bug ipa/102474] [12 regression] Crash in ipa-modref compiling Go code

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102474

Andrew Pinski  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
  Component|tree-optimization   |ipa

--- Comment #1 from Andrew Pinski  ---
  /* We assume that containment and lossless merging
 was tested earlier.  */
  gcc_checking_assert (!contains (a) && !a.contains (*this)
   && !merge (a, record_adjustments));
  gcc_checking_assert (parm_offset_known && a.parm_offset_known);

[Bug tree-optimization/102474] [12 regression] Crash in ipa-modref compiling Go code

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102474

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |12.0

[Bug target/102472] Infinite loop on m68k

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102472

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug fortran/101320] Bind(C): Missing diagnostic for constraint C1557 on allocatable/pointer arguments

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101320

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Sandra Loosemore :

https://gcc.gnu.org/g:2646d0e06b170569be1da28fce1d6e2f03a15f60

commit r12-3871-g2646d0e06b170569be1da28fce1d6e2f03a15f60
Author: Sandra Loosemore 
Date:   Thu Sep 23 08:03:52 2021 -0700

Fortran: Diagnose default-initialized pointer/allocatable dummies

TS29113 changed what was then C516 in the 2010 Fortran standard (now
C1557 in F2018) from disallowing all of pointer, allocatable, and
optional attributes on dummy arguments to BIND(C) functions, to
disallowing only pointer/allocatable with default-initialization.
gfortran was previously failing to diagnose violations of this
constraint.

2021-09-23  Sandra Loosemore  

PR fortran/101320

gcc/fortran/
* decl.c (gfc_verify_c_interop_param): Handle F2018 C1557,
aka TS29113 C516.

gcc/testsuite/
* gfortran.dg/c-interop/c516.f90: Remove xfails.  Add more
tests.

[PATCH, Fortran] Add missing diagnostic for F2018 C711 (TS29113 C407c)

[Sandra Loosemore]

Here's another missing-diagnostic patch for the Fortran front end, this 
time for PR Fortran/101333.  OK to commit?


-Sandra
commit 53171e748e28901693ca4362ff658883dab97e13
Author: Sandra Loosemore 
Date:   Thu Sep 23 15:00:43 2021 -0700

Fortran: Add missing diagnostic for F2018 C711 (TS29113 C407c)

2021-09-23  Sandra Loosemore  

	PR Fortran/101333

gcc/fortran/
	* interface.c (compare_parameter): Enforce F2018 C711.

gcc/testsuite/
	* gfortran.dg/c-interop/c407c-1.f90: Remove xfails.

diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index dae4b95..a2fea0e 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -2448,6 +2448,21 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
   return false;
 }
 
+  /* TS29113 C407c; F2018 C711.  */
+  if (actual->ts.type == BT_ASSUMED
+  && symbol_rank (formal) == -1
+  && actual->rank != -1
+  && !(actual->symtree->n.sym->as
+	   && actual->symtree->n.sym->as->type == AS_ASSUMED_SHAPE))
+{
+  if (where)
+	gfc_error ("Assumed-type actual argument at %L corresponding to "
+		   "assumed-rank dummy argument %qs must be "
+		   "assumed-shape or assumed-rank",
+		   >where, formal->name);
+  return false;
+}
+
   /* F2008, 12.5.2.5; IR F08/0073.  */
   if (formal->ts.type == BT_CLASS && formal->attr.class_ok
   && actual->expr_type != EXPR_NULL
diff --git a/gcc/testsuite/gfortran.dg/c-interop/c407c-1.f90 b/gcc/testsuite/gfortran.dg/c-interop/c407c-1.f90
index e4da66a..c77e6ac 100644
--- a/gcc/testsuite/gfortran.dg/c-interop/c407c-1.f90
+++ b/gcc/testsuite/gfortran.dg/c-interop/c407c-1.f90
@@ -44,7 +44,7 @@ subroutine s2 (x)
   implicit none
   type(*) :: x(*)
 
-  call g (x, 1)  ! { dg-error "Assumed.type" "pr101333" { xfail *-*-* } }
+  call g (x, 1)  ! { dg-error "Assumed.type" }
 end subroutine
 
 ! Check that a scalar gives an error.
@@ -53,7 +53,7 @@ subroutine s3 (x)
   implicit none
   type(*) :: x
 
-  call g (x, 1)  ! { dg-error "Assumed.type" "pr101333" { xfail *-*-* } }
+  call g (x, 1)  ! { dg-error "Assumed.type" }
 end subroutine
 
 ! Explicit-shape assumed-type actual arguments are forbidden implicitly

[Bug sanitizer/102317] signed integer overflow sanitizer cannot work well with -fno-strict-overflow

[kees at outflux dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317

--- Comment #11 from Kees Cook  ---
The trouble with "optimize" is that it just doesn't work. The kernel has banned
its use because it results in all other optimization options being forgotten
for the function in question.

gcc-9-20210923 is now available

[GCC Administrator via Gcc]

Snapshot gcc-9-20210923 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/9-20210923/
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 fb21e85a3acaf1f8db872518b7a0a2664a0458dd

You'll find:

 gcc-9-20210923.tar.xzComplete GCC

  SHA256=183fe75a826b02fa51c8a5ffb4123d7746ba4565c34b718abec598ba5e8dc2c6
  SHA1=69cfe424ad710af6cfd8898242ef1919a69f33e7

Diffs from 9-20210916 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.

Someone I have my own personal information my old personal data on my old Gmail all around my Samsung all account my Google Drive data AND YouTube channel personal URL number And My all domain name,s

[Kuljit Kaur via Gcc]

Sent from my iPhone

[Bug target/102140] [12 Regression] ICE: in extract_constrain_insn, at recog.c:2670 (insn does not satisfy its constraints) with -Og -fipa-cp -fno-tree-ccp -fno-tree-ter

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102140

--- Comment #4 from Segher Boessenkool  ---
Confirmed.  Doesn't need -mlittle or -mabi=elfv2, or -mcpu=power8 even, but
does need -mvsx.

Re: [PATCH v3] Fix ICE when mixing VLAs and statement expressions [PR91038]

[Jason Merrill via Gcc-patches]

On 9/23/21 15:49, Uecker, Martin wrote:

Am Mittwoch, den 22.09.2021, 17:18 -0400 schrieb Jason Merrill:

On 9/5/21 15:14, Uecker, Martin wrote:

Here is the third version of the patch. This also
fixes the index zero case.  Thus, this should be
a complete fix for 91038 and should fix all cases
also supported by clang.  Still not working is
returning a struct of variable size from a
statement expression (29970) when the size depends
on computations inside the statement expression.

Bootstrapped and regression tested
on x86-64 for all languages.

Martin




Fix ICE when mixing VLAs and statement expressions [PR91038]

When returning VM-types from statement expressions, this can
lead to an ICE when declarations from the statement expression
are referred to later. Most of these issues can be addressed by
gimplifying the base expression earlier in gimplify_compound_lval.
Another issue is fixed by not reording some size-related expressions
during folding. This fixes PR91038 and some of the test cases
from PR29970 (structs with VLA members need further work).

  
  2021-08-01  Martin Uecker  
  
  gcc/

PR c/91038
PR c/29970
* gimplify.c (gimplify_var_or_parm_decl): Update comment.
(gimplify_compound_lval): Gimplify base expression first.
(gimplify_target_expr): Do not gimplify size expression.
* fold-const.c (fold_binary_loc): Do not reorder SAVE_EXPR
in pointer arithmetic for variably modified types.
  
  gcc/testsuite/

PR c/91038
PR c/29970
* gcc.dg/vla-stexp-3.c: New test.
* gcc.dg/vla-stexp-4.c: New test.
* gcc.dg/vla-stexp-5.c: New test.
* gcc.dg/vla-stexp-6.c: New test.
* gcc.dg/vla-stexp-7.c: New test.
* gcc.dg/vla-stexp-8.c: New test.
* gcc.dg/vla-stexp-9.c: New test.


diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index ff23f12f33c..1e6f50692b5 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -10854,7 +10854,15 @@ fold_binary_loc (location_t loc, enum tree_code code, 
tree type,
  return build2_loc (loc, COMPOUND_EXPR, type, TREE_OPERAND (arg0, 0),
 tem);
}
-  if (TREE_CODE (arg1) == COMPOUND_EXPR)
+  /* This interleaves execution of the two sub-expressions
+which is allowed in C.  For pointer arithmetic when the
+the pointer has a variably modified type, the right expression
+might have a SAVE_EXPR which depends on the left expr, so
+do not fold in this case.  */
+  if (TREE_CODE (arg1) == COMPOUND_EXPR
+ && !(code == POINTER_PLUS_EXPR
+  && TREE_CODE (TREE_OPERAND (arg1, 0)) == SAVE_EXPR)
+  && variably_modified_type_p (type, NULL_TREE))


This seems pretty fragile.  If the problem is that the SAVE_EXPR depends
on a statement-expr on the LHS, can't that happen with expressions other
than POINTER_PLUS_EXPR?


I intentionally limited the change to this specific
case to avoid accidentally breaking or pessimizing
anything else. I did not notice any other cases that
need fixing. It is of course possible that
I have missed some...



Maybe we should include the statement-expr in the SAVE_EXPR?


I am not really sure how to implement this.


Nor am I, I'm not at all familiar with the VLA handling code.  But if 
the generated trees rely on evaluation happening with a stricter order 
than is actually guaranteed, that seems like a bug in the generation of 
the expression trees, not the folding code.


Could someone that knows more about VLA weigh in?


Maybe we could apply this patch first (because
I have to work around this bug in a couple of
projects which is a bit annoying)? I am happy
to implement an alternative later if there is
a better way (which I can understand).


The gimplify_compound_lval change is OK now.

What's the rationale for the gimplify_target_expr change?


{
  tem = fold_build2_loc (loc, code, type, op0,
 fold_convert_loc (loc, TREE_TYPE (op1),
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 99d1c7fcce4..8ee205f593c 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -2840,7 +2840,10 @@ gimplify_var_or_parm_decl (tree *expr_p)
declaration, for which we've already issued an error.  It would
be really nice if the front end wouldn't leak these at all.
Currently the only known culprit is C++ destructors, as seen
- in g++.old-deja/g++.jason/binding.C.  */
+ in g++.old-deja/g++.jason/binding.C.
+ Another possible culpit are size expressions for variably modified
+ types which are lost in the FE or not gimplified correctly.
+  */
 if (VAR_P (decl)
 && !DECL_SEEN_IN_BIND_EXPR_P (decl)
 && !TREE_STATIC (decl) && !DECL_EXTERNAL (decl)
@@ -2985,16 +2988,22 @@ gimplify_compound_lval (tree *expr_p, gimple_seq 
*pre_p, gimple_seq
*post_p,
expression until we deal with any variable bounds, sizes, or

byte/char string representation (Was: [PATCH] Fix byte char and byte string lexing code)

[Mark Wielaard]

On Thu, Sep 23, 2021 at 04:10:59PM +0200, Arthur Cohen wrote:
> > Something I was thinking about outside of the scope of that patch was
> about the utf8 how do they get represented? Is it some kind of wchar_t?
> 
> Do you mean in C++ or in rustc? In rustc, they are represented as Unicode
> Scalar Values which are 4 bytes wide.
> 
> From the docs over here: [https://doc.rust-lang.org/std/primitive.char.html]
> 
> So I'm assuming they could be represented as `int32_t`s which would also
> make sense for the check

Yes, for rust characters a 32bit type (I would pick uint32_t or maybe
char32_t) makes sense, since chars in rust are (almost) equal to
unicode code points (technically only 21 bits are used). But not
really, it is a Unicode scalar value, which excludes high-surrogate
and low-surrogate code points and so the only valid values are 0x0 to
0xD7FF and 0xE000 to 0x10.

We should not use the C type wchar_t, because wchar_t is
implementation defined and can be 16 or 32 bits.

See also https://doc.rust-lang.org/reference/types/textual.html

But utf8 strings are made up of u8 "utf8 chars". You need 1 to 4 utf8
chars to encode a code point. https://en.wikipedia.org/wiki/UTF-8
We can use c++ strings made up of (8 bit) chars for that.

Our lexer should make sure we only accept valid rust characters or
utf-8 sequences.

Note that the above doesn't hold for "byte chars" (b'A') or "byte
strings" (b"abc"). Those are really just u8 or [u8] arrays which hold
bytes (0x0 to 0xff).

We currently get the type for byte strings wrong. We pretend they are
, but they really should be &[u8].

I tried to fix that with the following:

diff --git a/gcc/rust/typecheck/rust-hir-type-check-expr.h 
b/gcc/rust/typecheck/rust-hir-type-check-expr.h
index fe8973a4d81..b0dd1c3ff2c 100644
--- a/gcc/rust/typecheck/rust-hir-type-check-expr.h
+++ b/gcc/rust/typecheck/rust-hir-type-check-expr.h
@@ -609,15 +609,42 @@ public:
break;
 
case HIR::Literal::LitType::BYTE_STRING: {
- /* We just treat this as a string, but it really is an arraytype of
-u8. It isn't in UTF-8, but really just a byte array.  */
- TyTy::BaseType *base = nullptr;
- auto ok = context->lookup_builtin ("str", );
+ /* This is an arraytype of u8 reference (&[u8;size]). It isn't in
+UTF-8, but really just a byte array. Code to construct the array
+reference copied from ArrayElemsValues and ArrayType. */
+ TyTy::BaseType *u8;
+ auto ok = context->lookup_builtin ("u8", );
  rust_assert (ok);
 
+ auto crate_num = mappings->get_current_crate ();
+ Analysis::NodeMapping mapping (crate_num, UNKNOWN_NODEID,
+mappings->get_next_hir_id (crate_num),
+UNKNOWN_LOCAL_DEFID);
+
+ /* Capacity is the size of the string (number of chars).
+It is a constant, but for fold it to get a BExpression.  */
+ std::string capacity_str = std::to_string (expr.as_string ().size ());
+ HIR::LiteralExpr literal_capacity (mapping, capacity_str,
+HIR::Literal::LitType::INT,
+PrimitiveCoreType::CORETYPE_USIZE,
+expr.get_locus ());
+
+ // mark the type for this implicit node
+ context->insert_type (mapping,
+   new TyTy::USizeType (mapping.get_hirid ()));
+
+ Bexpression *capacity
+   = ConstFold::ConstFoldExpr::fold (_capacity);
+
+ TyTy::ArrayType *array
+   = new TyTy::ArrayType (expr.get_mappings ().get_hirid (), capacity,
+  TyTy::TyVar (u8->get_ref ()));
+
+ context->insert_type (expr.get_mappings (), array);
+
  infered
= new TyTy::ReferenceType (expr.get_mappings ().get_hirid (),
-  TyTy::TyVar (base->get_ref ()), false);
+  TyTy::TyVar (array->get_ref ()), false);
}
break;
 
But that looks more complicated than is probably necessary and it
doesn't work. When the type checker wants to print this type
ReferenceType.as_string () goes into a loop for some reason.

Can anybody see what is wrong with the above?

Cheers,

Mark

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

[PATCH] real: fix encoding of negative IEEE double/quad values [PR98216]

[Patrick Palka via Gcc-patches]

In encode_ieee_double/quad, the assignment

  unsigned long VAL = r->sign << 31;

is intended to set the 31st bit of VAL whenever the given REAL_CST is
negative.  But on LP64 hosts it also unintentionally sets the upper 32
bits of VAL due to the promotion of r->sign from unsigned:1 to int and
the subsequent sign extension of the shifted value from int to long.

In the C++ frontend, this bug causes incorrect mangling of negative
double values due to the output of real_to_target during write_real_cst
unexpectedly having the upper 32 bits of each word set.  (I'm not sure
if/how this bug manifests itself outside of the frontend..)

This patch fixes this by avoiding the unwanted sign extension.  Note
that r0-53976 fixed the same bug in encode_ieee_single long ago.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk and perhaps the release branches?

PR c++/98216
PR c++/91292

gcc/ChangeLog:

* real.c (encode_ieee_double): Avoid incorrect sign extension.
(encode_ieee_quad): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/nontype-float2.C: New test.
---
 gcc/real.c  |  6 --
 gcc/testsuite/g++.dg/cpp2a/nontype-float2.C | 13 +
 2 files changed, 17 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/nontype-float2.C

diff --git a/gcc/real.c b/gcc/real.c
index 555cf44c142..8c7a47a69e6 100644
--- a/gcc/real.c
+++ b/gcc/real.c
@@ -3150,9 +3150,10 @@ encode_ieee_double (const struct real_format *fmt, long 
*buf,
const REAL_VALUE_TYPE *r)
 {
   unsigned long image_lo, image_hi, sig_lo, sig_hi, exp;
+  unsigned long sign = r->sign;
   bool denormal = (r->sig[SIGSZ-1] & SIG_MSB) == 0;
 
-  image_hi = r->sign << 31;
+  image_hi = sign << 31;
   image_lo = 0;
 
   if (HOST_BITS_PER_LONG == 64)
@@ -3938,10 +3939,11 @@ encode_ieee_quad (const struct real_format *fmt, long 
*buf,
  const REAL_VALUE_TYPE *r)
 {
   unsigned long image3, image2, image1, image0, exp;
+  unsigned long sign = r->sign;
   bool denormal = (r->sig[SIGSZ-1] & SIG_MSB) == 0;
   REAL_VALUE_TYPE u;
 
-  image3 = r->sign << 31;
+  image3 = sign << 31;
   image2 = 0;
   image1 = 0;
   image0 = 0;
diff --git a/gcc/testsuite/g++.dg/cpp2a/nontype-float2.C 
b/gcc/testsuite/g++.dg/cpp2a/nontype-float2.C
new file mode 100644
index 000..5db208a05d1
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/nontype-float2.C
@@ -0,0 +1,13 @@
+// PR c++/98216
+// { dg-do compile { target c++20 } }
+
+template void f() { }
+
+template void f<-1.0f>();
+template void f<-2.0f>();
+
+template void f<-1.0>();
+template void f<-2.0>();
+
+template void f<-1.0L>();
+template void f<-2.0L>();
-- 
2.33.0.514.g99c99ed825

Re: [PATCH] wwwdocs: [GCC12] Mention Intel AVX512-FP16.

[Joseph Myers]

On Thu, 23 Sep 2021, liuhongt via Gcc-patches wrote:

> +IA-32/x86-64
> +
> +  New ISA extension support for Intel AVX512-FP16 was added to GCC.
> +  AVX512FP16 intrinsics are available via the -mavx512fp16
> +  compiler switch.
> +

I think the support for _Float16 should be mentioned in the release notes 
as well.

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

[Bug tree-optimization/102474] New: [12 regression] Crash in ipa-modref compiling Go code

[ian at airs dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102474

Bug ID: 102474
   Summary: [12 regression] Crash in ipa-modref compiling Go code
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian at airs dot com
  Target Milestone: ---

Compiling this Go program with -O1 -fno-strict-aliasing crashes the compiler in
ipa-modref.

package p

type S struct {
f1 string
f2 interface{}
f3 string
f4 struct {
f41 uint32
f42 struct {
f421 int32
f422 uint32
}
}
f5 struct {
f51 *byte
f52 *byte
f53 *byte
}
f6 struct {
f61 int32
}
f7 struct {
f71 uint64
f72 int64
f73 *byte
}
f8 *byte
}

The crash I see is:

during IPA pass: modref
go1: internal compiler error: in forced_merge, at ipa-modref-tree.h:351
0xcbaff1 modref_access_node::forced_merge(modref_access_node const&, bool)
../../trunk/gcc/ipa-modref-tree.h:351
0xcbe389 modref_ref_node::insert_access(modref_access_node, unsigned long,
bool)
../../trunk/gcc/ipa-modref-tree.h:575
0xcbe8e3 modref_tree::insert(int, int, modref_access_node, bool)
../../trunk/gcc/ipa-modref-tree.h:844
0xcb65de propagate_unknown_call
../../trunk/gcc/ipa-modref.c:3418
0xcb6a69 modref_propagate_in_scc
../../trunk/gcc/ipa-modref.c:3598
0xcb740e execute
../../trunk/gcc/ipa-modref.c:3968
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Re: [PATCH] c++: fix wrong fixit hints for misspelled typedef [PR77565]

[Jason Merrill via Gcc-patches]

On Wed, Sep 22, 2021 at 7:05 PM Michel Morin  wrote:

   On Thu, Sep 23, 2021 at 5:09 AM Jason Merrill  wrote:
>
> On 9/21/21 20:53, Michel Morin wrote:
> > On Tue, Sep 21, 2021 at 5:24 AM Jason Merrill
wrote:
> >>
> >> On 9/17/21 13:31, Michel Morin wrote:
> >>> On Fri, Sep 17, 2021 at 3:23 AM Jason Merrill
wrote:
> 
>  On 9/16/21 11:50, Michel Morin wrote:
> > On Thu, Sep 16, 2021 at 5:44 AM Jason Merrill
wrote:
> >>
> >> On 9/14/21 04:29, Michel Morin via Gcc-patches wrote:
> >>> On Tue, Sep 14, 2021 at 7:14 AM David Malcolm
wrote:
> 
>  On Tue, 2021-09-14 at 03:35 +0900, Michel Morin via
   Gcc-patches wrote:
> > Hi,
> >
> > PR77565 reports that, with the code `typdef int Int;`,
   GCC emits
> > "did you mean 'typeof'?" instead of "did you mean
   'typedef'?".
> >
> > This happens because the typo corrector determines that
   `typeof` is a
> > candidate for suggestion (through
> > `cp_keyword_starts_decl_specifier_p`),
> > but `typedef` is not.
> >
> > This patch fixes the issue by adding `typedef` as a
   candidate. The
> > patch
> > additionally adds the `inline` specifier and
   cv-specifiers as a
> > candidate.
> > Here is a patch (tests `make check-gcc` pass on darwin):
> 
>  Thanks for this patch (and for reporting the bug in the
   first place).
> 
>  I notice that, as well as being used for fix-it hints by
>  lookup_name_fuzzy (indirectly via suggest_rid_p),
>  cp_keyword_starts_decl_specifier_p is also used by
>  cp_lexer_next_token_is_decl_specifier_keyword, which is
   used by
>  cp_parser_lambda_declarator_opt and
   cp_parser_constructor_declarator_p.
> >>>
> >>> Ah, you're right! Thank you for pointing this out.
> >>> I failed to grep those functions somehow.
> >>>
> >>> One thing that confuses me is that
   cp_keyword_starts_decl_specifier_p
> >>> misses many keywords that can start decl-specifiers (e.g.
> >>> typedef/inline/cv-qual and friend/explicit/virtual).
> >>> So let's wait C++ frontend maintainers ;)
> >>
> >> That is strange.  Let's add all the rest of them as well.
> >
> > Done. Thanks for your help!
> >
> > One more thing — cp_keyword_starts_decl_specifier_p
   includes RID_ATTRIBUTE
> > (from the beginning; see https://gcc.gnu.org/PR28261 ), but
   attributes are
> > not decl-specifiers. Would it be reasonable to remove this?
> 
>  It looks like the place that PR28261 used
>  cp_lexer_next_token_is_decl_specifier_keyword specifically
   exempts
>  attributes:
> 
> >             &&
   (!cp_lexer_next_token_is_decl_specifier_keyword (parser->lexer)
> >                 /* GNU attributes can actually appear both
   at the start of
> >                    a parameter and parenthesized declarator.
> >                    S (__attribute__((unused)) int);
> >                    is a constructor, but
> >                    S (__attribute__((unused)) foo) (int);
> >                    is a function declaration.  */
> >                 || (cp_parser_allow_gnu_extensions_p (parser)
> >                     &&
   cp_next_tokens_can_be_gnu_attribute_p (parser)))
> 
>  So yes, let's remove RID_ATTRIBUTE and the || clause there. 
   I'd keep
>  the comment, but move it to go with the test for C++11
   attributes below.
> >>>
> >>> Done. No regressions introduced.
> >>>
> > One more thing — cp_keyword_starts_decl_specifier_p
   includes RID_ATTRIBUTE
> > (from the beginning; see https://gcc.gnu.org/PR28261 ), but
   attributes are
> > not decl-specifiers.
> >>>
> >>> Oh, this is wrong. I thought that, since C++11 attributes are
   not a
> >>> decl-specifier, neither are GNU attributes. But the comment
   just before
> >>> cp_parser_decl_specifier_seq says that GNU attributes are
   considered as a
> >>> decl-specifier. So I'm not confident about the removal of
   RID_ATTRIBUTE in
> >>> cp_keyword_starts_decl_specifier_p...
> >>
> >> GNU attributes can appear in lots of places, and the only two
   callers of
> >> cp_parser_next_token_is_decl_specifier_keyword don't want to treat
> >> attributes accordingly.
> >
> > Makes sense.
> >
> >> Let's go with both your patches, and also
> >> remove the consequently-unnecessary attributes check in
> >> cp_parser_lambda_declarator_opt:
> >>
> >>>    if (cp_lexer_next_token_is_decl_specifier_keyword
   

[Bug c++/77565] `typdef int Int;` --> did you mean `typeof`?

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77565

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:eb9f099c3df2b1b4c5fb0fa25cfdfa3cb5fc817e

commit r12-3869-geb9f099c3df2b1b4c5fb0fa25cfdfa3cb5fc817e
Author: Michel Morin 
Date:   Thu Sep 16 23:29:54 2021 +0900

c++: add spellcheck suggestions for typedef etc. [PR77565]

cp_keyword_starts_decl_specifier_p misses many keywords that can
start decl-specifiers. This patch adds support for those keywords.

PR c++/77565

gcc/cp/ChangeLog:

* parser.c (cp_keyword_starts_decl_specifier_p): Handle more
decl-specifiers (typedef/inline/cv/explicit/virtual/friend).

gcc/testsuite/ChangeLog:

* g++.dg/spellcheck-pr77565.C: New test.

[Bug middle-end/102464] Miss optimization for (_Float16) sqrtf ((float) f16)

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102464

--- Comment #4 from joseph at codesourcery dot com  ---
Note that for fma this would only be valid for 
-funsafe-math-optimizations.

Re: [PATCH] libstdc++: Clear padding bits in atomic compare_exchange

[Jonathan Wakely via Gcc-patches]

On Thu, 23 Sep 2021, 20:07 Jakub Jelinek via Libstdc++, <
libstd...@gcc.gnu.org> wrote:

> On Thu, Sep 23, 2021 at 11:08:37AM -0700, Thomas Rodgers wrote:
> > From: Thomas Rodgers 
> >
> > This change implements P0528 which requires that padding bits not
> > participate in atomic compare exchange operations. All arguments to the
>
> Thanks for working on this.
>
> > generic template are 'sanitized' by the __builtin_clear_padding intrinsic
> > before they are used in atomic compare_exchange. This alrequires that any
> > stores also sanitize the incoming value.
>
> Not a review, just random nit.
> Shouldn't the __builtin_clear_padding calls be guarded with
> #if __has_builtin(__builtin_clear_padding)
> or #ifdef _GLIBCXX_HAVE_BUILTIN_CLEAR_PADDING defined based on that?
>

Yes. It can just use __has_builtin directly. All the compilers we care
about support that now.



I think clang doesn't support it (yet?), and it doesn't support the MSVC
> __builtin_zero_non_value_bits (with very similar, but slightly different,
> behavior).
>
> > Signed-off-by: Thomas Rodgers 
> >
> > libstdc++=v3/ChangeLog:
> >
> >   * include/std/atomic (atomic::atomic(_Tp) clear padding for
> >   __cplusplus > 201703L.
> >   (atomic::store()) Clear padding.
> >   (atomic::exchange()) Likewise.
> >   (atomic::compare_exchange_weak()) Likewise.
> >   (atomic::compare_exchange_strong()) Likewise.
> >   * testsuite/29_atomics/atomic/compare_exchange_padding.cc: New
> >   test.
>
> Jakub
>
>

Re: [PATCH] libstdc++: Clear padding bits in atomic compare_exchange

[Thomas Rodgers via Gcc-patches]

Agreed, I'll revise the patch to do so.

On Thu, Sep 23, 2021 at 12:07 PM Jakub Jelinek  wrote:

> On Thu, Sep 23, 2021 at 11:08:37AM -0700, Thomas Rodgers wrote:
> > From: Thomas Rodgers 
> >
> > This change implements P0528 which requires that padding bits not
> > participate in atomic compare exchange operations. All arguments to the
>
> Thanks for working on this.
>
> > generic template are 'sanitized' by the __builtin_clear_padding intrinsic
> > before they are used in atomic compare_exchange. This alrequires that any
> > stores also sanitize the incoming value.
>
> Not a review, just random nit.
> Shouldn't the __builtin_clear_padding calls be guarded with
> #if __has_builtin(__builtin_clear_padding)
> or #ifdef _GLIBCXX_HAVE_BUILTIN_CLEAR_PADDING defined based on that?
> I think clang doesn't support it (yet?), and it doesn't support the MSVC
> __builtin_zero_non_value_bits (with very similar, but slightly different,
> behavior).
>
> > Signed-off-by: Thomas Rodgers 
> >
> > libstdc++=v3/ChangeLog:
> >
> >   * include/std/atomic (atomic::atomic(_Tp) clear padding for
> >   __cplusplus > 201703L.
> >   (atomic::store()) Clear padding.
> >   (atomic::exchange()) Likewise.
> >   (atomic::compare_exchange_weak()) Likewise.
> >   (atomic::compare_exchange_strong()) Likewise.
> >   * testsuite/29_atomics/atomic/compare_exchange_padding.cc: New
> >   test.
>
> Jakub
>
>

[Bug fortran/102460] fortran internal compile error in coverage.c

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102460

--- Comment #3 from anlauf at gcc dot gnu.org ---
Reduced testcase:

MODULE MOD2
  IMPLICIT NONE
CONTAINS
  SUBROUTINE SUB1()
  ENTRY ENTRY1()
  END SUBROUTINE SUB1
END MODULE MOD2

[Bug fortran/102460] fortran internal compile error in coverage.c

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102460

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to fail||12.0
   Last reconfirmed||2021-09-23
 Ever confirmed|0   |1

--- Comment #2 from anlauf at gcc dot gnu.org ---
Confirmed.

The issue disappears if I comment out the line

  ENTRY ENTRY1()

I also do not see it on 11-branch, but that may be related to my local build.

[Bug target/102472] Infinite loop on m68k

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102472

--- Comment #4 from Giulio Benetti  ---
Created attachment 51506
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51506=edit
Pre-processed loop.c(loop.s)

[Bug target/102472] Infinite loop on m68k

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102472

--- Comment #3 from Giulio Benetti  ---
Created attachment 51505
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51505=edit
Pre-processed loop.c(loop.i)

[Bug target/102472] Infinite loop on m68k

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102472

--- Comment #2 from Giulio Benetti  ---
Oh, I didn't know it could produce .i and .s even when hanging. But yes, that
happens before really building. So .i .s files follow.

Thank you and
Best regards

[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458

--- Comment #10 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2021-September/056571.html

Re: [PATCH v3] Fix ICE when mixing VLAs and statement expressions [PR91038]

[Uecker, Martin]

Am Mittwoch, den 22.09.2021, 17:18 -0400 schrieb Jason Merrill:
> On 9/5/21 15:14, Uecker, Martin wrote:
> > Here is the third version of the patch. This also
> > fixes the index zero case.  Thus, this should be
> > a complete fix for 91038 and should fix all cases
> > also supported by clang.  Still not working is
> > returning a struct of variable size from a
> > statement expression (29970) when the size depends
> > on computations inside the statement expression.
> > 
> > Bootstrapped and regression tested
> > on x86-64 for all languages.
> > 
> > Martin
> > 
> > 
> > 
> > 
> > Fix ICE when mixing VLAs and statement expressions [PR91038]
> > 
> > When returning VM-types from statement expressions, this can
> > lead to an ICE when declarations from the statement expression
> > are referred to later. Most of these issues can be addressed by
> > gimplifying the base expression earlier in gimplify_compound_lval.
> > Another issue is fixed by not reording some size-related expressions
> > during folding. This fixes PR91038 and some of the test cases
> > from PR29970 (structs with VLA members need further work).
> > 
> >  
> >  2021-08-01  Martin Uecker  
> >  
> >  gcc/
> > PR c/91038
> > PR c/29970
> > * gimplify.c (gimplify_var_or_parm_decl): Update comment.
> > (gimplify_compound_lval): Gimplify base expression first.
> > (gimplify_target_expr): Do not gimplify size expression.
> > * fold-const.c (fold_binary_loc): Do not reorder SAVE_EXPR
> > in pointer arithmetic for variably modified types.
> >  
> >  gcc/testsuite/
> > PR c/91038
> > PR c/29970
> > * gcc.dg/vla-stexp-3.c: New test.
> > * gcc.dg/vla-stexp-4.c: New test.
> > * gcc.dg/vla-stexp-5.c: New test.
> > * gcc.dg/vla-stexp-6.c: New test.
> > * gcc.dg/vla-stexp-7.c: New test.
> > * gcc.dg/vla-stexp-8.c: New test.
> > * gcc.dg/vla-stexp-9.c: New test.
> > 
> > 
> > diff --git a/gcc/fold-const.c b/gcc/fold-const.c
> > index ff23f12f33c..1e6f50692b5 100644
> > --- a/gcc/fold-const.c
> > +++ b/gcc/fold-const.c
> > @@ -10854,7 +10854,15 @@ fold_binary_loc (location_t loc, enum tree_code 
> > code, tree type,
> >   return build2_loc (loc, COMPOUND_EXPR, type, TREE_OPERAND (arg0, 0),
> >  tem);
> > }
> > -  if (TREE_CODE (arg1) == COMPOUND_EXPR)
> > +  /* This interleaves execution of the two sub-expressions
> > +which is allowed in C.  For pointer arithmetic when the
> > +the pointer has a variably modified type, the right expression
> > +might have a SAVE_EXPR which depends on the left expr, so
> > +do not fold in this case.  */
> > +  if (TREE_CODE (arg1) == COMPOUND_EXPR
> > + && !(code == POINTER_PLUS_EXPR
> > +  && TREE_CODE (TREE_OPERAND (arg1, 0)) == SAVE_EXPR)
> > +  && variably_modified_type_p (type, NULL_TREE))
> 
> This seems pretty fragile.  If the problem is that the SAVE_EXPR depends 
> on a statement-expr on the LHS, can't that happen with expressions other 
> than POINTER_PLUS_EXPR?

I intentionally limited the change to this specific
case to avoid accidentally breaking or pessimizing
anything else. I did not notice any other cases that
need fixing. It is of course possible that
I have missed some...

> 
> Maybe we should include the statement-expr in the SAVE_EXPR?

I am not really sure how to implement this.

Maybe we could apply this patch first (because
I have to work around this bug in a couple of
projects which is a bit annoying)? I am happy
to implement an alternative later if there is
a better way (which I can understand).

Martin



> > {
> >   tem = fold_build2_loc (loc, code, type, op0,
> >  fold_convert_loc (loc, TREE_TYPE (op1),
> > diff --git a/gcc/gimplify.c b/gcc/gimplify.c
> > index 99d1c7fcce4..8ee205f593c 100644
> > --- a/gcc/gimplify.c
> > +++ b/gcc/gimplify.c
> > @@ -2840,7 +2840,10 @@ gimplify_var_or_parm_decl (tree *expr_p)
> >declaration, for which we've already issued an error.  It would
> >be really nice if the front end wouldn't leak these at all.
> >Currently the only known culprit is C++ destructors, as seen
> > - in g++.old-deja/g++.jason/binding.C.  */
> > + in g++.old-deja/g++.jason/binding.C.
> > + Another possible culpit are size expressions for variably modified
> > + types which are lost in the FE or not gimplified correctly.
> > +  */
> > if (VAR_P (decl)
> > && !DECL_SEEN_IN_BIND_EXPR_P (decl)
> > && !TREE_STATIC (decl) && !DECL_EXTERNAL (decl)
> > @@ -2985,16 +2988,22 @@ gimplify_compound_lval (tree *expr_p, gimple_seq 
> > *pre_p, gimple_seq
> > *post_p,
> >expression until we deal with any variable bounds, sizes, or
> >positions in order to deal with PLACEHOLDER_EXPRs.
> >   
> > - So we do this in three steps.  First we deal with the annotations
> > - for any variables in the components, then we gimplify the base,

[PATCH] PR fortran/102458 - ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136

[Harald Anlauf via Gcc-patches]

Dear Fortranners,

we missed certain intrinsics as being disallowed in constant expressions,
which lead to an ICE when these intrinsics were used in a specification
expression with an initializer.  The intrinsics in question are listed in
F2018:10.1.2.

As discussed in the PR, Steve recommended to omit TRANSFER from that list,
as it is special and might need separate treatment.  I also could not come
up with a case where TRANSFER should not have simplified to a constant and
we would run into an issue.  (We could leave that job to Gerhard... ;-).

However, in testing I encountered a case involving TRANSFER that is not
properly simplified, which seems orthogonal to the present case.  I would
like to handle this separately.  This case is mentioned in the testcase,
but commented out.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald

Fortran - improve checking for intrinsics allowed in constant expressions

gcc/fortran/ChangeLog:

	PR fortran/102458
	* expr.c (is_non_constant_intrinsic): Check for intrinsics
	excluded in constant expressions (F2018:10.1.2).
	(gfc_is_constant_expr): Use that check.

gcc/testsuite/ChangeLog:

	PR fortran/102458
	* gfortran.dg/pr102458.f90: New test.

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 604e63e6164..5ad1c4f9523 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -990,6 +990,34 @@ done:
 }


+/* Standard intrinsics listed under F2018:10.1.2 (6), which are excluded in
+   constant expressions, except TRANSFER (c.f. item (8)), which would need
+   separate treatment.  */
+
+static bool
+is_non_constant_intrinsic (gfc_expr *e)
+{
+  if (e->expr_type == EXPR_FUNCTION
+  && e->value.function.isym)
+{
+  switch (e->value.function.isym->id)
+	{
+	  case GFC_ISYM_COMMAND_ARGUMENT_COUNT:
+	  case GFC_ISYM_GET_TEAM:
+	  case GFC_ISYM_NULL:
+	  case GFC_ISYM_NUM_IMAGES:
+	  case GFC_ISYM_TEAM_NUMBER:
+	  case GFC_ISYM_THIS_IMAGE:
+	return true;
+
+	default:
+	  return false;
+	}
+}
+  return false;
+}
+
+
 /* Determine if an expression is constant in the sense of F08:7.1.12.
  * This function expects that the expression has already been simplified.  */

@@ -1023,6 +1051,10 @@ gfc_is_constant_expr (gfc_expr *e)
   gcc_assert (e->symtree || e->value.function.esym
 		  || e->value.function.isym);

+  /* Check for intrinsics excluded in constant expressions.  */
+  if (e->value.function.isym && is_non_constant_intrinsic (e))
+	return false;
+
   /* Call to intrinsic with at least one argument.  */
   if (e->value.function.isym && e->value.function.actual)
 	{
diff --git a/gcc/testsuite/gfortran.dg/pr102458.f90 b/gcc/testsuite/gfortran.dg/pr102458.f90
new file mode 100644
index 000..555e4978fdb
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr102458.f90
@@ -0,0 +1,42 @@
+! { dg-do compile }
+! { dg-options "-fcoarray=lib" }
+! PR fortran/102458 - standard intrinsics excluded in constant expressions
+
+subroutine s1
+  integer :: a(command_argument_count()) = 1 ! { dg-error "Automatic array" }
+  print *, a
+end
+
+program p
+  block
+integer :: a(get_team()) = 1 ! { dg-error "Automatic array" }
+print *, a
+  end block
+end
+
+subroutine s2
+  integer :: a(num_images()) = 1 ! { dg-error "Automatic array" }
+  print *, a
+end
+
+function f()
+  block
+integer :: a(team_number()) = 0 ! { dg-error "Automatic array" }
+a = 1
+  end block
+end
+
+subroutine s3
+  integer :: a(this_image()) = 1 ! { dg-error "Automatic array" }
+  print *, a
+end
+
+subroutine s4
+  integer, parameter :: n = 4
+  integer, parameter :: x(transfer(n, n)) = 1 ! legal
+  integer:: y(transfer(n, n)) = 2 ! legal
+  integer, parameter :: k = size (x)  ! ok
+! integer, parameter :: m = size (y)  ! fails, tracked separately
+  print *, k, x, y
+  if (k /= size (y)) stop 1
+end

[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #8)
> I think TRANSFER needs to be handled differently.
> 
> From the same section of the Fortran standard, TRANSFER is
> rejected if the following does not apply.
> 
>(8) a reference to the intrinsic function TRANSFER where each
>argument is a constant expression and each ultimate pointer
>component of the SOURCE argument is disassociated,

yeah, I did that for the final patch.  Will submit soon.

> So, one should be able to do something like
> 
>integer,parameter :: n = 4
>integer,parameter :: x(transfer(n, n)) = 1
>print *, x
>end
> 
> which gfortran will give 
> 
> % gfortran10 -o z a.f90
> % ./z
>1   1   1   1

This is less of an issue.  We also currently fail on the following:

subroutine s4
  integer, parameter :: n = 4
  integer, parameter :: x(transfer(n, n)) = 1 ! legal
  integer:: y(transfer(n, n)) = 2 ! legal
  integer, parameter :: k = size (x) ! ok
  integer, parameter :: m = size (y) ! fails, tracked separately
  print *, k, x, y
  if (k /= size (y)) stop 1
end

For some reason we do not simplify SIZE(y), and this reason lies elsewhere.
And it is not touch by my patch.

> If you remove TRANSFER from the patch, it looks good to me.
> We can revisit TRANSFER when Gerhard breaks gfortran, again! ;-)

I'll bet he does, but don't hold your breath?

[Bug target/102472] Infinite loop on m68k

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102472

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-23
  Component|c   |target
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Keywords||compile-time-hog

--- Comment #1 from Andrew Pinski  ---
>In this case that we have an infinite loop, I don't know how provide .i and .s 
>files. Can you please point me some instruction for this case?

https://gcc.gnu.org/bugs/ has instructions on how to get the .i file. 
Basically add -save-temps to gcc command line (add -v too)

[Patch] Fortran: Fix associated intrinsic with assumed rank [PR101334] [was: [PATCH, Fortran] Fixes for F2018 C838 (PR fortran/101334)]

[Tobias Burnus]

On 20.09.21 09:58, Tobias Burnus wrote:


On 20.09.21 06:01, Sandra Loosemore wrote:

This patch fixes some bugs in handling of assumed-rank arguments
revealed by the TS29113 testsuite, ... giving a bogus error when
passing one as the first argument to the ASSOCIATED intrinsic.  ...


...  if I try the following testcase, which is now permitted, I get
two ICEs. Can you check?

* The first one seems to be a bug in gfc_conv_intrinsic_function, which
  assumes also for assumed rank that if the first argument is an array,
  the second argument must also be an array.

* For the second one, I see in the dump:
p->dim[p->dtype.rank + -1].stride
  is seems as '-1' is gfc_array_index_type while 'dtype.rank' is
signed_char_type_node.


I fixed that issue + extended the testcase.

OK for mainline?

Tobias

PS: Sorry for the testcase, it should have used a separate function for
scalar vs. array target, but it somehow evolved like that.

PPS: Pending patches: (1) this one, (2) "Fortran: Improve file-reading
error diagnostic [PR55534]" (third in the series), (3) "[Patch] Fortran:
Fix assumed-size to assumed-rank passing [PR94070]" – plus (4) GFC<->CFI
array-descriptor conversion patch, but I will repost an
extended/cleaned-up version soon.

-
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
Fortran: Fix associated intrinsic with assumed rank [PR101334]

ASSOCIATE (ptr, tgt) takes as first argument also an assumed-rank array;
however, using it together with a tgt (required to be non assumed rank)
had issues for both scalar and nonscalar tgt.

	PR fortran/101334
gcc/fortran/ChangeLog:

	* trans-intrinsic.c (gfc_conv_associated): Support assumed-rank
	'pointer' with scalar/array 'target' argument.

libgfortran/ChangeLog:

	* intrinsics/associated.c (associated): Also check for same rank.

gcc/testsuite/ChangeLog:

	* gfortran.dg/associated_assumed_rank.f90: New test.

 gcc/fortran/trans-intrinsic.c  |  30 +++--
 .../gfortran.dg/associated_assumed_rank.f90| 126 +
 libgfortran/intrinsics/associated.c|   3 +-
 3 files changed, 149 insertions(+), 10 deletions(-)

diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 612ca41a016..60e94f0bdc2 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -8974,7 +8974,7 @@ gfc_conv_associated (gfc_se *se, gfc_expr *expr)
   gfc_se arg2se;
   tree tmp2;
   tree tmp;
-  tree nonzero_arraylen;
+  tree nonzero_arraylen = NULL_TREE;
   gfc_ss *ss;
   bool scalar;
 
@@ -9074,14 +9074,16 @@ gfc_conv_associated (gfc_se *se, gfc_expr *expr)
 	{
 	  tmp = gfc_conv_descriptor_rank (arg1se.expr);
 	  tmp = fold_build2_loc (input_location, MINUS_EXPR,
- TREE_TYPE (tmp), tmp, gfc_index_one_node);
+ TREE_TYPE (tmp), tmp,
+ build_int_cst (TREE_TYPE (tmp), 1));
 	}
 	  else
 	tmp = gfc_rank_cst[arg1->expr->rank - 1];
 	  tmp = gfc_conv_descriptor_stride_get (arg1se.expr, tmp);
-	  nonzero_arraylen = fold_build2_loc (input_location, NE_EXPR,
-	  logical_type_node, tmp,
-	  build_int_cst (TREE_TYPE (tmp), 0));
+	  if (arg2->expr->rank != 0)
+	nonzero_arraylen = fold_build2_loc (input_location, NE_EXPR,
+		logical_type_node, tmp,
+		build_int_cst (TREE_TYPE (tmp), 0));
 
 	  /* A pointer to an array, call library function _gfor_associated.  */
 	  arg1se.want_pointer = 1;
@@ -9091,16 +9093,26 @@ gfc_conv_associated (gfc_se *se, gfc_expr *expr)
 
 	  arg2se.want_pointer = 1;
 	  arg2se.force_no_tmp = 1;
-	  gfc_conv_expr_descriptor (, arg2->expr);
+	  if (arg2->expr->rank != 0)
+	gfc_conv_expr_descriptor (, arg2->expr);
+	  else
+	{
+	  gfc_conv_expr (, arg2->expr);
+	  arg2se.expr
+		= gfc_conv_scalar_to_descriptor (, arg2se.expr,
+		 gfc_expr_attr (arg2->expr));
+	  arg2se.expr = gfc_build_addr_expr (NULL_TREE, arg2se.expr);
+	}
 	  gfc_add_block_to_block (>pre, );
 	  gfc_add_block_to_block (>post, );
 	  se->expr = build_call_expr_loc (input_location,
   gfor_fndecl_associated, 2,
   arg1se.expr, arg2se.expr);
 	  se->expr = convert (logical_type_node, se->expr);
-	  se->expr = fold_build2_loc (input_location, TRUTH_AND_EXPR,
-  logical_type_node, se->expr,
-  nonzero_arraylen);
+	  if (arg2->expr->rank != 0)
+	se->expr = fold_build2_loc (input_location, TRUTH_AND_EXPR,
+	logical_type_node, se->expr,
+	nonzero_arraylen);
 }
 
   /* If target is present zero character length pointers cannot
diff --git a/gcc/testsuite/gfortran.dg/associated_assumed_rank.f90 b/gcc/testsuite/gfortran.dg/associated_assumed_rank.f90
new file mode 100644
index 000..f1b91998006
--- /dev/null
+++ 

Re: [PATCH] libstdc++: Clear padding bits in atomic compare_exchange

[Jakub Jelinek via Gcc-patches]

On Thu, Sep 23, 2021 at 11:08:37AM -0700, Thomas Rodgers wrote:
> From: Thomas Rodgers 
> 
> This change implements P0528 which requires that padding bits not
> participate in atomic compare exchange operations. All arguments to the

Thanks for working on this.

> generic template are 'sanitized' by the __builtin_clear_padding intrinsic
> before they are used in atomic compare_exchange. This alrequires that any
> stores also sanitize the incoming value.

Not a review, just random nit.
Shouldn't the __builtin_clear_padding calls be guarded with
#if __has_builtin(__builtin_clear_padding)
or #ifdef _GLIBCXX_HAVE_BUILTIN_CLEAR_PADDING defined based on that?
I think clang doesn't support it (yet?), and it doesn't support the MSVC
__builtin_zero_non_value_bits (with very similar, but slightly different,
behavior).

> Signed-off-by: Thomas Rodgers 
> 
> libstdc++=v3/ChangeLog:
> 
>   * include/std/atomic (atomic::atomic(_Tp) clear padding for
>   __cplusplus > 201703L.
>   (atomic::store()) Clear padding.
>   (atomic::exchange()) Likewise.
>   (atomic::compare_exchange_weak()) Likewise.
>   (atomic::compare_exchange_strong()) Likewise.
>   * testsuite/29_atomics/atomic/compare_exchange_padding.cc: New
>   test.

Jakub

[Bug c++/98216] [C++20] template mangling for double template argument is wrong

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98216

Patrick Palka  changed:

   What|Removed |Added

 CC||andrei.popa105 at yahoo dot com

--- Comment #7 from Patrick Palka  ---
*** Bug 102092 has been marked as a duplicate of this bug. ***

[Bug c++/102092] [C++2b] Passing argument to auto template parameter modifies the value of argument inside function

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102092

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED
 CC||ppalka at gcc dot gnu.org

--- Comment #4 from Patrick Palka  ---
Thanks for the bug report, confirmed.  It looks like the root cause is the same
as  PR98216, so I'm going to mark this bug a duplicate of that one.

*** This bug has been marked as a duplicate of bug 98216 ***

[Bug c++/98216] [C++20] template mangling for double template argument is wrong

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98216

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

Re: [PATCH v3] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

[Jason Merrill via Gcc-patches]

On 9/20/21 18:59, Marek Polacek via Gcc-patches wrote:

On Mon, Sep 20, 2021 at 09:08:09PM +0200, Jakub Jelinek wrote:

On Mon, Sep 20, 2021 at 02:37:03PM -0400, Marek Polacek wrote:

So, wouldn't be this better specified as
Wno-attributes=
Common Joined RejectNegative
(not sure if RejectNegative is actually needed for an option
starting with Wno- )?


Looks like RejectNegative is not needed.  I could do that, but I think
it regresses the diagnostic:

error: unrecognized command-line option '-Wattributes=attr::'
vs
error: arguments ignored for ‘-Wattributes=’; use ‘-Wno-attributes=’ instead

I prefer the latter.  (I've changed the warning into error.)


Ok.


+/* { dg-additional-options "-std=c++11" { target c++ } } */
+/* { dg-additional-options "-Wno-attributes=company::,yoyodyne::attr" } */
+/* { dg-additional-options "-Wno-attributes=c1::attr,c1::attr,c1::__attr__" } 
*/
+/* { dg-additional-options "-Wno-attributes=clang" } */
+/* { dg-additional-options "-Wno-attributes=c2::,c2::attr" } */
+/* { dg-additional-options "-Wno-attributes=c3::attr,c3::" } */
+/* { dg-additional-options "-Wno-attributes=x::," } */


Should the above be accepted (I mean trailing , ?)  What does that mean?
  
I'm thinking it should: the arguments to -Wno-attributes= could be

generated by a tool so accepting the trailing , might help, like in
enums etc.


I don't think we allow that for any other options that accept a list of
something (except maybe -W{p,c,a,l}, those just pass the args through).
Generating a list that has comma separation only in between items and not
at the end is trivial.


Hmm, ok, here's a version with that checking added.  Sadly it needs
to be handled before handle_ignored_attributes_option because of
strtok.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --
It is desirable for -Wattributes to warn about e.g.

[[deprecate]] void g(); // typo, should warn

However, -Wattributes also warns about vendor-specific attributes
(that's because lookup_scoped_attribute_spec -> find_attribute_namespace
finds nothing), which, with -Werror, causes grief.  We don't want the
-Wattributes warning for

[[company::attr]] void f();

GCC warns because it doesn't know the "company" namespace; it only knows
the "gnu" and "omp" namespaces.  We could entirely disable warning about
attributes in unknown scopes but then the compiler would also miss typos
like

   [[company::attrx]] void f();

or

   [[gmu::warn_used_result]] int write();

so that is not a viable solution.  A workaround is to use a #pragma:

   #pragma GCC diagnostic push
   #pragma GCC diagnostic ignored "-Wattributes"
   [[company::attr]] void f() {}
   #pragma GCC diagnostic pop

but that's a mouthful and awkward to use and could also hide typos.  In
fact, any macro-based solution doesn't seem like a way forward.

This patch implements -Wno-attributes=, which takes these arguments:

company::attr
company::
clang

The last one is a special option to ignore clang-only attributes; in
this patch it is accepted but currently has no effect.

This option should go well with using @file: the user could have a file
containing
-Wno-attributes=vendor::attr1,vendor::attr2
and then invoke gcc with '@attrs' or similar.

I've also added a new pragma which has the same effect:

The pragma along with the new option should help with various static
analysis tools.

PR c++/101940

gcc/ChangeLog:

* attribs.c (struct scoped_attributes): Add a bool member.
(lookup_scoped_attribute_spec): Forward declare.
(register_scoped_attributes): New bool parameter, defaulted to
false.  Use it.
(handle_ignored_attributes_option): New function.
(free_attr_data): New function.
(init_attributes): Call handle_ignored_attributes_option.
(attr_namespace_ignored_p): New function.
(decl_attributes): Check attr_namespace_ignored_p before
warning.
* attribs.h (free_attr_data): Declare.
(register_scoped_attributes): Adjust declaration.
(handle_ignored_attributes_option): Declare.
* common.opt (Wattributes=): New option with a variable.
* doc/extend.texi: Document #pragma GCC diagnostic ignored_attributes.
* doc/invoke.texi: Document -Wno-attributes=.
* opts.c (common_handle_option) : Handle.
* plugin.h (register_scoped_attributes): Adjust declaration.

gcc/c-family/ChangeLog:

* c-pragma.c (handle_pragma_diagnostic): Handle #pragma GCC diagnostic
ignored_attributes.

gcc/c/ChangeLog:

* c-decl.c (c_parse_final_cleanups): Call free_attr_data.

gcc/cp/ChangeLog:

* decl2.c (c_parse_final_cleanups): Call free_attr_data.

gcc/testsuite/ChangeLog:

* c-c++-common/Wno-attributes-1.c: New test.
* c-c++-common/Wno-attributes-2.c: New test.
---
  gcc/attribs.c | 126 +-
  gcc/attribs.h |   5 +-
  

[PATCH] libstdc++: Clear padding bits in atomic compare_exchange

[Thomas Rodgers]

From: Thomas Rodgers 

This change implements P0528 which requires that padding bits not
participate in atomic compare exchange operations. All arguments to the
generic template are 'sanitized' by the __builtin_clear_padding intrinsic
before they are used in atomic compare_exchange. This alrequires that any
stores also sanitize the incoming value.

Signed-off-by: Thomas Rodgers 

libstdc++=v3/ChangeLog:

* include/std/atomic (atomic::atomic(_Tp) clear padding for
__cplusplus > 201703L.
(atomic::store()) Clear padding.
(atomic::exchange()) Likewise.
(atomic::compare_exchange_weak()) Likewise.
(atomic::compare_exchange_strong()) Likewise.
* testsuite/29_atomics/atomic/compare_exchange_padding.cc: New
test.
---
 libstdc++-v3/include/std/atomic   | 23 +-
 .../atomic/compare_exchange_padding.cc| 42 +++
 2 files changed, 63 insertions(+), 2 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc

diff --git a/libstdc++-v3/include/std/atomic b/libstdc++-v3/include/std/atomic
index 936dd50ba1c..51450badace 100644
--- a/libstdc++-v3/include/std/atomic
+++ b/libstdc++-v3/include/std/atomic
@@ -228,7 +228,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   atomic& operator=(const atomic&) = delete;
   atomic& operator=(const atomic&) volatile = delete;
 
-  constexpr atomic(_Tp __i) noexcept : _M_i(__i) { }
+#if __cplusplus > 201703L
+  constexpr atomic(_Tp __i) noexcept : _M_i(__i)
+  { __builtin_clear_padding(std::__addressof(_M_i)); }
+#else
+  atomic(_Tp __i) noexcept : _M_i(__i)
+  { }
+#endif
 
   operator _Tp() const noexcept
   { return load(); }
@@ -268,12 +274,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   void
   store(_Tp __i, memory_order __m = memory_order_seq_cst) noexcept
   {
+   __builtin_clear_padding(std::__addressof(__i));
__atomic_store(std::__addressof(_M_i), std::__addressof(__i), int(__m));
   }
 
   void
   store(_Tp __i, memory_order __m = memory_order_seq_cst) volatile noexcept
   {
+   __builtin_clear_padding(std::__addressof(__i));
__atomic_store(std::__addressof(_M_i), std::__addressof(__i), int(__m));
   }
 
@@ -300,6 +308,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
 alignas(_Tp) unsigned char __buf[sizeof(_Tp)];
_Tp* __ptr = reinterpret_cast<_Tp*>(__buf);
+   __builtin_clear_padding(std::__addressof(__i));
__atomic_exchange(std::__addressof(_M_i), std::__addressof(__i),
  __ptr, int(__m));
return *__ptr;
@@ -311,6 +320,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
 alignas(_Tp) unsigned char __buf[sizeof(_Tp)];
_Tp* __ptr = reinterpret_cast<_Tp*>(__buf);
+   __builtin_clear_padding(std::__addressof(__i));
__atomic_exchange(std::__addressof(_M_i), std::__addressof(__i),
  __ptr, int(__m));
return *__ptr;
@@ -322,6 +332,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
__glibcxx_assert(__is_valid_cmpexch_failure_order(__f));
 
+   __builtin_clear_padding(std::__addressof(__e));
+   __builtin_clear_padding(std::__addressof(__i));
return __atomic_compare_exchange(std::__addressof(_M_i),
 std::__addressof(__e),
 std::__addressof(__i),
@@ -334,6 +346,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
__glibcxx_assert(__is_valid_cmpexch_failure_order(__f));
 
+   __builtin_clear_padding(std::__addressof(__e));
+   __builtin_clear_padding(std::__addressof(__i));
return __atomic_compare_exchange(std::__addressof(_M_i),
 std::__addressof(__e),
 std::__addressof(__i),
@@ -358,6 +372,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
__glibcxx_assert(__is_valid_cmpexch_failure_order(__f));
 
+   __builtin_clear_padding(std::__addressof(__e));
+   __builtin_clear_padding(std::__addressof(__i));
return __atomic_compare_exchange(std::__addressof(_M_i),
 std::__addressof(__e),
 std::__addressof(__i),
@@ -370,6 +386,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
__glibcxx_assert(__is_valid_cmpexch_failure_order(__f));
 
+   __builtin_clear_padding(std::__addressof(__e));
+   __builtin_clear_padding(std::__addressof(__i));
return __atomic_compare_exchange(std::__addressof(_M_i),
 std::__addressof(__e),
 std::__addressof(__i),
@@ -392,6 +410,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 void
 wait(_Tp __old, memory_order __m = memory_order_seq_cst) const noexcept
 {
+  __builtin_clear_padding(std::__addressof(__old));
   

Re: [RFC] c++: Allow parm use outside function body for constexpr members

[Barrett Adair via Gcc-patches]

I'm past this snag, so disregard this RFC for now. If I post again about
this, it will be with a working patch.

On Fri, Sep 17, 2021 at 11:15 AM Barrett Adair 
wrote:

> The WIP attached patch attempts to enable usage of parameters' constexpr
> members before the function body begins (see new tests dependent-expr11.C
> and dependent-expr12.C).
>
> Unfortunately, I hit a "vexing" snag: gcc/testsuite/g++.dg/parse/ambig7.C
> breaks with this patch. After several hours of debugging, here's what I
> think happens:
>
> In trunk, ambig7.C's testFail line compiles because the tentative parse --
> where "testFail" is a function and int(A) is a parameter type -- fails only
> when seeing that function uses "parameter outside function body" (the
> error removed by this patch). This occurs when parsing the template
> argument list, before calling finish_template_type.
>
> After applying the patch, the tentative parse still fails because
> function is not a type, but this only occurs after finish_template_type
> is called, which causes the incorrect template-id for function to be
> cached with broken arguments, such that function remains "unresolved
> overloaded function type":
>
> ambig7.C:16:36: error: no matching function for call to
> ‘Helper::Helper(int, )’
>16 | Helper testFail(int(A), function);
>
> Any suggestions on how to go about fixing this? For instance, is it
> possible to repair or roll back the cached template instantation?
>
>

[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or

[amacleod at redhat dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102463

Andrew Macleod  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #8 from Andrew Macleod  ---
Fixed.

[COMMITTED] tree-optimization/102463 - Look for a relation between operands only when possible.

[Andrew MacLeod via Gcc-patches]

The routnie that is trapping (relation_fold_and_or)  is looking to see 
if there are any relationships between dependencies that can be 
exploited. ie

   c_2 = a_6 > b_7
   c_3 = a_6 < b_7
   c_4 = c_2 && c_3
  if (c_4 != 0)

when trying to fold c_4,  it looks at c_2 and c_3, it notes that they 
both depend on the same 2 ssa-names,  a_6, and a_7.
It then queries whether there is a relationship between them when c_2 is 
[1,1] and c_3 is [1,1].   If so, it then tries to apply that relation to 
see if the stmt can never be true or not based on that raw relation.  
This allows it to determine the above condition can never be true.


In this case, the 2 defining stmts are both PHI nodes, which happen to 
have the same 2 ssa_names in the dependency list, so it matches the 
pattern being looked for:


  # ntdef_6 = PHI 
  # tdef_7 = PHI <_bfd_elf_merge_symbol_h.0_1(2), newdef_10(3)>
  _5 = __tdef_7 & ntdef_6

both names depend on the value of newdef_10 and 
_bfd_elf_merge_symbol_h.0_1, so a check is being made for a relationship 
between op1 and op2 in those stmts.


Whats missing is that we can only check for operand relationships in 
range-ops enabled stmts... The phi will never overtly give us a relation 
between the first and second operand, so no need to check.


Bootstrapped on x86_64-pc-linux-gnu with no regressions.  Pushed.

Andrew


>From fe4e6c824a580012bf9034cc33f0b440df93f56f Mon Sep 17 00:00:00 2001
From: Andrew MacLeod 
Date: Thu, 23 Sep 2021 09:32:00 -0400
Subject: [PATCH 2/2] Look for a relation between operands only when possible.

Do not look for a relation between 2 operands if there is no range-ops handler.

	gcc/
	PR tree-optimization/102463
	* gimple-range-fold.cc (fold_using_range::relation_fold_and_or): If
	there is no range-ops handler, don't look for a relation.

	gcc/testsuite/
	* gcc.dg/pr102463.c: New.
---
 gcc/gimple-range-fold.cc|  4 
 gcc/testsuite/gcc.dg/pr102463.c | 21 +
 2 files changed, 25 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr102463.c

diff --git a/gcc/gimple-range-fold.cc b/gcc/gimple-range-fold.cc
index 35324fd72c2..bb09b751a4e 100644
--- a/gcc/gimple-range-fold.cc
+++ b/gcc/gimple-range-fold.cc
@@ -1358,6 +1358,10 @@ fold_using_range::relation_fold_and_or (irange& lhs_range, gimple *s,
   range_operator *handler1 = gimple_range_handler (SSA_NAME_DEF_STMT (ssa1));
   range_operator *handler2 = gimple_range_handler (SSA_NAME_DEF_STMT (ssa2));
 
+  // If either handler is not present, no relation is found.
+  if (!handler1 || !handler2)
+return;
+
   int_range<2> bool_one (boolean_true_node, boolean_true_node);
 
   relation_kind relation1 = handler1->op1_op2_relation (bool_one);
diff --git a/gcc/testsuite/gcc.dg/pr102463.c b/gcc/testsuite/gcc.dg/pr102463.c
new file mode 100644
index 000..ca63f0b8767
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr102463.c
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+_Bool _bfd_elf_merge_symbol_h, _bfd_elf_merge_symbol_h_1;
+_Bool _bfd_elf_merge_symbol_olddef;
+_Bool bfd_is_com_section();
+
+void
+_bfd_elf_merge_symbol() {
+  _Bool newdef = bfd_is_com_section(), ntdef, tdef;
+  _bfd_elf_merge_symbol_olddef = _bfd_elf_merge_symbol_h;
+  if (_bfd_elf_merge_symbol_h_1) {
+ntdef = newdef;
+tdef = _bfd_elf_merge_symbol_h;
+  } else {
+ntdef = _bfd_elf_merge_symbol_h;
+tdef = newdef;
+  }
+  if (tdef && ntdef)
+;
+}
-- 
2.17.2

[COMMITTED] Ranger converted to a local edge flag instead of EDGE_EXECUTABLE.

[Andrew MacLeod via Gcc-patches]

This patch converts the Ranger ecosystem to use a local edge flag to 
represent a "not executable" edge rather than reusing the 
EDGE_EXECUTABLE flag.


This has multiple benefits,
 - No need to set all the flags on every edge before starting
 - No chance of interference from other passes which might be using the 
flag in a slightly different manner
 - IF we don't actual set the flag somewhere, it will have no impact 
anywhere
 - Multiple instances wouldn't interfere with each other..  but that 
probably not an issue anyway.


The implementation works as follows:

* Ranger will create a publicly available,  instance-local flag when it 
is instantiated.  When checking is enabled, it also verifies every edge 
is already clear, as expected.
* Ranger and the GORI engine check this flag to determine if an edge is 
not executable, and will return UNDEFINED for any requests on such edges.
* The gimple-range-fold and relation oracle classes all utilize 
UNDEFINED values for their work, so this is transparent to them and 
doesn't prevent them from being used by other clients without a flag.
* The simplifier accepts an optional flag value which it will set on 
edges and propagate when it changes the IL to cause an edge to be not 
executable.  This is done in parallel with whatever it use to do with 
EDGE_EXECUTABLE, and is thus transparent to other uses.  If no flag is 
provided, it does nothing.
* The simplifier also tracks when it sets this flag, and upon 
destruction, clears all flags which were set.
* the VRP pass provides the simplifier with the flag so that only during 
a VRP pass will the simplifer set the flag, and thus only then will the 
unexecutable flag work currently be triggered.


Ranger manages the non-executable flag independent of EDGE_EXECUTABLE 
now, and doesn't need to do any additional work unless its paired with a 
simplfier (or other mechanism) to set the flag on an edge.  It becomes a 
consumer of a flag which the client can optionally utilize.


Bootstraps on x86_64-pc-linux-gnu with no regressions, in both ranger 
only and hybrid modes.  Pushed.


Andrew

>From 053e1d642104d19d5f9e5fb08a9e7354a0db28f5 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod 
Date: Wed, 22 Sep 2021 16:58:22 -0400
Subject: [PATCH 1/2] Create a ranger-local flag for non-executable edges.

Instead of repurposing EDGE_EXECUTABLE, ranger creates a local flag and
ultizes it throughout.

	* gimple-range-cache.cc (ranger_cache::ranger_cache): Take
	non-executable_edge flag as parameter.
	* gimple-range-cache.h (ranger_cache): Adjust prototype.
	* gimple-range-gori.cc (gori_compute::gori_compute): Take
	non-executable_edge flag as parameter.
	(gori_compute::outgoing_edge_range_p): Check new flag.
	* gimple-range-gori.h (gori_compute): Adjust prototype.
	* gimple-range.cc (gimple_ranger::gimple_ranger): Create new flag.
	(gimple_ranger::range_on_edge): Check new flag.
	* gimple-range.h (gimple_ranger::non_executable_edge_flag): New.
	* gimple-ssa-evrp.c (rvrp_folder): Pass ranger flag to simplifer.
	(hybrid_folder::hybrid_folder): Set ranger non-executable flag value.
	(hybrid_folder::fold_stmt): Set flag value in the simplifer.
	* vr-values.c (simplify_using_ranges::set_and_propagate_unexecutable):
	Use not_executable flag if provided inmstead of EDGE_EXECUTABLE.
	(simplify_using_ranges::simplify_switch_using_ranges): Clear
	EDGE_EXECUTABLE like it originally did.
	(simplify_using_ranges::cleanup_edges_and_switches): Clear any
	NON_EXECUTABLE flags.
	(simplify_using_ranges::simplify_using_ranges): Adjust.
	* vr-values.h (class simplify_using_ranges): Adjust.
	(simplify_using_ranges::set_range_query): Add non-executable flag param.
---
 gcc/gimple-range-cache.cc |  3 ++-
 gcc/gimple-range-cache.h  |  2 +-
 gcc/gimple-range-gori.cc  |  5 +++--
 gcc/gimple-range-gori.h   |  7 ++-
 gcc/gimple-range.cc   | 22 ++
 gcc/gimple-range.h|  1 +
 gcc/gimple-ssa-evrp.c | 12 +---
 gcc/vr-values.c   | 24 ++--
 gcc/vr-values.h   |  8 ++--
 9 files changed, 64 insertions(+), 20 deletions(-)

diff --git a/gcc/gimple-range-cache.cc b/gcc/gimple-range-cache.cc
index b856b212169..61043d3f375 100644
--- a/gcc/gimple-range-cache.cc
+++ b/gcc/gimple-range-cache.cc
@@ -750,7 +750,8 @@ temporal_cache::set_always_current (tree name)
 
 // --
 
-ranger_cache::ranger_cache ()
+ranger_cache::ranger_cache (int not_executable_flag)
+		: m_gori (not_executable_flag)
 {
   m_workback.create (0);
   m_workback.safe_grow_cleared (last_basic_block_for_fn (cfun));
diff --git a/gcc/gimple-range-cache.h b/gcc/gimple-range-cache.h
index 3b55673fd29..4937a0b305a 100644
--- a/gcc/gimple-range-cache.h
+++ b/gcc/gimple-range-cache.h
@@ -92,7 +92,7 @@ private:
 class ranger_cache : public range_query
 {
 public:
-  ranger_cache ();
+  ranger_cache (int not_executable_flag);
   ~ranger_cache ();
 
   virtual 

[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102463

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

https://gcc.gnu.org/g:fe4e6c824a580012bf9034cc33f0b440df93f56f

commit r12-3868-gfe4e6c824a580012bf9034cc33f0b440df93f56f
Author: Andrew MacLeod 
Date:   Thu Sep 23 09:32:00 2021 -0400

Look for a relation between operands only when possible.

Do not look for a relation between 2 operands if there is no range-ops
handler.

gcc/
PR tree-optimization/102463
* gimple-range-fold.cc (fold_using_range::relation_fold_and_or): If
there is no range-ops handler, don't look for a relation.

gcc/testsuite/
* gcc.dg/pr102463.c: New.

[Bug ipa/102388] [12 Regression] ICE in duplicate, at ipa-prop.c:4436 since r12-2523-g13586172d0b70c9d

[jamborm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102388

--- Comment #2 from Martin Jambor  ---
I proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580183.html

[PATCH] ipa: Fix ICE when speculating calls from inlined functions (PR 102388)

[Martin Jambor]

Hi,

The code handling various cases which lead to call graph edge
duplication (in order to update reference descriptions used to track
and remove no-longer needed references) has missed one important case.

When edge duplication is an effect of creating a speculative edge for
an indirect edge which carries a constant jump function which had been
created from a pass-through function when the edge caller has was
inlined into one of its callers, the reference description attached to
the function describes an edge higher up in the "inlined" clone tree
and so even the new speculative edge will.  Therefore we should not
try to duplicate the reference description itself but rather just bump
the refcount of the existing one.

Creating a small testcase unfortunately is not very straightforward, I
have not attempted to trigger just the right speculation after inlining.

Bootstrapped and tested on an x86_64-linux.  OK for trunk?

Thanks,

Martin


gcc/ChangeLog:

2021-09-22  Martin Jambor  

PR ipa/102388
* ipa-prop.c (ipa_edge_args_sum_t::duplicate): Also handle the
case when the source reference description corresponds to a
referance taken in a function src->caller is inlined to.
---
 gcc/ipa-prop.c | 40 +++-
 1 file changed, 27 insertions(+), 13 deletions(-)

diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 1c69d9766c5..443f21ce61b 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -4428,19 +4428,33 @@ ipa_edge_args_sum_t::duplicate (cgraph_edge *src, 
cgraph_edge *dst,
dst_jf->value.constant.rdesc = NULL;
  else if (src->caller == dst->caller)
{
- struct ipa_ref *ref;
- symtab_node *n = symtab_node_for_jfunc (src_jf);
- gcc_checking_assert (n);
- ref = src->caller->find_reference (n, src->call_stmt,
-src->lto_stmt_uid);
- gcc_checking_assert (ref);
- dst->caller->clone_reference (ref, ref->stmt);
-
- struct ipa_cst_ref_desc *dst_rdesc = ipa_refdesc_pool.allocate ();
- dst_rdesc->cs = dst;
- dst_rdesc->refcount = src_rdesc->refcount;
- dst_rdesc->next_duplicate = NULL;
- dst_jf->value.constant.rdesc = dst_rdesc;
+ /* Creation of a speculative edge.  If the source edge is the one
+grabbing a reference, we must create a new (duplicate)
+reference description.  Otherwise they refer to the same
+description corresponding to a reference taken in a function
+src->caller is inlined to.  In that case we just must
+increment the refcount.  */
+ if (src_rdesc->cs == src)
+   {
+  symtab_node *n = symtab_node_for_jfunc (src_jf);
+  gcc_checking_assert (n);
+  ipa_ref *ref
+= src->caller->find_reference (n, src->call_stmt,
+   src->lto_stmt_uid);
+  gcc_checking_assert (ref);
+  dst->caller->clone_reference (ref, ref->stmt);
+
+  ipa_cst_ref_desc *dst_rdesc = ipa_refdesc_pool.allocate ();
+  dst_rdesc->cs = dst;
+  dst_rdesc->refcount = src_rdesc->refcount;
+  dst_rdesc->next_duplicate = NULL;
+  dst_jf->value.constant.rdesc = dst_rdesc;
+   }
+ else
+   {
+ src_rdesc->refcount++;
+ dst_jf->value.constant.rdesc = src_rdesc;
+   }
}
  else if (src_rdesc->cs == src)
{
-- 
2.33.0

[Bug fortran/93834] [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469

[burnus at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93834

Tobias Burnus  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||burnus at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #9 from Tobias Burnus  ---
FIXED. Thanks for the report.

Based on the discussion, it was decided that the code is was probably valid
(i.e. 'scalar[4]' is regarded as allocatable).

Cf. https://gcc.gnu.org/pipermail/fortran/2021-September/056486.html and in
particular Malcolm's judgement at
https://mailman.j3-fortran.org/pipermail/j3/2021-September/013322.html

Re: [PATCH, Fortran] Diagnose default-initialized pointer/allocatable dummies

[Tobias Burnus]

On 23.09.21 18:30, Sandra Loosemore wrote:

On 9/23/21 10:10 AM, Tobias Burnus wrote:

On 23.09.21 17:50, Sandra Loosemore wrote:

This patch is for PR101320, another issue related to missing bind(c)
diagnostics.  OK to commit?

LGTM - I am only ...

+  gfc_error ("Default-initialized %s dummy argument %qs "
+ "at %L is not permitted in BIND(C) procedure %qs",
+ (sym->attr.pointer ? "pointer" : "allocatable"),

... wondering how to best handle such strings for translators.
Namely, whether to duplicate the string and fill-in the %s, rewriting
it them to make it clearer for the translator ("dummy argument %qs
with %s attribute"), or leaving it as is.

I think the later is acceptable – thus, I assume you will choose that
option :-)


Well, "pointer" and "allocatable" are Fortran language keywords, not
just regular English words.


True but that does not solve the translator problem.

Assume the following isn't English "A %s dummy conflicts with ...", x ?
"allocatable" : "pointer"

How do you translate it? "An %s" for "An allocatable" or "A %s" for "A
pointer"? Similar issues occur all the time with languages, each having
its own special requirements.

But admittedly, there is no simple solution. In any case, I think I
wouldn't capitalize the pointer/allocatable as then those stand out -
while I think the 'default-initialized' is the more important (even
though all: it, allocatable/pointer + bind(C) are important).

And as you wrote, using %qs (%<...%>), capitalized and non-capitalized
keywords are all used a bit inconsistently.

And, as mentioned in the review, it is probably simplest to commit it as
submitted as there it no really convincing  solution to the translation
problem, I think.

Tobias

-
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

Re: [Patch] Fortran: Handle allocated() with coindexed scalars [PR93834] (was: [PATCH] PR fortran/93834 - [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469)

[Tobias Burnus]

Hi Harald,

On 22.09.21 21:47, Harald Anlauf via Fortran wrote:

while still feeling somewhat unsure (given my previous comment
and the discussion), I think your patch is basically OK.

However, your testcase has a { dg-do compile }, so it does not
really do any runtime tests.  Is that intended?  If so, please
add a respective comment, or adjust the testcase.


I have now moved the testcase to coarray/ and turned it into 'dg-do run'.

To make it a bit more interesting, I added allocate/deallocate plus some
more allocate() checks. Updating the -fdump-tree-original dump scans
took a small trickery as allocate/deallocate of a coarray has some extra
inlined checks (is allocated? did malloc work?) with -fcoarray=single
but puts the burden to the library for -fcoarray=lib. Fortunately, there
is a pointless cast for 'allocatable' which made it possible to
distinguish the ==/!= 0 checks.


Otherwise this LGTM.


Thanks for the review!

Tobias


-
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
commit 1b07d9dce6c51c98d011236c3d4cd84a2ed59ba2
Author: Tobias Burnus 
Date:   Thu Sep 23 18:47:45 2021 +0200

Fortran: Handle allocated() with coindexed scalars [PR93834]

While for an allocatable 'array', 'array(:)' and 'array(:)[1]' are
not allocatable, it is believed that not only 'scalar' but also
'scalar[1]' is allocatable.  However, coarrays are collectively
established/allocated; thus, 'allocated(scalar[i])' is equivalent
to 'allocated(scalar)'. [At least when assuming that 'i' does not
refer to a failed image.]

2021-09-23  Harald Anlauf  
Tobias Burnus  

PR fortran/93834
gcc/fortran/ChangeLog:

* trans-intrinsic.c (gfc_conv_allocated): Cleanup. Handle
coindexed scalar coarrays.

gcc/testsuite/ChangeLog:

* gfortran.dg/coarray/coarray_allocated.f90: New test.
---
 gcc/fortran/trans-intrinsic.c  | 55 +-
 .../gfortran.dg/coarray/coarray_allocated.f90  | 55 ++
 2 files changed, 89 insertions(+), 21 deletions(-)

diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 42a995be348..612ca41a016 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -8887,50 +8887,63 @@ caf_this_image_ref (gfc_ref *ref)
 static void
 gfc_conv_allocated (gfc_se *se, gfc_expr *expr)
 {
-  gfc_actual_arglist *arg1;
   gfc_se arg1se;
   tree tmp;
-  symbol_attribute caf_attr;
+  bool coindexed_caf_comp = false;
+  gfc_expr *e = expr->value.function.actual->expr;
 
   gfc_init_se (, NULL);
-  arg1 = expr->value.function.actual;
-
-  if (arg1->expr->ts.type == BT_CLASS)
+  if (e->ts.type == BT_CLASS)
 {
   /* Make sure that class array expressions have both a _data
 	 component reference and an array reference  */
-  if (CLASS_DATA (arg1->expr)->attr.dimension)
-	gfc_add_class_array_ref (arg1->expr);
+  if (CLASS_DATA (e)->attr.dimension)
+	gfc_add_class_array_ref (e);
   /*  whilst scalars only need the _data component.  */
   else
-	gfc_add_data_component (arg1->expr);
+	gfc_add_data_component (e);
 }
 
-  /* When arg1 references an allocatable component in a coarray, then call
+  /* When 'e' references an allocatable component in a coarray, then call
  the caf-library function caf_is_present ().  */
-  if (flag_coarray == GFC_FCOARRAY_LIB && arg1->expr->expr_type == EXPR_FUNCTION
-  && arg1->expr->value.function.isym
-  && arg1->expr->value.function.isym->id == GFC_ISYM_CAF_GET)
-caf_attr = gfc_caf_attr (arg1->expr->value.function.actual->expr);
-  else
-gfc_clear_attr (_attr);
-  if (flag_coarray == GFC_FCOARRAY_LIB && caf_attr.codimension
-  && !caf_this_image_ref (arg1->expr->value.function.actual->expr->ref))
-tmp = trans_caf_is_present (se, arg1->expr->value.function.actual->expr);
+  if (flag_coarray == GFC_FCOARRAY_LIB && e->expr_type == EXPR_FUNCTION
+  && e->value.function.isym
+  && e->value.function.isym->id == GFC_ISYM_CAF_GET)
+{
+  e = e->value.function.actual->expr;
+  if (gfc_expr_attr (e).codimension)
+	{
+	  /* Last partref is the coindexed coarray. As coarrays are collectively
+	 (de)allocated, the allocation status must be the same as the one of
+	 the local allocation.  Convert to local access. */
+	  for (gfc_ref *ref = e->ref; ref; ref = ref->next)
+	if (ref->type == REF_ARRAY && ref->u.ar.codimen)
+	  {
+		for (int i = ref->u.ar.dimen;
+		 i < ref->u.ar.dimen + ref->u.ar.codimen; ++i)
+		ref->u.ar.dimen_type[i] = DIMEN_THIS_IMAGE;
+		break;
+	  }
+	}
+  else if (!caf_this_image_ref (e->ref))
+	coindexed_caf_comp = true;
+}
+  if (coindexed_caf_comp)
+

[Bug fortran/93834] [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93834

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:1b07d9dce6c51c98d011236c3d4cd84a2ed59ba2

commit r12-3866-g1b07d9dce6c51c98d011236c3d4cd84a2ed59ba2
Author: Tobias Burnus 
Date:   Thu Sep 23 18:47:45 2021 +0200

Fortran: Handle allocated() with coindexed scalars [PR93834]

While for an allocatable 'array', 'array(:)' and 'array(:)[1]' are
not allocatable, it is believed that not only 'scalar' but also
'scalar[1]' is allocatable.  However, coarrays are collectively
established/allocated; thus, 'allocated(scalar[i])' is equivalent
to 'allocated(scalar)'. [At least when assuming that 'i' does not
refer to a failed image.]

2021-09-23  Harald Anlauf  
Tobias Burnus  

PR fortran/93834
gcc/fortran/ChangeLog:

* trans-intrinsic.c (gfc_conv_allocated): Cleanup. Handle
coindexed scalar coarrays.

gcc/testsuite/ChangeLog:

* gfortran.dg/coarray/coarray_allocated.f90: New test.

[Bug target/102473] New: 521.wrf_r 5% slower at -Ofast and generic x86_64 tuning after r12-3426-g8f323c712ea76c

[jamborm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102473

Bug ID: 102473
   Summary: 521.wrf_r 5% slower at -Ofast and generic x86_64
tuning after r12-3426-g8f323c712ea76c
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: crazylht at gmail dot com
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

All three x86_64 LNT machines have detected a 4.5-5.2% performance
regression of SPEC FPrate 2017 benchmarks 521.wrf_r when compiled with
-Ofast and the default (generic) march and mtune.

Zen2 based machine regressed by 5%:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=294.548.0
Zen1 based machine regressed by 5.2%:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=35.548.0
Kabylake based machine regressed by 4.5%:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=34.548.0

On an AMD zen2 based machine I have bisected the regression to commit
r12-3426-g8f323c712ea76c:

8f323c712ea76cc4506b03895e9b991e4e4b2baf is the first bad commit
commit 8f323c712ea76cc4506b03895e9b991e4e4b2baf
Author: liuhongt 
Date:   Tue Sep 7 12:39:04 2021 +0800

Optimize v4sf reduction.

gcc/ChangeLog:

PR target/101059
* config/i386/sse.md (reduc_plus_scal_): Split to ..
(reduc_plus_scal_v4sf): .. this, New define_expand.
(reduc_plus_scal_v2df): .. and this, New define_expand.


I have confirmed that the commit causes a similar regression on
another Intel Skylake server.

On the Zen2 machine, this is the difference in samples collected by
perf for different symbols (before is commit 60eec23b5ed, after commit
8f323c712ea):

| Symbol  | sys lib | Before | After | 
diff | % |
|-+-++---+---+---|
| __logf_fma  | yes |  68882 | 68940 |  
+58 | +0.08 |
| __atanf | yes |  4 | 66196 | 
-468 | -0.70 |
| __module_advect_em_MOD_advect_scalar_pd | no  |  62286 | 62348 |  
+62 | +0.10 |
| __powf_fma  | yes |  56213 | 56127 |  
-86 | -0.15 |
| __module_mp_wsm5_MOD_nislfv_rain_plm| no  |  46990 | 48340 |
+1350 | +2.87 |
| __module_mp_wsm5_MOD_wsm52d | no  |  41031 | 40968 |  
-63 | -0.15 |
| __module_small_step_em_MOD_advance_uv   | no  |  30908 | 30909 |   
+1 | +0.00 |
| __module_small_step_em_MOD_advance_w| no  |  28738 | 28600 | 
-138 | -0.48 |
| __module_advect_em_MOD_advect_scalar| no  |  28400 | 28429 |  
+29 | +0.10 |
| __expf_fma  | yes |  26702 | 26516 | 
-186 | -0.70 |
| __module_big_step_utilities_em_MOD_phy_prep | no  |  25878 | 25816 |  
-62 | -0.24 |
| psim_unstable_  | no  |  24994 | 25106 | 
+112 | +0.45 |
| __module_bl_ysu_MOD_ysu2d   | no  |  24799 | 25251 | 
+452 | +1.82 |
| psih_unstable_  | no  |  22600 | 23139 | 
+539 | +2.38 |
| __module_small_step_em_MOD_advance_mu_t | no  |  22250 | 22232 |  
-18 | -0.08 |
| __memset_avx2_unaligned_erms| yes |  21748 | 21613 | 
-135 | -0.62 |
| _ZGVbN4vv_powf_sse4 | yes |  21206 | 21355 | 
+149 | +0.70 |


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug target/101985] vec_cpsgn parameter order

[wschmidt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985

Bill Schmidt  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org
   Last reconfirmed||2021-09-23

--- Comment #1 from Bill Schmidt  ---
Confirmed.  I'll take a look.

Re: [PATCH, Fortran] Diagnose default-initialized pointer/allocatable dummies

[Sandra Loosemore]

On 9/23/21 10:10 AM, Tobias Burnus wrote:

On 23.09.21 17:50, Sandra Loosemore wrote:
This patch is for PR101320, another issue related to missing bind(c) 
diagnostics.  OK to commit?

LGTM - I am only ...

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index f2e8896..b3c65b7 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -1557,6 +1557,20 @@ gfc_verify_c_interop_param (gfc_symbol *sym)
 "CONTIGUOUS attribute as procedure %qs is BIND(C)",
 sym->name, >declared_at, sym->ns->proc_name->name);
+  /* Per F2018, C1557, pointer/allocatable dummies to a bind(c)
+ procedure that are default-initialized are not permitted.  */
+  if ((sym->attr.pointer || sym->attr.allocatable)
+  && sym->ts.type == BT_DERIVED
+  && gfc_has_default_initializer (sym->ts.u.derived))
+    {
+  gfc_error ("Default-initialized %s dummy argument %qs "
+ "at %L is not permitted in BIND(C) procedure %qs",
+ (sym->attr.pointer ? "pointer" : "allocatable"),


... wondering how to best handle such strings for translators. Namely, 
whether to duplicate the string and fill-in the %s, rewriting it them to 
make it clearer for the translator ("dummy argument %qs with %s 
attribute"), or leaving it as is.


I think the later is acceptable – thus, I assume you will choose that 
option :-)


Well, "pointer" and "allocatable" are Fortran language keywords, not 
just regular English words.  Should I capitalize them?  It didn't seem 
like other messages in the Fortran front end are consistent about that, 
but if that's the convention I'll do so here.


-Sandra

[Bug c/102472] New: Infinite loop on m68k

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102472

Bug ID: 102472
   Summary: Infinite loop on m68k
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: giulio.benetti at benettiengineering dot com
  Target Milestone: ---

When building python-uvloop package on Buildroot for m68k gcc enters an
infinite loop on:
'''
/home/giuliobenetti/autobuild/run/instance-3/output-1/host/bin/m68k-linux-gcc
-Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -g2
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -g2
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC
-I/home/giuliobenetti/autobuild/run/instance-3/output-1/host/m68k-buildroot-linux-uclibc/sysroot/usr/include/python3.9
-c uvloop/loop.c -o build/temp.linux-x86_64-3.9/uvloop/loop.o -O2
'''

To reproduce it:

# git clone git://git.busybox.net/buildroot
# wget https://git.busybox.net/buildroot-test/tree/utils/br-reproduce-build

- modify BASE_GIT=... with your buildroot path in br-reproduce-build then:
# chmod a+x br-reproduce-build
# ./br-reproduce-build 17d6e6422abadcd6313c430c40f2a5d7162dbbd3

The only way I've found to build correctly is to turn off optimization
overriding CFLAGS with -O0.

In this case that we have an infinite loop, I don't know how provide .i and .s
files. Can you please point me some instruction for this case?

Thanks in advance

[PATCH] attribs: Allow optional second arg for attr deprecated [PR102049]

[Marek Polacek via Gcc-patches]

Clang implements something we don't have:

__attribute__((deprecated("message", "replacement")));

which seems pretty neat so I wrote this patch to add it to gcc.

It doesn't allow the optional second argument in the standard [[]]
form so as not to clash with possible future standard additions.

I had hoped we could print a nice fix-it replacement hint, but that
won't be possible until warn_deprecated_use gets something better than
input_location.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

PR c++/102049

gcc/c-family/ChangeLog:

* c-attribs.c (c_common_attribute_table): Increase max_len for
deprecated.
(handle_deprecated_attribute): Allow an optional second argument
in the GNU form of attribute deprecated.

gcc/c/ChangeLog:

* c-parser.c (c_parser_std_attribute): Give a diagnostic when
the standard form of an attribute deprecated has a second argument.

gcc/ChangeLog:

* doc/extend.texi: Document attribute deprecated with an
optional second argument.
* tree.c (warn_deprecated_use): Print the replacement argument,
if any.

gcc/testsuite/ChangeLog:

* gcc.dg/c2x-attr-deprecated-3.c: Adjust dg-error.
* c-c++-common/Wdeprecated-arg-1.c: New test.
---
 gcc/c-family/c-attribs.c  | 17 -
 gcc/c/c-parser.c  |  8 ++
 gcc/doc/extend.texi   | 24 ++
 .../c-c++-common/Wdeprecated-arg-1.c  | 21 
 gcc/testsuite/gcc.dg/c2x-attr-deprecated-3.c  |  2 +-
 gcc/tree.c| 25 +++
 6 files changed, 90 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/Wdeprecated-arg-1.c

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 007b928c54b..ef857a9ae2c 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -409,7 +409,7 @@ const struct attribute_spec c_common_attribute_table[] =
  to prevent its usage in source code.  */
   { "no vops",0, 0, true,  false, false, false,
  handle_novops_attribute, NULL },
-  { "deprecated", 0, 1, false, false, false, false,
+  { "deprecated", 0, 2, false, false, false, false,
  handle_deprecated_attribute, NULL },
   { "unavailable",0, 1, false, false, false, false,
  handle_unavailable_attribute, NULL },
@@ -4107,6 +4107,21 @@ handle_deprecated_attribute (tree *node, tree name,
   error ("deprecated message is not a string");
   *no_add_attrs = true;
 }
+  else if (TREE_CHAIN (args) != NULL_TREE)
+{
+  /* We allow an optional second argument in the GNU form of
+attribute deprecated, which specifies the replacement.  */
+  if (flags & ATTR_FLAG_CXX11)
+   {
+ error ("replacement argument only allowed in GNU attributes");
+ *no_add_attrs = true;
+   }
+  else if (TREE_CODE (TREE_VALUE (TREE_CHAIN (args))) != STRING_CST)
+   {
+ error ("replacement argument is not a string");
+ *no_add_attrs = true;
+   }
+}
 
   if (DECL_P (*node))
 {
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index fa29d2c15fc..2b47f01d166 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -4952,6 +4952,14 @@ c_parser_std_attribute (c_parser *parser, bool for_tm)
TREE_VALUE (attribute)
  = c_parser_attribute_arguments (parser, takes_identifier,
  require_string, false);
+   if (c_parser_next_token_is (parser, CPP_COMMA)
+   && strcmp (IDENTIFIER_POINTER (name), "deprecated") == 0)
+ {
+   error_at (open_loc, "replacement argument only allowed in "
+ "GNU attributes");
+   c_parser_skip_until_found (parser, CPP_CLOSE_PAREN, NULL);
+   return error_mark_node;
+ }
   }
 else
   c_parser_balanced_token_sequence (parser);
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 9501a60f20e..7d399f4b2bc 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -2860,6 +2860,7 @@ StrongAlias (allocate, alloc);
 
 @item deprecated
 @itemx deprecated (@var{msg})
+@itemx deprecated (@var{msg}, @var{replacement})
 @cindex @code{deprecated} function attribute
 The @code{deprecated} attribute results in a warning if the function
 is used anywhere in the source file.  This is useful when identifying
@@ -2880,6 +2881,13 @@ results in a warning on line 3 but not line 2.  The 
optional @var{msg}
 argument, which must be a string, is printed in the warning if
 present.
 
+This attribute accepts an optional second argument which specifies
+the replacement that ought to be used instead:
+
+@smallexample
+int old_fn () __attribute__ ((deprecated("unsafe", "new_fn")));
+@end smallexample
+
 The @code{deprecated} 

Re: [PATCH] Avoid invalid loop transformations in jump threading registry.

[Jeff Law via Gcc-patches]

On 9/23/2021 5:15 AM, Aldy Hernandez wrote:

My upcoming improvements to the forward jump threader make it thread
more aggressively.  In investigating some "regressions", I noticed
that it has always allowed threading through empty latches and across
loop boundaries.  As we have discussed recently, this should be avoided
until after loop optimizations have run their course.

Note that this wasn't much of a problem before because DOM/VRP
couldn't find these opportunities, but with a smarter solver, we trip
over them more easily.
We used to be much more aggressive in this space -- but we removed the 
equivalency tracking on backedges in the main part of DOM which had the 
side effect to reducing the number of threads related to back edges in 
loops.


Of course that was generally a positive thing given the issues we've 
been discussing.





Because the forward threader doesn't have an independent localized cost
model like the new threader (profitable_path_p), it is difficult to
catch these things at discovery.  However, we can catch them at
registration time, with the added benefit that all the threaders
(forward and backward) can share the handcuffs.
In an ideal world profitability and correctness would be separated -- 
but they're still intertwined and I don't think this makes that 
situation particularly worse.  And I do like that having a single choke 
point.


Obviously you're cleaning this up, so I think a significant degree of 
freedom should be given here





This patch is an adaptation of what we do in the backward threader, but
it is not meant to catch everything we do there, as some of the
restrictions there are due to limitations of the different block
copiers (for example, the generic copier does not re-use existing
threading paths).

We could ideally remove the now redundant bits in profitable_path_p, but
I would prefer not to for two reasons.  First, the backward threader uses
profitable_path_p as it discovers paths to avoid discovering paths in
unprofitable directions.  Second, I would like to merge all the forward
cost restrictions into the profitability class in the backward threader,
not the other way around.  Alas, that reshuffling will have to wait for
the next release.

As usual, there are quite a few tests that needed adjustments.  It seems
we were quite happily threading improper scenarios.  With most of them,
as can be seen in pr77445-2.c, we're merely shifting the threading to
after loop optimizations.

Tested on x86-64 Linux.

OK for trunk?

p.s. "Sure, sounds like fun... how hard can improving the threaders be?"

gcc/ChangeLog:

* tree-ssa-threadupdate.c (jt_path_registry::cancel_invalid_paths):
New.
(jt_path_registry::register_jump_thread): Call
cancel_invalid_paths.
* tree-ssa-threadupdate.h (class jt_path_registry): Add
cancel_invalid_paths.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/20030714-2.c: Adjust.
* gcc.dg/tree-ssa/pr66752-3.c: Adjust.
* gcc.dg/tree-ssa/pr77445-2.c: Adjust.
* gcc.dg/tree-ssa/ssa-dom-thread-18.c: Adjust.
* gcc.dg/tree-ssa/ssa-dom-thread-7.c: Adjust.
* gcc.dg/vect/bb-slp-16.c: Adjust.

OK
jeff

Re: [PATCH, Fortran] Diagnose default-initialized pointer/allocatable dummies

[Tobias Burnus]

On 23.09.21 17:50, Sandra Loosemore wrote:

This patch is for PR101320, another issue related to missing bind(c)
diagnostics.  OK to commit?

LGTM - I am only ...

commit d3507154fd34e65e2887262218fec09d5fb082a2
Author: Sandra Loosemore
Date:   Thu Sep 23 08:03:52 2021 -0700

 Fortran: Diagnose default-initialized pointer/allocatable dummies

 TS29113 changed what was then C516 in the 2010 Fortran standard (now
 C1557 in F2018) from disallowing all of pointer, allocatable, and
 optional attributes on dummy arguments to BIND(C) functions, to
 disallowing only pointer/allocatable with default-initialization.
 gfortran was previously failing to diagnose violations of this
 constraint.

 2021-09-23  Sandra Loosemore

  PR Fortran/101320

  gcc/fortran/
  * decl.c (gfc_verify_c_interop_param): Handle F2018 C1557,
  aka TS29113 C516.

  gcc/testsuite/
  * gfortran.dg/c-interop/c516.f90: Remove xfails.  Add more
  tests.

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index f2e8896..b3c65b7 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -1557,6 +1557,20 @@ gfc_verify_c_interop_param (gfc_symbol *sym)
 "CONTIGUOUS attribute as procedure %qs is BIND(C)",
 sym->name, >declared_at, sym->ns->proc_name->name);

+   /* Per F2018, C1557, pointer/allocatable dummies to a bind(c)
+  procedure that are default-initialized are not permitted.  */
+   if ((sym->attr.pointer || sym->attr.allocatable)
+   && sym->ts.type == BT_DERIVED
+   && gfc_has_default_initializer (sym->ts.u.derived))
+ {
+   gfc_error ("Default-initialized %s dummy argument %qs "
+  "at %L is not permitted in BIND(C) procedure %qs",
+  (sym->attr.pointer ? "pointer" : "allocatable"),


... wondering how to best handle such strings for translators. Namely,
whether to duplicate the string and fill-in the %s, rewriting it them to
make it clearer for the translator ("dummy argument %qs with %s
attribute"), or leaving it as is.

I think the later is acceptable – thus, I assume you will choose that
option :-)

Thanks,

Tobias



+  sym->name, >declared_at,
+  sym->ns->proc_name->name);
+   retval = false;
+ }
+
/* Character strings are only C interoperable if they have a
   length of 1.  However, as an argument they are also iteroperable
   when passed as descriptor (which requires len=: or len=*).  */
diff --git a/gcc/testsuite/gfortran.dg/c-interop/c516.f90 
b/gcc/testsuite/gfortran.dg/c-interop/c516.f90
index 208eb84..d6a65af 100644
--- a/gcc/testsuite/gfortran.dg/c-interop/c516.f90
+++ b/gcc/testsuite/gfortran.dg/c-interop/c516.f90
@@ -27,6 +27,10 @@ module m2

interface

+! First test versions with optional attributes on the argument.
+! TS29113 removed the constraint disallowing optional arguments
+! that previously used to be in C516.
+
  ! good, no default initialization, no pointer/allocatable attribute
  subroutine s1a (x) bind (c)
use m1
@@ -52,16 +56,54 @@ module m2
  end subroutine

  ! bad, default initialization + allocatable
-subroutine s2b (x) bind (c)  ! { dg-error "BIND\\(C\\)" "pr101320" { xfail 
*-*-* } }
+subroutine s2b (x) bind (c)  ! { dg-error "BIND\\(C\\)" }
use m1
type(t2), allocatable, optional :: x
  end subroutine

  ! bad, default initialization + pointer
-subroutine s2c (x) bind (c)  ! { dg-error "BIND\\(C\\)" "pr101320" { xfail 
*-*-* } }
+subroutine s2c (x) bind (c)  ! { dg-error "BIND\\(C\\)" }
use m1
type(t2), pointer, optional :: x
  end subroutine

+! Now do all the same tests without the optional attribute.
+
+! good, no default initialization, no pointer/allocatable attribute
+subroutine s3a (x) bind (c)
+  use m1
+  type(t1) :: x
+end subroutine
+
+! good, no default initialization
+subroutine s3b (x) bind (c)
+  use m1
+  type(t1), allocatable :: x
+end subroutine
+
+! good, no default initialization
+subroutine s3c (x) bind (c)
+  use m1
+  type(t1), pointer :: x
+end subroutine
+
+! good, default initialization but no pointer/allocatable attribute
+subroutine s4a (x) bind (c)
+  use m1
+  type(t2) :: x
+end subroutine
+
+! bad, default initialization + allocatable
+subroutine s4b (x) bind (c)  ! { dg-error "BIND\\(C\\)" }
+  use m1
+  type(t2), allocatable :: x
+end subroutine
+
+! bad, default initialization + pointer
+subroutine s4c (x) bind (c)  ! { dg-error "BIND\\(C\\)" }
+  use m1
+  type(t2), pointer :: x
+end subroutine
+
end interface
  end module

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; 

Re: [PATCH] libiberty: prevent null dereferencing on dlang_type

[Jeff Law via Gcc-patches]

On 9/23/2021 4:17 AM, ibuclaw--- via Gcc-patches wrote:

On 22/09/2021 03:31 Luís Ferreira  wrote:

  
This patch prevents dereferencing a null reference on a crafted

malformed magled name, often causing SIGSEGV to be raised.


OK, seems reasonable to me.

I pushed this to the trunk.

Thanks,
jeff

[Bug libstdc++/102425] std::error_code() does not compare equal to std::error_condition()

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102425

--- Comment #3 from Jonathan Wakely  ---
Fixed on trunk so far, but I'll backport it.

[PATCH, Fortran] Diagnose default-initialized pointer/allocatable dummies

[Sandra Loosemore]

This patch is for PR101320, another issue related to missing bind(c) 
diagnostics.  OK to commit?


-Sandra
commit d3507154fd34e65e2887262218fec09d5fb082a2
Author: Sandra Loosemore 
Date:   Thu Sep 23 08:03:52 2021 -0700

Fortran: Diagnose default-initialized pointer/allocatable dummies

TS29113 changed what was then C516 in the 2010 Fortran standard (now
C1557 in F2018) from disallowing all of pointer, allocatable, and
optional attributes on dummy arguments to BIND(C) functions, to
disallowing only pointer/allocatable with default-initialization.
gfortran was previously failing to diagnose violations of this
constraint.

2021-09-23  Sandra Loosemore  

	PR Fortran/101320

	gcc/fortran/
	* decl.c (gfc_verify_c_interop_param): Handle F2018 C1557,
	aka TS29113 C516.

	gcc/testsuite/
	* gfortran.dg/c-interop/c516.f90: Remove xfails.  Add more
	tests.

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index f2e8896..b3c65b7 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -1557,6 +1557,20 @@ gfc_verify_c_interop_param (gfc_symbol *sym)
 		   "CONTIGUOUS attribute as procedure %qs is BIND(C)",
 		   sym->name, >declared_at, sym->ns->proc_name->name);
 
+	  /* Per F2018, C1557, pointer/allocatable dummies to a bind(c)
+	 procedure that are default-initialized are not permitted.  */
+	  if ((sym->attr.pointer || sym->attr.allocatable)
+	  && sym->ts.type == BT_DERIVED
+	  && gfc_has_default_initializer (sym->ts.u.derived))
+	{
+	  gfc_error ("Default-initialized %s dummy argument %qs "
+			 "at %L is not permitted in BIND(C) procedure %qs",
+			 (sym->attr.pointer ? "pointer" : "allocatable"),
+			 sym->name, >declared_at,
+			 sym->ns->proc_name->name);
+	  retval = false;
+	}
+
   /* Character strings are only C interoperable if they have a
 	 length of 1.  However, as an argument they are also iteroperable
 	 when passed as descriptor (which requires len=: or len=*).  */
diff --git a/gcc/testsuite/gfortran.dg/c-interop/c516.f90 b/gcc/testsuite/gfortran.dg/c-interop/c516.f90
index 208eb84..d6a65af 100644
--- a/gcc/testsuite/gfortran.dg/c-interop/c516.f90
+++ b/gcc/testsuite/gfortran.dg/c-interop/c516.f90
@@ -27,6 +27,10 @@ module m2
 
   interface
 
+! First test versions with optional attributes on the argument.
+! TS29113 removed the constraint disallowing optional arguments
+! that previously used to be in C516.
+
 ! good, no default initialization, no pointer/allocatable attribute
 subroutine s1a (x) bind (c)
   use m1
@@ -52,16 +56,54 @@ module m2
 end subroutine
 
 ! bad, default initialization + allocatable
-subroutine s2b (x) bind (c)  ! { dg-error "BIND\\(C\\)" "pr101320" { xfail *-*-* } }
+subroutine s2b (x) bind (c)  ! { dg-error "BIND\\(C\\)" }
   use m1
   type(t2), allocatable, optional :: x
 end subroutine
 
 ! bad, default initialization + pointer
-subroutine s2c (x) bind (c)  ! { dg-error "BIND\\(C\\)" "pr101320" { xfail *-*-* } }
+subroutine s2c (x) bind (c)  ! { dg-error "BIND\\(C\\)" }
   use m1
   type(t2), pointer, optional :: x
 end subroutine
 
+! Now do all the same tests without the optional attribute.
+
+! good, no default initialization, no pointer/allocatable attribute
+subroutine s3a (x) bind (c)
+  use m1
+  type(t1) :: x
+end subroutine
+
+! good, no default initialization
+subroutine s3b (x) bind (c)
+  use m1
+  type(t1), allocatable :: x
+end subroutine
+
+! good, no default initialization
+subroutine s3c (x) bind (c)
+  use m1
+  type(t1), pointer :: x
+end subroutine
+
+! good, default initialization but no pointer/allocatable attribute
+subroutine s4a (x) bind (c)
+  use m1
+  type(t2) :: x
+end subroutine
+
+! bad, default initialization + allocatable
+subroutine s4b (x) bind (c)  ! { dg-error "BIND\\(C\\)" }
+  use m1
+  type(t2), allocatable :: x
+end subroutine
+
+! bad, default initialization + pointer
+subroutine s4c (x) bind (c)  ! { dg-error "BIND\\(C\\)" }
+  use m1
+  type(t2), pointer :: x
+end subroutine
+
   end interface
 end module

Re: [PATCH] libiberty: prevent buffer overflow when decoding user input

[Jeff Law via Gcc-patches]

On 9/23/2021 4:16 AM, ibuclaw--- via Gcc-patches wrote:

On 22/09/2021 03:10 Luís Ferreira  wrote:

  
Currently a stack/heap overflow may happen if a crafted mangle is

maliciously used to cause denial of service, such as intentional
crashes
by accessing a reserved memory space.


Hi,

Thanks for this.  Is there a test that could trigger this code path?
I don't think Luis has commit privs, so I went ahead and committed this 
patch.


Yea, a testcase would be great.

Jeff

Re: [PATCH] libiberty: prevent buffer overflow when decoding user input

[Luís Ferreira via Gcc-patches]

Hi,

Here is an example of a crafted mangle that can cause heap buffer
overflow.

```
fuzzer-results/crash-18b7f0799be49886550876b5ab6bb63e4231979b
_D2FGWG4EQe
  5f 44 32 46 47 57 47 34  34 34 34 34 34 34 34 34 
|_D2FGWG4|
0010  34 34 34 34 34 34 34 34  45 51 65 0a 
|EQe.|
001c
```

Here is an example of a crafted mangle that can cause stack buffer
overflow.

```
fuzzer-results/crash-79833f1c8ce510bbf138c0d5ad06a7fb11ce3bae
_D8ee2_Qe
  5f 44 38 65 65 32 5f 31  31 31 31 51 65  
|_D8ee2_Qe|
000d
```

Even though this triggers an UB by reading/writing other memory space,
I couldn't find a situation where this constantly fails, although, if
running with an address + UB sanitizer this can be easily catched and
replicated with some confidence. I didn't add this to the test suite
because of that.

On Thu, 2021-09-23 at 12:16 +0200, ibuc...@gdcproject.org wrote:
> > On 22/09/2021 03:10 Luís Ferreira  wrote:
> > 
> >  
> > Currently a stack/heap overflow may happen if a crafted mangle is
> > maliciously used to cause denial of service, such as intentional
> > crashes
> > by accessing a reserved memory space.
> > 
> 
> Hi,
> 
> Thanks for this.  Is there a test that could trigger this code path?
> 
> Iain.
> 
> 
> > Signed-off-by: Luís Ferreira 
> > ---
> >  libiberty/d-demangle.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
> > index a2152cc65518..7ded3e2a2563 100644
> > --- a/libiberty/d-demangle.c
> > +++ b/libiberty/d-demangle.c
> > @@ -381,7 +381,7 @@ dlang_symbol_backref (string *decl, const char
> > *mangled,
> >  
> >    /* Must point to a simple identifier.  */
> >    backref = dlang_number (backref, );
> > -  if (backref == NULL)
> > +  if (backref == NULL || strlen(backref) < len)
> >  return NULL;
> >  
> >    backref = dlang_lname (decl, backref, len);

-- 
Sincerely,
Luís Ferreira @ lsferreira.net



signature.asc
Description: This is a digitally signed message part

Re: [PATCH] Enable auto-vectorization at O2 with very-cheap cost model.

[Martin Sebor via Gcc-patches]

On 9/23/21 12:30 AM, Richard Biener wrote:

On Thu, 23 Sep 2021, Hongtao Liu wrote:


On Thu, Sep 23, 2021 at 9:48 AM Hongtao Liu  wrote:


On Wed, Sep 22, 2021 at 10:21 PM Martin Sebor  wrote:


On 9/21/21 7:38 PM, Hongtao Liu wrote:

On Mon, Sep 20, 2021 at 4:13 AM Martin Sebor  wrote:

...

diff --git a/gcc/testsuite/c-c++-common/Wstringop-overflow-2.c 
b/gcc/testsuite/c-c++-common/Wstringop-overflow-2.c
index 1d79930cd58..9351f7e7a1a 100644
--- a/gcc/testsuite/c-c++-common/Wstringop-overflow-2.c
+++ b/gcc/testsuite/c-c++-common/Wstringop-overflow-2.c
@@ -1,7 +1,7 @@
/* PR middle-end/91458 - inconsistent warning for writing past the end
   of an array member
   { dg-do compile }
-   { dg-options "-O2 -Wall -Wno-array-bounds -fno-ipa-icf" } */
+   { dg-options "-O2 -Wall -Wno-array-bounds -fno-ipa-icf -fno-tree-vectorize" 
} */


The testcase is large - what part requires this change?  Given the
testcase was added for inconsistent warnings do they now become
inconsistent again as we enable vectorization at -O2?

That said, the testcase adjustments need some explaining - I suppose
you didn't just slap -fno-tree-vectorize to all of those changing
behavior?


void ga1_ (void)
{
 a1_.a[0] = 0;
 a1_.a[1] = 1; // { dg-warning "\\\[-Wstringop-overflow" }
 a1_.a[2] = 2; // { dg-warning "\\\[-Wstringop-overflow" }

 struct A1 a;
 a.a[0] = 0;
 a.a[1] = 1;   // { dg-warning "\\\[-Wstringop-overflow" }
 a.a[2] = 2;   // { dg-warning "\\\[-Wstringop-overflow" }
 sink ();
}

It's supposed to be 2 warning for a.a[1] = 1 and a.a[2] = 1 since
there are 2 accesses, but after enabling vectorization, there's only
one access, so one warning is missing which causes the failure.


With the stores vectorized, is the warning on the correct line or
does it point to the first store, the one that's in bounds, as
it does with -O3?  The latter would be a regression at -O2.

For the upper case, It points to the second store which is out of
bounds, the third store warning is missing.




I would find it preferable to change the test code over disabling
optimizations that are on by default.  My concern is that the test
would no longer exercise the default behavior.  (The same goes for
the -fno-ipa-icf option.)

Hmm, it's a middle-end test, for some backend, it may not do
vectorization(it depends on TARGET_VECTOR_MODE_SUPPORTED_P and
relative cost model).


Yes, there are quite a few warning tests like that.  Their main
purpose is to verify that in common GCC invocations (i.e., without
any special options) warnings are a) issued when expected and b)
not issued when not expected.  Otherwise, middle end warnings are
known to have both false positives and false negatives in some
invocations, depending on what optimizations are in effect.
Indiscriminately disabling common optimizations for these large
tests and invoking them under artificial conditions would
compromise this goal and hide the problems.

If enabling vectorization at -O2 causes regressions in the quality
of diagnostics (as the test failure above indicates seems to be
happening) we should investigate these and open bugs for them so
they can be fixed.  We can then tweak the specific failing test
cases to avoid the failures until they are fixed.

There are indeed cases of false positives and false negatives
.i.e.
// Verify warning for access to a definition with an initializer that
// initializes the one-element array member.
struct A1 a1i_1 = { 0, { 1 } };

void ga1i_1 (void)
{
   a1i_1.a[0] = 0;
   a1i_1.a[1] = 1;   // { dg-warning "\\\[-Wstringop-overflow" }
   a1i_1.a[2] = 2;   // { dg-warning "\\\[-Wstringop-overflow" }

   struct A1 a = { 0, { 1 } }; --- false positive here.
   a.a[0] = 1;
   a.a[1] = 2;   // { dg-warning
"\\\[-Wstringop-overflow" } false negative here.
   a.a[2] = 3;   // { dg-warning
"\\\[-Wstringop-overflow" } false negative here.
   sink ();
}

Similar for
* gcc.dg/Warray-bounds-51.c.
* gcc.dg/Warray-parameter-3.c
* gcc.dg/Wstringop-overflow-14.c
* gcc.dg/Wstringop-overflow-21.c

So there're 3 situations.
1. All accesses are out of bound, and after vectorization, there are
some warnings missing.
2. Part of accesses are inbound, part of accesses are out of bound,
and after vectorization, the warning goes from out of bound line to
inbound line.
3. All access are out of bound, and after vectoriation, all warning
are missing, and goes to a false-positive line.


I remember some of the warning code explicitely excuses itself from
even trying to deal with vectorized loads/stores, that might need to
be revisited.  It would also be useful to verify whether the line
info on the vectorized loads/stores is sensible (if you dump with
-lineno you get stmts with line numbers).


Yes, it's this code in handle_mem_ref() in pointer-query.cc:

  if (VECTOR_TYPE_P (TREE_TYPE (mref)))
{
  /* Hack: 

[committed] libstdc++: Remove c++20-specific dg-error directives in test

[Jonathan Wakely via Gcc-patches]

I added extra dg-error directives for C++20 to match the extra errors
caused by some of the call stack being constexpr in C++20. Since Jason's
changes to reduce those errors, those dg-error lines no longer match.
This removes them again.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

* 
testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_neg.cc:
Remove dg-error lines for C++20-only errors.

Tested x86_64-linux. Committed to trunk.

commit 43358e91bd1d2b376ce8f426cf9becedf8343a06
Author: Jonathan Wakely 
Date:   Wed Sep 22 18:15:24 2021

libstdc++: Remove c++20-specific dg-error directives in test

I added extra dg-error directives for C++20 to match the extra errors
caused by some of the call stack being constexpr in C++20. Since Jason's
changes to reduce those errors, those dg-error lines no longer match.
This removes them again.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

* 
testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_neg.cc:
Remove dg-error lines for C++20-only errors.

diff --git 
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_neg.cc
 
b/libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_neg.cc
index e114168842e..dfdead42daa 100644
--- 
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_neg.cc
+++ 
b/libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_neg.cc
@@ -47,5 +47,3 @@ test02()
 }
 
 // { dg-error "value type is destructible" "" { target *-*-* } 0 }
-// { dg-error "use of deleted function" "" { target c++20 } 0 }
-// { dg-error "is private within this context" "" { target c++20 } 0 }

[committed] libstdc++: Disable PCH for test that depends on a macro being defined

[Jonathan Wakely via Gcc-patches]

This test tries to ensure that  can be included after
defining _XOPEN_SOURCE=600, which doesn't test anything if that header
is already included via the  PCH before the macro
definition. Disable PCH so that it behaves as intended.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

* testsuite/19_diagnostics/headers/system_error/93151.cc:
Disable PCH.

Tested x86_64-linux. Committed to trunk.

commit 8fa90926e08950cc00d0e22eace27402b9f9fa57
Author: Jonathan Wakely 
Date:   Wed Sep 22 14:11:54 2021

libstdc++: Disable PCH for test that depends on a macro being defined

This test tries to ensure that  can be included after
defining _XOPEN_SOURCE=600, which doesn't test anything if that header
is already included via the  PCH before the macro
definition. Disable PCH so that it behaves as intended.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

* testsuite/19_diagnostics/headers/system_error/93151.cc:
Disable PCH.

diff --git 
a/libstdc++-v3/testsuite/19_diagnostics/headers/system_error/93151.cc 
b/libstdc++-v3/testsuite/19_diagnostics/headers/system_error/93151.cc
index c54c9a3022d..6aca63d4db3 100644
--- a/libstdc++-v3/testsuite/19_diagnostics/headers/system_error/93151.cc
+++ b/libstdc++-v3/testsuite/19_diagnostics/headers/system_error/93151.cc
@@ -1,4 +1,5 @@
 // { dg-do compile { target c++11 } }
+// { dg-add-options no_pch }
 
 // Copyright (C) 2020-2021 Free Software Foundation, Inc.
 //

[committed] libstdc++: Make std::system_category() recognize Windows error codes

[Jonathan Wakely via Gcc-patches]

The std::system_category error category should be used for
system-specific error codes, which means on Windows it should be used
for Windows error codes.  Currently that category assumes that the error
numbers it deals with are errno numbers, which means that
ERROR_ACCESS_DENIED (which has value 0x5) gets treated as whichever
errno number happens to have that value (EIO on mingw32-w64).

This adds a mapping from known Windows error codes to generic errno
ones. This means we correctly treat ERROR_ACCESS_DENIED as corresponding
to EACCES.

Also make std::system_category().message(int) return the right message
for Windows errors, by using FormatMessage instead of strerror. The
output of FormatMessage includes ".\r\n" at the end, so we strip that
off to allow the message to be used in contexts where that would be
problematic.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

* src/c++11/system_error.cc (system_error_category) [_WIN32]:
Map Windows error codes to generic POSIX error numbers. Use
FormatMessage instead of strerror.
* testsuite/19_diagnostics/error_category/system_category.cc:
Adjust for new behaviour on Windows.

Tested x86_64-linux. Committed to trunk.

commit 477897451e46d67acb46f3ac45585e6eb9e7dde5
Author: Jonathan Wakely 
Date:   Wed Feb 10 16:10:46 2021

libstdc++: Make std::system_category() recognize Windows error codes

The std::system_category error category should be used for
system-specific error codes, which means on Windows it should be used
for Windows error codes.  Currently that category assumes that the error
numbers it deals with are errno numbers, which means that
ERROR_ACCESS_DENIED (which has value 0x5) gets treated as whichever
errno number happens to have that value (EIO on mingw32-w64).

This adds a mapping from known Windows error codes to generic errno
ones. This means we correctly treat ERROR_ACCESS_DENIED as corresponding
to EACCES.

Also make std::system_category().message(int) return the right message
for Windows errors, by using FormatMessage instead of strerror. The
output of FormatMessage includes ".\r\n" at the end, so we strip that
off to allow the message to be used in contexts where that would be
problematic.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

* src/c++11/system_error.cc (system_error_category) [_WIN32]:
Map Windows error codes to generic POSIX error numbers. Use
FormatMessage instead of strerror.
* testsuite/19_diagnostics/error_category/system_category.cc:
Adjust for new behaviour on Windows.

diff --git a/libstdc++-v3/src/c++11/system_error.cc 
b/libstdc++-v3/src/c++11/system_error.cc
index 7fc178a4deb..f1cfc03c3de 100644
--- a/libstdc++-v3/src/c++11/system_error.cc
+++ b/libstdc++-v3/src/c++11/system_error.cc
@@ -32,6 +32,11 @@
 #include 
 #undef __sso_string
 
+#if defined(_WIN32) && !defined(__CYGWIN__)
+#include 
+#include 
+#endif
+
 namespace
 {
   using std::string;
@@ -81,9 +86,33 @@ namespace
 string
 message(int i) const final
 {
+#if defined(_WIN32) && !defined(__CYGWIN__)
+  char* buf = nullptr;
+  auto len
+   = FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM
+   | FORMAT_MESSAGE_ALLOCATE_BUFFER,
+   nullptr,
+   i,
+   LANG_USER_DEFAULT,
+   reinterpret_cast(),
+   0,
+   nullptr);
+  if (len > 0)
+  {
+   struct deleter {
+ void operator()(void* p) const { ::LocalFree(p); }
+   };
+   std::unique_ptr guard(buf);
+   if (len > 3 && !__builtin_memcmp(buf + len - 3, ".\r\n", 3)) [[likely]]
+ len -= 3;
+   return string(buf, len);
+  }
+  return string("Unknown error code");
+#else
   // XXX locale issues: how does one get or set loc.
   // _GLIBCXX_HAVE_STRERROR_L, strerror_l(i, cloc)
   return string(strerror(i));
+#endif
 }
 
 std::error_condition
@@ -93,6 +122,132 @@ namespace
   // and system category otherwise.
   switch (ev)
   {
+#if defined(_WIN32) && !defined(__CYGWIN__)
+  case 0:
+   return {0, generic_category_instance.obj};
+   // Convert Windows error code into a corresponding POSIX errno value.
+#define X(w, e) case ERROR_##w: return {e, generic_category_instance.obj};
+   // This list is based on Cygwin's winsup/cygwin/errno.cc
+   X (ACCESS_DENIED,   EACCES);
+   X (ACTIVE_CONNECTIONS,  EAGAIN);
+   X (ALREADY_EXISTS,  EEXIST);
+   X (BAD_DEVICE,  ENODEV);
+   X (BAD_EXE_FORMAT,  ENOEXEC);
+   X (BAD_NETPATH, ENOENT);
+   X (BAD_NET_NAME,ENOENT);
+   X (BAD_NET_RESP,ENOSYS);
+   X (BAD_PATHNAME,

[committed] libstdc++: Improvements to standard error category objects

[Jonathan Wakely via Gcc-patches]

This ensures that the objects returned by std::generic_category() and
std::system_category() are initialized before any code starts executing,
and are not destroyed at the end of the program. This means it is always
safe to access them, even during startup and termination. See LWG 2992
and P1195R0 for further discussion of this.

Additionally, make the types of those objects final, which might
potentially allow additional devirtualization opportunities. The types
are not visible to users, so there is no way they can derive from them,
so making them final has no semantic change.

Finally, add overrides for equivalent(int, const error_condition&) to
those types, to avoid the second virtual call that would be performed by
the base class definition of the function. Because we know what
default_error_condition(int) does for the derived type, we don't need to
make a virtual call.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

* src/c++11/system_error.cc (generic_error_category): Define
class and virtual functions as 'final'.
(generic_error_category::equivalent(int, const error_condition&)):
Override.
(system_error_category): Define class and virtual functions as
'final'.
(system_error_category::equivalent(int, const error_condition&)):
Override.
(generic_category_instance, system_category_instance): Use
constinit union to make the objects immortal.

Tested x86_64-linux. Committed to trunk.

commit dd396a321be5099536af36e64454c1fcf9d67e12
Author: Jonathan Wakely 
Date:   Wed Sep 22 13:56:21 2021

libstdc++: Improvements to standard error category objects

This ensures that the objects returned by std::generic_category() and
std::system_category() are initialized before any code starts executing,
and are not destroyed at the end of the program. This means it is always
safe to access them, even during startup and termination. See LWG 2992
and P1195R0 for further discussion of this.

Additionally, make the types of those objects final, which might
potentially allow additional devirtualization opportunities. The types
are not visible to users, so there is no way they can derive from them,
so making them final has no semantic change.

Finally, add overrides for equivalent(int, const error_condition&) to
those types, to avoid the second virtual call that would be performed by
the base class definition of the function. Because we know what
default_error_condition(int) does for the derived type, we don't need to
make a virtual call.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

* src/c++11/system_error.cc (generic_error_category): Define
class and virtual functions as 'final'.
(generic_error_category::equivalent(int, const error_condition&)):
Override.
(system_error_category): Define class and virtual functions as
'final'.
(system_error_category::equivalent(int, const error_condition&)):
Override.
(generic_category_instance, system_category_instance): Use
constinit union to make the objects immortal.

diff --git a/libstdc++-v3/src/c++11/system_error.cc 
b/libstdc++-v3/src/c++11/system_error.cc
index 6c79202eb0e..7fc178a4deb 100644
--- a/libstdc++-v3/src/c++11/system_error.cc
+++ b/libstdc++-v3/src/c++11/system_error.cc
@@ -36,39 +36,58 @@ namespace
 {
   using std::string;
 
-  struct generic_error_category : public std::error_category
+  template
+struct constant_init
+{
+  union {
+   unsigned char unused;
+   T obj;
+  };
+  constexpr constant_init() : obj() { }
+
+  ~constant_init() { /* do nothing, union member is not destroyed */ }
+};
+
+  struct generic_error_category final : public std::error_category
   {
-virtual const char*
-name() const noexcept
+const char*
+name() const noexcept final
 { return "generic"; }
 
 _GLIBCXX_DEFAULT_ABI_TAG
-virtual string
-message(int i) const
+string
+message(int i) const final
 {
   // XXX locale issues: how does one get or set loc.
   // _GLIBCXX_HAVE_STRERROR_L, strerror_l(i, cloc)
   return string(strerror(i));
 }
+
+// Override this to avoid a virtual call to default_error_condition(i).
+bool
+equivalent(int i, const std::error_condition& cond) const noexcept final
+{ return i == cond.value() && *this == cond.category(); }
   };
 
-  struct system_error_category : public std::error_category
+  __constinit constant_init 
generic_category_instance{};
+
+  struct system_error_category final : public std::error_category
   {
-virtual const char*
-name() const noexcept
+const char*
+name() const noexcept final
 { return "system"; }
 
 _GLIBCXX_DEFAULT_ABI_TAG
-virtual string
-message(int i) const
+string
+

[committed] libstdc++: std::system_category should know meaning of zero [PR102425]

[Jonathan Wakely via Gcc-patches]

Although 0 is not an errno value, it should still be recognized as
corresponding to a value belonging to the generic_category().

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/102425
* src/c++11/system_error.cc
(system_error_category::default_error_condition): Add 0 to
switch.
* testsuite/19_diagnostics/error_category/102425.cc: New test.

Tested x86_64-linux. Committed to trunk.

commit ce01e2e64c340dadb55a8a24c545a13e654804d4
Author: Jonathan Wakely 
Date:   Wed Sep 22 11:58:20 2021

libstdc++: std::system_category should know meaning of zero [PR102425]

Although 0 is not an errno value, it should still be recognized as
corresponding to a value belonging to the generic_category().

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/102425
* src/c++11/system_error.cc
(system_error_category::default_error_condition): Add 0 to
switch.
* testsuite/19_diagnostics/error_category/102425.cc: New test.

diff --git a/libstdc++-v3/src/c++11/system_error.cc 
b/libstdc++-v3/src/c++11/system_error.cc
index f12290adaee..6c79202eb0e 100644
--- a/libstdc++-v3/src/c++11/system_error.cc
+++ b/libstdc++-v3/src/c++11/system_error.cc
@@ -70,6 +70,8 @@ namespace
 virtual std::error_condition
 default_error_condition(int ev) const noexcept
 {
+  // Use generic category for all known POSIX errno values (including zero)
+  // and system category otherwise.
   switch (ev)
   {
   // List of errno macros from [cerrno.syn].
@@ -310,6 +312,7 @@ namespace
 #ifdef EXDEV
   case EXDEV:
 #endif
+  case 0:
 return std::error_condition(ev, std::generic_category());
 
   /* Additional system-dependent mappings from non-standard error codes
diff --git a/libstdc++-v3/testsuite/19_diagnostics/error_category/102425.cc 
b/libstdc++-v3/testsuite/19_diagnostics/error_category/102425.cc
new file mode 100644
index 000..069b5e284e1
--- /dev/null
+++ b/libstdc++-v3/testsuite/19_diagnostics/error_category/102425.cc
@@ -0,0 +1,18 @@
+// { dg-do run { target c++11 } }
+#include 
+#include 
+
+void test01()
+{
+  // PR libstdc++/102425
+  VERIFY( std::error_code() == std::error_condition() );
+
+  auto zero = std::system_category().default_error_condition(0);
+  // This is the condition that the equality above relies on:
+  VERIFY( zero.category() == std::generic_category() );
+}
+
+int main()
+{
+  test01();
+}

[committed] libstdc++: std::system_category should know meaning of zero [PR102425]

[Jonathan Wakely via Gcc-patches]

Although 0 is not an errno value, it should still be recognized as
corresponding to a value belonging to the generic_category().

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/102425
* src/c++11/system_error.cc
(system_error_category::default_error_condition): Add 0 to
switch.
* testsuite/19_diagnostics/error_category/102425.cc: New test.

Tested powerpc64le-linux. Committed to trunk.

git mailpatch dd396a321be5099536af36e64454c1fcf9d67e12
git mailpatch 477897451e46d67acb46f3ac45585e6eb9e7dde5
git mailpatch 8fa90926e08950cc00d0e22eace27402b9f9fa57
git mailpatch 43358e91bd1d2b376ce8f426cf9becedf8343a06
commit ce01e2e64c340dadb55a8a24c545a13e654804d4
Author: Jonathan Wakely 
Date:   Wed Sep 22 11:58:20 2021

libstdc++: std::system_category should know meaning of zero [PR102425]

Although 0 is not an errno value, it should still be recognized as
corresponding to a value belonging to the generic_category().

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/102425
* src/c++11/system_error.cc
(system_error_category::default_error_condition): Add 0 to
switch.
* testsuite/19_diagnostics/error_category/102425.cc: New test.

diff --git a/libstdc++-v3/src/c++11/system_error.cc 
b/libstdc++-v3/src/c++11/system_error.cc
index f12290adaee..6c79202eb0e 100644
--- a/libstdc++-v3/src/c++11/system_error.cc
+++ b/libstdc++-v3/src/c++11/system_error.cc
@@ -70,6 +70,8 @@ namespace
 virtual std::error_condition
 default_error_condition(int ev) const noexcept
 {
+  // Use generic category for all known POSIX errno values (including zero)
+  // and system category otherwise.
   switch (ev)
   {
   // List of errno macros from [cerrno.syn].
@@ -310,6 +312,7 @@ namespace
 #ifdef EXDEV
   case EXDEV:
 #endif
+  case 0:
 return std::error_condition(ev, std::generic_category());
 
   /* Additional system-dependent mappings from non-standard error codes
diff --git a/libstdc++-v3/testsuite/19_diagnostics/error_category/102425.cc 
b/libstdc++-v3/testsuite/19_diagnostics/error_category/102425.cc
new file mode 100644
index 000..069b5e284e1
--- /dev/null
+++ b/libstdc++-v3/testsuite/19_diagnostics/error_category/102425.cc
@@ -0,0 +1,18 @@
+// { dg-do run { target c++11 } }
+#include 
+#include 
+
+void test01()
+{
+  // PR libstdc++/102425
+  VERIFY( std::error_code() == std::error_condition() );
+
+  auto zero = std::system_category().default_error_condition(0);
+  // This is the condition that the equality above relies on:
+  VERIFY( zero.category() == std::generic_category() );
+}
+
+int main()
+{
+  test01();
+}

[Bug libstdc++/102425] std::error_code() does not compare equal to std::error_condition()

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102425

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:ce01e2e64c340dadb55a8a24c545a13e654804d4

commit r12-3859-gce01e2e64c340dadb55a8a24c545a13e654804d4
Author: Jonathan Wakely 
Date:   Wed Sep 22 11:58:20 2021 +0100

libstdc++: std::system_category should know meaning of zero [PR102425]

Although 0 is not an errno value, it should still be recognized as
corresponding to a value belonging to the generic_category().

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/102425
* src/c++11/system_error.cc
(system_error_category::default_error_condition): Add 0 to
switch.
* testsuite/19_diagnostics/error_category/102425.cc: New test.

[Bug c++/102419] [11/12 Regression][concepts] [regression] return-type-requirement of "Y" does not check that T::type actually exists

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102419

--- Comment #5 from Patrick Palka  ---
(In reply to Arthur O'Dwyer from comment #4)
> > IMHO Clang/MSVC are clearly misbehaving here -- when evaluating the 
> > concept-id X, they appear to be substituting {int} into X's 
> > constraint-expression instead of into the normal form of X's 
> > constraint-expression.
> 
> Isn't this situation exactly analogous to `std::void_t`?
> 
>   template using void_t = void;
>   template auto foo(T t) -> void_t;  // SFINAEs
> away
>   template auto foo(T t) -> int;  // this is the only viable
> candidate
>   static_assert(std::same_as);
> 
> The language has definitely decided that you can't preemptively fold
> `void_t` down to `void`;

True, that 
I don't think you should
> be allowed to preemptively fold `Y` down to
> `true`, either.
> I don't know for sure that Clang/MSVC have been authoritatively dubbed
> righteous, but their behavior certainly seems, to me, more consistent and
> useful than GCC's.

(In reply to Arthur O'Dwyer from comment #4)
> > IMHO Clang/MSVC are clearly misbehaving here -- when evaluating the 
> > concept-id X, they appear to be substituting {int} into X's 
> > constraint-expression instead of into the normal form of X's 
> > constraint-expression.
> 
> Isn't this situation exactly analogous to `std::void_t`?
> 
>   template using void_t = void;
>   template auto foo(T t) -> void_t;  // SFINAEs
> away
>   template auto foo(T t) -> int;  // this is the only viable
> candidate
>   static_assert(std::same_as);
> 
> The language has definitely decided that you can't preemptively fold
> `void_t` down to `void`; I don't think you should
> be allowed to preemptively fold `Y` down to
> `true`, either.

I see what you mean, but I think the constraint normalization process as
currently specified forces us to effectively perform such folding. 
Specifically in the definition of an atomic constraint
([temp.constr.atomic]p1):

  An atomic constraint is formed from an expression E and a mapping from the
template parameters that appear within E to template arguments that are formed
via substitution during constraint normalization in the declaration of a
constrained entity.

the parameter mapping of an atomic constraint is defined to consist only of the
template parameters that _appear within E_.  In this case E is just 'true',
which doesn't depend on any template parameters, so the normal form of
Y is just 'true (with empty parameter mapping)', which is
trivially satisfied for all T.

In order to achieve the behavior that you expect, IIUC this definition would
need to be changed to say that the parameter mapping of an atomic constraint
includes all in-scope template parameters and not only those that appear within
the expression.

[Bug tree-optimization/102462] vectorization breaks diagnostic for array out of bound detect.

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102462

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-23
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 Blocks||88443

--- Comment #7 from Martin Sebor  ---
One thing to note here is that the three Wstringop-overflow tests mentioned in
comment #0 disable -Warray-bounds.  With the warning enabled the affected cases
will (should) continue to trigger the expected diagnostics on the expected
lines (and not on the in bounds accesses).

I.e., the default GCC invocation (with no special codegen or warning
suppression options) should be unaffected by the -O2 -> -O3 change, and so the
regression in the quality of these diagnostics can be viewed as only minor.

That -Warray-bounds is issued on the correct lines for these cases also
confirms the viability of the idea of moving the strlen subset
-Wstringop-overflow warnings into the -Warray-bounds pass.  (As comment #6
implies, moving the whole strlen pass would likely have bigger repercussions
and is not a suitable change just to maintain warning locations).

Alternatively, since -Wstringop-overflow is documented to "warn for calls to
string manipulation functions" it might make sense to consider disabling the
-Wstringop-overflow warnings issued from the strlen pass as long as they're all
handled by -Warray-bounds.  (I'm not sure they are at present: I think
out-of-bounds subobject accesses are not detected.)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

Re: [PATCH] Fix byte char and byte string lexing code

[Arthur Cohen via Gcc-rust]

> Something I was thinking about outside of the scope of that patch was
about the utf8 how do they get represented? Is it some kind of wchar_t?

Do you mean in C++ or in rustc? In rustc, they are represented as Unicode
Scalar Values which are 4 bytes wide.

>From the docs over here: [https://doc.rust-lang.org/std/primitive.char.html]

So I'm assuming they could be represented as `int32_t`s which would also
make sense for the check

Cheers,
Arthur

Le jeu. 23 sept. 2021 à 13:43, Philip Herron  a
écrit :

> Hi guys,
>
> Thanks, Thomas for raising the PR it is currently being merged. We will
> raise the next PR to get bootstrapable builds working which will be really
> nice there is a GitHub automation for that at the moment.
>
> Something I was thinking about outside of the scope of that patch was
> about the utf8 how do they get represented? Is it some kind of wchar_t?
>
> Thanks again
>
> --Phil
>
> On Wed, 22 Sept 2021 at 21:37, Mark Wielaard  wrote:
>
>> Hi Thomas,
>>
>> On Wed, Sep 22, 2021 at 11:48:56AM +0200, Thomas Schwinge wrote:
>> > That's .
>> > [...]
>> > That's .
>>
>> Ah, sorry, I don't really track the github issues and had missed
>> those. But good to see the analysis matches.
>>
>> > Both these related to 
>> > "GCC '--enable-bootstrap' build".
>>
>> To make --enable-bootstrap possible (wow, that takes a long time...)
>> you'll also need:
>> https://gcc.gnu.org/pipermail/gcc-rust/2021-September/000178.html
>>
>> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=rust-mangle-unreachable
>>
>> With this and that patch applied there are no more warnings building
>> the rust frontend, so a --enable-bootstrap (-Werror) build completes
>> successfully.
>>
>> > >
>> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=bytecharstring
>> >
>> > Thanks, that's now: 
>> > "Fix byte char and byte string lexing code".
>>
>> Thanks,
>>
>> Mark
>>
>> --
>> Gcc-rust mailing list
>> Gcc-rust@gcc.gnu.org
>> https://gcc.gnu.org/mailman/listinfo/gcc-rust
>>
> --
> Gcc-rust mailing list
> Gcc-rust@gcc.gnu.org
> https://gcc.gnu.org/mailman/listinfo/gcc-rust
>


-- 
Arthur Cohen
+33 6 10 15 73 74
cohenarthur@gmail.com
https://github.com/cohenarthur
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or

[amacleod at redhat dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102463

--- Comment #6 from Andrew Macleod  ---
That trapping routine (relation_fold_and_or)  is looking to see if there are
any relationships between dependencies that can be exploited. ie
   c_2 = a_6 > b_7
   c_3 = a_6 < b_7
   c_4 = c_2 && c_3
  if (c_4 != 0)

when looking at c_2 and c_3, it notes that they both depend on the same 2
ssa-names,  a_6, and a_7.
It then queries whether there is a relationship between them when c_2 is [1,1]
and c_3 is [1,1].   If so, it then tries to apply that relation to see if the
stmt can never be true or not based on that raw relation.

In this case, the 2 defining stmts are both PHI nodes, which happen to have the
same 2 ssa_names in the dependency list, so it matches the pattern being looked
for:

  # ntdef_6 = PHI 
  # tdef_7 = PHI <_bfd_elf_merge_symbol_h.0_1(2), newdef_10(3)>
  _5 = __tdef_7 & ntdef_6

both names depend on the value of newdef_10 and _bfd_elf_merge_symbol_h.0_1, so
a check is being made for a relationship between op1 and op2 in those stmts.

Whats missing is that we can only check for operand relationships in range-ops
enabled stmts... The phi will never overtly give us a relation between the
first and second operand, so no need to check.

[Bug analyzer/102471] New: RFE: add support to analyzer testsuite for running SAMATE/SARD tests (e.g. Juliet Test Suite)

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102471

Bug ID: 102471
   Summary: RFE: add support to analyzer testsuite for running
SAMATE/SARD tests (e.g. Juliet Test Suite)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

See:
  https://www.nist.gov/itl/ssd/software-quality-group/samate
  https://samate.nist.gov/SARD/testsuite.php

The links above have various promising-looking testsuites e.g.
- Juliet Test Suite
- Klocwork test suite
- ITC-Benchmarks
etc

It would be good to be able to (somehow) automatically run them as part of
regression testing of the analyzer - either by turning them directly into
DejaGnu tests, or by wrapping the suite's own harness in a way that we can
invoke it during "make check".

[Ada] Wrappers of access-to-subprograms with pre/post conditions

[Pierre-Marie de Rodat via Gcc-patches]

This patch fixes decoration of wrappers of access to subprograms with
pre/post conditions (that is, wrappers internally built by the compiler
to support AI12-0220). This patch also adds assertions, fixes node
decorations, and avoids cascade errors.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_ch3.adb (Build_Access_Subprogram_Wrapper): Decorate the
wrapper with attribute Is_Wrapper, and move its declaration to
the freezing actions of its type declaration; done to facilitate
identifying it at later stages to avoid handling it as a
primitive operation of a tagged type; otherwise it may be
handled as a dispatching operation and erroneously registered in
a dispatch table.
(Make_Index): Add missing decoration of field Parent.
* sem_disp.adb (Check_Dispatching_Operation): Complete
decoration of late-overriding dispatching primitives.
(Is_Access_To_Subprogram_Wrapper): New subprogram.
(Inherited_Subprograms): Prevent cascaded errors; adding missing
support for private types.
* sem_type.adb (Add_One_Interp): Add missing support for the
first interpretation of a primitive of an inmediate ancestor
interface.
* sem_util.adb (Check_Result_And_Post_State_In_Pragma): Do not
report missing reference in postcondition placed in internally
built wrappers.
* exp_disp.adb (Expand_Dispatching_Call): Adding assertion.diff --git a/gcc/ada/exp_disp.adb b/gcc/ada/exp_disp.adb
--- a/gcc/ada/exp_disp.adb
+++ b/gcc/ada/exp_disp.adb
@@ -1016,6 +1016,10 @@ package body Exp_Disp is
 
   Typ := Find_Specific_Type (CW_Typ);
 
+  --  The tagged type of a dispatching call must be frozen at this stage
+
+  pragma Assert (Is_Frozen (Typ));
+
   if not Is_Limited_Type (Typ) then
  Eq_Prim_Op := Find_Prim_Op (Typ, Name_Op_Eq);
   end if;


diff --git a/gcc/ada/sem_ch3.adb b/gcc/ada/sem_ch3.adb
--- a/gcc/ada/sem_ch3.adb
+++ b/gcc/ada/sem_ch3.adb
@@ -6767,6 +6767,7 @@ package body Sem_Ch3 is
Make_Procedure_Specification (Loc,
  Defining_Unit_Name   => Subp,
  Parameter_Specifications => Profile);
+ Mutate_Ekind (Subp, E_Procedure);
   else
  Spec :=
Make_Function_Specification (Loc,
@@ -6775,13 +6776,32 @@ package body Sem_Ch3 is
  Result_Definition=>
New_Copy_Tree
  (Result_Definition (Type_Definition (Decl;
+ Mutate_Ekind (Subp, E_Function);
   end if;
 
   New_Decl :=
 Make_Subprogram_Declaration (Loc, Specification => Spec);
   Set_Aspect_Specifications (New_Decl, Contracts);
+  Set_Is_Wrapper (Subp);
+
+  --  The wrapper is declared in the freezing actions to facilitate its
+  --  identification and thus avoid handling it as a primitive operation
+  --  of a tagged type (see Is_Access_To_Subprogram_Wrapper); otherwise it
+  --  may be handled as a dispatching operation and erroneously registered
+  --  in a dispatch table.
+
+  if not GNATprove_Mode then
+ Ensure_Freeze_Node (Id);
+ Append_Freeze_Actions (Id, New_List (New_Decl));
+
+  --  Under GNATprove mode there is no such problem but we do not declare
+  --  it in the freezing actions since they are not analyzed under this
+  --  mode.
+
+  else
+ Insert_After (Decl, New_Decl);
+  end if;
 
-  Insert_After (Decl, New_Decl);
   Set_Access_Subprogram_Wrapper (Designated_Type (Id), Subp);
   Build_Access_Subprogram_Wrapper_Body (Decl, New_Decl);
end Build_Access_Subprogram_Wrapper;
@@ -19794,6 +19814,8 @@ package body Sem_Ch3 is
Set_Is_Non_Static_Subtype (Def_Id);
 end if;
  end if;
+
+ Set_Parent (Def_Id, N);
   end if;
 
   --  Final step is to label the index with this constructed type


diff --git a/gcc/ada/sem_disp.adb b/gcc/ada/sem_disp.adb
--- a/gcc/ada/sem_disp.adb
+++ b/gcc/ada/sem_disp.adb
@@ -1018,6 +1018,9 @@ package body Sem_Disp is
-
 
procedure Check_Dispatching_Operation (Subp, Old_Subp : Entity_Id) is
+  function Is_Access_To_Subprogram_Wrapper (E : Entity_Id) return Boolean;
+  --  Return True if E is an access to subprogram wrapper
+
   procedure Warn_On_Late_Primitive_After_Private_Extension
 (Typ  : Entity_Id;
  Prim : Entity_Id);
@@ -1025,6 +1028,22 @@ package body Sem_Disp is
   --  if it is a public primitive defined after some private extension of
   --  the tagged type.
 
+  -
+  -- Is_Access_To_Subprogram_Wrapper --
+  -
+
+  function Is_Access_To_Subprogram_Wrapper (E : Entity_Id) return Boolean
+  is
+ Decl_N : constant Node_Id := Unit_Declaration_Node (E);
+ Par_N  : constant 

[Ada] Adjust documentation of gnatsymbolize

[Pierre-Marie de Rodat via Gcc-patches]

This documents the new --load option and makes a few minor tweaks.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* doc/gnat_ugn/gnat_utility_programs.rst (gnatsymbolize):
Document new --load option and -g1 as minimal compilation
requirement.diff --git a/gcc/ada/doc/gnat_ugn/gnat_utility_programs.rst b/gcc/ada/doc/gnat_ugn/gnat_utility_programs.rst
--- a/gcc/ada/doc/gnat_ugn/gnat_utility_programs.rst
+++ b/gcc/ada/doc/gnat_ugn/gnat_utility_programs.rst
@@ -4294,10 +4294,13 @@ building specialized scripts.
 Standard Output. Has no effect otherwise.
 
   :switch:`--count={N}`
-If specified, compute the symbolic traceback ``N`` times in a row.
-This option is mostly useful for measuring the performance of
-``gnatsymbolize``, particularly in the case where the cache is
-being used.
+Compute the symbolic traceback ``N`` times in a row. This option
+is mostly useful for measuring the performance of ``gnatsymbolize``,
+particularly in the case where the cache is being used.
+
+  :switch:`--load`
+Interpret the first address as the load address of the executable.
+This is needed for position-independent executables on Windows.
 
   Requirements for Correct Operation
   --
@@ -4311,12 +4314,7 @@ building specialized scripts.
   This program provides a functionality similar to ``addr2line``.
   It has fewer options to tailor its output, but has been designed
   to require fewer of the DWARF sections to be present in the
-  executable. In particular, the following sections can be
-  stripped from the executable without impact to ``gnatsymbolize``'s
-  functionality:
-
-* ``.debug_str``
-* ``.debug_ranges``
+  executable. In particular, it works for code compiled with ``-g1``.
 
 
 .. only:: PRO or GPL

[Ada] Ada2022: implementation of AI12-0212 : iterator specs in array aggregates

[Pierre-Marie de Rodat via Gcc-patches]

This patch implements the two-pass algorithm described in RM 4.3.3
(20.2/5), for the construction of an array aggregate all of whose
component associations are iterated component associations with iterator
specifications. Each iterator specification is executed twice: once to
compute the number of elements it will generate, and build the run-time
code to evaluate the full length of the declared array, and the second
pass to generate the elements and insert them in their proper position
in the resulting aggregate.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_aggr.adb (Resolve_Array_Aggregate): Check the validity of
an array aggregate all of whose components are iterated
component associations.
* exp_aggr.adb (Expand_Array_Aggregate,
Two_Pass_Aggregate_Expansion): implement two-pass algorithm and
replace original aggregate with resulting temporary, to ensure
that a proper length check is performed if context is
constrained. Use attributes Pos and Val to handle index types of
any discrete type.diff --git a/gcc/ada/exp_aggr.adb b/gcc/ada/exp_aggr.adb
--- a/gcc/ada/exp_aggr.adb
+++ b/gcc/ada/exp_aggr.adb
@@ -5718,6 +5718,15 @@ package body Exp_Aggr is
   --  built directly into the target of the assignment it must be free
   --  of side effects. N is the LHS of an assignment.
 
+  procedure Two_Pass_Aggregate_Expansion (N : Node_Id);
+  --  If the aggregate consists only of iterated associations then the
+  --  aggregate is constructed in two steps:
+  --  a) Build an expression to compute the number of elements
+  -- generated by each iterator, and use the expression to allocate
+  -- the destination aggregate.
+  --  b) Generate the loops corresponding to each iterator to insert
+  -- the elements in their proper positions.
+
   
   -- Build_Constrained_Type --
   
@@ -6334,6 +6343,185 @@ package body Exp_Aggr is
  end if;
   end Safe_Left_Hand_Side;
 
+  --
+  -- Two_Pass_Aggregate_Expansion --
+  --
+
+  procedure Two_Pass_Aggregate_Expansion (N : Node_Id) is
+ Loc: constant Source_Ptr := Sloc (N);
+ Comp_Type  : constant Entity_Id := Etype (N);
+ Index_Id   : constant Entity_Id := Make_Temporary (Loc, 'I', N);
+ Index_Type : constant Entity_Id := Etype (First_Index (Etype (N)));
+ Size_Id: constant Entity_Id := Make_Temporary (Loc, 'I', N);
+ TmpE   : constant Entity_Id := Make_Temporary (Loc, 'A', N);
+
+ Assoc: Node_Id := First (Component_Associations (N));
+ Incr : Node_Id;
+ Iter : Node_Id;
+ New_Comp : Node_Id;
+ One_Loop : Node_Id;
+
+ Size_Expr_Code : List_Id;
+ Insertion_Code : List_Id := New_List;
+
+  begin
+ Size_Expr_Code := New_List (
+   Make_Object_Declaration (Loc,
+ Defining_Identifier => Size_Id,
+ Object_Definition   => New_Occurrence_Of (Standard_Integer, Loc),
+ Expression  => Make_Integer_Literal (Loc, 0)));
+
+ --  First pass: execute the iterators to count the number of elements
+ --  that will be generated.
+
+ while Present (Assoc) loop
+Iter := Iterator_Specification (Assoc);
+Incr := Make_Assignment_Statement (Loc,
+  Name => New_Occurrence_Of (Size_Id, Loc),
+  Expression =>
+Make_Op_Add (Loc,
+ Left_Opnd  => New_Occurrence_Of (Size_Id, Loc),
+ Right_Opnd => Make_Integer_Literal (Loc, 1)));
+
+One_Loop := Make_Loop_Statement (Loc,
+  Iteration_Scheme =>
+Make_Iteration_Scheme (Loc,
+  Iterator_Specification =>  New_Copy_Tree (Iter)),
+Statements => New_List (Incr));
+
+Append (One_Loop, Size_Expr_Code);
+Next (Assoc);
+ end loop;
+
+ Insert_Actions (N, Size_Expr_Code);
+
+ --  Build a constrained subtype with the calculated length
+ --  and declare the proper bounded aggregate object.
+ --  The index type is some discrete type, so the bounds of the
+ --  constructed array are computed as T'Val (T'Pos (ineger bound));
+
+ declare
+Pos_Lo : constant Node_Id :=
+  Make_Attribute_Reference (Loc,
+Prefix => New_Occurrence_Of (Index_Type, Loc),
+Attribute_Name => Name_Pos,
+Expressions => New_List (
+  Make_Attribute_Reference (Loc,
+Prefix => New_Occurrence_Of (Index_Type, Loc),
+Attribute_Name => Name_First)));
+
+Aggr_Lo : constant Node_Id :=

[Ada] Tune detection of internally generated positional aggregates

[Pierre-Marie de Rodat via Gcc-patches]

In Resolve_Array_Aggregate we typically compute and set Aggregate_Bounds
based on the aggregate itself. We only need to keep the already computed
bounds for aggregates that have been optimized into positional ones.

However, we kept the already computed bounds for other aggregates too.
In particular, we also kept bounds computed by
Preanalyze_Assert_Expression for consequents of Contract_Cases. This was
wrong, because those bounds could reference 'Old that we intended to be
rewritten by Expand_Attributes_In_Consequence.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_aggr.adb (Resolve_Array_Aggregate): Only keep the bounds
for internally generated attributes; otherwise, compute them
anew.diff --git a/gcc/ada/sem_aggr.adb b/gcc/ada/sem_aggr.adb
--- a/gcc/ada/sem_aggr.adb
+++ b/gcc/ada/sem_aggr.adb
@@ -2800,7 +2800,10 @@ package body Sem_Aggr is
   --  Exp_Aggr.Convert_To_Positional, so we don't want to change those
   --  bounds.
 
-  if Present (Aggregate_Bounds (N)) and then not Others_Allowed then
+  if Present (Aggregate_Bounds (N))
+and then not Others_Allowed
+and then not Comes_From_Source (N)
+  then
  Aggr_Low  := Low_Bound  (Aggregate_Bounds (N));
  Aggr_High := High_Bound (Aggregate_Bounds (N));
   end if;

[Ada] Follow-on efficiency improvements

[Pierre-Marie de Rodat via Gcc-patches]

This patch improves compiler efficiency by placing the Homonym attribute
at offset zero. Homonym is a heavily used field.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* gen_il-gen.adb: Set the number of concrete nodes that have the
Homonym field to a higher number than any other field. This
isn't true, but it forces Homonym's offset to be chosen first,
so it will be at offset zero and hence slot zero.diff --git a/gcc/ada/gen_il-gen.adb b/gcc/ada/gen_il-gen.adb
--- a/gcc/ada/gen_il-gen.adb
+++ b/gcc/ada/gen_il-gen.adb
@@ -1036,6 +1036,13 @@ package body Gen_IL.Gen is
 Append (All_Fields, F);
  end loop;
 
+ --  Force Homonym to be at offset zero, which speeds up the
+ --  compiler. The Sort below will place Homonym first in
+ --  All_Fields.
+
+ Num_Concrete_Have_Field (Homonym) :=
+   Num_Concrete_Have_Field (Nkind) + 1;
+
  --  Sort All_Fields based on how many concrete types have the field.
  --  This is for efficiency; we want to choose the offsets of the most
  --  common fields first, so they get low numbers.

[Ada] If unnesting and relocating subprogram call, make new Parameter_Associations

[Pierre-Marie de Rodat via Gcc-patches]

When unnesting, we may add static links to the actual parameters. This
will cause duplication if a the Parameter_Associations list is shared,
so ensure that we make a new one in this situation.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* atree.adb (Relocate_Node): If relocating a subprgram call and
we're doing unnesting, make a new Parameter_Associations, if
any.diff --git a/gcc/ada/atree.adb b/gcc/ada/atree.adb
--- a/gcc/ada/atree.adb
+++ b/gcc/ada/atree.adb
@@ -1962,6 +1962,22 @@ package body Atree is
  Set_Original_Node (New_Node, Original_Node (Source));
   end if;
 
+  --  If we're relocating a subprogram call and we're doing
+  --  unnesting, be sure we make a new copy of any parameter associations
+  --  so that we don't share them.
+
+  if Nkind (Source) in N_Subprogram_Call
+and then Opt.Unnest_Subprogram_Mode
+and then Present (Parameter_Associations (Source))
+  then
+ declare
+New_Assoc : constant List_Id := Parameter_Associations (Source);
+ begin
+Set_Parent (New_Assoc, New_Node);
+Set_Parameter_Associations (New_Node, New_Assoc);
+ end;
+  end if;
+
   return New_Node;
end Relocate_Node;
 

[Ada] Cleanup and efficiency improvements

[Pierre-Marie de Rodat via Gcc-patches]

This patch implements some efficiency improvements related to field
getters and setters, and implements some cleanups that make the
efficiency improvements easier.

Instead of just storing the Offset with each node, we store a node
header, which contains the Offset plus a small number of slots. Fields
with small offsets are stored in these slots.

Combine types Node_Field and Entity_Field into one enumeration type
Node_Or_Entity_Field. This allows us to avoid some code duplication.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* gen_il-gen.adb: Generate getters and setters with much of the
code inlined. Generate code for storing a few fields in the node
header, to avoid the extra level of indirection for those
fields. We generate the header type, so we don't have to
duplicate hand-written Ada and C code to depend on the number of
header fields.  Declare constants for slot size. Use short names
because these are used all over.  Remove
Put_Low_Level_Accessor_Instantiations, Put_Low_Level_C_Getter,
which are no longer needed.  Rename
Put_High_Level_C_Getter-->Put_C_Getter.
* atree.ads, atree.adb: Take into account the header slots.
Take into account the single Node_Or_Entity_Field type.  Remove
"pragma Assertion_Policy (Ignore);", because the routines in
this package are no longer efficiency critical.
* atree.h: Remove low-level getters, which are no longer used by
sinfo.h and einfo.h.
* einfo-utils.adb: Avoid crash in Known_Alignment.
* live.adb, sem_eval.adb: Remove code that prevents Node_Id from
having a predicate.  We don't actually add a predicate to
Node_Id, but we want to be able to for temporary debugging.
* sinfo-utils.adb: Remove code that prevents Node_Id from having
a predicate.  Take into account the single Node_Or_Entity_Field
type.
* sinfo-utils.ads: Minor.
* table.ads (Table_Type): Make the components aliased, because
low-level setters in Atree need to take 'Access.
* treepr.adb: Take into account the single Node_Or_Entity_Field
type.  Make some code more robust, so we can print out
half-baked nodes.
* types.ads: Move types here for visibility purposes.
* gcc-interface/gigi.h, gcc-interface/trans.c: Take into account
the Node_Header change in the GNAT front end.
* gcc-interface/cuintp.c, gcc-interface/targtyps.c: Add because
gigi.h now refers to type Node_Header, which is in sinfo.h.

patch.diff.gz
Description: application/gzip

[Ada] Remove Initializes contracts from Ada.Strings.Bounded

[Pierre-Marie de Rodat via Gcc-patches]

SPARK rules regarding constants with variable inputs and generic actual
parameters are currently not flexible enough to allow an explicit
Initializes contract on Ada.Strings.Bounded.Generic_Bounded_Length.

This patch removes the explicit contract, so that GNATprove generates an
implicit one with or without the Max_Length, as necessary.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* libgnat/a-strbou.ads (Generic_Bounded_Length): Remove explicit
Initializes contract.diff --git a/gcc/ada/libgnat/a-strbou.ads b/gcc/ada/libgnat/a-strbou.ads
--- a/gcc/ada/libgnat/a-strbou.ads
+++ b/gcc/ada/libgnat/a-strbou.ads
@@ -45,8 +45,6 @@ package Ada.Strings.Bounded with SPARK_Mode is
   --  Maximum length of a Bounded_String
 
package Generic_Bounded_Length with SPARK_Mode,
- Initializes   => (Null_Bounded_String => Max,
-   Max_Length  => Max),
  Initial_Condition => Length (Null_Bounded_String) = 0,
  Abstract_State=> null
is

[Ada] Minimize parts of Ada.Strings.Fixed marked SPARK_Mode => Off

[Pierre-Marie de Rodat via Gcc-patches]

Replace use of SPARK_Mode Off on callers of procedure Move by stronger
preconditions, as mandated by Ada RM A.4.3, so that calls to the
corresponding functions inside the procedure bodies are provably
correct.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* libgnat/a-strfix.adb (Delete, Insert, Overwrite,
Replace_Slice): Remove SPARK_Mode Off.
* libgnat/a-strfix.ads (Insert, Overwrite, Replace_Slice):
Strengthen precondition.diff --git a/gcc/ada/libgnat/a-strfix.adb b/gcc/ada/libgnat/a-strfix.adb
--- a/gcc/ada/libgnat/a-strfix.adb
+++ b/gcc/ada/libgnat/a-strfix.adb
@@ -214,7 +214,8 @@ package body Ada.Strings.Fixed with SPARK_Mode is
   -- Lemma_Split --
   -
 
-  procedure Lemma_Split (Result : String) is
+  procedure Lemma_Split (Result : String)
+  is
   begin
  for K in Ptr + 1 .. Ptr + Right'Length loop
 Lemma_Mod (K - 1);
@@ -307,7 +308,8 @@ package body Ada.Strings.Fixed with SPARK_Mode is
   From: Positive;
   Through : Natural;
   Justify : Alignment := Left;
-  Pad : Character := Space) with SPARK_Mode => Off is
+  Pad : Character := Space)
+   is
begin
   Move (Source  => Delete (Source, From, Through),
 Target  => Source,
@@ -403,7 +405,8 @@ package body Ada.Strings.Fixed with SPARK_Mode is
  (Source   : in out String;
   Before   : Positive;
   New_Item : String;
-  Drop : Truncation := Error) with SPARK_Mode => Off is
+  Drop : Truncation := Error)
+   is
begin
   Move (Source => Insert (Source, Before, New_Item),
 Target => Source,
@@ -419,7 +422,8 @@ package body Ada.Strings.Fixed with SPARK_Mode is
   Target  : out String;
   Drop: Truncation := Error;
   Justify : Alignment  := Left;
-  Pad : Character  := Space) with SPARK_Mode => Off
+  Pad : Character  := Space)
+   with SPARK_Mode => Off
is
   Sfirst  : constant Integer := Source'First;
   Slast   : constant Integer := Source'Last;
@@ -571,7 +575,8 @@ package body Ada.Strings.Fixed with SPARK_Mode is
  (Source   : in out String;
   Position : Positive;
   New_Item : String;
-  Drop : Truncation := Right) with SPARK_Mode => Off is
+  Drop : Truncation := Right)
+   is
begin
   Move (Source => Overwrite (Source, Position, New_Item),
 Target => Source,
@@ -648,7 +653,8 @@ package body Ada.Strings.Fixed with SPARK_Mode is
   By   : String;
   Drop : Truncation := Error;
   Justify  : Alignment  := Left;
-  Pad  : Character  := Space) with SPARK_Mode => Off is
+  Pad  : Character  := Space)
+   is
begin
   Move (Replace_Slice (Source, Low, High, By), Source, Drop, Justify, Pad);
end Replace_Slice;


diff --git a/gcc/ada/libgnat/a-strfix.ads b/gcc/ada/libgnat/a-strfix.ads
--- a/gcc/ada/libgnat/a-strfix.ads
+++ b/gcc/ada/libgnat/a-strfix.ads
@@ -904,7 +904,15 @@ package Ada.Strings.Fixed with SPARK_Mode is
   Justify : Alignment  := Left;
   Pad : Character  := Space)
with
- Pre=> Low - 1 <= Source'Last,
+ Pre=>
+   Low - 1 <= Source'Last
+ and then High >= Source'First - 1
+ and then (if High >= Low
+   then Natural'Max (0, Low - Source'First)
+<= Natural'Last
+   - By'Length
+   - Natural'Max (Source'Last - High, 0)
+   else Source'Length <= Natural'Last - By'Length),
 
--  Incomplete contract
 
@@ -966,7 +974,9 @@ package Ada.Strings.Fixed with SPARK_Mode is
   New_Item : String;
   Drop : Truncation := Error)
with
- Pre=> Before - 1 in Source'First - 1 .. Source'Last,
+ Pre=>
+   Before - 1 in Source'First - 1 .. Source'Last
+ and then Source'Length <= Natural'Last - New_Item'Length,
 
  --  Incomplete contract
 
@@ -1033,7 +1043,11 @@ package Ada.Strings.Fixed with SPARK_Mode is
   New_Item : String;
   Drop : Truncation := Right)
with
- Pre=> Position - 1 in Source'First - 1 .. Source'Last,
+ Pre=>
+   Position - 1 in Source'First - 1 .. Source'Last
+ and then
+   (if Position - Source'First >= Source'Length - New_Item'Length
+then Position - Source'First <= Natural'Last - New_Item'Length),
 
  --  Incomplete contract
 

[Ada] Update "Implementation Defined Characteristics" documentation.

[Pierre-Marie de Rodat via Gcc-patches]

Ada RM M.2 gives a list of implementation-defined characteristics, each
of which is required to be documented. This requirement is addressed in
the "Implementation Defined Characteristics" section of the GNAT RM.
This section needs to be updated to reflect changes to the Ada RM M.2
over the last few years.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* doc/gnat_rm/implementation_defined_characteristics.rst: Update
this section to reflect the current version of Ada RM M.2.
* gnat_rm.texi: Regenerate.

patch.diff.gz
Description: application/gzip