This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: inline asm string/line break rules change
- From: Andi Kleen <ak at suse dot de>
- To: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Cc: Andi Kleen <ak at suse dot de>, Joel Sherrill <joel at OARcorp dot com>,gcc at gcc dot gnu dot org
- Date: Sat, 13 Apr 2002 23:56:42 +0200
- Subject: Re: inline asm string/line break rules change
- References: <3CB88687.85AA58CB@OARcorp.com.suse.lists.egcs> <p737knbbdkm.fsf@oldwotan.suse.de> <200204132303.04966@enzo.bigblue.local>
On Sat, Apr 13, 2002 at 11:03:04PM +0200, Franz Sirl wrote:
> On Saturday 13 April 2002 21:31, Andi Kleen wrote:
> > Joel Sherrill <joel@OARcorp.com> writes:
> > > If there was a discussion on this, I must not have missed
> > > it or not realized the potential impact. I sure don't want
> > > to begin to modify other code bases until I know the intention.
> >
> > It's also a big problem for the linux kernel and for various other
> > packages.
>
> kernel is fixed for a long time and there are only a few packages out there
> using inline assembly heavily.
It is still a big issue when older kernels are compiled for example.
Same when the other packages are compiled.
>
> > Even if there should be good reasons to discourage multi line string
> > I think it shouldn't be warned until an alternative inline assembly
> > syntax that doesn't rely on strings exists. Currently it is discouraging
> > one practice with no good replacement.
>
> Please? A warning is there since gcc-3.0! And adding the 3 chars \n\ to each
> multiline isn't that hard, with Joel's example:
It isn't hard, but it makes the assembly completely unreadable and worse
it is an endless source of editing errors (it is very error prone and with
longer assembly statements usually needs another edit-fix cycle to get it right)
I would call it syntatic vinegar.
> Seems easy enough to me (did it to the ppc assmbly in glibc for example).
I guess you didn't do actual development on the assembly though
(= frequent changes).
-Andi