[cfe-dev] errors running clang/test testcases
Steve Naroff
snaroff at apple.com
Sun Jan 13 18:54:27 PST 2008
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
More information about the cfe-dev
mailing list