This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: remove the "tile" architecture from glibc

On 04/12/2017 16:03, Joseph Myers wrote:
> On Mon, 4 Dec 2017, Adhemerval Zanella wrote:
>> GCC version which does not support m68k (I do not think we have a policy
>> to remove deprecated architecture in GCC latest version where there is still
>> compiler support in older releases).
> In my view, if GCC removes support for an architecture I think that's 
> sufficient basis for obsoleting it in glibc as well rather than waiting a 
> few more years in which it becomes increasingly hard for people to test 
> changes build on that architecture because of the need to use a different 
> GCC version there.  However, we don't need to decide this now, as while 
> there are suggestions of obsoleting non-cc0 or non-LRA architectures, 
> nothing has happened yet in that regard (and even if non-cc0 architectures 
> were obsoleted for GCC 8, the removal probably wouldn't be until after GCC 
> 8 branched, so until then we'd just add --enable-obsolete to the GCC 
> configure options for such architectures in

I personally think it is too restrictive to remove the architecture in
such case if the minimum glibc required GCC version still provides support. 
I give you that it incur in a more troublesome testing because one will
need to pick an subset of supported compiler version, but in such case
we can set a policy of architecture being 'deprecated' and schedule for
future removal (maybe in a subsequent glibc release).

>> Now back to thread topic, Chris Metcalf gave us some indications that
>> tilepro userbase and support do not justify the maintaining effort.  It
>> already has kernel ABI incompatibilities (for instance ca768667d873 fix on 
>> linux and some atomic unsupported operations that broke the build on
>> recent glibc fixes).  I think we could at least remove old tilepro
>> support. 
> Certainly we can come to separate conclusions about obsoletion for tilegx 
> and tilepro.  (Preferably obsoleting tilepro would mean the sysdeps 
> directory structure then being simplified to avoid the unnecessary 
> directory levels in tile/tilegx, just as after obsoleting ARM old-ABI I 
> eliminated the eabi/ subdirectories.)

I think this sounds like a plan for 2.27. I will try to spend some cycles
on this in following weeks.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]