On Tue, Feb 6, 2018 at 3:38 AM, Richard Earnshaw (lists)
wrote:
> On 02/02/18 20:55, Eric Botcazou wrote:
>>> But, that is not what the builtin setjmp/longjmp tests have.
>>
>> Yes, but I don't think that we want to risk breaking a working compiler on
>> some targets because peculiar tests don't p
On 02/02/18 20:55, Eric Botcazou wrote:
>> But, that is not what the builtin setjmp/longjmp tests have.
>
> Yes, but I don't think that we want to risk breaking a working compiler on
> some targets because peculiar tests don't pass on another. I think that
> init_eh is OK for x32 so SJLJ except
> I think it should be a predefined macro.
Macros cannot be used outside of the C family of languages while builtins can,
but a macro might be sufficient in practice and easier to implement indeed.
--
Eric Botcazou
On Fri, Feb 2, 2018 at 12:55 PM, Eric Botcazou wrote:
>> But, that is not what the builtin setjmp/longjmp tests have.
>
> Yes, but I don't think that we want to risk breaking a working compiler on
> some targets because peculiar tests don't pass on another. I think that
> init_eh is OK for x32 so
> But, that is not what the builtin setjmp/longjmp tests have.
Yes, but I don't think that we want to risk breaking a working compiler on
some targets because peculiar tests don't pass on another. I think that
init_eh is OK for x32 so SJLJ exceptions work and the issue is only with the
undocum
On Fri, Feb 2, 2018 at 10:54 AM, Eric Botcazou wrote:
>> One more thing. Word can be bigger than pointer on ILP32 targets.
>> 5 pointers aren't sufficient.
>
> Yes, that's why the buffer should be 5 words, as init_eh allocates now.
>
But, that is not what the builtin setjmp/longjmp tests have.
> One more thing. Word can be bigger than pointer on ILP32 targets.
> 5 pointers aren't sufficient.
Yes, that's why the buffer should be 5 words, as init_eh allocates now.
--
Eric Botcazou
On Fri, Feb 2, 2018 at 9:57 AM, H.J. Lu wrote:
> On Fri, Feb 2, 2018 at 9:53 AM, Eric Botcazou wrote:
>>> We currently read and write beyond the builtin jmpbuf on ILP32 targets
>>> where Pmode == DImode and ptr_mode == SImode. Since the builtin jmpbuf
>>> is an array of 5 pointers, ptr_mode shou
On Fri, Feb 2, 2018 at 9:53 AM, Eric Botcazou wrote:
>> We currently read and write beyond the builtin jmpbuf on ILP32 targets
>> where Pmode == DImode and ptr_mode == SImode. Since the builtin jmpbuf
>> is an array of 5 pointers, ptr_mode should be used to save and restore
>> frame and program p
> We currently read and write beyond the builtin jmpbuf on ILP32 targets
> where Pmode == DImode and ptr_mode == SImode. Since the builtin jmpbuf
> is an array of 5 pointers, ptr_mode should be used to save and restore
> frame and program pointers. Since x86 only saves stack pointer in
> stack sa
register_operand" ""))
>> + (use (match_operand 1 "memory_operand" ""))]
>> + ""
>> +{
>> + /* Stack is saved in ptr_mode and stack register is in Pmode. */
>> + if (GET_MODE (operands[0]) != GET_MODE (operands[1]))
&
On Thu, Feb 1, 2018 at 1:16 AM, H.J. Lu wrote:
>
> We currently read and write beyond the builtin jmpbuf on ILP32 targets
> where Pmode == DImode and ptr_mode == SImode. Since the builtin jmpbuf
> is an array of 5 pointers, ptr_mode should be used to save and restore
> frame and program pointers.
We currently read and write beyond the builtin jmpbuf on ILP32 targets
where Pmode == DImode and ptr_mode == SImode. Since the builtin jmpbuf
is an array of 5 pointers, ptr_mode should be used to save and restore
frame and program pointers. Since x86 only saves stack pointer in
stack save area,
13 matches
Mail list logo
