Guys,
I checked out a fresh copy of the GCC sources today, applied somebodies
patch to it and voila!
options.c:13591:2: error: #error Report option property is dropped #error
Report option property is dropped
I built this the same minimally convoluted way that I always do.
cd $1
BASE=`pwd`
ech
On March 15, 2021 7:31:46 PM GMT+01:00, Thomas Schwinge
wrote:
>Hi!
>
>First time I'm using this API -- so the error certainly may be on my
>side. ;-)
>
>What I'm doing, is a 'walk_gimple_seq', and in that one's
>'callback_stmt', call 'walk_stmt_load_store_addr_ops', to collect
>variable load/st
Hi!
First time I'm using this API -- so the error certainly may be on my
side. ;-)
What I'm doing, is a 'walk_gimple_seq', and in that one's
'callback_stmt', call 'walk_stmt_load_store_addr_ops', to collect
variable load/store/address-taken instances. This did seem quite
straight-forward, given
Actually, what I want is a processor with ECS,
EDS and EES, as new registers, and for GCC
to target that, supporting near, far and huge
code pointers and data pointers.
BFN. Paul.
-Original Message-
From: Paul Edwards
Sent: Tuesday, March 16, 2021 12:55 AM
To: GCC Development
Subj
> The RISC-V document linked to suggests that won't be an issue for RISC-V
> with hardware _Float16 support, though obviously it's still necessary to
> decide what to do when using _Float16 on RISC-V systems without the
> hardware support, if that is allowed at all.
My thought is that _Float16 is
Would it be possible for GCC to generate code
that reserves ESI and EDI as "extended segment"
registers to hold a source and destination
"extended segment" of any operation.
This will be the upper 32-bits of a 64-bit address.
When run on a normal 80386, such code will work
fine, and ESI and EDI
On Mon, 15 Mar 2021 at 10:17, Sjoerd Meijer wrote:
>
> Many thanks for your replies and thoughts on this.
>
> I wanted to add that I agree with this, and say that this is the
> current state in Clang (exactly because of the reason that
> _Float16 is entirely new):
>
> I see less value in adding add
Many thanks for your replies and thoughts on this.
I wanted to add that I agree with this, and say that this is the
current state in Clang (exactly because of the reason that
_Float16 is entirely new):
I see less value in adding additional distinct types that don't add anything
you can't already
On Sun, Mar 14, 2021 at 3:20 PM Paul Edwards wrote:
>
> Thanks Richard.
>
> Based on what you said I made this change:
>
> C:\devel\gcc\gcc\config\i370>cvs diff
> cvs diff: Diffing .
> Index: i370.h
> ===
> RCS file: c:\cvsroot/gcc/gc
