Jason Merrill [Mon, 25 May 2020 22:04:39 +0000 (18:04 -0400)]
c++: constexpr and lambda capture [PR90212]
This is the same issue as PR86429, just in potential_constant_expression_1
rather than cxx_eval_constant_expression. As in that case, when we're
trying to evaluate a constant expression within a lambda, we don't have a
constant closure object to refer to, but we can try to refer directly to the
captured variable.
gcc/cp/ChangeLog
2020-05-05 Jason Merrill <jason@redhat.com>
PR c++/90212
* constexpr.c (potential_constant_expression_1): In a lambda
function, consider a captured variable directly.
Jason Merrill [Mon, 25 May 2020 22:04:39 +0000 (18:04 -0400)]
c++: Local class DMI using local static [PR90749]
For default member initializers in templates it's important to push into the
right context during get_nsdmi. But for a local class that's not possible,
and trying leaves the function context we need to be in, so don't try.
gcc/cp/ChangeLog
2020-05-01 Jason Merrill <jason@redhat.com>
PR c++/90479
* init.c (get_nsdmi): Don't push_to_top_level for a local class.
Jason Merrill [Mon, 25 May 2020 22:04:39 +0000 (18:04 -0400)]
c++: -fmerge-all-constants vs. destructors [PR91529]
cp_finish_decl avoids setting TREE_READONLY on TREE_STATIC variables that
have non-constant construction or destruction, but -fmerge-all-constants was
converting an automatic variable to static while leaving TREE_READONLY set.
Fixed by clearing the flag in cp_finish_decl in the presence of
-fmerge-all-constants.
gcc/cp/ChangeLog
2020-05-01 Jason Merrill <jason@redhat.com>
PR c++/91529
* decl.c (cp_finish_decl): Also clear TREE_READONLY if
-fmerge-all-constants.
Jason Merrill [Mon, 25 May 2020 22:04:39 +0000 (18:04 -0400)]
c++: generic lambda and -fsanitize=vla-bound [PR93822]
Within the generic lambda the VLA capture proxy VAR_DECL has DECL_VALUE_EXPR
which is a NOP_EXPR to the VLA type of the proxy. The problem here was that
when instantiating we were tsubsting that type twice, once for the type of
the DECL and once for the type of the NOP_EXPR, and getting two
different (though equivalent) types. Then gimplify_type_sizes fixed up the
type of the DECL, but that didn't affect the type of the NOP_EXPR, leading
to sadness.
Fixed by directly reusing the type from the DECL.
gcc/cp/ChangeLog
2020-05-01 Jason Merrill <jason@redhat.com>
PR c++/93822
* pt.c (tsubst_decl): Make sure DECL_VALUE_EXPR continues to have
the same type as the variable.
gcc/ChangeLog:
PR target/95255
* config/i386/i386.md (<rounding_insn><mode>2): Do not try to
expand non-sse4 ROUND_ROUNDEVEN rounding via SSE support routines.
gcc/testsuite/ChangeLog:
PR target/95255
* gcc.target/i386/pr95255.c: New test.
Iain Sandoe [Sun, 24 May 2020 11:18:19 +0000 (12:18 +0100)]
Darwin: Make sanitizer local vars linker-visible.
Another case where we need a linker-visible symbol in order
to preserve the ld64 atom model. If these symbols are emitted
as 'local' the linker cannot see that they are separate from any
global weak entry that precedes them. This will cause the linker
to complain that there is (apparently) direct access to such a
weak global.
This is a short-term fix for the problem - ideally we need a more
generic handling for all the relevant cases.
Iain Sandoe [Sun, 24 May 2020 11:09:10 +0000 (12:09 +0100)]
coroutines: Implicitly movable objects should use move CTORs for co_return.
This is a case where the standard contains conflicting information.
after discussion between implementators, the accepted intent is of
[class.copy.elision]. This amends the handling of co_return statements
to follow that.
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.
projects / people / ms / gcc.git / log
