search for: huge_v

Chris Lattner wrote: >I think that we should switch to C constants in this case. Can you try >#include <math.h> and use HUGE_VAL instead? > It works: [finna at coplin11 ~/test]$ cat tst.cpp #include <limits> #include <iostream> #include <math.h> int main() { std::cerr << std::numeric_limits<float>::infinity() << "\n"; std::cerr << HUGE_VAL << "\n";...

...: error: floating constant exceeds range of 'double' LiveIntervalAnalysis.cpp:328: error: floating constant exceeds range of 'double' LiveIntervalAnalysis.cpp:1350: error: floating constant exceeds range of 'double' If I disable -pedantic the build succeeds. NOTE: HUGE_VALF should be used instead of (float)HUGE_VAL. Proposed patch enclosed. -------------- next part -------------- A non-text attachment was scrubbed... Name: HUGE_VAL.patch Type: application/octet-stream Size: 5451 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachm...

On Thu, May 06, 2004 at 04:06:27PM +0200, Finn S Andersen wrote: > Chris Lattner wrote: > > >I think that we should switch to C constants in this case. Can you try > >#include <math.h> and use HUGE_VAL instead? > > > It works: > > [finna at coplin11 ~/test]$ cat tst.cpp > #include <limits> > #include <iostream> > #include <math.h> > int main() { > std::cerr << std::numeric_limits<float>::infinity() << "\n"; > std:...

Chris Lattner wrote: >Could you try compiling and running this program: > >--- >#include <limits> >#include <iostream> >int main() { > std::cerr << std::numeric_limits<float>::infinity() << "\n"; >} >--- > > Sure thing. It prints "0". Calling that inifinity is somewhat of a stretch, isn't it ? What on earth

...s::infinity has had a line of problems: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5527 http://lists.suse.com/archive/suse-programming-e/2003-Mar/0004.html > What on earth is going on here? I think that we should switch to C constants in this case. Can you try #include <math.h> and use HUGE_VAL instead? -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/

...le' > LiveIntervalAnalysis.cpp:328: error: floating constant exceeds range > of 'double' > LiveIntervalAnalysis.cpp:1350: error: floating constant exceeds range > of 'double' > > If I disable -pedantic the build succeeds. > > > > > NOTE: HUGE_VALF should be used instead of (float)HUGE_VAL. Proposed > patch enclosed. > > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listi...

...How can I spill some live intervals at the end of each iteration with > new > > live intervals having correct weights? > > The linscan allocator inserts spill code with infinite weight, take a look > at how it works. So, as far as I understood live intervals with weight equal to HUGE_VAL are spilled and I don't need to allocate physical registers for them, right? Shoud hasStackSlot method of VirtRegMap return true for these intervals' reg members? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/a...

Hi all, Someone please consider committing the attached patch. It fixes building recent revisions with Visual C++. (HUGE_VAL is needed by LiveInterval.cpp, and it's defined in math.h, which didn't get included for MSVC.) Cheers, Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090728/c0b11b17/attachment.ht...

...happens, reg_v' will receive a physical register. You must assign to reg_v' a weight such that is is not spilled again, otherwise you may enter on an infinite loop, always spilling the same spilled register. Fernando > > So, as far as I understood live intervals with weight equal to HUGE_VAL are > spilled and I don't need to allocate physical registers for them, right? > Shoud hasStackSlot method of VirtRegMap return true for these intervals' reg > members? >

On Fri, Jan 29, 2016 at 6:27 PM, Matthias Braun via llvm-commits < llvm-commits at lists.llvm.org> wrote: > The point I was trying to make here is that all things that DataTypes.h > provides: > intXXX_t, uintXX_t, PRIdXX, INT64_MAX, HUGE_VAL, ssize_t ... > are all part of the C++11 standard and can be found in <cstdint>, <cmath> > (except for ssize_t) so I wondered if there is still a need for llvm to > provide this header since we require a C++11 compiler anyway nowadays. > FWIW, I've thought about this...

DataTypes.h is transitively included through a lot of very common includes already. So its entirely possible AMDGPU and Hexagon are really including it. On Fri, Jan 29, 2016 at 5:02 PM, mats petersson <mats at planetcatfish.com> wrote: > Sounds to me like including `DataTypes.h` would be the right choice, since > it will include `stdint.h` if it exists - and error if it doesn't,

all, this is all probably very old news and probably fixed in a later OSX, but..... on my 10.4.11 machine, math.h has (IMHO this bug) #define HUGE_VALF 1e50f this compiles when I build LLVM using "configure", but not with "cmake", probably to do with different C-standard-ness and pedantic-ness switches.... I would recommend LLVM Support not import the HUGE_VAL, HUGE_VALF feature, and instead use its own definition,...

...uential changes in LLVM seems trickier. > > Do you plan to correct it in CVS, or is there a path I can follow > > to fix it myself on my own installation ? > > The easy way to do it in your area is to replace all occurences of > std::numeric_limits<float>::infinity() with HUGE_VAL. The only two files > that use std::numeric_limits<float>::infinity() are > lib/CodeGen/RegAllocLinearScan.cpp and lib/CodeGen/LiveIntervals.cpp. > > As for CVS, I am not sure this should be fixed because there is > really no LLVM bug here :-) While this is not an LLVM bug,...

Hi! I'm developing a register allocator that works iteratively. It spills some virtual registers on each iteration until all the rest have physical ones assigned. How can I spill some live intervals at the end of each iteration with new live intervals having correct weights? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Sun, 6 Aug 2006, Anton Vayvod wrote: > I'm developing a register allocator that works iteratively. It spills some > virtual registers on each iteration until all the rest have physical ones > assigned. Take a look at the linear scan allocator. It is also iterative: it uses the spiller interface to insert spill code, which creates (unspillable) intervals for the spill code it

First: R core: (Thank You!)^HUGE_VAL Now, down to business: In a loop or in repeated command lines: system.time(lm(rnorm(1000)~rnorm(1000))) ( or lm(rnorm(1000)~rnorm(1000))$coef ) fails after several iterations with the Windows message 'This program has performed an illegal operation and will be shut down. If the problem p...

I am experiencing some difficulties with vorbis on my LX164 alpha. Specifically, in bark_noise (psy.c) I see the following behaviour on the first pass through the function: val=-3.4e38 del=1 noise[0]+=val*del noise[1]-=val*del norm[0]+=del norm[1]-=del del=1 noise[1]-=val*del <== here is the problem At this point, noise[1]==3.4e38. We are trying to add another 3.4e38 to it and this is

...sical register. You > must assign to reg_v' a weight such that is is not spilled again, > otherwise you may enter on an infinite loop, always spilling the same > spilled register. > > Fernando > > > > > So, as far as I understood live intervals with weight equal to HUGE_VAL > are > > spilled and I don't need to allocate physical registers for them, right? > > Shoud hasStackSlot method of VirtRegMap return true for these intervals' > reg > > members? > > > _______________________________________________ > LLVM Developers ma...

...as_object_set_variable (number, SWFDEC_AS_STR_MIN_VALUE, &val); + swfdec_as_object_set_variable_and_flags (number, SWFDEC_AS_STR_MIN_VALUE, + &val, SWFDEC_AS_VARIABLE_HIDDEN | SWFDEC_AS_VARIABLE_PERMANENT | + SWFDEC_AS_VARIABLE_CONSTANT); SWFDEC_AS_VALUE_SET_NUMBER (&val, -HUGE_VAL); - swfdec_as_object_set_variable (number, SWFDEC_AS_STR_NEGATIVE_INFINITY, &val); + swfdec_as_object_set_variable_and_flags (number, + SWFDEC_AS_STR_NEGATIVE_INFINITY, &val, SWFDEC_AS_VARIABLE_HIDDEN | + SWFDEC_AS_VARIABLE_PERMANENT | SWFDEC_AS_VARIABLE_CONSTANT); SWFDEC_A...

...+ +static void swfdec_as_context_init_global (SwfdecAsContext *context, guint version) { SwfdecAsValue val; @@ -770,6 +777,8 @@ swfdec_as_context_init_global (SwfdecAsC swfdec_as_object_set_variable (context->global, SWFDEC_AS_STR_NaN, &val); SWFDEC_AS_VALUE_SET_NUMBER (&val, HUGE_VAL); swfdec_as_object_set_variable (context->global, SWFDEC_AS_STR_Infinity, &val); + swfdec_as_object_add_function (context->global, SWFDEC_AS_STR_parseInt, 0, + swfdec_as_context_parseInt, 1); } /** diff --git a/libswfdec/swfdec_as_strings.c b/libswfdec/swfdec_as_strings.c i...