c++: var tmpl w/ dependent constrained auto type [PR103341]

When deducing the type of a variable template (or templated static data
member) with a constrained auto type, we might need its template
arguments for satisfaction since the constraint could depend on them.

PR c++/103341

gcc/cp/ChangeLog:

* decl.cc (cp_finish_decl): Pass the template arguments of a
variable template specialization or a templated static data
member to do_auto_deduction when the auto is constrained.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-class4.C: New test.
* g++.dg/cpp2a/concepts-var-templ2.C: New test.

tree-optimization/104267 - fix external def vector type for call args

The following fixes the vector type registered for external defs
in call arguments when vectorizing with SLP.  We assumed uniform
vectype_in types here but with calls like .COND_MUL we also have
mask arguments which, when invariant or external, need to have
a proper mask vector type.

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

PR tree-optimization/104267
* tree-vect-stmts.cc (vectorizable_call): Properly use the
per-argument determined vector type for externals and
invariants.

tree-optimization/104263 - avoid retaining abnormal edges for non-call/goto stmts

This removes a premature optimization from
gimple_purge_dead_abnormal_call_edges which, after eliding the
last setjmp (or computed goto) statement from a function and
thus clearing cfun->calls_setjmp, leaves us with the abnormal
edges from other calls that are elided for example via inlining
or DCE.  That's a CFG / IL combination that should be impossible
(not addressing the fact that with cfun->calls_setjmp and
cfun->has_nonlocal_label cleared we should not have any abnormal
edge at all).

For the testcase in the PR this means that IPA inlining will
remove the abormal edges from the block after inlining the call
the edge was coming from.

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

PR tree-optimization/104263
* tree-cfg.cc (gimple_purge_dead_abnormal_call_edges):
Purge edges also when !cfun->has_nonlocal_label
and !cfun->calls_setjmp.

* gcc.dg/tree-ssa/inline-13.c: New testcase.

RISC-V: Document `auipc' and `bitmanip' `type' attributes

Document new `auipc' and `bitmanip' `type' attributes added respectively
with commit 88108b27dda9 ("RISC-V: Add sifive-7 pipeline description.")
and commit 283b1707f237 ("RISC-V: Implement instruction patterns for ZBA
extension.") but not listed so far.

gcc/
* config/riscv/riscv.md: Document `auipc' and `bitmanip' `type'
attributes.

Prevent malicious descriptor stacking for scalar components [V2].

gcc/fortran/ChangeLog:

PR fortran/103790
* trans-array.cc (structure_alloc_comps): Prevent descriptor
stacking for non-array data; do not broadcast caf-tokens.
* trans-intrinsic.cc (conv_co_collective): Prevent generation
of unused descriptor.

gcc/testsuite/ChangeLog:

PR fortran/103790
* gfortran.dg/coarray_collectives_18.f90: New test.

cfgrtl: Fix up locus comparison in unique_locus_on_edge_between_p [PR104237]

The testcase in the PR (not included for the testsuite because we don't
have an (easy) way to -fcompare-debug LTO, we'd need 2 compilations/linking,
one with -g and one with -g0 and -fdump-rtl-final= at the end of lto1
and compare that) has different code generation for -g vs. -g0.

The difference appears during expansion, where we have a goto_locus
that is at -O0 compared to the INSN_LOCATION of the previous and next insn
across an edge.  With -g0 the locations are equal and so no nop is added.
With -g the locations aren't equal and so a nop is added holding that
location.

The reason for the different location is in the way how we stream in
locations by lto1.
We have lto_location_cache::apply_location_cache that is called with some
set of expanded locations, qsorts them, creates location_t's for those
and remembers the last expanded location.
lto_location_cache::input_location_and_block when read in expanded_location
is equal to the last expanded location just reuses the last location_t
(or adds/changes/removes LOCATION_BLOCK in it), when it is not queues
it for next apply_location_cache.  Now, when streaming in -g input, we can
see extra locations that don't appear with -g0, and if we are unlucky
enough, those can be sorted last during apply_location_cache and affect
what locations are used from the single entry cache next.
In particular, second apply_location_cache with non-empty loc_cache in
the testcase has 14 locations with -g0 and 16 with -g and those 2 extra
ones sort both last (they are the same).  The last one from -g0 then
appears to be input_location_and_block sourced again, for -g0 triggers
the single entry cache, while for -g it doesn't and so apply_location_cache
will create for it another location_t with the same content.

The following patch fixes it by comparing everything we care about the
location instead (well, better in addition) to a simple location_t ==
location_t check.  I think we don't care about the sysp flag for debug
info...

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

PR lto/104237
* cfgrtl.cc (loc_equal): New function.
(unique_locus_on_edge_between_p): Use it.

Make graph dumping work for fn != cfun

The following makes dumping of a function as graph work as intended
when specifying a function other than cfun.  Unfortunately the loop
and the dominance APIs are not set up to work for other functions
than cfun so you won't get any fancy loop dumps but the non-loop
dump works up to reaching mark_dfs_back_edges which I trivially made
function aware and adjusted current callers with a wrapper.

With all this, doing dot-fn id->src_cfun from the debugger when
debugging inlining works.  Previously you got a strange mix of
the src and dest functions visualized ;)

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

* cfganal.h (mark_dfs_back_edges): Provide API with struct
function argument.
* cfganal.cc (mark_dfs_back_edges): Take a struct function
to work on, add a wrapper passing cfun.
* graph.cc (draw_cfg_nodes_no_loops): Replace stray cfun
uses with fun which is already passed.
(draw_cfg_edges): Likewise.
(draw_cfg_nodes_for_loop): Do not use draw_cfg_nodes_for_loop
for fun != cfun.

Fix wrong operator for universal_integer operands in instance

This is a regression present on mainline and 11 branch: the transformation
applied during expansion by Narrow_Large_Operation would incorrectly perform
name resolution for the operator again.

gcc/ada/
PR ada/104258
* exp_ch4.adb (Narrow_Large_Operation): Also copy the entity, if
any, when rewriting the operator node.

gcc/testsuite/
* gnat.dg/generic_comp.adb: New test.

Revert "Prevent malicious descriptor stacking for scalar components."

Breaks bootstrap.

This reverts commit c9c48ab7bad9fe5e096076e56a60ce0a5a2b65f7.

Prevent malicious descriptor stacking for scalar components.

gcc/fortran/ChangeLog:

PR fortran/103790
* trans-array.cc (structure_alloc_comps): Prevent descriptor
stacking for non-array data; do not broadcast caf-tokens.
* trans-intrinsic.cc (conv_co_collective): Prevent generation
of unused descriptor.

gcc/testsuite/ChangeLog:

PR fortran/103790
* gfortran.dg/coarray_collectives_18.f90: New test.

c++: pack in enumerator in lambda [PR100198]

The GCC 8 lambda overhaul fixed most uses of lambdas in pack expansions, but
local enums and classes within such lambdas that depend on parameter packs
are still broken.  For now, give a sorry instead of an ICE or incorrect
error.

PR c++/100198
PR c++/100030
PR c++/100282

gcc/cp/ChangeLog:

* parser.cc (cp_parser_enumerator_definition): Sorry on parameter
pack in lambda.
(cp_parser_class_head): And in class attributes.
* pt.cc (check_for_bare_parameter_packs): Sorry instead of error
in lambda.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-variadic13.C: Accept the sorry
as well as the correct error.
* g++.dg/cpp0x/lambda/lambda-variadic14.C: Likewise.
* g++.dg/cpp0x/lambda/lambda-variadic14a.C: New test.
* g++.dg/cpp0x/lambda/lambda-variadic15.C: New test.
* g++.dg/cpp0x/lambda/lambda-variadic16.C: New test.

Daily bump.

libstdc++: Prevent -Wstringop-overread warning in std::deque [PR100516]

The compiler warns about the loop in deque::_M_range_initialize because
it doesn't know that the number of nodes has already been correctly
sized to match the size of the input. Use __builtin_unreachable to tell
it that the loop will never be entered if the number of elements is
smaller than a single node.

libstdc++-v3/ChangeLog:

PR libstdc++/100516
* include/bits/deque.tcc (_M_range_initialize<ForwardIterator>):
Add __builtin_unreachable to loop.
* testsuite/23_containers/deque/100516.cc: New test.

analyzer: show region creation events for uninit warnings

When reviewing the output of -fanalyzer on PR analyzer/104224 I noticed
that despite very verbose paths, the diagnostic paths for
  -Wanalyzer-use-of-uninitialized-value
don't show where the uninitialized memory is allocated.

This patch adapts and simplifies material from
  "[PATCH 3/6] analyzer: implement infoleak detection"
    https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584377.html
in order to add region creation events for the pertinent region (whether
on the stack or heap).

For example, this patch extends:

malloc-1.c: In function 'test_40':
malloc-1.c:461:5: warning: use of uninitialized value '*p' [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
  461 |   i = *p;
      |   ~~^~~~
  'test_40': event 1
    |
    |  461 |   i = *p;
    |      |   ~~^~~~
    |      |     |
    |      |     (1) use of uninitialized value '*p' here
    |

to:

malloc-1.c: In function 'test_40':
malloc-1.c:461:5: warning: use of uninitialized value '*p' [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
  461 |   i = *p;
      |   ~~^~~~
  'test_40': events 1-2
    |
    |  460 |   int *p = (int*)malloc(sizeof(int*));
    |      |                  ^~~~~~~~~~~~~~~~~~~~
    |      |                  |
    |      |                  (1) region created on heap here
    |  461 |   i = *p;
    |      |   ~~~~~~
    |      |     |
    |      |     (2) use of uninitialized value '*p' here
    |

and this helps readability of the resulting warnings, especially in
more complicated cases.

gcc/analyzer/ChangeLog:
* checker-path.cc (event_kind_to_string): Handle
EK_REGION_CREATION.
(region_creation_event::region_creation_event): New.
(region_creation_event::get_desc): New.
(checker_path::add_region_creation_event): New.
* checker-path.h (enum event_kind): Add EK_REGION_CREATION.
(class region_creation_event): New subclass.
(checker_path::add_region_creation_event): New decl.
* diagnostic-manager.cc
(diagnostic_manager::emit_saved_diagnostic): Pass NULL for new
param to add_events_for_eedge when handling trailing eedge.
(diagnostic_manager::build_emission_path): Create an interesting_t
instance, allow the pending diagnostic to populate it, and pass it
to the calls to add_events_for_eedge.
(diagnostic_manager::add_events_for_eedge): Add "interest" param.
Use it to add region_creation_events for on-stack regions created
within at function entry, and when pertinent dynamically-sized
regions are created.
(diagnostic_manager::prune_for_sm_diagnostic): Add case for
EK_REGION_CREATION.
* diagnostic-manager.h (diagnostic_manager::add_events_for_eedge):
Add "interest" param.
* pending-diagnostic.cc: Include "selftest.h", "tristate.h",
"analyzer/call-string.h", "analyzer/program-point.h",
"analyzer/store.h", and "analyzer/region-model.h".
(interesting_t::add_region_creation): New.
(interesting_t::dump_to_pp): New.
* pending-diagnostic.h (struct interesting_t): New.
(pending_diagnostic::mark_interesting_stuff): New vfunc.
* region-model.cc
(poisoned_value_diagnostic::poisoned_value_diagnostic): Add
(poisoned_value_diagnostic::operator==): Compare m_pkind and
m_src_region fields.
(poisoned_value_diagnostic::mark_interesting_stuff): New.
(poisoned_value_diagnostic::m_src_region): New.
(region_model::check_for_poison): Call
get_region_for_poisoned_expr for uninit values and pass the resul
to the diagnostic.
(region_model::get_region_for_poisoned_expr): New.
(region_model::deref_rvalue): Pass NULL for
poisoned_value_diagnostic's src_region.
* region-model.h (region_model::get_region_for_poisoned_expr): New
decl.
* region.h (frame_region::get_fndecl): New.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/data-model-1.c: Add dg-message directives for
expected region creation events.
* gcc.dg/analyzer/malloc-1.c: Likewise.
* gcc.dg/analyzer/memset-CVE-2017-18549-1.c: Likewise.
* gcc.dg/analyzer/pr101547.c: Likewise.
* gcc.dg/analyzer/pr101875.c: Likewise.
* gcc.dg/analyzer/pr101962.c: Likewise.
* gcc.dg/analyzer/pr104224.c: Likewise.
* gcc.dg/analyzer/pr94047.c: Likewise.
* gcc.dg/analyzer/symbolic-1.c: Likewise.
* gcc.dg/analyzer/uninit-1.c: Likewise.
* gcc.dg/analyzer/uninit-4.c: Likewise.
* gcc.dg/analyzer/uninit-alloca.c: New test.
* gcc.dg/analyzer/uninit-pr94713.c: Add dg-message directive for
expected region creation event.
* gcc.dg/analyzer/uninit-pr94714.c: Likewise.
* gcc.dg/analyzer/zlib-3.c: Likewise.

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

libstdc++: Avoid overflow in ranges::advance(i, n, bound)

When (bound - i) or n is the most negative value of its type, the
negative of the value will overflow. Instead of abs(n) >= abs(bound - i)
use n >= (bound - i) when positive and n <= (bound - i) when negative.
The function has a precondition that they must have the same sign, so
this works correctly. The precondition check can be moved into the else
branch, and simplified.

The standard requires calling ranges::advance(i, bound) even if i==bound
is already true, which is technically observable, but that's pointless.
We can just return n in that case. Similarly, for i!=bound but n==0 we
are supposed to call ranges::advance(i, n), but that's pointless. An LWG
issue to allow omitting the pointless calls is expected to be filed.

libstdc++-v3/ChangeLog:

* include/bits/ranges_base.h (ranges::advance): Avoid signed
overflow. Do nothing if already equal to desired result.
* testsuite/24_iterators/range_operations/advance_overflow.cc:
New test.

c++: dependent and non-dependent attributes [PR104245]

A flaw in my patch for PR51344 was that cplus_decl_attributes calls
decl_attributes after save_template_attributes, which messes up the ordering
that save_template_attributes set up.  Fixed by splitting
save_template_attributes around the call to decl_attributes.

PR c++/104245
PR c++/51344

gcc/cp/ChangeLog:

* decl2.cc (save_template_attributes): Take late attrs as parm.
(cplus_decl_attributes): Call it after decl_attributes,
splice_template_attributes before.

gcc/testsuite/ChangeLog:

* g++.dg/lto/alignas1_0.C: New test.

testsuite: Fix gfortran.dg/ieee/signaling_?.f90 tests for x86 targets

As stated in signaling_?.f90 tests, x86-32 ABI is not suitable to
correctly handle signaling NaNs.  However, XFAIL is not the correct choice
to disable these tests, since various optimizations can generate code
that avoids moves from registers to memory (and back), resulting
in the code that executes correctly, producing spurious XFAIL.
These tests should be disabled on x86-32 using { ! ia32 } dg-directive
which rules out x32 ilp32 ABI, where tests execute without problems.

Please note that check_effective_target_ia32 test tries to compile code that
uses __i386__ target-dependent preprocessor definition, so it is guaranteed
to fail on all non-ia32 targets.

2022-01-27  Uroš Bizjak  <ubizjak@gmail.com>

gcc/testsuite/ChangeLog:

* gfortran.dg/ieee/signaling_1.f90 (dg-do):
Run only on non-ia32 targets.
* gfortran.dg/ieee/signaling_2.f90 (dg-do): Ditto.
* gfortran.dg/ieee/signaling_3.f90 (dg-do): Ditto.

Fortran: fix issues with internal conversion between default and wide char

gcc/fortran/ChangeLog:

PR fortran/104128
* expr.cc (gfc_copy_expr): Convert internal representation of
string to wide char in value only for default character kind.
* target-memory.cc (interpret_array): Pass flag for conversion of
wide chars.
(gfc_target_interpret_expr): Likewise.

gcc/testsuite/ChangeLog:

PR fortran/104128
* gfortran.dg/transfer_simplify_14.f90: New test.

c++: Add a couple of CTAD testcases [PR82632]

PR c++/82632

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/class-deduction104.C: New test.
* g++.dg/cpp1z/class-deduction105.C: New test.

Fortran: add missing conversions for result of intrinsics to result type

gcc/fortran/ChangeLog:

PR fortran/84784
* trans-intrinsic.cc (conv_intrinsic_image_status): Convert result
to resulting (default) integer type.
(conv_intrinsic_team_number): Likewise.
(gfc_conv_intrinsic_popcnt_poppar): Likewise.

gcc/testsuite/ChangeLog:

PR fortran/84784
* gfortran.dg/pr84784.f90: New test.

git-undescr.sh: Support full output of git-descr.sh.

contrib/ChangeLog:

* git-undescr.sh: Support full output of git-descr.sh.

contrib: Put gcc-descr and gcc-undescr to file.

contrib/ChangeLog:

* git-descr.sh: New file.
* git-undescr.sh: New file.
Support optional arguments --long, --short and default
to 14 characters of git hash.
* gcc-git-customization.sh: Use the created files.

Co-Authored-By: Martin Jambor <mjambor@suse.cz>

c++: non-dependent immediate member fn call [PR99895]

Here we're emitting a bogus error during ahead of time evaluation of a
non-dependent immediate member function call such as a.f(args) because
the defacto templated form for such a call is (a.f)(args) but we're
trying to evaluate it using the intermediate CALL_EXPR built by
build_over_call, which has the non-member form f(a, args).  The defacto
member form is built in build_new_method_call, so it seems we should
handle the immediate call there instead, or perhaps make build_over_call
build the correct form in the first place.

Giiven that there are many spots other than build_new_method_call that
call build_over_call for member functions, e.g. build_op_call, this
patch takes the latter approach.

In passing, this patch makes us avoid wrapping PARM_DECL in
NON_DEPENDENT_EXPR for benefit of the third testcase below.

PR c++/99895

gcc/cp/ChangeLog:

* call.cc (build_over_call): For a non-dependent member call,
build up a CALL_EXPR using a COMPONENT_REF callee, as in
build_new_method_call.
* pt.cc (build_non_dependent_expr): Don't wrap PARM_DECL either.
* tree.cc (build_min_non_dep_op_overload): Adjust accordingly
after the build_over_call change.

gcc/ChangeLog:

* tree.cc (build_call_vec): Add const to second parameter.
* tree.h (build_call_vec): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/consteval-memfn1.C: New test.
* g++.dg/cpp2a/consteval-memfn2.C: New test.
* g++.dg/cpp2a/consteval28.C: New test.

c++: constrained partial spec using qualified name [PR92944, PR103678]

In the nested_name_specifier branch within cp_parser_class_head, we need
to update 'type' with the result of maybe_process_partial_specialization
like we do in the template_id_p branch.

PR c++/92944
PR c++/103678

gcc/cp/ChangeLog:

* parser.cc (cp_parser_class_head): Update 'type' with the result
of maybe_process_partial_specialization in the
nested_name_specifier branch.  Refactor nearby code to accomodate
that maybe_process_partial_specialization returns a _TYPE, not a
TYPE_DECL, and eliminate local variable 'class_type' in passing.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-partial-spec10.C: New test.
* g++.dg/cpp2a/concepts-partial-spec11.C: New test.

libstdc++: fix typo in acinclude.m4.

PR libstdc++/104259

libstdc++-v3/ChangeLog:

* acinclude.m4: Fix typo.
* configure: Regenerate.

c++: new-expr of array of deduced class tmpl [PR101988]

In r12-1933 I attempted to implement DR2397 aka allowing

  int a[3];
  auto (&r)[3] = a;

by removing the type_uses_auto check in create_array_type_for_decl.
That may have gone too far, because it also allows arrays of
CLASS_PLACEHOLDER_TEMPLATE and it looks like [dcl.type.class.deduct]
prohibits that: "...the declared type of the variable shall be cv T,
where T is the placeholder."  However, in /2 it explicitly states that
"A placeholder for a deduced class type can also be used in the
type-specifier-seq in the new-type-id or type-id of a new-expression."

In this PR, it manifested by making us accept invalid

  template<class T> struct A { A(T); };
  auto p = new A[]{1};

[expr.new]/2 says that such a construct is treated as an invented
declaration of the form

  A x[]{1};

but, I think, that ought to be ill-formed as per above.  So this patch
sort of restores the create_array_type_for_decl check.  I should mention
that the difference between [] and [1] is due to cp_parser_new_type_id:

      if (*nelts == NULL_TREE)
        /* Leave [] in the declarator.  */;

and groktypename returning different types based on that.

PR c++/101988

gcc/cp/ChangeLog:

* decl.cc (create_array_type_for_decl): Reject forming an array of
placeholder for a deduced class type.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/class-deduction-new1.C: New test.
* g++.dg/cpp23/auto-array2.C: New test.

Improve wording for -freport-bug option.

PR web/104254

gcc/ChangeLog:

* diagnostic.cc (diagnostic_initialize):
Initialize report_bug flag.
(diagnostic_action_after_output):
Explain that -freport-bug option can be used for pre-processed
file creation.  Make the message shorter.
(error_recursion): Rename Internal to internal.
* diagnostic.h (struct diagnostic_context): New field.
* opts.cc (common_handle_option): Init the field here.

analyzer: fix -Wformat warnings on i686

PR analyzer/104247

gcc/analyzer/ChangeLog:

* constraint-manager.cc (bounded_ranges_manager::log_stats):
Cast to long for format purpose.
* region-model-manager.cc (log_uniq_map): Likewise.

rs6000: Fix an assertion in update_target_cost_per_stmt [PR103702]

This patch is to fix one wrong assertion which is too aggressive.
Vectorizer can do vec_construct costing for the vector type which
only has one unit.  For the failed case, the passed in vector type
is "vector(1) int", though it doesn't end up with any construction
eventually, we have to handle this kind of possibility.

gcc/ChangeLog:

PR target/103702
* config/rs6000/rs6000.cc
(rs6000_cost_data::update_target_cost_per_stmt): Fix one wrong
assertion with early return.

gcc/testsuite/ChangeLog:

PR target/103702
* gcc.target/powerpc/pr103702.c: New test.

Fix omp-low ICE for indirect references based off component access [PR103642]

This issue was triggered after the patch extending syntax for component access
in map clauses in commit 0ab29cf0bb68960c1f87405f14b4fb2109254e2f.

In gimplify_scan_omp_clauses, the case for handling indirect accesses (which
creates firstprivate ptr and zero-length array section map for such decls) was
erroneously went into for non-pointer cases (here being the base struct decl),
so added the
appropriate checks there.

Added new testcase is a compile only test for the ICE. The original omptests
t-partial-struct test actually should not execute correctly, because for
map(t.s->a[:N]), map(t.s[:1]) is not implicitly mapped, thus the entire
offloaded access does not work as is (fixing that omptests test is out of
scope here).

2022-01-27  Chung-Lin Tang  <cltang@codesourcery.com>

PR middle-end/103642

gcc/ChangeLog:

* gimplify.cc (gimplify_scan_omp_clauses): Do not do indir_p handling
for non-pointer or non-reference-to-pointer cases.

gcc/testsuite/ChangeLog:

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

Fix aarch64/104201: branch-protection-attr.c fails after quoting difference

After the quoting changes in r12-6521-g03a1a86b5ee40d4e240, branch-protection-attr.c
fails due to expecting a different quoting type for "leaf".
This patch changes the quoting from "" to '' as that is what is used now.

Committed as obvious after a test of the testcase.

gcc/testsuite/ChangeLog:

PR target/104201
* gcc.target/aarch64/branch-protection-attr.c: Fix quoting for
the expected error message on line 5 of leaf.

reassoc: Fix up inter-bb range optimization [PR104196]

As mentioned in the PR, reassoc1 miscompiles following testcase.
We have:
  if (a.1_1 >= 0)
    goto <bb 5>; [59.00%]
  else
    goto <bb 4>; [41.00%]

  <bb 4> [local count: 440234144]:
  _3 = -2147483647 - a.1_1;
  _9 = a.1_1 != -2147479551;
  _4 = _3 == 1;
  _8 = _4 | _9;
  if (_8 != 0)
    goto <bb 5>; [34.51%]
  else
    goto <bb 3>; [65.49%]

and the inter-bb range test optimization treats it as:
  if ((a.1_1 >= 0)
      | (-2147483647 - a.1_1 == 1)
      | (a.1_1 != -2147479551))
    goto bb5;
  else
    goto bb3;
and recognizes that a.1_1 >= 0 is redundant with a.1_1 != -2147479551
and so will optimize it into:
  if (0
      | (-2147483647 - a.1_1 == 1)
      | (a.1_1 != -2147479551))
    goto bb5;
  else
    goto bb3;
When merging 2 comparisons, we use update_range_test which picks one
of the comparisons as the one holding the result (currently always
the RANGE one rather than all the OTHERRANGE* ones) and adjusts the
others to be true or false.
The problem with doing that is that means the
  _3 = -2147483647 - a.1_1;
stmt with undefined behavior on overflow used to be conditional before
but now is unconditional.  reassoc performs a no_side_effect_bb check
which among other checks punts on gimple_has_side_effects and
gimple_assign_rhs_could_trap_p stmts as well as ones that have uses of
their lhs outside of the same bb, but it doesn't punt for this potential
signed overflow case.

Now, for this testcase, it can be fixed in update_range_test by being
smarter and choosing the other comparison to modify.  This is achieved
by storing into oe->id index of the bb with GIMPLE_COND the
comparison feeds into not just for the cases where the comparison is
the GIMPLE_COND itself, but in all cases, and then finding oe->id that
isn't dominated by others.  If we find such, use that oe for the merge
test and if successful, swap range->idx and swap_with->idx.
So for the above case we optimize it into:
  if ((a.1_1 != -2147479551)
      | (-2147483647 - a.1_1 == 1)
      | 0)
    goto bb5;
  else
    goto bb3;
instead.

Unfortunately, this doesn't work in all cases,
optimize_range_tests_to_bit_test and
optimize_range_tests_cmp_bitwise optimizations use non-NULL seq
to update_range_test and they carefully choose a particular comparison
because the sequence then uses SSA_NAMEs that may be defined only in
their blocks.  For that case, the patch keeps using the chosen comparison
but if the merge is successful, rewrites stmts with signed overflow behavior
into defined overflow.
For this I ran into a problem, rewrite_to_defined_overflow returns a
sequence that includes the original stmt with modified arguments, this means
it needs to be gsi_remove first.  Unfortunately, gsi_remove regardless of
the remove_permanently argument creates debug temps for the lhs, which I
think is quite undesirable here.  So I've added an argument (default to
false) to rewrite_to_defined_overflow to do the modification in place
without the need to remove the stmt.

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

PR tree-optimization/104196
* gimple-fold.h (rewrite_to_defined_overflow): Add IN_PLACE argument.
* gimple-fold.cc (rewrite_to_defined_overflow): Likewise.  If true,
return NULL and emit needed stmts before and after stmt.
* tree-ssa-reassoc.cc (update_range_test): For inter-bb range opt
pick as operand_entry that will hold the merged test the one feeding
earliest condition, ensure that by swapping range->idx with some
other range's idx if needed.  If seq is non-NULL, don't actually swap
it but instead rewrite stmts with undefined overflow in between
the two locations.
(maybe_optimize_range_tests): Set ops[]->id to bb->index with the
corresponding condition even if they have non-NULL ops[]->op.
Formatting fix.

* gcc.c-torture/execute/pr104196.c: New test.

libgomp.texi: Update OpenMP implementation status

libgomp/
* libgomp.texi (OpenMP 5.0): Update implementation status.

Daily bump.

rs6000: Fix up *intrin.h for C89 [PR104239]

When writing testcases for the previously posted patch, I have noticed
that 3 of the headers aren't valid C89 (I didn't have any dg-options
so -ansi -pedantic-errors was implied and these errors were reported).

The following patch fixes those, ok for trunk?

Note, as can be seen even in this patch, seems older rs6000/*intrin.h
headers uglify not just argument names (__A instead of A etc.), but also
automatic variable names and other local identifiers, while e.g. emmintrin.h
or bmi2intrin.h clearly uglify only the argument names and not local
variables.  I think that should be fixed but don't have time for that myself
(libstdc++ or e.g. the x86 headers uglify everything; this is so that one
can
 #define result a + b
 #include <x86intrin.h>
etc.).

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

PR target/104239
* config/rs6000/emmintrin.h (_mm_sad_epu8): Use __asm__ instead of
asm.
* config/rs6000/smmintrin.h (_mm_minpos_epu16): Declare iterator
before for loop instead of for init clause.
* config/rs6000/bmi2intrin.h (_pext_u64): Likewise.

* gcc.target/powerpc/pr104239-3.c: New test.

rs6000: Fix up #include <immintrin.h> or <x86gprintrin.h> [PR104239]

r12-4717-g7d37abedf58d66 added immintrin.h and x86gprintrin.h headers
to rs6000, these headers are on x86 standalone headers that various
programs include directly rather than including them through
<x86intrin.h>.
Unfortunately, for that change the bmiintrin.h and bmi2intrin.h
headers haven't been adjusted, so the effect is that if one includes them
(without including also x86intrin.h first) #error will trigger.
Furthermore, when including such headers conditionally as some real-world
packages do, this means a regression.

The following patch fixes it and matches what the x86 bmi{,2}intrin.h
headers do.

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

PR target/104239
* config/rs6000/bmiintrin.h: Test _X86GPRINTRIN_H_INCLUDED instead of
_X86INTRIN_H_INCLUDED and adjust #error wording.
* config/rs6000/bmi2intrin.h: Likewise.

* gcc.target/powerpc/pr104239-1.c: New test.
* gcc.target/powerpc/pr104239-2.c: New test.

c++: vector compound literal [PR104206]

My patch for PR101072 removed the specific VECTOR_TYPE handling here, which
broke pr72747-2.c on PPC; this patch restores it.

PR c++/104206
PR c++/101072

gcc/cp/ChangeLog:

* semantics.cc (finish_compound_literal): Restore VECTOR_TYPE check.

dwarf2out: For ppc64le IEEE quad long double, emit DW_TAG_typedef to _Float128 [PR104194]

On Mon, Jan 24, 2022 at 11:26:27PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Yet another short term solution might be not use DW_TAG_base_type
> for the IEEE quad long double, but instead pretend it is a DW_TAG_typedef
> with DW_AT_name "long double" to __float128 DW_TAG_base_type.
> I bet gdb would even handle it without any changes, but of course, it would
> be larger than the other proposed changes.

Here it is implemented.

Testcases I've played with are e.g.:
__ibm128 a;
long double b;
_Complex long double c;

static __attribute__((noinline)) int
foo (long double d)
{
  long double e = d + 1.0L;
  return 0;
}

int
main ()
{
  a = 1.0;
  b = 2.0;
  c = 5.0 + 6.0i;
  return foo (7.0L);
}
and
  real(kind=16) :: a
  complex(kind=16) :: b
  a = 1.0
  b = 2.0
end

Printing the values of the variables works well,
p &b or p &c shows pointer to the correct type, just
ptype b or ptype c prints _Float128 instead of
long double or complex _Float128 instead of complex long double.
Even worse in fortran where obviously _Float128 or
complex _Float128 aren't valid types, but as GDB knows them by name,
it is just ptype that is weird.

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

PR debug/104194
* dwarf2out.cc (long_double_as_float128): New function.
(modified_type_die): For powerpc64le IEEE 754 quad long double
and complex long double emit those as DW_TAG_typedef to
_Float128 or complex _Float128 base type.

c++: Fix up handling of vector CONSTRUCTORs with vectors in it in constexpr.cc [PR104226]

The middle-end uses sometimes VECTOR_TYPE CONSTRUCTORs that contain
some other VECTOR_TYPE elements in it (should be with compatible element
size and smaller number of elements, e.g. a V8SImode vector can be
constructed as { V4SImode_var_1, V4SImode_var_2 }), and expansion of
__builtin_shufflevector emits these early, so constexpr.cc can see those
too.
constexpr.cc already has special cases for NULL index which is typical
for VECTOR_TYPE CONSTRUCTORs, and for VECTOR_TYPE CONSTRUCTORs that
contain just scalar elts that works just fine - init_subob_ctx just
returns on non-aggregate elts and get_or_insert_ctor_field has
  if (TREE_CODE (type) == VECTOR_TYPE && index == NULL_TREE)
    {
      CONSTRUCTOR_APPEND_ELT (CONSTRUCTOR_ELTS (ctor), index, NULL_TREE);
      return &CONSTRUCTOR_ELTS (ctor)->last();
    }
handling for it.  But for the vector in vector case init_subob_ctx would
try to create a sub-CONSTRUCTOR and even didn't handle the NULL index
case well, so instead of creating the sub-CONSTRUCTOR after the elts already
in it overwrote the first one.  So
(V8SImode) { { 0, 0, 0, 0 }, { 0, 0, 0, 0 } }
became
(V8SImode) { 0, 0, 0, 0 }
The following patch fixes it by not forcing a sub-CONSTRUCTOR for this
vector in vector case.

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

PR c++/104226
* constexpr.cc (init_subob_ctx): For vector ctors containing
vector elements, ensure appending to the same ctor instead of
creating another one.

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

warn-access: Prevent -Wuse-after-free on ARM [PR104213]

Here, -Wuse-after-free warns about using 'this' which, on ARM, cdtors
return, as mandated by the EABI.  To be entirely correct, it only
requires it for C1 and C2 ctors and D2 and D1 dtors, but I don't feel
like changing that now and possibly running into issues later on.

This patch uses suppress_warning on 'this' for certain cdtor_returns_this
cases in the C++ FE, and then warn_invalid_pointer makes use of this
information and doesn't warn.

In my first attempt I tried suppress_warning the MODIFY_EXPR or RETURN_EXPR
we build in build_delete_destructor_body, but the complication is that
the suppress_warning bits don't always survive gimplification; see e.g.
gimplify_modify_expr where we do

 6130       if (COMPARISON_CLASS_P (*from_p))
 6131         copy_warning (assign, *from_p);

but here we're not dealing with a comparison.  Removing that check
regresses uninit-pr74762.C.  Adding copy_warning (assign, *expr_p)
regresses c-c++-common/uninit-17.c.

PR target/104213

gcc/cp/ChangeLog:

* decl.cc (finish_constructor_body): Suppress -Wuse-after-free.
(finish_destructor_body): Likewise.
* optimize.cc (build_delete_destructor_body): Likewise.

gcc/ChangeLog:

* gimple-ssa-warn-access.cc (pass_waccess::warn_invalid_pointer): Don't
warn when the SSA_NAME_VAR of REF has supressed -Wuse-after-free.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wuse-after-free2.C: New test.
* g++.dg/warn/Wuse-after-free3.C: New test.

c++: ->template and using-decl [PR104235]

cp_parser_template_id wasn't prepared to handle getting a USING_DECL back
from cp_parser_template_name.  Let's defer that case to instantiation time,
as well.

PR c++/104235

gcc/cp/ChangeLog:

* parser.cc (cp_parser_template_name): Repeat lookup of USING_DECL.

gcc/testsuite/ChangeLog:

* g++.dg/parse/template-keyword2.C: New test.

IPA mod-ref: fix usage of --param names in dump messages.

gcc/ChangeLog:

* ipa-modref-tree.cc (modref_access_node::update):
Remove "--param param=foo" with "--param foo".
(modref_access_node::insert): Likewise.
(modref_access_node::insert_kill): Likewise.
* ipa-modref-tree.h (struct modref_ref_node): Likewise.
(struct modref_base_node): Likewise.
(struct modref_tree): Likewise.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/modref-7.c: Update scanned patterns.
* gcc.dg/tree-ssa/modref-8.c: Likewise.

rtl: builtins: Fix builtins feclearexcept and feraiseexcept operand check [PR94193]

Commit 4343f5e25679 ("rtl: builtins: (not just) rs6000: Add builtins
for fegetround, feclearexcept and feraiseexcept [PR94193]") broke gcc
bootstra when building with --enable-checking=rtl[1].

The function expand_builtin_feclear_feraise_except was failing to
proper validate op0 predicate before emit_insn leading to the mismatch
type failure.

[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589186.html

2022-01-26  Raoni Fassina Firmino  <raoni@linux.ibm.com>

gcc/
PR target/94193
* builtins.cc (expand_builtin_feclear_feraise_except): Add op0
predicate check.

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

analyzer: fix missing uninit warning on args to stdio builtins [PR104224]

We were failing to check for uninitialized arguments to stdio builtins,
such as when passing local "go" to the call to "printf" in "main" in
the testcase.

gcc/analyzer/ChangeLog:
PR analyzer/104224
* region-model.cc (region_model::check_call_args): New.
(region_model::on_call_pre): Call it when ignoring stdio builtins.
* region-model.h (region_model::check_call_args): New decl

gcc/testsuite/ChangeLog:
PR analyzer/104224
* gcc.dg/analyzer/pr104224.c: New test.

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

analyzer: fix sense in range::add_bound [PR94362]

Mikael Morin spotted that I got the sense wrong when discarding
redundant constraints in
r12-6782-gc4b8f3730a80025192fdb485ad2535c165340e41.

Fixed as follows, which also moves the rejection of contradictory
constraints in range::add_bound to earlier, so that this code can
be self-tested.

gcc/analyzer/ChangeLog:
PR analyzer/94362
* constraint-manager.cc (range::add_bound): Fix tests for
discarding redundant constraints.  Perform test for rejecting
unsatisfiable constraints earlier so that they don't update
the object on failure.
(selftest::test_range): New.
(selftest::test_constant_comparisons): Add test coverage for
existing constraints becoming narrower until they are
unsatisfiable.
(selftest::run_constraint_manager_tests): Call test_range.

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

testsuite: Fix up pr104188.c testcase for i686-linux [PR104188]

On i686-linux this new testcase FAILs with:
cc1: warning: SSE instruction set disabled, using 387 arithmetics
FAIL: gcc.target/i386/pr104188.c (test for excess errors)
Excess errors:
cc1: warning: SSE instruction set disabled, using 387 arithmetics
This is because it uses -mfpmath=sse, but -msse2 isn't on.  Fixed
by adding -msse2 to dg-options and requiring sse2_runtime effective
target.

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

PR target/104188
* gcc.target/i386/pr104188.c: Add dg-require-effective-target
sse2_runtime.  Add -msse2 to dg-options.

Fortran: fix bootstrap on SPARC/Solaris

libgfortran/ChangeLog:

PR libfortran/104233
* ieee/issignaling_fallback.h: Check GFC_REAL_16_IS_FLOAT128
instead of __FLT128_IS_IEC_60559__.

c++: alias template and typename [PR103057]

Usually we handle DR1558 substitution near the top of tsubst, but in this
case while substituting TYPENAME_TYPE we were passing an alias
specialization to tsubst_aggr_type, which ignored its aliasness.

PR c++/103057

gcc/cp/ChangeLog:

* pt.cc (tsubst_aggr_type): Call tsubst for alias template
specialization.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/alias-decl-void1.C: New test.

Daily bump.

Fortran: fix issignaling() implementation

libgfortran/ChangeLog:

* ieee/issignaling_fallback.h: Fix GCC-specific preprocessor
macros.

Avoid recomputing PHI results after failure (PR104203).

Resolves:
PR tree-optimization/104203 - huge compile-time regression in pointer_query

gcc/ChangeLog:

PR tree-optimization/104203
* gimple-ssa-warn-access.cc (pass_data pass_data_waccess): Use
TV_WARN_ACCESS.
* pointer-query.cc (access_ref::merge_ref): Change return type.
Convert failure to a conservative success.
(access_ref::get_ref): Adjust to the change above.  Short-circuit
PHI evaluation after first failure turned into conservative success.
* pointer-query.h (access_ref::merge_ref): Change return type.
* timevar.def (TV_WARN_ACCESS): New timer variable.

libstdc++: Avoid some more warnings [PR104019]

With -fno-exceptions we get a -Wmisleading-indentation warning for:

  if (cond)
    __try {}
    __catch (...) {}

This is because the __catch(...) expands to if (false), but is indented
as though it is controlled by the preceding 'if'. Surround it in braces.

The new make_shared<T[]> code triggers a bogus warning due to PR 61596,
which can be disabled with a pragma.

libstdc++-v3/ChangeLog:

PR libstdc++/104019
* include/bits/istream.tcc (basic_istream::sentry): Add braces
around try-block.
* include/bits/shared_ptr_base.h (_Sp_counted_array_base::_M_init):
Add pragmas to disable bogus warnings from PR 61596.

libstdc++: Define _GNU_SOURCE for secure_getenv on Cygwin [PR104217]

For GNU/Linux G++ defines _GNU_SOURCE automatically, but not for Cygwin.
This means secure_getenv is not declared by Cygwin's <stdlib.h>, even
though autoconf detected it is present in the library. Define it in the
source files that want to use secure_getenv.

libstdc++-v3/ChangeLog:

PR libstdc++/104217
* src/c++17/fs_ops.cc (_GNU_SOURCE): Define.
* src/filesystem/dir.cc (_GNU_SOURCE): Define.
* src/filesystem/ops.cc (_GNU_SOURCE): Define.

libstdc++: Avoid symlink race in filesystem::remove_all [PR104161]

This adds a new internal flag to the filesystem::directory_iterator
constructor that makes it fail if the path is a symlink that resolves to
a directory. This prevents filesystem::remove_all from following a
symlink to a directory, rather than deleting the symlink itself.

We can also use that new flag in recursive_directory_iterator to ensure
that we don't follow symlinks if the follow_directory_symlink option is
not set.

This also moves an error check in filesystem::remove_all after the while
loop, so that errors from the directory_iterator constructor are
reproted, instead of continuing to the filesystem::remove call below.

libstdc++-v3/ChangeLog:

PR libstdc++/104161
* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check for
fdopendir.
* config.h.in: Regenerate.
* configure: Regenerate.
* src/c++17/fs_dir.cc (_Dir): Add nofollow flag to constructor
and pass it to base class constructor.
(directory_iterator): Pass nofollow flag to _Dir constructor.
(fs::recursive_directory_iterator::increment): Likewise.
* src/c++17/fs_ops.cc (do_remove_all): Use nofollow option for
directory_iterator constructor. Move error check outside loop.
* src/filesystem/dir-common.h (_Dir_base): Add nofollow flag to
constructor and when it's set use ::open with O_NOFOLLOW and
O_DIRECTORY.
* src/filesystem/dir.cc (_Dir): Add nofollow flag to constructor
and pass it to base class constructor.
(directory_iterator): Pass nofollow flag to _Dir constructor.
(fs::recursive_directory_iterator::increment): Likewise.
* src/filesystem/ops.cc (remove_all): Use nofollow option for
directory_iterator constructor. Move error check outside loop.

Fortran: MOLD argument to TRANSFER intrinsic having storage size zero

gcc/fortran/ChangeLog:

PR fortran/104227
* check.cc (gfc_calculate_transfer_sizes): Fix checking of arrays
passed as MOLD argument to the TRANSFER intrinsic for having
storage size zero.

gcc/testsuite/ChangeLog:

PR fortran/104227
* gfortran.dg/transfer_check_6.f90: New test.

Fortran: optional argument DIM for intrinsics NORM2, PARITY must be scalar

gcc/fortran/ChangeLog:

PR fortran/104212
* check.cc (gfc_check_norm2): Check that optional argument DIM is
scalar.
(gfc_check_parity): Likewise.

gcc/testsuite/ChangeLog:

PR fortran/104212
* gfortran.dg/argument_checking_26.f90: New test.

c++: deleted fn and noexcept inst [PR101532, PR104225]

Here when attempting to use B's implicitly deleted default constructor,
mark_used rightfully returns false, but for the wrong reason: it
tries to instantiate the synthesized noexcept specifier which then only
silently fails because get_defaulted_eh_spec suppresses diagnostics
for deleted functions.  This lack of diagnostics causes us to crash on
the first testcase below (thanks to the assert in finish_expr_stmt), and
silently accept the second testcase.

To fix this, this patch makes mark_used avoid attempting to instantiate
the noexcept specifier of a deleted function, so that we'll instead
directly reject (and diagnose) the function due to its deletedness.

PR c++/101532
PR c++/104225

gcc/cp/ChangeLog:

* decl2.cc (mark_used): Don't consider maybe_instantiate_noexcept
on a deleted function.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/nsdmi-template21.C: New test.
* g++.dg/cpp0x/nsdmi-template21a.C: New test.

c++: assignment to temporary [PR59950]

Given build_this of a TARGET_EXPR, cp_build_fold_indirect_ref returns the
TARGET_EXPR.  But that's the wrong value category for the result of the
defaulted class assignment operator, which returns an lvalue, so we need to
actually build the INDIRECT_REF.

PR c++/59950

gcc/cp/ChangeLog:

* call.cc (build_over_call): Use cp_build_indirect_ref.

gcc/testsuite/ChangeLog:

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

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.