Re: linux-next: Tree for Jun 21

Re: linux-next: Tree for Jun 21

[Sudip Mukherjee]

On Tuesday 21 June 2016 06:46 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20160620:

tilepro defconfig is failing while doing "make prepare" and bisect shows 
the first bad commit as:

1af5de9af138 ("locking/atomic, arch/tile: Implement 
atomic{,64}_fetch_{add,sub,and,or,xor}()")

You can find today's build log at:
https://travis-ci.org/sudipm-mukherjee/parport/jobs/139112570

Please do let me know if i can help in any way to debug/solve this.

regards
sudip

Re: linux-next: Tree for Jun 21

[Sudip Mukherjee]

On Tuesday 21 June 2016 06:46 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20160620:

tilepro defconfig is failing while doing "make prepare" and bisect shows 
the first bad commit as:

1af5de9af138 ("locking/atomic, arch/tile: Implement 
atomic{,64}_fetch_{add,sub,and,or,xor}()")

You can find today's build log at:
https://travis-ci.org/sudipm-mukherjee/parport/jobs/139112570

Please do let me know if i can help in any way to debug/solve this.

regards
sudip

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 08:01:36AM +0100, Sudip Mukherjee wrote:

> tilepro defconfig is failing while doing "make prepare" and bisect shows the
> first bad commit as:
> 
> 1af5de9af138 ("locking/atomic, arch/tile: Implement
> atomic{,64}_fetch_{add,sub,and,or,xor}()")
> 
> You can find today's build log at:
> https://travis-ci.org/sudipm-mukherjee/parport/jobs/139112570
> 
> Please do let me know if i can help in any way to debug/solve this.

I cannot reproduce, I tried both tip/master (which carries the patch you
fingered) and next/master.

My tilepro build ends in a vmlinux with just a single warning.


root@ivb-ep:/usr/src/linux-2.6# rm -rf tile-defconfig/ tile-tilepro_defconfig/
root@ivb-ep:/usr/src/linux-2.6# ./build-arch-defconfig.sh tilepro
make[1]: Entering directory `/usr/src/linux-2.6/tile-tilepro_defconfig'
  HOSTCC  scripts/basic/fixdep
  GEN     ./Makefile
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
make[1]: Leaving directory `/usr/src/linux-2.6/tile-tilepro_defconfig'
../arch/tile/lib/cacheflush.c: In function 'finv_buffer_remote':
../arch/tile/lib/cacheflush.c:146:0: warning: ignoring #pragma unroll  [-Wunknown-pragmas]
 #pragma unroll 8
 
root@ivb-ep:/usr/src/linux-2.6# ls -la tile-tilepro_defconfig/vmlinux
vmlinux    vmlinux.o  

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 08:01:36AM +0100, Sudip Mukherjee wrote:

> tilepro defconfig is failing while doing "make prepare" and bisect shows the
> first bad commit as:
> 
> 1af5de9af138 ("locking/atomic, arch/tile: Implement
> atomic{,64}_fetch_{add,sub,and,or,xor}()")
> 
> You can find today's build log at:
> https://travis-ci.org/sudipm-mukherjee/parport/jobs/139112570
> 
> Please do let me know if i can help in any way to debug/solve this.

I cannot reproduce, I tried both tip/master (which carries the patch you
fingered) and next/master.

My tilepro build ends in a vmlinux with just a single warning.


root@ivb-ep:/usr/src/linux-2.6# rm -rf tile-defconfig/ tile-tilepro_defconfig/
root@ivb-ep:/usr/src/linux-2.6# ./build-arch-defconfig.sh tilepro
make[1]: Entering directory `/usr/src/linux-2.6/tile-tilepro_defconfig'
  HOSTCC  scripts/basic/fixdep
  GEN     ./Makefile
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
make[1]: Leaving directory `/usr/src/linux-2.6/tile-tilepro_defconfig'
../arch/tile/lib/cacheflush.c: In function 'finv_buffer_remote':
../arch/tile/lib/cacheflush.c:146:0: warning: ignoring #pragma unroll  [-Wunknown-pragmas]
 #pragma unroll 8
 
root@ivb-ep:/usr/src/linux-2.6# ls -la tile-tilepro_defconfig/vmlinux
vmlinux    vmlinux.o  

Re: linux-next: Tree for Jun 21

[Sudip Mukherjee]

On Tue, Jun 21, 2016 at 09:58:28AM +0200, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 08:01:36AM +0100, Sudip Mukherjee wrote:
> 
> > tilepro defconfig is failing while doing "make prepare" and bisect shows the
> > first bad commit as:
> > 
> > 1af5de9af138 ("locking/atomic, arch/tile: Implement
> > atomic{,64}_fetch_{add,sub,and,or,xor}()")
> > 
> > You can find today's build log at:
> > https://travis-ci.org/sudipm-mukherjee/parport/jobs/139112570
> > 
> > Please do let me know if i can help in any way to debug/solve this.
> 
> I cannot reproduce, I tried both tip/master (which carries the patch you
> fingered) and next/master.

Thats strange.
The log I gave is for next-20160621.
BTW, I am using gcc-5.3.0

regards
sudip

Re: linux-next: Tree for Jun 21

[Sudip Mukherjee]

On Tue, Jun 21, 2016 at 09:58:28AM +0200, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 08:01:36AM +0100, Sudip Mukherjee wrote:
> 
> > tilepro defconfig is failing while doing "make prepare" and bisect shows the
> > first bad commit as:
> > 
> > 1af5de9af138 ("locking/atomic, arch/tile: Implement
> > atomic{,64}_fetch_{add,sub,and,or,xor}()")
> > 
> > You can find today's build log at:
> > https://travis-ci.org/sudipm-mukherjee/parport/jobs/139112570
> > 
> > Please do let me know if i can help in any way to debug/solve this.
> 
> I cannot reproduce, I tried both tip/master (which carries the patch you
> fingered) and next/master.

Thats strange.
The log I gave is for next-20160621.
BTW, I am using gcc-5.3.0

regards
sudip

Re: linux-next: Tree for Jun 21

[Chris Metcalf]

On 6/21/2016 3:01 AM, Sudip Mukherjee wrote:
> On Tuesday 21 June 2016 06:46 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20160620:
>
> tilepro defconfig is failing while doing "make prepare" and bisect shows the first bad commit as:
>
> 1af5de9af138 ("locking/atomic, arch/tile: Implement atomic{,64}_fetch_{add,sub,and,or,xor}()")
>
> You can find today's build log at:
> https://travis-ci.org/sudipm-mukherjee/parport/jobs/139112570

On inspection, I note that the arch/tile/include/atomic_32.h header has

ATOMIC64_OP(and)
ATOMIC64_OP(or)
ATOMIC64_OP(xor)

but these should be ATOMIC64_OPS, plural.

Peter, what toolchain were you using for tilepro build testing?  You need to have a tilepro toolchain (not tilegx) and build with ARCH=tilepro.

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21

[Chris Metcalf]

On 6/21/2016 3:01 AM, Sudip Mukherjee wrote:
> On Tuesday 21 June 2016 06:46 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20160620:
>
> tilepro defconfig is failing while doing "make prepare" and bisect shows the first bad commit as:
>
> 1af5de9af138 ("locking/atomic, arch/tile: Implement atomic{,64}_fetch_{add,sub,and,or,xor}()")
>
> You can find today's build log at:
> https://travis-ci.org/sudipm-mukherjee/parport/jobs/139112570

On inspection, I note that the arch/tile/include/atomic_32.h header has

ATOMIC64_OP(and)
ATOMIC64_OP(or)
ATOMIC64_OP(xor)

but these should be ATOMIC64_OPS, plural.

Peter, what toolchain were you using for tilepro build testing?  You need to have a tilepro toolchain (not tilegx) and build with ARCH=tilepro.

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 08:08:29AM -0400, Chris Metcalf wrote:
> 
> On inspection, I note that the arch/tile/include/atomic_32.h header has
> 
> ATOMIC64_OP(and)
> ATOMIC64_OP(or)
> ATOMIC64_OP(xor)
> 
> but these should be ATOMIC64_OPS, plural.

Bugger, I'll go fix. Clearly nobody has tilepro toolchains :/

> Peter, what toolchain were you using for tilepro build testing? 

tilegx-linux-

> You need to have a tilepro toolchain (not tilegx) 

Ah, should I go use TARGET=tilepro-linux ?

> and build with ARCH=tilepro.

        tilepro)
                ARCH=tile
                CROSS_COMPILE=tilegx-linux-
                if [ "$CONFIG" == "defconfig" ] ; then
                        CONFIG=tilepro_defconfig
                fi
                ;;

So I suppose that too is wrong.

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 08:08:29AM -0400, Chris Metcalf wrote:
> 
> On inspection, I note that the arch/tile/include/atomic_32.h header has
> 
> ATOMIC64_OP(and)
> ATOMIC64_OP(or)
> ATOMIC64_OP(xor)
> 
> but these should be ATOMIC64_OPS, plural.

Bugger, I'll go fix. Clearly nobody has tilepro toolchains :/

> Peter, what toolchain were you using for tilepro build testing? 

tilegx-linux-

> You need to have a tilepro toolchain (not tilegx) 

Ah, should I go use TARGET=tilepro-linux ?

> and build with ARCH=tilepro.

        tilepro)
                ARCH=tile
                CROSS_COMPILE=tilegx-linux-
                if [ "$CONFIG" == "defconfig" ] ; then
                        CONFIG=tilepro_defconfig
                fi
                ;;

So I suppose that too is wrong.

Re: linux-next: Tree for Jun 21

[Chris Metcalf]

On 6/21/2016 8:42 AM, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 08:08:29AM -0400, Chris Metcalf wrote:
>> You need to have a tilepro toolchain (not tilegx)
> Ah, should I go use TARGET=tilepro-linux ?

Yes.

>> and build with ARCH=tilepro.
>          tilepro)
>                  ARCH=tile
>                  CROSS_COMPILE=tilegx-linux-
>                  if [ "$CONFIG" == "defconfig" ] ; then
>                          CONFIG=tilepro_defconfig
>                  fi
>                  ;;
>
> So I suppose that too is wrong.

Yup.  That's actually just building exactly what "tilegx" would build by default.

I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
so should be easy enough to include.  There's also a cross-toolchain for x64 I put
up a while ago [1] that you could grab if you wanted to try it.

[1] http://www.mellanox.com/repository/solutions/tile-scm/tilepro-x86_64.tar.bz2

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 09:47:00AM -0400, Chris Metcalf wrote:
> On 6/21/2016 8:42 AM, Peter Zijlstra wrote:
> >On Tue, Jun 21, 2016 at 08:08:29AM -0400, Chris Metcalf wrote:
> >>You need to have a tilepro toolchain (not tilegx)
> >Ah, should I go use TARGET=tilepro-linux ?
> 
> Yes.

> I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
> so should be easy enough to include.  There's also a cross-toolchain for x64 I put
> up a while ago [1] that you could grab if you wanted to try it.

I usually build my own set -- and just did. But tilepro was not
included. Lemme go do so.

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 09:47:00AM -0400, Chris Metcalf wrote:
> On 6/21/2016 8:42 AM, Peter Zijlstra wrote:
> >On Tue, Jun 21, 2016 at 08:08:29AM -0400, Chris Metcalf wrote:
> >>You need to have a tilepro toolchain (not tilegx)
> >Ah, should I go use TARGET=tilepro-linux ?
> 
> Yes.

> I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
> so should be easy enough to include.  There's also a cross-toolchain for x64 I put
> up a while ago [1] that you could grab if you wanted to try it.

I usually build my own set -- and just did. But tilepro was not
included. Lemme go do so.

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> > I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
> > so should be easy enough to include.  There's also a cross-toolchain for x64 I put
> > up a while ago [1] that you could grab if you wanted to try it.
> 
> I usually build my own set -- and just did. But tilepro was not
> included. Lemme go do so.

binutils-2_26-branch builds for tilepro-linux
gcc-6-branch does _not_ build for tilepro-linux


---

/usr/local/src/buildall/tilepro/gcc/./gcc/xgcc -B/usr/local/src/buildall/tilepro/gcc/./gcc/ -B/opt/cross/tilepro-linux/bin/ -B/opt/cross/tilepro-linux/lib/ -isystem /opt/cross/tilepro-linux/include -isystem /opt/cross/tilepro-linux/sys-include    -g -O2 -O2  -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -fPIC -I. -I. -I../.././gcc -I/usr/local/src/gcc/libgcc -I/usr/local/src/gcc/libgcc/. -I/usr/local/src/gcc/libgcc/../gcc -I/usr/local/src/gcc/libgcc/../include  -DHAVE_CC_TLS  -o unwind-sjlj.o -MT unwind-sjlj.o -MD -MP -MF unwind-sjlj.dep -fexceptions -c /usr/local/src/gcc/libgcc
 /unwind-sjlj.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from /usr/local/src/gcc/libgcc/config/tilepro/atomic.c:26:0:
/usr/local/src/gcc/libgcc/config/tilepro/atomic.h:98:24: fatal error: asm/unistd.h: No such file or directory
 #include <asm/unistd.h>
                        ^
compilation terminated.
mv -f softmpy.visT softmpy.vis
make[2]: *** [atomic.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/usr/local/src/buildall/tilepro/gcc/tilepro-linux/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/usr/local/src/buildall/tilepro/gcc'
make: *** [all] Error 2

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> > I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
> > so should be easy enough to include.  There's also a cross-toolchain for x64 I put
> > up a while ago [1] that you could grab if you wanted to try it.
> 
> I usually build my own set -- and just did. But tilepro was not
> included. Lemme go do so.

binutils-2_26-branch builds for tilepro-linux
gcc-6-branch does _not_ build for tilepro-linux


---

/usr/local/src/buildall/tilepro/gcc/./gcc/xgcc -B/usr/local/src/buildall/tilepro/gcc/./gcc/ -B/opt/cross/tilepro-linux/bin/ -B/opt/cross/tilepro-linux/lib/ -isystem /opt/cross/tilepro-linux/include -isystem /opt/cross/tilepro-linux/sys-include    -g -O2 -O2  -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -fPIC -I. -I. -I../.././gcc -I/usr/local/src/gcc/libgcc -I/usr/local/src/gcc/libgcc/. -I/usr/local/src/gcc/libgcc/../gcc -I/usr/local/src/gcc/libgcc/../include  -DHAVE_CC_TLS  -o unwind-sjlj.o -MT unwind-sjlj.o -MD -MP -MF unwind-sjlj.dep -fexceptions -c /usr/local/src/gcc/libgcc/unwind-sjlj.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from /usr/local/src/gcc/libgcc/config/tilepro/atomic.c:26:0:
/usr/local/src/gcc/libgcc/config/tilepro/atomic.h:98:24: fatal error: asm/unistd.h: No such file or directory
 #include <asm/unistd.h>
                        ^
compilation terminated.
mv -f softmpy.visT softmpy.vis
make[2]: *** [atomic.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/usr/local/src/buildall/tilepro/gcc/tilepro-linux/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/usr/local/src/buildall/tilepro/gcc'
make: *** [all] Error 2

Re: linux-next: Tree for Jun 21

[Chris Metcalf]

On 6/21/2016 10:14 AM, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
>>> I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
>>> so should be easy enough to include.  There's also a cross-toolchain for x64 I put
>>> up a while ago [1] that you could grab if you wanted to try it.
>> I usually build my own set -- and just did. But tilepro was not
>> included. Lemme go do so.
> binutils-2_26-branch builds for tilepro-linux
> gcc-6-branch does _not_ build for tilepro-linux

That's unexpected.  I'll pass this over to our compiler folks. Thanks!

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21

[Chris Metcalf]

On 6/21/2016 10:14 AM, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
>>> I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
>>> so should be easy enough to include.  There's also a cross-toolchain for x64 I put
>>> up a while ago [1] that you could grab if you wanted to try it.
>> I usually build my own set -- and just did. But tilepro was not
>> included. Lemme go do so.
> binutils-2_26-branch builds for tilepro-linux
> gcc-6-branch does _not_ build for tilepro-linux

That's unexpected.  I'll pass this over to our compiler folks. Thanks!

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 10:20:39AM -0400, Chris Metcalf wrote:
> On 6/21/2016 10:14 AM, Peter Zijlstra wrote:
> >On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> >>>I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
> >>>so should be easy enough to include.  There's also a cross-toolchain for x64 I put
> >>>up a while ago [1] that you could grab if you wanted to try it.
> >>I usually build my own set -- and just did. But tilepro was not
> >>included. Lemme go do so.
> >binutils-2_26-branch builds for tilepro-linux
> >gcc-6-branch does _not_ build for tilepro-linux
> 
> That's unexpected.  I'll pass this over to our compiler folks. Thanks!

If you need more info like gcc-configure, gcc-build logs or exact
gcc-6-branch commitid, please let me know.

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 10:20:39AM -0400, Chris Metcalf wrote:
> On 6/21/2016 10:14 AM, Peter Zijlstra wrote:
> >On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> >>>I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
> >>>so should be easy enough to include.  There's also a cross-toolchain for x64 I put
> >>>up a while ago [1] that you could grab if you wanted to try it.
> >>I usually build my own set -- and just did. But tilepro was not
> >>included. Lemme go do so.
> >binutils-2_26-branch builds for tilepro-linux
> >gcc-6-branch does _not_ build for tilepro-linux
> 
> That's unexpected.  I'll pass this over to our compiler folks. Thanks!

If you need more info like gcc-configure, gcc-build logs or exact
gcc-6-branch commitid, please let me know.

Re: linux-next: Tree for Jun 21

[Sudip Mukherjee]

On Tue, Jun 21, 2016 at 04:14:35PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> > > I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
> > > so should be easy enough to include.  There's also a cross-toolchain for x64 I put
> > > up a while ago [1] that you could grab if you wanted to try it.
> > 
> > I usually build my own set -- and just did. But tilepro was not
> > included. Lemme go do so.
> 
> binutils-2_26-branch builds for tilepro-linux
> gcc-6-branch does _not_ build for tilepro-linux

I have not tried with binutils-2_26. But if you want my compiler, its at
http://chat.vectorindia.net/crosstool/x86_64/5.3.0/tilepro-linux-gnu.tar.xz

regards
sudip

Re: linux-next: Tree for Jun 21

[Sudip Mukherjee]

On Tue, Jun 21, 2016 at 04:14:35PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> > > I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
> > > so should be easy enough to include.  There's also a cross-toolchain for x64 I put
> > > up a while ago [1] that you could grab if you wanted to try it.
> > 
> > I usually build my own set -- and just did. But tilepro was not
> > included. Lemme go do so.
> 
> binutils-2_26-branch builds for tilepro-linux
> gcc-6-branch does _not_ build for tilepro-linux

I have not tried with binutils-2_26. But if you want my compiler, its at
http://chat.vectorindia.net/crosstool/x86_64/5.3.0/tilepro-linux-gnu.tar.xz

regards
sudip

Re: linux-next: Tree for Jun 21

[Chris Metcalf]

On 6/21/2016 10:14 AM, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
>>> I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
>>> so should be easy enough to include.  There's also a cross-toolchain for x64 I put
>>> up a while ago [1] that you could grab if you wanted to try it.
>> I usually build my own set -- and just did. But tilepro was not
>> included. Lemme go do so.
> binutils-2_26-branch builds for tilepro-linux
> gcc-6-branch does _not_ build for tilepro-linux

I figured I would take a stab at diagnosing this myself, and it looks like the
toolchain build assumes that the kernel headers have already been installed
and therefore we have <asm/unistd.h> available.  This actually seems like
a reasonable prerequisite for building the toolchain.  I'm guessing you
don't?  Should you?  Or perhaps the compiler shouldn't make that assumption?
This has been true since gcc 4.x when tilepro support was first added.

In any case if you replace the #include <asm/unistd.h> with

#define __NR_FAST_cmpxchg    -1
#define __NR_FAST_atomic_update    -2
#define __NR_FAST_cmpxchg64    -3

that should also probably fix it, though I haven't tested it.  It probably
wouldn't be crazy to just put those #defines directly in tilepro's atomic.h,
since it's not like those fast system call numbers will ever change.

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21

[Chris Metcalf]

On 6/21/2016 10:14 AM, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
>>> I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
>>> so should be easy enough to include.  There's also a cross-toolchain for x64 I put
>>> up a while ago [1] that you could grab if you wanted to try it.
>> I usually build my own set -- and just did. But tilepro was not
>> included. Lemme go do so.
> binutils-2_26-branch builds for tilepro-linux
> gcc-6-branch does _not_ build for tilepro-linux

I figured I would take a stab at diagnosing this myself, and it looks like the
toolchain build assumes that the kernel headers have already been installed
and therefore we have <asm/unistd.h> available.  This actually seems like
a reasonable prerequisite for building the toolchain.  I'm guessing you
don't?  Should you?  Or perhaps the compiler shouldn't make that assumption?
This has been true since gcc 4.x when tilepro support was first added.

In any case if you replace the #include <asm/unistd.h> with

#define __NR_FAST_cmpxchg    -1
#define __NR_FAST_atomic_update    -2
#define __NR_FAST_cmpxchg64    -3

that should also probably fix it, though I haven't tested it.  It probably
wouldn't be crazy to just put those #defines directly in tilepro's atomic.h,
since it's not like those fast system call numbers will ever change.

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 11:26:19AM -0400, Chris Metcalf wrote:
> On 6/21/2016 10:14 AM, Peter Zijlstra wrote:
> >On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> >>>I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
> >>>so should be easy enough to include.  There's also a cross-toolchain for x64 I put
> >>>up a while ago [1] that you could grab if you wanted to try it.
> >>I usually build my own set -- and just did. But tilepro was not
> >>included. Lemme go do so.
> >binutils-2_26-branch builds for tilepro-linux
> >gcc-6-branch does _not_ build for tilepro-linux
> 
> I figured I would take a stab at diagnosing this myself, and it looks like the
> toolchain build assumes that the kernel headers have already been installed
> and therefore we have <asm/unistd.h> available.  This actually seems like
> a reasonable prerequisite for building the toolchain.  I'm guessing you
> don't?  Should you?  Or perhaps the compiler shouldn't make that assumption?

I can build:

ls -la /opt/cross/bin/*-gcc | wc -l
27

compilers without installing kernel headers.

> This has been true since gcc 4.x when tilepro support was first added.
> 
> In any case if you replace the #include <asm/unistd.h> with
> 
> #define __NR_FAST_cmpxchg    -1
> #define __NR_FAST_atomic_update    -2
> #define __NR_FAST_cmpxchg64    -3
> 
> that should also probably fix it, though I haven't tested it.  It probably
> wouldn't be crazy to just put those #defines directly in tilepro's atomic.h,
> since it's not like those fast system call numbers will ever change.

OK, I'll go test that right after I've got the kid in bed .. I'll let
you know.

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 11:26:19AM -0400, Chris Metcalf wrote:
> On 6/21/2016 10:14 AM, Peter Zijlstra wrote:
> >On Tue, Jun 21, 2016 at 04:04:08PM +0200, Peter Zijlstra wrote:
> >>>I'm not sure who builds the toolchains, but tilepro is in upstream gcc/binutils/etc
> >>>so should be easy enough to include.  There's also a cross-toolchain for x64 I put
> >>>up a while ago [1] that you could grab if you wanted to try it.
> >>I usually build my own set -- and just did. But tilepro was not
> >>included. Lemme go do so.
> >binutils-2_26-branch builds for tilepro-linux
> >gcc-6-branch does _not_ build for tilepro-linux
> 
> I figured I would take a stab at diagnosing this myself, and it looks like the
> toolchain build assumes that the kernel headers have already been installed
> and therefore we have <asm/unistd.h> available.  This actually seems like
> a reasonable prerequisite for building the toolchain.  I'm guessing you
> don't?  Should you?  Or perhaps the compiler shouldn't make that assumption?

I can build:

ls -la /opt/cross/bin/*-gcc | wc -l
27

compilers without installing kernel headers.

> This has been true since gcc 4.x when tilepro support was first added.
> 
> In any case if you replace the #include <asm/unistd.h> with
> 
> #define __NR_FAST_cmpxchg    -1
> #define __NR_FAST_atomic_update    -2
> #define __NR_FAST_cmpxchg64    -3
> 
> that should also probably fix it, though I haven't tested it.  It probably
> wouldn't be crazy to just put those #defines directly in tilepro's atomic.h,
> since it's not like those fast system call numbers will ever change.

OK, I'll go test that right after I've got the kid in bed .. I'll let
you know.

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 07:06:07PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 11:26:19AM -0400, Chris Metcalf wrote:
> > This has been true since gcc 4.x when tilepro support was first added.
> > 
> > In any case if you replace the #include <asm/unistd.h> with
> > 
> > #define __NR_FAST_cmpxchg    -1
> > #define __NR_FAST_atomic_update    -2
> > #define __NR_FAST_cmpxchg64    -3
> > 
> > that should also probably fix it, though I haven't tested it.  It probably
> > wouldn't be crazy to just put those #defines directly in tilepro's atomic.h,
> > since it's not like those fast system call numbers will ever change.

OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
can build me a kernel with it.

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 07:06:07PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 11:26:19AM -0400, Chris Metcalf wrote:
> > This has been true since gcc 4.x when tilepro support was first added.
> > 
> > In any case if you replace the #include <asm/unistd.h> with
> > 
> > #define __NR_FAST_cmpxchg    -1
> > #define __NR_FAST_atomic_update    -2
> > #define __NR_FAST_cmpxchg64    -3
> > 
> > that should also probably fix it, though I haven't tested it.  It probably
> > wouldn't be crazy to just put those #defines directly in tilepro's atomic.h,
> > since it's not like those fast system call numbers will ever change.

OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
can build me a kernel with it.

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 07:29:18PM +0200, Peter Zijlstra wrote:

> OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
> can build me a kernel with it.

The below, much larger than desired, patch seems to make it go again.

I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
with the builtin C11 atomic primitives.

You want me to rename them all to regain consistent naming?

---
 arch/tile/include/asm/atomic_32.h |   16 ++++++++--------
 arch/tile/include/asm/futex.h     |    6 +++---
 arch/tile/lib/atomic_32.c         |    8 ++++----
 arch/tile/lib/atomic_asm_32.S     |    8 ++++----
 4 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/arch/tile/include/asm/atomic_32.h b/arch/tile/include/asm/atomic_32.h
index da8eb4e..e063825 100644
--- a/arch/tile/include/asm/atomic_32.h
+++ b/arch/tile/include/asm/atomic_32.h
@@ -143,15 +143,15 @@ static inline void atomic64_##op(long long i, atomic64_t *v)	\
 {								\
 	_atomic64_fetch_##op(&v->counter, i);			\
 }								\
-static inline void atomic64_##op(long long i, atomic64_t *v)	\
+static inline long long atomic64_fetch_##op(long long i, atomic64_t *v)	\
 {								\
 	smp_mb();						\
 	return _atomic64_fetch_##op(&v->counter, i);		\
 }
 
-ATOMIC64_OP(and)
-ATOMIC64_OP(or)
-ATOMIC64_OP(xor)
+ATOMIC64_OPS(and)
+ATOMIC64_OPS(or)
+ATOMIC64_OPS(xor)
 
 #undef ATOMIC64_OPS
 
@@ -272,10 +272,10 @@ extern struct __get_user __atomic_xchg(volatile int *p, int *lock, int n);
 extern struct __get_user __atomic_xchg_add(volatile int *p, int *lock, int n);
 extern struct __get_user __atomic_xchg_add_unless(volatile int *p,
 						  int *lock, int o, int n);
-extern struct __get_user __atomic_fetch_or(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_fetch_and(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_fetch_andn(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_fetch_xor(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_fetch_or(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_fetch_and(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_fetch_andn(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_fetch_xor(volatile int *p, int *lock, int n);
 extern long long __atomic64_cmpxchg(volatile long long *p, int *lock,
 					long long o, long long n);
 extern long long __atomic64_xchg(volatile long long *p, int *lock, long long n);
diff --git a/arch/tile/include/asm/futex.h b/arch/tile/include/asm/futex.h
index 1a6ef1b..479b28b 100644
--- a/arch/tile/include/asm/futex.h
+++ b/arch/tile/include/asm/futex.h
@@ -82,9 +82,9 @@
 
 #define __futex_set() __futex_call(__atomic_xchg)
 #define __futex_add() __futex_call(__atomic_xchg_add)
-#define __futex_or() __futex_call(__atomic_or)
-#define __futex_andn() __futex_call(__atomic_andn)
-#define __futex_xor() __futex_call(__atomic_xor)
+#define __futex_or() __futex_call(__atomic32_fetch_or)
+#define __futex_andn() __futex_call(__atomic32_fetch_andn)
+#define __futex_xor() __futex_call(__atomic32_fetch_xor)
 
 #define __futex_cmpxchg()						\
 	{								\
diff --git a/arch/tile/lib/atomic_32.c b/arch/tile/lib/atomic_32.c
index 5b6bd93..64d12fa 100644
--- a/arch/tile/lib/atomic_32.c
+++ b/arch/tile/lib/atomic_32.c
@@ -90,25 +90,25 @@ EXPORT_SYMBOL(_atomic_cmpxchg);
 
 unsigned long _atomic_fetch_or(volatile unsigned long *p, unsigned long mask)
 {
-	return __atomic_fetch_or((int *)p, __atomic_setup(p), mask).val;
+	return __atomic32_fetch_or((int *)p, __atomic_setup(p), mask).val;
 }
 EXPORT_SYMBOL(_atomic_fetch_or);
 
 unsigned long _atomic_fetch_and(volatile unsigned long *p, unsigned long mask)
 {
-	return __atomic_fetch_and((int *)p, __atomic_setup(p), mask).val;
+	return __atomic32_fetch_and((int *)p, __atomic_setup(p), mask).val;
 }
 EXPORT_SYMBOL(_atomic_fetch_and);
 
 unsigned long _atomic_fetch_andn(volatile unsigned long *p, unsigned long mask)
 {
-	return __atomic_fetch_andn((int *)p, __atomic_setup(p), mask).val;
+	return __atomic32_fetch_andn((int *)p, __atomic_setup(p), mask).val;
 }
 EXPORT_SYMBOL(_atomic_fetch_andn);
 
 unsigned long _atomic_fetch_xor(volatile unsigned long *p, unsigned long mask)
 {
-	return __atomic_fetch_xor((int *)p, __atomic_setup(p), mask).val;
+	return __atomic32_fetch_xor((int *)p, __atomic_setup(p), mask).val;
 }
 EXPORT_SYMBOL(_atomic_fetch_xor);
 
diff --git a/arch/tile/lib/atomic_asm_32.S b/arch/tile/lib/atomic_asm_32.S
index 507abdd..e78fed0 100644
--- a/arch/tile/lib/atomic_asm_32.S
+++ b/arch/tile/lib/atomic_asm_32.S
@@ -177,10 +177,10 @@ atomic_op _xchg, 32, "move r24, r2"
 atomic_op _xchg_add, 32, "add r24, r22, r2"
 atomic_op _xchg_add_unless, 32, \
 	"sne r26, r22, r2; { bbns r26, 3f; add r24, r22, r3 }"
-atomic_op _fetch_or, 32, "or r24, r22, r2"
-atomic_op _fetch_and, 32, "and r24, r22, r2"
-atomic_op _fetch_andn, 32, "nor r2, r2, zero; and r24, r22, r2"
-atomic_op _fetch_xor, 32, "xor r24, r22, r2"
+atomic_op 32_fetch_or, 32, "or r24, r22, r2"
+atomic_op 32_fetch_and, 32, "and r24, r22, r2"
+atomic_op 32_fetch_andn, 32, "nor r2, r2, zero; and r24, r22, r2"
+atomic_op 32_fetch_xor, 32, "xor r24, r22, r2"
 
 atomic_op 64_cmpxchg, 64, "{ seq r26, r22, r2; seq r27, r23, r3 }; \
 	{ bbns r26, 3f; move r24, r4 }; { bbns r27, 3f; move r25, r5 }"

Re: linux-next: Tree for Jun 21

[Chris Metcalf]

On 6/21/2016 2:28 PM, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 07:29:18PM +0200, Peter Zijlstra wrote:
>
>> >OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
>> >can build me a kernel with it.
> The below, much larger than desired, patch seems to make it go again.
>
> I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
> with the builtin C11 atomic primitives.
>
> You want me to rename them all to regain consistent naming?

Yes, it's probably the right thing to do.  All the internal routines with "atomic32"
or "atomic64" I assume you mean?

So what's your build process for the cross tools, by the way?  I'm assuming
you're not doing a total bootstrap cross-tool build since you'd need minimal
kernel headers (linux/errno.h or whatever) in that case.  I assume you're using
the host headers to build the cross tool?

So I'm a little confused how the other kernel headers are working out for you,
e.g. <arch/icache.h> is referenced when building the tilegx libgcc.

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21

[Chris Metcalf]

On 6/21/2016 2:28 PM, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 07:29:18PM +0200, Peter Zijlstra wrote:
>
>> >OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
>> >can build me a kernel with it.
> The below, much larger than desired, patch seems to make it go again.
>
> I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
> with the builtin C11 atomic primitives.
>
> You want me to rename them all to regain consistent naming?

Yes, it's probably the right thing to do.  All the internal routines with "atomic32"
or "atomic64" I assume you mean?

So what's your build process for the cross tools, by the way?  I'm assuming
you're not doing a total bootstrap cross-tool build since you'd need minimal
kernel headers (linux/errno.h or whatever) in that case.  I assume you're using
the host headers to build the cross tool?

So I'm a little confused how the other kernel headers are working out for you,
e.g. <arch/icache.h> is referenced when building the tilegx libgcc.

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 02:36:34PM -0400, Chris Metcalf wrote:
> On 6/21/2016 2:28 PM, Peter Zijlstra wrote:

> >I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
> >with the builtin C11 atomic primitives.
> >
> >You want me to rename them all to regain consistent naming?
> 
> Yes, it's probably the right thing to do.  All the internal routines with "atomic32"
> or "atomic64" I assume you mean?

Yep, after this patch we have a few __atomic_ and a few __atomic32_,
which is rather unbecoming. Lemme go convert them all to __atomic32_.

> So what's your build process for the cross tools, by the way?  I'm assuming
> you're not doing a total bootstrap cross-tool build since you'd need minimal
> kernel headers (linux/errno.h or whatever) in that case.  I assume you're using
> the host headers to build the cross tool?
> 
> So I'm a little confused how the other kernel headers are working out for you,
> e.g. <arch/icache.h> is referenced when building the tilegx libgcc.

I've no idea; I use this thing:

  git://git.infradead.org/users/segher/buildall.git

Although I've got some local modifications, none are to the actual
toolchain building part (although I suppose I should send segher a
patch).

I have binutils-gdb.git and gcc.bit checkouts and point the buildall
config to that (both are on latest stable branches binutils-2_26-branch
and gcc-6-branch resp.). And I point the kernel path to my current
hacked up tree.

I don't really rebuild the entire toolchains often, mostly only when I
really need a new GCC or its getting really old (like I used 5.3.0 for a
long while).

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 02:36:34PM -0400, Chris Metcalf wrote:
> On 6/21/2016 2:28 PM, Peter Zijlstra wrote:

> >I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
> >with the builtin C11 atomic primitives.
> >
> >You want me to rename them all to regain consistent naming?
> 
> Yes, it's probably the right thing to do.  All the internal routines with "atomic32"
> or "atomic64" I assume you mean?

Yep, after this patch we have a few __atomic_ and a few __atomic32_,
which is rather unbecoming. Lemme go convert them all to __atomic32_.

> So what's your build process for the cross tools, by the way?  I'm assuming
> you're not doing a total bootstrap cross-tool build since you'd need minimal
> kernel headers (linux/errno.h or whatever) in that case.  I assume you're using
> the host headers to build the cross tool?
> 
> So I'm a little confused how the other kernel headers are working out for you,
> e.g. <arch/icache.h> is referenced when building the tilegx libgcc.

I've no idea; I use this thing:

  git://git.infradead.org/users/segher/buildall.git

Although I've got some local modifications, none are to the actual
toolchain building part (although I suppose I should send segher a
patch).

I have binutils-gdb.git and gcc.bit checkouts and point the buildall
config to that (both are on latest stable branches binutils-2_26-branch
and gcc-6-branch resp.). And I point the kernel path to my current
hacked up tree.

I don't really rebuild the entire toolchains often, mostly only when I
really need a new GCC or its getting really old (like I used 5.3.0 for a
long while).

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 08:50:48PM +0200, Peter Zijlstra wrote:
> I've no idea; I use this thing:
> 
>   git://git.infradead.org/users/segher/buildall.git
> 
> Although I've got some local modifications, none are to the actual
> toolchain building part (although I suppose I should send segher a
> patch).

Oops, I do have..

sjlj-exceptions is causing aarch64 to fail, so I killed it, its not like
the kernel needs that.


diff --git a/build-gcc b/build-gcc
index a93c624..183f445 100755
--- a/build-gcc
+++ b/build-gcc
@@ -22,7 +22,7 @@ $ECHO -ne "       gcc:" && \
 	$GCC_SRC/configure \
 	--target=$TARGET --enable-targets=all --prefix=$PREFIX \
 	--enable-languages=c --without-headers --disable-bootstrap \
-	--enable-sjlj-exceptions --with-system-libunwind \
+	--disable-sjlj-exceptions --with-system-libunwind \
 	--disable-nls --disable-threads --disable-shared \
 	--disable-libmudflap --disable-libssp --disable-libgomp \
 	--disable-decimal-float --disable-libquadmath \

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 08:50:48PM +0200, Peter Zijlstra wrote:
> I've no idea; I use this thing:
> 
>   git://git.infradead.org/users/segher/buildall.git
> 
> Although I've got some local modifications, none are to the actual
> toolchain building part (although I suppose I should send segher a
> patch).

Oops, I do have..

sjlj-exceptions is causing aarch64 to fail, so I killed it, its not like
the kernel needs that.


diff --git a/build-gcc b/build-gcc
index a93c624..183f445 100755
--- a/build-gcc
+++ b/build-gcc
@@ -22,7 +22,7 @@ $ECHO -ne "       gcc:" && \
 	$GCC_SRC/configure \
 	--target=$TARGET --enable-targets=all --prefix=$PREFIX \
 	--enable-languages=c --without-headers --disable-bootstrap \
-	--enable-sjlj-exceptions --with-system-libunwind \
+	--disable-sjlj-exceptions --with-system-libunwind \
 	--disable-nls --disable-threads --disable-shared \
 	--disable-libmudflap --disable-libssp --disable-libgomp \
 	--disable-decimal-float --disable-libquadmath \

Re: linux-next: Tree for Jun 21

[Arnd Bergmann]

On Tuesday, June 21, 2016 8:50:48 PM CEST Peter Zijlstra wrote:
> 
> > So what's your build process for the cross tools, by the way?  I'm assuming
> > you're not doing a total bootstrap cross-tool build since you'd need minimal
> > kernel headers (linux/errno.h or whatever) in that case.  I assume you're using
> > the host headers to build the cross tool?
> > 
> > So I'm a little confused how the other kernel headers are working out for you,
> > e.g. <arch/icache.h> is referenced when building the tilegx libgcc.
> 
> I've no idea; I use this thing:
> 
>   git://git.infradead.org/users/segher/buildall.git
> 
> Although I've got some local modifications, none are to the actual
> toolchain building part (although I suppose I should send segher a
> patch).
> 
> I have binutils-gdb.git and gcc.bit checkouts and point the buildall
> config to that (both are on latest stable branches binutils-2_26-branch
> and gcc-6-branch resp.). And I point the kernel path to my current
> hacked up tree.
> 
> I don't really rebuild the entire toolchains often, mostly only when I
> really need a new GCC or its getting really old (like I used 5.3.0 for a
> long while).

I think the kernel headers are only needed for building glibc, which
buildall.git doesn't use: it only does the initial stage of creating
a cross-toolchain.

	Arnd

Re: linux-next: Tree for Jun 21

[Arnd Bergmann]

On Tuesday, June 21, 2016 8:50:48 PM CEST Peter Zijlstra wrote:
> 
> > So what's your build process for the cross tools, by the way?  I'm assuming
> > you're not doing a total bootstrap cross-tool build since you'd need minimal
> > kernel headers (linux/errno.h or whatever) in that case.  I assume you're using
> > the host headers to build the cross tool?
> > 
> > So I'm a little confused how the other kernel headers are working out for you,
> > e.g. <arch/icache.h> is referenced when building the tilegx libgcc.
> 
> I've no idea; I use this thing:
> 
>   git://git.infradead.org/users/segher/buildall.git
> 
> Although I've got some local modifications, none are to the actual
> toolchain building part (although I suppose I should send segher a
> patch).
> 
> I have binutils-gdb.git and gcc.bit checkouts and point the buildall
> config to that (both are on latest stable branches binutils-2_26-branch
> and gcc-6-branch resp.). And I point the kernel path to my current
> hacked up tree.
> 
> I don't really rebuild the entire toolchains often, mostly only when I
> really need a new GCC or its getting really old (like I used 5.3.0 for a
> long while).

I think the kernel headers are only needed for building glibc, which
buildall.git doesn't use: it only does the initial stage of creating
a cross-toolchain.

	Arnd

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 02:36:34PM -0400, Chris Metcalf wrote:
> On 6/21/2016 2:28 PM, Peter Zijlstra wrote:
> >On Tue, Jun 21, 2016 at 07:29:18PM +0200, Peter Zijlstra wrote:
> >
> >>>OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
> >>>can build me a kernel with it.
> >The below, much larger than desired, patch seems to make it go again.
> >
> >I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
> >with the builtin C11 atomic primitives.
> >
> >You want me to rename them all to regain consistent naming?
> 
> Yes, it's probably the right thing to do.  All the internal routines with "atomic32"
> or "atomic64" I assume you mean?

Something like so then?

---
 arch/tile/include/asm/atomic_32.h |   24 ++++++++++++------------
 arch/tile/include/asm/futex.h     |   14 +++++++-------
 arch/tile/lib/atomic_32.c         |   16 ++++++++--------
 arch/tile/lib/atomic_asm_32.S     |   21 +++++++++++++--------
 4 files changed, 40 insertions(+), 35 deletions(-)

diff --git a/arch/tile/include/asm/atomic_32.h b/arch/tile/include/asm/atomic_32.h
index da8eb4e..a937742 100644
--- a/arch/tile/include/asm/atomic_32.h
+++ b/arch/tile/include/asm/atomic_32.h
@@ -143,15 +143,15 @@ static inline void atomic64_##op(long long i, atomic64_t *v)	\
 {								\
 	_atomic64_fetch_##op(&v->counter, i);			\
 }								\
-static inline void atomic64_##op(long long i, atomic64_t *v)	\
+static inline long long atomic64_fetch_##op(long long i, atomic64_t *v)	\
 {								\
 	smp_mb();						\
 	return _atomic64_fetch_##op(&v->counter, i);		\
 }
 
-ATOMIC64_OP(and)
-ATOMIC64_OP(or)
-ATOMIC64_OP(xor)
+ATOMIC64_OPS(and)
+ATOMIC64_OPS(or)
+ATOMIC64_OPS(xor)
 
 #undef ATOMIC64_OPS
 
@@ -266,16 +266,16 @@ struct __get_user {
 	unsigned long val;
 	int err;
 };
-extern struct __get_user __atomic_cmpxchg(volatile int *p,
+extern struct __get_user __atomic32_cmpxchg(volatile int *p,
 					  int *lock, int o, int n);
-extern struct __get_user __atomic_xchg(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_xchg_add(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_xchg_add_unless(volatile int *p,
+extern struct __get_user __atomic32_xchg(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_xchg_add(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_xchg_add_unless(volatile int *p,
 						  int *lock, int o, int n);
-extern struct __get_user __atomic_fetch_or(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_fetch_and(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_fetch_andn(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_fetch_xor(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_fetch_or(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_fetch_and(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_fetch_andn(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_fetch_xor(volatile int *p, int *lock, int n);
 extern long long __atomic64_cmpxchg(volatile long long *p, int *lock,
 					long long o, long long n);
 extern long long __atomic64_xchg(volatile long long *p, int *lock, long long n);
diff --git a/arch/tile/include/asm/futex.h b/arch/tile/include/asm/futex.h
index 1a6ef1b..e64a1b7 100644
--- a/arch/tile/include/asm/futex.h
+++ b/arch/tile/include/asm/futex.h
@@ -80,16 +80,16 @@
 		ret = gu.err;						\
 	}
 
-#define __futex_set() __futex_call(__atomic_xchg)
-#define __futex_add() __futex_call(__atomic_xchg_add)
-#define __futex_or() __futex_call(__atomic_or)
-#define __futex_andn() __futex_call(__atomic_andn)
-#define __futex_xor() __futex_call(__atomic_xor)
+#define __futex_set() __futex_call(__atomic32_xchg)
+#define __futex_add() __futex_call(__atomic32_xchg_add)
+#define __futex_or() __futex_call(__atomic32_fetch_or)
+#define __futex_andn() __futex_call(__atomic32_fetch_andn)
+#define __futex_xor() __futex_call(__atomic32_fetch_xor)
 
 #define __futex_cmpxchg()						\
 	{								\
-		struct __get_user gu = __atomic_cmpxchg((u32 __force *)uaddr, \
-							lock, oldval, oparg); \
+		struct __get_user gu = __atomic32_cmpxchg((u32 __force *)uaddr, \
+							  lock, oldval, oparg); \
 		val = gu.val;						\
 		ret = gu.err;						\
 	}
diff --git a/arch/tile/lib/atomic_32.c b/arch/tile/lib/atomic_32.c
index 5b6bd93..f812880 100644
--- a/arch/tile/lib/atomic_32.c
+++ b/arch/tile/lib/atomic_32.c
@@ -61,13 +61,13 @@ static inline int *__atomic_setup(volatile void *v)
 
 int _atomic_xchg(int *v, int n)
 {
-	return __atomic_xchg(v, __atomic_setup(v), n).val;
+	return __atomic32_xchg(v, __atomic_setup(v), n).val;
 }
 EXPORT_SYMBOL(_atomic_xchg);
 
 int _atomic_xchg_add(int *v, int i)
 {
-	return __atomic_xchg_add(v, __atomic_setup(v), i).val;
+	return __atomic32_xchg_add(v, __atomic_setup(v), i).val;
 }
 EXPORT_SYMBOL(_atomic_xchg_add);
 
@@ -78,37 +78,37 @@ int _atomic_xchg_add_unless(int *v, int a, int u)
 	 * to use the first argument consistently as the "old value"
 	 * in the assembly, as is done for _atomic_cmpxchg().
 	 */
-	return __atomic_xchg_add_unless(v, __atomic_setup(v), u, a).val;
+	return __atomic32_xchg_add_unless(v, __atomic_setup(v), u, a).val;
 }
 EXPORT_SYMBOL(_atomic_xchg_add_unless);
 
 int _atomic_cmpxchg(int *v, int o, int n)
 {
-	return __atomic_cmpxchg(v, __atomic_setup(v), o, n).val;
+	return __atomic32_cmpxchg(v, __atomic_setup(v), o, n).val;
 }
 EXPORT_SYMBOL(_atomic_cmpxchg);
 
 unsigned long _atomic_fetch_or(volatile unsigned long *p, unsigned long mask)
 {
-	return __atomic_fetch_or((int *)p, __atomic_setup(p), mask).val;
+	return __atomic32_fetch_or((int *)p, __atomic_setup(p), mask).val;
 }
 EXPORT_SYMBOL(_atomic_fetch_or);
 
 unsigned long _atomic_fetch_and(volatile unsigned long *p, unsigned long mask)
 {
-	return __atomic_fetch_and((int *)p, __atomic_setup(p), mask).val;
+	return __atomic32_fetch_and((int *)p, __atomic_setup(p), mask).val;
 }
 EXPORT_SYMBOL(_atomic_fetch_and);
 
 unsigned long _atomic_fetch_andn(volatile unsigned long *p, unsigned long mask)
 {
-	return __atomic_fetch_andn((int *)p, __atomic_setup(p), mask).val;
+	return __atomic32_fetch_andn((int *)p, __atomic_setup(p), mask).val;
 }
 EXPORT_SYMBOL(_atomic_fetch_andn);
 
 unsigned long _atomic_fetch_xor(volatile unsigned long *p, unsigned long mask)
 {
-	return __atomic_fetch_xor((int *)p, __atomic_setup(p), mask).val;
+	return __atomic32_fetch_xor((int *)p, __atomic_setup(p), mask).val;
 }
 EXPORT_SYMBOL(_atomic_fetch_xor);
 
diff --git a/arch/tile/lib/atomic_asm_32.S b/arch/tile/lib/atomic_asm_32.S
index 507abdd..1a70e6c 100644
--- a/arch/tile/lib/atomic_asm_32.S
+++ b/arch/tile/lib/atomic_asm_32.S
@@ -172,15 +172,20 @@ STD_ENTRY_SECTION(__atomic\name, .text.atomic)
 	.endif
 	.endm
 
-atomic_op _cmpxchg, 32, "seq r26, r22, r2; { bbns r26, 3f; move r24, r3 }"
-atomic_op _xchg, 32, "move r24, r2"
-atomic_op _xchg_add, 32, "add r24, r22, r2"
-atomic_op _xchg_add_unless, 32, \
+
+/*
+ * Use __atomic32 prefix to avoid collisions with GCC builtin __atomic functions.
+ */
+
+atomic_op 32_cmpxchg, 32, "seq r26, r22, r2; { bbns r26, 3f; move r24, r3 }"
+atomic_op 32_xchg, 32, "move r24, r2"
+atomic_op 32_xchg_add, 32, "add r24, r22, r2"
+atomic_op 32_xchg_add_unless, 32, \
 	"sne r26, r22, r2; { bbns r26, 3f; add r24, r22, r3 }"
-atomic_op _fetch_or, 32, "or r24, r22, r2"
-atomic_op _fetch_and, 32, "and r24, r22, r2"
-atomic_op _fetch_andn, 32, "nor r2, r2, zero; and r24, r22, r2"
-atomic_op _fetch_xor, 32, "xor r24, r22, r2"
+atomic_op 32_fetch_or, 32, "or r24, r22, r2"
+atomic_op 32_fetch_and, 32, "and r24, r22, r2"
+atomic_op 32_fetch_andn, 32, "nor r2, r2, zero; and r24, r22, r2"
+atomic_op 32_fetch_xor, 32, "xor r24, r22, r2"
 
 atomic_op 64_cmpxchg, 64, "{ seq r26, r22, r2; seq r27, r23, r3 }; \
 	{ bbns r26, 3f; move r24, r4 }; { bbns r27, 3f; move r25, r5 }"

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Tue, Jun 21, 2016 at 02:36:34PM -0400, Chris Metcalf wrote:
> On 6/21/2016 2:28 PM, Peter Zijlstra wrote:
> >On Tue, Jun 21, 2016 at 07:29:18PM +0200, Peter Zijlstra wrote:
> >
> >>>OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
> >>>can build me a kernel with it.
> >The below, much larger than desired, patch seems to make it go again.
> >
> >I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
> >with the builtin C11 atomic primitives.
> >
> >You want me to rename them all to regain consistent naming?
> 
> Yes, it's probably the right thing to do.  All the internal routines with "atomic32"
> or "atomic64" I assume you mean?

Something like so then?

---
 arch/tile/include/asm/atomic_32.h |   24 ++++++++++++------------
 arch/tile/include/asm/futex.h     |   14 +++++++-------
 arch/tile/lib/atomic_32.c         |   16 ++++++++--------
 arch/tile/lib/atomic_asm_32.S     |   21 +++++++++++++--------
 4 files changed, 40 insertions(+), 35 deletions(-)

diff --git a/arch/tile/include/asm/atomic_32.h b/arch/tile/include/asm/atomic_32.h
index da8eb4e..a937742 100644
--- a/arch/tile/include/asm/atomic_32.h
+++ b/arch/tile/include/asm/atomic_32.h
@@ -143,15 +143,15 @@ static inline void atomic64_##op(long long i, atomic64_t *v)	\
 {								\
 	_atomic64_fetch_##op(&v->counter, i);			\
 }								\
-static inline void atomic64_##op(long long i, atomic64_t *v)	\
+static inline long long atomic64_fetch_##op(long long i, atomic64_t *v)	\
 {								\
 	smp_mb();						\
 	return _atomic64_fetch_##op(&v->counter, i);		\
 }
 
-ATOMIC64_OP(and)
-ATOMIC64_OP(or)
-ATOMIC64_OP(xor)
+ATOMIC64_OPS(and)
+ATOMIC64_OPS(or)
+ATOMIC64_OPS(xor)
 
 #undef ATOMIC64_OPS
 
@@ -266,16 +266,16 @@ struct __get_user {
 	unsigned long val;
 	int err;
 };
-extern struct __get_user __atomic_cmpxchg(volatile int *p,
+extern struct __get_user __atomic32_cmpxchg(volatile int *p,
 					  int *lock, int o, int n);
-extern struct __get_user __atomic_xchg(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_xchg_add(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_xchg_add_unless(volatile int *p,
+extern struct __get_user __atomic32_xchg(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_xchg_add(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_xchg_add_unless(volatile int *p,
 						  int *lock, int o, int n);
-extern struct __get_user __atomic_fetch_or(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_fetch_and(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_fetch_andn(volatile int *p, int *lock, int n);
-extern struct __get_user __atomic_fetch_xor(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_fetch_or(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_fetch_and(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_fetch_andn(volatile int *p, int *lock, int n);
+extern struct __get_user __atomic32_fetch_xor(volatile int *p, int *lock, int n);
 extern long long __atomic64_cmpxchg(volatile long long *p, int *lock,
 					long long o, long long n);
 extern long long __atomic64_xchg(volatile long long *p, int *lock, long long n);
diff --git a/arch/tile/include/asm/futex.h b/arch/tile/include/asm/futex.h
index 1a6ef1b..e64a1b7 100644
--- a/arch/tile/include/asm/futex.h
+++ b/arch/tile/include/asm/futex.h
@@ -80,16 +80,16 @@
 		ret = gu.err;						\
 	}
 
-#define __futex_set() __futex_call(__atomic_xchg)
-#define __futex_add() __futex_call(__atomic_xchg_add)
-#define __futex_or() __futex_call(__atomic_or)
-#define __futex_andn() __futex_call(__atomic_andn)
-#define __futex_xor() __futex_call(__atomic_xor)
+#define __futex_set() __futex_call(__atomic32_xchg)
+#define __futex_add() __futex_call(__atomic32_xchg_add)
+#define __futex_or() __futex_call(__atomic32_fetch_or)
+#define __futex_andn() __futex_call(__atomic32_fetch_andn)
+#define __futex_xor() __futex_call(__atomic32_fetch_xor)
 
 #define __futex_cmpxchg()						\
 	{								\
-		struct __get_user gu = __atomic_cmpxchg((u32 __force *)uaddr, \
-							lock, oldval, oparg); \
+		struct __get_user gu = __atomic32_cmpxchg((u32 __force *)uaddr, \
+							  lock, oldval, oparg); \
 		val = gu.val;						\
 		ret = gu.err;						\
 	}
diff --git a/arch/tile/lib/atomic_32.c b/arch/tile/lib/atomic_32.c
index 5b6bd93..f812880 100644
--- a/arch/tile/lib/atomic_32.c
+++ b/arch/tile/lib/atomic_32.c
@@ -61,13 +61,13 @@ static inline int *__atomic_setup(volatile void *v)
 
 int _atomic_xchg(int *v, int n)
 {
-	return __atomic_xchg(v, __atomic_setup(v), n).val;
+	return __atomic32_xchg(v, __atomic_setup(v), n).val;
 }
 EXPORT_SYMBOL(_atomic_xchg);
 
 int _atomic_xchg_add(int *v, int i)
 {
-	return __atomic_xchg_add(v, __atomic_setup(v), i).val;
+	return __atomic32_xchg_add(v, __atomic_setup(v), i).val;
 }
 EXPORT_SYMBOL(_atomic_xchg_add);
 
@@ -78,37 +78,37 @@ int _atomic_xchg_add_unless(int *v, int a, int u)
 	 * to use the first argument consistently as the "old value"
 	 * in the assembly, as is done for _atomic_cmpxchg().
 	 */
-	return __atomic_xchg_add_unless(v, __atomic_setup(v), u, a).val;
+	return __atomic32_xchg_add_unless(v, __atomic_setup(v), u, a).val;
 }
 EXPORT_SYMBOL(_atomic_xchg_add_unless);
 
 int _atomic_cmpxchg(int *v, int o, int n)
 {
-	return __atomic_cmpxchg(v, __atomic_setup(v), o, n).val;
+	return __atomic32_cmpxchg(v, __atomic_setup(v), o, n).val;
 }
 EXPORT_SYMBOL(_atomic_cmpxchg);
 
 unsigned long _atomic_fetch_or(volatile unsigned long *p, unsigned long mask)
 {
-	return __atomic_fetch_or((int *)p, __atomic_setup(p), mask).val;
+	return __atomic32_fetch_or((int *)p, __atomic_setup(p), mask).val;
 }
 EXPORT_SYMBOL(_atomic_fetch_or);
 
 unsigned long _atomic_fetch_and(volatile unsigned long *p, unsigned long mask)
 {
-	return __atomic_fetch_and((int *)p, __atomic_setup(p), mask).val;
+	return __atomic32_fetch_and((int *)p, __atomic_setup(p), mask).val;
 }
 EXPORT_SYMBOL(_atomic_fetch_and);
 
 unsigned long _atomic_fetch_andn(volatile unsigned long *p, unsigned long mask)
 {
-	return __atomic_fetch_andn((int *)p, __atomic_setup(p), mask).val;
+	return __atomic32_fetch_andn((int *)p, __atomic_setup(p), mask).val;
 }
 EXPORT_SYMBOL(_atomic_fetch_andn);
 
 unsigned long _atomic_fetch_xor(volatile unsigned long *p, unsigned long mask)
 {
-	return __atomic_fetch_xor((int *)p, __atomic_setup(p), mask).val;
+	return __atomic32_fetch_xor((int *)p, __atomic_setup(p), mask).val;
 }
 EXPORT_SYMBOL(_atomic_fetch_xor);
 
diff --git a/arch/tile/lib/atomic_asm_32.S b/arch/tile/lib/atomic_asm_32.S
index 507abdd..1a70e6c 100644
--- a/arch/tile/lib/atomic_asm_32.S
+++ b/arch/tile/lib/atomic_asm_32.S
@@ -172,15 +172,20 @@ STD_ENTRY_SECTION(__atomic\name, .text.atomic)
 	.endif
 	.endm
 
-atomic_op _cmpxchg, 32, "seq r26, r22, r2; { bbns r26, 3f; move r24, r3 }"
-atomic_op _xchg, 32, "move r24, r2"
-atomic_op _xchg_add, 32, "add r24, r22, r2"
-atomic_op _xchg_add_unless, 32, \
+
+/*
+ * Use __atomic32 prefix to avoid collisions with GCC builtin __atomic functions.
+ */
+
+atomic_op 32_cmpxchg, 32, "seq r26, r22, r2; { bbns r26, 3f; move r24, r3 }"
+atomic_op 32_xchg, 32, "move r24, r2"
+atomic_op 32_xchg_add, 32, "add r24, r22, r2"
+atomic_op 32_xchg_add_unless, 32, \
 	"sne r26, r22, r2; { bbns r26, 3f; add r24, r22, r3 }"
-atomic_op _fetch_or, 32, "or r24, r22, r2"
-atomic_op _fetch_and, 32, "and r24, r22, r2"
-atomic_op _fetch_andn, 32, "nor r2, r2, zero; and r24, r22, r2"
-atomic_op _fetch_xor, 32, "xor r24, r22, r2"
+atomic_op 32_fetch_or, 32, "or r24, r22, r2"
+atomic_op 32_fetch_and, 32, "and r24, r22, r2"
+atomic_op 32_fetch_andn, 32, "nor r2, r2, zero; and r24, r22, r2"
+atomic_op 32_fetch_xor, 32, "xor r24, r22, r2"
 
 atomic_op 64_cmpxchg, 64, "{ seq r26, r22, r2; seq r27, r23, r3 }; \
 	{ bbns r26, 3f; move r24, r4 }; { bbns r27, 3f; move r25, r5 }"

Re: linux-next: Tree for Jun 21

[Chris Metcalf]

On 6/22/2016 5:16 AM, Peter Zijlstra wrote:
> On Tue, Jun 21, 2016 at 02:36:34PM -0400, Chris Metcalf wrote:
>> >On 6/21/2016 2:28 PM, Peter Zijlstra wrote:
>>> > >On Tue, Jun 21, 2016 at 07:29:18PM +0200, Peter Zijlstra wrote:
>>> > >
>>>>> > >>>OK, I seem to have a tilepro-linux-gcc-6.1.1 build done. Lets see if I
>>>>> > >>>can build me a kernel with it.
>>> > >The below, much larger than desired, patch seems to make it go again.
>>> > >
>>> > >I had to s/__atomic_fetch/__atomic32_fetch/ to avoid a namespace clash
>>> > >with the builtin C11 atomic primitives.
>>> > >
>>> > >You want me to rename them all to regain consistent naming?
>> >
>> >Yes, it's probably the right thing to do.  All the internal routines with "atomic32"
>> >or "atomic64" I assume you mean?
> Something like so then?
>
> ---
>   arch/tile/include/asm/atomic_32.h |   24 ++++++++++++------------
>   arch/tile/include/asm/futex.h     |   14 +++++++-------
>   arch/tile/lib/atomic_32.c         |   16 ++++++++--------
>   arch/tile/lib/atomic_asm_32.S     |   21 +++++++++++++--------
>   4 files changed, 40 insertions(+), 35 deletions(-)

Yes, that looks good.  Thanks!

Acked-by: Chris Metcalf <cmetcalf@mellanox.com>

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21

[Chris Metcalf]

On 6/21/2016 5:14 PM, Arnd Bergmann wrote:
> On Tuesday, June 21, 2016 8:50:48 PM CEST Peter Zijlstra wrote:
>>> So what's your build process for the cross tools, by the way?  I'm assuming
>>> you're not doing a total bootstrap cross-tool build since you'd need minimal
>>> kernel headers (linux/errno.h or whatever) in that case.  I assume you're using
>>> the host headers to build the cross tool?
>>>
>>> So I'm a little confused how the other kernel headers are working out for you,
>>> e.g. <arch/icache.h> is referenced when building the tilegx libgcc.
>> I've no idea; I use this thing:
>>
>>    git://git.infradead.org/users/segher/buildall.git
>>
>> Although I've got some local modifications, none are to the actual
>> toolchain building part (although I suppose I should send segher a
>> patch).
>>
>> I have binutils-gdb.git and gcc.bit checkouts and point the buildall
>> config to that (both are on latest stable branches binutils-2_26-branch
>> and gcc-6-branch resp.). And I point the kernel path to my current
>> hacked up tree.
>>
>> I don't really rebuild the entire toolchains often, mostly only when I
>> really need a new GCC or its getting really old (like I used 5.3.0 for a
>> long while).
> I think the kernel headers are only needed for building glibc, which
> buildall.git doesn't use: it only does the initial stage of creating
> a cross-toolchain.

It turns out there were a few places where we were #include'ing Linux
headers in the gcc build (asm/unistd.h, arch/icache.h, arch/spr_def.h).
I patched gcc to provide inline copies of what was needed (pretty simple
stuff and won't ever change) and asked our lead compiler guy to upstream
it back up to gcc, so using buildall.git should get easier for tilepro/tilegx.

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

Re: linux-next: Tree for Jun 21

[Peter Zijlstra]

On Wed, Jun 22, 2016 at 04:43:15PM -0400, Chris Metcalf wrote:
> It turns out there were a few places where we were #include'ing Linux
> headers in the gcc build (asm/unistd.h, arch/icache.h, arch/spr_def.h).
> I patched gcc to provide inline copies of what was needed (pretty simple
> stuff and won't ever change) and asked our lead compiler guy to upstream
> it back up to gcc, so using buildall.git should get easier for tilepro/tilegx.

tilegx actually built without issue (although I think it needed
--disable-gdb for binutils).

But thanks! Much appreciated.

I'll try and make a few patches for Segher to update buildall and reduce
the number of hacks/patches I have to carry around on that.