On 11 Nov 2021 09:50, Jeff Law via Gdb-patches wrote:
> The upstream GCC tester has  showed spurious execution failures on the 
> H8 target for the H8/SX multilibs. I suspected memory corruption or an 
> uninitialized variable early as the same binary would sometimes work and 
> sometimes it got the wrong result. Worse yet, the point where the test 
> determined it was getting the wrong result would change.
> 
> Because it only happened on the H8/SX variant I was able to zero in on 
> the "mova" support and the "short form" of those instructions in particular.
> 
> As the code stands it checks if code->op3.type == 0 to try and identify 
> cases where op3 wasn't filled in and thus we've got the short form of 
> the mova instruction.
> 
> But for the short-form of those instructions we never set any of the 
> "op3" data structure. We get whatever was lying around -- it's usually 
> zero and thus things usually work, but if the stale data was nonzero, 
> then we'd fail to recognize the instruction as a short-form and fail to 
> set up the various fields appropriately.
> 
> I initially initialized the op3.type field to zero, but didn't like that 
> because it was inconsistent with how other operands were initialized. 
> Bringing consistency meant using -1 as the initializer value and 
> adjusting the check for short form mova appropriately.
> 
> I've had this in the upstream GCC tester for perhaps a year at this 
> point and haven't seen any of the intermittent failures again.

can you update the unittests too ?

and while we have your eyes on H8, can you perhaps peek at the open reports ?
https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&component=sim&&short_desc=h8300&short_desc_type=allwordssubstr
-mike