[cfe-dev] errors running clang/test testcases

[Steve Naroff]

Thanks much for the test case. Commit r45951 should fix this problem.

Please let me know if you have any problems,

snaroff

On Jan 13, 2008, at 3:37 AM, Bjørn Roald wrote:

> Bjørn Roald skrev:
>> Steve Naroff skrev:
>>
>>> 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.
>>>
>>
>> Ok, I will see when I get some time.  That will not happen in the  
>> first few days, but if this only directly affects me now, then that  
>> is probably ok.
>>
> Ok, here is one function which give the error in clang and is  
> accepted by gcc.
> Then there is a function that is accepted by both compilers.  Hope  
> this helps.
>
> void f3_2_0() {
>  __typeof__ (* (__typeof__ (0 ? (double *) 0 : (void *) (double*)  
> 0 ) ) 0 ) a;          // gcc: Ok , clang  
> error                               ^^^^^^^^^
> }
>
> void f3_2_0_1() {
>  __typeof__ (* (__typeof__ (0 ? (double *) 0 : (void *)             
> 0 ) ) 0 ) a;
>  // gcc/clang: Ok                                        ^^^^^^^^
> }
>
> Simplifying further caused the two compilerd to behave in the same  
> way, accepting or  rejecting the code.
>
> -- 
> Bjørn