X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
Subject: Re: ANNOUNCE: Update of DJGPP port of gcc-5.3.0
To: djgpp AT delorie DOT com
References: <201601312013 DOT u0VKDC4O017569 AT delorie DOT com>
 <n8norb$gck$1 AT usenet DOT news DOT interia DOT pl> <56AF7CFB DOT 8010507 AT iki DOT fi>
 <n8obct$m4c$1 AT usenet DOT news DOT interia DOT pl> <83twlsyya8 DOT fsf AT gnu DOT org>
 <56B03232 DOT 8040802 AT iki DOT fi> <n8skjg$bf4$1 AT usenet DOT news DOT interia DOT pl>
 <n9siu0$hu6$1 AT usenet DOT news DOT interia DOT pl>
 <7c07fdd8-c7f5-4cba-b83d-42407a6717f7 AT googlegroups DOT com>
 <n9upim$3hk$1 AT usenet DOT news DOT interia DOT pl>
From: "Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
Message-ID: <56C407C8.40505@iki.fi>
Date: Wed, 17 Feb 2016 07:40:24 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <n9upim$3hk$1@usenet.news.interia.pl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On 02/16/2016 11:19 AM, Wiktor S. (wswiktorSP AT Mpoczta DOT fm) [via djgpp AT delorie DOT com] wrote:
>>> This was a one-line problem in assembly code:
>>>
>>>     rep/movsl (%esi),(%edi)
>>>
>>> Newest as.exe generates wrong binary code on the above line. After
>>> changing to "rep movsl" with space it worked.
>>>
>>> I don't know if rep/movsl syntax is correct or not, but if it is
>>> not, AS should fail instead of silently generating bad code.
>>
>> Do you mean that GCC itself is generating [sic] "rep/movsl" or is it
>> some inline or handwritten (external) assembly file?
>
>
> It is in handwritten assembly.
>
> The dissasembled (wrong) instruction is
>
>    rep add %eax,%esi
>
>
>
I guess that it should be reported to binutils mailing list  to get some information.
Is it a bug or something else?

This is not the first time when change to binutils forces to change existing
assembler code. Most often error messages are being generated for old
GNU assembler  code. One that I remember was operand length suffix
handling (when they are required, when not accepted).

I think that binutils downgrading from 2.26 to 2.25 was not the way to go.
It is rather common that old code has to be updated to work with new
compiler and this time binutils version.

Andris