headers
Quentin Mathé | 7 Nov 2011 13:04
Picon

Clang 3.0 rc 1 and LanguageKit Status

Hi,

To compile LanguageKit, I had to work around the glibc __block issue in various places once again. 
The patch is pretty ugly, so before committing it I wanted to know if someone had a better solution.

I tested various examples from the Compiler/Examples directory, and they run fine. However test.st
doesn't work, I get:

edlc -f test.st 
2011-11-07 13:00:59.907 edlc[9986] ERROR: Can not determine type for sqrt
2011-11-07 13:00:59.909 edlc[9986] ERROR: Can not determine type for fdim
2011-11-07 13:00:59.909 edlc[9986] ERROR: Can not determine type for fdim
2011-11-07 13:00:59.909 edlc[9986] ERROR: Can not determine type for putchar
2011-11-07 13:00:59.909 edlc[9986] ERROR: Can not determine type for putchar
2011-11-07 13:00:59.909 edlc[9986] ERROR: Can not determine type for putchar
2011-11-07 13:00:59.911 edlc[9986] Failed to compile input.

I also ran the test suite. Various Smalltalk tests related to the interpreter fail, but the JIT tests pass in
most cases except:
- TestRetainOnlyOnce (may be it's an excepted failure…)
- TestTimesRepeat (removed from the output below, because it never ends)

For the record, I'm on Ubuntu 10.4 x86-32.

In addition, all EtoileFoundation tests pass with the current libobjc2 from trunk and Clang 3.0 rc 1.

Here is the Smalltalk test suite result (with TestTimesRepeat disabled):

------------------------------------------------------
Test: TestArrayLiterals -i
(Continue reading)

Permalink | Reply |
headers
David Chisnall | 7 Nov 2011 13:46

Re: Clang 3.0 rc 1 and LanguageKit Status

On 7 Nov 2011, at 12:04, Quentin Mathé wrote:

> Hi,
> 
> To compile LanguageKit, I had to work around the glibc __block issue in various places once again. 
> The patch is pretty ugly, so before committing it I wanted to know if someone had a better solution.

The same better solution I've suggested the last four times you've encountered this problem:

$ cat unistd.h
#ifdef __block
#	undef __block
#	include_next "unistd.h"
#	define __block __attribute__((__blocks__(byref)))
#else
#	include_next "unistd.h"
#endif

Just drop this file into any directory that has problem (or install it in Local/Library/Headers) and never
think about it again.

> I tested various examples from the Compiler/Examples directory, and they run fine. However test.st
doesn't work, I get:
> 
> edlc -f test.st 
> 2011-11-07 13:00:59.907 edlc[9986] ERROR: Can not determine type for sqrt
> 2011-11-07 13:00:59.909 edlc[9986] ERROR: Can not determine type for fdim
> 2011-11-07 13:00:59.909 edlc[9986] ERROR: Can not determine type for fdim
> 2011-11-07 13:00:59.909 edlc[9986] ERROR: Can not determine type for putchar
> 2011-11-07 13:00:59.909 edlc[9986] ERROR: Can not determine type for putchar
(Continue reading)

Permalink | Reply |
headers
Quentin Mathé | 8 Nov 2011 13:29
Picon

Re: Clang 3.0 rc 1 and LanguageKit Status

Le 7 nov. 2011 à 13:46, David Chisnall a écrit :

> On 7 Nov 2011, at 12:04, Quentin Mathé wrote:
> 
>> Hi,
>> 
>> To compile LanguageKit, I had to work around the glibc __block issue in various places once again. 
>> The patch is pretty ugly, so before committing it I wanted to know if someone had a better solution.
> 
> The same better solution I've suggested the last four times you've encountered this problem:
> 
> $ cat unistd.h
> #ifdef __block
> #	undef __block
> #	include_next "unistd.h"
> #	define __block __attribute__((__blocks__(byref)))
> #else
> #	include_next "unistd.h"
> #endif
> 
> Just drop this file into any directory that has problem (or install it in Local/Library/Headers) and
never think about it again.

I read about this solution in a recent mail you sent about ObjectMerging, but I thought it wouldn't work in
this case since the include directives to override are in the LLVM code.
But it does work. That's neat.

>> I tested various examples from the Compiler/Examples directory, and they run fine. However test.st
doesn't work, I get:
>>
(Continue reading)

Permalink | Reply |
headers
David Chisnall | 8 Nov 2011 13:35

Re: Clang 3.0 rc 1 and LanguageKit Status


On 8 Nov 2011, at 12:29, Quentin Mathé wrote:

> Le 7 nov. 2011 à 13:46, David Chisnall a écrit :
> 
>> On 7 Nov 2011, at 12:04, Quentin Mathé wrote:
>> 
>>> Hi,
>>> 
>>> To compile LanguageKit, I had to work around the glibc __block issue in various places once again. 
>>> The patch is pretty ugly, so before committing it I wanted to know if someone had a better solution.
>> 
>> The same better solution I've suggested the last four times you've encountered this problem:
>> 
>> $ cat unistd.h
>> #ifdef __block
>> #	undef __block
>> #	include_next "unistd.h"
>> #	define __block __attribute__((__blocks__(byref)))
>> #else
>> #	include_next "unistd.h"
>> #endif
>> 
>> Just drop this file into any directory that has problem (or install it in Local/Library/Headers) and
never think about it again.
> 
> I read about this solution in a recent mail you sent about ObjectMerging, but I thought it wouldn't work in
this case since the include directives to override are in the LLVM code.
> But it does work. That's neat.
>
(Continue reading)

Permalink | Reply |
headers
Ulrich Pöhlmann | 7 Nov 2011 21:47
Picon

Re: Clang 3.0 rc 1 and LanguageKit Status

On 11/07/2011 01:04 PM, Quentin Mathé wrote:
Hi, To compile LanguageKit, I had to work around the glibc __block issue in various places once again. The patch is pretty ugly, so before committing it I wanted to know if someone had a better solution.
Isn't that patch already included in etoile trunk? After running "make install" I got the patch automatically installed under "/Local/Library/Headers/EtoileFoundation/glibc_hack_unistd.h".
I tested various examples from the Compiler/Examples directory, and they run fine. However test.st doesn't work, I get: edlc -f test.st 2011-11-07 13:00:59.907 edlc[9986] ERROR: Can not determine type for sqrt 2011-11-07 13:00:59.909 edlc[9986] ERROR: Can not determine type for fdim 2011-11-07 13:00:59.909 edlc[9986] ERROR: Can not determine type for fdim 2011-11-07 13:00:59.909 edlc[9986] ERROR: Can not determine type for putchar 2011-11-07 13:00:59.909 edlc[9986] ERROR: Can not determine type for putchar 2011-11-07 13:00:59.909 edlc[9986] ERROR: Can not determine type for putchar 2011-11-07 13:00:59.911 edlc[9986] Failed to compile input.
Same for me.
I also ran the test suite. Various Smalltalk tests related to the interpreter fail, but the JIT tests pass in most cases except: - TestRetainOnlyOnce (may be it's an excepted failure…) - TestTimesRepeat (removed from the output below, because it never ends)
TestTimesRepeat neved ends for me too, When i run the test manually, it never ends when the option "-i" is passed.
For the record, I'm on Ubuntu 10.4 x86-32.
I'm running Ubuntu 11.10 x86-32.
In addition, all EtoileFoundation tests pass with the current libobjc2 from trunk and Clang 3.0 rc 1. Here is the Smalltalk test suite result (with TestTimesRepeat disabled): ------------------------------------------------------ Test: TestArrayLiterals -i -e TestArrayLiterals: OK ------------------------------------------------------ Test: TestArrayLiterals -e TestArrayLiterals: OK ------------------------------------------------------ Test: TestBlockAssignment -i Segmentation fault -e TestBlockAssignment: FAIL (crash) ------------------------------------------------------ Test: TestBlockAssignment -e TestBlockAssignment: OK ------------------------------------------------------ Test: TestBlockReturn -i Segmentation fault -e TestBlockReturn: FAIL (crash) ------------------------------------------------------ Test: TestBlockReturn -e TestBlockReturn: OK ------------------------------------------------------ Test: TestBlockReturningABlock -i -e TestBlockReturningABlock: OK ------------------------------------------------------ Test: TestBlockReturningABlock -e TestBlockReturningABlock: OK ------------------------------------------------------ Test: TestCascadedMessages -i -e TestCascadedMessages: OK ------------------------------------------------------ Test: TestCascadedMessages -e TestCascadedMessages: OK ------------------------------------------------------ Test: TestClassMethods1 -i Segmentation fault -e TestClassMethods1: FAIL (crash) ------------------------------------------------------ Test: TestClassMethods1 -e TestClassMethods1: OK ------------------------------------------------------ Test: TestClassMethods2 -i Segmentation fault -e TestClassMethods2: FAIL (crash) ------------------------------------------------------ Test: TestClassMethods2 -e TestClassMethods2: OK ------------------------------------------------------ Test: TestClassMethods3 -i Segmentation fault -e TestClassMethods3: FAIL (crash) ------------------------------------------------------ Test: TestClassMethods3 -e TestClassMethods3: OK ------------------------------------------------------ Test: TestClassVariables -i -e TestClassVariables: OK ------------------------------------------------------ Test: TestClassVariables -e TestClassVariables: OK ------------------------------------------------------ Test: TestClassVariables2 -i -e TestClassVariables2: OK ------------------------------------------------------ Test: TestClassVariables2 -e TestClassVariables2: OK ------------------------------------------------------ Test: TestComplexBoxing -i Aborted -e TestComplexBoxing: FAIL (crash) ------------------------------------------------------ Test: TestComplexBoxing -e TestComplexBoxing: OK ------------------------------------------------------ Test: TestCountingWhileTrue -i -e TestCountingWhileTrue: OK ------------------------------------------------------ Test: TestCountingWhileTrue -e TestCountingWhileTrue: OK ------------------------------------------------------ Test: TestDealloc -i -e TestDealloc: FAIL result | expected > Sub destroyed > Super destroyed ------------------------------------------------------ Test: TestDealloc -e TestDealloc: FAIL result | expected > Sub destroyed > Super destroyed ------------------------------------------------------ Test: TestDeeplyNestedBlocks -i -e TestDeeplyNestedBlocks: OK ------------------------------------------------------ Test: TestDeeplyNestedBlocks -e TestDeeplyNestedBlocks: OK ------------------------------------------------------ Test: TestFloatBoxing -i -e TestFloatBoxing: OK ------------------------------------------------------ Test: TestFloatBoxing -e TestFloatBoxing: OK ------------------------------------------------------ Test: TestInstanceVariables -i -e TestInstanceVariables: OK ------------------------------------------------------ Test: TestInstanceVariables -e TestInstanceVariables: OK ------------------------------------------------------ Test: TestIntArithmetic -i -e TestIntArithmetic: OK ------------------------------------------------------ Test: TestIntArithmetic -e TestIntArithmetic: OK ------------------------------------------------------ Test: TestIntegerAddition -i -e TestIntegerAddition: OK ------------------------------------------------------ Test: TestIntegerAddition -e TestIntegerAddition: OK ------------------------------------------------------ Test: TestIntegerUpTo -i -e TestIntegerUpTo: OK ------------------------------------------------------ Test: TestIntegerUpTo -e TestIntegerUpTo: OK ------------------------------------------------------ Test: TestJustAnInteger -i -e TestJustAnInteger: OK ------------------------------------------------------ Test: TestJustAnInteger -e TestJustAnInteger: OK ------------------------------------------------------ Test: TestKVC -i Segmentation fault -e TestKVC: FAIL (crash) ------------------------------------------------------ Test: TestKVC -e TestKVC: OK ------------------------------------------------------ Test: TestMutRecursiveClassDefs -i Segmentation fault -e TestMutRecursiveClassDefs: FAIL (crash) ------------------------------------------------------ Test: TestMutRecursiveClassDefs -e TestMutRecursiveClassDefs: OK ------------------------------------------------------ Test: TestNSPointBoxing -i Segmentation fault -e TestNSPointBoxing: FAIL (crash) ------------------------------------------------------ Test: TestNSPointBoxing -e TestNSPointBoxing: OK ------------------------------------------------------ Test: TestNSRangeBoxing -i -e TestNSRangeBoxing: OK ------------------------------------------------------ Test: TestNSRangeBoxing -e TestNSRangeBoxing: OK ------------------------------------------------------ Test: TestNSRectBoxing -i -e TestNSRectBoxing: OK ------------------------------------------------------ Test: TestNSRectBoxing -e TestNSRectBoxing: OK ------------------------------------------------------ Test: TestNSSizeBoxing -i Segmentation fault -e TestNSSizeBoxing: FAIL (crash) ------------------------------------------------------ Test: TestNSSizeBoxing -e TestNSSizeBoxing: OK ------------------------------------------------------ Test: TestNestedBlocks -i -e TestNestedBlocks: OK ------------------------------------------------------ Test: TestNestedBlocks -e TestNestedBlocks: OK ------------------------------------------------------ Test: TestNonLocalReturn -i -e TestNonLocalReturn: OK ------------------------------------------------------ Test: TestNonLocalReturn -e TestNonLocalReturn: OK ------------------------------------------------------ Test: TestNonLocalReturn2 -i -e TestNonLocalReturn2: OK ------------------------------------------------------ Test: TestNonLocalReturn2 -e TestNonLocalReturn2: OK ------------------------------------------------------ Test: TestOperatorDefinition -i Segmentation fault -e TestOperatorDefinition: FAIL (crash) ------------------------------------------------------ Test: TestOperatorDefinition -e TestOperatorDefinition: OK ------------------------------------------------------ Test: TestPolymorphicSelectors -i -e TestPolymorphicSelectors: OK ------------------------------------------------------ Test: TestPolymorphicSelectors -e TestPolymorphicSelectors: OK ------------------------------------------------------ Test: TestRetainOnlyOnce -i -e TestRetainOnlyOnce: FAIL (crash) ------------------------------------------------------ Test: TestRetainOnlyOnce -e TestRetainOnlyOnce: FAIL (crash) ------------------------------------------------------ Test: TestScopes -i Segmentation fault -e TestScopes: FAIL (crash) ------------------------------------------------------ Test: TestScopes -e TestScopes: OK ------------------------------------------------------ Test: TestSimpleSelect -i -e TestSimpleSelect: OK ------------------------------------------------------ Test: TestSimpleSelect -e TestSimpleSelect: OK ------------------------------------------------------ Test: TestTranscript -i -e TestTranscript: OK ------------------------------------------------------ Test: TestTranscript -e TestTranscript: OK ------------------------------------------------------ Test: TestYourself -i -e TestYourself: OK ------------------------------------------------------ Test: TestYourself -e TestYourself: OK
Looks the same on my environment.
Cheers, Quentin.

_______________________________________________ Etoile-dev mailing list Etoile-dev <at> gna.org https://mail.gna.org/listinfo/etoile-dev
Regards,
Uli P.
-- Ulrich Pöhlmann Karlstraße 25 88045 Friedrichshafen Mobil: +49 176 20940291 
_______________________________________________
Etoile-dev mailing list
Etoile-dev <at> gna.org
https://mail.gna.org/listinfo/etoile-dev
Permalink | Reply |
headers
Quentin Mathé | 8 Nov 2011 12:12
Picon

Re: Clang 3.0 rc 1 and LanguageKit Status

Le 7 nov. 2011 à 21:47, Ulrich Pöhlmann a écrit :

> On 11/07/2011 01:04 PM, Quentin Mathé wrote:
>> Hi,
>> 
>> To compile LanguageKit, I had to work around the glibc __block issue in various places once again. 
>> The patch is pretty ugly, so before committing it I wanted to know if someone had a better solution.
>> 
> Isn't that patch already included in etoile trunk? After running "make install" I got the patch
automatically installed under "/Local/Library/Headers/EtoileFoundation/glibc_hack_unistd.h".

No, this is a old hack that doesn't use the 'include_next' trick and requires that you replace every
#include <unistd.h> by #include "glibc_hack_unistd.h". 
Moreover it won't work here because the #include directives we want to override are in the LLVM code rather
than in the LanguageKit code.

I'll remove it to use the new hack suggested by David.

Cheers,
Quentin.
Permalink | Reply |
headers
David Chisnall | 8 Nov 2011 12:57

Re: Clang 3.0 rc 1 and LanguageKit Status

Of course, the real fix is to get your buggy libc headers fixed.  Since Drepper refuses to fix his code, maybe
try sending a patch to Debian / Ubuntu and get them to include it in their version...

David

On 8 Nov 2011, at 11:12, Quentin Mathé wrote:

> Le 7 nov. 2011 à 21:47, Ulrich Pöhlmann a écrit :
> 
>> On 11/07/2011 01:04 PM, Quentin Mathé wrote:
>>> Hi,
>>> 
>>> To compile LanguageKit, I had to work around the glibc __block issue in various places once again. 
>>> The patch is pretty ugly, so before committing it I wanted to know if someone had a better solution.
>>> 
>> Isn't that patch already included in etoile trunk? After running "make install" I got the patch
automatically installed under "/Local/Library/Headers/EtoileFoundation/glibc_hack_unistd.h".
> 
> No, this is a old hack that doesn't use the 'include_next' trick and requires that you replace every
#include <unistd.h> by #include "glibc_hack_unistd.h". 
> Moreover it won't work here because the #include directives we want to override are in the LLVM code rather
than in the LanguageKit code.
> 
> I'll remove it to use the new hack suggested by David.
> 
> Cheers,
> Quentin.
> _______________________________________________
> Etoile-dev mailing list
> Etoile-dev <at> gna.org
> https://mail.gna.org/listinfo/etoile-dev

-- Sent from my STANTEC-ZEBRA
Permalink | Reply |
headers
Ulrich Pöhlmann | 8 Nov 2011 21:03
Picon

Re: Clang 3.0 rc 1 and LanguageKit Status

Am 08.11.11 12:57, schrieb David Chisnall:
> Of course, the real fix is to get your buggy libc headers fixed.  Since Drepper refuses to fix his code, maybe
try sending a patch to Debian / Ubuntu and get them to include it in their version...
>
> David
>
> On 8 Nov 2011, at 11:12, Quentin Mathé wrote:
>
>> Le 7 nov. 2011 à 21:47, Ulrich Pöhlmann a écrit :
>>
>>> On 11/07/2011 01:04 PM, Quentin Mathé wrote:
>>>> Hi,
>>>>
>>>> To compile LanguageKit, I had to work around the glibc __block issue in various places once again.
>>>> The patch is pretty ugly, so before committing it I wanted to know if someone had a better solution.
>>>>
>>> Isn't that patch already included in etoile trunk? After running "make install" I got the patch
automatically installed under "/Local/Library/Headers/EtoileFoundation/glibc_hack_unistd.h".
>> No, this is a old hack that doesn't use the 'include_next' trick and requires that you replace every
#include<unistd.h>  by #include "glibc_hack_unistd.h".
>> Moreover it won't work here because the #include directives we want to override are in the LLVM code
rather than in the LanguageKit code.
>>
>> I'll remove it to use the new hack suggested by David.
>>
>> Cheers,
>> Quentin.
>> _______________________________________________
>> Etoile-dev mailing list
>> Etoile-dev <at> gna.org
>> https://mail.gna.org/listinfo/etoile-dev
>
> -- Sent from my STANTEC-ZEBRA
>
>
> _______________________________________________
> Etoile-dev mailing list
> Etoile-dev <at> gna.org
> https://mail.gna.org/listinfo/etoile-dev
Thanks a lot for the explanations.

Regards,
Uli P.
Permalink | Reply |

Gmane