public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Andreas Krebbel" <Andreas.Krebbel@de.ibm.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PING] Target hook for rewriting inline asm constraints
Date: Wed, 31 Oct 2007 17:22:00 -0000	[thread overview]
Message-ID: <20071031155400.GA13083@homer.boeblingen.de.ibm.com> (raw)
In-Reply-To: <m3sl3r5o38.fsf@fleche.redhat.com>

Hi,

> I'm not an FE or ME maintainer but I took a look anyway.
Thanks!

> Wouldn't the C++ FE need a similar patch?  And, if so, why do this
> work in the front ends rather than somewhere more generic?  

Yes, the C++ FE also needs to call that hook.  I've focused on C with
my first patch since this is the most obvious user of inline
assemblies, but you are right this has to be extended.

I've tried at first to implement this as a more generic hook in the
middle end, but dealing with this in recog and reload turned out to be
way more complicated.

> Or, if the
> FE is really the way to go, perhaps a helper function in c-common.c
> would be better.
Ok that might be a good idea.

> I saw a few coding standard violations in the code.
> 
> * Repeated use of strlen in the loop (use an output index)

Ok.

> * Assignments in conditional expressions (frowned on by GNU standards;
>   in any case the comma operators seemed gratuitous to me)
> * No braces around body of do-while.

I've simply copied the loop reload and recog are using.  See
find_reloads and constrain_operands.  I wasn't aware that this isn't
considered good style.  I can certainly change that.

> * Hard-coded lengths without bounds checking (this one is questionable
>   I suppose)

It would be difficult to harden that code against back end hooks
returning huge strings.  I'm not sure thats worth the effort.  But
I'll try to address this.

Bye,

-Andreas-

  parent reply	other threads:[~2007-10-31 15:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-30 12:54 Andreas Krebbel
2007-10-31 16:31 ` Tom Tromey
2007-10-31 16:43   ` Richard Guenther
2007-10-31 18:55     ` Andreas Krebbel
2007-10-31 19:13       ` Richard Guenther
2007-10-31 20:40         ` Andreas Krebbel
2007-11-04 23:05           ` Richard Sandiford
2007-11-05  9:25             ` Andreas Krebbel
2007-11-05  9:43               ` Richard Sandiford
2007-11-05 10:32                 ` Andreas Krebbel
2007-11-05 11:02                   ` Richard Sandiford
2007-11-05 13:42                     ` Andreas Krebbel
2007-11-06 22:00                       ` Richard Sandiford
2007-11-07 11:55                         ` Andreas Krebbel
2007-10-31 17:22   ` Andreas Krebbel [this message]
2007-10-31 17:56     ` Tom Tromey
2007-11-06 18:20 ` Michael Meissner
2007-11-07  9:10   ` Andreas Krebbel

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=20071031155400.GA13083@homer.boeblingen.de.ibm.com \
    --to=andreas.krebbel@de.ibm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=tromey@redhat.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).