Joseph S. Myers wrote:
On Wed, 1 Nov 2006, Ian Lance Taylor wrote:
According to the proposal, we will restore the GNU handling for
"extern inline" even when using -std=c99, which will fix the problem
when using glibc.
We definitely need to revert that until the fixincludes changes are
available. (The precise nature of the fix - whether we disable the
inlines, change them to be C99-aware or add an attribute to give yet
another form of inline function in gnu99 mode that mimics gnu89 extern
inline - is less important.)
If we restore the previous behavior, then we don't need the fixincludes
as immediately -- but since you're right that people will no doubt want
to use GCC 4.4 with RHEL3, SLES8, etc., I think you're correct that when
we do switch, we should be armed with fixincludes for GLIBC. It's
certainly not enough just to change the current GLIBC sourcebase to use
C99 semantics going forward, as we must expect that people will want to
install the software on older versions of the OS.
Thus, I hereby propose starting the 48 hour reversion timer.
I concur.
Once we have the fixincludes fixes, I don't think we need to wait for 4.4
to switch the default in gnu99 mode back to C99 inline semantics, as long
as we have those fixes during Stage 1.
I think it would be better to have GLIBC changed before changing the
behavior of the compiler. It might even be better to have a released
version of GLIBC with the changes. fixincludes causes sufficient
problems for people that ensuring that only users putting new compilers
on old systems suffer might be a good goal.
On the other hand, I agree that if we have fixincludes in place, then
4.3 would not be in any way broken on GNU/Linux, so I think this is a
judgment call.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
