lkml.org 
[lkml]   [2012]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 01/16] math128: Introduce various 128bit primitives
From
Date
On Thu, 2012-10-25 at 07:21 +0200, Geert Uytterhoeven wrote:
> On Wed, Oct 24, 2012 at 11:53 PM, Juri Lelli <juri.lelli@gmail.com> wrote:
> > +#ifdef __SIZEOF_INT128__ /* gcc-4.6+ */
> > + unsigned __int128 val;
> > +#endif
>
> So the definition of val depends on (gcc) __SIZEOF_INT128__...
>
> > +/*
> > + * Make usage of __int128 dependent on arch code so they can
> > + * judge if gcc is doing the right thing for them and can over-ride
> > + * any funnies.
> > + */
> > +
> > +#ifndef ARCH_HAS_INT128
>
> ... but all generic users depend on (Kconfig) ARCH_HAS_INT128?

Ah, you're saying both should depend on the same thing. I fear there's a
chicken-egg problem in the code as it is now, the asm/math128.h thing
needs the data structure but is also the one setting ARCH_HAS_INT128.

So its not Kconfig.

> How can Kconfig know if gcc supports this?

It cannot, its per the asm/math128.h header to opt-in on using it. This
so archs can make sure gcc doesn't generate broken code or relies on
libgcc for its __int128 implementation.

Now, if we do as Linus suggests and push the data structure definition
into a separate header we could possibly avoid this.


\
 
 \ /
  Last update: 2012-10-25 16:21    [W:0.436 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site