[llvm-bugs] [Bug 36315] New: DFSan incorrectly transfers param attributes for variadic custom "__dfsw_*" handlers

[via llvm-bugs]

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

Bug ID: 36315
   Summary: DFSan incorrectly transfers param attributes for
variadic custom "__dfsw_*" handlers
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Miscellaneous Instrumentation passes
  Assignee: unassignedb...@nondot.org
  Reporter: sbu...@google.com
CC: llvm-bugs@lists.llvm.org

For variadic function calls that are uninstrumented and provided with a custom
"__dfsw_*" handler, the DFSan pass transfers the param attributes from the old
call to the new call, but it does not offset the indices of the extra
arguments, which come after the shadow arguments in the new call. This causes
attributes like "nonnull" to be attached to shadow arguments, which aren't
pointers, and hence should never be marked as "nonnull".

Example for a snprintf custom wrapper:

Before instrumentation:   %X = call i32 (i8*, i64, i8*, ...) @snprintf(i8*
nonnull %30, i64 200, i8* getelementptr inbounds ([19 x i8], [19 x i8]*
@.str.94.1284, i64 0, i64 0), i64 %32, i8* %29, i8* nonnull %34) #1

After instrumentation: %Y = call i32 (i8*, i64, i8*, i16, i16, i16, i16*, i16*,
...) @__dfsw_snprintf(i8* nonnull %98, i64 200, i8* getelementptr inbounds ([19
x i8], [19 x i8]* @.str.94.1284, i64 0, i64 0), i16 zeroext 0, i16 zeroext 0,
i16 nonnull zeroext 0, i16* %130, i16* %labelreturn, i64 %118, i8* %97, i8*
%126)

Note that the "nonnull" attribute stays in the same position, although it
should have been shifted to the end of the argument list.

-- 
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 36314] New: DFSan wrapper function sometimes gets wrong 'dso_local' attribute

[via llvm-bugs]

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

Bug ID: 36314
   Summary: DFSan wrapper function sometimes gets wrong
'dso_local' attribute
   Product: libraries
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Miscellaneous Instrumentation passes
  Assignee: unassignedb...@nondot.org
  Reporter: sbu...@google.com
CC: llvm-bugs@lists.llvm.org

The "dfsw$" wrapper functions in DFSan are created using the
'GlobalValue::LinkOnceODRLinkage' linkage and inherit the attributes of the
original function by calling "NewF->copyAttributesFrom(F);".

However, when the original function (F) has internal linkage, it automatically
gets the 'dso_local' attribute via its GlobalValue constructor. This attribute
is thus inadvertently transferred to the wrapper (NewF), which has a public
linkage type and should not be marked 'dso_local'.

On x86_64, this behavior causes the wrapper symbol in the generated code to
have 
a relocation table entry (R_X86_64_PC32) that triggers a linker error when
linking in a shared library.

-- 
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 35804] [meta] 6.0.0 Release Blockers

[via llvm-bugs]

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

Bug 35996 Summary: asan_rt_conflict_test-1 segfaults
https://bugs.llvm.org/show_bug.cgi?id=35996

   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 35996] asan_rt_conflict_test-1 segfaults

[via llvm-bugs]

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

Diana Picus  changed:

   What|Removed |Added

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

--- Comment #10 from Diana Picus  ---
Seems to be gone now, thanks!

-- 
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 36313] New: [AArch64] Incorrect RETURN_ADDRESS in tests

[via llvm-bugs]

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

Bug ID: 36313
   Summary: [AArch64] Incorrect RETURN_ADDRESS in tests
   Product: OpenMP
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Runtime Library
  Assignee: unassignedb...@nondot.org
  Reporter: diana.pi...@linaro.org
CC: llvm-bugs@lists.llvm.org

Created attachment 19846
  --> https://bugs.llvm.org/attachment.cgi?id=19846=edit
Full failure report

I'm getting these failures on AArch64 in 6.0.0-rc2:

Failing Tests (6):
libomp :: ompt/misc/control_tool.c
libomp :: ompt/synchronization/flush.c
libomp :: ompt/synchronization/master.c
libomp :: ompt/synchronization/taskwait.c
libomp :: ompt/synchronization/test_lock.c
libomp :: ompt/synchronization/test_nest_lock_parallel.c

They all look something like this:
 TEST 'libomp ::
ompt/synchronization/test_nest_lock_parallel.c' FAILED 
Script:
--
/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/Phase3/Release/llvmCore-6.0.0-rc2.obj/./bin/clang
-fopenmp  -I
/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/llvm.src/projects/openmp/runtime/test
-I
/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/Phase3/Release/llvmCore-6.0.0-rc2.obj/projects/openmp/runtime/src
-L
/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/Phase3/Release/llvmCore-6.0.0-rc2.obj/lib
 -I
/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/llvm.src/projects/openmp/runtime/test/ompt
/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/llvm.src/projects/openmp/runtime/test/ompt/synchronization/test_nest_lock_parallel.c
-o
/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/Phase3/Release/llvmCore-6.0.0-rc2.obj/projects/openmp/runtime/test/ompt/synchronization/Output/test_nest_lock_parallel.c.tmp
-lm -latomic &&
/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/Phase3/Release/llvmCore-6.0.0-rc2.obj/projects/openmp/runtime/test/ompt/synchronization/Output/test_nest_lock_parallel.c.tmp
| sort --numeric-sort --stable |
/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/Phase3/Release/llvmCore-6.0.0-rc2.obj/./bin/FileCheck
/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/llvm.src/projects/openmp/runtime/test/ompt/synchronization/test_nest_lock_parallel.c
--
Exit Code: 1

Command Output (stdout):
--
$
"/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/Phase3/Release/llvmCore-6.0.0-rc2.obj/./bin/clang"
"-fopenmp" "-I"
"/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/llvm.src/projects/openmp/runtime/test"
"-I"
"/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/Phase3/Release/llvmCore-6.0.0-rc2.obj/projects/openmp/runtime/src"
"-L"
"/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/Phase3/Release/llvmCore-6.0.0-rc2.obj/lib"
"-I"
"/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/llvm.src/projects/openmp/runtime/test/ompt"
"/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/llvm.src/projects/openmp/runtime/test/ompt/synchronization/test_nest_lock_parallel.c"
"-o"
"/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/Phase3/Release/llvmCore-6.0.0-rc2.obj/projects/openmp/runtime/test/ompt/synchronization/Output/test_nest_lock_parallel.c.tmp"
"-lm" "-latomic"
$
"/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/Phase3/Release/llvmCore-6.0.0-rc2.obj/projects/openmp/runtime/test/ompt/synchronization/Output/test_nest_lock_parallel.c.tmp"
$ "sort" "--numeric-sort" "--stable"
$
"/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/Phase3/Release/llvmCore-6.0.0-rc2.obj/./bin/FileCheck"
"/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/llvm.src/projects/openmp/runtime/test/ompt/synchronization/test_nest_lock_parallel.c"
# command stderr:
/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-apm_64-build/rc2/llvm.src/projects/openmp/runtime/test/ompt/synchronization/test_nest_lock_parallel.c:47:17:
error: expected string not found in input
 // CHECK-NEXT: {{^}}[[MASTER_ID]]: current_address={{.*}}[[RETURN_ADDRESS]]
^
:20:1: note: scanning from here
281474976710657: current_address=0x403658 or 0x403654
^
:20:1: note: with variable "MASTER_ID" equal to "281474976710657"
281474976710657: current_address=0x403658 or 0x403654
^
:20:1: note: with variable "RETURN_ADDRESS" equal to "0x403650"
281474976710657: current_address=0x403658 or 0x403654
^
:20:13: note: possible intended match here
281474976710657: current_address=0x403658 or 0x403654
^

error: command failed with 

[llvm-bugs] [Bug 35804] [meta] 6.0.0 Release Blockers

[via llvm-bugs]

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

Bug 34182 Summary: test_exception_address_alignment fails on ARM
https://bugs.llvm.org/show_bug.cgi?id=34182

   What|Removed |Added

 Status|RESOLVED|REOPENED
 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 34182] test_exception_address_alignment fails on ARM

[via llvm-bugs]

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

Diana Picus  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---
 Blocks|33849   |35804

--- Comment #8 from Diana Picus  ---
I'm seeing this again in 6.0.0-rc2. It was also in rc1, but I didn't notice it
because of the other ~1000 failures in libcxx tests.


Referenced Bugs:

https://bugs.llvm.org/show_bug.cgi?id=33849
[Bug 33849] [meta] 5.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=35804
[Bug 35804] [meta] 6.0.0 Release Blockers
-- 
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 36312] New: clang crashes at -O1 and above: Assertion `Node2Index[SU.NodeNum] > Node2Index[PD.getSUnit()->NodeNum] && "Wrong topological sorting"' failed

[via llvm-bugs]

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

Bug ID: 36312
   Summary: clang crashes at -O1 and above: Assertion
`Node2Index[SU.NodeNum] >
Node2Index[PD.getSUnit()->NodeNum] && "Wrong
topological sorting"' failed
   Product: clang
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org

Tested with trunk revision 324696. 

$ clangpolly -v
clang version 7.0.0 (http://llvm.org/git/clang.git
4d259cd5974c3927ca86d9b61bb9be2d6739913f) (http://llvm.org/git/llvm.git
5aa15f49a2933afc58166d0e1c976cb5e586f1c8)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/su/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.0.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$ 
$ clangpolly -O0 -c small.c
$ 
$ clangpolly -O1 -c small.c
clang-6.0: /home/su/software/tmp/polly/llvm/lib/CodeGen/ScheduleDAG.cpp:518:
void llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting(): Assertion
`Node2Index[SU.NodeNum] > Node2Index[PD.getSUnit()->NodeNum] && "Wrong
topological sorting"' failed.
#0 0x021805ca llvm::sys::PrintStackTrace(llvm::raw_ostream&)
/home/su/software/tmp/polly/llvm/lib/Support/Unix/Signals.inc:402:0
#1 0x0217e45e llvm::sys::RunSignalHandlers()
/home/su/software/tmp/polly/llvm/lib/Support/Signals.cpp:50:0
#2 0x0217e5d2 SignalHandler(int)
/home/su/software/tmp/polly/llvm/lib/Support/Unix/Signals.inc:242:0
#3 0x7f4726576390 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
#4 0x7f47252e8428 gsignal
/build/glibc-bfm8X4/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0
#5 0x7f47252ea02a abort /build/glibc-bfm8X4/glibc-2.23/stdlib/abort.c:91:0
#6 0x7f47252e0bd7 __assert_fail_base
/build/glibc-bfm8X4/glibc-2.23/assert/assert.c:92:0
#7 0x7f47252e0c82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82)
#8 0x01a840a5
llvm::BitVector::init_words(llvm::MutableArrayRef, bool)
/home/su/software/tmp/polly/llvm/include/llvm/ADT/BitVector.h:877:0
#9 0x01a840a5 llvm::BitVector::set_unused_bits(bool)
/home/su/software/tmp/polly/llvm/include/llvm/ADT/BitVector.h:849:0
#10 0x01a840a5 llvm::BitVector::clear_unused_bits()
/home/su/software/tmp/polly/llvm/include/llvm/ADT/BitVector.h:864:0
#11 0x01a840a5 llvm::BitVector::resize(unsigned int, bool)
/home/su/software/tmp/polly/llvm/include/llvm/ADT/BitVector.h:389:0
#12 0x01a840a5
llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting()
/home/su/software/tmp/polly/llvm/lib/CodeGen/ScheduleDAG.cpp:511:0
#13 0x02b2fe49 (anonymous namespace)::ScheduleDAGRRList::Schedule()
/home/su/software/tmp/polly/llvm/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp:371:0
#14 0x02abf5c6 llvm::TimeRegion::~TimeRegion()
/home/su/software/tmp/polly/llvm/include/llvm/Support/Timer.h:152:0
#15 0x02abf5c6 llvm::NamedRegionTimer::~NamedRegionTimer()
/home/su/software/tmp/polly/llvm/include/llvm/Support/Timer.h:160:0
#16 0x02abf5c6 llvm::SelectionDAGISel::CodeGenAndEmitDAG()
/home/su/software/tmp/polly/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:883:0
#17 0x02ac484a
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
/home/su/software/tmp/polly/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1632:0
#18 0x02ac67b9
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) [clone
.part.853] 

[llvm-bugs] [Bug 36311] New: Assertion failed: isAvailableAtLoopEntry(LHS, L) && "LHS is not available at Loop Entry"

[via llvm-bugs]

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

Bug ID: 36311
   Summary: Assertion failed: isAvailableAtLoopEntry(LHS, L) &&
"LHS is not available at Loop Entry"
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Loop Optimizer
  Assignee: unassignedb...@nondot.org
  Reporter: l...@meinersbur.de
CC: llvm-bugs@lists.llvm.org, serguei.kat...@azul.com

Created attachment 19844
  --> https://bugs.llvm.org/attachment.cgi?id=19844=edit
fe_q_hierarchical_0.ll

The attached test case crashes with an assertion. Trunk r324705.

Might be related to r324204.


FAIL: Polly :: fe_q_hierarchical_0.ll (1126 of 1128)
 TEST 'Polly :: fe_q_hierarchical_0.ll' FAILED

Script:
--
opt -loop-vectorize -S <
C:\Users\Meinersbur\src\llvm\tools\polly\test\fe_q_hierarchical_0.ll
--
Exit Code: 2147483651

Command Output (stdout):
--
$ "opt" "-polly-process-unprofitable" "-polly-remarks-minimal"
"-polly-use-llvm-names"
"-polly-import-jscop-dir=C:\Users\Meinersbur\src\llvm\tools\polly\test"
"-polly-codegen-verify" "-loop-vectorize" "-S"
# command stderr:
Assertion failed: isAvailableAtLoopEntry(LHS, L) && "LHS is not available at
Loop Entry", file
C:\Users\Meinersbur\src\llvm\lib\Analysis\ScalarEvolution.cpp, line 9069
0x7FF7B355A235 (0x7FF7B43E8901 0x7FFBF0B88741 0x00A70006
0x7FFBF0C55510), HandleAbort() + 0x5 bytes(s),
c:\users\meinersbur\src\llvm\lib\support\windows\signals.inc, line 411
0x7FFBF0BDA9FF (0x2301 0x7FF7 0x236D
0x7FF7B43EC7F0), raise() + 0x1CF bytes(s)
0x7FFBF0BDB6F1 (0x7FFB0003 0x7FFB0003 0x7FF7B43EC7F0
0x7FF7B43E89B0), abort() + 0x31 bytes(s)
0x7FFBF0BDD3A5 (0x236D 0x7FF7B43EC7F0 0x01A99796EFC8
0x01A9978C2878), _get_wpgmptr() + 0x1BF5 bytes(s)
0x7FFBF0BDD68F (0x01A997901B10 0x00A799F8D251 0x01A9978C2878
0x01A997901B10), _wassert() + 0x3F bytes(s)
0x7FF7B2B2D36E (0x01A997901B10 0x01A9978C2800 0x01A90024
0x01A99796EF78), llvm::ScalarEvolution::isLoopEntryGuardedByCond() + 0x5E
bytes(s), c:\users\meinersbur\src\llvm\lib\analysis\scalarevolution.cpp, line
9070
0x7FF7B2AE9E1C (0x01A997901B10 0x01A9978B2D58 0x01A99796EFC8
0x7FF7B2FD6AA5), llvm::ScalarEvolution::getZeroExtendExpr() + 0x90C
bytes(s), c:\users\meinersbur\src\llvm\lib\analysis\scalarevolution.cpp, line
1729 + 0x44 byte(s)
0x7FF7B2B0D82C (0x01A9992225B0 0x01A9978EC788 0x01A9978F0B70
0x0090), llvm::ScalarEvolution::createSCEV() + 0x121C bytes(s),
c:\users\meinersbur\src\llvm\lib\analysis\scalarevolution.cpp, line 6238 + 0x29
byte(s)
0x7FF7B2B1FC16 (0x01A997821680 0x01A9978EC788 0x01A99782
0x7FF7B2F8D75D), llvm::ScalarEvolution::getSCEV() + 0x76 bytes(s),
c:\users\meinersbur\src\llvm\lib\analysis\scalarevolution.cpp, line 3807
0x7FF7B2B0BC6B (0x01A9978F0B70 0x01A9978F0B70 0x01A997901B10
0x0068), llvm::ScalarEvolution::createNodeForGEP() + 0xCB bytes(s),
c:\users\meinersbur\src\llvm\lib\analysis\scalarevolution.cpp, line 5265 + 0xB
byte(s)
0x7FF7B2B0D947 (0x01A999222A30 0x01A9978F0B70 0x01A9978F0B70
0x), llvm::ScalarEvolution::createSCEV() + 0x1337 bytes(s),
c:\users\meinersbur\src\llvm\lib\analysis\scalarevolution.cpp, line 6270 + 0x13
byte(s)
0x7FF7B2B1FC16 (0x01A9978C2860 0x01A9978F0B70 0x01A9978F04F0
0x00A799F8F0A0), llvm::ScalarEvolution::getSCEV() + 0x76 bytes(s),
c:\users\meinersbur\src\llvm\lib\analysis\scalarevolution.cpp, line 3807
0x7FF7B3DCE586 (0x 0x0004 0x0001
0x0004), llvm::LoopAccessInfo::isUniform() + 0x46 bytes(s),
c:\users\meinersbur\src\llvm\lib\analysis\loopaccessanalysis.cpp, line 1961 +
0xB byte(s)
0x7FF7B36D6FC2 (0x01A99796CC00 0x00A799F8E010 0x
0x00A799F8E010), llvm::InnerLoopVectorizer::vectorizeMemoryInstruction() +
0x1F2 bytes(s),
c:\users\meinersbur\src\llvm\lib\transforms\vectorize\loopvectorize.cpp, line
3051 + 0x14 byte(s)
0x7FF7B36BFBA7 (0x00A799F8DE30 0x0001 0x01A9978F1B58
0x01A9978F1D98), llvm::VPWidenMemoryInstructionRecipe::execute() + 0x37
bytes(s),
c:\users\meinersbur\src\llvm\lib\transforms\vectorize\loopvectorize.cpp, line
8282 + 0x13 byte(s)
0x7FF7B3710878 (0x01A99797BAD0 0x00A799F8E070 0x00A799F8F100
0x), llvm::VPBasicBlock::execute() + 0x438 bytes(s),
c:\users\meinersbur\src\llvm\lib\transforms\vectorize\vplan.cpp, line 184
0x7FF7B3711641 (0x01A99792C988 0x 0x00A799F8EAB0
0x01A9978C1BE0), llvm::VPlan::execute() + 0x561 bytes(s),

[llvm-bugs] Issue 4908 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: Null-dereference READ in llvm::IRMutator::mutateModule

[ClusterFuzz-External via monorail via llvm-bugs]

Updates:
Labels: Fuzz-Blocker

Comment #5 on issue 4908 by ClusterFuzz-External:  
llvm/llvm-isel-fuzzer--aarch64-gisel: Null-dereference READ in  
llvm::IRMutator::mutateModule

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

This crash occurs very frequently on linux platform and is likely  
preventing the fuzzer llvm-isel-fuzzer--aarch64-gisel from making much  
progress. Fixing this will allow more bugs to be found.


If this is incorrect, please file a bug on  
https://github.com/google/oss-fuzz/issues/new


--
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] Issue 4704 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: Abrt in handleLLVMFatalError

[ClusterFuzz-External via monorail via llvm-bugs]

Updates:
Labels: Fuzz-Blocker

Comment #5 on issue 4704 by ClusterFuzz-External:  
llvm/llvm-isel-fuzzer--aarch64-gisel: Abrt in handleLLVMFatalError

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

This crash occurs very frequently on linux platform and is likely  
preventing the fuzzer llvm-isel-fuzzer--aarch64-gisel from making much  
progress. Fixing this will allow more bugs to be found.


If this is incorrect, please file a bug on  
https://github.com/google/oss-fuzz/issues/new


--
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] Issue 3195 in oss-fuzz: llvm: Direct-leak in clang::Parser::ParseParameterDeclarationClause

[ClusterFuzz-External via monorail via llvm-bugs]

Updates:
Labels: Fuzz-Blocker

Comment #14 on issue 3195 by ClusterFuzz-External: llvm: Direct-leak in  
clang::Parser::ParseParameterDeclarationClause

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

This crash occurs very frequently on linux platform and is likely  
preventing the fuzzer clang-fuzzer from making much progress. Fixing this  
will allow more bugs to be found.


If this is incorrect, please file a bug on  
https://github.com/google/oss-fuzz/issues/new


--
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] Issue 4702 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: Direct-leak in llvm::BitcodeReaderValueList::getValueFwdRef

[ClusterFuzz-External via monorail via llvm-bugs]

Updates:
Labels: Fuzz-Blocker

Comment #5 on issue 4702 by ClusterFuzz-External:  
llvm/llvm-isel-fuzzer--aarch64-gisel: Direct-leak in  
llvm::BitcodeReaderValueList::getValueFwdRef

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

This crash occurs very frequently on linux platform and is likely  
preventing the fuzzer llvm-isel-fuzzer--aarch64-gisel from making much  
progress. Fixing this will allow more bugs to be found.


If this is incorrect, please file a bug on  
https://github.com/google/oss-fuzz/issues/new


--
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] Issue 4701 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: Direct-leak in llvm::MDTuple::getImpl

[ClusterFuzz-External via monorail via llvm-bugs]

Updates:
Labels: Fuzz-Blocker

Comment #5 on issue 4701 by ClusterFuzz-External:  
llvm/llvm-isel-fuzzer--x86_64-O2: Direct-leak in llvm::MDTuple::getImpl

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

This crash occurs very frequently on linux platform and is likely  
preventing the fuzzer llvm-isel-fuzzer--x86_64-O2 from making much  
progress. Fixing this will allow more bugs to be found.


If this is incorrect, please file a bug on  
https://github.com/google/oss-fuzz/issues/new


--
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] Issue 6158 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: RC && "This value type is not natively supported!"

[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, xpl...@gmail.com, akils...@apple.com
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible  
Engine-libfuzzer Proj-llvm Reported-2018-02-09

Type: Bug

New issue 6158 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--aarch64-O2:  
ASSERT: RC && "This value type is not natively supported!"

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

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

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

Crash Type: ASSERT
Crash Address:
Crash State:
  RC && "This value type is not natively supported!"
  llvm::TargetLoweringBase::getRegClassFor
  llvm::FunctionLoweringInfo::CreateRegs

Sanitizer: address (ASAN)

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201712190608:201712210617


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


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 36310] New: Safe -icf-data

[via llvm-bugs]

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

Bug ID: 36310
   Summary: Safe -icf-data
   Product: lld
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: ELF
  Assignee: unassignedb...@nondot.org
  Reporter: r...@google.com
CC: llvm-bugs@lists.llvm.org

Merging data sections by ICF is not usually safe because it breaks an
assumption pointer equality. However, section A is a substring of section B,
and if A's starting position in B is not zero, we can merge the two without
breaking the pointer equality. I don't know how much we can save with it, but
it may worth investigating.

-- 
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 6157 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-gvn: ASSERT: !isa(TI) && "Cannot split critical edge from IndirectBrInst"

[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, xpl...@gmail.com, akils...@apple.com
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible  
Engine-libfuzzer Proj-llvm Reported-2018-02-09

Type: Bug

New issue 6157 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-gvn:  
ASSERT: !isa(TI) && "Cannot split critical edge from  
IndirectBrInst"

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

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

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

Crash Type: ASSERT
Crash Address:
Crash State:
  !isa(TI) && "Cannot split critical edge from  
IndirectBrInst"

  llvm::SplitCriticalEdge
  llvm::GVN::splitCriticalEdges

Sanitizer: address (ASAN)

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201802050757:201802060728


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


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 36309] Clang on Windows needs to support UTF-16 sources

[via llvm-bugs]

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

Eli Friedman  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED
 CC||efrie...@codeaurora.org

--- Comment #1 from Eli Friedman  ---


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

-- 
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 6156 in oss-fuzz: llvm: Stack-overflow in clang::Sema::GetNameFromUnqualifiedId

[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, xpl...@gmail.com, akils...@apple.com
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible  
Engine-libfuzzer Proj-llvm Reported-2018-02-09

Type: Bug

New issue 6156 by ClusterFuzz-External: llvm: Stack-overflow in  
clang::Sema::GetNameFromUnqualifiedId

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

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

Project: llvm
Fuzzer: libFuzzer_llvm_clang-fuzzer
Job Type: libfuzzer_asan_llvm
Platform Id: linux

Crash Type: Stack-overflow
Crash Address: 0x7ffc3db3eb98
Crash State:
  clang::Sema::GetNameFromUnqualifiedId
  clang::Sema::DecomposeUnqualifiedId
  clang::Sema::ActOnIdExpression

Sanitizer: address (ASAN)

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201711140614:201711141648


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


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 36309] New: Clang on Windows needs to support UTF-16 sources

[via llvm-bugs]

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

Bug ID: 36309
   Summary: Clang on Windows needs to support UTF-16 sources
   Product: clang
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Driver
  Assignee: unassignedclangb...@nondot.org
  Reporter: lminkov...@outlook.com
CC: llvm-bugs@lists.llvm.org

On Windows, C++ source files with non-ANSI characters are typically stored with
UTF-16 encoding. An attempt to compile such files with Clang leads to an error:

CL : fatal error : UTF-16 (LE) byte order mark detected in ..., but encoding is
not supported.

-- 
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 36308] New: ELF tests randomly failing on lld-x86_64-freebsd

[via llvm-bugs]

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

Bug ID: 36308
   Summary: ELF tests randomly failing on lld-x86_64-freebsd
   Product: lld
   Version: unspecified
  Hardware: PC
OS: FreeBSD
Status: NEW
  Severity: normal
  Priority: P
 Component: ELF
  Assignee: unassignedb...@nondot.org
  Reporter: franci...@yahoo.com
CC: llvm-bugs@lists.llvm.org

I've seen some ELF tests failing here:

http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/15400
http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/15292

None of the changes seem to affect lld/ELF, and it seems that the next builds
are also fixed by unrelated changes.

-- 
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 4588 in oss-fuzz: llvm/clang-fuzzer: Stack-buffer-overflow in clang::expandUCNs

[vsap… via monorail via llvm-bugs]

Comment #9 on issue 4588 by vsap...@gmail.com: llvm/clang-fuzzer:  
Stack-buffer-overflow in clang::expandUCNs

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

The fix should be available in clang 6.0 release.

--
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 36307] -Wpragma-pack fires incorrectly in header with #pragma options align which gets reset in the end

[via llvm-bugs]

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

Alex Lorenz  changed:

   What|Removed |Added

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

--- Comment #2 from Alex Lorenz  ---
Fixed in r324651

-- 
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 35804] [meta] 6.0.0 Release Blockers

[via llvm-bugs]

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

Bug 36307 Summary: -Wpragma-pack fires incorrectly in header with #pragma 
options align which gets reset in the end
https://bugs.llvm.org/show_bug.cgi?id=36307

   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 36307] New: -Wpragma-pack fires incorrectly in header with #pragma options align which gets reset in the end

[via llvm-bugs]

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

Bug ID: 36307
   Summary: -Wpragma-pack fires incorrectly in header with #pragma
options align which gets reset in the end
   Product: clang
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Frontend
  Assignee: unassignedclangb...@nondot.org
  Reporter: arpha...@gmail.com
CC: llvm-bugs@lists.llvm.org

-Wpragma-pack is a new warning in Clang 6 that warns about #pragma pack and
#pragma options align directives that leak outside their headers.

Clang currently incorrectly emits a warning for the alignment value modified in
a header in the following scenario:

$ cat header.h
#pragma options align=mac68k

struct S { int x; };

#pragma options align=reset
$ cat file.c
#include "header.h"
$ clang file.c
file.c:1:10: warning: the current #pragma pack aligment value is modified in
the included file
  [-Wpragma-pack]
#include "header.h"
 ^
./header.h:1:9: note: previous '#pragma pack' directive that modifies alignment
is here
#pragma options align=mac68k
^
1 warning generated.

We should not emit this warning as header correctly resets the alignment value.
This happens only when "#pragma options align=reset" is the last non-PP token
in the header.

-- 
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 4176 in oss-fuzz: llvm/llvm-special-case-list-fuzzer: Heap-buffer-overflow in llvm_regcomp

[sheriff… via monorail via llvm-bugs]

Updates:
Labels: Deadline-Approaching

Comment #6 on issue 4176 by sheriff...@chromium.org:  
llvm/llvm-special-case-list-fuzzer: Heap-buffer-overflow in llvm_regcomp

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

This bug is approaching its deadline for being fixed, and will be  
automatically derestricted within 7 days. If a fix is planned within 2  
weeks after the deadline has passed, a grace extension can be granted.


- Your friendly Sheriffbot

--
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] Issue 4237 in oss-fuzz: llvm: Stack-overflow in p_ere

[sheriff… via monorail via llvm-bugs]

Updates:
Labels: Deadline-Approaching

Comment #7 on issue 4237 by sheriff...@chromium.org: llvm: Stack-overflow  
in p_ere

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

This bug is approaching its deadline for being fixed, and will be  
automatically derestricted within 7 days. If a fix is planned within 2  
weeks after the deadline has passed, a grace extension can be granted.


- Your friendly Sheriffbot

--
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] Issue 4189 in oss-fuzz: llvm/clang-format-fuzzer: Null-dereference READ in clang::format::TokenAnnotator::splitPenalty

[sheriff… via monorail via llvm-bugs]

Updates:
Labels: Deadline-Approaching

Comment #7 on issue 4189 by sheriff...@chromium.org:  
llvm/clang-format-fuzzer: Null-dereference READ in  
clang::format::TokenAnnotator::splitPenalty

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

This bug is approaching its deadline for being fixed, and will be  
automatically derestricted within 7 days. If a fix is planned within 2  
weeks after the deadline has passed, a grace extension can be granted.


- Your friendly Sheriffbot

--
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] Issue 4278 in oss-fuzz: llvm/clang-format-fuzzer: ASSERT: (TokenText.startswith("//") || TokenText.startswith("#")) && "unsupported line c

[sheriff… via monorail via llvm-bugs]

Updates:
Labels: Deadline-Approaching

Comment #7 on issue 4278 by sheriff...@chromium.org:  
llvm/clang-format-fuzzer: ASSERT: (TokenText.startswith("//") ||  
TokenText.startswith("#")) && "unsupported line c

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

This bug is approaching its deadline for being fixed, and will be  
automatically derestricted within 7 days. If a fix is planned within 2  
weeks after the deadline has passed, a grace extension can be granted.


- Your friendly Sheriffbot

--
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] Issue 4192 in oss-fuzz: llvm/llvm-special-case-list-fuzzer: Heap-buffer-overflow in p_ere

[sheriff… via monorail via llvm-bugs]

Updates:
Labels: Deadline-Approaching

Comment #7 on issue 4192 by sheriff...@chromium.org:  
llvm/llvm-special-case-list-fuzzer: Heap-buffer-overflow in p_ere

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

This bug is approaching its deadline for being fixed, and will be  
automatically derestricted within 7 days. If a fix is planned within 2  
weeks after the deadline has passed, a grace extension can be granted.


- Your friendly Sheriffbot

--
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 36306] New: variable template specialization accepted as class member name

[via llvm-bugs]

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

Bug ID: 36306
   Summary: variable template specialization accepted as class
member name
   Product: clang
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: C++14
  Assignee: unassignedclangb...@nondot.org
  Reporter: richard-l...@metafoo.co.uk
CC: llvm-bugs@lists.llvm.org

Example of incorrectly-accepted code:

template int n;
struct X { int n<0>; };

This results in an anonymous FieldDecl.

Thanks to Jonathan Caves for reporting this!

-- 
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 36305] New: [DAGCombine] Difference in behaviour for SDIV undef, %X on scalar and vector types

[via llvm-bugs]

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

Bug ID: 36305
   Summary: [DAGCombine] Difference in behaviour for SDIV undef,
%X on scalar and vector types
   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: llvm-bugs@lists.llvm.org, spatel+l...@rotateright.com

llvm\test\CodeGen\X86\combine-sdiv.ll

; fold (sdiv undef, x) -> 0
define i32 @combine_sdiv_undef0(i32 %x) {
; CHECK-LABEL: combine_sdiv_undef0:
; CHECK:   # %bb.0:
; CHECK-NEXT:xorl %eax, %eax
; CHECK-NEXT:retq
  %1 = sdiv i32 undef, %x
  ret i32 %1
}

define <4 x i32> @combine_vec_sdiv_undef0(<4 x i32> %x) {
; CHECK-LABEL: combine_vec_sdiv_undef0:
; CHECK:   # %bb.0:
; CHECK-NEXT:retq
  %1 = sdiv <4 x i32> undef, %x
  ret <4 x i32> %1
}

Scalar divisions by undef combine to zero, while vectors combine to undef.

Similar behaviour for udiv, srem, urem.

-- 
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 36304] New: [Regression] sub nsw i32 %x, -1 gets transformed into add i32 %0, 2147483647 illegally

[via llvm-bugs]

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

Bug ID: 36304
   Summary: [Regression] sub nsw i32 %x, -1 gets transformed into
add i32 %0, 2147483647 illegally
   Product: new-bugs
   Version: 6.0
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: arpha...@gmail.com
CC: llvm-bugs@lists.llvm.org

LLVM transforms the 'sub nsw i32 %x, -1' instruction into 'add i32 %0,
2147483647' illegally.

Reproducer:

$ cat test.cpp

typedef unsigned long size_t;

void *memcpy(void *__dst, const void *__src, size_t __n);

int Execute(int , char *Output, const char *Input) {
for (int d=0; d<64; ++d) {
for (int s=0; s<64; ++s) {
for (int n=0; n<3; ++n) {
size_t len = minSize + (n*0x11389737 & minSize-1);
memcpy(Output+d, Input+s, len);
}
}
}
return 0;
}

$ ~/u/b/bin/clang repr.cpp -S -Xclang -emit-llvm  -O1 -o ir.ll
$ cat ir.ll

Bad pass: "Combine redundant instructions"
...
  %mul = mul nuw nsw i32 %n.028, 288921399
  %sub = add i32 %0, 2147483647
  %and = and i32 %sub, %mul
...

-- 
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 36303] New: PGO leads to performance degradation

[via llvm-bugs]

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

Bug ID: 36303
   Summary: PGO leads to performance degradation
   Product: new-bugs
   Version: 6.0
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: vlesc...@gmail.com
CC: llvm-bugs@lists.llvm.org

Created attachment 19840
  --> https://bugs.llvm.org/attachment.cgi?id=19840=edit
Code sample

I've been testing PGO with the code from the thread:
http://lists.llvm.org/pipermail/llvm-dev/2016-May/099395.html

(Code is attached).

And it appeared that using PGO (either -fprofile-instr or -fprofile) lead to
performance degradation. See the results of `{ for i in `seq 1 100`; do time
./test > /dev/null ; done ; } 2>> perf.log` below:

clang -O3: 3.12253
clang -O3 + -fprofile-use: 3.14982
clang -O3 + -fprofile-use + -mllvm -force-precise-rotation-cost : 3.14189
gcc -O3: 3.38019
gcc -O3 + -fprofile-use: 2.937

clang/llvm were built from release_60 branch, gcc version was 7.3.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 36302] New: Assertion "cast() argument of incompatible type!" in 'Unroll loops' pass

[via llvm-bugs]

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

Bug ID: 36302
   Summary: Assertion "cast() argument of incompatible type!"
in 'Unroll loops' pass
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: ilia.tara...@intel.com
CC: llvm-bugs@lists.llvm.org

This test fails at "Unroll loops" with "cast() argument of incompatible
type!" :

= nice.c ==
unsigned int m = 0;
unsigned int a [192];
int main ()
{
unsigned int j = 0;
unsigned int i = 0;
for (i = 0; i <= 7; i++)
for (j = i; j > 1; j--) {
if (i == 96)
m++;
if (i == 0)
a[0] = j;

a[2 * j]++;
}
return 0;
}


===

>>> clang -v
clang version 7.0.0 (trunk 324592)
Target: x86_64-unknown-linux-gnu
Thread model: posix

...


>>> clang -c -O3 -march=skx nice.c
clang-7.0: .../llvm/include/llvm/Support/Casting.h:255: typename
llvm::cast_retty::ret_type llvm::cast(Y*) [with X = llvm::ConstantInt; Y
= llvm::Value; typename llvm::cast_retty::ret_type =
llvm::ConstantInt*]: Assertion `isa(Val) && "cast() argument of
incompatible type!"' failed.
...
1.   parser at end of file
2.  Per-module optimization passes
3.  Running pass 'Function Pass Manager' on module 'nice.c'.
4.  Running pass 'Loop Pass Manager' on function '@main'
5.  Running pass 'Unroll loops' on basic block '%vector.body'


This is a small ll reproducer for opt:
= fine.ll =
@a = external local_unnamed_addr global [4 x i64], align 16

; Function Attrs: norecurse nounwind uwtable
define void @main() local_unnamed_addr #0 {
entry:
  br label %vector.body

vector.body:  ; preds = %vector.body,
%entry
  %vec.ind = phi <2 x i64> [ , %entry ], [ undef, %vector.body ]
  %0 = shl <2 x i64> %vec.ind, 
  %1 = getelementptr inbounds [4 x i64], [4 x i64]* @a, i64 0, <2 x i64> %0
  br i1 undef, label %middle.block, label %vector.body

middle.block: ; preds = %vector.body
  unreachable
}

===

>>> opt -loop-unroll fine.ll
opt: .../llvm/include/llvm/Support/Casting.h:255: typename llvm::cast_retty::ret_type llvm::cast(Y*) [with X = llvm::ConstantInt; Y = llvm::Value;
typename llvm::cast_retty::ret_type = llvm::ConstantInt*]: Assertion
`isa(Val) && "cast() argument of incompatible type!"' failed.

...

Stack dump:
0.  Program arguments: opt -loop-unroll fine.ll
1.  Running pass 'Function Pass Manager' on module 'fine.ll'.
2.  Running pass 'Loop Pass Manager' on function '@main'
3.  Running pass 'Unroll loops' on basic block '%vector.body'
Aborted (core dumped)

-- 
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 36301] New: fatal error: error in backend: Cannot select: 0x56101c6eb3c0: v16i8 = X86ISD::PSHUFB 0x56101c6eac70, 0x56101c6eaee0t:

[via llvm-bugs]

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

Bug ID: 36301
   Summary: fatal error: error in backend: Cannot select:
0x56101c6eb3c0: v16i8 = X86ISD::PSHUFB 0x56101c6eac70,
0x56101c6eaee0t:
   Product: clang
   Version: 5.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: omicro...@gmail.com
CC: llvm-bugs@lists.llvm.org

Building bearssl (https://bearssl.org/) with -O0 flag (specifically
ghash_pclmul.c) results with error from summary.

Reproducing:
> (git clone https://www.bearssl.org/git/BearSSL && cd BearSSL && clang -O0 
> -Isrc -Iinc -c -o src/hash/ghash_pclmul.o src/hash/ghash_pclmul.c)

Resulting error:
> fatal error: error in backend: Cannot select: 0x563cd9168ba0: v16i8 = 
> X86ISD::PSHUFB 0x563cd9168450, 0x563cd91686c0
>   0x563cd9168450: v16i8,ch = CopyFromReg 0x563cd90b0fc8, Register:v16i8 
> %vreg124
> 0x563cd9168318: v16i8 = Register %vreg124
>   0x563cd91686c0: v16i8,ch = CopyFromReg 0x563cd90b0fc8, Register:v16i8 
> %vreg125
> 0x563cd9168588: v16i8 = Register %vreg125
> In function: br_ghash_pclmul
> clang-5.0: error: clang frontend command failed with exit code 70 (use -v to 
> see invocation)
> clang version 5.0.1 (tags/RELEASE_501/final)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> InstalledDir: /usr/bin
> clang-5.0: note: diagnostic msg: PLEASE submit a bug report to 
> http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, 
> and associated run script.
> clang-5.0: note: diagnostic msg:
> 
> 
> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
> Preprocessed source(s) and associated run script(s) are located at:
> clang-5.0: note: diagnostic msg: /tmp/ghash_pclmul-30bc48.c
> clang-5.0: note: diagnostic msg: /tmp/ghash_pclmul-30bc48.sh
> clang-5.0: note: diagnostic msg:

-- 
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 36153] [Formatter/ObjC] Formatter should not break ObjC string literals inside ObjC array literals

[via llvm-bugs]

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

Ben Hamilton  changed:

   What|Removed |Added

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

--- Comment #3 from Ben Hamilton  ---
Fix landed in r324618.

-- 
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 36300] New: [x86] Invalid operand expansion for MLOAD

[via llvm-bugs]

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

Bug ID: 36300
   Summary: [x86] Invalid operand expansion for MLOAD
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: aivch...@gmail.com
CC: llvm-bugs@lists.llvm.org

$ cat test.ll

declare <16 x float> @llvm.masked.load.v16f32.p0v16f32(<16 x float>*, i32, <16
x i1>, <16 x float>)

define void @foo() local_unnamed_addr {
  %tmp = call <16 x float> @llvm.masked.load.v16f32.p0v16f32(<16 x float>*
nonnull undef, i32 4, <16 x i1> undef, <16 x float> undef)
  ret void
}

$ llc test.ll -mcpu=core-avx2
...
llc:  llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp:968: bool
llvm::DAGTypeLegalizer::PromoteIntegerOperand(llvm::SDNode*, unsigned int):
Assertion `Res.getValueType() == N->getValueType(0) && N->getNumValues() == 1
&& "Invalid operand expansion"' failed.
llvm::DAGTypeLegalizer::PromoteIntegerOperand(llvm::SDNode*, unsigned int) 
llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp:967:0
#10 0x03486599 llvm::DAGTypeLegalizer::run() 
llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp:309:0
#11 0x0348b6b1 llvm::SelectionDAG::LegalizeTypes() 
llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp:1187:0
#12 0x03438267 llvm::SelectionDAGISel::CodeGenAndEmitDAG()

-- 
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 36270] [ValueTracking] Crash in computeKnownBitsFromAssume

[via llvm-bugs]

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

Sanjay Patel  changed:

   What|Removed |Added

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

--- Comment #3 from Sanjay Patel  ---
Should be fixed with:
https://reviews.llvm.org/rL324610

-- 
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 36298] New: LLD does not support following output section types in script: DSECT, COPY, INFO, OVERLAY

[via llvm-bugs]

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

Bug ID: 36298
   Summary: LLD does not support following output section types in
script: DSECT, COPY, INFO, OVERLAY
   Product: lld
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: ELF
  Assignee: unassignedb...@nondot.org
  Reporter: gri...@accesssoftek.com
CC: llvm-bugs@lists.llvm.org

(SECT), (COPY), (INFO), (OVERLAY) all have the same effect: section should be
marked as non-allocatable.
Currently we do not support them and produce misleading error instead:
ld.lld: error: test.script:4: symbol not found: INFO

This is used by some apps, for example by TianoCore UEFI firmare:
.build-id (INFO) : { *(.note.gnu.build-id) }
(https://github.com/tianocore/edk2/blob/master/BaseTools/Scripts/GccBase.lds#L72)

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

[llvm-bugs] [Bug 36297] New: [ELF] - LLD can produce excessive undefined symbols with specific linker script.

[via llvm-bugs]

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

Bug ID: 36297
   Summary: [ELF] - LLD can produce excessive undefined symbols
with specific linker script.
   Product: lld
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: ELF
  Assignee: unassignedb...@nondot.org
  Reporter: gri...@accesssoftek.com
CC: llvm-bugs@lists.llvm.org

Imagine following script:

SECTIONS { .bar (a+b) : { *(.stub) } };

And assume that there is no .stub section in object.
"a+b" here is address expression.
We add all symbols referenced by script as undefined
early. ".bar" becomes empty section and removed from output.

a and b though present as undefined in symtab and no error
is produced.

bfd produce error:
test.script:4: non constant or forward reference address expression for section
.bar

gold too:
ld: error: undefined symbol 'a' referenced in expression
ld: error: undefined symbol 'a' referenced in expression

-- 
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 35804] [meta] 6.0.0 Release Blockers

[via llvm-bugs]

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

Bug 36008 Summary: Regression (r316268): erroneous -Wsign-compare for 
typeof(enum T) and typeof(enumValue)
https://bugs.llvm.org/show_bug.cgi?id=36008

   What|Removed |Added

 Status|REOPENED|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 36008] Regression (r316268): erroneous -Wsign-compare for typeof(enum T) and typeof(enumValue)

[via llvm-bugs]

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

Hans Wennborg  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #9 from Hans Wennborg  ---
(In reply to Aaron Ballman from comment #8)
> (In reply to Hans Wennborg from comment #7)
> > Let's keep it open until we decide whether to merge to 6.0.
> > 
> > Richard, Aaron, what do you think?
> 
> I am fine merging this -- it's small and uncontroversial, IMO.

Okay, r324602.

-- 
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 35804] [meta] 6.0.0 Release Blockers

[via llvm-bugs]

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

Bug 36055 Summary: Reproducible Clang crash + strongly suspected invalid code 
generation
https://bugs.llvm.org/show_bug.cgi?id=36055

   What|Removed |Added

 Status|RESOLVED|REOPENED
 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 36055] Reproducible Clang crash + strongly suspected invalid code generation

[via llvm-bugs]

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

Hans Wennborg  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #6 from Hans Wennborg  ---
(In reply to Richard Smith from comment #5)
> Fixed in r324537.

Do you think we should merge it to 6.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 35804] [meta] 6.0.0 Release Blockers

[via llvm-bugs]

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

Bug 36008 Summary: Regression (r316268): erroneous -Wsign-compare for 
typeof(enum T) and typeof(enumValue)
https://bugs.llvm.org/show_bug.cgi?id=36008

   What|Removed |Added

 Status|RESOLVED|REOPENED
 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 36008] Regression (r316268): erroneous -Wsign-compare for typeof(enum T) and typeof(enumValue)

[via llvm-bugs]

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

Hans Wennborg  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED
 CC||aa...@aaronballman.com,
   ||richard-l...@metafoo.co.uk

--- Comment #7 from Hans Wennborg  ---
Let's keep it open until we decide whether to merge to 6.0.

Richard, Aaron, what do you think?

-- 
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 6109 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-sccp: ASSERT: getActiveBits() <= 64 && "Too many bits for uint64_t"

[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, xpl...@gmail.com, akils...@apple.com
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible  
Engine-libfuzzer Proj-llvm Reported-2018-02-08

Type: Bug

New issue 6109 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-sccp:  
ASSERT: getActiveBits() <= 64 && "Too many bits for uint64_t"

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

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

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

Crash Type: ASSERT
Crash Address:
Crash State:
  getActiveBits() <= 64 && "Too many bits for uint64_t"
  llvm::Constant::getAggregateElement
  llvm::ConstantFoldLoadThroughGEPConstantExpr

Sanitizer: address (ASAN)

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201802070726:201802080701


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


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 36293] clang crashes on windows compiling chromium

[via llvm-bugs]

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

Hans Wennborg  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|NEW |RESOLVED
 CC||h...@chromium.org

--- Comment #2 from Hans Wennborg  ---
Strange :-/

I'm unable to reproduce this with either tip-of-tree, the 6.0 branch, or
r321529 which you are using.

Could you be running out of memory or something? It's a pretty large
preprocessed file.

-- 
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 36295] New: symbol version "has undefined version error" when all symbols with version are hidden.

[via llvm-bugs]

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

Bug ID: 36295
   Summary: symbol version "has undefined version error" when all
symbols with version are hidden.
   Product: lld
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: ELF
  Assignee: unassignedb...@nondot.org
  Reporter: peter.sm...@linaro.org
CC: llvm-bugs@lists.llvm.org

While attempting to build the Android dynamic linker on Arm I ran into many
errors of the form:
"out/soong/.intermediates/bionic/libc/libc_nomalloc/android_arm_armv7-a_static_core/libc_nomalloc.a(__aeabi.o):
symbol __aeabi_memcpy@LIBC_PRIVATE has undefined version LIBC_PRIVATE"
"error:
out/soong/.intermediates/bionic/libc/libc_nomalloc/android_arm_armv7-a_static_core/libc_nomalloc.a(__aeabi.o):
symbol __aeabi_memmove8@@LIBC_N has undefined version LIBC_N"

I did not get these errors with ld.gold, although I did get them with ld.bfd.
The errors are only Arm specific on the dynamic linker because the file
__aeabi.o is Arm specific.

It turns out that there was indeed no version script [*] so the LIBC_PRIVATE
and LIBC_N were not defined. However the dynamic linker links with the flag
"--exclude-libs ALL" which prevents symbols in the library from being exported
into the dynamic symbol table.

A simplified reproducer on x86:
t.s:
.globl foo_impl2
foo_impl2:
ret

.symver foo_impl, foo@@LIBC_N
.symver foo_impl2, foo@LIBC_PRIVATE
t2.s:
.text
.globl foo
.globl _start
_start:
ret

.data
.quad foo
clang -fPIC t.s t2.s -c
ld.gold --shared t2.o t.a -o t2.so --exclude-libs ALL # All works fine
ld.bfd --shared t2.o t.a -o t2.so --exclude-libs ALL
t2.so: version node not found for symbol foo@LIBC_PRIVATE
ld.lld --shared t2.o t.a -o t2.so --exclude-libs ALL 
ld.lld: error: t.a(t.o): symbol foo@@LIBC_N has undefined version LIBC_N
ld.lld: error: t.a(t.o): symbol foo@LIBC_PRIVATE has undefined version
LIBC_PRIVATE


Something like "--exclude-libs ALL" is important to get this past gold as the
.symver foo_impl, foo@@VERSION will always create the symbol foo with
STV_DEFAULT visibility.

I don't think that there is a clear answer in the symbol versioning
specification as to whether the linker should give an error in this case. It is
true that the version isn't defined, but if the symbol isn't in the dynamic
symbol table then do we care? Gold will give an error message if a symbol
definition in the dynamic symbol table has an undefined version. Personally I
have some sympathy for Gold's view, for example lld doesn't give an error
message for an undefined version in an executable.

For what it is worth, and this could be a separate PR, I noticed that when I
wrote a simple symbol version script for LLD to force the symbols local, they
were exported into the dynamic symbol table with default visibility:

LIBC_PRIVATE
{
local:
  foo;
};

LIBC_N
{
local:
 foo;
};
ld.lld --shared t2.o t.a -o t2.so --exclude-libs ALL --version-script=t.version
readelf --dyn-syms t2.so
Symbol table '.dynsym' contains 4 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
 0:  0 NOTYPE  LOCAL  DEFAULT  UND 
 1: 1000 0 NOTYPE  GLOBAL DEFAULT8 _start
 2: 1004 0 NOTYPE  GLOBAL DEFAULT8 foo@@LIBC_N
 3: 1005 0 NOTYPE  GLOBAL DEFAULT8 foo@LIBC_PRIVATE

My understanding of local: was that it was supposed to prevent symbols from
being exported into the symbol table, and this is the behaviour I see from gold
and bfd. It could be that my symbol version script is wrong though.

I think that there are potentially two changes that could be made:
- Do not error if there is no version defined for a symbol that isn't in the
dynamic symbol table.
- LLD's local: implementation doesn't seem to be working for the version script
above. 

[*] The libc_nomalloc.a library is used in the bionic libc library where LIBC_N
and LIBC_PRIVATE are defined in a version script, and in the dynamic linker
where there are no definitions.

-- 
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 36294] New: AlwaysBreakAfterReturnType works incorrectly for some operator functions

[via llvm-bugs]

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

Bug ID: 36294
   Summary: AlwaysBreakAfterReturnType works incorrectly for some
operator functions
   Product: clang
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Formatter
  Assignee: unassignedclangb...@nondot.org
  Reporter: artemiev.mikh...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org

Tried it with the latest trunk code.

$ cat /tmp/foo.cpp
class Foo {
 public:
   bool operator!() const;
   bool operator<( Foo const & ) const;
   bool operator*() const;
   bool operator->() const;
   bool operator+() const;
   bool operator-() const;
   bool f() const;
};

bool Foo::operator!() const { return true; }
bool Foo::operator<( Foo const & ) const { return true; }
bool Foo::operator*() const { return true; }
bool Foo::operator->() const { return true; }
bool Foo::operator+() const { return true; }
bool Foo::operator-() const { return true; }
bool Foo::f() const { return true; }

$ bin/clang-format --style="{BasedOnStyle: llvm, AlwaysBreakAfterReturnType:
TopLevelDefinitions}" /tmp/foo.cpp
class Foo {
public:
  bool operator!() const;
  bool operator<(Foo const &) const;
  bool operator*() const;
  bool operator->() const;
  bool operator+() const;
  bool operator-() const;
  bool f() const;
};

bool Foo::operator!() const { return true; }
bool
Foo::operator<(Foo const &) const {
  return true;
}
bool Foo::operator*() const { return true; }
bool Foo::operator->() const { return true; }
bool
Foo::operator+() const {
  return true;
}
bool
Foo::operator-() const {
  return true;
}
bool
Foo::f() const {
  return true;
}

As you can see there is no break after the return type for the operators !, *
and ->

-- 
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 36293] New: clang crashes on windows compiling chromium

[via llvm-bugs]

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

Bug ID: 36293
   Summary: clang crashes on windows compiling chromium
   Product: clang
   Version: 6.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: release blocker
  Priority: P
 Component: C++
  Assignee: unassignedclangb...@nondot.org
  Reporter: keremkat+l...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org

Stack trace:

#0 0x7ff6594bef60
(C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x164ef60)
#1 0x7ff6594e6983
(C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1676983)
#2 0x7ff659e31b2d
(C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1fc1b2d)
#3 0x7ff659e2e81d
(C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1fbe81d)
#4 0x7ff659df7bcc
(C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1f87bcc)
#5 0x7ff658ac0458
(C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0xc50458)
#6 0x7ff658faec4b
(C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x113ec4b)
#7 0x7ff6591e9b07
(C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1379b07)
#8 0x7ff6591e9e29
(C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1379e29)
#9 0x7ff6591ea4a8
(C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x137a4a8)
#10 0x7ff65996693c
(C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1af693c)
#11 0x7ff65b4bd242
(C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x364d242)
#12 0x7ff659d9017c
(C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1f2017c)
#13 0x7ff65a4c1cd2
(C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x2651cd2)
#14 0x7ff659d4b2d0
(C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1edb2d0)
#15 0x7ff659d34d41
(C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1ec4d41)
#16 0x7ff659dc2ca3
(C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1f52ca3)
#17 0x7ff657e76d40
(C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x6d40)
#18 0x7ff657e7478f
(C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x478f)
#19 0x7ff65b4e6195
(C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x3676195)
#20 0x7ffe7f7d1fe4 (C:\WINDOWS\System32\KERNEL32.DLL+0x11fe4)
#21 0x7ffe81fbef91 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x6ef91)
clang-cl.exe: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 6.0.0 (trunk 321529)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin
clang-cl.exe: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.

-- 
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 36288] Merge clang r324419 into 6.0 branch: [Lex] Fix handling numerical literals ending with ' and signed exponent.

[via llvm-bugs]

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

Hans Wennborg  changed:

   What|Removed |Added

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

--- Comment #1 from Hans Wennborg  ---
Merged in r324579.

-- 
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 35804] [meta] 6.0.0 Release Blockers

[via llvm-bugs]

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

Bug 36288 Summary: Merge clang r324419 into 6.0 branch: [Lex] Fix handling 
numerical literals ending with ' and signed exponent.
https://bugs.llvm.org/show_bug.cgi?id=36288

   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