That would be brilliant if you could do that! I can spend my time
focused on splitting the front-end into patches. In the meantime,
while you work on that, I will use your patch here to disable the
target hook stuff so that the patches are buildable.
--Phil
On Thu, 28 Jul 2022 at 12:09, Thomas Sc
Hi Phil!
On 2022-07-28T11:51:37+0100, Philip Herron wrote:
> I think you are right here. There are parts in
> libstd/liballoc/libpanic which start to look for what CPU features are
> available iirc.
Aha, good. That -- once we get there ;-) -- shall then guide us on the
target options we impleme
Hi Thomas,
I think you are right here. There are parts in
libstd/liballoc/libpanic which start to look for what CPU features are
available iirc. Maintaining our patches here has been becoming
difficult as of late, especially when it comes to libcore, which just
cares about target pointer width and
Hi!
On 2022-07-27T14:40:38+0100, "herron.philip--- via Gcc-patches"
wrote:
> This patch introduces a new set of interfaces to define the target info as
> expected by the rust front-end. It takes advantage of the information
> within gcc/config/target directories which gets called by the front-en
Note, the ChangeLog entry formatting is wrong and in various places
the code formatting as well. In gcc/rust/ you can choose different
formatting if there are strong reasons for that, but at least it should be
consistent and ideally documented.
None of the gcc/doc, gcc/config, gcc/config/i386 dir
From: Philip Herron
This patch introduces a new set of interfaces to define the target info as
expected by the rust front-end. It takes advantage of the information
within gcc/config/target directories which gets called by the front-end
to populate rust front-end datastructures by calling into:
b
