Re: [PATCH] Fix do_div() for all architectures

[Andrea Arcangeli <andrea@suse.de>]

On Thu, Jul 10, 2003 at 09:31:45PM +0200, Bernardo Innocenti wrote:
> On Thursday 10 July 2003 18:39, Richard Henderson wrote:
> 
>  > On Thu, Jul 10, 2003 at 06:18:59PM +0200, Andrea Arcangeli wrote:
>  > > On Thu, Jul 10, 2003 at 08:40:19AM -0700, Richard Henderson wrote:
>  > > > On Tue, Jul 08, 2003 at 08:27:26PM +0200, Bernardo Innocenti wrote:
>  > > > > +extern uint32_t __div64_32(uint64_t *dividend, uint32_t
>  > > > > divisor) __attribute_pure__;
>  > > >
>  > > > ...
>  > > >
>  > > > > +		__rem = __div64_32(&(n), __base);	\
>  > > >
>  > > > The pure declaration is very incorrect.  You're writing to N.
>  > >
>  > > now pure sounds more reasonable, I wondered how could gcc keep track
>  > > of the stuff pointed by the parameters (especially if this stuff
>  > > points to other stuff etc.. ;).
> 
>  The compiler could easily tell what memory can be clobbered by a pointer
> by applying type-based aliasing rules. For example, a function taking a
> "char *" can't clobber memory objects declared as "long bar" or
> "struct foo".
> 
>  Without type based alias analysis, the compiler is forced to flush
> all registers containing copies of memory objects before function
> call and reloading values from memory afterwards.

the kernel isn't complaint with the alias analysis, that's why it has to
be turned off (-fnostrict-aliasing) or stuff would break.

> Boy, that's ugly! It's too bad C can't do it the Perl way:
> 
>     (n,rem) = __div64_32(n, base);

or the python way:

	n, rem = __div64_32(n, base)

;)

Andrea