search for: lnx1

Hello I have two MS AD 2008 let's say AD1 and AD2. They have bi-direction trusted relationship. I have two linux servers joined into AD2, let's say LNX1 and LNX2. On LNX1, it can authenticate any users both from AD1 or AD2. Howerver, on LNX2, it can only authenticate users in AD2 but failed against AD1. It reports NT_STATUS_TRUSTED_DOMAIN_FAILURE (0xc000018c). I'm sure the smb.conf have the same settings on LNX1 and LNX2. I set the log level =...

...o conflict opportunity. 2. I didn't realize the scope of the patch covered all targets and both scalars and vectors. That isn't going to work as-is. We can't assume that every target and data type will prefer to replace that multiply. Even the x86 diffs in lea-3.ll are regressions: -; LNX1-NEXT: leal (%rdi,%rdi,2), %eax +; LNX1-NEXT: leal (,%rdi,4), %eax +; LNX1-NEXT: subl %edi, %eax I suggest taking a smaller first step by limiting the patch to cases where the multiply is not a legal op for a target (TLI.isOperationLegal()). 3. Since the patch can cause a crash, that need...

...I didn't realize the scope of the patch covered all targets and both > scalars and vectors. That isn't going to work as-is. We can't assume > that every target and data type will prefer to replace that multiply. > Even the x86 diffs in lea-3.ll are regressions: > > -; LNX1-NEXT:    leal (%rdi,%rdi,2), %eax > +; LNX1-NEXT:    leal (,%rdi,4), %eax > +; LNX1-NEXT:    subl %edi, %eax > > I suggest taking a smaller first step by limiting the patch to cases > where the multiply is not a legal op for a target (TLI.isOperationLegal()). > > 3. Since th...

...the scope of the patch covered all targets and both > > scalars and vectors. That isn't going to work as-is. We can't assume > > that every target and data type will prefer to replace that multiply. > > Even the x86 diffs in lea-3.ll are regressions: > > > > -; LNX1-NEXT: leal (%rdi,%rdi,2), %eax > > +; LNX1-NEXT: leal (,%rdi,4), %eax > > +; LNX1-NEXT: subl %edi, %eax > > > > I suggest taking a smaller first step by limiting the patch to cases > > where the multiply is not a legal op for a target > (TLI.isOperationLega...

...targets > and both > > scalars and vectors. That isn't going to work as-is. We can't assume > > that every target and data type will prefer to replace that multiply. > > Even the x86 diffs in lea-3.ll are regressions: > > > > -; LNX1-NEXT:    leal (%rdi,%rdi,2), %eax > > +; LNX1-NEXT:    leal (,%rdi,4), %eax > > +; LNX1-NEXT:    subl %edi, %eax > > > > I suggest taking a smaller first step by limiting the patch to cases > > where the multiply is not a legal op for a target...

Hi, I am currently working on a more or less intrusive patch (D37896), which pulls optimizations on multiplications from some back-ends, e.g., (mul x, 2^N + 1) => (add (shl x, N), x) in AArch64, into the DAGCombiner to have this optimization generic on all targets. However, running the LLVM Tests leads to 67 unexpected results. Am 19.09.2017 um 15:58 schrieb Sanjay Patel: > For the

Hello list, I'm having some difficulty getting rJava to load in littler. Even after a R CMD javareconf and a reinstall of littler, I get this: jlaing at xenon:~$ r -e "require(rJava)" Loading required package: rJava Loading required package: methods Error : .onLoad failed in loadNamespace() for 'rJava', details: call: dyn.load(file, DLLpath = DLLpath, ...) error: unable

For the tests that are changing, you should see if those changes are improvements, regressions, or neutral. This is unfortunately not always obvious for x86 asm, so feel free to just post those diffs in an updated version of the patch at D37896. If the test files have auto-generated assertions (look for this string on the first line of the test file: "NOTE: Assertions have been autogenerated