similar to: [LLVMdev] [Clang] Reasons for lack of -fsingle-precision-constant support? Alternatives?

Thanks for the response. If we add the support would you accept the patch? Seems like a pretty straightforward flag since it maps directly to NumericLiteralParser::NumericLiteralParser within LiteralSupport.cpp. I understand the maintenance concern with flags that affect multiple points in code though. Still trying to get the bottom of why we're crashing with double floating point literal.

Do anybody could compile app_conference on x86_64??? I tryied with two versions of app_conference and got the same problem on compiling: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared recompile with -fPIC app_conference.o: could not read symbols: Bad value" ENVIRONMENT:

On Fri, Apr 02, 2004 at 12:33:13AM -0500, Jean-Marc Valin wrote: > Do you have any sample code for that? Also, how do you tell autoconf to > append '-msse' without running into problems when CFLAGS is not set (and > usually defaults to -g -O2, but not always). Example patch attached. It only tries if the use passes --enable-sse; testing by target arch as Aron suggested is

On Mon, 2005-02-28 at 19:42 -0500, Jean-Marc Valin wrote: > > jean-marc: i think we can remove spx_sig_t *orig. > > but am not sure about exc2Buf. is it for extension? > > orig is already removed in SVN (which you should probably use). As for > exc2, it can be removed, but I'm not sure if you can just use exc > instead (maybe yes). > when removing "spx_sig_t

Any C gurus out there that can tell me if this code compiled ok to be used in x86_64 (Pentium Dual Core). It's for the app_conference application. Im using Centos 4.3 x86_64 kernel: 2.6.9-34.ELsmp libgcc-3.4.5-2 gcc-3.4.5-2 after the compilation part is the makefile ************begin compilation******************* [root@centos app_conference]# make clean rm -f *.so *.o app_conference.o

When compiling Speex 1.1.4 with GCC 3.3.2, the option -msse must be added to the CFLAGS in libspeex/Makefile. GCC 3.1.1 added a new option "-msse" (see http://gcc.gnu.org/gcc-3.1/changes.html , specifically under "New Targets and Target Specific Improvements") to enable SSE instructions within the compiler's output (for appropriate architectures). Compiling speex on

> On Nov 17, 2016, at 8:03 AM, Sanjay Patel <spatel at rotateright.com> wrote: > > On Thu, Nov 17, 2016 at 2:31 AM, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > On 17.11.2016 09:51, Ristow, Warren wrote: > Those are all good points. Your reassociation point in the context of > inlining is particularly

On 17.11.2016 09:51, Ristow, Warren wrote: > Those are all good points. Your reassociation point in the context of > inlining is particularly interesting. > > > > FWIW, we also have a case where a customer wants '-fno-associative-math' > to suppress reassociation under '-ffastmath'. It would take me a while > to find the specifics of the issue, but it was

If we take this argument to its end: any one of those relaxed FP settings *guarantees* that we cannot ensure that the result will be the same between two versions of clang. Therefore, we can no-op all of them, and greatly simplify the optimizer. I know that's not what you're advocating, but the suggestion that we remove 'arcp' is the first step on that path. We can't do that.

Hello, I''m having problems compiling Ruby 1.8.5 on a 64-bit Intel machine running Solaris 10 U3. I''m using Sun Studio 12 for building an optimized package for our company. We''re not interested in coolstack (from Sun used with GCC). Any help below would be appreciated: root@host # uname -an SunOS host 5.10 Generic_125101-08 i86pc i386 i86pc Solaris root@host # isainfo

Alfred E. Heggestad wrote: >On Mon, 2005-02-28 at 19:42 -0500, Jean-Marc Valin wrote: > > >>>jean-marc: i think we can remove spx_sig_t *orig. >>>but am not sure about exc2Buf. is it for extension? >>> >>> >>orig is already removed in SVN (which you should probably use). As for >>exc2, it can be removed, but I'm not sure if you

The patch prevents KEIL MDK compile warnings, like:   warning:  #1035-d: single-precision operand implicitly converted to double-precision Actually ARM Cortex-M4F has only a *single precision* (float) FPU. It's suit for all platforms. See the comment at the begin of patch file. Sincerely Forrest Zhang -------------- next part -------------- Specify the floating point constant with single