compilation fails with IBM xlc in ceval

[GoogleCodeExporter]

In ceval.c, compilation fails with IBM's xlc at the following point:

Python/ceval.c-854-     static Opcode labels[] = {
Python/ceval.c:855:#include "ceval-labels.i"
Python/ceval.c-856-     };

with a message for each entry in ceval-labels.i that is of the form:

"Include/ceval-labels.i", line 1.1: 1506-221 (S) Initializer must be a
valid constant expression. 

I think it's actually just upset about taking the address of a label,
something gcc complains about if you try to compile with -pedantic. It's
not a showstopper as it is still possible to compile ceval with gcc and
finish the build with xlc.

Original issue reported on code.google.com by wscul...@gmail.com on 27 Apr 2009 at 3:45

[GoogleCodeExporter]

Yes, the vmgen implementation's use of computed goto has some portability 
issues. For
the Q1 release branch, where a large part of the speedups comes from using 
vmgen,
we'll have to live with it.

For trunk, where 'hot' functions will end up not using the interpreter part 
anyway,
I'm working on getting rid of vmgen and just using the computed-goto patch used 
in
Python trunk, which is a smidgen slower but makes the whole thing easier to 
maintain.
We'll fix any remaining portability issues afterwards (although I believe the 
trunk
patch already takes care of most of them.)

Original comment by thomaswout@gmail.com on 27 Apr 2009 at 3:56

• Changed state: Started
• Added labels: Type-Defect
• Removed labels: Type-Enhancement

[GoogleCodeExporter]

Original comment by collinw on 28 May 2009 at 10:10

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Is this still an issue now that the vmgen-base eval loop has been replaced with 
the
computed gotos-based one?

Original comment by collinw on 29 May 2009 at 4:15

[GoogleCodeExporter]

It still hits the issue. Sorry for the drop, but wanted to see if IBM's latest 
xlc
for linux would fix the issue. It's still refusing to compile due to the taking 
the
address of a label.

Original comment by wscul...@gmail.com on 23 Jul 2009 at 5:00

[GoogleCodeExporter]

What if you pass --without-computed-gotos to configure? That should disable 
that 
feature.

If that fixes it, we should have configure sanity-check the 
--with-computed-gotos flag 
to make sure the underlying compiler actually supports computed gotos.

Original comment by collinw on 23 Jul 2009 at 5:07

[GoogleCodeExporter]

I reconfigured to use --without-computed-gotos, but had the same result:

w@nu:~/unladen> make
xlc -c  -DNDEBUG -O  -I. -IInclude -I. -I./Include   -DPy_BUILD_CORE -fno-gcse 
-o
Python/ceval.o Python/ceval.c
/opt/ibmcmp/vacpp/bg/9.0/bin/bgxlC: 1501-216 (W) command option -fno-gcse is not
recognized - passed to ld
"Include/ceval-labels.i", line 1.1: 1506-221 (S) Initializer must be a valid 
constant
expression.
"Include/ceval-labels.i", line 2.1: 1506-221 (S) Initializer must be a valid 
constant
expression.
...

Trying things manually with the xlC options explicitly set:
w@nu:~/unladen> xlC -c  -DNDEBUG -O  -I. -IInclude -I. -I./Include   
-DPy_BUILD_CORE
-qlanglvl=extended -o Python/ceval.o Python/ceval.c
"Include/instructionsobject.h", line 21.51: 1506-277 (S) Syntax error: possible
missing ';' or ','?
"Include/instructionsobject.h", line 21.8: 1506-485 (S) Parameter declaration 
list is
incompatible with declarator for inline.
"Include/instructionsobject.h", line 28.12: 1506-045 (S) Undeclared identifier 
inst.
"Include/instructionsobject.h", line 31.73: 1506-277 (S) Syntax error: possible
missing ';' or ','?
"Include/instructionsobject.h", line 31.8: 1506-485 (S) Parameter declaration 
list is
incompatible with declarator for inline.
"Include/instructionsobject.h", line 37.5: 1506-045 (S) Undeclared identifier 
inst.
"Include/instructionsobject.h", line 38.27: 1506-045 (S) Undeclared identifier 
arg.
"Include/ceval-labels.i", line 1.1: 1506-221 (S) Initializer must be a valid 
constant
expression.
"Include/ceval-labels.i", line 2.1: 1506-221 (S) Initializer must be a valid 
constant
expression.
"Include/ceval-labels.i", line 3.1: 1506-221 (S) Initializer must be a valid 
constant
expression.
"Include/ceval-labels.i", line 4.1: 1506-221 (S) Initializer must be a valid 
constant
expression.
...

Original comment by wscul...@gmail.com on 23 Jul 2009 at 7:28

[GoogleCodeExporter]

Include/ceval-labels.i hasn't existed since dropping the vmgen-based eval loop. 
 What
version are you trying to compile?  Try checking out a fresh copy of 2009Q2:
http://code.google.com/p/unladen-swallow/wiki/Release2009Q2

Original comment by abbeyj on 23 Jul 2009 at 8:11

[GoogleCodeExporter]

The error talks about ceval-labels.i, which means you're still using the Q1 
release.
The Q1 release won't be fixed in this regard. It requires computed goto support 
in
the compiler. That requirement was lifted during Q2 work, and the Q2 release no
longer has that requirement.

Can you try the Q2 release and see if that works (without having to pass
--without-computed-gotos that is?)

Original comment by thomaswout@gmail.com on 23 Jul 2009 at 8:15

[GoogleCodeExporter]

Sorry, we've now stuck on an llvm related issue... still fighting through 
this...

Util/llvm/Release-Asserts/bin/clang -O3 -emit-llvm -c  -I. -IInclude -I. 
-I./Include
  -DPy_BUILD_CORE Python/llvm_inline_functions.c -o Python/llvm_inline_functions.bc
clang: warning: not using the clang compiler for the 'ppc' architecture
Util/llvm/Release-Asserts/bin/llc Python/llvm_inline_functions.bc -march=cpp
-cppgen=contents \
        -cppfname=FillInitialGlobalModule -o Include/initial_llvm_module_body.cc -f
Util/llvm/Release-Asserts/bin/llc: bitcode didn't read correctly.
Reason: Bitcode stream should be a multiple of 4 bytes in length
make: *** [Include/initial_llvm_module_body.cc] Error 1
w@nu:~/unladen-2009Q2> 

Original comment by wscul...@gmail.com on 22 Sep 2009 at 6:37

[GoogleCodeExporter]

I believe jyasskin is doing an LLVM update today to pick up some unrelated 
changes. If 
that doesn't fix it and if you have time, I'd recommend trying to build your 
own copy of 
LLVM trunk@head and see if the problem persists. If it does, it's a bug they 
will 
probably want to know about.

Original comment by collinw on 22 Sep 2009 at 7:58

• Changed state: New

[GoogleCodeExporter]

"clang: warning: not using the clang compiler for the 'ppc' architecture" looks
suspicious. I think that clang falls back to gcc when it doesn't understand the
architecture, but it should just fail if you've also asked for -emit-llvm. 
Instead,
it may be emitting object code, which of course doesn't read as bitcode. 

Could you see if clang passes its test suite on your machine?
(http://clang.llvm.org/get_started.html; run `make test` inside tools/clang 
after
building everything.) We'll need to find a way to automatically disable LLVM for
architectures it+clang don't support in any case.

Original comment by jyass...@gmail.com on 22 Sep 2009 at 8:23

[GoogleCodeExporter]

I think I figured out what was going on; despite feeding configure
'--enable-targets=ppc,ppc64,cpp' in the configure script
(http://code.google.com/p/unladen-swallow/source/browse/trunk/configure#25799) 
the
llvm build kept building x86 and cpp targets only. I took the line:

ac_configure_args="$ac_configure_args --enable-jit --enable-targets=x86,cpp
--enable-bindings=none"

and changed it to:

ac_configure_args="$ac_configure_args --enable-jit --enable-targets=all
--enable-bindings=none"

I seem to be winning except on the battle to minimize compile time. I'll report 
back
in a bit.

Original comment by wscul...@gmail.com on 22 Sep 2009 at 10:06

[GoogleCodeExporter]

Oops, sorry for wasting your time. That's http://llvm.org/PR4047. Why didn't I 
ever
commit that?

Original comment by jyass...@gmail.com on 22 Sep 2009 at 11:28

[GoogleCodeExporter]

Jeffrey, bounce this back once the fix for that PR lands; wscullin can try 
again from 
there.

Original comment by collinw on 22 Sep 2009 at 11:47

• Changed state: Accepted

[GoogleCodeExporter]

Meh, no dice. Fixing the target flags didn't get me very far. As per jyasskin's
request, running clang's test suite showed quite a few failures:

********************
Expected Failures (14):

/local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CXX/basic/basic.lookup/basic.
lookup.unqual/p14.cpp

/local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CXX/basic/basic.lookup/basic.
lookup.unqual/p15.cpp

/local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CXX/basic/basic.lookup/basic.
lookup.unqual/p3.cpp

/local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CXX/dcl.dcl/dcl.spec/dcl.fct.
spec/p3.cpp

/local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CXX/dcl.dcl/dcl.spec/dcl.fct.
spec/p4.cpp

/local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CXX/dcl.dcl/dcl.spec/dcl.fct.
spec/p6.cpp

/local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CXX/dcl.dcl/dcl.spec/dcl.stc/
p10.cpp

/local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CXX/dcl.dcl/dcl.spec/dcl.type
def/p4.cpp
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CXX/temp/temp.param/p14.cpp

/local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CXX/temp/temp.res/temp.dep.re
s/temp.point/p1.cpp

/local/w/unladen-2009Q2/Util/llvm/tools/clang/test/SemaCXX/template-specializati
on.cpp
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/SemaObjC/conditional-expr-4.m

/local/w/unladen-2009Q2/Util/llvm/tools/clang/test/SemaObjC/rdr-6211479-array-pr
operty.m
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/SemaObjCXX/references.mm
********************
Failing Tests (26):
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CodeGen/always_inline.c
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CodeGen/bitfield-promote.c
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CodeGen/blocks-seq.c
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CodeGen/call-knr-indirect.c

/local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CodeGen/darwin-string-literal
s.c
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CodeGen/illegal-UTF8.m
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CodeGen/inline.c
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CodeGen/lineno-dbginfo.c
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CodeGen/no-common.c
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CodeGen/stack-protector.c
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/CodeGen/x86_64-arguments.c
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/Driver/clang_cpp.c
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/Driver/clang_f_opts.c
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/Driver/hello.c
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/Driver/pth.c
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/Driver/redzone.c
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/Frontend/dependency-gen.c
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/Lexer/counter.c
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/Misc/message-length.c
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/PCH/pr4489.c

/local/w/unladen-2009Q2/Util/llvm/tools/clang/test/Preprocessor/print_line_count
.c
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/Sema/transparent-union.c
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/Sema/warn-unused-parameters.c

/local/w/unladen-2009Q2/Util/llvm/tools/clang/test/SemaObjC/class-property-acces
s.m
        /local/w/unladen-2009Q2/Util/llvm/tools/clang/test/SemaObjC/ucn-objc-string.m

/local/w/unladen-2009Q2/Util/llvm/tools/clang/test/SemaObjC/warn-unused-paramete
rs.m

The curious part is that I can compile files with clang-cc and produce valid
bytecode. I am currently building llvm/clang separately to see if it's 
something in
the unladen swallow build or clang.

Original comment by wscul...@gmail.com on 23 Sep 2009 at 2:36

[GoogleCodeExporter]

d'oh http://llvm.org/docs/GettingStarted.html#hardware

Original comment by wscul...@gmail.com on 23 Sep 2009 at 3:29

[GoogleCodeExporter]

Original comment by collinw on 9 Oct 2009 at 6:07

[GoogleCodeExporter]

I once tried to build & run Unladen Swallow on a PowerPC Mac; execution would 
abort whenever the JIT kicked in, 
due to ‘symbol stubs’ not being implementing.

If you want to get Unladen Swallow running on AIX/PowerPC, I'd suggest you take 
an incremental approach: First, 
try to get it running on Darwin or Linux using GCC; then, try to get it running 
on AIX using GCC; finally, try to 
get it building with the IBM compiler. Having three unknown factors at the same 
time seems like a recipe for 
disaster… :-)

Original comment by danchr on 9 Oct 2009 at 11:02