similar to: [LLVMdev] HUGE_VALF in OSX

The build is failing with; LiveIntervalAnalysis.cpp:218: error: floating constant exceeds range of 'double' LiveIntervalAnalysis.cpp:253: 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

Chris said something about Xcode fixing this ? It doesn't happen with the GCC 3.4.6 compiler on Linux so that's why I missed it, but I thought Chris had fixed it. Reid. On Fri, 2006-11-03 at 08:48 -0400, Jim Laskey wrote: > The build is failing with; > > LiveIntervalAnalysis.cpp:218: error: floating constant exceeds range > of 'double' >

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

Hi, Any ideas why HUGE_VALF is not accepted as a float constant on Mac OS X 10.4.11 (Intel)? ./llvm/include/llvm/CodeGen/LiveInterval.h:569: error: floating constant exceeds range of 'float' ./llvm/include/llvm/CodeGen/LiveInterval.h:574: error: floating constant exceeds range of 'float' llvm/lib/CodeGen/CalcSpillWeights.cpp:111: error: floating constant exceeds range of

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

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

Thanks for the updates! Minor comments: + if (!Accuracy) + // If it's not a floating point number then it must be 'fast'. + return HUGE_VALF; Can we add an assert instead of a comment? It's just as documenting and will catch any goofs. + // If it's not a floating point number then it must be 'fast'. + return !isa<ConstantFP>(MD->getOperand(0));

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,

At line 1155 of LiveIntervalAnalysis.cpp (in LiveIntervals::rewriteInstructionsForSpills), should the condition be: if (ImpUse && MI != ReMatDefMI && MI != ReMatOrigDefMI) instead of: if (ImpUse && MI != ReMatDefMI) ? After all, ReMatDefMI is a clone of the original def instruction (ReMatOrigDefMI). I'm seeing bad things happen, with intervals getting HUGE_VALF

Hi Chandler, > Minor comments: > + if (!Accuracy) > + // If it's not a floating point number then it must be 'fast'. > + return HUGE_VALF; > > Can we add an assert instead of a comment? It's just as documenting and will > catch any goofs. Done. > > + // If it's not a floating point number then it must be 'fast'. > + return

Dave, The way I see it there should be just one pass that implements deleting UB (maybe it would come to be called UBCE), and that one pass should have a command line option simply for the reason than all passes should have one. Peter Lawrence. > On Jul 26, 2017, at 10:02 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Jul 26, 2017 at 9:23 PM

Mehdi, Hal’s transformation only kicks in in the *presence* of UB, and it does not matter how that UB got there, whether by function inlining or without function inlining. The problem with Hal’s argument is that the compiler does not have a built in ouija board with which it can conjure up the spirit of the author of the source code and find out if the UB was intentional with the

Dave, Dead code elimination is generally done in a pass called dead code elimination, Can you give concrete examples why the same would not be true for UB code elimination ? Yes, speculatively hoisting code requires it to be UB-free, but that has nothing to do with UBCE deleting entire blocks of code because of the existence of UB. The former requires an analysis proving UB-absense, the

David, -fsanitize=undefined sounds great, but is not quite what I want. I recently ran into a problem with "CodeGen/MachineSink.cpp” [*], for a target that has to expand Select into control flow. The original IR had two select in a row that were based on the same condition, so the CMP that sets the FLAGS reg in the second select was MCSE’ed to the earlier CMP in the first

> On Jul 21, 2017, at 10:55 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > 2017-07-21 22:44 GMT-07:00 Peter Lawrence <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>>: > Mehdi, > Hal’s transformation only kicks in in the *presence* of UB > > No, sorry I entirely disagree with this assertion: I believe we

Dave, I will try to locate and take a look at the actual llvm logic that deletes based on UB-presence, one of these days, and report back. In the mean time... Your “For example:" is a plausibility argument only. It is not meaningful until you can show this happening in real source code from real applications that are compiler warning free and static analysis warning free. Hal

On Wed, 5 May 2004, Finn S Andersen wrote: > 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

On Mon, Jul 31, 2017 at 7:40 AM Peter Lawrence <peterl95124 at sbcglobal.net> wrote: > Dave, > Dead code elimination is generally done in a pass called dead > code elimination, > Can you give concrete examples why the same would not be true for UB code > elimination ? > I haven't actually looked at how optimizations on the basis of the code being UB-free

> > Having read all of these threads, I am thoroughly convinced by the positions put forward by others. > Chandler, others have decided to let the compiler continue mis-compiling the function-inlining example, others have decided to not fix the inability to hoist a loop invariant divide out of a loop. It sounds like you haven’t even thought about these things let alone

Sean, Let me re-phrase a couple words to make it perfectly clear > On Jul 21, 2017, at 6:29 PM, Peter Lawrence <peterl95124 at sbcglobal.net> wrote: > > Sean, > > Dan Gohman’s “transform” changes a loop induction variable, but does not change the CFG, > > Hal’s “transform” deletes blocks out of the CFG, fundamentally altering it. > > These are two totally