PR analyzer/94099 and PR analyzer/94105 both report ICEs relating to
calling region_model::get_lvalue on a NOP_EXPR.

PR analyzer/94099's ICE happens when generating a checker_path when
encountering an unhandled tree code (NOP_EXPR) in get_lvalue with a
NULL context (from for_each_state_change).

PR analyzer/94105 ICE happens when handling an ARRAY_REF where the
first operand is a NOP_EXPR: the unhandled tree code gives us
a symbolic_region, but the case for ARRAY_REF assumes we have an
array_region.

This patch fixes the ICEs by handling NOP_EXPR within
region_model::get_lvalue, and bulletproofs both of the above sources
of failure.

gcc/analyzer/ChangeLog:
	PR analyzer/94099
	PR analyzer/94105
	* diagnostic-manager.cc (for_each_state_change): Bulletproof
	against errors in get_rvalue by passing a
	tentative_region_model_context and rejecting if there's an error.
	* region-model.cc (region_model::get_lvalue_1): When handling
	ARRAY_REF, handle results of error-handling.  Handle NOP_EXPR.

gcc/testsuite/ChangeLog:
	PR analyzer/94099
	PR analyzer/94105
	* gcc.dg/analyzer/pr94099.c: New test.
	* gcc.dg/analyzer/pr94105.c: New test.

1. Implement DIP 1010 - (Static foreach)

Support for 'static foreach' has been added.  'static foreach' is a conditional
compilation construct that is to 'foreach' what 'static if' is to 'if'.  It is
a convenient way to generate declarations and statements by iteration.

    import std.conv: to;

    static foreach(i; 0 .. 10)
    {

        // a 'static foreach' body does not introduce a nested scope
        // (similar to 'static if').

        // The following mixin declaration is at module scope:
        // declares 10 variables x0, x1, ..., x9
        mixin('enum x' ~ to!string(i) ~ ' = i;');
    }

    import std.range: iota;
    // all aggregate types that can be iterated with a standard 'foreach'
    // loop are also supported by static foreach:
    static foreach(i; iota(10))
    {
        // we access the declarations generated in the first 'static foreach'
        pragma(msg, "x", i, ": ", mixin(`x` ~ to!string(i)));
        static assert(mixin(`x` ~ to!string(i)) == i);
    }

    void main()
    {
        import std.conv: text;
        import std.typecons: tuple;
        import std.algorithm: map;
        import std.stdio: writeln;

        // 'static foreach' has both declaration and statement forms
        // (similar to 'static if').

        static foreach(x; iota(3).map!(i => tuple(text("x", i), i)))
        {
            // generates three local variables x0, x1 and x2.
            mixin(text(`int `,x[0],` = x[1];`));

            scope(exit) // this is within the scope of 'main'
            {
                writeln(mixin(x[0]));
            }
        }

        writeln(x0," ",x1," ",x2); // first runtime output
    }

2. Aliases can be created directly from a '__trait'.

Aliases can be created directly from the traits that return symbol(s) or
tuples.  This includes 'getMember', 'allMembers', 'derivedMembers', 'parent',
'getOverloads', 'getVirtualFunctions', 'getVirtualMethods', 'getUnitTests',
'getAttributes' and finally 'getAliasThis'.  Previously an 'AliasSeq' was
necessary in order to alias their return.  Now the grammar allows to write
shorter declarations:

    struct Foo
    {
        static int a;
    }

    alias oldWay = AliasSeq!(__traits(getMember, Foo, "a"))[0];
    alias newWay = __traits(getMember, Foo, "a");

To permit this it was more interesting to include '__trait' in the basic types
rather than just changing the alias syntax. So additionally, wherever a type
appears a '__trait' can be used, for example in a variable declaration:

    struct Foo { static struct Bar {} }
    const(__traits(getMember, Foo, "Bar")) fooBar;
    static assert(is(typeof(fooBar) == const(Foo.Bar)));

3. fix Issue 10100 - Identifiers with double underscores and allMembers

The identifer whitelist has been converted into a blacklist of all possible
internal D language declarations.

Reviewed-on: https://github.com/dlang/dmd/pull/10791

2020-03-13  Vasee Vinayagamoorthy  <vaseeharan.vinayagamoorthy@arm.com>

gcc/testsuite/
	* gcc.target/aarch64/advsimd-intrinsics/bfcvt-nosimd.c: Fix DejaGnu
	typo.

2020-03-13  Vladimir Makarov  <vmakarov@redhat.com>

	PR rtl-optimization/92303
	* lra-spills.c (remove_pseudos): Try to simplify memory subreg.

gcc/testsuite/ChangeLog:

       * gcc.dg/torture/pr54261-1.c: Correct built-in declartion.

gcc/c/ChangeLog:

	PR c/94040
	* c-decl.c (builtin_structptr_type_count): New constant.
	(match_builtin_function_types): Reject decls that are incompatible
	in types pointed to by pointers.
	(diagnose_mismatched_decls): Adjust comments.

gcc/testsuite/ChangeLog:

	PR c/94040
	* gcc.dg/Wbuiltin-declaration-mismatch-12.c: Relax test to look
	for warning name rather than the exact text.
	* gcc.dg/Wbuiltin-declaration-mismatch-14.c: New test.
	* gcc.dg/Wbuiltin-declaration-mismatch-15.c: New test.
	* gcc.dg/pr62090.c: Prune expected warning.
	* gcc.dg/pr89314.c: Look for warning name rather than text.

	* gcc.target/i386/pr64409.c: Do not limit compilation to x32 targets.
	(dg-error): Quote 'ms_abi' attribute.
	* gcc.target/i386/pr71958.c: Do not limit compilation to x32 targets.
	Require maybe_x32 effective target.
	(dg-options): Add -mx32.
	(dg-error): Quote 'ms_abi' attribute.
	* gcc.target/i386/pr90096.c (dg-error): Update relative
	location of target x32 error.

The df dataflow solvers use the aux field in the basic_block struct,
although that is reserved for any use by passes.  And not only that,
it is required that you set all such fields to NULL before calling
the solvers, or you quietly get wrong results.

This changes the solvers to use a local array for last_change_age
instead, just like it already had a local array for last_visit_age.

	PR rtl-optimization/94148
	PR rtl-optimization/94042
	* df-core.c (BB_LAST_CHANGE_AGE): Delete.
	(df_worklist_propagate_forward): New parameter last_change_age, use
	that instead of bb->aux.
	(df_worklist_propagate_backward): Ditto.
	(df_worklist_dataflow_doublequeue): Use a local array last_change_age.

In build_over_call, we are emitting a redundant -Wdeprecated-declarations
warning about the deprecated callee function, first from mark_used and again
from build_addr_func <- decay_conversion <- cp_build_addr_expr <- mark_used.

It seems this second deprecation warning coming from build_addr_func will always
be redundant, so we can safely use a warning_sentinel to disable it before
calling build_addr_func.  (And any deprecation warning that could come from
build_addr_func would be for FN, so we wouldn't be suppressing too much.)

gcc/cp/ChangeLog:

	PR c++/67960
	* call.c (build_over_call): Use a warning_sentinel to disable
	warn_deprecated_decl before calling build_addr_func.

gcc/testsuite/ChangeLog:

	PR c++/67960
	* g++.dg/diagnostic/pr67960.C: New test.
	* g++.dg/diagnostic/pr67960-2.C: New test.

This avoids HWI -> unsigned truncation to end up with zero alignment
which set_ptr_info_alignment ICEs on.

2020-03-13  Richard Biener  <rguenther@suse.de>

	PR tree-optimization/94163
	* tree-ssa-pre.c (create_expression_by_pieces): Check
	whether alignment would be zero.

	PR lto/94157
	* lto-wrapper.c (run_gcc): Use concat for appending
	to collect_gcc_options.
	PR lto/94157
	* gcc.dg/lto/pr94157_0.c: New test.

This patch is to apply the same fix as r267528 to another similar case
bb-slp-over-widen-2.c which requires misaligned vector access.

gcc/testsuite/ChangeLog

    PR testsuite/93935
    * gcc.dg/vect/bb-slp-over-widen-2.c: Expect basic block vectorized
    messages only on vect_hw_misalign targets.

> I'm getting this ICE with -mabi=ilp32:
>
> during RTL pass: fwprop1
> /opt/gcc/gcc-20200312/gcc/testsuite/gcc.dg/pr94121.c: In function 'bar':
> /opt/gcc/gcc-20200312/gcc/testsuite/gcc.dg/pr94121.c:16:1: internal compiler error: in decompose, at rtl.h:2279

That is a preexisting issue, caused by another bug in the same function.
When mode is SImode and moffset is 0x80000000 (or anything else with the
bit 31 set), we need to sign-extend it.

2020-03-13  Jakub Jelinek  <jakub@redhat.com>

	PR target/94121
	* config/aarch64/aarch64.c (aarch64_add_offset_1): Use gen_int_mode
	instead of GEN_INT.

There is no need to set mode attribute to XImode nor V8DFmode since
ix86_output_ssemov can properly encode xmm16-xmm31 registers with and
without AVX512VL.

gcc/

	PR target/89229
	* config/i386/i386.c (ix86_output_ssemov): Handle MODE_DF.
	* config/i386/i386.md (*movdf_internal): Call ix86_output_ssemov
	for TYPE_SSEMOV.  Remove TARGET_AVX512F, TARGET_PREFER_AVX256,
	TARGET_AVX512VL and ext_sse_reg_operand check.

gcc/testsuite/

	PR target/89229
	* gcc.target/i386/pr89229-4a.c: New test.
	* gcc.target/i386/pr89229-4b.c: Likewise.
	* gcc.target/i386/pr89229-4c.c: Likewise.

-mlow-precision-div hard-coded the number of iterations to 2 for double
and 1 for float.  This patch adds a --param to control the number.

2020-03-13  Bu Le  <bule1@huawei.com>

gcc/
	PR target/94154
	* config/aarch64/aarch64.opt (-param=aarch64-float-recp-precision=)
	(-param=aarch64-double-recp-precision=): New options.
	* doc/invoke.texi: Document them.
	* config/aarch64/aarch64.c (aarch64_emit_approx_div): Use them
	instead of hard-coding the choice of 1 for float and 2 for double.

The issue is that relax_delay_slots can streamline the CFG in some cases,
in particular remove BARRIERs, but removing BARRIERs changes the way the
instructions are associated with (basic) blocks by the liveness analysis
code in resource.c (find_basic_block) and thus can cause entries in the
cache maintained by resource.c to become outdated, thus producing wrong
answers downstream.

The fix is to invalidate the cache entries affected by the removal of
BARRIERs in relax_delay_slots, i.e. for the instructions down to the
next BARRIER.

	PR rtl-optimization/94119
	* resource.h (clear_hashed_info_until_next_barrier): Declare.
	* resource.c (clear_hashed_info_until_next_barrier): New function.
	* reorg.c (add_to_delay_list): Fix formatting.
	(relax_delay_slots): Call clear_hashed_info_until_next_barrier on
	the next instruction after removing a BARRIER.

store_integral_bit_field is ready to handle BLKmode fields, there is
even a subtlety with their handling on big-endian targets, see e.g.
PR middle-end/50325, but not if they are unaligned, so the fix is
simply to call extract_bit_field for them in order to generate an
unaligned load.  As a bonus, this subsumes  the big-endian specific
path that was added under PR middle-end/50325.

	PR middle-end/92071
	* expmed.c (store_integral_bit_field): For fields larger than a
	word, call extract_bit_field on the value if the mode is BLKmode.
	Remove specific path for big-endian targets and tidy things up a
	little bit.

        PR rtl-optimization/90275
        * cse.c (cse_insn): Delete no-op register moves too.

        PR rtl-optimization/90275
        * gcc.c-torture/compile/pr90275.c: New test.

Support for the CPEN control register was removed in rev .50 of the RXv1 Instruction Set Architecture manual in Feb 2009.  This patch removes it from GCC.

	* config/rx/rx.md (CTRLREG_CPEN): Remove.
	* config/rx/rx.c (rx_print_operand): Remove CTRLREG_CPEN support.

2020-03-12  Jakub Jelinek  <jakub@redhat.com>

	* gcc_release (upload_files): Without -l, pass -m 755 to the mkdir
	command invoked through ssh.

scripts/update_web_docs_git -r 9.3.0 -d gcc-9.3.0
failed after the sourceware upgrade, there is no python-sphinx10 package and
python3-sphinx is new enough that the docs build succeeded.

2020-03-12  Jakub Jelinek  <jakub@redhat.com>

	* update_web_docs_git: Drop SPHINXBUILD=/usr/bin/sphinx-1.0-build.

VN currently replaces a load of a 16 byte entity 128 bits of precision
(TImode) with the result of a load of a 16 byte entity with 80 bits of
mode precision (XFmode).  That will go downhill since if the padding
bits are not actually filled with memory contents those bits are
missing.

2020-03-12  Richard Biener  <rguenther@suse.de>

	PR tree-optimization/94103
	* tree-ssa-sccvn.c (visit_reference_op_load): Avoid type
	punning when the mode precision is not sufficient.

	* gcc.target/i386/pr94103.c: New testcase.

This test fails in the Fedora RPM build (but not elsewhere, for unknown
reasons). The warning is correct, we're passing a null pointer.

	* testsuite/tr1/8_c_compatibility/cstdlib/functions.cc: Do not pass
	a null pointer to functions with nonnull(1) attribute.

There is no need to set mode attribute to XImode since ix86_output_ssemov
can properly encode xmm16-xmm31 registers with and without AVX512VL.

	PR target/89229
	* config/i386/i386.c (ix86_output_ssemov): Handle MODE_DI,
	MODE_V1DF and MODE_V2SF.
	* config/i386/mmx.md (MMXMODE:*mov<mode>_internal): Call
	ix86_output_ssemov for TYPE_SSEMOV.  Remove ext_sse_reg_operand
	check.

2020-03-12  Tobias Burnus  <tobias@codesourcery.com>

        PR middle-end/94120
        * openmp.c (gfc_match_oacc_declare): Accept function-result
        variables; reject variables declared in a different scoping unit.

2020-03-12  Tobias Burnus  <tobias@codesourcery.com>

        PR middle-end/94120
        * gfortran.dg/goacc/pr78260-2.f90: Correct scan-tree-dump-times.
        Extend test case to result variables.
        * gfortran.dg/goacc/declare-2.f95: Actually check module-declaration
        restriction of OpenACC.
        * gfortran.dg/goacc/declare-3.f95: Remove case where this
        restriction is violated.
        * gfortran.dg/goacc/pr94120-1.f90: New.
        * gfortran.dg/goacc/pr94120-2.f90: New.
        * gfortran.dg/goacc/pr94120-3.f90: New.

When looking into PR94134, I've noticed bugs in the
ASM_OUTPUT_ALIGNED_DECL_LOCAL documentation.  varasm.c has:
  #if defined ASM_OUTPUT_ALIGNED_DECL_LOCAL
    unsigned int align = symtab_node::get (decl)->definition_alignment ();
    ASM_OUTPUT_ALIGNED_DECL_LOCAL (asm_out_file, decl, name,
                                   size, align);
    return true;
  #elif defined ASM_OUTPUT_ALIGNED_LOCAL
    unsigned int align = symtab_node::get (decl)->definition_alignment ();
    ASM_OUTPUT_ALIGNED_LOCAL (asm_out_file, name, size, align);
    return true;
  #else
    ASM_OUTPUT_LOCAL (asm_out_file, name, size, rounded);
    return false;
  #endif
and the ASM_OUTPUT_ALIGNED_LOCAL documentation properly mentions:
Like @code{ASM_OUTPUT_LOCAL} and mentions the same macro in another place.
The ASM_OUTPUT_ALIGNED_DECL_LOCAL description mentions non-existing macros
ASM_OUTPUT_ALIGNED_DECL and ASM_OUTPUT_DECL instead of the right ones
ASM_OUTPUT_ALIGNED_LOCAL and ASM_OUTPUT_LOCAL.

2020-03-12  Jakub Jelinek  <jakub@redhat.com>

	* doc/tm.texi.in (ASM_OUTPUT_ALIGNED_DECL_LOCAL): Change
	ASM_OUTPUT_ALIGNED_DECL in description to ASM_OUTPUT_ALIGNED_LOCAL
	and ASM_OUTPUT_DECL to ASM_OUTPUT_LOCAL.
	* doc/tm.texi: Regenerated.

As the testcase shows, if DSE decides to head trim {mem{set,cpy,move},strncpy}
and the call has lhs, it is incorrect to leave the lhs as is, because it
will then point to the adjusted address (base + head_trim) instead of the
original base.
The following patch fixes that by dropping the lhs of the call and assigning
lhs the original base in a following statement.

2020-03-12  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/94130
	* tree-ssa-dse.c: Include gimplify.h.
	(increment_start_addr): If stmt has lhs, drop the lhs from call and
	set it after the call to the original value of the first argument.
	Formatting fixes.
	(decrement_count): Formatting fix.

	* gcc.c-torture/execute/pr94130.c: New test.

Isn't it wasteful to first copy perhaps a large constructor (recursively)
and then truncate it to very few elts (zero in this case)?

> We should certainly avoid copying if they're the same.  The code above for
> only copying the bits that aren't going to be thrown away seems pretty
> straightforward, might as well use it even if the savings aren't likely to
> be large.

Calling vec_safe_truncate with the same number of elts the vector already
has is a nop, so IMHO we just should make sure we only unshare if it
changed.

2020-03-12  Jakub Jelinek  <jakub@redhat.com>

	PR c++/94124
	* decl.c (reshape_init_array_1): Don't unshare constructor if there
	aren't any trailing zero elts, otherwise only unshare the first
	nelts.

This updates myself to the right place in MAINTAINERS.

gcc/ChangeLog

2020-03-11  Bin Bin Lv  <shlb@linux.ibm.com>

	* MAINTAINERS (Write After Approval): Update myself.

The source file rs6000.c was split up into several smaller source files
through commit 1acf0246.  However, variable "altivec_builtin_mask_for_load" and
"builtin_mode_to_type[MAX_MACHINE_MODE][2]" were marked with the wrong syntax
"GTY(([options])) type name", which led these two variables were not marked as
roots correctly and wrongly GCed.  And when "altivec_builtin_mask_for_load"
was wrongly GCed, the compiling for openJDK is failed with ICEs enabling
precompiled header under mcpu=power7.  So roots must be declared using one of
the following syntaxes: "extern GTY(([options])) type name;" and "static
GTY(([options])) type name;".

And the following patch adds variable "altivec_builtin_mask_for_load" and
"builtin_mode_to_type[MAX_MACHINE_MODE][2]" into the roots array.

Bootstrap and regression tests were done on powerpc64le-linux-gnu (LE) with no
regressions.

gcc/ChangeLog

2020-03-11  Bin Bin Lv  <shlb@linux.ibm.com>

	* config/rs6000/rs6000-internal.h (altivec_builtin_mask_for_load,
	builtin_mode_to_type): Remove the declaration.
	* config/rs6000/rs6000.h (altivec_builtin_mask_for_load,
	builtin_mode_to_type): Add an extern GTY(()) declaration.
	* config/rs6000/rs6000.c (altivec_builtin_mask_for_load,
	builtin_mode_to_type): Remove the GTY(()) declaration.

This adds myself to MAINTAINERS in the Write After Approval section.

gcc/ChangeLog

2020-03-11  Bin Bin Lv  <shlb@linux.ibm.com>

	* MAINTAINERS (Write After Approval): Add myself.

The test FAILs on 32-bit targets that don't have __int128 type.

2020-03-12  Jakub Jelinek  <jakub@redhat.com>

	PR c++/93907
	* g++.dg/cpp2a/concepts-using2.C (cc): Use long long instead of
	__int128 if __SIZEOF_INT128__ isn't defined.

The problem here was that we were checking satisfaction once with 'e', a
typedef of 'void', and another time with 'void' directly, and treated them
as different for hashing based on the assumption that
canonicalize_type_argument would have already removed a typedef that wasn't
a complex dependent alias.  But that wasn't happening here, so let's add a
call.

gcc/cp/ChangeLog
2020-03-11  Jason Merrill  <jason@redhat.com>

	PR c++/93907
	* constraint.cc (tsubst_parameter_mapping): Canonicalize type
	argument.

I got a report that building Chromium fails with the "modifying a const
object" error.  After some poking I realized it's a bug in GCC, not in
their codebase.

Much like with ARRAY_REFs, which can be const even though the array
itself isn't, COMPONENT_REFs can be const although neither the object
nor the field were declared const.  So let's dial down the checking.
Here the COMPONENT_REF was const because of the "const_cast<const U &>(m)"
thing -- cxx_eval_component_reference then builds a COMPONENT_REF with
TREE_TYPE (t).

While looking into this I noticed that we don't detect modifying a const
object in certain cases like in
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94074#c2>.  That's because
we never evaluate an X::X() CALL_EXPR -- there's none.  Fixed as per
Jason's suggestion by setting TREE_READONLY on a CONSTRUCTOR after
initialization in cxx_eval_store_expression.

2020-03-11  Marek Polacek  <polacek@redhat.com>
	    Jason Merrill  <jason@redhat.com>

	PR c++/94074 - wrong modifying const object error for COMPONENT_REF.
	* constexpr.c (cref_has_const_field): New function.
	(modifying_const_object_p): Consider a COMPONENT_REF
	const only if any of its fields are const.
	(cxx_eval_store_expression): Mark a CONSTRUCTOR of a const type
	as readonly after its initialization has been done.

	* g++.dg/cpp1y/constexpr-tracking-const17.C: New test.
	* g++.dg/cpp1y/constexpr-tracking-const18.C: New test.
	* g++.dg/cpp1y/constexpr-tracking-const19.C: New test.
	* g++.dg/cpp1y/constexpr-tracking-const20.C: New test.
	* g++.dg/cpp1y/constexpr-tracking-const21.C: New test.
	* g++.dg/cpp1y/constexpr-tracking-const22.C: New test.

This adds a tests that verifies taking the split_view of a non-forward range
works correctly.  Doing so revealed a typo in one of _OuterIter's constructors.

It also revealed that the default constructor of
__gnu_test::test_range::iterator misbehaves, because by delegating to
Iter<T>(nullptr, nullptr) we perform a null-pointer deref at runtime in
input_iterator_wrapper's constructor due to the ITERATOR_VERIFY check therein.
Instead of delegating to this constructor it seems we can just inherit the
protected default constructor, which does not contain this ITERATOR_VERIFY
check.

libstdc++-v3/ChangeLog:

	* include/std/ranges (split_view::_OuterIter::_OuterIter): Typo fix,
	'address' -> 'std::__addressof'.
	* testsuite/std/ranges/adaptors/split.cc: Test taking the split_view of
	a non-forward input_range.
	* testsuite/util/testsuite_iterators.h (output_iterator_wrapper): Make
	default constructor protected instead of deleted, like with
	input_iterator_wrapper.
	(test_range::iterator): Add comment explaining that this type is used
	only when the underlying wrapper is input_iterator_wrapper or
	output_iterator_wrapper.  Remove delegating defaulted constructor so
	that the inherited default constructor is used instead.

This patch fixes a bug introduced by my earlier patch (
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541680.html ).
It introduces a new scalar builtin type that was missing in the original
patch.

Bootstrapped cleanly on arm-none-linux-gnueabihf.
Tested for regression on arm-none-linux-gnueabihf. No regression from
before the original patch.
Tests that failed or became unsupported because of the original tests
now work as they did before it.

	* config/arm/arm-builtins.c
	(arm_init_simd_builtin_scalar_types): New.
	* config/arm/arm_neon.h (vld2_bf16): Used new builtin type.
	(vld2q_bf16): Used new builtin type.
	(vld3_bf16): Used new builtin type.
	(vld3q_bf16): Used new builtin type.
	(vld4_bf16): Used new builtin type.
	(vld4q_bf16): Used new builtin type.
	(vld2_dup_bf16): Used new builtin type.
	(vld2q_dup_bf16): Used new builtin type.
	(vld3_dup_bf16): Used new builtin type.
	(vld3q_dup_bf16): Used new builtin type.
	(vld4_dup_bf16): Used new builtin type.
	(vld4q_dup_bf16): Used new builtin type.

As mentioned in the PR, the generic code decides to put the a variable into
lcomm_section, which is a NOSWITCH section and thus the generic code doesn't
switch into a particular section before using
ASM_OUTPUT{_ALIGNED{,_DECL}_}_LOCAL, on many targets that results just in
.lcomm (or for non-local .comm) directives which don't need a switch to some
section, other targets put switch_to_section (bss_section) at the start of
that macro.
pdp11 doesn't do that (and doesn't have bss_section), and so emits the
lcomm/comm variables in whatever section is current (it has only .text/.data
and for DEC assembler rodata).

The following patch fixes that by putting it always into data section, and
additionally avoids emitting an empty line in the assembly for the lcomm
vars.

2020-03-11  Jakub Jelinek  <jakub@redhat.com>

	PR target/94134
	* config/pdp11/pdp11.c (pdp11_asm_output_var): Call switch_to_section
	at the start to switch to data section.  Don't print extra newline if
	.globl directive has not been emitted.

	* gcc.c-torture/execute/pr94134.c: New test.