similar to: [LLVMdev] Linux-x86 Compatability

Chris Lattner wrote: >>ISSUE: INT64_MAX undefined in InstrSelectionSupport.cpp and >>InstructionCombining.cpp. I'm not completely sure where INT64_MAX comes >>from on Solaris, but C99 says that INT64_MAX is defined in stdint.h, >>but, for C++, only if __STDC_LIMIT_MACROS is #defined. Solaris (at >>least in CSIL) unfortunately does not have stdint.h, but it does

> ISSUE: INT64_MAX undefined in InstrSelectionSupport.cpp and > InstructionCombining.cpp. I'm not completely sure where INT64_MAX comes > from on Solaris, but C99 says that INT64_MAX is defined in stdint.h, > but, for C++, only if __STDC_LIMIT_MACROS is #defined. Solaris (at > least in CSIL) unfortunately does not have stdint.h, but it does have > the old inttypes.h - and

Chris Lattner wrote: >>>Interesting. INT64_MAX is supposed to be provided by >>>include/Support/DataTypes.h. Do you know of a reliable preprocessor >>>symbol that can be used to determine whether we're on a linux box, or >>> >>> > > > >>Well, there is always __linux__, but that doesn't necessarily imply that >>we

ISSUE: line 474 of InstrSelectionSupport.cpp is a conditional expression of the form (<expr> ? (ConstantSInt*) : (ConstantUInt*)), which is an unholy mixture of pointer types. ACTION: Apply static_cast<Value*> to the two pointers, as the source intends. -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69 -------------- next part -------------- An embedded and

ISSUE: In CommandLine.h, gcc 2.96 thinks that the apply() template function, when called as: apply("Some text string", x) should be expanded to applicator<const char[n]>("Some text string", x) instead of applicator<char[n]>("Some text string", x). ACTION: Duplicate the template specialization for applicator<char[n]> as applicator<const

ISSUE: In Interpreter::getCurrentExecutablePath(), dladdr() is a Solarisism. Luckily, getCurrentExecutablePath isn't being currently used anywhere in lli. ACTION: Wrap the method contents with #ifdef __sun__ ... #else return ""; #endif. If this functionality is actually desired, it would be more portable to hack up main() to join getcwd() with basename(argv[0]) to find the

ISSUE: This code: %bob = type { int } int %alias() { %pbob1 = alloca %bob %pbob2 = getelementptr %bob* %pbob1 ;pbob2 aliases pbob1 %pbobel = getelementptr %bob* %pbob2, long 0, ubyte 0 %rval = load int* %pbobel ret int %rval } Crashes when run through opt -instcombine. InstCombiner visits instructions in reverse declaration order, but

On 3/28/19 11:18 AM, Richard W.M. Jones wrote: > This new pair of callbacks allows plugins to describe which extents in > the virtual disk are allocated, holes or zeroes. > --- > +++ b/server/extents.c > @@ -0,0 +1,210 @@ > +/* nbdkit > + * Copyright (C) 2019 Red Hat Inc. > + * All rights reserved. We started work on this phrase but it got waylaid by extents work; maybe

ISSUE: In Interpreter::executeInstruction(), _sys_siglistp is a Solarisism. ACTION: Replace _sys_siglistp[signo] with strsignal(signo) which is more portable, maybe POSIX? PATCH: Apply from llvm top-level directory with "patch -p0." -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69 -------------- next part -------------- An embedded and charset-unspecified text

ISSUE: ExternalFunctions.cpp::lookupFunction() calls dlsym(RTLD_DEFAULT, ...). In glibc, dlfcn.h does not make RTLD_DEFAULT visible unless _GNU_SOURCE is #defined. Unlike the evil money-grubbing non-free software pigs at sun, the FSF is trying not to pollute the C namespace. ;) ACTION: Hack the Makefile to #define _GNU_SOURCE while compiling in tools/lli. Yes, I know that this is ugly.

ISSUE: Linux doesn't have any steenking SIGEMT signal, as referred to in lib/Support/Signals.cpp. ACTION: Wrap the use with a #ifdef SIGEMT / #endif. PATCH: Apply from llvm top-level directory with "patch -p0". -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed...

So, I had to make a few changes to the llvm sources to allow compilation on x86 redhat 7.3 (gcc-2.96, glibc 2.2.4). Is there any general interest in maintaining a port? I will happily submit patches. -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69

Issue: GraphWriter includes <ostream>, which my gcc2 apparently thinks is <ostream.h>. Fix: Make a new <Support/ostream> that handles this discrepancy, ala <Support/hash_set>. -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch URL:

From: Nikolay Ivanets <stenavin@gmail.com> nbdkit_parse_size() uses strtoumax() function to parse input strings which states: "if there was a leading minus sign, the negation of the result of the conversion represented as an unsigned value, unless the original (nonnegated) value would overflow." Later validation doesn't catch the situation when parsed value is within the

On Tue, Sep 05, 2023 at 11:09:02AM +0100, Richard W.M. Jones wrote: > > > +static inline int64_t > > > +human_size_parse (const char *str, > > > + const char **error, const char **pstr) > > > +{ > > > + int64_t size; > > > + char *end; > > > + uint64_t scale = 1; > > > + > > > + /* XXX Should we

On Sun, Nov 10, 2013 at 01:42:24PM +0000, Alp Toker wrote: > |#undef NetBSD|| > ||#undef mips|| > ||#undef sparc|| > ||#undef INT64_MAX|| > ||#undef alloca| > > This is not OK to do globally -- even if LLVM doesn't care about the > definition, maybe embedding applications or OS headers do? Given that 3 of the 5 #undefs are directly relevant for me -- they exist

Is the #include <endian.h> necessary for Linux or is that a leftover artifact from before? I'm trying to get this code to compile on MacOS (which is based on BSD), and stdint.h exists there, but not endian.h. --Vikram ---------------------------------------------------------------------- VIKRAM S. ADVE Assistant Professor E-MAIL: vadve at cs.uiuc.edu

Chris Lattner wrote: >>test for linux / definition of __STDC_LIMIT_MACROS. This will not work, >>since stdint.h is implemented by including inttypes.h, which was already >>included the first time with __STDC_LIMIT_MACROS not defined. I think >>the best solution to this problem is to change DataTypes.h to simply: >> >> #define __STDC_LIMIT_MACROS >>

Change from v2: Correct the logic when calculating icount. Change from v1: According to Jan and Stefano''s comments, drop the previous logic which setting the value in an arbitrary way and use Stefano''s suggestion instead. Currently, the max expiration time is 2147483647ns(INT32_MAX ns). This is enough when guest is busy, but when guest is idle, the next timer will be later than

I can't seem to figure out how to tell the PassManager that one Pass requires the results of two other Passes, in such a way that it will not crash itself. Attached file is the simplest possible example of Passes A, B, and C, such that C's getAnalysisUsage(AU) method calls AU.addRequired<A>() and AU.addRequired<B>(). When I try to run opt -load ... -opt-c, it tells me: