http://bugzilla.gdcproject.org/show_bug.cgi?id=115

--- Comment #2 from Iain Buclaw <ibuclaw@gdcproject.org> ---
Are you using a compiler with --enable-checking? Release compilers don't generally complain about mismatched arguments.

I'll have a look when I get time.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=115

Johannes Pfau <johannespfau@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |johannespfau@gmail.com

--- Comment #1 from Johannes Pfau <johannespfau@gmail.com> ---
The problem starts in the frontend, optimize.c(DotVarExp::optimize).
It optimizes 'func(_f(a).i)' into 'func (a)', so it produces a call to func
with an incorrectly typed parameter.

The backend then tries to pass 'a' in floating point register leading to these strange results.

@Iain do you think this should be fixed in the frontend or in the glue layer by doing an explicit conversion? I also wonder why the GCC backend didn't catch this problem, I thought it should know there's a type mismatch between the function declaration and the actual call?

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=115

--- Comment #3 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to comment #1)
> The problem starts in the frontend, optimize.c(DotVarExp::optimize).
> It optimizes 'func(_f(a).i)' into 'func (a)', so it produces a call to func
> with an incorrectly typed parameter.
> 
> The backend then tries to pass 'a' in floating point register leading to these strange results.
> 
> @Iain do you think this should be fixed in the frontend or in the glue layer by doing an explicit conversion? I also wonder why the GCC backend didn't catch this problem, I thought it should know there's a type mismatch between the function declaration and the actual call?

You could do a view convert in SymbolExp if 'this->type' and 'this->var->type' mismatch.  There'd be no way to enforce that we are dealing with a union optimisation though...

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=115

--- Comment #4 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to comment #3)
> (In reply to comment #1)
> > The problem starts in the frontend, optimize.c(DotVarExp::optimize).
> > It optimizes 'func(_f(a).i)' into 'func (a)', so it produces a call to func
> > with an incorrectly typed parameter.
> > 
> > The backend then tries to pass 'a' in floating point register leading to these strange results.
> > 
> > @Iain do you think this should be fixed in the frontend or in the glue layer by doing an explicit conversion? I also wonder why the GCC backend didn't catch this problem, I thought it should know there's a type mismatch between the function declaration and the actual call?
> 
> You could do a view convert in SymbolExp if 'this->type' and 'this->var->type' mismatch.  There'd be no way to enforce that we are dealing with a union optimisation though...

*SymbolExp::toElem

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=115

Johannes Pfau <johannespfau@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from Johannes Pfau <johannespfau@gmail.com> ---
https://github.com/D-Programming-GDC/GDC/commit/d1afed7fa3b4482e41df95bd21326d1a2f9f1653

-- 
You are receiving this mail because:
You are watching all bug changes.