[llvm-bugs] [Bug 30425] New: clang crash building libclc

2016-09-17 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30425

Bug ID: 30425
   Summary: clang crash building libclc
   Product: clang
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: adf.li...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 17294
  --> https://llvm.org/bugs/attachment.cgi?id=17294&action=edit
console output

Building libclc I am getting a crash in clang.
I don't build libclc very often so don't know how long this has been an issue.

I build llvm/clang with gcc 5.3.0 like -

cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
-DLLVM_TARGETS_TO_BUILD="host;AMDGPU" -DLLVM_ENABLE_ASSERTIONS=ON
-DLLVM_BUILD_LLVM_DYLIB=ON .. && make -j5


llvm head =

commit 338f974b6e4f5d5d004d36d0d446289280d0c372
Author: Kostya Serebryany 
Date:   Sat Sep 17 06:01:55 2016 +

[libFuzzer] properly reset the guards when reseting the coverage. Also try
to fix check-fuzzer on the bot

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281814
91177308-0d34-0410-b5e6-96231b3b80d8

clang head = 

commit 72aeae9a2f042f160e700b97fde61be3e0adc133
Author: Daniel Jasper 
Date:   Sat Sep 17 07:20:36 2016 +

clang-format: [JS] Fix a crash in handledTemplateStrings.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281816
91177308-0d34-0410-b5e6-96231b3b80d8

libclc head =

commit 598792bc7e9eb636f0fa892180770afc2442a6eb
Author: Tom Stellard 
Date:   Fri Sep 16 22:43:33 2016 +

configure: Add amdgcn-mesa-mesa3d target

git-svn-id: https://llvm.org/svn/llvm-project/libclc/trunk@281793
91177308-0d34-0410-b5e6-96231b3b80d8

output and files from /tmp attached.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 30426] New: x86_64 with SSE2 disabled: Assertion failed: (Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP register!"), function getFPReg

2016-09-17 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30426

Bug ID: 30426
   Summary: x86_64 with SSE2 disabled: Assertion failed: (Reg >=
X86::FP0 && Reg <= X86::FP6 && "Expected FP
register!"), function getFPReg
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: dimi...@andric.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

This is a rather strange one.  I got a test case via FreeBSD bug 212703 [1],
where somebody encountered a clang 3.4.1 segfault, compiling some sample from
openMVG [2].

This segfault is actually the assertion "(Reg >= X86::FP0 && Reg <= X86::FP6 &&
"Expected FP register!"), function getFPReg", and it even reproduces with trunk
r281149.

For some reason, the build process targets x86_64, but then turns off SSE2, and
this is the key to getting the assertion.  The test case is extremely minimal,
and optimization isn't even required:

// compile with: clang -cc1 -triple x86_64 -S -target-feature -sse2
testcase.cpp
void fn1(double);
int main() { fn1(4.); }

As far as I know, disabling SSE2 also disables all the higher forms of SSE, so
I think it just can't find any x87 FP register at all, in this case?

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212703
[2] https://github.com/openMVG/openMVG

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 30427] New: Tonga Unreal elemental bad rendering since [AMDGPU] Refactor MUBUF/MTBUF instructions

2016-09-17 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30427

Bug ID: 30427
   Summary: Tonga Unreal elemental bad rendering since [AMDGPU]
Refactor MUBUF/MTBUF instructions
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: AMDGPU
  Assignee: unassignedb...@nondot.org
  Reporter: adf.li...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 17297
  --> https://llvm.org/bugs/attachment.cgi?id=17297&action=edit
elemental bad rendering

R9285 Tonga, since -

commit c220fde748d8b296c46498b37753c494a57e2ee9
Author: Valery Pykhtin 
Date:   Sat Sep 10 13:09:16 2016 +

[AMDGPU] Refactor MUBUF/MTBUF instructions

Differential revision: https://reviews.llvm.org/D24295

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281137
91177308-0d34-0410-b5e6-96231b3b80d8

Unreal ElementalDemo doesn't render properly.

There is no error logging or crash.

Example screen + R600_DEBUG=vs,ps,fs for good and bad attached.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 30428] New: Infer nsw/nuw flags for increment/decrement if relational comparison succeeded

2016-09-17 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30428

Bug ID: 30428
   Summary: Infer nsw/nuw flags for increment/decrement if
relational comparison succeeded
   Product: new-bugs
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Keywords: code-quality
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: matti.niemenmaa+llvmb...@iki.fi
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Created attachment 17300
  --> https://llvm.org/bugs/attachment.cgi?id=17300&action=edit
LLVM emitted for simple Rust example

Consider the following example:


define i1 @func(i64 %a, i64 %b, i64 %c) {
  %sgt = icmp sgt i64 %a, %b
  br i1 %sgt, label %greater, label %lesser

greater:
  %add = add i64 %b, 1
  %sgt.add = icmp sgt i64 %add, %c
  ret i1 %sgt.add

lesser:
  ret i1 true
}


At the point where %add is executed we know that %sgt was true, i.e. %a > %b.
We then know that incrementing %b cannot wrap: there is "room" in the value
range for at least %a before we would wrap. More generally:

1. If (X s< Y), then both X + 1 and Y - 1 are nsw.
2. If (X u< Y), then both X + 1 and Y - 1 are nuw. [1]

Currently (LLVM trunk r281814, or release version 3.9.0) this kind of analysis
is not performed. I'm not sure where it would belong, either. It doesn't feel
important enough to me to have its own pass.

This arose from looking at why a bounds check in Rust is not eliminated [2]: it
would require this kind of analysis in addition to my patch from
https://reviews.llvm.org/D24700 to simplify unsigned comparisons. Attached is a
complete example of LLVM emitted by the Rust compiler including a bounds check
that could be eliminated. Adding a nuw flag to the increment and using a
version of opt that includes D24700, the whole function can be optimized down
to a 'ret void'.

[1]: Due to the current canonicalization from 'sub nuw Y, 1' to 'add Y, -1' the
latter flag would not be so helpful. But as I mention in D24700, this
canonicalization seems misguided to me: keeping the nuw would be useful.
[2]: https://github.com/rust-lang/rust/issues/35981

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 30429] New: Should recognize redundant comparisons with constant offsets

2016-09-17 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30429

Bug ID: 30429
   Summary: Should recognize redundant comparisons with constant
offsets
   Product: new-bugs
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Keywords: code-quality
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: matti.niemenmaa+llvmb...@iki.fi
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Consider the following pair of C functions that are both equivalent to "return
0":


int one(int i, int len) {
   return i < len && i + 1 > len;
}

int two(int i, int len) {
   return i + 1 < len && i + 2 > len;
}


They map to the following LLVM functions (simplified a bit):


define i32 @one(i32 %i, i32 %len) {
  %1 = icmp slt i32 %i, %len
  %2 = add nsw i32 %i, 1
  %3 = icmp sgt i32 %2, %len
  %4 = and i1 %1, %3
  %5 = zext i1 %4 to i32
  ret i32 %5
}

define i32 @two(i32 %i, i32 %len) {
  %1 = add nsw i32 %i, 1
  %2 = icmp slt i32 %1, %len
  %3 = add nsw i32 %i, 2
  %4 = icmp sgt i32 %3, %len
  %5 = and i1 %2, %4
  %6 = zext i1 %5 to i32
  ret i32 %6
}


Now, opt -instcombine optimizes @one to "ret i32 0" but leaves @two untouched.
This is because InstCombineCompares.cpp has logic for "icmp sgt (X + 1), Y ->
icmp sge X, Y" which starts the chain of optimizations required in @one. I
considered extending this to "icmp sgt (X + C), Y -> icmp sge (X + (C - 1)), Y"
(and analogously for the other similar icmp optimizations) but this isn't
always a profitable transformation and seems oddly specific anyway. It's only
worth it here because we happen to have "icmp slt (X + (C - 1)), Y" nearby and
can combine the two.

Overall this kind of thing seems like something LLVM should be able to
optimize, but I'm not sure how it should go about doing it. I would imagine
cases like these to show up in e.g. array bounds checks on occasion.

This was with LLVM trunk r281814 and release version 3.9.0.

For what it's worth, GCC 6.2.1 can optimize both C functions to return 0, but
even it is stumped by the following:

int two_trickier(int i, int len) {
   return i + 1 < len && i + 1 > len - 1;
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 30385] SORT_NONE not implemented

2016-09-17 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30385

George Rimar  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from George Rimar  ---
r281771

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 30430] New: AVX512: incorrect code generation for very basic code

2016-09-17 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30430

Bug ID: 30430
   Summary: AVX512: incorrect code generation for very basic code
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: wenzel.ja...@epfl.ch
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Hi,

I'm getting invalid code for a very basic snippet which constructs a packed
float array and prints it. I suspect an issue with calling conventions. The
problem only appears at optimization level -O0.

Observed output:

$ clang test.c -o test -mavx512f -stdlib=libc++ -O0
$ ./test   
   
   
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
9.00 10.00 11.00 12.00 13.00 14.00 15.00 16.00

Expected output:
$ ./test   
   
   
1.00 2.00 3.00 4.00 5.00 6.00 7.00 8.00
9.00 10.00 11.00 12.00 13.00 14.00 15.00 16.00

For reference, this is with

$ clang -v
clang version 4.0.0 (trunk 281812)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.5
Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.5
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

===
#include 

__m512 makefloat(float f1, float f2, float f3, float f4, float f5, float f6,
float f7, float f8, float f9, float f10, float f11, float f12, float f13, float
f14, float f15, float f16) {
return _mm512_setr_ps(f1, f2, f3, f4, f5, f6, f7, f8, f9, f10, f11, f12,
f13, f14, f15, f16);
}

int main(int argc, char *argv[]) {
__m512 x = makefloat(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
16);

float result[16];
_mm512_storeu_ps(result, x);
for (int i = 0; i < 16; ++i)
printf("%f ", result[i]);

return 0;
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 30395] SEGMENT_START's default argument can be an expression

2016-09-17 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30395

George Rimar  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from George Rimar  ---
r281831

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 30419] [ThinLTO] Assertion `GV.hasName() && "Can't get GlobalValueSummary for GV with no name"' failed.

2016-09-17 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30419

Teresa Johnson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Teresa Johnson  ---
Fix in at r281840.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 30431] New: error in backend: assembler label L?xxx$parent_frame_offset can not be undefined (MSVC, SEH-related)

2016-09-17 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30431

Bug ID: 30431
   Summary: error in backend: assembler label
L?xxx$parent_frame_offset can not be undefined (MSVC,
SEH-related)
   Product: clang
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: reupenl...@forward.cat
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

While compiling my source tree under LLVM-4.0.0-r281648-win64.exe and MSVC
2015, the following compilation error happens for debug builds:

CL : fatal error : error in backend: assembler label
'L?query_cpu_feature_set@pfc@@YA_NI@Z$parent_frame_offset' can not be undefined
[F:\foobar2000\columns_ui\pfc\pfc.vcxproj]

This does not happen in release builds. This happens in previous versions of
LLVM/Clang too.


To reproduce, open a VS2015 x86 Native Tools command prompt and run:

git clone --recursive https://github.com/reupen/columns_ui.git
cd columns_ui
msbuild /m /p:PlatformToolset=LLVM-vs2014 /p:Platform=Win32
/p:Configuration=Debug /t:Rebuild vc14\columns_ui-public.sln

The problematic function is defined here:
https://github.com/reupen/pfc/blob/07bdb04d9eef8a03fada2c3ee6f364039cb4a1b5/cpuid.cpp#L7

Removing the usage of SEH makes the problem go away. Release builds also work.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 30432] New: [Rust][MUSL] duplicate symbol: __tls_get_addr

2016-09-17 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30432

Bug ID: 30432
   Summary: [Rust][MUSL] duplicate symbol: __tls_get_addr
   Product: lld
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: ELF
  Assignee: unassignedb...@nondot.org
  Reporter: japarici...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Hello!

I'm working on embedding lld into rustc [1] with the goal of removing rustc
dependence on an external linker, like `cc`/`ld`, wherever possible. One of our
target use case is building statically linked Rust executables that are linked
to MUSL but using `lld` instead of `ld`. (The ultimate goal is to be able to
build/compile/link "foreign", e.g. ARM, binaries without having to install a
cross toolchain, e.g. `arm-linux-gnueabihf-gcc`, or a cross compiled C library,
but this bug report is about native linking).

But when trying to link the simplest Rust program using `lld` instead of `ld`,
which works fine, I'm hitting the following error:

```
duplicate symbol: __tls_get_addr in
$sysroot/lib/rustlib/x86_64-unknown-linux-musl/lib/liblibc-411f48d3.rlib(__tls_get_addr.lo)
and (internal)
```

### Steps To Reproduce

As a bash script but I've also attached the .cpio file generated by these
commands:

``` bash
main() {
install_rust

# test program
echo 'fn main() {}' > musl.rs

# to save some typing
local target=x86_64-unknown-linux-musl

# compile only, we'll link manually
rm -f musl.o
rustc --target $target --emit=obj musl.rs

# store the path to the sysroot in a variable to make the following
commands shorter
local sysroot=$(rustc --print sysroot)

# link 
# NOTE The arguments used here are what `rustc` (and `cc`) would ultimately
pass to `ld` when
# directly building an executable via the `rustc --target $target musl.rs`
command. You can see
# what flags `rustc` passes to `cc` with the `rustc --target $target -Z
print-link-args musl.rs`
# command.
ld.lld \
--build-id \
--hash-style=gnu \
-m \
elf_x86_64 \
-static \
-o \
musl \
-L$sysroot/lib/rustlib/x86_64-unknown-linux-musl/lib \
-L$sysroot/lib/rustlib/x86_64-unknown-linux-musl/lib \
-L/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1 \
-L/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../lib \
-L/lib/../lib \
-L/usr/lib/../lib \
-L/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../.. \
--as-needed \
-z \
noexecstack \
--eh-frame-hdr \
"-(" \
$sysroot/lib/rustlib/x86_64-unknown-linux-musl/lib/crt1.o \
$sysroot/lib/rustlib/x86_64-unknown-linux-musl/lib/crti.o \
musl.o \
--gc-sections \
-Bstatic \
-Bdynamic \
$sysroot/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd-411f48d3.rlib
\
   
$sysroot/lib/rustlib/x86_64-unknown-linux-musl/lib/libpanic_unwind-411f48d3.rlib
\
   
$sysroot/lib/rustlib/x86_64-unknown-linux-musl/lib/libunwind-411f48d3.rlib \
   
$sysroot/lib/rustlib/x86_64-unknown-linux-musl/lib/librand-411f48d3.rlib \
   
$sysroot/lib/rustlib/x86_64-unknown-linux-musl/lib/libcollections-411f48d3.rlib
\
   
$sysroot/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_unicode-411f48d3.rlib
\
   
$sysroot/lib/rustlib/x86_64-unknown-linux-musl/lib/liballoc-411f48d3.rlib \
   
$sysroot/lib/rustlib/x86_64-unknown-linux-musl/lib/liballoc_jemalloc-411f48d3.rlib
\
   
$sysroot/lib/rustlib/x86_64-unknown-linux-musl/lib/liblibc-411f48d3.rlib \
   
$sysroot/lib/rustlib/x86_64-unknown-linux-musl/lib/libcore-411f48d3.rlib \
   
$sysroot/lib/rustlib/x86_64-unknown-linux-musl/lib/libcompiler_builtins-411f48d3.rlib
\
$sysroot/lib/rustlib/x86_64-unknown-linux-musl/lib/crtn.o \
"-)" \
--reproduce musl

uninstall_rust
}

install_rust() {
curl https://sh.rustup.rs -sSf | sh -s -- --default-toolchain
nightly-2016-09-15 --no-modify-path -y
source ~/.cargo/env
rustup target add x86_64-unknown-linux-musl
}

uninstall_rust() {
rustup self uninstall
}

main
```

### Meta

```
$ ld.lld --version
LLD 4.0 (git://github.com/llvm-mirror/lld.git
a499b2da2436789a9136f046f193caad0801ed93)
```

### Background information

- On Linux, `rustc` uses `cc` to link executables.
- By default `rustc` produces executables that are *dynamically* linked to
*glibc*.
- But, if the `--target x86_64-unknown-linux-musl` flag is used, `rustc` will
produce a *statically* linked executable that's linked to *MUSL*.
- A `.rlib` file is just an archive (the stuff `ar` produces) that contain
(ELF) objects + Rust metadata.
- A copy of MUSL's `libc.a` lives in `liblibc.rlib`, which we distribute with
our toolchain. That's why we don't pass `-lc` to the linker.

Happy to provide

[llvm-bugs] [Bug 30433] New: [X86][SSE] Improve FCOPYSIGN lowering of vectors

2016-09-17 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30433

Bug ID: 30433
   Summary: [X86][SSE] Improve FCOPYSIGN lowering of vectors
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: llvm-...@redking.me.uk
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Lowering FCOPYSIGN of vector values are currently scalarized on SSE/AVX
targets. 

Both vector lowering and suitable vectorization costs and tests need to be
added.

define <4 x float> @fcopysign_v4f32(<4 x float> %x, <4 x float> %y) {
  %1 = call <4 x float> @llvm.copysign.v4f32(<4 x float> %x, <4 x float> %y)
  ret <4 x float> %1
}
declare <4 x float> @llvm.copysign.v4f32(<4 x float> %Mag, <4 x float> %Sgn)

define <2 x double> @fcopysign_v2f64(<2 x double> %x, <2 x double> %y) {
  %1 = call <2 x double> @llvm.copysign.v2f64(<2 x double> %x, <2 x double> %y)
  ret <2 x double> %1
}
declare <2 x double> @llvm.copysign.v2f64(<2 x double> %Mag, <2 x double> %Sgn)

fcopysign_v4f32:# @fcopysign_v4f32
vmovaps.LCPI0_0(%rip), %xmm2   # xmm2 =
[-0.00e+00,0.00e+00,0.00e+00,0.00e+00]
vmovaps.LCPI0_1(%rip), %xmm4   # xmm4 =
[nan,0.00e+00,0.00e+00,0.00e+00]
vmovshdup%xmm0, %xmm6# xmm6 = xmm0[1,1,3,3]
vandps%xmm2, %xmm1, %xmm3
vandps%xmm4, %xmm0, %xmm5
vandps%xmm4, %xmm6, %xmm6
vorps%xmm3, %xmm5, %xmm3
vmovshdup%xmm1, %xmm5# xmm5 = xmm1[1,1,3,3]
vandps%xmm2, %xmm5, %xmm5
vorps%xmm5, %xmm6, %xmm5
vpermilpd$1, %xmm0, %xmm6 # xmm6 = xmm0[1,0]
vpermilps$231, %xmm0, %xmm0 # xmm0 = xmm0[3,1,2,3]
vinsertps$16, %xmm5, %xmm3, %xmm3 # xmm3 = xmm3[0],xmm5[0],xmm3[2,3]
vpermilpd$1, %xmm1, %xmm5 # xmm5 = xmm1[1,0]
vpermilps$231, %xmm1, %xmm1 # xmm1 = xmm1[3,1,2,3]
vandpd%xmm4, %xmm6, %xmm6
vandps%xmm4, %xmm0, %xmm0
vandpd%xmm2, %xmm5, %xmm5
vandps%xmm2, %xmm1, %xmm1
vorpd%xmm5, %xmm6, %xmm5
vorps%xmm1, %xmm0, %xmm0
vinsertps$32, %xmm5, %xmm3, %xmm3 # xmm3 = xmm3[0,1],xmm5[0],xmm3[3]
vinsertps$48, %xmm0, %xmm3, %xmm0 # xmm0 = xmm3[0,1,2],xmm0[0]
retq

fcopysign_v2f64:# @fcopysign_v2f64
vmovapd.LCPI1_0(%rip), %xmm2   # xmm2 = [-0.00e+00,0.00e+00]
vmovapd.LCPI1_1(%rip), %xmm4   # xmm4 = [nan,0.00e+00]
vandpd%xmm2, %xmm1, %xmm3
vandpd%xmm4, %xmm0, %xmm5
vpermilpd$1, %xmm1, %xmm1 # xmm1 = xmm1[1,0]
vpermilpd$1, %xmm0, %xmm0 # xmm0 = xmm0[1,0]
vandpd%xmm2, %xmm1, %xmm1
vandpd%xmm4, %xmm0, %xmm0
vorpd%xmm3, %xmm5, %xmm3
vorpd%xmm1, %xmm0, %xmm0
vunpcklpd%xmm0, %xmm3, %xmm0 # xmm0 = xmm3[0],xmm0[0]
retq

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 30434] New: [Rust] Executable linked with -pie segfaults

2016-09-17 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30434

Bug ID: 30434
   Summary: [Rust] Executable linked with -pie segfaults
   Product: lld
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: ELF
  Assignee: unassignedb...@nondot.org
  Reporter: japarici...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Trying to link a hello world program written in Rust succeeds but running the
executable produces a
segfault. If I remove the `-pie` flag from the arguments `rustc` passes to
`lld` then the link
also succeeds but I get an executable that works correctly this time.

### Steps To Reproduce

As a bash script but I've also attached the .cpio file generated by these
commands:

``` bash
main() {
install_rust

# test program
echo 'fn main() { println!("Hello, world!"); }' > hello.rs

# compile only, we'll link manually
rm -f hello.o
rustc --emit=obj hello.rs

# store the path to the sysroot in a variable to make the following
commands shorter
local sysroot=$(rustc --print sysroot)

# link 
# NOTE The arguments used here are what `rustc` (and `cc`) would ultimately
pass to `ld` when
# directly building an executable via the `rustc hello.rs` command. You can
see what flags
# `rustc` passes to `cc` with the `rustc -Z print-link-args hello.rs`
command.
# NOTE(2) You will have to update the library search paths and paths to
startup objects
ld.lld \
--build-id \
--eh-frame-hdr \
--hash-style=gnu \
-m \
elf_x86_64 \
-dynamic-linker \
/lib64/ld-linux-x86-64.so.2 \
-pie \
-o \
hello \
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../lib/Scrt1.o \
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../lib/crti.o \
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/crtbeginS.o \
-L$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib \
-L$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib \
-L/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1 \
-L/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../lib \
-L/lib/../lib \
-L/usr/lib/../lib \
-L/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../.. \
--as-needed \
-z \
noexecstack \
hello.o \
--gc-sections \
-Bstatic \
-Bdynamic \
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-411f48d3.rlib
\
   
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-411f48d3.rlib
\
   
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-411f48d3.rlib \
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-411f48d3.rlib
\
   
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-411f48d3.rlib
\
   
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_unicode-411f48d3.rlib
\
   
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-411f48d3.rlib \
   
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-411f48d3.rlib
\
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-411f48d3.rlib
\
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-411f48d3.rlib
\
   
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-411f48d3.rlib
\
-ldl \
-lpthread \
-lgcc_s \
-lpthread \
-lc \
-lm \
-lrt \
-lutil \
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/crtendS.o \
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../lib/crtn.o \
--reproduce pie

# segfaults
./hello

# NOTE some link command as above but without the -pie flag
ld.lld \
--build-id \
--eh-frame-hdr \
--hash-style=gnu \
-m \
elf_x86_64 \
-dynamic-linker \
/lib64/ld-linux-x86-64.so.2 \
-o \
hello \
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../lib/Scrt1.o \
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../lib/crti.o \
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/crtbeginS.o \
-L$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib \
-L$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib \
-L/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1 \
-L/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../lib \
-L/lib/../lib \
-L/usr/lib/../lib \
-L/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../.. \
--as-needed \
-z \
noexecstack \
hello.o \
--gc-sections \
-Bstatic \
-Bdynamic \
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-411f48d3.rlib
\
   
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-411f48d3.rlib
\
   
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib

[llvm-bugs] [Bug 30435] New: [Rust][DebugInfo] SHF_MERGE section size must be a multiple of sh_entsize

2016-09-17 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30435

Bug ID: 30435
   Summary: [Rust][DebugInfo] SHF_MERGE section size must be a
multiple of sh_entsize
   Product: lld
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: ELF
  Assignee: unassignedb...@nondot.org
  Reporter: japarici...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

Trying to link a hello world program written in Rust with debuginfo enabled
yields the following error message:

```
hello.o: SHF_MERGE section size must be a multiple of sh_entsize
```

Omitting the debuginfo results in bug 30434
(https://llvm.org/bugs/show_bug.cgi?id=30434)

Linking with `ld` instead of `lld` works fine.

### Steps To Reproduce

As a bash script but I've also attached the .cpio file generated by these
commands below:

.cpio file: https://www.dropbox.com/s/nikwo5s8fms22du/debuginfo.cpio?dl=0

``` bash
main() {
# install_rust

# test program
echo 'fn main() { println!("Hello, world!"); }' > hello.rs

# compile only, we'll link manually
rm -f hello.o
# NOTE omit the `-g` to omit debuginfo
rustc -g --emit=obj hello.rs

# store the path to the sysroot in a variable to make the following
commands shorter
local sysroot=$(rustc --print sysroot)

# link 
# NOTE The arguments used here are what `rustc` (and `cc`) would ultimately
pass to `ld` when
# directly building an executable via the `rustc hello.rs` command. You can
see what flags
# `rustc` passes to `cc` with the `rustc -Z print-link-args hello.rs`
command.
# NOTE(2) You will have to update the library search paths and paths to
startup objects
ld.lld \
--build-id \
--eh-frame-hdr \
--hash-style=gnu \
-m \
elf_x86_64 \
-dynamic-linker \
/lib64/ld-linux-x86-64.so.2 \
-pie \
-o \
hello \
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../lib/Scrt1.o \
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../lib/crti.o \
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/crtbeginS.o \
-L$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib \
-L$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib \
-L/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1 \
-L/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../lib \
-L/lib/../lib \
-L/usr/lib/../lib \
-L/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../.. \
--as-needed \
-z \
noexecstack \
hello.o \
--gc-sections \
-Bstatic \
-Bdynamic \
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-411f48d3.rlib
\
   
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-411f48d3.rlib
\
   
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-411f48d3.rlib \
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-411f48d3.rlib
\
   
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-411f48d3.rlib
\
   
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_unicode-411f48d3.rlib
\
   
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-411f48d3.rlib \
   
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-411f48d3.rlib
\
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-411f48d3.rlib
\
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-411f48d3.rlib
\
   
$sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-411f48d3.rlib
\
-ldl \
-lpthread \
-lgcc_s \
-lpthread \
-lc \
-lm \
-lrt \
-lutil \
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/crtendS.o \
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../lib/crtn.o \
--reproduce debuginfo

uninstall_rust
}

install_rust() {
curl https://sh.rustup.rs -sSf | sh -s -- --default-toolchain
nightly-2016-09-15 --no-modify-path -y
source ~/.cargo/env
}

uninstall_rust() {
rustup self uninstall
}

main
```

### Meta

```
$ ld.lld --version
LLD 4.0 (git://github.com/llvm-mirror/lld.git
a499b2da2436789a9136f046f193caad0801ed93)
```

```
$ rustc -Vv
rustc 1.13.0-nightly (6ffdda1ba 2016-09-14)
binary: rustc
commit-hash: 6ffdda1ba183c981d57e63b59c88184be449eee4
commit-date: 2016-09-14
host: x86_64-unknown-linux-gnu
release: 1.13.0-nightly
```

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 30436] New: ARM64 assembler does not set shift bits on add instruction to calculate TLS address

2016-09-17 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30436

Bug ID: 30436
   Summary: ARM64 assembler does not set shift bits on add
instruction to calculate TLS address
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: lei.l...@windriver.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

ARM64 assembler generates invalid code sequence to access TLS variables in
local-exec TLS model.  In particular, the add instruction generated to
calculate the higher 12-bit value of TLS offset does not set its shift bit, so
the immediate value is incorrectly added to the lower part of the register.

E.g.

.text
.align  2
.global foo
.type   foo, %function
foo:
mrs x0, tpidr_el0
add x0, x0, #:tprel_hi12:ta
add x0, x0, #:tprel_lo12_nc:ta

Assembled with clang --target=arm64.

 :
   0:d53bd040 mrsx0, tpidr_el0
   4:9100 addx0, x0, #0x0
   8:9100 addx0, x0, #0x0

Assembled with aarch64-linux-gnu-gcc.

 :
   0:d53bd040 mrsx0, tpidr_el0
   4:9140 addx0, x0, #0x0, lsl #12
   8:9100 addx0, x0, #0x0

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 30437] New: [AArch64] Unnecessary mask instruction on AArch64

2016-09-17 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=30437

Bug ID: 30437
   Summary: [AArch64] Unnecessary mask instruction on AArch64
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: LLVM Codegen
  Assignee: unassignedclangb...@nondot.org
  Reporter: yyc1...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified

When compiling the following C program.

```c
typedef struct {
char a;
char b;
} ntuple2_t;

ntuple2_t g(void);

ntuple2_t f(void)
{
return g();
}
```

The LLVM IR generated on AArch64 is
```llvm
define i64 @f() local_unnamed_addr #0 {
  %1 = tail call i64 @g() #2
  %2 = and i64 %1, 65535
  ret i64 %2
}
```

Here the `and` instruction is not really necessary since `g` and `f` follows
the same calling convention.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 27504] Inherited constructor with dependent base class introduced by a typedef-name may not work

2016-09-17 Thread via llvm-bugs 
https://llvm.org/bugs/show_bug.cgi?id=27504

frankhb1...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #2 from frankhb1...@gmail.com ---
This is still strange following the assumptions on the resolution. How does the
existence of default template argument in the base interact with the
using-declaration?

If `S x;` is deleted, it also does not trigger any diagnostic. Does this
work as intended?

Moreover, will Clang++ preserve the behavior in old standard mode? (I read CWG
2070 as an "enhancement" to the standard.)

The diagnostic here is also confusing. Is it intended?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs