search for: darwin14

...rom the > builders link on the main page. > > Never passed at all: > libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 > libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan > libcxx-libcxxabi-x86_64-linux-ubuntu-tsan > libcxx-libcxxabi-x86_64-linux-ubuntu-gcc > libcxx-libcxxabi-x86_64-apple-darwin14-system-lib > lldb-x86_64-ubuntu-14.04-android > llgo-x86_64-linux > > Not pass in at least a month: > > llvm-clang-lld-x86_64-debian-fast > clang-native-mingw32-win7 > clang-x86_64-linux-selfhost-abi-test > clang-x64-ninja-win7-debug > perf-x86_64-penryn-O3-polly-detec...

...t; howarth.mailing.lists at gmail.com> wrote: > On a positive note, current llvm 3.7svn with the two outstanding > OPENMP patches applied builds the openmp support in gromacs 5.0.4 and the > resulting build fully passes the gromacs regression test suite. Tested on > x86_64-apple-darwin14. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150503/b6dd7bb8/attachment.html>

On Tue, May 19, 2015 at 10:40 AM, James Y Knight <jyknight at google.com> wrote: > Yes, I also find the amount of bot spam in #llvm is basically intolerable. > It makes it difficult to see actual people talking. At first, I just put > all the bots on /ignore. Now I have an xchat script to move the botspam to > another tab (tabify-004.pl). I'd recommend that the bots should

On Thu, Apr 30, 2015 at 10:23 AM, Jack Howarth < howarth.mailing.lists at gmail.com> wrote: > The current test suite status on x86_64-apple-darwin14, with the > proposed patch from > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150427/128219.html > applied to current cfe trunk, is quite respectable.... > > Summary: > S Number of tested Open MP constructs: 62 > S Number of used tests: 123 >...

Jack, Could you, please, submit a bug report? -- including steps to reproduce (where you got imageMagick sources, how exactly you compiled them, etc) Andrey On Fri, May 1, 2015 at 3:56 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > > > On Fri, May 1, 2015 at 4:45 AM, Andrey Bokhanko <andreybokhanko at gmail.com> > wrote: >> >> Chandler,

All, I'd like to resurrect the discussion on replacing libgomp with libiomp as the default OpenMP runtime library linked with -fopenmp. For reference, the previous discussion is accessible there: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/thread.html#99461 We are very close to getting *full* OpenMP 3.1 specification supported in clang (only one (!) clause is not

Chandler, Thanks for the reply -- I always included you in libiomp supporters camp; it is good to see I wasn't mistaken! ;-) On Fri, May 1, 2015 at 12:51 AM, Chandler Carruth <chandlerc at google.com> wrote: > Is there no way to support libgomp here as well? I don't say this to hold > up changing the defaults in any way, just curious. =] > No, sorry. libgomp doesn't

...rs. Do you really want to release 3.6 with this level of performance regression? Jack On Fri, Feb 13, 2015 at 2:47 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > Also confirmed with the llvm 3.5.1 release and the llvm 3.6 release > branch on x86_64-apple-darwin14... > > % clang-3.5 -O3 -mssse3 -fomit-frame-pointer -fno-stack-protector > -fno-exceptions -o 8 8.c > % time ./8 9 > 352 solutions > 3.603u 0.002s 0:03.60 100.0% 0+0k 0+0io 2pf+0w > % time ./8 10 > 724 solutions > 104.217u 0.059s 1:44.30 99.9% 0+0k 0+0io 2pf+0w > >...

...level of performance regression? >> Jack >> >> On Fri, Feb 13, 2015 at 2:47 PM, Jack Howarth >> <howarth.mailing.lists at gmail.com> wrote: >>> Also confirmed with the llvm 3.5.1 release and the llvm 3.6 release >>> branch on x86_64-apple-darwin14... >>> >>> % clang-3.5 -O3 -mssse3 -fomit-frame-pointer -fno-stack-protector >>> -fno-exceptions -o 8 8.c >>> % time ./8 9 >>> 352 solutions >>> 3.603u 0.002s 0:03.60 100.0% 0+0k 0+0io 2pf+0w >>> % time ./8 10 >>> 724 solutions...

I submitted the problem report to clang's bugzilla but no one seems to care so I have to send it to the mailing list. clang 3.7 svn (trunk 229055 as the time I was to report this problem) generates slower code than 3.5 (Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)) for the following code. It is a "8 queens puzzle" solver written as an educational example. As