2019-02-17 Thomas Koenig <tkoenig@gcc.gnu.org>
PR fortran/71066
* trans-decl.c (generate_coarray_sym_init): For an array
constructor in a DATA statement of a coarray variable, set the
rank to 1 to avoid confusion later on. If the constructor
contains only one value, use that for initiailizig.
2019-02-17 Thomas Koenig <tkoenig@gcc.gnu.org>
PR fortran/71066
* gfortran.dg/coarray_data_1.f90: New test.
From-SVN: r268960
PR rtl-optimization/66152
* builtins.h (c_readstr): Declare.
* builtins.c (c_readstr): Remove forward declaration. Add
null_terminated_p argument, if false, read all bytes from the
string instead of stopping after '\0'.
* expr.c (string_cst_read_str): New function.
(store_expr): Use string_cst_read_str instead of
builtin_strncpy_read_str. Try to store by pieces the whole
exp_len first, and only if that fails, split it up into
store by pieces followed by clear_storage. Formatting fix.
* gcc.target/i386/pr66152.c: New test.
From-SVN: r268957
Currently, the compiler lowers runtime.getcallersp to
__builtin_frame_address(1). In the C side of the runtime,
getcallersp is defined as __builtin_frame_address(0). They don't
match. Further, neither of them actually returns the caller's SP.
On AMD64, __builtin_frame_address(0) just returns the frame
pointer. __builtin_frame_address(1) returns the memory content
where the frame pointer points to, which is typically the
caller's frame pointer but can also be garbage if the frame
pointer is not enabled.
This CL changes it to use __builtin_dwarf_cfa(), which returns
the caller's SP at the call site. This matches the SP we get
from unwinding the stack.
Currently getcallersp is not used for anything real. It will be
used for precise stack scan (a new version of CL 159098).
Reviewed-on: https://go-review.googlesource.com/c/162905
* go-gcc.cc (Gcc_backend::Gcc_backend): Define __builtin_dwarf_cfa
instead of __builtin_frame_address.
From-SVN: r268952
PR go/89368
compiler: write barrier check nil-check policy tweak
Tweak the recipe for generating writeBarrier loads to insure that the
dereference expr is marked as not requiring a nil check (not needed
for gccgo, but needed for gollvm).
Fixes https://gcc.gnu.org/PR89368
Reviewed-on: https://go-review.googlesource.com/c/162904
From-SVN: r268948
There's a bit of a disconnect between the feature flags that don't test the fpu
and ones that do when the test itself also forces an architecture. The forcing
of the architecture would change the defaults and without explicitly giving the
correct fpu again the test would fail.
I don't see a good way to solve this problem, really the feature tests should
ideally contain the extra options the test adds too, but for this specific case
it can be solved by always testing the fpu explicitly.
Committed under the GCC obvious
gcc/testsuite/ChangeLog:
* lib/target-supports.exp
(check_effective_target_arm_neon_softfp_fp16_ok_nocache): Drop non-fpu
checking alternative.
From-SVN: r268943
* c-c++-common/patchable_function_entry-decl.c: Do not run on Visium.
* c-c++-common/patchable_function_entry-default.c: Likewise.
* c-c++-common/patchable_function_entry-definition.c: Likewise.
* gcc.dg/tree-ssa/pr84859.c: Add -ftree-cselim switch.
From-SVN: r268932
libgcc/
* config/visium/lib2funcs.c (__set_trampoline_parity): Replace
TRAMPOLINE_SIZE with __LIBGCC_TRAMPOLINE_SIZE__.
gcc/
* final.c (insn_current_reference_address): Replace test on JUMP_P
with test on jump_to_label_p.
* config/visium/visium-passes.def: New file.
* config/visium/t-visium (PASSES_EXTRA): Define.
* config/visium/visium-protos.h (make_pass_visium_reorg): Declare.
* config/visium/visium.h (TRAMPOLINE_SIZE): Adjust.
(TRAMPOLINE_ALIGNMENT): Define.
* config/visium/visium.c (visium_option_override): Do not register
the machine-specific reorg pass here.
(visium_trampoline_init): Align the BRA insn on a 64-bit boundary
for the GR6.
(output_branch): Adjust threshold for long branch instruction.
* config/visium/visium.md (cpu): Move around.
(length): Adjust for the GR6.
From-SVN: r268931
PR other/69006
PR testsuite/88920
* lib/gcc-dg.exp: If llvm_binutils effective target, set
allow_blank_lines to 2 during initialization.
(dg-allow-blank-lines-in-output): Set allow_blank_lines to 1 only if
it was previously zero.
(gcc-dg-prune): Don't check for llvm_binutils effective target here.
Clear allow_blank_lines afterwards whenever it was 1.
* gdc.test/gdc-test.exp (dmd2dg): Don't call
dg-allow-blank-lines-in-output here.
(gdc-do-test): Set allow_blank_lines to 3 if it is 0 before running
the tests and restore it back at the end.
From-SVN: r268930
* c-c++-common/ubsan/opts-1.c: New test.
* c-c++-common/ubsan/opts-2.c: New test.
* c-c++-common/ubsan/opts-3.c: New test.
* c-c++-common/ubsan/opts-4.c: New test.
From-SVN: r268929
PR tree-optimization/89278
* tree-loop-distribution.c: Include tree-eh.h.
(generate_memset_builtin, generate_memcpy_builtin): Call
rewrite_to_non_trapping_overflow on builtin->size before passing it
to force_gimple_operand_gsi.
* gcc.dg/pr89278.c: New test.
Co-Authored-By: Jakub Jelinek <jakub@redhat.com>
From-SVN: r268927
PR c/89340
* c-decl.c (start_function): Clear TREE_PUBLIC on nested functions
before c_decl_attributes rather than after it.
* gcc.dg/pr89340.c: New test.
* gcc.dg/torture/pr57036-2.c (jpgDecode_convert): Expect a warning
that leaf attribute on nested function is useless.
From-SVN: r268926
Compiling with LTO revealed a number of cases in the runtime and
standard library where C and Go disagreed about the type of an object or
function (or where Go and code generated by the compiler disagreed). In
all cases the underlying representation was the same (e.g., uintptr vs.
void*), so this wasn't causing actual problems, but it did result in a
number of annoying warnings when compiling with LTO.
Reviewed-on: https://go-review.googlesource.com/c/160700
From-SVN: r268923
PR go/89168
libgo: change gotest to run examples with output
Change the gotest script to act like "go test" and run examples that
have "output" comments. This is not done with full generality, but
just enough to run the libgo tests. Other packages should be tested
with "go test" as usual.
While we're here clean up some old bits of gotest, and only run
TestXXX functions that are actually in *_test.go files. The latter
change should fix https://gcc.gnu.org/PR89168.
Reviewed-on: https://go-review.googlesource.com/c/162139
From-SVN: r268922
* config/i386/i386.h (TARGET_SUBTARGET64_ISA_DEFAULT):
Enable MMX, SSE and SSE2 by default.
* config/i386/i386.c (ix86_option_override_internal): Do not
explicitly set MMX, SSE and SSE2 flags for TARGET_64BIT here.
From-SVN: r268917
PR rtl-optimization/89354
* combine.c (make_extraction): Punt if extraction_mode is narrower
than len bits.
* gcc.dg/pr89354.c: New test.
From-SVN: r268913
Make the option handling code parse the -flag-init-integer value as a
C long type, allowing a larger range on systems where long is a larger
type than int. Document the behavior.
Regtested on x86_64-pc-linux-gnu, committed as obvious.
2019-02-14 Janne Blomqvist <jb@gcc.gnu.org>
PR fortran/81552
* gfortran.h (gfc_option_t): Make flag_init_integer_value a long.
* options.c (gfc_handle_option): Use strtol instead of atoi.
* invoke.texi: Document -finit-integer behavior in more detail
From-SVN: r268906
2018-02-14 Steve Ellcey <sellcey@marvell.com>
* config/aarch64/aarch64.c (aarch64_attribute_table): Change
affects_type_identity to true for aarch64_vector_pcs.
(aarch64_comp_type_attributes): New function.
(TARGET_COMP_TYPE_ATTRIBUTES): New macro.
From-SVN: r268902
2019-02-14 Harald Anlauf <anlauf@gmx.de>
PR fortran/88248
* symbol.c: Move check for labeled DO statement from
gfc_define_st_label to gfc_reference_st_label.
PR fortran/88248
* gfortran.dg/pr88248.f90: New test.
* gfortran.dg/f2018_obs.f90: Updated test.
From-SVN: r268895
The iterator ANY64 are used in various general split patterns and is supposed
to contain all 64 bit modes.
For some reason the pattern has HI but not HF. This adds HF so that general
64 bit splits are generated for these modes as well. These are required
by various split patterns that expect them to be there.
gcc/ChangeLog:
PR target/88850
* config/arm/iterators.md (ANY64): Add V4HF.
gcc/testsuite/ChangeLog:
PR target/88850
* gcc.target/arm/pr88850-2.c: New test.
* lib/target-supports.exp
(check_effective_target_arm_neon_softfp_fp16_ok_nocache,
check_effective_target_arm_neon_softfp_fp16_ok,
add_options_for_arm_neon_softfp_fp16): New.
From-SVN: r268884
Because uses-allocator construction is invariably done with a const
lvalue the __uses_alloc helper should use a const lvalue for the
is_constructible checks. Otherwise, it can detect that the type can be
constructed from an rvalue, and then an error happens when a const
lvalue is passed to the constructor instead.
Prior to LWG DR 2586 scoped_allocator_adaptor incorrectly used an rvalue
type in the is_constructible check and then used a non-const lvalue for
the actual construction. The other components using uses-allocator
construction (tuple and polymorphic_allocator) have always done so with
a const lvalue allocator, although the use of __use_alloc in our
implementation meant they behaved the same as scoped_allocator_adaptor
and incorrectly used rvalues for the is_constructible checks.
In C++20 the P0591R4 changes mean that all uses-allocator construction
is defined in terms of the new uses_allocator_construction_args
functions, which always use a const lvalue allocator.
The changes in this patch ensure that the __use_alloc helper correctly
matches the requirements in the standard, consistently using a const
lvalue allocator for the is_constructible checks and the actual
constructor arguments.
* doc/xml/manual/intro.xml: Document LWG 2586 status.
* include/bits/uses_allocator.h (__uses_alloc): Use const lvalue
allocator type in is_constructible checks.
* testsuite/20_util/scoped_allocator/69293_neg.cc: Adjust dg-error.
* testsuite/20_util/scoped_allocator/dr2586.cc: New test.
* testsuite/20_util/tuple/cons/allocators.cc: Add test using
problematic type from LWG 2586 discussion.
* testsuite/20_util/uses_allocator/69293_neg.cc: Adjust dg-error.
* testsuite/20_util/uses_allocator/cons_neg.cc: Likewise.
From-SVN: r268882
When this testcase was introduced it failed to account for the possibility of
targets that do not support arm mode or that do not support the ldrd/strd
instructions.
This patch accounts for both of these by adding some
dg-require-effective-target lines to the testcase.
This patch also adds a new effective-target procedure to check a target
supports ldrd/strd.
This patch also adds a new effective-target procedure to check a target
supports arm ldrd/strd.
The check uses the 'r' constraint to ensure SP is not used so that it will work
for thumb mode code generation as well as arm mode.
Tested by running this testcase with cross compilers using "-march=armv5t",
"-mcpu=cortex-m3", "-mcpu-arm7tdmi", "-mcpu=cortex-a9 -march=armv5t" for both
arm-none-eabi and arm-none-linux-gnueabihf.
Also ran this testcase with `make check` natively.
gcc/testsuite/ChangeLog:
2019-02-14 Matthew Malcomson <matthew.malcomson@arm.com>
* gcc.dg/rtl/arm/ldrd-peepholes.c: Restrict testcase.
* lib/target-supports.exp: Add procedure to check for ldrd.
From-SVN: r268881
