similar to: [LLVMdev] 254.gap SPEC2000

Are there any results for the SPEC2000 benchmarks using llvm with and without LTO? It would be interesting to know how the current LTO in llvm compares to the results being seen in current gcc trunk with their LTO... http://gcc.gnu.org/ml/gcc/2009-10/msg00155.html It would appear that the gcc LTO implementation is finally showing results (although with a lot of wrong code results). I assume we

On 2009-12-23 08:22, Li Shengmei wrote: > > Hi, all > > I use llvm-gcc –O4 to compile SPEC 2000, some benchmarks > can’t be built successfully, such as 164.gzip, 175.vpr etc. > > The error messages are as follows. > > > > …… > > zh.o unlzw.o unpack.o unzip.o util.o zip.o -o gzip > > bits.o: file not recognized: File format not recognized

Hi, all I use llvm-gcc -O4 to compile SPEC 2000, some benchmarks can't be built successfully, such as 164.gzip, 175.vpr etc. The error messages are as follows. .. zh.o unlzw.o unpack.o unzip.o util.o zip.o -o gzip bits.o: file not recognized: File format not recognized collect2: ld returned 1 exit status specmake: *** [gzip] Error 1 specmake options 2> options.err |

Hi, In my experiments, I need to disable several linking optimizations. However, bzip2, vortex and eon failed if "-disable-opt" was passed to gccld. I tried the out-of-box llvm and the building process provided by llvm-test. The same problem was observed, when I specified EXTRA_LINKTIME_OPT_FLAGS = -disable-opt on Makefile.program and simplied typed "make" under

Hi Drew, Thakns for the patch. Here's some comments for now (not done reviewing): 1) You want to use isqrt32() rather than celt_sqrt(), since celt_sqrt() changes behaviour for fixed-point and provides no guarantee about rounding. 2) About these two lines: + if (nondiegetic_channels && 2 != nondiegetic_channels) + return OPUS_UNIMPLEMENTED; Why not just have the

On 25/04/17 10:12 AM, Drew Allen wrote: > We assume that the input file is ordered first by ACN ambisonic channels > followed by a (possible) stereo track, and we want to swap the order for > the API in order to couple the stereo for coding. Well, if you look at section 5.1.1 of RFC7845: The 'coupled stream count' field indicates that the decoders for the first M

Oops, looks like we both should have been more careful. The patch had some extra lines that shouldn't have been there. Jean-Marc On 28/04/17 12:59 PM, Drew Allen wrote: > My apologies for the confusion, I think I have the mapping layout > correct in this patch. > > Cheers! > > > > On Tue, Apr 25, 2017 at 10:07 AM Jean-Marc Valin <jmvalin at jmvalin.ca >

On 28/04/17 07:54 PM, Drew Allen wrote: > sorry about that... extra lines... was it whitespace? If so, sorry about > that. No, that was worse than that. It broke all the builds. See the fix: https://git.xiph.org/?p=opus.git;a=commitdiff;h=a31e9fd24cd Jean-Marc

http://bugzilla.mindrot.org/show_bug.cgi?id=254 Summary: Problems building. Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dsusman at

http://bugzilla.mindrot.org/show_bug.cgi?id=254 ------- Additional Comments From dtucker at zip.com.au 2002-06-12 23:25 ------- What C compiler are you using? There's a bug in some versions of gcc that causes it to pick up -L link paths last, so it might be picking up libcrypto from /usr/lib and the headers from /usr/local/ssl/include. See:

Hi Drew, I think your revised patch looks good overall. Just two comments: 1) In opus_multistream_encoder_init_impl(), rather than use a huge condition with two ORs for the return OPUS_BAD_ARG, maybe you can just multiple three separate if()s, each with its own condition (one of which will be entirely in an #ifdef). That should make the code easier to read. 2) In

Hey Jean-Marc, sorry about that... extra lines... was it whitespace? If so, sorry about that. Thanks! Cheers, Drew Cheers, Drew On Fri, Apr 28, 2017 at 2:43 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Oops, looks like we both should have been more careful. The patch had > some extra lines that shouldn't have been there. > > Jean-Marc > > On

Hello all, Attached is a proposed patch for Opus that allows support for encoding non-diegetic stereo audio as a coupled stream for use with channel mapping 254. It also rejects channel counts that are not (n+1)^2 + 2j, where n is 0 to 14 and j is either 0 or 1 (See IETF public draft doc attached for clarification). Please let me know any suggestions / concerns / comments. Thank you for your

I have a large computation that performs various bootstrap resampling loops over pairs of samples using lapply(). After a few seconds it stops like this > do.summarize.effects(compute.power=T) ... Error: Unimplemented feature in rep > .Traceback [[1]] [1] "rep(no, length = length(ans))" [[2]] [1] "ifelse(t.howto == \"n\", boot.result, l.meanboot.test(onew.x,

My apologies for the confusion, I think I have the mapping layout correct in this patch. Cheers! On Tue, Apr 25, 2017 at 10:07 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > On 25/04/17 10:12 AM, Drew Allen wrote: > > We assume that the input file is ordered first by ACN ambisonic channels > > followed by a (possible) stereo track, and we want to swap the order for

Hi Jean-Marc, Thanks again for your comments. Attached is a revised patch. On Mon, Apr 24, 2017 at 1:08 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Drew, > > I think your revised patch looks good overall. Just two comments: > > 1) In opus_multistream_encoder_init_impl(), rather than use a huge > condition with two ORs for the return OPUS_BAD_ARG, maybe you can

Hi Jean-Marc et all, Thanks for the quick feedback, responses to your questions are below: I've attached a revised patch. PTAL, thanks! On Fri, Apr 7, 2017 at 1:22 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: Hi Drew, Thakns for the patch. Here's some comments for now (not done reviewing): 1) You want to use isqrt32() rather than celt_sqrt(), since celt_sqrt() changes