similar to: [LLVMdev] FileCheck for instructions of indeterminate order?

Hi all, I'm investigating the following test case that reports as an unexpected pass on powerpc64-unknown-linux-gnu. Clang : CodeGenCXX/member-alignment.cpp This test case is marked as XFAIL for arm and powerpc. However, the test passes fine for powerpc64-unknown-linux-gnu. There are two tests of this form: void t::bar(void) { // CHECK: _ZN1t3barEv{{.*}} align 2

The problem I'm trying to solve: Invoking clang on PowerPC with -fno-altivec has no effect. >From what I've been able to piece together, PPC.td specifies various CPUs and the processor features available on each. So for example we have: def FeatureAltivec : SubtargetFeature<"altivec","HasAltivec", "true",

----- Original Message ----- > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com> > To: llvmdev at cs.uiuc.edu > Sent: Thursday, January 31, 2013 9:26:15 AM > Subject: [LLVMdev] Getting command line options to affect subtarget features > > The problem I'm trying to solve: Invoking clang on PowerPC with > -fno-altivec has no effect. > > From what

On Thu, 2013-01-31 at 11:29 -0600, Bill Schmidt wrote: > On Thu, 2013-01-31 at 11:23 -0600, Bill Schmidt wrote: > > On Thu, 2013-01-31 at 10:17 -0600, Bill Schmidt wrote: > > > > > > On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > > > > ----- Original Message ----- > > > > > From: "Bill Schmidt" <wschmidt at

On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > ----- Original Message ----- > > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com> > > To: llvmdev at cs.uiuc.edu > > Sent: Thursday, January 31, 2013 9:26:15 AM > > Subject: [LLVMdev] Getting command line options to affect subtarget features > > > > The problem I'm trying to

To fix some problems with how condition registers are saved/restored for PowerPC, I need to override TargetRegisterInfo::hasReservedSpillSlot() in PPCRegisterInfo. I've had some difficulties because of the constness of the function, and I'm wondering what the best way to handle this would be. Essentially I need to add a field to PPCRegisterInfo, and modify that field in

On Thu, 2013-01-31 at 10:17 -0600, Bill Schmidt wrote: > > On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > > ----- Original Message ----- > > > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com> > > > To: llvmdev at cs.uiuc.edu > > > Sent: Thursday, January 31, 2013 9:26:15 AM > > > Subject: [LLVMdev] Getting command line

On Thu, 2013-01-31 at 11:23 -0600, Bill Schmidt wrote: > On Thu, 2013-01-31 at 10:17 -0600, Bill Schmidt wrote: > > > > On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > > > ----- Original Message ----- > > > > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com> > > > > To: llvmdev at cs.uiuc.edu > > > > Sent:

On Fri, Sep 7, 2012 at 8:20 AM, Matthew Curtis <mcurtis at codeaurora.org>wrote: > Hello all, > > For the hexagon target, we have a couple of tests that are failing due to > variations in the order of checked text. In these cases the ordering is not > directly relevant to the functionality being tested. > > For example: > > ; CHECK: memw(##a) > ; CHECK:

On 9/7/2012 4:08 PM, Chandler Carruth wrote: > On Fri, Sep 7, 2012 at 8:20 AM, Matthew Curtis <mcurtis at codeaurora.org > <mailto:mcurtis at codeaurora.org>> wrote: > > Hello all, > > For the hexagon target, we have a couple of tests that are failing > due to variations in the order of checked text. In these cases the > ordering is not directly

Adding Jiangning Liu to the thread. Jiangning reported a similar issue on the llvm-commits list on Debian aarch64. In general it sounds like std::call_once may not really be bug free. Jiangning, can you please provide your gcc/libstdc++ version? Thanks, -Chris > On Nov 4, 2014, at 9:38 AM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote: > > On Tue, 2014-11-04 at 12:17

Ok, I'll put a patch together to fix this later today. I'll probably do what Reid was suggesting and use what is already in there for Windows. Thanks, Samuel Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote on 11/04/2014 12:11:08 PM: > From: Bill Schmidt <wschmidt at linux.vnet.ibm.com> > To: Samuel F Antao/Watson/IBM at IBMUS > Cc: azanella at

It seems the crash of llvm/clang build on aarch64 Debian has been fixed by r220941. Thanks, -Jiangning 2014-11-05 8:45 GMT+08:00 Jiangning Liu <liujiangning1 at gmail.com>: > The versions I'm using right now are > > * gcc: (Debian/Linaro 4.9.1-14) 4.9.1 > * libstdc++: libstdc++.so.6.0.20 > > Thanks, > -Jiangning > > 2014-11-05 4:46 GMT+08:00 Chris Bieneman

Hi Bill, You can find the same issue in the buildbot: http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/16444/steps/compile.llvm.stage2/logs/stdio It is failing for me both in BE (gcc 4.8.2) and LE(4.9.1). I am compiling with clang 3.5, but those are the gcc toolchains I am using. What do you think is the best way to fix this? Thanks! Samuel Bill Schmidt <wschmidt at

My 2c: I think that ability to pattern match “out-of-order” in tests is critical. I currently have to disable instruction scheduling on several Hexagon tests in order to preserve “expected” order of patterns, which has nothing to do with actual correctness of the test… So if nothing else, scheduler is left untested for those cases. Needless to say, this feature must maintain status quo for all

Hello all, For the hexagon target, we have a couple of tests that are failing due to variations in the order of checked text. In these cases the ordering is not directly relevant to the functionality being tested. For example: ; CHECK: memw(##a) ; CHECK: memw(##b) %0 = load i32* @a, align 4 %1 = load i32* @b, align 4 requires that the compiler emit the memory operations for

Just adding to the clamor for FileChecks ability to pattern match out-of-order (match for mere presence); Just in the last 2 weeks, I have come across at least a couple instances when I was unable to add small unit tests to the testsuite because of this deficiency in FileCheck. Also, I agree with Krzysztof about the lack of any real recurring overhead. Can this feature please be added to

Greetings, I'm investigating a bug in the PowerPC back end in which a load from a storage address is being reordered prior to a store to the same storage address. I'm quite new to LLVM, so I would appreciate some help understanding what I'm seeing from the dumps. I assume that some information is missing that would represent the memory dependency, but I don't know what form that

On Fri, 2013-05-17 at 15:32 -0700, Jakob Stoklund Olesen wrote: > On May 17, 2013, at 2:04 PM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote: > > > Hello, > > > > In http://llvm.org/viewvc/llvm-project?view=revision&revision=177889 and > > http://llvm.org/viewvc/llvm-project?view=revision&revision=177890 (along > > with some follow-up

Hi, I have imported some data to R from stata and my factor variables have an Indeterminate level which I don't really want. For example the variable sex has the levels Male, Female and Indeterminate. There are no 'Indeterminate' values in the data. Can somebody tell me how to get rid of this level as it restricting my cox ph model. Thanks Neil