[OE-core] [PATCH 2/2] gcc: Avoid non-aligned access for ARM5e

Phil Blundell pb at pbcl.net
Wed Oct 14 13:31:49 UTC 2015


On Tue, 2015-10-13 at 09:18 -0300, Otavio Salvador wrote:
> On Tue, Oct 13, 2015 at 9:07 AM, Phil Blundell <pb at pbcl.net> wrote:
> > On Tue, 2015-10-13 at 08:45 -0300, Otavio Salvador wrote:
> > > I understand Khem is excitant to include more non-upstreamed
> > > patches
> > > into GCC but I would prefer to have it included and Java working
> > > fine
> > > than a local patch applied forever. :-(
> > 
> > Maybe you'd like to file a bug against upstream GCC in that case. 
> >  I
> > think Khem already suggested this to Jens but he said he had "no
> > time"
> > to do that.
> 
> We don't require upstream bugzilla items for patches in all recipes 
> so GCC should not be an exception. Sorry but I don't buy this 
> argument and I think the patch is clear and short enough to go in.

GCC is not necessarily an exception to that rule.  If the patch was a
correct and proper fix for the bug then I would be happy to see it
installed even without an upstream bugzilla entry.  But that is not the
case here: the patch is, at best, a hack which happens to work around
the problem in some circumstances.  It is not clear what the underlying
bug is, or whether the patch is sufficient to avoid the bug in all
cases (i.e. whether it might in fact happen for ARMv6 as well).  

Without knowing more about the underlying GCC bug it will be very diffi
cult to determine when the actual bug has been fixed and it is safe to
remove the patch, in which case we might end up carrying the patch
around forever.

Nor is the patch entirely harmless: turning off LDRD/STRD instructions
across the board will cause code size and performance to get slightly
worse for all users of the compiler.

If none of the proponents of the patch are prepared to make the small
amount of effort required to file an upstream bug then it's not at all
obvious to me that oe-core as a project should accept these various
burdens associated with installing this patch.

p.




More information about the Openembedded-core mailing list