On Mon, 2 Apr 2012, Michael Matz wrote:
On Mon, 2 Apr 2012, Jakub Jelinek wrote:
inline int syscall1(int number, long arg1) {
register int ax __asm__(eax);
register long di __asm__(rdi);
ax = number;
di = arg1;
__asm__ volatile (syscall);
}
_then_ we would
Hi,
On Fri, 30 Mar 2012, Jan Hubicka wrote:
Motion across hardreg sets/uses are not restricted. And I would not expect
an optimizing compiler to do that (it's your own fault to use hardregs in
complex C code).
Well, the syscall sequence is an example of somehting that should be
On Mon, Apr 02, 2012 at 04:07:59PM +0200, Michael Matz wrote:
On Fri, 30 Mar 2012, Jan Hubicka wrote:
Motion across hardreg sets/uses are not restricted. And I would not
expect
an optimizing compiler to do that (it's your own fault to use hardregs in
complex C code).
Well,
Hi,
On Mon, 2 Apr 2012, Jakub Jelinek wrote:
inline int syscall1(int number, long arg1) {
register int ax __asm__(eax);
register long di __asm__(rdi);
ax = number;
di = arg1;
__asm__ volatile (syscall);
}
_then_ we would probably get miscompilations here and there.
On Thu, Mar 29, 2012 at 8:34 PM, Richard Henderson r...@redhat.com wrote:
On 03/29/2012 01:16 PM, Jan Hubicka wrote:
Of course, there's still the problem of getting the unwind data correct at
the point of the asm. I commented about that in the PR you filed.
I think i386 still has the problem
On Thu, Mar 29, 2012 at 3:59 PM, Michael Matz m...@suse.de wrote:
Hi,
On Thu, 29 Mar 2012, Stephan Bergmann wrote:
Anyway, would it be worthwhile filing an RFE for an asm annotation
telling the compiler that it contains code that can throw?
I suppose yes.
On Thu, Mar 29, 2012 at 8:34 PM, Richard Henderson r...@redhat.com wrote:
On 03/29/2012 01:16 PM, Jan Hubicka wrote:
Of course, there's still the problem of getting the unwind data correct at
the point of the asm. I commented about that in the PR you filed.
I think i386 still has the
2012/3/30 Jan Hubicka hubi...@ucw.cz:
On Thu, Mar 29, 2012 at 8:34 PM, Richard Henderson r...@redhat.com wrote:
On 03/29/2012 01:16 PM, Jan Hubicka wrote:
Of course, there's still the problem of getting the unwind data correct
at
the point of the asm. I commented about that in the PR
Motion across hardreg sets/uses are not restricted. And I would not expect
an optimizing compiler to do that (it's your own fault to use hardregs in
complex C code).
Well, the syscall sequence is an example of somehting that should be inlined
into arbitrary code w/o potential risk of ICEs.
Hi all,
In LibreOffice's ever-beloved low-level code to synthesize calls to C++
virtual functions, I'm having the following problem (on Linux x86_64).
The function callVirtualMethod at
On Thu, Mar 29, 2012 at 09:05:29AM +0200, Stephan Bergmann wrote:
In LibreOffice's ever-beloved low-level code to synthesize calls to
C++ virtual functions, I'm having the following problem (on Linux
x86_64). The function callVirtualMethod at
On 03/29/2012 09:44 AM, Jakub Jelinek wrote:
On Thu, Mar 29, 2012 at 09:05:29AM +0200, Stephan Bergmann wrote:
In LibreOffice's ever-beloved low-level code to synthesize calls to
C++ virtual functions, I'm having the following problem (on Linux
x86_64). The function callVirtualMethod
On Thu, Mar 29, 2012 at 10:47 AM, Stephan Bergmann sberg...@redhat.com wrote:
On 03/29/2012 09:44 AM, Jakub Jelinek wrote:
On Thu, Mar 29, 2012 at 09:05:29AM +0200, Stephan Bergmann wrote:
In LibreOffice's ever-beloved low-level code to synthesize calls to
C++ virtual functions, I'm having
On 03/29/2012 11:16 AM, Richard Guenther wrote:
On Thu, Mar 29, 2012 at 10:47 AM, Stephan Bergmannsberg...@redhat.com wrote:
So an explicit -fnon-call-exceptions on the command line seems to indeed
help. Unfortunately, moving that into a
#pragma GCC optimize (non-call-exceptions)
at the
Hi,
On Thu, 29 Mar 2012, Stephan Bergmann wrote:
Anyway, would it be worthwhile filing an RFE for an asm annotation
telling the compiler that it contains code that can throw?
I suppose yes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52770 RFE: Letting
compiler know asm block can
On 03/29/2012 02:59 PM, Michael Matz wrote:
Actually, with -fnon-call-exceptions volatile asms are already supposed to
be throwing. It's just that this got lost with tree-ssa. With the patch
and -fnon-call-exceptions a simple __asm__ volatile (...) is regarded as
possibly throwing.
On 03/29/2012 04:12 PM, Andrew Haley wrote:
On 03/29/2012 02:59 PM, Michael Matz wrote:
Actually, with -fnon-call-exceptions volatile asms are already supposed to
be throwing. It's just that this got lost with tree-ssa. With the patch
and -fnon-call-exceptions a simple __asm__ volatile (...)
Hi,
On Thu, 29 Mar 2012, Andrew Haley wrote:
On 03/29/2012 02:59 PM, Michael Matz wrote:
Actually, with -fnon-call-exceptions volatile asms are already supposed to
be throwing. It's just that this got lost with tree-ssa. With the patch
and -fnon-call-exceptions a simple __asm__
On 03/29/2012 03:05 AM, Stephan Bergmann wrote:
Hi all,
In LibreOffice's ever-beloved low-level code to synthesize calls to
C++ virtual functions, I'm having the following problem (on Linux
x86_64). The function callVirtualMethod at
On 03/29/2012 03:05 AM, Stephan Bergmann wrote:
Hi all,
In LibreOffice's ever-beloved low-level code to synthesize calls to
C++ virtual functions, I'm having the following problem (on Linux
x86_64). The function callVirtualMethod at
On 03/29/2012 01:16 PM, Jan Hubicka wrote:
Of course, there's still the problem of getting the unwind data correct at
the point of the asm. I commented about that in the PR you filed.
I think i386 still has the problem that it is small register class target and
if you
set rdi/rax and
non-call-exceptions is a relatively big hammer. It marks _all_
non-trivial instructions as throwing.
The all goes against the relatively here, and relatively is more correct.
Not all non-trivial instructions are marked as throwing, e.g. loads and stores
from/to the stack aren't.
--
Eric
22 matches
Mail list logo
