c/s 14420 (gcc 3.4+ required)

c/s 14420 (gcc 3.4+ required)

[Jan Beulich]

Keir,

what are the exact issues that required this change? SLES9 being based on
gcc 3.3.3 makes it pretty undesirable for me/us to have this kind of a
requirement. Despite me certainly being able to compile newer gcc-s (I
actually have these around all the time), the mere fact to remember to pass
a CC= each time I want to build Xen is going to make this cumbersome.

Hence I'd like to understand the underlying issue(s), see whether they apply
to the 3.3.x versions we have in use (aside of SLES9 I also continue to have
one 9.0 system around that I use for regular building and testing).

Thanks, Jan

Re: c/s 14420 (gcc 3.4+ required)

[Keir Fraser]

On 19/3/07 09:35, "Jan Beulich" <jbeulich@novell.com> wrote:

> what are the exact issues that required this change? SLES9 being based on
> gcc 3.3.3 makes it pretty undesirable for me/us to have this kind of a
> requirement. Despite me certainly being able to compile newer gcc-s (I
> actually have these around all the time), the mere fact to remember to pass
> a CC= each time I want to build Xen is going to make this cumbersome.
> 
> Hence I'd like to understand the underlying issue(s), see whether they apply
> to the 3.3.x versions we have in use (aside of SLES9 I also continue to have
> one 9.0 system around that I use for regular building and testing).

It's fine to build Xenolinux with older gcc versions. The new constraint is
just for the hypervisor itself, plus the toolstack. The issue is that all
gcc 3.3.x miscompile alignment attributes hidden inside typedefs, which we
were having to work around. It's not a big issue (the workaround in this
case is small), but gcc 3.4.0 has been available now for three years, and I
wouldn't recommend anyone to run a distro as old as SLES9 as their dom0
anyway (I'm thinking particularly of the fact that we rely heavily on
hotplug/udev, and I know there were issues with older versions of udev).
Also, I like the defensive position of supporting a continually
'sliding-window' of modern gcc's to limit our exposure to compiler bugs
(which are inevitably present in any gcc version and which complex code like
Linux or Xen is bound to trip up on from time to time).

I'm happy to consider falling back to support of gcc 3.3 if there's a good
reason. However I don't think that not being able to build on a pretty old
distro really counts. Upgrade. ;-)

 -- Keir

Re: c/s 14420 (gcc 3.4+ required)

[Jan Beulich]

>>> Keir Fraser <keir@xensource.com> 19.03.07 10:51 >>>
>On 19/3/07 09:35, "Jan Beulich" <jbeulich@novell.com> wrote:
>
>> what are the exact issues that required this change? SLES9 being based on
>> gcc 3.3.3 makes it pretty undesirable for me/us to have this kind of a
>> requirement. Despite me certainly being able to compile newer gcc-s (I
>> actually have these around all the time), the mere fact to remember to pass
>> a CC= each time I want to build Xen is going to make this cumbersome.
>> 
>> Hence I'd like to understand the underlying issue(s), see whether they apply
>> to the 3.3.x versions we have in use (aside of SLES9 I also continue to have
>> one 9.0 system around that I use for regular building and testing).
>
>It's fine to build Xenolinux with older gcc versions. The new constraint is
>just for the hypervisor itself, plus the toolstack. The issue is that all
>gcc 3.3.x miscompile alignment attributes hidden inside typedefs, which we
>were having to work around. It's not a big issue (the workaround in this
>case is small), but gcc 3.4.0 has been available now for three years, and I
>wouldn't recommend anyone to run a distro as old as SLES9 as their dom0
>anyway...

I just scanned the tree and couldn't spot any such instance. Could you point
me to one?

Jan

Re: c/s 14420 (gcc 3.4+ required)

[Jan Beulich]

>>> "Jan Beulich" <jbeulich@novell.com> 19.03.07 13:36 >>>
>>>> Keir Fraser <keir@xensource.com> 19.03.07 10:51 >>>
>>On 19/3/07 09:35, "Jan Beulich" <jbeulich@novell.com> wrote:
>>
>>> what are the exact issues that required this change? SLES9 being based on
>>> gcc 3.3.3 makes it pretty undesirable for me/us to have this kind of a
>>> requirement. Despite me certainly being able to compile newer gcc-s (I
>>> actually have these around all the time), the mere fact to remember to pass
>>> a CC= each time I want to build Xen is going to make this cumbersome.
>>> 
>>> Hence I'd like to understand the underlying issue(s), see whether they apply
>>> to the 3.3.x versions we have in use (aside of SLES9 I also continue to have
>>> one 9.0 system around that I use for regular building and testing).
>>
>>It's fine to build Xenolinux with older gcc versions. The new constraint is
>>just for the hypervisor itself, plus the toolstack. The issue is that all
>>gcc 3.3.x miscompile alignment attributes hidden inside typedefs, which we
>>were having to work around. It's not a big issue (the workaround in this
>>case is small), but gcc 3.4.0 has been available now for three years, and I
>>wouldn't recommend anyone to run a distro as old as SLES9 as their dom0
>>anyway...
>
>I just scanned the tree and couldn't spot any such instance. Could you point
>me to one?

Okay, sorry, I found one - I had skipped the public headers, as I assumed you
wouldn't change those, forgetting about the few __XEN__/__XEN_TOOLS__
conditionals in there.

Jan

Re: Re: c/s 14420 (gcc 3.4+ required)

[Keir Fraser]

On 19/3/07 12:44, "Jan Beulich" <jbeulich@novell.com> wrote:

>> I just scanned the tree and couldn't spot any such instance. Could you point
>> me to one?
> 
> Okay, sorry, I found one - I had skipped the public headers, as I assumed you
> wouldn't change those, forgetting about the few __XEN__/__XEN_TOOLS__
> conditionals in there.

Like I said, its hardly an insurmountable obstacle to support of gcc 3.3.x.
But in general requiring a modern gcc will avoid exposure to bugs specific
to older gcc, avoid needing workarounds for bugs in older gcc, and allow us
to use new gcc features without requiring consideration of older gcc. That's
my default position unless there's a good reason to do otherwise. Given how
much we depend on subtleties of gcc, I think this is the sane approach. :-)

 -- Keir