Re: [PATCH] Introduce nodemask_t ADT [0/7]

[William Lee Irwin III <wli@holomorphy.com>]

At some point in the past, I wrote:
>> gcc flat out miscompiled such inlines last I checked (Zwane shipped the
>> bugreport IIRC).

On Mon, Mar 22, 2004 at 07:36:28PM -0800, Paul Jackson wrote:
> The one error I've heard tell of recently is one that Andi Kleen hit in
> include/linux/bitmap.h.  He had to compute the copy length explicitly in
> a separate variable, or gcc forgot to do it (I forget the details).  The
> change is:
>  static inline void bitmap_copy(unsigned long *dst,
>                         const unsigned long *src, int bits)
>  {
> -       memcpy(dst, src, BITS_TO_LONGS(bits)*sizeof(unsigned long));
> +       int len = BITS_TO_LONGS(bits)*sizeof(unsigned long);
> +       memcpy(dst, src, len);
>  }
> Do you have any more pointers/info on the miscompile you quote above?
> Like - how long ago - what gcc version ...

It dates back to before the merge. It should have been posted to lkml
by Zwane.


On Mon, Mar 22, 2004 at 07:36:28PM -0800, Paul Jackson wrote:
> It would be an insult to wrap the entire cpumask design around the
> axle of such non-specific allegations of gcc misconduct.  Better to
> get the API right, and then deal with specific tool bugs as necessary.
> Or, as Linus might say (did say, in a quite different context):
>   Never _ever_ make your source-code look worse because your tools suck. Fix
>   the tools instead.

I can't answer this directly. Basically, if ppl are merging workarounds
for ancient compilers, my expectation is that operational semantics
specific to newer compiler versions (or specific architectures) can't
be assumed. I'm not the one making the calls as to whether the
requirements (compiling out completely on UP, compiling to no indirection
on small SMP) are relaxed or if "new enough compiler" meets them.


-- wli