From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3886 invoked by alias); 1 Jul 2002 19:26:07 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 3871 invoked by uid 71); 1 Jul 2002 19:26:05 -0000 Date: Mon, 01 Jul 2002 12:26:00 -0000 Message-ID: <20020701192605.3870.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Ben Liblit Subject: Re: c/7153: bad operands for 'movsbl' error Reply-To: Ben Liblit X-SW-Source: 2002-07/txt/msg00010.txt.bz2 List-Id: The following reply was made to PR c/7153; it has been noted by GNATS. From: Ben Liblit To: Eric Botcazou 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.