Jakub Jelinek writes:
> On Fri, Nov 08, 2024 at 05:44:48PM +, Richard Sandiford wrote:
>> It's for https://gcc.gnu.org/pipermail/gcc-patches/2024-November/667499.html
>> ,
>> which needs to switch to the simd clone's chosen target (SVE) in order
>> to construct the correct types. Currently t
On Fri, Nov 08, 2024 at 05:44:48PM +, Richard Sandiford wrote:
> It's for https://gcc.gnu.org/pipermail/gcc-patches/2024-November/667499.html ,
> which needs to switch to the simd clone's chosen target (SVE) in order
> to construct the correct types. Currently the patch uses:
>
> + cl_ta
Andrew Stubbs writes:
> On 08/11/2024 12:25, Richard Sandiford wrote:
>> For the aarch64 simd clones patches, it would be useful to be able to
>> push a function declaration onto the cfun stack, even though it has no
>> function body associated with it. That is, we want cfun to be null,
>> curren
On 08/11/2024 12:25, Richard Sandiford wrote:
For the aarch64 simd clones patches, it would be useful to be able to
push a function declaration onto the cfun stack, even though it has no
function body associated with it. That is, we want cfun to be null,
current_function_decl to be the decl itse
On Fri, 8 Nov 2024, Richard Sandiford wrote:
> For the aarch64 simd clones patches, it would be useful to be able to
> push a function declaration onto the cfun stack, even though it has no
> function body associated with it. That is, we want cfun to be null,
> current_function_decl to be the dec
For the aarch64 simd clones patches, it would be useful to be able to
push a function declaration onto the cfun stack, even though it has no
function body associated with it. That is, we want cfun to be null,
current_function_decl to be the decl itself, and the target and
optimisation flags to ref
