BRBUILDLOG:command:br_prepare_repo binutils_gdb master
---> git remote prune origin
---> git pull --all
Fetching origin
Already up-to-date.

Current top commit:
commit 65fca0597f3a5f76f6d7d79bc3a922c160254e0a
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri Feb 14 14:27:28 2020 +0100

    x86: replace adhoc (partly wrong) ambiguous operand checking for MOVSX/MOVZX
    
    For these to get treatment consistent with other operand size checking
    the special logic shouldn't live in md_assemble(), but process_suffix().
    And there's more logic involved than simply zapping the suffix.
    
    Note however that MOVS[BW]* and MOVZ[BW]* still won't be fully
    consistent, due to the objection to fold MOVS* templates just like was
    done for MOVZ* in c07315e0c6 ("x86: allow suffix-less movzw and 64-bit
    movzb").
    
    Note further that it is against my own intentions to have MOVSX/MOVZX
    silently default to a byte source in AT&T mode. This should happen only
    when the destination register is a 16-bit one. In all other cases there
    is an ambiguity, and the user should be warned. But it was explicitly
    requested for this to be done in a way inconsistent with everything
    else.
    
    Note finally that the assembler change points out (and this patch fixes)
    a wrong Intel syntax test introduced by bc31405ebb2c ("x86-64: Properly
    encode and decode movsxd"): When source code specifies a 16-bit
    destination register, disassembly expectations shouldn't have been to
    find a 32-bit one.

Outstanding patch:
BRBUILDLOG:starttime:1581686585
BRBUILDLOG:stoptime:1581686588
BRBUILDLOG:duration:3
BRBUILDLOG:status:0