This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix PR46399 - missing mode promotion for libcall args - updated


On 03/03/2011 05:32 PM, Andreas Krebbel wrote:
> [PATCH] Fix PR46399 - missing mode promotion for libcall args
> http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01595.html
> 
> after removing the FUNCTION_VALUE target macro with:
> 
> [Committed] S/390: Remove deprecated target macro FUNCTION_VALUE
> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00127.html
> 
> And I've moved the documentation of the new target hook to target.def
> as requested by Nathan.
> 
> Bootstrapped on x86_64, s390 and s390x. No regressions.
> 
> Two testcases fixed on s390x:
> 
> < FAIL: gcc.dg/dfp/pr41049.c execution test
> < FAIL: decimal/comparison.cc execution test

The problem is quite real, it's just bitten us with some ARM changes.
The fact that we don't have types for libcall function args is very
unfortunate. Maybe that's something we need to change? It would be a
much better fix, and it might not even be _that_ much work to add an
optional type field to each optab entry, which could then be passed to
emit_library_call - if it's nonnull, we'd use the normal
promote_function_mode hook otherwise ignore the problem as before. This
would allow us to solve the s390 problem reasonably quickly and lets us
add more libcall types later.

As to the existing patch, isn't fntype NULL throughout
emit_library_call_value_1? It might make sense to lose that argument
from the hook. I also doubt that the unsignedp bit is very useful
without an argument type, but I'm at a loss to think of something
sensible to do about it.


Bernd


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]