[llvm-bugs] [Bug 35460] [LLD/ELF] - LLD produced reproduce file has abnormal size.
https://bugs.llvm.org/show_bug.cgi?id=35460 George Rimar changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from George Rimar --- Fixed in r319750 + r319752. (In reply to Rui Ueyama from comment #6) > Regarding multiple .a files, is that really a common practice to specify the > same .a files multiple times in the same command line? I know there's a > valid use case of doing it, but in most cases, I believe people use > --start-group and --end-group. > --start-group/--end-group looks much cleaner way for me. Not sure why clang do different. If it is common practice then de-deplicating does not worth doing probably. -- 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 35526] New: TAG_label not created for labels
https://bugs.llvm.org/show_bug.cgi?id=35526
Bug ID: 35526
Summary: TAG_label not created for labels
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: pmatos@linki.tools
CC: llvm-bugs@lists.llvm.org
With a simple program like:
int main(void) {
top:
return 0;
}
which generates IR:
; ModuleID = 'test.c'
source_filename = "test.c"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
; Function Attrs: noinline nounwind uwtable
define i32 @main() #0 !dbg !6 {
entry:
%retval = alloca i32, align 4
store i32 0, i32* %retval, align 4
br label %top, !dbg !10
top: ; preds = %entry
ret i32 0, !dbg !11
}
attributes #0 = { noinline nounwind uwtable
"correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false"
"less-precise-fpmad"="false" "no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false"
"no-jump-tables"="false" "no-nans-fp-math"="false"
"no-signed-zeros-fp-math"="false" "no-trapping-math"="false"
"stack-protector-buffer-size"="8" "target-cpu"="x86-64"
"target-features"="+fxsr,+mmx,+sse,+sse2,+x87" "unsafe-fp-math"="false"
"use-soft-float"="false" }
!llvm.dbg.cu = !{!0}
!llvm.module.flags = !{!3, !4}
!llvm.ident = !{!5}
!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang
version 5.0.0 (trunk 297627)", isOptimized: false, runtimeVersion: 0,
emissionKind: FullDebug, enums: !2)
!1 = !DIFile(filename: "test.c", directory:
"/home/pmatos/Clients/embecosm/BUGS/b639")
!2 = !{}
!3 = !{i32 2, !"Dwarf Version", i32 4}
!4 = !{i32 2, !"Debug Info Version", i32 3}
!5 = !{!"clang version 5.0.0 (trunk 297627)"}
!6 = distinct !DISubprogram(name: "main", scope: !1, file: !1, line: 1, type:
!7, isLocal: false, isDefinition: true, scopeLine: 1, flags: DIFlagPrototyped,
isOptimized: false, unit: !0, variables: !2)
!7 = !DISubroutineType(types: !8)
!8 = !{!9}
!9 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
!10 = !DILocation(line: 1, column: 16, scope: !6)
!11 = !DILocation(line: 3, column: 3, scope: !6)
LLVM is not generating the respective DW_TAG_label. For example, gcc generates:
<2><4a>: Abbrev Number: 3 (DW_TAG_label)
<4b> DW_AT_name: top
<4f> DW_AT_decl_file : 1
<50> DW_AT_decl_line : 2
<51> DW_AT_low_pc : 0x0
This is useful because it allows one to set a breakpoint through the label.
--
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 35480] Failure to hit a breakpoint in global constructors in a shared library
https://bugs.llvm.org/show_bug.cgi?id=35480 Tamas Berghammer changed: What|Removed |Added CC||tbergham...@google.com Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Tamas Berghammer --- *** This bug has been marked as a duplicate of bug 25806 *** -- 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 35527] New: ARM interrupt attribute warning doesn't correctly handle function pointers
https://bugs.llvm.org/show_bug.cgi?id=35527
Bug ID: 35527
Summary: ARM interrupt attribute warning doesn't correctly
handle function pointers
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: jonat...@codesourcery.com
CC: llvm-bugs@lists.llvm.org
https://reviews.llvm.org/D28820
```
typedef void __attribute__((interrupt("IRQ"))) (*interrupt_callback_t)(uint32_t
i, void *ctx);
interrupt_callback_t interrupt_callee;
typedef void (*callback_t)(uint32_t i, void *ctx);
callback_t callee;
void __attribute((interrupt("IRQ"))) __cs3_isr_irq() {
interrupt_callee(42, NULL); // don't warn here
callee(37, NULL); // do warn here
}
```
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35528] New: ARM interrupt attribute warning doesn't have its own flag
https://bugs.llvm.org/show_bug.cgi?id=35528 Bug ID: 35528 Summary: ARM interrupt attribute warning doesn't have its own flag Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: jonat...@codesourcery.com CC: llvm-bugs@lists.llvm.org https://reviews.llvm.org/D28820 Not sure what to call it. How about `-Warm-interrupt-safety`? -- 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 35503] Bug in union member handling in TBAA
https://bugs.llvm.org/show_bug.cgi?id=35503 Ivan Kosarev changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #7 from Ivan Kosarev --- (In reply to Hal Finkel from comment #6) > (In reply to Ivan Kosarev from comment #4) > > The failure is caused by this snippet: > > > > --- > > short *q; > > p->u.vec[i] = 0; > > q = &p->u.vec[16]; > > *q = 1; > > return p->u.vec[i]; > > --- > > > > LLVM currently implements a TBAA model that assumes that differently-typed > > accesses may never alias. For this reason we require accesses to union > > members to have their most enclosed union objects specified explicitly and > > taking addresses of union members is thus not allowed in strict-aliasing > > mode. > > No, I don't believe that's a model we do, or can, implement. What we have > agreed is that type-changing accesses must be explicitly through the > containing union. This, however, does not prohibit taking points to union > members. It simply means that access through such pointers can't be > type-changing accesses. Ah, I see. So the idea is that type-changing accesses work as barriers, and between that barriers types of pointers match the types of objects they point to. I think we can implement this. Will prepare another patch. Thanks a lot for the clarifications! -- 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 35529] New: Conversion to TMHH gives wrong result
https://bugs.llvm.org/show_bug.cgi?id=35529 Bug ID: 35529 Summary: Conversion to TMHH gives wrong result Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: SystemZ Assignee: unassignedb...@nondot.org Reporter: pauls...@linux.vnet.ibm.com CC: llvm-bugs@lists.llvm.org Created attachment 19519 --> https://bugs.llvm.org/attachment.cgi?id=19519&action=edit reduced csmith program (pre-processed) Csmith discovered a program which gave a differing checksum with clang -O0: *** Analyzing wrong6.c (seed= 15242346099534488386, size= 153640): 3F15FE04: 16 88680976: 2 Different reduced builds (18): 3F15FE04: /root/llvm/build/llvm-dev/bin/clang -O3 -march=z10 wrong6.c -I/root/csmith/runtime -o a.out -w 3F15FE04: gcc -O0 -march=z10 wrong6.c -I/root/csmith/runtime -o a.out -w 3F15FE04: gcc -O1 -march=z10 wrong6.c -I/root/csmith/runtime -o a.out -w 3F15FE04: gcc -O0 -march=z13 wrong6.c -I/root/csmith/runtime -o a.out -w 3F15FE04: gcc -O1 -march=z13 wrong6.c -I/root/csmith/runtime -o a.out -w 88680976: /root/llvm/build/llvm-dev/bin/clang -O0 -march=z10 wrong6.c -I/root/csmith/runtime -o a.out -w 88680976: /root/llvm/build/llvm-dev/bin/clang -O0 -march=z13 wrong6.c -I/root/csmith/runtime -o a.out -w 3F15FE04: /root/llvm/build/llvm-dev/bin/clang -O3 -march=z13 wrong6.c -I/root/csmith/runtime -o a.out -w opt -instsimplify corrected the output... The non-simplified condition check was not correctly handled. I am not sure exactly what goes wrong, but by commenting out like // Check whether the mask is suitable for TMHH, TMHL, TMLH or TMLL. // if (!SystemZ::isImmLL(Mask) && !SystemZ::isImmLH(Mask) && // !SystemZ::isImmHL(Mask) && !SystemZ::isImmHH(Mask)) return 0; , the correct checksum is printed, which makes it seem that the TMHH conversion contains the bug. This if statement is always false (and with -instsimplify it is removed): static int16_t g_5 = (-9L); ... int64_t p_3 = g_5; if (((0 > p_3) >= 3L)) (*g_1619) = 0; The store of 0 to g_1619 should never happen (a jump *should* be made to BB0_17, past BB0_16 which contains the store) The diff of the .s files is actually very small in this block: correct bad .LBB0_15: .LBB0_15: brasl %r14, platform_main_b brasl %r14, platform_main_b brasl %r14, crc32_gentab@PL brasl %r14, crc32_gentab@PL lghrl %r0, g_5lghrl %r0, g_5 srlg%r1, %r0, 63 | tmhh%r0, 32768 stg %r0, 184(%r15) stg %r0, 184(%r15) cgijl %r1, 3, .LBB0_17 | je .LBB0_17 It seems that to the left both the check for p_3 being negative and then comparing that to 3, while the tmhh just checks for the sign bit and forgets the check against 3L..? bin/clang -O0 -march=z13 w6.i -o a.out -w ./a.out checksum = 6522DF69 // BAD checksum bin/clang -O1 -march=z13 w6.i -o a.out -w ./a.out checksum = B5499A84 // GOOD checksum -- 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 35530] New: [DI] LLVM loses track of induction variables at -O1 and beyond
https://bugs.llvm.org/show_bug.cgi?id=35530
Bug ID: 35530
Summary: [DI] LLVM loses track of induction variables at -O1
and beyond
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: dav...@freebsd.org
CC: apra...@apple.com, fr...@apple.com,
jdevliegh...@apple.com, jing...@apple.com,
jmole...@apple.com, llvm-bugs@lists.llvm.org,
v...@apple.com
Testcase:
$ cat missing.cpp
#include
#include
#include
int
main(void)
{
std::atomic limit(0);
std::atomic vr_ac(0);
uint64_t vr_index;
limit.store(UINT64_MAX, std::memory_order_seq_cst);
for (vr_index = 0; vr_index < limit; vr_index++)
vr_ac.store(vr_index, std::memory_order_seq_cst);
return vr_ac;
}
The quality of DI generates varies a bit depending on the optimization level.
-O0 -g:
(lldb) p vr_ac
(std::__1::atomic) $0 = 519251459
(lldb) p vr_index
(uint64_t) $1 = 519251460
(lldb) p limit
(std::__1::atomic) $2 = 18446744073709551615
-O1 -g:
(lldb) p vr_index
(uint64_t) $1 = 12232201402
(lldb) p vr_ac
error: Couldn't materialize: couldn't get the value of variable vr_ac: no
location, value may have been optimized out
error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression
(lldb) p limit
error: Couldn't materialize: couldn't get the value of variable limit: no
location, value may have been optimized out
error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression
-O2 -g (also -O3 -g):
(lldb) p vr_index
(uint64_t) $0 = 0
(lldb) p limit
error: Couldn't materialize: couldn't get the value of variable limit: no
location, value may have been optimized out
error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression
(lldb) p vr_ac
error: Couldn't materialize: couldn't get the value of variable vr_ac: no
location, value may have been optimized out
At -O1, it's not able to retrieve the values for vr_ac and limit (although
they're atomic and therefore not optimized out). At -O2, it's slightly worse as
the value of vr_index is wrong (always zero, no matter when I break).
I'm actually not on top-of-tree so the situation might have improved a bit, but
writing this down so I won't forget (and I'll test with a new compiler as soon
as I can).
--
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 35531] New: Wrong result after Loop Vectorization.
https://bugs.llvm.org/show_bug.cgi?id=35531
Bug ID: 35531
Summary: Wrong result after Loop Vectorization.
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: ilia.tara...@intel.com
CC: llvm-bugs@lists.llvm.org
This test fails with wrong result after Loop Vectorization:
= nice.c ==
unsigned int i = 0;
int main ()
{
unsigned int m = i;
unsigned int k = 1;
for (i = 0; i <= 63; ++i)
{
m &= k;
m++;
}
printf("%u\n", m);
return 0;
}
===
>>> clang -v
clang version 6.0.0 (trunk 319765)
Target: x86_64-unknown-linux-gnu
Thread model: posix
...
>>> clang -O0 -o nice.exe nice.c
>> ./nice.exe
2
>>> clang -O2 -o nice.exe nice.c
>>> ./nice.exe
0
>>> clang -O2 -o nice.exe nice.c -mllvm -opt-bisect-limit=62 && ./nice.exe
...
BISECT: running pass (61) Rotate Loops on loop
BISECT: running pass (62) Loop Distribution on function (main)
BISECT: NOT running pass (63) Loop Vectorization on function (main)
BISECT: NOT running pass (64) Loop Load Elimination on function (main)
...
2
>>> clang -O2 -o nice.exe nice.c -mllvm -opt-bisect-limit=63 && ./nice.exe
...
BISECT: running pass (62) Loop Distribution on function (main)
BISECT: running pass (63) Loop Vectorization on function (main)
BISECT: NOT running pass (64) Loop Load Elimination on function (main)
BISECT: NOT running pass (65) Combine redundant instructions on function (main)
...
0
Let's look at IR before after Loop Vectorization:
nice.after.ll
...
%9 = extractelement <16 x i1> %bin.rdx6, i32 0
%10 = zext i1 %9 to i32; used i1, but variable m at the end of for can be
only 1 or 2.
%cmp.n = icmp eq i32 64, 64
br i1 %cmp.n, label %for.end, label %scalar.ph
...
for.end: ; preds = %middle.block,
%for.body
%inc.lcssa = phi i32 [ %inc, %for.body ], [ %10, %middle.block ]; result is
in %10
store i32 64, i32* @i, align 4, !tbaa !2
%call = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x
i8], [4 x i8]* @.str, i64 0, i64 0), i32 %inc.lcssa)
ret i32 0
}
===
--
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 20801] Devirtualization fails for loop, while succeeds for a scalar call of the same method
https://bugs.llvm.org/show_bug.cgi?id=20801
Fedor Sergeev changed:
What|Removed |Added
CC||fedor.v.serg...@gmail.com
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #10 from Fedor Sergeev ---
I can confirm that devirtualization does happen with clang -Ofast
-fstrict-vtable-pointers (and still does not happen with just -Ofast).
] clang++ --version
clang version 5.0.1 (https://github.com/llvm-mirror/clang
d8199c9eaa2e16c7b64b6c18fe88d4339321496e) (https://github.com/llvm-mirror/llvm
8baf891c0f1426d89835f878ba94cb198d93b155)
Target: x86_64-unknown-linux-gnu
Thread model: posix
] clang++ devirt-loop.cpp -Ofast -fstrict-vtable-pointers -emit-llvm -o - -S |
sed -n "/define.*Vector/,/^}/p"
define i32 @_Z6Vectori(i32) local_unnamed_addr #0 {
%2 = icmp sgt i32 %0, 0
%3 = mul i32 %0, 123
%4 = select i1 %2, i32 %3, i32 0
ret i32 %4
}
] clang++ devirt-loop.cpp -Ofast -emit-llvm -o - -S | sed -n
"/define.*Vector/,/^}/p" | grep call
%2 = tail call i8* @_Znwm(i64 8) #4
%8 = tail call i32 @_ZN1A1fEv(%class.A* nonnull %3)
%18 = tail call i32 %17(%class.A* nonnull %3)
]
--
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 35532] New: Merge r315889 into the 5.0 branch : bpf: fix bug on silently truncating 64-bit immediate
https://bugs.llvm.org/show_bug.cgi?id=35532 Bug ID: 35532 Summary: Merge r315889 into the 5.0 branch : bpf: fix bug on silently truncating 64-bit immediate Product: new-bugs Version: 5.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: tstel...@redhat.com CC: llvm-bugs@lists.llvm.org Blocks: 34492 Is it OK to merge the following revision(s) to the 5.0 branch? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=34492 [Bug 34492] [meta] 5.0.1 Release Blockers -- 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 30890] Reduction across teams hangs at __kmpc_end_reduce()
https://bugs.llvm.org/show_bug.cgi?id=30890 Jonas Hahnfeld changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||r319788 Status|ASSIGNED|RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35532] Merge r315889 into the 5.0 branch : bpf: fix bug on silently truncating 64-bit immediate
https://bugs.llvm.org/show_bug.cgi?id=35532 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Fixed By Commit(s)|r315889 |r315889 r319633 --- Comment #7 from Tom Stellard --- Ok, then it sounds like we are all set. I'll just leave the commit as is. -- 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 34492] [meta] 5.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=34492 Bug 34492 depends on bug 35532, which changed state. Bug 35532 Summary: Merge r315889 into the 5.0 branch : bpf: fix bug on silently truncating 64-bit immediate https://bugs.llvm.org/show_bug.cgi?id=35532 What|Removed |Added Status|ASSIGNED|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 35533] New: Wasm backend COMDAT support
https://bugs.llvm.org/show_bug.cgi?id=35533
Bug ID: 35533
Summary: Wasm backend COMDAT support
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
In order to support C++, the Wasm target needs to support COMDATs.
### Aside - linkonce_odr and MachO
Alternatively, it might also be possible to get by with only linkonce_odr
support, similarly to how MachO does it.
Pros:
* linkonce_odr sounds like it will be simpler, since it's one flag to pass to
the linker rather than a map of strings
Cons:
* MachO may be less well understood than ELF (certainly by me!)
* Everything else in Wasm is ELF-ish at the moment
* MachO is known to be limited in various ways, and maybe more bits of MachO
need to be implemented as well as just linkonce_odr to get full C++ support
* There may be compat concerns for migrating existing Emscripten code? (Might
just be FUD, but I don't know...)
* COMDAT actually encodes more information, by linking data/globals/functions
together into one linkable object. The richer info should actually make LLD
simpler!
### Use-cases to support
inline const char* basicFunction() {
// Ideally data like this wouldn't be duplicated for every
// translation unit including basicFunction()
return "string";
}
typedef const char* (*fnSig)();
fnSig takeInlineAddress() {
// We must guarantee that if we pass the function pointer between
// translation units, the pointers are equal!
return &basicFunction;
}
struct InlineClass {
InlineClass() {} // These are inline too
~InlineClass() {}
};
// This one is very nasty - the vtable goes in a COMDAT, and must be
// de-duplicated so that in all translation units the constructor sets the
// the vtable pointer to point to the same address.
template
struct VirtualTemplClass {
VirtualTemplClass() {}
virtual ~VirtualTemplClass() {}
};
template struct VirtualTemplClass;
### Work to cover
1. Must add COMDAT to the Wasm linkage data for LLD to read
2. Must avoid errors on encountering duplicate functions if taken from the same
COMDAT
3. Must "compress" the function table. Currently, the function tables from
every object file are simply concatenated, but they must instead be assigned
indexes exactly once so that each function has a unique function pointer, for
use by the relocations.
4. No need to worry about the types we export (we already make sure not to
write out the same type twice)
5. No need to worry about imports (again, they're only generated once per
Symtab entry, not once per input file)
6. Need to make sure that exports are duplicated
7. Must merge data segments that are duplicates due to COMDAT (eg vtables)
8. Must merge global variables pointing to those data segments (eg
address-of-vtable variables)
--
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 35414] WASM backend cannot build libcxx - fails on .text.__startup section
https://bugs.llvm.org/show_bug.cgi?id=35414 Dan Gohman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dan Gohman --- The .text.__startup issue is fixed in r319801. -- 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 35534] New: Wasm backend duplicate function pruning
https://bugs.llvm.org/show_bug.cgi?id=35534
Bug ID: 35534
Summary: Wasm backend duplicate function pruning
Product: lld
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedb...@nondot.org
Reporter: n...@realvnc.com
CC: llvm-bugs@lists.llvm.org
This is as a follow-on to COMDAT support
(https://bugs.llvm.org/show_bug.cgi?id=35533). I've split this out from bug
35533 because it's not a functional requirement; COMDAT works fine without this
refinement albeit with huge binaries.
Currently, our binary size is bigger than it need be, because duplicate
functions aren't removed.
For example, if two files both include the following code:
void __attribute__((weak)) weakFn() {}
then the output Wasm from LLD will include *both* definitions of weakFn (one
from each input file), even though relocations will ensure that all callers
only ever call the first-defined instance.
This is a result of LLD dumbly concatenating the code sections of each object
file. It should prune function definitions where the Symbol for the function is
actually defined in a different object file.
This will greatly reduce code bloat for weak symbols and COMDAT (inline)
function definitions.
--
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 35535] New: Wasm backend duplicate data pruning
https://bugs.llvm.org/show_bug.cgi?id=35535
Bug ID: 35535
Summary: Wasm backend duplicate data pruning
Product: lld
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedb...@nondot.org
Reporter: n...@realvnc.com
CC: llvm-bugs@lists.llvm.org
This is as a follow-on to COMDAT support
(https://bugs.llvm.org/show_bug.cgi?id=35533). I've split this out from bug
35533 because it's not a functional requirement; COMDAT works fine without this
refinement albeit with huge binaries.
Currently, our binary size is bigger than it need be, because duplicate data is
removed.
In a function like this:
inline const char* inlineStringFn() { return "string"; }
extern void importedFn(int* dat);
inline void inlineArrayFn() {
const int dat[] = {1,2,3,4,5,6,7,8,9};
importedFn(dat);
}
the string data is NOT part of a COMDAT, surprisingly. It does go in its own
section named ".rodata.". However, there isn't a clear
command to the linker, as far as I can see, to ensure that the duplicate data
is pruned. Again, in the case inlineArrayFn() it looks like the front-end is
relying on the linker to do some kind of de-deplication, because the read-only
data is put in a separate section but not put in a COMDAT, so LLD is going to
have to de-duplicate it in some other way.
In any case, string data is a special case that deserves special attention,
regardless of inline functions.
LLD needs to ensure that when linking Wasm, strings and other read-only data
sections with duplicate contents are merged. I think ld has a pass for
de-duping constant data, and is able to special-case string data by
string-by-string de-duping, and for other data sections is able to hash the
whole section and avoid linking in duplicate data.
--
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 4537 in oss-fuzz: llvm/clang-fuzzer: ASSERT: isa(Val) && "cast() argument of incompatible type!"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, llvm-b...@lists.llvm.org, v...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2017-12-05 Type: Bug New issue 4537 by ClusterFuzz-External: llvm/clang-fuzzer: ASSERT: isa(Val) && "cast() argument of incompatible type!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4537 Detailed report: https://oss-fuzz.com/testcase?key=5542430263738368 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: isa(Val) && "cast() argument of incompatible type!" FindDeclaringClass diagnoseBadDirectAccess Sanitizer: address (ASAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5542430263738368 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35536] New: lld might be creating DSOs that takes more time to load for the dynamic loader than those created by gold
https://bugs.llvm.org/show_bug.cgi?id=35536 Bug ID: 35536 Summary: lld might be creating DSOs that takes more time to load for the dynamic loader than those created by gold Product: lld Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org According to http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20171127/506937.html, LLVM component build time with lld is slower than that with gold. gold: 138.207661064 seconds time elapsed lld master: 143.343427881 seconds time elapsed cutting bloom filter in half: 148.267076771 seconds time elapsed bloom filter of size 1: 180.053104591 seconds time elapsed It implies that our DSO outputs are inefficient for the dynamic loader than gold. This is not high priority, but we want to investigate it. -- 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 35529] Conversion to TMHH gives wrong result
https://bugs.llvm.org/show_bug.cgi?id=35529 Ulrich Weigand changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Ulrich Weigand --- Should be fixed as r319818. -- 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 35537] New: Merge r312509 into the 5.0 branch : NewGVN: Fix PR 34452 by passing instruction all the way down when we do aggregat
https://bugs.llvm.org/show_bug.cgi?id=35537 Bug ID: 35537 Summary: Merge r312509 into the 5.0 branch : NewGVN: Fix PR 34452 by passing instruction all the way down when we do aggregat Product: new-bugs Version: 5.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: tstel...@redhat.com CC: llvm-bugs@lists.llvm.org Blocks: 34492 Is it OK to merge the following revision(s) to the 5.0 branch? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=34492 [Bug 34492] [meta] 5.0.1 Release Blockers -- 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 35538] New: [LoopVectorize] fast-math-flags on fcmp are not propagated correctly
https://bugs.llvm.org/show_bug.cgi?id=35538
Bug ID: 35538
Summary: [LoopVectorize] fast-math-flags on fcmp are not
propagated correctly
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
This is the IR for the max loop in bug 35284 when compiled with
-ffinite-math-only:
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.13.0"
define float @test(float* nocapture readonly %a, i32 %N) #0 {
entry:
%cmp12 = icmp sgt i32 %N, 0
br i1 %cmp12, label %for.body.lr.ph, label %for.cond.cleanup
for.body.lr.ph:
%wide.trip.count = zext i32 %N to i64
br label %for.body
for.cond.cleanup:
%max.0.lcssa = phi float [ -1.00e+00, %entry ], [ %max.0., %for.body ]
ret float %max.0.lcssa
for.body:
%indvars.iv = phi i64 [ 0, %for.body.lr.ph ], [ %indvars.iv.next, %for.body ]
%max.013 = phi float [ -1.00e+00, %for.body.lr.ph ], [ %max.0., %for.body
]
%arrayidx = getelementptr inbounds float, float* %a, i64 %indvars.iv
%0 = load float, float* %arrayidx, align 4, !tbaa !3
%cmp1.inv = fcmp nnan ninf oge float %0, %max.013
%max.0. = select i1 %cmp1.inv, float %0, float %max.013
%indvars.iv.next = add nuw nsw i64 %indvars.iv, 1
%exitcond = icmp eq i64 %indvars.iv.next, %wide.trip.count
br i1 %exitcond, label %for.cond.cleanup, label %for.body
}
attributes #0 = { norecurse nounwind readonly ssp uwtable
"correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false"
"less-precise-fpmad"="false" "no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="true"
"no-jump-tables"="false" "no-nans-fp-math"="true"
"no-signed-zeros-fp-math"="false" "no-trapping-math"="false"
"stack-protector-buffer-size"="8" "target-cpu"="penryn"
"target-features"="+cx16,+fxsr,+mmx,+sse,+sse2,+sse3,+sse4.1,+ssse3,+x87"
"unsafe-fp-math"="false" "use-soft-float"="false" }
!llvm.module.flags = !{!0, !1}
!llvm.ident = !{!2}
!0 = !{i32 1, !"wchar_size", i32 4}
!1 = !{i32 7, !"PIC Level", i32 2}
!2 = !{!"clang version 6.0.0 (trunk 319684)"}
!3 = !{!4, !4, i64 0}
!4 = !{!"float", !5, i64 0}
!5 = !{!"omnipotent char", !6, i64 0}
!6 = !{!"Simple C/C++ TBAA"}
---
$ ./opt -loop-vectorize 35284finite.ll -S | grep fast
%rdx.minmax.cmp = fcmp fast ogt <4 x float> %11, %12
%rdx.minmax.cmp4 = fcmp fast ogt <4 x float> %rdx.minmax.select, %rdx.shuf
%rdx.minmax.cmp7 = fcmp fast ogt <4 x float> %rdx.minmax.select5, %rdx.shuf6
The vectorizer took one fcmp with only 'nnan ninf', and it got replicated to
'fast' sometimes...but not all the time:
$ ./opt -loop-vectorize 35284finite.ll -S | grep nnan
%8 = fcmp nnan ninf oge <4 x float> %wide.load, %vec.phi
%9 = fcmp nnan ninf oge <4 x float> %wide.load3, %vec.phi2
%cmp1.inv = fcmp nnan ninf oge float %15, %max.013
--
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 35539] New: Clang does not diagnose calls to non-constexpr member functions from constexpr member functions
https://bugs.llvm.org/show_bug.cgi?id=35539
Bug ID: 35539
Summary: Clang does not diagnose calls to non-constexpr member
functions from constexpr member functions
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: lebedev...@gmail.com
CC: llvm-bugs@lists.llvm.org
Not sure if this is a gcc or clang problem.
struct A {
void b(){}
constexpr void c(){b();}
};
With -std=c++14, clang trunk compiles it just fine, and gcc trunk does not:
: In member function 'constexpr void A::c()':
3 : :3:23: error: call to non-'constexpr' function 'void A::b()'
constexpr void c(){b();}
~^~
Compiler exited with result code 1
https://godbolt.org/g/E9cioD
--
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 34123] Clangd fails with 'LLVM ERROR: inconsistency in registered CommandLine options' with deb package
https://bugs.llvm.org/show_bug.cgi?id=34123 Tom Stellard changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED Assignee|unassignedb...@nondot.org |benny@gmail.com --- Comment #13 from Tom Stellard --- Hi Benjamin, Is this OK to merge: https://reviews.llvm.org/rL314107 -- 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 34492] [meta] 5.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=34492 Bug 34492 depends on bug 34123, which changed state. Bug 34123 Summary: Clangd fails with 'LLVM ERROR: inconsistency in registered CommandLine options' with deb package https://bugs.llvm.org/show_bug.cgi?id=34123 What|Removed |Added Status|RESOLVED|REOPENED 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 34492] [meta] 5.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=34492 Bug 34492 depends on bug 33839, which changed state. Bug 33839 Summary: [C++1z] Bogus warning of unused variable during range-based iteration of templated type https://bugs.llvm.org/show_bug.cgi?id=33839 What|Removed |Added Status|RESOLVED|REOPENED 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 35517] Delete called in virtual destructor
https://bugs.llvm.org/show_bug.cgi?id=35517 Eli Friedman changed: What|Removed |Added Status|NEW |RESOLVED CC||efrie...@codeaurora.org Resolution|--- |INVALID --- Comment #1 from Eli Friedman --- This is how the ABI works. https://eli.thegreenplace.net/2015/c-deleting-destructors-and-virtual-operator-delete/ has a good description of deleting destructors. Also, please use the cfe-dev mailing list, not the bugtracker, for questions about clang's behavior. -- 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 34123] Clangd fails with 'LLVM ERROR: inconsistency in registered CommandLine options' with deb package
https://bugs.llvm.org/show_bug.cgi?id=34123 Tom Stellard changed: What|Removed |Added Status|REOPENED|RESOLVED Fixed By Commit(s)|r314107 |r314107 r319846 Resolution|--- |FIXED --- Comment #15 from Tom Stellard --- Merged: r319846 -- 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 34492] [meta] 5.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=34492 Bug 34492 depends on bug 34123, which changed state. Bug 34123 Summary: Clangd fails with 'LLVM ERROR: inconsistency in registered CommandLine options' with deb package https://bugs.llvm.org/show_bug.cgi?id=34123 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34492] [meta] 5.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=34492 Bug 34492 depends on bug 33839, which changed state. Bug 33839 Summary: [C++1z] Bogus warning of unused variable during range-based iteration of templated type https://bugs.llvm.org/show_bug.cgi?id=33839 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35540] New: Clang crash for OpenCL local void** arithmetic
https://bugs.llvm.org/show_bug.cgi?id=35540
Bug ID: 35540
Summary: Clang crash for OpenCL local void** arithmetic
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: OpenCL
Assignee: unassignedclangb...@nondot.org
Reporter: pjc...@gmail.com
CC: llvm-bugs@lists.llvm.org
On this module:
-bash-4.1$ cat t.cl
void st(int, local void *);
void process(local void ** wr) {
st(5, wr[0] + 2);
}
clang asserts with:
clang -target spir -S -emit-llvm t.cl
clang-6.0: /SCRATCH/petecoup/llvm-monorepo/llvm/lib/IR/Instructions.cpp:2565:
static llvm::CastInst* llvm::CastInst::Create(llvm::Instruction::CastOps,
llvm::Value*, llvm::Type*, const llvm::Twine&, llvm::Instruction*): Assertion
`castIsValid(op, S, Ty) && "Invalid cast!"' failed.
#0 0x020a139a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/SCRATCH/petecoup/build_monorepo/bin/clang-6.0+0x20a139a)
#1 0x0209f23e llvm::sys::RunSignalHandlers()
(/SCRATCH/petecoup/build_monorepo/bin/clang-6.0+0x209f23e)
#2 0x0209f3a2 SignalHandler(int)
(/SCRATCH/petecoup/build_monorepo/bin/clang-6.0+0x209f3a2)
#3 0x77bcf710 __restore_rt (/lib64/libpthread.so.0+0xf710)
#4 0x76807625 __GI_raise (/lib64/libc.so.6+0x32625)
#5 0x76808e05 __GI_abort (/lib64/libc.so.6+0x33e05)
#6 0x7680074e __assert_fail_base (/lib64/libc.so.6+0x2b74e)
#7 0x76800810 __GI___assert_perror_fail (/lib64/libc.so.6+0x2b810)
#8 0x01ba8e57
(/SCRATCH/petecoup/build_monorepo/bin/clang-6.0+0x1ba8e57)
#9 0x0228ae56 llvm::IRBuilder::CreateCast(llvm::Instruction::CastOps,
llvm::Value*, llvm::Type*, llvm::Twine const&)
(/SCRATCH/petecoup/build_monorepo/bin/clang-6.0+0x228ae56)
--
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 35541] New: X86: 32 bit reloc applied to field with different size
https://bugs.llvm.org/show_bug.cgi?id=35541 Bug ID: 35541 Summary: X86: 32 bit reloc applied to field with different size Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: eric.schwe...@pgroup.com CC: llvm-bugs@lists.llvm.org Created attachment 19520 --> https://bugs.llvm.org/attachment.cgi?id=19520&action=edit reproducer for bad relocation with -code-model=medium This bug happens in my latest trunk build. Similar failures happen in 5.0, 4.0, and 3.9 as well. % llc -relocation-model=pic -code-model=medium -filetype=obj -o bug.o bug.bc LLVM ERROR: 32 bit reloc applied to a field with a different size -- 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
