Jakub Jelinek [Tue, 17 Mar 2020 09:42:35 +0000 (10:42 +0100)]
expand: Don't depend on warning flags in code generation of strnlen [PR94189]
The following testcase FAILs with -O2 -fcompare-debug, but the reason isn't
that we'd emit different code based on -g or non-debug, but rather that
we emit different code depending on whether -w is used or not (or e.g.
-Wno-stringop-overflow or whether some other pass emitted some other warning
already on the call).
Code generation shouldn't depend on whether we emit a warning or not if at
all possible.
The following patch punts (i.e. doesn't optimize the strnlen call to a
constant value) if we would emit the warning if it was enabled.
In the PR there is an alternate patch which does optimize the strnlen call
no matter if we emit the warning or not, though I think I prefer the version
below, e.g. the strnlen call might be crossing field boundaries, which is in
strict reading undefined, but I'd be afraid people do that in the real
world programs.
2020-03-17 Jakub Jelinek <jakub@redhat.com>
PR middle-end/94189
* builtins.c (expand_builtin_strnlen): Do return NULL_RTX if we would
emit a warning if it was enabled and don't depend on TREE_NO_WARNING
for code-generation.
Jakub Jelinek [Mon, 16 Mar 2020 08:03:59 +0000 (09:03 +0100)]
tree-inline: Fix a -fcompare-debug issue in the inliner [PR94167]
The following testcase fails with -fcompare-debug. The problem is that
bar is marked as address_taken only with -g and not without.
I've tracked it down to insert_init_stmt calling gimple_regimplify_operands
even on DEBUG_STMTs. That function will just insert normal stmts before
the DEBUG_STMT if the DEBUG_STMT operand isn't gimple val or invariant.
While DCE will turn those statements into debug temporaries, it can cause
differences in SSA_NAMEs and more importantly, the ipa references are
generated from those before the DCE happens.
On the testcase, the DEBUG_STMT value is (int)bar.
We could generate DEBUG_STMTs with debug temporaries instead, but I fail to
see the reason to do that, DEBUG_STMTs allow other expressions and all we
want to ensure is that the expressions aren't too large (arbitrarily
complex), but during inlining/function versioning I don't see why something
would queue a DEBUG_STMT with arbitrarily complex expressions in there.
Jakub Jelinek [Fri, 13 Mar 2020 10:33:16 +0000 (11:33 +0100)]
aarch64: Fix another bug in aarch64_add_offset_1 [PR94121]
> 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.
Jakub Jelinek [Thu, 12 Mar 2020 08:35:30 +0000 (09:35 +0100)]
doc: Fix up ASM_OUTPUT_ALIGNED_DECL_LOCAL description
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.
Jakub Jelinek [Thu, 12 Mar 2020 08:34:00 +0000 (09:34 +0100)]
tree-dse: Fix mem* head trimming if call has lhs [PR94130]
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.
Jakub Jelinek [Wed, 11 Mar 2020 17:35:13 +0000 (18:35 +0100)]
pdp11: Fix handling of common (local and global) vars [PR94134]
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.
Jakub Jelinek [Wed, 11 Mar 2020 09:54:22 +0000 (10:54 +0100)]
aarch64: Fix ICE in aarch64_add_offset_1 [PR94121]
abs_hwi asserts that the argument is not HOST_WIDE_INT_MIN and as the
(invalid) testcase shows, the function can be called with such an offset.
The following patch is IMHO minimal fix, absu_hwi unlike abs_hwi allows even
that value and will return (unsigned HOST_WIDE_INT) HOST_WIDE_INT_MIN
in that case. The function then uses moffset in two spots which wouldn't
care if the value is (unsigned HOST_WIDE_INT) HOST_WIDE_INT_MIN or
HOST_WIDE_INT_MIN and wouldn't accept it (!moffset and
aarch64_uimm12_shift (moffset)), then in one spot where the signedness of
moffset does matter and using unsigned is the right thing -
moffset < 0x1000000 - and finally has code which will handle even this
value right; the assembler doesn't really care for DImode immediates if
mov x1, -9223372036854775808
or
mov x1, 9223372036854775808
is used and similarly it doesn't matter if we add or sub it in DImode.
2020-03-11 Jakub Jelinek <jakub@redhat.com>
PR target/94121
* config/aarch64/aarch64.c (aarch64_add_offset_1): Use absu_hwi
instead of abs_hwi, change moffset type to unsigned HOST_WIDE_INT.
Jakub Jelinek [Wed, 11 Mar 2020 08:33:52 +0000 (09:33 +0100)]
dfp: Fix decimal_to_binary [PR94111]
As e.g. decimal_from_decnumber shows, the REAL_VALUE_TYPE representation
contains a decimal128 embedded in ->sig only if it is rvc_normal, for
other kinds like rvc_inf or rvc_nan, ->sig is ignored and everything is
contained in the REAL_VALUE_TYPE flags (cl, sign, signalling and decimal).
decimal_to_binary which is used when folding a decimal{32,64,128} constant
to a binary floating point type ignores this and thus folds infinities and
NaNs into +0.0.
The following patch fixes that by only doing that for rvc_normal.
Similarly to the binary to decimal folding, it goes through a string, in
order to e.g. deal with canonical NaN mantissas, or binary float formats
that don't support infinities and/or NaNs.
2020-03-11 Jakub Jelinek <jakub@redhat.com>
PR middle-end/94111
* dfp.c (decimal_to_binary): Only use decimal128ToString if from->cl
is rvc_normal, otherwise use real_to_decimal to print the number to
string.
Jakub Jelinek [Wed, 11 Mar 2020 08:32:22 +0000 (09:32 +0100)]
ldist: Further fixes for -ftrapv [PR94114]
As the testcase shows, arithmetics that for -ftrapv would need multiple
basic blocks can show up not just in nb_bytes expressions where we
are calling rewrite_to_non_trapping_overflow for a while already,
but also in the pointer expression to the start of the region.
While the testcase covers just the first hunk and I've failed to create
a testcase for the latter, it is at least in theory possible too, so I've
adjusted that hunk too.
2020-03-11 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/94114
* tree-loop-distribution.c (generate_memset_builtin): Call
rewrite_to_non_trapping_overflow even on mem.
(generate_memcpy_builtin): Call rewrite_to_non_trapping_overflow even
on dest and src.
Jakub Jelinek [Thu, 5 Mar 2020 08:12:44 +0000 (09:12 +0100)]
print-rtl: Fix printing of CONST_STRING in DEBUG_INSNs [PR93399]
The following testcase fails to assemble, as CONST_STRING in the DEBUG_INSNs
is printed as is, so if it contains \n and/or \r, we are in trouble:
.loc 1 14 3
# DEBUG haystack => [si]
# DEBUG needle => "
"
In the gimple dumps we print those (STRING_CSTs) as
# DEBUG haystack => D#1
# DEBUG needle => "\n"
so this patch uses what we use in tree printing for the CONST_STRINGs too.
2020-03-05 Jakub Jelinek <jakub@redhat.com>
PR middle-end/93399
* tree-pretty-print.h (pretty_print_string): Declare.
* tree-pretty-print.c (pretty_print_string): Remove forward
declaration, no longer static. Change nbytes parameter type
from unsigned to size_t.
* print-rtl.c (print_value) <case CONST_STRING>: Use
pretty_print_string and for shrink way too long strings.
Jakub Jelinek [Wed, 4 Mar 2020 11:59:04 +0000 (12:59 +0100)]
inliner: Copy DECL_BY_REFERENCE in copy_decl_to_var [PR93888]
In the following testcase we emit wrong debug info for the karg
parameter in the DW_TAG_inlined_subroutine into main.
The problem is that the karg PARM_DECL is DECL_BY_REFERENCE and thus
in the IL has const K & type, but in the source just const K.
When the function is inlined, we create a VAR_DECL for it, but don't
set DECL_BY_REFERENCE, so when emitting DW_AT_location, we treat it like
a const K & typed variable, but it has DW_AT_abstract_origin which has
just the const K type and thus the debugger thinks the variable has
const K type.
Fixed by copying the DECL_BY_REFERENCE flag. Not doing it in
copy_decl_for_dup_finish, because copy_decl_no_change already copies
that flag through copy_node and in copy_result_decl_to_var it is
undesirable, as we handle DECL_BY_REFERENCE in that case instead
by changing the type.
Jakub Jelinek [Wed, 4 Mar 2020 08:01:59 +0000 (09:01 +0100)]
tailcall: Fix up process_assignment [PR94001]
When a function returns void or the return value is ignored, ass_var
is NULL_TREE. The tail recursion handling generally assumes DCE has been
performed and so doesn't expect to encounter useless assignments after the
call and expects them to be part of the return value adjustment that need
to be changed into tail recursion additions/multiplications.
process_assignment does some verification and has a way to tell the caller
to try to move dead or whatever other stmts that don't participate in the
return value modifications before it is returned.
For binary rhs assignments it is just fine, neither op0 nor op1 will be
NULL_TREE and thus if *ass_var is NULL_TREE, it will not match, but unary
rhs is handled by only setting op0 to rhs1 and setting op1 to NULL_TREE.
And at this point, NULL_TREE == NULL_TREE and thus we think e.g. the
c_2 = -e_3(D);
dead stmt is actually a return value modification, so we queue it as
multiplication and then create a void type SSA_NAME accumulator for it
and ICE shortly after.
Fixed by making sure op1 == *ass_var comparison is done only if *ass_var.
2020-03-04 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/94001
* tree-tailcall.c (process_assignment): Before comparing op1 to
*ass_var, verify *ass_var is non-NULL.
Kewen Lin [Mon, 9 Mar 2020 02:55:11 +0000 (21:55 -0500)]
[testsuite] Fix PR94019 to check vector char when vect_hw_misalign
As PR94019 shows, without misaligned vector access support but with
realign load, the vectorized loop will end up with realign scheme.
It generates mask (control vector) with return type vector signed
char which breaks the not check.
gcc/testsuite/ChangeLog
2020-03-17 Kewen Lin <linkw@gcc.gnu.org>
Backport from master
2020-03-09 Kewen Lin <linkw@gcc.gnu.org>
PR testsuite/94019
* gcc.dg/vect/vect-over-widen-17.c: Don't expect vector char if it's
without misaligned vector access support.
Kewen Lin [Mon, 9 Mar 2020 02:34:13 +0000 (21:34 -0500)]
[testsuite] Fix PR94023 to guard case under vect_hw_misalign
As PR94023 shows, the expected SLP requires misaligned vector access
support. This patch is to guard the check under the target condition
vect_hw_misalign to ensure that.
2020-03-17 Kewen Lin <linkw@gcc.gnu.org>
Backport from master
2020-03-09 Kewen Lin <linkw@gcc.gnu.org>
PR testsuite/94023
* gcc.dg/vect/slp-perm-12.c: Expect loop vectorized messages only on
vect_hw_misalign targets.
Jonathan Wakely [Mon, 16 Mar 2020 22:55:48 +0000 (22:55 +0000)]
libstdc++: Add default constructor to net::service_already_exists (PR 94199)
The service_already_exists exception type specified in the TS doesn't
have any constructors defined. Since its base class isn't default
constructible, that means has no usable constructors. This may be a
defect in the TS.
This patch fixes it by adding a default constructor, but making it
private. The make_service function is declared as a friend to be able to
call that private constructor.
Backport from mainline
2020-03-16 Jonathan Wakely <jwakely@redhat.com>
PR libstdc++/94199
* include/experimental/executor (service_already_exists): Add default
constructor. Declare make_service to be a friend.
* testsuite/experimental/net/execution_context/make_service.cc: New
test.
Jason Merrill [Sat, 14 Mar 2020 21:10:39 +0000 (17:10 -0400)]
c++: Fix ICE-after-error on partial spec [92068]
Here the template arguments for the partial specialization are valid
arguments for the template, but not for a partial specialization, because
'd' can never be deduced to anything other than an empty pack.
gcc/cp/ChangeLog
2020-03-14 Jason Merrill <jason@redhat.com>
PR c++/92068
* pt.c (process_partial_specialization): Error rather than crash on
extra pack expansion.
Jason Merrill [Sat, 14 Mar 2020 21:10:39 +0000 (17:10 -0400)]
c++: Fix CTAD with multiple-arg ctor template [93248].
When cp_unevaluated_operand is set, tsubst_decl thinks that if it sees a
PARM_DECL that isn't already in local_specializations, we're in a decltype
in a trailing return type or some such, and so we only want a substitution
for a single PARM_DECL. In this case, we want the whole chain, so make sure
cp_unevaluated_operand is cleared.
gcc/cp/ChangeLog
2020-03-14 Jason Merrill <jason@redhat.com>
PR c++/93248
* pt.c (build_deduction_guide): Clear cp_unevaluated_operand for
substituting DECL_ARGUMENTS.
Eric Botcazou [Fri, 13 Mar 2020 08:58:44 +0000 (09:58 +0100)]
Fix incorrect filling of delay slots in branchy code at -O2
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.
PR87560 reports an ICE when a test case is compiled with -mpower9-vector
and -mno-altivec. This patch terminates compilation with an error when
this combination (and other unreasonable ones) are requested.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. Reported error is now:
f951: Error: '-mno-altivec' turns off '-mpower9-vector'
2020-03-12 Bill Schmidt <wschmidt@linux.ibm.com>
Backport from master
2020-03-02 Bill Schmidt <wschmidt@linux.ibm.com>
PR target/87560
* rs6000-cpus.def (OTHER_ALTIVEC_MASKS): New #define.
* rs6000.c (rs6000_disable_incompatible_switches): Add table entry
for OPTION_MASK_ALTIVEC.
The filesystem::path::operator+= and filesystem::path::concat functions
operate directly on the native format of the path and so can cause a
path to mutate to a completely different type.
For Windows combining a filename "x" with a filename ":" produces a
root-name "x:". Similarly, a Cygwin root-directory "/" combined with a
root-directory and filename "/x" produces a root-name "//x".
Before this patch the implemenation didn't support those kind of
mutations, assuming that concatenating two filenames would always
produce a filename and concatenating with a root-dir would still have a
root-dir.
This patch fixes it simply by checking for the problem cases and
creating a new path by re-parsing the result of the string
concatenation. This is slightly suboptimal because the argument has
already been parsed if it's a path, but more importantly it doesn't
reuse any excess capacity that the path object being modified might
already have allocated.
Backport from mainline
2020-03-09 Jonathan Wakely <jwakely@redhat.com>
PR libstdc++/94063
* src/c++17/fs_path.cc (path::operator+=(const path&)): Add kluge to
handle concatenations that change the type of the first component.
(path::operator+=(basic_string_view<value_type>)): Likewise.
* testsuite/27_io/filesystem/path/concat/94063.cc: New test.
Jonathan Wakely [Thu, 12 Mar 2020 17:39:05 +0000 (17:39 +0000)]
libstdc++: Fix name of macro in #undef directive
The macro that is defined is _GLIBCXX_NOT_FN_CALL_OP but the macro that
was named in the #undef directive was _GLIBCXX_NOT_FN_CALL. This fixes
the #undef.
Backport from mainline
2020-02-04 Jonathan Wakely <jwakely@redhat.com>
* include/std/functional (_GLIBCXX_NOT_FN_CALL_OP): Un-define after
use.
Jonathan Wakely [Thu, 12 Mar 2020 17:39:04 +0000 (17:39 +0000)]
libstdc++: Fix FS-dependent filesystem tests
These tests were failing on XFS because it doesn't support setting file
timestamps past 2038, so the expected overflow when reading back a huge
timestamp into a file_time_type didn't happen.
Additionally, the std::filesystem::file_time_type::clock has an
epoch that is out of range of 32-bit time_t so testing times around that
epoch may also fail.
This fixes the tests to give up gracefully if the filesystem doesn't
support times that can't be represented in 32-bit time_t.
Backport from mainline
2020-02-28 Jonathan Wakely <jwakely@redhat.com>
* testsuite/27_io/filesystem/operations/last_write_time.cc: Fixes for
filesystems that silently truncate timestamps.
* testsuite/experimental/filesystem/operations/last_write_time.cc:
Likewise.
Jonathan Wakely [Thu, 12 Mar 2020 17:39:04 +0000 (17:39 +0000)]
libstdc++: Ensure root-dir converted to forward slash (PR93244)
Backport from mainline
2020-01-13 Jonathan Wakely <jwakely@redhat.com>
PR libstdc++/93244
* include/bits/fs_path.h (path::generic_string<C,A>)
[_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Convert root-dir to forward-slash.
* testsuite/27_io/filesystem/path/generic/generic_string.cc: Check
root-dir is converted to forward slash in generic pathname.
* testsuite/27_io/filesystem/path/generic/utf.cc: New test.
* testsuite/27_io/filesystem/path/generic/wchar_t.cc: New test.
arm: correct constraints on movsi_compare0 [PR91913]
The peephole that detects a mov of one register to another followed by
a comparison of the original register against zero is only used in Arm
state; but the instruction that matches this is generic to all 32-bit
compilation states. That instruction lacks support for SP which is
permitted in Arm state, but has restrictions in Thumb2 code.
This patch fixes the problem by allowing SP when in ARM state for all
registers; in Thumb state it allows SP only as a source when the
register really is copied to another target.
gcc/ChangeLog:
PR target/91913
Backport from master
* config/arm/arm.md (movsi_compare0): Allow SP as a source register
in Thumb state and also as a destination in Arm state. Add T16
variants.
gcc/testsuite/ChangeLog:
2020-02-10 Jakub Jelinek <jakub@redhat.com>
PR target/91913
Backport from master
* gfortran.dg/pr91913.f90: New test.
Backport from mainline
2020-03-09 Martin Liska <mliska@suse.cz>
PR target/93800
* config/rs6000/rs6000.c (rs6000_option_override_internal):
Remove set of str_align_loops and str_align_jumps as these
should be set in previous 2 conditions in the function.
Backport from mainline
2020-03-09 Martin Liska <mliska@suse.cz>
PR target/93800
* gcc.target/powerpc/pr93800.c: New test.
Eric Botcazou [Wed, 11 Mar 2020 09:47:34 +0000 (10:47 +0100)]
Fix internal error on locally-defined subpools
If the type is derived in the current compilation unit, and Allocate
is not overridden on derivation (as is typically the case with
Root_Storage_Pool_With_Subpools), the entity for Allocate of the
derived type is an alias for System.Storage_Pools.Subpools.Allocate.
The main assertion in gnat_to_gnu_entity fails in this case, since
this is not a definition and Is_Public is false (since the entity
is nested in the same compilation unit).
2020-03-11 Richard Wai <richard@annexi-strayline.com>
* gcc-interface/decl.c (gnat_to_gnu_entity): Also test Is_Public on
the Alias of the entitiy, if is present, in the main assertion.
Xionghu Luo [Tue, 10 Mar 2020 01:25:20 +0000 (20:25 -0500)]
Backport to gcc-9: PR92398: Fix testcase failure of pr72804.c
Backport the patch to fix failures on P9 and P8BE, P7LE for PR94036.
Tested pass on P9/P8/P7.
(gcc-8 is not needed as the test doesn't exists.)
P9LE generated instruction is not worse than P8LE.
mtvsrdd;xxlnot;stxv vs. not;not;std;std.
It can have longer latency, but latency via memory is not so critical,
and this does save decode and other resources. It's hard to choose
which is best. Update the test case to fix failures.
gcc/testsuite/ChangeLog:
2020-03-10 Luo Xiong Hu <luoxhu@linux.ibm.com>
backport from master.
PR testsuite/94036
2019-12-02 Luo Xiong Hu <luoxhu@linux.ibm.com>
PR testsuite/92398
* gcc.target/powerpc/pr72804.c: Split the store function to...
* gcc.target/powerpc/pr92398.h: ... this one. New.
* gcc.target/powerpc/pr92398.p9+.c: New.
* gcc.target/powerpc/pr92398.p9-.c: New.
* lib/target-supports.exp (check_effective_target_p8): New.
(check_effective_target_p9+): New.
Jonathan Wakely [Fri, 6 Mar 2020 12:52:51 +0000 (12:52 +0000)]
libstdc++: Fix call to __glibcxx_rwlock_init (PR 94069)
When the target doesn't define PTHREAD_RWLOCK_INITIALIZER we use a
wrapper around pthread_wrlock_init, but the wrapper only takes one
argument and we try to call it with two.
This went unnnoticed on most targets because they do define the
PTHREAD_RWLOCK_INITIALIZER macro, but it causes a bootstrap failure on
darwin8.
Backport from mainline
2020-03-06 Jonathan Wakely <jwakely@redhat.com>
PR libstdc++/94069
* include/std/shared_mutex [!PTHREAD_RWLOCK_INITIALIZER]
(__shared_mutex_pthread::__shared_mutex_pthread()): Remove incorrect
second argument to __glibcxx_rwlock_init.
* testsuite/30_threads/shared_timed_mutex/94069.cc: New test.
Jakub Jelinek [Thu, 5 Mar 2020 18:44:42 +0000 (19:44 +0100)]
i386: Fix some -O0 avx2intrin.h and xopintrin.h intrinsic macros [PR94046]
As the testcases show, the macros we have for -O0 for intrinsics that require
constant argument(s) should first cast the argument to the type the -O1+
inline uses and afterwards to whatever type e.g. a builtin needs.
The PR reported one which violated this, and I've grepped for all double-casts
and grepped out from that meaningful casts where the __m{128,256,512}{,d,i}
first cast is cast to same sized __v* type and has the same kind of element
type (float, double, integral). These 7 macros were using different casts,
and I've double checked them against the inline function types.
2020-03-05 Jakub Jelinek <jakub@redhat.com>
PR target/94046
* config/i386/avx2intrin.h (_mm_mask_i32gather_ps): Fix first cast of
SRC and MASK arguments to __m128 from __m128d.
(_mm256_mask_i32gather_ps): Fix first cast of MASK argument to __m256
from __m256d.
(_mm_mask_i64gather_ps): Fix first cast of MASK argument to __m128
from __m128d.
* config/i386/xopintrin.h (_mm_permute2_pd): Fix first cast of C
argument to __m128i from __m128d.
(_mm256_permute2_pd): Fix first cast of C argument to __m256i from
__m256d.
(_mm_permute2_ps): Fix first cast of C argument to __m128i from __m128.
(_mm256_permute2_ps): Fix first cast of C argument to __m256i from
__m256.
* g++.target/i386/pr94046-1.C: New test.
* g++.target/i386/pr94046-2.C: New test.
Jonathan Wakely [Thu, 5 Mar 2020 17:32:58 +0000 (17:32 +0000)]
libstdc++: Fix some warnings in filesystem tests
There's a -Wunused-but-set-variable warning in operations/all.cc which
can be fixed with [[maybe_unused]].
The statements in operations/copy.cc give -Wunused-value warnings. I
think I meant to use |= rather than !=.
And operations/file_size.cc gets -Wsign-compare warnings.
Backport from mainline
2020-03-05 Jonathan Wakely <jwakely@redhat.com>
* testsuite/27_io/filesystem/operations/all.cc: Mark unused variable.
* testsuite/27_io/filesystem/operations/copy.cc: Fix typo.
* testsuite/experimental/filesystem/operations/copy.cc: Likewise.
* testsuite/27_io/filesystem/operations/file_size.cc: Use correct type
for return value, and in comparison.
* testsuite/experimental/filesystem/operations/file_size.cc: Likewise.
Jonathan Wakely [Thu, 5 Mar 2020 16:52:19 +0000 (16:52 +0000)]
libstdc++: make negative count safe with std::for_each_n
The Library Working Group have approved a change to std::for_each_n that
requires it to handle negative N gracefully, which we were not doing for
random access iterators.
Backport from mainline
2019-11-07 Jonathan Wakely <jwakely@redhat.com>
* include/bits/stl_algo.h (for_each_n): Handle negative count.
* testsuite/25_algorithms/for_each/for_each_n_debug.cc: New test.
Richard Earnshaw [Thu, 18 Jul 2019 13:56:52 +0000 (13:56 +0000)]
arm: Fix incorrect modes with 'borrow' operations [PR90311]
Looking through the arm backend I noticed that the modes used to pass
comparison types into subtract-with-carry operations were being
incorrectly set. The result is that the compiler is not truly
self-consistent. To clean this up I've introduced a new predicate,
arm_borrow_operation (borrowed from the AArch64 backend) which can
match the comparison type with the required mode and then fixed all
the patterns to use this. The split patterns that were generating
incorrect modes have all obviously been fixed as well.
The basic rule for the use of a borrow is:
- if the condition code was set by a 'subtract-like' operation (subs, cmp),
then use CCmode and LTU.
- if the condition code was by unsigned overflow of addition (adds), then
use CC_Cmode and GEU.
gcc:
PR target/90311
Backport from master
* config/arm/predicates.md (arm_borrow_operation): New predicate.
* config/arm/arm.c (subdi3_compare1): Use CCmode for the split.
(arm_subdi3, subdi_di_zesidi, subdi_di_sesidi): Likewise.
(subdi_zesidi_zesidi): Likewise.
(negdi2_compare, negdi2_insn): Likewise.
(negdi_extensidi): Likewise.
(negdi_zero_extendsidi): Likewise.
(arm_cmpdi_insn): Likewise.
(subsi3_carryin): Use arm_borrow_operation.
(subsi3_carryin_const): Likewise.
(subsi3_carryin_const0): Likewise.
(subsi3_carryin_compare): Likewise.
(subsi3_carryin_compare_const): Likewise.
(subsi3_carryin_compare_const0): Likewise.
(subsi3_carryin_shift): Likewise.
(rsbsi3_carryin_shift): Likewise.
(negsi2_carryin_compare): Likewise.
gcc/testsuite:
2020-03-05 Jakub Jelinek <jakub@redhat.com>
Backport from master
PR target/90311
* gcc.c-torture/execute/pr90311.c: New test.
Uros Bizjak [Thu, 5 Mar 2020 16:53:03 +0000 (17:53 +0100)]
testsuite: Compile asan_test.C with -Wno-alloc-size-larger-than
asan_test.cc tries to allocate 0xf0000000 bytes for 32bit targets in
a disabled DISABLED_DemoOOM test. Since the testcase is compiled with
-Werror, the compilation fails with:
Paul Thomas [Thu, 5 Mar 2020 10:01:59 +0000 (11:01 +0100)]
Fix ICE in trans_associate_var
2020-03-05 Paul Thomas <pault@gcc.gnu.org>
Backport from trunk
PR fortran/92976
* match.c (select_type_set_tmp): Variable 'selector' to replace
select_type_stack->selector. If the selector array spec has
explicit bounds, make the temporary's bounds deferred.
2020-03-05 Paul Thomas <pault@gcc.gnu.org>
Backport from trunk
PR fortran/92976
* gfortran.dg/select_type_48.f90 : New test.
Marek Polacek [Wed, 4 Mar 2020 23:49:37 +0000 (18:49 -0500)]
c++: Fix mismatch in template argument deduction [PR90505]
2020-03-03 Jason Merrill <jason@redhat.com>
Marek Polacek <polacek@redhat.com>
PR c++/90505 - mismatch in template argument deduction.
* pt.c (tsubst): Don't reduce the template level of template
parameters when tf_partial.
* g++.dg/template/deduce4.C: New test.
* g++.dg/template/deduce5.C: New test.
* g++.dg/template/deduce6.C: New test.
* g++.dg/template/deduce7.C: New test.
Jakub Jelinek [Thu, 27 Feb 2020 08:38:12 +0000 (09:38 +0100)]
maintainer-scripts: Speed up git clone in gcc_release
When doing the 8.4-rc1, I've noticed (probably also because of the dying
disk on sourceware) that git clone is extremely slow, and furthermore when
all of us have some local snapshots, it is a waste of resources to download
everything again. Especially for the -f runs when we'll need to wait until
git tag -s asks us for a gpg password interactively.
The following patch adds an option through which one can point the script
at a local gcc .git directory from which it can --dissociate --reference ...
during cloning to speed it up.
2020-02-27 Jakub Jelinek <jakub@redhat.com>
* gcc_release: Add support for -b local-git-repo argument.
Jakub Jelinek [Tue, 3 Mar 2020 09:42:34 +0000 (10:42 +0100)]
explow: Fix ICE caused by plus_constant [PR94002]
The following testcase ICEs in cross to riscv64-linux. The problem is
that we have a DImode integral constant (that doesn't fit into SImode),
which is pushed into a constant pool and later access just the first half of
it using a MEM. When plus_constant is called on such a MEM, if the constant
has mode, we verify the mode, but if it doesn't, we don't and ICE later on
when we think the CONST_INT is a valid SImode constant.
2020-03-03 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/94002
* explow.c (plus_constant): Punt if cst has VOIDmode and
get_pool_mode is different from mode.
Jason Merrill [Mon, 2 Mar 2020 19:42:47 +0000 (14:42 -0500)]
c++: Fix ({ ... }) array mem-initializer.
Here, we were going down the wrong path in perform_member_init because of
the incorrect parens around the mem-initializer for the array. And then
cxx_eval_vec_init_1 didn't know what to do with a CONSTRUCTOR as the
initializer. For GCC 9, let's just fix the latter issue.
gcc/cp/ChangeLog
2020-03-02 Jason Merrill <jason@redhat.com>
Jason Merrill [Mon, 2 Mar 2020 19:42:47 +0000 (14:42 -0500)]
c++: Allow parm of empty class type in constexpr.
Since copying a class object is defined in terms of the copy constructor,
copying an empty class is OK even if it would otherwise not be usable in a
constant expression. Relatedly, using a parameter as an lvalue is no more
problematic than a local variable, and calling a member function uses the
object as an lvalue.
gcc/cp/ChangeLog
2020-03-02 Jason Merrill <jason@redhat.com>
PR c++/91953
* constexpr.c (potential_constant_expression_1) [PARM_DECL]: Allow
empty class type.
[COMPONENT_REF]: A member function reference doesn't use the object
as an rvalue.
Jason Merrill [Mon, 2 Mar 2020 19:42:47 +0000 (14:42 -0500)]
c++: Fix cast to pointer to VLA.
The C front-end fixed this issue in r257620 by adding a DECL_EXPR from
grokdeclarator. We don't have an easy way to do that in the C++ front-end,
but it works fine to create and prepend a DECL_EXPR when we are genericizing
the NOP_EXPR for the cast.
The C patch wraps the DECL_EXPR in a BIND_EXPR, but that seems unnecessary
in C++; this is just a hook to run gimplify_type_sizes, we aren't actually
declaring anything that we need to worry about scoping for.
gcc/cp/ChangeLog
2020-03-02 Jason Merrill <jason@redhat.com>
PR c++/88256
* cp-gimplify.c (predeclare_vla): New.
(cp_genericize_r) [NOP_EXPR]: Call it.
Jason Merrill [Mon, 2 Mar 2020 19:42:47 +0000 (14:42 -0500)]
checking: avoid verify_type_variant crash on incomplete type.
Here, we end up calling gen_type_die_with_usage for a type that's in the
middle of finish_struct_1, after we set TYPE_NEEDS_CONSTRUCTING on it but
before we copy all the flags to the variants--and, significantly, before we
set its TYPE_SIZE. It seems reasonable to only look at
TYPE_NEEDS_CONSTRUCTING on complete types, since we aren't going to try to
create an object of an incomplete type any other way.
gcc/ChangeLog
2020-03-02 Jason Merrill <jason@redhat.com>
PR c++/92601
* tree.c (verify_type_variant): Only verify TYPE_NEEDS_CONSTRUCTING
of complete types.
Jason Merrill [Mon, 2 Mar 2020 19:42:47 +0000 (14:42 -0500)]
c++: Fix return deduction of lambda in discarded stmt.
A return statement in a discarded statement is not used for return type
deduction, but we still want to do deduction for a return statement in a
lambda in a discarded statement.
gcc/cp/ChangeLog
2020-03-02 Jason Merrill <jason@redhat.com>
Jason Merrill [Mon, 2 Mar 2020 19:42:47 +0000 (14:42 -0500)]
PR c++/90732 - ICE with VLA capture and generic lambda.
We were failing to handle VLA capture in tsubst_lambda_expr; initially
building a DECLTYPE_TYPE for the capture and then tsubsting it doesn't give
the special VLA handling. So with this patch we call add_capture again for
VLAs.
gcc/cp/ChangeLog
2020-03-02 Jason Merrill <jason@redhat.com>
PR c++/90732 - ICE with VLA capture and generic lambda.
* pt.c (tsubst_lambda_expr): Repeat add_capture for VLAs.
Jason Merrill [Mon, 2 Mar 2020 19:42:47 +0000 (14:42 -0500)]
c++: Fix attributes with lambda and trailing return type.
My fix for 60503 fixed handling of C++11 attributes following the
lambda-declarator. My patch for 89640 re-added support for GNU attributes,
but attributes after the trailing return type were parsed as applying to the
return type rather than to the function. This patch adjusts parsing of a
trailing-return-type to ignore GNU attributes at the end of the declaration
so that they will be applied to the declaration as a whole.
I also considered parsing the attributes between the closing paren and the
trailing-return-type, and tried a variety of approaches to implementing
that, but I think it's better to stick with the documented rule that "An
attribute specifier list may appear immediately before the comma, '=' or
semicolon terminating the declaration of an identifier...." Anyone
disagree?
Meanwhile, C++ committee discussion about the lack of any way to apply
attributes to a lambda op() seems to have concluded that they should go
between the introducer and declarator, so I've implemented that as well.
gcc/cp/ChangeLog
2020-03-02 Jason Merrill <jason@redhat.com>
PR c++/90333
PR c++/89640
PR c++/60503
* parser.c (cp_parser_type_specifier_seq): Don't parse attributes in
a trailing return type.
(cp_parser_lambda_declarator_opt): Parse C++11 attributes before
parens.
Jakub Jelinek [Thu, 27 Feb 2020 09:45:30 +0000 (10:45 +0100)]
gimplify: Don't optimize register const vars to static [PR93949]
The following testcase is rejected, while it was accepted in 3.4 and earlier
(before tree-ssa merge).
The problem is that we decide to promote the const variable to TREE_STATIC,
but TREE_STATIC DECL_REGISTER VAR_DECLs may only be the global register vars
and so assemble_variable/make_decl_rtl diagnoses it.
Either we do what the following patch does, where we could consider
register as a hint the user doesn't want such optimization, because if
something is forced static, it is not "register" anymore and register static
is not valid in C either, or we could clear DECL_REGISTER instead, but would
still need to punt at least on DECL_HARD_REGISTER cases.
projects / thirdparty / gcc.git / log
