Revert "Fix PR 67102: Add libstdc++ dependancy to libffi" [PR67102]

This reverts commit db1a65d9364fe72c2fff65fb2dec051728b6f3fa.

On 2021-09-17T01:01:39-0700, Andrew Pinski via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> On Fri, Sep 17, 2021 at 12:46 AM Thomas Schwinge <thomas@codesourcery.com> wrote:
>> On 2021-09-15T13:56:37-0700, apinski--- via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>> > The error message is obvious -funconfigured-libstdc++-v3 is used
>> > on the g++ command line.  So we just add the dependancy.
>>
>> > --- a/Makefile.def
>> > +++ b/Makefile.def
>> > @@ -592,6 +592,7 @@ dependencies = { module=configure-target-fastjar; on=configure-target-zlib; };
>> >  dependencies = { module=all-target-fastjar; on=all-target-zlib; };
>> >  dependencies = { module=configure-target-libgo; on=configure-target-libffi; };
>> >  dependencies = { module=configure-target-libgo; on=all-target-libstdc++-v3; };
>> > +dependencies = { module=configure-target-libffi; on=all-target-libstdc++-v3; };
>> >  dependencies = { module=all-target-libgo; on=all-target-libbacktrace; };
>> >  dependencies = { module=all-target-libgo; on=all-target-libffi; };
>> >  dependencies = { module=all-target-libgo; on=all-target-libatomic; };
>>
>> I'm confused, because given that this 'Makefile.def' change only has the
>> following effect:
>>
>> > --- a/Makefile.in
>> > +++ b/Makefile.in
>> > @@ -61261,6 +61261,7 @@ all-bison: maybe-all-intl
>> >  all-flex: maybe-all-intl
>> >  all-m4: maybe-all-intl
>> >  configure-target-libgo: maybe-all-target-libstdc++-v3
>> > +configure-target-libffi: maybe-all-target-libstdc++-v3
>> >  configure-target-liboffloadmic: maybe-configure-target-libgomp
>> >  all-target-liboffloadmic: maybe-all-target-libgomp
>> >  configure-target-newlib: maybe-all-binutils
>>
>> ... isn't that actually a no-op, because we already had such a dependency
>> listed?  Now twice:
>>
>>     $ grep -n -F 'configure-target-libffi: maybe-all-target-libstdc++-v3' -- Makefile.in
>>     61264:configure-target-libffi: maybe-all-target-libstdc++-v3
>>     61372:configure-target-libffi: maybe-all-target-libstdc++-v3
>>
>> Compared to the existing one, the one you've added is additionally
>> restricted by '@unless gcc-bootstrap'.
>>
>> I noticed this as I remembered that on our og[...] development branches
>> we have a patch in the opposite direction: get rid of this dependency via
>> removing 'lang_env_dependencies = { module=libffi; cxx=true; };' from
>> 'Makefile.def'.  See
>> <http://mid.mail-archive.com/alpine.DEB.2.21.9999.1812201344250.99920@build7-trusty-cs.sje.mentorg.com>
>> "Disable libstdc++ dependency for libffi".  (Maciej CCed in case you have
>> any further thoughts on that.)
>
> Oh, I see what happened now, the old bug was actually fixed by r6-5415
> which added cxx=true.
> So yes my patch is actually not needed and can be reverted.
> I tried to look to see if there was a dependency was there but for
> some reason I did not see it.

aix: AIX is not GLIBC.

A recent patch added tests for OPTION_GLIBC that is defined in
linux.h and linux64.h.  This broke bootstrap for non-Linux rs6000
configurations.  This patch defines OPTION_GLIBC as 0.

* config/rs6000/aix.h (OPTION_GLIBC): Define as 0.

libfortran: Provide fallback __issignalingl for IBM extended long double

On Mon, Jan 17, 2022 at 12:11:59AM +0100, FX via Gcc-patches wrote:
> This patch is the third in my “signaling NaN” series.
> For targets with IEEE support but without the issignaling macro in libc
> (i.e., everywhere except glibc), this allows us to provide a fallback
> implementation.

This doesn't seem to handle the powerpc* IBM double double long double.

__LDBL_IS_IEC_60559__ isn't defined for this type, because it is far from
an IEEE754 type, but it has signaling NaNs - as can be seen in glibc
libc/sysdeps/ieee754/ldbl-128ibm/s_issignalingl.c
the type is a pair of doubles and whether it is a sNaN or qNaN is determined
by whether the first double is a sNaN or qNaN.

2022-01-25  Jakub Jelinek  <jakub@redhat.com>

* ieee/issignaling_fallback.h (__issignalingl): Define for
IBM extended long double are returning __issignaling on the
first double.

tree-optimization/104214 - amend PR100740 fix for pointer compares

When we have a pointer relational compare we have stronger guarantees
about overflow, in particular rewriting BASE0 + STEP0 cmp BASE1 + STEP1
as BASE0 + STEP0 - STEP1 cmp BASE1 is always valid and the new IV0
does not overflow.  The patch basically reverts the previous change
when pointers are involved, keeping only the more conservative handling
for equality compares which can involve comparing different object
addresses.

2022-01-25  Richard Biener  <rguenther@suse.de>

PR tree-optimization/104214
* tree-ssa-loop-niter.cc (number_of_iterations_cond): Use
stronger guarantees for relational pointer compares when
rewriting BASE0 + STEP0 cmp BASE1 + STEP1 as
BASE0 + STEP0 - STEP1 cmp BASE1.

* gcc.dg/vect/pr81196-2.c: New variant testcase only
requiring vect_int.

libgcc: Fix _Unwind_Find_FDE for missing unwind data with glibc 2.35

_dl_find_object returns success even if no unwind information has been
found, and dlfo_eh_frame is NULL.

libgcc/ChangeLog:

PR libgcc/104207
* unwind-dw2-fde-dip.c (_Unwind_Find_FDE): Add NULL check.

Fortran: fix preprocessor condition

libgfortran/ChangeLog:

* ieee/issignaling_fallback.h: fix preprocessor condition.

Fortran: do not run signaling testsuite on 32-bit x86/x86_64

gcc/testsuite/ChangeLog:

* gfortran.dg/ieee/signaling_3.f90: Skip test on 32-bit x86/x86_64.

Fortran: fix typo in signaling NaN testcase

gcc/testsuite/ChangeLog:

* gfortran.dg/ieee/signaling_1.f90: Fix test.

rs6000: Remove GCC 8.1 U10__float128 mangling compatibility [PR104172]

In GCC 7.x and earlier, while it had -mabi=ieeelongdouble option, that option
was undocumented and unsupported.
In GCC 8.1 that option got documented and -mabi=ieeelongdouble long double started
to be mangled as U10__float128.
In GCC 9 and backported to before 8.2 release, that mangling changed to
u9__ieee128 and a support for emitting compatibility mangling aliases have
been added.
Unfortunately, as mentioned in the PR, those don't really work well in many
cases, the free_lang_data pass throws away important trees, so e.g. with
-flto -ffat-lto-objects the compiler often ICEs on templates that involve
IEEE quad long double arguments etc. because the mangling was done too late
(at final time).
Furthermore, lto1's mangler is not the C++ mangler, so with -flto it would
often emit as "mangled identifiers" something that wasn't a valid assembler
identifier, e.g. operator+ etc.
While it is possible to do such mangling earlier, e.g. at the same time when
the C++ FE emits its mangling aliases and untested proof of concept is in
the PR, there seems to be agreement that we shouldn't bother with this
ABI compatibility with something that probably nobody really used.
GCC 8.2 already uses the new mangling, it was just a few months, but more
importantly, libstdc++ support for IEEE quad long double on
powerpc64le-linux was only added in GCC 11, and glibc support for that some
weeks after 8.2 got released.

So, the following patch just drops those aliases.

2022-01-25  Jakub Jelinek  <jakub@redhat.com>

PR target/104172
gcc/
* config/rs6000/rs6000-internal.h (rs6000_passes_ieee128): Don't
declare.
* config/rs6000/rs6000.cc (rs6000_passes_ieee128,
ieee128_mangling_gcc_8_1): Remove.
(TARGET_ASM_GLOBALIZE_DECL_NAME): Don't redefine.
(rs6000_mangle_type): Return "u9__ieee128" instead of
ieee128_mangling_gcc_8_1 ? "U10__float128" : "u9__ieee128".
(rs6000_globalize_decl_name): Remove.
* config/rs6000/rs6000-call.cc (init_cumulative_args,
rs6000_function_arg_advance_1): Don't set rs6000_passes_ieee128.

Daily bump.

Remove duplicate code block.

gcc/ChangeLog:
* pointer-query.cc (pointer_query::dump): Remove duplicate
block.

preprocessor: -Wbidi-chars and UCNs [PR104030]

Stephan Bergmann reported that our -Wbidi-chars breaks the build
of LibreOffice because we warn about UCNs even when their usage
is correct: LibreOffice constructs strings piecewise, as in:

  aText = u"\u202D" + aText;

and warning about that is overzealous.  Since no editor (AFAIK)
interprets UCNs to show them as Unicode characters, there's less
risk in misinterpreting them, and so perhaps we shouldn't warn
about them by default.  However, identifiers containing UCNs or
programs generating other programs could still cause confusion,
so I'm keeping the UCN checking.  To turn it on, you just need
to use -Wbidi-chars=unpaired,ucn or -Wbidi-chars=any,ucn.

The implementation is done by using the new EnumSet feature.

PR preprocessor/104030

gcc/c-family/ChangeLog:

* c.opt (Wbidi-chars): Mark as EnumSet.  Also accept =ucn.

gcc/ChangeLog:

* doc/invoke.texi: Update documentation for -Wbidi-chars.

libcpp/ChangeLog:

* include/cpplib.h (enum cpp_bidirectional_level): Add
bidirectional_ucn.  Set values explicitly.
* internal.h (cpp_reader): Adjust warn_bidi_p.
* lex.cc (maybe_warn_bidi_on_close): Don't warn about UCNs
unless UCN checking is on.
(maybe_warn_bidi_on_char): Likewise.

gcc/testsuite/ChangeLog:

* c-c++-common/Wbidi-chars-10.c: Turn on UCN checking.
* c-c++-common/Wbidi-chars-11.c: Likewise.
* c-c++-common/Wbidi-chars-14.c: Likewise.
* c-c++-common/Wbidi-chars-16.c: Likewise.
* c-c++-common/Wbidi-chars-17.c: Likewise.
* c-c++-common/Wbidi-chars-4.c: Likewise.
* c-c++-common/Wbidi-chars-5.c: Likewise.
* c-c++-common/Wbidi-chars-6.c: Likewise.
* c-c++-common/Wbidi-chars-7.c: Likewise.
* c-c++-common/Wbidi-chars-8.c: Likewise.
* c-c++-common/Wbidi-chars-9.c: Likewise.
* c-c++-common/Wbidi-chars-ranges.c: Likewise.
* c-c++-common/Wbidi-chars-18.c: New test.
* c-c++-common/Wbidi-chars-19.c: New test.
* c-c++-common/Wbidi-chars-20.c: New test.
* c-c++-common/Wbidi-chars-21.c: New test.
* c-c++-common/Wbidi-chars-22.c: New test.
* c-c++-common/Wbidi-chars-23.c: New test.

Fortran: provide a fallback implementation of issignaling

For targets with IEEE support but without the issignaling macro in libc
(currently, everywhere except glibc), this allows us to provide a fallback
implementation. In order to keep the code in ieee_helper.c relatively
readable, I've put that new implementation in a separate file,
issignaling_fallback.h.

libgfortran/ChangeLog:

* ieee/issignaling_fallback.h: New file.
* ieee/ieee_helper.c: Include issignaling_fallback.h when target
does not define issignaling macro.

gcc/testsuite/ChangeLog:

* gfortran.dg/ieee/signaling_1.f90: Do not require issignaling.
* gfortran.dg/ieee/signaling_2.f90: Add comment.
* gfortran.dg/ieee/signaling_3.f90: New test.

rtl: builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]

This optimizations were originally in glibc, but was removed
and suggested that they were a good fit as gcc builtins[1].

feclearexcept and feraiseexcept were extended (in comparison to the
glibc version) to accept any combination of the accepted flags, not
limited to just one flag bit at a time anymore.

The builtin expanders needs knowledge of the target libc's FE_*
values, so they are limited to expand only to suitable libcs.

[1] https://sourceware.org/legacy-ml/libc-alpha/2020-03/msg00047.html
    https://sourceware.org/legacy-ml/libc-alpha/2020-03/msg00080.html

2020-08-13  Raoni Fassina Firmino  <raoni@linux.ibm.com>

gcc/
PR target/94193
* builtins.cc (expand_builtin_fegetround): New function.
(expand_builtin_feclear_feraise_except): New function.
(expand_builtin): Add cases for BUILT_IN_FEGETROUND,
BUILT_IN_FECLEAREXCEPT and BUILT_IN_FERAISEEXCEPT.
* config/rs6000/rs6000.md (fegetroundsi): New pattern.
(feclearexceptsi): New Pattern.
(feraiseexceptsi): New Pattern.
* doc/extend.texi: Add a new introductory paragraph about the
new builtins.
* doc/md.texi: (fegetround@var{m}): Document new optab.
(feclearexcept@var{m}): Document new optab.
(feraiseexcept@var{m}): Document new optab.
* optabs.def (fegetround_optab): New optab.
(feclearexcept_optab): New optab.
(feraiseexcept_optab): New optab.

gcc/testsuite/
PR target/94193
* gcc.target/powerpc/builtin-feclearexcept-feraiseexcept-1.c: New test.
* gcc.target/powerpc/builtin-feclearexcept-feraiseexcept-2.c: New test.
* gcc.target/powerpc/builtin-fegetround.c: New test.

Signed-off-by: Raoni Fassina Firmino <raoni@linux.ibm.com>

c++: Fix non-portable default argument of make_auto_1 [PR104197]

Avoid using the macro current_template_depth, which expands to an
expression that uses __FUNCTION__, within the signature of a function.

PR c++/104197

gcc/cp/ChangeLog:

* pt.cc (make_auto_1): Use -1 as a placeholder default argument
for level.

c++: value category of compound object expr [PR104173]

Here the call to (the &&-qualified) toLower() is incorrectly rejected
during overload resolution because the object expression is encoded as
an lvalue when it's really a prvalue.  The object expression,
instance()->applicationName(), is encoded as an INDIRECT_REF of a
COMPOUND_EXPR

  *(*instance ();, &TARGET_EXPR <D.2383, QCoreApplication::applicationName ()>;);

which lvalue_kind deems an lvalue.

This issue is similar to PR88103 except that here the original compound
object expression is a prvalue rather than an xvalue.  The fix there was to
adjust the result of unary_complex_lvalue in build_class_member_access_expr
so that xvalueness of the original expression is preserved.  This patch
extends that fix so that rvalueness is preserved more generally.

PR c++/104173

gcc/cp/ChangeLog:

* typeck.cc (build_class_member_access_expr): Extend
unary_complex_lvalue result adjustment to preserve all
rvalues, not just xvalues.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/ref-qual21.C: New test.

gcc-changelog: Be stricter for top-level dir.

contrib/ChangeLog:

* gcc-changelog/git_commit.py: New files in toplev must
be explicitly marked as "New file".
* gcc-changelog/test_email.py: Test.
* gcc-changelog/test_patches.txt: Add test.

tree-optimization/102131 - fix niter analysis wrt overflow

This fixes the overflow issues seen with analyzing
BASE0 + STEP0 cmp BASE1 + STEP1 as BASE0 + STEP0 - STEP1 cmp BASE1
by following the logic we have when simplifying comparisons.

2022-01-24  Richard Biener  <rguenther@suse.de>
    Jiufu Guo  <guojiufu@linux.ibm.com>

PR tree-optimization/100740
PR tree-optimization/101508
PR tree-optimization/101972
PR tree-optimization/102131
* tree-ssa-loop-niter.cc (number_of_iterations_cond): Properly
constrain BASE0 + STEP0 cmp BASE1 + STEP1 to
BASE0 + STEP0 - STEP1 cmp BASE1 transform.

* gcc.dg/torture/pr100740.c: New testcase.
* gcc.dg/torture/pr101508.c: Likewise.
* gcc.dg/torture/pr101972.c: Likewise.
* gcc.dg/torture/pr102131-1.c: Likewise.
* gcc.dg/torture/pr102131-2.c: Likewise.
* gcc.dg/torture/pr102131-3.c: Likewise.
* gcc.dg/torture/pr102131-4.c: Likewise.

acinclude.m4: Remove duplicite AC_DEFUN.

libatomic/ChangeLog:

* acinclude.m4: Remove duplicate
LIBAT_CHECK_LINKER_FEATURES.
* configure: Regenerate.

options: Add EnumBitSet property support [PR104158]

On Sat, Jan 22, 2022 at 01:47:08AM +0100, Jakub Jelinek via Gcc-patches wrote:
> I think with the 2) patch I achieve what we want for Fortran, for 1)
> the only behavior from gcc 11 is that
> -fsanitize-coverage=trace-cmp,trace-cmp is now rejected.
> This is mainly from the desire to disallow
> -fconvert=big-endian,little-endian or -Wbidi-chars=bidirectional,any
> etc. where it would be confusing to users what exactly it means.
> But it is the only from these options that actually acts as an Enum
> bit set, each enumerator can be specified with all the others.
> So one option would be stop requiring the EnumSet implies Set properties
> must be specified and just require that either they are specified on all
> EnumValues, or on none of them; the latter case would be for
> -fsanitize-coverage= and the non-Set case would mean that all the
> EnumValues need to have disjoint Value bitmasks and that they can
> be all specified and unlike the Set case also repeated.
> Thoughts on this?

Here is an incremental patch to the first two patches of the series
that implements EnumBitSet that fully restores the -fsanitize-coverage
GCC 11 behavior.

2022-01-24  Jakub Jelinek  <jakub@redhat.com>

PR sanitizer/104158
* opt-functions.awk (var_set): Handle EnumBitSet property.
* optc-gen.awk: Don't disallow RejectNegative if EnumBitSet is
specified.
* opts.h (enum cl_enum_var_value): New type.
* opts-common.cc (decode_cmdline_option): Use CLEV_* values.
Handle CLEV_BITSET.
(cmdline_handle_error): Handle CLEV_BITSET.
* opts.cc (test_enum_sets): Also test EnumBitSet requirements.
* doc/options.texi (EnumBitSet): Document.
* common.opt (fsanitize-coverage=): Use EnumBitSet instead of
EnumSet.
(trace-pc, trace-cmp): Drop Set properties.

* gcc.dg/sancov/pr104158-7.c: Adjust for repeating of arguments
being allowed.

fortran: Extend -fconvert= option for ppc64le r16_ieee and r16_ibm

This patch on top of the previously posted option handling changes patch
allows specifying -fconvert=swap,r16_ieee etc. (but will error on it
when not on powerpc64le because in the library such swapping is only
implemented for HAVE_REAL_17).

2022-01-24  Jakub Jelinek  <jakub@redhat.com>

* lang.opt (fconvert=): Add EnumSet property and mention also
r16_ieee and r16_ibm arguments.
(big-endian, little-endian, native, swap): Add Set(1) property.
(r16_ieee, r16_ibm): New EnumValue entries with Set(2) property.
* trans-types.cc (gfc_init_kinds): Emit gfc_fatal_error for
-fconvert=r16_ieee or -fconvert=r16_ibm when R16_IEEE <=> R16_IBM
conversions aren't supported.

options: Fix up -fsanitize-coverage= [PR104158]

This is incremental patch to fix up -fsanitize-coverage= option
handling, allow -fno-sanitize-coverage= again, allow both
options together in one option or make
-fsanitize-coverage=trace-pc -fsanitize-coverage=trace-cmp
actually enable both suboptions rather than the last one.

2022-01-24  Jakub Jelinek  <jakub@redhat.com>

PR sanitizer/104158
* common.opt (flag_sanitize_coverage): Remove Variable entry.
(fsanitize-coverage=): Remove RejectNegative property, add
Var(flag_sanitize_coverage) and EnumSet properties.
(trace-pc): Add Set(1) property.
(trace-cmp): Add Set(2) property.
* opts.cc (common_handle_option): Don't handle
OPT_fsanitize_coverage_.

* gcc.dg/spellcheck-options-24.c: New test.
* gcc.dg/sancov/pr104158-1.c: New test.
* gcc.dg/sancov/pr104158-2.c: New test.
* gcc.dg/sancov/pr104158-3.c: New test.
* gcc.dg/sancov/pr104158-4.c: New test.
* gcc.dg/sancov/pr104158-5.c: New test.
* gcc.dg/sancov/pr104158-6.c: New test.
* gcc.dg/sancov/pr104158-7.c: New test.

options: Add EnumSet and Set property support [PR104158]

The following patch is infrastructure support for at least 3 different
options that need changes:
1) PR104158 talks about a regression with the -fsanitizer-coverage=
   option; in GCC 11 and older and on trunk prior to r12-1177, this
   option behaved similarly to -f{,no-}sanitizer{,-recover}= options,
   namely that the option allows negative and argument of the option
   is a list of strings, each of them has some enumerator and
   -fsanitize-coverage= enabled those bits in the underlying
   flag_sanitize_coverage, while -fno-sanitize-coverage= disabled them.
   So, -fsanitize-coverage=trace-pc,trace-cmp was equivalent to
   -fsanitize-coverage=trace-pc -fsanitize-coverage=trace-cmp and both
   set flag_sanitize_coverage to
   (SANITIZE_COV_TRACE_PC | SANITIZE_COV_TRACE_CMP)
   Also, e.g.
   -fsanitize-coverage=trace-pc,trace-cmp -fno-sanitize-coverage=trace-pc
   would in the end set flag_sanitize_coverage to
   SANITIZE_COV_TRACE_CMP (first set both bits, then subtract one)
   The r12-1177 change, I think done to improve argument misspelling
   diagnostic, changed the option incompatibly in multiple ways,
   -fno-sanitize-coverage= is now rejected, only a single argument
   is allowed, not multiple and
   -fsanitize-coverage=trace-pc -fsanitize-coverage=trace-cmp
   enables just SANITIZE_COV_TRACE_CMP and not both (each option
   overrides the previous value)
2) Thomas Koenig wants to extend Fortran -fconvert= option for the
   ppc64le real(kind=16) swapping support; currently the option
   accepts -fconvert={native,swap,big-endian,little-endian} and the
   intent is to add support for -fconvert=r16_ibm and -fconvert=r16_ieee
   (that alone is just normal Enum), but also to handle
   -fconvert=swap,r16_ieee or -fconvert=r16_ieee,big-endian but not
   -fconvert=big-endian,little-endian - the
   native/swap/big-endian/little-endian are one mutually exclusive set
   and r16_ieee/r16_ibm another one.
   See https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587943.html
   and thread around that.
3) Similarly Marek Polacek wants to extend the -Wbidi-chars= option,
   such that it will handle not just the current
   -Wbidi-chars={none,bidirectional,any}, but also -Wbidi-chars=ucn
   and bidirectional,ucn and ucn,any etc.  Again two separate sets,
   one none/bidirectional/any and another one ucn.
   See https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588960.html

The following patch adds framework for this and I'll post incremental
patches for 1) and 2).
As I've tried to document, such options are marked by additional
EnumSet property on the option and in that case all the EnumValues
in the Enum referenced from it must use a new Set property with set
number (initially I wanted just mark last enumerator in each mutually
exclusive set, but optionlist is sorted and so it doesn't really work
well).  So e.g. for the Fortran -fconvert=, one specifies:
fconvert=
Fortran RejectNegative Joined Enum(gfc_convert) EnumSet Var(flag_convert) Init(GFC_FLAG_CONVERT_NATIVE)
-fconvert=<big-endian|little-endian|native|swap|r16_ieee|r16_ibm>      The endianness used for unformatted files.

Enum
Name(gfc_convert) Type(enum gfc_convert) UnknownError(Unrecognized option to endianness value: %qs)

EnumValue
Enum(gfc_convert) String(big-endian) Value(GFC_FLAG_CONVERT_BIG) Set(1)

EnumValue
Enum(gfc_convert) String(little-endian) Value(GFC_FLAG_CONVERT_LITTLE) Set(1)

EnumValue
Enum(gfc_convert) String(native) Value(GFC_FLAG_CONVERT_NATIVE) Set(1)

EnumValue
Enum(gfc_convert) String(swap) Value(GFC_FLAG_CONVERT_SWAP) Set(1)

EnumValue
Enum(gfc_convert) String(r16_ieee) Value(GFC_FLAG_CONVERT_R16_IEEE) Set(2)

EnumValue
Enum(gfc_convert) String(r16_ibm) Value(GFC_FLAG_CONVERT_R16_IBM) Set(2)

and this says to the option handling code that
1) if only one arg is specified to one instance of the option, it can be any
of those 6
2) if two args are specified, one has to be from the first 4 and another
from the last 2, in any order
3) at most 2 args may be specified (there are just 2 sets)

There is a requirement on the Value values checked in self-test, the
values from one set ored together must be disjunct from values from
another set ored together.  In the Fortran case, the first 4 are 0-3
so mask is 3, and the last 2 are 4 and 8, so mask is 12.
When say -fconvert=big-endian is specified, it sets the first set
to GFC_FLAG_CONVERT_BIG (2) but doesn't modify whatever value the
other set had, so e.g.
-fconvert=big-endian -fconvert=r16_ieee
-fconvert=r16_ieee -fconvert=big-endian
-fconvert=r16_ieee,big_endian
-fconvert=big_endian,r16_ieee
all behave the same.

Also, with the EnumSet support, it is now possible to allow
not specifying RejectNegative - we can set some set's value and
then clear it and set it again to some other value etc.

I think with the 2) patch I achieve what we want for Fortran, for 1)
the only behavior from gcc 11 is that
-fsanitize-coverage=trace-cmp,trace-cmp is now rejected.
This is mainly from the desire to disallow
-fconvert=big-endian,little-endian or -Wbidi-chars=bidirectional,any
etc. where it would be confusing to users what exactly it means.
But it is the only from these options that actually acts as an Enum
bit set, each enumerator can be specified with all the others.
So one option would be stop requiring the EnumSet implies Set properties
must be specified and just require that either they are specified on all
EnumValues, or on none of them; the latter case would be for
-fsanitize-coverage= and the non-Set case would mean that all the
EnumValues need to have disjoint Value bitmasks and that they can
be all specified and unlike the Set case also repeated.
Thoughts on this?

2022-01-24  Jakub Jelinek  <jakub@redhat.com>

PR sanitizer/104158
* opt-functions.awk (var_set): Handle EnumSet property.
* optc-gen.awk: Don't disallow RejectNegative if EnumSet is
specified.
* opt-read.awk: Handle Set property.
* opts.h (CL_ENUM_SET_SHIFT, CL_ERR_ENUM_SET_ARG): Define.
(struct cl_decoded_option): Mention enum in value description.
Add mask member.
(set_option): Add mask argument defaulted to 0.
* opts.cc (test_enum_sets): New function.
(opts_cc_tests): Call it.
* opts-common.cc (enum_arg_to_value): Change return argument
from bool to int, on success return index into the cl_enum_arg
array, on failure -1.  Add len argument, if non-0, use strncmp
instead of strcmp.
(opt_enum_arg_to_value): Adjust caller.
(decode_cmdline_option): Handle EnumSet represented as
CLVC_ENUM with non-zero var_value.  Initialize decoded->mask.
(decode_cmdline_options_to_array): CLear opt_array[0].mask.
(handle_option): Pass decoded->mask to set_options last argument.
(generate_option): Clear decoded->mask.
(generate_option_input_file): Likewise.
(cmdline_handle_error): Handle CL_ERR_ENUM_SET_ARG.
(set_option): Add mask argument, use it for CLVC_ENUM.
(control_warning_option): Adjust enum_arg_to_value caller.
* doc/options.texi: Document Set and EnumSet properties.

properly disable -fsplit-stack on non-glibc targets [PR104170]

On Sat, Jan 22, 2022 at 10:32:21AM +0100, Martin Liška wrote:
> I've just noticed the patch broke a few cross compilers:
>
> s390x-ibm-tpf:
>
> /home/marxin/buildworker/zen2-cross-compilers/build/gcc/common/config/s390/s390-common.cc: In function ‘bool s390_supports_split_stack(bool, gcc_options*)’:
> /home/marxin/buildworker/zen2-cross-compilers/build/gcc/common/config/s390/s390-common.cc:126:13: error: ‘struct gcc_options’ has no member named ‘x_linux_libc’
>   126 |   if (opts->x_linux_libc == LIBC_GLIBC)
>       |             ^~~~~~~~~~~~
>
> i686-kopensolaris-gnu, i686-symbolics-gnu
>
> /home/marxin/buildworker/zen2-cross-compilers/build/gcc/common/config/i386/i386-common.cc: In function ‘bool ix86_supports_split_stack(bool, gcc_options*)’:
> /home/marxin/buildworker/zen2-cross-compilers/build/gcc/common/config/i386/i386-common.cc:1721:13: error: ‘struct gcc_options’ has no member named ‘x_linux_libc’
>  1721 |   if (opts->x_linux_libc != LIBC_GLIBC)
>       |             ^~~~~~~~~~~~
> make[1]: *** [Makefile:2418: i386-common.o] Error 1
>
> Can you please take a look? Btw. do you have a bugzilla account?

I bet instead of opts->x_linux_libc != LIBC_GLIBC it needs to use
 #ifdef OPTION_GLIBC
   if (!OPTION_GLIBC)
 #endif
or so.  I think the first committed patch actually used that
but used it in #if directive, which is wrong because it is something
that needs to be evaluated at runtime.

That doesn't work well either, because the *supports_split_stack
hooks have opts argument and OPTION_GLIBC doesn't take that.

So, here is a patch that introduces OPTION_*_P macros that take opts
as an argument and redefines OPTION_* using those (similarly to how
the option scripts create TARGET_*_P and TARGET_* macros).

2022-01-24  Jakub Jelinek  <jakub@redhat.com>

PR bootstrap/104170
* config/linux.h (OPTION_GLIBC_P, OPTION_UCLIBC_P,
OPTION_BIONIC_P, OPTION_MUSL_P): Define.
(OPTION_GLIBC, OPTION_UCLIBC, OPTION_BIONIC, OPTION_MUSL): Redefine
using OPTION_*_P macros.
* config/alpha/linux.h (OPTION_GLIBC_P, OPTION_UCLIBC_P,
OPTION_BIONIC_P, OPTION_MUSL_P): Define.
(OPTION_GLIBC, OPTION_UCLIBC, OPTION_BIONIC, OPTION_MUSL): Redefine
using OPTION_*_P macros.
* config/rs6000/linux.h (OPTION_GLIBC_P, OPTION_UCLIBC_P,
OPTION_BIONIC_P, OPTION_MUSL_P): Define.
(OPTION_GLIBC, OPTION_UCLIBC, OPTION_BIONIC, OPTION_MUSL): Redefine
using OPTION_*_P macros.
* config/rs6000/linux64.h (OPTION_GLIBC_P, OPTION_UCLIBC_P,
OPTION_BIONIC_P, OPTION_MUSL_P): Define.
(OPTION_GLIBC, OPTION_UCLIBC, OPTION_BIONIC, OPTION_MUSL): Redefine
using OPTION_*_P macros.
* config/fuchsia.h (OPTION_MUSL_P): Redefine.
* config/glibc-stdint.h (OPTION_MUSL_P): Define if not defined.
* common/config/s390/s390-common.cc (s390_supports_split_stack): Re-add
ATTRIBUTE_UNUSED to opts parameter.  If OPTION_GLIBC_P is defined, use
OPTION_GLIBC_P (opts) as condition, otherwise assume if (false).
* common/config/i386/i386-common.cc (ix86_supports_split_stack): If
OPTION_GLIBC_P is defined use !OPTION_GLIBC_P (opts) as condition,
otherwise assume if (true).

RISC-V: Fix testcase after bump isa spec version

Extension version might be different among different ISA spec version,
add explicitly isa-spec version to prevent that might fail when build
GCC with different default ISA version.

gcc/testsuite/ChangeLog

* gcc.target/riscv/attribute-19.c: Add -misa-spec=2.2

RISC-V: Do not emit zcisr and zifencei if i-ext is 2.0

I-ext 2.0 already included zicsr and zifencei, skip that prevent
confusing binutils.

gcc/ChangeLog

* common/config/riscv/riscv-common.cc (riscv_subset_list::to_string):
Skip zicsr and zifencei if I-ext is 2.0.

RISC-V: Change default ISA version into 20191213

Bump default ISA spec to newer version 20191213, current default ISA spec
is 2.2, but it's already out of date for a long time, sync with binutils
ISA version, convention in toolchain use.

gcc/ChangeLog:

* config.gcc: Modify default isa_spec version.

Update the type of control.base after changed

This patch correct the type of niter->control.base, when it is updated
as a PLUS expr.
During build PLUS expr, the result type should align with the type of
the operands.

PR tree-optimization/102087

gcc/ChangeLog:

* tree-ssa-loop-niter.cc (number_of_iterations_until_wrap):
Correct PLUS result type.

gcc/testsuite/ChangeLog:

* gcc.dg/pr102087_1.c: New test.

RISC-V: Update testcases info with new implement info

    After commit 591b6e00d1bfe12932ca31530d5859f95db8a35a " riscv: fix -Wformat-diag errors ", some strings in implement was changed.
    This patch update the check info in testcases to sync with it.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/arch-9.c: Update the check info.
* gcc.target/riscv/arch-10.c: Ditto.
* gcc.target/riscv/arch-12.c: Ditto.

testsuite: Ignore pr104159 psabi warning.

gcc/testsuite/ChangeLog:

* gcc.dg/analyzer/torture/pr104159.c: Ignore psabi warning.

x86: Also check mode of memory broadcast in bcst_mem_operand

Return false for invalid mode on memory broadcast in bcst_mem_operand:

(vec_duplicate:V16SF (mem/j:V4SF (reg/v/f:DI 109 [ b ])))

gcc/

PR target/104188
* config/i386/predicates.md (bcst_mem_operand): Also check mode
of memory broadcast.

gcc/testsuite/

PR target/104188
* gcc.target/i386/pr104188.c: New test.

Daily bump.

libstdc++: Fix std::spanstream move assignment [PR104032]

libstdc++-v3/ChangeLog:

PR libstdc++/104032
* include/std/spanstream (basic_spanbuf(basic_spanbuf&&)): Use
mem-initializer for _M_buf.
(basic_spanbuf::Operator=(basic_spanbuf&&)): Fix ill-formed
member access.
* testsuite/27_io/spanstream/2.cc: New test.

libstdc++: Use fast_float for long double if it uses binary64 format

We can use the new from_chars implementation when long double and double
have the same representation.

libstdc++-v3/ChangeLog:

* src/c++17/floating_from_chars.cc (USE_STRTOD_FOR_FROM_CHARS):
Define macro for case where std::from_chars is implemented in
terms of strtod, strtof or strtold.
(buffer_resource, valid_fmt, find_end_of_float, pattern)
(from_chars_impl, make_result, reserve_string): Do not define
unless USE_STRTOD_FOR_FROM_CHARS is defined.
(from_chars): Define when at least one of USE_LIB_FAST_FLOAT and
USE_STRTOD_FOR_FROM_CHARS is defined, instead of
_GLIBCXX_HAVE_USELOCALE. Use fast_float for long double when it
is binary64.

libstdc++: Restore support for unordered_map<const T, ...> [PR104174]

I broke this unintentionally in r12-4259.

libstdc++-v3/ChangeLog:

PR libstdc++/104174
* include/bits/hashtable_policy.h (_Map_base): Add partial
specialization for maps with const key types.
* testsuite/23_containers/unordered_map/104174.cc: New test.

libstdc++: Fix aliasing violation in std::shared_ptr [PR104019]

The non-atomic store that sets both reference counts to zero uses a
type-punned pointer, which has undefined behaviour. We could use memset
to write 8 bytes, but we don't actually need it to be a single store
anyway. No other thread can observe the values, that's why it's safe to
use non-atomic stores in the first place. So we can just set each count
to zero.

With -fstore-merging (which is enabled by default at -O2) GCC produces
the same code for this as for memset or the type punned store. Clang
does that store merging even at -O1.

libstdc++-v3/ChangeLog:

PR libstdc++/104019
* include/bits/shared_ptr_base.h (_Sp_counted_base<>::_M_release):
Set members to zero without type punning.

c++: designated init of char array by string constant [PR55227]

There are two underlying bugs in the designated initialization of char array
fields by string literals that cause:

(1) Rejection of valid cases with:
  (a) brace-enclosed string literal initializer (of any valid size), or
  (b) unbraced string literal shorter than the target char array field.

(2) Acceptance of invalid cases with designators appearing within the braces
    of a braced string literal, in which case the bogus 'designator' was
    being entirely ignored and the string literal treated as a positional
    initializer.

The fixes above allow to address a FIXME in cp_complete_array_type:

  /* FIXME: this code is duplicated from reshape_init.
     Probably we should just call reshape_init here?  */

I believe that this was obstructed by the designator bugs (see comment here
https://patchwork.ozlabs.org/project/gcc/list/?series=199783)

PR c++/55227

gcc/cp/ChangeLog:

* decl.cc (reshape_init_r): Only call has_designator_check when
first_initializer_p or for the inner constructor element.
(cp_complete_array_type): Call reshape_init on braced-init-list.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/desig21.C: New test.

[aarch64/64821]: Simplify __builtin_aarch64_sqrt* into internal function .SQRT.

This is a simple patch which simplifies the __builtin_aarch64_sqrt* builtins
into the internal function SQRT which allows for constant folding and other
optimizations at the gimple level. It was originally suggested we do to
__builtin_sqrt just for __builtin_aarch64_sqrtdf when -fno-math-errno
but since r6-4969-g686ee9719a4 we have the internal function SQRT which does
the same so it makes we don't need to check -fno-math-errno either now.

Applied as approved after bootstrapped and tested on aarch64-linux-gnu with no regressions.

PR target/64821

gcc/ChangeLog:

* config/aarch64/aarch64-builtins.cc
(aarch64_general_gimple_fold_builtin): Handle
__builtin_aarch64_sqrt* and simplify into SQRT internal
function.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/vsqrt-1.c: New test.
* gcc.target/aarch64/vsqrt-2.c: New test.

contrib: filter out one more Clang warning.

contrib/ChangeLog:

* filter-clang-warnings.py: Filter out one another warning
for sse.md.

c++: array temporary at file scope [PR104182]

This is the same issue as PR104031, but that patch doesn't fix this
testcase because in this case, current_function_decl isn't set when we get
to cp_genericize_target_expr.  But there seems to be no need for
is_local_temp to check for function scope; !TREE_STATIC should be enough.

PR c++/104182

gcc/cp/ChangeLog:

* cp-gimplify.cc (cp_genericize_target_expr): Make sure nothing
has set DECL_INITIAL on a TARGET_EXPR slot.
* tree.cc (is_local_temp): Don't check DECL_CONTEXT.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist127.C: New test.

c++: constexpr and -fno-elide-constructors [PR101072]

We've been trying for a while to avoid TARGET_EXPRs in template code, but
there were still a few that snuck through, and the one in this case broke
the code that tried to handle it.  Fixed by using IMPLICIT_CONV_EXPR, as we
have done elsewhere.

I also noticed that finish_compound_literal was assuming that all T{init}
were for aggregate T, and we got a few more TARGET_EXPRs from that.  Fixed
by only messing with TARGET_EXPR if we actually have an aggregate init.

PR c++/101072

gcc/cp/ChangeLog:

* cp-tree.h (build_implicit_conv_flags): Declare.
* call.cc (build_implicit_conv_flags): Split out from...
(perform_implicit_conversion_flags): ...here.
* decl.cc (check_initializer): Use it.
* pt.cc (tsubst_copy_and_build): Remove TARGET_EXPR handling.
* semantics.cc (finish_compound_literal): Don't treat
scalar values like CONSTRUCTORs.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-empty14a.C: New test.

Daily bump.

ootstrap: Fix bootstrap with --disable-plugin [PR104176]

With --disable-plugin, bootstrap fails on x86_64-linux or probably
all other targets with:
../../gcc/opts-global.cc: In function ‘void handle_common_deferred_options()’:
../../gcc/opts-global.cc:420:62: error: unquoted option name ‘--enable-plugin’ in format [-Werror=format-diag]
  420 |           error ("plugin support is disabled; configure with --enable-plugin");
      |                                                              ^~~~~~~~~~~~~~~
../../gcc/opts-global.cc:428:62: error: unquoted option name ‘--enable-plugin’ in format [-Werror=format-diag]
  428 |           error ("plugin support is disabled; configure with --enable-plugin");
      |                                                              ^~~~~~~~~~~~~~~

The following patch fixes that.

2022-01-22  Jakub Jelinek  <jakub@redhat.com>

PR other/104176
* opts-global.cc (handle_common_deferred_options): Quote
--enable-plugin in diagnostics to avoid -Werror=format-diag.

testsuite: guard usage of _Float16 in analyzer test [PR104150]

gcc/testsuite/ChangeLog:
PR analyzer/104150
* gcc.dg/analyzer/pr104089.c: Add "dg-add-options float16"
and "dg-require-effective-target float16" directives.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

analyzer: fix ICE on vector casts [PR104159]

PR analyzer/104159 describes an ICE attempting to convert a vector_cst,
which occurs when symbolically executing within a recursive call on:

  _4 = BIT_FIELD_REF <w_3(D), 32, 0>;
  _1 = VIEW_CONVERT_EXPR<T>(_4);

where the BIT_FIELD_REF leads to a get_or_create_cast from
  VEC<long, 8> to VEC<unsigned 4>
which get_code_for_cast erroneously picks NOP_EXPR for the cast, leading
to a bogus input to the VIEW_CONVERT_EXPR.

This patch fixes the issue by giving up on attempts to cast symbolic
values of vector types, treating the result of such casts as unknowable.

gcc/analyzer/ChangeLog:
PR analyzer/104159
* region-model-manager.cc
(region_model_manager::get_or_create_cast): Bail out if the types
are the same.  Don't attempt to handle casts involving vector
types.

gcc/testsuite/ChangeLog:
PR analyzer/104159
* gcc.dg/analyzer/torture/pr104159.c: New test.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

Fortran: fix simplification of TRANSFER for zero-sized character array result

gcc/fortran/ChangeLog:

PR fortran/104127
* simplify.cc (gfc_simplify_transfer): Ensure that the result
typespec is set up for TRANSFER with MOLD of type CHARACTER
including character length even if the result is a zero-sized
array.

gcc/testsuite/ChangeLog:

PR fortran/104127
* gfortran.dg/transfer_simplify_11.f90: Fix logic.
* gfortran.dg/transfer_simplify_13.f90: New test.

toplevel: Remove accedentally checked in file

This has been added in r12-6342-ge7a7dbb5ca5dd69689f1a probably
by accident.

2022-01-22  Jakub Jelinek  <jakub@redhat.com>

PR other/104181
* build.log: Remove.

Fix fold-vec-splat-floatdouble testsuite failure on power10

When I added support for generating XXSPLTIDP on December 15th, 2021, I
missed updating the fold-vec-splat-floatdouble.c test to add to the regex
for the instructions generated.  This patch fixes that.

2022-01-20  Michael Meissner  <meissner@the-meissners.org>

gcc/testsuite/

PR testsuite/103763
* gcc.target/powerpc/fold-vec-splat-floatdouble.c: Fix insn regex
on power10.

Daily bump.

Mark XXSPLTIW/XXSPLTIDP as prefixed -- PR 104136

If you compile module_advect_em.F90 with -Ofast -mcpu=power10, one module
is large enough that we can't use a single conditional jump to span the
function.  Instead, GCC has to reverse the condition, and do a conditional
jump around an unconditional branch.  It turns out when xxspltiw and
xxspltdp instructions were generated, they were not marked as being
prefixed (i.e. length of 12 bytes instead of 4 bytes).  This meant the
calculations for the branch length were off, which in turn meant the
assembler raised an error because it couldn't do the conditional jump.

The fix is to explicitly set the prefixed attribute when we are loading up
vector constants with the xxspltiw or xxspltidp instructions.

I have removed the code that sets the prefixed attribute for xxspltiw,
xxspltidp, and xxsplti32dx instructions, since it no longer will be invoked.

I have also explicitly set the prefixed attribute for load SF and DF mode
constants with xxsplitw and xxspltidp.  Previously, it was not set on these
insns, but when the insn was split to get the XXSPLTIW/XXSPLTIDP forms, those
forms already had the prefixed attribute set.

2022-01-21  Michael Meissner  <meissner@the-meissners.org>

gcc/
PR target/104136
* config/rs6000/rs6000-protos.h (prefixed_xxsplti_p): Delete.
* config/rs6000/rs6000.cc (prefixed_xxsplti_p): Delete.
* config/rs6000/rs6000.md (prefixed attribute): Delete section
that sets the prefixed attribute for xxspltiw, xxspltidp, and
xxsplti32dx instructions.
(movsf_hardfloat): Explicitly set the prefixed attribute
when xxspltiw and xxspltidp instructions are generated.
(mov<mode>_hardfloat32): Likewise.
(mov<mode>_hardfloat64): Likewise.
* config/rs6000/vsx.md (vsx_mov<mode>_64bit): Explicitly set the
prefixed attribute for xxspltiw and xxspltidp instructions.
(vsx_mov<mode>_32bit): Likewise.

x86: Properly disable -fsplit-stack support on non-glibc targets

Revert x86 changes in

commit c163647ffbc9a20c8feb6e079dbecccfe016c82e
Author: Soren Tempel <soeren@soeren-tempel.net>
Date:   Fri Jan 21 19:22:46 2022 +0000

    Disable -fsplit-stack support on non-glibc targets

and change ix86_supports_split_stack to return true only on glibc.

PR bootstrap/104170
* common/config/i386/i386-common.cc (ix86_supports_split_stack):
Return true only on glibc.
* config/i386/gnu-user-common.h (STACK_CHECK_STATIC_BUILTIN):
Revert commit c163647ffbc.
* config/i386/gnu.h (TARGET_LIBC_PROVIDES_SSP): Likewise.

c-family: Fix up a -Wformat regression [PR104148]

As can be seen on the testcase, GCC 11 no longer warns if the format
string is wrapped inside of ()s.
This regressed with r11-2457-gdf5cf47a978, which added
if (TREE_NO_WARNING (param)) return;
to check_function_arguments_recurse.  That function is used with a callback
for two cases, for -Wformat and for -Wnonnull.  For the latter it is
desirable to not warn in parameters or their subexpressions where that
warning is suppressed, but for -Wformat the function is used solely
to discover the string literals if any so that the c-format.cc code can
diagnose them.  I believe no warning suppression should stand in the
way of that, -Wformat* warnings should be decided from warning suppression
on the CALL_EXPR only.
In the PR Martin argued that now that we have specialized
warning_suppressed_p we should use it, so instead of adding a bool
arg to check_function_arguments_recurse I've added opt_code to the
function, but will defer the warning_suppressed_p change to him.
For OPT_Wformat_ we don't want to call it anyway at all (as I said,
I think there should be no suppression for it during the string discovery,
there isn't just one -Wformat= option, there are many and
warning_suppression_p even with no_warnings actually tests the
TREE_NO_WARNING bit).
Initially, I thought I'd restrict also call to fn with format_arg attribute
handling in check_function_arguments_recurse to OPT_Wformat_ only, but
after looking around, it perhaps is intentional that way, most functions
with format_arg attribute don't have nonnull attribute for that arg too,
various gettext implementations handle NULL argument by passing it through,
but when result of gettext (NULL) etc. is passed to non-NULL argument, it
makes sense to warn.

2022-01-21  Jakub Jelinek  <jakub@redhat.com>

PR c++/104148
* c-common.h (check_function_arguments_recurse): Add for_format
arg.
* c-common.cc (check_function_nonnull): Pass false to
check_function_arguments_recurse's last argument.
(check_function_arguments_recurse): Add for_format argument,
if true, don't stop on warning_suppressed_p.
* c-format.cc (check_format_info): Pass true to
check_function_arguments_recurse's last argument.

* c-c++-common/Wformat-pr104148.c: New test.

c++: explain failing static_assert

While looking at another bug I wanted the compiler to tell me what the two
unequal values were.

gcc/cp/ChangeLog:

* semantics.cc (find_failing_clause): Return expr if not
decomposable.
(finish_static_assert): Show constant values in failing
comparison.

gcc/testsuite/ChangeLog:

* g++.dg/template/explicit-args6.C: Add expected message.

c++: class array new checking [PR104084]

My patch for PR20040 made us stop exiting early from build_new_1 in
cases of trivial initialization if there's a class operator delete; as a
result, code later in the function needs to handle this case properly.

PR c++/104084
PR c++/20040

gcc/cp/ChangeLog:

* init.cc (build_new_1): Only pull out TARGET_EXPR_INITIAL if
alloc_expr is a TARGET_EXPR.

gcc/testsuite/ChangeLog:

* g++.dg/init/new50.C: New test.

Disable -fsplit-stack support on non-glibc targets

The -fsplit-stack option requires the pthread_t TCB definition in the
libc to provide certain struct fields at specific hardcoded offsets. As
far as I know, only glibc provides these fields at the required offsets.
Most notably, musl libc does not have these fields. However, since gcc
accesses the fields using a fixed offset, this does not cause a
compile-time error, but instead results in a silent memory corruption at
run-time with musl libc. For example, on s390x libgcc's
__stack_split_initialize CTOR will overwrite the cancel field in the
pthread_t TCB on musl.

The -fsplit-stack option is used within the gcc code base itself by
gcc-go (if available). On musl-based systems with split-stack support
(i.e. s390x or x86) this causes Go programs compiled with gcc-go to
misbehave at run-time.

This patch fixes gcc-go on musl by disabling -fsplit-stack in gcc itself
since it is not supported on non-glibc targets anyhow. This is achieved
by checking if gcc targets a glibc-based system. This check has been
added for x86 and s390x, the rs6000 config already checks for
TARGET_GLIBC_MAJOR. Other architectures do not have split-stack
support. With this patch applied, the gcc-go configure script will
detect that -fsplit-stack support is not available and will not use it.

See https://www.openwall.com/lists/musl/2012/10/16/12

This patch was written under the assumption that glibc is the only libc
implementation which supports the required fields at the required
offsets in the pthread_t TCB. The patch has been tested on Alpine Linux
Edge on the s390x and x86 architectures by bootstrapping Google's Go
implementation with gcc-go.

Signed-off-by: Sören Tempel <soeren@soeren-tempel.net>
gcc/ChangeLog:

* common/config/s390/s390-common.cc (s390_supports_split_stack):
Only support split-stack on glibc targets.
* config/i386/gnu-user-common.h (STACK_CHECK_STATIC_BUILTIN): Ditto.
* config/i386/gnu.h (defined): Ditto.

rs6000: Support vector float/double for vec_sldw

2022-01-21  Bill Schmidt  <wschmidt@linux.ibm.com>

gcc/
* config/rs6000/rs6000-overload.def (VEC_SLDW): Add instances for
vector float and vector double.

gcc/testsuite/
* gcc.target/powerpc/builtins-4.c: Add two test variants.  Adjust
assembler counts.

rs6000: Fix bootstrap

Fix a compilation issue in stage2 bootstrap.  Fixed as obvious (re:
discussion with Bill Schmidt).

2022-01-21  Bill Seurer  <seurer@gcc.gnu.org>

gcc/
* config/rs6000/rs6000.cc (rs6000_get_function_versions_dispatcher):
Fix mention of ifunc in string.

PR middle-end/104140: bootstrap ICE on riscv.

This patch resolves the P1 "ice-on-valid-code" regression boostrapping
GCC on risv-unknown-linux-gnu caused by my recent MULT_HIGHPART_EXPR
functionality.  RISC-V differs from x86_64 and many targets by
supporting a usmusidi3 instruction, basically a widening multiply
where one operand is signed and the other is unsigned.  Alas the
final version of my patch to recognize MULT_HIGHPART_EXPR didn't
sufficiently defend against the operands of WIDEN_MULT_EXPR having
different signedness.  This is fixed by the two-line change to
tree-ssa-math-opts.cc's convert_mult_to_highpart in the patch below.

The majority of the rest of the patch is to the documentation
(in tree.def and generic.texi).  It turns out that WIDEN_MULT_EXPR
wasn't previously documented in generic.texi, let alone the slightly
unusual semantics of allowing mismatched (signed vs unsigned) operands.
This also clarifies that MULT_HIGHPART_EXPR currently requires the
signedness of operands to match [but this might change in a future
release of GCC to support targets with usmul<mode>3_highpart].

The one final chunk of this patch (that is hopefully sufficiently
close to obvious for stage 4) is a similar (NULL pointer) sanity
check in riscv_cpu_cpp_builtins.  Currently running cc1 from the
command line (or from gdb) without specifying -march results in a
segmentation fault (ICE).  This is a minor annoyance tracking down
issues (in cross compilers) for riscv, and trivially fixed as below.

2022-01-22  Roger Sayle  <roger@nextmovesoftware.com>

gcc/ChangeLog
PR middle-end/104140
* tree-ssa-math-opts.cc (convert_mult_to_highpart): Check that the
operands of the widening multiplication are either both signed or
both unsigned, and abort the conversion if mismatched.
* doc/generic.texi (WIDEN_MULT_EXPR): Describe expression node.
(MULT_HIGHPART_EXPR): Clarify that operands must have the same
signedness.
* tree.def (MULT_HIGHPART_EXPR): Document both operands must have
integer types with the same precision and signedness.
(WIDEN_MULT_EXPR): Document that operands must have integer types
with the same precision, but possibly differing signedness.
* config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins): Defend against
riscv_current_subset_list returning a NULL pointer (empty list).

gcc/testsuite/ChangeLog
PR middle-end/104140
* gcc.target/riscv/pr104140.c: New test case.

[PR103676] LRA: Calculate and exclude some start hard registers for reload pseudos

LRA and old reload pass uses only one register class for reload pseudos even if
operand constraints contain more one register class.  Let us consider
constraint 'lh' for thumb arm which means low and high thumb registers.
Reload pseudo for such constraint will have general reg class (union of
low and high reg classes).  Assigning the last low register to the reload
pseudo is wrong if the pseudo is of DImode as it requires two hard regs.
But it is considered OK if we use general reg class.  The following patch
solves this problem for LRA.

gcc/ChangeLog:

PR target/103676
* ira.h (struct target_ira): Add member
x_ira_exclude_class_mode_regs.
(ira_exclude_class_mode_regs): New macro.
* lra.h (lra_create_new_reg): Add arg exclude_start_hard_regs and
move from here ...
* lra-int.h: ... to here.
(lra_create_new_reg_with_unique_value): Add arg
exclude_start_hard_regs.
(class lra_reg): Add member exclude_start_hard_regs.
* lra-assigns.cc (find_hard_regno_for_1): Setup
impossible_start_hard_regs from exclude_start_hard_regs.
* lra-constraints.cc (get_reload_reg): Add arg exclude_start_hard_regs and pass
it lra_create_new_reg[_with_unique_value].
(match_reload): Ditto.
(check_and_process_move): Pass NULL
exclude_start_hard_regs to lra_create_new_reg_with_unique_value.
(goal_alt_exclude_start_hard_regs): New static variable.
(process_addr_reg, simplify_operand_subreg): Pass NULL
exclude_start_hard_regs to lra_create_new_reg_with_unique_value
and get_reload_reg.
(process_alt_operands): Setup goal_alt_exclude_start_hard_regs.
Use this_alternative_exclude_start_hard_regs additionally to find
winning operand alternative.
(base_to_reg, base_plus_disp_to_reg, index_part_to_reg): Pass NULL
exclude_start_hard_regs to lra_create_new_reg.
(process_address_1, emit_inc): Ditto.
(curr_insn_transform): Pass exclude_start_hard_regs value to
lra_create_new_reg, get_reload_reg, match_reload.
(inherit_reload_reg, split_reg): Pass NULL exclude_start_hard_regs
to lra_create_new_reg.
(process_invariant_for_inheritance): Ditto.
* lra-remat.cc (update_scratch_ops): Ditto.
* lra.cc (lra_create_new_reg_with_unique_value): Add arg
exclude_start_hard_regs.  Setup the corresponding member of
lra reg info.
(lra_create_new_reg): Add arg exclude_start_hard_regs and pass it
to lra_create_new_reg_with_unique_value.
(initialize_lra_reg_info_element): Initialize member
exclude_start_hard_regs.
(get_scratch_reg): Pass NULL to lra_create_new_reg.
* ira.cc (setup_prohibited_class_mode_regs): Rename to
setup_prohibited_and_exclude_class_mode_regs and calculate
ira_exclude_class_mode_regs.

gcc/testsuite/ChangeLog:

PR target/103676
* g++.target/arm/pr103676.C: New.

c++: ICE with noexcept and canonical types [PR101715]

This is a "canonical types differ for identical types" ICE, which started
with r11-4682.  It's a bit tricky to explain.  Consider:

  template <typename T> struct S {
    S<T> bar() noexcept(T::value);  // #1
    S<T> foo() noexcept(T::value);  // #2
  };

  template <typename T> S<T> S<T>::foo() noexcept(T::value) {}  // #3

We ICE because #3 and #2 have the same type, but their canonical types
differ: TYPE_CANONICAL (#3) == #2 but TYPE_CANONICAL (#2) == #1.

The member functions #1 and #2 have the same type.  However, since their
noexcept-specifier is deferred, when parsing them, we create a variant for
both of them, because DEFERRED_PARSE cannot be compared.  In other words,
build_cp_fntype_variant's

  tree v = TYPE_MAIN_VARIANT (type);
  for (; v; v = TYPE_NEXT_VARIANT (v))
    if (cp_check_qualified_type (v, type, type_quals, rqual, raises, late))
      return v;

will *not* find an existing variant when creating a method_type for #2, so we
have to create a new one.

But then we perform delayed parsing and call fixup_deferred_exception_variants
for #1 and #2.  f_d_e_v will replace TYPE_RAISES_EXCEPTIONS with the newly
parsed noexcept-specifier.  It also sets TYPE_CANONICAL (#2) to #1.  Both
noexcepts turned out to be the same, so now we have two equivalent variants in
the list!  I.e.,

+-----------------+      +-----------------+      +-----------------+
|      main       |      |      #2         |      |      #1         |
| S S::<T379>(S*) |----->| S S::<T37c>(S*) |----->| S S::<T37a>(S*) |----->NULL
|    -            |      |  noex(T::value) |      |  noex(T::value) |
+-----------------+      +-----------------+      +-----------------+

Then we get to #3.  As for #1 and #2, grokdeclarator calls build_memfn_type,
which ends up calling build_cp_fntype_variant, which will use the loop
above to look for an existing variant.  The first one that matches
cp_check_qualified_type will be used, so we use #2 rather than #1, and the
TYPE_CANONICAL mismatch follows.  Hopefully that makes sense.

As for the fix, I didn't think I could rewrite the method_type #2 with #1
because the type may have escaped via decltype.  So my approach is to
elide #2 from the list, so when looking for a matching variant, we always
find #1 (#2 remains live though, which admittedly sounds sort of dodgy).

PR c++/101715

gcc/cp/ChangeLog:

* tree.cc (fixup_deferred_exception_variants): Remove duplicate
variants after parsing the exception specifications.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/noexcept72.C: New test.
* g++.dg/cpp0x/noexcept73.C: New test.

Strengthen a few OpenACC test cases

Rather than rubber-stamp whatever requested vs. actual device kernel launch
configuration happens, actually (again) verify the requested values (modulo
expected variations).

This better highlights that "AMD GCN has an upper limit of 'num_workers(16)'",
and the deficiency that "AMD GCN uses the autovectorizer for the vector
dimension: the use of a function call in vector-partitioned code [...] is not
currently supported".

And, this removes several instances of race conditions, where variables are
concurrently written to in OpenACC gang-redundant mode.

libgomp/
* testsuite/libgomp.oacc-c-c++-common/loop-gwv-1.c: Strengthen.
* testsuite/libgomp.oacc-c-c++-common/loop-gwv-2.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/loop-red-gwv-1.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/loop-red-v-1.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/loop-red-v-2.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/loop-red-w-1.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/loop-red-w-2.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/loop-red-wv-1.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/loop-v-1.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/loop-w-1.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/loop-wv-1.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/routine-gwv-1.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/routine-v-1.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/routine-w-1.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/routine-wv-1.c: Likewise.

c++: [[no_unique_address]] and virtual base [PR104139]

Fixing a thinko in my patch for 103681: when computing the size of a virtual
base, it would help to use its binfo instead of the one for the derived
class.

PR c++/104139
PR c++/103681

gcc/cp/ChangeLog:

* class.cc (end_of_class): Use base_binfo.

gcc/testsuite/ChangeLog:

* g++.dg/abi/no_unique_address2.C: Adjust to detect this on x86-64.

libstdc++: Fix typo in comment

libstdc++-v3/ChangeLog:

* testsuite/20_util/shared_ptr/cons/array.cc: Fix comment.

libstdc++: Ensure all feature test macros have type long [PR87193]

This defines all the __cpp_lib_xxx macros as type long, as required by
the standard. We had an inconsistent mix of int and long, sometimes even
for the same macro name.

The __cpp_lib_experimental_xxx macros are left as type int, because
that's what it says in the relevant TS specs.

libstdc++-v3/ChangeLog:

PR libstdc++/87193
PR libstdc++/104019
* include/bits/alloc_traits.h (__cpp_lib_allocator_traits_is_always_equal):
Define as type long.
* include/bits/allocator.h (__cpp_lib_incomplete_container_elements):
Likewise.
* include/bits/basic_string.h (__cpp_lib_string_udls): Likewise.
* include/bits/chrono.h (__cpp_lib_chrono): Likewise.
(__cpp_lib_chrono_udls): Likewise.
* include/bits/move.h (__cpp_lib_addressof_constexpr): Likewise.
* include/bits/node_handle.h (__cpp_lib_node_extract): Likewise.
* include/bits/range_access.h (__cpp_lib_nonmember_container_access):
Likewise.
* include/bits/shared_ptr.h (__cpp_lib_enable_shared_from_this):
Likewise.
* include/bits/stl_algo.h (__cpp_lib_clamp): Likewise.
(__cpp_lib_sample): Likewise.
* include/bits/stl_algobase.h (__cpp_lib_robust_nonmodifying_seq_ops):
Likewise.
* include/bits/stl_function.h (__cpp_lib_transparent_operators):
Likewise.
* include/bits/stl_iterator.h (__cpp_lib_make_reverse_iterator):
Likewise.
* include/bits/stl_map.h (__cpp_lib_map_try_emplace):
Likewise.
* include/bits/stl_tree.h (__cpp_lib_generic_associative_lookup):
Likewise.
* include/bits/unique_ptr.h (__cpp_lib_make_unique):
Likewise.
* include/bits/unordered_map.h (__cpp_lib_unordered_map_try_emplace):
Likewise.
* include/c_global/cmath (__cpp_lib_hypot): Likewise.
* include/c_global/cstddef (__cpp_lib_byte): Likewise.
* include/std/atomic (__cpp_lib_atomic_is_always_lock_free):
Likewise.
* include/std/complex (__cpp_lib_complex_udls): Likewise.
* include/std/filesystem (__cpp_lib_filesystem): Likewise.
* include/std/functional (__cpp_lib_not_fn): Likewise.
(__cpp_lib_boyer_moore_searcher): Likewise.
* include/std/iomanip (__cpp_lib_quoted_string_io): Likewise.
* include/std/mutex (__cpp_lib_scoped_lock): Likewise.
* include/std/numeric (__cpp_lib_gcd_lcm): Likewise.
(__cpp_lib_gcd, __cpp_lib_lcm): Likewise.
* include/std/tuple (__cpp_lib_apply): Likewise.
(__cpp_lib_make_from_tuple): Likewise.
* include/std/type_traits (__cpp_lib_integral_constant_callable)
(__cpp_lib_bool_constant, __cpp_lib_logical_traits)
(__cpp_lib_is_null_pointer, __cpp_lib_transformation_trait_aliases)
(__cpp_lib_result_of_sfinae, __cpp_lib_void_t)
(__cpp_lib_is_swappable, __cpp_lib_is_invocable)
(__cpp_lib_has_unique_object_representations)
(__cpp_lib_is_aggregate): Likewise.
* include/std/version: Likewise.
* libsupc++/new (__cpp_lib_launder): Likewise.

libstdc++: Fix condition for __cpp_lib_shared_ptr_arrays

I changed the preprocessor condition from <= to < in r12-6574 which
meant the macro was not defined by <version> for C++17.

libstdc++-v3/ChangeLog:

* include/std/version (__cpp_lib_shared_ptr_arrays): Fix
condition for C++17 definition.

Enable configure detection of ld.mold.

gcc/ChangeLog:

* configure.ac: Detect ld_is_mold and use it for
comdat_group=yes and gcc_cv_ld_hidden=yes.
* configure: Regenerate.

tree-optimization/100089 - BB vectorization of if-converted loop bodies

The PR complains that when we only partially BB vectorize an
if-converted loop body that this can leave unvectorized code
unconditionally executed and thus effectively slow down code.
For -O2 we already mitigated the issue by not doing BB vectorization
when not all if-converted stmts were covered but the issue is
present with -O3 as well.  Thus the following simply extends the
fix to cover all but the unlimited cost models.  It is after all
very likely that we vectorize some stmts, if only a single
paired store.

2022-01-21  Richard Biener  <rguenther@suse.de>

PR tree-optimization/100089
* tree-vect-slp.cc (vect_slp_region): Reject BB vectorization
of if-converted loops with unvectorized COND_EXPRs for
all but the unlimited cost models.

libstdc++: Fix constexpr constructor for atomic<shared_ptr<T>>

libstdc++-v3/ChangeLog:

* include/bits/shared_ptr_atomic.h (_Sp_atomic::_Atomic_count):
Add constexpr.
(_Sp_atomic::_M_ptr): Add default member-initializer.
* testsuite/20_util/shared_ptr/atomic/atomic_shared_ptr.cc:
Check constant initialization.
* testsuite/20_util/weak_ptr/atomic_weak_ptr.cc: Likewise.

sanitizer/99673 - bad -Wstringop-overread diagnostic with asan

The testcase got fixed by lowering of &MEM[ptr + CST] to ptr + CST.

2022-01-21  Richard Biener  <rguenther@suse.de>

PR sanitizer/99673
* gcc.dg/asan/pr99673.c: New testcase.

[ARM] Add support for TLS register based stack protector canary access

Add support for accessing the stack canary value via the TLS register,
so that multiple threads running in the same address space can use
distinct canary values. This is intended for the Linux kernel running in
SMP mode, where processes entering the kernel are essentially threads
running the same program concurrently: using a global variable for the
canary in that context is problematic because it can never be rotated,
and so the OS is forced to use the same value as long as it remains up.

Using the TLS register to index the stack canary helps with this, as it
allows each CPU to context switch the TLS register along with the rest
of the process, permitting each process to use its own value for the
stack canary.

gcc/ChangeLog:

* config/arm/arm-opts.h (enum stack_protector_guard): New.
* config/arm/arm-protos.h (arm_stack_protect_tls_canary_mem):
New.
* config/arm/arm.cc (TARGET_STACK_PROTECT_GUARD): Define.
(arm_option_override_internal): Handle and put in error checks.
for stack protector guard options.
(arm_option_reconfigure_globals): Likewise.
(arm_stack_protect_tls_canary_mem): New.
(arm_stack_protect_guard): New.
* config/arm/arm.md (stack_protect_set): New.
(stack_protect_set_tls): Likewise.
(stack_protect_test): Likewise.
(stack_protect_test_tls): Likewise.
(reload_tp_hard): Likewise.
* config/arm/arm.opt (-mstack-protector-guard): New
(-mstack-protector-guard-offset): New.
* doc/invoke.texi: Document new options.

gcc/testsuite/ChangeLog:

* gcc.target/arm/stack-protector-7.c: New test.
* gcc.target/arm/stack-protector-8.c: New test.

aarch64: Adjust spellcheck tests for recent quotation-mark changes

Adjust tests for quotation-mark and punctuation changes.

gcc/testsuite:

* gcc.target/aarch64/spellcheck_1.c: Adjust tests for new output.
* gcc.target/aarch64/spellcheck_2.c: Likewise.
* gcc.target/aarch64/spellcheck_3.c: Likewise.
* gcc.target/aarch64/spellcheck_7.c: Likewise.

tree-optimization/104156 - fix unswitching compare-debug issue

When hoisting guards the unswitching pass does not properly ignore
debug stmts when looking for uses outside of the loop of defs
produced in the skipped region.  The following rectifies this
by instead collecting them and resetting them after the transform.

2022-01-21  Richard Biener  <rguenther@suse.de>

PR tree-optimization/104156
* tree-ssa-loop-unswitch.cc (tree_unswitch_outer_loop):
Collect and reset debug stmts with out-of-loop uses when
hoisting guards.
(find_loop_guard): Adjust.
(empty_bb_without_guard_p): Likewise.  Ignore debug stmts.
(used_outside_loop_p): Push debug uses to a vector of
debug stmts to reset.
(hoist_guard): Adjust -fopt-info category.

* gcc.dg/loop-unswitch-6.c: New testcase.

tree-optimization/104152 - add missing check for SLP constant build

This adds a missing check to verify we can actually build an
invariant vector from components when SLP vectorizing an associatable
chain.

2022-01-21  Richard Biener  <rguenther@suse.de>

PR tree-optimization/104152
* tree-vect-slp.cc (vect_build_slp_tree_2): Add missing
can_duplicate_and_interleave_p check.

* gcc.dg/vect/pr104152.c: New testcase.

warn-access: Fix up warning_at arguments

A warning regression fix I'm about to post warns (and breaks bootstrap due
to that) on the following spot.  Seems it is a copy and paste from
earlier code that mentions the %qD variable instead of talking about
unnamed temporary.

2022-01-21  Jakub Jelinek  <jakub@redhat.com>

* gimple-ssa-warn-access.cc (pass_waccess::warn_invalid_pointer):
Avoid passing var to warning_at when the format string doesn't
refer to it.

Reset relations when crossing backedges.

As discussed in PR103721, the problem here is that we are crossing a
backedge and causing us to use relations from a previous iteration of a
loop.

This handles the testcases in both PR103721 and PR104067 which are variants
of the same thing.

Tested on x86-64 Linux with the usual regstrap as well as verifying the
thread count before and after the patch.  The number of threads is
reduced by a miniscule amount.

gcc/ChangeLog:

PR tree-optimization/103721
* gimple-range-path.cc
(path_range_query::relations_may_be_invalidated): New.
(path_range_query::compute_ranges_in_block): Reset relations if
they may be invalidated.
(path_range_query::maybe_register_phi_relation): Exit if relations
may be invalidated on incoming edge.
(path_range_query::compute_phi_relations): Pass incoming PHI edge
to maybe_register_phi_relation.
* gimple-range-path.h (relations_may_be_invalidated): New.
(maybe_register_phi_relation): Pass edge instead of tree.
* tree-ssa-threadbackward.cc (back_threader::back_threader):
Mark DFS edges.
* value-relation.cc (path_oracle::path_oracle): Call
mark_dfs_back_edges.
(path_oracle::register_relation): Add SSA names to m_registered
bitmap.
(path_oracle::reset_path): Clear m_registered bitmap.
* value-relation.h (path_oracle::set_root_oracle): New.

gcc/testsuite/ChangeLog:

* gcc.dg/pr103721-2.c: New test.
* gcc.dg/pr103721.c: New test.

optabs: Don't create pseudos in prepare_cmp_insn when not allowed [PR102478]

cond traps can be created during ce3 after reload (and e.g. PR103028
recently fixed some ce3 cond trap related bug, so I think often that
works fine and we shouldn't disable cond traps after RA altogether),
but it calls prepare_cmp_insn.  This function can fail, so I don't
see why we couldn't make it work after RA (in most cases it already
just works).  The first hunk is just an optimization which doesn't
make sense after RA, so I've guarded it with can_create_pseudo_p.
The second hunk is just a theoretical case, I don't have a testcase for it.
prepare_cmp_insn has some other spots that can create pseudos, like when
both operands have VOIDmode, or when it is BLKmode comparison, or
not OPTAB_DIRECT, but I think none of that applies to ce3, we punt on
BLKmode earlier, use OPTAB_DIRECT and shouldn't be comparing two
VOIDmode CONST_INTs.

2022-01-21  Jakub Jelinek  <jakub@redhat.com>

PR rtl-optimization/102478
* optabs.cc (prepare_cmp_insn): If !can_create_pseudo_p (), don't
force_reg constants and for -fnon-call-exceptions fail if copy_to_reg
would be needed.

* gcc.dg/pr102478.c: New test.

[committed] Fix expected output for various MIPS multiplication tests

The recent multiply-highpart work twiddled code generation on the MIPS targets
and is causing mips.exp failures.

The resultant code is actually better and matches a comment in the test files
which indicates that it would be better to generate a mult-highpart.  So I'm
pretty confident in removing the undesired mflo & changing the name of the
target pattern we expect to see.

This fixes the mips64 and mips64el failures in my tester.  I suspect it'll
also fix the failures on mipsisa32, but that target is bootstrapped with qemu --
which takes forever so it only runs once a week ;-)

gcc/testsuite
* gcc.target/mips/fix-r4000-2.c: Update expected output.
* gcc.target/mips/fix-r4000-3.c: Update expected output.  Add
-fexpensive-optimizations for consistency in output.
* gcc.target/mips/fix-r4000-7.c: Update expected output.
* gcc.target/mips/fix-r4000-8.c: Update expected output.

runtime: build panic32.go on amd64p32

Fixes https://gcc.gnu.org/PR104149

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/380054

Daily bump.

analyzer: reject ((i + 1 > 0) && (i < 0)) for integers [PR94362]

PR analyzer/94362 reports a false positive from
-Wanalyzer-null-dereference seen when analyzing OpenSSL.

The root cause is that the analyzer's path feasibility checker
erroneously considers this to be feasible:
  (R + 1 > 0) && (R < 0)
for int R (the return value from sk_EVP_PKEY_ASN1_METHOD_num),
whereas it's not satisfiable for any int R.

This patch makes the constraint manager try harder to reject
such combinations of conditions, fixing the false positive;
perhaps in the longer term we ought to use an SMT solver.

gcc/analyzer/ChangeLog:
PR analyzer/94362
* constraint-manager.cc (bound::ensure_closed): Convert param to
enum bound_kind.
(range::constrained_to_single_element): Likewise.
(range::add_bound): New.
(constraint_manager::add_constraint): Handle SVAL + OFFSET
compared to a constant.
(constraint_manager::get_ec_bounds): Rewrite in terms of
range::add_bound.
(constraint_manager::eval_condition): Reject if range::add_bound
fails.
(selftest::test_constant_comparisons): Add test coverage for
various impossible combinations of integer comparisons.
* constraint-manager.h (enum bound_kind): New.
(struct bound): Likewise.
(bound::ensure_closed): Convert to param to enum bound_kind.
(struct range): Convert to...
(class range): ...this, making fields private.
(range::add_bound): New decls.
* region-model.cc (region_model::add_constraint): Fail if
constraint_manager::add_constraint fails.

gcc/testsuite/ChangeLog:
PR analyzer/94362
* gcc.dg/analyzer/pr94362-1.c: New test.
* gcc.dg/analyzer/pr94362-2.c: New test.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

analyzer: add regression test [PR103685]

PR analyzer/103685 reports a false positive from -Wanalyzer-null-dereference
seen at -O2 with GCC 11.  I can reproduce it with GCC 11, but not with
trunk; this patch adds a reduced test case that reproduces it with
GCC 11 as a regression test for GCC 12 onwards.

gcc/testsuite/ChangeLog:
PR analyzer/103685
* gcc.dg/analyzer/torture/pr103685.c: New test.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

Fortran: Fix scope for OMP AFFINITY clause iterator variables [PR103695]

gfc_finish_var_decl was confused by the undocumented overloading of
the proc_name field in struct gfc_namespace to contain iterator
variables for the OpenMP AFFINITY clause, causing it to insert the
decls in the wrong scope.  This patch adds a new distinct field to
hold these variables.

2022-01-20  Sandra Loosemore  <sandra@codesourcery.com>

PR fortran/103695
PR fortran/102621

gcc/fortran
* gfortran.h (struct gfc_namespace) Add omp_affinity_iterator
field.
* dump-parse-tree.cc (show_iterator): Use it.
* openmp.cc (gfc_match_iterator): Likewise.
(resolve_omp_clauses): Likewise.
* trans-decl.cc (gfc_finish_var_decl): Likewise.
* trans-openmp.cc (handle_iterator): Likewise.

gcc/testsuite/
* gfortran.dg/gomp/affinity-clause-3.f90: Adjust pattern.
* gfortran.dg/gomp/pr102621.f90: New.
* gfortran.dg/gomp/pr103695.f90: New.

c++: designator for base class member [PR101405]

A C++20 designator must name a direct non-static member of the class; in
this case it names a member of a base class, and we should give an error
instead of crashing.

PR c++/101405

gcc/cp/ChangeLog:

* decl.cc (reshape_init_class): Reject designator for a member of
another class.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/desig20.C: New test.

c++: Add test for fixed PR [PR102338]

This was fixed by r12-6025 and is sufficiently different from
noexcept71.C that I think we should add it.

PR c++/102338

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/noexcept2.C: New test.

c++: add testcase for recently fixed PR [PR103631]

We accept this testcase after r12-6773.

PR c++/103631

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/nontype-class51.C: New test.

middle-end/100786 - constant folding from incompatible alias

The following avoids us ICEing doing constant folding from variables
with aliases of different types.  The issue appears both in
folding and CCP and FRE can do more fancy stuff to still constant
fold cases where the load is smaller than the initializer so
defer it to there.

2022-01-20  Richard Biener  <rguenther@suse.de>

PR middle-end/100786
* gimple-fold.cc (get_symbol_constant_value): Only return
values of compatible type to the symbol.

* gcc.dg/torture/pr100786.c: New testcase.

 aarch64: allow ld1/stq in test output [PR102517]

Following the changes to the inline memcpy operations get expanded, we
now generate ld1/st1 using a 128-bit vector register rather than ldp
with Q registers.  The behaviour is equivalent, so relax the tests to
permit either variant.

gcc/testsuite/ChangeLog:

PR target/102517
* gcc.target/aarch64/cpymem-q-reg_1.c: Allow ld1 and st1 for the
memcpy expansion.

Only add equivalencies that are still valid.

When equivalencies sets are merged, each member of the set should be queried
to ensure its still valid rather than a bulk union.

* value-relation.cc (relation_oracle::valid_equivs): Query and add
if valid members of a set.
(equiv_oracle::register_equiv): Call valid_equivs rather than
bitmap direct operations.
(path_oracle::register_equiv): Ditto.
* value-relation.h (relation_oracle::valid_equivs): New prototype.

c++: CTAD inside alias template [PR91911, PR103672]

In the first testcase below, when processing the alias template
ConstSpanType, transparency of alias template specializations means we
replace SpanType<T> with its instantiated definition.  But this
instantiation lowers the level of the CTAD placeholder for span{T()} from
2 to 1, and so the later instantiation of ConstSpanType<int> erroneously
substitutes this CTAD placeholder with the template argument at level 1
index 0, i.e. with int, before we get a chance to perform the CTAD.

Although we represent CTAD placeholders as template parameters, we never
actually want to replace them via tsubst.  So this patch adjusts tsubst
to handle CTAD placeholders by simply substituting the template and
returning a new CTAD placeholder.  Moreover, this means that the level
of a CTAD placeholder doesn't matter, so we may as well give them all
the same level.  This patch gives them the special level 0.

The change in tsubst_decl removes a likely dead !CHECKING_P safeguard
added in 2017, which would otherwise now get triggered for variables
with CTAD placeholder types (since their level is 0).

PR c++/91911
PR c++/103672

gcc/cp/ChangeLog:

* pt.cc (keep_template_parm): Punt on a level 0 template parm.
(tsubst_decl) <case VAR_DECL>: Remove !CHECKING_P safeguard.
(tsubst) <case TEMPLATE_TYPE_PARM>: Handle CTAD placeholders
specially.
(make_auto_1): Add defaulted 'level' parameter.
(make_template_placeholder): Pass 0 as 'level' to make_auto_1.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/class-deduction101.C: New test.
* g++.dg/cpp1z/class-deduction101a.C: New test.
* g++.dg/cpp1z/class-deduction101b.C: New test.
* g++.dg/cpp1z/class-deduction102.C: New test.
* g++.dg/cpp1z/class-deduction102a.C: New test.
* g++.dg/cpp1z/class-deduction102b.C: New test.
* g++.dg/cpp1z/class-deduction103.C: New test.

c++: consistently diagnose bare CTAD placeholder in fn return type

Relax slightly the existing check for diagnosing a bare CTAD placeholder
as the return type of a function declarator to also handle the abstract
declarator case.

gcc/cp/ChangeLog:

* decl.cc (grokdeclarator): Diagnose a CTAD placeholder as
function return type even when !funcdecl_p.

gcc/testsuite/ChangeLog:

* g++.dg/other/pr88187.C: Adjust expected C++17 diagnostic.

target/100784 - avoid ICE with folding __builtin_ia32_shufpd

This avoids ICEing when there is no LHS on the call by following
what foldings of other builtins do in , namely not folding.

2022-01-20  Richard Biener  <rguenther@suse.de>

PR target/100784
* config/i386/i386.cc (ix86_gimple_fold_builtin): Check for
LHS before folding __builtin_ia32_shufpd and friends.

MAINTAINERS: adjust requested email address

ChangeLog:

* MAINTAINERS: Adjust email address based on IRC request.

libstdc++: Use Clang attribute instead of __constinit

Clang doesn't support the __constinit extension that we use pre-C++20,
but it does have its own equivalent attribute that can be used instead.

This makes it a little easier to use Clang to build libstdc++ (which
isn't supported. but is sometimes attempted for esoteric targets).

libstdc++-v3/ChangeLog:

* src/c++11/cxx11-ios_failure.cc (__constinit): Define as
equivalent attribute for Clang.
* src/c++11/future.cc (__constinit): Likewise.
* src/c++11/system_error.cc (__constinit): Likewise.
* src/c++17/memory_resource.cc (__constinit): Likewise.

libstdc++: Only add valid -L paths to testsuite linker options

The MacOS linker warns about -L arguments that don't exist, which causes
all tests to fail for the defauly configuration (because libbacktrace
isn't built).

libstdc++-v3/ChangeLog:

* scripts/testsuite_flags.in: Only add src/filesystem/.libs and
src/libbacktrace/.libs to LDFLAGS if those directories exist.

arm: Add test for AES erratum mitigation

Add a testcase for the erratum mitigation.  To improve coverage
use -dp on the assembler output and match the pattern names (and where
needed the alternative number).

gcc/testsuite/ChangeLog:

* gcc.target/arm/crypto-vaese-erratum1.c: New test.

arm: elide some cases where the AES erratum workaround is not required.

Some common cases where the AES erratum workaround are not required
are when there are 64- or 128-bit loads from memory, moving a 128-bit
value from core registers, and where a 128-bit constant is being
loaded from a literal pool.  The loads may also be misaligned or
generated via a neon intrinsic function.

gcc/ChangeLog:

* config/arm/crypto.md (aes_op_protect): Allow moves from core
registers and from memory.
(aes_op_protect_misalign_load): New pattern.
(aes_op_protect_neon_vld1v16qi): New pattern.

arm: suppress aes erratum when forwarding from aes

AES operations are commonly chained and since the result of one AES
operation is never a 32-bit value, they do not need an additional
mitigation instruction for the forwarded result.  We handle this
common case by adding additional patterns that allow for this.

gcc/ChangeLog:

* config/arm/crypto.md (crypto_<CRYPTO_AESMC:crypto_pattern>_protected):
New pattern.
(aarch32_crypto_aese_fused_protected): Likewise.
(aarch32_crypto_aesd_fused_protected): Likewise.

arm: add basic mitigation for Cortex-A AES errata

This patch adds the basic patterns for mitigation of the erratum, but no
attempt is made at this point to optimize the results for the cases where
the erratum mitigation is not needed.

The mitigation is done by guaranteeing that the input operands are fed
from a full-width operation by using an identity operation on the input
values.

gcc/ChangeLog:

* config/arm/crypto.md (crypto_<CRYPTO_AES:crypto_pattern>): Convert
to define_expand.  Add mitigation for the Cortex-A AES erratum
when enabled.
(*crypto_<CRYPTO_AES:crypto_pattern>_insn): New pattern, based
on original crypto_<CRYPTO_AES:crypto_pattern> insn.
(aes_op_protect): New pattern.
* config/arm/unspecs.md (unspec): Add UNSPEC_AES_PROTECT.

arm: Add option for mitigating against Cortex-A CPU erratum for AES

Add a new option -mfix-cortex-a-aes for enabling the Cortex-A AES
erratum work-around and enable it automatically for the affected
products (Cortex-A57 and Cortex-A72).

gcc/ChangeLog:

* config/arm/arm-cpus.in (quirk_aes_1742098): New quirk feature
(ALL_QUIRKS): Add it.
(cortex-a57, cortex-a72): Enable it.
(cortex-a57.cortex-a53, cortex-a72.cortex-a53): Likewise.
* config/arm/arm.opt (mfix-cortex-a57-aes-1742098): New command-line
option.
(mfix-cortex-a72-aes-1655431): New option alias.
* config/arm/arm.cc (arm_option_override): Handle default settings
for AES erratum switch.
* doc/invoke.texi (Arm Options): Document new options.

arm: Consistently use crypto_mode attribute in crypto patterns

A couple of patterns in the crypto support code were hard-coding the
mode rather than using the iterators.  While not incorrect, it was
slightly confusing, so adapt those patterns to the style of the rest
of the file.

Also fix some white space issues.

gcc/ChangeLog:

* config/arm/crypto.md (crypto_<CYRPTO_AES:crypto_pattern>): Use
<crypto_mode> rather than hard-coding the mode.
(crypto_<CRYPTO_AESMC:crypto_pattern>): Fix white space.
(crypto_<CRYPTO_AES:crypto_pattern>): Likewise.
(*aarch32_crypto_aese_fused): Likewise.
(*aarch32_crypto_aesd_fused): Likewise.
(crypto_<CRYPTO_BINARY:crypto_pattern>): Likewise.
(crypto_<CRYPTO_TERNARY:crypto_pattern>): Likewise.
(crypto_sha1h_lb): Likewise.
(crypto_vmullp64): Likewise.
(crypto_<CRYPTO_SELECTING:crypto_pattern>): Likewise.
(crypto_<CRYPTO_SELECTING:crypto_pattern>_lb): Likewise.