Jakub Jelinek [Thu, 31 Dec 2020 10:06:56 +0000 (11:06 +0100)]
wide-int: Fix wi::to_mpz [PR98474]
The following testcase is miscompiled, because niter analysis miscomputes
the number of iterations to 0.
The problem is that niter analysis uses mpz_t (wonder why, wouldn't
widest_int do the same job?) and when wi::to_mpz is called e.g. on the
TYPE_MAX_VALUE of __uint128_t, it initializes the mpz_t result with wrong
value.
wi::to_mpz has code to handle negative wide_ints in signed types by
inverting all bits, importing to mpz and complementing it, which is fine,
but doesn't handle correctly the case when the wide_int's len (times
HOST_BITS_PER_WIDE_INT) is smaller than precision when wi::neg_p.
E.g. the 0xffffffffffffffffffffffffffffffff TYPE_MAX_VALUE is represented
in wide_int as 0xffffffffffffffff len 1, and wi::to_mpz would create
0xffffffffffffffff mpz_t value from that.
This patch handles it by adding the needed -1 host wide int words (and has
also code to deal with precision that aren't multiple of
HOST_BITS_PER_WIDE_INT).
2020-12-31 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/98474
* wide-int.cc (wi::to_mpz): If wide_int has MSB set, but type
is unsigned and excess negative, append set bits after len until
precision.
Jakub Jelinek [Mon, 21 Dec 2020 23:01:34 +0000 (00:01 +0100)]
gimplify: Gimplify value in gimplify_init_ctor_eval_range [PR98353]
gimplify_init_ctor_eval_range wasn't gimplifying value, so if it wasn't
a gimple val, verification at the end of gimplification would ICE (or with
release checking some random pass later on would ICE or misbehave).
2020-12-21 Jakub Jelinek <jakub@redhat.com>
PR c++/98353
* gimplify.c (gimplify_init_ctor_eval_range): Gimplify value before
storing it into cref.
Jakub Jelinek [Mon, 21 Dec 2020 07:59:05 +0000 (08:59 +0100)]
openmp: Fix up handling of addressable temporaries in simd lb, b and incr expressions [PR98383]
For simd, we have code to artificially add locally defined variables into
private clauses if they are addressable, so that omplower turns them into
"omp simd array" variables. As the testcase shows, this is undesirable if
those temporaries only show in the lb, b or incr expressions and nowhere else,
if it is just used there, we really want normal scalar temporaries.
This patch implements that by making sure we don't set for those GOVD_LOCAL-ish
temporaries turned into GOVD_PRIVATE the GOVD_SEEN flag during gimplification
of the lb, b and incr expressions, which means that the private clause isn't
added for those.
2020-12-21 Jakub Jelinek <jakub@redhat.com>
PR c++/98383
* gimplify.c (struct gimplify_omp_ctx): Add in_for_exprs flag.
(gimple_add_tmp_var): For addressable temporaries appearing in
simd lb, b or incr expressions, don't add a private clause unless
it is seen also outside of those expressions in the simd body.
(omp_notice_variable): Likewise.
(gimplify_omp_for): Set and reset in_for_exprs around gimplification
of lb, b or incr expressions.
Jakub Jelinek [Fri, 18 Dec 2020 20:43:20 +0000 (21:43 +0100)]
openmp: Don't optimize shared to firstprivate on task with depend clause
The attached testcase is miscompiled, because we optimize shared clauses
to firstprivate when task body can't modify the variable even when the
task has depend clause. That is wrong, because firstprivate means the
variable will be copied immediately when the task is created, while with
depend clause some other task might change it later before the dependencies
are satisfied and the task should observe the value only after the change.
2020-12-18 Jakub Jelinek <jakub@redhat.com>
* gimplify.c (struct gimplify_omp_ctx): Add has_depend member.
(gimplify_scan_omp_clauses): Set it to true if OMP_CLAUSE_DEPEND
appears on OMP_TASK.
(gimplify_adjust_omp_clauses_1, gimplify_adjust_omp_clauses): Force
GOVD_WRITTEN on shared variables if task construct has depend clause.
Jakub Jelinek [Sat, 12 Dec 2020 07:36:02 +0000 (08:36 +0100)]
openmp, openacc: Fix up handling of data regions [PR98183]
While the data regions (target data and OpenACC counterparts) aren't
standalone directives, unlike most other OpenMP/OpenACC constructs
we allow (apparently as an extension) exceptions and goto out of
the block. During gimplification we place an *end* call into a finally
block so that it is reached even on exceptions or goto out etc.).
During omplower pass we then add paired #pragma omp return for them,
but due to the exceptions because the region is not SESE we can end up
with #pragma omp return appearing only conditionally in the CFG etc.,
which the ompexp pass can't handle.
For the ompexp pass, we actually don't care about the end part or about
target data nesting, so we can treat it as standalone directive.
2020-12-12 Jakub Jelinek <jakub@redhat.com>
PR middle-end/98183
* omp-low.c (lower_omp_target): Don't add OMP_RETURN for
data regions.
* omp-expand.c (expand_omp_target): Don't try to remove
OMP_RETURN for data regions.
(build_omp_regions_1, omp_make_gimple_edges): Don't expect
OMP_RETURN for data regions.
* gcc.dg/gomp/pr98183.c: New test.
* gcc.dg/goacc/pr98183.c: New test.
Jakub Jelinek [Tue, 8 Dec 2020 14:44:10 +0000 (15:44 +0100)]
i386: Fix up X87_ENABLE_{FLOAT,ARITH} in conditions [PR94440]
The documentation says
For a named pattern, the condition may not depend on the data in
the insn being matched, but only the target-machine-type flags.
The i386 backend violates that by using flag_excess_precision and
flag_unsafe_math_optimizations in the conditions too, which is bad
when optimize attribute or pragmas are used. The problem is that the
middle-end caches the enabled conditions for the optabs for a particular
switchable target, but multiple functions can share the same
TARGET_OPTION_NODE, but have different TREE_OPTIMIZATION_NODE with different
flag_excess_precision or flag_unsafe_math_optimizations, so the enabled
conditions then match only one of those.
I think best would be to just have a single options node for both the
generic and target options, then such problems wouldn't exist, but that
would be very risky at this point and quite large change.
So, instead the following patch just shadows flag_excess_precision and
flag_unsafe_math_optimizations values for uses in the instruction conditions
in TargetVariable and during set_cfun artificially creates new
TARGET_OPTION_NODE if flag_excess_precision and/or
flag_unsafe_math_optimizations change from what is recorded in their
TARGET_OPTION_NODE. The target nodes are hashed, so worst case we can get 4
times as many target option nodes if one would for each unique target option
try all the flag_excess_precision and flag_unsafe_math_optimizations values.
2020-12-08 Jakub Jelinek <jakub@redhat.com>
PR target/94440
* config/i386/i386.opt (ix86_excess_precision,
ix86_unsafe_math_optimizations): New TargetVariables.
* config/i386/i386.h (X87_ENABLE_ARITH, X87_ENABLE_FLOAT): Use
ix86_unsafe_math_optimizations instead of
flag_unsafe_math_optimizations and ix86_excess_precision instead of
flag_excess_precision.
* config/i386/i386.c (ix86_excess_precision): Rename to ...
(ix86_get_excess_precision): ... this.
(TARGET_C_EXCESS_PRECISION): Define to ix86_get_excess_precision.
* config/i386/i386-options.c (ix86_valid_target_attribute_tree,
ix86_option_override_internal): Update ix86_unsafe_math_optimization
from flag_unsafe_math_optimizations and ix86_excess_precision
from flag_excess_precision when constructing target option nodes.
(ix86_set_current_function): If flag_unsafe_math_optimizations
or flag_excess_precision is different from the one recorded
in TARGET_OPTION_NODE, create a new target option node for the
current function and switch to that.
Jakub Jelinek [Tue, 8 Dec 2020 09:45:30 +0000 (10:45 +0100)]
openmp: -fopenmp-simd fixes [PR98187]
This patch fixes two bugs in the -fopenmp-simd support. One is that
in C++ #pragma omp parallel master would actually create OMP_PARALLEL
in the IL, which is a big no-no for -fopenmp-simd, we should be creating
only the constructs -fopenmp-simd handles (mainly OMP_SIMD, OMP_LOOP which
is gimplified as simd in that case, declare simd/reduction and ordered simd).
The other bug was that #pragma omp master taskloop simd combined construct
contains simd and thus should be recognized as #pragma omp simd (with only
the simd applicable clauses), but as master wasn't included in
omp_pragmas_simd, we'd ignore it completely instead.
* parser.c (cp_parser_omp_parallel): For parallel master with
-fopenmp-simd only, just call cp_parser_omp_master instead of
wrapping it in OMP_PARALLEL.
Jakub Jelinek [Sat, 5 Dec 2020 00:30:08 +0000 (01:30 +0100)]
c++: Fix constexpr access to union member through pointer-to-member [PR98122]
We currently incorrectly reject the first testcase, because
cxx_fold_indirect_ref_1 doesn't attempt to handle UNION_TYPEs.
As the second testcase shows, it isn't that easy, because I believe we need
to take into account the active member and prefer that active member over
other members, because if we pick a non-active one, we might reject valid
programs.
2020-12-05 Jakub Jelinek <jakub@redhat.com>
PR c++/98122
* constexpr.c (cxx_union_active_member): New function.
(cxx_fold_indirect_ref_1): Add ctx argument, pass it through to
recursive call. Handle UNION_TYPE.
(cxx_fold_indirect_ref): Add ctx argument, pass it to recursive calls
and cxx_fold_indirect_ref_1.
(cxx_eval_indirect_ref): Adjust cxx_fold_indirect_ref calls.
* g++.dg/cpp1y/constexpr-98122.C: New test.
* g++.dg/cpp2a/constexpr-98122.C: New test.
Jakub Jelinek [Fri, 4 Dec 2020 11:18:21 +0000 (12:18 +0100)]
debug: Fix another vector DECL_MODE ICE [PR98100]
The PR88587 fix changes DECL_MODE of vars with vector type during inlining/cloning
when the vars are copied, so that their DECL_MODE matches their TYPE_MODE in
the new function. Unfortunately, the following testcase still ICEs, the var
isn't really used in the new function and so it isn't copied, but becomes
just a nonlocalized var. So we can't adjust its DECL_MODE because it
appears in multiple functions and needs different modes in between them.
The following patch changes the DEBUG_INSN creation to use TYPE_MODE instead
of DECL_MODE for vars with vector types.
2020-12-04 Jakub Jelinek <jakub@redhat.com>
PR target/98100
* cfgexpand.c (expand_gimple_basic_block): For vars with
vector type, use TYPE_MODE rather than DECL_MODE.
Jakub Jelinek [Wed, 2 Dec 2020 23:29:46 +0000 (00:29 +0100)]
dwarf2out: Fix up add_scalar_info not to create invalid DWARF
As discussed in https://sourceware.org/bugzilla/show_bug.cgi?id=26987 ,
for very large bounds (which don't fit into HOST_WIDE_INT) GCC emits invalid
DWARF.
In DWARF2, DW_AT_{lower,upper}_bound were constant reference class.
In DWARF3 they are block constant reference and the
Static and Dynamic Properties of Types
chapter says:
"For a block, the value is interpreted as a DWARF expression; evaluation of the expression
yields the value of the attribute."
In DWARF4/5 they are constant exprloc reference class.
Now, for add_AT_wide we use DW_FORM_data16 (valid in constant class)
when -gdwarf-5, but otherwise just use DW_FORM_block1, which is not constant
class, but block.
For DWARF3 this means emitting clearly invalid DWARF, because the
DW_FORM_block1 should contain a DWARF expression, not random bytes
containing the constant directly.
For DWARF2/DWARF4/5 it could be considered a GNU extension, but a very badly
designed one when it means something different in DWARF3.
The following patch uses add_AT_wide only if we know we'll be using
DW_FORM_data16, and otherwise wastes 2 extra bytes and emits in there
DW_OP_implicit_value <size> before the constant.
2020-12-03 Jakub Jelinek <jakub@redhat.com>
* dwarf2out.c (add_scalar_info): Only use add_AT_wide for 128-bit
constants and only in dwarf-5 or later, where DW_FORM_data16 is
available. Otherwise use DW_FORM_block*/DW_FORM_exprloc with
DW_OP_implicit_value to describe the constant.
Scott Snyder [Wed, 2 Dec 2020 14:42:56 +0000 (15:42 +0100)]
vec.h: Fix GCC build with -std=gnu++20 [PR98059]
Apparently vec.h doesn't build with -std=c++20/gnu++20, since the
DR2237 r11-532 change.
template <typename T>
class auto_delete_vec
{
private:
auto_vec_delete<T> (const auto_delete_vec<T> &) = delete;
};
which vec.h uses is invalid C++20, one needs to use
auto_vec_delete (const auto_delete_vec &) = delete;
instead which is valid all the way back to C++11 (and without = delete
to C++98).
2020-12-02 Scott Snyder <sss@li-snyder.org>
PR plugins/98059
* vec.h (auto_delete_vec): Use
DISABLE_COPY_AND_ASSIGN(auto_delete_vec) instead of
DISABLE_COPY_AND_ASSIGN(auto_delete_vec<T>) to make it valid C++20
after DR2237.
Jakub Jelinek [Tue, 1 Dec 2020 20:41:44 +0000 (21:41 +0100)]
openmp: Avoid ICE on depend clause on depobj OpenMP construct [PR98072]
Since r11-5430 we ICE on the following testcase. When parsing the depobj
directive we don't really use cp_parser_omp_all_clauses routine which ATM
disables generation of location wrappers and the newly added assertion
that there are no location wrappers thus triggers.
Fixed by adding the location wrappers suppression sentinel.
Longer term, we should handle location wrappers inside of OpenMP clauses.
Jakub Jelinek [Tue, 1 Dec 2020 09:44:40 +0000 (10:44 +0100)]
x86_64: Fix up -fpic -mcmodel=large -fno-plt [PR98063]
On the following testcase with -fpic -mcmodel=large -fno-plt we emit
call puts@GOTPCREL(%rip)
but that is not really appropriate for CM_LARGE_PIC, the .text can be larger
than 2GB in that case and the .got slot further away from %rip than what can
fit into the signed 32-bit immediate.
The following patch computes the address of the .got slot the way it is
computed for that model for function pointer loads, and calls that.
Marek Polacek [Tue, 5 Jan 2021 21:33:07 +0000 (16:33 -0500)]
c++: ICE with deferred noexcept when deducing targs [PR82099]
In this test we ICE in type_throw_all_p because it got a deferred
noexcept which it shouldn't. Here's the story:
In noexcept61.C, we call bar, so we perform overload resolution. When
adding the (only) candidate, we need to deduce template arguments, so
call fn_type_unification as usually. That deduces U to
void (*) (int &, int &)
which is correct, but its noexcept-spec is deferred_noexcept. Then
we call add_function_candidate (bar), wherein we try to create an
implicit conversion sequence for every argument. Since baz<int> is
of unknown type, we instantiate_type it; it is a TEMPLATE_ID_EXPR
so that calls resolve_address_of_overloaded_function. But we crash
there, because target_type contains the deferred_noexcept.
So we need to maybe_instantiate_noexcept before we can compare types.
resolve_overloaded_unification seemed like the appropriate spot, now
fn_type_unification produces the function type with its noexcept-spec
instantiated. This shouldn't go against CWG 1330 because here we
really need to instantiate the noexcept-spec.
This also fixes class-deduction76.C, a dg-ice test I recently added,
therefore this fix also fixes c++/90799, yay.
gcc/cp/ChangeLog:
PR c++/82099
* pt.c (resolve_overloaded_unification): Call
maybe_instantiate_noexcept after instantiating the function
decl.
gcc/testsuite/ChangeLog:
PR c++/82099
* g++.dg/cpp0x/noexcept61.C: New test.
Marek Polacek [Sat, 24 Oct 2020 19:26:27 +0000 (15:26 -0400)]
c++: Prevent warnings for value-dependent exprs [PR96742]
Here, in r11-155, I changed the call to uses_template_parms to
type_dependent_expression_p_push to avoid a crash in C++98 in
value_dependent_expression_p on a non-constant expression. But that
prompted a host of complaints that we now warn for value-dependent
expressions in templates. Those warnings are technically valid, but
people still don't want them because they're awkward to avoid. This
patch uses value_dependent_expression_p or type_dependent_expression_p.
But make sure that we don't ICE in value_dependent_expression_p by
checking potential_constant_expression first.
gcc/cp/ChangeLog:
PR c++/96675
PR c++/96742
* pt.c (tsubst_copy_and_build): Call value_dependent_expression_p or
type_dependent_expression_p instead of type_dependent_expression_p_push.
But only call value_dependent_expression_p for expressions that are
potential_constant_expression.
gcc/testsuite/ChangeLog:
PR c++/96675
PR c++/96742
* g++.dg/warn/Wdiv-by-zero-3.C: Turn dg-warning into dg-bogus.
* g++.dg/warn/Wtautological-compare3.C: New test.
* g++.dg/warn/Wtype-limits5.C: New test.
* g++.old-deja/g++.pt/crash10.C: Remove dg-warning.
Marek Polacek [Tue, 1 Dec 2020 15:39:08 +0000 (10:39 -0500)]
c++: Fix ICE with inline variable in template [PR97975]
In this test, we have
static inline const int c = b;
in a class template, and we call store_init_value as usual. There, the
value is
IMPLICIT_CONV_EXPR<const float>(b)
which is is_nondependent_static_init_expression but isn't
is_nondependent_constant_expression (they only differ in STRICT).
We call fold_non_dependent_expr, but that just returns the expression
because it only instantiates is_nondependent_constant_expression
expressions. Since we're not checking the initializer of a constexpr
variable, we go on to call maybe_constant_init, whereupon we crash
because it tries to evaluate all is_nondependent_static_init_expression
expressions, which our value is, but it still contains a template code.
I think the fix is to call fold_non_dependent_init instead of
maybe_constant_init, and only call fold_non_dependent_expr on the
"this is a constexpr variable" path so as to avoid instantiating twice
in a row. Outside a template this should also avoid evaluating the
value twice.
gcc/cp/ChangeLog:
PR c++/97975
* constexpr.c (fold_non_dependent_init): Add a tree parameter.
Use it.
* cp-tree.h (fold_non_dependent_init): Add a tree parameter with
a default value.
* typeck2.c (store_init_value): Call fold_non_dependent_expr
only when checking the initializer for constexpr variables.
Call fold_non_dependent_init instead of maybe_constant_init.
gcc/testsuite/ChangeLog:
PR c++/97975
* g++.dg/cpp1z/inline-var8.C: New test.
Marek Polacek [Wed, 2 Dec 2020 15:47:49 +0000 (10:47 -0500)]
c++: ICE with switch and scoped enum bit-fields [PR98043]
In this testcase we are crashing trying to gimplify a switch, because
the types of the switch condition and case constants have different
TYPE_PRECISIONs.
This started with my r5-3726 fix: SWITCH_STMT_TYPE is supposed to be the
original type of the switch condition before any conversions, so in the
C++ FE we need to use unlowered_expr_type to get the unlowered type of
enum bit-fields.
Normally, the switch type is subject to integral promotions, but here
we have a scoped enum type and those don't promote:
enum class B { A };
struct C { B c : 8; };
switch (x.c) // type B
case B::A: // type int, will be converted to B
Here TREE_TYPE is "signed char" but SWITCH_STMT_TYPE is "B". When
gimplifying this in gimplify_switch_expr, the index type is "B" and
we convert all the case values to "B" in preprocess_case_label_vec,
but SWITCH_COND is of type "signed char": gimple_switch_index should
be the (possibly promoted) type, not the original type, so we gimplify
the "x.c" SWITCH_COND to a SSA_NAME of type "signed char". And then
we crash because the precision of the index type doesn't match the
precision of the case value type.
I think it makes sense to do the following; at the end of pop_switch
we've already issued the switch warnings, and since scoped enums don't
promote, it should be okay to use the type of SWITCH_STMT_COND. The
r5-3726 change was about giving warnings for enum bit-fields anyway.
gcc/cp/ChangeLog:
PR c++/98043
* decl.c (pop_switch): If SWITCH_STMT_TYPE is a scoped enum type,
set it to the type of SWITCH_STMT_COND.
Marek Polacek [Wed, 2 Dec 2020 19:33:13 +0000 (14:33 -0500)]
c++: ICE with -fsanitize=vptr and constexpr dynamic_cast [PR98103]
-fsanitize=vptr initializes all vtable pointers to null so that it can
catch invalid calls; see cp_ubsan_maybe_initialize_vtbl_ptrs. That
means that evaluating a vtable reference can produce a null pointer
in this mode, so cxx_eval_dynamic_cast_fn should check that and give
and error.
gcc/cp/ChangeLog:
PR c++/98103
* constexpr.c (cxx_eval_dynamic_cast_fn): If the evaluating of vtable
yields a null pointer, give an error and return. Use objtype.
Marek Polacek [Tue, 5 Jan 2021 21:27:30 +0000 (16:27 -0500)]
c++: Fix wrong error with constexpr destructor [PR97427]
When I implemented the code to detect modifying const objects in
constexpr contexts, we couldn't have constexpr destructors, so I didn't
consider them. But now we can and that caused a bogus error in this
testcase: [class.dtor]p5 says that "const and volatile semantics are not
applied on an object under destruction. They stop being in effect when
the destructor for the most derived object starts." so we have to clear
the TREE_READONLY flag we set on the object after the constructors have
been called to mark it as no-longer-under-construction. In the ~Foo
call it's now an object under destruction, so don't report those errors.
gcc/cp/ChangeLog:
PR c++/97427
* constexpr.c (cxx_set_object_constness): New function.
(cxx_eval_call_expression): Set new_obj for destructors too.
Call cxx_set_object_constness to set/unset TREE_READONLY of
the object under construction/destruction.
gcc/testsuite/ChangeLog:
PR c++/97427
* g++.dg/cpp2a/constexpr-dtor10.C: New test.
Uros Bizjak [Tue, 5 Jan 2021 13:42:29 +0000 (14:42 +0100)]
i386: Prevent spurious FP exceptions with _mm_cvt{,t}ps_pi32 [PR98522]
Prevent spurious FP exceptions with _mm_cvt{,t}ps_pi32 for TARGET_MMX_WITH_SSE
by clearing the top 64 bytes of the input XMM register.
2021-01-05 Uroš Bizjak <ubizjak@gmail.com>
gcc/
PR target/98522
* config/i386/sse.md (sse_cvtps2pi): Redefine as define_insn_and_split.
Clear the top 64 bytes of the input XMM register.
(sse_cvttps2pi): Ditto.
gcc/testsuite
PR target/98522
* gcc.target/i386/pr98522.c: New test.
Harald Anlauf [Fri, 1 Jan 2021 17:55:41 +0000 (18:55 +0100)]
PR fortran/96381 - invalid read in gfc_find_derived_vtab
An invalid declaration of a CLASS instance can lead to an internal state
with inconsistent attributes during parsing that needs to be handled with
sufficient care when processing subsequent statements. Avoid a lookup of
the vtab entry for such cases.
gcc/fortran/ChangeLog:
* class.c (gfc_find_vtab): Add check on attribute is_class.
Iain Sandoe [Sat, 17 Oct 2020 10:21:11 +0000 (11:21 +0100)]
coroutines: Emit error for invalid promise return types [PR97438].
At one stage, use cases were proposed for allowing the promise
type to contain both return_value and return_void. That was
not accepted into C++20, so we should reject it as per the PR.
gcc/cp/ChangeLog:
PR c++/97438
* coroutines.cc (struct coroutine_info): Add a field to
record that we emitted a promise type error.
(coro_promise_type_found_p): Check for the case that the
promise type contains both return_void and return_value.
Emit an error if so, with information about the wrong
type methods.
gcc/testsuite/ChangeLog:
PR c++/97438
* g++.dg/coroutines/pr97438.C: New test.
Iain Sandoe [Wed, 18 Nov 2020 10:06:03 +0000 (10:06 +0000)]
Darwin : Update libtool and dependencies for Darwin20 [PR97865]
The change in major version (and the increment from Darwin19 to 20)
caused libtool tests to fail which resulted in incorrect build settings
for shared libraries.
We take this opportunity to sort out the shared undefined symbols state
rather than propagating the current unsound behaviour into a new rev.
This change means that we default to the case that missing symbols are
considered an error, and if one wants to allow this intentionally, the
confiuration for that case should be set appropriately.
Three existing cases need undefined dynamic lookup:
libitm, where there is already a configuration mechanism to add the
flags.
libcc1, where we add simple configuration to add the flags for Darwin.
libsanitizer, where we can add to the existing extra flags.
PR target/97865
* Makefile.am: Add dynamic_lookup to LD flags for Darwin.
* configure.ac: Test for Darwin host and set a flag.
* Makefile.in: Regenerate.
* configure: Regenerate.
libitm/ChangeLog:
PR target/97865
* configure.tgt: Add dynamic_lookup to XLDFLAGS for Darwin.
* configure: Regenerate.
libsanitizer/ChangeLog:
PR target/97865
* configure.tgt: Add dynamic_lookup to EXTRA_CXXFLAGS for
Darwin.
* configure: Regenerate.
ChangeLog:
PR target/97865
* libtool.m4: Update handling of Darwin platform link flags
for Darwin20.
gcc/ChangeLog:
PR target/97865
* configure: Regenerate.
libatomic/ChangeLog:
PR target/97865
* configure: Regenerate.
libbacktrace/ChangeLog:
PR target/97865
* configure: Regenerate.
libffi/ChangeLog:
PR target/97865
* configure: Regenerate.
libgfortran/ChangeLog:
PR target/97865
* configure: Regenerate.
libgomp/ChangeLog:
PR target/97865
* configure: Regenerate.
* Makefile.in: Update copyright years.
Iain Sandoe [Wed, 23 Dec 2020 17:16:08 +0000 (17:16 +0000)]
Darwin : Adjust handling of MACOSX_DEPLOYMENT_TARGET for macOS 11.
The shift to macOS version 11 also means that '11' without any
following '.x' is accepted as a valid version number. This adjusts
the validation code to accept this and map it to 11.0.0 which
matches what the clang toolchain appears to do.
gcc/ChangeLog:
* config/darwin-driver.c (validate_macosx_version_min): Allow
MACOSX_DEPLOYMENT_TARGET=11.
(darwin_default_min_version): Adjust warning spelling to avoid
an apostrophe.
Iain Sandoe [Sat, 19 Dec 2020 13:05:34 +0000 (13:05 +0000)]
Darwin : Update the kernel version to macOS version mapping.
With the change to macOS 11 and Darwin20, the algorithm for mapping
kernel version to macOS version has changed.
We now have darwin 20.X.Y => macOS 11.(X > 0 ? X - 1 : 0).??.
It currently unclear if the Y will be mapped to macOS patch version
and, if so, whether it will be one-based or 0-based.
Likewise, it's unknown if Darwin 21 will map to macOS 12, so these
entries are unchanged for the present.
gcc/ChangeLog:
* config/darwin-driver.c (darwin_find_version_from_kernel):
Compute the minor OS version from the minor kernel version.
As per Nigel Tufnel's assertion "... this one goes to 11".
The various parts of the code that deal with mapping Darwin versions
to macOS (X) versions need updating to deal with a major version of
11.
So now we have, for example:
Darwin 4 => macOS (X) 10.0
…
Darwin 14 => macOS (X) 10.10
...
Darwin 19 => macOS (X) 10.15
Darwin 20 => macOS 11.0
Because of the historical duplication of the "10" in macOSX 10.xx and
the number of tools that expect this, it is likely that system tools will
allow macos11.0 and/or macosx11.0 (despite that the latter makes little
sense).
Update the link test to cover Catalina (Darwin19/10.15) and
Big Sur (Darwin20/11.0).
gcc/ChangeLog:
* config/darwin-c.c: Allow for Darwin20 to correspond to macOS 11.
* config/darwin-driver.c: Likewise.
gcc/testsuite/ChangeLog:
* gcc.dg/darwin-minversion-link.c: Allow for Darwin19 (macOS 10.15)
and Darwin20 (macOS 11.0).
aarch64 : Fix a forward declaration signature to match the implementation.
The argument types given in the forward declaration for
aarch64_get_extension_string_for_isa_flags do not match those given in the
prototype. This leads to a build fail when 'unsigned long' is not a 64b
type.
Uros Bizjak [Mon, 28 Dec 2020 20:35:08 +0000 (21:35 +0100)]
i386: Fix __builtin_rint with FE_DOWNWARD rounding direction [PR96793]
x86_expand_rint expander uses x86_sse_copysign_to_positive, which
is unable to change the sign from - to +. When FE_DOWNWARD rounding
direction is in effect, the expanded sequence that involves subtraction
can trigger x - x = -0.0 special rule. x86_sse_copysign_to_positive
fails to change the sign of the intermediate value, assumed to always
be positive, back to positive.
The patch adds one extra fabs that strips the sign from the intermediate
value when flag_rounding_math is in effect.
2020-12-28 Uroš Bizjak <ubizjak@gmail.com>
gcc/
PR target/96793
* config/i386/i386-expand.c (ix86_expand_rint):
Remove the sign of the intermediate value for flag_rounding_math.
gcc/testsuite/
PR target/96793
* gcc.target/i386/pr96793-2.c: New test.
Paul Thomas [Thu, 20 Aug 2020 17:17:59 +0000 (18:17 +0100)]
This patch fixes PRs 96100 and 96101.
2020-08-20 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/96100
PR fortran/96101
* trans-array.c (get_array_charlen): Tidy up the evaluation of
the string length for array constructors. Avoid trailing array
references. Ensure string lengths of deferred length components
are set. For parentheses operator apply string length to both
the primary expression and the enclosed expression.
gcc/testsuite/
PR fortran/96100
PR fortran/96101
* gfortran.dg/char_length_23.f90: New test.
Paul Thomas [Sun, 2 Aug 2020 09:57:59 +0000 (10:57 +0100)]
This patch fixes PR96320. See the explanatory comment in the testcase.
2020-08-01 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR target/96320
* interface.c (gfc_check_dummy_characteristics): If a module
procedure arrives with assumed shape in the interface and
deferred shape in the procedure itself, update the latter and
copy the lower bounds.
gcc/testsuite/
PR target/96320
* gfortran.dg/module_procedure_4.f90 : New test.
Piotr Kubaj [Wed, 16 Dec 2020 22:26:18 +0000 (22:26 +0000)]
rs6000: Add support for powerpc64le-unknown-freebsd
This implements support for powerpc64le architecture on FreeBSD. Since
we don't have powerpcle (32-bit), I did not add support for powerpcle
here. This remains to be changed if there is powerpcle support in the
future.
Harald Anlauf [Fri, 25 Dec 2020 14:40:39 +0000 (15:40 +0100)]
PR fortran/93685 - ICE in gfc_constructor_append_expr, at fortran/constructor.c:135
Fix handling of F2018 enhancements to DATA statements that allows
initialization of pointer components to derived types, and adjust error
handling for the CHARACTER case.
gcc/fortran/ChangeLog:
* data.c (gfc_assign_data_value): Restrict use of
create_character_initializer to constant initializers.
* trans-expr.c (gfc_conv_initializer): Ensure that character
initializer is constant, otherwise fall through to get the same
error handling as for non-character cases.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr93685_1.f90: New test.
* gfortran.dg/pr93685_2.f90: New test.
Iain Sandoe [Sat, 21 Nov 2020 09:06:03 +0000 (09:06 +0000)]
Darwin, libgfortran : Do not use environ directly from the library.
On macOS / Darwin, the environ variable can be used directly in the
code of an executable, but cannot be used in the code of a shared
library (i.e. libgfortran.dylib), in this case.
In such cases, the function _NSGetEnviron should be called to get
the address of 'environ'.
libgfortran/ChangeLog:
* intrinsics/execute_command_line.c (environ): Use
_NSGetEnviron to get the environment pointer on Darwin.
Roman Zhuykov [Thu, 24 Dec 2020 16:43:40 +0000 (19:43 +0300)]
modulo-sched: Carefully process loop counter initialization [PR97421]
Do not allow direct adjustment of pre-header initialization instruction for
count register if is read in some instruction below in that basic block.
gcc/ChangeLog:
PR rtl-optimization/97421
* modulo-sched.c (generate_prolog_epilog): Remove forward
declaration, adjust last argument name and type.
(const_iteration_count): Add bool pointer parameter to return
whether count register is read in pre-header after its
initialization.
(sms_schedule): Fix count register initialization adjustment
procedure according to what const_iteration_count said.
gcc/testsuite/ChangeLog:
PR rtl-optimization/97421
* gcc.c-torture/execute/pr97421-1.c: New test.
* gcc.c-torture/execute/pr97421-2.c: New test.
* gcc.c-torture/execute/pr97421-3.c: New test.
Jason Merrill [Tue, 22 Dec 2020 21:40:37 +0000 (16:40 -0500)]
c++: Fix constexpr array ICE [PR98332]
The element initializer was non-constant, so its CONSTRUCTOR element ended
up NULL, so unshare_constructor crashed trying to look at it. This patch
fixes this in two places: First, by returning when we see a non-constant
initializer; second, by not crashing on NULL.
gcc/cp/ChangeLog:
PR c++/98332
* constexpr.c (unshare_constructor): Check for NULL.
(cxx_eval_vec_init_1): Always exit early if non-constant.
gcc/testsuite/ChangeLog:
PR c++/98332
* g++.dg/cpp0x/constexpr-overflow3.C: New test.
Jason Merrill [Wed, 12 Aug 2020 09:45:02 +0000 (05:45 -0400)]
c++: Copy elision and [[no_unique_address]]. [PR93711]
We don't elide a copy from a function returning a class by value into a base
because that can overwrite data laid out in the tail padding of the base
class; we need to handle [[no_unique_address]] fields the same way, or we
ICE when the middle-end wants to create a temporary object of a
TYPE_NEEDS_CONSTRUCTING type.
This means that we can't always express initialization of a field with
INIT_EXPR from a TARGET_EXPR the way we usually do, so I needed
to change several places that were assuming that was sufficient.
This also fixes 90254, the same problem with C++17 aggregate initialization
of a base.
Uros Bizjak [Wed, 23 Dec 2020 17:32:28 +0000 (18:32 +0100)]
i386: Fix __builtin_trunc with FE_DOWNWARD rounding direction [PR96793]
x86_expand_truncdf_32 expander uses x86_sse_copysign_to_positive, which
is unable to change the sign from - to +. When FE_DOWNWARD rounding
direction is in effect, the expanded sequence that involves subtraction
can trigger x - x = -0.0 special rule. x86_sse_copysign_to_positive
fails to change the sign of the intermediate value, assumed to always
be positive, back to positive.
The patch adds one extra fabs that strips the sign from the intermediate
value when flag_rounding_math is in effect.
2020-12-23 Uroš Bizjak <ubizjak@gmail.com>
gcc/
PR target/96793
* config/i386/i386-expand.c (ix86_expand_truncdf_32):
Remove the sign of the intermediate value for flag_rounding_math.
gcc/testsuite/
PR target/96793
* gcc.target/i386/pr96793-1.c: New test.
Uros Bizjak [Tue, 22 Dec 2020 20:11:51 +0000 (21:11 +0100)]
i386: Fix __builtin_floor with FE_DOWNWARD rounding direction [PR96793]
x86_expand_floorceil expander uses x86_sse_copysign_to_positive, which
is unable to change the sign from - to +. When FE_DOWNWARD rounding
direction is in effect, the expanded sequence that involves subtraction
can trigger x - x = -0.0 special rule. x86_sse_copysign_to_positive
fails to change the sign of the intermediate value, assumed to always
be positive, back to positive.
The patch adds one extra fabs that strips the sign from the intermediate
value when flag_rounding_math is in effect.
2020-12-22 Uroš Bizjak <ubizjak@gmail.com>
gcc/
PR target/96793
* config/i386/i386-expand.c (ix86_expand_floorceil):
Remove the sign of the intermediate value for flag_rounding_math.
(ix86_expand_floorceildf_32): Ditto.
gcc/testsuite/
PR target/96793
* gcc.target/i386/pr96793.c: New test.
Nathan Sidwell [Wed, 16 Dec 2020 19:49:41 +0000 (11:49 -0800)]
c++: Fix template parm ICE [PR 98297]
I think this is nonsense code, we seem to be naming an instantiation
of a template template parm. But this fixes the ICE. Perhaps we
should diagnose the issue earlier?
gcc/cp/
* parser.c (cp_parser_elaborated_type_specifier): Test
BOUND_TEMPLATE_TEMPLATE_PARM before checking for instantiation.
gcc/testsuite/
* g++.dg/template/pr98297.C: New.
Iain Buclaw [Tue, 15 Dec 2020 09:36:00 +0000 (10:36 +0100)]
d: Fix ICE in gimplify_expr, at gimplify.c (PR98277)
The DMD front-end shouldn't, but can sometimes leak manifest constants
in the AST passed to the code generator. To prevent this being an
issue, the setting of DECL_INITIAL has been moved to the point where the
CONST_DECL is used, rather than in the declaration handler.
gcc/d/ChangeLog:
PR d/98277
* decl.cc (DeclVisitor::visit (VarDeclaration *)): Move setting of
DECL_INITIAL for manifest constants to ...
(get_symbol_decl): ... here.
Wilco Dijkstra [Thu, 3 Dec 2020 18:40:34 +0000 (18:40 +0000)]
AArch64: Add support for --with-tune
Add support for --with-tune. Like --with-cpu and --with-arch, the argument is
validated and transformed into a -mtune option to be processed like any other
command-line option. --with-tune has no effect if a -mcpu or -mtune option
is used. The validating code didn't allow --with-cpu=native, so explicitly
allow that.
Co-authored-by: Delia Burduv <delia.burduv@arm.com>
Bootstrap OK, regress pass, OK to commit?
Dennis Zhang [Fri, 11 Dec 2020 16:18:05 +0000 (16:18 +0000)]
aarch64: intrinsics to extract half of bf16 vector
This patch implements ACLE intrinsics vget_low_bf16 and vget_high_bf16
to extract lower or higher half from a bfloat16x8 vector. The
vget_high_bf16 is done by 'dup' instruction. The vget_low_bf16 is just
to return the lower half of a vector register. Tests include both big-
and little-endian cases.
gcc/ChangeLog:
* config/aarch64/aarch64-simd-builtins.def (vget_lo_half): New entry.
(vget_hi_half): Likewise.
* config/aarch64/aarch64-simd.md (aarch64_vget_lo_halfv8bf): New entry.
(aarch64_vget_hi_halfv8bf): Likewise.
* config/aarch64/arm_neon.h (vget_low_bf16): New intrinsic.
(vget_high_bf16): Likewise.
gcc/testsuite/ChangeLog
* gcc.target/aarch64/advsimd-intrinsics/bf16_get.c: New test.
2020-10-29 Andrea Corallo <andrea.corallo@arm.com>
* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_bf16_indices_1.c:
Run it also for the arm backend.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_bf16_indices_1.c:
Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_bf16_indices_1.c:
Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_bf16_indices_1.c:
Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vld4_lane_bf16_indices_1.c:
Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vld4q_lane_bf16_indices_1.c:
Likewise.
* gcc.target/arm/simd/vldn_lane_bf16_1.c: New test.
Ed Schonberg [Thu, 10 Dec 2020 21:26:57 +0000 (22:26 +0100)]
Fix PR ada/98230
It's a rather curious malfunction of the 'Mod attribute applied to the
variable of a loop whose upper bound is dynamic.
gcc/ada/ChangeLog:
PR ada/98230
* exp_attr.adb (Expand_N_Attribute_Reference, case Mod): Use base
type of argument to obtain static bound and required size.
gcc/testsuite/ChangeLog:
* gnat.dg/modular6.adb: New test.
Patrick Palka [Thu, 30 Jul 2020 02:06:44 +0000 (22:06 -0400)]
c++: overload sets and placeholder return type [PR64194]
In the testcase below, template argument deduction for the call
g(id<int>) goes wrong because the functions in the overload set id<int>
each have a yet-undeduced auto return type, and this undeduced return
type makes try_one_overload fail to match up any of the overloads with
g's parameter type, leading to g's template argument going undeduced and
to the overload set going unresolved.
This patch fixes this issue by performing return type deduction via
instantiation before doing try_one_overload, in a manner similar to what
resolve_address_of_overloaded_function does.
gcc/cp/ChangeLog:
PR c++/64194
* pt.c (resolve_overloaded_unification): If the function
template specialization has a placeholder return type,
then instantiate it before attempting unification.
gcc/testsuite/ChangeLog:
PR c++/64194
* g++.dg/cpp1y/auto-fn60.C: New test.
Kewen Lin [Wed, 19 Aug 2020 02:37:39 +0000 (21:37 -0500)]
options: Make --help= see overridden values
Options "-Q --help=params" don't show the final values after
target option overriding, instead it emits the default values
in params.opt (without any explicit param settings).
This patch makes it see overridden values.
gcc/ChangeLog:
* opts-global.c (decode_options): Call target_option_override_hook
before it prints for --help=*.
Jason Merrill [Wed, 25 Nov 2020 22:05:24 +0000 (17:05 -0500)]
c++: Fix deduction from auto template parameter [PR93083]
The check in do_class_deduction to handle passing one class placeholder
template parm as an argument for itself needed to be extended to also handle
equivalent parms from other templates.
Eric Botcazou [Mon, 7 Dec 2020 09:48:06 +0000 (10:48 +0100)]
Fix internal error on library-level type extended locally
The compiler aborts on the local extension of a tagged type declared
at library level, with a progenitor given by an interface type having
a primitive that is a homograph of a primitive of the tagged type.
gcc/ada/ChangeLog:
* gcc-interface/trans.c (maybe_make_gnu_thunk): Return false if the
target is local and thunk and target do not have the same context.
projects / thirdparty / gcc.git / log
