[llvm-bugs] [Bug 50797] New: clang goes into an endless loop while trying to produce diagnostics

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50797

Bug ID: 50797
   Summary: clang goes into an endless loop while trying to
produce diagnostics
   Product: clang
   Version: 12.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: C
  Assignee: unassignedclangb...@nondot.org
  Reporter: jeroen.dobbela...@synopsys.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk

During a creduce session of a csmith triggered issue, I stumbled upon this
unrelated, but still annoying bug:
For the provided program, clang goes into an endless loop.
Based on the backtrace, it might be related to
TransformTypos::RecursiveTransformLoop ; At least, that one is consistently
showing up.


#0  0x04b111e0 in clang::TreeTransform<(anonymous
namespace)::TransformTypos>::TransformCXXDependentScopeMemberExpr(clang::CXXDependentScopeMemberExpr*)
()
#1  0x04b10898 in clang::TreeTransform<(anonymous
namespace)::TransformTypos>::TransformBinaryOperator(clang::BinaryOperator*) ()
#2  0x04ad9d63 in (anonymous
namespace)::TransformTypos::RecursiveTransformLoop(clang::Expr*, bool&) ()
#3  0x04ada6be in clang::Sema::CorrectDelayedTyposInExpr(clang::Expr*,
clang::VarDecl*, bool, llvm::function_ref (clang::Expr*)>) [clone .localalias.8] ()
#4  0x046bfddd in
clang::Parser::ParseParenExpression(clang::Parser::ParenParseOption&, bool,
bool, clang::OpaquePtr&, clang::SourceLocation&) [clone .lo


https://www.godbolt.org/z/5Mxae6fWY

Based on godbolt's feedback, this was introduced for llvm-12 and is still
present in trunc
It also only happens when in 'C' mode, C++ mode does not get into a loop.

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

[llvm-bugs] [Bug 50615] Miscompile with "[X86FixupLEAs] Transform the sequence LEA/SUB to SUB/SUB"

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50615

Max Kazantsev  changed:

   What|Removed |Added

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

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

[llvm-bugs] [Bug 50529] [lld/mac/arm64] Two of Chromium's base_unittests fail when linked with lld

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50529

Nico Weber  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Fixed By Commit(s)||https://reviews.llvm.org/rG
   ||d6565a2dbcbe0932cd5cbb95bf2
   ||fc06855dfe938
 Resolution|--- |FIXED

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

[llvm-bugs] [Bug 50703] Segfault in llvm::DIE::getUnitDie

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50703

Kamlesh Kumar  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 CC||kamleshbha...@gmail.com
 Status|NEW |RESOLVED

--- Comment #5 from Kamlesh Kumar  ---


*** This bug has been marked as a duplicate of bug 50611 ***

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

[llvm-bugs] [Bug 50798] New: [SIMD] code not recognized as all_true

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50798

Bug ID: 50798
   Summary: [SIMD] code not recognized as all_true
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: WebAssembly
  Assignee: unassignedb...@nondot.org
  Reporter: cl...@evan.coeusgroup.com
CC: llvm-bugs@lists.llvm.org

LLVM doesn't recognize that it can optimize these functions to an *.all_true
instruction..  This one might be a bit too specialized; it doesn't surprise me
at all that LLVM doesn't generate an *.all_true instruction.  Still, it would
be nice since the scalar version is pretty bad.

I've included an OpenMP SIMD annotation to try to help the compiler, but
obviously it would be better if it weren't required.

Here is the example, or on Compiler Explorer at https://godbolt.org/z/x3xshzYrf
if you prefer:


#include 

#pragma clang diagnostic ignored "-Wmissing-prototypes"

/* Because of , not
 * a WASM issue. */
#pragma clang diagnostic ignored "-Wsign-conversion"

typedef int8_t i8x16 __attribute__((__vector_size__(16)));
typedef int16_t i16x8 __attribute__((__vector_size__(16)));
typedef int32_t i32x4 __attribute__((__vector_size__(16)));
typedef int64_t i64x2 __attribute__((__vector_size__(16)));

int
i8x16_all_true(i8x16 a) {
int8_t r = ~0;
#pragma omp simd reduction(&:r)
for (int i = 0 ; i < 16 ; i++) {
r &= a[i];
}
return !!r;
}

int
i8x16_all_true_intrin(i8x16 a) {
return __builtin_wasm_all_true_i8x16(a);
}

int
i16x8_all_true(i16x8 a) {
int16_t r = ~0;
#pragma omp simd reduction(&:r)
for (int i = 0 ; i < 8 ; i++) {
r &= a[i];
}
return !!r;
}

int
i16x8_all_true_intrin(i16x8 a) {
return __builtin_wasm_all_true_i16x8(a);
}

int
i32x4_all_true(i32x4 a) {
int32_t r = ~0;
#pragma omp simd reduction(&:r)
for (int i = 0 ; i < 4 ; i++) {
r &= a[i];
}
return !!r;
}

int
i32x4_all_true_intrin(i32x4 a) {
return __builtin_wasm_all_true_i32x4(a);
}

int
i64x2_all_true(i64x2 a) {
int64_t r = ~0;
#pragma omp simd reduction(&:r)
for (int i = 0 ; i < 2 ; i++) {
r &= a[i];
}
return !!r;
}

int
i64x2_all_true_intrin(i64x2 a) {
return __builtin_wasm_all_true_i64x2(a);
}

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

[llvm-bugs] Issue 35481 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-simplifycfg: Use-of-uninitialized-value in llvm::IRBuilderBase::CreateSelect

[ClusterFuzz-External via monorail via llvm-bugs]

Status: New
Owner: 
CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, 
d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, 
llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, 
mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com 
Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer 
Engine-libfuzzer OS-Linux Proj-llvm Security_Severity-Medium Reported-2021-06-22
Type: Bug-Security

New issue 35481 by ClusterFuzz-External: 
llvm:llvm-opt-fuzzer--x86_64-simplifycfg: Use-of-uninitialized-value in 
llvm::IRBuilderBase::CreateSelect
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35481

Detailed Report: https://oss-fuzz.com/testcase?key=5488276524892160

Project: llvm
Fuzzing Engine: libFuzzer
Fuzz Target: llvm-opt-fuzzer--x86_64-simplifycfg
Job Type: libfuzzer_msan_llvm
Platform Id: linux

Crash Type: Use-of-uninitialized-value
Crash Address: 
Crash State:
  llvm::IRBuilderBase::CreateSelect
  SimplifyCFGOpt::simplifyOnce
  llvm::simplifyCFG
  
Sanitizer: memory (MSAN)

Recommended Security Severity: Medium

Crash Revision: 
https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&revision=202011180625

Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5488276524892160

Issue filed automatically.

See https://google.github.io/oss-fuzz/advanced-topics/reproducing for 
instructions to reproduce this bug locally.
When you fix this bug, please
  * mention the fix revision(s).
  * state whether the bug was a short-lived regression or an old bug in any 
stable releases.
  * add any other useful information.
This information can help downstream consumers.

If you need to contact the OSS-Fuzz team with a question, concern, or any other 
feedback, please file an issue at https://github.com/google/oss-fuzz/issues. 
Comments on individual Monorail issues are not monitored.

-- 
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 50799] New: [SIMD] Creating a vector from dereferenced pointer and zeros should use v128.load32/64_zero

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50799

Bug ID: 50799
   Summary: [SIMD] Creating a vector from dereferenced pointer and
zeros should use v128.load32/64_zero
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: WebAssembly
  Assignee: unassignedb...@nondot.org
  Reporter: cl...@evan.coeusgroup.com
CC: llvm-bugs@lists.llvm.org

Currently the compiler will generate a scalar load and a vector replace_lane. 
Example (Compiler Explorer: https://godbolt.org/z/bfv3nY6ro):



#include 

#pragma clang diagnostic ignored "-Wmissing-prototypes"

typedef int32_t i32x4 __attribute__((__vector_size__(16)));
typedef int64_t i64x2 __attribute__((__vector_size__(16)));

i32x4
load32_zero(const int32_t * a) {
  return (i32x4) { *a, 0, 0, 0 };
}

i64x2
load64_zero(const int64_t * a) {
  return (i64x2) { *a, 0 };
}

i32x4
load32_zero_intrin(const int32_t * a) {
return __builtin_wasm_load32_zero(a);
}

i64x2
load64_zero_intrin(const int64_t * a) {
return __builtin_wasm_load64_zero(a);
}

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

[llvm-bugs] [Bug 50800] New: [SIMD] *dest = vec[lane] should generate store*_lane instruction

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50800

Bug ID: 50800
   Summary: [SIMD] *dest = vec[lane] should generate store*_lane
instruction
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: WebAssembly
  Assignee: unassignedb...@nondot.org
  Reporter: cl...@evan.coeusgroup.com
CC: llvm-bugs@lists.llvm.org

This is very similar to #50792 (which is the load*_lane version, this is for
store*_lane).  Both are blocking the implementation of overloaded functions for
these operations in WAV.

Assigning an element from a vector to a pointer should use one of the
v128.store*_lane instructions, but right now uses an extract_lane and a scalar
store.

Example (Compiler Explorer: https://godbolt.org/z/a1cz8hexW):


#include 

typedef int8_t i8x16 __attribute__((__vector_size__(16)));
typedef int16_t i16x8 __attribute__((__vector_size__(16)));
typedef int32_t i32x4 __attribute__((__vector_size__(16)));
typedef int64_t i64x2 __attribute__((__vector_size__(16)));

void
i8x16_store_lane(int8_t * dest, i8x16 src) {
*dest = src[1];
}

void
i16x8_store_lane(int16_t * dest, i16x8 src) {
*dest = src[1];
}

void
i32x4_store_lane(int32_t * dest, i32x4 src) {
*dest = src[1];
}

void
i64x2_store_lane(int64_t * dest, i64x2 src) {
*dest = src[1];
}

void
i8x16_load_lane_intrin(int8_t * dest, i8x16 src) {
__builtin_wasm_store8_lane(dest, src, 1);
}

void
i16x8_load_lane_intrin(int16_t * dest, i16x8 src) {
__builtin_wasm_store16_lane(dest, src, 1);
}

void
i32x4_load_lane_intrin(int32_t * dest, i32x4 src) {
__builtin_wasm_store32_lane(dest, src, 1);
}

void
i64x2_load_lane_intrin(int64_t * dest, i64x2 src) {
__builtin_wasm_store64_lane(dest, src, 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 4832] inability to mark function as 'never returns NULL'

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=4832

Aaron Puchert  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|CONFIRMED   |RESOLVED

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

[llvm-bugs] [Bug 50801] New: missing sign extension when converting int to long long

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50801

Bug ID: 50801
   Summary: missing sign extension when converting int to long
long
   Product: new-bugs
   Version: 12.0
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: n...@fluxnic.net
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org

Given the following code:

int bar(long long x);

int foo(int x)
{
if (x < 0 || x >= 1024) return -1;
return bar(x);
}

Invoking clang with -O2 produces this for arm:

foo:
mov r1, #0
cmp r1, r0, lsr #10
mvnne   r0, #0
bxnelr
mov r1, #0
b   bar

And the following for i386:

foo:
pushl   %ebp
movl%esp, %ebp
movl8(%ebp), %eax
cmpl$1023, %eax # imm = 0x3FF
jbe .LBB0_1
movl$-1, %eax
popl%ebp
retl
.LBB0_1:
pushl   $0
pushl   %eax
calll   bar
addl$8, %esp
popl%ebp
retl

Notice that in both cases the argument to bar() is not sign extended as it
ought to be.

The same can be observed on aarch64 by replacing "long long" with "__int128":

foo:// @foo
cmp w0, #1023   // =1023
b.ls.LBB0_2
mov w0, #-1
ret
.LBB0_2:
mov w0, w0
mov x1, xzr
b   bar

And similarly for x86_64.

A slight simplification in the conditional e.g. removing the "x < 0" part is
enough for this issue to disappear.

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

[llvm-bugs] [Bug 11638] False positive "called function pointer is null" after assuming variable not null

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=11638

Aaron Puchert  changed:

   What|Removed |Added

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

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

[llvm-bugs] [Bug 50761] Cherry-pick 71e4d434dc83b02a853712a5cb026ee2fa9ba67f to release/12.x

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50761

Louis Dionne  changed:

   What|Removed |Added

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

--- Comment #3 from Louis Dionne  ---
commit 275ffa580880f6e18bf9742cad8e5dcab67b1f1d
Author: Louis Dionne 
Date:   Wed Jun 16 12:35:00 2021 -0400

[libc++] Make sure std::allocator is always trivial

When we removed the allocator specialization, the triviality of
std::allocator changed because the primary template had a
non-trivial default constructor and the specialization didn't
(so std::allocator went from trivial to non-trivial).

This commit fixes that oversight by giving a trivial constructor to
the primary template when instantiated on cv-void.

This was reported in https://llvm.org/PR50299.

(cherry picked from commit 71e4d434dc83b02a853712a5cb026ee2fa9ba67f)

Differential Revision: https://reviews.llvm.org/D104486

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

[llvm-bugs] [Bug 49317] [meta] 12.0.1 Release Blockers

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=49317
Bug 49317 depends on bug 50761, which changed state.

Bug 50761 Summary: Cherry-pick 71e4d434dc83b02a853712a5cb026ee2fa9ba67f to 
release/12.x
https://bugs.llvm.org/show_bug.cgi?id=50761

   What|Removed |Added

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

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

[llvm-bugs] [Bug 4558] False positive: assuming null for value previously assumed non-null

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=4558

Aaron Puchert  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|CONFIRMED   |RESOLVED
 CC||aaronpuch...@alice-dsl.net,
   ||noqnoq...@gmail.com

--- Comment #4 from Aaron Puchert  ---
Comment 3 says this should be fixed by now, and there has been no reply.

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

[llvm-bugs] [Bug 50801] missing sign extension when converting int to long long

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50801

Nicolas Pitre  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

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

[llvm-bugs] [Bug 50721] [Arm32] Atomic operations on 64-bit operations have invalid bit-cast

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50721

Renato Golin  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #1 from Renato Golin  ---
Looking at other back-ends, all of them create bitcasts to
`Builder.getInt8PtrTy()` which assumes whatever pointer was already in the
default address space. None of them have guards or asserts to check the address
space.

Of course, some of that code is from before address spaces were introduced, but
what I mean is that, since it has been added (many years ago), none of them had
to deal with different address spaces at that level, which means the
expectation David mentioned is pervasive and historical.

I don't think we need any special treatment of bitcasts in the ARM back-end. If
there's anything that needs to be encoded, it should be at a higher level.

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

[llvm-bugs] [Bug 50224] std::forward_list::swap noexcept specification not using correct member type

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50224

Louis Dionne  changed:

   What|Removed |Added

 Fixed By Commit(s)||7adf713a5e22b44c7cc746bcd37
   ||9d844277a19f2
 Resolution|--- |FIXED
 CC||ldio...@apple.com
 Status|NEW |RESOLVED

--- Comment #1 from Louis Dionne  ---
Thanks for the fix!

commit 7adf713a5e22b44c7cc746bcd379d844277a19f2
Author: Hyundeok Park 
Date:   Tue Jun 22 12:37:51 2021 -0400

[libc++] Change forward_list::swap to use propagate_on_container_swap for
noexcept specification

The current implementation of `std::forward_list::swap` uses
`propagate_on_container_move_assignment` for `noexcept` specification.
This patch changes it to use `propagate_on_container_swap`, as it should.

Fixes https://llvm.org/PR50224.

Differential Revision: https://reviews.llvm.org/D101899

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

[llvm-bugs] [Bug 50803] New: [SIMD] Compiler unable to vectorize trivial loops

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50803

Bug ID: 50803
   Summary: [SIMD] Compiler unable to vectorize trivial loops
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: WebAssembly
  Assignee: unassignedb...@nondot.org
  Reporter: cl...@evan.coeusgroup.com
CC: llvm-bugs@lists.llvm.org

Here is an example (or on Compiler Explorer: https://godbolt.org/z/5Was18P7r):


#include 

typedef int32_t i32x4 __attribute__((__vector_size__(16)));

i32x4 add(i32x4 a, i32x4 b);

i32x4
add(i32x4 a, i32x4 b) {
i32x4 r;

#pragma clang loop vectorize(enable)
for (int i = 0 ; i < 4 ; i++) {
r[i] = a[i] + b[i];
}

return r;
}


Compile with -msimd128 -O3, no vectorization.  The scalar version seems pretty
bad, too.

Even with the pragma the compiler won't vectorize the loop.  I'm wondering if
this might have something to do with the -Wconditional-uninitialized diagnostic
emitted when returning r (it's not enabled by default, -Weverything or
-Wconditional-uninitialized to see it).

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

[llvm-bugs] [Bug 50289] Backport 82150606fb11d28813ae6 into 12.0.1

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50289

Tom Stellard  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Fixed By Commit(s)|82150606fb11d28813ae6   |82150606fb11d28813ae6
   |414482751452e54710f16bae584 |414482751452e54710f16bae584
   |58c66298aaf69   |58c66298aaf69 cc08a27d2ecc
   ||385a6f37fefb
 Resolution|--- |FIXED

--- Comment #7 from Tom Stellard  ---
Merged: 385a6f37fefb

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

[llvm-bugs] [Bug 49317] [meta] 12.0.1 Release Blockers

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=49317
Bug 49317 depends on bug 50289, which changed state.

Bug 50289 Summary: Backport 82150606fb11d28813ae6 into 12.0.1
https://bugs.llvm.org/show_bug.cgi?id=50289

   What|Removed |Added

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

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

[llvm-bugs] [Bug 50804] New: Assertion failure with 'Operands with constraint "f" cannot overlap with defs'

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50804

Bug ID: 50804
   Summary: Assertion failure with 'Operands with constraint "f"
cannot overlap with defs'
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: LLVM Codegen
  Assignee: unassignedclangb...@nondot.org
  Reporter: i...@mgdl.fr
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk

Hello everyone, 
I was compiling Clang with LIBC using a version of Clang I had built before.
The compilation fails with an assertion failure in
`llvm/lib/Target/X86/X86FloatingPoint.cpp` and is caused by the compilation of
`llvm/libc/src/math/x86_64/tan.cpp` as well as for the sinus and cos functions.
Here's more detail

```
[509/6763] Building CXX object
projects/libc/src/math/x86_64/CMakeFiles/libc.src.math.x86_64.tan.dir/tan.cpp.o
FAILED:
projects/libc/src/math/x86_64/CMakeFiles/libc.src.math.x86_64.tan.dir/tan.cpp.o 
/usr/local/bin/clang++ -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Iprojects/libc/src/math/x86_64
-I/home/michel/sycl_workspace/llvm/libc/src/math/x86_64 -Iinclude
-I/home/michel/sycl_workspace/llvm/llvm/include -Iprojects/libc/include
-I/home/michel/sycl_workspace/llvm/libc -Iprojects/libc -fPIC
-fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
-Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor
-Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion
-Wmisleading-indentation -fdiagnostics-color -ffunction-sections
-fdata-sections -O2 -DNDEBUG -UNDEBUG -fpie -ffreestanding -march=native -O2
-DLLVM_LIBC_PUBLIC_PACKAGING -std=c++17 -MD -MT
projects/libc/src/math/x86_64/CMakeFiles/libc.src.math.x86_64.tan.dir/tan.cpp.o
-MF
projects/libc/src/math/x86_64/CMakeFiles/libc.src.math.x86_64.tan.dir/tan.cpp.o.d
-o
projects/libc/src/math/x86_64/CMakeFiles/libc.src.math.x86_64.tan.dir/tan.cpp.o
-c /home/michel/sycl_workspace/llvm/libc/src/math/x86_64/tan.cpp
clang++:
/home/michel/gitClones/llvm-project/llvm/lib/Target/X86/X86FloatingPoint.cpp:1602:
void (anonymous namespace)::FPS::handleSpecialFP(MachineBasicBlock::iterator
&): Assertion `(1 << getFPReg(MI.getOperand(I)) & STDefs) == 0 && "Operands
with constraint \"f\" cannot overlap with defs"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0.  Program arguments: /usr/local/bin/clang++ -D_DEBUG -D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-Iprojects/libc/src/math/x86_64
-I/home/michel/sycl_workspace/llvm/libc/src/math/x86_64 -Iinclude
-I/home/michel/sycl_workspace/llvm/llvm/include -Iprojects/libc/include
-I/home/michel/sycl_workspace/llvm/libc -Iprojects/libc -fPIC
-fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
-Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor
-Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion
-Wmisleading-indentation -fdiagnostics-color -ffunction-sections
-fdata-sections -O2 -DNDEBUG -UNDEBUG -fpie -ffreestanding -march=native -O2
-DLLVM_LIBC_PUBLIC_PACKAGING -std=c++17 -MD -MT
projects/libc/src/math/x86_64/CMakeFiles/libc.src.math.x86_64.tan.dir/tan.cpp.o
-MF
projects/libc/src/math/x86_64/CMakeFiles/libc.src.math.x86_64.tan.dir/tan.cpp.o.d
-o
projects/libc/src/math/x86_64/CMakeFiles/libc.src.math.x86_64.tan.dir/tan.cpp.o
-c /home/michel/sycl_workspace/llvm/libc/src/math/x86_64/tan.cpp
1.   parser at end of file
2.  Code generation
3.  Running pass 'Function Pass Manager' on module
'/home/michel/sycl_workspace/llvm/libc/src/math/x86_64/tan.cpp'.
4.  Running pass 'X86 FP Stackifier' on function '@tan'
 #0 0x029ad983 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/usr/local/bin/clang+++0x29ad983)
 #1 0x029abba0 llvm::sys::RunSignalHandlers()
(/usr/local/bin/clang+++0x29abba0)
 #2 0x029ad02d llvm::sys::CleanupOnSignal(unsigned long)
(/usr/local/bin/clang+++0x29ad02d)
 #3 0x0292f2e3 (anonymous
namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long)
CrashRecoveryContext.cpp:0:0
 #4 0x0292f468 CrashRecoverySignalHandler(int)
CrashRecoveryContext.cpp:0:0
 #5 0x7f7c4ee5fb20 __restore_rt sigaction.c:0:0
 #6 0x7f7c4db6d37f raise (/lib64/libc.so.6+0x3737f)
 #7 0x7f7c4db57db5 abo

[llvm-bugs] [Bug 50554] Merge r68d5235cb58f988c71b403334cd9482d663841ab into the 12.0 branch

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50554

Tom Stellard  changed:

   What|Removed |Added

 Fixed By Commit(s)|68d5235cb58f988c71b403334cd |68d5235cb58f988c71b403334cd
   |9482d663841ab   |9482d663841ab 884040db0869
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Tom Stellard  ---
Merged: 884040db0869

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

[llvm-bugs] [Bug 49317] [meta] 12.0.1 Release Blockers

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=49317
Bug 49317 depends on bug 50554, which changed state.

Bug 50554 Summary: Merge r68d5235cb58f988c71b403334cd9482d663841ab into the 
12.0 branch
https://bugs.llvm.org/show_bug.cgi?id=50554

   What|Removed |Added

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

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

[llvm-bugs] [Bug 49317] [meta] 12.0.1 Release Blockers

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=49317
Bug 49317 depends on bug 50734, which changed state.

Bug 50734 Summary: [libc++] Merge 52e9d80d5db20f23979e409f958736d130387f9e into 
12.0.1
https://bugs.llvm.org/show_bug.cgi?id=50734

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED

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

[llvm-bugs] [Bug 50734] [libc++] Merge 52e9d80d5db20f23979e409f958736d130387f9e into 12.0.1

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50734

Tom Stellard  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Fixed By Commit(s)|52e9d80d5db20f23979e409f958 |52e9d80d5db20f23979e409f958
   |736d130387f9e   |736d130387f9e 0680e2b5a118
 Status|CONFIRMED   |RESOLVED

--- Comment #2 from Tom Stellard  ---
Merged: 0680e2b5a118

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

[llvm-bugs] [Bug 50805] New: [SIMD] min / max patterns not recognized

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50805

Bug ID: 50805
   Summary: [SIMD] min / max patterns not recognized
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: WebAssembly
  Assignee: unassignedb...@nondot.org
  Reporter: cl...@evan.coeusgroup.com
CC: llvm-bugs@lists.llvm.org

Similar to #50793, but for min/max instead of pmin/pmax.  Probably less
important than pmin/pmax since most code doesn't bother checking for NaN, but
still nice to have.

If we add a quick check so the the code will return NaN if it is found, we end
up with the behavior of min/max instead of pmin/pmax.  Example
(https://godbolt.org/z/WEr9173h6):


#include 

#pragma clang diagnostic ignored "-Wmissing-prototypes"
#pragma clang diagnostic ignored "-Wvector-conversion"

typedef float f32x4 __attribute__((__vector_size__(16)));
typedef int32_t i32x4 __attribute__((__vector_size__(16)));
typedef double f64x2 __attribute__((__vector_size__(16)));
typedef int64_t i64x2 __attribute__((__vector_size__(16)));

f32x4
min32(f32x4 a, f32x4 b) {
i32x4 mask = (a != a) | (a < b);
return (f32x4) (
(((i32x4) a) &  mask) |
(((i32x4) b) & ~mask));
}

f64x2
min64(f64x2 a, f64x2 b) {
i64x2 mask = (a != a) | (a < b);
return (f64x2) (
(((i64x2) a) &  mask) |
(((i64x2) b) & ~mask));
}

f32x4
max32(f32x4 a, f32x4 b) {
i32x4 mask = (a != a) | (a > b);
return (f32x4) (
(((i32x4) a) &  mask) |
(((i32x4) b) & ~mask));
}

f64x2
max64(f64x2 a, f64x2 b) {
i64x2 mask = (a != a) | (a > b);
return (f64x2) (
(((i64x2) a) &  mask) |
(((i64x2) b) & ~mask));
}

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

[llvm-bugs] [Bug 50806] New: [SIMD] product of two extended halves of vectors should generate extmul_low/high

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50806

Bug ID: 50806
   Summary: [SIMD] product of two extended halves of vectors
should generate extmul_low/high
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: WebAssembly
  Assignee: unassignedb...@nondot.org
  Reporter: cl...@evan.coeusgroup.com
CC: llvm-bugs@lists.llvm.org

Here are some examples (or on Compiler Explorer:
https://godbolt.org/z/Ynnhz8srj):



#include 

#pragma clang diagnostic ignored "-Wmissing-prototypes"

typedef   int8_t i8x16 __attribute__((__vector_size__(16)));
typedef  int16_t i16x8 __attribute__((__vector_size__(16)));
typedef  int32_t i32x4 __attribute__((__vector_size__(16)));
typedef  int64_t i64x2 __attribute__((__vector_size__(16)));
typedef  uint8_t u8x16 __attribute__((__vector_size__(16)));
typedef uint16_t u16x8 __attribute__((__vector_size__(16)));
typedef uint32_t u32x4 __attribute__((__vector_size__(16)));
typedef uint64_t u64x2 __attribute__((__vector_size__(16)));

i16x8
i8x16_extmul_low(i8x16 a, i8x16 b) {
return
__builtin_convertvector(
__builtin_shufflevector(a, a, 0, 1, 2, 3, 4, 5, 6, 7),
__typeof__(int16_t __attribute__((__vector_size__(16
)
*
__builtin_convertvector(
__builtin_shufflevector(b, b, 0, 1, 2, 3, 4, 5, 6, 7),
__typeof__(int16_t __attribute__((__vector_size__(16
);
}

i32x4
i16x8_extmul_low(i16x8 a, i16x8 b) {
return
__builtin_convertvector(
__builtin_shufflevector(a, a, 0, 1, 2, 3),
__typeof__(int32_t __attribute__((__vector_size__(16
)
*
__builtin_convertvector(
__builtin_shufflevector(b, b, 0, 1, 2, 3),
__typeof__(int32_t __attribute__((__vector_size__(16
);
}

i64x2
i32x4_extmul_low(i32x4 a, i32x4 b) {
return
__builtin_convertvector(
__builtin_shufflevector(a, a, 0, 1),
__typeof__(int64_t __attribute__((__vector_size__(16
)
*
__builtin_convertvector(
__builtin_shufflevector(b, b, 0, 1),
__typeof__(int64_t __attribute__((__vector_size__(16
);
}

i16x8
i8x16_extmul_high(i8x16 a, i8x16 b) {
return
__builtin_convertvector(
__builtin_shufflevector(a, a, 8, 9, 10, 11, 12, 13, 14, 15),
__typeof__(int16_t __attribute__((__vector_size__(16
)
*
__builtin_convertvector(
__builtin_shufflevector(b, b, 8, 9, 10, 11, 12, 13, 14, 15),
__typeof__(int16_t __attribute__((__vector_size__(16
);
}

i32x4
i16x8_extmul_high(i16x8 a, i16x8 b) {
return
__builtin_convertvector(
__builtin_shufflevector(a, a, 4, 5, 6, 7),
__typeof__(int32_t __attribute__((__vector_size__(16
)
*
__builtin_convertvector(
__builtin_shufflevector(b, b, 4, 5, 6, 7),
__typeof__(int32_t __attribute__((__vector_size__(16
);
}

i64x2
i32x4_extmul_high(i32x4 a, i32x4 b) {
return
__builtin_convertvector(
__builtin_shufflevector(a, a, 2, 3),
__typeof__(int64_t __attribute__((__vector_size__(16
)
*
__builtin_convertvector(
__builtin_shufflevector(b, b, 2, 3),
__typeof__(int64_t __attribute__((__vector_size__(16
);
}

u16x8
u8x16_extmul_low(u8x16 a, u8x16 b) {
return
__builtin_convertvector(
__builtin_shufflevector(a, a, 0, 1, 2, 3, 4, 5, 6, 7),
__typeof__(uint16_t __attribute__((__vector_size__(16
)
*
__builtin_convertvector(
__builtin_shufflevector(b, b, 0, 1, 2, 3, 4, 5, 6, 7),
__typeof__(uint16_t __attribute__((__vector_size__(16
);
}

u32x4
u16x8_extmul_low(u16x8 a, u16x8 b) {
return
__builtin_convertvector(
__builtin_shufflevector(a, a, 0, 1, 2, 3),
__typeof__(uint32_t __attribute__((__vector_size__(16
)
*
__builtin_convertvector(
__builtin_shufflevector(b, b, 0, 1, 2, 3),
__typeof__(uint32_t __attribute__((__vector_size__(16
);
}

u64x2
u32x4_extmul_low(u32x4 a, u32x4 b) {
return
__builtin_convertvector(
__builtin_shufflevector(a, a, 0, 1),
__typeof__(uint64_t __attribute__((__vector_size__(16
)
*
__builtin_convertvector(
__builtin_shufflevector(b, b, 0, 1),
__typeof__(uint64_t __attribute__((__vector_size__(16
);
}

u16x8
u8x16_extmul_high(u8x16 a, u8x16 b) {
return
__builtin_convertvector(
__builtin_shufflevecto

[llvm-bugs] [Bug 50807] New: [SIMD] __builtin_shufflevector to 64-bit vector then extending not vectorized

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50807

Bug ID: 50807
   Summary: [SIMD] __builtin_shufflevector to 64-bit vector then
extending not vectorized
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: WebAssembly
  Assignee: unassignedb...@nondot.org
  Reporter: cl...@evan.coeusgroup.com
CC: llvm-bugs@lists.llvm.org

With -msimd128 -O3, I would expect a __builtin_shufflevector which returns half
the elements plus a __builtin_convertvector to extend each element (resulting
in a 128-bit vector) to generate a v128.shuffle and an extend_low.  Instead, it
generates a bunch of extract_lane and replace_lane instructions.

Here are a couple of quick examples (Compiler Explorer:
https://godbolt.org/z/EjbMqPhx1):


#include 

#pragma clang diagnostic ignored "-Wmissing-prototypes"

typedef   int8_t i8x16 __attribute__((__vector_size__(16)));
typedef  int16_t i16x8 __attribute__((__vector_size__(16)));
typedef  int32_t i32x4 __attribute__((__vector_size__(16)));
typedef  uint8_t u8x16 __attribute__((__vector_size__(16)));
typedef uint16_t u16x8 __attribute__((__vector_size__(16)));
typedef uint32_t u32x4 __attribute__((__vector_size__(16)));

i16x8
foo(i8x16 a) {
return __builtin_convertvector(
__builtin_shufflevector(a, a,
0, 2, 4, 6, 8, 10, 12, 14
),
i16x8
);
}

v128_t
foo_intrin(v128_t a) {
return
wasm_i16x8_extend_low_i8x16(
wasm_i8x16_shuffle(a, a,
0, 2, 4, 6, 8, 10, 12, 14,
1, 3, 5, 7, 9, 11, 13, 15)
);
}

i16x8
bar(i8x16 a) {
return
__builtin_convertvector(
__builtin_shufflevector(
a, a,
0, 2, 4, 6, 8, 10, 12, 14
),
i16x8
)
-
__builtin_convertvector(
__builtin_shufflevector(
a, a,
1, 3, 5, 7, 9, 11, 13, 15
),
i16x8
);
}

i16x8
bar_intrin(v128_t a) {
v128_t shuffled = wasm_i8x16_shuffle(
a, a,
0, 2, 4, 6, 8, 10, 12, 14,
1, 3, 5, 7, 9, 11, 13, 15
);
return
wasm_i16x8_extend_low_i8x16(shuffled) -
wasm_i16x8_extend_high_i8x16(shuffled);
}



I think it's pretty reasonable to expect that foo and foo_intrin should
generate roughly the same code (the upper half of the shuffle doesn't matter,
so maybe all zeros or something).

I'd be very impressed, OTOH, if bar and bar_intrin generated the same code. 
I'm not sure how feasible that is, though.

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

[llvm-bugs] [Bug 50808] New: [SIMD] shuffle even/odd, extend, add should generate extadd_pairwise

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50808

Bug ID: 50808
   Summary: [SIMD] shuffle even/odd, extend, add should generate
extadd_pairwise
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: WebAssembly
  Assignee: unassignedb...@nondot.org
  Reporter: cl...@evan.coeusgroup.com
CC: llvm-bugs@lists.llvm.org

With -msimd128, shuffling to extract even and odd elements, then extending
those and adding the result should result in one of the extadd_pairwise
instructions (assuming 8 or 16 bit inputs).  It doesn't.

Right now they result in some rather atrocious code, but I filed that as
#50807.  This issue is about generating an extadd_pairwise instruction.

Example (Compiler Explorer: https://godbolt.org/z/94n6sooTs):



#include 

#pragma clang diagnostic ignored "-Wmissing-prototypes"

typedef   int8_t i8x16 __attribute__((__vector_size__(16)));
typedef  int16_t i16x8 __attribute__((__vector_size__(16)));
typedef  int32_t i32x4 __attribute__((__vector_size__(16)));
typedef  uint8_t u8x16 __attribute__((__vector_size__(16)));
typedef uint16_t u16x8 __attribute__((__vector_size__(16)));
typedef uint32_t u32x4 __attribute__((__vector_size__(16)));

i16x8
i8x16_extadd_pairwise(i8x16 a) {
return (i16x8) {
  __builtin_convertvector(__builtin_shufflevector(a, a, 0, 2, 4, 6, 8, 10,
12, 14), i16x8) +
  __builtin_convertvector(__builtin_shufflevector(a, a, 1, 3, 5, 7, 9, 11,
13, 15), i16x8)  
};
}

i32x4
i16x8_extadd_pairwise(i16x8 a) {
return (i32x4) {
  __builtin_convertvector(__builtin_shufflevector(a, a, 0, 2, 4, 6), i32x4)
+
  __builtin_convertvector(__builtin_shufflevector(a, a, 1, 3, 5, 7), i32x4) 
};
}

u16x8
u8x16_extadd_pairwise(i8x16 a) {
return (u16x8) {
  __builtin_convertvector(__builtin_shufflevector(a, a, 0, 2, 4, 6, 8, 10,
12, 14), u16x8) +
  __builtin_convertvector(__builtin_shufflevector(a, a, 1, 3, 5, 7, 9, 11,
13, 15), u16x8)  
};
}

u32x4
u16x8_extadd_pairwise(i16x8 a) {
return (u32x4) {
  __builtin_convertvector(__builtin_shufflevector(a, a, 0, 2, 4, 6), u32x4)
+
  __builtin_convertvector(__builtin_shufflevector(a, a, 1, 3, 5, 7), u32x4) 
};
}

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

[llvm-bugs] [Bug 50809] New: clang-format does not indent the body of an else-comment-if correctly

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50809

Bug ID: 50809
   Summary: clang-format does not indent the body of an
else-comment-if correctly
   Product: clang
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Formatter
  Assignee: unassignedclangb...@nondot.org
  Reporter: owenpi...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org

If there is a comment between "else" and "if", the "if" statement and its body
are indented incorrectly. See the example in LLVM style below.

Input:
if (foo)
  f();
else // comment
  if (bar) {
g();
h();
  }

Output:
if (foo)
  f();
else // comment
if (bar) {
  g();
  h();
}

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

[llvm-bugs] [Bug 50810] New: [SIMD] pattern for i32x4.dot_i16x8_s not recognized

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50810

Bug ID: 50810
   Summary: [SIMD] pattern for i32x4.dot_i16x8_s not recognized
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: WebAssembly
  Assignee: unassignedb...@nondot.org
  Reporter: cl...@evan.coeusgroup.com
CC: llvm-bugs@lists.llvm.org

With -msimd128 -O3, the compiler wont't recognize the following snippet as an
i32x4.dot_i16x8_s.

It also scalarizes a lot of stuff; the WASM backend seems to have a lot of
trouble with non-128-bit vectors.  Even if this wasn't recognized as a dot
product, I'd hope to see some extmuls (or at least i16x8.extend_low/high and
i32x4.mul) and shuffles for this.  I can file another bug for that if you want.

Anyways, here is the example (Compiler Explorer:
https://godbolt.org/z/an4jKTnf5):



#include 

typedef  int16_t i16x8 __attribute__((__vector_size__(16)));
typedef  int32_t i32x4 __attribute__((__vector_size__(16)));

i32x4
dot(i16x8 a, i16x8 b) {
int32_t prod __attribute__((__vector_size__(32))) =
__builtin_convertvector(a, __typeof__(prod)) *
__builtin_convertvector(b, __typeof__(prod)); 
return
__builtin_shufflevector(prod, prod, 0, 2, 4, 6) +
__builtin_shufflevector(prod, prod, 1, 3, 5, 7);
}

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

[llvm-bugs] [Bug 32377] __STDC_NO_THREADS__ undefined with glibc

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=32377

Evan Nemerson  changed:

   What|Removed |Added

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

--- Comment #2 from Evan Nemerson  ---
This has been fixed for quite a while;
https://reviews.llvm.org/rG5c086c7626fab2617c0178a3951378bcbce2271c

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

[llvm-bugs] [Bug 36626] unable to execute command: Segmentation fault (core dumped) (llvm::MachineBasicBlock::addPredecessor)

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36626

Nick Desaulniers  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ndesaulni...@google.com
 Resolution|--- |WORKSFORME

--- Comment #1 from Nick Desaulniers  ---
Sorry, I was unable to reproduce the issue as reported. Please reopen with
further steps to reproduce if this is still an issue for you.

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

[llvm-bugs] [Bug 50757] Cherry-pick 097d77d611d1e1b3972be661fdc3caaa4d1824b4 to release/12.x

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50757

Tom Stellard  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Fixed By Commit(s)|097d77d611d1e1b3972be661fdc |097d77d611d1e1b3972be661fdc
   |3caaa4d1824b4   |3caaa4d1824b4 5cb420073975
 Status|NEW |RESOLVED

--- Comment #1 from Tom Stellard  ---
Merged: 5cb420073975

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

[llvm-bugs] [Bug 50758] Cherry-pick 76fc35752d19ac605c1c1fd757af9c7c3bb4a906 to release/12.x

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50758

Tom Stellard  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 Fixed By Commit(s)|76fc35752d19ac605c1c1fd757a |76fc35752d19ac605c1c1fd757a
   |f9c7c3bb4a906   |f9c7c3bb4a906 fa21c5d4cf8c

--- Comment #1 from Tom Stellard  ---
Merged: fa21c5d4cf8c

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

[llvm-bugs] [Bug 49317] [meta] 12.0.1 Release Blockers

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=49317
Bug 49317 depends on bug 50757, which changed state.

Bug 50757 Summary: Cherry-pick 097d77d611d1e1b3972be661fdc3caaa4d1824b4 to 
release/12.x
https://bugs.llvm.org/show_bug.cgi?id=50757

   What|Removed |Added

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

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

[llvm-bugs] [Bug 49317] [meta] 12.0.1 Release Blockers

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=49317
Bug 49317 depends on bug 50758, which changed state.

Bug 50758 Summary: Cherry-pick 76fc35752d19ac605c1c1fd757af9c7c3bb4a906 to 
release/12.x
https://bugs.llvm.org/show_bug.cgi?id=50758

   What|Removed |Added

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

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

[llvm-bugs] Issue 35496 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-gisel: ASSERT: EC.isVector() && "invalid number of vector elements"

[ClusterFuzz-External via monorail via llvm-bugs]

Status: New
Owner: 
CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, 
d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, 
llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, 
mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com 
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible 
Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-06-23
Type: Bug

New issue 35496 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--aarch64-gisel: 
ASSERT: EC.isVector() && "invalid number of vector elements"
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35496

Detailed Report: https://oss-fuzz.com/testcase?key=5747816600305664

Project: llvm
Fuzzing Engine: libFuzzer
Fuzz Target: llvm-isel-fuzzer--aarch64-gisel
Job Type: libfuzzer_asan_llvm
Platform Id: linux

Crash Type: ASSERT
Crash Address: 
Crash State:
  EC.isVector() && "invalid number of vector elements"
  llvm::LLT::init
  llvm::LLT::vector
  
Sanitizer: address (ASAN)

Regressed: 
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202106210617:202106220622

Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5747816600305664

Issue filed automatically.

See https://google.github.io/oss-fuzz/advanced-topics/reproducing for 
instructions to reproduce this bug locally.
When you fix this bug, please
  * mention the fix revision(s).
  * state whether the bug was a short-lived regression or an old bug in any 
stable releases.
  * add any other useful information.
This information can help downstream consumers.

If you need to contact the OSS-Fuzz team with a question, concern, or any other 
feedback, please file an issue at https://github.com/google/oss-fuzz/issues. 
Comments on individual Monorail issues are not monitored.

-- 
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 50811] New: [alias] Missing optimization for __restrict

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50811

Bug ID: 50811
   Summary: [alias] Missing optimization for __restrict
   Product: libraries
   Version: 11.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Global Analyses
  Assignee: unassignedb...@nondot.org
  Reporter: zhongyu...@tom.com
CC: llvm-bugs@lists.llvm.org

base on https://gcc.godbolt.org/, I test the following simple case with newest
x86-64 clang 12.0.0， foo don't return false directly even with -O3 option.

int foo (int * __restrict a, int * __restrict b)
{
  return a==b;
}


 x86-64 clang 12.0.0 -O3 -S  -g0 

foo(int*, int*): # @foo(int*, int*)
.cfi_startproc
xor eax, eax
cmp rdi, rsi
seteal
ret

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

[llvm-bugs] [Bug 50812] New: "Invalid symbol type" while parsing a valid framework archive

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50812

Bug ID: 50812
   Summary: "Invalid symbol type" while parsing a valid framework
archive
   Product: lld
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: MachO
  Assignee: unassignedb...@nondot.org
  Reporter: v...@google.com
CC: g...@fb.com, jezr...@gmail.com,
llvm-bugs@lists.llvm.org, smee...@fb.com

Repro:
ld64.lld.darwinnew  -arch x86_64 -force_load Cronet 

This isn't expected to succeed, in fact, it should complain about a bunch of
undef symbols, but this is the easiest way to real the problem.

This would result in a crash "Invalid symbol type" on line[0] - the value of
`type` is 4.

I haven't done a lot of digging, but from a bit of initial inspection, it
seemed 111704 symbols (out of 340463) from this archive were seen to have this
invalid type. All of them are actually local symbols (ie., denoted with 't' by
llvm-nm)



-

`Cronet` is produced from this package[1], which I'm attaching here for
convenience. You could also rebuild it yourself.

[0]
https://github.com/llvm/llvm-project/blob/e8c8ce0974edca7bc21ce53826ff7b2c0456d70a/lld/MachO/InputFiles.cpp#L570
[1]
https://chromium.googlesource.com/chromium/src/+/refs/heads/main/components/cronet/ios/BUILD.gn

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

[llvm-bugs] [Bug 50765] [LSR] Zero factor leads to division by zero/assertion failure

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50765

Max Kazantsev  changed:

   What|Removed |Added

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

--- Comment #9 from Max Kazantsev  ---
commit b7d2c173ebbbd48342d498ebc8a1127dbc6d87b1 (HEAD -> main, origin/main)
Author: Max Kazantsev 
Date:   Wed Jun 23 10:43:06 2021 +0700

[LSR] Filter out zero factors. PR50765

Zero factor leads to division by zero and failure of corresponding
assert as shown in PR50765. We should filter out such factors.

Differential Revision: https://reviews.llvm.org/D104702
Reviewed By: huihuiz, reames

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

[llvm-bugs] [Bug 50813] New: [RISCV] wrong vector register alloc in vector instruction

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50813

Bug ID: 50813
   Summary: [RISCV] wrong vector register alloc  in vector
instruction
   Product: new-bugs
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: tangxingxin1...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org

There is a wrong vector instruction will be produced: 
   vrgather.vv  v25, v25, v25
in the below test case.
>From the the vector spec, there is a rule: for any vrgather instruction, the
destination vector register group cannot overlap the source vector register
group. 

vrgather-test.ll:

declare  @llvm.riscv.vrgather.vv.nxv8i8.i64(
  ,
  ,
  i64);

define dso_local signext i32 @intrinsic_vrgather_vv_nxv8i8_nxv8i8_nxv8i8()
nounwind {
entry:
  %0 = alloca , align 8
  %1 = call  @llvm.riscv.vrgather.vv.nxv8i8.i64(
 undef,
 undef,
i64 undef)
  store volatile  %1, * %0, align 8

  ret i32 0
}


llc -mtriple=riscv64 -mattr=+experimental-v,+d,+experimental-zfh
-verify-machineinstrs vrgather-test.ll -o vrgather-test.s

vrgather-test.s:
.text
.attribute  4, 16
.attribute  5, "rv64i2p0_f2p0_d2p0_v0p10_zfh0p1"
.file   "vrgather-test.ll"
.globl  intrinsic_vrgather_vv_nxv8i8_nxv8i8_nxv8i8 # -- Begin function
intrinsic_vrgather_vv_nxv8i8_nxv8i8_nxv8i8
.p2align2
.type   intrinsic_vrgather_vv_nxv8i8_nxv8i8_nxv8i8,@function
intrinsic_vrgather_vv_nxv8i8_nxv8i8_nxv8i8: #
@intrinsic_vrgather_vv_nxv8i8_nxv8i8_nxv8i8
# %bb.0:# %entry
addisp, sp, -16
csrra0, vlenb
sub sp, sp, a0
vsetvli zero, a0, e8,m1,ta,mu
vrgather.vv v25, v25, v25
addia0, sp, 16
vs1r.v  v25, (a0)
mv  a0, zero
csrra1, vlenb
add sp, sp, a1
addisp, sp, 16
ret
.Lfunc_end0:
.size   intrinsic_vrgather_vv_nxv8i8_nxv8i8_nxv8i8,
.Lfunc_end0-intrinsic_vrgather_vv_nxv8i8_nxv8i8_nxv8i8
# -- End function
.section".note.GNU-stack","",@progbits

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