public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: Ben Liblit <liblit@CS.Berkeley.EDU>
To: gcc-gnats@gcc.gnu.org
Subject: c/7153: bad operands for 'movsbl' error
Date: Fri, 28 Jun 2002 04:16:00 -0000	[thread overview]
Message-ID: <200206280945.g5S9jE325314@brawnix.CS.Berkeley.EDU> (raw)


>Number:         7153
>Category:       c
>Synopsis:       bad operands for 'movsbl' error
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Fri Jun 28 02:46:05 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Ben Liblit <liblit@cs.berkeley.edu>
>Release:        3.1
>Organization:
Computer Science Division, UC Berkeley
>Environment:
System: Linux brawnix.CS.Berkeley.EDU 2.4.18 #6 Wed Jun 12 02:01:38 PDT 2002 i686 unknown
Architecture: i686

host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../gcc-3.1/configure --prefix=/var/local/gcc/install
>Description:

When fed the C source file given below, gcc generates assembly code
which yields the following error message:

/var/tmp/ccKc5NSG.s:14: Error: suffix or operands invalid for `movsbl'

The assembly code on the line in question is:

	movsbl	%ebx,%eax

I don't know enough about x86 assembly code to know whether that is
correct (asm bug) or incorrect (gcc bug), but something somewhere is
broken.

Important note: the error only appears when compiling with
optimization level 2 or higher (-O2).  Below that, the code compiles
correctly.

Although I am reporting this as a bug in gcc-3.1, I have reproduced
the same problem in 2.96 and 3.0.

On the off chance that this is an assembler bug, I'm using
as-2.11.93.0.2.

>How-To-Repeat:

Compile the following code using "gcc -O2 -c bug.c":

	void f(char);
	void g();


	void scale()
	{
	  int width;
	  char bytes;
	  char *src;

	  if (width)
	    {
	      bytes = *src;
	      g();
	      width *= bytes;
	    }

	  f(bytes);
	}

I am aware that this code doesn't exactly do anything useful, and even
accesses uninitialized variables.  This fragment is a minimized
excerpt from the thousand-line source file in which I originally
encountered the bug.

>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:


             reply	other threads:[~2002-06-28  9:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-28  4:16 Ben Liblit [this message]
2002-06-28 10:56 Eric Botcazou
2002-07-01 12:26 Ben Liblit
2002-07-01 14:06 Eric Botcazou
2002-07-16 12:35 rth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200206280945.g5S9jE325314@brawnix.CS.Berkeley.EDU \
    --to=liblit@cs.berkeley.edu \
    --cc=gcc-gnats@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).