Re: c/7153: bad operands for 'movsbl' error

Re: c/7153: bad operands for 'movsbl' error

[Eric Botcazou]

The following reply was made to PR c/7153; it has been noted by GNATS.

From: "Eric Botcazou" <ebotcazou@libertysurf.fr>
To: "Ben Liblit" <liblit@eecs.berkeley.edu>
Cc: <gcc-gnats@gcc.gnu.org>
Subject: Re: c/7153: bad operands for 'movsbl' error
Date: Mon, 1 Jul 2002 23:05:19 +0200

 > Do we still want to consider that implicit expectation to be a gcc bug? 
 > I'd say yes.  If the optimizer genuinely *cannot* be made to work with
 > uninitialized data, then it should emit an error message (not just a
 > warning) and refuse to continue.
 
 > Generating bogus assembly code is a poor diagnostic.
 
 Why ? ;-)
 
 
 I posted a (not yet reviewed) patch against the 3.1 codebase:
 http://gcc.gnu.org/ml/gcc-patches/2002-06/msg02298.html
 
 --
 Eric Botcazou
 ebotcazou@multimania.com
 

Re: c/7153: bad operands for 'movsbl' error

[rth]

Synopsis: bad operands for 'movsbl' error

State-Changed-From-To: open->closed
State-Changed-By: rth
State-Changed-When: Tue Jul 16 12:35:27 2002
State-Changed-Why:
    Fixed.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7153

Re: c/7153: bad operands for 'movsbl' error

[Ben Liblit]

The following reply was made to PR c/7153; it has been noted by GNATS.

From: Ben Liblit <liblit@eecs.berkeley.edu>
To: Eric Botcazou <ebotcazou@libertysurf.fr>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c/7153: bad operands for 'movsbl' error
Date: Mon, 01 Jul 2002 12:18:04 -0700

 Thank you, Eric, for your speedy and expert diagnosis!  Unfortunatley,
 in my case, the problem is not so easily solved.  :-(
 
 The real code in which I am encountering this error is the product of an
 automatic transformation which adds logging of the values of local
 variables at a randomized subset of dynamic program points.  Right now,
 I don't do anything special to avoid logging uninitialized variables. 
 If I want to avoid this bug, I'd essentially need to reimplement the
 dataflow analysis used by gcc to identify uninitialized variables,
 including any and all special cases or quirks particular to gcc's
 definition of what exactly "uninitialized" means.
 
 Furthermore, the logging transformation is intended as a bug hunting
 tool, and some bugs may be caused by accessing uninitialized data: i.e.,
 if I filter out uninitialized variables, I miss a broad class of the
 bugs that the transformation is intended to detect.
 
 Hmm.
 
 > one of the optimization passes of the compiler (register movement)
 > implicitly expects variables to be set before being accessed
 
 Do we still want to consider that implicit expectation to be a gcc bug? 
 I'd say yes.  If the optimizer genuinely *cannot* be made to work with
 uninitialized data, then it should emit an error message (not just a
 warning) and refuse to continue.  Generating bogus assembly code is a
 poor diagnostic.

Re: c/7153: bad operands for 'movsbl' error

[Eric Botcazou]

The following reply was made to PR c/7153; it has been noted by GNATS.

From: "Eric Botcazou" <ebotcazou@libertysurf.fr>
To: "Ben Liblit" <liblit@CS.Berkeley.EDU>
Cc: <gcc-gnats@gcc.gnu.org>
Subject: Re: c/7153: bad operands for 'movsbl' error
Date: Fri, 28 Jun 2002 19:07:14 +0200

 > 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
 
 It should have been: movsbl %bl,%eax.
 
 > 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.
 
 That's actually the "cause" of the problem: one of the optimization passes
 of the compiler (register movement) implicitly expects variables to be set
 before being accessed, here the 'bytes' variable. Writing 'char bytes = 0;"
 lets the problem disappear.
 
 > This fragment is a minimized excerpt from the thousand-line source file in
 > which I originally encountered the bug.
 
 Do you compile it with '-Wall' ? The compiler should then spot (most of) the
 uninitialized automatic variables, thus giving you the opportunity for
 working around the problem.
 
 --
 Eric Botcazou
 ebotcazou@multimania.com
 

c/7153: bad operands for 'movsbl' error

[Ben Liblit]

>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: