on 2022/4/2 5:52 AM, Peter Bergner wrote:
> On 4/1/22 3:50 PM, will schmidt wrote:
>> Is there a testcase, new or existing, that illustrates this error path?
>
> Well, the already existsing test case pr101849.c is where the issue was seen,
> but only when compiled by hand outside of the test harne
On 4/1/22 3:50 PM, will schmidt wrote:
> Is there a testcase, new or existing, that illustrates this error path?
Well, the already existsing test case pr101849.c is where the issue was seen,
but only when compiled by hand outside of the test harness and using only the
-maltivec option and not the
On Thu, 2022-03-03 at 16:38 +0800, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
Hi
> As PR103353 shows, we may want to continue to expand a MMA built-in
> function like a normal function, even if we have already emitted
> error messages about some missing required conditions. As shown in
> that PR,
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591150.html
BR,
Kewen
on 2022/3/3 4:38 PM, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As PR103353 shows, we may want to continue to expand a MMA built-in
> function like a normal function, even if we have already emitted
> er
Hi,
As PR103353 shows, we may want to continue to expand a MMA built-in
function like a normal function, even if we have already emitted
error messages about some missing required conditions. As shown in
that PR, without one explicit mov optab on OOmode provided, it would
call emit_move_insn recu
