public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Ben Liblit <liblit@eecs.berkeley.edu> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: c/7153: bad operands for 'movsbl' error Date: Mon, 01 Jul 2002 12:26:00 -0000 [thread overview] Message-ID: <20020701192605.3870.qmail@sources.redhat.com> (raw) 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.
next reply other threads:[~2002-07-01 19:26 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-07-01 12:26 Ben Liblit [this message] -- strict thread matches above, loose matches on Subject: below -- 2002-07-16 12:35 rth 2002-07-01 14:06 Eric Botcazou 2002-06-28 10:56 Eric Botcazou 2002-06-28 4:16 Ben Liblit
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=20020701192605.3870.qmail@sources.redhat.com \ --to=liblit@eecs.berkeley.edu \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@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: linkBe 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).