public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Richard Guenther" <richard.guenther@gmail.com>
To: "Mark Mitchell" <mark@codesourcery.com>
Cc: "Paul Brook" <paul@codesourcery.com>,
	gcc-patches@gcc.gnu.org,
	 	"Carlos O'Donell" <carlos@codesourcery.com>
Subject: Re: [PATCH] Stack corruption in naked functions.
Date: Fri, 23 May 2008 19:55:00 -0000	[thread overview]
Message-ID: <84fc9c000805231147u5c70b035wf1a9f7a8e65f99e5@mail.gmail.com> (raw)
In-Reply-To: <48370EE1.5070604@codesourcery.com>

On Fri, May 23, 2008 at 8:37 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> Paul Brook wrote:
>
>> If the stack slots result from code not permitted by the documentation
>> then this is user error.  Some not-permitted code may happen to "work" at
>> some optimisation levels with some compilers. However when this stops
>> working (e.g. at -O0) it is IMHO not defect in the compiler, it is user
>> error.  If anything the bug is that we allowed the code in the first place.
>
> I agree.
>
> As I see it, Carlos' patch makes things monotonically better.  It makes a
> valid test case work, and it causes no new failures.  Richard's comment is
> about what might happen with invalid code, but Carlos' patch is about valid
> code.  We could perhaps do better to catch more errors in the front ends,
> but that's an orthogonal issue.
>
> Richard, are you objecting to the patch?

I merely wanted to raise the concern that user errors will be noticed as ICEs
and not errors, which will lead to false bug-reports.  It would be nice if we
can emit an error, even if we cannot make sure to not ICE afterwards - that
will be a confused after errors, which is way better than an ICE with an
instruction to report a bug.

It's not clear to me if going this route has been evaluated?  IMHO we
don't need to rush in this change at this point before this was done.
The change itself looks to be papering over the problem - Carlos, can
you try Honzas patch for going into SSA at -O0 and look at what optimizations
you would need to make the valid testcases also work with -O0?

Thanks,
Richard.

  reply	other threads:[~2008-05-23 18:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-23  2:28 Carlos O'Donell
2008-05-23 10:40 ` Richard Guenther
2008-05-23 13:27   ` Carlos O'Donell
2008-05-23 13:30     ` Richard Guenther
2008-05-23 13:31   ` Paul Brook
2008-05-23 13:48     ` Richard Guenther
2008-05-23 14:34       ` Paul Brook
2008-05-23 19:04         ` Mark Mitchell
2008-05-23 19:55           ` Richard Guenther [this message]
2008-05-23 20:23             ` Mark Mitchell
2008-05-23 20:28               ` Richard Guenther
2008-05-23 20:41                 ` Mark Mitchell
2008-05-23 20:59                   ` Carlos O'Donell
  -- strict thread matches above, loose matches on Subject: below --
2007-11-08 17:14 [patch] " Paul Brook
2007-11-12  3:27 ` Mark Mitchell

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=84fc9c000805231147u5c70b035wf1a9f7a8e65f99e5@mail.gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=carlos@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mark@codesourcery.com \
    --cc=paul@codesourcery.com \
    /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).