On 8/24/22 15:51, Philip Herron wrote:
> Hi Martin,
>
> Not right now, it is on the to-do list, but do we have to do it in texinfo?
Well, I still hope we will move to Sphinx (and remove Texinfo) after the
Cauldron.
Anyway, using Sphinx is even now possible as a default documentation formal
(see
Hi Martin,
Not right now, it is on the to-do list, but do we have to do it in texinfo?
Thanks
--Phil
On Wed, 24 Aug 2022 at 14:49, Martin Liška wrote:
>
> On 8/15/22 16:33, Martin Liška wrote:
> > On 8/15/22 16:07, Manuel López-Ibáñez via Gcc-patches wrote:
> >> Dear Philip,
> >>
> >> Another
On 8/15/22 16:33, Martin Liška wrote:
> On 8/15/22 16:07, Manuel López-Ibáñez via Gcc-patches wrote:
>> Dear Philip,
>>
>> Another thing to pay attention to is the move to Sphinx for documentation:
>> https://gcc.gnu.org/pipermail/gcc/2022-August/239233.html
>
> Hi.
>
> Which is something I can h
On 8/15/22 16:07, Manuel López-Ibáñez via Gcc-patches wrote:
> Dear Philip,
>
> Another thing to pay attention to is the move to Sphinx for documentation:
> https://gcc.gnu.org/pipermail/gcc/2022-August/239233.html
Hi.
Which is something I can help you with. I have a script that converts a texin
Dear Philip,
Another thing to pay attention to is the move to Sphinx for documentation:
https://gcc.gnu.org/pipermail/gcc/2022-August/239233.html
Best,
Manuel.
On Wed, 10 Aug 2022 at 20:57, Philip Herron
wrote:
> Hi everyone
>
> For my v2 of the patches, I've been spending a lot of time ensur
On Aug 10, 2022, at 11:56 AM, Philip Herron wrote:
>
> For my v2 of the patches, I've been spending a lot of time ensuring
> each patch is buildable. It would end up being simpler if it was
> possible if each patch did not have to be like this so I could split
> up the front-end in more patches.
On Wed, 2022-08-10 at 19:56 +0100, Philip Herron wrote:
> Hi everyone
>
> For my v2 of the patches, I've been spending a lot of time ensuring
> each patch is buildable. It would end up being simpler if it was
> possible if each patch did not have to be like this so I could split
> up the front-end
Hi everyone
For my v2 of the patches, I've been spending a lot of time ensuring
each patch is buildable. It would end up being simpler if it was
possible if each patch did not have to be like this so I could split
up the front-end in more patches. Does this make sense? In theory,
when everything g
Thanks, for confirming David. I think it was too big in the end. I was
trying to figure out how to actually split that up but it seems
reasonable that I can split up the front-end patches into patches for
each separate pass in the compiler seems like a reasonable approach
for now.
--Phil
On Wed,
On Wed, 2022-07-27 at 14:40 +0100, herron.philip--- via Gcc-patches
wrote:
> This is the initial version 1 patch set for the Rust front-end. There
> are more changes that need to be extracted out for all the target
> hooks we have implemented. The goal is to see if we are implementing
> the target
This is the initial version 1 patch set for the Rust front-end. There are more
changes that need to be extracted out for all the target hooks we have
implemented. The goal is to see if we are implementing the target hooks
information for x86 and arm. We have more patches for the other targets I
11 matches
Mail list logo
