similar to: [LLVMdev] Implementation of builtins/intrinsics

Le 20 janv. 2012 à 14:38, Ruben Van Boxem a écrit : > Hi, > > Lately, I have been wondering how a compiler like GCC or Clang implements builtin functions like sqrt, sin, and also more bit-specific things like bcmp and ffs. Originially, these were all deferred to the C library where they might still have a "backup implementation", but I don't understand why a compiler would

If we are considering an optimization to convert calls to memcmp into bcmp, then does it make sense to add an intrinsic for bcmp like there is for memcmp? That way IR writers can express their requirements precisely: memcmp if you care about the direction of inequality, and bcmp if you do not. On Fri, Jan 4, 2019 at 12:34 PM James Y Knight via llvm-dev < llvm-dev at lists.llvm.org> wrote:

On Mon, Jan 7, 2019 at 5:50 AM Clement Courbet <courbet at google.com> wrote: > On Fri, Jan 4, 2019 at 12:34 PM James Y Knight via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> This seems a somewhat odd and overcomplicated way to go about this. >>> >>> Given that bcmp was required in POSIX until relatively recently, I will

On Tue, Jan 8, 2019 at 9:24 AM Clement Courbet <courbet at google.com> wrote: > > > On Mon, Jan 7, 2019 at 10:26 PM James Y Knight <jyknight at google.com> > wrote: > I'm afraid about the "almost" and "generally": what about users who don't ? > Even so, it should be fine to enable it for those platforms which do include it. I do note,

On Thu, Jan 10, 2019 at 4:47 PM Clement Courbet <courbet at google.com> wrote: > > > On Wed, Jan 9, 2019 at 6:16 PM James Y Knight <jyknight at google.com> wrote: > >> >> >> On Tue, Jan 8, 2019 at 9:24 AM Clement Courbet <courbet at google.com> >> wrote: >> >>> >>> >>> On Mon, Jan 7, 2019 at 10:26 PM James Y

Hi all, We'd like to suggest *adding a -memeq-lib-function* flag to allow the user to specify a `*memeq()*` function to improve string equality check performance. Right now, when llvm encounters a *string equality check*, e.g. `if (memcmp(a, b, s) == 0)`, it tries to expand to an equality comparison if `s` is a small compile-time constant, and falls back on calling `memcmp()` else. This is

2011/1/5 Óscar Fuentes <ofv at wanadoo.es>: > Ruben Van Boxem <vanboxem.ruben at gmail.com> writes: > >> Yeah that's the two different ones I mean. Everything MS (intrinsics, >> language features etc...) is purely version-bound, so I don't even get >> why CMake insists on checking every known function prototype of for >> example "recv"

I first sent this to the Clang dev list, but they told me to come here: ---------- Forwarded message ---------- From: Ruben Van Boxem <vanboxem.ruben at gmail.com> Date: 2010/12/31 Subject: LLVM on Windows MSVC 10 To: cfe-dev at cs.uiuc.edu Hi, I'm trying to build svn LLVM with Visual Studio 2010: cd build cmake .. -G"NMake Makefiles" nmake and several link steps fail

Clang doesn't have a suitable replacement for libgcc readily available. Supply one that we know exists. Use "-fno-builtin-bcmp" to prevent clang from calling a function that doesn't exist. Signed-off-by: Bill Wendling <morbo at google.com> --- scripts/Kbuild.klibc | 2 ++ usr/klibc/arch/x86_64/MCONFIG | 2 ++ 2 files changed, 4 insertions(+) diff --git

On Thu, Oct 6, 2011 at 2:09 PM, Ruben Van Boxem <vanboxem.ruben at gmail.com> wrote: > You're welcome! Please remember that MinGW-w64 does not mean it is 64-bit. > It provides both 32- and 64-bit headers/libs. The "w64" in the name was > originally because that was the project's principal goal, among extending > the API completeness and compatibility with MSVC.

Whoops, phone rang and I forgot to cc to the list before I typed the message. ----- Forwarded Message ---- > From: Samuel Crow <samuraileumas at yahoo.com> > To: Ruben Van Boxem <vanboxem.ruben at gmail.com> > Sent: Wed, January 5, 2011 3:38:21 PM > Subject: Re: [LLVMdev] include/Config/config.h discrepancies between CMake and >autofoo builds > > > >

Clang defaults to "-fno-common" which causes linking errors because of duplicate symbols in the BSS section. Signed-off-by: Bill Wendling <morbo at google.com> --- usr/klibc/arch/x86_64/MCONFIG | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/usr/klibc/arch/x86_64/MCONFIG b/usr/klibc/arch/x86_64/MCONFIG index a6ba7c85c68b..46d29985bfd6 100644 ---

I don't normally build using nmake.. but I just tried and it worked 100% here. Are you sure you are using the trunk? On Fri, Dec 31, 2010 at 7:32 AM, Ruben Van Boxem <vanboxem.ruben at gmail.com>wrote: > I first sent this to the Clang dev list, but they told me to come here: > > > ---------- Forwarded message ---------- > From: Ruben Van Boxem <vanboxem.ruben at

- Renamed IMAGE_BASE to LD_IMAGE_BASE_OPT. - Moved "-fcommon" to KLIBCREQFLAGS in scripts/Kbuild.klibc. - Remove "dash" warning fixes which have been upstreamed. - Conditionalize the inclusion of compiler flags by using the proper compiler name or "cc-option". - Added "-Werror" to "cc-option" to catch flags that cause warnings. - Retain

2010/12/31 Francois Pichet <pichet2000 at gmail.com>: > I don't normally build using nmake.. but I just tried and it worked 100% > here. > Are you sure you are using the trunk? > > On Fri, Dec 31, 2010 at 7:32 AM, Ruben Van Boxem <vanboxem.ruben at gmail.com> > wrote: >> >> I first sent this to the Clang dev list, but they told me to come here:

hi Roland > On Tue, 1 Nov 2016 11:00:15 +0000 > niya levi via samba <samba at lists.samba.org> wrote: > >> hi everyone >> >> i have configured 2 domain controllers and a domain member >> >> the domain member is joined to the domain and >> >> ad and rfc2307 is configured for idmap backend, >> >> wbinfo returns domain builtins for

On Thu, Oct 6, 2011 at 2:00 PM, Ruben Van Boxem <vanboxem.ruben at gmail.com> wrote: > When building LLVM/Clang, I get the following build failure: > > MinGW-w64 provides the necessary typedefs and declarations. I adjusted the > ifdef's to include a check for a the MinGW-w64-specific symbol of choice to > differentiate mingw.org vs mingw-w64. Tested on i686-w64-mingw32 and

2011/10/6 Aaron Ballman <aaron at aaronballman.com> > On Thu, Oct 6, 2011 at 2:09 PM, Ruben Van Boxem > <vanboxem.ruben at gmail.com> wrote: > > You're welcome! Please remember that MinGW-w64 does not mean it is > 64-bit. > > It provides both 32- and 64-bit headers/libs. The "w64" in the name was > > originally because that was the

This is a series of patches for clang compatibility: - Using flags needed flags and removing unsupported flags. - Adding support for clang's LLD linker. - Removing a variety of warnings. Bill Wendling (3): [klibc] Kbuild: use "libc.a" with clang [klibc] Kbuild: Add "-fcommon" for clang builds [klibc] Clean up clang warnings Michael Davidson (1): [klibc] Kbuild:

Run this: >p <- c('a', 'c', '', ''); a <- c(10, 20, 30, 40); d1 <- >data.frame(Promoter=p, ip=a) # Note duplicate empty names in p. >p <- c('b', 'c', 'd', ''); a <- c(15, 20, 30, 40); d2 <- >data.frame(Promoter=p, ip=a) >all <- merge(x=d1, y=d2, by="Promoter", all=T) >all <-