On Wed, Sep 25, 2019 at 10:06:13PM -0600, Jeff Law wrote:
> (insn 13 12 14 2 (set (reg:SI 124)
> (const_int -939524096 [0xc800])) "j.c":10:54 161
> {*arm_movsi_insn}
> (nil))
>
> (insn 14 13 16 2 (parallel [
> (set (reg:SI 132)
> (plus:SI (mult:
On Wed, 25 Sep 2019, Prathamesh Kulkarni wrote:
> On Fri, 20 Sep 2019 at 15:20, Jeff Law wrote:
> >
> > On 9/19/19 10:19 AM, Prathamesh Kulkarni wrote:
> > > Hi,
> > > For PR91532, the dead store is trivially deleted if we place dse pass
> > > between ifcvt and vect. Would it be OK to add another
Hi!
I wasn't aware of this new build_clobber function added last year,
apparently we have still tons of spots that build clobbers by hand and using
build_clobber will make it clear what we are actually building.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2019-09-26 Jak
On Wed, 25 Sep 2019, Eric Botcazou wrote:
> > For the PR it would be good enough. Though I wonder what the original reason
> > for the mode handling was. Was it to avoid not naturally aligned modes for
> > strict align targets? Or modes for non-mode size entities?
>
> Bit-field extraction ultimat
Hi Segher,
On 26.09.19 00:49, Segher Boessenkool wrote:
On Wed, Sep 25, 2019 at 10:46:57PM +0200, Andreas Tobler wrote:
--- gcc/config/rs6000/t-freebsd64 (revision 276090)
+++ gcc/config/rs6000/t-freebsd64 (working copy)
@@ -27,3 +27,6 @@
MULTILIB_EXCEPTIONS =
MULTILIB_OSDI
Thanks Martin,
On 2019/9/25 18:57, Martin Liška wrote:
On 9/25/19 5:45 AM, luoxhu wrote:
Hi,
Sorry for replying so late due to cauldron conference and other LTO issues
I was working on.
Hello.
That's fine, we still have plenty of time for patch review.
Not fixed issues which I reported in
> commit fa761b10d40aaa71e62fbc0c9f2ab8fc07a98b49 (HEAD, refs/bisect/bad)
> Author: wilco
> Date: Wed Sep 18 18:33:30 2019 +
>
> [ARM] Cleanup 64-bit multiplies
>
> Cleanup 64-bit multiplies. Combine the expanders using iterators.
> Merge the signed/unsigned multiplies as
On Sep 13, 2019, Richard Biener wrote:
> On Fri, Sep 13, 2019 at 1:32 AM Alexandre Oliva wrote:
>> On Sep 12, 2019, Richard Biener wrote:
>> > So - maybe we can have the patch a bit cleaner by adding
>> > a flag to add_type_attribute saying we only want it if it's
>> > different from that alre
On Sep 10, 2019, Alexandre Oliva wrote:
> This patchset fixes some latent problems in cmpstrn* patterns for x86,
> and introduces cmpmemsi for short fixed-size memcmp.
Ping? https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00701.html
> Would it make sense to install the test program somewhere?
On Wed, 25 Sep 2019 at 09:33, Richard Biener wrote:
>
> On Tue, 24 Sep 2019, Christophe Lyon wrote:
>
> > On Wed, 18 Sep 2019 at 20:11, Richard Biener wrote:
> > >
> > >
> > > It shouldn't be neccessary.
> > >
> > > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
> > > (SLP
On Wed, Sep 25, 2019 at 8:01 PM Christian Biesinger
wrote:
> On Mon, Sep 23, 2019 at 3:15 PM Jason Merrill wrote:
> > On Mon, Sep 23, 2019 at 3:52 PM Christian Biesinger via gcc-patches
> > wrote:
> > >
> > > From: Christian Biesinger
> > >
> > > Removes an unused include as a cleanup. Requires
On Mon, Sep 23, 2019 at 3:15 PM Jason Merrill wrote:
>
> On Mon, Sep 23, 2019 at 3:52 PM Christian Biesinger via gcc-patches
> wrote:
> >
> > From: Christian Biesinger
> >
> > Removes an unused include as a cleanup. Requires updating
> > lots of files who previously relied on this transitive inc
On Sat, Sep 21, 2019 at 7:41 AM Richard Biener
wrote:
>
> On September 21, 2019 12:28:57 PM GMT+02:00, Christian Biesinger
> wrote:
> >On Sat, Sep 21, 2019 at 7:22 PM Richard Biener
> > wrote:
> >>
> >> On September 21, 2019 11:12:38 AM GMT+02:00, Christian Biesinger via
> >gcc-patches wrote:
>
On Tue, 24 Sep 2019, Palmer Dabbelt wrote:
> The documentation used to indicate that the inline keyword was only
> supported by c99 and c11, whereas in fact it is supported by c99 and all
> newer standards.
>
> gcc/ChangeLog
>
> 2019-09-24 Palmer Dabbelt
>
> * doc/extended.texi (Alte
On Tue, 24 Sep 2019, Eric Botcazou wrote:
> > I think this has to depend on the C standards version. I think each C
> > standard needs to be read against the edition of ISO 10646 current at
> > the time of standards approval (the references are sadly not
> > versioned, so the version is implied).
On Tue, 24 Sep 2019, Eric Botcazou wrote:
> Hi,
>
> the Universal Character Names accepted by the C family of compilers are
> mapped
> to those of ISO/IEC 10646, which defines the Universal Character Set
> codespace
> as the range 0-0x10 inclusive. The upper bound is already enforced for
On Tue, 24 Sep 2019, Florian Weimer wrote:
> I think this has to depend on the C standards version. I think each C
> standard needs to be read against the edition of ISO 10646 current at
> the time of standards approval (the references are sadly not
> versioned, so the version is implied). Early
On 9/25/19 3:54 PM, Joseph Myers wrote:
> On Fri, 20 Sep 2019, Richard Henderson wrote:
>
>> Tested on aarch64-linux (glibc) and aarch64-elf (installed newlib).
>>
>> The existing configure claims to be generated by 2.69, but there
>> are changes wrt the autoconf distributed with Ubuntu 18. Nothi
On 9/25/19 3:54 PM, Joseph Myers wrote:
> On Fri, 20 Sep 2019, Richard Henderson wrote:
>
>> Tested on aarch64-linux (glibc) and aarch64-elf (installed newlib).
>>
>> The existing configure claims to be generated by 2.69, but there
>> are changes wrt the autoconf distributed with Ubuntu 18. Nothi
On Fri, 20 Sep 2019, Richard Henderson wrote:
> Tested on aarch64-linux (glibc) and aarch64-elf (installed newlib).
>
> The existing configure claims to be generated by 2.69, but there
> are changes wrt the autoconf distributed with Ubuntu 18. Nothing
> that seems untoward though.
They're meant
Hi!
On Wed, Sep 25, 2019 at 10:46:57PM +0200, Andreas Tobler wrote:
> --- gcc/config/rs6000/t-freebsd64 (revision 276090)
> +++ gcc/config/rs6000/t-freebsd64 (working copy)
> @@ -27,3 +27,6 @@
> MULTILIB_EXCEPTIONS =
> MULTILIB_OSDIRNAMES = ../lib32
>
> +SECURE_PLT = $(if $(findst
On Mon, Sep 23, 2019 at 10:45:29AM +0100, Richard Sandiford wrote:
> The PLUS handling in aarch64_rtx_costs only checked for nonnegative
> constants, meaning that simple immediate subtractions like:
>
> (set (reg R1) (plus (reg R2) (const_int -8)))
>
> had a cost of two instructions.
>
> Teste
On Tue, Sep 24, 2019 at 02:40:20PM +0100, Kyrill Tkachov wrote:
> Hi all,
>
> On 8/22/19 10:16 AM, Kyrill Tkachov wrote:
> > Hi all,
> >
> > The optimisation to optimise:
> > typedef unsigned long long u64;
> >
> > void bar(u64 *x)
> > {
> > *x = 0xabcdef10abcdef10;
> > }
> >
> >
Respect the `--enable-version-specific-runtime-libs' configuration
option in libada/, so that shared gnatlib libraries will be installed
in non-version-specific $(toolexeclibdir) if requested. In a
cross-compilation environment this helps setting up a consistent
sysroot, which can then be shar
For some reason, presumably historical, the `install-gnatlib' target for
the default multilib is invoked twice, once via the `ada.install-common'
target in `gcc/ada/gcc-interface/Make-lang.in' invoked from gcc/ and
again via the `install-libada' target in libada/.
Apart from doing the same twic
On Wed, Aug 07, 2019 at 08:28:50PM +0100, Richard Sandiford wrote:
> It was easier to add the SVE ACLE support without enumerating every
> function at build time. This in turn meant that it was easier if the
> SVE builtins occupied a distinct numberspace from the existing AArch64
> ones, which *ar
Hi,
Here's a mini patch series that addresses a couple of long-standing
installation issues observed with libada. These have been verified by
bootstrapping GCC with an `x86_64-linux-gnu' native configuration and
using that compiler to build a `riscv-linux-gnu' cross-compiler, in both
cases w
Hi all,
the attached patch makes use of the secure-plt for 32-bit PowerPC on
FreeBSD 13 and upwards. The OS support will arrive in FreeBSD 13.0
I'd like to commit this patch to head and later to all open branches.
Comments appreciated!
If I do not get any, I'll commit in a few days.
TIA,
An
Some more tests have revealed a small problem in is_sorted test. It was
revealed by the Debug mode but not in a clean ways so for the moment I
prefer to fix it and I'll add a _neg test when Debug is able to report
it correctly.
I've also added a _neg test for equal which doesn't need Debug mo
Hello world,
this patch makes sure that the __def_init variables, which have been
generated for normal allocatable arrays for quite some time, do not fill
up huge amounts of space in the object files with zeros. This is done by
not marking them read-only, which means that they are put into the BS
On Wed, Sep 25, 2019 at 5:48 PM Richard Sandiford
wrote:
>
> Ping
>
> Richard Sandiford writes:
> > One of the effects of the function_abi series is to make -fipa-ra
> > work for partially call-clobbered registers. E.g. if a call preserves
> > only the low 32 bits of a register R, we handled the
The main change here is in the treatment of $...$ escapes.
I've relaxed the treatment of unknown escapes, during
unescaping, to continue processing the input string,
leaving the remainder of current path segment as-is.
Relatedly, rust_is_mangled function doesn't check escapes
at all anymore (as unk
[This follows on from:
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01466.html]
The AArch64 SVE tlsdesc patterns were the main motivating reason
for clobber_high. It's no longer needed now that the patterns use
calls instead.
At the time, one of the possible future uses for clobber_high was fo
> For the PR it would be good enough. Though I wonder what the original reason
> for the mode handling was. Was it to avoid not naturally aligned modes for
> strict align targets? Or modes for non-mode size entities?
Bit-field extraction ultimately required integer modes before vector modes
came
[This follows on from:
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00778.html
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01456.html
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01464.html]
One (unintended) side effect of the patches to support multiple
ABIs is that we can now represent tl
On 2019-09-19 11:33, Martin Liška wrote:
Hi.
Function reordering has been around for quite some time and a naive
implementation was also part of my diploma thesis some time ago.
Currently, the GCC can reorder function based on first execution, which
happens with PGO and LTO of course. Known limi
[This follows on from:
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00778.html
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01456.html]
At the moment we rely on SYMBOL_REF_DECL to get the ABI of the callee
of a call insn, falling back to the default ABI if the decl isn't
available. I think it
Hi David,
does this look sane?
Yes.
OK for trunk, and thanks a lot!
Regards
Thomas
On Wed, Sep 25, 2019 at 04:52:14PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Thu, Sep 12, 2019 at 08:51:59AM +0100, Richard Sandiford wrote:
> >> Segher Boessenkool writes:
> >> > It is not such a great name like that. Since its children are
> >> > very_long_names, it d
[This follows on from:
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00778.html
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01456.html]
This patch makes more use of the function_abi infrastructure.
We can then avoid checking specifically for the vector PCS in
a few places, and can test it more
[This follows on from:
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00778.html
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01456.html]
With the function ABI stuff, we can now support shrink-wrapping of
non-leaf vector PCS functions. This is particularly useful if the
vector PCS function call
ping
On Wed, 11 Sep 2019 11:25:58 +0100
Jozef Lawrynowicz wrote:
> The MSP430 target has a "430X" extension which increases the directly
> addressable memory range from 64KB (16-bit) to 1MB (20-bit).
> This 1MB memory range is split into a "lower" region (below address 0x1)
> and "upper" reg
On Fri, 20 Sep 2019 at 15:20, Jeff Law wrote:
>
> On 9/19/19 10:19 AM, Prathamesh Kulkarni wrote:
> > Hi,
> > For PR91532, the dead store is trivially deleted if we place dse pass
> > between ifcvt and vect. Would it be OK to add another instance of dse there
> > ?
> > Or should we add an ad-hoc
On Thu, 19 Sep 2019 at 10:30, Richard Biener wrote:
>
> On Thu, 19 Sep 2019, Prathamesh Kulkarni wrote:
>
> > Hi,
> > For PR91532, the dead store is trivially deleted if we place dse pass
> > between ifcvt and vect. Would it be OK to add another instance of dse there
> > ?
> > Or should we add an
[This follows on from:
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00778.html]
If we support multiple ABIs in the same translation unit, it can
sometimes be the case that a callee clobbers more registers than
its caller is allowed to. We need to call df_set_regs_ever_live
on these extra regist
On Mon, 16 Sep 2019 at 08:54, Prathamesh Kulkarni
wrote:
>
> On Mon, 9 Sep 2019 at 09:36, Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 9 Sep 2019 at 16:45, Richard Sandiford
> > wrote:
> > >
> > > Prathamesh Kulkarni writes:
> > > > With patch, the only following FAIL remains for aarch64-sve.ex
Richard Sandiford writes:
> This is another case in which we should conservatively treat
> partial kills as full kills.
Similary to the combine patch, I've updated this to avoid the
short "abi" name and use a temporary HARD_REG_SET instead.
Richard
2019-09-25 Richard Sandiford
gcc/
Richard Sandiford writes:
> This is another case in which we can conservatively treat partial
> kills as full kills. Again this is in principle a bug fix for
> TARGET_HARD_REGNO_CALL_PART_CLOBBERED targets, but in practice
> it probably doesn't make a difference.
Similary to the combine patch, I
On September 25, 2019 5:29:55 PM GMT+02:00, Eric Botcazou
wrote:
>> The following patch relaxes the condition under which we force
>> VOIDmode by making all non-integral types where the extraction
>> size matches the type size (thus isn't "bitfieldish") use the
>> mode of the extraction type.
>
>
Richard Sandiford writes:
> Like with the combine.c patch, this one keeps things simple by
> invalidating values in partially-clobbered registers, rather than
> trying to tell whether the value in a partially-clobbered register
> is actually clobbered or not. Again, this is in principle a bug fix
Segher Boessenkool writes:
> Hi Richard,
>
> Sorry this too me so long to get back to.
>
> On Thu, Sep 12, 2019 at 08:51:59AM +0100, Richard Sandiford wrote:
>> Segher Boessenkool writes:
>> > On Wed, Sep 11, 2019 at 08:08:38PM +0100, Richard Sandiford wrote:
>> >>hard_reg_set_iterator hr
Ping
Richard Sandiford writes:
> One of the effects of the function_abi series is to make -fipa-ra
> work for partially call-clobbered registers. E.g. if a call preserves
> only the low 32 bits of a register R, we handled the partial clobber
> separately from -fipa-ra, and so treated the upper b
Richard Sandiford writes:
> This patch replaces get_call_reg_set_usage with call_insn_abi,
> which returns the ABI of the target of a call insn. The ABI's
> full_reg_clobbers corresponds to regs_invalidated_by_call,
> whereas many callers instead passed call_used_or_fixed_regs, i.e.:
>
> (regs_
> The following patch relaxes the condition under which we force
> VOIDmode by making all non-integral types where the extraction
> size matches the type size (thus isn't "bitfieldish") use the
> mode of the extraction type.
Wouldn't TREE_CODE (TREE_TYPE (exp)) == VECTOR_TYPE be sufficient? At le
Hi,
it was brought to my attention that my call to internal_error in the new
IPA-SRA makes -Wformat-diag complain because it thinks that everything
with an underscore is an identifier or a keyword and should be quoted.
Well, the string should not contain "IPA_SRA" but "IPA-SRA" in the first
place
Hi,
PR 91853 and its duplicate PR 91894 show that IPA-SRA can stumble when
presented with code with mismatched types, whether because it is a K&R C
or happening through an originally indirect call (or probably also
because of LTO).
The problem is that we try to work with a register value - in thi
On 8/22/19 4:53 PM, Kyrill Tkachov wrote:
Hi all,
We currently have a nasty error when trying to use the __crc*
intrinsics with an -mfloat-abi=hard.
That is because the target pragma guarding them uses armv8-a+crc that
does not include fp by default.
So we get errors like:
error: '-mfloat-a
Hi,
On Tue, Sep 24 2019, Martin Jambor wrote:
>
>
> It is the correct thing to do, sorry for the breakage. I have to run
> now but will prepare a patch tomorrow.
>
and here it is. The patch fixes the thinko explained in my email
yesterday - basically the test for locally_unused was intended for
Hi,
Martin and his clang warnings discovered that I forgot to remove a
static inline function and a variable when ripping out the old IPA-SRA
from tree-sra.c and both are now unused. Thus I am doing that now
with the patch below which I will commit as obvious (after including
it in a round of a b
BIT_FIELD_REFs can extract almost any kind of type but specifically
is used to extract vector elements (that very special case is handled)
but also sub-vectors (missing). RTL expansion of stores relies
on an appropriate mode to use vector stores it seems.
The following patch relaxes the conditi
Hi all,
On 2/6/19 1:52 PM, Kyrill Tkachov wrote:
[resending with patch compressed]
Hi all,
We're somewhat inconsistent in arm_neon.h when it comes to using the
implementation namespace for local
identifiers. This means things like:
#define hash_abcd 0
#define hash_e 1
#define wk 2
#include
On 9/24/19 3:34 PM, Marek Polacek wrote:
On Tue, Sep 24, 2019 at 09:07:03PM +0200, Paolo Carlini wrote:
Hi,
Marek's recent fix prompted an audit of name-lookup.c and I found a few
additional straightforward places where we should use a more accurate
location. Tested x86_64-linux.
Thanks, Paolo
Hi all,
On 9/3/19 9:35 AM, Shaokun Zhang wrote:
The DCache clean & ICache invalidation requirements for instructions
to be data coherence are discoverable through new fields in CTR_EL0.
Let's support the two bits if they are enabled, the CPU core will
not execute the unnecessary DCache clean or
* include/bits/regex.h
(basic_regex::assign(const C*, size_t, flag_type)): Add default
argument (LWG 3296).
* testsuite/28_regex/basic_regex/assign/char/lwg3296.cc: New test.
* testsuite/28_regex/basic_regex/assign/wchar_t/lwg3296.cc: New test.
Tested x86_6
On 9/24/19 7:47 PM, Matt Turner wrote:
When -march=native is passed to host_detect_local_cpu to the backend,
it overrides all command lines after it. That means
$ gcc -march=native -march=armv8-a
is treated as
$ gcc -march=armv8-a -march=native
Prune joined switches with Negative and Rejec
On 9/25/19 5:45 AM, luoxhu wrote:
> Hi,
>
> Sorry for replying so late due to cauldron conference and other LTO issues
> I was working on.
Hello.
That's fine, we still have plenty of time for patch review.
Not fixed issues which I reported in v3 (and still valid in v4):
- please come up with in
Removing operand swapping for reduction vectorization has enabled
more pattern recognition which in turn triggers a latent bug
in reduction vectorization.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2019-09-25 Richard Biener
PR tree-optimization/91896
Hi all,
This patch implements some more SIMD32, but these ones have a DImode
result+addend.
Apart from that there's nothing too exciting about them.
Bootstrapped and tested on arm-none-linux-gnueabihf.
Will commit to trunk within the next day or two.
Thanks,
Kyrill
2019-09-25 Kyrylo Tkacho
Hi all,
This patch is part of a series to implement the SIMD32 ACLE intrinsics [1].
The interesting parts implementation-wise involve adding support for
setting and reading
the Q bit for saturation and the GE-bits for the packed SIMD instructions.
That will come in a later patch.
For now, this
On 9/24/19 5:57 PM, Jeff Law wrote:
> Sure, and IMHO moving tests like this should be something that can be
> done without explicit ACKs.
Ok, next time I'll not ask for a confirmation ;)
Thanks,
Martin
>
> jeff
Hi.
Similarly to SLP pass, we should probably set TODO_update_ssa
when a SLP BB vectorization happens from the normal vect pass.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-09-25 Martin Liska
PR tr
On Tue, 24 Sep 2019, Christophe Lyon wrote:
> On Wed, 18 Sep 2019 at 20:11, Richard Biener wrote:
> >
> >
> > It shouldn't be neccessary.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
> > (SLP part testing separately)
> >
> > Richard.
> >
> > 2019-09-18 Richard B
From: "Dragan Mladjenovic"
This fixes the issue by checking that addr's base reg is not part of dest
multiword reg instead just checking the first reg of dest.
gcc/ChangeLog:
2019-09-25 Dragan Mladjenovic
PR target/91769
* config/mips/mips.c (mips_split_move): Use reg_overla
73 matches
Mail list logo
