search for: enable_assertions

...g. It took some time for me to figure out why some of our builds behaved differently than others. Is this an intentional design choice? If so, what's the rationale? If not, would it make sense to add a CMake option to specify whether textual IR preserves names or not rather than overloading ENABLE_ASSERTIONS? -David

...larly fix user bugs depend on that > information, we should keep it a debug build by default. Otherwise, I think > an optimized build would be fine. Another option is to build an optimized build with assertions on. Do to local demand, I added a build option 'make ENABLE_OPTIMIZED=1 ENABLE_ASSERTIONS=1' that provides this. -Chris -- http://nondot.org/sabre/ http://llvm.org/

On Mon, 27 Mar 2006, Andrew Lenharth wrote: >> Another option is to build an optimized build with assertions on. Do to >> local demand, I added a build option 'make ENABLE_OPTIMIZED=1 >> ENABLE_ASSERTIONS=1' that provides this. > > How does this compare size and performance wise with a debug build or a > release build? I haven't done any scientific measurements. Here is some educated guessing :) I know that a debug build is about 10x bigger and 10x slower than a release build....

...that > > information, we should keep it a debug build by default. Otherwise, I think > > an optimized build would be fine. > > Another option is to build an optimized build with assertions on. Do to > local demand, I added a build option 'make ENABLE_OPTIMIZED=1 > ENABLE_ASSERTIONS=1' that provides this. How does this compare size and performance wise with a debug build or a release build? Andrew

FWIW, I was able to use the EarlyCSE debug counters without issue in a Release build with -DLLVM_ENABLE_ASSERTIONS=Yes. Further, the only preprocessor checks I see around debug counters use `NDEBUG`. Am I missing something? It seems reasonable to me to require that assertions are on when you're trying to debug the compiler. Not so much to require that the compiler itself has been built with `-O0` :) On We...

...Eric On Mar 27, 2006, at 9:09 PM, Chris Lattner wrote: > On Mon, 27 Mar 2006, Andrew Lenharth wrote: >>> Another option is to build an optimized build with assertions >>> on. Do to >>> local demand, I added a build option 'make ENABLE_OPTIMIZED=1 >>> ENABLE_ASSERTIONS=1' that provides this. >> >> How does this compare size and performance wise with a debug build >> or a >> release build? > > I haven't done any scientific measurements. Here is some educated > guessing :) > > I know that a debug build is about 10...

...c +libopusfile_la_LIBADD = $(DEPS_LIBS) + +EXTRA_PROGRAMS = examples/opusfile_example examples/seeking_example + +examples_opusfile_example_LDADD = libopusfile.la +examples_seeking_example_LDADD = libopusfile.la + +example: $(EXTRA_PROGRAMS) + +debug: + $(MAKE) CFLAGS="${CFLAGS} -O0 -ggdb -DOP_ENABLE_ASSERTIONS" all example diff --git a/autogen.sh b/autogen.sh new file mode 100755 index 0000000..e31a822 --- /dev/null +++ b/autogen.sh @@ -0,0 +1,3 @@ +#!/bin/sh + +autoreconf -is diff --git a/configure.ac b/configure.ac new file mode 100644 index 0000000..3f4e6f4 --- /dev/null +++ b/configure.ac @@ -0,...

...c +libopusfile_la_LIBADD = $(DEPS_LIBS) + +EXTRA_PROGRAMS = examples/opusfile_example examples/seeking_example + +examples_opusfile_example_LDADD = libopusfile.la +examples_seeking_example_LDADD = libopusfile.la + +example: $(EXTRA_PROGRAMS) + +debug: + $(MAKE) CFLAGS="${CFLAGS} -O0 -ggdb -DOP_ENABLE_ASSERTIONS" all example diff --git a/configure.ac b/configure.ac new file mode 100644 index 0000000..3f4e6f4 --- /dev/null +++ b/configure.ac @@ -0,0 +1,66 @@ +AC_INIT([libopusfile], [0.0]) + +AC_USE_SYSTEM_EXTENSIONS +AC_SYS_LARGEFILE + +AM_INIT_AUTOMAKE([1.11 foreign dist-bzip2 no-dist-gzip]) +LT_INIT...

...; On Mar 27, 2006, at 9:09 PM, Chris Lattner wrote: > >> On Mon, 27 Mar 2006, Andrew Lenharth wrote: >>>> Another option is to build an optimized build with assertions on. Do to >>>> local demand, I added a build option 'make ENABLE_OPTIMIZED=1 >>>> ENABLE_ASSERTIONS=1' that provides this. >>> >>> How does this compare size and performance wise with a debug build or a >>> release build? >> >> I haven't done any scientific measurements. Here is some educated guessing >> :) >> >> I know that a...

...fined \ + -version-info @OP_LT_CURRENT@:@OP_LT_REVISION@:@OP_LT_AGE@ + +noinst_PROGRAMS = examples/opusfile_example examples/seeking_example + +examples_opusfile_example_LDADD = libopusfile.la +examples_seeking_example_LDADD = libopusfile.la + +debug: + $(MAKE) CFLAGS="${CFLAGS} -O0 -ggdb -DOP_ENABLE_ASSERTIONS" all example + +#API Documentation + +if HAVE_DOXYGEN + +EXTRA_DIST = doc/Doxyfile.in + +all-local: doc/doxygen-build.stamp + +doc/doxygen-build.stamp: doc/Doxyfile $(top_srcdir)/include/*.h + cd doc && doxygen + touch "$@" + +install-data-local: + cd doc && for f in...

Reid Spencer wrote: > Developers: > > Please visit PR723 http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=723, > read it and cast your vote on whether release 1.7 should default the > configure script to building optimized or whether the status quo (debug > build) should be kept. It is likely that we now have more active users > than active developers and we should respond to

...me of our builds behaved differently than others. > > > > Is this an intentional design choice? If so, what's the rationale? If > > not, would it make sense to add a CMake option to specify whether > > textual IR preserves names or not rather than overloading > > ENABLE_ASSERTIONS? > > > > You can use `opt -instnamer`. > > -- > Davide > > "There are no solved problems; there are only problems that are more > or less solved" -- Henri Poincare > _______________________________________________ > LLVM Developers mailing list > llv...

Developers: Please visit PR723 http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=723, read it and cast your vote on whether release 1.7 should default the configure script to building optimized or whether the status quo (debug build) should be kept. It is likely that we now have more active users than active developers and we should respond to that change of circumstances with the default build

The opus code default compiles on -o2 optimization level. I would like to change it to -o3. I have tried doing the changes in makefile.unix . The change is not getting reflected. I am building the code in Code composer studio for TI processor C6000. Could anybody help me with this -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, all Those days, we spent some efforts to check severe error handling (panic, BUG_ON, BUG, ASSERT) in XEN. We have several round internal discussions as well as several mail threads with Keir. Below is the discussion writeup. If agreed, after review, we want to place it in XEN document folder or XEN wiki since we think it might be helpful to developers. Thanks a lot for your help! Regards,

...this isn't your case, could you send me the actual commands you ran? > > In the meantime, you can add -DLLVM_FOURCE_ENABLE_DUMP=ON to your cmake > invocation which should guarantee LLVM_ENABLE_DUMP is defined. > > hth... > don > > Don, Did you try a build with -DLLVM_ENABLE_ASSERTIONS:BOOL=OFF -DCMAKE_BUILD_TYPE:STRING=Release? Jack On Sat, Oct 14, 2017 at 9:36 AM, Jack Howarth <howarth.mailing.lists at gmail. > com> wrote: > >> >> >> On Sat, Oct 14, 2017 at 11:38 AM, Don Hinton <hintonda at gmail.com> wrote: >> >>> Sor...

This patch to opus-tools adds optional support to WavPack lossless format as input to opusenc. Like support to FLAC, it depends on an external library, libwavpack, and may be disabled on configure. Lucas Clemente Vella (1): Reading input from WavPack files. Makefile.am | 7 +- configure.ac | 37 ++++++++ src/audio-in.c | 71 ++++++++------- src/opusenc.c | 19 +++- src/opusenc.h

...m_optimization} - Intrinsics Optimizations.......: ${enable_intrinsics} + Intrinsics Optimizations.......: ${intrinsics_support} Run-time CPU detection: ........ ${rtcd_support} Custom modes: .................. ${enable_custom_modes} Assertion checking: ............ ${enable_assertions} diff --git a/m4/opus-intrinsics.m4 b/m4/opus-intrinsics.m4 new file mode 100644 index 0000000..c74aecd --- /dev/null +++ b/m4/opus-intrinsics.m4 @@ -0,0 +1,29 @@ +dnl opus-intrinsics.m4 +dnl macro for testing for support for compiler intrinsics, either by default or with a compiler flag + +dnl OPU...

...m_optimization} - Intrinsics Optimizations.......: ${enable_intrinsics} + Intrinsics Optimizations.......: ${intrinsics_support} Run-time CPU detection: ........ ${rtcd_support} Custom modes: .................. ${enable_custom_modes} Assertion checking: ............ ${enable_assertions} diff --git a/m4/opus-intrinsics.m4 b/m4/opus-intrinsics.m4 new file mode 100644 index 0000000..c74aecd --- /dev/null +++ b/m4/opus-intrinsics.m4 @@ -0,0 +1,29 @@ +dnl opus-intrinsics.m4 +dnl macro for testing for support for compiler intrinsics, either by default or with a compiler flag + +dnl OPU...

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