On Wed, Jan 07, 2015 at 04:12:47PM +1100, Anton Blanchard wrote:
> Hi Alan,
>
> > Right. This is really an rs6000 backend bug. We describe one of the
> > indirect calls that go wrong here as
> >
> > (call_insn 108 107 109 13 (parallel [
> > (set (reg:DI 3 3)
> > (cal
On Wed, 2015-01-07 at 16:12 +1100, Anton Blanchard wrote:
> Thanks for looking into this. Does that mean we were just getting lucky
> with the previous version:
>
> static inline struct thread_info *current_thread_info(void)
> {
> register unsigned long sp asm("r1");
>
> return (s
Hi Alan,
> Right. This is really an rs6000 backend bug. We describe one of the
> indirect calls that go wrong here as
>
> (call_insn 108 107 109 13 (parallel [
> (set (reg:DI 3 3)
> (call (mem:SI (reg:DI 288) [0 *_67 S4 A8])
> (const_int 64 [0x40]
On Thu, Dec 18, 2014 at 05:25:46PM +1100, Anton Blanchard wrote:
> On Thu, 18 Dec 2014 16:11:54 +1100
> Michael Ellerman wrote:
>
> > On Wed, 2014-12-17 at 02:16 +0100, Alexander Graf wrote:
> > > On 31.10.14 04:47, Anton Blanchard wrote:
> > > > LLVM doesn't support local named register variable
On Wed, 2014-12-17 at 10:27 +0100, Alexander Graf wrote:
>
> On 17.12.14 04:44, Anton Blanchard wrote:
> > Hi Alex,
> >
> >> Git bisect managed to point me to this commit as the offender for
> >> OOPSes on e5500 and e6500 (and maybe the G4 as well, not sure).
> >>
> >> Doing a git revert of this
On 18.12.14 07:25, Anton Blanchard wrote:
> On Thu, 18 Dec 2014 16:11:54 +1100
> Michael Ellerman wrote:
>
>> On Wed, 2014-12-17 at 02:16 +0100, Alexander Graf wrote:
>>> On 31.10.14 04:47, Anton Blanchard wrote:
LLVM doesn't support local named register variables and is
unlikely to.
On 18.12.14 06:11, Michael Ellerman wrote:
> On Wed, 2014-12-17 at 02:16 +0100, Alexander Graf wrote:
>> On 31.10.14 04:47, Anton Blanchard wrote:
>>> LLVM doesn't support local named register variables and is unlikely
>>> to. current_thread_info is using one, fix it by moving it out and
>>> call
On Thu, 18 Dec 2014 16:11:54 +1100
Michael Ellerman wrote:
> On Wed, 2014-12-17 at 02:16 +0100, Alexander Graf wrote:
> > On 31.10.14 04:47, Anton Blanchard wrote:
> > > LLVM doesn't support local named register variables and is
> > > unlikely to. current_thread_info is using one, fix it by movin
On Wed, 2014-12-17 at 02:16 +0100, Alexander Graf wrote:
> On 31.10.14 04:47, Anton Blanchard wrote:
> > LLVM doesn't support local named register variables and is unlikely
> > to. current_thread_info is using one, fix it by moving it out and
> > calling it __current_r1().
> >
> > I gave it a bit
On 17.12.14 04:44, Anton Blanchard wrote:
> Hi Alex,
>
>> Git bisect managed to point me to this commit as the offender for
>> OOPSes on e5500 and e6500 (and maybe the G4 as well, not sure).
>>
>> Doing a git revert of this commit on top of linus/master makes things
>> work fine for me again.
>
Hi Alex,
> Git bisect managed to point me to this commit as the offender for
> OOPSes on e5500 and e6500 (and maybe the G4 as well, not sure).
>
> Doing a git revert of this commit on top of linus/master makes things
> work fine for me again.
Ouch, sorry for that, I'll work to reproduce. What gc
On 31.10.14 04:47, Anton Blanchard wrote:
> LLVM doesn't support local named register variables and is unlikely
> to. current_thread_info is using one, fix it by moving it out and
> calling it __current_r1().
>
> I gave it a bit of an obscure name because we don't want anyone else
> using it - the
LLVM doesn't support local named register variables and is unlikely
to. current_thread_info is using one, fix it by moving it out and
calling it __current_r1().
I gave it a bit of an obscure name because we don't want anyone else
using it - they should use current_stack_pointer(). This specific
ca
13 matches
Mail list logo
