On Fri, May 31, 2019 at 05:43:44PM +0200, Mark Brand wrote:
> On Thu, May 30, 2019 at 9:26 PM Tycho Andersen wrote:
> >
> > Hi Andrew,
> >
> > On Thu, May 30, 2019 at 10:09:44AM -0700, Andrew Pinski wrote:
> > > On Thu, May 30, 2019 at 10:01 AM Tycho Andersen wrote:
> > > >
> > > > Hi all,
> > >
On Thu, May 30, 2019 at 9:26 PM Tycho Andersen wrote:
>
> Hi Andrew,
>
> On Thu, May 30, 2019 at 10:09:44AM -0700, Andrew Pinski wrote:
> > On Thu, May 30, 2019 at 10:01 AM Tycho Andersen wrote:
> > >
> > > Hi all,
> > >
> > > I've been trying to implement an idea Andy suggested recently for
> >
Hi Andrew,
On Thu, May 30, 2019 at 10:09:44AM -0700, Andrew Pinski wrote:
> On Thu, May 30, 2019 at 10:01 AM Tycho Andersen wrote:
> >
> > Hi all,
> >
> > I've been trying to implement an idea Andy suggested recently for
> > preventing some kinds of ROP attacks. The discussion of the idea is
> >
On Thu, May 30, 2019 at 10:01 AM Tycho Andersen wrote:
>
> Hi all,
>
> I've been trying to implement an idea Andy suggested recently for
> preventing some kinds of ROP attacks. The discussion of the idea is
> here:
> https://lore.kernel.org/linux-mm/dfa69954-3f0f-4b79-a9b5-893d33d87...@amacapital.
Feng LI writes:
> I'm trying to expand a builtin functions into assembles, with
> processing a little bit for the operands.
>
> Like for the builtin function:
> tcreate (arg0, arg1, arg2)
> I'm trying to generate the assemble code (pseudo):
> TCREATE arg0<<32|arg1, arg2
>
> but I got the followin
Philip Pemberton writes:
>> The address is unusual:
>>
>> (subreg:SI (mem/s:DI (plus:SI (reg/v/f:SI 39 [ ctx ])
>> (const_int 64 [0x40])) [0 S8 A64]) 4)
>>
>> Why isn't that simply
>>
>> (mem/s:SI (plus:SI (reg/v/f:SI 39 [ ctx ])
>> (const_int 68 [0x40]))
On 25/05/10 06:06, Ian Lance Taylor wrote:
The official list of maintainers is stored in the gcc source code in
the file MAINTAINERS. Having said that, there is no maintainer listed
for lm32. I assume that it must be, as you suggest, Jon Beniston.
Yeah, I spotted that in SVN about five minute
Philip Pemberton writes:
> 1) Who's the current maintainer for the lm32 port? Jon Beniston?
> I can't see anything on the gcc website that says definitively "target
> X is maintained by $PERSON", and I really don't want to step on
> his/her toes and start a flame war, turf war or any other kind o
On 18/05/2010 15:24, Paulo J. Matos wrote:
> On Tue, May 18, 2010 at 3:26 PM, Dave Korn wrote:
>>> This however causes an unrecognizable insn error during the compiler
>>> runtime when I have TARGET_X defined.
>>> I was expecting the clobbers not to influence the recognition but it
>>> seems I was
On Tue, May 18, 2010 at 3:26 PM, Dave Korn wrote:
>>
>> This however causes an unrecognizable insn error during the compiler
>> runtime when I have TARGET_X defined.
>> I was expecting the clobbers not to influence the recognition but it
>> seems I was wrong.
>
> Actually, IIUC the clobbers don't
On 18/05/2010 13:01, Paulo J. Matos wrote:
> I have for call_value a define_expand and define_insn that look like:
> (define_expand "call_value"
> [
> (set (match_operand 0 "" "")
> (call (match_operand:QI 1 "nonmemory_operand" "")
>(match_operand:QI 2 "immediate_oper
11 matches
Mail list logo
