This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: preprocessor: % as args to #defines

On Jan 29, 2004, at 10:55, Syd Polk wrote:
It seems that most of Apple's customers do not agree at all; most major Macintosh software vendors have many many lines of inline assembly in their source files. It is one of the big preventers of GCC adoption in the Apple world.

I wished GCC never supplied an inline-asm because it causes so much problems in that
it can cause seg faults when you are using %c0 or some other operand character which
does not work for your case, there are three different bugs for this on three different
targets. The idea of using a compiler is to have the compiler optimize for you, if the
compiler does not, then either drop the compiler, improve it, or write full asm.

Inline-asm to gcc basically gives the information for the machine descriptions to the user
which is a bad thing.

I have to agree with Zack here that most of the problems come from people abusing inline-asm
too much problems for people to use with more than one asm instructions as most of gcc does
not understand really that the asm is really more than one instruction (yes parts of it does
but the problems that come with thins like this:

asm("lots of asm":"=r"(x0),"=r"(x1),"=r"(x2),"=r"(x3),"=r"(x4),"=r"(x5):"r"(y0),"r"(y 1),"r"(y2),"r"(y3),"r"(y4),"r"(y5));
people do not why this fails on targets like x86 which does not have enough registers to fill
all those constraints. There are others things like this happens a lot in people's code.
Also glibc has ugly (I mean ugly) inline-asm in their headers for some string and math
functions (at least on x86).

Thanks, Andrew Pinski a gcc bug master (and not speaking for Apple at all)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]