This is the mail archive of the
mailing list for the GCC project.
Re: Proposal for merging scalar-storage-order branch into mainline
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Eric Botcazou <ebotcazou at adacore dot com>, Andrew Pinski <pinskia at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 26 Jun 2015 09:56:24 +0200
- Subject: Re: Proposal for merging scalar-storage-order branch into mainline
- Authentication-results: sourceware.org; auth=none
- References: <2354857 dot 0uXrE6NL1R at polaris> <CAFiYyc0aVBYeT2Utr9=NxKVLGMEPWMBR7Qb+=ataQG93fgw55w at mail dot gmail dot com> <942B0474-BB29-4417-BD62-65A22DF0BA24 at gmail dot com> <2378875 dot nh2BShqZTT at polaris> <558C3446 dot 9040205 at redhat dot com>
On Thu, Jun 25, 2015 at 7:03 PM, Jeff Law <email@example.com> wrote:
> On 06/09/2015 10:20 AM, Eric Botcazou wrote:
>>> Because some folks don't want to audit their code to where to add
>>> I am serious people have legacy big-endian code they want to run little
>>> endian. There is a reason this is around in the first place. Developers
>> That's a little rough, but essentially correct in our experience.
> Agreed on both points. These legacy codebases can be large and full
> auditing may not really be that feasible.
Well - they need a full audit anyway to slap those endian attributes on the
appropriate structures. We are not, after all, introducing a -fbig-endian
"Legacy code base" and "new compiler feature" don't mix in my mind.