On 2/15/24 7:49 PM, Michael Ellerman wrote:
> Peter Bergner writes:
>> On 2/15/24 2:16 AM, Arnd Bergmann wrote:
>>> On Wed, Feb 14, 2024, at 23:34, Peter Bergner wrote:
>>>> Arnd, we seem to have consensus on the patch below. Is this something
>>>
On 2/15/24 2:16 AM, Arnd Bergmann wrote:
> On Wed, Feb 14, 2024, at 23:34, Peter Bergner wrote:
>> The powerpc toolchain keeps a copy of the HWCAP bit masks in our TCB for fast
>> access by the __builtin_cpu_supports built-in function. The TCB space for
>> the HWCAP entrie
-by: Peter Bergner
Acked-by: Adhemerval Zanella (glibc)
Acked-by: Nicholas Piggin (powerpc)
Acked-by: Szabolcs Nagy (arm)
---
include/uapi/linux/auxvec.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/auxvec.h b/include/uapi/linux/auxvec.h
index 6991c4b8ab18
On 9/26/23 5:02 PM, Peter Bergner wrote:
> The powerpc toolchain keeps a copy of the HWCAP bit masks in our TCB for fast
> access by our __builtin_cpu_supports built-in function. The TCB space for
> the HWCAP entries - which are created in pairs - is an ABI extension, so
> waiti
On 10/3/23 9:08 AM, Adhemerval Zanella Netto wrote:
> What it is not clear to me is what kind of ABI boundary you are trying to
> preemptively add support here. The TCB ABI for __builtin_cpu_supports is
> userland only, so if your intention is just to allow gcc to work on older
> glibcs, it should
Hi Adhemerval, sorry for the delay in replying, I was a little under the
weather last week.
On 9/27/23 11:03 AM, Adhemerval Zanella Netto wrote:
> On 26/09/23 19:02, Peter Bergner wrote:
>> The powerpc toolchain keeps a copy of the HWCAP bit masks in our TCB for fast
>>
looking for unused AT_*
values and 29 and 30 did not seem to be used, so they are what I went
with. If anyone sees a problem with using those specific values, I'm
amenable to using other values, just let me know what would be better.
Peter
Signed-off-by: Peter Bergner
---
include/uapi/linux/auxvec.h
On 8/31/22 5:45 PM, Segher Boessenkool wrote:
> On Tue, Aug 30, 2022 at 09:10:02AM +, Christophe Leroy wrote:
>> Le 30/08/2022 à 11:01, Nicholas Piggin a écrit :
>>> On Tue Aug 30, 2022 at 3:24 PM AEST, Christophe Leroy wrote:
> This is still slightly concerning to me. Is there any
On 5/20/22 12:15 AM, Nicholas Piggin via Gcc wrote:
> +PPC_FEATURE_HAS_ALTIVEC
> +Vector (aka Altivec, VSX) facility is available.
Slight typo. s/VSX/VMX/
Peter
On 11/23/16 11:52 PM, Balbir Singh wrote:
On 24/11/16 16:14, Andrew Donnellan wrote:
On 24/11/16 13:05, Balbir Singh wrote:
9. The license for these files is now GPL v3 or later
As much as I love the GPLv3, isn't this an instant NAK?
Thats why I called it out, my bad though I should
On Fri, 2015-10-02 at 22:03 +0300, Denis Kirjanov wrote:
> arch/powerpc/kernel/swsusp_asm64.S: Assembler messages:
>> arch/powerpc/kernel/swsusp_asm64.S:188: Error: missing operand
>> scripts/Makefile.build:294: recipe for target
>> 'arch/powerpc/kernel/swsusp_asm64.o' failed
>> make[1]: ***
On Fri, 2015-10-02 at 17:00 -0500, Segher Boessenkool wrote:
> On Sat, Oct 03, 2015 at 12:37:35AM +0300, Denis Kirjanov wrote:
> > >> -0: tlbie r4; \
> > >> +0: tlbie r4, 0; \
> > >
> > > This isn't correct. With POWER7 and later
On Thu, 2014-11-27 at 10:08 -0600, Segher Boessenkool wrote:
On Wed, Nov 26, 2014 at 05:50:27PM -0600, Peter Bergner wrote:
Nope, you don't get a SIGILL when executing 64-bit instructions in
32-bit mode, so it'll happily just execute the instruction, doing
a full 64-bit compare. I'm
On Thu, 2014-11-27 at 09:38 +1100, Michael Ellerman wrote:
On Thu, 2014-11-27 at 08:11 +1100, Anton Blanchard wrote:
I used some 64 bit instructions when adding the 32 bit getcpu VDSO
function. Fix it.
Ouch. The symptom is a SIGILL I presume?
Nope, you don't get a SIGILL when executing
On Wed, 2013-01-09 at 16:19 -0600, Jimi Xenidis wrote:
I agree, but that means it is impossible for the same .S file can be compiled
but -mcpu=e500mc and -mcpu=powerpc? So either these files have to be Book3S
versus Book3E --or-- we use a CPP macro to get them right.
FWIW, I prefer the latter
On Tue, 2012-12-18 at 07:28 -0600, Jimi Xenidis wrote:
On Dec 17, 2012, at 6:26 PM, Peter Bergner berg...@vnet.ibm.com wrote:
Jimi, are you using an old binutils from before my patch that
changed the operand order for these types of instructions?
http://sourceware.org/ml/binutils/2009
On Mon, 2012-12-17 at 22:33 +1100, Anton Blanchard wrote:
Hi Jimi,
I know this is a little late, but shouldn't these power7 specific
thingies be in obj-$(CONFIG_PPC_BOOK3S_64). The reason I ask is
that my compiler pukes on dcbtst and as I deal with that I wanted
to point this out.
I
On Tue, 2011-11-01 at 08:32 +0530, Santosh Kumar wrote:
I am using the same compiler as 476 440 instruction is almost the same.
Well the 476 implements ISA 2.05, which I think has added a fair amount
over the 440. Not to mention the 476 core that has been released has
a FP unit. I'll note
On Tue, 2011-11-01 at 22:44 +0530, Santosh Kumar wrote:
I had a problem configuring the GCC for 476 in little endian mode,
What type of problem? I assume the binutils you are building
against has 476 support too, correct? You'll need that.
So is this PTE fault related to the compiler
On Sat, 2009-10-17 at 21:34 +0200, Wolfgang Denk wrote:
Dear Joakim Tjernlund,
OK, but then you don't mix some libs/apps with soft and other
apps/libs with hard FP?
No, we never tried that. Sounds scary to me.
And dangerous. Hard-float and soft-float are ABI incompatible, so you
cannot
On Mon, 2009-04-06 at 15:36 -0500, Kumar Gala wrote:
The tlbilx opcode was not matching the Power ISA 2.06 arch spec.
The old opcode was an early suggested opcode that changed during the
2.06 architecture process.
[snip]
#define PPC_INST_STSWI 0x7c0005aa
#define
On Tue, 2009-04-07 at 12:54 -0500, Kumar Gala wrote:
On Apr 7, 2009, at 12:36 PM, Peter Bergner wrote:
How do you want to handle the current binutils code that implements tlbilx
and its extended mnemonics? Should they be changed to use secondary opcode
18 instead of 787 as per the ISA 2.06
On Tue, 2009-03-03 at 08:56 -0800, Andrew Morton wrote:
On Tue, 3 Mar 2009 11:14:04 +0100 (CET) Geert Uytterhoeven
geert.uytterhoe...@sonycom.com wrote:
let us know if that works :-)
didn't. Oh well.
Does allnoconfig work if you force the compiler to be 32-bit, like
23 matches
Mail list logo