Steve Naroff 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@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.
CodeGen/mandel.c
******************** 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)
^
CodeGen/mandel.c:49:43: error: invalid operands to binary expression
('void' and 'int')
if (hypot(__real__ z, __imag__ z) >= ESCAPE)
~~~~~ ^ ~~~~~~
2 diagnostics generated.
; ModuleID = 'foo'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:128:128"
target triple = "i686-pc-linux-gnu"
@accum = global { double, double } zeroinitializer ; <{ double,
double }*> [#uses=0]
******************** TEST 'CodeGen/mandel.c' FAILED! ********************
This is not critical issue or platform for me, this platform is only
used out of convenience as it is up and running in my home. As of right
now it is really only noise in the test output while I am experimenting
with clang, I can live with that until I get a new box most likly with
ubuntu up and running. The harddrive on my old laptop died recently, so
that give me excuse to get a new laptop 
I could look into this problem more if you like me to, I am happy to try
to help.
Also, it should be noted thay my working copy is not clean, see svn
status under. Is there a smart way of working with svn so I can pull my
own working copy changes temporarilly out for testing, then put them
back in. Having two working copies may be the obivious solution, but
having to rebuild all llvm stuff all the time is not all that smooth. I
have tried svk before, and that may be better for me as a none-comitter
in the clang repository. It provide me with local repository, local
branches, and good merge tools. But I am not sure if that really helps
me. Extra working copies may be just as usefull. Any ideas?
[bjorn@frodo clang]$ svn status
? TAGS
? BROWSE
? test/%t1
? test/Lexer/Output
? test/Lexer/c90pedantic.c
M test/Lexer/c90.c
M test/TestRunner.sh
? test/Parser/cxx-extern.cpp
? test/Parser/Output
? test/Parser/c99-cxx-aggregate-initialisers.cpp
M include/clang/Basic/DiagnosticKinds.def
M include/clang/CodeGen/ModuleBuilder.h
M include/clang/AST/ASTContext.h
M include/clang/AST/Decl.h
M include/clang/AST/Type.h
M include/clang/Parse/Parser.h
M include/clang/Parse/Action.h
M Sema/Sema.h
M Sema/SemaDecl.cpp
? AST/Decl.cpp.mine
? AST/Decl.cpp.orig
? AST/Decl.cpp.r45745
? AST/Decl.cpp.r45593
C AST/Decl.cpp
? Driver/ASTConsumers.cpp.r45745
? Driver/ASTConsumers.cpp.r45593
? Driver/ASTConsumers.cpp.mine
? Driver/ASTConsumers.cpp.orig
M Driver/clang.cpp
C Driver/ASTConsumers.cpp
? CodeGen/ModuleBuilder.cpp.orig
M CodeGen/ModuleBuilder.cpp
M Parse/ParseDeclCXX.cpp
M Parse/Parser.cpp
The two conflicts are manually synched with repository version.
[bjorn@frodo clang]$ svn status | grep "^C"
C AST/Decl.cpp
C Driver/ASTConsumers.cpp
[bjorn@frodo clang]$ svn update AST/Decl.cpp
At revision 45759.
[bjorn@frodo clang]$ svn update Driver/ASTConsumers.cpp
At revision 45759.