similar to: [LLVMdev] [PATCH] Detect SVN revision and path on Git working copy

On Sep 17, 2013, at 6:16 AM, Adam Strzelecki <ono at java.pl> wrote: > Currently when building from Git `clang --version` shows Git hash and repo URL > instead of SVN revision. However SVN is master for LLVM, so it is better to > show exactly the same as if built from SVN, if we build using clean master. I’m not sure I follow why that is better. If I’m building from a clone of a

On 17 Sep 2013, at 18:18, Mark Lacey <mark.lacey at apple.com> wrote: > This means that from build to build, depending on whether a Git change or SVN change is the most recent on my branch, I will get different results. That seems problematic. If you're not rebasing after pulling in changes from LLVM svn, then you're going to be in for a world of pain later (I, unfortunately,

> Anyway, thanks very much for the information. Hopefully that'll let me > track things down. Let me know if you need some more information or dumps. > Would you mind me taking a day or so to investigate what's going on > here properly? Introducing a volatile to work around a bug in Clang > itself just seems perverse to me. (And we shouldn't let a CodeGen bug >

Hello, This is my first patch on this list, however I've already submitted several trough bug tracking system. Since it probably needs some review and it's not a bug I am submitting it here. The main intent of this patch is to detect "core-avx2" platform on Haswell i7 CPUs when running -march=native. Currently it detects it as generic x86_64. lib/Support/Host.cpp: * Haswell is

Hi Adam, > * I have marked HasAVX2 as "volatile", since otherwise it gets > magically zeroed (by optimizer?) when compiling clang with latest > clang build from trunk That's far more worrying to me than not being able to detect Haswell. I can't reproduce the problem here at the moment: both debug and release builds give identical assembly for Host.cpp. I don't

Hi Yuri, > Is there an API function exported from libLLVM.so that would return the > version of llvm compiler used? > I would like to be able to read not only 2.8 but also the precise source > version identifier, like svn revision for example. And maybe the build date. maybe utils/GetSourceVersion will help. Ciao, Duncan.

On 07/21/2010 03:39, Duncan Sands wrote: > maybe utils/GetSourceVersion will help. > No, I meant can I read the version from the shared library libLLVM.so? I guess the answer is "no". So I will make a patch for this. Yuri

Pretty sure you need to check EAX>=7 from cpuid leaf 0 before calling leaf 7 and you need to use the pass ECX=0 to leaf 7. See lib/Target/X86/X86Subtarget.cpp which uses a GetX86CpuIDAndInfoEx function to pass EAX and ECX to cpuid. I don't think it explains your compiler bug though. On Thu, Sep 12, 2013 at 2:12 PM, Adam Strzelecki <ono at java.pl> wrote: > > Anyway, thanks

On 02/05/2014 11:26, Adam Strzelecki wrote: >> It should be fixed. Can you confirm? > > Nope. Sorry. Still doesn't work here: > > Get:3 http://llvm.org/apt/trusty/ llvm-toolchain-trusty/main libllvm3.5 amd64 1:3.5~svn207822-1~exp1 [7,300 kB] > Get:4 http://llvm.org/apt/trusty/ llvm-toolchain-trusty/main llvm-3.5-runtime amd64 1:3.5~svn207822-1~exp1 [52.0 kB] > Get:5

Is there an API function exported from libLLVM.so that would return the version of llvm compiler used? I would like to be able to read not only 2.8 but also the precise source version identifier, like svn revision for example. And maybe the build date. Yuri

Rsync has no memory of what other instances of rsync have done in the past. An existing file with a different name is of no interest to it unless --delete in which case it would be deleted. Maybe what you really want is --partial-dir? On 6/7/23 16:17, Lacey, Nathan wrote: > I'm suggesting a partial file that isn't hidden is worse. > Because any other app looking at the file

Hello, I don't know how it happened, but recent Ubuntu builds have broken -dev packages, which contain same libraries as non-dev packages. dpkg: error processing archive /var/cache/apt/archives/libllvm3.5_1%3a3.5~svn207603-1~exp1_amd64.deb (--unpack): trying to overwrite '/usr/lib/llvm-3.5/lib/libLLVM-3.5.so', which is also in package llvm-3.5-dev 1:3.5~svn207603-1~exp1 dpkg:

On 2013 Nov 15, at 19:41, Mark Lacey <mark.lacey at apple.com> wrote: > I don’t have the C/C++ standards in front of me but IIRC whether a char/short/int/long/long long bitfield is signed or unsigned is implementation defined. You need to explicitly specify signed or unsigned in order to have any guarantee of the signedness, e.g. signed int. Section 3.9.1 of the C++11 standard [1]

Hi, I would like to add a key to my trellis plot using draw.key. Here is what I want: 3 x 6 key where the first row is a header. row 1: empty, "S-R Mapping", "R^2" row 2: pch=17, "Color", 0.951 row 2: pch=17, "Shape", 0.934 ect... The problem is that I would like the cell in the upper left corner to be empty (a placeholder) with the remaining

On Nov 15, 2013, at 3:42 PM, Kay Tiong Khoo <kkhoo at perfwizard.com> wrote: > I've been diagnosing this bug: > http://llvm.org/bugs/show_bug.cgi?id=17827 > > Summary: I think the following program miscompiles at -O1 because the fact that 'f0' is a signed 3-bit value is lost in the unoptimized LLVM IR. How do we fix this? I don’t have the C/C++ standards in front

I've been diagnosing this bug: http://llvm.org/bugs/show_bug.cgi?id=17827 Summary: I think the following program miscompiles at -O1 because the fact that 'f0' is a signed 3-bit value is lost in the unoptimized LLVM IR. How do we fix this? $ cat bitfield.c /* %struct.S = type { i8, [3 x i8] } ??? */ struct S { int f0:3; } a; int foo (int p) { struct S c = a; c.f0 = p & 6;

Hi Mark, This will workaround the problem of "default" branch restriction on the switch instruction. The trouble with this technique is that it will trump later optimization phases such as constant propagation. When a block was part of a case, because of the knowledge of the case value, the block was a candidate for better optimization. However, when we move the body of the case into

On Thu, Aug 8, 2013 at 2:07 PM, Chad Rosier <chad.rosier at gmail.com> wrote: > On Thu, Aug 8, 2013 at 1:56 PM, Mark Lacey <mark.lacey at apple.com> wrote: > >> >> On Aug 8, 2013, at 9:56 AM, Jim Grosbach <grosbach at apple.com> wrote: >> >> Hi Chad, >> >> This is a great transform to do, but you’re right that it’s only safe >>

C says that plain bit-fields could be either signed or unsigned. C++ removed this allowance in core issue 739: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#739 On Sat, Nov 16, 2013 at 1:55 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > On 2013 Nov 15, at 19:41, Mark Lacey <mark.lacey at apple.com> wrote: > > > I don’t have the C/C++

Hi, Well after trying to fix the assign commands in version 3.1.7 of your nlme package I still cannot get the plot functions to work. Basically I have no other packages installed (apart from those provided with R) so nlme is the first. my R version info is; platform sparc-sun-solaris2.7 arch sparc os solaris2.7 system sparc, solaris2.7 status