This is the mail archive of the gcc-patches@gcc.gnu.org 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: New C parser [patch]


Richard Henderson <rth@redhat.com> writes:

> On Mon, Oct 25, 2004 at 05:03:31PM -0700, Zack Weinberg wrote:
>> The only way
>> asm() at top level can continue to make sense is if we pass it along
>> to cgraph, and somehow get cgraph to preserve the global order of
>> functions and asm()s.  [Mind you, I would not have any problem with
>> dropping this feature.]
>
> False.
>
> ----
> static void doit(int, int);
>
> __asm__("\
> 	.ent doit	\n\
> doit:			\n\
> 	...		\n\
> 	ret		\n\
> 	.end doit	\n\
> ");

... Okay, so _some_ uses of asm() at top level aren't ordering-
sensitive.  Doesn't change the fact that some are, and that it's not
an obvious proposition to come up with another way to do them.  (If I
could think of a better way to write crtstuff.c I would have done it
long ago.)

On a more abstract note, whether or not we decide we want to keep
supporting order-sensitive top level asm() SOMEhow, it's still a
layering violation to be calling assembly output routines directly
from the parser.

zw


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