Martin Sebor [Tue, 21 Apr 2020 15:02:06 +0000 (11:02 -0400)]
c++: reject scalar array initialization with nullptr [PR94510]
The change committed to GCC 9 to allow string literals as template arguments
caused the compiler to prune away, and thus miss diagnosing, conversion from
nullptr to int in an array initializer. After looking at various approaches
to improving the pruning, we realized that the only place the pruning is
necessary is in the mangler.
gcc/cp/ChangeLog
2020-04-21 Martin Sebor <msebor@redhat.com>
Jason Merrill <jason@redhat.com>
PR c++/94510
* decl.c (reshape_init_array_1): Avoid stripping redundant trailing
zero initializers...
* mangle.c (write_expression): ...and handle them here even for
pointers to members by calling zero_init_expr_p.
* cp-tree.h (zero_init_expr_p): Declare.
* tree.c (zero_init_expr_p): Define.
(type_initializer_zero_p): Remove.
* pt.c (tparm_obj_values): New hash_map.
(get_template_parm_object): Store to it.
(tparm_object_argument): New.
gcc/testsuite/ChangeLog
2020-04-21 Martin Sebor <msebor@redhat.com>
PR c++/94510
* g++.dg/init/array58.C: New test.
* g++.dg/init/array59.C: New test.
* g++.dg/cpp2a/nontype-class34.C: New test.
* g++.dg/cpp2a/nontype-class35.C: New test.
Andre Vieira [Wed, 22 Apr 2020 14:16:20 +0000 (15:16 +0100)]
aarch64: Fix bootstrap with old binutils [PR93053]
As reported in the PR, GCC 10 (and also 9.3.1 but not 9.3.0) fails to build
when using older binutils which lack LSE support, because those instructions
are used in libgcc.
Thanks to Kyrylo's hint, the following patches (hopefully) allow it to build
even with older binutils by using .inst directive if LSE support isn't
available in the assembler.
2020-04-22 Andre Vieira <andre.simoesdiasvieira@arm.com>
Backport from mainline.
2020-04-15 Jakub Jelinek <jakub@redhat.com>
PR target/93053
* configure.ac (LIBGCC_CHECK_AS_LSE): Add HAVE_AS_LSE checking.
* config/aarch64/lse.S: Include auto-target.h, if HAVE_AS_LSE
is not defined, use just .arch armv8-a.
(B, M, N, OPN): Define.
(COMMENT): New .macro.
(CAS, CASP, SWP, LDOP): Use .inst directive if HAVE_AS_LSE is not
defined. Otherwise, move the operands right after the glue? and
comment out operands where the macros are used.
* configure: Regenerated.
* config.in: Regenerated.
Jonathan Wakely [Wed, 22 Apr 2020 07:09:11 +0000 (08:09 +0100)]
libstdc++: Improve C++14 status docs
This adds a full table of contents for the C++14 standard, with status
for each part.
The list of C++14 proposals is removed, as it adds little value now that
everything is supported.
* doc/Makefile.am (xml_sources_manual): Add missing XML files.
* doc/Makefile.in: Regenerate.
* doc/xml/manual/status_cxx1998.xml: Refer to "this section" instead
of "this page".
* doc/xml/manual/status_cxx2011.xml: Formatting and other corrections
to the C++11 status table.
* doc/xml/manual/status_cxx2014.xml: Replace list of C++14 feature
proposals with table matching contents of the C++14 standard.
* doc/html/*: Regenerate.
Martin Jambor [Tue, 21 Apr 2020 12:20:37 +0000 (14:20 +0200)]
sra-9: Fix sra_modify_expr handling of partial writes (PR 94482)
This is a fairly straightforward backport of the mainline fix for PR 94482.
When sra_modify_expr is invoked on an expression that modifies only
part of the underlying replacement, such as a BIT_FIELD_REF on a LHS
of an assignment and the SRA replacement's type is not compatible with
what is being replaced (0th operand of the B_F_R in the above
example), it does not work properly, basically throwing away the part
of the expr that should have stayed intact.
This is fixed in two ways. For BIT_FIELD_REFs, which operate on the
binary image of the replacement (and so in a way serve as a
VIEW_CONVERT_EXPR) we just do not bother with converting. For
REALPART_EXPRs and IMAGPART_EXPRs, if the replacement is not a
register, we insert a VIEW_CONVERT_EXPR under
the complex partial access expression, which is always OK, for loads
from registers we take the extra step of converting it to a temporary.
This revealed a bug in fwprop which is fixed with the hunk from Richi.
This is the only difference from the mainline patch which has two
hunks, but the code handling BIT_FIELD_REF is not present in gcc-9.
Oh, and the testcase options were changed to what Jakub put there on
the mainline to suppress all vector ABI warnings.
Bootstrapped and tested on x86_64-linux.
2020-04-21 Martin Jambor <mjambor@suse.cz>
Backport from master
2020-04-09 Martin Jambor <mjambor@suse.cz>
Richard Biener <rguenther@suse.de>
PR tree-optimization/94482
* tree-sra.c (create_access_replacement): Dump new replacement with
TDF_UID.
(sra_modify_expr): Fix handling of cases when the original EXPR writes
to only part of the replacement.
* tree-ssa-forwprop.c (pass_forwprop::execute): Properly verify
the first operand of combinations into REAL/IMAGPART_EXPR and
BIT_FIELD_REF.
testsuite/
* gcc.dg/torture/pr94482.c: New test.
* gcc.dg/tree-ssa/pr94482-2.c: Likewise.
Marek Polacek [Mon, 20 Apr 2020 19:43:49 +0000 (15:43 -0400)]
c++: Fix bogus -Wparentheses warning with fold-expression [PR94505]
We issue bogus -Wparentheses warnings (3 of them!) for this fold expression:
((B && true) || ...)
Firstly, issuing a warning for a compiler-generated expression is wrong
and secondly, B && true must be wrapped in ( ) otherwise you'll get
error: binary expression in operand of fold-expression.
PR c++/94505 - bogus -Wparentheses warning with fold-expression.
* pt.c (fold_expression): Add warning_sentinel for -Wparentheses
before calling build_x_binary_op.
Tamar Christina [Mon, 20 Apr 2020 10:43:43 +0000 (11:43 +0100)]
AArch64: Fix options canonicanization for assembler
It is currently impossible to use fp16 on any architecture higher than Armv8.3-a
due to a bug in options canonization. This bug results in the fp16 flag not
being emitted in the assembly when it should have been.
This is caused by a complicated architectural requirement at Armv8.4-a. On
Armv8.2-a and Armv8.3-a fp16fml is an optional extension and turning it on turns
on both fp and fp16. However starting with Armv8.4-a fp16fml is mandatory if
fp16 is available, otherwise it's optional.
In short this means that to enable fp16fml the smallest option that needs to
passed to the assembler is Armv8.4-a+fp16.
The fix in this patch takes into account that an option may be on by default in
an architecture, but that not all the bits required to use it are on by default
in an architecture. In such cases the difference between the two are still
emitted to the assembler.
PR target/94396
* gcc.target/aarch64/options_set_11.c: New test.
* gcc.target/aarch64/options_set_12.c: New test.
* gcc.target/aarch64/options_set_13.c: New test.
* gcc.target/aarch64/options_set_14.c: New test.
* gcc.target/aarch64/options_set_15.c: New test.
* gcc.target/aarch64/options_set_16.c: New test.
* gcc.target/aarch64/options_set_17.c: New test.
* gcc.target/aarch64/options_set_18.c: New test.
* gcc.target/aarch64/options_set_19.c: New test.
* gcc.target/aarch64/options_set_20.c: New test.
* gcc.target/aarch64/options_set_21.c: New test.
* gcc.target/aarch64/options_set_22.c: New test.
* gcc.target/aarch64/options_set_23.c: New test.
* gcc.target/aarch64/options_set_24.c: New test.
* gcc.target/aarch64/options_set_25.c: New test.
* gcc.target/aarch64/options_set_26.c: New test.
Backport from mainline
2020-04-17 Martin Liska <mliska@suse.cz>
Jonathan Yong <10walls@gmail.com>
PR gcov-profile/94570
* ltmain.sh: Do not define HAVE_DOS_BASED_FILE_SYSTEM
for CYGWIN.
Backport from mainline
2020-04-17 Martin Liska <mliska@suse.cz>
Jonathan Yong <10walls@gmail.com>
PR gcov-profile/94570
* coverage.c (coverage_init): Use separator properly.
Backport from mainline
2020-04-17 Martin Liska <mliska@suse.cz>
Jonathan Yong <10walls@gmail.com>
PR gcov-profile/94570
* filenames.h (defined): Do not define HAVE_DOS_BASED_FILE_SYSTEM
for CYGWIN.
i386: Remove unneeded assignments when triggering SSE exceptions
According to "Intel 64 and IA32 Arch SDM, Vol. 3":
"Because SIMD floating-point exceptions are precise and occur immediately,
the situation does not arise where an x87 FPU instruction, a WAIT/FWAIT
instruction, or another SSE/SSE2/SSE3 instruction will catch a pending
unmasked SIMD floating-point exception."
Remove unneeded assignments to volatile memory.
libgcc/ChangeLog:
* config/i386/sfp-exceptions.c (__sfp_handle_exceptions) [__SSE_MATH__]:
Remove unneeded assignments to volatile memory.
libatomic/ChangeLog:
* config/x86/fenv.c (__atomic_feraiseexcept) [__SSE_MATH__]:
Remove unneeded assignments to volatile memory.
libgfortran/ChangeLog:
* config/fpu-387.h (local_feraiseexcept) [__SSE_MATH__]:
Remove unneeded assignments to volatile memory.
H.J. Lu [Fri, 17 Apr 2020 22:23:27 +0000 (15:23 -0700)]
x86: Insert ENDBR if function will be called indirectly
Since constant_call_address_operand has
;; Test for a pc-relative call operand
(define_predicate "constant_call_address_operand"
(match_code "symbol_ref")
{
if (ix86_cmodel == CM_LARGE || ix86_cmodel == CM_LARGE_PIC
|| flag_force_indirect_call)
return false;
if (TARGET_DLLIMPORT_DECL_ATTRIBUTES && SYMBOL_REF_DLLIMPORT_P (op))
return false;
return true;
})
even if cgraph_node::get (cfun->decl)->only_called_directly_p () returns
false, the fuction may still be called indirectly. Copy the logic from
constant_call_address_operand to rest_of_insert_endbranch to insert ENDBR
at function entry if function will be called indirectly.
NB: gcc.target/i386/pr94417-2.c is updated to expect 4 ENDBRs, instead
of 2, since only GCC 10 has the fix for PR target/89355 not to insert
ENDBR after NOTE_INSN_DELETED_LABEL.
gcc/
Backport from master
PR target/94417
* config/i386/i386.c (rest_of_insert_endbranch): Insert ENDBR at
function entry if function will be called indirectly.
gcc/testsuite/
Backport from master
PR target/94417
* gcc.target/i386/pr94417-1.c: New test.
* gcc.target/i386/pr94417-2.c: Likewise.
* gcc.target/i386/pr94417-3.c: Likewise.
Kewen Lin [Fri, 3 Apr 2020 07:10:08 +0000 (02:10 -0500)]
Fix PR94443 with gsi_insert_seq_before [PR94443]
This patch is to fix the stupid mistake by using
gsi_insert_seq_before instead of gsi_insert_before.
BTW, the regression testing on one x86_64 machine from CFarm is
unable to reveal it (I guess due to native arch sandybridge?), so I
specified additional option -march=znver2 and verified the coverage.
Bootstrapped/regtested on powerpc64le-linux-gnu (P9) and
x86_64-pc-linux-gnu, also verified the fail cases in related PRs.
Backport from mainline.
2020-04-03 Kewen Lin <linkw@gcc.gnu.org>
gcc/
PR tree-optimization/94443
* tree-vect-loop.c (vectorizable_live_operation): Use
gsi_insert_seq_before to replace gsi_insert_before.
gcc/testsuite/
PR tree-optimization/94443
* gcc.dg/vect/pr94443.c: New test.
Kewen Lin [Wed, 1 Apr 2020 03:48:46 +0000 (22:48 -0500)]
Fix PR94043 by making vect_live_op generate lc-phi
As PR94043 shows, my commit r10-4524 exposed one issue in
vectorizable_live_operation, which inserts one extra BB
before the single exit, leading unexpected operand expansion
and unexpected loop depth assertion. As Richi suggested,
this patch is to teach vectorizable_live_operation to
generate loop closed phi for vec_lhs, it looks like:
loop;
# lhs' = PHI <lhs>
=>
loop;
# vec_lhs' = PHI <vec_lhs>
new_tree = BIT_FIELD_REF <vec_lhs', ...>;
lhs' = new_tree;
I noticed that there are some SLP cases that have same lhs
and vec_lhs but different offsets, which can make us have
more PHIs for the same vec_lhs there. But I think it would
be fine since only one of them is actually live, the others
should be eliminated by the following dce. So the patch
doesn't check whether there is one phi for vec_lhs, just
create one directly instead.
Bootstrapped/regtested on powerpc64le-linux-gnu (LE) P8.
Backport from mainline.
2020-04-01 Kewen Lin <linkw@gcc.gnu.org>
gcc/ChangeLog
PR tree-optimization/94043
* tree-vect-loop.c (vectorizable_live_operation): Generate loop-closed
phi for vec_lhs and use it for lane extraction.
gcc/testsuite/ChangeLog
PR tree-optimization/94043
* gfortran.dg/graphite/vect-pr94043.f90: New test.
Michael Meissner [Thu, 16 Apr 2020 16:49:22 +0000 (12:49 -0400)]
Fix target/94557 PowerPC regression on GCC 9 (variable vec_extract)
2020-04-16 Michael Meissner <meissner@linux.ibm.com>
PR target/94557
* config/rs6000/rs6000.c (rs6000_adjust_vec_address): Fix
regression caused by PR target/93932 backport. Mask variable
vector extract index so it does not go beyond the vector when
extracting a vector element from memory.
Richard Biener [Tue, 7 Apr 2020 14:29:37 +0000 (16:29 +0200)]
middle-end/94479 - fix gimplification of address
When gimplifying an address operand we may expose an indirect
ref via DECL_VALUE_EXPR for example. This is dealt with in the
code already but it fails to consider that INDIRECT_REFs get
gimplified to MEM_REFs.
Fixed which makes the ICE observed on x86_64-netbsd go away.
2020-04-07 Richard Biener <rguenther@suse.de>
PR middle-end/94479
* gimplify.c (gimplify_addr_expr): Also consider generated
MEM_REFs.
Max Filippov [Mon, 13 Apr 2020 20:26:04 +0000 (13:26 -0700)]
xtensa: backport fix for PR target/94584
Patterns zero_extendhisi2, zero_extendqisi2 and extendhisi2_internal can
load value from memory, but they don't treat volatile memory correctly.
Add %v1 before load instructions to emit 'memw' instruction when
-mserialize-volatile is in effect.
2020-04-15 Max Filippov <jcmvbkbc@gmail.com>
gcc/
* config/xtensa/xtensa.md (zero_extendhisi2, zero_extendqisi2)
(extendhisi2_internal): Add %v1 before the load instructions.
gcc/testsuite/
* gcc.target/xtensa/pr94584.c: New test.
Max Filippov [Thu, 26 Sep 2019 20:51:27 +0000 (20:51 +0000)]
xtensa: backport fix for PR target/91880
Xtensa hwloop_optimize segfaults when zero overhead loop is about to be
inserted as the first instruction of the function.
Insert zero overhead loop instruction into new basic block before the
loop when basic block that precedes the loop is empty.
2020-04-15 Max Filippov <jcmvbkbc@gmail.com>
gcc/
* config/xtensa/xtensa.c (hwloop_optimize): Insert zero overhead
loop instruction into new basic block before the loop when basic
block that precedes the loop is empty.
gcc/testsuite/
* gcc.target/xtensa/pr91880.c: New test case.
* gcc.target/xtensa/xtensa.exp: New test suite.
Thomas Schwinge [Mon, 13 Apr 2020 06:56:03 +0000 (08:56 +0200)]
Rename 'libgomp.oacc-c-c++-common/static-dynamic-lifetimes-*' to 'libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-*' [PR92843]
Fix-up for commit be9862dd96945772ae0692bc95b37ec6dbcabda0 "Test cases for
mixed structured/dynamic data lifetimes with OpenACC [PR92843]": it's
"structured", not "static" data lifetimes/reference counters.
V4SI, V8HI and V16QI modes of redux_<code>_scal_<mode> expander
expand with SSE2 instructions (PSRLDQ and PCMPGTx) so use
TARGET_SSE2 as relevant mode iterator codition.
PR target/94494
* config/i386/sse.md (REDUC_SSE_SMINMAX_MODE): Use TARGET_SSE2
condition for V4SI, V8HI and V16QI modes.
testsuite/ChangeLog:
PR target/94494
* gcc.target/i386/pr94494.c: New test.
V4SI, V8HI and V16QI modes of redux_<code>_scal_<mode> expander
expand with SSE2 instructions (PSRLDQ and PCMPGTx) so use
TARGET_SSE2 as relevant mode iterator codition.
PR target/94494
* config/i386/sse.md (REDUC_SSE_SMINMAX_MODE): Use TARGET_SSE2
condition for V4SI, V8HI and V16QI modes.
testsuite/ChangeLog:
PR target/94494
* gcc.target/i386/pr94494.c: New test.
Backport PR target/93932 (variable vec_extract) to GCC 9
2020-04-09 Michael Meissner <meissner@linux.ibm.com>
Back port from trunk
2020-02-26 Michael Meissner <meissner@linux.ibm.com>
PR target/93932
* config/rs6000/vsx.md (vsx_extract_<mode>_var, VSX_D iterator):
Split the insn into two parts. This insn only does variable
extract from a register.
(vsx_extract_<mode>_var_load, VSX_D iterator): New insn, do
variable extract from memory.
(vsx_extract_v4sf_var): Split the insn into two parts. This insn
only does variable extract from a register.
(vsx_extract_v4sf_var_load): New insn, do variable extract from
memory.
(vsx_extract_<mode>_var, VSX_EXTRACT_I iterator): Split the insn
into two parts. This insn only does variable extract from a
register.
(vsx_extract_<mode>_var_load, VSX_EXTRACT_I iterator): New insn,
do variable extract from memory.
The following testcases are miscompiled, because expand_vec_perm_pshufb
incorrectly thinks it can use vpshufb instruction for the permutations
when it can't.
The
if (vmode == V32QImode)
{
/* vpshufb only works intra lanes, it is not
possible to shuffle bytes in between the lanes. */
for (i = 0; i < nelt; ++i)
if ((d->perm[i] ^ i) & (nelt / 2))
return false;
}
intra-lane check which is correct has been copied and adjusted for 64-byte
modes into:
if (vmode == V64QImode)
{
/* vpshufb only works intra lanes, it is not
possible to shuffle bytes in between the lanes. */
for (i = 0; i < nelt; ++i)
if ((d->perm[i] ^ i) & (nelt / 4))
return false;
}
which is not correct, because 64-byte modes have 4 lanes rather than just
two and the above is only testing that the permutation grabs even lane elts
from even lanes and odd lane elts from odd lanes, but not that they are
from the same 256-bit half.
The following patch fixes it by using 3 * nelt / 4 instead of nelt / 4,
so we actually check the most significant 2 bits rather than just one.
2020-04-07 Jakub Jelinek <jakub@redhat.com>
PR target/94509
* config/i386/i386-expand.c (expand_vec_perm_pshufb): Fix the check
for inter-lane permutation for 64-byte modes.
* gcc.target/i386/avx512bw-pr94509-1.c: New test.
* gcc.target/i386/avx512bw-pr94509-2.c: New test.
We need to set OMP_PARALLEL_COMBINED only if the parsing of omp_master
succeeded, because otherwise there is no nested master construct in the
parallel.
2020-04-07 Jakub Jelinek <jakub@redhat.com>
PR c++/94512
* c-parser.c (c_parser_omp_parallel): Set OMP_PARALLEL_COMBINED
if c_parser_omp_master succeeded.
* parser.c (cp_parser_omp_parallel): Set OMP_PARALLEL_COMBINED
if cp_parser_omp_master succeeded.
The following testcase ICEs on aarch64 apparently since the introduction of
the aarch64 port. The reason is that the {ashl,ashr,lshr}<mode>3 expanders
completely unnecessarily FAIL; if operands[2] is something other than
a CONST_INT or REG or MEM and the middle-end code can't cope with the
pattern giving up in these cases. All the expanders use general_operand
predicate for the shift amount operand, but then have just a special case
for CONST_INT (if in-bound, emit an immediate shift, otherwise force into
REG), or MEM (force into REG), or REG (that is the case it handles).
In the testcase, operands[2] is a lowpart SUBREG of a REG, which is valid
general_operand.
I don't see any reason what is magic about MEMs that it should be forced
into REG and others like SUBREGs that it shouldn't, there isn't even a
reason to check for !REG_P because force_reg will do nothing if the operand
is already a REG, and otherwise can handle general_operand just fine.
2020-04-07 Jakub Jelinek <jakub@redhat.com>
PR target/94488
* config/aarch64/aarch64-simd.md (ashl<mode>3, lshr<mode>3,
ashr<mode>3): Force operands[2] into reg whenever it is not CONST_INT.
Assume it is a REG after that instead of testing it and doing FAIL
otherwise. Formatting fix.
Jakub Jelinek [Tue, 7 Apr 2020 19:01:40 +0000 (21:01 +0200)]
debug: Improve debug info of c++14 deduced return type [PR94459]
On the following testcase, in gdb ptype S<long>::m1 prints long as return
type, but all the other methods show void instead.
PR53756 added code to add_type_attribute if the return type is
auto/decltype(auto), but we actually should look through references,
pointers and qualifiers.
Haven't included there DW_TAG_atomic_type, because I think at least ATM
one can't use that in C++. Not sure about DW_TAG_array_type or what else
could be deduced.
> http://eel.is/c++draft/dcl.spec.auto#3 says it has to appear as a
> decl-specifier.
>
> http://eel.is/c++draft/temp.deduct.type#8 lists the forms where a template
> argument can be deduced.
>
> Looks like you are missing arrays, pointers to members, and function return
> types.
2020-04-04 Hannes Domani <ssbssa@yahoo.de>
Jakub Jelinek <jakub@redhat.com>
PR debug/94459
* dwarf2out.c (gen_subprogram_die): Look through references, pointers,
arrays, pointer-to-members, function types and qualifiers when
checking if in-class DIE had an 'auto' or 'decltype(auto)' return type
to emit type again on definition.
Jakub Jelinek [Fri, 3 Apr 2020 22:35:41 +0000 (00:35 +0200)]
openmp: Fix ICE on #pragma omp parallel master in template [PR94477]
The following testcase ICEs, because for parallel combined with some
other construct we initialize the omp_parallel_combined_clauses pointer
and expect the construct combined with it to clear it after it no longer
needs it, but OMP_MASTER didn't do that.
The following testcase is miscompiled, because the AVX2 patterns don't
describe correctly what the insn does. E.g. vphaddd with %ymm* operands
(the second pattern) instruction as per:
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm256_hadd_epi32&expand=2941
does { a0+a1, a2+a3, b0+b1, b2+b3, a4+a5, a6+a7, b4+b5, b6+b7 }
but our RTL pattern did
{ a0+a1, a2+a3, a4+a5, a6+a7, b0+b1, b2+b3, b4+b5, b6+b7 }
where the first and last 64 bits are the same and two middle 64 bits
swapped.
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm256_hadd_epi16&expand=2939
similarly, insn does:
{ a0+a1, a2+a3, a4+a5, a6+a7, b0+b1, b2+b3, b4+b5, b6+b7,
a8+a9, a10+a11, a12+a13, a14+a15, b8+b9, b10+b11, b12+b13, b14+b15 }
but RTL pattern did
{ a0+a1, a2+a3, a4+a5, a6+a7, a8+a9, a10+a11, a12+a13, a14+a15,
b0+b1, b2+b3, b4+b5, b6+b7, b8+b9, b10+b11, b12+b13, b14+b15 }
again, first and last 64 bits are the same and the two middle 64 bits
swapped.
2020-04-03 Jakub Jelinek <jakub@redhat.com>
PR target/94460
* config/i386/sse.md (avx2_ph<plusminus_mnemonic>wv16hi3,
avx2_ph<plusminus_mnemonic>dv8si3): Fix up RTL pattern to do
second half of first lane from first lane of second operand and
first half of second lane from second lane of first operand.
Jakub Jelinek [Tue, 7 Apr 2020 19:01:06 +0000 (21:01 +0200)]
objsz: Don't call replace_uses_by on SSA_NAME_OCCURS_IN_ABNORMAL_PHI [PR94423]
The following testcase ICEs because the objsz pass calls replace_uses_by
on SSA_NAME_OCCURS_IN_ABNORMAL_PHI SSA_NAME. The following patch instead
of that calls replace_call_with_value, which will turn it into
xyz_123(ab) = 234;
Jakub Jelinek [Mon, 30 Mar 2020 20:55:36 +0000 (22:55 +0200)]
c++: Fix handling of internal fn calls in statement expressions [PR94385]
The following testcase ICEs, because the FE when processing the statement
expression changes the .VEC_CONVERT internal fn CALL_EXPR into .PHI call.
That is because the internal fn call is recorded in the base.u.ifn
field, which overlaps base.u.bits.lang_flag_1 which is used for
STMT_IS_FULL_EXPR_P, so this essentially does ifn |= 2 on little-endian.
STMT_IS_FULL_EXPR_P bit is used in:
cp-gimplify.c- if (STATEMENT_CODE_P (code))
cp-gimplify.c- {
cp-gimplify.c- saved_stmts_are_full_exprs_p = stmts_are_full_exprs_p ();
cp-gimplify.c- current_stmt_tree ()->stmts_are_full_exprs_p
cp-gimplify.c: = STMT_IS_FULL_EXPR_P (*expr_p);
cp-gimplify.c- }
and
pt.c- if (STATEMENT_CODE_P (TREE_CODE (t)))
pt.c: current_stmt_tree ()->stmts_are_full_exprs_p = STMT_IS_FULL_EXPR_P (t);
so besides being wrong on some other codes, it actually isn't beneficial at
all to set it on anything else, so the following patch restricts it to
trees with STATEMENT_CODE_P TREE_CODE.
2020-03-30 Jakub Jelinek <jakub@redhat.com>
PR c++/94385
* semantics.c (add_stmt): Only set STMT_IS_FULL_EXPR_P on trees with
STATEMENT_CODE_P code.
Jakub Jelinek [Tue, 7 Apr 2020 19:00:28 +0000 (21:00 +0200)]
Fix vextract* masked patterns [PR93069]
The AVX512F documentation clearly states that in instructions where the
destination is a memory only merging-masking is possible, not zero-masking,
and the assembler enforces that.
The testcase in this patch fails to assemble because of
Error: unsupported masking for `vextracti32x8'
on
vextracti32x8 $0x0, %zmm1, -64(%rsp){%k1}{z}
For the vector extraction patterns, we apparently have 7 *_maskm patterns
that only accept memory destinations and rtx_equal_p merge-masking source
for it, 7 *<mask_name> corresponding patterns that allow memory destination
only for the non-masked cases (through <store_mask_constraint>), then 2
*<mask_name> patterns (lo ssehalf V16FI and lo ssehalf VI8F_256 ones) which
do allow memory destination even for masked cases and are the cause of the
testsuite failure, because we must not allow C constraint if the destination
is m, and finally one pair of patterns (separate * and *_mask, hi ssehalf
VI4F_256), which has another issue (for which I don't have a testcase
though), where if it would match zero-masking with register destination,
it wouldn't emit the needed {z} into assembly.
The attached patch fixes those 3 issues only, perhaps more suitable for
backporting.
2020-03-30 Jakub Jelinek <jakub@redhat.com>
PR target/93069
* config/i386/sse.md (vec_extract_lo_<mode><mask_name>): Use
<store_mask_constraint> instead of m in output operand constraint.
(vec_extract_hi_<mode><mask_name>): Use <mask_operand2> instead of
%{%3%}.
* gcc.target/i386/avx512vl-pr93069.c: New test.
* gcc.dg/vect/pr93069.c: New test.
Jakub Jelinek [Sat, 28 Mar 2020 09:21:52 +0000 (10:21 +0100)]
reassoc: Fix -fcompare-debug bug in reassociate_bb [PR94329]
The following testcase FAILs with -fcompare-debug, because reassociate_bb
mishandles the case when the last stmt in a bb has zero uses. In that case
reassoc_remove_stmt (like gsi_remove) moves the iterator to the next stmt,
i.e. gsi_end_p is true, which means the code sets the iterator back to
gsi_last_bb. The problem is that the for loop does gsi_prev on that before
handling the next statement, which means the former penultimate stmt, now
last one, is not processed by reassociate_bb.
Now, with -g, if there is at least one debug stmt at the end of the bb,
reassoc_remove_stmt moves the iterator to that following debug stmt and we
just do gsi_prev and continue with the former penultimate non-debug stmt,
now last non-debug stmt.
The following patch fixes that by not doing the gsi_prev in this case; there
are too many continue; cases, so I didn't want to copy over the gsi_prev to
all of them, so this patch uses a bool for that instead. The second
gsi_end_p check isn't needed anymore, because when we don't do the
undesirable gsi_prev after gsi = gsi_last_bb, the loop !gsi_end_p (gsi)
condition will catch the removal of the very last stmt from a bb.
2020-03-28 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/94329
* tree-ssa-reassoc.c (reassociate_bb): When calling reassoc_remove_stmt
on the last stmt in a bb, make sure gsi_prev isn't done immediately
after gsi_last_bb.
Jakub Jelinek [Tue, 7 Apr 2020 18:59:37 +0000 (20:59 +0200)]
varasm: Fix output_constructor where a RANGE_EXPR index needs to skip some elts [PR94303]
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.
Jakub Jelinek [Tue, 7 Apr 2020 18:57:37 +0000 (20:57 +0200)]
if-conv: Fix -fcompare-debug bugs in ifcvt_local_dce [PR94283]
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.
Jakub Jelinek [Tue, 24 Mar 2020 08:33:17 +0000 (09:33 +0100)]
cgraphunit: Avoid code generation differences based on -w/TREE_NO_WARNING [PR94277]
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.
Jakub Jelinek [Mon, 23 Mar 2020 18:44:58 +0000 (19:44 +0100)]
c: Fix up cfun->function_end_locus on invalid function bodies [PR94239]
Unfortunately the patch broke
+FAIL: gcc.dg/pr20245-1.c (internal compiler error)
+FAIL: gcc.dg/pr20245-1.c (test for excess errors)
+FAIL: gcc.dg/pr28419.c (internal compiler error)
+FAIL: gcc.dg/pr28419.c (test for excess errors)
on some targets (and under valgrind on the rest of them).
Those functions don't have the opening { and so c_parser_compound_statement
returned error_mark_node before initializing *endlocp.
So, either we can initialize it in that case too:
--- gcc/c/c-parser.c 2020-03-20 22:09:39.659411721 +0100
+++ gcc/c/c-parser.c 2020-03-21 09:36:44.455705261 +0100
@@ -5611,6 +5611,8 @@ c_parser_compound_statement (c_parser *p
if we have just prepared to enter a function body. */
stmt = c_begin_compound_stmt (true);
c_end_compound_stmt (brace_loc, stmt, true);
+ if (endlocp)
+ *endlocp = brace_loc;
return error_mark_node;
}
stmt = c_begin_compound_stmt (true);
or perhaps simpler initialize it to the function_start_locus at the
beginning and have those functions without { have function_start_locus ==
function_end_locus like the __GIMPLE functions (where propagating the
closing } seemed too difficult).
2020-03-23 Jakub Jelinek <jakub@redhat.com>
PR gcov-profile/94029
PR c/94239
* c-parser.c (c_parser_declaration_or_fndef): Initialize endloc to
the function_start_locus location. Don't do that afterwards for the
__GIMPLE body parsing.
Jakub Jelinek [Thu, 19 Mar 2020 21:56:20 +0000 (22:56 +0100)]
c: Fix up cfun->function_end_locus from the C FE [PR94029]
On the following testcase we ICE because while
DECL_STRUCT_FUNCTION (current_function_decl)->function_start_locus
= c_parser_peek_token (parser)->location;
and similarly DECL_SOURCE_LOCATION (fndecl) is set from some token's
location, the end is set as:
/* Store the end of the function, so that we get good line number
info for the epilogue. */
cfun->function_end_locus = input_location;
and the thing is that input_location is only very rarely set in the C FE
(the primary spot that changes it is the cb_line_change/fe_file_change).
Which means, e.g. for pretty much all C functions that are on a single line,
function_start_locus column is > than function_end_locus column, and the
testcase even has smaller line in function_end_locus because cb_line_change
isn't performed while parsing multi-line arguments of a function-like macro.
Attached are two possible fixes to achieve what the C++ FE does, in
particular that cfun->function_end_locus is the locus of the closing } of
the function. The first one updates input_location when we see a closing }
of a compound statement (though any, not just the function body) and thus
input_location in the finish_function call is what we need.
The second instead propagates the location_t from the parsing of the
outermost compound statement (the function body) to finish_function.
The second one is this version.
2020-03-19 Jakub Jelinek <jakub@redhat.com>
PR gcov-profile/94029
* c-tree.h (finish_function): Add location_t argument defaulted to
input_location.
* c-parser.c (c_parser_compound_statement): Add endlocp argument and
set it to the locus of closing } if non-NULL.
(c_parser_compound_statement_nostart): Return locus of closing }.
(c_parser_parse_rtl_body): Likewise.
(c_parser_declaration_or_fndef): Propagate locus of closing } to
finish_function.
* c-decl.c (finish_function): Add end_loc argument, use it instead of
input_location to set function_end_locus.
Jakub Jelinek [Thu, 19 Mar 2020 11:22:47 +0000 (12:22 +0100)]
c++: Fix up handling of captured vars in lambdas in OpenMP clauses [PR93931]
Without the parser.c change we were ICEing on the testcase, because while the
uses of the captured vars inside of the constructs were replaced with capture
proxy decls, we didn't do that for decls in OpenMP clauses.
With that fixed, we don't ICE anymore, but the testcase is miscompiled and FAILs
at runtime. This is because the capture proxy decls have DECL_VALUE_EXPR and
during gimplification we were gimplifying those to their DECL_VALUE_EXPRs.
That is fine for shared vars, but for privatized ones we must not do that.
So that is what the cp-gimplify.c changes do. Had to add a DECL_CONTEXT check
before calling is_capture_proxy because some VAR_DECLs don't have DECL_CONTEXT
set (yet) and is_capture_proxy relies on that being non-NULL always.
2020-03-19 Jakub Jelinek <jakub@redhat.com>
PR c++/93931
* parser.c (cp_parser_omp_var_list_no_open): Call process_outer_var_ref
on outer_automatic_var_p decls.
* cp-gimplify.c (cxx_omp_disregard_value_expr): Return true also for
capture proxy decls.
Jakub Jelinek [Thu, 19 Mar 2020 09:24:16 +0000 (10:24 +0100)]
phiopt: Avoid -fcompare-debug bug in phiopt [PR94211]
Two years ago, I've added support for up to 2 simple preparation statements
in value_replacement, but the
- && estimate_num_insns (assign, &eni_time_weights)
+ && estimate_num_insns (bb_seq (middle_bb), &eni_time_weights)
change, meant that we compute the cost of all those statements rather than
just the single assign that has been the single supported non-debug
statement in the bb before, doesn't do what I thought would do, gimple_seq
is just gimple * and thus it can't be really overloaded depending on whether
we pass a single gimple * or a whole sequence. Which means in the last
two years it doesn't count all the statements, but only the first one.
With -g that happens to be a DEBUG_STMT, or it could be e.g. the first
preparation statement which could be much cheaper than the actual assign.
2020-03-19 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/94211
* tree-ssa-phiopt.c (value_replacement): Use estimate_num_insns_seq
instead of estimate_num_insns for bb_seq (middle_bb). Rename
emtpy_or_with_defined_p variable to empty_or_with_defined_p, adjust
all uses.
Jakub Jelinek [Tue, 17 Mar 2020 21:32:34 +0000 (22:32 +0100)]
c: Handle C_TYPE_INCOMPLETE_VARS even for ENUMERAL_TYPEs [PR94172]
The following testcases ICE, because they contain extern variable
declarations with incomplete enum types that is later completed and after
that those variables are accessed. The ICEs are because the vars then may have
incorrect DECL_MODE etc., e.g. in the first case the var has SImode
DECL_MODE (the guessed mode for the enum), but the enum then actually has
DImode because its enumerators don't fit into unsigned int.
The following patch fixes it by using C_TYPE_INCOMPLETE_VARS not just on
incomplete struct/union types, but also incomplete enum types.
TYPE_VFIELD can't be used as it is TYPE_MIN_VALUE on ENUMERAL_TYPE,
thankfully TYPE_LANG_SLOT_1 has been used in the C FE only on
FUNCTION_TYPEs.
2020-03-17 Jakub Jelinek <jakub@redhat.com>
PR c/94172
* c-tree.h (C_TYPE_INCOMPLETE_VARS): Define to TYPE_LANG_SLOT_1
instead of TYPE_VFIELD, and support it on {RECORD,UNION,ENUMERAL}_TYPE.
(TYPE_ACTUAL_ARG_TYPES): Check that it is only used on FUNCTION_TYPEs.
* c-decl.c (pushdecl): Push C_TYPE_INCOMPLETE_VARS also to
ENUMERAL_TYPEs.
(finish_incomplete_vars): New function, moved from finish_struct. Use
relayout_decl instead of layout_decl.
(finish_struct): Remove obsolete comment about C_TYPE_INCOMPLETE_VARS
being TYPE_VFIELD. Use finish_incomplete_vars.
(finish_enum): Clear C_TYPE_INCOMPLETE_VARS. Call
finish_incomplete_vars.
* c-typeck.c (c_build_qualified_type): Clear C_TYPE_INCOMPLETE_VARS
also on ENUMERAL_TYPEs.
* gcc.dg/pr94172-1.c: New test.
* gcc.dg/pr94172-2.c: New test.
Jakub Jelinek [Tue, 17 Mar 2020 20:21:16 +0000 (21:21 +0100)]
c++: Fix parsing of invalid enum specifiers [PR90995]
The testcase shows some accepts-invalid (the ones without alignas) and
ice-on-invalid-code (the ones with alignas) cases.
If the enum doesn't have an underlying type and is not a definition,
the caller retries to parse it as elaborated type specifier.
E.g. for enum struct S s it will then pedwarn that elaborated type specifier
shouldn't have the struct/class keywords.
The problem is if the enum specifier is not followed by { when it has
underlying type. In that case we have already called
cp_parser_parse_definitely to end the tentative parsing started at the
beginning of cp_parser_enum_specifier. But the
cp_parser_error (parser, "expected %<;%> or %<{%>");
doesn't emit any error because the whole function is called from yet another
tentative parse and the caller starts parsing the elaborated type
specifier where the cp_parser_enum_specifier stopped (i.e. after the
underlying type token(s)). The ultimate caller than commits the tentative
parsing (and even if it wouldn't, it wouldn't know what kind of error
to report). I think after seeing enum {,struct,class} : type not being
followed by { or ;, there is no reason not to report it right away, as it
can't be valid C++, which is what the patch does. Not sure if we shouldn't
also return error_mark_node instead of NULL_TREE, so that the caller doesn't
try to parse it as elaborated type specifier (the patch doesn't do that
right now).
Furthermore, while reading the code, I've noticed that
parser->colon_corrects_to_scope_p is saved and set to false at the start
of the function, but not restored back in some cases. Don't have a testcase
where this would be a problem, but it just seems wrong. Either we can in
the two spots replace return NULL_TREE; with { type = NULL_TREE; goto out; }
or we could perhaps abuse warning_sentinel or create a special class with
dtor to clean the flag up.
And lastly, I've fixed some formatting issues in the function while reading
it.
2020-03-17 Jakub Jelinek <jakub@redhat.com>
PR c++/90995
* parser.c (cp_parser_enum_specifier): Use temp_override for
parser->colon_corrects_to_scope_p, replace goto out with return.
If scoped enum or enum with underlying type is not followed by
{ or ;, call cp_parser_commit_to_tentative_parse before calling
cp_parser_error and make sure to return error_mark_node instead of
NULL_TREE. Formatting fixes.
d: Fix ICE in add_symbol_to_partition_1, at lto/lto-partition.c:215
This patch addresses two problems with TypeInfo initializer generation.
1. D array fields pointing to compiler generated data are referencing
public symbols with no unique prefix, which can lead to duplicate
definition errors in some hard to reduce cases. To avoid name clashes,
all symbols that are generated for TypeInfo initializers now use the
assembler name of the TypeInfo decl as a prefix.
2. An ICE would occur during LTO pass because these same decls are
considered to be part of the same comdat group as the TypeInfo decl that
it's referred by, despite itself being neither marked public nor comdat.
This resulted in decls being added to the LTRANS partition out of order,
triggering an assert when add_symbol_to_partition_1 attempted to add
them again. To remedy, TREE_PUBLIC and DECL_COMDAT are now set on all
generated symbols.
gcc/d/ChangeLog:
PR d/94240
* typeinfo.cc (class TypeInfoVisitor): Replace type_ field with decl_.
(TypeInfoVisitor::TypeInfoVisitor): Set decl_.
(TypeInfoVisitor::result): Update.
(TypeInfoVisitor::internal_reference): New function.
(TypeInfoVisitor::layout_string): Use internal_reference.
(TypeInfoVisitor::visit (TypeInfoTupleDeclaration *)): Likewise.
(layout_typeinfo): Construct TypeInfoVisitor with typeinfo decl.
(layout_classinfo): Likewise.
Jakub Jelinek [Tue, 7 Apr 2020 06:27:49 +0000 (08:27 +0200)]
i386: Fix emit_reduc_half on V{64Q,32H}Imode [PR94500]
The following testcase is miscompiled in 8.x, because emit_reduc_half is
prepared to handle for 512-bit modes only i equal to 512, 256, 128 and 64.
V32HImode also needs i equal to 32 and V64QImode i equal to 32 and 16,
but emit_reduc_half in that case performs a redundant permutation exactly
like i == 32. In 9+ the testcase works because Richard in r9-3393
changed the reduc_* expanders so that they actually don't call
ix86_expand_reduc on 512-bit modes, but only 128-bit ones.
The patch fixes emit_reduc_half to handle also i of 32 and 16 similarly to
how V32QImode/V16HImode are handled for AVX2. I think it shouldn't hurt
to fix the function even on the trunk and 9 branch even when nothing uses
it ATM.
2020-04-07 Jakub Jelinek <jakub@redhat.com>
PR target/94500
* config/i386/i386.c (emit_reduc_half): For V{64QI,32HI}mode
handle i < 64 using avx512bw_lshrv4ti3. Formatting fixes.
Marek Polacek [Mon, 6 Apr 2020 00:31:56 +0000 (20:31 -0400)]
c++: Fix ICE with lambda in operator function [PR93597]
If we are going to use get_first_fn let's make sure we operate on
is_overloaded_fn, as the rest of the codebase does, and if lookup finds
any class-scope declaration, return early too.
PR c++/93597 - ICE with lambda in operator function.
* name-lookup.c (maybe_save_operator_binding): Check is_overloaded_fn.
Jason Merrill [Sat, 4 Apr 2020 15:04:55 +0000 (11:04 -0400)]
c++: Fix reuse of class constants [PR94453]
The testcase hit an ICE trying to expand a TARGET_EXPR temporary cached from
the other lambda-expression. This patch fixes this in two ways:
1) Avoid reusing a TARGET_EXPR from another function.
2) Avoid ending up with a TARGET_EXPR at all; the use of 'p' had become
<TARGET_EXPR<NON_LVALUE_EXPR<TARGET_EXPR ...>>>, which doesn't make any
sense.
gcc/cp/ChangeLog
2020-04-04 Jason Merrill <jason@redhat.com>
PR c++/94453
* constexpr.c (maybe_constant_value): Use break_out_target_exprs.
* expr.c (mark_use) [VIEW_CONVERT_EXPR]: Don't wrap a TARGET_EXPR in
NON_LVALUE_EXPR.
Jason Merrill [Fri, 3 Apr 2020 03:40:46 +0000 (23:40 -0400)]
c++: alias template and parameter packs (PR91966).
In this testcase, when we do a pack expansion of count_better_mins<nums>,
nums appears both in the definition of count_better_mins and as its template
argument. The intent is that we get a expansion over pairs of elements of
the pack, i.e. less<2,2>, less<2,7>, less<7,2>, .... But if we substitute
into the definition of count_better_mins when parsing the template, we end
up with sum<less<nums,nums>...>, which never gives us less<2,7>. We could
deal with this by somehow marking up the use of 'nums' as an argument for
'num', but it's simpler to mark the alias as complex, so we need to
instantiate it later with all its arguments rather than replace it early
with its expansion.
gcc/cp/ChangeLog
2020-04-03 Jason Merrill <jason@redhat.com>
PR c++/91966
* pt.c (complex_pack_expansion_r): New.
(complex_alias_template_p): Use it.
Martin Jambor [Fri, 3 Apr 2020 18:32:44 +0000 (20:32 +0200)]
gcc-9 sra: Cap number of sub-access propagations with a param (PR 93435)
This is non-trivial but rather straightforward backport of 29f23ed79b60949fc60f6fdbbd931bd58090b241 from master. See
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542390.html for
more information.
2020-04-02 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/93435
* params.def (PARAM_SRA_MAX_PROPAGATIONS): New parameter.
* tree-sra.c (propagation_budget): New variable.
(budget_for_propagation_access): New function.
(propagate_subaccesses_across_link): Use it.
(propagate_all_subaccesses): Set up and destroy propagation_budget.
* doc/invoke.texi (sra-max-propagations): New.
Jonathan Wakely [Fri, 3 Apr 2020 11:00:07 +0000 (12:00 +0100)]
libstdc++: Fix std::to_address for debug iterators (PR 93960)
It should be valid to use std::to_address on a past-the-end iterator,
but the debug mode iterators do a check for dereferenceable in their
operator->(). That check is generally useful, so rather than remove it
this changes std::__to_address to identify a debug mode iterator and
use base().operator->() to skip the check.
Backport from mainline
2020-04-03 Jonathan Wakely <jwakely@redhat.com>
PR libstdc++/93960
* include/bits/ptr_traits.h (__to_address): Add special case for debug
iterators, to avoid dereferenceable check.
* testsuite/20_util/to_address/1_neg.cc: Adjust dg-error line number.
* testsuite/20_util/to_address/debug.cc: New test.
Richard Biener [Thu, 12 Mar 2020 13:18:35 +0000 (14:18 +0100)]
tree-optimization/94103 avoid CSE of loads with padding
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.
Jakub Jelinek [Thu, 2 Apr 2020 10:54:47 +0000 (12:54 +0200)]
aarch64: Fix ICE due to aarch64_gen_compare_reg_maybe_ze [PR94435]
The following testcase ICEs, because aarch64_gen_compare_reg_maybe_ze emits
invalid RTL.
For y_mode [QH]Imode it expects y to be of that mode (or CONST_INT that fits
into that mode) and x being SImode; for non-CONST_INT y it zero extends y
into SImode and compares that against x, for CONST_INT y it zero extends y
into SImode. The problem is that when the zero extended constant isn't
usable directly, it forces it into a REG, but with y_mode mode, and then
compares against y. That is wrong, because it should force it into a SImode
REG and compare that way.
2020-04-02 Jakub Jelinek <jakub@redhat.com>
PR target/94435
* config/aarch64/aarch64.c (aarch64_gen_compare_reg_maybe_ze): For
y_mode E_[QH]Imode and y being a CONST_INT, change y_mode to SImode.
Mark Eggleston [Thu, 2 Apr 2020 07:26:34 +0000 (08:26 +0100)]
fortran: ICE equivalence with an element of an array PR94030
Deferred size arrays can not be used in equivalance statements.
gcc/fortran/ChangeLog:
Backport from master
2020-04-02 Mark Eggleston <markeggleston@gcc.gnu.org>
PR fortran/94030
* resolve.c (resolve_equivalence): Correct formatting
around the label "identical_types". Instead of using
gfc_resolve_array_spec use is_non_constants_shape_array
to determine whether the array can be used in a in an
equivalence statement.
gcc/testsuite/ChangeLog:
Backport from master
2020-04-02 Mark Eggleston <markeggleston@gcc.gnu.org>
Backport from mainline
2020-03-31 Jakub Jelinek <jakub@redhat.com>
PR target/94368
* config/aarch64/constraints.md (Uph): New constraint.
* config/aarch64/atomics.md (cas_short_expected_imm): New mode attr.
(@aarch64_compare_and_swap<mode>): Use it instead of n in operand 2's
constraint.
Backport from mainline
2019-09-19 Richard Henderson <richard.henderson@linaro.org>
* config/aarch64/lse-init.c: New file.
* config/aarch64/lse.S: New file.
* config/aarch64/t-lse: New file.
* config.host: Add t-lse to all aarch64 tuples.
Backport from mainline
2019-09-19 Richard Henderson <richard.henderson@linaro.org>
* config/aarch64/aarch64 (aarch64_split_compare_and_swap): Disable
strong_zero_p for aarch64_track_speculation; unify some code paths;
use aarch64_gen_compare_reg instead of open-coding.
Backport from mainline
2019-09-19 Richard Henderson <richard.henderson@linaro.org>
* config/aarch64/aarch64.c (aarch64_gen_compare_reg): Add support
for NE comparison of TImode values.
(aarch64_emit_load_exclusive): Add support for TImode.
(aarch64_emit_store_exclusive): Likewise.
(aarch64_split_compare_and_swap): Disable strong_zero_p for TImode.
* config/aarch64/atomics.md (@atomic_compare_and_swap<ALLI_TI>):
Change iterator from ALLI to ALLI_TI.
(@atomic_compare_and_swap<JUST_TI>): New.
(@atomic_compare_and_swap<JUST_TI>_lse): New.
(aarch64_load_exclusive_pair): New.
(aarch64_store_exclusive_pair): New.
* config/aarch64/iterators.md (JUST_TI): New.
projects / thirdparty / gcc.git / log
