From: Matt Thomas
Fix an ICE with the handling of RTL expressions like:
(subreg:QI (mem/c:SI (plus:SI (plus:SI (mult:SI (reg/v:SI 0 %r0 [orig:67 i ]
[67])
(const_int 4 [0x4]))
(reg/v/f:SI 7 %r7 [orig:59 doacross ] [59]))
(const_int 40 [0x28])) [1
The `c' operand format specifier is handled directly by the middle end
in `output_asm_insn':
%cN means require operand N to be a constant
and print the constant expression with no punctuation.
however it resorts to the target for constants that are not valid
addresses:
else
The VAX ELF psABI does not permit the use of all hardware operand modes
for PIC symbol references due to the need to use PC-relative addressing
for symbols that end up local and the need to make references indirect
symbols that end up global.
Therefore symbols referred as immediates may only be us
It makes sense to use what other targets do and run all the VAX test
cases over all the usual optimization levels, so make `vax.exp' use our
`gcc-dg-runtest' rather than the generic `dg-runtest' test driver.
This breaks `pr56875.c' however, which is optimized away at levels above
`-O0' as a result
Expression costs are required to be given in terms of COSTS_N_INSNS (n),
which is defined to stand for the count of single fast instructions, and
actually returns `n * 4'. The VAX backend however instead operates on
naked numbers, causing an anomaly for the integer const zero rtx, where
the cost g
The `builtins.md' machine description fragment is not included anywhere
and is therefore dead code, which has become bitrotten due to non-use.
If actually enabled, it does not build due to the use of an unknown `t'
constraint:
.../gcc/config/vax/builtins.md:42:1: error: undefined machine-specific
Add wide integer aka 'w' rtx format support to int iterators so that
machine description can iterate over `const_int' expressions.
This is made by expanding standard integer aka 'i' format support,
observing that any standard integer already present in any of our
existing RTL code will also fit in
VAX has interlocked branch instructions used for atomic operations and
we want to have them wrapped in UNSPEC_VOLATILE so as not to have code
carried across. This however breaks with jump optimization and leads
to an ICE in the build of libbacktrace like:
.../libbacktrace/mmap.c:190:1: internal c
Regardless of the machine mode all the interlocked branches of the same
kind, one of the two provided by the ISA, use the same RTL patterns and
machine instructions, except for the memory operand's constraint.
Remove code duplication then and make use of a mode iterator combined
with an attribute
With mode-specific interlocked branch insns already folded into iterated
templates now fold the two templates into one too, observing that the
only difference between them is the value of the bit branched on, which
is of course reflected both in the RTL expression and the instruction
produced. Use
Remove an ICE like:
during RTL pass: expand
.../libatomic/tas_n.c: In function 'libat_test_and_set_1':
.../libatomic/tas_n.c:39:1: internal compiler error: in patch_jump_insn, at
cfgrtl.c:1298
39 | }
| ^
0x108a09ff patch_jump_insn
.../gcc/cfgrtl.c:1298
0x108a0b07 redirect_branch_
Test cases will follow.
gcc/
* config/vax/vax.md: Include `builtins.md'.
---
gcc/config/vax/vax.md | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/config/vax/vax.md b/gcc/config/vax/vax.md
index e6b217fd0d7..66f03df1932 100644
--- a/gcc/config/vax/vax.md
+++ b/gcc/config
gcc/testsuite/
* gcc.target/vax/ffssi.c: New test.
---
gcc/testsuite/gcc.target/vax/ffssi.c | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/vax/ffssi.c
diff --git a/gcc/testsuite/gcc.target/vax/ffssi.c
b/gcc/testsuite/gcc.ta
Based on gcc.dg/pr61756.c.
gcc/testsuite/
* gcc.target/vax/bbcci.c: New test.
* gcc.target/vax/bbssi.c: New test.
---
gcc/testsuite/gcc.target/vax/bbcci.c | 20
gcc/testsuite/gcc.target/vax/bbssi.c | 20
2 files changed, 40 inserti
Our `ffssi2_internal' pattern and the machine FFS instruction, which
technically is a bitfield operation, match the `ctz' operation exactly,
with the result produced for the bitfield source operand of zero equal
to its width as specified with another machine instruction operand, not
directly expres
The FFS machine instruction provides for arbitrary input bitfield widths
so take advantage of this and convert `ffssi2' and `ctzsi2' to templates
for all the three of QI, HI, SI machine modes.
Test cases will be added separately.
gcc/
* config/vax/builtins.md (width): New mode att
The middle end does not refer to `ctzqi2'/`ctzhi2' or `ffsqi2'/`ffshi2'
patterns by name where `__builtin_ctz' or `__builtin_ffs' respectively
is invoked for an argument of the QImode or HImode type, and instead it
extends the data type before passing it to `ctzsi2' or `ffssi2'.
Avoid the redundan
gcc/testsuite/
* gcc.target/vax/cpymem.c: New test.
---
gcc/testsuite/gcc.target/vax/cpymem.c | 23 +++
1 file changed, 23 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/vax/cpymem.c
diff --git a/gcc/testsuite/gcc.target/vax/cpymem.c
b/gcc/testsuit
The MOVC3 machine instruction has `memmove' semantics[1]:
"The operation of the instruction is such that overlap of the source and
destination strings does not affect the result."
so use it to provide the `movmemhi' instruction as well.
References:
[1] DEC STD 032-0 "VAX Architecture Standard",
It makes no sense for insn operand predicates, as long as they accept a
register operand, to be more restrictive than the set of the associated
constraints, because expand will choose the insn based on the relevant
operand being a pseudo register then and reload keep it happily as a
memory referenc
The INSV machine instruction is the only computational operation in the
VAX ISA that keeps condition codes intact. In preparation to MODE_CC
transition keep patterns apart then that make or do not make use of said
instruction. For consistency update EXTV and EXTZV instruction uses
accordingly. I
With the `*insv_aligned', `*extzv_aligned' and `*extv_aligned' insns we
are going to adjust the bitfield location if it is in memory, so only
allow such location addresses that can be offset, excluding external
symbol references in the PIC mode in particular.
This fixes an ICE like:
during RTL pa
We have matching insns defined for `sign_extract' and `zero_extract'
expressions, so make the three named patterns for bitfield operations
consistent and make `extv' an expander rather than an insn taking a
SImode, a QImode, and a SImode general operand for the LOC, SIZE, and
POS operands respectiv
It makes no sense for insn operand predicates, as long as they accept a
register operand, to be more restrictive than the set of the associated
constraints, because expand will choose the insn based on the relevant
operand being a pseudo register then and reload keep it happily as a
memory referenc
It makes no sense for insn operand predicates, as long as they accept a
register operand, to be more restrictive than the set of the associated
constraints, because expand will choose the insn based on the relevant
operand being a pseudo register then and reload will keep it happily as
an immediate
Correct issues with commented-out insns, which fail to build if enabled:
.../gcc/config/vax/vax.md:503:1: repeated operand number 1
.../gcc/config/vax/vax.md:503:1: repeated operand number 2
and then when the issue with the repeated operands has been corrected:
.../gcc/config/vax/vax.md:107:1: d
Use a double colon to introduce the comments like elsewhere throughout
the VAX machine description.
gcc/
* config/vax/vax.md (divmoddisi4, *amulsi4): Make the comment
notation consistent with the rest of the file.
---
gcc/config/vax/vax.md | 38 +++-
The use of a constant double zero is required for post-reload compare
elimination to be able to discard redundant floating-point comparisons,
for example with a VAX RTL instruction stream like:
(insn 34 4 3 2 (parallel [
(set (reg/v:DF 0 %r0 [orig:24 x ] [24])
(mem/c:DF
We do not define a comparison operation between floating-point and
integer data, including integer zero constant. Consequently the RTL
instruction stream presented to the post-reload comparison elimination
pass will include, where applicable, floating-point comparison insns
against `const_double:D
In the VAX ISA INSV bitfield insert instruction is the only computational
operation that keeps the condition codes, held in the PSL or Processor
Status Longword register, intact. The instruction is flexible enough it
could potentially be used for data moves post-reload, but then reportedly
it is n
Hi,
[Paul, there's a PDP11 piece for you further down here and then 29/31.]
This is the much-desired refurbishment of the VAX backend. A little bit
past the end of Stage 1, which I apologise for and which I do hope is not
going to make it a no-no for GCC 11. I feel quite satisfied anyway I
On Linux/x86_64,
d0d8b5d83614d8f0d0e40c0520d4f40ffa01f8d9 is the first bad commit
commit d0d8b5d83614d8f0d0e40c0520d4f40ffa01f8d9
Author: Andrew MacLeod
Date: Thu Nov 19 17:41:30 2020 -0500
Process only valid shift ranges.
caused
FAIL: gcc.dg/pr97515.c scan-tree-dump-times evrp "goto" 1
From: Aaron Sawdey
Segher & Bergner -
Thanks for the reviews, here's the updated patch after fixing those things.
We now have an UNSPEC for xxsetaccz, and an accompanying change to
rs6000_rtx_costs to make it be cost 0 so that CSE doesn't try to replace it
with a bunch of register moves.
If bo
Here is what I am testing.
I use your enum proposal as an alias for the bool type. I cannot use it
as template parameter on _M_copy unless I put it at std namespace level
to use it in definition of the outline _M_copy overload.
I also added some tests checking correct usage of
__move_if_noex
On Fri, Nov 20, 2020 at 12:30 AM Eric Botcazou wrote:
>
> > Successfully bootstrapped/regtested on x86_64-linux and i686-linux,
> > including make install which looked problematic in PR97911.
> >
> > Ok for trunk?
>
> I cannot really approve, but this looks like a step in the right direction.
OK.
Hello,
Okay, I proposed this check to upstream [1] and it has already been
accepted. We can either apply the fix or postpone it until next sync with
upstream.
Anyway the bug doesn't seem so bad if we were the only team who faced it during
all this time.
Best Regards,
Vyacheslav Barinov
[1]: htt
On 11/20/20 8:44 AM, Vyacheslav Barinov wrote:
Hello,
Okay, I proposed this check to upstream [1] and it has already been
accepted.
Hello.
Great. Please commit it to the llvm-project upstream and I'll make then
the patch cherry-pick.
We can either apply the fix or postpone it until next syn
On Fri, Nov 20, 2020 at 12:58 AM Segher Boessenkool
wrote:
>
> On Thu, Nov 19, 2020 at 03:30:37PM -0700, Jeff Law wrote:
> > > No, the vast majority of people will *not* (consciously) use them,
> > > because the target defaults will set things to useful values.
> > >
> > > The compiler could use s
Morning Maciej,
Then there is a fix for the PDP11 backend addressing an issue I found in
the handling of floating-point comparisons. Unlike all the other changes
this one has not been regression-tested, not even built as I have no idea
how to prepare a development environment for a PDP11 targe
101 - 139 of 139 matches
Mail list logo
