[cfe-dev] errors running clang/test testcases

Steve Naroff snaroff at apple.com
Wed Jan 9 10:35:40 PST 2008


On Jan 9, 2008, at 7:30 AM, Bjørn Roald wrote:

> Steve Naroff wrote:
>>
>> On Jan 6, 2008, at 2:54 PM, Chris Lattner wrote:
>>
>>>
>>> On Jan 6, 2008, at 2:00 PM, Bjørn Roald wrote:
>>>
>>>> Chris Lattner wrote:
>>>>
>>>> Thanks for your reply Chris,
>>>>>> ******************** TEST 'CodeGen/mandel.c' FAILED!
>>>>>> ********************
>>>>>> Command:
>>>>>> clang -emit-llvm CodeGen/mandel.c
>>>>>> Output:
>>>>>> CodeGen/mandel.c:49:13: error: variable has incomplete type
>>>>>> 'typeof(*(0 ? (typeof(0 ? (double *)0 : (void *) 
>>>>>> ((((typeof((__real
>>>>>> z) + (__imag z)))0.25) && ((typeof((__real z) + (__imag  
>>>>>> z)))0.25 -
>>>>>> 1)))))0 : (typeof(0 ? (typeof((__real z) + (__imag z)) *)0 :  
>>>>>> (void
>>>>>> *)(!((((typeof((__real z) + (__imag z)))0.25) && ((typeof((__real
>>>>>> z) + (__imag z)))0.25 - 1))))))0))'
>>>>>>     if (hypot(__real__ z, __imag__ z) >= ESCAPE)
>>>>>
>>>>> Please make a .i file for mandel.c (clang -E mandel.c > mandel.i)
>>>>> and send it to the list.
>>>>
>>>> attached
>>>
>>> Okay, this ugliness seems to be because your system hypot expands  
>>> out
>>> into some amazingly nasty stuff.  Here is a reduced testcase:
>>>
>>> void foo() {
>>>  *((__typeof__ (0 ? (double *)0 : (void *)0)) 0) = 0;
>>> }
>>>
>>> cond.c:2:3: warning: dereferencing void pointer
>>>  *((__typeof__ (0 ? (double *)0 : (void *)0)) 0) = 0;
>>>  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> cond.c:2:51: error: incomplete type 'void' is not assignable
>>>  *((__typeof__ (0 ? (double *)0 : (void *)0)) 0) = 0;
>>>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
>>>
>>> This is because of this fixme in sema:
>>>
>>>      // The pointer types are compatible.
>>>      // C99 6.5.15p6: If both operands are pointers to compatible
>>> types *or* to
>>>      // differently qualified versions of compatible types, the
>>> result type is
>>>      // a pointer to an appropriately qualified version of the
>>> *composite*
>>>      // type.
>>>      // FIXME: Need to return the composite type.
>>>      return lexT;
>>>
>>> Steve, can you please take a look at this?  Also, the code isn't
>>> handling a number of other cases explicitly mentioned in the  
>>> standard,
>>> such as "const int *" + "volatile int *"  -> "const volatile int*".
>>>
>>
>> I just submitted a fix for this. The FIXME still remains (it didn't  
>> have anything to do with this particular bug).
>
> I did svn update of both llvm and clang, and rebuild all
>
> [bjorn at frodo clang]$ svn update
> At revision 45757.
>
> I still seem to have the same problem in test/CodeGen/mantel.c. I have
> provided mantel.i before, so if you compiled successfully with that as
> input there must be something else?  I am not sure if you expected  
> this
> to go away.  If you tested the limitet testcase Chris made, that may  
> not
> have done it.
>

I only tested Chris's reduced test case (as you suggest).

I am able to reproduce this using your .i file. Unfortunately, the  
expression is still hard to work with (since it's nearly 1000  
characters long).

If you could provide a reduced test case, it would help me localize/ 
nail this bug.

Thanks,

snaroff





More information about the cfe-dev mailing list