On 23/07/12 14:57, Ulrich Weigand wrote:
> Richard Earnshaw wrote:
Hmm, I wonder if we should just unconditionally call split_all_insns()
at the start of md_reorg when -O0. This would address your problem, but
have the added benefit that the length calculations would be more
ac
Richard Earnshaw wrote:
> >> Hmm, I wonder if we should just unconditionally call split_all_insns()
> >> at the start of md_reorg when -O0. This would address your problem, but
> >> have the added benefit that the length calculations would be more
> >> accurate. We're going to have to split the i
Richard Earnshaw wrote:
> On 17/07/12 16:17, Ulrich Weigand wrote:
> > Richard Earnshaw wrote:
> >
> >> Hmm, I wonder if we should just unconditionally call split_all_insns()
> >> at the start of md_reorg when -O0. This would address your problem, but
> >> have the added benefit that the length ca
On 17/07/12 16:17, Ulrich Weigand wrote:
> Richard Earnshaw wrote:
>
>> Hmm, I wonder if we should just unconditionally call split_all_insns()
>> at the start of md_reorg when -O0. This would address your problem, but
>> have the added benefit that the length calculations would be more
>> accurat
Richard Earnshaw wrote:
> Hmm, I wonder if we should just unconditionally call split_all_insns()
> at the start of md_reorg when -O0. This would address your problem, but
> have the added benefit that the length calculations would be more
> accurate. We're going to have to split the insns anyway
On 16/07/12 14:45, Ulrich Weigand wrote:
> Hello,
>
> when testing an out-of-tree patch I ran into a latent bug.
> The symptom is error messages along the lines of
> /tmp/cc6q0E3x.s:38: Error: co-processor offset out of range
> caused by an out-of-range reference to a literal pool constant.
> This
