On Tuesday 17 August 2010 22:53:10 you wrote:
> Job Noorman <jobnoorman@xxxxxxxxx> writes:
> > When I use the "r" constraint, it indeed works and GCC emits the
> > following
> >
> > code:
> > movl $_ZN3Foo6foobarEv, %eax
> > push %eax;
> >
> > What I find strange about this is that GCC has converted
> > "(plain_foobar_t)&Foo::foobar" in a constant value ($_ZN3Foo6foobarEv)
> > without using optimizations. So why can't it do the same when using the
> > "i" constraint?
>
> It can, as you can see, but when not optimizing it won't do it reliably
> before it determines asm constraints.
>
> In other words, there is no simple answer to your question, it's just
> happenstance of how the compiler is written. It's not a bug, because
> the compiler only promises to reduce an address to match the "i"
> constraint when optimizing.
>
> Ian
Hi Ian,
> ... it's just happenstance of how the compiler is written."
No offense but I think that's a non-argument. You could use that to reject
any bug report.
> It's not a bug, because the compiler only promises to reduce an address to
> match the "i" constraint when optimizing.
Where does it promise that? If that's true, why does something like this
always work?:
typedef return_type function(args);
function func;
int main()
{
asm("push %0" : : "i"((function*)&func));
}
I'm still convinced there is some kind of bug here and I think it has
something to do with how GCC handles its PMF to function pointer conversion
extension internally.
I already opened a bug report before I got you first reply so maybe it's easier
to continue the discussion there:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45303
Job
