date:20201209

[llvm-bugs] [Bug 48436] Add CSKY backend component

2020-12-09 Thread via llvm-bugs

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

Kristof Beyls  changed:

   What|Removed |Added

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

--- Comment #1 from Kristof Beyls  ---
I've just created that component.
Please check if everything seems to be done as expected.

Thanks,

Kristof

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

[llvm-bugs] [Bug 48449] New: "WebAssembly Fix Irreducible Control Flow" pass OOMs on a huge function

2020-12-09 Thread via llvm-bugs

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

Bug ID: 48449
   Summary: "WebAssembly Fix Irreducible Control Flow" pass OOMs
on a huge function
   Product: new-bugs
   Version: 11.0
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: mej...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org

Created attachment 24250
  --> https://bugs.llvm.org/attachment.cgi?id=24250&action=edit
LLVM IR that causes OOM

Clang/lib/AST/Interp/Disasm.cpp takes excessive time and resources to compile
when targeting WebAssembly. Memory usage exceeds 10GiB. It tends to OOM in
smaller machines.

The frontend completes without issues.

When running

clang -c Disasm.bc -mllvm -debug-pass=Executions

the last line printed before OOM is

[2020-12-08 19:16:08.463129734] 0x2d4fc70 Executing Pass 'WebAssembly Fix
Irreducible Control Flow' on Function
'_ZNK5clang6interp8Function4dumpERN4llvm11raw_ostreamE'

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

[llvm-bugs] [Bug 48450] New: Simplify CFG pass generatres invalid IR when -bonus-inst-threshold=2

2020-12-09 Thread via llvm-bugs

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

Bug ID: 48450
   Summary: Simplify CFG pass generatres invalid IR when
-bonus-inst-threshold=2
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: Transformation Utilities
  Assignee: unassignedb...@nondot.org
  Reporter: markus.la...@ericsson.com
CC: llvm-bugs@lists.llvm.org

Created attachment 24251
  --> https://bugs.llvm.org/attachment.cgi?id=24251&action=edit
Reproducer input.

opt -mcpu=phoenixIV -simplifycfg -bonus-inst-threshold=2 input.ll -S
-verify-each

Instruction does not dominate all uses!
  %dec = add nsw i16 %i.01, -1
  %i.01 = phi i16 [ %dec, %for.bodythread-pre-split ], [ 1, %entry ]
in function f
LLVM ERROR: Broken function found, compilation aborted!

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

[llvm-bugs] [Bug 48451] New: clang fails to build llvm-11.0.0 32-bit in 32-bit mode when XOP instructions are enabled

2020-12-09 Thread via llvm-bugs

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

Bug ID: 48451
   Summary: clang fails to build llvm-11.0.0 32-bit in 32-bit mode
when XOP instructions are enabled
   Product: clang
   Version: 11.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: LLVM Codegen
  Assignee: unassignedclangb...@nondot.org
  Reporter: mar...@cs.wisc.edu
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk

Created attachment 24252
  --> https://bugs.llvm.org/attachment.cgi?id=24252&action=edit
temp-015dcb.c

I was having trouble building llvm-11 with clang. I tried using clang 9-11 and
each failed with the same error. This is with the Gentoo-built packages, but
hopefully my repro is good enough.

The XOP instructions are enabled when using -march=native on an AMD fam15h CPU,
such as what I have. These instructions aren't supported on any other family of
CPUs, not before or after fam15h. My workaround was to use `-march=native
-mno-xop`, so I got clang 11 to build after all.

Repro:

cat >test.c <DAG Instruction Selection' on function '@main'
 #0 0x7fcb37c4411c
(/usr/lib/llvm/11/bin/../lib64/libLLVM-11libcxx.so+0x17b411c)
 #1 0x7fcb37c417a0 llvm::sys::RunSignalHandlers()
(/usr/lib/llvm/11/bin/../lib64/libLLVM-11libcxx.so+0x17b17a0)
 #2 0x7fcb37c4320d llvm::sys::CleanupOnSignal(unsigned long)
(/usr/lib/llvm/11/bin/../lib64/libLLVM-11libcxx.so+0x17b320d)
 #3 0x7fcb37b6d3f3
(/usr/lib/llvm/11/bin/../lib64/libLLVM-11libcxx.so+0x16dd3f3)
 #4 0x7fcb3d4624b0 __restore_rt (/lib64/libpthread.so.0+0x124b0)
 #5 0x7fcb360a84f1 raise (/lib64/libc.so.6+0x384f1)
 #6 0x7fcb36092536 abort (/lib64/libc.so.6+0x22536)
 #7 0x7fcb363a6fbe (/usr/lib64/libc++abi.so.1+0x36fbe)
 #8 0x7fcb363899a4 (/usr/lib64/libc++abi.so.1+0x199a4)
 #9 0x7fcb363a60f3 (/usr/lib64/libc++abi.so.1+0x360f3)
#10 0x7fcb363a8dc6 (/usr/lib64/libc++abi.so.1+0x38dc6)
#11 0x7fcb363a8d70 (/usr/lib64/libc++abi.so.1+0x38d70)
#12 0x7fcb36466545 (/usr/lib64/libc++.so.1+0xae545)
#13 0x7fcb364746dd (/usr/lib64/libc++.so.1+0xbc6dd)
#14 0x7fcb399c7dbc
(/usr/lib/llvm/11/bin/../lib64/libLLVM-11libcxx.so+0x3537dbc)
#15 0x7fcb383183f3
(/usr/lib/llvm/11/bin/../lib64/libLLVM-11libcxx.so+0x1e883f3)
#16 0x7fcb382fab75
(/usr/lib/llvm/11/bin/../lib64/libLLVM-11libcxx.so+0x1e6ab75)
#17 0x7fcb38319f8f llvm::SelectionDAG::LegalizeTypes()
(/usr/lib/llvm/11/bin/../lib64/libLLVM-11libcxx.so+0x1e89f8f)
#18 0x7fcb38429a48 llvm::SelectionDAGISel::CodeGenAndEmitDAG()
(/usr/lib/llvm/11/bin/../lib64/libLLVM-11libcxx.so+0x1f99a48)
#19 0x7fcb38429053
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
(/usr/lib/llvm/11/bin/../lib64/libLLVM-11libcxx.so+0x1f99053)
#20 0x7fcb38426190
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(/usr/lib/llvm/11/bin/../lib64/libLLVM-11libcxx.so+0x1f96190)
#21 0x7fcb39925417
(/usr/lib/llvm/11/bin/../lib64/libLLVM-11libcxx.so+0x3495417)
#22 0x7fcb37fb0efd
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/usr/lib/llvm/11/bin/../lib64/libLLVM-11libcxx.so+0x1b20efd)
#23 0x7fcb37d9425c llvm::FPPassManager::runOnFunction(llvm::Function&)
(/usr/lib/llvm/11/bin/../lib64/libLLVM-11libcxx.so+0x190425c)
#24 0x7fcb37d9bfe3 llvm::FPPassManager::runOnModule(llvm::Module&)
(/usr/lib/llvm/11/bin/../lib64/libLLVM-11libcxx.so+0x190bfe3)
#25 0x7fcb37d949e1 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/usr/lib/llvm/11/bin/../lib64/libLLVM-11libcxx.so+0x19049e1)
#26 0x7fcb3bf5120b 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 >)
(/usr/lib/llvm/11/bin/../lib64/libclang-cpp.so.11libcxx+0x1fb120b)
#27 0x7fcb3c23d516
(/usr/lib/llvm/11/bin/../lib64/libclang-cpp.so.11libcxx+0x229d516)
#28 0x7fcb3af46854 clang::ParseAST(clang::Sema&, bool, bool)
(/usr/lib/llvm/11/bin/../lib64/libclang-cpp.so.11libcxx+0xfa6854)
#29 0x7fcb3cb29854 clang::FrontendAction::Execute()
(/usr/lib/llvm/11/bin/../lib64/libclang-cpp.so.11libcxx+0x2b89854)
#30 0x7fcb3cab7211
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/usr/lib/llvm/11/bin/../lib64/libclang-cpp.so.11libcxx+0x2b17211)
#31 0x7fcb3cb9f460
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/usr/lib/llvm/11/bin/../lib64/libclang-cpp.so.1

[llvm-bugs] [Bug 48452] New: clang-tblgen crashing on x86_64 x32 ABI

2020-12-09 Thread via llvm-bugs

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

Bug ID: 48452
   Summary: clang-tblgen crashing on x86_64 x32 ABI
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: glaub...@physik.fu-berlin.de
CC: craig.top...@gmail.com, har...@gigawatt.nl,
jrt...@jrtc27.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, pengfei.w...@intel.com,
spatel+l...@rotateright.com

Just tried a full bootstrap on Debian x32 which failed with clang-tblgen
segfaulting with the following backtrace:

(gdb) r
Starting program:
/glaubitz/llvm-project/build/tools/clang/stage2-bins/bin/clang-tblgen
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnux32/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0056089b in std::call_once (__once=..., __f=@0x560540: {void
(void)} 0x560540 )
at /usr/lib/gcc/x86_64-linux-gnux32/10/../../../../include/c++/10/mutex:722
722   __once_call = []{ (*(decltype(__callable)*)__once_callable)(); };
(gdb) bt
#0  0x0056089b in std::call_once (__once=..., __f=@0x560540: {void
(void)} 0x560540 )
at /usr/lib/gcc/x86_64-linux-gnux32/10/../../../../include/c++/10/mutex:722
#1  0x0056082a in llvm::call_once (flag=..., F=@0x560540: {void
(void)} 0x560540 )
at /glaubitz/llvm-project/llvm/include/llvm/Support/Threading.h:121
#2  0x005603f4 in getManagedStaticMutex () at
/glaubitz/llvm-project/llvm/lib/Support/ManagedStatic.cpp:29
#3  0x005602bd in llvm::ManagedStaticBase::RegisterManagedStatic (this=0x7d70e0
,
Creator=0x53c5b0 ::call()>,
Deleter=0x53c5e0 ::call(void*)>) at
/glaubitz/llvm-project/llvm/lib/Support/ManagedStatic.cpp:37
#4  0x0053c5a0 in llvm::ManagedStatic<(anonymous namespace)::CommandLineParser,
llvm::object_creator<(anonymous namespace)::CommandLineParser>,
llvm::object_deleter<(anonymous namespace)::CommandLineParser> >::operator*
(this=0x7d70e0 ) at
/glaubitz/llvm-project/llvm/include/llvm/Support/ManagedStatic.h:89
#5  0x0052eeb3 in llvm::ManagedStatic<(anonymous namespace)::CommandLineParser,
llvm::object_creator<(anonymous namespace)::CommandLineParser>,
llvm::object_deleter<(anonymous namespace)::CommandLineParser> >::operator->
(this=0x7d70e0 ) at
/glaubitz/llvm-project/llvm/include/llvm/Support/ManagedStatic.h:94
#6  0x0052ee7c in llvm::cl::AddLiteralOption (O=..., Name=...) at
/glaubitz/llvm-project/llvm/lib/Support/CommandLine.cpp:437
#7  0x0051bbad in llvm::cl::parser::addLiteralOption
(this=0x7d6ae8 <(anonymous namespace)::Action+104>, Name=..., V=@0x7ddbb8: 0,
HelpStr=...)
at /glaubitz/llvm-project/llvm/include/llvm/Support/CommandLine.h:847
#8  0x0051ba42 in llvm::cl::ValuesClass::apply > > (this=0xd960, O=...)
at /glaubitz/llvm-project/llvm/include/llvm/Support/CommandLine.h:676
#9  0x0051b9bb in
llvm::cl::applicator::opt > > (M=..., O=...)
at /glaubitz/llvm-project/llvm/include/llvm/Support/CommandLine.h:1244
#10 0x0051b94b in llvm::cl::apply >, llvm::cl::ValuesClass> (O=0x7d6a80 <(anonymous
namespace)::Action>,
M=...) at
/glaubitz/llvm-project/llvm/include/llvm/Support/CommandLine.h:1298
#11 0x0051b0dc in llvm::cl::apply >, llvm::cl::desc, llvm::cl::ValuesClass> (
O=0x7d6a80 <(anonymous namespace)::Action>, M=..., Ms=...) at
/glaubitz/llvm-project/llvm/include/llvm/Support/CommandLine.h:1294
#12 0x0051936b in llvm::cl::opt
>::opt (
this=0x7d6a80 <(anonymous namespace)::Action>, Ms=..., Ms=...) at
/glaubitz/llvm-project/llvm/include/llvm/Support/CommandLine.h:1485
#13 0x00408806 in __cxx_global_var_init () at
/glaubitz/llvm-project/clang/utils/TableGen/TableGen.cpp:94
#14 0x004088b8 in _GLOBAL__sub_I_TableGen.cpp () at
/glaubitz/llvm-project/clang/utils/TableGen/TableGen.cpp:246
#15 0x0067d47b in __libc_csu_init ()
#16 0xf7ac1d39 in __libc_start_main (main=, argc=1,
argv=, init=, fini=,
rtld_fini=,
stack_end=0xdaf8) at ../csu/libc-start.c:264
#17 0x0040999b in _start ()
(gdb)

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

[llvm-bugs] [Bug 48453] New: Assigning to non-active trivial union member is not accepted in constexpr context

2020-12-09 Thread via llvm-bugs

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

Bug ID: 48453
   Summary: Assigning to non-active trivial union member is not
accepted in constexpr context
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: C++2a
  Assignee: unassignedclangb...@nondot.org
  Reporter: m.cenc...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk

Following program fails to compile in C++20 mode.
gcc accepts this code without any workarounds.

Even if following expression 'un.f2.f2 = true;' does not implicitly initialize
un.f2 (which I think it should according to language rules), then WORKAROUND1
should fix it, but it still doesn't work.

Passing -DWORKAROUND2 is needed to make this compile on clang.

#include 

union Un
{
constexpr Un() {}

char f1;
union NestedUn
{
constexpr NestedUn() {}

int f1;
bool f2;
} f2;
};

constexpr bool test()
{
Un un;
#ifdef WORKAROUND1
un.f2 = {};
#elif WORKAROUND2
std::construct_at(&un.f2);
#endif
un.f2.f2 = true;
return un.f2.f2;
}

static_assert(test());

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

[llvm-bugs] [Bug 48454] New: llc segfaults when run on my .ll file to generate a BPF object

2020-12-09 Thread via llvm-bugs

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

Bug ID: 48454
   Summary: llc segfaults when run on my .ll file to generate a
BPF object
   Product: new-bugs
   Version: 11.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: sh...@tigera.io
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org

I was previously using a much older version of clang that was shipped with
debian buster.  I tried upgrading to version 11 from the llvm APT repository
and it segfaults when trying to link my BPF program:

PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0.  Program arguments: llc-11 -march=bpf -filetype=obj -o
bin/from_wg_debug.o from_wg_debug.ll 
1.  Running pass 'Function Pass Manager' on module 'from_wg_debug.ll'.
2.  Running pass 'Live Variable Analysis' on function '@tc_calico_entry'
/usr/lib/x86_64-linux-gnu/libLLVM-11.so.1(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x1f)[0x7f4892e1edff]
/usr/lib/x86_64-linux-gnu/libLLVM-11.so.1(_ZN4llvm3sys17RunSignalHandlersEv+0x50)[0x7f4892e1d170]
/usr/lib/x86_64-linux-gnu/libLLVM-11.so.1(+0xbbb2d5)[0x7f4892e1f2d5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7f4892255730]
/usr/lib/x86_64-linux-gnu/libLLVM-11.so.1(_ZN4llvm13LiveVariables16HandleVirtRegUseEjPNS_17MachineBasicBlockERNS_12MachineInstrE+0x6e)[0x7f489309903e]
/usr/lib/x86_64-linux-gnu/libLLVM-11.so.1(_ZN4llvm13LiveVariables10runOnInstrERNS_12MachineInstrERNS_15SmallVectorImplIjEE+0x23e)[0x7f489309b25e]
/usr/lib/x86_64-linux-gnu/libLLVM-11.so.1(_ZN4llvm13LiveVariables10runOnBlockEPNS_17MachineBasicBlockEj+0x266)[0x7f489309b666]
/usr/lib/x86_64-linux-gnu/libLLVM-11.so.1(_ZN4llvm13LiveVariables20runOnMachineFunctionERNS_15MachineFunctionE+0x32f)[0x7f489309bcff]
/usr/lib/x86_64-linux-gnu/libLLVM-11.so.1(_ZN4llvm19MachineFunctionPass13runOnFunctionERNS_8FunctionE+0x10e)[0x7f48930f330e]
/usr/lib/x86_64-linux-gnu/libLLVM-11.so.1(_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE+0x3b9)[0x7f4892f2e7f9]
/usr/lib/x86_64-linux-gnu/libLLVM-11.so.1(_ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE+0x33)[0x7f4892f33e23]
/usr/lib/x86_64-linux-gnu/libLLVM-11.so.1(_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE+0x3e0)[0x7f4892f2ee10]
llc-11(main+0x2242)[0x40e0f2]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f4891d8509b]
llc-11(_start+0x2a)[0x40ba2a]
make: *** [Makefile:90: bin/from_wg_debug.o] Segmentation fault (core dumped)

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

[llvm-bugs] [Bug 48456] New: wrong code with "-early-cse-memssa -jump-threading -loop-unroll -correlated-propagation -dse"

2020-12-09 Thread via llvm-bugs

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

Bug ID: 48456
   Summary: wrong code with "-early-cse-memssa -jump-threading
-loop-unroll -correlated-propagation -dse"
   Product: new-bugs
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: new bugs
  Assignee: unassignedb...@nondot.org
  Reporter: suochen...@163.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org

Created attachment 24254
  --> https://bugs.llvm.org/attachment.cgi?id=24254&action=edit
bc file

***
OS and Platform:
CentOS Linux release 7.8.2003 (Core), x86_64 GNU/Linux
***
Program:
$ cat a.c
int printf(const char *, ...);
int a=0;
static int b(int *c) {
  char d;
  int e, f;
  int g[1];
  f = 0;
  for (; f < 1; f++)
g[f] = 0;
  *c = g[0];
}
int main() {
  int e;
  int *h = &a;
  b(h);
  printf("%d\n", a);
}
***
clang version:
$ clang --version
clang version 12.0.0 (/home/suocy/src/llvm-dev/llvm-project/llvm/tools/clang
64e7685368894742517524878716184a8cd3ba9b)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/suocy/bin/llvm-dev/bin
***
Command Lines:
$ clang -c -emit-llvm -O3 -mllvm -disable-llvm-optzns a.c -o a.bc
a.c:11:1: warning: non-void function does not return a value [-Wreturn-type]
}
^
1 warning generated.
$ opt a.bc -o a.opt1.bc
$ opt -early-cse-memssa -jump-threading -loop-unroll -correlated-propagation
-dse a.bc -o a.opt2.bc
$ clang a.opt1.bc -o a1.o
$ clang a.opt2.bc -o a2.o
$ ./a1.o
0
$ ./a2.o
32767

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

[llvm-bugs] [Bug 46983] [SLP] Failure to account for truncating stores in MinVF calculation

2020-12-09 Thread via llvm-bugs

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

Anton Afanasyev  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Fixed By Commit(s)||https://reviews.llvm.org/rG
   ||e5bf2e8989469ec328d910be26b
   ||d3ee0710326d9
 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 46968] Missed SLP vectorization with umin/umax

2020-12-09 Thread via llvm-bugs

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

Bug 46983 Summary: [SLP] Failure to account for truncating stores in MinVF 
calculation
https://bugs.llvm.org/show_bug.cgi?id=46983

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

[llvm-bugs] [Bug 48458] New: isREXExtendedReg called on non-reg operand of MRMDestMem

2020-12-09 Thread via llvm-bugs

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

Bug ID: 48458
   Summary: isREXExtendedReg called on non-reg operand of
MRMDestMem
   Product: libraries
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Backend: X86
  Assignee: unassignedb...@nondot.org
  Reporter: tim.bes...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, pengfei.w...@intel.com,
spatel+l...@rotateright.com

The following IR violates an assertion in the x86 machine code emitter on
current trunk:

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

define i1 @foo(i64* %0) {
top:
  %1 = load i64, i64* %0, !range !0
  %2 = icmp ult i64 %1, 2147483648
  ret i1 %2
}

!0 = !{i64 0, i64 100}
```

The assertion and backtrace:

llc: llvm/include/llvm/MC/MCInst.h:65: unsigned int llvm::MCOperand::getReg()
const: Assertion `isReg() && "This is not a register operand!"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0.  Program arguments: ./bin/llc ../wip.ll
1.  Running pass 'Function Pass Manager' on module '../wip.ll'.
2.  Running pass 'X86 Assembly Printer' on function '@foo'
 #0 0x7f2d65e9914d llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
llvm/lib/Support/Unix/Signals.inc:567:3
 #1 0x7f2d65e96fe4 llvm::sys::RunSignalHandlers()
llvm/lib/Support/Signals.cpp:71:20
 #2 0x7f2d65e97825 SignalHandler(int)
llvm/lib/Support/Unix/Signals.inc:395:31
 #3 0x7f2d680fa700 __restore_rt
(/nix/store/5didcr1sjp2rlx8abbzv92rgahsarqd9-glibc-2.32/lib/libpthread.so.0+0x12700)
 #4 0x7f2d6582441a raise
(/nix/store/5didcr1sjp2rlx8abbzv92rgahsarqd9-glibc-2.32/lib/libc.so.6+0x3841a)
 #5 0x7f2d6580e523 abort
(/nix/store/5didcr1sjp2rlx8abbzv92rgahsarqd9-glibc-2.32/lib/libc.so.6+0x22523)
 #6 0x7f2d6580e41f _nl_load_domain.cold.0
(/nix/store/5didcr1sjp2rlx8abbzv92rgahsarqd9-glibc-2.32/lib/libc.so.6+0x2241f)
 #7 0x7f2d6581cd52
(/nix/store/5didcr1sjp2rlx8abbzv92rgahsarqd9-glibc-2.32/lib/libc.so.6+0x30d52)
 #8 0x7f2d683d3af3 llvm/include/llvm/MC/MCInst.h:65:5
 #9 0x7f2d683d3d4a llvm/include/llvm/ADT/SmallVector.h:250:5
#10 0x7f2d683d5701 operator()
llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp:1261:7
#11 0x7f2d683d5701 emitREXPrefix
llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp:1297:4
#12 0x7f2d683d5701 emitOpcodePrefix
llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp:1356:36
#13 0x7f2d683d5701 (anonymous
namespace)::X86MCCodeEmitter::emitPrefixImpl(unsigned int&, llvm::MCInst
const&, llvm::MCSubtargetInfo const&, llvm::raw_ostream&) const
llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp:703:30
#14 0x7f2d683d7b97 (anonymous
namespace)::X86MCCodeEmitter::encodeInstruction(llvm::MCInst const&,
llvm::raw_ostream&, llvm::SmallVectorImpl&,
llvm::MCSubtargetInfo const&) const
llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp:1427:16
#15 0x7f2d6898c2f1
llvm::X86AsmPrinter::StackMapShadowTracker::count(llvm::MCInst&,
llvm::MCSubtargetInfo const&, llvm::MCCodeEmitter*) (.part.0)
llvm/lib/Target/X86/X86MCInstLower.cpp:110:23
#16 0x7f2d6899409e llvm::SmallVectorTemplateCommon::end() llvm/include/llvm/ADT/SmallVector.h:224:35
#17 0x7f2d6899409e llvm::SmallVector::~SmallVector()
llvm/include/llvm/ADT/SmallVector.h:1026:5
#18 0x7f2d6899409e llvm::MCInst::~MCInst()
llvm/include/llvm/MC/MCInst.h:158:7
#19 0x7f2d6899409e llvm::X86AsmPrinter::emitInstruction(llvm::MachineInstr
const*) llvm/lib/Target/X86/X86MCInstLower.cpp:2613:10
#20 0x7f2d681a35bc llvm::AsmPrinter::emitFunctionBody()
llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1224:9
#21 0x7f2d6871a32f
llvm::X86AsmPrinter::runOnMachineFunction(llvm::MachineFunction&)
llvm/lib/Target/X86/X86AsmPrinter.cpp:85:16
#22 0x7f2d675847b1
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
llvm/lib/CodeGen/MachineFunctionPass.cpp:72:33
#23 0x7f2d675847b1
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
llvm/lib/CodeGen/MachineFunctionPass.cpp:37:6
#24 0x7f2d662af3dd llvm::FPPassManager::runOnFunction(llvm::Function&)
llvm/lib/IR/LegacyPassManager.cpp:1450:7
#25 0x7f2d662afea1
llvm::ilist_node_impl >::getNext() llvm/include/llvm/ADT/ilist_node.h:66:66
#26 0x7f2d662afea1
llvm::ilist_iterator, false, false>::operator++()
llvm/include/llvm/ADT/ilist_iterator.h:157:25
#27 0x7f2d662afea1 llvm::FPPassManager::runOnModule(llvm::Module&)
llvm/lib/IR/LegacyPassManager.cpp:1485:22
#28 0x7f2d662aedb8 runOnModule llvm/lib/IR/LegacyPassManager.cpp:1562:7
#29 0x7f2d662aedb8 llvm::legacy::PassManagerImpl::run(llvm::Module&)
llvm/lib/IR/LegacyPassManager.cpp:542:55
#3

[llvm-bugs] [Bug 47800] [meta] 11.0.1 Release Blockers

2020-12-09 Thread via llvm-bugs

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

Bug 48442 Summary: Backport RISC-V ABI fix
https://bugs.llvm.org/show_bug.cgi?id=48442

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

[llvm-bugs] [Bug 48442] Backport RISC-V ABI fix

2020-12-09 Thread via llvm-bugs

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

Tom Stellard  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Fixed By Commit(s)|ca93f9abdc0abc96ca8fb799954 |ca93f9abdc0abc96ca8fb799954
   |9a50aadd95caf   |9a50aadd95caf
   |fa8f5bfa4e8cff042c9730320c7 |fa8f5bfa4e8cff042c9730320c7
   |4e97fab152ae1   |4e97fab152ae1
   |3af354e863f553ef727967dfc09 |3af354e863f553ef727967dfc09
   |1a64a11500aa5   |1a64a11500aa5 ba223fa19d3
   ||a4eaecf122e b430f94d005
 Resolution|--- |FIXED

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

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

[llvm-bugs] [Bug 47800] [meta] 11.0.1 Release Blockers

2020-12-09 Thread via llvm-bugs

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

Bug 48448 Summary: Please merge d538c5837a2cf to 11.x: [AMDGPU] Fix missed 
SI_RETURN_TO_EPILOG in pre-emit peephol
https://bugs.llvm.org/show_bug.cgi?id=48448

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

[llvm-bugs] [Bug 48448] Please merge d538c5837a2cf to 11.x: [AMDGPU] Fix missed SI_RETURN_TO_EPILOG in pre-emit peephol

2020-12-09 Thread via llvm-bugs

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

Tom Stellard  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Fixed By Commit(s)|d538c5837a2cf   |d538c5837a2cf 0feb4bc5295
 Status|NEW |RESOLVED

--- Comment #1 from Tom Stellard  ---
Merged: 0feb4bc5295

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

[llvm-bugs] [Bug 47800] [meta] 11.0.1 Release Blockers

2020-12-09 Thread via llvm-bugs

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

Bug 48215 Summary: [X86][AVX] Attempt to share broadcasts of different widths 
(D57663) - node/value mismatch
https://bugs.llvm.org/show_bug.cgi?id=48215

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

[llvm-bugs] [Bug 48215] [X86][AVX] Attempt to share broadcasts of different widths (D57663) - node/value mismatch

2020-12-09 Thread via llvm-bugs

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

Tom Stellard  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 Fixed By Commit(s)|8270f8c252d7013761c54e5bf52 |8270f8c252d7013761c54e5bf52
   |8ac3e4e3b517c   |8ac3e4e3b517c
   |14ae02fb3397961bb5f99a0df60 |14ae02fb3397961bb5f99a0df60
   |622375fc1976d   |622375fc1976d a21e609d6a2
   ||14d60e9a80d

--- Comment #11 from Tom Stellard  ---
Merged: 14d60e9a80d

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

[llvm-bugs] [Bug 48459] New: __cpu_indicator_init() runs too late on macOS

2020-12-09 Thread via llvm-bugs

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

Bug ID: 48459
   Summary: __cpu_indicator_init() runs too late on macOS
   Product: compiler-rt
   Version: 11.0
  Hardware: PC
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: builtins
  Assignee: unassignedb...@nondot.org
  Reporter: chf...@gmail.com
CC: llvm-bugs@lists.llvm.org

The usage of __builtin_cpu_supports() requires CPU information being
initialized up front. This is done by __cpu_indicator_init() which is
implemented in compiler-rt/builtins as __attribute__((constructor)). From the
GCC documentation and this comment in code:
https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/builtins/cpu_model.c#L709-L713,
the __cpu_indicator_init() should be invoked with high priority and calling it
directly from other "constructors" should only be needed only in very specific
cases like IFUNC resolving.

However this promise is not fulfilled on macOS. From my experiments the
__cpu_indicator_init() is actually the last in __mod_init_func section of
Mach-O.

For example program cpu_check.c:


int puts(const char *str);

__attribute__((constructor)) static void check_cpu()
{
if (__builtin_cpu_supports("sse2"))
puts("SSE2 supported");
else
puts("SSE2 not supported");
}

int main() {}


I get the following:

> objdump -macho -section=__mod_init_func ./a.out
./a.out:
Contents of (__DATA,__mod_init_func) section
0x00012020 0x000114d0 _check_cpu
0x00012060 0x00011510 ___cpu_indicator_init


It does not matter if I set any explicit priority value for my constructor.


In the compiler-rt the __cpu_indicator_init() is declared with this attribute:

#if defined(HAVE_INIT_PRIORITY)
#define CONSTRUCTOR_ATTRIBUTE __attribute__((__constructor__ 101))
#elif __has_attribute(__constructor__)
#define CONSTRUCTOR_ATTRIBUTE __attribute__((__constructor__))
#else

https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/builtins/cpu_model.c#L16-L20

I haven't built it for macOS, but at least from searching on GitHub the
HAVE_INIT_PRIORITY is never defined therefore it does not have the priority
set.
Furthermore, the 101 priority value does not look correct as "user" priorities
start from 100.

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

[llvm-bugs] [Bug 48460] New: Prefer a warning for when VLAs declared on stack

2020-12-09 Thread via llvm-bugs

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

Bug ID: 48460
   Summary: Prefer a warning for when VLAs declared on stack
   Product: clang
   Version: trunk
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: enhancement
  Priority: P
 Component: C18
  Assignee: unassignedclangb...@nondot.org
  Reporter: svob...@cert.org
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk

The Clang docs (https://clang.llvm.org/docs/DiagnosticsReference.html#wvla)
define the "-Wvla" flag to do the following:

Also controls -Wvla-extension.
warning: variable length array used

Warn if a variable-length array is used in the code. -Wno-vla prevents the
-Wpedantic warning of the variable-length array.

The -Wvla flag causes both GCC 10 and Clang 12 to holler about this declaration
having a VLA:

  void func1(int n, int array[n]);

This happens even if func1 is called with a regular array or an int pointer.
Whether you consider 'array' to be a VLA or not depends on how you interpret
ISO C17 6.7.6.3p4.  A colleague called the declaration of array a "heisen-VLA"
on the grounds that array may be cast to a VLA before being immediately cast to
an int pointer.

Clang 12 also hollers about this line, but GCC 10 doesn't:

  void func2(int array[*]);

ISO C17 6.7.6.3p4 is pretty clear that an array declared this way is indeed a
VLA.

But both code examples use VLAs only as an actual parameter argument type. The
main hazard of VLAs is being declared as a stack variable with an unsecured
dimension, where they could potentially exhaust your stack.

Most experts on VLAs would suggest that casting something to a VLA is not a
problem per se, and the real danger of VLAs is declaring a VLA on the stack
(because of the potential for stack exhaustion).  However, neither GCC nor
Clang seem to have a warning to detect VLA stack declarations. This would be a
useful feature, as either a replacement for -Wvla's current behavior, or for a
new warning flag.

void func1(int n, int array[n]) { /* ok, no warning */
  int array2[n]; /* bad, VLA on stack, warn! */
  int (*array3)[n];  /* ok, no VLA on stack, so no warning */
}

Finally, declaring a function argument type as a VLA with an explicit
(non-compile-time) array bounds can improve software security, as a VLA bounds
conveys useful semantic information to programmers. Also a VLA bounds can be
checked by the compiler or a static-analysis tool. At CERT, we call such an
array a "conformant array". For more background, see CERT guideline:

  API05-C. Use conformant array parameters
  https://wiki.sei.cmu.edu/confluence/x/n9UxBQ


I have also submitted a similar bug report to GCC, it is here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217

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

[llvm-bugs] [Bug 48228] Clang fails to compile cuda code in C++20 mode, works in C++17

2020-12-09 Thread via llvm-bugs

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

Tom Stellard  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|CONFIRMED   |RESOLVED
 Fixed By Commit(s)|9a465057a64dba8a8614424d261 |9a465057a64dba8a8614424d261
   |36f5c0452bcc3   |36f5c0452bcc3
   |43267929423bf768bbbcc65e47a |43267929423bf768bbbcc65e47a
   |07e37af7f4e22   |07e37af7f4e22 aa29049404e
   ||59012b685fd

--- Comment #17 from Tom Stellard  ---
Merged: 59012b685fd

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

[llvm-bugs] [Bug 47800] [meta] 11.0.1 Release Blockers

2020-12-09 Thread via llvm-bugs

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

Bug 48228 Summary: Clang fails to compile cuda code in C++20 mode, works in 
C++17
https://bugs.llvm.org/show_bug.cgi?id=48228

   What|Removed |Added

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

[llvm-bugs] [Bug 48461] New: Linker defined variable used in asm() call results in incorrect value for 32-bit code

2020-12-09 Thread via llvm-bugs

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

Bug ID: 48461
   Summary: Linker defined variable used in asm() call results in
incorrect value for 32-bit code
   Product: clang
   Version: 10.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: LLVM Codegen
  Assignee: unassignedclangb...@nondot.org
  Reporter: jared.candela...@intel.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk

Created attachment 24256
  --> https://bugs.llvm.org/attachment.cgi?id=24256&action=edit
Repro consisting of C source and linker script with build script

I'm compiling 32-bit x86 code that uses inline assembly, linker defined
variables, and some arithmetic. Clang generates unexpected code around this
compared to gcc.

For example, given the following C:
extern uint8_t BASE[]; // This is the linker defined variable (0x2000).
#define BASE_ADDRESS((uint32_t) BASE)
#define TOP (0xFF10UL)
#define OFFSET  (0x00a5UL)
#define REGISTERS_BASE  (TOP - BASE_ADDRESS)
#define WRITE_CTL_REG(Register, Value)  WRITE_REG(REGISTERS_BASE + (Register),
Value)
#define WRITE_REG(Register, Value)  \
   __asm__( \
  "movl %1, %%fs:(%0) \n\t" \
  : \
  : "ir"(Register), "ir"(Value) \
  : "memory"\
  ) \

WRITE_CTL_REG(OFFSET, 0xdead);

Clang generates the corresponding:
64 c7 05 a5 20 f0 00movl   $0xdead,%fs:0xf020a5

While gcc generates:
b8 00 20 00 00  mov$0x2000,%eax
ba a5 00 10 ff  mov$0xff1000a5,%edx
29 c2   sub%eax,%edx
89 d0   mov%edx,%eax
64 c7 00 ad de 00 00movl   $0xdead,%fs:(%eax)

Clang generates the expected code when compiling as 64-bit.

I tested this on Ubuntu clang version
10.0.1-++20201013091236+ef32c611aa2-1~exp1~20201013191834.199. Attached is a
small repro that compiles, links, and disassembles the problem spot. You can
uncomment a gcc invocation in build.sh to see what gcc will do in the same
situation. Also attached is example.txt that does this for you.

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

[llvm-bugs] [Bug 48462] New: Macro expansion not performed on argument to __has_cpp_attribute

2020-12-09 Thread via llvm-bugs

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

Bug ID: 48462
   Summary: Macro expansion not performed on argument to
__has_cpp_attribute
   Product: clang
   Version: trunk
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: C++2a
  Assignee: unassignedclangb...@nondot.org
  Reporter: ndkrem...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk

C++20 specifies that the pp-tokens given to __has_cpp_attribute are subject to
macro expansion (http://eel.is/c++draft/cpp.cond#5). GCC performs macro
expansion here, but clang does not. For example (compiled with -std=c++20):

  #define X noreturn
  #if !__has_cpp_attribute(X)
#error FAIL
  #endif

(https://gcc.godbolt.org/z/jWG586)

The above program hits the error case, whereas using "noreturn" directly
instead of "X" does not.

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

[llvm-bugs] [Bug 48463] New: [MSVC compat] Null checks for non-noexcept allocation functions

2020-12-09 Thread via llvm-bugs

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

Bug ID: 48463
   Summary: [MSVC compat] Null checks for non-noexcept allocation
functions
   Product: clang
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: -New Bugs
  Assignee: unassignedclangb...@nondot.org
  Reporter: dma...@mozilla.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk

https://godbolt.org/z/h955c9

In the example above, clang tests the result of an allocation for null iff the
allocation function is marked noexcept. This makes sense, and agrees with my
reading of https://eel.is/c++draft/expr.new#20, but MSVC includes the null
check regardless of the exception specification. Should clang do the same when
targeting Windows?

(This was reduced from a real-world crash that occurred because the code put
the noexcept behind an #ifndef _MSC_VER, probably due to lack of support at the
time.)

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

[llvm-bugs] [Bug 47754] [11.0] Please integrate 4140f0744fb2deccb74e77282e23ff731f67821b: [LLD][COFF] Fix crash with /summary and PCH input files

2020-12-09 Thread via llvm-bugs

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

Tom Stellard  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 Fixed By Commit(s)|4140f0744fb2deccb74e77282e2 |4140f0744fb2deccb74e77282e2
   |3ff731f67821b   |3ff731f67821b b091768e60e

--- Comment #10 from Tom Stellard  ---
Merged: b091768e60e

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

[llvm-bugs] [Bug 47800] [meta] 11.0.1 Release Blockers

2020-12-09 Thread via llvm-bugs

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

Bug 47754 Summary: [11.0] Please integrate 
4140f0744fb2deccb74e77282e23ff731f67821b: [LLD][COFF] Fix crash with /summary 
and PCH input files
https://bugs.llvm.org/show_bug.cgi?id=47754

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

[llvm-bugs] [Bug 48464] New: performance-no-automatic-move should accept a list of classes to be ignored

2020-12-09 Thread via llvm-bugs

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

Bug ID: 48464
   Summary: performance-no-automatic-move should accept a list of
classes to be ignored
   Product: clang
   Version: 11.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Tooling
  Assignee: unassignedclangb...@nondot.org
  Reporter: aa...@kde.org
CC: llvm-bugs@lists.llvm.org

I see the point for some classes, but take for example Qt classes like QString
that is refcounted, returning it by copy is as good as returning it by move
because all that happens is that the internal refcounter is updated.

But if if you have a long function with

const QString foo = ...

// lots of code

return foo;

it's worth foo being const since it won't be slower than if it wasn't and
prevents you making the mistake of changing foo.

That's why i think it'd be good if there was a way to tell
performance-no-automatic-move to ignore some classes from the check.

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

[llvm-bugs] [Bug 48465] New: Compiler crashes due to incorrect template pack syntax

2020-12-09 Thread via llvm-bugs

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

Bug ID: 48465
   Summary: Compiler crashes due to incorrect template pack syntax
   Product: clang
   Version: 10.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: C++2a
  Assignee: unassignedclangb...@nondot.org
  Reporter: dbron...@go.olemiss.edu
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk

Created attachment 24257
  --> https://bugs.llvm.org/attachment.cgi?id=24257&action=edit
Crash synopsis including tmp files (sh and cpp), original run script, and stack
dump

Overview: When an unexpected, unexpanded parameter pack is encountered in the
template arguments of a concept, the compiler crashes.

Steps to Reproduce: Attempt to compile the following with clang++-10
-std=c++20:

===Begin Sample

template
concept test = requires{sizeof...(Ts);};//trivially true

template
requires test
struct Test{};

int main()
{
Test<>;
return 0;
}

===End Sample==

Actual Result: The compiler crashes with a seg fault

Expected Result: A syntax error message about an unexpected parameter pack

Build Data & Hardware: 2020 December 9th on Ubuntu 20.04.1 LTS with kernel
5.4.0-56-generic

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

[llvm-bugs] [Bug 48451] clang fails to build llvm-11.0.0 in 32-bit mode when XOP instructions are enabled

2020-12-09 Thread via llvm-bugs

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

Markus Ivan Peloquin  changed:

   What|Removed |Added

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

--- Comment #4 from Markus Ivan Peloquin  ---
https://reviews.llvm.org/rG57c0c4a27575840ae0a48eb9f8455a5ed087c857

> [X86] Fix crash with i64 bitreverse on 32-bit targets with XOP.

That's exactly it. I might as well have named this bug 'crashes with i64
bitreverse on 32-bit targets with XOP'...

Thanks for pointing me to that, Simon. And thanks to Craig, wherever you are.

I'm satisfied. I guess I'll close as 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 48465] Compiler crashes due to incorrect template pack syntax

2020-12-09 Thread via llvm-bugs

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

Richard Smith  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from Richard Smith  ---
Thanks for the report, this is already fixed in trunk.

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

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

[llvm-bugs] [Bug 48458] isREXExtendedReg called on non-reg operand of MRMDestMem

2020-12-09 Thread via llvm-bugs

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

Craig Topper  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Fixed By Commit(s)||5ff5cf8e057782e3e648ecf5ccf
   ||1d9990b53ee90
 Status|NEW |RESOLVED

--- Comment #3 from Craig Topper  ---
Fixed in 5ff5cf8e057782e3e648ecf5ccf1d9990b53ee90

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

[llvm-bugs] [Bug 48453] Assigning to non-active trivial union member is not accepted in constexpr context

2020-12-09 Thread via llvm-bugs

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

Richard Smith  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Smith  ---
Per http://eel.is/c++draft/class.union#general-6, an assignment can only change
the active union member if the union member has a trivial default constructor.

`Un::NestedUn` has a non-trivial default constructor, so the union member
`Un::f2` cannot be made active by simply assigning to it or one of its
subobjects.

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

[llvm-bugs] [Bug 47808] Merge 9ae95a0f8f1bc9bd9e8eb30a5a9444fbdca5cc29 into 11.0.1: [Sparc] Remove cast that truncates immediate operands to 32 bits.

2020-12-09 Thread via llvm-bugs

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

Tom Stellard  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 Fixed By Commit(s)|9ae95a0f8f1bc9bd9e8eb30a5a9 |9ae95a0f8f1bc9bd9e8eb30a5a9
   |444fbdca5cc29   |444fbdca5cc29 852f4d8eb6d

--- Comment #4 from Tom Stellard  ---
Merged: 852f4d8eb6d

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

[llvm-bugs] [Bug 47800] [meta] 11.0.1 Release Blockers

2020-12-09 Thread via llvm-bugs

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

Bug 47808 Summary: Merge 9ae95a0f8f1bc9bd9e8eb30a5a9444fbdca5cc29 into 11.0.1: 
[Sparc] Remove cast that truncates immediate operands to 32 bits.
https://bugs.llvm.org/show_bug.cgi?id=47808

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

[llvm-bugs] [Bug 48466] New: -Wconsumed ICE on switch default case with empty enum

2020-12-09 Thread via llvm-bugs

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

Bug ID: 48466
   Summary: -Wconsumed ICE on switch default case with empty enum
   Product: clang
   Version: trunk
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: Static Analyzer
  Assignee: dcough...@apple.com
  Reporter: arthur.j.odw...@gmail.com
CC: dcough...@apple.com, llvm-bugs@lists.llvm.org

Originally reported by Drew Gross.
Possibly somehow related to #16212, #33699. The enum being "empty" (an enum
type with no enumerators) is important to this ICE somehow.

// https://godbolt.org/z/KxbGsv
enum E {};
void foo(E e) {
switch (e) { default:; }
}

clang++ -Wconsumed test.cpp


PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0.  Program arguments: /opt/compiler-explorer/clang-trunk/bin/clang++ -g -o
./output.s -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot
-fcolor-diagnostics -fno-crash-diagnostics -Wconsumed 
1.   parser at end of file
2.  :3:15: parsing function body 'foo'
 #0 0x5651c0f17e4c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2e0ae4c)
 #1 0x5651c0f15be4 llvm::sys::RunSignalHandlers()
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2e08be4)
 #2 0x5651c0f15e75 llvm::sys::CleanupOnSignal(unsigned long)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2e08e75)
 #3 0x5651c0e84338 CrashRecoverySignalHandler(int)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x2d77338)
 #4 0x7fc53fc493c0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
 #5 0x5651c34128b3
clang::consumed::ConsumedAnalyzer::run(clang::AnalysisDeclContext&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x53058b3)
 #6 0x5651c336466e
clang::sema::AnalysisBasedWarnings::IssueWarnings(clang::sema::AnalysisBasedWarnings::Policy,
clang::sema::FunctionScopeInfo*, clang::Decl const*, clang::QualType)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x525766e)
 #7 0x5651c2c54dfe
clang::Sema::PopFunctionScopeInfo(clang::sema::AnalysisBasedWarnings::Policy
const*, clang::Decl const*, clang::QualType)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4b47dfe)
 #8 0x5651c2dab042 clang::Sema::ActOnFinishFunctionBody(clang::Decl*,
clang::Stmt*, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x4c9e042)
 #9 0x5651c2bf9d97 clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4aecd97)
#10 0x5651c2b4e527
clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4a41527)
#11 0x5651c2b6a6d5 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&,
clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4a5d6d5)
#12 0x5651c2b49551
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4a3c551)
#13 0x5651c2b49c81
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier) (.part.250)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4a3cc81)
#14 0x5651c2b4fc29
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4a42c29)
#15 0x5651c2b511b1
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&, bool)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4a441b1)
#16 0x5651c2b44319 clang::ParseAST(clang::Sema&, bool, bool)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4a37319)
#17 0x5651c1735be1 clang::FrontendAction::Execute()
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x3628be1)
#18 0x5651c16ebe3b
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x35dee3b)
#19 0x5651c17fd463
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x36f0463)
#20 0x5651bf00629c cc1_main(llvm::ArrayRef, char const*,
void*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0xef929c)
#21 0x5651bf00297d ExecuteCC1Tool(llvm::SmallVectorImpl&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0xef597d)
#22 0x5651c15b6955 void llvm::function_ref::callback_fn
>, std::__cxx11::basic_string,
std::allocator >*, bool*) const::'lambda'()>(long)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x34a9955)
#23 0x5651c0e84413
llvm::CrashRecoveryContext::RunSafely(llvm::function_ref)
(/

[llvm-bugs] [Bug 47370] --print-before/after don't work with new pass manager

2020-12-09 Thread via llvm-bugs

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

Arthur Eubanks  changed:

   What|Removed |Added

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

--- Comment #1 from Arthur Eubanks  ---
Fixed with https://reviews.llvm.org/D87216

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

[llvm-bugs] [Bug 46651] Fix all opt tests to work under NPM

2020-12-09 Thread via llvm-bugs

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

Bug 47370 Summary: --print-before/after don't work with new pass manager
https://bugs.llvm.org/show_bug.cgi?id=47370

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

[llvm-bugs] [Bug 47402] llvm.coro.prepare.retcon unsupported under new pass manager

2020-12-09 Thread via llvm-bugs

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

Arthur Eubanks  changed:

   What|Removed |Added

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

--- Comment #1 from Arthur Eubanks  ---
Fixed with https://reviews.llvm.org/D87731

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

[llvm-bugs] [Bug 46651] Fix all opt tests to work under NPM

2020-12-09 Thread via llvm-bugs

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

Bug 47402 Summary: llvm.coro.prepare.retcon unsupported under new pass manager
https://bugs.llvm.org/show_bug.cgi?id=47402

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

[llvm-bugs] [Bug 47244] There's no equivalent for adjustPassManager() for targets to add passes in the optimizer pipeline for the NPM

2020-12-09 Thread via llvm-bugs

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

Arthur Eubanks  changed:

   What|Removed |Added

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

--- Comment #6 from Arthur Eubanks  ---
Marking this as fixed. AMDGPU passes still need to be ported, but that's a
separate bug.

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

[llvm-bugs] [Bug 46649] Change default pass manager to new pass manager

2020-12-09 Thread via llvm-bugs

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

Bug 47244 Summary: There's no equivalent for adjustPassManager() for targets to 
add passes in the optimizer pipeline for the NPM
https://bugs.llvm.org/show_bug.cgi?id=47244

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

[llvm-bugs] [Bug 48467] New: inconsistent behaviors: the source code lines an address belongs to is inconsistent at source-level debugging and instruction-level debugging

2020-12-09 Thread via llvm-bugs

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

Bug ID: 48467
   Summary: inconsistent behaviors: the source code lines an
address belongs to is inconsistent at source-level
debugging and instruction-level debugging
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-...@lists.llvm.org
  Reporter: yangyib...@nju.edu.cn
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org

Created attachment 24259
  --> https://bugs.llvm.org/attachment.cgi?id=24259&action=edit
binary

$ clang -v
Ubuntu clang version
12.0.0-++20201202063839+f0193623297-1~exp1~20201202174527.2077
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/10
Candidate multilib: .;@m64
Selected multilib: .;@m64

$ lldb -v
lldb version 12.0.0



$ cat small.c
/* { dg-options "-O2" } */
/* { dg-do run } */

static const long long int TagTypeNumber = 0xll;

long long int x;

void foo(void)
{
  x = TagTypeNumber + 1;// Line 10
}

int main(int argc, char **argv)
{
  if (argc > 0)
foo ();// Line 16

  if ((x & TagTypeNumber) == TagTypeNumber)
  {
unsigned y = (unsigned)x;
__builtin_printf ("v: %u\n", y);
if (y != 1)
  __builtin_abort ();
  }

  return 0;
}


$ clang -O2 -g small.c

$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/root/DeVIL/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main + 11 at small.c:15:12, address =
0x0040056b
(lldb) r
Process 42468 stopped
frame #0: 0x0040056b a.out`main(argc=1, argv=0x7fffe038) at
small.c:15:12
-> 15 if (argc > 0)
(lldb) s
Process 42468 stopped
frame #0: 0x0040056f a.out`main(argc=1, argv=0x7fffe038) at
small.c:16
-> 16   foo ();// Line 16
(lldb) s
frame #0: 0x0040056f a.out`main [inlined] foo at small.c:10:5
-> 10 x = TagTypeNumber + 1;// Line 10
(lldb) 



We can found that when step line by line, 0x0040056f belongs to Line 16
and Line 10.
However, when step instruction by instruction, 0x0040056f only belongs
to Line 16 as follows:



$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/root/DeVIL/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main + 11 at small.c:15:12, address =
0x0040056b
(lldb) r
Process 42608 stopped
frame #0: 0x0040056b a.out`main(argc=1, argv=0x7fffe038) at
small.c:15:12
-> 15 if (argc > 0)
(lldb) si
Process 42608 stopped
frame #0: 0x0040056d a.out`main(argc=1, argv=0x7fffe038) at
small.c:15:7
-> 15 if (argc > 0)
(lldb) si
Process 42608 stopped
frame #0: 0x0040056f a.out`main(argc=1, argv=0x7fffe038) at
small.c:16
-> 16   foo ();// Line 16
(lldb) si
Process 42608 stopped
frame #0: 0x00400573 a.out`main [inlined] foo at small.c:10:5
-> 10 x = TagTypeNumber + 1;// Line 10
(lldb)

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

42 matches

Mail list logo