The simplest test case I've found is at
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=57760
I did/do not have time to check it closely now but at first sight it's
the same I've found.
> > I thought about it, I'm just afraid too much kernel wouldn't build.
>
> Then it won't build. Use a different compiler.
If we know the impact [how wildly broken compilers are used] we could
decide about the approach, IMHO.
Please note, this is not only about how to make build fail but how not
to waste potentially significant users and developers time if one
circumvent the blocking phase and starts distributing [intentional or
not] the broken binaries. Bigger the impact the bigger the chance it
happens.
> > This bug is in most 2.95, 2.96 and according to Alan in 3.0 and early
> > 3.1) and people would just start "working around" it by commenting out
> > the check for getting something to work quickly then forgetting about
> > the issue completely.
>
> The bug report I can find,
>
> http://gcc.gnu.org/ml/gcc-patches/2001-06/msg00746.html
>
> was fixed before gcc 3.0.0 was released. So if this is
> a different bug...
Could be also the classical "copy-paste [slightly change one occasion]
then fix one occasion" type of bug? I've never looked the quality of
the gcc source. I really don't know.
Szaka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/