On Tue, 4 Mar 2014, Marc Glisse wrote:
> On Tue, 4 Mar 2014, Richard Biener wrote:
>
> > We're doing the LTO bytecode version check only for two section
> > types at the moment - specifically _not_ for the first section
> > we read. Which causes us to crash instead of reporting a
> > version mis
On Tue, 4 Mar 2014, Richard Biener wrote:
We're doing the LTO bytecode version check only for two section
types at the moment - specifically _not_ for the first section
we read. Which causes us to crash instead of reporting a
version mismatch ...
Not for 4.9, but when the object is fat, could
On Tue, 4 Mar 2014, Richard Biener wrote:
> On Tue, 4 Mar 2014, Jan-Benedict Glaw wrote:
>
> > On Tue, 2014-03-04 12:22:12 +0100, Richard Biener wrote:
> > >
> > > We're doing the LTO bytecode version check only for two section
> > > types at the moment - specifically _not_ for the first sectio
On Tue, 4 Mar 2014, Jan-Benedict Glaw wrote:
> On Tue, 2014-03-04 12:22:12 +0100, Richard Biener wrote:
> >
> > We're doing the LTO bytecode version check only for two section
> > types at the moment - specifically _not_ for the first section
> > we read. Which causes us to crash instead of rep
On Tue, 2014-03-04 12:22:12 +0100, Richard Biener wrote:
>
> We're doing the LTO bytecode version check only for two section
> types at the moment - specifically _not_ for the first section
> we read. Which causes us to crash instead of reporting a
> version mismatch ...
>
> Fixed by doing the
We're doing the LTO bytecode version check only for two section
types at the moment - specifically _not_ for the first section
we read. Which causes us to crash instead of reporting a
version mismatch ...
Fixed by doing the version check in the most appropriate place.
LTO bootstrapped on x86_64
