Hi Richard,
On 09/05/18 19:37, Richard Biener wrote:
On May 9, 2018 6:19:47 PM GMT+02:00, Kyrill Tkachov
wrote:
Hi all,
I'm looking into implementing the usad/ssad optabs for aarch64 to catch
code like in PR 85693
and I'm a bit lost with what the midend expects the optabs to produce.
The do
On May 10, 2018 10:53:19 AM GMT+02:00, Kyrill Tkachov
wrote:
>Hi Richard,
>
>On 09/05/18 19:37, Richard Biener wrote:
>> On May 9, 2018 6:19:47 PM GMT+02:00, Kyrill Tkachov
> wrote:
>>> Hi all,
>>>
>>> I'm looking into implementing the usad/ssad optabs for aarch64 to
>catch
>>> code like in PR
Hi!
for i in `grep __builtin_ia32 config/i386/i386-builtin.def | sed
's/^.*__builtin_ia32_/__builtin_ia32_/;s/".*$//' | sort -u`; do grep -q -w $i
config/i386/*.h || echo $i; done
shows many builtins not used in any of the intrinsic headers.
I believe for the __builtin_ia32_* builtins we only
On Thu, 10 May 2018, Jakub Jelinek wrote:
for i in `grep __builtin_ia32 config/i386/i386-builtin.def | sed
's/^.*__builtin_ia32_/__builtin_ia32_/;s/".*$//' | sort -u`; do grep -q -w $i
config/i386/*.h || echo $i; done
shows many builtins not used in any of the intrinsic headers.
I believe fo
On Thu, 10 May 2018, Jakub Jelinek wrote:
> __builtin_ia32_fldenv
> __builtin_ia32_fnclex
> __builtin_ia32_fnstenv
> __builtin_ia32_fnstsw
Calls to these are generated by ix86_atomic_assign_expand_fenv.
--
Joseph S. Myers
jos...@codesourcery.com
Hello,
While working on a port of GCC for a non-public architecture that has
pre/post-modify memory access instructions, I discovered what looks
like a bug which can cause incorrect code generation.
My suggested fix is trivial:
https://github.com/tyomitch/gcc/commit/7d9cc102adf11065358d4694109ce3
Hi,
"A. Skrobov" writes:
> Hello,
>
> While working on a port of GCC for a non-public architecture that has
> pre/post-modify memory access instructions, I discovered what looks
> like a bug which can cause incorrect code generation.
>
> My suggested fix is trivial:
> https://github.com/tyomitch/
On 05/10/2018 01:44 PM, A. Skrobov wrote:
> Hello,
>
> While working on a port of GCC for a non-public architecture that has
> pre/post-modify memory access instructions, I discovered what looks
> like a bug which can cause incorrect code generation.
>
> My suggested fix is trivial:
> https://git
Hi!
In one of my embedded projects I have an option to enable LTO. This was
working more or less fine for GCC 6 and GCC 7, however for GCC 8.1.0
(and binutils 2.30) - with the same set of options - I see something
like this
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
$ arm-non
Snapshot gcc-7-20180510 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20180510/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7
On Fri, May 11, 2018 at 12:09 AM, Jeff Law wrote:
>
> My recollection is that auto-increment addressing modes should not
> appear in the RTL in the CSE pass.
Fair enough; but they're explicitly listed in the big switch block in
hash_rtx_cb ().
Should my added line change from "invalidate_dest (XE
11 matches
Mail list logo
