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

John McCall rjmccall at apple.com
Tue Jan 22 15:50:58 PST 2013


On Jan 16, 2013, at 1:41 PM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> 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.  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!

Minor point:
+    const QualType LHSBaseType = LHSComplexInt->getElementType();
We don't usually make local variables 'const' like this.  It looks like you
don't, either, except that you want to do it to QualType.  QualType is a very
small, cheap-to-copy value type — essentially a pointer — and you should
treat it like any other type with those properties.

Major point:  it doesn't look like you're considering signedness at all as
part of your promotions.  C wants us to do the usual arithmetic conversions
on the corresponding real type in order to select the common real type;
maybe you can extract those out from handleIntegerConversion somehow?

John.



More information about the cfe-commits mailing list