Christophe Lyon writes:
> On Fri, 11 Jan 2019 at 23:59, Jeff Law wrote:
>>
>> On 1/8/19 5:03 AM, Richard Sandiford wrote:
>> > Bernd Edlinger writes:
>> >> On 1/7/19 10:23 AM, Jakub Jelinek wrote:
>> >>> On Sun, Dec 16, 2018 at 06:13:57PM +0200, Dimitar Dimitrov wrote:
>> - /* Clobbering
On Fri, 11 Jan 2019 at 23:59, Jeff Law wrote:
>
> On 1/8/19 5:03 AM, Richard Sandiford wrote:
> > Bernd Edlinger writes:
> >> On 1/7/19 10:23 AM, Jakub Jelinek wrote:
> >>> On Sun, Dec 16, 2018 at 06:13:57PM +0200, Dimitar Dimitrov wrote:
> - /* Clobbering the STACK POINTER register is an
On 1/8/19 5:03 AM, Richard Sandiford wrote:
> Bernd Edlinger writes:
>> On 1/7/19 10:23 AM, Jakub Jelinek wrote:
>>> On Sun, Dec 16, 2018 at 06:13:57PM +0200, Dimitar Dimitrov wrote:
- /* Clobbering the STACK POINTER register is an error. */
+ /* Clobbered STACK POINTER register is
On Thu, Jan 10, 2019 at 09:56:28PM +, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > On Thu, Jan 10, 2019 at 09:23:27PM +, Richard Sandiford wrote:
> >> > "noreturn"... What would that mean, *exactly*? It cannot execute any
> >> > code the compiler can see, so such asm is better
Segher Boessenkool writes:
>> I think it would act like a noreturn call to an unknown function.
>
> Except it won't behave like a call otherwise (on Power all calls force a
> stack frame, for example; and on all targets noreturn calls do the same
> currently I think?)
I agree no current asm
On Thu, Jan 10, 2019 at 09:23:27PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Tue, Jan 08, 2019 at 12:03:06PM +, Richard Sandiford wrote:
> >> Bernd Edlinger writes:
> >> > Meanwhile I found out, that the stack clobber has only been ignored up to
> >> > gcc-5 (at
On 1/10/19 10:23 PM, Richard Sandiford wrote:
> Segher Boessenkool writes:
>> On Tue, Jan 08, 2019 at 12:03:06PM +, Richard Sandiford wrote:
>>> Bernd Edlinger writes:
Meanwhile I found out, that the stack clobber has only been ignored up to
gcc-5 (at least with lra targets, not
Jakub Jelinek writes:
> On Thu, Jan 10, 2019 at 09:23:27PM +, Richard Sandiford wrote:
>> > "noreturn"... What would that mean, *exactly*? It cannot execute any
>> > code the compiler can see, so such asm is better off as real asm anyway
>> > (not inline asm).
>>
>> "Exactly" is a strong
On Thu, Jan 10, 2019 at 09:23:27PM +, Richard Sandiford wrote:
> > "noreturn"... What would that mean, *exactly*? It cannot execute any
> > code the compiler can see, so such asm is better off as real asm anyway
> > (not inline asm).
>
> "Exactly" is a strong word, and this wasn't my
Segher Boessenkool writes:
> On Tue, Jan 08, 2019 at 12:03:06PM +, Richard Sandiford wrote:
>> Bernd Edlinger writes:
>> > Meanwhile I found out, that the stack clobber has only been ignored up to
>> > gcc-5 (at least with lra targets, not really sure about reload targets).
>> > From gcc-6
Hi!
On Tue, Jan 08, 2019 at 12:03:06PM +, Richard Sandiford wrote:
> Bernd Edlinger writes:
> > Meanwhile I found out, that the stack clobber has only been ignored up to
> > gcc-5 (at least with lra targets, not really sure about reload targets).
> > From gcc-6 on, with the exception of PR
Bernd Edlinger writes:
> On 1/7/19 10:23 AM, Jakub Jelinek wrote:
>> On Sun, Dec 16, 2018 at 06:13:57PM +0200, Dimitar Dimitrov wrote:
>>> - /* Clobbering the STACK POINTER register is an error. */
>>> + /* Clobbered STACK POINTER register is not saved/restored by GCC,
>>> + which is often
On 1/7/19 10:23 AM, Jakub Jelinek wrote:
> On Sun, Dec 16, 2018 at 06:13:57PM +0200, Dimitar Dimitrov wrote:
>> - /* Clobbering the STACK POINTER register is an error. */
>> + /* Clobbered STACK POINTER register is not saved/restored by GCC,
>> + which is often unexpected by users. See
On Sun, Dec 16, 2018 at 06:13:57PM +0200, Dimitar Dimitrov wrote:
> - /* Clobbering the STACK POINTER register is an error. */
> + /* Clobbered STACK POINTER register is not saved/restored by GCC,
> + which is often unexpected by users. See PR52813. */
>if (overlaps_hard_reg_set_p
On Wed, Dec 19, 2018 at 08:40:13AM +0200, Dimitar Dimitrov wrote:
> On Mon, Dec 17 2018 20:15:02 EET Bernd Edlinger wrote:
> > out of curiosity I looked at the clobber statement in
> > gdb/nat/linux-ptrace.c:
> >
> >asm volatile ("pushq %0;"
> > ".globl
On Mon, Dec 17 2018 20:15:02 EET Bernd Edlinger wrote:
> out of curiosity I looked at the clobber statement in
> gdb/nat/linux-ptrace.c:
>
>asm volatile ("pushq %0;"
> ".globl linux_ptrace_test_ret_to_nx_instr;"
>
On 12/18/18 3:16 PM, Bernd Edlinger wrote:
> Hi,
>
> while I looked closely at the asm statement in the gdb,
> I realized that the SP clobber forces the function to use
> the frame pointer, and prevents the red zone. That
> makes the push / pop sequence in the asm statement safe
> to use, as
Hi,
while I looked closely at the asm statement in the gdb,
I realized that the SP clobber forces the function to use
the frame pointer, and prevents the red zone. That
makes the push / pop sequence in the asm statement safe
to use, as long as the stack is restored to the original
value. That
On 12/17/18 7:46 PM, Richard Sandiford wrote:
> Segher Boessenkool writes:
>> On Mon, Dec 17, 2018 at 11:47:42AM +, Richard Sandiford wrote:
>>> Dimitar Dimitrov writes:
On Sun, Dec 16 2018 at 14:36:26 EET Bernd Edlinger wrote:
> Hi,
>
> if I understood that right, then
Segher Boessenkool writes:
> On Mon, Dec 17, 2018 at 11:47:42AM +, Richard Sandiford wrote:
>> Dimitar Dimitrov writes:
>> > On Sun, Dec 16 2018 at 14:36:26 EET Bernd Edlinger wrote:
>> >> Hi,
>> >>
>> >> if I understood that right, then clobbering sp is and has always been
>> >> ignored.
On Mon, Dec 17, 2018 at 11:47:42AM +, Richard Sandiford wrote:
> Dimitar Dimitrov writes:
> > On Sun, Dec 16 2018 at 14:36:26 EET Bernd Edlinger wrote:
> >> Hi,
> >>
> >> if I understood that right, then clobbering sp is and has always been
> >> ignored.
>
> PR77904 was about the clobber
On Sun, Dec 16, 2018 at 10:43:47AM +0200, Dimitar Dimitrov wrote:
> On Fri, Dec 14 2018 2:52:17 EET Segher Boessenkool wrote:
> > You need a few tweaks to what you committed. Or just one perhaps: if
> > flag_pic is not set, you should not check PIC_OFFSET_TABLE_REGNUM, it is
> > meaningless in
On 12/17/18 2:35 PM, Richard Sandiford wrote:
> Christophe Lyon writes:
>> On Mon, 17 Dec 2018 at 12:47, Richard Sandiford
>> wrote:
>>>
>>> Dimitar Dimitrov writes:
On Sun, Dec 16 2018 at 14:36:26 EET Bernd Edlinger wrote:
> Hi,
>
> if I understood that right, then clobbering
On 12/17/18 2:42 PM, Christophe Lyon wrote:
> On Mon, 17 Dec 2018 at 14:35, Richard Sandiford
> wrote:
>>
>> Christophe Lyon writes:
>>> On Mon, 17 Dec 2018 at 12:47, Richard Sandiford
>>> wrote:
Dimitar Dimitrov writes:
> On Sun, Dec 16 2018 at 14:36:26 EET Bernd Edlinger wrote:
On Mon, 17 Dec 2018 at 14:35, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > On Mon, 17 Dec 2018 at 12:47, Richard Sandiford
> > wrote:
> >>
> >> Dimitar Dimitrov writes:
> >> > On Sun, Dec 16 2018 at 14:36:26 EET Bernd Edlinger wrote:
> >> >> Hi,
> >> >>
> >> >> if I understood that
Christophe Lyon writes:
> On Mon, 17 Dec 2018 at 12:47, Richard Sandiford
> wrote:
>>
>> Dimitar Dimitrov writes:
>> > On Sun, Dec 16 2018 at 14:36:26 EET Bernd Edlinger wrote:
>> >> Hi,
>> >>
>> >> if I understood that right, then clobbering sp is and has always been
>> >> ignored.
>>
>>
On Mon, 17 Dec 2018 at 12:47, Richard Sandiford
wrote:
>
> Dimitar Dimitrov writes:
> > On Sun, Dec 16 2018 at 14:36:26 EET Bernd Edlinger wrote:
> >> Hi,
> >>
> >> if I understood that right, then clobbering sp is and has always been
> >> ignored.
>
> PR77904 was about the clobber not being
Dimitar Dimitrov writes:
> On Sun, Dec 16 2018 at 14:36:26 EET Bernd Edlinger wrote:
>> Hi,
>>
>> if I understood that right, then clobbering sp is and has always been
>> ignored.
PR77904 was about the clobber not being ignored, so the behaviour
hasn't been consistent.
I'm also not sure it was
On Sun, Dec 16 2018 at 14:36:26 EET Bernd Edlinger wrote:
> Hi,
>
> if I understood that right, then clobbering sp is and has always been
> ignored.
>
> If that is right, then I would much prefer a warning, that says exactly
> that, because that would also help to understand why removing that
Hi,
if I understood that right, then clobbering sp is and has always been ignored.
If that is right, then I would much prefer a warning, that says exactly that,
because that would also help to understand why removing that clobber statement
is safe even for old gcc versions.
Since your patch did
On Fri, Dec 14 2018 2:52:17 EET Segher Boessenkool wrote:
> You need a few tweaks to what you committed. Or just one perhaps: if
> flag_pic is not set, you should not check PIC_OFFSET_TABLE_REGNUM, it is
> meaningless in that case. I'm not sure if you need to check whether the
> register is
On Fri, Dec 14, 2018 at 01:49:40PM +, Richard Sandiford wrote:
> > OK, I read PR52813 too, but I'm not sure to fully understand the new status.
> > My understanding is that since this patch was committed, if an asm statement
> > clobbers sp, it is now allowed to actually declare it as clobber
(Maybe the discussion has moved on from this already -- sorry if so)
Christophe Lyon writes:
> On Wed, 12 Dec 2018 at 12:21, Thomas Preudhomme
> wrote:
>>
>> So my understanding is that the original code (CMSIS library) used to
>> clobber sp because the asm statement was actually changing the
On Thu, Dec 13, 2018 at 11:26:40PM +0200, Dimitar Dimitrov wrote:
> On Thu, Dec 13, 2018 at 8:48:38 EET Segher Boessenkool wrote:
> > On Wed, Dec 12, 2018 at 06:26:10PM +0200, Dimitar Dimitrov wrote:
> > > I expect that if I mark a HW register as "clobber", compiler would save
> > > its
> > >
On Thu, Dec 13, 2018 at 8:48:38 EET Segher Boessenkool wrote:
> On Wed, Dec 12, 2018 at 06:26:10PM +0200, Dimitar Dimitrov wrote:
> > I expect that if I mark a HW register as "clobber", compiler would save
> > its
> > contents before executing the asm statement, and after that it would
> > restore
On Wed, Dec 12, 2018 at 06:26:10PM +0200, Dimitar Dimitrov wrote:
> I expect that if I mark a HW register as "clobber", compiler would save its
> contents before executing the asm statement, and after that it would restore
> its contents. This is the GCC behaviour for all but the SP and PIC
On Wed, 12 Dec 2018 at 11:03:24 EET Christophe Lyon wrote:
> And just noticed it causes a failure to build GDB for x86_64:
> gdb-8.1-release/gdb/nat/linux-ptrace.c: In function 'void
> linux_ptrace_init_warnings()':
> gdb-8.1-release/gdb/nat/linux-ptrace.c:149:23: error: Stack Pointer
> register
On Wed, 12 Dec 2018 at 14:19:27 EET Christophe Lyon wrote:
> On Wed, 12 Dec 2018 at 12:21, Thomas Preudhomme
>
> wrote:
> > So my understanding is that the original code (CMSIS library) used to
> > clobber sp because the asm statement was actually changing the sp.
> > That in turn led GCC to try
[resending from the right address]
Hi Christophe,
Why not simply: "Clobber of unsupported" with an
accompanying change of the documentation to state the extra bit you
wanted to put in that error message? Perhaps even add a reference to
the section of the documentation in the error message.
On Wed, 12 Dec 2018 at 14:19, Christophe Lyon
wrote:
>
> On Wed, 12 Dec 2018 at 12:21, Thomas Preudhomme
> wrote:
> >
> > So my understanding is that the original code (CMSIS library) used to
> > clobber sp because the asm statement was actually changing the sp.
> > That in turn led GCC to try
On Wed, 12 Dec 2018 at 12:21, Thomas Preudhomme
wrote:
>
> So my understanding is that the original code (CMSIS library) used to
> clobber sp because the asm statement was actually changing the sp.
> That in turn led GCC to try to save and restore sp which is not what
> CMSIS was expecting to
This breaks ia64:
In file included from ../../../libgomp/config/linux/wait.h:46,
from ../../../libgomp/config/linux/mutex.c:30:
../../../libgomp/config/linux/ia64/futex.h: In function 'gomp_mutex_lock_slow':
../../../libgomp/config/linux/ia64/futex.h:43:3: error: Stack Pointer
So my understanding is that the original code (CMSIS library) used to
clobber sp because the asm statement was actually changing the sp.
That in turn led GCC to try to save and restore sp which is not what
CMSIS was expecting to happen. Changing sp without clobber as done now
is probably the right
Hi Christophe,
That PR was about a bug occuring when sp was clobbered so if it cannot
be clobbered anymore the whole commit (r242693) can be removed. Let me
check the original code that lead to the PR why it's clobbering sp
though.
Best regards,
Thomas
On Wed, 12 Dec 2018 at 09:43, Christophe
On Wed, 12 Dec 2018 at 10:42, Christophe Lyon
wrote:
>
> On Tue, 11 Dec 2018 at 16:52, Richard Sandiford
> wrote:
> >
> > Dimitar Dimitrov writes:
> > > On понеделник, 10 декември 2018 г. 11:21:53 EET Richard Sandiford wrote:
> > >> Dimitar Dimitrov writes:
> > >> > I have tested this fix on
On Tue, 11 Dec 2018 at 16:52, Richard Sandiford
wrote:
>
> Dimitar Dimitrov writes:
> > On понеделник, 10 декември 2018 г. 11:21:53 EET Richard Sandiford wrote:
> >> Dimitar Dimitrov writes:
> >> > I have tested this fix on x86_64 host, and found no regression in the C
> >> > and C++
Dimitar Dimitrov writes:
> On понеделник, 10 декември 2018 г. 11:21:53 EET Richard Sandiford wrote:
>> Dimitar Dimitrov writes:
>> > I have tested this fix on x86_64 host, and found no regression in the C
>> > and C++ testsuites. I'm marking this patch as RFC simply because I don't
>> > have
On понеделник, 10 декември 2018 г. 11:21:53 EET Richard Sandiford wrote:
> Dimitar Dimitrov writes:
> > I have tested this fix on x86_64 host, and found no regression in the C
> > and C++ testsuites. I'm marking this patch as RFC simply because I don't
> > have experience with other
Dimitar Dimitrov writes:
> I have tested this fix on x86_64 host, and found no regression in the C
> and C++ testsuites. I'm marking this patch as RFC simply because I don't
> have experience with other architectures, and I don't have a setup to
> test all architectures supported by GCC.
>
>
I have tested this fix on x86_64 host, and found no regression in the C
and C++ testsuites. I'm marking this patch as RFC simply because I don't
have experience with other architectures, and I don't have a setup to
test all architectures supported by GCC.
gcc/ChangeLog:
2018-12-07 Dimitar
50 matches
Mail list logo
