Jonathan Wakely [Sat, 23 May 2020 17:40:53 +0000 (18:40 +0100)]
libstdc++: Remove incorrect static specifiers
These functions were originally static members of the path class, but
the 'static' specifiers were not removed when they were moved to
namespace scope. This causes ODR violations when the functions are
called from functions defined in the header. Change them to 'inline'
instead.
Backport from mainline
2020-05-23 Jonathan Wakely <jwakely@redhat.com>
Jonathan Wakely [Sat, 23 May 2020 17:29:33 +0000 (18:29 +0100)]
libstdc++: Fix function that can't be constexpr in C++11 (PR 95289)
The body of this function isn't just a return statement, so it can't be
constexpr until C++14.
Backport from mainline
2020-05-23 Jonathan Wakely <jwakely@redhat.com>
PR libstdc++/95289
* include/debug/helper_functions.h (__get_distance): Only declare
as a constexpr function for C++14 and up.
* testsuite/25_algorithms/copy/debug/95289.cc: New test.
Jonathan Wakely [Thu, 21 May 2020 06:47:17 +0000 (07:47 +0100)]
libstdc++: Avoid constraint recursion with iterator_traits (PR 93983)
Checking whether a filesystem::path constructor argument is an iterator
requires instantiating std::iterator_traits. In C++20 that checks for
satisfaction of std::iterator_traits constraints, which checks if the
type is copyable, which can end up recursing back to the path
constructor. The fix in LWG 3420 is to reorder the cpp17-iterator
concept's constraints to check if the type looks vaguely like an
iterator before checking copyable. That avoids the recursion for types
which definitely aren't iterators, but isn't foolproof.
Backport from mainline
2020-05-21 Jonathan Wakely <jwakely@redhat.com>
PR libstdc++/93983
* include/bits/iterator_concepts.h (__detail::__cpp17_iterator):
Reorder constraints to avoid recursion when constructors use
iterator_traits (LWG 3420).
* testsuite/24_iterators/customization_points/lwg3420.cc: New test.
Mark Eggleston [Thu, 7 May 2020 07:02:02 +0000 (08:02 +0100)]
Fortran : ProcPtr function results: 'ppr@' in error message PR39695
The value 'ppr@' is set in the name of result symbol, the actual
name of the symbol is in the procedure name symbol pointed
to by the result symbol's namespace (ns). When reporting errors for
symbols that have the proc_pointer attribute check whether the
result attribute is set and set the name accordingly.
Backported from master.
2020-05-20 Mark Eggleston <markeggleston@gcc.gnu.org>
gcc/fortran/
PR fortran/39695
* resolve.c (resolve_fl_procedure): Set name depending on
whether the result attribute is set. For PROCEDURE/RESULT
conflict use the name in sym->ns->proc_name->name.
* symbol.c (gfc_add_type): Add check for function and result
attributes use sym->ns->proc_name->name if both are set.
Where the symbol cannot have a type use the name in
sym->ns->proc_name->name.
2020-05-20 Mark Eggleston <markeggleston@gcc.gnu.org>
gcc/testsuite/
PR fortran/39695
* gfortran.dg/pr39695_1.f90: New test.
* gfortran.dg/pr39695_2.f90: New test.
* gfortran.dg/pr39695_3.f90: New test.
* gfortran.dg/pr39695_4.f90: New test.
H.J. Lu [Tue, 19 May 2020 21:42:12 +0000 (14:42 -0700)]
x86: Add FEATURE_AVX512VP2INTERSECT and update GFNI check
Add FEATURE_AVX512VP2INTERSECT to libgcc so that enum processor_features
in libgcc matches enum processor_features in i386-builtins.c. Update
GFNI check to support processors with SSE and AVX versions of GFNI.
Tobias Burnus [Tue, 19 May 2020 08:10:21 +0000 (10:10 +0200)]
[OpenMP] Fix 'omp exit data' for Fortran arrays (PR 94635)
Backport from mainline
2020-05-15 Tobias Burnus <tobias@codesourcery.com>
gcc/
PR middle-end/94635
* gimplify.c (gimplify_scan_omp_clauses): For MAP_TO_PSET with
OMP_TARGET_EXIT_DATA, use 'release:' unless the associated
item is 'delete:'.
Martin Sebor [Mon, 18 May 2020 22:04:56 +0000 (16:04 -0600)]
PR middle-end/94940 - spurious -Warray-bounds for a zero length array member of union
gcc/testsuite/ChangeLog:
PR middle-end/94940
* gcc.dg/Warray-bounds-61.c: New test.
gcc/ChangeLog:
PR middle-end/94940
* tree-vrp.c (vrp_prop::check_mem_ref): Remove unreachable code.
* tree.c (component_ref_size): Correct the handling or array members
of unions.
Drop a pointless test.
Rename a local variable.
Douglas Rupp [Mon, 18 May 2020 18:43:48 +0000 (11:43 -0700)]
Require powerpc_vsx_ok in gcc.target/powerpc/pr71763.c
We're getting an error when running this test on PowerPC VxWorks 7,
due to an unexpected warning:
| Excess errors:
| cc1: warning: '-mvsx' and '-mno-altivec' are incompatible
The warning comes from a combination of factors:
- The test itself uses -mvsx explicitly via the following directive:
// { dg-options "-O1 -mvsx" }
- Our toolchain was configured so as to make -mno-altivec
the default;
- These two options are mutually exclusive.
This commit adds a powerpc_vsx_ok dg-require-effective-target directive
to that test, and thus making it UNSUPPORTED instead.
Tested on PowerPC VxWorks 7. Also tested on PowerPC ELF as well,
a platform where we do not make -mno-altivec the default, to verify
that the test continues to run as usual in that case.
Iain Buclaw [Sun, 17 May 2020 16:49:19 +0000 (18:49 +0200)]
libphobos: Backport library fixes from mainline
- core.cpuid has been fixed to not use i7 detection on AMD processors.
- std.net.curl has been fixed to correctly handle HTTP/2 status lines.
- std.zip has had a test fixed to not rely on unzip being installed.
libphobos/ChangeLog:
PR d/95166
* libdruntime/core/cpuid.d (cpuidX86): Do not use i7 detection on AMD
processors.
(hasCPUID): Fix deprecated asm syntax.
PR d/95167
* src/std/zip.d (unittest): Skip test if unzip is not installed.
PR d/95168
* src/std/net/curl.d (HTTP.onReceiveHeader): Move status line parsing
to ...
(HTTP.parseStatusLine): ... here. New function. Add support for
parsing HTTP/2 status lines.
Iain Buclaw [Sun, 17 May 2020 14:25:35 +0000 (16:25 +0200)]
d: Fix ICE in verify_gimple_stmt, at tree-cfg.c:4959
Both array concat and array new expressions wrapped any temporaries
created into a BIND_EXPR. This does not work if an expression used to
construct the result requires scope destruction, which is represented by
a TARGET_EXPR with a clean-up, and a CLEANUP_POINT_EXPR at the
location where the temporaries logically go out of scope. The reason
for this not working is because the lowering of cleanup point
expressions does not traverse inside BIND_EXPRs to expand any gimple
cleanup expressions within.
The use of creating BIND_EXPR has been removed at both locations, and
replaced with a normal temporary variable that has initialization
delayed until its address is taken.
gcc/d/ChangeLog:
PR d/94970
* d-codegen.cc (force_target_expr): Move create_temporary_var
implementation inline here.
(create_temporary_var): Remove.
(maybe_temporary_var): Remove.
(bind_expr): Remove.
* d-convert.cc (d_array_convert): Use build_local_temp to generate
temporaries, and generate its assignment.
* d-tree.h (create_temporary_var): Remove.
(maybe_temporary_var): Remove.
(d_array_convert): Remove vars argument.
* expr.cc (ExprVisitor::visit (CatExp *)): Use build_local_temp to
generate temporaries, don't wrap them in a BIND_EXPR.
(ExprVisitor::visit (NewExp *)): Likewise.
Mark Eggleston [Thu, 7 May 2020 07:29:14 +0000 (08:29 +0100)]
Fortran : ICE in gfc_conv_array_constructor_expr PR93497
Invalid expressions, such as those involving array constructors,
used for the length of character types will cause an ICE.
2020-05-11 Mark Eggleston <markeggleston@gcc.gnu.org>
Backported from master
2020-05-13 Steven G. Kargl <kargl@gcc.gnu.org>
gcc/fortran/
PR fortran/93497
* decl.c (char_len_param_value): Check whether character
length expression is of type EXPR_OP and if so simplify it.
* resolve.c (resolve_charlen): Reject length if it has a
rank.
2020-05-11 Mark Eggleston <markeggleston@gcc.gnu.org>
Backported from master
2020-05-13 Mark Eggleston <markeggleston@gcc.gnu.org>
gcc/testsuite/
PR fortran/93497
* gfortran.dg/pr88025.f90: Change in wording of error.
* gfortran.dg/pr93497.f90: New test.
* gfortran.dg/pr93714_1.f90: Change in wording of errors.
* gfortran.dg/pr93714_2.f90: Change in wording of errors.
David Edelsohn [Thu, 30 Apr 2020 15:29:32 +0000 (11:29 -0400)]
rs6000: AIX long double builtins for 64 bit long double.
When long doubles are 64 bit, the AIX C library overrides the definitions
but GCC builtins point to 128 bit names. This patch overrides the
builtins for fmodl, frexpl, ldexpl and modfl to refer to the 64 bit symbols.
Backport from mainline
2020-05-04 Clement Chigot <clement.chigot@atos.net>
David Edelsohn <dje.gcc@gmail.com>
* config/rs6000/rs6000-call.c (rs6000_init_builtins): Override explicit
for fmodl, frexpl, ldexpl and modfl builtins.
Backported from mainline
2020-05-11 Tobias Burnus <tobias@codesourcery.com>
PR fortran/94672
* trans.h (gfc_conv_expr_present): Add use_saved_decl=false argument.
* trans-expr.c (gfc_conv_expr_present): Likewise; use DECL directly
and only if use_saved_decl is true, use the actual PARAM_DECL arg (saved
descriptor).
* trans-array.c (gfc_trans_dummy_array_bias): Set local 'arg.0'
variable to NULL if 'arg' is not present.
* trans-openmp.c (gfc_omp_check_optional_argument): Simplify by checking
'arg.0' instead of the true PARM_DECL.
(gfc_omp_finish_clause): Remove setting 'arg.0' to NULL.
Jonathan Wakely [Tue, 12 May 2020 08:54:24 +0000 (09:54 +0100)]
libstdc++: Make byte-sized std::fill_n a constant expression (PR 94933)
The overload for byte types uses memset and isn't constexpr. This adds
the specifier and uses std::is_constant_evaluated() to provide a
compile-time alternative.
Backport from mainline
2020-05-03 Jonathan Wakely <jwakely@redhat.com>
PR libstdc++/94933
* include/bits/stl_algobase.h (__fill_a1): Make overload for byte types
usable in constant expressions.
* testsuite/25_algorithms/fill_n/constexpr.cc: Test with bytes and
non-scalars.
Ian Lance Taylor [Mon, 11 May 2020 23:23:44 +0000 (16:23 -0700)]
syscall: append to environment in tests, don't clobber it
This is a partial backport of https://golang.org/cl/233318.
It's only a partial backport because part of the change was
already applied to libgo in CL 193497 as part of the update
to the Go 1.13beta1 release.
Mark Eggleston [Thu, 23 Apr 2020 09:33:14 +0000 (10:33 +0100)]
Fortran : Spurious warning message with -Wsurprising PR59107
This change is from a patch developed for gcc-5. The code
has moved on since then requiring a change to interface.c
2020-05-11 Mark Eggleston <markeggleston@gcc.gnu.org>
Backported from mainline
2020-05-11 Janus Weil <janus@gcc.gnu.org>
Dominique d'Humieres <dominiq@lps.ens.fr>
gcc/fortran/
PR fortran/59107
* gfortran.h: Rename field resolved as resolve_symbol_called
and assign two 2 bits instead of 1.
* interface.c (check_dtio_interface1): Use new field name.
(gfc_find_typebound_dtio_proc): Use new field name.
* resolve.c (gfc_resolve_intrinsic): Replace check of the formal
field with resolve_symbol_called is at least 2, if it is not
set the field to 2. (resolve_typebound_procedure): Use new field
name. (resolve_symbol): Use new field name and check whether it
is at least 1, if it is not set the field to 1.
Backported from mainline
2020-05-11 Mark Eggleston <markeggleston@gcc.gnu.org>
gcc/testsuite/
PR fortran/59107
* gfortran.dg/pr59107.f90: New test.
Iain Sandoe [Sun, 10 May 2020 13:20:13 +0000 (14:20 +0100)]
coroutines: Update TREE_SIDE_EFFECTS on inserted bind exprs.
There are several places where we insert bind expressions while
making the coroutine AST transforms. These should be marked as
having side-effects where relevant, which had been omitted. This
leads to at least one failure in the cppcoros test suite, where a loop
body is dropped in gimplification because it is not marked.
gcc/cp/ChangeLog:
2020-05-10 Iain Sandoe <iain@sandoe.co.uk>
Backported from mainline
2020-05-08 Iain Sandoe <iain@sandoe.co.uk>
PR c++/95003
* coroutines.cc (build_actor_fn): Ensure that bind scopes
are marked as having side-effects where necessary.
(replace_statement_captures): Likewise.
(morph_fn_to_coro): Likewise.
gcc/testsuite/ChangeLog:
2020-05-10 Iain Sandoe <iain@sandoe.co.uk>
Backported from mainline
2020-05-08 Iain Sandoe <iain@sandoe.co.uk>
PR c++/95003
* g++.dg/coroutines/torture/pr95003.C: New test.
Marek Polacek [Fri, 8 May 2020 15:04:29 +0000 (11:04 -0400)]
c++: Parenthesized-init of aggregates accepts invalid code [PR94885]
Here we have (conceptually *) something like
struct B { };
struct D : B { };
D(0); // invalid
and in C++20 the ()-initialization has created a { 0 } constructor that
it tries to initialize an object of type D with. We should reject
initializing an object of type B from 0, but we wrongly accept it because
process_init_constructor_record skips initializers for empty bases/fields:
if (DECL_SIZE (field) && integer_zerop (DECL_SIZE (field))
&& !TREE_SIDE_EFFECTS (next))
/* Don't add trivial initialization of an empty base/field to the
constructor, as they might not be ordered the way the back-end
expects. */
continue;
but here 'next' was error_mark_node, returned by massage_elt_init, so we
wound up with { } which would validly value-initialize the object.
[*] Usually digest_init in build_new_method_call_1 would detect this,
but in this case the instance is is_dummy_object and we don't call
digest just yet.
PR c++/94885
* typeck2.c (process_init_constructor_record): Return PICFLAG_ERRONEOUS
if an initializer element was erroneous.
Jakub Jelinek [Fri, 8 May 2020 07:37:09 +0000 (09:37 +0200)]
tree: Avoid variable sharing in get_narrower [PR94724]
On Thu, May 07, 2020 at 02:45:29PM +0200, Thomas Schwinge wrote:
> >>+ for (tree op = win; TREE_CODE (op) == COMPOUND_EXPR;
>
> ..., and new 'op' variable here.
>
> >>+ op = TREE_OPERAND (op, 1))
> >>+ v.safe_push (op);
> >>+ FOR_EACH_VEC_ELT_REVERSE (v, i, op)
> >>+ ret = build2_loc (EXPR_LOCATION (op), COMPOUND_EXPR,
> >>+ TREE_TYPE (win), TREE_OPERAND (op, 0),
> >>+ ret);
> >>+ return ret;
> >> }
> >> while (TREE_CODE (op) == NOP_EXPR)
> >> {
There is no reason for the shadowing and op at this point acts as a
temporary and will be overwritten in FOR_EACH_VEC_ELT_REVERSE anyway.
So, we can just s/tree // here.
2020-05-08 Jakub Jelinek <jakub@redhat.com>
PR middle-end/94724
* tree.c (get_narrower): Reuse the op temporary instead of
shadowing it.
Jonathan Wakely [Thu, 7 May 2020 16:39:56 +0000 (17:39 +0100)]
libstdc++: Replace deduced return type in ranges::iter_move (PR 92894)
The deduced return type causes the instantiation of the function body,
which can then require the instantiation of std::projected::operator*
which is intentionally not defined.
This patch uses a helper trait to define the return type, so that the
function body doesn't need to be instantiated.
Unlike on the master branch, this backport to gcc-10 does not change the
iter_rvalue_reference_t alias template and __indirectly_readable_impl
concept to use the new trait.
Backport from mainline
2020-05-01 Jonathan Wakely <jwakely@redhat.com>
Patrick Palka <ppalka@redhat.com>
PR libstdc++/92894
* include/bits/iterator_concepts.h (ranges::__cust_imove::_IMove):
Add trait to determine return type and an alias for it.
(ranges::__cust_imove::_IMove::operator()): Use __result instead of
deduced return type.
* testsuite/24_iterators/customization_points/92894.cc: New test.
* testsuite/24_iterators/indirect_callable/92894.cc: New test.
Marek Polacek [Thu, 7 May 2020 18:34:15 +0000 (14:34 -0400)]
c++: ICE in value_dependent_expression_p in C++98 mode [PR94938]
Here we ICE with -std=c++98 since the newly added call to uses_template_parms
(r10-6357): we hit
26530 gcc_assert (cxx_dialect >= cxx11
26531 || INTEGRAL_OR_ENUMERATION_TYPE_P (type));
and TYPE is a record type. The problem is that the argument to
value_dependent_expression_p does not satisfy potential_constant_expression
which it must, as the comment explains. I thought about fixing this in
uses_template_parms -- only call v_d_e_p if p_c_e is true, but in this
case we want to also suppress the warnings if we don't have a constant
expression. I couldn't simply check TREE_CONSTANT as in
compute_array_index_type_loc, because then we'd stop warning in the new
Wtype-limits3.C test.
Fixed by using type_dependent_expression_p_push instead. This means
that we won't suppress the warnings for value-dependent expressions that
aren't type-dependent, e.g. sizeof (T). This only seems to make a
difference for -Wdiv-by-zero, now tested in Wdiv-by-zero-3.C, where I
think it's reasonable to warn. It could make -Wtautological-compare
warn more, but that warning doesn't trigger when it gets constant arguments.
Wtype-limits4.C is a test reduced from poly-int.h and it tests a scenario
that was missing in our testsuite.
This patch also moves the warning_sentinels after the RECURs -- we mean
to use them for build_x_binary_op purposes only.
PR c++/94938
* pt.c (tsubst_copy_and_build): Call type_dependent_expression_p_push
instead of uses_template_parms. Move the warning_sentinels after the
RECURs.
* g++.dg/warn/Wdiv-by-zero-3.C: New test.
* g++.dg/warn/Wtype-limits4.C: New test.
* g++.dg/warn/template-2.C: New test.
* g++.old-deja/g++.pt/crash10.C: Add dg-warning.
Uros Bizjak [Thu, 7 May 2020 15:14:23 +0000 (17:14 +0200)]
alpha: Implement the PR94780 fix for alpha.
Essentially the same fix as for x86.
2020-05-07 Uroš Bizjak <ubizjak@gmail.com>
gcc/
* config/alpha/alpha.c (alpha_atomic_assign_expand_fenv): Use
TARGET_EXPR instead of MODIFY_EXPR for the first assignments to
fenv_var and new_fenv_var.
The testcase in the current form doesn't FAIL without the patch on
x86_64-linux unless also testing with -m32; as that the 64-bit testing
on that target is probably way more common, and we can use also attributes
that FAIL without the patch with -m64, the following patch adjusts the
test, so that it FAILs without the patch for both -m64 and -m32 (but not
-mx32) and PASSes with the patch.
2020-05-07 Jakub Jelinek <jakub@redhat.com>
PR c++/94946
* g++.dg/ext/attr-parm-1.C: Enable the test also for lp64 x86, use
sysv_abi and ms_abi attributes in that case instead of fastcall and
no attribute.
Jakub Jelinek [Wed, 6 May 2020 21:38:13 +0000 (23:38 +0200)]
c++: Avoid strict_aliasing_warning on dependent types or expressions [PR94951]
The following testcase gets a bogus warning during build_base_path,
when cp_build_indirect_ref* calls strict_aliasing_warning with a dependent
expression. IMHO calling get_alias_set etc. on dependent types feels wrong
to me, we should just defer the warnings in those cases until instantiation
and only handle the cases where neither type nor expr are dependent.
2020-05-06 Jakub Jelinek <jakub@redhat.com>
PR c++/94951
* typeck.c (cp_strict_aliasing_warning): New function.
(cp_build_indirect_ref_1, build_reinterpret_cast_1): Use
it instead of strict_aliasing_warning.
* g++.dg/warn/Wstrict-aliasing-bogus-tmpl.C: New test.
Jakub Jelinek [Wed, 6 May 2020 21:36:31 +0000 (23:36 +0200)]
c++: Don't synthesize sfk_comparison method multiple times [PR94907]
On the following testcase we ICE, because synthesize_method is called twice
on the same sfk_comparison method fndecl, the first time it works fine
because start_preparsed_function in that case sets both
current_function_decl and cfun, but second time it is called it only sets
the former and keeps cfun NULL, so we ICE when trying to store
current_function_returns_value.
I think it is just wrong to call synthesize_method multiple times, and most
synthesize_method callers avoid that by not calling it if DECL_INITIAL is
already set, so this patch does that too.
2020-05-06 Jakub Jelinek <jakub@redhat.com>
PR c++/94907
* method.c (defaulted_late_check): Don't call synthesize_method
on constexpr sfk_comparison if it has been called on it already.
Jakub Jelinek [Wed, 6 May 2020 07:40:33 +0000 (09:40 +0200)]
riscv: Fix up riscv_atomic_assign_expand_fenv [PR94950]
Similarly to the fixes on many other targets, riscv needs to use TARGET_EXPR
to avoid having the create_tmp_var_raw temporaries without proper DECL_CONTEXT
and not mentioned in local decls.
2020-05-06 Jakub Jelinek <jakub@redhat.com>
PR target/94950
* config/riscv/riscv-builtins.c (riscv_atomic_assign_expand_fenv): Use
TARGET_EXPR instead of MODIFY_EXPR for first assignment to old_flags.
Jakub Jelinek [Wed, 6 May 2020 07:31:19 +0000 (09:31 +0200)]
combine: Don't replace SET_SRC with REG_EQUAL note content if SET_SRC has side-effects [PR94873]
There were some discussions about whether REG_EQUAL notes are valid on insns with a single
set which contains auto-inc-dec side-effects in the SET_SRC and the majority thinks that
it should be valid. So, this patch fixes the combiner to punt in that case, because otherwise
the auto-inc-dec side-effects from the SET_SRC are lost.
2020-05-06 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/94873
* combine.c (combine_instructions): Don't optimize using REG_EQUAL
note if SET_SRC (set) has side-effects.
Jakub Jelinek [Tue, 5 May 2020 09:33:47 +0000 (11:33 +0200)]
x86: Fix *vec_dupv4hi constraints [PR94942]
This insn and split splits into HI->V?HImode broadcast for avx2 and later,
but either the operands need to be %xmm0-%xmm15 (i.e. VEX encoded insn), or
the insn needs both AVX512BW and AVX512VL.
Now, Yv constraint is v for AVX512VL and x otherwise, so for -mavx512vl -mno-avx512bw
we ICE if we end up with a %xmm16+ register from RA.
Yw constraint is v for AVX512VL and AVX512BW and nothing otherwise, so
in this pattern we actually need xYw.
2020-05-05 Jakub Jelinek <jakub@redhat.com>
PR target/94942
* config/i386/mmx.md (*vec_dupv4hi): Use xYw constraints instead of Yv.
Jakub Jelinek [Mon, 4 May 2020 07:31:27 +0000 (09:31 +0200)]
diagnostics: get_option_html_page fixes
While testing the --with-documentation-root-url= changes, I run into
[Wreturn-type] URL pointing to gfortran documentation where it obviously
isn't documented. The following patch updates the list of options to match
reality (on the other side -Wconversion-extra is gfortran only option
documented in gfortran.texi).
Or, perhaps better use the attached patch instead, which doesn't have a
hardcoded list and instead uses the flags? I went through options.c
and the updated list of options matches exactly the cases where CL_Fortran
is set for "-W*" options together with CL_C and/or CL_CXX (ok, there is also
-Wall and -Wextra, but hopefully we don't emit [Wall] or [Wextra] for
anything).
2020-05-04 Jakub Jelinek <jakub@redhat.com>
* opts.c (get_option_html_page): Instead of hardcoding a list of
options common between C/C++ and Fortran only use gfortran/
documentation for warnings that have CL_Fortran set but not
CL_C or CL_CXX.
Jakub Jelinek [Thu, 30 Apr 2020 19:48:30 +0000 (21:48 +0200)]
c: Fix ICE with _Atomic side-effect in nested fn param decls [PR94842]
If there are _Atomic side-effects in the parameter declarations
of non-nested function, when they are parsed, current_function_decl is
NULL, the create_artificial_label created labels during build_atomic* are
then adjusted by store_parm_decls through set_labels_context_r callback.
Unfortunately, if such thing happens in nested function parameter
declarations, while those decls are parsed current_function_decl is the
parent function (and am not sure it is a good idea to temporarily clear it,
some code perhaps should be aware it is in a nested function, or it can
refer to variables from the parent function etc.) and that means
store_param_decls through set_labels_context_r doesn't adjust anything.
As those labels are emitted in the nested function body rather than in the
parent, I think it is ok to override the context in those cases.
2020-04-30 Jakub Jelinek <jakub@redhat.com>
PR c/94842
* c-decl.c (set_labels_context_r): In addition to context-less
LABEL_DECLs adjust also LABEL_DECLs with context equal to
parent function if any.
(store_parm_decls): Adjust comment.
Kyrylo Tkachov [Wed, 6 May 2020 15:23:38 +0000 (16:23 +0100)]
[AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc
This version of the fix uses __getauxval instead of getauxval.
The whole thing is guarded simply on __gnu_linux__.
__getauxval was introduced in 2.16 but the aarch64 port was added in 2.17 so in practice I expect all aarch64 glibcs to support __getauxval.
Bootstrapped and tested on aarch64-none-linux-gnu.
Also tested on aarch64-none-elf.
Rainer Orth [Wed, 6 May 2020 12:07:03 +0000 (14:07 +0200)]
libstdc++: Update Solaris baselines for GCC 10.1
I just remembered that the libstdc++ ABI baselines haven't been updated
for the GCC 10 release yet. This patch corrects this for Solaris/SPARC
and x86.
Created on master with make new-abi-baseline on i386-pc-solaris2.11 and
sparc-sun-solaris2.11, bootstrapped on gcc-10 branch without regressions.
Jakub Jelinek [Wed, 6 May 2020 09:21:28 +0000 (11:21 +0200)]
libstdc++: Update {x86_64,i?86,powerpc64,s390x,aarch64}-linux baselines for GCC 10.1
On Wed, May 06, 2020 at 10:49:13AM +0200, Rainer Orth wrote:
> I just remembered that the libstdc++ ABI baselines haven't been updated
> for the GCC 10 release yet. This patch corrects this for Solaris/SPARC
> and x86.
Oops, here are the updates from Fedora packages built during the weekend.
Rainer Orth [Wed, 6 May 2020 08:13:09 +0000 (10:13 +0200)]
doc: Update install.texi for GCC 10 on Solaris
This patch updates install.texi for GCC 10 on Solaris. It includes some
general cleanup and updates and includes a couple of caveats, some of
them found when testing GCC 10.1.0 RC1 with only the bundled tools.
The reference to TGCware on the binaries page is gone because they only
provide binaries up to Solaris 9.
The note about configuring 64-bit Solaris/SPARC compilers with
--build=sparcv9-sun-solaris2.11 became necessary because upstream
config.guess silently reverted my patch to automatically detect this. We
already had a bug report about a comparison failure caused by this issue.
Tested with make doc/gccinstall.info and doc/gccinstall.pdf and
inspection of the resulting files.
* doc/install.texi: Replace Sun with Solaris as appropriate.
(Tools/packages necessary for building GCC, Perl version between
5.6.1 and 5.6.24): Remove Solaris 8 reference.
(Installing GCC: Binaries, Solaris 2 (SPARC, Intel)): Remove
TGCware reference.
(Specific, i?86-*-solaris2*): Update version references for
Solaris 11.3 and later. Remove gas 2.26 caveat.
(Specific, *-*-solaris2*): Update version references for
Solaris 11.3 and later. Remove boehm-gc reference.
Document GMP, MPFR caveats on Solaris 11.3.
(Specific, sparc-sun-solaris2*): Update Solaris 9 references.
(Specific, sparc64-*-solaris2*): Likewise.
Document --build requirement.
Rainer Orth [Tue, 5 May 2020 08:46:20 +0000 (10:46 +0200)]
build: Fix 32-bit TLS detection with 64-bit-default gas on Solaris/x86
I've recently tested i386-pc-solaris2.11 bootstrap on Solaris 11/x86
with only the bundled tools (using /usr/gnu/bin/as from binutils 2.30 in
this case). It failed compiling libgo/runtime/proc.c, creating invalid
assembly:
proc.s: Assembler messages:
proc.s:2092: Error: junk at end of line, first unrecognized character is `*'
.globl __emutls_v.*runtime.g
and several more errors. This is completely unexpected since Solaris
does support TLS. It turned out that 32-bit TLS detection in
gcc/configure had failed:
configure:25145: checking assembler for thread-local storage support
configure:25158: /usr/gnu/bin/as --fatal-warnings -o conftest.o conftest.s >&5
conftest.s: Assembler messages:
conftest.s:6: Error: relocated field and relocation type differ in signedness
conftest.s:7: Error: @TLSLDM reloc is not supported with 64-bit output format
conftest.s:7: Error: junk `@tlsldm' after expression
which isn't unexpected given that the bundled gas has been configured
for x86_64-pc-solaris2.11, i.e. 64-bit-default.
This is easily fixed by explicitly passing --32 for the 32-bit case,
matching what is done for the 64-bit test.
Tested on i386-pc-solaris2.11 with 32-bit-default and 64-bit-default gas
as well as with /usr/bin/as, always correctly detecting TLS support.
* configure.ac <i[34567]86-*-*>: Add --32 to tls_as_opt on Solaris.
* configure: Regenerate.
Jonathan Wakely [Mon, 4 May 2020 21:54:25 +0000 (22:54 +0100)]
libstdc++: Fix broken link to SGI STL FAQ
The previous URL to an entry in the wayback machine now redirects to a
page saying "SGI.com Tech Archive Resources now retired" so use an older
entry from the archive.
* doc/xml/faq.xml: Use working link for SGI STL FAQ.
* doc/html/*: Regenerate.
Eric Botcazou [Mon, 4 May 2020 21:32:39 +0000 (23:32 +0200)]
Fix Ada bootstrap on Cygwin64
This fixes two compilation errors preventing bootstrap with Ada
on x86_64-pc-cygwin.
2020-05-04 Mikael Pettersson <mikpelinux@gmail.com>
PR bootstrap/94918
* mingw32.h: Prevent windows.h from including emmintrin.h on Cygw64.
* s-oscons-tmplt.c (Serial_Port_Descriptor): Use System.Win32.HANDLE
also on Cygwin.
internal-fn: Avoid dropping the lhs of some calls [PR94941]
create_output_operand coerces an output operand to the insn's
predicates, using a suggested rtx location if convenient.
But if that rtx location is actually required rather than
optional, the builder of the insn has to emit a move afterwards.
(We could instead add a new interface that does this automatically,
but that's future work.)
This PR shows that we were failing to emit the move for some of the
vector load internal functions. I think there are other routines in
internal-fn.c that potentially have the same problem, but this patch is
supposed to be a conservative subset suitable for backporting to GCC 10.
2020-05-04 Richard Sandiford <richard.sandiford@arm.com>
gcc/
PR middle-end/94941
* internal-fn.c (expand_load_lanes_optab_fn): Emit a move if the
chosen lhs is different from the gcall lhs.
(expand_mask_load_optab_fn): Likewise.
(expand_gather_load_optab_fn): Likewise.
gcc/testsuite/
PR middle-end/94941
* gcc.target/aarch64/sve/acle/general/unoptimized_1.c: New test.
Jakub Jelinek [Sat, 2 May 2020 10:09:04 +0000 (12:09 +0200)]
tilegx: Unbreak build
../../gcc/config/tilegx/tilegx.md:4109:1: ambiguous attribute 'n'; could be '1' (via 'I124MODE:n') or '4' (via 'I48MODE:n')
../../gcc/config/tilegx/tilegx.md:4109:1: ambiguous attribute 'n'; could be '1' (via 'I124MODE:n') or '' (via 'I48MODE:n')
../../gcc/config/tilegx/tilegx.md:4109:1: ambiguous attribute 'n'; could be '2' (via 'I124MODE:n') or '4' (via 'I48MODE:n')
../../gcc/config/tilegx/tilegx.md:4109:1: ambiguous attribute 'n'; could be '2' (via 'I124MODE:n') or '' (via 'I48MODE:n')
../../gcc/config/tilegx/tilegx.md:4109:1: ambiguous attribute 'n'; could be '4' (via 'I124MODE:n') or '' (via 'I48MODE:n')
The insn name already uses <I124MODE:n> explicitly, just the preparation
stmts don't, and as it creates a I124MODE lowpart subreg of a word mode
register, <I124MODE:n> seems obviously correct.
2020-05-02 Jakub Jelinek <jakub@redhat.com>
* config/tilegx/tilegx.md
(insn_stnt<I124MODE:n>_add<I48MODE:bitsuffix>): Use <I124MODE:n>
rather than just <n>.
cse: Use simplify_replace_fn_rtx to process notes [PR94740]
cse_process_notes did a very simple substitution, which in the wrong
circumstances could create non-canonical RTL and invalid MEMs.
Various sticking plasters have been applied to cse_process_notes_1
to handle cases like ZERO_EXTEND, SIGN_EXTEND and UNSIGNED_FLOAT,
but I think this PR is a plaster too far.
The code is trying hard to avoid creating unnecessary rtl, which of
course is a good thing. If we continue to do that, then we can end
up changing subexpressions while keeping the containing rtx.
This in turn means that validate_change will be a no-op on the
containing rtx, even if its contents have changed. So in these
cases we have to apply validate_change to the individual subexpressions.
On the other hand, if we always apply validate_change to the
individual subexpressions, we'll end up calling validate_change
on something before it has been simplified and canonicalised.
And that's one of the situations we're trying to avoid.
There might be a middle ground in which we queue the validate_changes
as part of a group, and so can cancel the pending validate_changes
for subexpressions if there's a change in the outer expression.
But that seems even more ad-hoc than the current code.
It would also be quite an invasive change.
I think the best thing is just to hook into the existing
simplify_replace_fn_rtx function, keeping the REG and MEM handling
from cse_process_notes_1 essentially unchanged. It can generate
more redundant rtl when a simplification takes place, but it has
the advantage of being relative well-used code (both directly
and via simplify_replace_rtx).
2020-04-30 Richard Sandiford <richard.sandiford@arm.com>
gcc/
PR rtl-optimization/94740
* cse.c (cse_process_notes_1): Replace with...
(cse_process_note_1): ...this new function, acting as a
simplify_replace_fn_rtx callback to process_note. Handle only
REGs and MEMs directly. Validate the MEM if cse_process_note
changes its address.
(cse_process_notes): Replace with...
(cse_process_note): ...this new function.
(cse_extended_basic_block): Update accordingly, iterating over
the register notes and passing individual notes to cse_process_note.
Martin Jambor [Thu, 30 Apr 2020 15:59:00 +0000 (17:59 +0200)]
ipa: Cgraph verification fix (PR 94856)
PR 94856 is a call graph verifier error. We have a method which (in
the course of IPA-CP) loses its this pointer because it is unused and
the pass then does not clone all the this adjusting thunks and just
makes the calls go straight to the new clone - and then the verifier
complains that the edge does not seem to point to a clone of what it
used to. This looked weird because the verifier actually has logic
detecting this case but it turns out that it is confused by inliner
body-saving mechanism which invents a new decl for the base function.
Making the inlining body-saving mechanism to correctly set
former_clone_of allows us to detect this case too. Then we pass this
particular round of verification but the subsequent one fails because
we have inlined the function into its former thunk - which
subsequently does not have any callees, but the verifier still access
them and segfaults. Therefore the patch also adds a test whether the
a former hunk even has any call.
2020-04-30 Martin Jambor <mjambor@suse.cz>
PR ipa/94856
* cgraph.c (clone_of_p): Also consider thunks whih had their bodies
saved by the inliner and thunks which had their call inlined.
* ipa-inline-transform.c (save_inline_function_body): Fill in
former_clone_of of new body holders.
c++ ICE with nested requirement as default tpl parm[PR94827]
Template headers are not incrementally updated as we parse its parameters.
We maintain a dummy level until the closing > when we replace the dummy with
a real parameter set. requires processing was expecting a properly populated
arg_vec in current_template_parms, and then creates a self-mapping of parameters
from that. But we don't need to do that, just teach map_arguments to look at
TREE_VALUE when args is NULL.
* constraint.cc (map_arguments): If ARGS is null, it's a
self-mapping of parms.
(finish_nested_requirement): Do not pass argified
current_template_parms to normalization.
(tsubst_nested_requirement): Don't assert no template parms.
Jonathan Wakely [Thu, 30 Apr 2020 14:47:52 +0000 (15:47 +0100)]
libstdc++: Avoid errors in allocator's noexcept-specifier (PR 89510)
This fixes a regression due to the conditional noexcept-specifier on
std::allocator::construct and std::allocator::destroy, as well as the
corresponding members of new_allocator, malloc_allocator, and
allocator_traits. Those noexcept-specifiers were using expressions which
might be ill-formed, which caused errors outside the immediate context
when checking for the presence of construct and destroy in SFINAE
contexts.
The fix is to use the is_nothrow_constructible and
is_nothrow_destructible type traits instead, because those traits are
safe to use even when the construction/destruction itself is not valid.
The is_nothrow_constructible trait will be false for a type that is not
also nothrow-destructible, even if the new-expression used in the
construct function body is actually noexcept. That's not the correct
answer, but isn't a problem because providing a noexcept-specifier on
these functions is not required by the standard anyway. If the answer is
false when it should be true, that's suboptimal but OK (unlike giving
errors for valid code, or giving a true answer when it should be false).
PR libstdc++/89510
* include/bits/alloc_traits.h (allocator_traits::_S_construct)
(allocator_traits::_S_destroy)
(allocator_traits<allocator<T>>::construct): Use traits in
noexcept-specifiers.
* include/bits/allocator.h (allocator<void>::construct)
(allocator<void>::destroy): Likewise.
* include/ext/malloc_allocator.h (malloc_allocator::construct)
(malloc_allocator::destroy): Likewise.
* include/ext/new_allocator.h (new_allocator::construct)
(new_allocator::destroy): Likewise.
* testsuite/20_util/allocator/89510.cc: New test.
* testsuite/ext/malloc_allocator/89510.cc: New test.
* testsuite/ext/new_allocator/89510.cc: New test.
coroutines: Fix handling of artificial vars [PR94886]
The testcase ICEs because the range-based for generates three
artificial variables that need to be allocated to the coroutine
frame but, when walking the BIND_EXR that contains these, the
DECL_INITIAL for one of them refers to an entry appearing later,
which means that the frame entry hasn't been allocated when that
INITIAL is walked.
The solution is to defer walking the DECL_INITIAL/SIZE etc. until
all the BIND_EXPR vars have been processed.
gcc/cp/ChangeLog:
2020-04-30 Iain Sandoe <iain@sandoe.co.uk>
PR c++/94886
* coroutines.cc (transform_local_var_uses): Defer walking
the DECL_INITIALs of BIND_EXPR vars until all the frame
allocations have been made.
gcc/testsuite/ChangeLog:
2020-04-30 Iain Sandoe <iain@sandoe.co.uk>
PR c++/94886
* g++.dg/coroutines/pr94886-folly-3.C: New test.
coroutines: Fix handling of target cleanup exprs [PR94883]
The problem here is that target cleanup expressions have been
added to the initialisers for the awaitable (and returns of
non-trivial values from await_suspend() calls. This is because
the expansion of the co_await into its control flow is not
apparent to the machinery adding the target cleanup expressions.
The solution being tested is simply to recreate target expressions
as the co_awaits are lowered. Teaching the machinery to handle
walking co_await expressions in different ways at different points
(outside the coroutine transformation) seems overly complex.
gcc/cp/ChangeLog:
2020-04-30 Iain Sandoe <iain@sandoe.co.uk>
PR c++/94883
* coroutines.cc (register_awaits): Update target
expressions for awaitable and suspend handle
initializers.
gcc/testsuite/ChangeLog:
2020-04-30 Iain Sandoe <iain@sandoe.co.uk>
PR c++/94883
* g++.dg/coroutines/pr94883-folly-2.C: New test.
git://gcc.gnu.org / gcc.git / log