Hi Andrew,
on 2022/12/5 18:10, Andrew Pinski wrote:
> On Sun, Dec 4, 2022 at 11:33 PM Richard Sandiford via Gcc
> wrote:
>>
>> "Kewen.Lin" writes:
>>> Hi,
>>>
>>> I'm working to find one solution for PR106736, which requires us to
>>> make some built-in types only valid for some target features,
On Mon, Dec 05, 2022 at 07:31:48AM +, Richard Sandiford wrote:
> FWIW, the aarch64 fp move patterns emit the error directly. They then
> expand an integer-mode move, to provide some error recovery. (The
> alternative would be to make the error fatal.)
>
> (define_expand "mov"
> [(set (matc
Hi Richard,
on 2022/12/5 15:31, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi,
>>
>> I'm working to find one solution for PR106736, which requires us to
>> make some built-in types only valid for some target features, and
>> emit error messages for the types when the condition isn't satisf
On Sun, Dec 4, 2022 at 11:33 PM Richard Sandiford via Gcc
wrote:
>
> "Kewen.Lin" writes:
> > Hi,
> >
> > I'm working to find one solution for PR106736, which requires us to
> > make some built-in types only valid for some target features, and
> > emit error messages for the types when the conditi
"Kewen.Lin" writes:
> Hi,
>
> I'm working to find one solution for PR106736, which requires us to
> make some built-in types only valid for some target features, and
> emit error messages for the types when the condition isn't satisfied.
> A straightforward idea is to guard the registry of built
Hi,
I'm working to find one solution for PR106736, which requires us to
make some built-in types only valid for some target features, and
emit error messages for the types when the condition isn't satisfied.
A straightforward idea is to guard the registry of built-in type under
the corresponding
