This is the mail archive of the
mailing list for the GCC project.
Re: Proposal for merging scalar-storage-order branch into mainline
- From: Jeff Law <law at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail 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 10:01:13 -0600
- 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> <CAFiYyc1-b+qQ+6Qn-_BM68Ox2aNrv3swVxYtY8oo5R_DVd=vSg at mail dot gmail dot com>
On 06/26/2015 01:56 AM, Richard Biener wrote:
On Thu, Jun 25, 2015 at 7:03 PM, Jeff Law <firstname.lastname@example.org> 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
The cases I'm aware of would *love* a -fbig-endian switch :-)
Assume the legacy platform didn't use GCC (because GCC wasn't a viable
option way back when the now legacy platform was state-of-the-art),
while the new platform will use GCC and will have an endianness change.
In that case features to ease the pain of migration make a goodly
amount of sense.
"Legacy code base" and "new compiler feature" don't mix in my mind.