[llvm-bugs] Issue 5020 in oss-fuzz: llvm/clang-fuzzer: ASSERT: width && "Can't truncate to 0 bits"

[ClusterFuzz-External via monorail via llvm-bugs]

Status: New
Owner: 
CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com,  
igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com,  
mitchphi...@outlook.com, akils...@apple.com
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible  
Engine-libfuzzer Proj-llvm Reported-2018-01-08

Type: Bug

New issue 5020 by ClusterFuzz-External: llvm/clang-fuzzer: ASSERT: width  
&& "Can't truncate to 0 bits"

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5020

Detailed report: https://oss-fuzz.com/testcase?key=4656722267340800

Project: llvm
Fuzzer: libFuzzer_llvm_clang-fuzzer
Fuzz target binary: clang-fuzzer
Job Type: libfuzzer_asan_llvm
Platform Id: linux

Crash Type: ASSERT
Crash Address:
Crash State:
  width && "Can't truncate to 0 bits"
  llvm::APInt::trunc
  AnalyzeBitFieldAssignment

Sanitizer: address (ASAN)

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201712090607:201712100011


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


Issue filed automatically.

See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for  
more information.


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 have questions for the OSS-Fuzz team, please file an issue at  
https://github.com/google/oss-fuzz/issues.


--
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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 35853] New: Clang 4.0 still uses C++98 by default

[via llvm-bugs]

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

Bug ID: 35853
   Summary: Clang 4.0 still uses C++98 by default
   Product: clang
   Version: 4.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: C++
  Assignee: unassignedclangb...@nondot.org
  Reporter: noloa...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org

Well, this was a surprising result. I noticed it while troubleshooting an issue
where a lambda was not invoked. The lambda was guarded with a macro because the
code is both C++03 and C++11.

Testing on Fedora 27 with LLVM's Clang 4.0:

$ clang++ -x c++ -dM -E - < /dev/null | egrep '(clang|__cplusplus)'
#define __clang__ 1
#define __clang_major__ 4
#define __clang_minor__ 0
#define __clang_patchlevel__ 1
#define __clang_version__ "4.0.1 (tags/RELEASE_401/final)"
#define __cplusplus 199711L

Maybe it would be prudent to change to C++03 or C++11 by default in 2018.

-- 
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 35851] New: [X86] Missing entries from load folding tables

[via llvm-bugs]

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

Bug ID: 35851
   Summary: [X86] Missing entries from load folding tables
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: craig.top...@gmail.com
CC: llvm-bugs@lists.llvm.org

Created attachment 19642
  --> https://bugs.llvm.org/attachment.cgi?id=19642=edit
Stripped version of the auto generated load folding table

Attached to this bug is somewhat audited list of the currently missing load
folding table entries.

I believe I've removed the entries that are already implemented and some that
looked suspect or dealt with system instructions we never generate.

-- 
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 35849] strtoll undefined

[via llvm-bugs]

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

Gábor Bérczi  changed:

   What|Removed |Added

 Resolution|WONTFIX |---
 Status|RESOLVED|REOPENED

--- Comment #2 from Gábor Bérczi  ---
Thanks, but that does not do anything, in fact stdlib.h is not even getting
looked at according to ktrace.

-- 
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 35849] strtoll undefined

[via llvm-bugs]

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

Dimitry Andric  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX
 CC||dimi...@andric.com

--- Comment #1 from Dimitry Andric  ---
First, please note that FreeBSD 8.4 is end-of-life, and unsupported.  Same for
LLVM 3.5.0.

That said, https://svnweb.freebsd.org/base?view=revision=297212, which
exposes a number of long long types and functions (among which strtoll), has
never been merged to stable/8.  So indeed, under C++ mode, there is no strtoll
in stdlib.h.

As a workaround, you can manually merge this into your stdlib.h:

--- head/include/stdlib.h   2016/03/23 18:21:26 297211
+++ head/include/stdlib.h   2016/03/23 19:17:12 297212
@@ -125,7 +125,7 @@
  *
  * (The only other extension made by C99 in thie header is _Exit().)
  */
-#if __ISO_C_VISIBLE >= 1999
+#if __ISO_C_VISIBLE >= 1999 || defined(__cplusplus)
 #ifdef __LONG_LONG_SUPPORTED
 /* LONGLONG */
 typedef struct {

Note that CMake is able to find strtoll, because it compiles a small C test
program, and for C strtoll is defined.

In any case, this will not be fixed anymore, either in FreeBSD or LLVM.

-- 
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 34620] redundant pand after vector shift of a byte vector (psrlw)

[via llvm-bugs]

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

Simon Pilgrim  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 Fixed By Commit(s)||321969

--- Comment #3 from Simon Pilgrim  ---
Committed at rL321969 on behalf of Sam

-- 
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 35849] New: strtoll undefined

[via llvm-bugs]

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

Bug ID: 35849
   Summary: strtoll undefined
   Product: new-bugs
   Version: 3.5
  Hardware: PC
OS: FreeBSD
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: m...@gabucino.hu
CC: llvm-bugs@lists.llvm.org

Somebody riddle me this: ever since 3.5.0 llvm+cfe doesn't build on FreeBSD
8.4. Due to this:

[  5%] Building CXX object
lib/TableGen/CMakeFiles/LLVMTableGen.dir/TGLexer.cpp.o
/data/nfs/tgp/src/llvm-3.5.0.src/lib/TableGen/TGLexer.cpp: In member function
'llvm::tgtok::TokKin
/data/nfs/tgp/src/llvm-3.5.0.src/lib/TableGen/TGLexer.cpp:392:19: error:
'strtoll' was not declare
  CurIntVal = strtoll(NumStart, nullptr, 16);
  ^~~

But earlier in the output there's this:

-- Looking for strtoll
-- Looking for strtoll - found

So what gives? I've tried all GCC from 4 to 7.2.0.

LLVM+CFE 3.4.2 builds OK.

-- 
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 24441] missing cse for smin/smax

[via llvm-bugs]

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

Sanjay Patel  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 Fixed By Commit(s)||320460

--- Comment #5 from Sanjay Patel  ---
https://reviews.llvm.org/rL320640

-- 
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 35848] New: Merge r321964 into the 6.0 branch: Correct types of pointers to doacross_num_done

[via llvm-bugs]

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

Bug ID: 35848
   Summary: Merge r321964 into the 6.0 branch: Correct types of
pointers to doacross_num_done
   Product: OpenMP
   Version: unspecified
  Hardware: PC
OS: Linux
Status: ASSIGNED
  Severity: release blocker
  Priority: P
 Component: Runtime Library
  Assignee: andrey.churba...@intel.com
  Reporter: hah...@hahnjo.de
CC: h...@chromium.org, llvm-bugs@lists.llvm.org

This field is defined as kmp_int32, so we should use neither
pointers to kmp_int64 nor 64 bit atomic instructions.
(Found while testing on a Raspberry Pi, 32 bit ARM)

Andrey, Hans, is this ok to merge?

-- 
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 32035] pushf/popf default to wrong operand size in 64-bit with Intel syntax

[via llvm-bugs]

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

Simon Pilgrim  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   See Also||https://bugs.llvm.org/show_
   ||bug.cgi?id=35847
 Resolution|--- |FIXED

--- Comment #7 from Simon Pilgrim  ---
Resolving original bug.

(In reply to Coby Tayree from comment #5)
> (In reply to Vicente Bergas from comment #3)
> 
> This one seems as independent issue.
> Both clang & GCC will fall if the call to printf is omitted.
> assembly difference lays in GCC's epilogue code for the encapsulating
> function - it uses the 'leave' instruction and bypassing the stack's
> dis-alignment.

Split this off to Bug #35847

-- 
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 10988] x86 MC encoder and disassembler bugs umbrella

[via llvm-bugs]

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

Bug 32035 Summary: pushf/popf default to wrong operand size in 64-bit with 
Intel syntax
https://bugs.llvm.org/show_bug.cgi?id=32035

   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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 35847] New: pushf/popw out of sync stack

[via llvm-bugs]

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

Bug ID: 35847
   Summary: pushf/popw out of sync stack
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: llvm-...@redking.me.uk
CC: coby.tay...@intel.com, llvm-bugs@lists.llvm.org,
mku...@google.com, r...@google.com, vice...@gmail.com

Split from Bug #32035 Comment #3

> (In reply to Vicente Bergas from comment #3)
> Hello,
> this code:
> 
> #include 
> #include 
> int main() {
>   uint16_t u16;
>   asm(
> "pushf\n"
> "popw %0\n"
> : "=r" (u16)
>   );
>   printf("0x%04hX\n", u16);
>   return(0);
> }
> 
> when assembled with clang -S generates
> ...
> pushfq
> popw %ax
> ...
> and the stack size gets out of sync.
> When executing the resulting program it segfaults.
> Tested also in GCC: works fine there.

-- 
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 34492] [meta] 5.0.1 Release Blockers

[via llvm-bugs]

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

Bug 35346 Summary: Merge r312742 into the 5.0 branch : [OpenCL] Add half load 
and store builtins
https://bugs.llvm.org/show_bug.cgi?id=35346

   What|Removed |Added

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

-- 
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 35346] Merge r312742 into the 5.0 branch : [OpenCL] Add half load and store builtins

[via llvm-bugs]

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

Simon Pilgrim  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX
 CC||llvm-...@redking.me.uk

--- Comment #4 from Simon Pilgrim  ---
Dropping request

-- 
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 35846] New: [InstCombine] Compare known true or false was not folded

[via llvm-bugs]

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

Bug ID: 35846
   Summary: [InstCombine] Compare known true or false was not
folded
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Common Code Generator Code
  Assignee: unassignedb...@nondot.org
  Reporter: llvm-...@redking.me.uk
CC: craig.top...@gmail.com, david.majne...@gmail.com,
dav...@freebsd.org, djas...@google.com,
llvm-bugs@lists.llvm.org, spatel+l...@rotateright.com

Reduced from https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4718

opt -instcombine

define i32 @bar4(i32 %a, i32 %b) {
  %and1 = and i32 %b, 3
  %B1 = ashr i32 %and1, %and1
  %B3 = shl i32 %and1, %B1
  %cmp = icmp eq i32 %B3, 1
  tail call void @llvm.assume(i1 %cmp)
  %cmp2 = icmp eq i32 %B1, %B3
  tail call void @llvm.assume(i1 %cmp2)
  ret i32 %and1
}
declare void @llvm.assume(i1)

Assertion failed: C.ashr(*ShiftAmt).shl(*ShiftAmt) == C && "Compare known true
or false was not folded", file
C:\LLVM\llvm\lib\Transforms\InstCombine\InstCombineCompares.cpp, line 1900

-- 
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] Issue 5011 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: Use-after-poison in DAGCombiner::useDivRem

[ClusterFuzz-External via monorail via llvm-bugs]

Status: New
Owner: 
CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com,  
igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com,  
mitchphi...@outlook.com, akils...@apple.com
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible  
Engine-libfuzzer Proj-llvm Reported-2018-01-07

Type: Bug-Security

New issue 5011 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--x86_64-O2:  
Use-after-poison in DAGCombiner::useDivRem

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5011

Detailed report: https://oss-fuzz.com/testcase?key=6607743608684544

Project: llvm
Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--x86_64-O2
Fuzz target binary: llvm-isel-fuzzer--x86_64-O2
Job Type: libfuzzer_asan_llvm
Platform Id: linux

Crash Type: Use-after-poison READ 8
Crash Address: 0x62127040
Crash State:
  DAGCombiner::useDivRem
  DAGCombiner::visit
  DAGCombiner::combine

Sanitizer: address (ASAN)

Recommended Security Severity: High

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201710160455:201710190451


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


Issue filed automatically.

See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for  
more information.


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 have questions for the OSS-Fuzz team, please file an issue at  
https://github.com/google/oss-fuzz/issues.


--
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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs