> Complete tested diffs have a much better chance of getting accepted.
> Yes it takes a while but it will for anyone else who might look at it
> and you actually have the machine to test it on. It's only going to be
> a bit slower on your machine than the sort of macppc which most
> developers have access to...
I don't like submitting patches that I haven't tested, but here I did it
because I thought the issue was exactly the same as the one with
SSE2 (it seems to be a crash in the lexer as well), and it's hard for me
to build such a big package on this box (see below). But if the SSE2
patch isn't fixing anything after all, then I guess the issue is
somewhere else, yes...
And I thought the official packages were built on a G5 and that it
would've been faster (and easier) to build a package that I could
have tested to see if it really fixes the crash.
> Donovan,
> Stuart had this same discussion with me and jsing@ in mid-April where
> he showed this nifty thing to check for SSE (I hope Stuart doesn't
> mind posting useful contents of a private email here. It is harmless.)
>
> $ arch -s; cpp -dM /dev/null | grep SSE
>
> which doesn't have any output on i386, but does on amd64. Please do
> the same for __ALTIVEC, and post the result so Stuart or other
> knowledgeable people can give you correct feedback.
This indeed only outputs "powerpc". Nothing about ALTIVEC.
Actually, I thought we were undef'ing a macro which was previously
defined by clang/llvm. I didn't realize it was a system macro, sorry.
Then I guess the bug is elsewhere... which is weird, because I think
clang has been tested on powerpc and that it can compile the
trivial examples I've posted earlier without crashing, right?
Could anyone with an Altivec-capable macppc test that? (well, I
know you must be busy at the moment with the 5.0 release, so
probably later).
> On macppc on a G4 mac mini, it's defined if you use -maltivec, and not
> defined if you don't.
Hmm... then I think I'm starting to understand something:
See clang-2.9/lib/Lex/Makefile:
ifeq ($(ARCH),PowerPC)
CXX.Flags += -maltivec
endif
So: the packages are built on an Altivec-capable macppc box, this
makefile makes the mistake of always enabling -maltivec, hence
__ALTIVEC__ is defined in Lexer.cpp, and I get this crash on my
non-Altivec-capable box. Am I right? :)
So, the patch for SEE2 would be correct as well, wouldn't it?
(As for building this myself: I've already tried it, but B&W G3 have
an old issue of timeouts... under certain circumstances, I get
"bm0: device timeout", and if I unpack a big tarball, I get wd0
timeouts as well. Looking at the archives, it seems to be an old
bug for B&W G3; I don't have this kind of problems when
running Slackintosh. This makes building big packages under
OpenBSD almost impossible, I'm afraid.)
2011/8/3, Donovan Watteau <tso...@gmail.com>:
> Sorry to bump this again, but I think it deserves to make the release
> since the bug is important and the fix is easy (a similar one is already
> used to avoid using SSE2)...
>
>> I think this deserves a bump...
>>
>>> Hi,
>>>
>>> It seems clang is almost unusuable on old macppc boxes such as my G3
>>> B&W, which doesn't have Altivec support.
>>>
>>> This compiles OK:
>>> int main() { return 0; }
>>>
>>> but this crashes:
>>> /* Same thing, but with a comment. */
>>> int main() { return 0; }
>>>
>>> with the following error:
>>> Stack dump:
>>> 0. Program arguments:
>>> /usr/local/bin/clang -cc1 -triple powerpc-unknown-openbsd4.9 -S
>>> -disable-free -disable-llvm-verifier -main-file-name test2.c
>>> -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
>>> -target-linker-version 2.15 -momit-leaf-frame-pointer -resource-dir
>>> /usr/local/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 0
>>> -fno-signed-char -fgnu-runtime -fdiagnostics-show-option -o
>>> /tmp/cc-hLpenZ.s -x c test2.c
>>> 1. <unknown> parser at unknown
>>> location clang: error: unable to execute command: Illegal instruction
>>> (core dumped) clang: error: clang frontend command failed due to
>>> signal 1 (use -v to see invocation)
>>>
>>> I see there this a patch in the port [1] which undef's __SSE2__ so I
>>> guess the same thing should be done for __ALTIVEC__. Unfortunately,
>>> it wasn't possible for me to test the patch, since it would take forever
>>> to compile on such an old box. But I guess the issue is here.
>>>
>>> I'd gladly test any new package built with this patch on my G3, if it
>>> helps.
>>>
>>> Tsomi.
>>>
>>> [1] patch-tools_clang_lib_Lex_Lexer_cpp
>>>
>>> Index: devel/llvm/patches/patch-tools_clang_lib_Lex_Lexer_cpp
>>> ===================================================================
>>> RCS file:
>>> /cvs/ports/devel/llvm/patches/patch-tools_clang_lib_Lex_Lexer_cpp,v
>>> retrieving revision 1.6
>>> diff -u -p -r1.6 patch-tools_clang_lib_Lex_Lexer_cpp
>>> --- devel/llvm/patches/patch-tools_clang_lib_Lex_Lexer_cpp 13 Jan 2011
>>> 00:15:50 -0000 1.6
>>> +++ devel/llvm/patches/patch-tools_clang_lib_Lex_Lexer_cpp 26 Jun 2011
>>> 12:41:36 -0000
>>> @@ -1,10 +1,11 @@
>>> $OpenBSD: patch-tools_clang_lib_Lex_Lexer_cpp,v 1.6 2011/01/13 00:15:50
>>> jeremy Exp $
>>> ---- tools/clang/lib/Lex/Lexer.cpp.orig Tue Aug 31 09:42:00 2010
>>> -+++ tools/clang/lib/Lex/Lexer.cpp Thu Jan 6 11:26:07 2011
>>> -@@ -1334,6 +1334,7 @@ static bool
>>> isEndOfBlockCommentWithEscapedNewLine(cons
>>> +--- tools/clang/lib/Lex/Lexer.cpp.orig Mon Feb 28 03:37:51 2011
>>> ++++ tools/clang/lib/Lex/Lexer.cpp Sun Jun 26 14:39:38 2011
>>> +@@ -1516,6 +1516,8 @@ static bool
>>> isEndOfBlockCommentWithEscapedNewLine(cons
>>> return true;
>>> }
>>>
>>> ++#undef __ALTIVEC__
>>> +#undef __SSE2__
>>> #ifdef __SSE2__
>>> #include <emmintrin.h>
>>>
>>
>
