Iain Sandoe [Sat, 31 Oct 2020 09:25:47 +0000 (09:25 +0000)]
Objective-C++ : Fix ICE in potential_constant_expression_1.
We cannot, as things stand, handle Objective-C tree codes in
the switch and deal with this by calling out to a function that
has a dummy version when Objective-C is not enabled.
Because of the way the logic works (with a fall through to a
'sorry' in case of unhandled expressions), the function reports
cases that are known to be unsuitable for constant exprs. The
dummy function always reports 'false' and thus will fall through
to the 'sorry'.
The fix for PR libstdc++/82481 should only have applied for targets
where _GLIBCXX_HAVE_TLS is defined. Because it was also done for non-TLS
targets, it isn't possible to use clang's analyzers on non-TLS targets
if the code uses <mutex>. This fixes it by using a NOLINT comment on
the relevant line instead of testing #ifdef __clang_analyzer__ and
compiling different code when analyzing.
I'm not actually able to reproduce the analyzer warning with the tools
from Clang 10.0.1 so I'm not going to try to make the suppression more
specific with NOLINTNEXTLINE(clang-analyzer-code.StackAddressEscape).
libstdc++-v3/ChangeLog:
PR libstdc++/98605
* include/std/mutex (call_once): Use NOLINT to suppress clang
analyzer warnings.
Samuel Thibault [Mon, 21 Dec 2020 14:36:30 +0000 (15:36 +0100)]
hurd: libgcc unwinding over signal trampolines with SIGINFO
When the application sets SA_SIGINFO, the signal trampoline parameters
are different to follow POSIX.
libgcc/
* config/i386/gnu-unwind.h (x86_gnu_fallback_frame_state): Add the
posix siginfo case to struct handler_args. Detect between legacy
and siginfo from the second parameter, which is a small sigcode in
the legacy case, and a pointer in the siginfo case.
Richard Biener [Wed, 6 Jan 2021 08:26:55 +0000 (09:26 +0100)]
tree-optimization/98513 - fix bug in range intersection code
This fixes a premature optimization in the range intersection code
which assumes earlier branches have to be taken, not taking into
account that for symbolic ranges we cannot always compare endpoints.
The fix is to instantiate the compare deemed redundant (which then
fails as undecidable for the testcase).
2021-01-06 Richard Biener <rguenther@suse.de>
PR tree-optimization/98513
* value-range.cc (intersect_ranges): Compare the upper bounds
for the expected relation.
vect: Fix bogus alignment assumption in alias checks [PR94994]
This PR is about a case in which the vectoriser was feeding
incorrect alignment information to tree-data-ref.c, leading
to incorrect runtime alias checks. The alignment was taken
from the TREE_TYPE of the DR_REF, which in this case was a
COMPONENT_REF with a normally-aligned type. However, the
underlying MEM_REF was only byte-aligned.
This patch uses dr_alignment to calculate the (byte) alignment
instead, just like we do when creating vector MEM_REFs.
gcc/
PR tree-optimization/94994
* tree-vect-data-refs.c (vect_vfa_align): Use dr_alignment.
gcc/testsuite/
PR tree-optimization/94994
* gcc.dg/vect/pr94994.c: New test.
vect, aarch64: Fix alignment units for IFN_MASK* [PR95401]
The IFN_MASK* functions take two leading arguments: a load or
store pointer and a “cookie”. The type of the cookie is the
type of the access for TBAA purposes (like for MEM_REFs)
while the value of the cookie is the alignment of the access.
This PR was caused by a disagreement about whether the alignment
is measured in bits or bytes.
It looks like this goes back to PR68786, which made the
vectoriser create its own cookie argument rather than reusing
the one created by ifcvt. The alignment value of the new cookie
was measured in bytes (as needed by set_ptr_info_alignment)
while the existing code expected it to be measured in bits.
The folds I added for IFN_MASK_LOAD and STORE then made
things worse.
gcc/
PR tree-optimization/95401
* config/aarch64/aarch64-sve-builtins.cc
(gimple_folder::load_store_cookie): Use bits rather than bytes
for the alignment argument to IFN_MASK_LOAD and IFN_MASK_STORE.
* gimple-fold.c (gimple_fold_mask_load_store_mem_ref): Likewise.
* tree-vect-stmts.c (vectorizable_store): Likewise.
(vectorizable_load): Likewise.
gcc/testsuite/
PR tree-optimization/95401
* g++.dg/vect/pr95401.cc: New test.
* g++.dg/vect/pr95401a.cc: Likewise.
recog: Fix a constrain_operands corner case [PR97144]
aarch64's *add<mode>3_poly_1 has a pattern with the constraints:
"=...,r,&r"
"...,0,rk"
"...,Uai,Uat"
i.e. the penultimate alternative requires operands 0 and 1 to match,
but the final alternative does not allow them to match.
The register allocators dealt with this correctly, and so used
different input and output registers for instructions with Uat
operands. However, constrain_operands carried the penultimate
alternative's matching rule over to the final alternative,
so it would essentially ignore the earlyclobber. This in turn
allowed postreload to convert a correct Uat pairing into an
incorrect one.
The fix is simple: recompute the matching information for each
alternative.
gcc/
PR rtl-optimization/97144
* recog.c (constrain_operands): Initialize matching_operand
for each alternative, rather than only doing it once.
gcc/testsuite/
PR rtl-optimization/97144
* gcc.c-torture/compile/pr97144.c: New test.
* gcc.target/aarch64/sve/pr97144.c: Likewise.
genmodes: Update GET_MODE_MASK when changing NUNITS [PR98214]
The static GET_MODE_MASKs for SVE vectors are based on the
static precisions, which in turn are based on 128-bit SVE.
The precisions are later updated based on -msve-vector-bits
(usually to become variable length), but the GET_MODE_MASK
stayed the same. This caused combine to fold:
(*_extract:DI (subreg:DI (reg:VNxMM R) 0) ...)
to zero because the extracted bits appeared to be insignificant.
gcc/
PR rtl-optimization/98214
* genmodes.c (emit_insn_modes_h): Emit a definition of CONST_MODE_MASK.
(emit_mode_mask): Treat mode_mask_array as non-constant if adj_nunits.
(emit_mode_adjustments): Update GET_MODE_MASK when updating
GET_MODE_NUNITS.
* machmode.h (mode_mask_array): Use CONST_MODE_MASK.
unsigned long long x = ...;
char y = (char) (x << 37);
The overwidening pattern realised that only the low 8 bits
of x << 37 are needed, but then tried to turn that into:
unsigned long long x = ...;
char y = (char) x << 37;
which gives an out-of-range shift. In this case y can simply
be replaced by zero, but as the comment in the patch says,
it's kind-of awkward to do that in the middle of vectorisation.
Most of the overwidening stuff is about keeping operations
as narrow as possible, which is important for vectorisation
but could be counter-productive for scalars (especially on
RISC targets). In contrast, optimising y to zero in the above
feels like an independent optimisation that would benefit scalar
code and that should happen before vectorisation.
gcc/
PR tree-optimization/98302
* tree-vect-patterns.c (vect_determine_precisions_from_users): Make
sure that the precision remains greater than the shift count.
gcc/testsuite/
PR tree-optimization/98302
* gcc.dg/vect/pr98302.c: New test.
vect: Fix missing alias checks for 128-bit SVE [PR98371]
On AArch64, the vectoriser tries various ways of vectorising with both
SVE and Advanced SIMD and picks the best one. All other things being
equal, it prefers earlier attempts over later attempts.
The way this works currently is that, once it has a successful
vectorisation attempt A, it analyses all other attempts as epilogue
loops of A:
/* When pick_lowest_cost_p is true, we should in principle iterate
over all the loop_vec_infos that LOOP_VINFO could replace and
try to vectorize LOOP_VINFO under the same conditions.
E.g. when trying to replace an epilogue loop, we should vectorize
LOOP_VINFO as an epilogue loop with the same VF limit. When trying
to replace the main loop, we should vectorize LOOP_VINFO as a main
loop too.
However, autovectorize_vector_modes is usually sorted as follows:
- Modes that naturally produce lower VFs usually follow modes that
naturally produce higher VFs.
- When modes naturally produce the same VF, maskable modes
usually follow unmaskable ones, so that the maskable mode
can be used to vectorize the epilogue of the unmaskable mode.
This order is preferred because it leads to the maximum
epilogue vectorization opportunities. Targets should only use
a different order if they want to make wide modes available while
disparaging them relative to earlier, smaller modes. The assumption
in that case is that the wider modes are more expensive in some
way that isn't reflected directly in the costs.
There should therefore be few interesting cases in which
LOOP_VINFO fails when treated as an epilogue loop, succeeds when
treated as a standalone loop, and ends up being genuinely cheaper
than FIRST_LOOP_VINFO. */
However, the vectoriser can normally elide alias checks for epilogue
loops, on the basis that the main loop should do them instead.
Converting an epilogue loop to a main loop can therefore cause the alias
checks to be skipped. (It probably also unfairly penalises the original
loop in the cost comparison, given that one loop will have alias checks
and the other won't.)
As the comment says, we should in principle analyse each vector mode
twice: once as a main loop and once as an epilogue. However, doing
that up-front would be quite expensive. This patch instead goes for a
compromise: if an epilogue loop for mode M2 seems better than a main
loop for mode M1, re-analyse with M2 as the main loop.
The patch fixes dg.torture.exp=pr69719.c when testing with
-msve-vector-bits=128.
gcc/
PR tree-optimization/98371
* tree-vect-loop.c (vect_reanalyze_as_main_loop): New function.
(vect_analyze_loop): If an epilogue loop appears to be cheaper
than the main loop, re-analyze it as a main loop before adopting
it as a main loop.
in the 64-bit vst[234] functions. The zero was forced into a
register at expand time, and we relied on combine to fuse the
zero and combine back together into a single combinez pattern.
The problem is that the zero could be hoisted before combine
gets a chance to do its thing.
gcc/
PR target/89057
* config/aarch64/aarch64-simd.md (aarch64_combine<mode>): Accept
aarch64_simd_reg_or_zero for operand 2. Use the combinez patterns
to handle zero operands.
gcc/testsuite/
PR target/89057
* gcc.target/aarch64/pr89057.c: New test.
aarch64: Extend aarch64-autovec-preference==2 to 128-bit SVE
When compiling with -msve-vector-bits=128, aarch64_preferred_simd_mode
would pass the same vector width to aarch64_simd_container_mode for
both SVE and Advanced SIMD, and so Advanced SIMD would always “win”.
This patch instead makes it choose directly between SVE and Advanced
SIMD modes, so that aarch64-autovec-preference==2 and
aarch64-autovec-preference==4 work for this configuration.
(aarch64-autovec-preference shouldn't affect aarch64_simd_container_mode
because that would have an ABI impact for things like GNU vectors.)
gcc/
* config/aarch64/aarch64.c (aarch64_preferred_simd_mode): Use
aarch64_full_sve_mode and aarch64_vq_mode directly, instead of
going via aarch64_simd_container_mode.
The gdb.Type.name attribute isn't present in GDB 7.6, so we get an
exception from StdPathPrinter._iterator.__next__ trying to use it.
The StdPathPrinter._iterator is already passed the type's name in its
constructor, so we can just store that and use it instead of
gdb.Type.name.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdExpPathPrinter): Store the
name of the type and pass it to the iterator.
(StdPathPrinter): Likewise.
* testsuite/libstdc++-prettyprinters/filesystem-ts.cc: New test.
Jonathan Wakely [Wed, 2 Dec 2020 21:39:08 +0000 (21:39 +0000)]
libstdc++: Fix std::any pretty printer [PR 68735]
This fixes errors seen on powerpc64 (big endian only) due to the
printers for std::any and std::experimental::any being unable to find
the manager function.
libstdc++-v3/ChangeLog:
PR libstdc++/65480
PR libstdc++/68735
* python/libstdcxx/v6/printers.py (function_pointer_to_name):
New helper function to get the name of a function from its
address.
(StdExpAnyPrinter.__init__): Use it.
Richard Biener [Mon, 7 Dec 2020 09:29:07 +0000 (10:29 +0100)]
tree-optimization/98117 - fix range set by vectorization on niter IVs
This avoids the degenerate case of a TYPE_MAX_VALUE latch iteration
count value causing wrong range info for the vector IV. There's
still the case of VF == 1 where if we don't know whether we hit the
above case we cannot emit a range.
2020-12-07 Richard Biener <rguenther@suse.de>
PR tree-optimization/98117
* tree-vect-loop-manip.c (vect_gen_vector_loop_niters):
Properly handle degenerate niter when setting the vector
loop IV range.
Richard Biener [Tue, 3 Nov 2020 14:03:41 +0000 (15:03 +0100)]
tree-optimization/97623 - Avoid PRE hoist insertion iteration
We are not really interested in PRE opportunities exposed by
hoisting but only the other way around. So this moves hoist
insertion after PRE iteration finished and removes hoist
insertion iteration alltogether.
It also guards access to NEW_SETS properly.
2020-11-11 Richard Biener <rguenther@suse.de>
PR tree-optimization/97623
* tree-ssa-pre.c (insert): Move hoist insertion after PRE
insertion iteration and do not iterate it.
(create_expression_by_pieces): Guard NEW_SETS access.
(insert_into_preds_of_block): Likewise.
Richard Biener [Fri, 30 Oct 2020 12:32:32 +0000 (13:32 +0100)]
tree-optimization/97623 - avoid excessive insert iteration for hoisting
This avoids requiring insert iteration for back-to-back hoisting
opportunities as seen in the added testcase. For the PR at hand
this halves the number of insert iterations retaining only
the hard to avoid PRE / hoist insert back-to-backs.
2020-10-30 Richard Biener <rguenther@suse.de>
PR tree-optimization/97623
* tree-ssa-pre.c (insert): First do hoist insertion in
a backward walk.
Jakub Jelinek [Sat, 9 Jan 2021 09:49:38 +0000 (10:49 +0100)]
tree-cfg: Allow enum types as result of POINTER_DIFF_EXPR [PR98556]
As conversions between signed integers and signed enums with the same
precision are useless in GIMPLE, it seems strange that we require that
POINTER_DIFF_EXPR result must be INTEGER_TYPE.
If we really wanted to require that, we'd need to change the gimplifier
to ensure that, which it isn't the case on the following testcase.
What is going on during the gimplification is that when we have the
(enum T) (p - q) cast, it is stripped through
/* Strip away as many useless type conversions as possible
at the toplevel. */
STRIP_USELESS_TYPE_CONVERSION (*expr_p);
and when the MODIFY_EXPR is gimplified, the *to_p has enum T type,
while *from_p has intptr_t type and as there is no conversion in between,
we just create GIMPLE_ASSIGN from that.
2021-01-09 Jakub Jelinek <jakub@redhat.com>
PR c++/98556
* tree-cfg.c (verify_gimple_assign_binary): Allow lhs of
POINTER_DIFF_EXPR to be any integral type.
Patrick Palka [Fri, 8 Jan 2021 15:11:25 +0000 (10:11 -0500)]
c++: ICE with constexpr call that returns a PMF [PR98551]
We shouldn't do replace_result_decl after evaluating a call that returns
a PMF because PMF temporaries aren't wrapped in a TARGET_EXPR (and so we
can't trust ctx->object), and PMF initializers can't be self-referential
anyway, so replace_result_decl would always be a no-op.
To that end, this patch changes the relevant AGGREGATE_TYPE_P test to
CLASS_TYPE_P, which should rule out PMFs (as well as arrays, which we
can't return and therefore won't see here). This fixes an ICE from the
sanity check in replace_result_decl in the below testcase during
constexpr evaluation of the call f() in the initializer g(f()).
gcc/cp/ChangeLog:
PR c++/98551
* constexpr.c (cxx_eval_call_expression): Check CLASS_TYPE_P
instead of AGGREGATE_TYPE_P before calling replace_result_decl.
gcc/testsuite/ChangeLog:
PR c++/98551
* g++.dg/cpp0x/constexpr-pmf2.C: New test.
Patrick Palka [Fri, 31 Jul 2020 02:21:41 +0000 (22:21 -0400)]
c++: decl_constant_value and unsharing [PR96197]
In the testcase from the PR we're seeing excessive memory use (> 5GB)
during constexpr evaluation, almost all of which is due to the call to
decl_constant_value in the VAR_DECL/CONST_DECL branch of
cxx_eval_constant_expression. We reach here every time we evaluate an
ARRAY_REF of a constexpr VAR_DECL, and from there decl_constant_value
makes an unshared copy of the VAR_DECL's initializer. But unsharing
here is unnecessary because callers of cxx_eval_constant_expression
already unshare its result when necessary.
To fix this excessive unsharing, this patch adds a new defaulted
parameter unshare_p to decl_really_constant_value and
decl_constant_value so that callers can control whether to unshare.
As a simplification, we can also move the call to unshare_expr in
constant_value_1 outside of the loop, since doing unshare_expr on a
DECL_P is a no-op.
Now that we no longer unshare the result of decl_constant_value and
decl_really_constant_value from cxx_eval_constant_expression, memory use
during constexpr evaluation for the testcase from the PR falls from ~5GB
to 15MB according to -ftime-report.
gcc/cp/ChangeLog:
PR c++/96197
* constexpr.c (cxx_eval_constant_expression) <case CONST_DECL>:
Pass false to decl_constant_value and decl_really_constant_value
so that they don't unshare their result.
* cp-tree.h (decl_constant_value): New declaration with an added
bool parameter.
(decl_really_constant_value): Add bool parameter defaulting to
true to existing declaration.
* init.c (constant_value_1): Add bool parameter which controls
whether to unshare the initializer before returning. Call
unshare_expr at most once.
(scalar_constant_value): Pass true to constant_value_1's new
bool parameter.
(decl_really_constant_value): Add bool parameter and forward it
to constant_value_1.
(decl_constant_value): Likewise, but instead define a new
overload with an added bool parameter.
gcc/testsuite/ChangeLog:
PR c++/96197
* g++.dg/cpp1y/constexpr-array8.C: New test.
Iain Sandoe [Wed, 6 Jan 2021 19:40:45 +0000 (19:40 +0000)]
testsuite, coroutines : Fix a bad testcase [PR96504].
Where possible (i.e. where that doesn't alter the intent of a test) we
use a suspend_always as the final suspend and a test that the coroutine
was 'done' to check that the state machine had terminated correctly.
Sometimes, filed PRs have 'suspend_never' as the final suspend expression
and that needs to be changed to match the testsuite style. This is one
I missed and means that the call to 'done()' on the handle is made to an
already-destructed coroutine. Surprisngly, thAt didn't actually trigger
a failure until glibc 2-32.
Fixed by changing the final suspend to be 'suspend_always'.
gcc/testsuite/ChangeLog:
PR c++/96504
* g++.dg/coroutines/torture/pr95519-05-gro.C: Use suspend_always
as the final suspend point so that we can check that the state
machine has reached the expected point.
This was a bad testcase, found with fsanitize=address; the final suspend
is 'suspend never' which flows off the end of the coroutine destroying
the promise and the frame. At that point access via the handle is an
error. Fixed by checking that the promise is destroyed via a global var.
gcc/testsuite/ChangeLog:
* g++.dg/coroutines/torture/co-ret-17-void-ret-coro.C: Check for
promise destruction via a global variable.
Paul Thomas [Sun, 2 Aug 2020 09:35:36 +0000 (10:35 +0100)]
This patch fixes PR96325. See the explanatory comment in the testcase.
2020-08-02 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/96325
* primary.c (gfc_match_varspec): In the case that a component
reference is added to an intrinsic type component, emit the
error message in this function.
Paul Thomas [Sat, 26 Dec 2020 15:08:11 +0000 (15:08 +0000)]
Fix failures with -m32 and some memory leaks.
2020-12-23 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/83118
* trans-array.c (gfc_alloc_allocatable_for_assignment): Make
sure that class expressions are captured for dummy arguments by
use of gfc_get_class_from_gfc_expr otherwise the wrong vptr is
used.
* trans-expr.c (gfc_get_class_from_gfc_expr): New function.
(gfc_get_class_from_expr): If a constant expression is
encountered, return NULL_TREE;
(gfc_trans_assignment_1): Deallocate rhs allocatable components
after passing derived type function results to class lhs.
* trans.h : Add prototype for gfc_get_class_from_gfc_expr.
Paul Thomas [Fri, 18 Dec 2020 14:00:11 +0000 (14:00 +0000)]
As well as the PR this patch fixes problems in handling class objects
2020-12-18 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/83118
PR fortran/96012
* resolve.c (resolve_ordinary_assign): Generate a vtable if
necessary for scalar non-polymorphic rhs's to unlimited lhs's.
* trans-array.c (get_class_info_from_ss): New function.
(gfc_trans_allocate_array_storage): Defer obtaining class
element type until all sources of class exprs are tried. Use
class API rather than TREE_OPERAND. Look for class expressions
in ss->info by calling get_class_info_from_ss. After, obtain
the element size for class descriptors. Where the element type
is unknown, cast the data as character(len=size) to overcome
unlimited polymorphic problems.
(gfc_conv_ss_descriptor): Do not fix class variable refs.
(build_class_array_ref, structure_alloc_comps): Replace code
replicating the new function gfc_resize_class_size_with_len.
(gfc_alloc_allocatable_for_assignment): Obtain element size
for lhs in cases of deferred characters and class enitities.
Move code for the element size of rhs to start of block. Clean
up extraction of class parameters throughout this function.
After the shape check test whether or not the lhs and rhs
element sizes are the same. Use earlier evaluation of
'cond_null'. Reallocation of lhs only to happen if size changes
or element size changes.
* trans-expr.c (gfc_resize_class_size_with_len): New function.
(gfc_get_class_from_expr): If a constant expression is
encountered, return NULL_TREE;
(trans_scalar_class_assign): New function.
(gfc_conv_procedure_call): Ensure the vtable is present for
passing a non-class actual to an unlimited formal.
(trans_class_vptr_len_assignment): For expressions of type
BT_CLASS, extract the class expression if necessary. Use a
statement block outside the loop body. Ensure that 'rhs' is
of the correct type. Obtain rhs vptr in all circumstances.
(gfc_trans_scalar_assign): Call trans_scalar_class_assign to
make maximum use of the vptr copy in place of assignment.
(trans_class_assignment): Actually do reallocation if needed.
(gfc_trans_assignment_1): Simplify some of the logic with
'realloc_flag'. Set 'vptr_copy' for all array assignments to
unlimited polymorphic lhs.
* trans.c (gfc_build_array_ref): Call gfc_resize_class_size_
with_len to correct span for unlimited polymorphic decls.
* trans.h : Add prototype for gfc_resize_class_size_with_len.
gcc/testsuite/
PR fortran/83118
PR fortran/96012
* gfortran.dg/dependency_60.f90: New test.
* gfortran.dg/class_allocate_25.f90: New test.
* gfortran.dg/class_assign_4.f90: New test.
* gfortran.dg/unlimited_polymorphic_32.f03: New test.
Jakub Jelinek [Tue, 5 Jan 2021 15:37:40 +0000 (16:37 +0100)]
reassoc: Fix reassociation on 32-bit hosts with > 32767 bbs [PR98514]
Apparently reassoc ICEs on large functions (more than 32767 basic blocks
with something to reassociate in those).
The problem is that the pass uses long type to store the ranks, and
the bb ranks are (number of SSA_NAMEs with default defs + 2 + bb->index) << 16,
so with many basic blocks we overflow the ranks and we then have assertions
rank is not negative.
The following patch just uses int64_t instead of long in the pass,
yes, it means slightly higher memory consumption (one array indexed by
bb->index is twice as large, and one hash_map from trees to the ranks
will grow by 50%, but I think it is better than punting on large functions
the reassociation on 32-bit hosts and making it inconsistent e.g. when
cross-compiling. Given vec.h uses unsigned for vect element counts,
we don't really support more than 4G of SSA_NAMEs or more than 2G of basic
blocks in a function, so even with the << 16 we can't really overflow the
int64_t rank counters.
2021-01-05 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/98514
* tree-ssa-reassoc.c (bb_rank): Change type from long * to
int64_t *.
(operand_rank): Change type from hash_map<tree, long> to
hash_map<tree, int64_t>.
(phi_rank): Change return type from long to int64_t.
(loop_carried_phi): Change block_rank variable type from long to
int64_t.
(propagate_rank): Change return type, rank parameter type and
op_rank variable type from long to int64_t.
(find_operand_rank): Change return type from long to int64_t
and change slot variable type from long * to int64_t *.
(insert_operand_rank): Change rank parameter type from long to
int64_t.
(get_rank): Change return type and rank variable type from long to
int64_t. Use PRId64 instead of ld to print the rank.
(init_reassoc): Change rank variable type from long to int64_t
and adjust correspondingly bb_rank and operand_rank initialization.
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.
git://gcc.gnu.org / gcc.git / log