search for: abs64

...>> in trunk? > > I checked in a fix. Also, IndVarSimplify.cpp has the same problem, only one abs usage in it, line 700: if (Max.getZExtValue() > static_cast<uint64_t>(abs(intEV - intIV))) Following your style change: if (Max.getZExtValue() > static_cast<uint64_t>(abs64(intEV - intIV))) Also, why make an abs64, why not just override abs with 64 bit parameters?

I add a function abs64 to support abs for 64 bit integer -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -------------- next part -------------- A non-text attachment was scrubbed... Name: llvmabsfault.patch Type: application/octet-stream Size: 800 bytes Desc: not available URL: <http://lists.llvm.org/piperma...

...t; I checked in a fix. > > Also, IndVarSimplify.cpp has the same problem, only one abs usage in > it, line 700: > if (Max.getZExtValue() > static_cast<uint64_t>(abs(intEV - intIV))) > Following your style change: > if (Max.getZExtValue() > static_cast<uint64_t>(abs64(intEV - intIV))) Fixed, thanks. > Also, why make an abs64, why not just override abs with 64 bit > parameters? Because I think overloading standard functions is evil. ymmv.

...rodata section should be moved into a separate segment. For Bionic libc, the rodata section takes up 20% of its ALLOC | READ segment, and we'd like to be able to maintain page sharing for the remaining 189KiB of other read-only data in this segment. d) Relocations 1. GLOB_DAT, ABS64, and RELATIVE relocations change semantics - they would be required to retrieve and insert the memory tag of the symbol into the relocated value. For example, the ABS64 relocation becomes: sym_addr = get_symbol_address() // sym_addr = 0x1008 sym_addr |= get_tag(sym_addr & 0xf) /...

...s ** libs cc -xc99 -m64 -xarch=sparcvis2 -I/apps/sparcv9/R-2.12.0/lib/R/include -I/opt/csw/include -DHAVE_LIBIDN_FIELD=1 -DHAVE_CURLOPT_URL=1 -DHAVE_CURLINFO_EFFECTIVE_URL=1 .........(omitted here is very long, all upper case) -DHAVE_CURLOPT_SSL_SESSIONID_CACHE=1 -I/opt/csw/include -KPIC -xcode=abs64 -xlibmieee -xtarget=ultra3 -xarch=sparcvis2 -c base64.c -o base64.o "/opt/csw/include/curl/curlrules.h", line 144: zero or negative subscript "base64.c", line 25: warning: assignment type mismatch: pointer to const char "=" pointer to unsigned char "base64...

...k' root@dqssun4 local# which cc /opt/solstudio12.2/bin/cc root@dqssun4 local# which R /apps/sparcv9/R-2.12.0/bin/R The configure script for the successful R installation is the following, CC="cc -xc99 -m64 -xarch=sparcvis2" CPPFLAGS="-I/opt/csw/include" CFLAGS="-xcode=abs64 -xlibmieee -xtarget=ultra3 -xarch=sparcvis2" F77=f95 CXX="CC -m64 -library=stlport4" FC=$F77 FFLAGS="-m64 -xarch=sparcvis2" FCFLAGS=$FFLAGS LDFLAGS="-L/opt/csw/lib/sparcv9 -L/opt/solstudio12.2/prod/lib/v9" export CC CPPFLAGS CFLAGS F77 FFLAGS CXX CXXFLAGS FC FCFLA...

On May 12, 2009, at 5:01 PMPDT, OvermindDL1 wrote: > On Tue, May 12, 2009 at 5:01 PM, Dale Johannesen <dalej at apple.com> > wrote: >> >> On May 12, 2009, at 3:09 PMPDT, OvermindDL1 wrote: >> >>> The error given: >>> >>> ..\..\..\..\trunk\lib\Transforms\Scalar >>> \LoopStrengthReduce.cpp(1016) : >>> error C2668:

...o a separate segment. For Bionic > libc, the rodata section takes up 20% of its ALLOC | READ segment, and we'd > like to be able to maintain page sharing for the remaining 189KiB of other > read-only data in this segment. > > > > d) Relocations > > > > GLOB_DAT, ABS64, and RELATIVE relocations change semantics - they would > be required to retrieve and insert the memory tag of the symbol into the > relocated value. For example, the ABS64 relocation becomes: > > sym_addr = get_symbol_address() // sym_addr = 0x1008 > > sym_addr |= get_tag(sym...

On Tue, May 12, 2009 at 5:01 PM, Dale Johannesen <dalej at apple.com> wrote: > > On May 12, 2009, at 3:09 PMPDT, OvermindDL1 wrote: > >> The error given: >> >> ..\..\..\..\trunk\lib\Transforms\Scalar\LoopStrengthReduce.cpp(1016) : >> error C2668: 'abs' : ambiguous call to overloaded function >> >> It should be rather obvious from the

...ent. For Bionic libc, the rodata section takes up 20% of its ALLOC | READ segment, and we'd like to be able to maintain page sharing for the remaining 189KiB of other read-only data in this segment. >>> > >>> > d) Relocations >>> > >>> > GLOB_DAT, ABS64, and RELATIVE relocations change semantics - they would be required to retrieve and insert the memory tag of the symbol into the relocated value. For example, the ABS64 relocation becomes: >>> > sym_addr = get_symbol_address() // sym_addr = 0x1008 >>> > sym_addr |= get_t...

...> like to be able to maintain page sharing for the remaining 189KiB of > other > > read-only data in this segment. > > i think a design that prevents sharing is not acceptable. > > > > > d) Relocations > > > > 1. > > > > GLOB_DAT, ABS64, and RELATIVE relocations change semantics - they > would > > be required to retrieve and insert the memory tag of the symbol into > the > > relocated value. For example, the ABS64 relocation becomes: > > sym_addr = get_symbol_address() // sym_addr = 0x1008 > &...

...ointerType>(IPtr->getType())->getElementType(); > + int64_t VTyTSS = (int64_t) TD.getTypeStoreSize(VTy); > + > + assert(VTy == cast<PointerType>(JPtr->getType())->getElementType()); > + > + OffsetInElmts = Offset/VTyTSS; > + return (abs64(Offset) % VTyTSS) == 0; > + } > + > + return false; > + } > + > + // Returns true if the provided CallInst represents an intrinsic that can > + // be vectorized. > + bool isVectorizableIntrinsic(CallInst* I) { > + bool VIntr = false; > +...

...e())->getElementType(); > > + int64_t VTyTSS = (int64_t) TD.getTypeStoreSize(VTy); > > + > > + assert(VTy == cast<PointerType>(JPtr->getType())->getElementType()); > > + > > + OffsetInElmts = Offset/VTyTSS; > > + return (abs64(Offset) % VTyTSS) == 0; > > + } > > + > > + return false; > > + } > > + > > + // Returns true if the provided CallInst represents an intrinsic that can > > + // be vectorized. > > + bool isVectorizableIntrinsic(CallInst* I) { &gt...

On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > > Tobias, > > > > I've attached an updated patch. It contains a few bug fixes and many > > (refactoring and coding-convention) changes inspired by your comments. > > > > I'm currently trying to fix the bug responsible for causing a compile

...e())->getElementType(); > > + int64_t VTyTSS = (int64_t) TD.getTypeStoreSize(VTy); > > + > > + assert(VTy == cast<PointerType>(JPtr->getType())->getElementType()); > > + > > + OffsetInElmts = Offset/VTyTSS; > > + return (abs64(Offset) % VTyTSS) == 0; > > + } > > + > > + return false; > > + } > > + > > + // Returns true if the provided CallInst represents an intrinsic that can > > + // be vectorized. > > + bool isVectorizableIntrinsic(CallInst* I) { &gt...

On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > Tobias, > > I've attached an updated patch. It contains a few bug fixes and many > (refactoring and coding-convention) changes inspired by your comments. > > I'm currently trying to fix the bug responsible for causing a compile > failure when compiling >