From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: inefficiency of GCC output code & -O problem
Date:	Fri, 14 Apr 2000 07:15:03 +0200
Organization:	NetVision Israel
Lines:	18
Message-ID:	<38F6A957.90A167DE@is.elta.co.il>
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 1000413112851 DOT 28180G-100000 AT is> <38F6137B DOT 47481761 AT mtu-net DOT ru> <38f6342c DOT 52524603 AT news DOT freeserve DOT net> <38F637C7 DOT 4F4ECB6 AT mtu-net DOT ru>
NNTP-Posting-Host:	ras1-p116.rvt.netvision.net.il
Mime-Version:	1.0
X-Trace:	news.netvision.net.il 955689248 2311 62.0.172.118 (14 Apr 2000 05:14:08 GMT)
X-Complaints-To:	abuse AT netvision DOT net DOT il
NNTP-Posting-Date:	14 Apr 2000 05:14:08 GMT
X-Mailer:	Mozilla 4.7 [en] (Win98; I)
X-Accept-Language:	en,ru,hebrew
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

"Alexei A. Frounze" wrote:
> 
> Steamer wrote:
> > The bugs in your code are in the interface between the C and the inline
> > assembly.  They may not cause a problem if you don't use -O2, but they
> > surely will as soon as the optimizer starts trying to rearrange things,
> > remove redundant instructions, avoid unnecessary memory access, etc.
> 
> Thus design of the optimizer is buggy as well. :))

No, the optimizer is okay, and the interface between GCC and Gas is okay as
well.  You just need to put into the inline assembly the necessary magic
(constraints and clobbered registers) to let GCC know enough about the inline
fragment so that it could Do The Right Thing.

However, if you intend purposefully to fight GCC and deliberately not abide
by the rules of correct inline assembly, don't be surprised if GCC and Gas
will fight back and produce invalid code... ;-)

- Raw text -