Hi Alexey,
On Mon, Jun 3, 2019 at 3:42 PM Alexey Brodkin
wrote:
>
> For a long time we used to hard-code CROSS_COMPILE prefix
> for ARC until it started to cause problems, so we decided to
> solely rely on CROSS_COMPILE externally set by a user:
> commit 40660f1fcee8 ("ARC: build: Don't set CROSS
On Mai 31 2019, Alexey Brodkin wrote:
> I guess mentioned change is not supposed to be reverted but then
> how do you think it's possible [if at all] to implement that kind of
> "automatic" setup of slibdir/rtlddir?
As the commit message says, you can reference makefile variables in the
value.
Hi Masahiro-san,
> -Original Message-
> From: Masahiro Yamada
> Sent: Monday, June 3, 2019 11:18 AM
> To: Alexey Brodkin
> Cc: arcml ; Linux Kernel Mailing List
> ker...@vger.kernel.org>; Vineet Gupta
> Subject: Re: [PATCH] ARC: build: Try to guess CROSS_COMPILE with
> cc-cross-prefi
Hi Alexey,
On Mon, Jun 3, 2019 at 5:34 PM Alexey Brodkin
wrote:
>
> Hi Masahiro-san,
>
> > -Original Message-
> > From: Masahiro Yamada
> > Sent: Monday, June 3, 2019 11:18 AM
> > To: Alexey Brodkin
> > Cc: arcml ; Linux Kernel Mailing List
> > > ker...@vger.kernel.org>; Vineet Gupta
To print the pathname that will be used by shell in the current
environment, 'command -v' is a standardized way. [1]
'which' is also often used in scripting, but it is not portable.
When I worked on commit bd55f96fa9fc ("kbuild: refactor cc-cross-prefix
implementation"), I was eager to use 'comma
Hi Masahiro-san,
> -Original Message-
> From: linux-snps-arc On Behalf
> Of Masahiro Yamada
> Sent: Monday, June 3, 2019 1:49 PM
> To: linux-kbu...@vger.kernel.org
> Cc: Michal Marek ; Vineet Gupta
> ; Alexey Brodkin
> ; linux-ker...@vger.kernel.org; linux-stable
> ; Masahiro
> Yamada
From: Masahiro Yamada
> Sent: 03 June 2019 11:49
>
> To print the pathname that will be used by shell in the current
> environment, 'command -v' is a standardized way. [1]
>
> 'which' is also often used in scripting, but it is not portable.
>
> When I worked on commit bd55f96fa9fc ("kbuild: refa
From: Masahiro Yamada
> Sent: 03 June 2019 11:49
>
> To print the pathname that will be used by shell in the current
> environment, 'command -v' is a standardized way. [1]
>
> 'which' is also often used in scripting, but it is not portable.
All uses of 'which' should be expunged.
It is a bourne
Hi David,
On Mon, Jun 3, 2019 at 8:14 PM David Laight wrote:
>
> From: Masahiro Yamada
> > Sent: 03 June 2019 11:49
> >
> > To print the pathname that will be used by shell in the current
> > environment, 'command -v' is a standardized way. [1]
> >
> > 'which' is also often used in scripting, but
On Mon, Jun 3, 2019 at 8:16 PM David Laight wrote:
>
> From: Masahiro Yamada
> > Sent: 03 June 2019 11:49
> >
> > To print the pathname that will be used by shell in the current
> > environment, 'command -v' is a standardized way. [1]
> >
> > 'which' is also often used in scripting, but it is not
From: Masahiro Yamada
> Sent: 03 June 2019 12:45
> On Mon, Jun 3, 2019 at 8:16 PM David Laight wrote:
> >
> > From: Masahiro Yamada
> > > Sent: 03 June 2019 11:49
> > >
> > > To print the pathname that will be used by shell in the current
> > > environment, 'command -v' is a standardized way. [1]
From: Masahiro Yamada
> Sent: 03 June 2019 12:38
> Hi David,
>
> On Mon, Jun 3, 2019 at 8:14 PM David Laight wrote:
> >
> > From: Masahiro Yamada
> > > Sent: 03 June 2019 11:49
> > >
> > > To print the pathname that will be used by shell in the current
> > > environment, 'command -v' is a standar
On Fri, 31 May 2019, Alexey Brodkin wrote:
> Hi Andreas,
>
> I'm trying to implement multilib support for ARC port of Glibc
> and for that we seem to need to have unique slibdir/rtlddir pair per
> each machine flavor. In our case these are at least:
> - ARC700 (legacy ARCompact architecture)
>
On 6/2/19 11:31 PM, Alexey Brodkin wrote:
> For a long time we used to hard-code CROSS_COMPILE prefix
> for ARC until it started to cause problems, so we decided to
> solely rely on CROSS_COMPILE externally set by a user:
> commit 40660f1fcee8 ("ARC: build: Don't set CROSS_COMPILE in arch's
> Make
Hi Vineet,
> -Original Message-
> From: Vineet Gupta
> Sent: Monday, June 3, 2019 7:25 PM
> To: Alexey Brodkin ; linux-snps-arc@lists.infradead.org
> Cc: linux-ker...@vger.kernel.org; Masahiro Yamada
>
> Subject: Re: [PATCH] ARC: build: Try to guess CROSS_COMPILE with
> cc-cross-prefix
I wish we could just set CROSS_COMPILE and ARCH in .config. That would
make everyones life compile testing on multiple architectures so much
easier.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/li
Hi Joseph,
> -Original Message-
> From: Joseph Myers
> Sent: Monday, June 3, 2019 6:41 PM
> To: Alexey Brodkin
> Cc: Andreas Schwab ; libc-al...@sourceware.org;
> linux-snps-arc@lists.infradead.org
> Subject: Re: Pass config-time variable to LIBC_SLIBDIR_RTLDDIR
>
> On Fri, 31 May 2019
On Mon, 3 Jun 2019, Alexey Brodkin wrote:
> Well I'm trying to solve a little bit different problem - to build
> a universal multilib cross-toolchain which will be usable for building
> binaries optimized for different ARC cores. Different I mean:
> - Binary-incompatible architecture generations:
On 5/31/19 1:21 AM, Peter Zijlstra wrote:
>> I'm not sure how to interpret "natural alignment" for the case of double
>> load/stores on 32-bit systems where the hardware and ABI allow for 4 byte
>> alignment (ARCv2 LDD/STD, ARM LDRD/STRD )
> Natural alignment: !((uintptr_t)ptr % sizeof(*ptr))
>
On 5/31/19 1:21 AM, Peter Zijlstra wrote:
> And I'll stand by my earlier conviction that any architecture that has a
> native u64 (be it a 64bit arch or a 32bit with double-width
> instructions) but has an ABI that allows u32 alignment on them is daft.
Why ? For 64-bit data on 32-bit systems, hard
On 5/31/19 2:41 AM, David Laight wrote:
>> While it seems reasonable form hardware pov to not implement such atomicity
>> by
>> default it seems there's an additional burden on application writers. They
>> could
>> be happily using a lockless algorithm with just a shared flag between 2
>> thread
On Mon, Jun 03, 2019 at 06:08:35PM +, Vineet Gupta wrote:
> On 5/31/19 1:21 AM, Peter Zijlstra wrote:
> >> I'm not sure how to interpret "natural alignment" for the case of double
> >> load/stores on 32-bit systems where the hardware and ABI allow for 4 byte
> >> alignment (ARCv2 LDD/STD, ARM L
Hi Linus,
Please pull.
Thx,
-Vineet
->
The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/ tags/a
On 6/3/19 1:13 PM, Paul E. McKenney wrote:
> On Mon, Jun 03, 2019 at 06:08:35PM +, Vineet Gupta wrote:
>> On 5/31/19 1:21 AM, Peter Zijlstra wrote:
I'm not sure how to interpret "natural alignment" for the case of double
load/stores on 32-bit systems where the hardware and ABI allow f
The pull request you sent on Mon, 3 Jun 2019 14:04:16 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/ tags/arc-5.2-rc4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/788a024921c48985939f8241c1ff862a7374d8f9
Thank you!
--
Deet-doot-dot, I am a
On Tue, Jun 4, 2019 at 1:27 AM Vineet Gupta wrote:
>
> On 6/2/19 11:31 PM, Alexey Brodkin wrote:
> > For a long time we used to hard-code CROSS_COMPILE prefix
> > for ARC until it started to cause problems, so we decided to
> > solely rely on CROSS_COMPILE externally set by a user:
> > commit 4066
On Mon, Jun 3, 2019 at 10:09 PM David Laight wrote:
>
> From: Masahiro Yamada
> > Sent: 03 June 2019 12:38
> > Hi David,
> >
> > On Mon, Jun 3, 2019 at 8:14 PM David Laight wrote:
> > >
> > > From: Masahiro Yamada
> > > > Sent: 03 June 2019 11:49
> > > >
> > > > To print the pathname that will be
On Mon, Jun 3, 2019 at 9:43 PM David Laight wrote:
>
> From: Masahiro Yamada
> > Sent: 03 June 2019 12:45
> > On Mon, Jun 3, 2019 at 8:16 PM David Laight wrote:
> > >
> > > From: Masahiro Yamada
> > > > Sent: 03 June 2019 11:49
> > > >
> > > > To print the pathname that will be used by shell in t
28 matches
Mail list logo
