Hi Christophe,
>> The warning is off by default so there is no need to do anything in the
>> testsuite,
>> you just need a fixed binutils.
>>
>
> Don't we want to fix GCC to stop generating the offending sequence?
Why? All ARMv8 implementations have to support it, and despite the warning
code a
On Fri, 6 Dec 2019 at 19:47, Wilco Dijkstra wrote:
>
> Hi Christophe,
>
> > In practice, how do you activate it when running the GCC testsuite? Do
> > you plan to send a GCC patch to enable this assembler flag, or do you
> > locally enable that option by default in your binutils?
>
> The warning i
Hi Christophe,
> In practice, how do you activate it when running the GCC testsuite? Do
> you plan to send a GCC patch to enable this assembler flag, or do you
> locally enable that option by default in your binutils?
The warning is off by default so there is no need to do anything in the
testsu
On Fri, 6 Dec 2019 at 16:03, Wilco Dijkstra wrote:
>
> Hi Christophe,
>
> I've added an option to allow the warning to be enabled/disabled:
> https://sourceware.org/ml/binutils/2019-12/msg00093.html
>
Thanks.
In practice, how do you activate it when running the GCC testsuite? Do
you plan to send
Hi Christophe,
I've added an option to allow the warning to be enabled/disabled:
https://sourceware.org/ml/binutils/2019-12/msg00093.html
Cheers,
Wilco
On Fri, 6 Dec 2019 at 11:47, Wilco Dijkstra wrote:
>
> Hi Christophe,
>
> > This patch (r278968) is causing regressions when building GCC
> > --target arm-none-linux-gnueabihf
> > --with-mode thumb
> > --with-cpu cortex-a57
> > --with-fpu crypto-neon-fp-armv8
> > because the assembler (gas version
Hi Christophe,
> This patch (r278968) is causing regressions when building GCC
> --target arm-none-linux-gnueabihf
> --with-mode thumb
> --with-cpu cortex-a57
> --with-fpu crypto-neon-fp-armv8
> because the assembler (gas version 2.33.1) complains:
> /ccc7z5eW.s:4267: IT blocks containing more tha
On Tue, 3 Dec 2019 at 14:45, Wilco Dijkstra wrote:
>
> Hi,
>
> Part 2, split off from
> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00399.html
>
> To enable cores to use the correct max_cond_insns setting, use the
> core-specific
> tuning when a CPU/tune is selected unless -mrestrict-it is exp
On 12/3/19 1:45 PM, Wilco Dijkstra wrote:
Hi,
Part 2, split off from
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00399.html
To enable cores to use the correct max_cond_insns setting, use the
core-specific
tuning when a CPU/tune is selected unless -mrestrict-it is explicitly set.
On Cor
Hi,
Part 2, split off from https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00399.html
To enable cores to use the correct max_cond_insns setting, use the core-specific
tuning when a CPU/tune is selected unless -mrestrict-it is explicitly set.
On Cortex-A57 this gives 1.1% performance gain on SPECIN
10 matches
Mail list logo
