similar to: [LLVMdev] random clang install problem

I'm getting the error below on Ubuntu Hardy on ia32 on r55688. John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc

See below. This is on Ubuntu Hardy on ia32. Thanks, John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/.

I get the output below on Ubuntu Hardy on ia32 from svn 56984. John make[2]: Entering directory `/home/regehr/llvm-gcc/build/gcc' /home/regehr/llvm-gcc/build/./gcc/xgcc -B/home/regehr/llvm-gcc/build/./gcc/ -B/home/regehr/i686-pc-linux-gnu/bin/ -B/home/regehr/i686-pc-linux-gnu/lib/ -isystem /home/regehr/i686-pc-linux-gnu/include -isystem /home/regehr/i686-pc-linux-gnu/sys-include -O2 -O2

On Tue, Sep 2, 2008 at 8:21 PM, John Regehr <regehr at cs.utah.edu> wrote: > I'm getting the error below on Ubuntu Hardy on ia32 on r55688. > ... > ../../gcc/postreload-gcse.c:1123: error: > flag_darwin_rtl_pre_ignore_critical_edges undeclared (first use in this > function) This is a Darwin-specific flag. I added a conditional to check for "CONFIG_DARWIN_H"

I get this on Ubuntu Hardy on ia32: llvm[1]: Compiling raw_ostream.cpp for Release build In file included from raw_ostream.cpp:14: /home/regehr/llvm/include/llvm/Support/raw_ostream.h:116: error: ‘llvm::raw_ostream& llvm::raw_ostream::operator<<(size_t)’ cannot be overloaded /home/regehr/llvm/include/llvm/Support/raw_ostream.h:108: error: with ‘llvm::raw_ostream&

On ubuntu hardy on x86-64, using current svn, llvm builds fine, but I'm getting this when building llvm-gcc: /usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/../lib/crti.o' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/../lib/crtn.o' is incompatible with i386 output Searching the web for these messages turned up a few

Hi folks, Below is a short list of integer undefined behaviors executed by Clang when compiling the LLVM test suite. They seem pretty self explanatory, but let me know if not, if you cannot reproduce any of them, or if it would be better for me to file bugzillas on them. This is on x64 Linux, using r108984. Thanks, John --------------------------------- CLANG UNDEFINED at

I'm pretty sure that isn't what nnan is supposed to mean. If the result of nnan math were undefined in the sense of "undef", programs using nnan could have undefined behavior if the result is used in certain ways which would not be undefined for any actual float value (e.g. converting the result to a string), which seems like a surprising result.  And I don't think we

On Thu, Mar 1, 2018 at 2:08 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > We can do "add %x, undef" => "undef" because for any value of %x, we can > always find a value that when added to %x produces any value in the domain > of integers. > > This is not the case with floats since with some inputs, e.g., NaNs, we > are not able to produce some

What I’m saying is that if we have one operand that is not an undef value then that operand might be NaN and if it is then the result must be NaN. So while it may be true that we don’t have a NaN, it is not true that we definitely do not have a NaN in the example. This is analogous to the example in the language reference where it says “%A = or %X, undef” -> “%A = undef” is unsafe because any

I'm away from my Linux machines, if this hasn't been resolved by tonight I'll send more details. THe problem in cplus-dem.c is that CPP is conditionally including code that comes when HAVE_STDLIB is not defined, including an alternate protptype for malloc() that conflicts with the existing one. This is just what causes the error I sent-- no idea what the root cause is. Thanks,

We can do "add %x, undef" => "undef" because for any value of %x, we can always find a value that when added to %x produces any value in the domain of integers. This is not the case with floats since with some inputs, e.g., NaNs, we are not able to produce some values in the domain (e.g., there's no value of %x that makes "fadd NaN, %x" return 42.0). In

For the first part of Sanjay’s question, I think the answer is, “Yes, we can fold all of these to NaN in the general case.” For the second part, which the nnan FMF is present, I’m not sure. The particulars of the semantics of nnan are unclear to me. But let me explore what Eli is saying. It sounds reasonable, but I have a question about it. Suppose we have the nnan FMF set, and we encounter

Ok, makes sense. My suggestion is that we patch the IR Verifier to ensure that the mask is indeed a vector of constants and/or undefs. Right now it only runs the standard checks for instructions. We will also run Alive2 on the test suite to make sure undef is never replaced in practice. Thanks, Nuno -----Original Message----- From: Eli Friedman <efriedma at quicinc.com> Sent: 27 de

Ah, thanks for explaining. So given that any of these ops will return NaN with a NaN operand, let's choose the undef operand value to be NaN. That means we can fold all of these to a NaN constant in the general case. But if we have 'nnan' FMF, then we can fold harder to undef? nnan - Allow optimizations to assume the arguments and result are not NaN. Such optimizations are required to

1. I'm not sure what you mean by "full vector" here - using the same shift distance for all lanes (as opposed to per-lane distances), or doing a treat-the-vector-as-bag-of-bits shift that doesn't have any internal lane boundaries? If the latter, that doesn't really help you much with implementing a per-lane rotate. I think the most useful generalization of a vector

Other than finding someone to volunteer for the work required, is there a reason not to add a NaN the IR? I can already ask a ConstantFP if it is a NaN. Why not make that easier to represent? -----Original Message----- From: Nuno Lopes [mailto:nunoplopes at sapo.pt] Sent: Thursday, March 01, 2018 2:31 PM To: David Majnemer <david.majnemer at gmail.com> Cc: Kaylor, Andrew <andrew.kaylor

Why is NaN “just ‘undef’ in IR”? NaN is a specific value with well-defined behavior. I would think that unless the no-NaNs flag is used we need to preserve the behavior of NaNs. From: Sanjay Patel [mailto:spatel at rotateright.com] Sent: Wednesday, February 28, 2018 12:08 PM To: Kaylor, Andrew <andrew.kaylor at intel.com> Cc: llvm-dev <llvm-dev at lists.llvm.org>; Nuno Lopes

As you all have undoubtedly noticed, I recently did Yet Another Merge to Apple's GCC top-of-tree. This merge was prompted by several important fixes in the "blocks" implementation. There are still many testcases that need to be moved over, but those can come at our leisure. I compiled both the "Apple way" and the "FSF way". It also passed the tests in

Well, using ConstantFP to represent NaNs is at least unclear enough that someone claimed that there is no NaN constant in LLVM IR. :-) But your point is well made. I guess what I was really asking for is a 'NaN' token in the asm writer/parser. This is obviously a much less important issue, but I can't say that I would look at 0x7f800000 in an ll file and immediately think, "Oh,