On November 6, 2024 10:15:13 AM PST, Jakub Jelinek wrote:
>On Wed, Nov 06, 2024 at 10:03:25AM -0800, H. Peter Anvin wrote:
>> The issue is that we want the frame pointer chain to be maintained, even
>> across alternatives.
>
>If the current function doesn't have frame po
On November 6, 2024 8:31:53 AM PST, Uros Bizjak wrote:
>On Wed, Nov 6, 2024 at 5:23 PM Jakub Jelinek wrote:
>>
>> On Wed, Nov 06, 2024 at 05:05:54PM +0100, Uros Bizjak wrote:
>> > Please see [1]:
>> >
>> > /*
>> > * This output constraint should be used for any inline asm which has a
>> > "call
On November 6, 2024 7:27:51 AM PST, Uros Bizjak wrote:
>On Wed, Nov 6, 2024 at 11:57 AM Jakub Jelinek wrote:
>>
>> On Wed, Nov 06, 2024 at 10:44:54AM +0100, Uros Bizjak wrote:
>> > After some more thinking and considering all recent discussion
>> > (thanks!), I am convinced that a slightly simpli
Well, these kinds of asm are inherently target specific, but I did already ask
for a cpp symbol to indicate this faculty us available.
On May 20, 2015 9:21:07 AM PDT, Jeff Law wrote:
>On 05/15/2015 09:37 AM, Richard Henderson wrote:
>> Version 2 includes proper test cases and documentation.
>> H
On 05/07/2015 02:39 PM, Richard Henderson wrote:
> All j mnemonics implemented as =@cc
> to make it easy for someone reading the manual
> to figure out what condition is desired.
One request: would it be possible to get a cpp symbol for this (e.g.
__GCC_X86_INLINE_ASM_CC__) so we don't have to do
On 05/08/2015 08:54 AM, Richard Henderson wrote:
>
> Anyway, I'll look into whether the branch around alpha can be optimized, but
> I'd be shocked if I'd be able to do anything about the branch around beta.
> True, there's nothing in between that will clobber the flags so it would be an
> excellen
This is a separate issue which really shouldn't have anything to do with
this, but is there a specific reason why:
void good1(int x, int y)
{
_Bool pf;
asm("cmpl %2,%1"
: "=@ccp" (pf)
: "r" (x), "g" (y));
if (pf)
beta();
}
... ends up generating a jump to a jump?
On 05/07/2015 02:38 PM, Richard Henderson wrote:
> Here's a prototype for i386 only, which stands up to light testing.
> I'd rather post this tonight rather than wait until tomorrow when I
> can write more proper dejagnu tests.
>
> I've tested the intermedate patches via config-list.mk, so despite
On 12/18/2014 10:37 AM, Rasmus Villemoes wrote:
>
> Minor thing: If it's not too late, I'd appreciate a 'Suggested-by' or
> similar mention in the kernel change log.
>
I think we can get that.
-hpa
On 12/18/2014 09:43 AM, H.J. Lu wrote:
>
> Peter, please feel free to use my kernel patch or create a different
> one.
>
Great, thanks!
-hpa
m OK with the patch approach, but let's wait for
> eventual comments from Linux people.
>
Acked-by: H. Peter Anvin
H.J. already coordinated with us; we are more than happy with this approach.
Thank you!
-hpa
Richard Henderson wrote:
>On 06/20/2011 04:39 PM, H. Peter Anvin wrote:
>> sys_foo:
>> cmpl$10, %edi
>> jae .L1
>>
>> movqfoo_table(,%rdi,3), %rax
>> retq
>> .L1:
>> movq$-EINVAL, %rax
>> r
On 06/20/2011 03:49 PM, Richard Henderson wrote:
>>
>> As I have already stated, if we *cannot* require pointers to be
>> zero-extended on entry to the kernel, we're going to have to have
>> special entry points for all the x32 system calls except the ones that
>> don't take pointers.
>
> If it's
On 06/20/2011 07:43 AM, H.J. Lu wrote:
> On Mon, Jun 20, 2011 at 7:33 AM, H. Peter Anvin wrote:
>> On 06/20/2011 07:01 AM, H.J. Lu wrote:
>>> On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt
>>> wrote:
>>>> On 06/20/2011 03:51 PM, H.J. Lu wrote:
>&
t a problem since pointer is 64bit
> in kernel and we don't pass pointers on stack to kernel.
As I have already stated, if we *cannot* require pointers to be
zero-extended on entry to the kernel, we're going to have to have
special entry points for all the x32 system calls except the
15 matches
Mail list logo
