Re: lame 3.101 beta 1 in SVN...

Alexander Leidinger via Lame-dev <[email protected]> Wed, 17 Mar 2021 15:37:09 +0100
Newsgroups gmane.comp.audio.mp3.lame
Message-ID <20210317153709.Horde.TcA4Mzm7IS7FH-VeZHaFfDz@webmail.leidinger.net>
Quoting Elio Blanca via Lame-dev <[email protected]>  
(from Tue, 16 Mar 2021 20:31:29 +0100):

> Il giorno Tue, 16 Mar 2021 13:03:34 +0100
> Alexander Leidinger <[email protected]> ha scritto:
>
>> So what is wrong here with the '=' and why is it better solved with a
>> memcpy?
>
> I faced at least two cases of obscure crashes in C code due to
> assignment in code involving float variables (as the struct the patch
> cares about does). In those cases the ARM CPU was reacting very badly
> (crash) in front of misaligned float variables as the compiler (a
> proprietary closed source one) used to convert the '=' into load/move
> (can't remember the name ATM) asm instructions, sensitive to data
> alignment. Converting the '=' into a 'memcpy' solved our crashes.

Ah... data alignment... now this rings a bell... the solution would  
then be to request the compiler to properly align the struct... or we  
need to reorder the struct to make it align properly.

Anyone with access to an ARM CPU willing to test this?

typedef struct calc_noise_result_t {
     FLOAT   over_noise;      /* sum of quantization noise > masking */
     FLOAT   tot_noise;       /* sum of all quantization noise */
     FLOAT   max_noise;       /* max quantization noise */
     int     over_count;      /* number of quantization noise > masking */
     int     over_SSD;        /* SSD-like cost of distorted bands */
     int     bits;
} calc_noise_result __attribute__ ((aligned (8)));

I've chosen an alignment of 8 just to make sure everything works even  
if FLOAT is defined to double.

Bye,
Alexander.
-- 
http://www.Leidinger.net [email protected]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [email protected]  : PGP 0x8F31830F9F2772BF