The following testcase FAILs, because gimplify_body adds a GIMPLE_NOP only
when there are no statements in the function and with -g there is a
DEBUG_BEGIN_STMT, so it doesn't add it and due to -fno-tree-dce that never
gets removed afterwards. Similarly, if the body seq after gimplification
contains some DEBUG_BEGIN_STMTs plus a single gbind, then we could behave
differently between -g0 and -g, by using that gbind as the body in the -g0
case and not in the -g case.
This patch fixes that by ignoring DEBUG_BEGIN_STMTs (other debug stmts can't
appear at this point yet thankfully) during decisions and if we pick the
single gbind and there are DEBUG_BEGIN_STMTs next to it, it moves them into
the gbind.
While debugging this, I found also a bug in the gimple_seq_last_nondebug_stmt
function, for a seq that has a single non-DEBUG_BEGIN_STMT statement
followed by one or more DEBUG_BEGIN_STMTs it would return NULL rather than
the first statement.
2020-03-26 Jakub Jelinek <jakub@redhat.com>
PR debug/94281
* gimple.h (gimple_seq_first_nondebug_stmt): New function.
(gimple_seq_last_nondebug_stmt): Don't return NULL if seq contains
a single non-debug stmt followed by one or more debug stmts.
* gimplify.c (gimplify_body): Use gimple_seq_first_nondebug_stmt
instead of gimple_seq_first_stmt, use gimple_seq_first_nondebug_stmt
and gimple_seq_last_nondebug_stmt instead of gimple_seq_first and
gimple_seq_last to check if outer_stmt gbind could be reused and
if yes and it is surrounded by any debug stmts, move them into the
gbind body.
* g++.dg/debug/pr94281.C: New test.
The standard says: "A function is user-provided if it is user-declared and
not explicitly defaulted or deleted on its first declaration."
I don't see anything about function templates having different rules here,
but user_provided_p does return true for all TEMPLATE_DECLs.
The following patch fixes it by treating as user-provided only templates
that aren't deleted.
2020-03-26 Jakub Jelinek <jakub@redhat.com>
PR c++/81349
* class.c (user_provided_p): Use STRIP_TEMPLATE instead of returning
true for all TEMPLATE_DECLs.
* g++.dg/cpp1z/pr81349.C: New test.
The following testcase FAILs with -fcompare-debug. The problem is that
the C++ FE initially uses IF_STMTs, tcc_statement which default to
TREE_SIDE_EFFECTS set, but later on is genericized into COND_EXPRs,
tcc_expression which default to TREE_SIDE_EFFECTS ored from all 3 operands.
Furthermore, with -g we emit by default DEBUG_BEGIN_STMTs (TREE_SIDE_EFFECTS
clear) and so end up with a STATEMENT_LIST containing DEBUG_BEGIN_STMT
+ e.g. the IF_STMT, while with -g0 we would end up with just the IF_STMT
alone and in that case there is no STATEMENT_LIST wrapping it.
Now, the STATEMENT_LIST has TREE_SIDE_EFFECTS set to match the IF_STMT,
but if none of the 3 operands (condition and both branches) have
TREE_SIDE_EFFECTS, genericize_if_stmt will replace the IF_STMT with
COND_EXPR without TREE_SIDE_EFFECTS, but with -g only STATEMENT_LIST
wrapping it will keep TREE_SIDE_EFFECTS. Then during gimplification,
shortcut_cond_expr checks TREE_SIDE_EFFECTS of the operands and as it
is differennt between -g and -g0, will generate different code.
The following patch attempts to fix this by clearing TREE_SIDE_EFFECTS
on STATEMENT_LISTs that initially have it set and contain only
DEBUG_BEGIN_STMT or at most one other statement that lost TREE_SIDE_EFFECTS
during the genericization.
2020-03-26 Jakub Jelinek <jakub@redhat.com>
PR c++/94272
* cp-gimplify.c (cp_genericize_r): Handle STATEMENT_LIST.
* g++.dg/debug/pr94272.C: New test.
With this simple patch, on i686-linux and x86_64-linux with -m32 (no change
for -m64), the find_base_term visited_vals.length () > 100 find_base_term
statistics changed (fbt is before this patch, fbt2 with this patch):
for k in '' '1$'; do for i in 32 64; do for j in fbt fbt2; do \
echo -n "$j $i $k "; LC_ALL=C grep ^$i.*"$k" $j | wc -l; done; done; done
fbt 32 5313355
fbt2 32 4229854
fbt 64 217523
fbt2 64 217523
fbt 32 1$ 1296
fbt2 32 1$ 407
fbt 64 1$ 0
fbt2 64 1$ 0
For frame_pointer_needed functions, we need to wait until we see the
fp_setter insn in the prologue at which point we disassociate the fp based
VALUEs from sp based VALUEs, but for !frame_pointer_needed functions,
we IMHO don't need to wait anything. For ACCUMULATE_OUTGOING_ARGS it isn't
IMHO worth doing anything, as there is a single sp adjustment and so there
is no risk of many thousands deep VALUE chains, but for
!ACCUMULATE_OUTGOING_ARGS the sp keeps changing constantly.
2020-03-26 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/92264
* var-tracking.c (add_stores): Call cselib_set_value_sp_based even
for sp based values in !frame_pointer_needed
&& !ACCUMULATE_OUTGOING_ARGS functions.
In the testcase for PR94269, widening_mul moves two multiply
instructions from outside the loop to inside
the loop, merging with two add instructions separately. This
increases the cost of the loop. Like FMA detection
in the same pass, simply restrict ops to be defined in the same
basic-block to avoid possibly moving multiply
to a different block with a higher execution frequency.
2020-03-26 Felix Yang <felix.yang@huawei.com>
PR tree-optimization/94269
* tree-ssa-math-opts.c (convert_plusminus_to_widen): Restrict
this
operation to single basic block.
* gcc.dg/pr94269.c: New test.
These tests were supposed to be committed as part of r278904 (aka
b789efeae8) but I didn't 'git add' them.
* testsuite/30_threads/shared_timed_mutex/try_lock_until/1.cc: New
test.
* testsuite/30_threads/shared_timed_mutex/try_lock_until/2.cc: New
test.
For C++20 the wait_until members of mutexes and condition variables are
required to be ill-formed if given a clock that doesn't meet the
requirements for a clock type. To implement that requirement this patch
adds static assertions using the chrono::is_clock trait, and defines
that trait.
To avoid expensive checks for the common cases, the trait (and
associated variable template) are explicitly specialized for the
standard clock types.
This also moves the filesystem::__file_clock type from <filesystem> to
<chrono>, so that chrono::file_clock and chrono::file_time can be
defined in <chrono> as required.
* include/bits/fs_fwd.h (filesystem::__file_clock): Move to ...
* include/std/chrono (filesystem::__file_clock): Here.
(filesystem::__file_clock::from_sys, filesystem::__file_clock::to_sys):
Define public member functions for C++20.
(is_clock, is_clock_v): Define traits for C++20.
* include/std/condition_variable (condition_variable::wait_until): Add
check for valid clock.
* include/std/future (_State_baseV2::wait_until): Likewise.
* include/std/mutex (__timed_mutex_impl::_M_try_lock_until): Likewise.
* include/std/shared_mutex (shared_timed_mutex::try_lock_shared_until):
Likewise.
* include/std/thread (this_thread::sleep_until): Likewise.
* testsuite/30_threads/condition_variable/members/2.cc: Qualify
slow_clock with new namespace.
* testsuite/30_threads/condition_variable/members/clock_neg.cc: New
test.
* testsuite/30_threads/condition_variable_any/members/clock_neg.cc:
New test.
* testsuite/30_threads/future/members/clock_neg.cc: New test.
* testsuite/30_threads/recursive_timed_mutex/try_lock_until/3.cc:
Qualify slow_clock with new namespace.
* testsuite/30_threads/recursive_timed_mutex/try_lock_until/
clock_neg.cc: New test.
* testsuite/30_threads/shared_future/members/clock_neg.cc: New
test.
* testsuite/30_threads/shared_lock/locking/clock_neg.cc: New test.
* testsuite/30_threads/shared_timed_mutex/try_lock_until/clock_neg.cc:
New test.
* testsuite/30_threads/timed_mutex/try_lock_until/3.cc: Qualify
slow_clock with new namespace.
* testsuite/30_threads/timed_mutex/try_lock_until/4.cc: Likewise.
* testsuite/30_threads/timed_mutex/try_lock_until/clock_neg.cc: New
test.
* testsuite/30_threads/unique_lock/locking/clock_neg.cc: New test.
* testsuite/std/time/traits/is_clock.cc: New test.
* testsuite/util/slow_clock.h (slow_clock): Move to __gnu_test
namespace.
The following testcase ICEs, because arm_gen_dicompare_reg creates invalid
RTL which then propagates into DEBUG_INSNs and ICEs while handling them.
The problem is that this function emits
(insn 18 17 19 2 (set (reg:CC_DNE 100 cc)
(compare (ior:SI (ne:SI (subreg:SI (reg:DI 129) 0)
(subreg:SI (reg:DI 114 [ _2 ]) 0))
(ne:SI (subreg:SI (reg:DI 129) 4)
(subreg:SI (reg:DI 114 [ _2 ]) 4)))
(const_int 0 [0]))) "pr94292.c":7:11 325 {*cmp_ior}
(nil))
and the invalid thing is that the COMPARE has VOIDmode. Setting a
non-VOIDmode SET_DEST to VOIDmode SET_SRC is only valid if the SET_SRC is
CONST_INT/CONST_DOUBLE.
The following patch fixes it by giving the COMPARE the same mode as it gives
to the SET_DEST cc register.
2020-03-25 Jakub Jelinek <jakub@redhat.com>
PR target/94292
* config/arm/arm.c (arm_gen_dicompare_reg): Set mode of COMPARE to
mode rather than VOIDmode.
* gcc.dg/pr94292.c: New test.
gcc/testsuite/ChangeLog:
PR middle-end/94004
* gcc.dg/Walloca-larger-than-3.c: New test.
* gcc.dg/Walloca-larger-than-3.h: New test header.
* gcc.dg/Wvla-larger-than-4.c: New test.
gcc/ChangeLog:
PR middle-end/94004
* gimple-ssa-warn-alloca.c (pass_walloca::execute): Issue warnings
even for alloca calls resulting from system macro expansion.
Include inlining context in all warnings.
g:497498c878d48754318e486428e2aa30854020b9 caused lra to cycle
on some SDmode reloads for power6. As explained in more detail
in the PR comments, the problem was a conflict between two target
hooks: rs6000_secondary_memory_needed_mode required SDmode FPR
reloads to use DDmode memory (rightly, since using SDmode memory
wouldn't make progress) but rs6000_can_change_mode_class didn't
allow FPRs to change from SDmode to DDmode. Previously lra
ignored that and changed the mode anyway.
From what Segher says, it sounds like the "from_size < 8 || to_size < 8"
check is mostly there for SF<->64-bit subregs, and that SDmode is stored
in the way that target-independent code expects. This patch therefore
allows SD<->DD changes.
I wondered about checking for SD<->64-bit changes instead, but that
seemed like an unnecessary generalisation for this stage.
2020-03-23 Richard Sandiford <richard.sandiford@arm.com>
gcc/
PR target/94254
* config/rs6000/rs6000.c (rs6000_can_change_mode_class): Allow
FPRs to change between SDmode and DDmode.
This fixes a false-positive warning from -Wduplicate-cond in the presence of an
if-statement with a non-empty init-statement. Precisely determining whether a
non-empty init-statement has side effects seems tricky and error-prone, so this
patch takes the route of unconditionally invalidating the condition chain when
it encounters such an if-statement.
gcc/cp/ChangeLog:
PR c++/94265
* parser.c (cp_parser_selection_statement) <case RID_IF>: Invalidate the
current condition chain when the if-statement has a non-empty
init-statement.
gcc/testsuite/ChangeLog:
PR c++/94265
* g++.dg/warn/Wduplicated-cond1.C: New test.
As this test produces different code depending on whether
__GCC_HAVE_DWARF2_CFI_ASM macro is defined or not, it is inherently
incompatible with -fcompare-debug, as with
-fcompare-debug -fno-asynchronous-unwind-tables -fno-exceptions
the macro is defined only in the -g case and not otherwise.
The purpose of the macro is to tell when the compiler is emitting
.cfi* directives itself and thus it is desirable that user code uses them in
inline asm as well, so I think it is fine the way it is.
As -fexceptions makes the test pass even in that case because it emits
.cfi* directives, the test actually doesn't FAIL even with
make check-gcc RUNTESTFLAGS='--target_board=unix/-fcompare-debug/-fno-asynchronous-unwind-tables/-fno-exceptions dg.exp=cleanup-13.c'
so the intent of this patch is help Martin and others who do run gcc tests
out of the testsuite with random compiler flags to find out that this is a
known issue.
2020-03-25 Jakub Jelinek <jakub@redhat.com>
PR debug/94296
* gcc.dg/cleanup-13.c: Add a comment that the test is not
-fcompare-debug compatible with certain other options.
The following patch ICEs due to my recent change r10-6451-gb7b3378f91c.
Since that patch, for explicit vzeroupper in the sources (when an intrinsic
is used), we start with the *avx_vzeroupper_1 pattern which contains just the
UNSPECV_VZEROUPPER and no sets/clobbers. The vzeroupper pass then adds some
sets to those, but doesn't add clobbers and finally there is an
&& epilogue_completed splitter that splits this into the *avx_vzeroupper
pattern which has the right number of sets/clobbers (16 on 64-bit, 8 on
32-bit) + the UNSPECV_VZEROUPPER first.
The problem with this testcase on !TARGET_64BIT is that the vzeroupper pass
adds 8 sets to the pattern, i.e. the maximum number, but INSN_CODE stays
to be the one of the *avx_vzeroupper_1 pattern. The splitter doesn't do
anything here, because it sees the number of rtxes in the PARALLEL already
the right count, but during final we see that the *avx_vzeroupper_1 pattern
has "#" output template and ICE that we forgot to split it.
The following patch fixes it by forcing re-recognition of the insn after we
make the changes to it in ix86_add_reg_usage_to_vzeroupper. Anything that
will call recog_memoized later on will recog it and find out it is in this
case already *avx_vzeroupper rather than *avx_vzeroupper_1.
2020-03-25 Jakub Jelinek <jakub@redhat.com>
PR target/94308
* config/i386/i386-features.c (ix86_add_reg_usage_to_vzeroupper): Set
INSN_CODE (insn) to -1 when changing the pattern.
* gcc.target/i386/pr94308.c: New test.
PR target/93274
PR ipa/94271
* config/i386/i386-features.c (make_resolver_func): Drop
public flag for resolver.
* config/rs6000/rs6000.c (make_resolver_func): Add comdat
group for resolver and drop public flag if possible.
* multiple_target.c (create_dispatcher_calls): Drop unique_name
and resolution as we want to enable LTO privatization of the default
symbol.
PR target/93274
PR ipa/94271
* gcc.target/i386/pr81213-2.c: New test.
* gcc.target/i386/pr81213.c: Add additional source.
* gcc.dg/lto/pr94271_0.c: New test.
* gcc.dg/lto/pr94271_1.c: New test.
These 3 tests use compiler_options() function,
which is inherently incompatible with -fcompare-debug compilation, as it
emits into a string literal in the assembly the exact f951 command line
options, which differs between the two compilations with -fcompare-debug,
where one has -gtoggle and -fcompare-debug-second options added and
different -fdump-final-insns= option argument.
The following patch adds dg-skip-if directives, so that these tests are
ignored during
make check-gfortran RUNTESTFLAGS='--target_board=unix/-fcompare-debug'
2020-03-25 Jakub Jelinek <jakub@redhat.com>
PR debug/94280
* gfortran.dg/iso_c_binding_compiler_1.f90: Add dg-skip-if for
-fcompare-debug.
* gfortran.dg/iso_c_binding_compiler_3.f90: Likewise.
* gfortran.dg/unlimited_polymorphic_31.f03: Likewise.
Using undeclared symbol k in an expression in the following
array constructor results in an ICE:
print *, [real(x(k))]
If the call to the intrinsic is not in a constructor a no IMPLICIT
type error is reported and the ICE does not occur.
Matching on an expression instead of an initialisation express an
and not converting a MATCH_ERROR return value into MATCH_NO results
in the no IMPLICIT error and no ICE.
Note: Steven G. Kargl <kargl@gcc.gnu.org> is the author of the
changes except for the test cases.
gcc/fortran/ChangeLog:
PR fortran/93484
* match.c (gfc_match_type_spec): Replace gfc_match_init_expr with
gfc_match_expr. Return m if m is MATCH_NO or MATCH_ERROR.
gcc/testsuite
PR fortran/93484
* gfortran.dg/pr93484_1.f90: New test.
* gfortran.dg/pr93484_2.f90: New test.
The following testcase is miscompiled, because output_constructor doesn't
output the initializer correctly. The FE creates {[1...2] = 9} in this
case, and we emit .long 9; long 9; .zero 8 instead of the expected
.zero 8; .long 9; .long 9. If the CONSTRUCTOR is {[1] = 9, [2] = 9},
output_constructor_regular_field has code to notice that the current
location (local->total_bytes) is smaller than the location we want to write
to (1*sizeof(elt)) and will call assemble_zeros to skip those. But
RANGE_EXPRs are handled by a different function which didn't do this,
so for RANGE_EXPRs we emitted them properly only if local->total_bytes
was always equal to the location where the RANGE_EXPR needs to start.
2020-03-25 Jakub Jelinek <jakub@redhat.com>
PR middle-end/94303
* varasm.c (output_constructor_array_range): If local->index
RANGE_EXPR doesn't start at the current location in the constructor,
skip needed number of bytes using assemble_zeros or assert we don't
go backwards.
PR middle-end/94303
* g++.dg/torture/pr94303.C: New test.
As mentioned in the PR, we don't guarantee DECL_UID to be the same between
corresponding decls in -g and -g0 builds, -g can create more decls and all
that is guaranteed is that the DECL_UIDs of the corresponding decls compare
the same.
The following testcase gets a -fcompare-debug failure because these
functions use DECL_UID as the number in ASM_FORMAT_PRIVATE_NAME.
The patch fixes it by using just a sequential number there instead.
I don't think this can be called during PCH writing, this only happens for
non-public decls and the C/C++ FEs shouldn't mangling those at that point
(furthermore C++ FE uses a different set_decl_assembler_name hook and this
one is something only the gimplifier calls on C.NNNN temporaries.
2020-03-25 Jakub Jelinek <jakub@redhat.com>
PR c++/94223
* langhooks.c (lhd_set_decl_assembler_name): Use a static ulong
counter instead of DECL_UID.
* lto-lang.c (lto_set_decl_assembler_name): Use a static ulong
counter instead of DECL_UID.
* g++.dg/opt/pr94223.C: New test.
The following testcase is miscompiled, because there is a buffer overflow
in push_partial_def in the little-endian case when working 64-byte vectors.
The code computes the number of bytes we need in the BUFFER: NEEDED_LEN,
which is rounded up number of bits we need. Then the code
native_encode_expr each (partially overlapping) pd into THIS_BUFFER.
If pd.offset < 0, i.e. the pd.rhs store starts at some bits before the
window we are interested in, we pass -pd.offset to native_encode_expr and
shrink the size already earlier:
HOST_WIDE_INT size = pd.size;
if (pd.offset < 0)
size -= ROUND_DOWN (-pd.offset, BITS_PER_UNIT);
On this testcase, the problem is with a store with pd.offset > 0,
in particular pd.offset 256, pd.size 512, i.e. a 64-byte store which doesn't
fit into entirely into BUFFER.
We have just:
size = MIN (size, (HOST_WIDE_INT) needed_len * BITS_PER_UNIT);
in this case for little-endian, which isn't sufficient, because needed_len
is 64, the entire BUFFER (except of the last extra byte used for shifting).
native_encode_expr fills the whole THIS_BUFFER (again, except the last extra
byte), and the code then performs memcpy (BUFFER + 32, THIS_BUFFER, 64);
which overflows BUFFER and as THIS_BUFFER is usually laid out after it,
overflows it into THIS_BUFFER.
The following patch fixes it by for pd.offset > 0 making sure size is
reduced too. For big-endian the code does things differently and already
handles this right.
2020-03-25 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/94300
* tree-ssa-sccvn.c (vn_walk_cb_data::push_partial_def): If pd.offset
is positive, make sure that off + size isn't larger than needed_len.
* gcc.target/i386/avx512f-pr94300.c: New test.
Now that convert_like creates an IMPLICIT_CONV_EXPR when it converts
something that involves a class in a template, we must be prepared to
handle it. In this test, we have a class S and we're converting it
to long int& using a user-defined conversion since we're performing
-- on it. So cp_build_unary_op/POSTDECREMENT_EXPR calls
build_expr_type_conversion which gets the IMPLICIT_CONV_EXPR. Before
the convert_like change it got *S::operator long int &(&b) whose type
is long int but now it gets IMPLICIT_CONV_EXPR<long int&>(b) whose type
is a reference type. But the !MAYBE_CLASS_TYPE_P switch doesn't handle
reference types and so we complain.
Fixed by calling convert_from_reference on the result of convert_like.
PR c++/94190 - wrong no post-decrement operator error in template.
* call.c (convert_like_real): Use convert_from_reference on the result.
* g++.dg/conversion/op7.C: New test.
It would have been trivial to make the error for non-bool constraint in
satisfy_atom unconditional, but that didn't give context for the error or
printing with the dependent form and template arguments. So I changed a
couple of places so that, when a hard error is encountered during quiet
substitution/satisfaction, we go through again noisily; this builds up the
necessary context.
The similar change to tsubst_nested_requirement does not build up the
necessary context; rather than try to fix that now I changed
get_constraint_error_location to give up and use input_location if there's
no CONSTR_CONTEXT. In the case of concepts-pr67697.C, we still have a good
source location because the NESTED_REQ has a correct EXPR_LOCATION, but this
patch doesn't improve context printing for this case as it does for the
above.
gcc/cp/ChangeLog
2020-03-24 Jason Merrill <jason@redhat.com>
PR c++/94186
* constraint.cc (constraint_satisfaction_value): Repeat noisily on
error.
(tsubst_nested_requirement): Likewise.
(get_constraint_error_location): Allow missing context.
(diagnose_atomic_constraint): Diagnose non-bool constraint here.
(satisfy_atom): Not here. Only diagnose non-constant when noisy.
While looking at PR94186 I also noticed this regression; if a non-type
template parameter uses a type parameter in its type, we need to map both
template parameters.
gcc/cp/ChangeLog
2020-03-24 Jason Merrill <jason@redhat.com>
* pt.c (any_template_parm_r): Look into the type of a non-type
template parm.
In the testcase for PR94186, we have a SCOPE_REF with no location even
though at one point it was in a cp_expr which had a location. So let's make
the cp_expr constructor that takes a location apply it to the expression
when possible.
gcc/cp/ChangeLog
2020-03-24 Jason Merrill <jason@redhat.com>
* cp-tree.h (cp_expr): When constructing from an expr and a
location, call protected_set_expr_location.
Parts of the cmp-2.c test rely on double-precision support, making the
test fail on targets where the FPU supports single-precision only.
Split the test into single-precision (cmp-2.c) and double-precision
tests (cmp-3.c).
2020-03-24 Christophe Lyon <christophe.lyon@linaro.org>
gcc/testsuite/
* gcc.target/arm/cmp-2.c: Move double-precision tests to...
* gcc.target/arm/cmp-3.c: ...here (new file)
Some tests require double-precision support, but the existing
arm_fp_ok effective-target only checks if hardware floating-point is
available, not what level. So this patch adds a new arm_fp_dp_ok
effective-target to check that double-precision is supported.
2020-03-24 Christophe Lyon <christophe.lyon@linaro.org>
gcc/
* doc/sourcebuild.texi (ARM-specific attributes): Add
arm_fp_dp_ok.
(Features for dg-add-options): Add arm_fp_dp.
gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_arm_fp_dp_ok_nocache): New.
(check_effective_target_arm_fp_dp_ok): New.
(add_options_for_arm_fp_dp): New.
The following testcase ICEs, because these expanders will happily create
a SImode 0x80000000 CONST_INT, which is not valid RTL, as CONST_INTs need to
be sign extended from the mode precision to full HWI.
2020-03-24 Jakub Jelinek <jakub@redhat.com>
PR target/94286
* config/arm/arm.md (subvdi4, usubvsi4, usubvdi4): Use gen_int_mode
instead of GEN_INT.
* gcc.dg/pr94286.c: New test.
The following testcase FAILs with -fcompare-debug. The problem is that
create_iv behaves differently when inserting after into an empty bb (in that
case sets location to goto_locus), or when inserting before gsi_end_p (i.e.
at the end of bb; in that case it will not set location, otherwise it will
set it to the location of next stmt).
This isn't -fcompare-debug friendly, because if inserting after and the
bb contains only debug stmts, then the location will not be set with -g
and will be with -g0, or when inserting before, the location might either
be set from the following debug stmt rather than some non-debug stmt after
that, or might not be set with -g0 if it is to be inserted at the end of bb,
while with -g would be set to location of debug stmt.
2020-03-24 Jakub Jelinek <jakub@redhat.com>
PR debug/94285
* tree-ssa-loop-manip.c (create_iv): If after, set stmt location to
e->goto_locus even if gsi_bb (*incr_pos) contains only debug stmts.
If not after and at *incr_pos is a debug stmt, set stmt location to
location of next non-debug stmt after it if any.
* gfortran.dg/pr94285.f90: New test.
The following testcase shows -fcompare-debug bugs in ifcvt_local_dce,
where the decisions what statements are needed is based also on debug stmt
operands, which is wrong.
So, this patch makes sure to never add debug stmt to the worklist, or never
add an assign to worklist just because it is used in a debug stmt in another
bb.
2020-03-24 Jakub Jelinek <jakub@redhat.com>
PR debug/94283
* tree-if-conv.c (ifcvt_local_dce): For gimple debug stmts, just set
GF_PLF_2, but don't add them to worklist. Don't add an assigment to
worklist or set GF_PLF_2 just because it is used in a debug stmt in
another bb. Formatting improvements.
* gcc.target/i386/pr94283.c: New test.
The following testcase FAILs with -fcompare-debug, but not because -g vs.
-g0 would make a difference, but because the second compilation is done with
-w in order not to emit warnings twice and -w seems to affect the *.gkd dump
content.
This is because TREE_NO_WARNING flag, or warn_unused_function does affect
not just whether a warning/pedwarn is printed, but also whether we set
TREE_PUBLIC on such decls.
The following patch makes sure we set it regardless of anything warning
related (TREE_NO_WARNING or warn_unused_function).
2020-03-24 Jakub Jelinek <jakub@redhat.com>
PR debug/94277
* cgraphunit.c (check_global_declaration): For DECL_EXTERNAL and
non-TREE_PUBLIC non-DECL_ARTIFICIAL FUNCTION_DECLs, set TREE_PUBLIC
regardless of whether TREE_NO_WARNING is set on it or whether
warn_unused_function is true or not.
* gcc.dg/pr94277.c: New test.
