The Wayback Machine - https://web.archive.org/web/20111004073001/http://lists.trolltech.com/qt4-preview-feedback/2005-02/msg00691.html
Trolltech Home | Qt4-preview-feedback Home | Recent Threads | All Threads | Author | Date
All threads index page 5

Qt4-preview-feedback Archive, February 2005
mkspecs and patches for LLVM compile of Qt4

Message 1 in thread

LLVM cvs can now compile Qt4 from the snapshots available via the unofficial 
svn repository save for a few linking issues. (1)

For those who do not know, LLVM stands for the Low Level Virtual Machine, an 
Open Source project out of the University of Illinois at Urbana-Champaign.  
LLVM has no less of a goal than to replace the aging GCC compiler suite as 
the premier open source tool chain.

The creator and lead author, Chris Lattner, has just been hired by Apple to 
work on LLVM.  Apple is making a major investment in this compilation 
strategy.

Quickly, what it provides now:

*  Re-targeted gcc/g++ frontends that produce LLVM bytecode or native code 
depending upon the switch.

*  An advanced JIT with several optimization strategies.

*  The ability to link with regular g++ compiled libraries and an impressive 
set of compilation strategies over the entire lifetime of the program.

*  The ability to compile Qt4 to bytecode and run it with a JIT.  If I'm not 
mistaken, this is a first for Qt and Trolltech.

What it could provide Trolltech, Qt and KDE:

*  A platform on which to base a permanent solution to the increasingly 
important problem of language bindings for KDE/Qt.

Ok, so now that you know a little about it, I want to tell you that the LLVM 
team has been hard at work exercising the codebase against Qt4.  This 
produced several bugs and fixes over the last few weeks. (2) The result is 
that LLVM can now build Qt4 and will be able to run all the demos very 
shortly.  It can run QMake right now, but we're working on a few problems 
with the linker.

As a result of this work, we've also discovered some bugs and/or inelegant 
code in the Qt4 snapshots.  We've also written mkspecs for LLVM and have 
attached them along with some patches for Qt4.

As soon as we're able to run all the demo's, rest assured, we'll be letting 
everyone know :)  In the meantime, I just wanted to give a head's up and see 
if we can get these mkspecs and patches pushed upstream.

I'll be making a HOWTO compile LLVM cvs and Qt4 at a later point.  In the 
meatime, feel free to email with questions.

Cheers,

Adam Treat

1) http://llvm.cs.uiuc.edu/
2) http://tinyurl.com/4fm9h

Index: src/core/arch/ia64/arch.pri

Index: src/core/arch/ia64/arch.pri
===================================================================
--- src/core/arch/ia64/arch.pri	(revision 42)
+++ src/core/arch/ia64/arch.pri	(working copy)
@@ -9,5 +9,5 @@
 
 HEADERS += $$ARCH_H/qatomic.h
 
-!*-g++:!*-icc:SOURCES += $$ARCH_CPP/qatomic.s
+!*-g++:!*-icc:!*-llvm*:SOURCES += $$ARCH_CPP/qatomic.s
 
Index: src/core/arch/ia64/arch/qatomic.h
===================================================================
--- src/core/arch/ia64/arch/qatomic.h	(revision 42)
+++ src/core/arch/ia64/arch/qatomic.h	(working copy)
@@ -69,7 +69,7 @@
 
 #else // !Q_CC_INTEL
 
-#  if defined(Q_CC_GNU)
+#  if defined(Q_CC_GNU) && !defined(__llvm__)
 
 inline int q_atomic_test_and_set_int(volatile int *ptr, int expected, int newval)
 {
Index: src/core/arch/alpha/arch.pri
===================================================================
--- src/core/arch/alpha/arch.pri	(revision 42)
+++ src/core/arch/alpha/arch.pri	(working copy)
@@ -8,5 +8,5 @@
 DEPENDPATH += $$ARCH_CPP;$$ARCH_H
 
 HEADERS += $$ARCH_H/qatomic.h
-!*-g++*:SOURCES += $$ARCH_CPP/qatomic.s
+!*-g++*:!*-llvm*:SOURCES += $$ARCH_CPP/qatomic.s
 
Index: src/core/arch/alpha/arch/qatomic.h
===================================================================
--- src/core/arch/alpha/arch/qatomic.h	(revision 42)
+++ src/core/arch/alpha/arch/qatomic.h	(working copy)
@@ -31,7 +31,7 @@
 
 #include <QtCore/qglobal.h>
 
-#if defined(Q_CC_GNU)
+#if defined(Q_CC_GNU) && !defined(__llvm__)
 
 inline int q_atomic_test_and_set_int(volatile int *ptr, int expected, int newval)
 {
Index: src/core/arch/i386/arch.pri
===================================================================
--- src/core/arch/i386/arch.pri	(revision 42)
+++ src/core/arch/i386/arch.pri	(working copy)
@@ -9,4 +9,4 @@
 
 HEADERS += $$ARCH_H/qatomic.h
 
-!*-g++*:!*-icc*:SOURCES += $$ARCH_CPP/qatomic.s
+!*-g++*:!*-icc*:!*-llvm*:SOURCES += $$ARCH_CPP/qatomic.s
Index: src/core/arch/i386/arch/qatomic.h
===================================================================
--- src/core/arch/i386/arch/qatomic.h	(revision 42)
+++ src/core/arch/i386/arch/qatomic.h	(working copy)
@@ -31,7 +31,7 @@
 
 #include <QtCore/qglobal.h>
 
-#if defined(Q_CC_GNU) || defined(Q_CC_INTEL)
+#if (defined(Q_CC_GNU) || defined(Q_CC_INTEL)) && !defined(__llvm__)
 
 inline int q_atomic_test_and_set_int(volatile int *ptr, int expected, int newval)
 {

Attachment:

Attachment: llvm-mkspecs.tar.gz
Description: application/tgz

Index: src/core/global/qfixedpoint.cpp
===================================================================
--- src/core/global/qfixedpoint.cpp	(revision 42)
+++ src/core/global/qfixedpoint.cpp	(working copy)
@@ -38,7 +38,7 @@
     return QFixedPoint(root, QFixedPoint::FixedPoint);
 }
 
-#ifdef __i386__
+#if defined(__i386__) && !defined(__llvm__)
 inline double qCos(double a)
 {
     double r;
@@ -99,7 +99,7 @@
     return qCos(f.toDouble());
 }
 
-#ifdef __i386__
+#if defined(__i386__) && !defined(__llvm__)
 inline double qACos(double x)
 {
     // #####
@@ -196,7 +196,7 @@
     return qCos(f.toDouble());
 }
 
-#ifdef __i386__
+#if defined(__i386__) && !defined(__llvm__)
 QFixedPointLong acos(QFixedPointLong f)
 {
     return QFixedPointLong(qACos(f.toDouble()));

Index: src/gui/widgets/qlineedit_p.h

Index: src/gui/widgets/qlineedit_p.h
===================================================================
--- src/gui/widgets/qlineedit_p.h	(revision 42)
+++ src/gui/widgets/qlineedit_p.h	(working copy)
@@ -125,11 +125,11 @@
     enum CommandType { Separator, Insert, Remove, Delete, RemoveSelection, DeleteSelection };
     struct Command {
         inline Command(){}
-        inline Command(CommandType type, int pos, QChar c)
-            :type(type),c(c),pos(pos){}
+        inline Command(CommandType t, int p, QChar ch)
+            :type(t),pos(p),c(ch){}
         uint type : 4;
+        int pos;
         QChar c;
-        int pos;
     };
     int modifiedState;
     int undoState;
Message 2 in thread

Hi,

> As a result of this work, we've also discovered some bugs and/or inelegant 
> code in the Qt4 snapshots.  We've also written mkspecs for LLVM and have 
> attached them along with some patches for Qt4.

Which bugs or inelegeant code have you discovered? If you send a list 
they'll probably get fixed before the final releae.

--
 [ signature omitted ]
Message 3 in thread

On Sunday 20 February 2005 10:34 am, Dimitri wrote:
> Which bugs or inelegeant code have you discovered? If you send a list
> they'll probably get fixed before the final releae.

See the qlinedit_p.h patch for instance.  This is what was there before:

     enum CommandType { Separator, Insert, Remove, Delete, RemoveSelection, 
DeleteSelection };
     struct Command {
         inline Command(){}
-        inline Command(CommandType type, int pos, QChar c)
-            :type(type),c(c),pos(pos){}
+        inline Command(CommandType t, int p, QChar ch)
+            :type(t),pos(p),c(ch){}
         uint type : 4;
+        int pos;
         QChar c;
-        int pos;
     };

See the naming/order of the args...  it is debateable whether the compiler 
should allow this.  We've patched llvm to allow it, but it would be best to 
make this snippet less ambiguous.

The rest of the patches were attached.
Message 4 in thread

Hi,

> See the qlinedit_p.h patch for instance.  This is what was there before:
> [...]

I don't see any such patch attached to the original posting. Could it be
that part of the attachments are missing?

> See the naming/order of the args...  it is debateable whether the compiler 
> should allow this.  We've patched llvm to allow it, but it would be best to 
> make this snippet less ambiguous.

I agree this is not very elegant. Are there other places in Qt with
similar constructs?

That said I think this is legal C++, although not elegant.

> The rest of the patches were attached.

As far as I can see, the rest of the patches are not about Qt bugs or
inelegant code. Again, maybe some patches were missing from teh original
posting?

--
 [ signature omitted ]
Message 5 in thread

On Sunday 20 February 2005 10:52 am, Adam Treat wrote:
> On Sunday 20 February 2005 10:34 am, Dimitri wrote:
> > Which bugs or inelegeant code have you discovered? If you send a list
> > they'll probably get fixed before the final releae.
>
> See the qlinedit_p.h patch for instance.  This is what was there before:
>
>      enum CommandType { Separator, Insert, Remove, Delete, RemoveSelection,
> DeleteSelection };
>      struct Command {
>          inline Command(){}
> -        inline Command(CommandType type, int pos, QChar c)
> -            :type(type),c(c),pos(pos){}
> +        inline Command(CommandType t, int p, QChar ch)
> +            :type(t),pos(p),c(ch){}
>          uint type : 4;
> +        int pos;
>          QChar c;
> -        int pos;
>      };
>
> See the naming/order of the args...  it is debateable whether the compiler
> should allow this.

The naming part is not debatable, at all. 12.6.2, #7 in the standard 
explicitly permits that[1]. So I think you fixed a real bug in LLVM if it 
didn't allow that. 

[1] The draft at http://www.csci.csusb.edu/dick/c++std/cd2/special.html 
already has the language
Message 6 in thread

Hi,

> I'll be making a HOWTO compile LLVM cvs and Qt4 at a later point.  In the 
> meatime, feel free to email with questions.

I had a look at the patches. There's one detail I wish I could have some
explanations on:

	-#  if defined(Q_CC_GNU)
	+#  if defined(Q_CC_GNU) && !defined(__llvm__)

What I understand from this is that the LLVM compiler disguises as the
GNU compiler, and additionally defines __llvm__.

If so, I would suggest modifying
	src/core/global/qglobal.h
testing for __llvm__ and defining Q_CC_LLVM before testing for __GNUC__.
The effect would be that Q_CC_GNU is not defined, and Q_CC_LLVM would be
defined instead. I think Qt follows the same scenario with the Intel
compiler. What do you think about that?

--
 [ signature omitted ]