Jakub Jelinek [Sat, 8 Feb 2020 09:59:40 +0000 (10:59 +0100)]
i386: Make xmm16-xmm31 call used even in ms ABI [PR65782]
On Tue, Feb 04, 2020 at 11:16:06AM +0100, Uros Bizjak wrote:
> I guess that Comment #9 patch form the PR should be trivially correct,
> but althouhg it looks obvious, I don't want to propose the patch since
> I have no means of testing it.
I don't have means of testing it either.
https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019
is quite explicit that [xyz]mm16-31 are call clobbered and only xmm6-15 (low
128-bits only) are call preserved.
We are talking e.g. about
/* { dg-options "-O2 -mabi=ms -mavx512vl" } */
typedef double V __attribute__((vector_size (16)));
void foo (void);
V bar (void);
void baz (V);
void
qux (void)
{
V c;
{
register V a __asm ("xmm18");
V b = bar ();
asm ("" : "=x" (a) : "0" (b));
c = a;
}
foo ();
{
register V d __asm ("xmm18");
V e;
d = c;
asm ("" : "=x" (e) : "0" (d));
baz (e);
}
}
where according to the MSDN doc gcc incorrectly holds the c value
in xmm18 register across the foo call; if foo is compiled by some Microsoft
compiler (or LLVM), then it could clobber %xmm18.
If all xmm18 occurrences are changed to say xmm15, then it is valid to hold
the 128-bit value across the foo call (though, surprisingly, LLVM saves it
into stack anyway).
The other parts are I guess mainly about SEH. Consider e.g.
void
foo (void)
{
register double x __asm ("xmm14");
register double y __asm ("xmm18");
asm ("" : "=x" (x));
asm ("" : "=v" (y));
x += y;
y += x;
asm ("" : : "x" (x));
asm ("" : : "v" (y));
}
looking at cross-compiler output, with -O2 -mavx512f this emits
.file "abcdeq.c"
.text
.align 16
.globl foo
.def foo; .scl 2; .type 32; .endef
.seh_proc foo
foo:
subq $40, %rsp
.seh_stackalloc 40
vmovaps %xmm14, (%rsp)
.seh_savexmm %xmm14, 0
vmovaps %xmm18, 16(%rsp)
.seh_savexmm %xmm18, 16
.seh_endprologue
vaddsd %xmm18, %xmm14, %xmm14
vaddsd %xmm18, %xmm14, %xmm18
vmovaps (%rsp), %xmm14
vmovaps 16(%rsp), %xmm18
addq $40, %rsp
ret
.seh_endproc
.ident "GCC: (GNU) 10.0.1 20200207 (experimental)"
Does whatever assembler mingw64 uses even assemble this (I mean the
.seh_savexmm %xmm16, 16 could be problematic)?
I can find e.g.
https://stackoverflow.com/questions/43152633/invalid-register-for-seh-savexmm-in-cygwin/43210527
which then links to
https://gcc.gnu.org/PR65782
2020-02-08 Uroš Bizjak <ubizjak@gmail.com>
Jakub Jelinek <jakub@redhat.com>
PR target/65782
* config/i386/i386.h (CALL_USED_REGISTERS): Make
xmm16-xmm31 call-used even in 64-bit ms-abi.
Jakub Jelinek [Thu, 6 Feb 2020 08:19:08 +0000 (09:19 +0100)]
openmp: Fix handling of non-addressable shared scalars in parallel nested inside of target [PR93515]
As the following testcase shows, we need to consider even target to be a construct
that forces not to use copy in/out for shared on parallel inside of the target.
E.g. for parallel nested inside another parallel or host teams, we already avoid
copy in/out and we need to treat target the same.
2020-02-06 Jakub Jelinek <jakub@redhat.com>
PR libgomp/93515
* omp-low.c (use_pointer_for_field): For nested constructs, also
look for map clauses on target construct.
(scan_omp_1_stmt) <case GIMPLE_OMP_TARGET>: Bump temporarily
taskreg_nesting_level.
* testsuite/libgomp.c-c++-common/pr93515.c: New test.
Jakub Jelinek [Thu, 6 Feb 2020 08:15:13 +0000 (09:15 +0100)]
openmp: Notice reduction decl in outer contexts after adding it to shared [PR93515]
If we call omp_add_variable, following omp_notice_variable will already find it
on that construct and not go through outer constructs, the following patch fixes that.
Note, this still doesn't follow OpenMP 5.0 semantics on target combined with other
constructs with reduction/lastprivate/linear clauses, will handle that for GCC11.
2020-02-06 Jakub Jelinek <jakub@redhat.com>
PR libgomp/93515
* gimplify.c (gimplify_scan_omp_clauses) <do_notice>: If adding
shared clause, call omp_notice_variable on outer context if any.
Jakub Jelinek [Wed, 5 Feb 2020 22:35:08 +0000 (23:35 +0100)]
c++: Mark __builtin_convertvector operand as read [PR93557]
In C++ we weren't calling mark_exp_read on the __builtin_convertvector first
argument. I guess it could misbehave even with lambda implicit captures.
Fixed by calling decay_conversion on the argument, we use the argument as
rvalue so we want the standard lvalue to rvalue conversions, but as the
argument must be a vector type, e.g. integral promotions aren't really
needed.
2020-02-05 Jakub Jelinek <jakub@redhat.com>
PR c++/93557
* semantics.c (cp_build_vec_convert): Call decay_conversion on arg
prior to passing it to c_build_vec_convert.
Jakub Jelinek [Wed, 5 Feb 2020 10:32:37 +0000 (11:32 +0100)]
openmp: Avoid ICEs with declare simd; declare simd inbranch [PR93555]
The testcases ICE because when processing the declare simd inbranch,
we don't create the i == 0 clone as it already exists, which means
clone_info->nargs is not adjusted, but we then rely on it being adjusted
when trying other clones.
2020-02-05 Jakub Jelinek <jakub@redhat.com>
PR middle-end/93555
* omp-simd-clone.c (expand_simd_clones): If simd_clone_mangle or
simd_clone_create failed when i == 0, adjust clone->nargs by
clone->inbranch.
* c-c++-common/gomp/pr93555-1.c: New test.
* c-c++-common/gomp/pr93555-2.c: New test.
* gfortran.dg/gomp/pr93555.f90: New test.
Jakub Jelinek [Thu, 30 Jan 2020 20:28:17 +0000 (21:28 +0100)]
combine: Punt on out of range rotate counts [PR93505]
What happens on this testcase is with the out of bounds rotate we get:
Trying 13 -> 16:
13: r129:SI=r132:DI#0<-<0x20
REG_DEAD r132:DI
16: r123:DI=r129:SI<0
REG_DEAD r129:SI
Successfully matched this instruction:
(set (reg/v:DI 123 [ <retval> ])
(const_int 0 [0]))
during combine. So, perhaps we could also change simplify-rtx.c to punt
if it is out of bounds rather than trying to optimize anything.
Or, but probably GCC11 material, if we decide that ROTATE/ROTATERT doesn't
have out of bounds counts or introduce targetm.rotate_truncation_mask,
we should truncate the argument instead of punting.
Punting is better for backports though.
2020-01-30 Jakub Jelinek <jakub@redhat.com>
PR middle-end/93505
* combine.c (simplify_comparison) <case ROTATE>: Punt on out of range
rotate counts.
Jakub Jelinek [Wed, 29 Jan 2020 08:41:42 +0000 (09:41 +0100)]
openmp: c++: Consider typeinfo decls to be predetermined shared [PR91118]
If the typeinfo decls appear in OpenMP default(none) regions, as we no longer
predetermine const with no mutable members, they are diagnosed as errors,
but it isn't something the users can actually provide explicit sharing for in
the clauses.
2020-01-29 Jakub Jelinek <jakub@redhat.com>
PR c++/91118
* cp-gimplify.c (cxx_omp_predetermined_sharing): Return
OMP_CLAUSE_DEFAULT_SHARED for typeinfo decls.
* g++.dg/gomp/pr91118-1.C: New test.
* g++.dg/gomp/pr91118-2.C: New test.
The following testcase is miscompiled, because the variable shift left
operand, { -1, -1, -1, -1 } is represented as a VECTOR_CST with
VECTOR_CST_NPATTERNS 1 and VECTOR_CST_NELTS_PER_PATTERN 1, so when
we call builder.new_unary_operation, builder.encoded_nelts () will be just 1
and thus we encode the resulting vector as if all the elements were the
same.
For non-masked is_vshift, we could perhaps call builder.new_binary_operation
(TREE_TYPE (args[0]), args[0], args[1], false), but then there are masked
shifts, for non-is_vshift we could perhaps call it too but with args[2]
instead of args[1], but there is no builder.new_ternary_operation.
All this stuff is primarily for aarch64 anyway, on x86 we don't have any
variable length vectors, and it is not a big deal to compute all elements
and just let builder.finalize () find the most efficient VECTOR_CST
representation of the vector. So, instead of doing too much, this just
keeps using new_unary_operation only if only one VECTOR_CST is involved
(i.e. non-masked shift by constant) and for the rest just compute all elts.
2020-01-28 Jakub Jelinek <jakub@redhat.com>
PR target/93418
* config/i386/i386.c (ix86_fold_builtin) <do_shift>: If mask is not
-1 or is_vshift is true, use new_vector with number of elts npatterns
rather than new_unary_operation.
Jakub Jelinek [Thu, 23 Jan 2020 19:08:22 +0000 (20:08 +0100)]
postreload: Fix up postreload combine [PR93402]
The following testcase is miscompiled, because the postreload pass changes:
-(insn 14 13 23 2 (parallel [
- (set (reg:DI 1 dx [94])
- (plus:DI (reg:DI 1 dx [95])
- (reg:DI 5 di [92])))
- (clobber (reg:CC 17 flags))
- ]) "pr93402.c":8:30 186 {*adddi_1}
- (expr_list:REG_EQUAL (plus:DI (reg:DI 5 di [92])
- (const_int 111111111111 [0x19debd01c7]))
- (nil)))
-(insn 23 14 25 2 (set (reg:SI 0 ax)
+(insn 23 13 25 2 (set (reg:SI 0 ax)
(const_int 0 [0])) "pr93402.c":10:1 67 {*movsi_internal}
(nil))
(insn 25 23 26 2 (use (reg:SI 0 ax)) "pr93402.c":10:1 -1
(nil))
-(insn 26 25 35 2 (use (reg:DI 1 dx)) "pr93402.c":10:1 -1
+(insn 26 25 35 2 (use (plus:DI (reg:DI 1 dx [95])
+ (reg:DI 5 di [92]))) "pr93402.c":10:1 -1
(nil))
A USE insn is not a normal insn and verify_changes called from
apply_change_group is happy about any changes into it.
The following patch avoids this optimization if we were to change
the USE operand (this routine only changes a reg into (plus reg reg2)).
2020-01-23 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/93402
* postreload.c (reload_combine_recognize_pattern): Don't try to adjust
USE insns.
This fixes a fall-out from a patch I had submitted two years ago which started
allowing simplify-rtx to fold logical right shifts by offsets a followed by b
into >> (a + b).
However this can generate inefficient code when the resulting shift count ends
up being the same as the size of the shift mode. This will create some
undefined behavior on most platforms.
This patch changes to code to truncate to 0 if the shift amount goes out of
range. Before my older patch this used to happen in combine when it saw the
two shifts. However since we combine them here combine never gets a chance to
truncate them.
The issue mostly affects GCC 8 and 9 since on 10 the back-end knows how to deal
with this shift constant but it's better to do the right thing in simplify-rtx.
Note that this doesn't take care of the Arithmetic shift where you could replace
the constant with MODE_BITS (mode) - 1, but that's not a regression so punting it.
gcc/ChangeLog:
Backport from mainline
2020-01-31 Tamar Christina <tamar.christina@arm.com>
PR rtl-optimization/91838
* simplify-rtx.c (simplify_binary_operation_1): Update LSHIFTRT case
to truncate if allowed or reject combination.
gcc/testsuite/ChangeLog:
Backport from mainline
2020-01-31 Tamar Christina <tamar.christina@arm.com>
Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/91838
* g++.dg/opt/pr91838.C: New test.
H.J. Lu [Mon, 10 Feb 2020 15:58:45 +0000 (07:58 -0800)]
i386: Properly pop restore token in signal frame
Linux CET kernel places a restore token on shadow stack for signal
handler to enhance security. The restore token is 8 byte and aligned
to 8 bytes. It is usually transparent to user programs since kernel
will pop the restore token when signal handler returns. But when an
exception is thrown from a signal handler, now we need to pop the
restore token from shadow stack. For x86-64, we just need to treat
the signal frame as normal frame. For i386, we need to search for
the restore token to check if the original shadow stack is 8 byte
aligned. If the original shadow stack is 8 byte aligned, we just
need to pop 2 slots, one restore token, from shadow stack. Otherwise,
we need to pop 3 slots, one restore token + 4 byte padding, from
shadow stack.
This patch also includes 2 tests, one has a restore token with 4 byte
padding and one without.
Tested on Linux/x86-64 CET machine with and without -m32.
libgcc/
Backport from mainline
PR libgcc/85334
* config/i386/shadow-stack-unwind.h (_Unwind_Frames_Increment):
New.
gcc/testsuite/
Backport from mainline
PR libgcc/85334
* g++.target/i386/pr85334-1.C: New test.
* g++.target/i386/pr85334-2.C: Likewise.
Backport from mainline
PR target/85667
* config/i386/i386.c (function_arg_ms_64): Add a type argument.
Don't return aggregates with only SFmode and DFmode in SSE
register.
(ix86_function_arg): Pass type to function_arg_ms_64.
gcc/testsuite/
Backport from mainline
PR target/85667
* gcc.target/i386/pr85667-10.c: New test.
* gcc.target/i386/pr85667-7.c: Likewise.
* gcc.target/i386/pr85667-8.c: Likewise.
* gcc.target/i386/pr85667-9.c: Likewise.
Jason Merrill [Wed, 29 Jan 2020 22:16:12 +0000 (17:16 -0500)]
c++: Drop alignas restriction for stack variables.
Since expand_stack_vars and such know how to deal with variables aligned
beyond MAX_SUPPORTED_STACK_ALIGNMENT, we shouldn't reject alignas of large
alignments. And if we don't do that, there's no point in having
check_cxx_fundamental_alignment_constraints at all, since
check_user_alignment already enforces MAX_OFILE_ALIGNMENT.
Szabolcs Nagy [Wed, 15 Jan 2020 12:23:40 +0000 (12:23 +0000)]
[AArch64] PR92424: Fix -fpatchable-function-entry=N,M with BTI
This is a workaround that emits a BTI after the function label if that
is followed by a patch area. We try to remove the BTI that follows the
patch area (this may fail e.g. if the first instruction is a PACIASP).
So before this commit -fpatchable-function-entry=3,1 with bti generates
.section __patchable_function_entries
.8byte .LPFE
.text
.LPFE:
nop
foo:
nop
nop
bti c // or paciasp
...
and after this commit
.section __patchable_function_entries
.8byte .LPFE
.text
.LPFE:
nop
foo:
bti c
nop
nop
// may be paciasp
...
and with -fpatchable-function-entry=1 (M=0) the code now is
foo:
bti c
.section __patchable_function_entries
.8byte .LPFE
.text
.LPFE:
nop
// may be paciasp
...
There is a new bti insn in the middle of the patchable area users need
to be aware of unless M=0 (patch area is after the new bti) or M=N
(patch area is before the label, no new bti). Note: bti is not added to
all functions consistently (it can be turned off per function using a
target attribute or the compiler may detect that the function is never
called indirectly), so if bti is inserted in the middle of a patch area
then user code needs to deal with detecting it.
Tested on aarch64-none-linux-gnu.
gcc/ChangeLog:
PR target/92424
* config/aarch64/aarch64.c (aarch64_declare_function_name): Set
cfun->machine->label_is_assembled.
(aarch64_print_patchable_function_entry): New.
(TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY): Define.
* config/aarch64/aarch64.h (struct machine_function): New field,
label_is_assembled.
gcc/testsuite/ChangeLog:
PR target/92424
* gcc.target/aarch64/pr92424-2.c: New test.
* gcc.target/aarch64/pr92424-3.c: New test.
Jason Merrill [Tue, 28 Jan 2020 17:26:10 +0000 (12:26 -0500)]
c++: Allow template rvalue-ref conv to bind to lvalue ref.
When I implemented the [over.match.ref] rule that a reference conversion
function needs to match l/rvalue of the target reference type it changed our
handling of this testcase. It seems to me that our current behavior is what
the standard says, but it doesn't seem desirable, and all the other
compilers have our old behavior. So let's limit the change to non-templates
until there's some clarification from the committee.
PR c++/90546
* call.c (build_user_type_conversion_1): Allow a template conversion
returning an rvalue reference to bind directly to an lvalue.
Jason Merrill [Mon, 27 Jan 2020 03:19:47 +0000 (22:19 -0500)]
c++: Fix array of char typedef in template (PR90966).
Since Martin Sebor's patch for PR 71625 to change braced array initializers
to STRING_CST in some cases, we need to be ready for STRING_CST with types
that are changed by tsubst. fold_convert doesn't know how to deal with
STRING_CST, which is reasonable; we really shouldn't expect it to here. So
let's handle STRING_CST separately.
PR c++/90966
* pt.c (tsubst_copy) [STRING_CST]: Don't use fold_convert.
Jason Merrill [Fri, 24 Jan 2020 23:20:56 +0000 (18:20 -0500)]
c++: Fix ICE with lambda in member operator (PR93279)
Here the problem was that we were remembering the lookup in template scope,
and then trying to reuse that lookup in the instantiation without
substituting into it at all. The simplest solution is to not try to
remember a lookup that finds a class-scope declaration, as in that case
doing the normal lookup again at instantiation time will always find the
right declarations.
PR c++/93279 - ICE with lambda in member operator.
* name-lookup.c (maybe_save_operator_binding): Don't remember
class-scope bindings.
Nathan Sidwell [Mon, 27 Jan 2020 13:49:43 +0000 (05:49 -0800)]
c++: Bogus error using namespace alias [PR91826]
My changes to is_nested_namespace broke is_ancestor's use where a namespace
alias might be passed in. This changes is_ancestor to look through the alias.
PR c++/91826
* name-lookup.c (is_ancestor): Allow CHILD to be a namespace alias.
Wilco Dijkstra [Fri, 17 Jan 2020 13:17:21 +0000 (13:17 +0000)]
[AArch64] Fix shrinkwrapping interactions with atomics (PR92692)
The separate shrinkwrapping pass may insert stores in the middle
of atomics loops which can cause issues on some implementations.
Avoid this by delaying splitting atomics patterns until after
prolog/epilog generation.
gcc/
PR target/92692
* config/aarch64/aarch64.c (aarch64_split_compare_and_swap)
Add assert to ensure prolog has been emitted.
(aarch64_split_atomic_op): Likewise.
* config/aarch64/atomics.md (aarch64_compare_and_swap<mode>)
Use epilogue_completed rather than reload_completed.
(aarch64_atomic_exchange<mode>): Likewise.
(aarch64_atomic_<atomic_optab><mode>): Likewise.
(atomic_nand<mode>): Likewise.
(aarch64_atomic_fetch_<atomic_optab><mode>): Likewise.
(atomic_fetch_nand<mode>): Likewise.
(aarch64_atomic_<atomic_optab>_fetch<mode>): Likewise.
(atomic_nand_fetch<mode>): Likewise.
Jonathan Wakely [Fri, 24 Jan 2020 11:13:55 +0000 (11:13 +0000)]
libstdc++: Simplify makefile rule for largefile-config.h (PR91947)
The previous rule could leave an incomplete file if the build was
interrupted, which would then not be remade if make was run again.
This makes the rule more robust by writing to a temporary file and only
moving it into place as the final step. It also simplifies the rule so
that only the essential macro definitions are written to the file, not
the explanatory comments and commented out #undef lines.
Also, the macro for enabling LFS on Mac OS X 10.5 is now set
unconditionally, which is a bug fix from upstream autoconf.
Backport from mainline
2020-01-23 Jonathan Wakely <jwakely@redhat.com>
The two patterns that call aarch64_expand_subvti ensure that {low,high}_in1
is a register, while {low,high}_in2 can be a register or immediate.
subdi3_compare1_imm uses the aarch64_plus_immediate predicate for its last
two operands (the value and negated value), but aarch64_expand_subvti calls
it whenever low_in2 is a CONST_INT, which leads to ICEs during vregs pass,
as the emitted insn is not recognized as valid subdi3_compare1_imm.
The following patch fixes that by only using subdi3_compare1_imm if it is ok
to do so, and otherwise force the constant into register and use the
non-immediate version - subdi3_compare1.
Furthermore, previously the code was calling force_reg on high_in2 only if
low_in2 is CONST_INT, on the (reasonable) assumption is that only if low_in2
is a CONST_INT, high_in2 can be non-REG, but with the above changes even in
the else we might have CONST_INT and force_reg doesn't do anything if the
operand is already a REG, so this patch calls it unconditionally.
2020-01-22 Jakub Jelinek <jakub@redhat.com>
PR target/93335
* config/aarch64/aarch64.c (aarch64_expand_subvti): Only use
gen_subdi3_compare1_imm if low_in2 satisfies aarch64_plus_immediate
predicate, not whenever it is CONST_INT. Otherwise, force_reg it.
Call force_reg on high_in2 unconditionally.
Jakub Jelinek [Wed, 22 Jan 2020 17:07:54 +0000 (18:07 +0100)]
i386: Fix up -fdollars-in-identifiers with identifiers starting with $ in -masm=att [PR91298]
In AT&T syntax leading $ is special, so if we have identifiers that start
with dollar, we usually fail to assemble it (or assemble incorrectly).
As mentioned in the PR, what works is wrapping the identifiers inside of
parens, like:
movl $($a), %eax
leaq ($a)(,%rdi,4), %rax
movl ($a)(%rip), %eax
movl ($a)+16(%rip), %eax
.globl $a
.type $a, @object
.size $a, 72
$a:
.string "$a"
.quad ($a)
(this is x86_64 -fno-pic -O2). In some places ($a) is not accepted,
like as .globl operand, in .type, .size, so the patch overrides
ASM_OUTPUT_SYMBOL_REF rather than e.g. ASM_OUTPUT_LABELREF.
I didn't want to duplicate what assemble_name is doing (following
transparent aliases), so split assemble_name into two parts; just
mere looking at the first character of a name before calling assemble_name
wouldn't be good enough, a transparent alias could lead from a name
not starting with $ to one starting with it and vice versa.
2020-01-22 Jakub Jelinek <jakub@redhat.com>
PR target/91298
* output.h (assemble_name_resolve): Declare.
* varasm.c (assemble_name_resolve): New function.
(assemble_name): Use it.
* config/i386/i386.h (ASM_OUTPUT_SYMBOL_REF): Define.
* gcc.target/i386/pr91298-1.c: New test.
* gcc.target/i386/pr91298-2.c: New test.
Jakub Jelinek [Wed, 22 Jan 2020 17:05:49 +0000 (18:05 +0100)]
openmp: Teach omp_code_to_statement about rest of OpenMP statements
The omp_code_to_statement function added with the initial OpenACC support
only handled small subset of the OpenMP statements, leading to ICE if
any other OpenMP directive appeared inside of OpenACC directive.
Jakub Jelinek [Wed, 22 Jan 2020 16:55:23 +0000 (17:55 +0100)]
riscv: Fix up riscv_rtx_costs for RTL checking (PR target/93333)
As mentioned in the PR, during combine rtx_costs can be called sometimes
even on RTL that has not been validated yet and so can contain even operands
that aren't valid in any instruction.
2020-01-21 Jakub Jelinek <jakub@redhat.com>
PR target/93333
* config/riscv/riscv.c (riscv_rtx_costs) <case ZERO_EXTRACT>: Verify
the last two operands are CONST_INT_P before using them as such.
Jakub Jelinek [Wed, 22 Jan 2020 16:54:32 +0000 (17:54 +0100)]
powerpc: Fix ICE with fp conditional move (PR target/93073)
The following testcase ICEs, because for TFmode the particular subtraction
pattern (*subtf3) is not enabled with the given options. Using
expand_simple_binop instead of emitting the subtraction by hand just moves
the ICE one insn later, NEG of ABS is not then recognized, etc., but
ultimately the problem is that when rs6000_emit_cmove is called for floating
point operand mode (and earlier condition ensures that in that case
compare_mode is also floating point), the expander makes sure the
operand mode is SFDF, but for the comparison mode nothing checks it, yet
there is just one *fsel* pattern with 2 separate SFDF iterators.
The following patch fixes it by giving up if compare_mode is not SFmode or
DFmode.
2020-01-21 Jakub Jelinek <jakub@redhat.com>
PR target/93073
* config/rs6000/rs6000.c (rs6000_emit_cmove): If using fsel, punt for
compare_mode other than SFmode or DFmode.
Jakub Jelinek [Wed, 22 Jan 2020 16:52:11 +0000 (17:52 +0100)]
c++: Fix deprecated attribute handling on templates (PR c++/93228)
As the following testcase shows, when deprecated attribute is on a template,
we'd never print the message if any, because the attribute is not
present on the TEMPLATE_DECL with which warn_deprecated_use is called,
but on its DECL_TEMPLATE_RESULT or its type.
2020-01-17 Jakub Jelinek <jakub@redhat.com>
PR c++/93228
* parser.c (cp_parser_template_name): Look up deprecated attribute
in DECL_TEMPLATE_RESULT or its type's attributes.
Jakub Jelinek [Wed, 22 Jan 2020 16:51:14 +0000 (17:51 +0100)]
i386: Fix wrong-code x86 issue with avx512{f,vl} fma PR93009
As mentioned in the PR, the following testcase is miscompiled with avx512vl.
The reason is that the fma *_bcst_1 define_insns have two alternatives:
"=v,v" "0,v" "v,0" "m,m" and use the same
vfmadd213* %3<avx512bcst>, %2, %0<sd_mask_op4>
pattern. If the first alternative is chosen, everything is ok, but if the
second alternative is chosen, %2 and %0 are the same register, so instead
of doing dest=dest*another+membcst we do dest=dest*dest+membcst.
Now, to fix this, either we'd need separate:
"vfmadd213<ssemodesuffix>\t{%3<avx512bcst>, %2, %0<sd_mask_op4>|%0<sd_mask_op4>, %2, %3<avx512bcst>}
vfmadd213<ssemodesuffix>\t{%3<avx512bcst>, %1, %0<sd_mask_op4>|%0<sd_mask_op4>, %1, %3<avx512bcst>}"
where for the second alternative, we'd just use %1 instead of %2, but
what I think is actually cleaner is just use a single alternative and
make the two multiplication operands commutative, which they really are.
2020-01-15 Jakub Jelinek <jakub@redhat.com>
PR target/93009
* config/i386/sse.md
(*<sd_mask_codefor>fma_fmadd_<mode><sd_maskz_name>_bcst_1,
*<sd_mask_codefor>fma_fmsub_<mode><sd_maskz_name>_bcst_1,
*<sd_mask_codefor>fma_fnmadd_<mode><sd_maskz_name>_bcst_1,
*<sd_mask_codefor>fma_fnmsub_<mode><sd_maskz_name>_bcst_1): Use
just a single alternative instead of two, make operands 1 and 2
commutative.
Jakub Jelinek [Wed, 22 Jan 2020 16:50:14 +0000 (17:50 +0100)]
re PR libgomp/93219 (unused return value in affinity-fmt.c)
PR libgomp/93219
* libgomp.h (gomp_print_string): Change return type from void to int.
* affinity-fmt.c (gomp_print_string): Likewise. Return true if
not all characters have been written.
Jakub Jelinek [Wed, 22 Jan 2020 16:48:48 +0000 (17:48 +0100)]
re PR rtl-optimization/93088 (Compile time hog on gcc/testsuite/gcc.target/i386/pr56348.c w/ -O3 -funroll-loops -fno-tree-dominator-opts -fno-tree-vrp)
PR rtl-optimization/93088
* loop-iv.c (find_single_def_src): Punt after looking through
128 reg copies for regs with single definitions. Move definitions
to first uses.
Jakub Jelinek [Wed, 22 Jan 2020 16:42:02 +0000 (17:42 +0100)]
re PR c++/92438 (Function declaration parsed incorrectly with `-std=c++1z`)
PR c++/92438
* parser.c (cp_parser_constructor_declarator_p): If open paren
is followed by RID_ATTRIBUTE, skip over the attribute tokens and
try to parse type specifier.
Joseph Myers [Wed, 22 Jan 2020 17:26:10 +0000 (17:26 +0000)]
Fix ICE with cast of division by zero (PR c/93348).
Bug 93348 reports an ICE on certain cases of casts of expressions that
may appear only in unevaluated parts of integer constant expressions,
arising from the generation of nested C_MAYBE_CONST_EXPRs. This patch
fixes it by adding a call to remove_c_maybe_const_expr in the
integer-operands case, as is done in other similar cases.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
PR c/93348
gcc/c:
* c-typeck.c (build_c_cast): Call remove_c_maybe_const_expr on
argument with integer operands.
gcc/testsuite:
* gcc.c-torture/compile/pr93348-1.c: New test.
Richard Biener [Tue, 14 Jan 2020 07:43:32 +0000 (08:43 +0100)]
PR middle-end/93246 - missing alias subsets
Starting with the introduction of TYPE_TYPELESS_STORAGE the situation
of having a alias-set zero aggregate field became more common which
prevents recording alias-sets of fields of said aggregate as subset
of the outer aggregate. component_uses_parent_alias_set_from in the
past fended off some of the issues with that but the alias oracles
use of the alias set of the base of an access path never appropriately
handled it.
The following makes it so that alias-sets of fields of alias-set zero
aggregate fields are still recorded as subset of the container.
2020-01-14 Richard Biener <rguenther@suse.de>
PR middle-end/93246
* alias.c (record_component_aliases): Take superset to record
into, recurse for alias-set zero fields.
(record_component_aliases): New oveerload wrapping around the above.
Eric S. Raymond [Mon, 20 Jan 2020 02:10:52 +0000 (18:10 -0800)]
Clean up references to Subversion in documentation sources.
Clean up references to SVN in in the GCC docs, redirecting to Git
documentation as appropriate.
Where references to "the source code repository" rather than a
specific VCS make sense, I have used them. You might, after
all, change VCSes again someday.
I have not modified either generated HTML files nor maintainer scripts.
These changes should be complete with repect to the documentation tree.
2020-01-19 Eric S. Raymond <esr@thyrsus.com>
Sandra Loosemore <sandra@codesourcery.com>
Jason Merrill [Fri, 17 Jan 2020 13:37:49 +0000 (08:37 -0500)]
PR c++/92531 - ICE with noexcept(lambda).
This was failing because uses_template_parms didn't recognize LAMBDA_EXPR as
a kind of expression. Instead of trying to enumerate all the different
varieties of expression and then aborting if what's left isn't
error_mark_node, let's handle error_mark_node and then assume anything else
is an expression.
* pt.c (uses_template_parms): Don't try to enumerate all the
expression cases.
Jason Merrill [Thu, 16 Jan 2020 21:55:39 +0000 (16:55 -0500)]
PR c++/93286 - ICE with __is_constructible and variadic template.
Here we had been recursing in tsubst_copy_and_build if type2 was a TREE_LIST
because that function knew how to deal with pack expansions, and tsubst
didn't. But tsubst_copy_and_build expects to be dealing with expressions,
so we crash when trying to convert_from_reference a type.
* pt.c (tsubst) [TREE_LIST]: Handle pack expansion.
(tsubst_copy_and_build) [TRAIT_EXPR]: Always use tsubst for type2.
Mark Eggleston [Fri, 17 Jan 2020 09:44:23 +0000 (09:44 +0000)]
Fortran: PR93263 -fno-automatic and RECURSIVE
The use of -fno-automatic should not affect the save attribute of a
recursive procedure. The first test case checks unsaved variables
and the second checks saved variables.
Joseph Myers [Wed, 15 Jan 2020 20:52:45 +0000 (20:52 +0000)]
Fix setting of DECL_CONTEXT in pushdecl (PR c/93072).
Bug 93072 is a case where the C front end (a) wrongly interprets an
inline declaration at block scope as indicating that DECL_CONTEXT
should be set for an inline function and (b) this results in an ICE.
This is a regression resulting from a previous fix of mine for other
bugs involving such declarations being wrongly interpreted elsewhere
as nested function declarations. The fix is similar to the previous
fix: use TREE_PUBLIC instead of DECL_EXTERNAL in another place as the
relevant test to determine whether to set DECL_CONTEXT. (When a
variable reaches the code in question in pushdecl, the two are
equivalent.)
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
PR c/93072
gcc/c:
* c-decl.c (pushdecl): Use TREE_PUBLIC, not DECL_EXTERNAL, to
determine whether to set DECL_CONTEXT.
gcc/testsuite:
* gcc.dg/inline-42.c, gcc.dg/inline-43.c: New tests.
PR target/93254
* config/i386/i386.md (*movsf_internal): Require SSE2 ISA for
alternatives 9 and 10. Do not require SSE2 ISA for alternatives
14 and 15.
Joseph Myers [Tue, 14 Jan 2020 00:13:21 +0000 (00:13 +0000)]
Fix handling of overflow in C casts in integer constant expressions (PR c/93241).
Bug 93241 reports a case where certain C expressions involving casts,
that would not be valid in an evaluated part of an integer constant
expression (because of e.g. involving integer overflow), are wrongly
rejected in an unevaluated part of an integer constant expression even
though all the operands and operations are ones that are valid in that
context. This is a rejects-valid regression in GCC 4.5 and later
relative to 4.4 (for some testcases; the one in the bug uses
_Static_assert which isn't supported in those older releases).
The rule in the C front end is that an expression with those
properties (valid in an unevaluated part of an integer constant
expression but not an evaluated part) must be represented either as an
INTEGER_CST with TREE_OVERFLOW set or as a C_MAYBE_CONST_EXPR with
C_MAYBE_CONST_EXPR_INT_OPERANDS set. This patch fixes build_c_cast to
check for that case and call note_integer_operands as needed.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
PR c/93241
gcc/c:
* c-typeck.c (build_c_cast): Check for expressions with integer
operands that can occur in an unevaluated part of an integer
constant expression and call note_integer_operands as needed.
gcc/testsuite:
* gcc.dg/c11-static-assert-10.c, gcc.dg/c99-const-expr-15.c: New
tests.
Jonathan Wakely [Thu, 9 Jan 2020 13:38:43 +0000 (13:38 +0000)]
Build filesystem library with large file support
Enable AC_SYS_LARGEFILE to set the macros needed for large file APIs to
be used by default. We do not want to define those macros in the
public headers that users include. The values of the macros are copied
to a separate file that is only included by the filesystem sources
during the build, and then the macros in <bits/c++config.h> are renamed
so that they don't have any effect in user code including our headers.
Also use larger type for result of filesystem::file_size to avoid
truncation of large values on 32-bit systems (PR 91947).
Backport from mainlne
2019-10-04 Jonathan Wakely <jwakely@redhat.com>
PR libstdc++/81091
PR libstdc++/91947
* configure.ac: Use AC_SYS_LARGEFILE to enable 64-bit file APIs.
* config.h.in: Regenerate:
* configure: Regenerate:
* include/Makefile.am (${host_builddir}/largefile-config.h): New
target to generate config header for filesystem library.
(${host_builddir}/c++config.h): Rename macros for large file support.
* include/Makefile.in: Regenerate.
* src/c++17/fs_dir.cc: Include new config header.
* src/c++17/fs_ops.cc: Likewise.
(filesystem::file_size): Use uintmax_t for size.
* src/filesystem/dir.cc: Include new config header.
* src/filesystem/ops.cc: Likewise.
(experimental::filesystem::file_size): Use uintmax_t for size.
Joseph Myers [Mon, 13 Jan 2020 18:45:04 +0000 (18:45 +0000)]
Fix libdecnumber handling of non-canonical BID significands (PR middle-end/91226).
As reported in bug 91226, the libdecnumber code used on the host to
interpret DFP values in the BID encoding fails, for _Decimal64 and
_Decimal128, to check for the case where a significand is too large
and so specified in IEEE 754 to be a non-canonical encoding of the
zero significand. This patch adds the required handling of that case,
together with tests both using -O2 (testing this host code) and -O0
(testing libgcc code, which already worked before the patch); the
tests also cover _Decimal32, which already had the required check.
In the _Decimal128 case, where the code previously completely ignored
the case where the first four bits of the combination field are 1100,
1101 or 1110, the logic for determining the correct quantum exponent
in that case is also newly added by this patch, so tests are added for
that as well (again, libgcc already handled it correctly when the
conversion was done at runtime rather than at compile time).
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
PR middle-end/91226
libdecnumber:
* bid/bid2dpd_dpd2bid.c (_bid_to_dpd64): Handle non-canonical
significands.
(_bid_to_dpd128): Likewise. Check for case where combination
field starts 1100, 1101 or 1110.
backport: arm: Fix rmprofile multilibs when architecture includes +mp or +sec (PR target/93188)
When only the rmprofile multilibs are built, compiling for armv7-a
should select the generic v7 multilibs. This used to work before +sec
and +mp were added to the architecture options but it was broken by
that update. This patch fixes those variants and adds some tests to
ensure that they remain fixed
Backport from trunk
PR target/93188
* config/arm/t-multilib (MULTILIB_MATCHES): Add rules to match
armv7-a{+mp,+sec,+mp+sec} to appropriate armv7 multilib variants
when only building rm-profile multilibs.
projects / thirdparty / gcc.git / log
