[cfe-commits] [PATCH, RFC] Fix PR14881 (complex integer promotion rules)

Bill Schmidt wschmidt at linux.vnet.ibm.com
Thu Jan 17 07:36:11 PST 2013



On Thu, 2013-01-17 at 09:21 -0600, Will Schmidt wrote:
> On Wed, 2013-01-16 at 15:41 -0600, Bill Schmidt wrote:
> > This patch addresses PR14881.
> > 
> > Prior to the patch, Clang does not properly promote types when a complex
> > integer operand is combined with an integer via a binary operator, or when
> > one is assigned to the other in either order.  This patch detects when
> > promotion is needed (and permissible) and generates the necessary code.
> > 
> > I've included a rather extensive test case to exercise all the various
> > cases, including signed and unsigned variants.  I believe that the necessary
> > handling of signedness is already in place, and the generated code confirms
> > this to my best understanding.  I hope that the test will run on all targets.
> > I've assumed that no target has the same size operands for "char" and
> > "long long," and that no target performs arithmetic on char operands without
> > extending them to a larger format first.  If there are any targets for which
> > this is not the case, the test case will need adjustment.
> 
> If there are targets that don't fit those two assumptions,.. how
> extensive would the adjustments need to be?   Wondering if it would be
> more straightforward to mark as XFAIL for those targets and create
> additional testcase variants for those targets?

If there's a target with sizeof(char) == sizeof(long long), then no
integer promotion is needed, and we'd have to XFAIL for such targets.  I
can't imagine there is such a target, but who knows.

If there are targets that perform arithmetic directly on char, then some
of the variants will fail.  Example: Adding a complex signed char to a
signed char requires extracting the "real" portion of the complex char,
sign-extending it to the smallest size on which addition is possible,
sign-extending the signed char to the same size, performing the add,
truncating the result back to char size, and storing the results.  For a
hypothetical target that can perform arithmetic directly on chars, the
sext and trunc instructions won't be generated, and the tests will fail.
I'm less certain there aren't targets like this.

Bill

> 
> Thanks, 
> -Will
> 
> >   I'd appreciate
> > any information about the validity of my assumptions before I turn the test
> > loose on the world...
> 
> > 
> > Thanks in advance for your review!
> > 
> > _______________________________________________
> > cfe-commits mailing list
> > cfe-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> 
> 




More information about the cfe-commits mailing list