search for: investiag

...?) ------------- My concern/thoughts - When we swap out STDCXX for libc++ - We aren't able to self host clang. This could be entirely *our* fault, but it hasn't been investigated extensively. (We also see Perennial C++ testsuite regressions which appear to come from libc++, but also not investiaged/confirmed) Having a sunrise period would allow us to investigate this as well as report any potentially blocking problems. Having a gnu-free self hosting[1] policy attached to this would also be great - that makes a potentially easier backup solution to anyone on [linux] with older gnu compil...

...ing to address. Certainly, the platforms with only libc++ are self hosting clang successfully today. > This could be entirely *our* fault, but it hasn't been investigated > extensively. (We also see Perennial C++ testsuite regressions which appear > to come from libc++, but also not investiaged/confirmed) Having a sunrise > period would allow us to investigate this as well as report any potentially > blocking problems. > > Having a gnu-free self hosting[1] policy attached to this would also be > great - that makes a potentially easier backup solution to anyone on > [li...

Greetings, I'm working on some analyses where I need to calculate wilcox tests for paired samples. In my current literature search I've found a few papers on sample size determination for the wilcox test notably: Sample Size Determination for Some Common Nonparametric Tests Gottfried E. Noether Journal of the American Statistical Association

Focusing on one comment: On Mon, Oct 28, 2013 at 3:12 PM, Brooks Davis <brooks at freebsd.org> wrote: > Today you could probably pick a somewhat newer > Clang than 3.1 without much real impact on us, but it would hurt to have > the requirements change with every release. From our perspective it's > much better to change no more than every two years or so. > I think

...> My concern/thoughts - When we swap out STDCXX for libc++ - We aren't able > to self host clang. This could be entirely *our* fault, but it hasn't been > investigated extensively. (We also see Perennial C++ testsuite regressions > which appear to come from libc++, but also not investiaged/confirmed) > Having a sunrise period would allow us to investigate this as well as > report any potentially blocking problems. > [As an aside: I use libc++ for my Clang development (on Ubuntu Linux), and it works for me (tm). This is with libstdc++ providing the ABI pieces, rather than...

...eaning them out after every day and likewise one that takes a commit every hour. This means that if I suddenly see a weird behaviour change in something I'm working on I can step back through revisions until I find one which compiles and has the old behaviour, then diff the two to find stuff to investiage rather than have to think "what did I change recently". Likewise I'm into the habit of creating throwaway merge branches with mainline when doing development in order to check if there's conflicts. And it provides a nice way to synchronise "personal" development between...

On Mon, Oct 28, 2013 at 02:31:10PM -0700, Chris Lattner wrote: > > On Oct 28, 2013, at 2:19 PM, Chandler Carruth <chandlerc at google.com> wrote: > > > One thing I want to call out: > > > > On Mon, Oct 28, 2013 at 8:20 AM, Chris Lattner <clattner at apple.com> wrote: > > I suppose what I'm saying is that we are currently not using *any*

...rms with only libc++ are self hosting clang > successfully today. Hmm.... > > This could be entirely *our* fault, but it hasn't been > investigated extensively. (We also see Perennial C++ testsuite > regressions which appear to come from libc++, but also not > investiaged/confirmed) Having a sunrise period would allow us to > investigate this as well as report any potentially blocking problems. > > Having a gnu-free self hosting[1] policy attached to this would > also be great - that makes a potentially easier backup solution to > an...

The thing about this is that git-svn (un?)fortunately works so well that you can get all of these benefits with the main repo still in SVN. Hence, it is really a moot point regarding a switch to git for the main repo. E.g.: > Actually that's true today with svn. We have a ton of changes here we'd > like to submit but the process is really painful. Is there any difference from the

..., but gcc is not smart enough to optimize this out when optimizations ARE enabled. - It appears clang requires us to do this always (which is fair, since - technically the compiler is always allowed to do the dereference before - invoking the function implementing the intrinsic). I have not investiaged - whether it is any smarter than gcc when it comes to eliminating the extra - load instruction.*/ + Clang, in contrast, requires us to do this always for _mm_cvtepi8_epi32 + (which is fair, since technically the compiler is always allowed to do the + dereference before invoking the function...

..., but gcc is not smart enough to optimize this out when optimizations ARE enabled. - It appears clang requires us to do this always (which is fair, since - technically the compiler is always allowed to do the dereference before - invoking the function implementing the intrinsic). I have not investiaged - whether it is any smarter than gcc when it comes to eliminating the extra - load instruction.*/ + Clang, in contrast, requires us to do this always for _mm_cvtepi8_epi32 + (which is fair, since technically the compiler is always allowed to do the + dereference before invoking the function...

The attached patch cleans up Opus's x86 intrinsics configury. It: * Makes ?enable-intrinsics work with clang and other non-GCC compilers * Enables RTCD for the floating-point-mode SSE code in Celt. * Disables use of RTCD in cases where the compiler targets an instruction set by default. * Enables the SSE4.1 Silk optimizations that apply to the common parts of Silk when Opus is built in

Hi All, Since I continue to base my work on top of Jonathan's patch, and my previous Ne10 fft/ifft/mdct_forward/backward patches, I thought it would be better to just post all new patches as a patch series. Please let me know if anyone disagrees with this approach. You can see wip branch of all latest patches at https://git.linaro.org/people/viswanath.puttagunta/opus.git Branch:

Hi Timothy, As I mentioned earlier [1], I now fixed compile issues with fixed point and resubmitting the patch. I also have new patch that does intrinsics optimizations for celt_pitch_xcorr targetting aarch64. You can find my latest work-in-progress branch at [2] For reference, you can use the Ne10 pre-built libraries at [3] Note that I am working with Phil at ARM to get my patch at [4]

Hi All, As per Timothy's suggestion, disabling mdct_forward for fixed point. Only effects armv7,armv8: Extend fixed fft NE10 optimizations to mdct Rest of patches are same as in [1] For reference, latest wip code for opus is at [2] Still working with NE10 team at ARM to get corner cases of mdct_forward. Will update with another patch when issue in NE10 gets fixed. Regards, Vish [1]:

Hi All, Changes from RFC v2 [1] armv7,armv8: Extend fixed fft NE10 optimizations to mdct - Overflow issue fixed by Phil at ARM. Ne10 wip at [2]. Should be upstream soon. - So, re-enabled using fixed fft for mdct_forward which was disabled in RFCv2 armv7,armv8: Optimize fixed point fft using NE10 library - Thanks to Jonathan Lennox, fixed some build fixes on iOS and some copy-paste errors Rest

Hello Timothy / Jean-Marc / opus-dev, This patch series is follow up on work I posted on [1]. In addition to what was posted on [1], this patch series mainly integrates Fixed point FFT implementations in NE10 library into opus. You can view my opus wip code at [2]. Note that while I found some issues both with the NE10 library(fixed fft) and with Linaro toolchain (armv8 intrinsics), the work