Re: Kernel build error in hwpmc with system GNU cc

On Thu, May 02, 2013 at 04:12:36PM +0200, Davide Italiano wrote:
> On Thu, May 2, 2013 at 3:42 PM, Andrey Chernov <ache_at_freebsd.org> wrote:
> > On 02.05.2013 14:06, Davide Italiano wrote:
> >>> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_core.c:1935: warning: 'map' may be used uninitialized in this function
> >>> *** [hwpmc_core.o] Error code 1
> >
> >> You can find a patch attached at the end of this mail that should fix
> >> the problem.
> >
> > Thanks, it fix this warning.
> >
> >> More generally speaking, why are you building -CURRENT using GCC while
> >> the default compiler has been clang since November 2012?
> >
> > 1) clang is not ready for production, it is too buggy. See its fixes
> > rate for very common things 'must work' in every compiler. It is
> > included into -current not because of its quality, but to involve
> > developers into clang bugfixes to make its progress faster, and
> > personally me don't want to find clang bugs.
> >
> > 2) Its build time is too long.
> >
> > 3) It generates bigger code.
> >
> >> Putting the additional burden of
> >> testing on the committer because two compilers are supported at the
> >> same time doesn't scale really well, at least according to me.
> >
> > You'll hit this error later in any case, attempting to MFC your changes
> > to -stable with GNU cc.
> >
> > --
> > bitcoin:13fGiNutKNHcVSsgtGQ7bQ5kgUKgEQHn7N
> 
> 
> I won't object about your 2) and 3), but if you fear to hit bugs you
> shouldn't probably run -CURRENT.
> About the backport, I faced the problem of adapting code in the past
> when merging to stable releases, so this is actually a different
> problem. If I'd blindly merged the incrimined change to 9-STABLE
> without building and notifying the GCC warning, then I would expect
> you ranting at me because of build failure.
> There's a notion of "default compiler" in 9 and in 10 and they're
> different. My opinion is that people should live with it, and unless
> someone will introduce some mechanism a-la redports.org to overcome
> the issue, I will take my risks committing changes and fixing failures
> if they occur. It's already really difficult to have tinderbox not
> ranting these days, adding another compiler just result in another
> dimension of complexity in the whole scenario.

I experienced the same issues e.g. with the TTM commit, on somewhat
bigger scale. There were 3 or 4 problems compiling the code with gcc,
which were silently accepted by clang. Most ridiculous was clang silence
on the double-declaration of the functions.

For myself, I decided after the episode that I am morally unblended if
default build is fine after the commit. For any compile issues reported
by users with non-default compilers, I obviously take a look and do fix
if possible, but I certainly do not intend to even try to test with
non-default compiler on my own.