date:20171105

[llvm-bugs] Issue 4065 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: (!Is64Bit || isInt<32>((long long)FIOffset + Imm)) && "Requesting 64-bit offset

2017-11-05 Thread monor… via monorail via llvm-bugs


Status: New
Owner: 
CC: k...@google.com,  masc...@google.com,  jdevlieg...@apple.com,   
llvm-b...@lists.llvm.org,  v...@apple.com
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible  
Engine-libfuzzer Proj-llvm Reported-2017-11-05


New issue 4065 by monor...@clusterfuzz-external.iam.gserviceaccount.com:  
llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: (!Is64Bit || isInt<32>((long  
long)FIOffset + Imm)) && "Requesting 64-bit offset

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

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

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

Crash Type: ASSERT
Crash Address:
Crash State:
  (!Is64Bit || isInt<32>((long long)FIOffset + Imm)) && "Requesting 64-bit  
offset

  llvm::X86RegisterInfo::eliminateFrameIndex
  PEI::replaceFrameIndices

Sanitizer: address (ASAN)

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


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


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 35206] New: Clang-cl /Wall doesn't include all warnings

2017-11-05 Thread via llvm-bugs

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

Bug ID: 35206
   Summary: Clang-cl /Wall doesn't include all warnings
   Product: clang
   Version: 5.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: jva...@gmail.com
CC: llvm-bugs@lists.llvm.org

When one looks at the documentation of MSVC for the warnings, it contains
several warning levels /W0-/W4 + /Wall
https://msdn.microsoft.com/en-us/library/thxezb7y.aspx

The documentation of clang-cl
https://clang.llvm.org/docs/UsersManual.html#clang-cl indicates that it
supports the same warning levels by mapping:
/W1-/W3 to -Wall
/W4 and /Wall to -Wall -Wextra

It would be more logical that /Wall would be mapped to -Weverything as /Wall in
MSVC includes all warnings in MSVC, including several warnings its STL
violates.
-Weverything seems like the best fit for these.

-- 
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 35207] New: call to conversion operator instead of converting constructor in c++17 during overload resolution

2017-11-05 Thread via llvm-bugs

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

Bug ID: 35207
   Summary: call to conversion operator instead of converting
constructor in c++17 during overload resolution
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: C++
  Assignee: unassignedclangb...@nondot.org
  Reporter: bruno.bugs.cont...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org

This code compiled by clang trunk with std=c++17 returns 1 
instead of the expected 0 since D::operator C() is called instead of the
apparently better match C::C(const D&). Compiling the code with std=c++14
make this behaviour disappear and 0 is returned as expected.

clang 5 do not have this behaviour.
gcc 7.2 also has this behaviour but 6.4 do not.


Rationale for why 0 should be returned instead of 1 :
(copied from the original post on stackoverflow)

Tentative reading of the standard (latest draft N4687) :

C c(d) is a direct-initialization which is not a copy elision
([dcl.init]/17.6.1). [dcl.init]/17.6.2 tells us that applicable constructors
are enumerated and that the best one is chosen by overload resolution.
[over.match.ctor] tells us that the applicable constructors are in this case
all the constructors.

In this case : C(), C(const C&) and C(const D&) (no move ctor). C() is clearly
not viable and thus is discarded from the overload set. ([over.match.viable])

Constructors have no implicit object parameter and so C(const C&) and C(const
D&) both take exactly one parameter. ([over.match.funcs]/2)

We now go to [over.match.best]. Here we find that we need to determine which of
these two implicit conversion sequences (ICS) is better. The ICS of C(const D&)
only involves a standard conversion sequence, but the ICS of C(const C&)
involves a user-defined conversion sequence.

Therefore C(const D&) should be selected instead of C(const C&).


See the discussion on stackoverflow:
https://stackoverflow.com/questions/47110853/call-to-conversion-operator-instead-of-converting-constructor-in-c17-during-ov

static int ret;
struct D;
struct C {
C() {}
C(const C&) {}
C(const D&) {}
};
struct D {
operator C() { ret = 1; return C();}
};

int main(){
D d;
C c(d);
return ret;
}


clang++ -v output :

/home/bruno/software/llvm-build/bin/clang++ -v -O0 -g -std=c++17 -Wall -Wextra
-Wno-unused -pedantic bug_DoperatorC_CconstDref_minimal.cpp -o
bug_DoperatorC_CconstDref_minimal && ./bug_DoperatorC_CconstDref_minimal 
clang version 6.0.0 (trunk 317422)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/bruno/software/llvm-build/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/7.2.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.2.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.2.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
 "/home/bruno/software/llvm-build/bin/clang-6.0" -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
bug_DoperatorC_CconstDref_minimal.cpp -mrelocation-model static -mthread-model
posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases
-munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info
-debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -v -resource-dir
/home/bruno/software/llvm-build/lib/clang/6.0.0 -internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/x86_64-linux-gnu/c++/7.2.0
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/x86_64-linux-gnu/c++/7.2.0
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/backward
-internal-isystem /usr/local/include -internal-isystem
/home/bruno/software/llvm-build/lib/clang/6.0.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O0
-Wall -Wextra -Wno-unused -pedantic -std=c++17 -fdeprecated-macro
-fdebug-compilation-dir /home/bruno/computer_science

[llvm-bugs] [Bug 35208] New: Hosts.cpp: calls xgetbv before detecting xsave support

2017-11-05 Thread via llvm-bugs

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

Bug ID: 35208
   Summary: Hosts.cpp: calls xgetbv before detecting xsave support
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Support Libraries
  Assignee: unassignedb...@nondot.org
  Reporter: gonzalob...@gmail.com
CC: llvm-bugs@lists.llvm.org

In Hosts.cpp, the following code:

   bool HasAVXSave = ((ECX >> 27) & 1) && ((ECX >> 28) & 1) &&
  !getX86XCR0(&EAX, &EDX) && ((EAX & 0x6) == 0x6);

indirectly calls xgetbv through getX86XCR0 without checking whether the CPU
supports XSAVE before doing so. XSAVE is detected a bit after in: 

// Only enable XSAVE if OS has enabled support for saving YMM state.
Features["xsave"] = HasAVXSave && (ECX >> 26) & 1;

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

[llvm-bugs] [Bug 35209] New: Crash in ::AddressingModeMatcher::matchOperationAddr(llvm::User, unsigned int, unsigned int, bool)

2017-11-05 Thread via llvm-bugs

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

Bug ID: 35209
   Summary: Crash in
::AddressingModeMatcher::matchOperationAddr(llvm::User
*, unsigned int, unsigned int, bool*)
   Product: libraries
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Common Code Generator Code
  Assignee: unassignedb...@nondot.org
  Reporter: arichardson@gmail.com
CC: llvm-bugs@lists.llvm.org

After updating my clang checkout I noticed that the FreeBSD kernel compiled for
QEMU MIPS64 didn't boot anymore due to ata_xpt.c being miscompiled. I worked
around the issue by adding a printf() in
https://github.com/CTSRD-CHERI/cheribsd/commit/44e9de344eebb4dd7f855950f19a895f36d52f91
. With the latest trunk compiling this file now caused a crash and I managed to
bisect it and found that  https://reviews.llvm.org/rL314794 was the first
commit exposing this crash.

Crash backtrace: 
> #0 0x03499044 PrintStackTraceSignalHandler(void*) 
> (./bin/clang+0x3499044)
> #1 0x03499396 SignalHandler(int) (./bin/clang+0x3499396)
> #2 0x7fa9081d1390 __restore_rt 
> (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
> #3 0x02bf3e16 (anonymous 
> namespace)::AddressingModeMatcher::matchOperationAddr(llvm::User*, unsigned 
> int, unsigned int, bool*) (./bin/clang+0x2bf3e16)
> #4 0x02bf3126 (anonymous 
> namespace)::AddressingModeMatcher::matchAddr(llvm::Value*, unsigned int) 
> (./bin/clang+0x2bf3126)
> #5 0x02be8559 (anonymous 
> namespace)::CodeGenPrepare::optimizeMemoryInst(llvm::Instruction*, 
> llvm::Value*, llvm::Type*, unsigned int) (./bin/clang+0x2be8559)
> #6 0x02be12e7 (anonymous 
> namespace)::CodeGenPrepare::optimizeInst(llvm::Instruction*, bool&) 
> (./bin/clang+0x2be12e7)
> #7 0x02bdaaa1 (anonymous 
> namespace)::CodeGenPrepare::runOnFunction(llvm::Function&) 
> (./bin/clang+0x2bdaaa1)
> #8 0x02f9f17f llvm::FPPassManager::runOnFunction(llvm::Function&) 
> (./bin/clang+0x2f9f17f)
> #9 0x02f9f3d3 llvm::FPPassManager::runOnModule(llvm::Module&) 
> (./bin/clang+0x2f9f3d3)
> #10 0x02f9f8d6 llvm::legacy::PassManagerImpl::run(llvm::Module&) 
> (./bin/clang+0x2f9f8d6)
> #11 0x036172cc clang::EmitBackendOutput(clang::DiagnosticsEngine&, 
> clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, 
> clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout 
> const&, llvm::Module*, clang::BackendAction, 
> std::unique_ptr std::default_delete >) (./bin/clang+0x36172cc)
> #12 0x03b1f7d6 
> clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) 
> (./bin/clang+0x3b1f7d6)
> #13 0x041de596 clang::ParseAST(clang::Sema&, bool, bool) 
> (./bin/clang+0x41de596)
> #14 0x03a8e418 clang::FrontendAction::Execute() 
> (./bin/clang+0x3a8e418)
> #15 0x03a21b71 
> clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) 
> (./bin/clang+0x3a21b71)
> #16 0x03b19d30 
> clang::ExecuteCompilerInvocation(clang::CompilerInstance*) 
> (./bin/clang+0x3b19d30)
> #17 0x01f206d6 cc1_main(llvm::ArrayRef, char const*, 
> void*) (./bin/clang+0x1f206d6)
> #18 0x01f1eb82 main (./bin/clang+0x1f1eb82)
> #19 0x7fa906d26830 __libc_start_main 
> /build/glibc-bfm8X4/glibc-2.23/csu/../csu/libc-start.c:325:0
> #20 0x01f1c029 _start (./bin/clang+0x1f1c029)
> Stack dump:
> 0.  Program arguments: ./bin/clang -cc1 -internal-isystem 
> /local/scratch/alr48/cheri/build/upstream-llvm-build/lib/clang/6.0.0/include 
> -nostdsysteminc -triple mips64-unknown-freebsd12.0 -emit-obj 
> -mrelocation-model static -ffreestanding -target-cpu mips64 -target-abi n64 
> -mllvm -mips-ssection-threshold=0 -mllvm -mgpopt -target-linker-version 302.3 
> -coverage-notes-file 
> /Users/alex/cheri/build/freebsd-mips-build/Users/alex/cheri/freebsd-mips/mips.mips64/sys/MALTA64/ata_xpt.gcno
>  -nostdsysteminc -nobuiltininc -sys-header-deps -D _KERNEL -D 
> HAVE_KERNEL_OPTION_HEADERS -D KERNLOADADDR=0x8010 -D 
> __printf__=__freebsd_kprintf__ -O2 -Wall -Wredundant-decls -Wnested-externs 
> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual 
> -Wundef -Wno-pointer-sign -Wmissing-include-dirs -Wno-unknown-pragmas 
> -Wno-error-tautological-compare -Wno-error-empty-body 
> -Wno-error-parentheses-equality -Wno-error-unused-function 
> -Wno-error-pointer-sign -Wno-error-shift-negative-value 
> -Wno-error-address-of-packed-member -Werror -std=iso9899:1999 -fwrapv 
> -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /dev/null 
> /local/scratch/alr48/cheri/upstream-llvm/tools/clang/test/CodeGen/ata_xpt-bdf4d9-reduce.test.c
> 1.   parser at end of file
> 2.  Code generation
> 3.  Running pass 'Function Pass Manager' on module 
> '/local/scratch/alr48/cheri/ups

[llvm-bugs] [Bug 35210] New: Crash from r316869

2017-11-05 Thread via llvm-bugs

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

Bug ID: 35210
   Summary: Crash from r316869
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: release blocker
  Priority: P
 Component: Scalar Optimizations
  Assignee: unassignedb...@nondot.org
  Reporter: d...@google.com
CC: llvm-bugs@lists.llvm.org

(Somewhat) reduced test case:
https://reviews.llvm.org/P8043

=
template 
struct TempPtr {
  explicit TempPtr(T* ptr) : p_(ptr) {}
  ~TempPtr() { delete p_; }
  T* leak() const {
T* ptr = p_;
p_ = 0;
return ptr;
  }
  mutable T* p_;
};

template 
struct Ptr {
  Ptr(TempPtr&& o) : p_(o.leak()) {}
  TempPtr release() {
T* ptr = p_;
p_ = 0;
return TempPtr(ptr);
  }
  T* operator->() const {
if (!p_) __builtin_trap();
return p_;
  }
  operator bool() const { return p_; }

  T* p_;
};

struct C {
  ~C();
  Ptr x_;
};

struct Deleter {
  void handle(TempPtr&&);
};

C::~C()
{
  if (!x_)
return;
  Deleter d;
  Ptr current = x_.release();
  while (true) {
Ptr next = current->x_.release();
d.handle(current.release());
if (!next)
  break;
current = next.release();
  }
}
=

bin/clang -cc1 -triple x86_64-grtev4-linux-gnu -emit-obj -O3 -std=gnu++11
-fexperimental-new-pass-manager -x c++ crasher.cc


Gives me this error (edited for brevity):

=
#0 llvm::sys::RunSignalHandlers()
#1 SignalHandler(int)
#2 __restore_rt
#3 llvm::IDFCalculator,
true>::calculate(llvm::SmallVectorImpl&)
#4 (anonymous
namespace)::AggressiveDeadCodeElimination::performDeadCodeElimination()
#5 llvm::ADCEPass::run(llvm::Function&, llvm::AnalysisManager&)
#6 llvm::detail::PassModel>::run(llvm::Function&,
llvm::AnalysisManager&)
#7 llvm::PassManager>::run(llvm::Function&,
llvm::AnalysisManager&)
#8 llvm::CGSCCToFunctionPassAdaptor> >::run(llvm::LazyCallGraph::SCC&,
llvm::AnalysisManager&,
llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&)
#9 llvm::detail::PassModel> >, llvm::PreservedAnalyses,
llvm::AnalysisManager,
llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&,
llvm::AnalysisManager&,
llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&)
#10 llvm::PassManager,
llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&,
llvm::AnalysisManager&,
llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&)
#11 llvm::DevirtSCCRepeatedPass,
llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>
>::run(llvm::LazyCallGraph::SCC&,
llvm::AnalysisManager&,
llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&)
#12
llvm::ModuleToPostOrderCGSCCPassAdaptor,
llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&> > >::run(llvm::Module&,
llvm::AnalysisManager&)
#13 llvm::detail::PassModel,
llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&> > >, llvm::PreservedAnalyses,
llvm::AnalysisManager>::run(llvm::Module&,
llvm::AnalysisManager&)
#14 llvm::PassManager>::run(llvm::Module&,
llvm::AnalysisManager&)
#15 llvm::detail::PassModel>, llvm::PreservedAnalyses,
llvm::AnalysisManager>::run(llvm::Module&,
llvm::AnalysisManager&)
#16 llvm::PassManager>::run(llvm::Module&,
llvm::AnalysisManager&)
#17 clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout
const&, llvm::Module*, clang::BackendAction,
std::unique_ptr >)
#18 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
#19 clang::ParseAST(clang::Sema&, bool, bool)
#20 clang::FrontendAction::Execute()
#21 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
#22 clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
#23 cc1_main(llvm::ArrayRef, char const*, void*)
#24 main
#25 __libc_start_main
#26 _start
Stack dump:
0.  Program arguments: bin/clang -cc1 -triple x86_64-grtev4-linux-gnu
-emit-obj -O3 -std=gnu++11 -fexperimental-new-pass-manager -x c++
/tmp/crasher.cpp
1.   parser at end of file
2.  Optimizer
=

Reverting r316869 fixes the crash.

-- 
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 35211] New: Incorrect store to load forwarding for noalias pointer across return_twice functions

2017-11-05 Thread via llvm-bugs

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

Bug ID: 35211
   Summary: Incorrect store to load forwarding for noalias pointer
across return_twice functions
   Product: libraries
   Version: 5.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Scalar Optimizations
  Assignee: unassignedb...@nondot.org
  Reporter: yyc1...@gmail.com
CC: llvm-bugs@lists.llvm.org

The IR repro independent of C code is,

```
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

; Function Attrs: noinline nounwind sspstrong uwtable
define i32 @f(i32) #0 {
  %2 = call noalias i32* @alloc(i64 4) #1
  store i32 %0, i32* %2, align 4
  %3 = call i32 @enter() #2
  %4 = icmp eq i32 %3, 0
  br i1 %4, label %5, label %6

; :5:  ; preds = %1
  store i32 1, i32* %2, align 4
  call void @throw() #3
  unreachable

; :6:  ; preds = %1
  %7 = load i32, i32* %2, align 4
  ret i32 %7
}

; Function Attrs: nounwind
declare noalias i32* @alloc(i64) #1

; Function Attrs: nounwind returns_twice
declare i32 @enter() #2

; Function Attrs: noreturn nounwind
declare void @throw() #3

attributes #0 = { noinline nounwind sspstrong uwtable }
attributes #1 = { nounwind }
attributes #2 = { nounwind returns_twice }
attributes #3 = { noreturn nounwind }
```

This is optimized by GVN to

```
define i32 @f(i32) #0 {
  %2 = call noalias i32* @alloc(i64 4) #1
  store i32 %0, i32* %2, align 4
  %3 = call i32 @enter() #2
  %4 = icmp eq i32 %3, 0
  br i1 %4, label %5, label %6

; :5:  ; preds = %1
  store i32 1, i32* %2, align 4
  call void @throw() #3
  unreachable

; :6:  ; preds = %1
  ret i32 %0
}
```

Which is wrong since the `enter` may return a second time after the store of
`1`.

The issue is obviously fixed if the store and load are marked as volatile but
those should only be needed for stack addresses.

A C repro is,

```
#include 
#include 

int f(int b)
{
jmp_buf buf;
int *p = (int*)malloc(sizeof(int));
*p = b;
if (setjmp(buf) == 0) {
*p = 1;
longjmp(buf, 1);
}
int c = *p;
free(p);
return c;
}
```

Which is optimized by `clang -O3` to
```
define i32 @f(i32) local_unnamed_addr #0 {
  %2 = alloca [1 x %struct.__jmp_buf_tag], align 16
  %3 = bitcast [1 x %struct.__jmp_buf_tag]* %2 to i8*
  call void @llvm.lifetime.start.p0i8(i64 200, i8* nonnull %3) #4
  %4 = getelementptr inbounds [1 x %struct.__jmp_buf_tag], [1 x
%struct.__jmp_buf_tag]* %2, i64 0, i64 0
  %5 = call i32 @_setjmp(%struct.__jmp_buf_tag* nonnull %4) #5
  %6 = icmp eq i32 %5, 0
  br i1 %6, label %7, label %8

; :7:  ; preds = %1
  call void @longjmp(%struct.__jmp_buf_tag* nonnull %4, i32 1) #6
  unreachable

; :8:  ; preds = %1
  call void @llvm.lifetime.end.p0i8(i64 200, i8* nonnull %3) #4
  ret i32 %0
}
```

In this case, I believe it is clear from the C spec that the optimization is
illegal, without assuming any llvm specific semantic of `noalias` which the
LLVM IR case above relies on.

This is similar to https://bugs.llvm.org/show_bug.cgi?id=21183 but is an IR
level bug and not limited to a particular backend.

-- 
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 35161] [X86] Legacy scalar sqrt, rsqrt, and rcp intrinsics should select EVEX instructions when available

2017-11-05 Thread via llvm-bugs

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

Craig Topper  changed:

   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 35212] New: ThinLTO-generated IR yields dwarfdump error

2017-11-05 Thread via llvm-bugs

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

Bug ID: 35212
   Summary: ThinLTO-generated IR yields dwarfdump error
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: DebugInfo
  Assignee: unassignedb...@nondot.org
  Reporter: a...@crichton.co
CC: llvm-bugs@lists.llvm.org

Created attachment 19373
  --> https://bugs.llvm.org/attachment.cgi?id=19373&action=edit
minimized IR

This is a minimization of an upstream issue at
https://github.com/rust-lang/rust/issues/45511 where the Rust compiler, when
using ThinLTO, generates DWARF information that the `dwarfdump` program
interprets as invalid.

I managed to minimize to the attached IR. The IR attached has been reduced via
machines (creduce on Rust source code, bugpoint on LLVM IR) and also by hand.
As a result this isn't really a direct translation of anything in Rust but
rather an "artisinal" reduction which may or may not have invalidated the
reduction itself along the way.

I unfortunately know very little about DWARF much less dwarfdump. I'm operating
under the assumption that anything accepted by LLVM *shouldn't* generate an
error with dwarfdump, but that may also be totally wrong! If so, please just
let me know!

In any case, I can reproduce the error via:


$ llc -filetype=obj -O0 foo.ll -o foo.o
$ dwarfdump -i foo.o > /dev/null

dwarfdump ERROR:  reference form with no valid local ref?!,
offset=<0x0078>:  DW_DLE_ATTR_FORM_OFFSET_BAD (119)

-- 
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 35213] New: mrs ip, psr invalid operand for instruction

2017-11-05 Thread via llvm-bugs

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

Bug ID: 35213
   Summary: mrs ip, psr invalid operand for instruction
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Backend: ARM
  Assignee: unassignedb...@nondot.org
  Reporter: lesliez...@llvm.org.cn
CC: llvm-bugs@lists.llvm.org

Hi LLVM developers,

$ /opt/llvm-svn/bin/llvm-mc -filetype=obj -triple=thumbv7m context_switch.S -o
context_switch.o
context_switch.S:7:10: error: invalid operand for instruction
mrs ip, psr
^


context_switch.S  
https://github.com/jserv/mini-arm-os/blob/master/02-ContextSwitch-1/context_switch.S#L7


$ /opt/llvm-svn/bin/llvm-mc --version
LLVM (http://llvm.org/):
  LLVM version 6.0.0svn
  Optimized build.
  Default target: x86_64-redhat-linux
  Host CPU: sandybridge

  Registered Targets:
aarch64- AArch64 (little endian)
aarch64_be - AArch64 (big endian)
amdgcn - AMD GCN GPUs
arc- ARC
arm- ARM
arm64  - ARM64 (little endian)
armeb  - ARM (big endian)
avr- Atmel AVR Microcontroller
bpf- BPF (host endian)
bpfeb  - BPF (big endian)
bpfel  - BPF (little endian)
hexagon- Hexagon
lanai  - Lanai
mips   - Mips
mips64 - Mips64 [experimental]
mips64el   - Mips64el [experimental]
mipsel - Mipsel
msp430 - MSP430 [experimental]
nvptx  - NVIDIA PTX 32-bit
nvptx64- NVIDIA PTX 64-bit
ppc32  - PowerPC 32
ppc64  - PowerPC 64
ppc64le- PowerPC 64 LE
r600   - AMD GPUs HD2XXX-HD6XXX
sparc  - Sparc
sparcel- Sparc LE
sparcv9- Sparc V9
systemz- SystemZ
thumb  - Thumb
thumbeb- Thumb (big endian)
x86- 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
xcore  - XCore


But GNU cross-compile toolchain is able to work:
$ gcc-arm-none-eabi-6-2017-q2-update/bin/arm-none-eabi-gcc -fno-common
-ffreestanding -O0 -gdwarf-2 -g3 -Wall -Werror -mcpu=cortex-m3 -mthumb
-Wl,-Tos.ld -nostartfiles  os.c startup.c context_switch.S -o os.elf

Regards,
Leslie Zhai

-- 
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 4065 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: (!Is64Bit || isInt<32>((long long)FIOffset + Imm)) && "Requesting 64-bit offset

[llvm-bugs] [Bug 35206] New: Clang-cl /Wall doesn't include all warnings

[llvm-bugs] [Bug 35207] New: call to conversion operator instead of converting constructor in c++17 during overload resolution

[llvm-bugs] [Bug 35208] New: Hosts.cpp: calls xgetbv before detecting xsave support

[llvm-bugs] [Bug 35209] New: Crash in ::AddressingModeMatcher::matchOperationAddr(llvm::User, unsigned int, unsigned int, bool)

[llvm-bugs] [Bug 35210] New: Crash from r316869

[llvm-bugs] [Bug 35211] New: Incorrect store to load forwarding for noalias pointer across return_twice functions

[llvm-bugs] [Bug 35161] [X86] Legacy scalar sqrt, rsqrt, and rcp intrinsics should select EVEX instructions when available

[llvm-bugs] [Bug 35212] New: ThinLTO-generated IR yields dwarfdump error

[llvm-bugs] [Bug 35213] New: mrs ip, psr invalid operand for instruction

10 matches

Site Navigation

Mail list logo

Footer information