Re: [PATCH] arm: Don't require a runtime check function for targets with unconditional NEON

On Tue, Oct 11, 2022 at 3:36 PM Martin Storsjö <[email protected]> wrote:
>
> On Tue, 11 Oct 2022, Cosmin Truta wrote:
>
> > Hello, and thank you for your contribution. There are already other errors
> > in the existing code in pngpriv.h.
> >
> > For example, earlier on, PNG_ARM_NEON_OPT is set to 2 exactly under the
> > conditions that you're mentioning. (See the lines 130-133.) The real bug is
> > behind the conflict of PNG_ARM_NEON_OPT being equal to 2 on one hand, and
> > PNG_ARM_NEON_CHECK_SUPPORTED being enabled on the other hand. These two
> > conflicting conditions should be in fact mutually exclusive.
>
> Sure. In this case, as far as I can see, we can either move the #undef of
> PNG_ARM_NEON_CHECK_SUPPORTED into this ifdef block which sets
> PNG_ARM_NEON_OPT to 2 - resolving the conflicting macros right away, or
> check for this in the build systems.

Actually, I think I'm having a change of mind:

A developer may enable the __ARM_NEON__ codegen at compile time, but
that is not necessarily an assurance that the intended target machine
(to be used at run time) is actually Neon-enabled.

On the other hand, I do agree that the configure script and the cmake
file should be consistent in their behavior.

I wonder what other people say.

Sincerely,
Cosmin


_______________________________________________
png-mng-implement mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/png-mng-implement