similar to: [LLVMdev] Building llvm-gcc for specific processors

Hi Martin, On Tue, Mar 20, 2018 at 1:18 PM Martin J. O'Riordan <MartinO at theheart.ie> wrote: > Thanks Eric, > > > > After the original reply to my query I had a good look at the GCC > documentation for these options, and what I discovered is that “there is no > consensus” in GCC. Basically, saying do what GCC does was a non-answer as > it clarified nothing.

Thanks very much Eric for taking the time to carefully explain this to me. So if I am the author of the backend for a new processor technology, or willing to modernise my existing implementation, you would recommend that the ‘-mcpu’ option is deprecated and probably best not used at all, or perhaps just as a synonym for ‘-march + -mtune’? The first part of the target triple guides the

Thanks Eric, After the original reply to my query I had a good look at the GCC documentation for these options, and what I discovered is that “there is no consensus” in GCC. Basically, saying do what GCC does was a non-answer as it clarified nothing. X86 has deprecated ‘-mcpu’ in favour of ‘-mtune’, and it uses ‘-mtune’ to mean that the scheduling, etc. should be biased in favour of more

Hi, Recently, I committed a patch adding default features for '-mcpu'. And after that, Eric replied me here's a proposal toward using '-march' instead of '-mcpu'. As it's half a year later from original proposal, some background may changes. One thing worth to mention is, during this time, Apple Contributed its backend and introduced another new CPU type: cyclone.

Full_Name: Poor Yorick Version: R-2.6.1 OS: 2.4.21-50.ELhugemem #1 SMP Tue May 8 17:10:31 EDT 2007 i686 i686 i386 GNU/Linux Submission from: (NULL) (148.168.40.4) After compiling R-2.6.1 with gcc-4.2.1 pressing the 'delete' key three times in an interactive session causes R to malfunction, spitting out an infinite stream of errors. I have also replicated the issue in R-2.5.1: R

Hi all, I compiled 64-bit R on an Apple Mac G5 running OS X, but it failed make check. Simon Urbanek suggested I post results to R-devel. > On Nov 6, 2007, at 10:23 PM, Steven McKinney wrote: > > > Hi Simon, > > > > Would you be able to give more guidance on how to compile 64-bit > > libiconv for Tiger, > > You can get the sources from Apple and compile

Hi there, I am trying to install from the source R-2.4.0 on my mac (osx 10.4.8 G5 DP) The error imply Tcl/Tk. I install it by all the way I know: darwinport, the Tcl/Tk package from the dmg available from CRAN but without success. The PATH is correct. tclConfig.sh is localised in /opt/local/lib and have those permission: -rw-r--r-- 2 root admin 7K Oct 9 09:49 tclConfig.sh Here is

On May 10, 2010, at 9:07 PM, NAKAMURA Takumi wrote: > Hello. This is my 1st post. ようこそ！ > I have tried SSE execution domain fixup pass. > But I am not able to see any improvements. Did you actually measure runtime, or did you look at assembly? > I expect for the example below to use MOVDQA, PAND &c. > (On nehalem, ANDPS is extremely slower than PAND) Are you sure? The

I was recently asked to upgrade some neolithic aged software (UW-IMAP, sendmail 8.12.x, apache 1.3, amongst other horrors). The box is physically remote, so an aggressive "new flush" wasn't an option. I've been able to upgrade the compiler to gcc-3.4, openssl to 1.0.2k, glibc, php to something in the 5.4-branch, etc. I have CLucene working, even. I know should take a shotgun

Hi, I have a number of issues compiling samba 3.4.0pre1 using makerpms.sh, under the RHEL folder in packaging. 1) samba.spec refers to 'source' when the folder has been renamed to 'source3' (easy enough to amend) which made it fail very early on. 2) Following that - (apologies in advance, if I have gone over the top in pasting output), it seems to be complaining about missing

Hello. This is my 1st post. I have tried SSE execution domain fixup pass. But I am not able to see any improvements. I expect for the example below to use MOVDQA, PAND &c. (On nehalem, ANDPS is extremely slower than PAND) Please tell me if something would be wrong for me. Thank you. Takumi Host: i386-mingw32 Build: trunk at 103373 foo.ll: define <4 x i32> @foo(<4 x i32> %x,

Hi Matt Your method is the easiest way for me to install the 64-bit R. I followed the directions on your web site and then did the following: R --arch=x86_64 source("http://bioconductor.org/biocLite.R") biocLite(type = "source",lib = "/Library/Frameworks/R.framework/Versions/2.8/Resources/RLib64") I got many errors and warnings which I copied to the attached file.

Hi, i'm running dovecot on a SMP sparc 32bit server with solaris 8(latest patch installed). Dovecot with ssl. Postfix+imap+maildrop . Dovecot work fine with every email and folders delivered by maildrop, but now i'm trying to move all my local folders (i'm using mutt and i'm storing my emails locally on my pc) to the imap server . The upload of an entire 12000 mails folders

>From http://bugs.r-project.org/cgi-bin/R: If you are not sure whether you have observed a bug or not, it is a good idea to ask on the mailing list R-Help by sending an e-mail to r-help at stat.math.ethz.ch rather than submitting a bug report. I'm wondering whether to submit a bug report on this: ============================================================== >

Let me describe more precisely what I am doing and why the results I got may help improve LLVM's performance on modern x86-64 processors regardless of the front end (GCC, Clang or DragonEgg). I am running ALL my tests on an Intel Xeon E5540 processor, which is an x86-64 Nehalem processor. The OS is a 64-bit version of Ubuntu. So, I am running all my tests on the same x86-64 machine and am

I think that this works (and adds no appreciable driver complexity) provided that we're not expecting to support -mtune. If clang is (one day) going to be able to isel based on one target and optimize based on another then we might find ourselves wanting to change the meaning of -march from 'isel and optimize' to 'isel only'. So Amara's question about -mtune (or more

Hi Tim, 2014-06-25 15:26 GMT+08:00 Tim Northover <t.p.northover at gmail.com>: > Hi Kevin, > > I assume you've looked at the GCC documentation in this area, since > your ideas are very similar: > https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html. I actually > think that looks like a rational set of conventions too. > > The main difference appears to be

On Mon, Jan 16, 2012 at 12:29 AM, Ghassan Shobaki <ghassan_shobaki at yahoo.com > wrote: > Let me describe more precisely what I am doing and why the results I got > may help improve LLVM's performance on modern x86-64 processors regardless > of the front end (GCC, Clang or DragonEgg). > > I am running ALL my tests on an Intel Xeon E5540 processor, which is an > x86-64

What would be the proper clang (3.2) options to generate ARM for Raspberry pi for LLVM 3.2 with clang 3.2? I realized that "-ccc-host-triple" is no longer valid option in clang. p.s. I googled and found the following which doesn't work with clang 3.2. To cross-compile for Raspberry Pi add flags -ccc-host-triple arm-eabi -marm -mfpu=vfp -mcpu=arm1176jzf-s -mtune=arm1176jzf-s

I knew I'd regret leaving that option in for the MIPS port back in 99. Basically this is the only acceptable way for mcpu to exist, but should never have been added to the GCC aarch64 port at all since there's no compatibility with existing build systems to worry about. I would still like you to show this mythical piece of software that needs this compatibility. -eric On Jan 8, 2014 3:06