Re: [PATCH 2.6.20-rc1 00/10] Kernel memory leak detector 0.13

[Mike Galbraith]

On Sun, 2006-12-17 at 09:58 +0100, Ingo Molnar wrote:
> * Catalin Marinas <catalin.marinas@xxxxxxxxx> wrote:
> 
> > Hi Ingo,
> > 
> > On 16/12/06, Ingo Molnar <mingo@xxxxxxx> wrote:
> > >FYI, i'm working on integrating kmemleak into -rt. Firstly, i needed the
> > >fixes below when applying it ontop of 2.6.19-rt15.
> > 
> > Do you need these fixes to avoid a compiler error? If yes, this is 
> > caused by a bug in gcc-4.x. The kmemleak container_of macro has 
> > protection for non-constant offsets passed to container_of but the 
> > faulty gcc always returns true for builtin_contant_p, even when this 
> > is not the case. Previous versions (3.4) or one of the latest 4.x gcc 
> > don't have this bug.
> > 
> > I wouldn't extend kmemleak to work around a gcc bug which was already 
> > fixed.
> 
> correct, i needed it for gcc 4.0.2. If you want this feature upstream, 
> this has to be solved - no way are we going to phase out portions of 
> gcc4. It's not hard as you can see it from my patch, non-static 
> container_of is very rare. We do alot of other hackery to keep older 
> compilers alive, and we only drop compiler support if some important 
> feature really, really needs new gcc and a sane workaround is not 
> possible.

If that's because of things like the dinky testcase below,

   int main (int argc, char *argv[])
   {
     static int a[] = { __builtin_constant_p (argc) ? 1 : 0 };
     return a[0];
   }

AFAIK, no SuSE compiler can handle it.  I just build/tested their latest
version,

   gcc version 4.1.2 20061129 (prerelease) (SUSE Linux)

and it still can't deal with that without gcc41-rh198849.patch being
applied.

	-Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/