[llvm-bugs] [Bug 35458] New: [AMDGPU][MC][GFX9] Incorrect mapping of pseudo to MC for v_add/sub/subrev_u32
https://bugs.llvm.org/show_bug.cgi?id=35458 Bug ID: 35458 Summary: [AMDGPU][MC][GFX9] Incorrect mapping of pseudo to MC for v_add/sub/subrev_u32 Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org v_add/sub/subrev_u32 shall be labelled as renamed for pseudoToMCOpcode to handle them correctly. -- 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 35459] New: llvm-cov: Can't combine coverage from multiple binaries
https://bugs.llvm.org/show_bug.cgi?id=35459 Bug ID: 35459 Summary: llvm-cov: Can't combine coverage from multiple binaries Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: dennis.fels...@sap.com CC: llvm-bugs@lists.llvm.org Created attachment 19484 --> https://bugs.llvm.org/attachment.cgi?id=19484&action=edit run script to reproduce the issue Creating two separate binaries creating a common coverage report for them does not work properly. Some files are missing, coverage in others is shown as lower than it actually is. This is useful in the case of having multiple unit test binaries for parts of a project. Minimal example attached. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35460] New: [LLD/ELF] - LLD produced reproduce file has abnormal size.
https://bugs.llvm.org/show_bug.cgi?id=35460 Bug ID: 35460 Summary: [LLD/ELF] - LLD produced reproduce file has abnormal size. Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: gri...@accesssoftek.com CC: llvm-bugs@lists.llvm.org I noticed the following strangeness. Reproduce file size for clang has size 266.2 megabytes. Extracted data size is 189.9 megabytes. If I compress these files using file manager context menu to tar, I get tar of size 190 megabytes, what is close to initial data size. I can link these files with LLD and it will produce 260+ megs file again. Why there is 40% difference in size ? Is is expected ? It does not look good for me, I am going to investigate this. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34777] clang-format: noexcept on lambda breaks formatting
https://bugs.llvm.org/show_bug.cgi?id=34777 Marek Kurdej changed: What|Removed |Added Product|clang-tools-extra |clang Version|unspecified |trunk CC||curde...@gmail.com, ||djas...@google.com, ||llvm-bugs@lists.llvm.org Component|Other |Formatter -- 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 35461] New: clang-format: wrong formatting of lambdas with noexcept and trailing return type
https://bugs.llvm.org/show_bug.cgi?id=35461
Bug ID: 35461
Summary: clang-format: wrong formatting of lambdas with
noexcept and trailing return type
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: curde...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
The third lambda in the following snippet gets weirdly formatted:
[]() noexcept {};
[]() -> void {};
[]() noexcept->void{}; // <- incorrect
whereas corresponding functions are formatted in this way:
auto f() noexcept;
auto f() -> void;
auto f() noexcept -> void; // <- OK
It may be related to bugs #28590 and #34777.
clang-format trunk from 2017-11-22.
--
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 35462] New: dynamic_cast to virtual base with multiple access control
https://bugs.llvm.org/show_bug.cgi?id=35462
Bug ID: 35462
Summary: dynamic_cast to virtual base with multiple access
control
Product: clang
Version: 5.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: stephane.zimmerm...@trust-in-soft.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
The following code:
struct Foo {
int x = 42;
virtual void f() {}
};
struct PublicBar: public virtual Foo { };
struct PrivateBar: private virtual Foo { };
struct EntryPoint {
virtual void g() {}
};
struct Baz: PublicBar, PrivateBar, EntryPoint {};
int main(void) {
Baz b;
EntryPoint *e = &b;
Foo *f = dynamic_cast(e);
return f->x;
}
when compiled and executed causes a segmentation fault because the dynamic_cast
is failing.
The dynamic cast should not fail, as the Foo base is unique because it is
virtual and is accessible because of the path PublicBar::Foo.
--
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 26954] Assertion `BestRC && "Couldn't find the register class"' failed
https://bugs.llvm.org/show_bug.cgi?id=26954 serge.guel...@telecom-bretagne.eu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from serge.guel...@telecom-bretagne.eu --- Cannot reproduce any longer with modern version, closing the bug report. -- 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 35463] New: X86: Stack probe symbol has wrong linkage while compiling a shared object
https://bugs.llvm.org/show_bug.cgi?id=35463
Bug ID: 35463
Summary: X86: Stack probe symbol has wrong linkage while
compiling a shared object
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Target Description Classes
Assignee: unassignedb...@nondot.org
Reporter: ales.hraba...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 19485
--> https://bugs.llvm.org/attachment.cgi?id=19485&action=edit
Nasty hack that fixes the issue for us
We build ELF objects on Windows. Everything seemed to be working fine until we
compiled some code that uses dynamic stack allocation, and tried to link it
into a shared library (executable linking works fine). Here is a minimal
example that produces the error we observed:
// minimal example -- commands //
clang++ --target=x86_64-pc-windows-elf -c foo.cpp
ld.lld -shared foo.o -o foo
// minimal example -- foo.cpp //
int foo(int x) {
void *p = __builtin_alloca( x );
return (int)p;
}
// minimal example -- lld error //
D:\build\llvm-install-release\bin\ld.lld.exe: error: can't create dynamic
relocation R_X86_64_PC32 against symbol: __chkstk in readonly segment;
recompile object files with -fPIC
>>> defined in foo.o
>>> referenced by foo.cpp
>>> foo.o:(foo(int))
We have tracked the bug to X86FrameLowering.cpp. Attached is a small, nasty
hack that fixes the problem for us. It is probably not a good solution, but the
library links now.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35464] New: Crash at llvm_gcda_emit_arcs or llvm_gcda_emit_function when running multiple processes
https://bugs.llvm.org/show_bug.cgi?id=35464 Bug ID: 35464 Summary: Crash at llvm_gcda_emit_arcs or llvm_gcda_emit_function when running multiple processes Product: compiler-rt Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: mcastelluc...@mozilla.com CC: llvm-bugs@lists.llvm.org There's still something that causes inconsistencies when multiple processes are writing the same gcda files. I have noticed these crashes, intermittently, in Firefox xpcshell and jittest suites, which are running several instances of Firefox in parallel. The crash usually occurs either in llvm_gcda_emit_arcs or in llvm_gcda_emit_function, when a process opens a file that has already been written by another. It never happens when the file is new. I have a patch that seems to fix this problem. The fix is to flush the file buffers before unlocking the file. Currently, the flush is done with fclose after the file is unlocked. So, between the unlocking and the flushing, there might be other processes opening the file and mapping it in memory when it hasn't been completely written yet. So, the process ends up writing outside the mapped memory and crashes. -- 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 34478] MOV16ms uses operand size override prefix
https://bugs.llvm.org/show_bug.cgi?id=34478 Nirav Dave changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Nirav Dave --- Landed in r318797. -- 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 35465] New: Domain generation should use exiting not latch conditions
https://bugs.llvm.org/show_bug.cgi?id=35465 Bug ID: 35465 Summary: Domain generation should use exiting not latch conditions Product: Polly Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Other Assignee: polly-...@googlegroups.com Reporter: doerf...@cs.uni-saarland.de CC: llvm-bugs@lists.llvm.org Created attachment 19486 --> https://bugs.llvm.org/attachment.cgi?id=19486&action=edit Test case + fix Attached a patch to fix and simplify the domain generation. Using latch constraints is problematic if multiple loops are left. One test case was fixed others have only be simplified. -- 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 35467] New: WASM backend fails on multiple symbols in same section for ctors
https://bugs.llvm.org/show_bug.cgi?id=35467
Bug ID: 35467
Summary: WASM backend fails on multiple symbols in same section
for ctors
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: WebAssembly
Assignee: unassignedb...@nondot.org
Reporter: n...@realvnc.com
CC: llvm-bugs@lists.llvm.org
When compiling simple code with a C++ constructor, the WASM backend refuses to
emit the code with the following error from WasmObjectWriter.cpp:
> LLVM ERROR: function sections must contain one function each
The error only occurs when compiling with "-O0", and does not occur when
compiling with "-Os".
I think this is a distinct problem to the one observed in
https://bugs.llvm.org/show_bug.cgi?id=35414.
=== Full testcase ===
### C++ code:
struct WithCtor {
WithCtor();
};
WithCtor::WithCtor() {}
static WithCtor withCtor;
### LLVM output from "clang++ -O0 -emit-llvm"
%struct.WithCtor = type { i8 }
@_ZL8withCtor = internal global %struct.WithCtor zeroinitializer, align 1
@llvm.global_ctors = appending global [1 x { i32, void ()*, i8* }] [{ i32, void
()*, i8* } { i32 65535, void ()* @_GLOBAL__sub_I_init_test.cxx, i8* null }]
@_ZN8WithCtorC1Ev = hidden alias %struct.WithCtor* (%struct.WithCtor*),
%struct.WithCtor* (%struct.WithCtor*)* @_ZN8WithCtorC2Ev
; Function Attrs: noinline nounwind optnone
define hidden %struct.WithCtor* @_ZN8WithCtorC2Ev(%struct.WithCtor* returned
%this) unnamed_addr #0 {
entry:
%this.addr = alloca %struct.WithCtor*, align 4
store %struct.WithCtor* %this, %struct.WithCtor** %this.addr, align 4
%this1 = load %struct.WithCtor*, %struct.WithCtor** %this.addr, align 4
ret %struct.WithCtor* %this1
}
; Function Attrs: noinline
define internal void @__cxx_global_var_init() #1 section ".text.__startup" {
entry:
%call = call %struct.WithCtor* @_ZN8WithCtorC1Ev(%struct.WithCtor*
@_ZL8withCtor)
ret void
}
; Function Attrs: noinline
define internal void @_GLOBAL__sub_I_init_test.cxx() #1 section
".text.__startup" {
entry:
call void @__cxx_global_var_init()
ret void
}
### Fails when compiled with "llc -filetype=obj output.o"
--
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 35469] New: [InlineCost] CallAnalyzer crashes when analyzing bitcasted callee
https://bugs.llvm.org/show_bug.cgi?id=35469
Bug ID: 35469
Summary: [InlineCost] CallAnalyzer crashes when analyzing
bitcasted callee
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Interprocedural Analyses
Assignee: unassignedb...@nondot.org
Reporter: kavon.farvar...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 19489
--> https://bugs.llvm.org/attachment.cgi?id=19489&action=edit
backtrace of infinite recursion crash
The following IR crashes LLVM when running -inline -early-cse. It is not
specific to early-cse, since other passes following inline also crash it, such
as instcombine, gvn, etc.
define void @func1() {
%t = bitcast void ()* @func2 to void ()*
tail call void %t()
ret void
}
define void @func2() {
%t = bitcast void ()* @func2 to void ()*
tail call void %t()
ret void
}
It appears to be the bitcast that is throwing off CallAnalyzer, and sends it
into an infinite loop. My best guess is that somewhere it assumes it is an
indirect call, but somewhere else it sees that the callee is known, and so it
recurses forever trying to analyze @func2. I have attached a backtrace to aid
in debugging.
--
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 35470] New: Enable debug fission on ThinLTO
https://bugs.llvm.org/show_bug.cgi?id=35470 Bug ID: 35470 Summary: Enable debug fission on ThinLTO Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: yunl...@google.com CC: llvm-bugs@lists.llvm.org Currently, when -flto=thin is specified, the debug fission option is ignored, we want to enable debug fission with ThinLTO. -- 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 35471] New: copy relocation symbols don't show up in --Map output
https://bugs.llvm.org/show_bug.cgi?id=35471 Bug ID: 35471 Summary: copy relocation symbols don't show up in --Map output Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: rafael.espind...@gmail.com CC: llvm-bugs@lists.llvm.org Given .global _start _start: .quad foo callq bar and a shared library with a foo object and a bar function bfd will print .plt 0x00400250 0x20 test.o 0x00400260bar .dynbss0x006010200x8 test.o 0x00601020foo but foo and bar are missing from lld's map output. -- 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 35387] Coverage: line count incorrect for single statement for/while loop
https://bugs.llvm.org/show_bug.cgi?id=35387 Vedant Kumar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Vedant Kumar --- r319373 -- 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 4238 in oss-fuzz: llvm: Stack-overflow in EvaluateValue
Updates: Status: WontFix Comment #1 on issue 4238 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm: Stack-overflow in EvaluateValue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4238#c1 ClusterFuzz testcase 4806284109938688 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 35437] [LLVM-COV] Two continuous "for" statements lead to incorrect coverage information
https://bugs.llvm.org/show_bug.cgi?id=35437 Vedant Kumar changed: What|Removed |Added CC||v...@apple.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Vedant Kumar --- Thank you for the report. This is a bug in the coverage segment builder, where I missed a corner case. Fixed in r319391. -- 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 35437] [LLVM-COV] Two continuous "for" statements lead to incorrect coverage information
https://bugs.llvm.org/show_bug.cgi?id=35437 Vedant Kumar changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #2 from Vedant Kumar --- Sorry, I meant to comment in PR35426. I have not looked at this yet. -- 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 35426] [LLVM-COV] A non-executed label was wrongly marked as executed in llvm-cov
https://bugs.llvm.org/show_bug.cgi?id=35426 Vedant Kumar changed: What|Removed |Added Resolution|--- |FIXED CC||v...@apple.com Status|NEW |RESOLVED --- Comment #1 from Vedant Kumar --- Thank you for the report. This is a bug in the coverage segment builder, where I missed a corner case. Fixed in r319391 -- 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 35472] New: Error with ThinLTO: Invalid function metadata: outgoing forward refs
https://bugs.llvm.org/show_bug.cgi?id=35472
Bug ID: 35472
Summary: Error with ThinLTO: Invalid function metadata:
outgoing forward refs
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: sunil_srivast...@playstation.sony.com
CC: llvm-bugs@lists.llvm.org
As shown below, a ThinLTO run fails with an assertion failure on two simple
files, trimmed from a larger code.
The attribute nodebug on ~Echo() is needed for this crash to occur. In this
trimmed example the ~Echo() default declaration has been added to be able to
put that attribute.
---
$ clang++ --version
clang version 6.0.0 (trunk 319376)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir:
$ clang++ -c a.cpp -o a.bc --std=c++11 -O0 -g -flto=thin
$ clang++ -c b.cpp -o b.bc --std=c++11 -O0 -g -flto=thin
$ llvm-lto -thinlto-action=run a.bc b.bc
ThinLTO: b.bc: error: Invalid function metadata: outgoing forward refs
(Producer: 'LLVM6.0.0svn' Reader: 'LLVM 6.0.0svn')
LLVM ERROR: importFunctions failed
$ cat a.cpp
struct Charlie {
__attribute__((__always_inline__)) ~Charlie() { Golf = 0; }
int Golf;
};
struct Delta {
Charlie Foxtrot;
};
struct Echo {
Charlie Foxtrot;
__attribute__((nodebug)) ~Echo() = default;
};
extern void Bravo();
void Bravo() {
Delta Hotel;
Echo India;
}
$ cat b.cpp
extern void Bravo();
extern void Alpha();
void Alpha() { Bravo(); }
$
--
The crash occurs in BitcodeReader.cpp at a point where it expects all Metadata
forward-refs to be resolved, but they are not. Around line 4615:
// Unexpected unresolved metadata about to be dropped.
if (MDLoader->hasFwdRefs())
return error("Invalid function metadata: outgoing forward refs");
I am filing this bug under clang/CodeGen under the assumption that the incoming
IR at this point is defective. If not, please go ahead and assign it to another
component.
--
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 35394] source code inside a label after a loop is wrongly labeled as not executed in llvm-cov
https://bugs.llvm.org/show_bug.cgi?id=35394 Vedant Kumar changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||v...@apple.com --- Comment #2 from Vedant Kumar --- *** This bug has been marked as a duplicate of bug 35426 *** -- 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 35403] Code in nesting if statement is wrongly labeled as executed in llvm-cov
https://bugs.llvm.org/show_bug.cgi?id=35403 Vedant Kumar changed: What|Removed |Added Resolution|--- |DUPLICATE CC||v...@apple.com Status|NEW |RESOLVED --- Comment #1 from Vedant Kumar --- *** This bug has been marked as a duplicate of bug 35404 *** -- 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 35437] [LLVM-COV] Two continuous "for" statements lead to incorrect coverage information
https://bugs.llvm.org/show_bug.cgi?id=35437 Vedant Kumar changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Vedant Kumar --- *** This bug has been marked as a duplicate of bug 35404 *** -- 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 35385] WASM backend generates invalid wasm for undeclared imports
https://bugs.llvm.org/show_bug.cgi?id=35385 jgrave...@google.com changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #9 from jgrave...@google.com --- My point is more that it doesn't really fix this bug at all. It just changes us from failure to build a valid wasm object file, to failure to link independently-valid-but-disagreeing wasm object files. It also breaks EM_ASM in C (https://logs.chromium.org/v/?s=chromium%2Fbb%2Fclient.wasm.llvm%2Flinux%2F26661%2F%2B%2Frecipes%2Fsteps%2FExecute_emscripten_testsuite__emwasm_%2F0%2Fstdout), which long-term I don't really mind because it's using a pretty fragile mechanism (i.e. prototypeless C function declarations, that are not even well-defined because they are expected to have mismatching callsites). Short-term it might be good to revert this until we can get EM_ASM not relying on that behavior (which I have some ideas around solving once and for all). -- 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 35473] New: Cannot mangle injected class name type.
https://bugs.llvm.org/show_bug.cgi?id=35473 Bug ID: 35473 Summary: Cannot mangle injected class name type. Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Modules Assignee: unassignedclangb...@nondot.org Reporter: warvs...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Created attachment 19490 --> https://bugs.llvm.org/attachment.cgi?id=19490&action=edit The error only happens when certain functions are called, such as PxSceneDesc sceneDesc(m); I get the following error when trying to compile a cpp module interface. Physics.cppm ( has includes for the PhysX library ) Physics.cpp ( crashes here when compiling for Windows, Android compiles fine. ) The error I get is Cannot mangle injected class name type. 1>UNREACHABLE executed at C:\src\llvm_package_318667\llvm\tools\clang\lib\AST\MicrosoftMangle.cpp:2469! 1>Wrote crash dump file "C:\Users\JARSTU~1\AppData\Local\Temp\clang++.exe-51e3dd.dmp" 1>0x021758F8 (0x0016 0x04FD3674 0x04FD3674 0x0003) 1>0x77655422 (0x04FD3680 0x0B39C190 0x0B39C198 0x0B39C190), abort() + 0x32 bytes(s) These are the arguments I pass to clang clang++.exe -Xclang --dependent-lib=msvcrtd -Xclang --dependent-lib=oldnames -Wno-c++11-narrowing -fno-ms-compatibility -Wno-unused-command-line-argument -Wno-pragma-pack -Wno-nonportable-include-path -fno-delayed-template-parsing -g2 -c ..\Shared\..\Project5\Physics.cpp -o ./x64/Debug/\Physics.cpp.o -DUNICODE -D_UNICODE -D_CONSOLE -DUSINGMODULES -DWIN32 -D_DEBUG -D_MT -D_DLL -DVC_EXTRALEAN -DWIN32_LEAN_AND_MEAN -DGLEW_STATIC -D_HAS_EXCEPTIONS=0 -fmodules-ts -IC:\glm\glm -IE:\physx\PhysX-3.4\PhysX_3.4\Source\Common\src -m64 --target=x86_64-windows-msvc -gcodeview -std=c++17 -O0 -emit-llvm -save-temps -fprebuilt-module-path=./x64/Debug/ -fmodule-file=./x64/Debug/Physics.pcm I've attached the ii file, not sure how helpful that would be. If there is any way I can be of help, let me know. Thanks Robert -- 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 35474] New: --emit-relocs produces wrongly-named reloc sections
https://bugs.llvm.org/show_bug.cgi?id=35474
Bug ID: 35474
Summary: --emit-relocs produces wrongly-named reloc sections
Product: lld
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: rol...@hack.frob.com
CC: jakehehrl...@google.com, llvm-bugs@lists.llvm.org,
pho...@chromium.org
The reloc sections emitted by --emit-relocs should have names that are
'.rela' (or '.rel') prepended to the corresponding output section name.
GNU linkers do this. LLD names multiple reloc sections for some section (I
don't know how it chooses), so there wind up being multiple reloc sections
by the same name though they correctly point (sh_info) to differently-named
sections.
$ cat foo.ld
SECTIONS {
. = 0x10;
.text.boot : { *(.text.boot) }
.text : { *(.text) }
}
$ cat foo.s
.section .text.boot,"ax"
foo: mov $bar, %rax
.section .text,"ax"
bar: mov $foo, %rax
$ gcc -c foo.s
$ readelf -WS foo.o
There are 10 section headers, starting at offset 0x180:
Section Headers:
[Nr] Name TypeAddress OffSize
ES Flg Lk Inf Al
[ 0] NULL 00 00
00 0 0 0
[ 1] .text PROGBITS 40 07
00 AX 0 0 1
[ 2] .rela.textRELA 000108 18
18 I 7 1 8
[ 3] .data PROGBITS 47 00
00 WA 0 0 1
[ 4] .bss NOBITS 47 00
00 WA 0 0 1
[ 5] .text.bootPROGBITS 47 07
00 AX 0 0 1
[ 6] .rela.text.boot RELA 000120 18
18 I 7 5 8
[ 7] .symtab SYMTAB 50 a8
18 8 7 8
[ 8] .strtab STRTAB f8 09
00 0 0 1
[ 9] .shstrtab STRTAB 000138 41
00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
l (large), p (processor specific)
$ ld.lld --emit-relocs -o foo.lld -T foo.ld foo.o
ld.lld: warning: cannot find entry symbol _start; defaulting to
0x17
$ readelf -WS foo.lld
There are 11 section headers, starting at offset 0x1180:
Section Headers:
[Nr] Name TypeAddress OffSize
ES Flg Lk Inf Al
[ 0] NULL 00 00
00 0 0 0
[ 1] .text.bootPROGBITS0010 001000 07
00 AX 0 0 1
[ 2] .text PROGBITS0017 001007 07
00 AX 0 0 1
[ 3] .data PROGBITS001e 00100e 00
00 WA 0 0 1
[ 4] .bss NOBITS 001e 00100e 00
00 WA 0 0 1
[ 5] .rela.textRELA 001010 18
18 I 8 2 8
[ 6] .rela.textRELA 001028 18
18 I 8 1 8
[ 7] .comment PROGBITS 001040 21
01 MS 0 0 1
[ 8] .symtab SYMTAB 001068 c0
18 10 8 8
[ 9] .shstrtab STRTAB 001128 4b
00 0 0 1
[10] .strtab STRTAB 001173 09
00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
l (large), p (processor specific)
$ ld.bfd --emit-relocs -o foo.bfd -T foo.ld foo.o
$ readelf -WS foo.bfd
There are 10 section headers, starting at offset 0x1001a0:
Section Headers:
[Nr] Name TypeAddress OffSize
ES Flg Lk Inf Al
[ 0] NULL 00 00
00 0 0 0
[ 1] .text.bootPROGBITS0010 10 07
00 AX 0 0 1
[ 2] .rela.text.boot RELA 100128 18
18 I 7 1 8
[llvm-bugs] [Bug 35475] New: plumhall interps/interp94.c test failed.
https://bugs.llvm.org/show_bug.cgi?id=35475 Bug ID: 35475 Summary: plumhall interps/interp94.c test failed. Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: hsiang...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 19491 --> https://bugs.llvm.org/attachment.cgi?id=19491&action=edit Reduced plumhall test case interps/interp94.c Plumhall interps/interp94.c will test 'the minimum negative number' and 'the recalculated minimum negative number by power of 2' is the same or not. In LLVM 6.0.0 will test failed in this case. Attachment is the reduced case according to interps/interp94.c in plumhall. ~/sandbox/plumhall/bug $ ~/llvm-x86/bin/clang --version clang version 5.0.0 (https://github.com/llvm-mirror/clang.git 7e8743f82ac7957c66d9c2444996be5b1218673b) (https://github.com/llvm-mirror/llvm.git 657c31173ea30090583e40c7a9204561d9c2d8c4) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /home/users/kai/llvm-x86/bin ~/sandbox/plumhall/bug $ ~/llvm-x86/bin/clang -m32 -O3 test.c ~/sandbox/plumhall/bug $ ./a.out test success ~/sandbox/plumhall/bug $ ~/llvm-dev/bin/clang --version clang version 6.0.0 (https://github.com/llvm-mirror/clang.git 9f9177d3ef72580ca29e8844327f63d7aa1908af) (https://github.com/llvm-mirror/llvm.git 75de121e01e390e4ca6e7e51c10ad27006cdc97a) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /home/users/kai/llvm-dev/bin ~/sandbox/plumhall/bug $ ~/llvm-dev/bin/clang -m32 -O3 test.c ~/sandbox/plumhall/bug $ ./a.out test failed -- 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 28520] type_tag_for_datatype causes clang to crash in some cases.
https://bugs.llvm.org/show_bug.cgi?id=28520 Matt Davis 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 35476] New: LLD cannot find library file linked via #pragma comment(lib)
https://bugs.llvm.org/show_bug.cgi?id=35476 Bug ID: 35476 Summary: LLD cannot find library file linked via #pragma comment(lib) Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: COFF Assignee: unassignedb...@nondot.org Reporter: ztur...@google.com CC: llvm-bugs@lists.llvm.org, l...@inglorion.net, r...@google.com, r...@google.com I found this when trying to configure a self-host build of LLVM which includes the LLDB subproject, and when forces the use of lld via CMake. It should be easy to create a trivial repro, but for now this is what I have. 1. Build clang and lld into some folder called foo. 2. Configure another build of LLVM with the following CMake arguments. cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;lld;lldb" -DLLVM_TARGETS_TO_BUILD=X86 -DPYTHON_HOME=C:\Python35 -DCMAKE_C_COMPILER=foo/clang-cl.exe -DCMAKE_CXX_COMPILER=foo/clang-cl.exe -DCMAKE_LINKER=foo/lld-link.exe When you build this, at the link step we can see it trying to run this command: [1/1] Linking CXX shared library bin\liblldb.dll FAILED: bin/liblldb.dll lib/liblldb.lib cmd.exe /C "cd . && "C:\Program Files (x86)\CMake\bin\cmake.exe" -E vs_link_dll --intdir=tools\lldb\source\API\CMakeFiles\liblldb.dir --manifests -- E:\src\llvmbuild\ninja-release-x64\bin\lld-link.exe /nologo @CMakeFiles/liblldb.rsp /out:bin\liblldb.dll /implib:lib\liblldb.lib /pdb:bin\liblldb.pdb /dll /version:6.0 /machine:X86 /MANIFEST:NO /debug /INCREMENTAL && cd ." E:\src\llvmbuild\ninja-release-x64\bin\lld-link.exe: error: could not open python35_d.lib: no such file or directory LINK failed. with 1 ninja: build stopped: subcommand failed. If we run that exact same command, replacing lld-link.exe with the path to the Microsoft linker, it works. python is special as the library is not specified on the command line, but in one of the python header files via a #pragma comment. As mentioned, it should be easy to create a simple repro, but I'm just recording the full steps I went through so this issue doesn't get lost. -- 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 35475] plumhall interps/interp94.c test failed.
https://bugs.llvm.org/show_bug.cgi?id=35475 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |INVALID --- Comment #2 from Richard Smith --- Testcase has undefined behavior on line 58: n = -n; n here is INT_MIN (== LONG_MIN); negating it results in UB. -- 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
