[Bug libstdc++/104032] New: Cannot move-assign a spanstream

[ensadc at mailnesia dot com via Gcc-bugs]

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

Bug ID: 104032
   Summary: Cannot move-assign a spanstream
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ensadc at mailnesia dot com
  Target Milestone: ---

https://godbolt.org/z/GxdYrYYrj


#include 

int main() {
std::ispanstream a(""), b("");
a = std::move(b);
}


In file included from :1:
/opt/compiler-explorer/gcc-trunk-20220114/include/c++/12.0.0/spanstream: In
instantiation of 'std::basic_spanbuf<_CharT, _Traits>&
std::basic_spanbuf<_CharT, _Traits>::operator=(std::basic_spanbuf<_CharT,
_Traits>&&) [with _CharT = char; _Traits = std::char_traits]':
/opt/compiler-explorer/gcc-trunk-20220114/include/c++/12.0.0/spanstream:258:24:
  required from here
/opt/compiler-explorer/gcc-trunk-20220114/include/c++/12.0.0/spanstream:89:7:
error: base operand of '->' has non-pointer type 'std::basic_spanbuf'
   89 |   basic_spanbuf(std::move(__rhs))->swap(*this);
  |   ^

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

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

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

--- Comment #13 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #12)
> It looks as if it is the same as in comment 8. If so, it does not seem to
> work. Cf. comment 7.

I meant: cf. comment 11.

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

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

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

--- Comment #12 from Tobias Burnus  ---
(In reply to rdapp from comment #10)
> Created attachment 52192 [details]
> Proposed patch
> 
> Could you try the proposed patch? Bootstraps cleanly for me and no
> regressions on Power or x86.

It looks as if it is the same as in comment 8. If so, it does not seem to work.
Cf. comment 7.

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

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

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

--- Comment #11 from Tobias Burnus  ---
(In reply to rdapp from comment #8)
> The following should help:

> @@ -1170,6 +1170,9 @@ vect_verify_loop_lens (loop_vec_info loop_vinfo)
> +  LOOP_VINFO_PARTIAL_LOAD_STORE_BIAS (loop_vinfo) =
> +VECT_PARTIAL_BIAS_UNSUPPORTED;

Unfortunately, this does not seem to help. If I place the debugger there,
it seems to call that function.


For the newlib testcase, I now get (in vect_set_loop_controls_directly):
(gdb) p partial_load_bias
$15 = 88

The value first pops up at:

Breakpoint 6, vect_create_loop_vinfo (loop=0x77c49578,
shared=0x7fffe250, info=0x7fffe130, main_loop_info=0x0) at
gcc-mainline/gcc/tree-vect-loop.c:1515
1515  loop_vec_info loop_vinfo = new _loop_vec_info (loop, shared);
(gdb) n
1516  LOOP_VINFO_NITERSM1 (loop_vinfo) = info->number_of_iterationsm1;
(gdb) p loop_vinfo->partial_load_store_bias 
$35 = 88 'X'

Wouldn't it make sense to add that value as initializer
to _loop_vec_info::_loop_vec_info?


Additionally, I have the feeling that vect_set_loop_controls_directly is also
supposed to be called for masked load/store not only for len_(store/load). But
I have not properly read the file.

If so, shouldn't in addition the condition
if (partial_load_bias != 0)
then be changed to
if (partial_load_bias != VECT_PARTIAL_BIAS_UNSUPPORTED && partial_load_bias
!= 0)
?

Re: git hooks: too strict check

[Michael Matz via Gcc]

Hello,

On Fri, 14 Jan 2022, Martin Liška wrote:

> Hello.
> 
> I'm working on a testsuite clean-up where some of the files are wrongly named.
> More precisely, so files have .cc extension and should use .C. However there's
> existing C test-case and it leads to:
> 
> marxin@marxinbox:~/Programming/gcc/gcc/testsuite> find . -name test-asm.*
> ./jit.dg/test-asm.C
> ./jit.dg/test-asm.c

You can't have that, the check is correct.  There are filesystems (NTFS 
for instance) that are case-preserving but case-insensitive, on those you 
really can't have two files that differ only in casing.  You need to find 
a different solution, either consistently use .cc instead of .C, live with 
the inconsistency or rename the base name of these files.


Ciao,
Michael.

> 
> test-kunlun me/rename-testsuite-files
> Enumerating objects: 804, done.
> Counting objects: 100% (804/804), done.
> Delta compression using up to 16 threads
> Compressing objects: 100% (242/242), done.
> Writing objects: 100% (564/564), 142.13 KiB | 7.48 MiB/s, done.
> Total 564 (delta 424), reused 417 (delta 295), pack-reused 0
> remote: Resolving deltas: 100% (424/424), completed with 222 local objects.
> remote: *** The following filename collisions have been detected.
> remote: *** These collisions happen when the name of two or more files
> remote: *** differ in casing only (Eg: "hello.txt" and "Hello.txt").
> remote: *** Please re-do your commit, chosing names that do not collide.
> remote: ***
> remote: *** Commit: 7297e1de9bed96821d2bcfd034bad604ce035afb
> remote: *** Subject: Rename tests in jit sub-folder.
> remote: ***
> remote: *** The matching files are:
> remote: ***
> remote: *** gcc/testsuite/jit.dg/test-quadratic.C
> remote: *** gcc/testsuite/jit.dg/test-quadratic.c
> remote: ***
> remote: *** gcc/testsuite/jit.dg/test-switch.C
> remote: *** gcc/testsuite/jit.dg/test-switch.c
> remote: ***
> remote: *** gcc/testsuite/jit.dg/test-asm.C
> remote: *** gcc/testsuite/jit.dg/test-asm.c
> remote: ***
> remote: *** gcc/testsuite/jit.dg/test-alignment.C
> remote: *** gcc/testsuite/jit.dg/test-alignment.c
> 
> Can we please do something about it?
> 
> Thanks,
> Martin
> 

[Bug middle-end/99578] [11/12 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal

[pmenzel+gcc at molgen dot mpg.de via Gcc-bugs]

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

--- Comment #21 from Paul Menzel  ---
Created attachment 52193
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52193=edit
[SeaBIOS] [PATCH] smm: Suppress gcc array-bounds warnings

For the record, I attach Kevin’s patch used to work around the issue in
SeaBIOS.

[1]:
https://mail.coreboot.org/hyperkitty/list/seab...@seabios.org/thread/HLK3BHP2T3FN6FZ46BIPIK3VD5FOU74Z/

Re: gcc/configure: out of date

[Martin Liška]

On 1/14/22 16:46, Martin Liška wrote:

Hello.

I noticed that when I run:
ACLOCAL=~/bin/automake-1.15.1/bin/aclocal  
AUTOMAKE=~/bin/automake-1.15.1/bin/automake autoconf

in gcc subfolder I get the following diff:


Have it, started with:


commit 7c6ae994fb587c19ca14aebe18dbc9aca83be609
Author: Iain Buclaw 
Date:   Thu Dec 16 23:56:16 2021 +0100

config: Add check whether D compiler works (PR103528)

As well as checking for the existence of a GDC compiler, also validate

that it has also been built with libphobos, otherwise warn or fail with
the message that GDC is required to build d.

config/ChangeLog:

PR d/103528

* acx.m4 (ACX_PROG_GDC): Add check whether D compiler works.

ChangeLog:

* configure: Regenerate.


I'm going to push the patch I pasted in the previous email.

Martin

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

[rdapp at linux dot ibm.com via Gcc-bugs]

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

--- Comment #10 from rdapp at linux dot ibm.com ---
Created attachment 52192
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52192=edit
Proposed patch

Could you try the proposed patch? Bootstraps cleanly for me and no regressions
on Power or x86.

gcc/configure: out of date

[Martin Liška]

Hello.

I noticed that when I run:
ACLOCAL=~/bin/automake-1.15.1/bin/aclocal  
AUTOMAKE=~/bin/automake-1.15.1/bin/automake autoconf

in gcc subfolder I get the following diff:

diff --git a/gcc/configure b/gcc/configure
index d19059e13cc..ff570f73ef5 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -5352,7 +5352,26 @@ else
   GDC="$ac_cv_prog_GDC"
 fi
 
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether the D compiler works" >&5

+$as_echo_n "checking whether the D compiler works... " >&6; }
+if ${acx_cv_d_compiler_works+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  cat >conftest.d <&1 || echo failure`
+  if test x"$errors" = x && test -f conftest.$ac_objext; then
+acx_cv_d_compiler_works=yes
+  fi
+  rm -f conftest.*
+fi
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $acx_cv_d_compiler_works" >&5
+$as_echo "$acx_cv_d_compiler_works" >&6; }
+if test "x$GDC" != xno && test x$acx_cv_d_compiler_works != xno; then
   have_gdc=yes
 else
   have_gdc=no
@@ -19640,7 +19659,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19643 "configure"
+#line 19662 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H

@@ -19746,7 +19765,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19749 "configure"
+#line 19768 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H


Am I correct that somebody forgot to re-generate the file?

Martin

Re: reordering of trapping operations and volatile

[Martin Uecker via Gcc]

Am Freitag, den 14.01.2022, 14:15 + schrieb Michael Matz:
> Hello,
> 
> On Thu, 13 Jan 2022, Martin Uecker wrote:

...

> > >  I think to define this 
> > > all rigorously seems futile (you need a new
> > > category between observable  and UB), so it comes
> > > down to compiler QoI on a case by case basis.
> > 
> > We would simply change UB to mean "arbitrary
> > behavior at the point of time the erraneous
> > construct is encountered at run-time"  and 
> > not "the complete program is invalid all
> > together". I see no problem in specifying this
> > (even in a formally precise way)
> 
> First you need to define "point in time", a concept which doesn't exist 
> yet in C.  The obvious choice is of course observable behaviour in the 
> execution environment and its specified ordering from the abstract 
> machine, as clarified via sequence points.  With that your "at the point 
> in time" becomes something like "after all side effects of previous 
> sequence point, but strictly before all side effects of next sequence 
> point".

Yes, all observable side effects sequenced before
the erroneous operation should be preserved. We
also need to consider multi-threading (happens-before)
But I do not think there is any need to discuss the
precise wording now.

> But doing that would have very far reaching consequences, as already
> stated in this thread.  

We already agreed that UB already works like this
relative to every function call.  So why do you
think this could have far reaching consequences
when we also require this for volatile accesses
- considering that volatile accesses are not nearly
as common as function calls, and often already
limit optimization?

We had a lot of trouble even finding examples where
compiler currently exhibit behavior that would need
to change.

> The above would basically make undefined behaviour 
> be reliably countable, and all implementations would need to produce the 
> same counts of UB.  That in turn disables many code movement and 
> commonization transformations, e.g. this:
> 
> int a = ..., b = ...;
> int x = a + b;
> int y = a + b;
> 
> can't be transformed into "y = x = a + b" anymore, because the addition 
> _might_ overflow, and if it does you have two UBs originally but would 
> have one UB after.  I know that you don't want to inhibit this or similar 
> transformations, but that would be the result of making UB countable, 
> which is the result of forcing UB to happen at specific points in time.  
> So, I continue to see problems in precisely specifying what you want, _but 
> not more_.

Don't worry, I do not want to make UB observable or
countable. Your example does not contain observable
behavior, so would be unaffected.

> I think all models in which you order the happening of UB with respect to 
> existing side effects (per abstract machine, so it includes modification 
> of objects!) have this same problem, it always becomes a side effect 
> itself (one where you don't specify what actually happens, but a side 
> effect nontheless) and hence becomes observable.

I don't think so. The standard always only defines behavior.
Here, would only guarantee that observable behavior before
a specific time point stays defined. For this we do not make
UB observable or countable because the statements we make 
is not about the UB,  but about the defined behavior before.


Martin

[Bug preprocessor/104030] [12 Regression] -Wbidi-chars should not warn about UCNs

[sbergman at redhat dot com via Gcc-bugs]

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

--- Comment #7 from Stephan Bergmann  ---
(In reply to Jakub Jelinek from comment #2)
> Of course, if something like libreoffice (I bet) carefully ensures it is
> paired, but constructs it from smaller separate literals, then it is fine.

(Or doesn't even need to ensure that e.g. a LRO is paired with a PDF, as my
understanding of  "Unicode
Bidirectional Algorithm" is that such an LRO doesn't require a matching PDF, in
which case its effect extends to the end of the paragraph, which appears to be
what the example LibreOffice code in comment 0 makes use of.)

Re: [PATCH] testsuite: Robustify aarch64/simd tests against more aggressive DCE

[Marc Poulhies via Gcc-patches]

Eric Botcazou  writes:

>> The new variables seem to be unused, so I think slightly stronger
>> DCE could remove the calls even after the patch.  Perhaps the containing
>> functions should take an int32x4_t *ptr or something, with the calls
>> assigning to different ptr[] indices.
>
> We run a minimal DCE pass at -O0 in our compiler to eliminate all the garbage 
> generated by the gimplifier for variable-sized types (people care about code 
> size at -O0 in specific contexts) but it does not touch anything written by 
> the user (and debugging is unaffected of course).  Given that the builtins 
> are 
> pure functions and the arguments have no side effects, it eliminates the 
> calls, but adding a LHS blocks that because this minimal DCE pass preserves 
> anything user-related, in particular assignments to user variables.
>
>> I think it would be better to do that using new calls though,
>> and xfail the existing ones when they no longer work.  For example:
>> 
>>   /* { dg-error "lane -1 out of range 0 - 7" "" {target *-*-*} 0 } */
>>   vqdmlal_high_laneq_s16 (int32x4_a, int16x8_b, int16x8_c, -1);
>>   /* { dg-error "lane -1 out of range 0 - 7" "" {target *-*-*} 0 } */
>>   ptr[0] = vqdmlal_high_laneq_s16 (int32x4_a, int16x8_b, int16x8_c, -1);
>> 
>> That way we don't lose the existing tests.
>
> Frankly I'm not quite sure of what we can lose by adding a LHS here, can you 
> elaborate a bit?  We would need a solution that works out of the box with our 
> compiler in the future, i.e. without having to tweak 50 testcases again.

Hi Richard,

Thank for your reply !

As Éric, I'm also wondering why having LHS in the existing tests would
make us loose them. I guess I'm not familiar enough with this part of
the testsuite and I'm missing something.

Thanks,
Marc

[Bug preprocessor/104030] [12 Regression] -Wbidi-chars should not warn about UCNs

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

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

--- Comment #6 from Jakub Jelinek  ---
Or support -Wbidi-chars=unpaired,ucn or -Wbidi-chars=any,ucn ?

Re: [PATCH] git-backport: support renamed .cc files in commit message.

[Martin Liška]

On 1/14/22 08:44, Bernhard Reutner-Fischer wrote:

On Wed, 12 Jan 2022 16:54:46 +0100
Martin Liška  wrote:


+def replace_file_in_changelog(lines, filename):
+if not filename.endswith('.cc'):
+return
+
+# consider all componenets of a path: gcc/ipa-icf.cc
+while filename:
+for i, line in enumerate(lines):
+if filename in line:
+line = line.replace(filename, filename[:-1])
+lines[i] = line
+return
+parts = filename.split('/')
+if len(parts) == 1:
+return
+filename = '/'.join(parts[1:])
+


I think you mean os.sep instead of the hardcoded slash.
But i'd use os.path.split and os.path.join


Hello.

Well, these are all paths from a git commit message. And we require unix-style
of paths for all ChangeLog entries. So it should be correct.

Martin



thanks,

Re: [PATCH] git-backport: support renamed .cc files in commit message.

[Martin Liška]

On 1/14/22 08:44, Bernhard Reutner-Fischer wrote:

On Wed, 12 Jan 2022 16:54:46 +0100
Martin Liška  wrote:


+def replace_file_in_changelog(lines, filename):
+if not filename.endswith('.cc'):
+return
+
+# consider all componenets of a path: gcc/ipa-icf.cc
+while filename:
+for i, line in enumerate(lines):
+if filename in line:
+line = line.replace(filename, filename[:-1])
+lines[i] = line
+return
+parts = filename.split('/')
+if len(parts) == 1:
+return
+filename = '/'.join(parts[1:])
+


I think you mean os.sep instead of the hardcoded slash.
But i'd use os.path.split and os.path.join


Hello.

Well, these are all paths from a git commit message. And we require unix-style
of paths for all ChangeLog entries. So it should be correct.

Martin



thanks,

[PATCH][pushed] testsuite: fix dh-warning typo.

[Martin Liška]

gcc/testsuite/ChangeLog:

* c-c++-common/Walloca-larger-than.c: Fix typo.
---
 gcc/testsuite/c-c++-common/Walloca-larger-than.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/Walloca-larger-than.c 
b/gcc/testsuite/c-c++-common/Walloca-larger-than.c
index 464ea242a7a..e7851eabb46 100644
--- a/gcc/testsuite/c-c++-common/Walloca-larger-than.c
+++ b/gcc/testsuite/c-c++-common/Walloca-larger-than.c
@@ -16,6 +16,6 @@ void warn_alloca_too_large (void)
 {
   sink (alloca (1));
   sink (alloca (128));
-  sink (alloca (129));// { dh-warning "\\\[-Walloca-larger-than" }
-  sink (alloca (1024));   // { dh-warning "\\\[-Walloca-larger-than" }
+  sink (alloca (129));// { dg-warning "\\\[-Walloca-larger-than" }
+  sink (alloca (1024));   // { dg-warning "\\\[-Walloca-larger-than" }
 }
--
2.34.1

[Bug analyzer/104029] [12 Regression] ICE with -fanalyzer-checker=taint since r12-5230-gb9365b93212041f1

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from David Malcolm  ---
Thanks for filing this; am working on a fix.

[PATCH] i386: Mark some of strict_low_part insn constraints earlyclobbered

[Uros Bizjak via Gcc-patches]

While there is practically impossible that input registers are matched
with in-out register, better mark the output operand of the split alternative
as earlyclobbered - we do output early to the output operand when
the insn is split.

2022-01-14  Uroš Bizjak  

gcc/ChangeLog:

* config/i386/i386.md (*add_1_slp"):
Mark alternative 1 output operand earlyclobbered.
(*sub_1_slp): Ditto.
(*and_1_slp): Ditto.
(*_1_slp): Ditto.
(*neg_1_slp): Ditto.
(*one_cmpl_1_slp): Ditto.
(*ashl3_1_slp): Ditto.
(*3_1_slp): Ditto.
(*3_1_slp): Ditto.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Pushed to master.

Uros.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index c2acb1dbd90..bd965df79df 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -5902,7 +5902,7 @@
 
 ;; Alternative 1 is needed to work around LRA limitation, see PR82524.
 (define_insn_and_split "*add_1_slp"
-  [(set (strict_low_part (match_operand:SWI12 0 "register_operand" "+,"))
+  [(set (strict_low_part (match_operand:SWI12 0 "register_operand" 
"+,&"))
(plus:SWI12 (match_operand:SWI12 1 "nonimmediate_operand" "%0,!")
(match_operand:SWI12 2 "general_operand" "mn,mn")))
(clobber (reg:CC FLAGS_REG))]
@@ -6856,7 +6856,7 @@
 
 ;; Alternative 1 is needed to work around LRA limitation, see PR82524.
 (define_insn_and_split "*sub_1_slp"
-  [(set (strict_low_part (match_operand:SWI12 0 "register_operand" "+,"))
+  [(set (strict_low_part (match_operand:SWI12 0 "register_operand" 
"+,&"))
(minus:SWI12 (match_operand:SWI12 1 "register_operand" "0,!")
 (match_operand:SWI12 2 "general_operand" "mn,mn")))
(clobber (reg:CC FLAGS_REG))]
@@ -9905,7 +9905,7 @@
 
 ;; Alternative 1 is needed to work around LRA limitation, see PR82524.
 (define_insn_and_split "*and_1_slp"
-  [(set (strict_low_part (match_operand:SWI12 0 "register_operand" "+,"))
+  [(set (strict_low_part (match_operand:SWI12 0 "register_operand" 
"+,&"))
(and:SWI12 (match_operand:SWI12 1 "nonimmediate_operand" "%0,!")
   (match_operand:SWI12 2 "general_operand" "mn,mn")))
(clobber (reg:CC FLAGS_REG))]
@@ -10543,7 +10543,7 @@
 
 ;; Alternative 1 is needed to work around LRA limitation, see PR82524.
 (define_insn_and_split "*_1_slp"
-  [(set (strict_low_part (match_operand:SWI12 0 "register_operand" "+,"))
+  [(set (strict_low_part (match_operand:SWI12 0 "register_operand" 
"+,&"))
(any_or:SWI12 (match_operand:SWI12 1 "nonimmediate_operand" "%0,!")
  (match_operand:SWI12 2 "general_operand" "mn,mn")))
(clobber (reg:CC FLAGS_REG))]
@@ -10897,7 +10897,7 @@
 
 ;; Alternative 1 is needed to work around LRA limitation, see PR82524.
 (define_insn_and_split "*neg_1_slp"
-  [(set (strict_low_part (match_operand:SWI12 0 "register_operand" "+,"))
+  [(set (strict_low_part (match_operand:SWI12 0 "register_operand" 
"+,&"))
(neg:SWI12 (match_operand:SWI12 1 "register_operand" "0,!")))
(clobber (reg:CC FLAGS_REG))]
   "!TARGET_PARTIAL_REG_STALL || optimize_function_for_size_p (cfun)"
@@ -11490,7 +11490,7 @@
 
 ;; Alternative 1 is needed to work around LRA limitation, see PR82524.
 (define_insn_and_split "*one_cmpl_1_slp"
-  [(set (strict_low_part (match_operand:SWI12 0 "register_operand" "+,"))
+  [(set (strict_low_part (match_operand:SWI12 0 "register_operand" 
"+,&"))
(not:SWI12 (match_operand:SWI12 1 "register_operand" "0,!")))]
   "!TARGET_PARTIAL_REG_STALL || optimize_function_for_size_p (cfun)"
   "@
@@ -12186,7 +12186,7 @@
 
 ;; Alternative 1 is needed to work around LRA limitation, see PR82524.
 (define_insn_and_split "*ashl3_1_slp"
-  [(set (strict_low_part (match_operand:SWI12 0 "register_operand" "+,"))
+  [(set (strict_low_part (match_operand:SWI12 0 "register_operand" 
"+,&"))
(ashift:SWI12 (match_operand:SWI12 1 "register_operand" "0,!")
  (match_operand:QI 2 "nonmemory_operand" "cI,cI")))
(clobber (reg:CC FLAGS_REG))]
@@ -13063,7 +13063,7 @@
 
 ;; Alternative 1 is needed to work around LRA limitation, see PR82524.
 (define_insn_and_split "*3_1_slp"
-  [(set (strict_low_part (match_operand:SWI12 0 "register_operand" "+,"))
+  [(set (strict_low_part (match_operand:SWI12 0 "register_operand" 
"+,&"))
(any_shiftrt:SWI12 (match_operand:SWI12 1 "register_operand" "0,!")
   (match_operand:QI 2 "nonmemory_operand" "cI,cI")))
(clobber (reg:CC FLAGS_REG))]
@@ -13607,7 +13607,7 @@
 
 ;; Alternative 1 is needed to work around LRA limitation, see PR82524.
 (define_insn_and_split "*3_1_slp"
-  [(set (strict_low_part (match_operand:SWI12 0 "register_operand" "+,"))
+  [(set (strict_low_part (match_operand:SWI12 0 "register_operand" 
"+,&"))
(any_rotate:SWI12 (match_operand:SWI12 1 "register_operand" "0,!")
  (match_operand:QI 2 "nonmemory_operand" "cI,cI")))
(clobber (reg:CC FLAGS_REG))]

[Bug preprocessor/104030] [12 Regression] -Wbidi-chars should not warn about UCNs

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

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

--- Comment #5 from Marek Polacek  ---
So maybe add -Wbidi-chars-ucn, which is off by default.

[Bug preprocessor/104030] [12 Regression] -Wbidi-chars should not warn about UCNs

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

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

--- Comment #4 from Marek Polacek  ---
(In reply to Jakub Jelinek from comment #2)
> Either we drop the UCN support altogether, or make -Wbidi-chars a 2 level
> warning, -Wbidi-chars mapping to -Wbidi-chars=1 which doesn't warn about
> UCNs and
> -Wbidi-chars=2 that does.

Exactly.  Except I'm not sure how well that will play with the rest of the
-Wbidi-chars= suboptions.  :/

Like,

-Wbidi-chars=any -Wbidi-chars=2

should probably warn about any bidi chars, including UCNs, but the latter
option might cause it to be just -Wbidi-chars=unpaired, but warn about UCNs.

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-01-14
 Ever confirmed|0   |1
 CC||ktkachov at gcc dot gnu.org
 Target|amdgcn-amdhsa   |amdgcn-amdhsa, aarch64

--- Comment #9 from ktkachov at gcc dot gnu.org ---
We're also seeing this on aarch64-none-elf with:
#include 

void execute(int *y);

void foo (int n) {
  int *b = (int *)malloc((n - 1) * sizeof(int));
  execute(b);

  int n1 = 1.0 / (n - 1);
  for (int i = 0; i < n - 1; i++) {
b[i] *= n1;
  }
}

compiled with -O2 -march=armv8-a+sve

[Bug preprocessor/104030] [12 Regression] -Wbidi-chars should not warn about UCNs

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Or e.g. for identifiers with UCNs in them, if they aren't paired, then
as/ld/readelf/demangler at runtime etc. can show weird things.

Re: reordering of trapping operations and volatile

[Paul Koning via Gcc]

> On Jan 14, 2022, at 9:15 AM, Michael Matz via Gcc  wrote:
> 
> Hello,
> 
> On Thu, 13 Jan 2022, Martin Uecker wrote:
> 
> Handling all volatile accesses in the very same way would be 
> possible but quite some work I don't see much value in.
 
 I see some value. 
 
 But an alternative could be to remove volatile
 from the observable behavior in the standard
 or make it implementation-defined whether it
 is observable or not.
>>> 
>>> But you are actually arguing for making UB be observable
>> 
>> No, I am arguing for UB not to have the power
>> to go back in time and change previous defined
>> observable behavior.
> 
> But right now that's equivalent to making it observable,
> because we don't have any other terms than observable or
> undefined.  As aluded to later you would have to
> introduce a new concept, something pseudo-observable,
> which you then started doing.  So, see below.

I find it really hard to view this notion of doing work for UB with any favor.  
The way I see it is that a program having UB is synonymous with "defective 
program" and for the compiler to do extra work for these doesn't make much 
sense to me.

If the issue is specifically the handling of overflow traps, perhaps a better 
answer would be to argue for language changes that manage such events 
explicitly rather than having them be undefined behavior.  Another (similar) 
option might be to choose a language in which this is done.  (Is Ada such a 
language?  I don't remember.)

paul

[Bug preprocessor/104030] [12 Regression] -Wbidi-chars should not warn about UCNs

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

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

--- Comment #2 from Jakub Jelinek  ---
Either we drop the UCN support altogether, or make -Wbidi-chars a 2 level
warning, -Wbidi-chars mapping to -Wbidi-chars=1 which doesn't warn about UCNs
and
-Wbidi-chars=2 that does.
UCNs indeed don't have the problem that a user in an editor sees something
different than what it actually is (unless some editor interprets UCNs and
shows them as unicode chars), but one reason to warn about UCNs was to make
sure that even what the program prints doesn't suffer from such problems.  Of
course, if something like libreoffice (I bet) carefully ensures it is paired,
but constructs it from smaller separate literals, then it is fine.

[Bug c++/104031] [12 regression] Global nested constructors generate invalid code since r12-6329-g4f6bc28fc7dd86bd

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-01-14
 Ever confirmed|0   |1
   Target Milestone|--- |12.0
Summary|[12 regression] Global  |[12 regression] Global
   |nested constructors |nested constructors
   |generate invalid code.  |generate invalid code since
   ||r12-6329-g4f6bc28fc7dd86bd
 Status|UNCONFIRMED |NEW
   Priority|P3  |P1
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Keywords||wrong-code

--- Comment #1 from Martin Liška  ---
Also started with r12-6329-g4f6bc28fc7dd86bd.

[Bug preprocessor/104030] [12 Regression] -Wbidi-chars should not warn about UCNs

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|-Wbidi-chars should not |[12 Regression]
   |warn about UCNs |-Wbidi-chars should not
   ||warn about UCNs
   Last reconfirmed||2022-01-14
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |12.0
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Mine then.  Regression because it rejects previously accepted code.

Re: [PATCH] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]

[Stephan Bergmann via Gcc-patches]

On 14/01/2022 14:28, Marek Polacek wrote:

On Fri, Jan 14, 2022 at 10:23:16AM +0100, Stephan Bergmann wrote:

On 30/11/2021 16:27, Marek Polacek wrote:

I guess we were concerned with programs that generate other programs.
Maybe UCNs should be ignored by default.  There's still time to adjust
the behavior.


Is there any update on this?  Shall I file a bug?  As-is, -Wbidi-chars is
unusable for building LibreOffice and (esp. in combination with
 "C++ preprocessor
ignores #pragma GCC diagnostic") has to be explicitly disabled globally.


No update, it wasn't clear to me what the action should be here.

Please do file a bug.  I think I'll just have to adjust the warning to ignore
UCNs.


 "-Wbidi-chars 
should not warn about UCNs"

[Bug c++/104031] New: [12 regression] Global nested constructors generate invalid code.

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

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

Bug ID: 104031
   Summary: [12 regression] Global nested constructors generate
invalid code.
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Extracted from original example of nix-2.4 where global constructors register
invalid primops. Single-file example:

// $ cat main.cc
#include 
#include 

struct Info {
std::vector args;
size_t arity = 0;
};

struct RegisterPrimOp
{
RegisterPrimOp(Info && info) __attribute__((noipa, noinline)) {
if (info.arity != 0)
__builtin_trap();
}
};

static RegisterPrimOp s_op({
.args = {"path"},
.arity = 0,
});

int main() {}

# ok:
$ g++-11.2.0 main.cc -o main -O2 && ./main
# bad:
$ g++-12.0.0 main.cc -o main -O2 && ./main
Illegal instruction (core dumped)

Using built-in specs.
COLLECT_GCC=/<>/gcc-12.0.0/bin/g++
COLLECT_LTO_WRAPPER=/<>/gcc-12.0.0/libexec/gcc/x86_64-unknown-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20220109 (experimental) (GCC)

Must be a recent regression. Possibly a close sibling of diagnostic false
positive: https://gcc.gnu.org/PR103984

[Bug preprocessor/104030] New: -Wbidi-chars should not warn about UCNs

[sbergman at redhat dot com via Gcc-bugs]

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

Bug ID: 104030
   Summary: -Wbidi-chars should not warn about UCNs
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

As discussed in the sub-thread starting at
 "Re:
[PATCH] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]",
-Wbidi-chars should not emit warnings when the problematic characters are
written as UCNs rather than verbatim.  For example, the line

> aText = u"\u202D" + aText;

found in the LibreOffice source code should not cause a warning (which couldn't
even be silenced with a local `#pragma GCC diagnostic ignored "-Wbidi-chars"`
due to bug 53431).

[Bug testsuite/104023] Bulk rename of C++ test files to one filename extension ?

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

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

--- Comment #8 from Martin Liška  ---
I have the following suggestion:

- require all C++ files in gcc/testsuite to have .C extension with the
following exceptions:

1) allow .cc and .cpp for tests of inherited projects (./gdc.test)
2) allow .cc extension for additional files not used directly, but require the
file ending with -aux.cc or -main.cc. Note quite some filenames do follow the
naming scheme

What do you think?

[Bug testsuite/104023] Bulk rename of C++ test files to one filename extension ?

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

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

--- Comment #7 from Jakub Jelinek  ---
I'd say renaming the *.C in tests to something else would only bring pain and
no gain.

[Bug testsuite/104023] Bulk rename of C++ test files to one filename extension ?

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Yeah, a lot of test directories rely on one extension for the test and another
for auxiliary sources.
Furthermore, e.g. for libraries inherited from upstreams, we should use
extensions those projects use rather than switching to something we choose.

[Bug testsuite/104023] Bulk rename of C++ test files to one filename extension ?

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Working on that.

RE: [PATCH v3 00/15] ARM/MVE use vectors of boolean for predicates

[Kyrylo Tkachov via Gcc-patches]

Hi Christophe, Richard,

> -Original Message-
> From: Gcc-patches  bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Richard
> Biener via Gcc-patches
> Sent: Friday, January 14, 2022 1:33 PM
> To: Christophe Lyon 
> Cc: GCC Patches 
> Subject: Re: [PATCH v3 00/15] ARM/MVE use vectors of boolean for
> predicates
> 
> On Fri, Jan 14, 2022 at 2:18 PM Christophe Lyon via Gcc-patches
>  wrote:
> >
> > Hi,
> >
> > I hadn't realized we are moving to stage 4 this week-end :-(
> >
> > The PRs I'm fixing are P3, but without these fixes MVE support is badly
> > broken, so I think I would be really good to fix that before the buggy
> > version becomes part of an actual release.
> > Anyway I posted v1 of the patches during stage1, so it should still be OK
> > if they are accepted as-is ?
> 
> In the end it's up to the target maintainers to weight the risk of breakage
> vs. the risk of not usefulness ;)  But stage3 is where the "was posted
> during stage1"
> rule can easily apply - at some point we have to stop with such general 
> ruling.
> 

Thanks, that's in line with my interpretation.
These patches resolve some nasty brokenness in the MVE support that I'm keen to 
see fixed and from what I can tell the patches shouldn't have a large effect on 
non-MVE code.
So the risk vs reward balance for the arm port as a whole looks good to me.
Andre has kindly agreed to help review the patches and I'll also try to get to 
them today and next week so that we can get them in early stage4.

Thanks,
Kyrill

> Richard.
> 
> > Thanks,
> >
> > Christophe
> >
> > On Thu, Jan 13, 2022 at 3:58 PM Christophe Lyon via Gcc-patches <
> > gcc-patches@gcc.gnu.org> wrote:
> >
> > >
> > > This is v3 of this patch series, fixing issues I discovered before
> > > committing v2 (which had been approved).
> > >
> > > Thanks a lot to Richard Sandiford for his help.
> > >
> > > The changes v2 -> v3 are:
> > >
> > > Patch 4: Fix arm_hard_regno_nregs and CLASS_MAX_NREGS to support
> VPR.
> > >
> > > Patch 7: Changes to the underlying representation of vectors of
> > > booleans to account for the different expectations between AArch64/SVE
> > > and Arm/MVE.
> > >
> > > Patch 8: Re-use and extend existing thumb2_movhi* patterns instead of
> > > duplicating them in mve_mov. This requires the introduction of a
> > > new constraint to match a constant vector of booleans. Add a new RTL
> > > test.
> > >
> > > Patch 9: Introduce check_effective_target_arm_mve and skip
> > > gcc.dg/signbit-2.c, because with MVE there is no fallback architecture
> > > unlike SVE or AVX512.
> > >
> > > Patch 12: Update less load/store MVE builtins
> > > (mve_vldrdq_gather_base_z_v2di,
> > > mve_vldrdq_gather_offset_z_v2di,
> > > mve_vldrdq_gather_shifted_offset_z_v2di,
> > > mve_vstrdq_scatter_base_p_v2di,
> > > mve_vstrdq_scatter_offset_p_v2di,
> > > mve_vstrdq_scatter_offset_p_v2di_insn,
> > > mve_vstrdq_scatter_shifted_offset_p_v2di,
> > > mve_vstrdq_scatter_shifted_offset_p_v2di_insn,
> > > mve_vstrdq_scatter_base_wb_p_v2di,
> > > mve_vldrdq_gather_base_wb_z_v2di,
> > > mve_vldrdq_gather_base_nowb_z_v2di,
> > > mve_vldrdq_gather_base_wb_z_v2di_insn) for which we keep HI
> mode
> > > for vpr_register_operand.
> > >
> > > Patch 13: No need to update
> > > gcc.target/arm/acle/cde-mve-full-assembly.c anymore since we re-use
> > > the mov pattern that emits '@ movhi' in the assembly.
> > >
> > > Patch 15: This is a new patch to fix a problem I noticed during this
> > > v2->v3 update.
> > >
> > >
> > >
> > > I'll squash patch 2 with patch 9 and patch 3 with patch 8.
> > >
> > > Original text:
> > >
> > > This patch series addresses PR 100757 and 101325 by representing
> > > vectors of predicates (MVE VPR.P0 register) as vectors of booleans
> > > rather than using HImode.
> > >
> > > As this implies a lot of mostly mechanical changes, I have tried to
> > > split the patches in a way that should help reviewers, but the split
> > > is a bit artificial.
> > >
> > > Patches 1-3 add new tests.
> > >
> > > Patches 4-6 are small independent improvements.
> > >
> > > Patch 7 implements the predicate qualifier, but does not change any
> > > builtin yet.
> > >
> > > Patch 8 is the first of the two main patches, and uses the new
> > > qualifier to describe the vcmp and vpsel builtins that are useful for
> > > auto-vectorization of comparisons.
> > >
> > > Patch 9 is the second main patch, which fixes the vcond_mask expander.
> > >
> > > Patches 10-13 convert almost all the remaining builtins with HI
> > > operands to use the predicate qualifier.  After these, there are still
> > > a few builtins with HI operands left, about which I am not sure: vctp,
> > > vpnot, load-gather and store-scatter with v2di operands.  In fact,
> > > patches 11/12 update some STR/LDR qualifiers in a way that breaks
> > > these v2di builtins although existing tests still pass.
> > >
> > > Christophe Lyon (15):
> > >   arm: Add new tests for comparison vectorization with Neon and MVE
> > >   arm: Add 

[Bug c++/85944] Address of temporary bound to a function parameter at global scope not considered constexpr

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #3 from Patrick Palka  ---
The problem seems to be that maybe_nonzero_address doesn't return true for all
temporaries, only those created at function scope, but here the temporary for
'S{}' is created at namespace scope.

Re: reordering of trapping operations and volatile

[Michael Matz via Gcc]

Hello,

On Thu, 13 Jan 2022, Martin Uecker wrote:

> > > >  Handling all volatile accesses in the very same way would be 
> > > > possible but quite some work I don't see much value in.
> > > 
> > > I see some value. 
> > > 
> > > But an alternative could be to remove volatile
> > > from the observable behavior in the standard
> > > or make it implementation-defined whether it
> > > is observable or not.
> > 
> > But you are actually arguing for making UB be observable
> 
> No, I am arguing for UB not to have the power
> to go back in time and change previous defined
> observable behavior.

But right now that's equivalent to making it observable,
because we don't have any other terms than observable or
undefined.  As aluded to later you would have to
introduce a new concept, something pseudo-observable,
which you then started doing.  So, see below.
 
> > That's 
> > much different from making volatile not be
> > observable anymore (which  obviously would
> > be a bad idea), and is also much harder to
> 
> I tend to agree that volatile should be
> considered observable. But volatile is
> a bit implementation-defined anyway, so this
> would be a compromise so that implementations
> do not have to make all the implied changes
> if we revise the meaning of UB.

Using volatile accesses for memory mapped IO is a much stronger use-case 
than your wish of using volatile accesses to block moving of UB as a 
debugging aid, and the former absolutely needs some guarantees, so I don't 
think it would be a compromise at all.  Mkaing volatile not be observable 
would break the C language.

> > Well, what you _actually_ want is an implied
> > dependency between some UB and volatile accesses
> > (and _only_ those, not e.g. with other UB), and the 
> > difficulty now is to define "some" and to create
> > the dependency without making that specific UB
> > to be properly observable. 
> 
> Yes, this is what I actually want.
> 
> >  I think to define this 
> > all rigorously seems futile (you need a new
> > category between observable  and UB), so it comes
> > down to compiler QoI on a case by case basis.
> 
> We would simply change UB to mean "arbitrary
> behavior at the point of time the erraneous
> construct is encountered at run-time"  and 
> not "the complete program is invalid all
> together". I see no problem in specifying this
> (even in a formally precise way)

First you need to define "point in time", a concept which doesn't exist 
yet in C.  The obvious choice is of course observable behaviour in the 
execution environment and its specified ordering from the abstract 
machine, as clarified via sequence points.  With that your "at the point 
in time" becomes something like "after all side effects of previous 
sequence point, but strictly before all side effects of next sequence 
point".

But doing that would have very far reaching consequences, as already
stated in this thread.  The above would basically make undefined behaviour 
be reliably countable, and all implementations would need to produce the 
same counts of UB.  That in turn disables many code movement and 
commonization transformations, e.g. this:

int a = ..., b = ...;
int x = a + b;
int y = a + b;

can't be transformed into "y = x = a + b" anymore, because the addition 
_might_ overflow, and if it does you have two UBs originally but would 
have one UB after.  I know that you don't want to inhibit this or similar 
transformations, but that would be the result of making UB countable, 
which is the result of forcing UB to happen at specific points in time.  
So, I continue to see problems in precisely specifying what you want, _but 
not more_.

I think all models in which you order the happening of UB with respect to 
existing side effects (per abstract machine, so it includes modification 
of objects!) have this same problem, it always becomes a side effect 
itself (one where you don't specify what actually happens, but a side 
effect nontheless) and hence becomes observable.


Ciao,
Michael.

[Bug tree-optimization/104012] [12 regression] -Wformat-truncation warnings not taking previous length check into account

[eike--- via Gcc-bugs]

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

--- Comment #4 from Rolf Eike Beer  ---
I have rebuilt gcc today, now at commit
b77e3b4e4589e56c01511fabdbaadb029cd47f5c.

Configuration line:

/var/tmp/portage/sys-devel/gcc-12.0.0_pre/work/gcc-12.0.0_pre/configure
--host=sparc-unknown-linux-gnu --build=sparc-unknown-linux-gnu --prefix=/usr
--bindir=/usr/sparc-unknown-linux-gnu/gcc-bin/12.0.0
--includedir=/usr/lib/gcc/sparc-unknown-linux-gnu/12.0.0/include
--datadir=/usr/share/gcc-data/sparc-unknown-linux-gnu/12.0.0
--mandir=/usr/share/gcc-data/sparc-unknown-linux-gnu/12.0.0/man
--infodir=/usr/share/gcc-data/sparc-unknown-linux-gnu/12.0.0/info
--with-gxx-include-dir=/usr/lib/gcc/sparc-unknown-linux-gnu/12.0.0/include/g++-v12
--with-python-dir=/share/gcc-data/sparc-unknown-linux-gnu/12.0.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --disable-nls
--disable-libunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion=Gentoo 12.0.0_pre,
commit b77e3b4e4589e56c01511fabdbaadb029cd47f5c --disable-esp
--enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libssp --disable-libada --disable-cet --disable-systemtap
--disable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--without-zstd --enable-lto --with-isl --disable-isl-version-check
--enable-default-pie --enable-default-ssp

I can still trigger the warning:

cd /tmp/cmtest/Source && /usr/bin/c++ -DCURL_STATICLIB -DLIBARCHIVE_STATIC
-D_FILE_OFFSET_BITS=64 -I/tmp/cmtest/Utilities -I/tmp/cmtest/Source
-I/home/buildbot/repos/CMake/Source
-I/home/buildbot/repos/CMake/Source/LexerParser
-I/home/buildbot/repos/CMake/Source/CTest
-I/home/buildbot/repos/CMake/Source/CPack -isystem
/home/buildbot/repos/CMake/Utilities/std -isystem
/home/buildbot/repos/CMake/Utilities -Wnon-virtual-dtor -Wcast-align
-Wchar-subscripts -Wall -W -Wshadow -Wpointer-arith -Wformat-security -Wundef
-g -std=c++17 -MD -MT
Source/CMakeFiles/CMakeLib.dir/cmLocalUnixMakefileGenerator3.cxx.o -MF
CMakeFiles/CMakeLib.dir/cmLocalUnixMakefileGenerator3.cxx.o.d -o
CMakeFiles/CMakeLib.dir/cmLocalUnixMakefileGenerator3.cxx.o -c
/home/buildbot/repos/CMake/Source/cmLocalUnixMakefileGenerator3.cxx
-Wformat-truncation=2

I still have the full gcc build log if that matters.

git hooks: too strict check

[Martin Liška]

Hello.

I'm working on a testsuite clean-up where some of the files are wrongly named.
More precisely, so files have .cc extension and should use .C. However there's
existing C test-case and it leads to:

marxin@marxinbox:~/Programming/gcc/gcc/testsuite> find . -name test-asm.*
./jit.dg/test-asm.C
./jit.dg/test-asm.c

test-kunlun me/rename-testsuite-files
Enumerating objects: 804, done.
Counting objects: 100% (804/804), done.
Delta compression using up to 16 threads
Compressing objects: 100% (242/242), done.
Writing objects: 100% (564/564), 142.13 KiB | 7.48 MiB/s, done.
Total 564 (delta 424), reused 417 (delta 295), pack-reused 0
remote: Resolving deltas: 100% (424/424), completed with 222 local objects.
remote: *** The following filename collisions have been detected.
remote: *** These collisions happen when the name of two or more files
remote: *** differ in casing only (Eg: "hello.txt" and "Hello.txt").
remote: *** Please re-do your commit, chosing names that do not collide.
remote: ***
remote: *** Commit: 7297e1de9bed96821d2bcfd034bad604ce035afb
remote: *** Subject: Rename tests in jit sub-folder.
remote: ***
remote: *** The matching files are:
remote: ***
remote: *** gcc/testsuite/jit.dg/test-quadratic.C
remote: *** gcc/testsuite/jit.dg/test-quadratic.c
remote: ***
remote: *** gcc/testsuite/jit.dg/test-switch.C
remote: *** gcc/testsuite/jit.dg/test-switch.c
remote: ***
remote: *** gcc/testsuite/jit.dg/test-asm.C
remote: *** gcc/testsuite/jit.dg/test-asm.c
remote: ***
remote: *** gcc/testsuite/jit.dg/test-alignment.C
remote: *** gcc/testsuite/jit.dg/test-alignment.c

Can we please do something about it?

Thanks,
Martin

[PATCH][pushed] testsuite: rename files in c-c++-common.

[Martin Liška]

Pushed, there should be only .c files in the sub-folder.

Martin

gcc/testsuite/ChangeLog:

* c-c++-common/Walloca-larger-than.C: Moved to...
* c-c++-common/Walloca-larger-than.c: ...here.
---
 .../c-c++-common/{Walloca-larger-than.C => Walloca-larger-than.c} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename gcc/testsuite/c-c++-common/{Walloca-larger-than.C => 
Walloca-larger-than.c} (100%)

diff --git a/gcc/testsuite/c-c++-common/Walloca-larger-than.C 
b/gcc/testsuite/c-c++-common/Walloca-larger-than.c
similarity index 100%
rename from gcc/testsuite/c-c++-common/Walloca-larger-than.C
rename to gcc/testsuite/c-c++-common/Walloca-larger-than.c
--
2.34.1

[Bug c++/99018] Comparing address of array element not considered a constant expression in certain contexts

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #4 from Patrick Palka  ---
GCC trunk accepts the first testcase ever since r12-6382.

(In reply to David Stone from comment #3)
> The error message looks suspiciously similar to
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85944. Perhaps it's the same
> bug?

Hmm yeah, it looks like the other testcases here are the same bug as PR85944.

[Bug c++/103705] [12 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'array_ref' in finish_omp_clauses, at cp/semantics.c:7928 since r12-5838-g6c0399378e77d029

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Chung-Lin Tang :

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

commit r12-6584-gcd7484d05cd4b7a9d741fe8bf6c4525406ed7620
Author: Chung-Lin Tang 
Date:   Fri Jan 14 21:58:34 2022 +0800

openmp: Fix ICE in [PR103705]

Fix ICE for cases like:
  #pragma omp target update from(s[0].a[0:1])

where multiple ARRAY_REF nodes exist and require more than one peeling
during [c_]finish_omp_clauses.

PR c++/103705

gcc/c/ChangeLog:

* c-typeck.c (c_finish_omp_clauses): Also continue peeling off of
outer node for ARRAY_REFs.

gcc/cp/ChangeLog:

* semantics.c (finish_omp_clauses): Also continue peeling off of
outer node for ARRAY_REFs.

gcc/testsuite/ChangeLog:

* c-c++-common/gomp/pr103705.c: New test.

Re: [PATCH] rs6000: Use known constant for GET_MODE_NUNITS and similar

[David Edelsohn via Gcc-patches]

On Fri, Jan 14, 2022 at 5:42 AM Kewen.Lin  wrote:
>
> on 2022/1/13 下午11:15, David Edelsohn wrote:
> > On Thu, Jan 13, 2022 at 7:40 AM Kewen.Lin  wrote:
> >>
> >> Hi David,
> >>
> >> on 2022/1/13 上午11:12, David Edelsohn wrote:
> >>> On Wed, Jan 12, 2022 at 8:56 PM Kewen.Lin  wrote:
> 
>  Hi,
> 
>  This patch is to clean up some codes with GET_MODE_UNIT_SIZE or
>  GET_MODE_NUNITS, which can use known constant instead.
> >>>
> >>> I'll let Segher decide, but often the additional code is useful
> >>> self-documentation instead of magic constants.  Or at least the change
> >>> requires comments documenting the derivation of the constants
> >>> currently described by the code itself.
> >>>
> >>
> >> Thanks for the comments, I added some comments as suggested, also removed
> >> the whole "altivec_vreveti2" since I noticed it's useless, it's not used
> >> by any built-in functions and even unused in the commit db042e1603db50573.
> >>
> >> The updated version has been tested as before.
> >
> > As we have discussed offline, the comments need to be clarified and 
> > expanded.
> >
> > And the removal of altivec_vreveti2 should be confirmed with Carl
> > Love, who added the pattern less than a year ago. There may be another
> > patch planning to use it.
> >
>
> Thanks for the suggestions David!  The comments have been updated, and Carl
> also helped to confirm the altivec_vreveti2 pattern is not planned for any
> future work and looks reasonable to remove.
>
> Does this updated version look good to you?

The revised patch is okay.

Thanks, David

>
> BR,
> Kewen
> -
> gcc/ChangeLog:
>
> * config/rs6000/altivec.md (altivec_vreveti2): Remove.
> * config/rs6000/vsx.md (*vsx_extract_si, 
> *vsx_extract_si_float_df,
> *vsx_extract_si_float_, *vsx_insert_extract_v4sf_p9): Use
> known constant values to simplify code.
> ---
>  gcc/config/rs6000/altivec.md | 25 -
>  gcc/config/rs6000/vsx.md | 16 
>  2 files changed, 12 insertions(+), 29 deletions(-)
>
> diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
> index 950b17862c4..4412175a0dc 100644
> --- a/gcc/config/rs6000/altivec.md
> +++ b/gcc/config/rs6000/altivec.md
> @@ -3950,31 +3950,6 @@
>DONE;
>  })
>
> -;; Vector reverse elements
> -(define_expand "altivec_vreveti2"
> -  [(set (match_operand:TI 0 "register_operand" "=v")
> -   (unspec:TI [(match_operand:TI 1 "register_operand" "v")]
> - UNSPEC_VREVEV))]
> -  "TARGET_ALTIVEC"
> -{
> -  int i, j, size, num_elements;
> -  rtvec v = rtvec_alloc (16);
> -  rtx mask = gen_reg_rtx (V16QImode);
> -
> -  size = GET_MODE_UNIT_SIZE (TImode);
> -  num_elements = GET_MODE_NUNITS (TImode);
> -
> -  for (j = 0; j < num_elements; j++)
> -for (i = 0; i < size; i++)
> -  RTVEC_ELT (v, i + j * size)
> -   = GEN_INT (i + (num_elements - 1 - j) * size);
> -
> -  emit_insn (gen_vec_initv16qiqi (mask, gen_rtx_PARALLEL (V16QImode, v)));
> -  emit_insn (gen_altivec_vperm_ti (operands[0], operands[1],
> -operands[1], mask));
> -  DONE;
> -})
> -
>  ;; Vector reverse elements for V16QI V8HI V4SI V4SF
>  (define_expand "altivec_vreve2"
>[(set (match_operand:VEC_K 0 "register_operand" "=v")
> diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
> index acd729d1687..ee748ff4ebd 100644
> --- a/gcc/config/rs6000/vsx.md
> +++ b/gcc/config/rs6000/vsx.md
> @@ -3854,8 +3854,10 @@
>rtx vec_tmp = operands[3];
>int value;
>
> +  /* Adjust index for LE element ordering, the below minuend 3 is computed by
> + GET_MODE_NUNITS (V4SImode) - 1.  */
>if (!BYTES_BIG_ENDIAN)
> -element = GEN_INT (GET_MODE_NUNITS (V4SImode) - 1 - INTVAL (element));
> +element = GEN_INT (3 - INTVAL (element));
>
>/* If the value is in the correct position, we can avoid doing the VSPLT
>   instruction.  */
> @@ -4230,8 +4232,10 @@
>rtx v4si_tmp = operands[3];
>int value;
>
> +  /* Adjust index for LE element ordering, the below minuend 3 is computed by
> + GET_MODE_NUNITS (V4SImode) - 1.  */
>if (!BYTES_BIG_ENDIAN)
> -element = GEN_INT (GET_MODE_NUNITS (V4SImode) - 1 - INTVAL (element));
> +element = GEN_INT (3 - INTVAL (element));
>
>/* If the value is in the correct position, we can avoid doing the VSPLT
>   instruction.  */
> @@ -4273,8 +4277,10 @@
>rtx df_tmp = operands[4];
>int value;
>
> +  /* Adjust index for LE element ordering, the below minuend 3 is computed by
> + GET_MODE_NUNITS (V4SImode) - 1.  */
>if (!BYTES_BIG_ENDIAN)
> -element = GEN_INT (GET_MODE_NUNITS (V4SImode) - 1 - INTVAL (element));
> +element = GEN_INT (3 - INTVAL (element));
>
>/* If the value is in the correct position, we can avoid doing the VSPLT
>   instruction.  */
> @@ -4466,8 +4472,10 @@
>  {
>int ele = INTVAL (operands[4]);
>
> +  /* Adjust index for LE element ordering, the below minuend 3 is computed by
> + 

[Bug ada/104027] [12 Regression] libgnat-12.so requires executable stack on x86_64-linux

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

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

--- Comment #4 from Arnaud Charlet  ---
Thanks for the report and investigation. The issue is actually caused by the
introduction of a "ghost" (empty for code generation purposes) unit
a-nbnbbig.ads, since the change you mentioned didn't change the existing call
to exit(0), the issue was already there before, just never triggered in
libgnat.so.

Patch looks good to me, if you get a successful build and check-ada, it's
preapproved.

Re: [PATCH] [i386] GLC tuning: Break false dependency for dest register.

[Hongyu Wang via Gcc-patches]

> Are there any technical obstacles to introduce subst to
> define_{,insn_and_}split?

gccint says: define_subst can be used only in define_insn and
define_expand, it cannot be used in other expressions (e.g. in
define_insn_and_split).
I have no idea how to implement it in current infrastructure.

> In the proposed patch, if the output register is also mentioned in the
> input, then clearing before insn will clear the value in the input
> register. The solution in the i386.md also takes care of this issue.
>

For this, I think we can add REGNO checks for operands in condition
(which means there is true dependency).

Uros Bizjak  于2022年1月14日周五 16:37写道：
>
> On Fri, Jan 14, 2022 at 7:11 AM Hongyu Wang  wrote:
> >
> > > > No, the approach is wrong. You have to solve output clearing on RTL
> > > > level, please look at how e.g. tzcnt false dep is solved:
> > >
> > > Actually we have considered such approach before, but we found we need
> > > to break original define_insn to remove the mask/rounding subst,
> > > since define_split could not adopt subst, and that would add 6 more
> > > define_insn_and_split and 4 define_insn for each instruction. We think
> > > such approach would introduce too much redundant code.
> > >
> > > Do you think the code size increment is acceptable?
> >
> > Also that 100+ more patterns increases maintenance effort. If we split
> > them at epilogue_complete stage,
> > it seems not much difference to put it under output template...
>
> In the proposed patch, if the output register is also mentioned in the
> input, then clearing before insn will clear the value in the input
> register. The solution in the i386.md also takes care of this issue.
>
> Uros.

[Bug analyzer/104029] [12 Regression] ICE with -fanalyzer-checker=taint since r12-5230-gb9365b93212041f1

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|internal compiler error |[12 Regression] ICE with
   |with|-fanalyzer-checker=taint
   |-fanalyzer-checker=taint|since
   ||r12-5230-gb9365b93212041f1

--- Comment #2 from Martin Liška  ---
Started with r12-5230-gb9365b93212041f1.

[Bug analyzer/104029] internal compiler error with -fanalyzer-checker=taint

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2022-01-14

--- Comment #1 from Martin Liška  ---
Reduced test-case:

$ cat pr104029.c
char heapsort_size;

void
heapsort() { char abaseabase = -heapsort_size; }

$ gcc pr104029.c -fanalyzer -fanalyzer-checker=taint
during IPA pass: analyzer
pr104029.c: In function ‘heapsort’:
pr104029.c:4:19: internal compiler error: in alt_get_inherited_state, at
analyzer/sm-taint.cc:652
4 | heapsort() { char abaseabase = -heapsort_size; }
  |   ^~
0x81290a alt_get_inherited_state
/home/marxin/Programming/gcc/gcc/analyzer/sm-taint.cc:652
0x12f081b ana::sm_state_map::get_state(ana::svalue const*, ana::extrinsic_state
const&) const
/home/marxin/Programming/gcc/gcc/analyzer/program-state.cc:424
0x12f299f ana::program_state::can_purge_p(ana::extrinsic_state const&,
ana::svalue const*) const
/home/marxin/Programming/gcc/gcc/analyzer/program-state.h:254
0x12f299f ana::program_state::prune_for_point(ana::exploded_graph&,
ana::program_point const&, ana::exploded_node*, ana::uncertainty_t*) const
/home/marxin/Programming/gcc/gcc/analyzer/program-state.cc:1151
0x12e03e4 ana::exploded_graph::process_node(ana::exploded_node*)
/home/marxin/Programming/gcc/gcc/analyzer/engine.cc:3719
0x12e0ffa ana::exploded_graph::process_worklist()
/home/marxin/Programming/gcc/gcc/analyzer/engine.cc:3137
0x12e331e ana::impl_run_checkers(ana::logger*)
/home/marxin/Programming/gcc/gcc/analyzer/engine.cc:5716
0x12e4333 ana::run_checkers()
/home/marxin/Programming/gcc/gcc/analyzer/engine.cc:5787
0x12d414c execute
/home/marxin/Programming/gcc/gcc/analyzer/analyzer-pass.cc:87
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 v3 00/15] ARM/MVE use vectors of boolean for predicates

[Richard Biener via Gcc-patches]

On Fri, Jan 14, 2022 at 2:18 PM Christophe Lyon via Gcc-patches
 wrote:
>
> Hi,
>
> I hadn't realized we are moving to stage 4 this week-end :-(
>
> The PRs I'm fixing are P3, but without these fixes MVE support is badly
> broken, so I think I would be really good to fix that before the buggy
> version becomes part of an actual release.
> Anyway I posted v1 of the patches during stage1, so it should still be OK
> if they are accepted as-is ?

In the end it's up to the target maintainers to weight the risk of breakage
vs. the risk of not usefulness ;)  But stage3 is where the "was posted
during stage1"
rule can easily apply - at some point we have to stop with such general ruling.

Richard.

> Thanks,
>
> Christophe
>
> On Thu, Jan 13, 2022 at 3:58 PM Christophe Lyon via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
> >
> > This is v3 of this patch series, fixing issues I discovered before
> > committing v2 (which had been approved).
> >
> > Thanks a lot to Richard Sandiford for his help.
> >
> > The changes v2 -> v3 are:
> >
> > Patch 4: Fix arm_hard_regno_nregs and CLASS_MAX_NREGS to support VPR.
> >
> > Patch 7: Changes to the underlying representation of vectors of
> > booleans to account for the different expectations between AArch64/SVE
> > and Arm/MVE.
> >
> > Patch 8: Re-use and extend existing thumb2_movhi* patterns instead of
> > duplicating them in mve_mov. This requires the introduction of a
> > new constraint to match a constant vector of booleans. Add a new RTL
> > test.
> >
> > Patch 9: Introduce check_effective_target_arm_mve and skip
> > gcc.dg/signbit-2.c, because with MVE there is no fallback architecture
> > unlike SVE or AVX512.
> >
> > Patch 12: Update less load/store MVE builtins
> > (mve_vldrdq_gather_base_z_v2di,
> > mve_vldrdq_gather_offset_z_v2di,
> > mve_vldrdq_gather_shifted_offset_z_v2di,
> > mve_vstrdq_scatter_base_p_v2di,
> > mve_vstrdq_scatter_offset_p_v2di,
> > mve_vstrdq_scatter_offset_p_v2di_insn,
> > mve_vstrdq_scatter_shifted_offset_p_v2di,
> > mve_vstrdq_scatter_shifted_offset_p_v2di_insn,
> > mve_vstrdq_scatter_base_wb_p_v2di,
> > mve_vldrdq_gather_base_wb_z_v2di,
> > mve_vldrdq_gather_base_nowb_z_v2di,
> > mve_vldrdq_gather_base_wb_z_v2di_insn) for which we keep HI mode
> > for vpr_register_operand.
> >
> > Patch 13: No need to update
> > gcc.target/arm/acle/cde-mve-full-assembly.c anymore since we re-use
> > the mov pattern that emits '@ movhi' in the assembly.
> >
> > Patch 15: This is a new patch to fix a problem I noticed during this
> > v2->v3 update.
> >
> >
> >
> > I'll squash patch 2 with patch 9 and patch 3 with patch 8.
> >
> > Original text:
> >
> > This patch series addresses PR 100757 and 101325 by representing
> > vectors of predicates (MVE VPR.P0 register) as vectors of booleans
> > rather than using HImode.
> >
> > As this implies a lot of mostly mechanical changes, I have tried to
> > split the patches in a way that should help reviewers, but the split
> > is a bit artificial.
> >
> > Patches 1-3 add new tests.
> >
> > Patches 4-6 are small independent improvements.
> >
> > Patch 7 implements the predicate qualifier, but does not change any
> > builtin yet.
> >
> > Patch 8 is the first of the two main patches, and uses the new
> > qualifier to describe the vcmp and vpsel builtins that are useful for
> > auto-vectorization of comparisons.
> >
> > Patch 9 is the second main patch, which fixes the vcond_mask expander.
> >
> > Patches 10-13 convert almost all the remaining builtins with HI
> > operands to use the predicate qualifier.  After these, there are still
> > a few builtins with HI operands left, about which I am not sure: vctp,
> > vpnot, load-gather and store-scatter with v2di operands.  In fact,
> > patches 11/12 update some STR/LDR qualifiers in a way that breaks
> > these v2di builtins although existing tests still pass.
> >
> > Christophe Lyon (15):
> >   arm: Add new tests for comparison vectorization with Neon and MVE
> >   arm: Add tests for PR target/100757
> >   arm: Add tests for PR target/101325
> >   arm: Add GENERAL_AND_VPR_REGS regclass
> >   arm: Add support for VPR_REG in arm_class_likely_spilled_p
> >   arm: Fix mve_vmvnq_n_ argument mode
> >   arm: Implement MVE predicates as vectors of booleans
> >   arm: Implement auto-vectorized MVE comparisons with vectors of boolean
> > predicates
> >   arm: Fix vcond_mask expander for MVE (PR target/100757)
> >   arm: Convert remaining MVE vcmp builtins to predicate qualifiers
> >   arm: Convert more MVE builtins to predicate qualifiers
> >   arm: Convert more load/store MVE builtins to predicate qualifiers
> >   arm: Convert more MVE/CDE builtins to predicate qualifiers
> >   arm: Add VPR_REG to ALL_REGS
> >   arm: Fix constraint check for V8HI in mve_vector_mem_operand
> >
> >  gcc/config/aarch64/aarch64-modes.def  |   8 +-
> >  gcc/config/arm/arm-builtins.c | 224 +++--
> >  gcc/config/arm/arm-builtins.h |   4 +-
> >  

[Bug target/104028] M68k: Error: value -16034 out of range

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2022-01-14

--- Comment #4 from Martin Liška  ---
Please provide output of m68k-linux-gcc with -v option.

Re: [PATCH] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]

[Marek Polacek via Gcc-patches]

On Fri, Jan 14, 2022 at 10:23:16AM +0100, Stephan Bergmann wrote:
> On 30/11/2021 16:27, Marek Polacek wrote:
> > I guess we were concerned with programs that generate other programs.
> > Maybe UCNs should be ignored by default.  There's still time to adjust
> > the behavior.
> 
> Is there any update on this?  Shall I file a bug?  As-is, -Wbidi-chars is
> unusable for building LibreOffice and (esp. in combination with
>  "C++ preprocessor
> ignores #pragma GCC diagnostic") has to be explicitly disabled globally.

No update, it wasn't clear to me what the action should be here.

Please do file a bug.  I think I'll just have to adjust the warning to ignore
UCNs.

Marek

[Bug target/104028] M68k: Error: value -16034 out of range

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-reduction
 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Reducing that right now..

Re: [PATCH v3 00/15] ARM/MVE use vectors of boolean for predicates

[Christophe Lyon via Gcc-patches]

Hi,

I hadn't realized we are moving to stage 4 this week-end :-(

The PRs I'm fixing are P3, but without these fixes MVE support is badly
broken, so I think I would be really good to fix that before the buggy
version becomes part of an actual release.
Anyway I posted v1 of the patches during stage1, so it should still be OK
if they are accepted as-is ?

Thanks,

Christophe

On Thu, Jan 13, 2022 at 3:58 PM Christophe Lyon via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

>
> This is v3 of this patch series, fixing issues I discovered before
> committing v2 (which had been approved).
>
> Thanks a lot to Richard Sandiford for his help.
>
> The changes v2 -> v3 are:
>
> Patch 4: Fix arm_hard_regno_nregs and CLASS_MAX_NREGS to support VPR.
>
> Patch 7: Changes to the underlying representation of vectors of
> booleans to account for the different expectations between AArch64/SVE
> and Arm/MVE.
>
> Patch 8: Re-use and extend existing thumb2_movhi* patterns instead of
> duplicating them in mve_mov. This requires the introduction of a
> new constraint to match a constant vector of booleans. Add a new RTL
> test.
>
> Patch 9: Introduce check_effective_target_arm_mve and skip
> gcc.dg/signbit-2.c, because with MVE there is no fallback architecture
> unlike SVE or AVX512.
>
> Patch 12: Update less load/store MVE builtins
> (mve_vldrdq_gather_base_z_v2di,
> mve_vldrdq_gather_offset_z_v2di,
> mve_vldrdq_gather_shifted_offset_z_v2di,
> mve_vstrdq_scatter_base_p_v2di,
> mve_vstrdq_scatter_offset_p_v2di,
> mve_vstrdq_scatter_offset_p_v2di_insn,
> mve_vstrdq_scatter_shifted_offset_p_v2di,
> mve_vstrdq_scatter_shifted_offset_p_v2di_insn,
> mve_vstrdq_scatter_base_wb_p_v2di,
> mve_vldrdq_gather_base_wb_z_v2di,
> mve_vldrdq_gather_base_nowb_z_v2di,
> mve_vldrdq_gather_base_wb_z_v2di_insn) for which we keep HI mode
> for vpr_register_operand.
>
> Patch 13: No need to update
> gcc.target/arm/acle/cde-mve-full-assembly.c anymore since we re-use
> the mov pattern that emits '@ movhi' in the assembly.
>
> Patch 15: This is a new patch to fix a problem I noticed during this
> v2->v3 update.
>
>
>
> I'll squash patch 2 with patch 9 and patch 3 with patch 8.
>
> Original text:
>
> This patch series addresses PR 100757 and 101325 by representing
> vectors of predicates (MVE VPR.P0 register) as vectors of booleans
> rather than using HImode.
>
> As this implies a lot of mostly mechanical changes, I have tried to
> split the patches in a way that should help reviewers, but the split
> is a bit artificial.
>
> Patches 1-3 add new tests.
>
> Patches 4-6 are small independent improvements.
>
> Patch 7 implements the predicate qualifier, but does not change any
> builtin yet.
>
> Patch 8 is the first of the two main patches, and uses the new
> qualifier to describe the vcmp and vpsel builtins that are useful for
> auto-vectorization of comparisons.
>
> Patch 9 is the second main patch, which fixes the vcond_mask expander.
>
> Patches 10-13 convert almost all the remaining builtins with HI
> operands to use the predicate qualifier.  After these, there are still
> a few builtins with HI operands left, about which I am not sure: vctp,
> vpnot, load-gather and store-scatter with v2di operands.  In fact,
> patches 11/12 update some STR/LDR qualifiers in a way that breaks
> these v2di builtins although existing tests still pass.
>
> Christophe Lyon (15):
>   arm: Add new tests for comparison vectorization with Neon and MVE
>   arm: Add tests for PR target/100757
>   arm: Add tests for PR target/101325
>   arm: Add GENERAL_AND_VPR_REGS regclass
>   arm: Add support for VPR_REG in arm_class_likely_spilled_p
>   arm: Fix mve_vmvnq_n_ argument mode
>   arm: Implement MVE predicates as vectors of booleans
>   arm: Implement auto-vectorized MVE comparisons with vectors of boolean
> predicates
>   arm: Fix vcond_mask expander for MVE (PR target/100757)
>   arm: Convert remaining MVE vcmp builtins to predicate qualifiers
>   arm: Convert more MVE builtins to predicate qualifiers
>   arm: Convert more load/store MVE builtins to predicate qualifiers
>   arm: Convert more MVE/CDE builtins to predicate qualifiers
>   arm: Add VPR_REG to ALL_REGS
>   arm: Fix constraint check for V8HI in mve_vector_mem_operand
>
>  gcc/config/aarch64/aarch64-modes.def  |   8 +-
>  gcc/config/arm/arm-builtins.c | 224 +++--
>  gcc/config/arm/arm-builtins.h |   4 +-
>  gcc/config/arm/arm-modes.def  |   8 +
>  gcc/config/arm/arm-protos.h   |   4 +-
>  gcc/config/arm/arm-simd-builtin-types.def |   4 +
>  gcc/config/arm/arm.c  | 169 ++--
>  gcc/config/arm/arm.h  |   9 +-
>  gcc/config/arm/arm_mve_builtins.def   | 746 
>  gcc/config/arm/constraints.md |   6 +
>  gcc/config/arm/iterators.md   |   6 +
>  gcc/config/arm/mve.md | 795 ++
>  gcc/config/arm/neon.md

[Bug analyzer/104029] New: internal compiler error with -fanalyzer-checker=taint

[urs at akk dot org via Gcc-bugs]

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

Bug ID: 104029
   Summary: internal compiler error with -fanalyzer-checker=taint
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: urs at akk dot org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 52191
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52191=edit
preprocessed file

gcc-12 (GCC) 12.0.0 20220114 (experimental)
up to and incl. commit de196e5dd8ea4d0ed01a8c265afdd3676e27545b
configured with --program-suffix=-12 --enable-languages=c,lto --enable-lto
--disable-multilib
on x86_64-pc-linux-gnu

errors out when using

gcc-12 -DHAVE_CONFIG_H -I. -I../include -DLOCALEDIR=\"/usr/share/locale\"
-DDEBUG -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED -g
-std=c11 -O2 -Wextra -Wpedantic -pipe -Wall -Winline -Wshadow
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wbad-function-cast -Wnested-externs -Wcast-align -Wpointer-arith
-Waggregate-return -Wcast-qual -Wwrite-strings -Wundef -Wpacked -Wfloat-equal
-Wunused-macros -Wold-style-definition -Winit-self -Wmissing-include-dirs
-Wlogical-op -Wjump-misses-init -Wformat=2 -Wshift-overflow=2
-Wnull-dereference -Wduplicated-cond -Walloc-zero -Walloca
-Wstringop-overflow=2 -Wduplicated-branches -Wno-format-nonliteral
-Wno-stringop-truncation -Wno-format-truncation -fno-diagnostics-color
-fdiagnostics-generate-patch -fanalyzer -fanalyzer-checker=taint

with

compiling heapsort.o
during IPA pass: analyzer
./heapsort.c: In function ‘heapsort’:
./heapsort.c:169:15: internal compiler error: in alt_get_inherited_state, at
analyzer/sm-taint.cc:652
  169 | abase = (char *)vbase - size;
  | ~~^~

[Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)

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

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

--- Comment #9 from Kewen Lin  ---
(In reply to rsand...@gcc.gnu.org from comment #6)
> I think the patch in comment 2 is the correct fix (OK to commit).
> 

Thanks for the review and approval Richard!

I totally agree this test case can be fragile when facing different
vectorisation strategies, but I'm not sure if leaving the exact number
checkings still has a bit value since this case seems the only case to catch
the redundant re-try (at least on Power?), once we fix it not to check any
times, we might miss some sensitive coverage on some useless re-tries, though
the compiling time influence is very very tiny (seems not a big deal :)).

[Bug libstdc++/95065] Remove std::bind1st and std::bind2nd when building in -std=c++17

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

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

--- Comment #3 from Jonathan Wakely  ---
For GCC 12 those features will still exist (because as explained above, that is
allowed by the standard) but they will give -Wdeprecated warnings.

[Bug libstdc++/91383] C++17 should remove some library feature deprecated in C++14

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

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

--- Comment #11 from Jonathan Wakely  ---
For GCC 12 those types will still exist (because as explained above, that is
allowed by the standard) but they will give -Wdeprecated warnings.

[Bug libstdc++/91260] std::unary_function and std::binary_function still exist in C++17

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED
   Target Milestone|--- |12.0

--- Comment #4 from Jonathan Wakely  ---
For GCC 12 those types will still exist (because as explained above, that is
allowed by the standard) but they will give -Wdeprecated warnings.

[committed] vect: Check partial vector param for supports_partial_vectors [PR104015]

[Kewen.Lin via Gcc-patches]

Hi,

As described in PR104015, the function partial_vectors_supported_p
mainly checks optabs for partial vectors support query, but we
still have one parameter param_vect_partial_vector_usage to control
the capability.

Power9 introduces vector with length instructions (for
len_load/len_store) but we don't enable partial vector on it by
default. It should be considered as not supporting partial vector by
default. This fix is to make the flag supports_partial_vectors check
param_vect_partial_vector_usage accordingly.

This was approved by Richard in the PR, thanks Richard and Andre for
the comments, pushed via r12-6582.

BR,
Kewen
-
gcc/ChangeLog:

PR tree-optimization/104015
* tree-vect-loop.c (vect_analyze_loop): Check
param_vect_partial_vector_usage for supports_partial_vectors.

---
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index ba67de490bb..49d53fb3383 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -3026,7 +3026,8 @@ vect_analyze_loop (class loop *loop, vec_info_shared 
*shared)
   vector_modes[0] = autodetected_vector_mode;
   mode_i = 0;

-  bool supports_partial_vectors = partial_vectors_supported_p ();
+  bool supports_partial_vectors =
+partial_vectors_supported_p () && param_vect_partial_vector_usage != 0;
   poly_uint64 first_vinfo_vf = LOOP_VINFO_VECT_FACTOR (first_loop_vinfo);

   while (1)

[PATCH] testsuite: Remove executable mode from source files.

[Martin Liška]

Pushed to master as obvious.

Martin

gcc/testsuite/ChangeLog:

* g++.dg/vect/pr99149.cc: Remove executable mode.
* g++.dg/vect/pr99220.cc: Likewise.
* g++.target/i386/avx512vl-pr100738-1.C: Likewise.
* g++.target/i386/pr100738-1.C: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/bfdot-1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/bfdot-2.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/bfdot-3.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vdot-3-1.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vdot-3-2.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vdot-3-3.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vdot-3-4.c: Likewise.
* gcc.target/i386/pr101796-1.c: Likewise.
* gcc.target/i386/pr94790-1.c: Likewise.
* gcc.target/i386/pr94790-2.c: Likewise.
* gcc.target/powerpc/mma-double-test.c: Likewise.
* gcc.target/powerpc/mma-single-test.c: Likewise.
* gdc.test/fail_compilation/constraints_aggr.d: Likewise.
* gdc.test/fail_compilation/constraints_defs.d: Likewise.
* gdc.test/fail_compilation/constraints_func1.d: Likewise.
* gdc.test/fail_compilation/constraints_func2.d: Likewise.
* gdc.test/fail_compilation/constraints_func3.d: Likewise.
* gdc.test/fail_compilation/constraints_func4.d: Likewise.
* gdc.test/fail_compilation/constraints_tmpl.d: Likewise.
* gdc.test/fail_compilation/imports/constraints.d: Likewise.
---
 gcc/testsuite/g++.dg/vect/pr99149.cc   | 0
 gcc/testsuite/g++.dg/vect/pr99220.cc   | 0
 gcc/testsuite/g++.target/i386/avx512vl-pr100738-1.C| 0
 gcc/testsuite/g++.target/i386/pr100738-1.C | 0
 gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/bfdot-1.c  | 0
 gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/bfdot-2.c  | 0
 gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/bfdot-3.c  | 0
 gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vdot-3-1.c | 0
 gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vdot-3-2.c | 0
 gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vdot-3-3.c | 0
 gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vdot-3-4.c | 0
 gcc/testsuite/gcc.target/i386/pr101796-1.c | 0
 gcc/testsuite/gcc.target/i386/pr94790-1.c  | 0
 gcc/testsuite/gcc.target/i386/pr94790-2.c  | 0
 gcc/testsuite/gcc.target/powerpc/mma-double-test.c | 0
 gcc/testsuite/gcc.target/powerpc/mma-single-test.c | 0
 gcc/testsuite/gdc.test/fail_compilation/constraints_aggr.d | 0
 gcc/testsuite/gdc.test/fail_compilation/constraints_defs.d | 0
 gcc/testsuite/gdc.test/fail_compilation/constraints_func1.d| 0
 gcc/testsuite/gdc.test/fail_compilation/constraints_func2.d| 0
 gcc/testsuite/gdc.test/fail_compilation/constraints_func3.d| 0
 gcc/testsuite/gdc.test/fail_compilation/constraints_func4.d| 0
 gcc/testsuite/gdc.test/fail_compilation/constraints_tmpl.d | 0
 gcc/testsuite/gdc.test/fail_compilation/imports/constraints.d  | 0
 24 files changed, 0 insertions(+), 0 deletions(-)
 mode change 100755 => 100644 gcc/testsuite/g++.dg/vect/pr99149.cc
 mode change 100755 => 100644 gcc/testsuite/g++.dg/vect/pr99220.cc
 mode change 100755 => 100644 
gcc/testsuite/g++.target/i386/avx512vl-pr100738-1.C
 mode change 100755 => 100644 gcc/testsuite/g++.target/i386/pr100738-1.C
 mode change 100755 => 100644 
gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/bfdot-1.c
 mode change 100755 => 100644 
gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/bfdot-2.c
 mode change 100755 => 100644 
gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/bfdot-3.c
 mode change 100755 => 100644 
gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vdot-3-1.c
 mode change 100755 => 100644 
gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vdot-3-2.c
 mode change 100755 => 100644 
gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vdot-3-3.c
 mode change 100755 => 100644 
gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vdot-3-4.c
 mode change 100755 => 100644 gcc/testsuite/gcc.target/i386/pr101796-1.c
 mode change 100755 => 100644 gcc/testsuite/gcc.target/i386/pr94790-1.c
 mode change 100755 => 100644 gcc/testsuite/gcc.target/i386/pr94790-2.c
 mode change 100755 => 100644 gcc/testsuite/gcc.target/powerpc/mma-double-test.c
 mode change 100755 => 100644 gcc/testsuite/gcc.target/powerpc/mma-single-test.c
 mode change 100755 => 100644 
gcc/testsuite/gdc.test/fail_compilation/constraints_aggr.d
 mode change 100755 => 100644 
gcc/testsuite/gdc.test/fail_compilation/constraints_defs.d
 mode change 100755 => 100644 
gcc/testsuite/gdc.test/fail_compilation/constraints_func1.d
 mode change 100755 => 100644 
gcc/testsuite/gdc.test/fail_compilation/constraints_func2.d
 mode change 100755 => 100644 

[Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:6d51a9c6447bace21f860e70aed13c6cd90971bd

commit r12-6582-g6d51a9c6447bace21f860e70aed13c6cd90971bd
Author: Kewen Lin 
Date:   Fri Jan 14 07:02:10 2022 -0600

vect: Check partial vector param for supports_partial_vectors [PR104015]

As described in PR104015, the function partial_vectors_supported_p
mainly checks optabs for partial vectors support query, but we
still have one parameter param_vect_partial_vector_usage to control
the capability.

Power9 introduces vector with length instructions (for
len_load/len_store) but we don't enable partial vector on it by
default. It should be considered as not supporting partial vector by
default. This fix is to make the flag supports_partial_vectors check
param_vect_partial_vector_usage accordingly.

gcc/ChangeLog:

PR tree-optimization/104015
* tree-vect-loop.c (vect_analyze_loop): Check
param_vect_partial_vector_usage for supports_partial_vectors.

Re: [Patch][V4][Patch 2/2]Enable -Wuninitialized + -ftrivial-auto-var-init for address taken variables.

[Richard Biener via Gcc-patches]

On Thu, Jan 13, 2022 at 2:45 AM Qing Zhao  wrote:
>
> Hi, Richard,
>
> This is the updated version for the second patch, which is mainly the change 
> for "Enable -Wuninitialized + -ftrivial-auto-var-init for  address taken 
> variables”.
>
> In this update, I mainly made the following change:
>
> 1.  Delete “repl_var”, use the var_def_stmt, i.e, the call to .DEFERRED_INIT 
> to record the warning suppressed info.
> 2. Add and change the comments in multiple places to make the change more 
> readable.
>
> Now, for the deleted variable, we will get the necessary info to report 
> warning from the call to .DEFERRED_INIT.
>
> A. the name string of DECL from the 3rd parameter of the call;
> B. the location of the DECL from the location of the call;
> C. the call can also be used to hold the information on whether the 
> warning
>has been issued or not to suppress warning messages when needed;
>
> Please see the detailed description below for the problem and solution of 
> this patch.
>
> This patch has been bootstrapped and regressing tested on both X86 and 
> aarch64.
>
> Okay for GCC12?

I think the change to split "%qD is used uninitialized" is bad for i8n
though it seems
like none of the strings passed to warn_uninit are currently marked
for localization.
I suppose there's lazy matching with the exact same strings passed to
warning_at around like 641 but after your change those will no longer match up,
at least for the "%qs ..." case constructed.  I think a better way
(for i8n) would be
to pass down a flag whether it is "may" or "is" and have the full translatable
strings literally passed to warning_at at the expense of some code duplication.
Actually the extra flag is unnecessary, the OPT_W... we pass is already fully
specifying that.

Instead of doing

+  if (gimple_call_internal_p (var_def_stmt, IFN_DEFERRED_INIT))
+   {
+ /* Ignore the call to .DEFERRED_INIT that define the original
+var itself as the following case:
+   temp = .DEFERRED_INIT (4, 2, â~@~\alt_reloc");
+   alt_reloc = temp;
+In order to avoid generating warning for the fake usage
+at alt_reloc = temp.
...

I thought of many options, none really very appealing so I guess we have to
go with this for now.

So OK with the i8n thing sorted out - please post one hopefully last update
for the patch.

Thanks for your patience,
Richard.

> thanks.
>
> Qing.
>
> 
> Enable -Wuninitialized + -ftrivial-auto-var-init for address
>  taken variables.
>
> With -ftrivial-auto-var-init, the address taken auto variable is replaced with
> a temporary variable during gimplification, and the original auto variable 
> might
> be eliminated by compiler optimization completely. As a result, the current
> uninitialized warning analysis cannot get enough information from the IR,
> therefore the uninitialized warnings for address taken variable cannot be
> issued based on the current implemenation of -ftrival-auto-var-init.
>
> For more info please refer to:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577431.html
>
> In order to improve this situation, we can improve uninitialized analysis
> for address taken auto variables with -ftrivial-auto-var-init as following:
>
> for the following stmt:
>
> _1 = .DEFERRED_INIT (4, 2, &"alt_reloc"[0]);
> if (_1 != 0)
>
> The original variable DECL has been eliminated from the IR, all the necessary
> information that is needed for reporting the warnings for DECL can be acquired
> from the call to .DEFERRED_INIT.
>
> A. the name string of DECL from the 3rd parameter of the call;
> B. the location of the DECL from the location of the call;
> C. the call can also be used to hold the information on whether the 
> warning
>has been issued or not to suppress warning messages when needed;
>
> The current testing cases for uninitialized warnings + -ftrivial-auto-var-init
> are adjusted to reflect the fact that we can issue warnings for address taken
> variables.
>
> gcc/ChangeLog:
>
> 2022-01-12  qing zhao  
>
> * tree-ssa-uninit.c (warn_uninit): Handle .DEFERRED_INIT call with an
> anonymous SSA_NAME specially.
> (check_defs): Likewise.
> (warn_uninit_phi_uses): Adjust the message format for warn_uninit.
> (warn_uninitialized_vars): Likewise.
> (warn_uninitialized_phi): Likewise
>
> gcc/testsuite/ChangeLog:
>
> 2022-01-12  qing zhao  
>
> * gcc.dg/auto-init-uninit-16.c (testfunc): Delete xfail to reflect
> the fact that address taken variable can be warned.
> * gcc.dg/auto-init-uninit-34.c (warn_scalar_1): Likewise.
> (warn_scalar_2): Likewise.
> * gcc.dg/auto-init-uninit-37.c (T1): Likewise.
> (T2): Likewise.
> * gcc.dg/auto-init-uninit-B.c (baz): Likewise.
>
> The complete patch is attached:
>

Re: [patch] Fix reverse SSO issues in IPA-SRA

[Martin Jambor]

Hi Eric,

On Tue, Jan 11 2022, Eric Botcazou via Gcc-patches wrote:
> Hi,
>
> we recently received the report that the IPA-SRA pass introduced in GCC 10 
> does not always play nice with the reverse scalar storage order that can be 
> used in structures/records/unions.  Reading the code, the pass apparently 
> correctly detects it but fails to propagate the information to the rewriting 
> phase in some cases and, in particular, does not stream it for LTO.
>
> The attached patch is a tentative fix for these issues spotted essentially by 
> code reading.  It also contains various minor tweaks left and right.
>
> Bootstrapped/regtested on x86-64/Linux, OK for mainline, 11 and 10 branches?
>
>
> 2022-01-11  Eric Botcazou  
>
>   * ipa-param-manipulation.c (ipa_dump_adjusted_parameters): Dump
>   reverse flag as "reverse" for the sake of consistency.
>   * ipa-sra.c: Fix copyright year.
>   (ipa_sra_function_summaries::duplicate): Copy the reverse flag.
>   (dump_isra_access): Remove confusing dump line.
>   (isra_write_node_summary): Write the reverse flag.
>   (isra_read_node_info): Read it.
>   (pull_accesses_from_callee): Copy it.

great, thanks, the patch is OK.

Martin

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

[rdapp at linux dot ibm.com via Gcc-bugs]

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

--- Comment #8 from rdapp at linux dot ibm.com ---
I think you're right.  In one of the last iterations of the patch I moved

+  LOOP_VINFO_PARTIAL_LOAD_STORE_BIAS (loop_vinfo) = partial_load_bias;

after the unsupported check.  It is now only set to something meaningful if it
is not unsupported.

The following should help:

diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 8748b1a5593..3c87920090b 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -1170,6 +1170,9 @@ vect_verify_loop_lens (loop_vec_info loop_vinfo)
   machine_mode len_store_mode = get_len_load_store_mode
 (loop_vinfo->vector_mode, false).require ();

+  LOOP_VINFO_PARTIAL_LOAD_STORE_BIAS (loop_vinfo) =
+VECT_PARTIAL_BIAS_UNSUPPORTED;
+
   signed char partial_load_bias = internal_len_load_store_bias
 (IFN_LEN_LOAD, len_load_mode);

Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).

[Tobias Burnus]

On 14.01.22 12:55, Jakub Jelinek via Fortran wrote:

If we want to check intptr_t, we should guard the dg-error with
"" { target { lp64 || llp64 } }
or so.


Well, if we want to use intptr_t, we could use be explicitly as with:

  use iso_c_binding, only: c_intptr_t
  ! use omp_lib, only: omp_allocator_handle_kind
  ...  ('implicit none' etc.)
  integer, parameter :: omp_allocator_handle_kind = c_intptr_t
  ...
  integer(kind=omp_allocator_handle_kind)

(@Abid: The 'use omp_lib' line is commented as in gcc/testsuite/*/gomp/,
the OpenMP module/header from libgomp is not available - and then a
stub parameter is created.)


Otherwise yes, we can add some other kind and hope it is not the
same as omp_allocator_handle_kind.  Or we can do both,
keep the current one with the target lp64 || llp64 and
add another one with some integer(kind=1).


For just testing something invalid, I think it makes more sense to just
set it to kind=1.

For checking the valid value, using c_intptr_t seems to make more sense
than restricting it to (l)l64.

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] libstdc++: Fix 22_locale/numpunct/members/char/3.cc execution test

[Jonathan Wakely via Gcc-patches]

On Fri, 14 Jan 2022 at 11:41, Uros Bizjak via Libstdc++ <
libstd...@gcc.gnu.org> wrote:

> The test fails on Fedora 33+ because nl_NL locale got thousands
> separator defined.  Use one of ar_SA, bg_BG, bs_BA, pt_PT
> or plain C locale instead.
>
> 2022-01-14  Uroš Bizjak  
>
> libstdc++-v3/ChangeLog:
>
>* testsuite/22_locale/numpunct/members/char/3.cc (test02):
>Use pt_PT locale instead of nl_NL.
>
> Tested on x86_64-linux-gnu (Fedora 33).
>
> OK for master?
>
>
Please also change the dg-require-namedlocale directive on the first line.

OK with that change, thanks.

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

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

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

--- Comment #7 from Tobias Burnus  ---
(In reply to rdapp from comment #4)
> This code path should only be active when the backend has len_load/len_store
> patterns.
> signed char partial_load_store_bias;
> is new in the "middle" of loop_vect_info. Could this become
> overwritten/corrupted by something?

My impression is:
- VECT_PARTIAL_BIAS_UNSUPPORTED is not always set when it should
- If it is not set, it is has some random value (stack variable, malloc not
calloc,
  ...); Still 0 is common - and it might work by chance as there is
  'if (partial_load_bias != 0)' around the ICEing code.
  (Side note: VECT_PARTIAL_BIAS_UNSUPPORTED = 127 while 0 is a valid/supported
value).
- It probably only affects loops where vect_verify_full_masking
  + LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P are true
  (and vect_verify_loop_lens is false)

Caveat: I might be completely off here.

Re: [PATCH] disable aggressive_loop_optimizations until niter ready

[Richard Biener via Gcc-patches]

On Fri, 14 Jan 2022, Jiufu Guo wrote:

> Richard Biener  writes:
> 
> > On Thu, 13 Jan 2022, guojiufu wrote:
> >
> >> On 2022-01-03 22:30, Richard Biener wrote:
> >> > On Wed, 22 Dec 2021, Jiufu Guo wrote:
> >> > 
> >> >> Hi,
> >> >> ...
> >> >> 
> >> >> Bootstrap and regtest pass on ppc64* and x86_64.  Is this ok for trunk?
> >> > 
> >> > So this is a optimality fix, not a correctness one?  I suppose the
> >> > estimates are computed/used from scev_probably_wraps_p via
> >> > loop_exits_before_overflow and ultimatively chrec_convert.
> >> > 
> >> > We have a call cycle here,
> >> > 
> >> > estimate_numbers_of_iterations -> number_of_latch_executions ->
> >> > ... -> estimate_numbers_of_iterations
> >> > 
> >> > where the first estimate_numbers_of_iterations will make sure
> >> > the later call will immediately return.
> >> 
> >> Hi Richard,
> >> Thanks for your comments! And sorry for the late reply.
> >> 
> >> In estimate_numbers_of_iterations, there is a guard to make sure
> >> the second call to estimate_numbers_of_iterations returns
> >> immediately.
> >> 
> >> Exactly as you said, it relates to scev_probably_wraps_p calls
> >> loop_exits_before_overflow.
> >> 
> >> The issue is: the first calling to estimate_numbers_of_iterations
> >> maybe inside number_of_latch_executions.
> >> 
> >> > 
> >> > I'm not sure what your patch tries to do - it seems to tackle
> >> > the case where we enter the cycle via number_of_latch_executions?
> >> > Why do we get "non-final" values?  idx_infer_loop_bounds resorts
> >> 
> >> Right, when the call cycle starts from number_of_latch_execution,
> >> the issue may occur:
> >> 
> >> number_of_latch_executions(*1st call)->..->
> >> analyze_scalar_evolution(IVs 1st) ->..follow_ssa_edge_expr..->
> >> loop_exits_before_overflow->
> >> estimate_numbers_of_iterations (*1st call)->
> >> number_of_latch_executions(*2nd call)->..->
> >> analyze_scalar_evolution(IVs 2nd)->..loop_exits_before_overflow->
> >> estimate_numbers_of_iterations(*2nd call)
> >> 
> >> The second calling to estimate_numbers_of_iterations returns quickly.
> >> And then, in the first calling to estimate_numbers_of_iterations,
> >> infer_loop_bounds_from_undefined is invoked.
> >> 
> >> And, function "infer_loop_bounds_from_undefined" instantiate/analyze
> >> SCEV for each SSA in the loop.
> >> *Here the issue occur*, these SCEVs are based on the interim IV's
> >> SCEV which come from "analyze_scalar_evolution(IVs 2nd)",
> >> and those IV's SCEV will be overridden by up level
> >> "analyze_scalar_evolution(IVs 1st)".
> >
> > OK, so indeed analyze_scalar_evolution is not protected against
> > recursive invocation on the same SSA name (though it definitely
> > doesn't expect to do that).  We could fix that by pre-seeding
> > the cache conservatively in analyze_scalar_evolution or by
> > not overwriting the cached result of the recursive invocation.
> >
> > But to re-iterate an unanswered question, is this a correctness issue
> > or an optimization issue?
> 
> Hi Richard,
> 
> Thanks for your time and patience on review this!
> 
> I would say it is an optimization issue for the current code,
> it does not fix known error.
> 
> The patch could help compiling-time.  Another benefit, this patch
> would be able to improve some scev(s) if the scev is cached in
> infer_loop_bounds_from_undefined under the call stack where IV's
> SCEV is under analyzing.
> 
> Yes, in analyze_scalar_evolution call chain, it may recursive on
> same SSA name.
> While outer level analyze_scalar_evolution 'may' get better
> chrec(POLYNOMIAL_CHREC), inner one may get other scev (e.g.
> conversion).  I'm even wondering this recursive is intended :).
> It may help to handle the chick-egg issue(wrap vs. niter).
> 
> >
> >> To handle this issue, disabling flag_aggressive_loop_optimizations
> >> inside number_of_latch_executions is one method.
> >> To avoid the issue in other cases, e.g. the call cycle starts from
> >> number_of_iterations_exit or number_of_iterations_exit_assumptions,
> >> this patch disable flag_aggressive_loop_optimizations inside
> >> number_of_iterations_exit_assumptions.
> >
> > But disabling flag_aggressive_loop_optimizations is a very
> > non-intuitive way of avoiding recursive calls.  I'd rather
> > avoid those in a similar way estimate_numbers_of_iterations does,
> > for example with
> >
> > diff --git a/gcc/tree-scalar-evolution.c b/gcc/tree-scalar-evolution.c
> > index 61d72c278a1..cc1e510b6c2 100644
> > --- a/gcc/tree-scalar-evolution.c
> > +++ b/gcc/tree-scalar-evolution.c
> > @@ -2807,7 +2807,7 @@ number_of_latch_executions (class loop *loop)
> >if (dump_file && (dump_flags & TDF_SCEV))
> >  fprintf (dump_file, "(number_of_iterations_in_loop = \n");
> >  
> > -  res = chrec_dont_know;
> > +  loop->nb_iterations = res = chrec_dont_know;
> >exit = single_exit (loop);
> >  
> >if (exit && number_of_iterations_exit (loop, exit, _desc, false))
> >
> > though this doesn't seem to improve the SCEV analysis 

Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).

[Jakub Jelinek via Gcc-patches]

On Fri, Jan 14, 2022 at 12:45:54PM +0100, Tobias Burnus wrote:
> On 14.01.22 10:10, Thomas Schwinge wrote:
> > > +  integer  :: x
> > > ...
> > > +  !$omp parallel allocate (0: x) private(x) ! { dg-error "Expected 
> > > integer expression of the 'omp_allocator_handle_kind' kind at .1." }
> > We do for x86_64 default '-m64', but for '-m32' and '-mx32' compilation,
> > we're not seeing this latter diagnostic:
> >  FAIL: gfortran.dg/gomp/allocate-2.f90   -O   (test for errors, line 36)
> > 
> > I suppose the reason is unintended congruence of data types?  Would it
> > work to make 'x' a floating-point data type, for example -- or is this
> > meant to explicitly check certain integer data type characteristics?
> 
> Alternatively, you could use 'integer(kind=1)' (which is a 1-byte/8-bits
> type.) I assume we do not have any platform which still uses 8-bit
> pointers and supports libgomp :-)

If we want to check intptr_t, we should guard the dg-error with
"" { target { lp64 || llp64 } }
or so.
Otherwise yes, we can add some other kind and hope it is not the
same as omp_allocator_handle_kind.  Or we can do both,
keep the current one with the target lp64 || llp64 and
add another one with some integer(kind=1).

Jakub

Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).

[Tobias Burnus]

Hi all,

On 14.01.22 10:10, Thomas Schwinge wrote:

+  integer  :: x
...
+  !$omp parallel allocate (0: x) private(x) ! { dg-error "Expected integer 
expression of the 'omp_allocator_handle_kind' kind at .1." }

We do for x86_64 default '-m64', but for '-m32' and '-mx32' compilation,
we're not seeing this latter diagnostic:
 FAIL: gfortran.dg/gomp/allocate-2.f90   -O   (test for errors, line 36)

I suppose the reason is unintended congruence of data types?  Would it
work to make 'x' a floating-point data type, for example -- or is this
meant to explicitly check certain integer data type characteristics?


Alternatively, you could use 'integer(kind=1)' (which is a 1-byte/8-bits
type.) I assume we do not have any platform which still uses 8-bit
pointers and supports libgomp :-)

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

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

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

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

Andrew Stubbs  changed:

   What|Removed |Added

 CC||ams at gcc dot gnu.org

--- Comment #6 from Andrew Stubbs  ---
amdgcn always uses 64-lane vectors, regardless of type, and relies on masking
to support anything smaller.

The len_store pattern seems to have been introduced in July 2020 which is more
recent than the last major work in the amdgcn backend.

[PATCH] libstdc++: Fix 22_locale/numpunct/members/char/3.cc execution test

[Uros Bizjak via Gcc-patches]

The test fails on Fedora 33+ because nl_NL locale got thousands
separator defined.  Use one of ar_SA, bg_BG, bs_BA, pt_PT
or plain C locale instead.

2022-01-14  Uroš Bizjak  

libstdc++-v3/ChangeLog:

   * testsuite/22_locale/numpunct/members/char/3.cc (test02):
   Use pt_PT locale instead of nl_NL.

Tested on x86_64-linux-gnu (Fedora 33).

OK for master?

Uros.
diff --git a/libstdc++-v3/testsuite/22_locale/numpunct/members/char/3.cc 
b/libstdc++-v3/testsuite/22_locale/numpunct/members/char/3.cc
index 6e4959860cd..4cf4b24407d 100644
--- a/libstdc++-v3/testsuite/22_locale/numpunct/members/char/3.cc
+++ b/libstdc++-v3/testsuite/22_locale/numpunct/members/char/3.cc
@@ -28,8 +28,8 @@ void test02()
 {
   using namespace std;
 
-  // nl_NL chosen because it has no thousands separator (at this time).
-  locale loc_it = locale(ISO_8859(15,nl_NL));
+  // pt_PT chosen because it has no thousands separator (at this time).
+  locale loc_it = locale(ISO_8859(15,pt_PT));
 
   const numpunct& nump_it = use_facet >(loc_it); 
 

Re: [PATCH] libstdc++: Add attribute to features deprecated in C++17 [PR91260]

[Jonathan Wakely via Gcc-patches]

On Wed, 12 Jan 2022 at 09:34, Jonathan Wakely via Libstdc++ <
libstd...@gcc.gnu.org> wrote:

> This passes testing (with -std=gnu++98/11/17/20) but is quite a large
> patch for this late in stage 3. Does anybody object to doing this now?
> The bugs it fixes were closed as INVALID because we're not actually
> *required* to remove these or deprecate them. But users are right to
> complain about us silently accepting use of things like std::bind1st in
> C++20 mode. Probably WONTFIX would have been better, and in fact we can
> fix them (as this patch does). If we don't do this, users will keep
> reporting bugs about it, but it could wait for stage 1 if needed.
>

Pushed to trunk.


> === >8 === >8 === >8 ===
>
> There are a lot of things in the C++ standard library which were
> deprecated in C++11, and more in C++17.  Some of them were removed after
> deprecation and are no longer present in the standard at all. We have
> not removed these from libstdc++ because keeping them as non-standard
> extensions is conforming, and avoids gratuitously breaking user code,
> and in some cases we need to keep using them to avoid ABI changes. But
> we should at least give a warning for using them. That has not been done
> previously because of the library's own uses of them (e.g. the
> std::iterator class template used as a base class).
>
> This adds deprecated attributes to the relevant components, and then
> goes through the whole library to add diagnostic pragmas where needed to
> suppress warnings about our internal uses of them. The tests are updated
> to either expect the additional warnings, or to suppress them where we
> aren't interested in them.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/91260
> PR libstdc++/91383
> PR libstdc++/95065
> * include/backward/binders.h (bind1st, bind2nd): Add deprecated
> attribute.
> * include/bits/refwrap.h (_Maybe_unary_or_binary_function):
> Disable deprecated warnings for base classes.
> (_Reference_wrapper_base): Likewise.
> * include/bits/shared_ptr_base.h (_Sp_owner_less): Likewise.
> * include/bits/stl_bvector.h (_Bit_iterator_base): Likewise.
> * include/bits/stl_function.h (unary_function, binary_function):
> Add deprecated attribute.
> (unary_negate, not1, binary_negate, not2, ptr_fun)
> (pointer_to_unary_function, pointer_to_binary_function)
> (mem_fun_t, const_mem_fun_t, mem_fun_ref_t, const_mem_fun_ref_t)
> (mem_fun1_t, const_mem_fun1_t, mem_fun_ref1_t)
> (const_mem_fun1_ref_t, mem_fun, mem_fun_ref): Add deprecated
> attributes.
> * include/bits/stl_iterator.h: Disable deprecated warnings for
> std::iterator base classes.
> * include/bits/stl_iterator_base_types.h (iterator): Add
> deprecated attribute.
> * include/bits/stl_map.h (map::value_compare): Disable
> deprecated warnings for base class.
> * include/bits/stl_multimap.h (multimap::value_compare):
> Likewise.
> * include/bits/stl_raw_storage_iter.h (raw_storage_iterator):
> Add deprecated attribute.
> * include/bits/stl_tempbuf.h (get_temporary_buffer): Likewise.
> * include/bits/stream_iterator.h: Disable deprecated warnings.
> * include/bits/streambuf_iterator.h: Likewise.
> * include/ext/bitmap_allocator.h: Remove unary_function base
> classes.
> * include/ext/functional: Disable deprecated warnings.
> * include/ext/rope: Likewise.
> * include/ext/throw_allocator.h: Likewise.
> * include/std/type_traits (result_of): Add deprecated attribute.
> * include/tr1/functional: Disable deprecated warnings.
> * include/tr1/functional_hash.h: Likewise.
> * testsuite/20_util/function_objects/binders/1.cc: Add
> -Wno-disable-deprecations.
> * testsuite/20_util/function_objects/binders/3113.cc: Likewise.
> * testsuite/20_util/function_objects/constexpr.cc: Add
> dg-warning.
> * testsuite/20_util/raw_storage_iterator/base.cc: Likewise.
> * testsuite/20_util/raw_storage_iterator/dr2127.cc: Likewise.
> *
> testsuite/20_util/raw_storage_iterator/requirements/base_classes.cc:
> Likewise.
> *
> testsuite/20_util/raw_storage_iterator/requirements/explicit_instantiation/1.cc:
> Likewise.
> * testsuite/20_util/raw_storage_iterator/requirements/typedefs.cc:
> Likewise.
> * testsuite/20_util/reference_wrapper/24803.cc:
> Likewise.
> * testsuite/20_util/reference_wrapper/typedefs.cc: Enable for
> C++20 and check for absence of nested types.
> * testsuite/20_util/shared_ptr/comparison/less.cc: Remove
> std::binary_function base class.
> * testsuite/20_util/temporary_buffer.cc: Add dg-warning.
> * testsuite/21_strings/basic_string/cons/char/69092.cc: Remove
>  

[Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)

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

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

--- Comment #7 from avieira at gcc dot gnu.org ---
Yeah I'm with Richard on this one, I just checked and the generated assembly is
the same for before and after my patch, so this looks like a testism.


And yeah I agree, if we were to decide to unroll this for instance then you'd
likely see it being printed more too, since you would likely end up with the
epilogue using the same mode.

I'll suggest changing it to just testing the existance of that string, rather
than requring it N times.

Having said that, the fail will go away for this particular case with the param
change.

[Bug libstdc++/95065] Remove std::bind1st and std::bind2nd when building in -std=c++17

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

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

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

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

commit r12-6581-gde196e5dd8ea4d0ed01a8c265afdd3676e27545b
Author: Jonathan Wakely 
Date:   Tue Jan 11 18:42:38 2022 +

libstdc++: Add attribute to features deprecated in C++17 [PR91260]

There are a lot of things in the C++ standard library which were
deprecated in C++11, and more in C++17.  Some of them were removed after
deprecation and are no longer present in the standard at all. We have
not removed these from libstdc++ because keeping them as non-standard
extensions is conforming, and avoids gratuitously breaking user code,
and in some cases we need to keep using them to avoid ABI changes. But
we should at least give a warning for using them. That has not been done
previously because of the library's own uses of them (e.g. the
std::iterator class template used as a base class).

This adds deprecated attributes to the relevant components, and then
goes through the whole library to add diagnostic pragmas where needed to
suppress warnings about our internal uses of them. The tests are updated
to either expect the additional warnings, or to suppress them where we
aren't interested in them.

libstdc++-v3/ChangeLog:

PR libstdc++/91260
PR libstdc++/91383
PR libstdc++/95065
* include/backward/binders.h (bind1st, bind2nd): Add deprecated
attribute.
* include/bits/refwrap.h (_Maybe_unary_or_binary_function):
Disable deprecated warnings for base classes.
(_Reference_wrapper_base): Likewise.
* include/bits/shared_ptr_base.h (_Sp_owner_less): Likewise.
* include/bits/stl_bvector.h (_Bit_iterator_base): Likewise.
* include/bits/stl_function.h (unary_function, binary_function):
Add deprecated attribute.
(unary_negate, not1, binary_negate, not2, ptr_fun)
(pointer_to_unary_function, pointer_to_binary_function)
(mem_fun_t, const_mem_fun_t, mem_fun_ref_t, const_mem_fun_ref_t)
(mem_fun1_t, const_mem_fun1_t, mem_fun_ref1_t)
(const_mem_fun1_ref_t, mem_fun, mem_fun_ref): Add deprecated
attributes.
* include/bits/stl_iterator.h: Disable deprecated warnings for
std::iterator base classes.
* include/bits/stl_iterator_base_types.h (iterator): Add
deprecated attribute.
* include/bits/stl_map.h (map::value_compare): Disable
deprecated warnings for base class.
* include/bits/stl_multimap.h (multimap::value_compare):
Likewise.
* include/bits/stl_raw_storage_iter.h (raw_storage_iterator):
Add deprecated attribute.
* include/bits/stl_tempbuf.h (get_temporary_buffer): Likewise.
* include/bits/stream_iterator.h: Disable deprecated warnings.
* include/bits/streambuf_iterator.h: Likewise.
* include/ext/bitmap_allocator.h: Remove unary_function base
classes.
* include/ext/functional: Disable deprecated warnings.
* include/ext/rope: Likewise.
* include/ext/throw_allocator.h: Likewise.
* include/std/type_traits (result_of): Add deprecated attribute.
* include/tr1/functional: Disable deprecated warnings.
* include/tr1/functional_hash.h: Likewise.
* testsuite/20_util/function_objects/binders/1.cc: Add
-Wno-disable-deprecations.
* testsuite/20_util/function_objects/binders/3113.cc: Likewise.
* testsuite/20_util/function_objects/constexpr.cc: Add
dg-warning.
* testsuite/20_util/raw_storage_iterator/base.cc: Likewise.
* testsuite/20_util/raw_storage_iterator/dr2127.cc: Likewise.
*
testsuite/20_util/raw_storage_iterator/requirements/base_classes.cc:
Likewise.
*
testsuite/20_util/raw_storage_iterator/requirements/explicit_instantiation/1.cc:
Likewise.
* testsuite/20_util/raw_storage_iterator/requirements/typedefs.cc:
Likewise.
* testsuite/20_util/reference_wrapper/24803.cc:
Likewise.
* testsuite/20_util/reference_wrapper/typedefs.cc: Enable for
C++20 and check for absence of nested types.
* testsuite/20_util/shared_ptr/comparison/less.cc: Remove
std::binary_function base class.
* testsuite/20_util/temporary_buffer.cc: Add dg-warning.
* testsuite/21_strings/basic_string/cons/char/69092.cc: Remove
std::iterator base class.
*
testsuite/24_iterators/back_insert_iterator/requirements/base_classes.cc:
Likewise.
*

[Bug libstdc++/91260] std::unary_function and std::binary_function still exist in C++17

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

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

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

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

commit r12-6581-gde196e5dd8ea4d0ed01a8c265afdd3676e27545b
Author: Jonathan Wakely 
Date:   Tue Jan 11 18:42:38 2022 +

libstdc++: Add attribute to features deprecated in C++17 [PR91260]

There are a lot of things in the C++ standard library which were
deprecated in C++11, and more in C++17.  Some of them were removed after
deprecation and are no longer present in the standard at all. We have
not removed these from libstdc++ because keeping them as non-standard
extensions is conforming, and avoids gratuitously breaking user code,
and in some cases we need to keep using them to avoid ABI changes. But
we should at least give a warning for using them. That has not been done
previously because of the library's own uses of them (e.g. the
std::iterator class template used as a base class).

This adds deprecated attributes to the relevant components, and then
goes through the whole library to add diagnostic pragmas where needed to
suppress warnings about our internal uses of them. The tests are updated
to either expect the additional warnings, or to suppress them where we
aren't interested in them.

libstdc++-v3/ChangeLog:

PR libstdc++/91260
PR libstdc++/91383
PR libstdc++/95065
* include/backward/binders.h (bind1st, bind2nd): Add deprecated
attribute.
* include/bits/refwrap.h (_Maybe_unary_or_binary_function):
Disable deprecated warnings for base classes.
(_Reference_wrapper_base): Likewise.
* include/bits/shared_ptr_base.h (_Sp_owner_less): Likewise.
* include/bits/stl_bvector.h (_Bit_iterator_base): Likewise.
* include/bits/stl_function.h (unary_function, binary_function):
Add deprecated attribute.
(unary_negate, not1, binary_negate, not2, ptr_fun)
(pointer_to_unary_function, pointer_to_binary_function)
(mem_fun_t, const_mem_fun_t, mem_fun_ref_t, const_mem_fun_ref_t)
(mem_fun1_t, const_mem_fun1_t, mem_fun_ref1_t)
(const_mem_fun1_ref_t, mem_fun, mem_fun_ref): Add deprecated
attributes.
* include/bits/stl_iterator.h: Disable deprecated warnings for
std::iterator base classes.
* include/bits/stl_iterator_base_types.h (iterator): Add
deprecated attribute.
* include/bits/stl_map.h (map::value_compare): Disable
deprecated warnings for base class.
* include/bits/stl_multimap.h (multimap::value_compare):
Likewise.
* include/bits/stl_raw_storage_iter.h (raw_storage_iterator):
Add deprecated attribute.
* include/bits/stl_tempbuf.h (get_temporary_buffer): Likewise.
* include/bits/stream_iterator.h: Disable deprecated warnings.
* include/bits/streambuf_iterator.h: Likewise.
* include/ext/bitmap_allocator.h: Remove unary_function base
classes.
* include/ext/functional: Disable deprecated warnings.
* include/ext/rope: Likewise.
* include/ext/throw_allocator.h: Likewise.
* include/std/type_traits (result_of): Add deprecated attribute.
* include/tr1/functional: Disable deprecated warnings.
* include/tr1/functional_hash.h: Likewise.
* testsuite/20_util/function_objects/binders/1.cc: Add
-Wno-disable-deprecations.
* testsuite/20_util/function_objects/binders/3113.cc: Likewise.
* testsuite/20_util/function_objects/constexpr.cc: Add
dg-warning.
* testsuite/20_util/raw_storage_iterator/base.cc: Likewise.
* testsuite/20_util/raw_storage_iterator/dr2127.cc: Likewise.
*
testsuite/20_util/raw_storage_iterator/requirements/base_classes.cc:
Likewise.
*
testsuite/20_util/raw_storage_iterator/requirements/explicit_instantiation/1.cc:
Likewise.
* testsuite/20_util/raw_storage_iterator/requirements/typedefs.cc:
Likewise.
* testsuite/20_util/reference_wrapper/24803.cc:
Likewise.
* testsuite/20_util/reference_wrapper/typedefs.cc: Enable for
C++20 and check for absence of nested types.
* testsuite/20_util/shared_ptr/comparison/less.cc: Remove
std::binary_function base class.
* testsuite/20_util/temporary_buffer.cc: Add dg-warning.
* testsuite/21_strings/basic_string/cons/char/69092.cc: Remove
std::iterator base class.
*
testsuite/24_iterators/back_insert_iterator/requirements/base_classes.cc:
Likewise.
*

[Bug libstdc++/91383] C++17 should remove some library feature deprecated in C++14

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

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

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

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

commit r12-6581-gde196e5dd8ea4d0ed01a8c265afdd3676e27545b
Author: Jonathan Wakely 
Date:   Tue Jan 11 18:42:38 2022 +

libstdc++: Add attribute to features deprecated in C++17 [PR91260]

There are a lot of things in the C++ standard library which were
deprecated in C++11, and more in C++17.  Some of them were removed after
deprecation and are no longer present in the standard at all. We have
not removed these from libstdc++ because keeping them as non-standard
extensions is conforming, and avoids gratuitously breaking user code,
and in some cases we need to keep using them to avoid ABI changes. But
we should at least give a warning for using them. That has not been done
previously because of the library's own uses of them (e.g. the
std::iterator class template used as a base class).

This adds deprecated attributes to the relevant components, and then
goes through the whole library to add diagnostic pragmas where needed to
suppress warnings about our internal uses of them. The tests are updated
to either expect the additional warnings, or to suppress them where we
aren't interested in them.

libstdc++-v3/ChangeLog:

PR libstdc++/91260
PR libstdc++/91383
PR libstdc++/95065
* include/backward/binders.h (bind1st, bind2nd): Add deprecated
attribute.
* include/bits/refwrap.h (_Maybe_unary_or_binary_function):
Disable deprecated warnings for base classes.
(_Reference_wrapper_base): Likewise.
* include/bits/shared_ptr_base.h (_Sp_owner_less): Likewise.
* include/bits/stl_bvector.h (_Bit_iterator_base): Likewise.
* include/bits/stl_function.h (unary_function, binary_function):
Add deprecated attribute.
(unary_negate, not1, binary_negate, not2, ptr_fun)
(pointer_to_unary_function, pointer_to_binary_function)
(mem_fun_t, const_mem_fun_t, mem_fun_ref_t, const_mem_fun_ref_t)
(mem_fun1_t, const_mem_fun1_t, mem_fun_ref1_t)
(const_mem_fun1_ref_t, mem_fun, mem_fun_ref): Add deprecated
attributes.
* include/bits/stl_iterator.h: Disable deprecated warnings for
std::iterator base classes.
* include/bits/stl_iterator_base_types.h (iterator): Add
deprecated attribute.
* include/bits/stl_map.h (map::value_compare): Disable
deprecated warnings for base class.
* include/bits/stl_multimap.h (multimap::value_compare):
Likewise.
* include/bits/stl_raw_storage_iter.h (raw_storage_iterator):
Add deprecated attribute.
* include/bits/stl_tempbuf.h (get_temporary_buffer): Likewise.
* include/bits/stream_iterator.h: Disable deprecated warnings.
* include/bits/streambuf_iterator.h: Likewise.
* include/ext/bitmap_allocator.h: Remove unary_function base
classes.
* include/ext/functional: Disable deprecated warnings.
* include/ext/rope: Likewise.
* include/ext/throw_allocator.h: Likewise.
* include/std/type_traits (result_of): Add deprecated attribute.
* include/tr1/functional: Disable deprecated warnings.
* include/tr1/functional_hash.h: Likewise.
* testsuite/20_util/function_objects/binders/1.cc: Add
-Wno-disable-deprecations.
* testsuite/20_util/function_objects/binders/3113.cc: Likewise.
* testsuite/20_util/function_objects/constexpr.cc: Add
dg-warning.
* testsuite/20_util/raw_storage_iterator/base.cc: Likewise.
* testsuite/20_util/raw_storage_iterator/dr2127.cc: Likewise.
*
testsuite/20_util/raw_storage_iterator/requirements/base_classes.cc:
Likewise.
*
testsuite/20_util/raw_storage_iterator/requirements/explicit_instantiation/1.cc:
Likewise.
* testsuite/20_util/raw_storage_iterator/requirements/typedefs.cc:
Likewise.
* testsuite/20_util/reference_wrapper/24803.cc:
Likewise.
* testsuite/20_util/reference_wrapper/typedefs.cc: Enable for
C++20 and check for absence of nested types.
* testsuite/20_util/shared_ptr/comparison/less.cc: Remove
std::binary_function base class.
* testsuite/20_util/temporary_buffer.cc: Add dg-warning.
* testsuite/21_strings/basic_string/cons/char/69092.cc: Remove
std::iterator base class.
*
testsuite/24_iterators/back_insert_iterator/requirements/base_classes.cc:
Likewise.
*

[committed] libgfortran: Partly revert my r12-6498 change to fix Solaris build [PR104006]

[Jakub Jelinek via Gcc-patches]

Hi!

In r12-6498 I've added $(version_dep) to BUILT_SOURCES, previously version_dep
on Linux used to be a file in $(srcdir), but with my changes it is a generated
file in the object directory (preprocessed version of the $(srcdir) file)
and I thought generated files belong to BUILT_SOURCES so that they are
cleaned up etc.
For Linux that is fine, but it broke parallel builds on Solaris.
BUILT_SOURCES is a special variable for automake where automake ensures
that for make all, make check and make install all those $(BUILT_SOURCES)
are generated before actually starting building in parallel the various
object files.  That way we can avoid hacks like:
$(patsubst %.F90,%.lo,$(notdir $(filter %.F90,$(prereq_SRC: kinds.inc 
c99_protos.inc
$(patsubst %.c,%.lo,$(notdir $(filter %.c,$(prereq_SRC: kinds.h
$(patsubst %.f90,%.lo,selected_real_kind.f90): selected_real_kind.inc
$(patsubst %.f90,%.lo,selected_int_kind.f90): selected_int_kind.inc
$(patsubst %.F90,%.lo,ieee_exceptions.F90): fpu-target.inc
$(patsubst %.F90,%.lo,ieee_arithmetic.F90): fpu-target.inc ieee_exceptions.lo
$(patsubst %.c,%.lo,fpu.c): fpu-target.h
which makes those dependencies explicit but hides it from automake, so that it
doesn't throw away its rules for those object files.
On Solaris, $(version_dep) contains gfortran.ver and gfortran.ver-sun.
gfortran.ver is like on Linux, it can be in $(BUILT_SOURCES), but unfortunately
gfortran.ver-sun depends on all the object files being compiled already,
so if gfortran.ver-sun appears in $(BUILT_SOURCES), the BUILT_SOURCES function
of ensuring the generated files are generated before building object files
is gone, almost everything is built before all-am is entered and there
are no explicit dependencies that e.g. *.F90 files depend on
kinds.inc etc.

So, this change reverts that mistake and instead adds $(version_dep) to
what is removed during make clean (clean-local in particular).

The reversion committed under the reversion of our own patches policy,
the clean-local change considered obvious, committed to trunk.

2022-01-14  Jakub Jelinek  

PR libfortran/104006
* Makefile.am (BUILT_SOURCES): Don't include $(version_dep).
(clean-local): Remove $(version_dep).
* Makefile.in: Regenerated.

--- libgfortran/Makefile.am.jj  2022-01-13 17:44:40.503962317 +0100
+++ libgfortran/Makefile.am 2022-01-13 23:37:52.876004924 +0100
@@ -1118,7 +1118,7 @@ ieee_arithmetic.mod: ieee_arithmetic.lo
:
 
 BUILT_SOURCES=$(gfor_built_src) $(gfor_built_specific_src) \
-   $(gfor_built_specific2_src) $(gfor_misc_specifics) $(version_dep)
+   $(gfor_built_specific2_src) $(gfor_misc_specifics)
 
 prereq_SRC = $(gfor_src) $(gfor_built_src) $(gfor_io_src) \
$(gfor_helper_src) $(gfor_ieee_src) $(gfor_io_headers) 
$(gfor_specific_src)
@@ -1356,7 +1356,7 @@ $(gfor_misc_specifics): m4/misc_specific
 endif
 
 clean-local:
-   -rm -rf include
+   -rm -rf include $(version_dep)
 
 EXTRA_DIST = $(m4_files)
 
--- libgfortran/Makefile.in.jj  2022-01-13 17:44:51.468807363 +0100
+++ libgfortran/Makefile.in 2022-01-13 23:37:58.729923341 +0100
@@ -1652,7 +1652,7 @@ intrinsics/random_init.f90
 
 BUILT_SOURCES = $(gfor_built_src) $(gfor_built_specific_src) \
$(gfor_built_specific2_src) $(gfor_misc_specifics) \
-   $(version_dep) $(am__append_7)
+   $(am__append_7)
 prereq_SRC = $(gfor_src) $(gfor_built_src) $(gfor_io_src) \
$(gfor_helper_src) $(gfor_ieee_src) $(gfor_io_headers) 
$(gfor_specific_src)
 
@@ -7857,7 +7857,7 @@ include/ISO_Fortran_binding.h: $(srcdir)
 @MAINTAINER_MODE_TRUE@ $(M4) -Dfile=$@ -I$(srcdir)/m4 misc_specifics.m4 > $@
 
 clean-local:
-   -rm -rf include
+   -rm -rf include $(version_dep)
 
 # target overrides
 -include $(tmake_file)

Jakub

[Bug libfortran/104006] [12 regression] power-ieee128 merge breaks Solaris build

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

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

--- Comment #27 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r12-6580-gac6a1181209b756882f89cdba6128565fad1a56e
Author: Jakub Jelinek 
Date:   Fri Jan 14 12:11:00 2022 +0100

libgfortran: Partly revert my r12-6498 change to fix Solaris build
[PR104006]

In r12-6498 I've added $(version_dep) to BUILT_SOURCES, previously
version_dep
on Linux used to be a file in $(srcdir), but with my changes it is a
generated
file in the object directory (preprocessed version of the $(srcdir) file)
and I thought generated files belong to BUILT_SOURCES so that they are
cleaned up etc.
For Linux that is fine, but it broke parallel builds on Solaris.
BUILT_SOURCES is a special variable for automake where automake ensures
that for make all, make check and make install all those $(BUILT_SOURCES)
are generated before actually starting building in parallel the various
object files.  That way we can avoid hacks like:
$(patsubst %.F90,%.lo,$(notdir $(filter %.F90,$(prereq_SRC: kinds.inc
c99_protos.inc
$(patsubst %.c,%.lo,$(notdir $(filter %.c,$(prereq_SRC: kinds.h
$(patsubst %.f90,%.lo,selected_real_kind.f90): selected_real_kind.inc
$(patsubst %.f90,%.lo,selected_int_kind.f90): selected_int_kind.inc
$(patsubst %.F90,%.lo,ieee_exceptions.F90): fpu-target.inc
$(patsubst %.F90,%.lo,ieee_arithmetic.F90): fpu-target.inc
ieee_exceptions.lo
$(patsubst %.c,%.lo,fpu.c): fpu-target.h
which makes those dependencies explicit but hides it from automake, so that
it
doesn't throw away its rules for those object files.
On Solaris, $(version_dep) contains gfortran.ver and gfortran.ver-sun.
gfortran.ver is like on Linux, it can be in $(BUILT_SOURCES), but
unfortunately
gfortran.ver-sun depends on all the object files being compiled already,
so if gfortran.ver-sun appears in $(BUILT_SOURCES), the BUILT_SOURCES
function
of ensuring the generated files are generated before building object files
is gone, almost everything is built before all-am is entered and there
are no explicit dependencies that e.g. *.F90 files depend on
kinds.inc etc.

So, this change reverts that mistake and instead adds $(version_dep) to
what is removed during make clean (clean-local in particular).

2022-01-14  Jakub Jelinek  

PR libfortran/104006
* Makefile.am (BUILT_SOURCES): Don't include $(version_dep).
(clean-local): Remove $(version_dep).
* Makefile.in: Regenerated.

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

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

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

--- Comment #5 from Tobias Burnus  ---
(In reply to Richard Biener from comment #2)
> OTOH, does amdgcn really require the load bias stuff?

According to Andrew, it doesn't - it uses maskstore.

[Bug c++/103991] [12 Regression] Bogus -Wreturn-type with constexpr if and local var with destructor

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r12-6579-gcbf06187d5f246634272e3d2892501563bff3d99
Author: Jakub Jelinek 
Date:   Fri Jan 14 12:09:19 2022 +0100

c++: Avoid some -Wreturn-type false positives with const{expr,eval} if
[PR103991]

The changes done to genericize_if_stmt in order to improve
-Wunreachable-code* warning (which Richi didn't actually commit
for GCC 12) are I think fine for normal ifs, but for constexpr if
and consteval if we have two competing warnings.
The problem is that we replace the non-taken clause (then or else)
with void_node and keep the if (cond) { something } else {}
or if (cond) {} else { something }; in the IL.
This helps -Wunreachable-code*, if something can't fallthru but the
non-taken clause can, we don't warn about code after it because it
is still (in theory) reachable.
But if the non-taken branch can't fallthru, we can get false positive
-Wreturn-type warnings (which are enabled by default) if there is
nothing after the if and the taken branch can't fallthru either.

One possibility to fix this is revert at least temporarily
to the previous behavior for constexpr and consteval if, yes, we
can get false positive -Wunreachable-code* warnings but the warning
isn't present in GCC 12.
The patch below implements that for constexpr if which throws its
clauses very early (either during parsing or during instantiation),
and for consteval if it decides based on block_may_fallthru on the
non-taken (for constant evaluation only) clause - if the non-taken
branch may fallthru, it does what you did in genericize_if_stmt
for consteval if, if it can't fallthru, it uses the older way
of pretending there wasn't an if and just replacing it with the
taken clause.  There are some false positive risks with this though,
block_may_fallthru is optimistic and doesn't handle some statements
at all (like FOR_STMT, WHILE_STMT, DO_STMT - of course handling those
is quite hard).
For constexpr if (but perhaps for GCC 13?) we could try to
block_may_fallthru before we throw it away and remember it in some
flag on the IF_STMT, but am not sure how dangerous would it be to call
it on the discarded stmts.  Or if it is too dangerous e.g. just
remember whether the discarded block of consteval if wasn't present
or was empty, in that case assume fallthru, and otherwise assume
it can't fallthru (-Wunreachable-code possible false positives).

2022-01-14  Jakub Jelinek  

PR c++/103991
* cp-objcp-common.c (cxx_block_may_fallthru) : For
IF_STMT_CONSTEXPR_P with constant false or true condition only
check if the taken clause may fall through.
* cp-gimplify.c (genericize_if_stmt): For consteval if, revert
to r12-5638^ behavior if then_ block can't fall through.  For
constexpr if, revert to r12-5638^ behavior.

* g++.dg/warn/Wreturn-type-13.C: New test.

[Bug c++/89074] valid pointer equality constexpr comparison rejected

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

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r12-6578-gd686d5d85c23451c03799dc55e456b73065f7333
Author: Jakub Jelinek 
Date:   Fri Jan 14 12:07:49 2022 +0100

c++: Reject in constant evaluation address comparisons of start of one var
and end of another [PR89074]

The following testcase used to be incorrectly accepted.  The match.pd
optimization that uses address_compare punts on folding comparison
of start of one object and end of another one only when those addresses
are cast to integral types, when the comparison is done on pointer types
it assumes undefined behavior and decides to fold the comparison such
that the addresses don't compare equal even when they at runtime they
could be equal.
But C++ says it is undefined behavior and so during constant evaluation
we should reject those, so this patch adds !folding_initializer &&
check to that spot.

Note, address_compare has some special cases, e.g. it assumes that
static vars are never adjacent to automatic vars, which is the case
for the usual layout where automatic vars are on the stack and after
.rodata/.data sections there is heap:
  /* Assume that automatic variables can't be adjacent to global
 variables.  */
  else if (is_global_var (base0) != is_global_var (base1))
;
Is it ok that during constant evaluation we don't treat those as undefined
behavior, or shall that be with !folding_initializer && too?

Another special case is:
  if ((DECL_P (base0) && TREE_CODE (base1) == STRING_CST)
   || (TREE_CODE (base0) == STRING_CST && DECL_P (base1))
   || (TREE_CODE (base0) == STRING_CST
   && TREE_CODE (base1) == STRING_CST
   && ioff0 >= 0 && ioff1 >= 0
   && ioff0 < TREE_STRING_LENGTH (base0)
   && ioff1 < TREE_STRING_LENGTH (base1)
  /* This is a too conservative test that the STRING_CSTs
 will not end up being string-merged.  */
   && strncmp (TREE_STRING_POINTER (base0) + ioff0,
   TREE_STRING_POINTER (base1) + ioff1,
   MIN (TREE_STRING_LENGTH (base0) - ioff0,
TREE_STRING_LENGTH (base1) - ioff1)) != 0))
;
  else if (!DECL_P (base0) || !DECL_P (base1))
return 2;
Here we similarly assume that vars aren't adjacent to string literals
or vice versa.  Do we need to stick !folding_initializer && to those
DECL_P vs. STRING_CST cases?  Though, because of the return 2; for
non-DECL_P that would mean rejecting comparisons like  == &"foobar"[3]
etc. which ought to be fine, no?  So perhaps we need to watch for
decls. vs. STRING_CSTs like for DECLs whether the address is at the start
or at the end of the string literal or somewhere in between (at least
for folding_initializer)?
And yet another chapter but probably unsolvable is comparison of
string literal addresses.  I think pedantically in C++
&"foo"[0] == &"foo"[0] is undefined behavior, different occurences of
the same string literals might still not be merged in some implementations.
But constexpr const char *s = "foo"; [0] == [0] should be well defined,
and we aren't tracking anywhere whether the string literal was the same one
or different (and I think other compilers don't track that either).

2022-01-14  Jakub Jelinek  

PR c++/89074
* fold-const.c (address_compare): Punt on comparison of address of
one object with address of end of another object if
folding_initializer.

* g++.dg/cpp1y/constexpr-89074-1.C: New test.

[Bug target/98737] Atomic operation on x86 no optimized to use flags

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:9896e96d4cae00d0f4d2b694284cb30bbd9c80fc

commit r12-6577-g9896e96d4cae00d0f4d2b694284cb30bbd9c80fc
Author: Jakub Jelinek 
Date:   Fri Jan 14 12:04:59 2022 +0100

forwprop: Canonicalize atomic fetch_op op x to op_fetch or vice versa
[PR98737]

When writing the PR98737 fix, I've handled just the case where people
use __atomic_op_fetch (p, x, y) etc.
But some people actually use the other builtins, like
__atomic_fetch_op (p, x, y) op x.
The following patch canonicalizes the latter to the former and vice versa
when possible if the result of the builtin is a single use and if
that use is a cast with same precision, also that cast's lhs has a single
use.
For all ops of +, -, &, | and ^ we can do those
__atomic_fetch_op (p, x, y) op x -> __atomic_op_fetch (p, x, y)
(and __sync too) opts, but cases of INTEGER_CST and SSA_NAME x
behave differently.  For INTEGER_CST, typically - x is
canonicalized to + (-x), while for SSA_NAME we need to handle various
casts, which sometimes happen on the second argument of the builtin
(there can be even two subsequent casts for char/short due to the
promotions we do) and there can be a cast on the argument of op too.
And all ops but - are commutative.
For the other direction, i.e.
__atomic_op_fetch (p, x, y) rop x -> __atomic_fetch_op (p, x, y)
we can't handle op of & and |, those aren't reversible, for
op + rop is -, for - rop is + and for ^ rop is ^, otherwise the same
stuff as above applies.
And, there is another case, we canonicalize
x - y == 0 (or != 0) and x ^ y == 0 (or != 0) to x == y (or x != y)
and for constant y x + y == 0 (or != 0) to x == -y (or != -y),
so the patch also virtually undoes those canonicalizations, because
e.g. for the earlier PR98737 patch but even generally, it is better
if a result of atomic op fetch is compared against 0 than doing
atomic fetch op and compare it to some variable or non-zero constant.
As for debug info, for non-reversible operations (& and |) the patch
resets debug stmts if there are any, for -fnon-call-exceptions too
(didn't want to include debug temps right before all uses), but
otherwise it emits (on richi's request) the reverse operation from
the result as a new setter of the old lhs, so that later DCE fixes
up the debug info.

On the emitted assembly for the testcases which are fairly large,
I see substantial decreases of the *.s size:
-rw-rw-r--. 1 jakub jakub 116897 Jan 13 09:58 pr98737-1.svanilla
-rw-rw-r--. 1 jakub jakub  93861 Jan 13 09:57 pr98737-1.spatched
-rw-rw-r--. 1 jakub jakub  70257 Jan 13 09:57 pr98737-2.svanilla
-rw-rw-r--. 1 jakub jakub  67537 Jan 13 09:57 pr98737-2.spatched
There are some functions where due to RA we get one more instruction
than previously, but most of them are smaller even when not hitting
the PR98737 previous patch's optimizations.

2022-01-14  Jakub Jelinek  

PR target/98737
* tree-ssa-forwprop.c (simplify_builtin_call): Canonicalize
__atomic_fetch_op (p, x, y) op x into __atomic_op_fetch (p, x, y)
and __atomic_op_fetch (p, x, y) iop x into
__atomic_fetch_op (p, x, y).

* gcc.dg/tree-ssa/pr98737-1.c: New test.
* gcc.dg/tree-ssa/pr98737-2.c: New test.

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

[rdapp at linux dot ibm.com via Gcc-bugs]

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

rdapp at linux dot ibm.com changed:

   What|Removed |Added

 CC||rdapp at linux dot ibm.com

--- Comment #4 from rdapp at linux dot ibm.com ---
This code path should only be active when the backend has len_load/len_store
patterns.

signed char partial_load_store_bias;

is new in the "middle" of loop_vect_info. Could this become
overwritten/corrupted by something?

[Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)

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

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
I think the patch in comment 2 is the correct fix (OK to commit).

(In reply to Kewen Lin from comment #4)
> (In reply to avieira from comment #3)
> > Hi Kewen,
> > 
> > Thanks for the analysis. The param_vect_partial_vector_usage suggestion
> > seems valid, but that shouldn't be the root cause.
> > 
> >  I would expect an unpredicated V8HI epilogue to fail for a V8HI main loop
> > (unless the main loop was unrolled).
> > 
> > That is what the following code in vect_analyze_loop_2 is responsible for:
> >   /* If we're vectorizing an epilogue loop, the vectorized loop either needs
> >  to be able to handle fewer than VF scalars, or needs to have a lower VF
> >  than the main loop.  */
> >   if (LOOP_VINFO_EPILOGUE_P (loop_vinfo)
> >   && !LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo)
> >   && maybe_ge (LOOP_VINFO_VECT_FACTOR (loop_vinfo),
> >LOOP_VINFO_VECT_FACTOR (orig_loop_vinfo)))
> > return opt_result::failure_at (vect_location,
> >"Vectorization factor too high for"
> >" epilogue loop.\n");
> > 
> 
> For this failure rs6000 specific, this check does take effect, but it's too
> late for this case. Since we already decide to re-try vector modes for
> epilogue in vect_analyze_loop, the retrying generates one extra unexpected
> statement in dumping file. Without the culprit commit, it doesn't have any
> re-tries.
Yeah, I think this just shows that it's a flaky test.  Does it really
matter that:

  permutation requires at least three vectors

is printed exactly once, rather than at least once?  It's inevitable
that we'll start printing more stuff when trying (and possibly failing)
to use other vectorisation strategies.

Re: [PATCH] rs6000: Use known constant for GET_MODE_NUNITS and similar

[Kewen.Lin via Gcc-patches]

on 2022/1/13 下午11:15, David Edelsohn wrote:
> On Thu, Jan 13, 2022 at 7:40 AM Kewen.Lin  wrote:
>>
>> Hi David,
>>
>> on 2022/1/13 上午11:12, David Edelsohn wrote:
>>> On Wed, Jan 12, 2022 at 8:56 PM Kewen.Lin  wrote:

 Hi,

 This patch is to clean up some codes with GET_MODE_UNIT_SIZE or
 GET_MODE_NUNITS, which can use known constant instead.
>>>
>>> I'll let Segher decide, but often the additional code is useful
>>> self-documentation instead of magic constants.  Or at least the change
>>> requires comments documenting the derivation of the constants
>>> currently described by the code itself.
>>>
>>
>> Thanks for the comments, I added some comments as suggested, also removed
>> the whole "altivec_vreveti2" since I noticed it's useless, it's not used
>> by any built-in functions and even unused in the commit db042e1603db50573.
>>
>> The updated version has been tested as before.
> 
> As we have discussed offline, the comments need to be clarified and expanded.
> 
> And the removal of altivec_vreveti2 should be confirmed with Carl
> Love, who added the pattern less than a year ago. There may be another
> patch planning to use it.
> 

Thanks for the suggestions David!  The comments have been updated, and Carl
also helped to confirm the altivec_vreveti2 pattern is not planned for any
future work and looks reasonable to remove.

Does this updated version look good to you?

BR,
Kewen
-
gcc/ChangeLog:

* config/rs6000/altivec.md (altivec_vreveti2): Remove.
* config/rs6000/vsx.md (*vsx_extract_si, *vsx_extract_si_float_df,
*vsx_extract_si_float_, *vsx_insert_extract_v4sf_p9): Use
known constant values to simplify code.
---
 gcc/config/rs6000/altivec.md | 25 -
 gcc/config/rs6000/vsx.md | 16 
 2 files changed, 12 insertions(+), 29 deletions(-)

diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 950b17862c4..4412175a0dc 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@ -3950,31 +3950,6 @@
   DONE;
 })

-;; Vector reverse elements
-(define_expand "altivec_vreveti2"
-  [(set (match_operand:TI 0 "register_operand" "=v")
-   (unspec:TI [(match_operand:TI 1 "register_operand" "v")]
- UNSPEC_VREVEV))]
-  "TARGET_ALTIVEC"
-{
-  int i, j, size, num_elements;
-  rtvec v = rtvec_alloc (16);
-  rtx mask = gen_reg_rtx (V16QImode);
-
-  size = GET_MODE_UNIT_SIZE (TImode);
-  num_elements = GET_MODE_NUNITS (TImode);
-
-  for (j = 0; j < num_elements; j++)
-for (i = 0; i < size; i++)
-  RTVEC_ELT (v, i + j * size)
-   = GEN_INT (i + (num_elements - 1 - j) * size);
-
-  emit_insn (gen_vec_initv16qiqi (mask, gen_rtx_PARALLEL (V16QImode, v)));
-  emit_insn (gen_altivec_vperm_ti (operands[0], operands[1],
-operands[1], mask));
-  DONE;
-})
-
 ;; Vector reverse elements for V16QI V8HI V4SI V4SF
 (define_expand "altivec_vreve2"
   [(set (match_operand:VEC_K 0 "register_operand" "=v")
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index acd729d1687..ee748ff4ebd 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -3854,8 +3854,10 @@
   rtx vec_tmp = operands[3];
   int value;

+  /* Adjust index for LE element ordering, the below minuend 3 is computed by
+ GET_MODE_NUNITS (V4SImode) - 1.  */
   if (!BYTES_BIG_ENDIAN)
-element = GEN_INT (GET_MODE_NUNITS (V4SImode) - 1 - INTVAL (element));
+element = GEN_INT (3 - INTVAL (element));

   /* If the value is in the correct position, we can avoid doing the VSPLT
  instruction.  */
@@ -4230,8 +4232,10 @@
   rtx v4si_tmp = operands[3];
   int value;

+  /* Adjust index for LE element ordering, the below minuend 3 is computed by
+ GET_MODE_NUNITS (V4SImode) - 1.  */
   if (!BYTES_BIG_ENDIAN)
-element = GEN_INT (GET_MODE_NUNITS (V4SImode) - 1 - INTVAL (element));
+element = GEN_INT (3 - INTVAL (element));

   /* If the value is in the correct position, we can avoid doing the VSPLT
  instruction.  */
@@ -4273,8 +4277,10 @@
   rtx df_tmp = operands[4];
   int value;

+  /* Adjust index for LE element ordering, the below minuend 3 is computed by
+ GET_MODE_NUNITS (V4SImode) - 1.  */
   if (!BYTES_BIG_ENDIAN)
-element = GEN_INT (GET_MODE_NUNITS (V4SImode) - 1 - INTVAL (element));
+element = GEN_INT (3 - INTVAL (element));

   /* If the value is in the correct position, we can avoid doing the VSPLT
  instruction.  */
@@ -4466,8 +4472,10 @@
 {
   int ele = INTVAL (operands[4]);

+  /* Adjust index for LE element ordering, the below minuend 3 is computed by
+ GET_MODE_NUNITS (V4SFmode) - 1.  */
   if (!BYTES_BIG_ENDIAN)
-ele = GET_MODE_NUNITS (V4SFmode) - 1 - ele;
+ele = 3 - ele;

   operands[4] = GEN_INT (GET_MODE_SIZE (SFmode) * ele);
   return "xxinsertw %x0,%x2,%4";

Re: [AArch64] Enable generation of FRINTNZ instructions

[Richard Sandiford via Gcc-patches]

"Andre Vieira (lists)"  writes:
> diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
> index 
> 19e89ae502bc2f51db64667b236c1cb669718b02..3b0e4e0875b4392ab6833568b207580ef597a98f
>  100644
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -6191,6 +6191,15 @@ operands; otherwise, it may not.
>  
>  This pattern is not allowed to @code{FAIL}.
>  
> +@cindex @code{ftrunc@var{m}@var{n}2} instruction pattern
> +@item @samp{ftrunc@var{m}@var{n}2}
> +Truncate operand 1 to a @var{n} mode signed integer, towards zero, and store
> +the result in operand 0. Both operands have mode @var{m}, which is a scalar 
> or
> +vector floating-point mode.  An exception must be raised if operand 1 does 
> not
> +fit in a @var{n} mode signed integer as it would have if the truncation
> +happened through separate floating point to integer conversion.
> +
> +

Nit: just one blank line here.

>  @cindex @code{round@var{m}2} instruction pattern
>  @item @samp{round@var{m}2}
>  Round operand 1 to the nearest integer, rounding away from zero in the
> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
> index 
> 6095a35cd4565fdb7d758104e80fe6411230f758..a56bbb775572fa72379854f90a01ad543557e29a
>  100644
> --- a/gcc/doc/sourcebuild.texi
> +++ b/gcc/doc/sourcebuild.texi
> @@ -2286,6 +2286,10 @@ Like @code{aarch64_sve_hw}, but also test for an exact 
> hardware vector length.
>  @item aarch64_fjcvtzs_hw
>  AArch64 target that is able to generate and execute armv8.3-a FJCVTZS
>  instruction.
> +
> +@item aarch64_frintzx_ok
> +AArch64 target that is able to generate the Armv8.5-a FRINT32Z, FRINT64Z,
> +FRINT32X and FRINT64X instructions.
>  @end table
>  
>  @subsubsection MIPS-specific attributes
> diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
> index 
> b24102a5990bea4cbb102069f7a6df497fc81ebf..9047b486f41948059a7a7f1ccc4032410a369139
>  100644
> --- a/gcc/internal-fn.c
> +++ b/gcc/internal-fn.c
> @@ -130,6 +130,7 @@ init_internal_fns ()
>  #define fold_left_direct { 1, 1, false }
>  #define mask_fold_left_direct { 1, 1, false }
>  #define check_ptrs_direct { 0, 0, false }
> +#define ftrunc_int_direct { 0, 1, true }
>  
>  const direct_internal_fn_info direct_internal_fn_array[IFN_LAST + 1] = {
>  #define DEF_INTERNAL_FN(CODE, FLAGS, FNSPEC) not_direct,
> @@ -156,6 +157,29 @@ get_multi_vector_move (tree array_type, convert_optab 
> optab)
>return convert_optab_handler (optab, imode, vmode);
>  }
>  
> +/* Expand FTRUNC_INT call STMT using optab OPTAB.  */
> +
> +static void
> +expand_ftrunc_int_optab_fn (internal_fn, gcall *stmt, convert_optab optab)
> +{
> +  class expand_operand ops[2];
> +  tree lhs, float_type, int_type;
> +  rtx target, op;
> +
> +  lhs = gimple_call_lhs (stmt);
> +  target = expand_normal (lhs);
> +  op = expand_normal (gimple_call_arg (stmt, 0));
> +
> +  float_type = TREE_TYPE (lhs);
> +  int_type = element_type (gimple_call_arg (stmt, 1));

Sorry for the run-around, but now that we don't (need to) vectorise
the second argument, I think we can drop this element_type.  That in
turn means that…

> +
> +  create_output_operand ([0], target, TYPE_MODE (float_type));
> +  create_input_operand ([1], op, TYPE_MODE (float_type));
> +
> +  expand_insn (convert_optab_handler (optab, TYPE_MODE (float_type),
> +   TYPE_MODE (int_type)), 2, ops);
> +}
> +
>  /* Expand LOAD_LANES call STMT using optab OPTAB.  */
>  
>  static void
> @@ -3747,6 +3771,15 @@ multi_vector_optab_supported_p (convert_optab optab, 
> tree_pair types,
> != CODE_FOR_nothing);
>  }
>  
> +static bool
> +direct_ftrunc_int_optab_supported_p (convert_optab optab, tree_pair types,
> +  optimization_type opt_type)
> +{
> +  return (convert_optab_handler (optab, TYPE_MODE (types.first),
> + TYPE_MODE (element_type (types.second)),
> + opt_type) != CODE_FOR_nothing);
> +}
> +

…this can use convert_optab_supported_p.

> diff --git a/gcc/testsuite/gcc.target/aarch64/frintnz.c 
> b/gcc/testsuite/gcc.target/aarch64/frintnz.c
> new file mode 100644
> index 
> ..008e1cf9f4a1b0148128c65c9ea0d1bb111467b7
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/frintnz.c
> @@ -0,0 +1,91 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -march=armv8.5-a" } */
> +/* { dg-require-effective-target aarch64_frintnzx_ok } */

Is this just a cut-&-pasto from a run test?  If not, why do we need both
this and the dg-options?  It feels like one on its own should be enough,
with the dg-options being better.

The test looks OK without this line.

> +/* { dg-final { check-function-bodies "**" "" } } */
> +
> +/*
> +** f1:
> +**   frint32zs0, s0
> +**   ret
> +*/
> +float
> +f1 (float x)
> +{
> +  int y = x;
> +  return (float) y;
> +}
> +
> +/*
> +** f2:
> +**   frint64zs0, s0
> +**   ret
> +*/
> +float
> +f2 (float x)
> +{
> +  long long int y = x;
> +  return (float) y;
> +}

Re: [patch] Fix reverse SSO issues in IPA-SRA

[Eric Botcazou via Gcc-patches]

> Yes, it must still be copied.

OK, revised patch attached, with testcases but they fail only on the 10 and 11 
branches because of a change in the heuristics apparently.


* ipa-param-manipulation.c (ipa_dump_adjusted_parameters): Dump
reverse flag as "reverse" for the sake of consistency.
* ipa-sra.c: Fix copyright year.
(ipa_sra_function_summaries::duplicate): Copy the reverse flag.
(dump_isra_access): Tweak dump line.
(isra_write_node_summary): Write the reverse flag.
(isra_read_node_info): Read it.
(pull_accesses_from_callee): Test its consistency and copy it.

testsuite/
* gnat.dg/lto25.adb: New test.
* gnat.dg/opt96.adb: Likewise.
* gnat.dg/opt96_pkg.ads, gnat.dg/opt96_pkg.adb: New helper.

-- 
Eric Botcazoudiff --git a/gcc/ipa-param-manipulation.c b/gcc/ipa-param-manipulation.c
index 4973bfb67dd..fa6815e0941 100644
--- a/gcc/ipa-param-manipulation.c
+++ b/gcc/ipa-param-manipulation.c
@@ -228,7 +228,7 @@ ipa_dump_adjusted_parameters (FILE *f,
 	  fprintf (f, " prefix: %s",
 		   ipa_param_prefixes[apm->param_prefix_index]);
 	  if (apm->reverse)
-	fprintf (f, ", reverse-sso");
+	fprintf (f, ", reverse");
 	  break;
 	}
   fprintf (f, "\n");
diff --git a/gcc/ipa-sra.c b/gcc/ipa-sra.c
index 45030a17c07..f300a328f2b 100644
--- a/gcc/ipa-sra.c
+++ b/gcc/ipa-sra.c
@@ -1,6 +1,5 @@
 /* Interprocedural scalar replacement of aggregates
-   Copyright (C) 2008-2022 Free Software Foundation, Inc.
-
+   Copyright (C) 2019-2022 Free Software Foundation, Inc.
Contributed by Martin Jambor 
 
 This file is part of GCC.
@@ -21,7 +20,7 @@ along with GCC; see the file COPYING3.  If not see
 
 /* IPA-SRA is an interprocedural pass that removes unused function return
values (turning functions returning a value which is never used into void
-   functions), removes unused function parameters.  It can also replace an
+   functions) and removes unused function parameters.  It can also replace an
aggregate parameter by a set of other parameters representing part of the
original, turning those passed by reference into new ones which pass the
value directly.
@@ -57,7 +56,6 @@ along with GCC; see the file COPYING3.  If not see
ipa-param-manipulation.h for more details.  */
 
 
-
 #include "config.h"
 #include "system.h"
 #include "coretypes.h"
@@ -93,7 +91,7 @@ static void ipa_sra_summarize_function (cgraph_node *);
 #define ISRA_ARG_SIZE_LIMIT_BITS 16
 #define ISRA_ARG_SIZE_LIMIT (1 << ISRA_ARG_SIZE_LIMIT_BITS)
 /* How many parameters can feed into a call actual argument and still be
-   tracked. */
+   tracked.  */
 #define IPA_SRA_MAX_PARAM_FLOW_LEN 7
 
 /* Structure describing accesses to a specific portion of an aggregate
@@ -122,7 +120,7 @@ struct GTY(()) param_access
  transformed function - initially not set for portions of formal parameters
  that are only used as actual function arguments passed to callees.  */
   unsigned certain : 1;
-  /* Set if the access has a reversed scalar storage order.  */
+  /* Set if the access has reverse scalar storage order.  */
   unsigned reverse : 1;
 };
 
@@ -156,7 +154,7 @@ struct gensum_param_access
  arguments to a function call that can be tracked.  */
   bool nonarg;
 
-  /* Set if the access has a reversed scalar storage order.  */
+  /* Set if the access has reverse scalar storage order.  */
   bool reverse;
 };
 
@@ -219,8 +217,8 @@ struct gensum_param_desc
 };
 
 /* Properly deallocate accesses of DESC.  TODO: Since this data structure is
-   not in GC memory, this is not necessary and we can consider removing the
-   function.  */
+   allocated in GC memory, this is not necessary and we can consider removing
+   the function.  */
 
 static void
 free_param_decl_accesses (isra_param_desc *desc)
@@ -275,9 +273,9 @@ public:
   unsigned m_queued : 1;
 };
 
-/* Clean up and deallocate isra_func_summary points to.  TODO: Since this data
-   structure is not in GC memory, this is not necessary and we can consider
-   removing the destructor.  */
+/* Deallocate the memory pointed to by isra_func_summary.  TODO: Since this
+   data structure is allocated in GC memory, this is not necessary and we can
+   consider removing the destructor.  */
 
 isra_func_summary::~isra_func_summary ()
 {
@@ -287,7 +285,6 @@ isra_func_summary::~isra_func_summary ()
   vec_free (m_parameters);
 }
 
-
 /* Mark the function as not a candidate for any IPA-SRA transformation.  Return
true if it was a candidate until now.  */
 
@@ -297,6 +294,7 @@ isra_func_summary::zap ()
   bool ret = m_candidate;
   m_candidate = false;
 
+  /* TODO: see the destructor above.  */
   unsigned len = vec_safe_length (m_parameters);
   for (unsigned i = 0; i < len; ++i)
 free_param_decl_accesses (&(*m_parameters)[i]);
@@ -306,7 +304,7 @@ isra_func_summary::zap ()
 }
 
 /* Structure to describe which formal parameters feed into a particular actual
-   arguments.  */
+   argument.  

[Bug ada/104027] [12 Regression] libgnat-12.so requires executable stack on x86_64-linux

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||kenner at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Indeed.  If the FE emitted something registered with the middle-end symtab,
best would be to remove those again, if not, just arranging for return into the
caller seems much better than exiting.  It isn't just .note.GNU-stack on Linux,
but
e.g. plugin hooks won't be called etc.

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

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

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

--- Comment #3 from Tobias Burnus  ---
Input file is:
https://sourceware.org/git/?p=newlib-cygwin.git;a=history;f=newlib/libc/stdlib/ecvtbuf.c;hb=HEAD

Compiled with   amdgcn-amdhsa-gcc -g -O2 -ffunction-sections

I tried to reduce it – which kind of worked. Except: The resulting file did no
longer consistently ICE but only every 10th (or so) time.
Thus, I have not attached it. In any case, that indicates some memory
corruption issue.

[Bug ada/104027] [12 Regression] libgnat-12.so requires executable stack on x86_64-linux

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-01-14

[Bug ada/104027] [12 Regression] libgnat-12.so requires executable stack on x86_64-linux

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

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 52190
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52190=edit
Patch which might fix the issue

I suspect it was caused by r12-5670-g8ba38e8c8b73 were we call:
Back_End.Gen_Or_Update_Object_File

It should have used a goto here instead of an exit.
The attached patch might be correct but I don't know Ada well enough.

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rdapp at gcc dot gnu.org
   Target Milestone|--- |12.0

--- Comment #2 from Richard Biener  ---
possibly wants to use build_vector_from_val if an uniform constant is desired.

OTOH, does amdgcn really require the load bias stuff?

Can you attach preprocessed source for ecvtbuf.c and instructions to invoke cc1
on it?

[Bug libstdc++/103992] common_iterator(const common_iterator<_It2, _Sent2>& __x) uses new instead of construct_at

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Jonathan Wakely  ---
Fixed, thanks for the report

[committed] arc: Add DWARF2 alternate CFA column.

[Claudiu Zissulescu via Gcc-patches]

Add DWARF 2 CFA column which tracks the return address from a signal
handler context.  This value must not correspond to a hard register
and must be out of the range of DWARF_FRAME_REGNUM().

gcc/
* config/arc/arc.h (DWARF_FRAME_REGNUM): Update definition.
(DWARF_FRAME_RETURN_COLUMN): Use RETURN_ADDR_REGNUM macro.
(INCOMING_RETURN_ADDR_RTX): Likewise.
(DWARF_ALT_FRAME_RETURN_COLUMN): Define.

gcc/testsuite/
* gcc.target/arc/cancel-1.c: New file.

libgcc/
* config/arc/linux-unwind.h (arc_fallback_frame_state): Use
DWARF_ALT_FRAME_RETURN_COLUMN macro.

Signed-off-by: Claudiu Zissulescu 
---
 gcc/config/arc/arc.h| 11 ++---
 gcc/testsuite/gcc.target/arc/cancel-1.c | 31 +
 libgcc/config/arc/linux-unwind.h|  9 +++
 3 files changed, 44 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arc/cancel-1.c

diff --git a/gcc/config/arc/arc.h b/gcc/config/arc/arc.h
index 78b5000eeb7..539a1662084 100644
--- a/gcc/config/arc/arc.h
+++ b/gcc/config/arc/arc.h
@@ -1356,7 +1356,7 @@ do { \
: (REGNO))
 
 /* Use gcc hard register numbering for eh_frame.  */
-#define DWARF_FRAME_REGNUM(REG) (REG)
+#define DWARF_FRAME_REGNUM(REG) ((REG) < 144 ? REG : INVALID_REGNUM)
 
 /* Map register numbers held in the call frame info that gcc has
collected using DWARF_FRAME_REGNUM to those that should be output
@@ -1370,9 +1370,14 @@ do { \
   : 57 + !!TARGET_MULMAC_32BY16_SET) /* MLO */ \
: (REGNO))
 
-#define DWARF_FRAME_RETURN_COLUMN  DWARF_FRAME_REGNUM (31)
+/* The DWARF 2 CFA column which tracks the return address.  */
+#define DWARF_FRAME_RETURN_COLUMN RETURN_ADDR_REGNUM
+#define INCOMING_RETURN_ADDR_RTX gen_rtx_REG (Pmode, RETURN_ADDR_REGNUM)
 
-#define INCOMING_RETURN_ADDR_RTX  gen_rtx_REG (Pmode, 31)
+/* The DWARF 2 CFA column which tracks the return address from a signal handler
+   context.  This value must not correspond to a hard register and must be out
+   of the range of DWARF_FRAME_REGNUM().  */
+#define DWARF_ALT_FRAME_RETURN_COLUMN 144
 
 /* Frame info.  */
 
diff --git a/gcc/testsuite/gcc.target/arc/cancel-1.c 
b/gcc/testsuite/gcc.target/arc/cancel-1.c
new file mode 100644
index 000..e050c538157
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arc/cancel-1.c
@@ -0,0 +1,31 @@
+/* Test for cleanups with pthread_cancel.  Any issue with libgcc's unwinder
+   will cause this test to spin in pthread_join.  */
+
+/* { dg-do run } */
+/* { dg-require-effective-target pthread } */
+/* { dg-options "-pthread" } */
+
+#include 
+#include 
+#include 
+
+void *thread_loop (void *)
+{
+  while (1)
+{
+  printf("worker: loop\n");
+  sleep(1);
+}
+}
+
+int main ()
+{
+  pthread_t thread;
+
+  pthread_create (, 0, thread_loop, 0);
+  sleep(5);
+  pthread_cancel (thread);
+  pthread_join (thread, 0);
+
+  return 0;
+}
diff --git a/libgcc/config/arc/linux-unwind.h b/libgcc/config/arc/linux-unwind.h
index 1d8c0c55883..be42a3163b2 100644
--- a/libgcc/config/arc/linux-unwind.h
+++ b/libgcc/config/arc/linux-unwind.h
@@ -120,10 +120,11 @@ arc_fallback_frame_state (struct _Unwind_Context *context,
= ((_Unwind_Ptr) &(regs[i])) - new_cfa;
 }
 
-  fs->regs.reg[31].how = REG_SAVED_VAL_OFFSET;
-  fs->regs.reg[31].loc.offset = ((_Unwind_Ptr) (regs[ret])) - new_cfa;
-
-  fs->retaddr_column = 31;
+  fs->signal_frame = 1;
+  fs->retaddr_column = __LIBGCC_DWARF_ALT_FRAME_RETURN_COLUMN__;
+  fs->regs.reg[fs->retaddr_column].how = REG_SAVED_VAL_OFFSET;
+  fs->regs.reg[fs->retaddr_column].loc.offset =
+((_Unwind_Ptr) (regs[ret])) - new_cfa;
 
   return _URC_NO_REASON;
 }
-- 
2.31.1

[committed] arc: Update stack size computation when accumulator registers are available.

[Claudiu Zissulescu via Gcc-patches]

When accumulator registers are available in a processor, they need to
be save onto stack durring interrupts.  We were already doing so, but
the stack size was wrongly computed in the case other than ARC600.

gcc/

* config/arc/arc.c (arc_compute_frame_size): Remove condition when
computin checking accumulator regs.
(arc_expand_prologue): Update comments.
(arc_expand_epilogue): Likewise.

Signed-off-by: Claudiu Zissulescu 
---
 gcc/config/arc/arc.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index 6de364e9ce0..3096a9bef44 100644
--- a/gcc/config/arc/arc.c
+++ b/gcc/config/arc/arc.c
@@ -2897,9 +2897,8 @@ arc_compute_frame_size (void)
  cfun, TARGET_DPFP))
 reg_size += UNITS_PER_WORD * 2;
 
-  /* Check for special MLO/MHI case used by ARC600' MUL64
- extension.  */
-  if (arc_must_save_register (R58_REG, cfun, TARGET_MUL64_SET))
+  /* Check if R58 is used.  */
+  if (arc_must_save_register (R58_REG, cfun, true))
 reg_size += UNITS_PER_WORD * 2;
 
   /* 4) Calculate extra size made up of the blink + fp size.  */
@@ -3878,7 +3877,7 @@ arc_expand_prologue (void)
}
 }
 
-  /* Save ARC600' MUL64 registers.  */
+  /* Save accumulator registers.  */
   if (arc_must_save_register (R58_REG, cfun, true))
 frame_size_to_allocate -= arc_save_callee_saves (3ULL << 58,
 false, false, 0, false);
@@ -3971,7 +3970,7 @@ arc_expand_epilogue (int sibcall_p)
   first_offset = 0;
 }
 
-  /* Restore ARC600' MUL64 registers.  */
+  /* Restore accumulator registers.  */
   if (arc_must_save_register (R58_REG, cfun, true))
 {
   rtx insn;
-- 
2.31.1

[Bug c/104028] M68k: Error: value -16034 out of range

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

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

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

[Bug c/104028] M68k: Error: value -16034 out of range

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

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

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

[Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)

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

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

--- Comment #5 from avieira at gcc dot gnu.org ---
Thanks Kewen, that seems worrying, I'll have a look.

[Bug c/104028] New: M68k: Error: value -16034 out of range

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

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

Bug ID: 104028
   Summary: M68k: Error: value -16034 out of range
   Product: gcc
   Version: 10.3.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 package sg3_utils on buildroot we get this error:
```
/home/peko/autobuild/instance-0/output-1/host/bin/m68k-linux-gcc
-DHAVE_CONFIG_H -I. -I..  -iquote ../include -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -Wall -W  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64  -Os -g2  -fno-dwarf2-cfi-asm  -Wl,-elf2flt=-r -static
-c -o sg_dd.o sg_dd.c
/tmp/cccfKmZB.s: Assembler messages:
/tmp/cccfKmZB.s:17093: Error: value -16034 out of range
/tmp/cccfKmZB.s:17093: Error: value of -16034 too large for field of 1 byte at
23149
make[3]: *** [Makefile:1176: sg_vpd.o] Error 1
```

To reproduce it:
```
# git clone git://git.busybox.net/buildroot
# cd buildroot
# git checkout feb9185fc185c1f76e3789b0dc521e3cf98c1ebb
# wget -O .config
http://autobuild.buildroot.net/results/c49300d12a209b18f41d389f092324592b881277/config
# make olddefconfig && make
```

I'm going to add the preprocessed files.

[committed] libstdc++: Add C++20 std::make_shared enhancements (P0674R1)

[Jonathan Wakely via Gcc-patches]

Tested powerpc64-le-linux, pushed to trunk.
N.B. we had a patch from JeanHeyd two years ago adding the first part of
this (P0674R1), but this is much simpler, works without concepts, and
also adds make_shared_for_overwrite.



This adds the overloads of std::make_shared and std::allocate_shared for
creating arrays, added to C++20 by P0674R1.

It also adds std::make_shared_for_overwrite, added to C++20 by P1020R1
(and renamed by P1973R1). The std::make_unique_for_overwite overloads
are already supported.

The original std::make_shared overload is changed to construct a
shared_ptr directly instead of calling std::allocate_shared. This
removes a function call at runtime, and avoids having to do overload
resolution for std::allocate_shared, now that there are five overloads
of it.

Allocating a shared array is done by a new __shared_count constructor.
An array is allocated with space for additional elements at the end and
an instance of new _Sp_counted_array class template is constructed in
that unused capacity.

The non-array form of std::make_shared_for_overwrite uses the same
__shared_count constructor as the original std::make_shared overload,
but a new partial specialization of _Sp_counted_ptr_inplace is selected
when the allocator's value_type is the new _Sp_overwrite_tag type. That
new partial specialization default-initializes its contained object and
destroys it with a destructor call rather than using the allocator.

Despite being C++20 features, this implementation only uses concepts
conditionally, with workarounds when they are not supported. This allows
it to work with older non-GCC compilers (Clang 9 and icc 2021). At some
point we can simplify the code by removing the workarounds.

libstdc++-v3/ChangeLog:

* include/bits/shared_ptr.h (__cpp_lib_shared_ptr_weak_type):
Correct type of macro value.
(shared_ptr): Add additional friend declarations.
(make_shared, allocate_shared): Constrain existing overloads and
remove static_assert.
* include/bits/shared_ptr_base.h (__cpp_lib_smart_ptr_for_overwrite):
New macro.
(_Sp_counted_ptr_inplace): New partial
specialization for use with make_shared_for_overwrite.
(__cpp_lib_shared_ptr_arrays): Update value for C++20.
(_Sp_counted_array_base): New class template.
(_Sp_counted_array): New class template.
(__shared_count(_Tp*&, const _Sp_counted_array_base&, _Init)):
New constructor for allocating shared arrays.
(__shared_ptr(const _Sp_counted_array_base&, _Init)): Likewise.
* include/std/version (__cpp_lib_shared_ptr_weak_type): Correct
type.
(__cpp_lib_shared_ptr_arrays): Update value for C++20.
(__cpp_lib_smart_ptr_for_overwrite): New macro.
* testsuite/20_util/shared_ptr/creation/99006.cc: Adjust
expected errors.
* testsuite/20_util/shared_ptr/creation/array.cc: New test.
* testsuite/20_util/shared_ptr/creation/overwrite.cc: New test.
* testsuite/20_util/shared_ptr/creation/version.cc: New test.
* testsuite/20_util/unique_ptr/creation/for_overwrite.cc: Check
feature test macro. Test non-trivial default-initialization.
---
 libstdc++-v3/include/bits/shared_ptr.h| 271 +++-
 libstdc++-v3/include/bits/shared_ptr_base.h   | 299 +-
 libstdc++-v3/include/std/version  |   6 +-
 .../20_util/shared_ptr/creation/99006.cc  |   7 +-
 .../20_util/shared_ptr/creation/array.cc  | 224 +
 .../20_util/shared_ptr/creation/overwrite.cc  | 143 +
 .../20_util/shared_ptr/creation/version.cc|  18 ++
 .../unique_ptr/creation/for_overwrite.cc  |  25 +-
 8 files changed, 975 insertions(+), 18 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/20_util/shared_ptr/creation/array.cc
 create mode 100644 
libstdc++-v3/testsuite/20_util/shared_ptr/creation/overwrite.cc
 create mode 100644 
libstdc++-v3/testsuite/20_util/shared_ptr/creation/version.cc

diff --git a/libstdc++-v3/include/bits/shared_ptr.h 
b/libstdc++-v3/include/bits/shared_ptr.h
index 5fdfcb2c4e1..f44008ed2b1 100644
--- a/libstdc++-v3/include/bits/shared_ptr.h
+++ b/libstdc++-v3/include/bits/shared_ptr.h
@@ -100,6 +100,57 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #endif
 }
 
+  /// @cond undocumented
+
+  // Constraint for overloads taking non-array types.
+#if __cpp_concepts && __cpp_lib_type_trait_variable_templates
+  template
+requires (!is_array_v<_Tp>)
+using _NonArray = _Tp;
+#else
+  template
+using _NonArray = __enable_if_t::value, _Tp>;
+#endif
+
+#if __cpp_lib_shared_ptr_arrays >= 201707L
+  // Constraint for overloads taking array types with unknown bound, U[].
+#if __cpp_concepts
+  template
+requires is_array_v<_Tp> && (extent_v<_Tp> == 0)
+using _UnboundedArray = _Tp;
+#else
+  template
+using _UnboundedArray
+  = __enable_if_t<__is_array_unknown_bounds<_Tp>::value, _Tp>;
+#endif
+
+  // 

[Bug ada/104027] [12 Regression] libgnat-12.so requires executable stack on x86_64-linux

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 CC||charlet at gcc dot gnu.org,
   ||ebotcazou at gcc dot gnu.org,
   ||pmderodat at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Compiling a-nbnbig.o with additional -Wa,--noexecstack fixes it, but it is an
ugly workaround and would need to be done conditionally on the assembler
supporting it and on the target being a target where gcc normally emits
.note.GNU-stack.