[llvm-bugs] [Bug 39737] Merge clang r345044, r345038, r345497, r346392 into 7.0.1

[via llvm-bugs]

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

Tom Stellard  changed:

   What|Removed |Added

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

--- Comment #4 from Tom Stellard  ---
Merged: r347834

-- 
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 39106] [meta] 7.0.1 Release Blockers

[via llvm-bugs]

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

Bug 39737 Summary: Merge clang r345044, r345038, r345497, r346392 into 7.0.1
https://bugs.llvm.org/show_bug.cgi?id=39737

   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 39107] Merge r343105 into the 7.0 branch : [analyzer] scan-build: if --status-bugs is passed, don't forget about the exit s

[via llvm-bugs]

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

Tom Stellard  changed:

   What|Removed |Added

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

--- Comment #3 from Tom Stellard  ---
Merged: r347829

-- 
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 39106] [meta] 7.0.1 Release Blockers

[via llvm-bugs]

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

Bug 39107 Summary: Merge r343105 into the 7.0 branch : [analyzer] scan-build: 
if --status-bugs is passed, don't forget about the exit s
https://bugs.llvm.org/show_bug.cgi?id=39107

   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] Issue 11595 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in processTypeAttrs

[ClusterFuzz-External via monorail via llvm-bugs]

Status: New
Owner: 
CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com,  
igm...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org,  
j...@chromium.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-11-29

Type: Bug

New issue 11595 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow  
in processTypeAttrs

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

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

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

Crash Type: Stack-overflow
Crash Address: 0x7ffd7340bea0
Crash State:
  processTypeAttrs
  ConvertDeclSpecToType
  GetDeclSpecTypeForDeclarator

Sanitizer: address (ASAN)

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201811270236:201811270644


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


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 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.


--
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 11594 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::ProcessDiag

[ClusterFuzz-External via monorail via llvm-bugs]

Status: New
Owner: 
CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com,  
igm...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org,  
j...@chromium.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-11-29

Type: Bug

New issue 11594 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow  
in clang::DiagnosticIDs::ProcessDiag

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

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

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

Crash Type: Stack-overflow
Crash Address: 0x7fffeef31e38
Crash State:
  clang::DiagnosticIDs::ProcessDiag
  clang::DiagnosticsEngine::EmitCurrentDiagnostic
  clang::Sema::EmitCurrentDiagnostic

Sanitizer: address (ASAN)

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201811270644:201811280235


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


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 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.


--
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 39734] Merge r347179 into the 7.0 branch

[via llvm-bugs]

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

Tom Stellard  changed:

   What|Removed |Added

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

--- Comment #3 from Tom Stellard  ---
Merged: r347822

-- 
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 39106] [meta] 7.0.1 Release Blockers

[via llvm-bugs]

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

Bug 39734 Summary: Merge r347179 into the 7.0 branch
https://bugs.llvm.org/show_bug.cgi?id=39734

   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 38460] assert with -fdelated-template-parsing: getContainingDC(DC) == CurContext && "The next DeclContext should be lexically contained in the current one."

[via llvm-bugs]

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

Reid Kleckner  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED
 Fixed By Commit(s)||r347713

--- Comment #4 from Reid Kleckner  ---
Should be fixed by r347713.

-- 
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 39835] New: The lit test suite does not differentiate between deployment target and system dylib in use

[via llvm-bugs]

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

Bug ID: 39835
   Summary: The lit test suite does not differentiate between
deployment target and system dylib in use
   Product: libc++
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: ldio...@apple.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com

Currently, the lit test suite does not make a difference between the deployment
target and the system dylib used to build the tests. As a result, a
command-line like this will fail:

./build/bin/llvm-lit -sv --param=enable_experimental=false
--param=enable_filesystem=false
--param=use_system_cxx_lib=""
--param=platform=macosx10.7 --param=std=c++03 --param=with_availability=True
libcxx/test/std/input.output/iostream.format/input.streams

The failing tests for this specific command are:

Unexpected Passing Tests (11):
libc++ ::
std/input.output/iostream.format/input.streams/istream.unformatted/get.pass.cpp
libc++ ::
std/input.output/iostream.format/input.streams/istream.unformatted/get_chart.pass.cpp
libc++ ::
std/input.output/iostream.format/input.streams/istream.unformatted/get_pointer_size.pass.cpp
libc++ ::
std/input.output/iostream.format/input.streams/istream.unformatted/get_pointer_size_chart.pass.cpp
libc++ ::
std/input.output/iostream.format/input.streams/istream.unformatted/getline_pointer_size.pass.cpp
libc++ ::
std/input.output/iostream.format/input.streams/istream.unformatted/getline_pointer_size_chart.pass.cpp
libc++ ::
std/input.output/iostream.format/input.streams/istream.unformatted/ignore_0xff.pass.cpp
libc++ ::
std/input.output/iostream.format/input.streams/istream.unformatted/read.pass.cpp
libc++ ::
std/input.output/iostream.format/input.streams/istream.unformatted/readsome.pass.cpp
libc++ ::
std/input.output/iostream.format/input.streams/istream.unformatted/seekg.pass.cpp
libc++ ::
std/input.output/iostream.format/input.streams/istream.unformatted/seekg_off.pass.cpp

Failing Tests (1):
libc++ ::
std/input.output/iostream.format/input.streams/istream.formatted/istream.formatted.arithmetic/pointer.pass.cpp


The problem is that tests like istream.unformatted/get.pass.cpp are marked as
`XFAIL: with_system_cxx_lib=macosx10.7`. However, the test doesn't fail because
while we're asking to back-deploy to macosx10.7, we're actually using a more
recent version of the dylib (macosx10.11 in this example), which does not
trigger a failure in this test.

The with_system_cxx_lib feature needs to be populated by something that's not
the deployment target, and that should be passed to lit on the command line or
in the configuration 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] Issue 11593 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: Heap-buffer-overflow in llvm::DWARFFormValue::dump

[ClusterFuzz-External via monorail via llvm-bugs]

Status: New
Owner: 
CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com,  
igm...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org,  
j...@chromium.org, v...@apple.com, mitchphi...@outlook.com,  
xpl...@gmail.com, akils...@apple.com
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible  
Engine-libfuzzer Proj-llvm Security_Severity-Medium Reported-2018-11-28

Type: Bug-Security

New issue 11593 by ClusterFuzz-External: llvm/llvm-dwarfdump-fuzzer:  
Heap-buffer-overflow in llvm::DWARFFormValue::dump

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

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

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

Crash Type: Heap-buffer-overflow READ 1
Crash Address: 0x61901890
Crash State:
  llvm::DWARFFormValue::dump
  llvm::AppleAcceleratorTable::dumpName
  llvm::AppleAcceleratorTable::dump

Sanitizer: address (ASAN)

Recommended Security Severity: Medium

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201709150442:201710101928


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


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 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.


--
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 39021] llvm-exegesis build on x86 doesn't set LLVM_EXEGESIS_INITIALIZE_NATIVE_TARGET

[via llvm-bugs]

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

Tom Stellard  changed:

   What|Removed |Added

 Fixed By Commit(s)|r342865 |r342865 r347811
 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Tom Stellard  ---
Merged: r347811

-- 
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 39106] [meta] 7.0.1 Release Blockers

[via llvm-bugs]

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

Bug 39021 Summary: llvm-exegesis build on x86 doesn't set 
LLVM_EXEGESIS_INITIALIZE_NATIVE_TARGET
https://bugs.llvm.org/show_bug.cgi?id=39021

   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 39834] New: PowerPC wait encoding is invalid for e500mc

[via llvm-bugs]

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

Bug ID: 39834
   Summary: PowerPC wait encoding is invalid for e500mc
   Product: libraries
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: PowerPC
  Assignee: unassignedb...@nondot.org
  Reporter: vit9...@avp.su
CC: llvm-bugs@lists.llvm.org, nemanja.i@gmail.com

Power ISA 2.07B and 3.0B have different encodings for wait instruction
(0x7C7C vs 0x7C3C). We happen to partially support the latter, and
mistakingly emit the wrong opcode for targets like e500mc.

Power ISA 3.0B [1] on page 876 defines wait instruction in a way we have it In
PPCInstrInfo.td:
def WAIT : XForm_24_sync<31, 30, (outs), (ins i32imm:$L),
 "wait $L", IIC_LdStLoad, []>;

However, in Power ISA 2.07B [2] on page 791 the instruction with the same
mnemonic is encoded differently, for which the actual definition should be:
def WAIT : XForm_24_sync<31, 62, (outs), (ins i32imm:$L),
 "wait $L", IIC_LdStLoad, []>;

The reference for e500mc [3] on page 6-371 also provides the waitrsv mnemonic,
and waitimpl mnemonic can be found in bintuils [4]. I believe the intention was
to support the 2.07B variant, which has neither of the two.

[1] https://ibm.box.com/s/1hzcwkwf8rbju5h9iyf44wm94amnlcrv
[2] https://ibm.box.com/s/jd5w15gz301s5b5dt375mshpq9c3lh4u
[3] https://www.nxp.com/files-static/32bit/doc/ref_manual/EREF_RM.pdf
[4]
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=opcodes/ppc-opc.c;h=bb311642d6a47824145122a16cabd6cff8272e58;hb=HEAD

-- 
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 39822] [Coverage] clang crashes with 'Assertion SpellingRegion(SM, StartLoc, EndLoc).isInSourceOrder() failed.'

[via llvm-bugs]

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

Vedant Kumar  changed:

   What|Removed |Added

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

--- Comment #8 from Vedant Kumar  ---
Thank you! Fixed in r347803.

-- 
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 39833] New: clang segfault in ComputeLineNumbers

[via llvm-bugs]

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

Bug ID: 39833
   Summary: clang segfault in ComputeLineNumbers
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: dholb...@mozilla.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org

Created attachment 21174
  --> https://bugs.llvm.org/attachment.cgi?id=21174=edit
backtrace & other logging from when the segfault happened

Just hit a clang segfault, with locally-built recent-SVN-trunk clang revision
346691.  Backtrace attached - if I'm understanding it correctly, it looks like
the segfault was in ComputeLineNumbers.

-- 
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 18686] AArch64 ELF PC-rel relocations are not supported in RuntimeDyld.

[via llvm-bugs]

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

Lang Hames  changed:

   What|Removed |Added

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

--- Comment #2 from Lang Hames  ---
Sounds good to me.

-- 
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 39740] Merge r347261 and maybe r347262 into the 7.0 branch (Clang coverage crash fixes)

[via llvm-bugs]

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

Tom Stellard  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 Fixed By Commit(s)|r347261 r347262 |r347261 r347262 r347797
   ||r347798

--- Comment #3 from Tom Stellard  ---
Merged: r347797 r347798

-- 
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 39106] [meta] 7.0.1 Release Blockers

[via llvm-bugs]

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

Bug 39740 Summary: Merge r347261 and maybe r347262 into the 7.0 branch (Clang 
coverage crash fixes)
https://bugs.llvm.org/show_bug.cgi?id=39740

   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 39832] New: VScode extension always popups output panel on errors

[via llvm-bugs]

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

Bug ID: 39832
   Summary: VScode extension always popups output panel on errors
   Product: clang-tools-extra
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: clangd
  Assignee: unassignedclangb...@nondot.org
  Reporter: m...@3v1n0.net
CC: llvm-bugs@lists.llvm.org

The extension has `revealOutputChannelOn` set to true on Errors, but this is
quite annoying when doing normal development.

While the output should be always be visible in the output panel, the panel
should, optionally, not to popup.

To workaround this, I've to manually patch the generated js at each release
with something like this.

Having an option flag would be indeed more convenient.

--- a/node_modules/vscode-languageclient/lib/client.js  2018-11-28
14:39:26.250075271 -0500
+++ b/node_modules/vscode-languageclient/lib/client.js  2018-11-28
14:39:29.857825456 -0500
@@ -1623,7 +1623,7 @@
 synchronize: clientOptions.synchronize || {},
 diagnosticCollectionName: clientOptions.diagnosticCollectionName,
 outputChannelName: clientOptions.outputChannelName || this._name,
-revealOutputChannelOn: clientOptions.revealOutputChannelOn ||
RevealOutputChannelOn.Error,
+revealOutputChannelOn: clientOptions.revealOutputChannelOn ||
RevealOutputChannelOn.Never,
 stdioEncoding: clientOptions.stdioEncoding || 'utf8',
 initializationOptions: clientOptions.initializationOptions,
 initializationFailedHandler:
clientOptions.initializationFailedHandler,

-- 
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 39831] New: Failure to compile code with ref-qualified conversion operator

[via llvm-bugs]

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

Bug ID: 39831
   Summary: Failure to compile code with ref-qualified conversion
operator
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: C++11
  Assignee: unassignedclangb...@nondot.org
  Reporter: kristian.spangs...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk

Created attachment 21172
  --> https://bugs.llvm.org/attachment.cgi?id=21172=edit
Code to trigger the bug

The attached core fails to compile with Clang 7.0 (and trunk). It does compile
with GCC 8.2 (and trunk). I would expect it to compile in Clang too.

Live demonstration: https://godbolt.org/z/BSioPr

-- 
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 39830] New: [llvm-mca] Investigate how to improve the load/store queue usage simulation in LSUnit.

[via llvm-bugs]

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

Bug ID: 39830
   Summary: [llvm-mca] Investigate how to improve the load/store
queue usage simulation in LSUnit.
   Product: tools
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: llvm-mca
  Assignee: unassignedb...@nondot.org
  Reporter: andrea.dibia...@gmail.com
CC: andrea.dibia...@gmail.com, llvm-bugs@lists.llvm.org,
matthew.da...@sony.com

On some processors, load/store operations are split into multiple uOps. For
example, X86 AMD Jaguar natively supports 128-bit data types, but not 256-bit
data types. So, a 256-bit load is effectively split into two 128-bit loads, and
each split load consumes one 'LoadQueue' entry. For simplicity, this class
optimistically assumes that a load instruction only consumes one entry in the
LoadQueue.  Similarly, store instructions only consume a single entry in the
StoreQueue.

In future, we should reassess the quality of this design, and consider
alternative approaches that let instructions specify the number of load/store
queue entries which they consume at dispatch stage.

-- 
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 39829] New: [llvm-mca] LSUnit: Consider using field `LoadLatency` from MCSchedModel to simulate the latency of load instructions.

[via llvm-bugs]

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

Bug ID: 39829
   Summary: [llvm-mca] LSUnit: Consider using field `LoadLatency`
from MCSchedModel to simulate the latency of load
instructions.
   Product: tools
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: llvm-mca
  Assignee: unassignedb...@nondot.org
  Reporter: andrea.dibia...@gmail.com
CC: andrea.dibia...@gmail.com, llvm-bugs@lists.llvm.org,
matthew.da...@sony.com

Class LSUnit doesn't know about the latency of load instructions. So, it
conservatively/pessimistically assumes that the latency of a load opcode
matches the instruction latency. 

In the absence of cache misses (i.e. L1I/L1D/iTLB/dTLB hits/misses),
and load/store conflicts, the latency of a load is determined by the depth
of the load pipeline. So, we could use field `LoadLatency` in the
MCSchedModel to model that latency.
Field `LoadLatency` often matches the so-called 'load-to-use' latency from
L1D, and it usually already accounts for any extra latency due to data
forwarding.
When doing throughput analysis, `LoadLatency` is likely to
be a better predictor of load latency than instruction latency. This is
particularly true when simulating code with temporal/spatial locality of
memory accesses.
Using `LoadLatency` (instead of the instruction latency) is also expected
to improve the load queue allocation for long latency instructions with
folded memory operands.

-- 
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 39828] New: [llvm-mca] Add a 'memory' event type to track load/store queue usage.

[via llvm-bugs]

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

Bug ID: 39828
   Summary: [llvm-mca] Add a 'memory' event type to track
load/store queue usage.
   Product: tools
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: llvm-mca
  Assignee: unassignedb...@nondot.org
  Reporter: andrea.dibia...@gmail.com
CC: andrea.dibia...@gmail.com, llvm-bugs@lists.llvm.org,
matthew.da...@sony.com

Once https://reviews.llvm.org/D54957 is committed, class SchedulerStatistics
will start correctly tracking the load/store queue consumption in the LSUnit.

However, SchedulerStatistics will work under the assumption that load/store
queue
entries are reserved at 'instruction dispatched' stage, and released at
'instruction executed' stage. This currently matches the behavior of LSUnit.

That design will minimize the number of events generated by the
Dispatch/Execute stages, at the cost of doing extra bookkeeping in method
`onEvent()`. It also introduces a subtle (not-so-nice) dependency with how the
LSUnit works internally.

In future, we should add a new "memory queue" event type, so that
SchedulerStatistics will stop making assumptions on when/how queue entries are
allocated by the LSUnit.

-- 
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 39807] SimplifyCFG may drop debugloc on invokes

[via llvm-bugs]

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

Jeremy Morse  changed:

   What|Removed |Added

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

--- Comment #7 from Jeremy Morse  ---
Committed in rL347782

-- 
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 11592 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: Timeout in llvm_llvm-isel-fuzzer--aarch64-gisel

[ClusterFuzz-External via monorail via llvm-bugs]

Status: New
Owner: 
CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com,  
igm...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org,  
j...@chromium.org, v...@apple.com, mitchphi...@outlook.com,  
xpl...@gmail.com, akils...@apple.com
Labels: ClusterFuzz Reproducible Engine-libfuzzer Proj-llvm  
Reported-2018-11-28

Type: Bug

New issue 11592 by ClusterFuzz-External:  
llvm/llvm-isel-fuzzer--aarch64-gisel: Timeout in  
llvm_llvm-isel-fuzzer--aarch64-gisel

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

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

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

Crash Type: Timeout (exceeds 25 secs)
Crash Address:
Crash State:
  llvm_llvm-isel-fuzzer--aarch64-gisel

Sanitizer: address (ASAN)

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201801020611:201801030610


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


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 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.


--
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 39827] New: [x86, GlobalIsel] crash with undef operand

[via llvm-bugs]

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

Bug ID: 39827
   Summary: [x86, GlobalIsel] crash with undef operand
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: spatel+l...@rotateright.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com

define i16 @add_undef(i16 %a) {
  %r = add i16 %a, undef
  ret i16 %r
}

$ llc -o - -global-isel undef.ll 
.section__TEXT,__text,regular,pure_instructions
.macosx_version_min 10, 14

# Machine code for function test2: NoPHIs, TracksLiveness, Legalized,
RegBankSelected, Selected

bb.0 (%ir-block.0):
  liveins: $edi
  %1:gr32 = COPY killed $edi
  %0:gr16 = COPY %1.sub_16bit:gr32
  %5:gr64_nosp = IMPLICIT_DEF
  %5.sub_16bit:gr64_nosp = COPY %0:gr16
  %6:gr64_nosp = IMPLICIT_DEF
  %6.sub_16bit:gr64_nosp = COPY %2:gr16
  %4:gr32 = LEA64_32r killed %5:gr64_nosp, 1, killed %6:gr64_nosp, 0, $noreg
  %3:gr16 = COPY killed %4.sub_16bit:gr32
  $ax = COPY killed %3:gr16
  RET 0, implicit killed $ax

# End machine code for function test2.

*** Bad machine code: Reading virtual register without a def ***
- function:test2
- basic block: %bb.0  (0x7fc56988bb40)
- instruction: %6.sub_16bit:gr64_nosp = COPY %2:gr16
- operand 1:   %2:gr16
LLVM ERROR: Found 1 machine code errors.

-- 
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 39826] New: merge:.rdata=.text produces broken executable

[via llvm-bugs]

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

Bug ID: 39826
   Summary: merge:.rdata=.text produces broken executable
   Product: lld
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: release blocker
  Priority: P
 Component: COFF
  Assignee: unassignedb...@nondot.org
  Reporter: m...@veg.by
CC: llvm-bugs@lists.llvm.org

The issue is easy to reproduce using clang 8.0.0 from trunk.

1. Create test.cpp with these contents:

#include 
int wmain(int argc, wchar_t* argv[])
{
printf("Hello, world!");
return 0;
}

2. Compile it using this command:

clang -std=c++17 -m32 -fuse-ld=lld -Oz
-Wl,-subsystem:console,-merge:.rdata=.text,-out:test.exe test.cpp

3. Try to run test.exe, you will see this error:

---
test.exe - System Error
---
The program can't start because KERNEL32.dll  is missing from your
computer. Try reinstalling the program to fix this problem. 
---
OK   
---

If you look into test.exe, you will notice that all the strings from the merged
.rdata section use 0xCC for padding, and 0xCC is used instead of 0 at the end
of strings like KERNEL32.DLL or function names.

I believe that when you merge a data section into code section, it should not
change padding byte from 0x00 to 0xCC, it should just merge sections without
changing actual contents of the sections.

LLVM v7 didn't have the issue.

-- 
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 39818] Unable to build GDB 8.2 with Clang 6

[via llvm-bugs]

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

Dimitry Andric  changed:

   What|Removed |Added

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

--- Comment #3 from Dimitry Andric  ---
This is a duplicate of bug 35724, and it was fixed by
.  Unfortunately this was never merged back
to the 6.0 branch, so you will have to do that yourself.  See also
.

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

-- 
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 39825] New: integrated assembler should accept both -defsym and --defsym

[via llvm-bugs]

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

Bug ID: 39825
   Summary: integrated assembler should accept both -defsym and
--defsym
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: FreeBSD
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: ema...@freebsd.org
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org

Clang IAS supports -Wa,-defsym,FOO=BAR but not -Wa,--defsym,FOO=BAR (with two
-s).  GNU as accepts both but documents the --defsym FOO=BAR form so it is
presumably preferred.

(We are attempting to retire use of GNU as 2.17.50 in FreeBSD.  Most assembly
files in our tree are already assembled by Clang IAS but there are a small
number that still use GNU as for on reason or another, listed in
https://bugs.freebsd.org/233611.)

-- 
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 39824] New: False positive error in memory sanitizer

[via llvm-bugs]

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

Bug ID: 39824
   Summary: False positive error in memory sanitizer
   Product: clang
   Version: 7.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Tooling
  Assignee: unassignedclangb...@nondot.org
  Reporter: gael.guenneb...@gmail.com
CC: llvm-bugs@lists.llvm.org

The following self-contained example trigger an error with memory sanitizer:

***
#include 

struct Vec {
  const float* data() const {return 0;}
};

struct myevaluator3 { ~myevaluator3() {} };

struct myevaluator2 : myevaluator3 {
  myevaluator2(const Vec& v) : m(v.data()) {}
  const float * m;
};

struct myevaluator : myevaluator2 {  
  myevaluator(const Vec& m) : myevaluator2(m) {}
};

float foo(const Vec&,int) {
  Vec w;
  myevaluator e(w);
  return 0;
}

int main() {
  Vec v;
  float x = foo(v,0);
  std::cout << x;
}
***

Compiling without any optimization, i.e.,

$ clang++-7  bug.cpp -fsanitize=memory && ./a.out

gives me:

Uninitialized bytes in __interceptor_memcmp at offset 244 inside
[0x7ffeeaa581c0, 256)
==10014==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7f2b3838ce2b in std::ctype::_M_widen_init() const
(/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0xb8e2b)
#1 0x7f2b383e8df7 in std::ostream& std::ostream::_M_insert(double)
(/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x114df7)
#2 0x49445c in main (a.out+0x49445c)
#3 0x7f2b37323b96 in __libc_start_main
/build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
#4 0x41b4d9 in _start (a.out+0x41b4d9)


This is the most reduced test case I managed to get. For instance any of the
following change will remove the reported error:
- remove the destructor ~myevaluator3() {}
- reduce the hierarchy of myevaluator
- change the prototype of foo to: float foo(const Vec&) or float foo(Vec,int)
- removing std::cout << x;
- ...

The reported error also goes away if compiling with -O1 or higher.

I hope I did not reported a false negative ;)

-- 
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 39823] New: wrong binaries/headers for llvm-toolchain-xenial-7

[via llvm-bugs]

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

Bug ID: 39823
   Summary: wrong binaries/headers for llvm-toolchain-xenial-7
   Product: Packaging
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: deb packages
  Assignee: unassignedb...@nondot.org
  Reporter: and...@ziglang.org
CC: llvm-bugs@lists.llvm.org

This build worked on Nov 24 and stopped working Nov 25.

2018-11-25T16:48:47.6020966Z + sudo sh -c echo "deb
http://apt.llvm.org/xenial/ llvm-toolchain-xenial-7 main" >>
/etc/apt/sources.list
...
2018-11-25T16:53:30.7836235Z
/home/vsts/work/1/s/src/zig_llvm.cpp:686:1: error: static assertion
failed
2018-11-25T16:53:30.7837134Z
static_assert((Triple::OSType)ZigLLVM_LastOSType ==
Triple::LastOSType, "");
2018-11-25T16:53:30.7837409Z ^
full logs
https://dev.azure.com/ziglang/zig/_build/results?buildId=229=logs

The version on apt.llvm.org has
HermitCore, // HermitCore Unikernel/Multikernel
LastOSType = HermitCore

But llvm 7.0.0 and 7.0.1 have
AMDPAL, // AMD PAL Runtime
LastOSType = AMDPAL

Downstream issue https://github.com/ziglang/zig/issues/1788

-- 
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 39774] SLP vectorizer crashes, regression after rL346970

[via llvm-bugs]

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

Alexey Bataev  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|CONFIRMED   |RESOLVED
 Fixed By Commit(s)||r347759

-- 
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 39822] New: [Coverage] clang crashes with 'Assertion SpellingRegion(SM, StartLoc, EndLoc).isInSourceOrder() failed.'

[via llvm-bugs]

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

Bug ID: 39822
   Summary: [Coverage] clang crashes with 'Assertion
SpellingRegion(SM, StartLoc, EndLoc).isInSourceOrder()
failed.'
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: C++
  Assignee: unassignedclangb...@nondot.org
  Reporter: di...@google.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk

Created attachment 21170
  --> https://bugs.llvm.org/attachment.cgi?id=21170=edit
Archive containing the crash backtrace + preprocessed source file + launcher
script

When enabling code coverage instrumentation, compiling a C++ source file makes
Clang crash with an assertion error message that reads as:

"""
clang++: .../llvm/tools/clang/lib/CodeGen/CoverageMappingGen.cpp:789: void
(anonymous
namespace)::CounterCoverageMappingBuilder::fillGapAreaWithCount(clang::SourceLocation,
clang::SourceLocation, llvm::coverage::Counter): Assertion `SpellingRegion(SM,
StartLoc, EndLoc).isInSourceOrder()' failed.
"""

This was detected by a Chromium build bot trying to build a new source file
(see https://crbug.com/908937 for details).

-- 
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 39821] New: Preprocessor recursion ends in segfault

[via llvm-bugs]

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

Bug ID: 39821
   Summary: Preprocessor recursion ends in segfault
   Product: new-bugs
   Version: 7.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: vincent.h...@higaski.at
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org

It's currently possible to segfault the compiler when the preprocessor
recursion depth gets deep enough. I've added a simple test case based on
BOOST_PP which triggers the segfault on my machine. Feel free to use the very
first define of N to adjust the recursion depth.

-- 
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 39678] Problems with dynamic section entries

[via llvm-bugs]

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

Peter Smith  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Fixed By Commit(s)||347736
 Status|CONFIRMED   |RESOLVED

--- Comment #7 from Peter Smith  ---
Committed r347736 to use an InputSection based calculation for DT_PLTRELSZ.
Resolving for now.

-- 
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 39820] New: -Wfloat-conversion error message formatting error

[via llvm-bugs]

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

Bug ID: 39820
   Summary: -Wfloat-conversion error message formatting error
   Product: clang
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: Frontend
  Assignee: unassignedclangb...@nondot.org
  Reporter: jyrki.ha...@helsinki.fi
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk

Given code

[havia@villikani colld]$ cat k.c
int main(void)
{
double a = 3.0;
long b = 2;

b /= a;

return 0;
}

[havia@villikani colld]$ clang-8 -Weverything  k.c
k.c:6:4: warning: implicit conversion turns floating-point number into integer:
'long' to 'double' [-Wfloat-conversion]
b /= a;
~~^~~~
1 warning generated.

  Shouldn't the end of the message be
  "'double' to 'long'" instead of "'long' to 'double'"?

clang-8 is localy compiled

[havia@villikani colld]$ clang-8 -v
clang version 8.0.0 (trunk 345705)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/llvm/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.5
Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.5
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

  The environment is

[havia@villikani colld]$ lsb_release 
LSB Version:   
:core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch

[havia@villikani colld]$ cat /etc/redhat-release 
CentOS Linux release 7.5.1804 (Core) 
[havia@villikani colld]$

-- 
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 10250 in oss-fuzz: llvm: Build failure

[ClusterFuzz-External via monorail via llvm-bugs]

Comment #17 on issue 10250 by ClusterFuzz-External: llvm: Build failure
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10250#c17

Friendly reminder that the the build is still failing.
Please try to fix this failure to ensure that fuzzing remains productive.
Latest build log:  
https://oss-fuzz-build-logs.storage.googleapis.com/log-7e63353d-ca06-491e-a936-953c3ab2409d.txt



--
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 38603] [OpenCL C++] Template parameters are broken due to address space changes

[via llvm-bugs]

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

Anastasia Stulova  changed:

   What|Removed |Added

 Fixed By Commit(s)||r347189
 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 39819] New: clang crash with co_await in an auto-lambda in a function template

[via llvm-bugs]

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

Bug ID: 39819
   Summary: clang crash with co_await in an auto-lambda in a
function template
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: C++
  Assignee: unassignedclangb...@nondot.org
  Reporter: blastr...@free.fr
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk

The following program makes clang crash:

template  void c(b) {
  [](auto client) { co_await client; };
}
int main() { c(0); }

Compiled with: clang++ -std=c++17 -fcoroutines-ts

Godbolt link: https://godbolt.org/z/bNEkkq

-- 
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 39818] New: Unable to build GDB 8.2 with Clang 6

[via llvm-bugs]

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

Bug ID: 39818
   Summary: Unable to build GDB 8.2 with Clang 6
   Product: clang
   Version: 6.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: iarspi...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk

When trying to build Gdb 8.2 with clang 6 (built with gcc 6.2), the build
fails:

```
Did not see access type in access path!
  %41 = load i8*, i8** %object_base, align 8, !dbg !10479, !tbaa !10480
!10480 = !{!9899, !6715, i64 16}
Did not see access type in access path!
  %83 = load i8*, i8** %next_free57, align 8, !dbg !10549, !tbaa !10550
!10550 = !{!9899, !6715, i64 24}
Did not see access type in access path!
  store i8* %add.ptr58, i8** %next_free57, align 8, !dbg !10549, !tbaa !10550
!10550 = !{!9899, !6715, i64 24}
fatal error: error in backend: Broken function found, compilation aborted!
clang-6.0: error: clang frontend command failed with exit code 70 (use -v to
see invocation)
clang version 6.0.0 (tags/RELEASE_600/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir:
/cvmfs/sft.cern.ch/lcg/releases/clang/6.0.0-6647e/x86_64-centos7-gcc62-opt/bin
clang-6.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-6.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-6.0: note: diagnostic msg: /tmp/minsyms-cc415f.cpp
clang-6.0: note: diagnostic msg: /tmp/minsyms-cc415f.sh
clang-6.0: note: diagnostic msg: 



```

Full build log: also attached

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

[llvm-bugs] Issue 11583 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::DeclContext::using_directives

[ClusterFuzz-External via monorail via llvm-bugs]

Updates:
Labels: -Reproducible Unreproducible

Comment #1 on issue 11583 by ClusterFuzz-External: llvm/clang-fuzzer:  
Stack-overflow in clang::DeclContext::using_directives

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

ClusterFuzz testcase 5770095679242240 appears to be flaky, updating  
reproducibility label.


--
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 11298 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in llvm::ConvertUTF8toWide

[ClusterFuzz-External via monorail via llvm-bugs]

Updates:
Labels: ClusterFuzz-Verified
Status: Verified

Comment #2 on issue 11298 by ClusterFuzz-External: llvm/clang-fuzzer:  
Stack-overflow in llvm::ConvertUTF8toWide

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

ClusterFuzz testcase 5708143561015296 is verified as fixed, so closing  
issue as verified.


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 11298 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in llvm::ConvertUTF8toWide

[ClusterFuzz-External via monorail via llvm-bugs]

Comment #1 on issue 11298 by ClusterFuzz-External: llvm/clang-fuzzer:  
Stack-overflow in llvm::ConvertUTF8toWide

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

ClusterFuzz has detected this issue as fixed in range  
201811270644:201811280235.


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

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

Crash Type: Stack-overflow
Crash Address: 0x7ffe95dffd18
Crash State:
  llvm::ConvertUTF8toWide
  clang::StringLiteralParser::CopyStringFragment
  clang::StringLiteralParser::init

Sanitizer: address (ASAN)

Fixed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201811270644:201811280235


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


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


If you suspect that the result above is incorrect, try re-doing that job on  
the test case report page.


--
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