[llvm-bugs] [Bug 36473] New: Scanning fis-gtm produces multiple cores

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36473

Bug ID: 36473
   Summary: Scanning fis-gtm produces multiple cores
   Product: clang
   Version: 4.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Static Analyzer
  Assignee: dcough...@apple.com
  Reporter: amul.s...@fisglobal.com
CC: llvm-bugs@lists.llvm.org

I am using the Clang SCA to analyze the source code of FIS GT.M (fis-gtm.com)
and have run into a number of failures that result in analyzer core dumps. I
understand that the bug report in this email will need to be re-entered into
the bug tracker, but since there will be some turn-around time between getting
access to the bug tracker and me needing to write the bug report, I thought it
would prudent to type up the report now.

Thanks,
Amul Shah

Host platform:
$ lsb_release -d
Description:Fedora release 26 (Twenty Six)

Clang version (default for Fedora):
$ clang --version
clang version 4.0.1 (tags/RELEASE_401/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

Source Code:
https://sourceforge.net/projects/fis-gtm/files/GT.M-x86-Linux-src/V6.3-003A/

Steps to reproduce:
1. Download sources and install dependencies listed in the README (on
Debian/Ubuntu installing fis-gtm will install all of the dependencies)
2. Execute the following from the source directory
mkdir build && cd build
export PATH "${PATH}:/usr/libexec"
set utflocale = `locale -a | gawk
'BEGIN{IGNORECASE=1}/en_us.utf-*8/{print;exit}'`
setenv LANG C
setenv LC_ALL "${utflocale}"
setenv LC_COLLATE C

setenv CCC_CC clang
setenv CCC_CXX clang++
set ccc_analyzer=`which ccc-analyzer`
cmake -DCMAKE_C_COMPILER=$ccc_analyzer -DCMAKE_ASM_COMPILER=gcc
-DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_FLAGS_DEBUG="-DSTATIC_ANALYSIS
-DSTATIC_ANALYSIS_NORETURN" -DGTM_ENABLE_DEBUG=0 ..

echo "Building in ${PWD}"
scan-build --status-bugs -analyze-headers -stats -disable-checker
deadcode.DeadStores -analyzer-config stable-report-filename=true -o ${PWD} make
-j 8

-- 
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 4816 in oss-fuzz: llvm: Stack-overflow in clang::CharLiteralParser::CharLiteralParser

2018-02-22 Thread ClusterFuzz-External via monorail via llvm-bugs 

Updates:
Status: WontFix

Comment #4 on issue 4816 by ClusterFuzz-External: llvm: Stack-overflow in  
clang::CharLiteralParser::CharLiteralParser

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

ClusterFuzz testcase 4971130851950592 is flaky and no longer crashes, so  
closing issue.


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 4609 in oss-fuzz: llvm: Stack-overflow in Evaluate

2018-02-22 Thread ClusterFuzz-External via monorail via llvm-bugs 

Updates:
Status: WontFix

Comment #5 on issue 4609 by ClusterFuzz-External: llvm: Stack-overflow in  
Evaluate

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

ClusterFuzz testcase 4629918072700928 is flaky and no longer crashes, so  
closing issue.


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 6504 in oss-fuzz: llvm/clang-format-fuzzer: Stack-overflow in clang::format::AnnotatingParser::parseAngle

2018-02-22 Thread 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-22

Type: Bug

New issue 6504 by ClusterFuzz-External: llvm/clang-format-fuzzer:  
Stack-overflow in clang::format::AnnotatingParser::parseAngle

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

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

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

Crash Type: Stack-overflow
Crash Address: 0x7ffe1cd22e38
Crash State:
  clang::format::AnnotatingParser::parseAngle
  clang::format::AnnotatingParser::consumeToken

Sanitizer: address (ASAN)

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


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


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

2018-02-22 Thread 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-22

Type: Bug

New issue 6505 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow  
in Evaluate

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

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

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: 0x7ffe33b77e80
Crash State:
  Evaluate
  IntExprEvaluator::VisitUnaryOperator
  clang::StmtVisitorBase::Visit


Sanitizer: address (ASAN)

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


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


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

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35804
Bug 35804 depends on bug 36423, which changed state.

Bug 36423 Summary: r324100 breaks lld on OpenBSD
https://bugs.llvm.org/show_bug.cgi?id=36423

   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 36423] r324100 breaks lld on OpenBSD

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36423

Hans Wennborg  changed:

   What|Removed |Added

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

--- Comment #5 from Hans Wennborg  ---
Sorry, I hadn't seen that there was follow-up discussion (for reference, this
is on the D42825 mailing list thread).

We're too late in the 6.0.0 process to mess around with this. In r325759 I've
reverted the branch back to where we were at branch point, i.e. the flag is
spelled the same as in lld 5.0.1.

Future changes can be done on trunk and shipped in lld 7.


(As a parenthesis to the discussion, note that Clang also supports the -nopie
spelling, and passing it along spelled like that to the linker on OpenBSD.)

-- 
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 6508 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: isa(Val) && "cast() argument of incompatible type!"

2018-02-22 Thread 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-22

Type: Bug

New issue 6508 by ClusterFuzz-External:  
llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: isa(Val)  
&& "cast() argument of incompatible type!"

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

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

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

Crash Type: ASSERT
Crash Address:
Crash State:
  isa(Val) && "cast() argument of incompatible type!"
  llvm::InnerLoopVectorizer::buildScalarSteps
  llvm::InnerLoopVectorizer::widenIntOrFpInduction

Sanitizer: address (ASAN)

Regressed:  
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201802190622:201802200626


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


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 36292] Invalid PPC CTR loop with llc on powerpc64le-unknown-linux-gnu

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36292

Hans Wennborg  changed:

   What|Removed |Added

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

--- Comment #8 from Hans Wennborg  ---
(In reply to Nemanja Ivanovic from comment #7)
> Committed revision 325739.
> 
> Hans, if you don't mind, please backport to 6.0.
> Sorry about the late submission.

Merged in r325767. 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 35804] [meta] 6.0.0 Release Blockers

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35804
Bug 35804 depends on bug 36292, which changed state.

Bug 36292 Summary: Invalid PPC CTR loop with llc on 
powerpc64le-unknown-linux-gnu
https://bugs.llvm.org/show_bug.cgi?id=36292

   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 36032] After r313012, Assertion failed: (ExitCount != SE.getCouldNotCompute() && "Invalid loop count"), function generateOverflowCheck, file lib/Analysis/ScalarEvolutionExpander.cpp,

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36032

Hans Wennborg  changed:

   What|Removed |Added

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

--- Comment #10 from Hans Wennborg  ---
(In reply to Silviu Baranga from comment #9)
> Yes, let's merge r325687 for 6.0.0.

Merged in r325773. 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 35804] [meta] 6.0.0 Release Blockers

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35804
Bug 35804 depends on bug 36032, which changed state.

Bug 36032 Summary: After r313012, Assertion failed: (ExitCount != 
SE.getCouldNotCompute() && "Invalid loop count"), function 
generateOverflowCheck, file lib/Analysis/ScalarEvolutionExpander.cpp, line 2126.
https://bugs.llvm.org/show_bug.cgi?id=36032

   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 36474] New: Assertion failure in RegionStoreManager::getBinding

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36474

Bug ID: 36474
   Summary: Assertion failure in RegionStoreManager::getBinding
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Static Analyzer
  Assignee: dcough...@apple.com
  Reporter: ale...@google.com
CC: ekarpen...@apple.com, llvm-bugs@lists.llvm.org

$ cat test-RegionStoreManager__getBinding.c
a;
b(void **c) {
  *c = a;
  int *d;
  b();
  *d;
}
$ clang-tidy -checks=-*,clang-analyzer* test-RegionStoreManager__getBinding.c
--
assert.h assertion failed at
llvm/tools/clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1408 in
clang::ento::SVal (anonymous
namespace)::RegionStoreManager::getBinding(RegionBindingsConstRef,
clang::ento::Loc, clang::QualType): !T->isVoidType() && "Attempting to
dereference a void pointer!"

@ 0x564dda45a0e6  __assert_fail
@ 0x564dd8ecd09d  (anonymous
namespace)::RegionStoreManager::getBinding()
@ 0x564dd8ec6ba4  (anonymous
namespace)::RegionStoreManager::getBinding()
@ 0x564dd8f04bf8  clang::ento::ProgramState::getSVal()
@ 0x564dd841cd30  clang::ento::check::Location::_checkLocation<>()
@ 0x564dd8f43b1c  clang::ento::CheckerManager::runCheckersForLocation()
@ 0x564dd8f5ea9f  clang::ento::ExprEngine::evalLocation()
@ 0x564dd8f5ece4  clang::ento::ExprEngine::evalLoadCommon()
@ 0x564dd8f5de77  clang::ento::ExprEngine::evalLoad()
@ 0x564dd8f7a97c  clang::ento::ExprEngine::VisitCast()
@ 0x564dd8f5429b  clang::ento::ExprEngine::Visit()
@ 0x564dd8f5179e  clang::ento::ExprEngine::ProcessStmt()
@ 0x564dd8f5149b  clang::ento::ExprEngine::processCFGElement()
@ 0x564dd8f72f85  clang::ento::CoreEngine::HandlePostStmt()
@ 0x564dd8f7223d  clang::ento::CoreEngine::ExecuteWorkList()
@ 0x564dd7f9b9c3  (anonymous
namespace)::AnalysisConsumer::ActionExprEngine()
@ 0x564dd7f9b546  (anonymous namespace)::AnalysisConsumer::HandleCode()
@ 0x564dd7f858c4  (anonymous
namespace)::AnalysisConsumer::HandleTranslationUnit()

-- 
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 36476] New: [InstCombine] Instcombine deletes call of 'new' function that has side effects after r325630

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36476

Bug ID: 36476
   Summary: [InstCombine] Instcombine deletes call of 'new'
function that has side effects after r325630
   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 with wrong result after r325630:

= nice.cpp 
#include 
#include 

extern void *operator new(size_t size)
{
printf("Happy ending\n");
exit(0);
return malloc(size);
}


struct S { int a;};

int main ()
{
S *s = new S;
printf("Bad ending\n");
printf("%x\n", s -> a);
return 0;
}
===


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

>>> clang -o nice.exe nice.cpp -O0
>>> ./nice.exe
Happy ending

>>> clang -o nice.exe nice.cpp -O1
>>> ./nice.exe
Bad ending
Illegal instruction (core dumped)


>>> clang -o nice.exe nice.cpp -mllvm -opt-bisect-limit :

BISECT: running pass (15) Simplify the CFG on function (_Znwm)   
-> Happy ending
BISECT: running pass (16) Combine redundant instructions on function (main)
-> Bad ending

 nice-before.ll ===
...
; Function Attrs: nobuiltin uwtable
define dso_local noalias i8* @_Znwm(i64) local_unnamed_addr #0 {
  %2 = call i32 @puts(i8* getelementptr inbounds ([13 x i8], [13 x i8]* @str,
i64 0, i64 0))
  call void @exit(i32 0) #5
  unreachable
}


; Function Attrs: norecurse uwtable
define dso_local i32 @main() local_unnamed_addr #3 {
  %1 = call i8* @_Znwm(i64 undef) #6
  %2 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([12 x i8], [12 x
i8]* @.str.1, i32 0, i32 0))
  %3 = getelementptr inbounds %struct.S, %struct.S* undef, i32 0, i32 0
  %4 = load i32, i32* %3, align 4, !tbaa !2
  %5 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x
i8]* @.str.2, i32 0, i32 0), i32 %4)
  ret i32 0
}
...

===

>>> opt nice-before.ll -instcombine -o nice-after.ll -S

 nice-after.ll ===
...
; Function Attrs: norecurse uwtable
define dso_local i32 @main() local_unnamed_addr #3 {
  %puts = call i32 @puts(i8* getelementptr inbounds ([11 x i8], [11 x i8]*
@str.1, i64 0, i64 0))
  store i32 undef, i32* null, align 536870912
  %1 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x
i8]* @.str.2, i64 0, i64 0), i32 undef)
  ret i32 0
}

...

===

This started giving wrong behavior after r325630
[https://reviews.llvm.org/rL325630]
---
r325630 | d0k | 2018-02-20 23:00:33 +0100 (Tue, 20 Feb 2018) | 5 lines

[MemoryBuiltins] Check nobuiltin status when identifying calls to free.

This is usually not a problem because this code's main purpose is
eliminating unused new/delete pairs. We got deletes of nullptr or
nobuiltin deletes of builtin new wrong though.
---

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

[llvm-bugs] [Bug 35650] [mc] Zero divider is not handled for modulo

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=35650

Simon Pilgrim  changed:

   What|Removed |Added

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

--- Comment #4 from Simon Pilgrim  ---
rL325810

-- 
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 36469] std::invoke of std::optional::has_value pointer-to-member-function fails, due to its class type being a private base.

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36469

David Blaikie  changed:

   What|Removed |Added

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

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

[llvm-bugs] [Bug 36479] New: libc++'s , , , provide wrong overload sets for abs

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36479

Bug ID: 36479
   Summary: libc++'s , , , 
provide wrong overload sets for abs
   Product: libc++
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: richard-l...@metafoo.co.uk
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com

libc++ does not implement the resolution of LWG issue 2192:

  https://cplusplus.github.io/LWG/issue2192

This results in the wrong value being produced for uses of abs() after only one
of math.h / stdlib.h is included.

-- 
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 36476] [InstCombine] Instcombine deletes call of 'new' function that has side effects after r325630

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36476

Richard Smith  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED
 CC||richard-l...@metafoo.co.uk

--- Comment #1 from Richard Smith  ---
C++ [expr.new]p10 (http://eel.is/c++draft/expr.new#10) explicitly permits this
optimization:

"An implementation is allowed to omit a call to a replaceable global allocation
function ([new.delete.single], [new.delete.array]). When it does so, the
storage is instead provided by the implementation"

If you want to observe side-effects of your '::operator new(size_t)'
implementation (eg, when writing tests for your allocator), you need to make a
regular function call, rather than using a new-expression. LLVM will not delete
the 'operator new' call here:

S *s = new (::operator new(sizeof(S))) S;

-- 
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 36478] New: Make lld-link.exe detect that the result file is in use and that linking will fail.

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36478

Bug ID: 36478
   Summary: Make lld-link.exe detect that the result file is in
use and that linking will fail.
   Product: lld
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: unassignedb...@nondot.org
  Reporter: p...@google.com
CC: llvm-bugs@lists.llvm.org

When building chrome (and I have chrome.exe running), linking completes and
fails when the result is about to be written to disk:

[519/542] LINK(DLL) chrome.dll chrome.dll.lib chrome.dll.pdb
FAILED: chrome.dll chrome.dll.lib chrome.dll.pdb
C:/python_27_amd64/files/python.exe ../../build/toolchain/win/tool_wrapper.py
link-wrapper environment.x86 False
../../third_party/llvm-build/Release+Asserts/bin/lld-link.exe /nologo
/IMPLIB:./chrome.dll.lib /DLL /OUT:./chrome.dll /PDB:./chrome.dll.pdb
@./chrome.dll.rsp
..\..\third_party\llvm-build\Release+Asserts\bin\lld-link.exe: error: failed to
write the output file: permission denied
[538/542] CXX
obj/chrome/test/browser_tests/better_session_restore_browsertest.obj

Since linking can take minutes it'd be nice if this case could (best-effort) be
caught on startup rather than when all work is done.

-- 
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 36477] New: clang-analyzer-core.uninitialized.Assign: False positive with reinterpret_cast

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36477

Bug ID: 36477
   Summary: clang-analyzer-core.uninitialized.Assign: False
positive with reinterpret_cast
   Product: clang
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Static Analyzer
  Assignee: dcough...@apple.com
  Reporter: r...@eatnumber1.com
CC: llvm-bugs@lists.llvm.org

I've been encountering a case where Clang Static Analyzer raises
clang-analyzer-core.uninitialized.Assign. I've narrowed down the culprit code
to the following sample case:

struct myint {
  int d;
};

struct foo {
  myint a;
};

int myfn1() {
  foo myfoo {5};
  const unsigned char *a = reinterpret_cast();
  char ret = a[1];
  return ret;
}

The warning generated is:

$ scan-build clang++ -std=c++11 -c -O0 ~/a.cc
scan-build: Using '/usr/bin/clang' for static analysis
/usr/local/google/home/eatnumber1/a.cc:12:3: warning: Assigned value is garbage
or undefined
  char ret = a[1];
  ^~~~   
1 warning generated.
scan-build: 1 bugs found.
scan-build: Run 'scan-view /tmp/scan-build-2017-10-13-151811-27304-1' to
examine bug reports.

If I change `struct foo` to the following:

struct foo {
  int a;
};

then the warning is not emitted.

What's going on here?

-- 
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 6515 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-gvn: ASSERT: (VTy->isFirstClassType() || VTy->isVoidTy() || VTy->isStructTy()) && "invalid Ca

2018-02-22 Thread 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-22

Type: Bug

New issue 6515 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-gvn:  
ASSERT: (VTy->isFirstClassType() || VTy->isVoidTy() || VTy->isStructTy())  
&& "invalid Ca

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

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

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:
  (VTy->isFirstClassType() || VTy->isVoidTy() || VTy->isStructTy())  
&& "invalid Ca

  llvm::Value::Value
  llvm::BitcodeReaderValueList::getConstantFwdRef

Sanitizer: address (ASAN)

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


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


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] Issue 6166 in oss-fuzz: llvm: Stack-overflow in clang::Lexer::LexTokenInternal

2018-02-22 Thread ClusterFuzz-External via monorail via llvm-bugs 

Updates:
Status: WontFix

Comment #1 on issue 6166 by ClusterFuzz-External: llvm: Stack-overflow in  
clang::Lexer::LexTokenInternal

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

ClusterFuzz testcase 6512758343335936 is flaky and no longer crashes, so  
closing issue.


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] [Bug 36481] New: Reassociation messes up SLPVectorizer reduction

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36481

Bug ID: 36481
   Summary: Reassociation messes up SLPVectorizer reduction
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Scalar Optimizations
  Assignee: unassignedb...@nondot.org
  Reporter: timshe...@gmail.com
CC: llvm-bugs@lists.llvm.org

Created attachment 19931
  --> https://bugs.llvm.org/attachment.cgi?id=19931=edit
Test

Running `opt -S -slp-vectorizer $TEST_FILE`, the function gets SLP-vectorized;
Running `opt -S -reassociate -slp-vectorizer $TEST_FILE`, the function doesn't
get SLP-vectorized.

This is because the reassociation pass re-associates instructions like `acc =
add ith_element, acc` to `acc = add acc, ith_element`, but didn't re-assocate
the first instruction `acc = add first_element, second_element` to `acc = add
second_element, first_element`.

However, as add is associative, a smarter SLP vectorizer could have ignored the
associations and vectorize the unordered adds anyway.

I'm not sure where to put the fix on.

-- 
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 36480] New: Option "-fpic" has no effection with option "-mcmodel=large"

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36480

Bug ID: 36480
   Summary: Option "-fpic" has no effection with option
"-mcmodel=large"
   Product: clang
   Version: 5.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: pan...@gmail.com
CC: llvm-bugs@lists.llvm.org

~$ cat x.c
extern void ();
void x()
{
  ();
}
~$ clang -mcmodel=large -fpic -S x.c
~$ grep  x.s 
movabsq $, %rax

-- 
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 6518 in oss-fuzz: llvm: Stack-overflow in EvaluateValue

2018-02-22 Thread 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-23

Type: Bug

New issue 6518 by ClusterFuzz-External: llvm: Stack-overflow in  
EvaluateValue

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

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

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

Crash Type: Stack-overflow
Crash Address: 0x7ffc14587ee0
Crash State:
  EvaluateValue

Sanitizer: address (ASAN)

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


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 36483] New: cfi-icall broken for available_externally functions

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36483

Bug ID: 36483
   Summary: cfi-icall broken for available_externally functions
   Product: libraries
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Interprocedural Optimizations
  Assignee: unassignedb...@nondot.org
  Reporter: v...@tsyrklevich.net
CC: llvm-bugs@lists.llvm.org

A change [1] to ThinLTO to mark non-prevailing values as dead (and later drop
dead symbols) has broken how LowerTypeTests handles available_externally
functions. The LowerTypeTests pass uses liveness to determine which functions
to emit cfi-icall thunks for to avoid avoid emitting thunks for unused
functions. Because of the change in [1], available_externally functions are
marked not live and LowerTypeTests does not emit thunks for them even when they
are actually used.

[1] https://reviews.llvm.org/D42107

-- 
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 36484] New: Assertion failure with GVNHoist: Assertion `MSSA->dominates(NewDef, FirstDef) && "Should have dominated the new access"' failed.

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36484

Bug ID: 36484
   Summary: Assertion failure with GVNHoist: Assertion
`MSSA->dominates(NewDef, FirstDef) && "Should have
dominated the new access"' failed.
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Scalar Optimizations
  Assignee: unassignedb...@nondot.org
  Reporter: efrie...@codeaurora.org
CC: dber...@dberlin.org, hiradi...@msn.com,
llvm-bugs@lists.llvm.org

Testcase (crashes with "opt -gvn-hoist"):

target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"

define void @f(i8* %p) {
entry:
  switch i4 undef, label %if.then30 [
i4 4, label %if.end
i4 0, label %if.end
  ]

if.end:
  br label %if.end19

if.end19:
  br i1 undef, label %e, label %e.thread

e.thread:
  store i8 0, i8* %p, align 4
  br label %if.then30

if.then30:
  call void @g()
  unreachable

e:
  store i8 0, i8* %p, align 4
  unreachable
}

declare void @g()





The issue is related to the MemoryPhi in the block if.then30. 
MemorySSAUpdater::moveTo erases the store in the block e.thread, then erases
the MemoryPHI in if.then30 because it's trivial (temporarily), then tries to
insert a def in if.end19.  fixupDefs then asserts that if.end19 dominates
if.then30, which is not true.

Not sure what the right fix is here.

-- 
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 36485] New: Crash when compiling LLVM IR with tons of musttail calls

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36485

Bug ID: 36485
   Summary: Crash when compiling LLVM IR with tons of musttail
calls
   Product: clang
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: fe...@indutny.com
CC: llvm-bugs@lists.llvm.org

Created attachment 19932
  --> https://bugs.llvm.org/attachment.cgi?id=19932=edit
LLVM IR file

0  clang-5.00x0001075c31e7
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
1  clang-5.00x0001075c26ea llvm::sys::RunSignalHandlers() +
83
2  clang-5.00x0001075c360e SignalHandler(int) + 239
3  libsystem_platform.dylib 0x7fff784cef5a _sigtramp + 26
4  libsystem_platform.dylib 00 _sigtramp + 2276659392
5  clang-5.00x000107553049
getCommonReturnValue(llvm::ReturnInst*, llvm::CallInst*) + 120
6  clang-5.00x00010755280a
eliminateRecursiveTailCall(llvm::CallInst*, llvm::ReturnInst*,
llvm::BasicBlock*&, bool&, llvm::SmallVectorImpl&,
llvm::AAResults*) + 735
7  clang-5.00x0001075517b6
eliminateTailRecursion(llvm::Function&, llvm::TargetTransformInfo const*,
llvm::AAResults*) + 2287
8  clang-5.00x00010729c2b4
llvm::FPPassManager::runOnFunction(llvm::Function&) + 276
9  clang-5.00x000106f7cb71 (anonymous
namespace)::CGPassManager::runOnModule(llvm::Module&) + 661
10 clang-5.00x00010729c7a5
llvm::legacy::PassManagerImpl::run(llvm::Module&) + 579
11 clang-5.00x0001076e9df8
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions
const&, clang::CodeGenOptions const&, clang::TargetOptions const&,
clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*,
clang::BackendAction, std::__1::unique_ptr) + 9714
12 clang-5.00x00010781fe97
clang::CodeGenAction::ExecuteAction() + 973
13 clang-5.00x0001079986db clang::FrontendAction::Execute()
+ 73
14 clang-5.00x00010796980b
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 625
15 clang-5.00x0001079c5a66
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2438
16 clang-5.00x0001066f0411 cc1_main(llvm::ArrayRef, char const*, void*) + 1169
17 clang-5.00x0001066eee70 main + 8127
18 libdyld.dylib0x7fff7824e145 start + 1
19 libdyld.dylib0x0033 start + 2279284463
Stack dump:
0.  Program arguments: /usr/local/Cellar/llvm/5.0.1/bin/clang-5.0 -cc1
-triple x86_64-apple-macosx10.13.0 -Wdeprecated-objc-isa-usage
-Werror=deprecated-objc-isa-usage -emit-obj -disable-free
-disable-llvm-verifier -discard-value-names -main-file-name otherwise-skip.ll
-mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim
-masm-verbose -munwind-tables -target-cpu penryn -target-linker-version 305
-dwarf-column-info -debugger-tuning=lldb -resource-dir
/usr/local/Cellar/llvm/5.0.1/lib/clang/5.0.1 -Os -fdebug-compilation-dir
/Users/findutnyy/Code/indutny/llparse -ferror-limit 19 -fmessage-length 178
-stack-protector 1 -fblocks -fobjc-runtime=macosx-10.13.0
-fencode-extended-block-signature -fmax-type-align=16 -fdiagnostics-show-option
-fcolor-diagnostics -vectorize-loops -vectorize-slp -o
/var/folders/7l/34nn743x7hv3pwhp4pjplxxc3kfgkf/T/otherwise-skip-5b8771.o -x ir
test/tmp/otherwise-skip.ll
1.  Per-module optimization passes
2.  Running pass 'CallGraph Pass Manager' on module
'test/tmp/otherwise-skip.ll'.
3.  Running pass 'Tail Call Elimination' on function '@llparse__n_start'
clang-5.0: error: unable to execute command: Segmentation fault: 11
clang-5.0: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 5.0.1 (tags/RELEASE_501/final)
Target: x86_64-apple-darwin17.0.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm/bin

-- 
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 36486] New: clang 5.0.1 coverage crashes on header only unit test project

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36486

Bug ID: 36486
   Summary: clang 5.0.1 coverage crashes on header only unit test
project
   Product: clang
   Version: 5.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Frontend
  Assignee: unassignedclangb...@nondot.org
  Reporter: sebastian.schnei...@sae-it.de
CC: llvm-bugs@lists.llvm.org

Created attachment 19933
  --> https://bugs.llvm.org/attachment.cgi?id=19933=edit
Preprocessed source and associated run script to reproduce crash

when running 

#clang --coverage -g -Wall sample_tests.cpp -o testCov 

clang crashes and writes the following crash dump:






0x00014015D774 (0x0439AE08 0x00013F34061F 0x48665CAA4742
0x0
3280A90)
0x00014015F1CB (0x0200 0x07FE 0x00B50488
0x0
7FEFD841B3B)
0x0001402F2B27 (0x0046 0x 0x00B57C10
0x0
380)
0x0001402F1975 (0x 0x0001401153F5 0x00A7C7B0
0x0
001)
0x000140116091 (0x00A7CAA8 0x 0x48665CAA4742
0x0
000)
0x000140698371 (0x033D3340 0x00B5B4C0 0x00A7DCC0
0x0
0A7DBC0)
0x000141C71708 (0x000142777C61 0x000B 0x0008
0x0
001427764D3)
0x000140F829C2 (0x 0x 0x000D
0x0
0BE55D0)
0x0001409EFDDA (0x07FE0012 0x000142777CC3 0x0009
0x0
013)
0x0001409BB460 (0x00A7DFA8 0x0001409B601B 0x00BFF1F0
0x0
031)
0x000140A3027C (0x00B500010110 0x00BFD2F0 0x00BFB6C0
0x0
0B57C10)
0x00013F315E6B (0x07FEE35D69D8 0x00BD439B 0x00BD4300
0x0
101)
0x00013F314293 (0x 0x 0x
0x0
1D3AC6EABF74634)
0x000141C92D81 (0x 0x 0x
0x0
000)
0x778B59CD (0x 0x 0x
0x0
000), BaseThreadInitThunk() + 0xD bytes(s)
0x77A1383D (0x 0x 0x
0x0
000), RtlUserThreadStart() + 0x1D bytes(s)
clang.exe: error: clang frontend command failed due to signal (use -v to see
inv
ocation)
clang version 5.0.1 (tags/RELEASE_501/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
clang.exe: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/b
ugs/ and include the crash backtrace, preprocessed source, and associated run
sc
ript.
clang.exe: note: diagnostic msg:


PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang.exe: note: diagnostic msg:
C:\Users\SRS\AppData\Local\Temp\sample_tests-c2
39fb.cpp
clang.exe: note: diagnostic msg:
C:\Users\SRS\AppData\Local\Temp\sample_tests-c2
39fb.sh
clang.exe: 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 36475] New: Unexpected change in layout behaviour for synthetic sections in scripts

2018-02-22 Thread via llvm-bugs 
https://bugs.llvm.org/show_bug.cgi?id=36475

Bug ID: 36475
   Summary: Unexpected change in layout behaviour for synthetic
sections in scripts
   Product: lld
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: ELF
  Assignee: unassignedb...@nondot.org
  Reporter: jh7370.2...@my.bristol.ac.uk
CC: llvm-bugs@lists.llvm.org

r325763 led to a change in how synthetic sections behave in layout when there
are no non-empty input sections in their linker script entry, but when there
are other commands, e.g. BYTE or symbol assignments. I'll post on
https://reviews.llvm.org/D43574 to highlight the bit of offending code for
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