public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/47237] New: builtin_apply_args broken WRT local API changes.
Date: Sun, 09 Jan 2011 18:28:00 -0000	[thread overview]
Message-ID: <bug-47237-4@http.gcc.gnu.org/bugzilla/> (raw)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47237

           Summary: builtin_apply_args broken WRT local API changes.
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hubicka@gcc.gnu.org


#define INTEGER_ARG  5

extern void abort(void);

static void foo(int arg)
{
  if (arg != INTEGER_ARG)
    abort();
}

static void bar(int arg)
{
  foo(arg);
  __builtin_apply(foo, __builtin_apply_args(), 16);
}

int main(void)
{
  bar(INTEGER_ARG);

  return 0;
}
fails at 32bit.  The problem is that we call bar with register calling
conventions, while foo's calling conventions are default.
We must prevent any call conventions changes on functions calling
builtlin_apply.

This is not only case where builtin_apply_args breaks, since we will happily
clone the functions, too.

I guess in addition to inlinable and cloning flag, we need flag whether
function calling convention can change. In what conditions this is false in
addition to apply_args?

This bug probably exists since GCC 3.4. I tested 4.3 and 4.5 to fail.


             reply	other threads:[~2011-01-09 18:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-09 18:28 hubicka at gcc dot gnu.org [this message]
2011-01-11 13:03 ` [Bug tree-optimization/47237] [4.3/4.4/4.5/4.6 Regression] " rguenth at gcc dot gnu.org
2011-01-26 10:23 ` [Bug tree-optimization/47237] [4.3/4.4/4.5/4.6 Regression] builtin_apply_args broken WRT local ABI changes hubicka at gcc dot gnu.org
2011-01-26 14:29 ` hubicka at gcc dot gnu.org
2011-01-26 14:45 ` hjl.tools at gmail dot com
2011-01-27  7:03 ` [Bug tree-optimization/47237] [4.3/4.4/4.5 " hjl.tools at gmail dot com
2011-02-02 18:00 ` dnovillo at gcc dot gnu.org
2011-02-02 18:01 ` dnovillo at gcc dot gnu.org
2011-06-27 14:38 ` rguenth at gcc dot gnu.org
2012-03-13 15:12 ` [Bug tree-optimization/47237] [4.5 " jakub at gcc dot gnu.org
2012-03-24 23:41 ` hubicka at gcc dot gnu.org
2012-07-02 10:24 ` rguenth at gcc dot gnu.org

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=bug-47237-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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).