[cfe-dev] errors running clang/test testcases

[Bjørn Roald]

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