[llvm-bugs] [Bug 31863] New: Clang can't read back a PCH just produced: Assertion failed: (D && "Cannot get layout of forward declarations!"), function getASTRecordLayout
https://llvm.org/bugs/show_bug.cgi?id=31863 Bug ID: 31863 Summary: Clang can't read back a PCH just produced: Assertion failed: (D && "Cannot get layout of forward declarations!"), function getASTRecordLayout Product: clang Version: 4.0 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Modules Assignee: unassignedclangb...@nondot.org Reporter: mehdi.am...@apple.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17936 --> https://llvm.org/bugs/attachment.cgi?id=17936&action=edit Repro reduced Clang-4.0 (and trunk) are crashing when building Unreal Engine, a PCH can't be read back we hit this assertion. I believe this is a regression from clang-3.9 introduced in r276159: Author: Richard Smith Date: Wed Jul 20 14:10:16 2016 [modules] Don't emit initializers for VarDecls within a module eagerly whenever we first touch any part of that module. Instead, defer them until the first time that module is (transitively) imported. The initializer step for a module then recursively initializes modules that its own headers imported. For example, this avoids running the global initializer in programs that don't actually use iostreams, but do use other parts of the standard library. Reduced repro attached. Run with: clang -c -x objective-c++-header pre.h -std=c++14 -o pre.gch clang -c -x objective-c++ /dev/null-std=c++14 -include-pch pre.gch -- 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 31864] New: 4.0/trunk regression: after r291477, incorrect _GCC_ATOMIC_LLONG_LOCK_FREE values on i386-freebsd
https://llvm.org/bugs/show_bug.cgi?id=31864
Bug ID: 31864
Summary: 4.0/trunk regression: after r291477, incorrect
_GCC_ATOMIC_LLONG_LOCK_FREE values on i386-freebsd
Product: new-bugs
Version: 4.0
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: dimi...@andric.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
In r291477, some long-standing inconsistencies with
__GCC_ATOMIC_LLONG_LOCK_FREE were fixed, solving bug 19355
(__GCC_ATOMIC_LLONG_LOCK_FREE only set to 1 on X86) and bug 30581 (Inconsistent
value of ATOMIC_LLONG_LOCK_FREE vs __atomic_always_lock_free(sizeof(long long),
0) on 32-bit x86).
However, this fix has the unfortunate side effect of making the value of
__GCC_ATOMIC_LLONG_LOCK_FREE incorrect on 32-bit FreeBSD, e.g. the
i386-unknown-freebsd target. This is because 32-bit FreeBSD defaults to
targeting i486, not i686 like most Linuxes:
$ uname -srm
FreeBSD 12.0-CURRENT i386
$ gcc -dM -E -x c /dev/null | grep LLONG_LOCK
#define __GCC_ATOMIC_LLONG_LOCK_FREE 1
$ clang-3.9.1 -dM -E -x c /dev/null | grep LLONG_LOCK
#define __GCC_ATOMIC_LLONG_LOCK_FREE 1
$ clang-4.0.0 -dM -E -x c /dev/null | grep LLONG_LOCK
#define __GCC_ATOMIC_LLONG_LOCK_FREE 2
As I mentioned in https://reviews.llvm.org/D28213, the value of
__GCC_ATOMIC_LLONG_LOCK_FREE is now still incorrect, even on Linux, if you
target i486:
$ uname -srm
Linux 3.16.0-4-686-pae i686
$ gcc -dM -E -x c /dev/null | grep LLONG_LOCK
#define __GCC_ATOMIC_LLONG_LOCK_FREE 2
$ gcc -march=i486 -dM -E -x c /dev/null | grep LLONG_LOCK
#define __GCC_ATOMIC_LLONG_LOCK_FREE 1
It turns out that this has been broken since quite some time (r142002, to be
exact), as tools/clang/lib/Basic/Targets.cpp has this comment:
X86_32TargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
: X86TargetInfo(Triple, Opts) {
[...]
// x86-32 has atomics up to 8 bytes
// FIXME: Check that we actually have cmpxchg8b before setting
// MaxAtomicInlineWidth. (cmpxchg8b is an i586 instruction.)
MaxAtomicPromoteWidth = MaxAtomicInlineWidth = 64;
We need to either fix this constructor to assign the correct max atomic inline
width for the target (either via the triple or via -march=), or r291477 must be
reverted.
--
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 31865] New: lldb asserts "Architecture or OS not supported" when loading RHEL core dump
https://llvm.org/bugs/show_bug.cgi?id=31865
Bug ID: 31865
Summary: lldb asserts "Architecture or OS not supported" when
loading RHEL core dump
Product: lldb
Version: 4.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: vladimir.guba...@itiviti.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
This bug is similar with https://llvm.org/bugs/show_bug.cgi?id=30485.
On RHEL6,7 we've no any of /lib/{x86_64,i386}-linux-gnu multilib path. Then
solution proposed here https://reviews.llvm.org/D25179 is only for
Ubuntu/Debian system and does not touch RedHat Linux.
The core dump was produced by an Red Hat Enterprise Linux Server release 7.2
(Maipo) (OS version:3.10.0-327.el7.x86_64).
Command used to launch lldb:
vladimirg@test> ~/opensource/build/bin/lldb ~/sandbox/coredump --core
coredump-27248.core
(lldb) target create "/export/home/vladimirg/sandbox/coredump" --core
"coredump-27248.core"
lldb:
/export/home/vladimirg/opensource/llvm/tools/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp:145:
virtual RegisterContextSP
ThreadElfCore::CreateRegisterContextForFrame(lldb_private::StackFrame *):
Assertion `false && "Architecture or OS not supported"' failed.
Aborted (core dumped)
Notes from coredump:
vladimirg@test> readelf -n coredump-27248.core
Notes at offset 0x0430 with length 0x0608:
Owner Data sizeDescription
CORE 0x0150NT_PRSTATUS (prstatus structure)
CORE 0x0088NT_PRPSINFO (prpsinfo structure)
CORE 0x0080NT_SIGINFO (siginfo_t data)
CORE 0x0130NT_AUXV (auxiliary vector)
CORE 0x021aNT_FILE (mapped files)
Page size: 4096
Start End Page Offset
0x0040 0x00401000 0x
/export/home/vladimirg/sandbox/coredump
0x0060 0x00601000 0x
/export/home/vladimirg/sandbox/coredump
0x00601000 0x00602000 0x0001
/export/home/vladimirg/sandbox/coredump
0x77a1c000 0x77bd2000 0x
/usr/lib64/libc-2.17.so
0x77bd2000 0x77dd2000 0x01b6
/usr/lib64/libc-2.17.so
0x77dd2000 0x77dd6000 0x01b6
/usr/lib64/libc-2.17.so
0x77dd6000 0x77dd8000 0x01ba
/usr/lib64/libc-2.17.so
0x77ddd000 0x77dfd000 0x
/usr/lib64/ld-2.17.so
0x77ffc000 0x77ffd000 0x001f
/usr/lib64/ld-2.17.so
I'll provide coredump and binary if needed.
I think we should pay attention on this bug because it really blocks usage of
lldb on RHEL.
--
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 31622] [meta] 4.0.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=31622 Bug 31622 depends on bug 30879, which changed state. Bug 30879 Summary: libunwind on i386: cannot deal with absence of frame pointers, even though libgcc can https://llvm.org/bugs/show_bug.cgi?id=30879 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 30261] [Meta] 3.9.1 Merges and Bug Fixes
https://llvm.org/bugs/show_bug.cgi?id=30261 Bug 30261 depends on bug 30879, which changed state. Bug 30879 Summary: libunwind on i386: cannot deal with absence of frame pointers, even though libgcc can https://llvm.org/bugs/show_bug.cgi?id=30879 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 30879] libunwind on i386: cannot deal with absence of frame pointers, even though libgcc can
https://llvm.org/bugs/show_bug.cgi?id=30879 Sjors Gielen changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #36 from Sjors Gielen --- Actually, the problem is not fixed for me, I just accidentally had the workaround still applied. So, even with libunwind 3.9.1 with r292723 applied, my i686 binaries still explode when they throw an exception. These binaries were produced with -O3. If I add the workaround, "-mllvm -no-x86-call-frame-opt" to the compiler commandline, the problem is still absent. -- 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 31866] New: Squaring a complex float gives inefficient code
https://llvm.org/bugs/show_bug.cgi?id=31866
Bug ID: 31866
Summary: Squaring a complex float gives inefficient code
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: drr...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Consider:
#include
complex float f(complex float x) {
return x*x;
}
clang trunk with -O3 -march=core-avx2 gives
f: # @f
vmovaps xmm2, xmm0
vmovshdup xmm1, xmm2 # xmm1 = xmm2[1,1,3,3]
vmulss xmm0, xmm2, xmm2
vmulss xmm3, xmm1, xmm1
vmulss xmm4, xmm2, xmm1
vsubss xmm0, xmm0, xmm3
vaddss xmm3, xmm4, xmm4
vucomissxmm0, xmm0
jnp .LBB0_3
vucomissxmm3, xmm3
jp .LBB0_2
.LBB0_3:
vinsertps xmm0, xmm0, xmm3, 16 # xmm0 = xmm0[0],xmm3[0],xmm0[2,3]
ret
.LBB0_2:
pushrax
vmovaps xmm0, xmm2
vmovaps xmm3, xmm1
call__mulsc3
vmovshdup xmm3, xmm0 # xmm3 = xmm0[1,1,3,3]
add rsp, 8
vinsertps xmm0, xmm0, xmm3, 16 # xmm0 = xmm0[0],xmm3[0],xmm0[2,3]
ret
The Intel C compiler with -fp-model strict gives
f:
vmovsldup xmm1, xmm0#3.12
vmovshdup xmm2, xmm0#3.12
vshufps xmm3, xmm0, xmm0, 177 #3.12
vmulpsxmm4, xmm1, xmm0 #3.12
vmulpsxmm5, xmm2, xmm3 #3.12
vaddsubps xmm0, xmm4, xmm5 #3.12
ret
"strict" should be value safe, turn on floating point exception semantics and
also disable fuse multiply add. "precise" is the setting to use if you just
want it to be value safe. -fp-model precise -fp-model except gives
f:
vmovshdup xmm1, xmm0#3.12
vshufps xmm2, xmm0, xmm0, 177 #3.12
vmulpsxmm4, xmm1, xmm2 #3.12
vmovsldup xmm3, xmm0#3.12
vfmaddsub213ps xmm0, xmm3, xmm4 #3.12
ret
gcc 7 gives code that is shorter than clang does but still call __mulsc3 .
f:
vmovq QWORD PTR [rsp-16], xmm0
vmovss xmm3, DWORD PTR [rsp-12]
vmovss xmm2, DWORD PTR [rsp-16]
vmovaps xmm1, xmm3
vmovaps xmm0, xmm2
jmp __mulsc3
If you enable -ffast-math in clang it is much better although not quite optimal
with:
f: # @f
vmovshdup xmm1, xmm0 # xmm1 = xmm0[1,1,3,3]
vaddss xmm2, xmm0, xmm0
vmulss xmm2, xmm1, xmm2
vmulss xmm1, xmm1, xmm1
vfmsub231ss xmm1, xmm0, xmm0
vinsertps xmm0, xmm1, xmm2, 16 # xmm0 = xmm1[0],xmm2[0],xmm1[2,3]
ret
>From my non-expert eyes it seems there are two questions:
1) In the "no fast-math" case is ICC actually meeting the C99 specs?
2) In the "fast-math" case can clang/llvm be persuaded/changed to use one call
to vmulps instead of two calls to vmulss?
--
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 31849] Improper alignment in pointer cast in unordered_map of std::aligned_storage
https://llvm.org/bugs/show_bug.cgi?id=31849 Eric Fiselier changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Eric Fiselier --- This has already been fixed in 4.0. I thought the fix made it into 3.9 but it appears it didn't. The UB fixes for __tree made it in, but not the ones for __hash_table. Thanks for the report. Feel free to file any other UBSan bugs you find in libc++ trunk. -- 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 28678] [X86][AVX] Repeated subvector insertions during insertion of elements
https://llvm.org/bugs/show_bug.cgi?id=28678 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED CC||craig.top...@gmail.com Resolution|--- |FIXED --- Comment #4 from Simon Pilgrim --- Fixed by rL293944 -- 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 31867] New: InstCombine uselessly checks for irreducible phi cycles.
https://llvm.org/bugs/show_bug.cgi?id=31867 Bug ID: 31867 Summary: InstCombine uselessly checks for irreducible phi cycles. Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: dber...@dberlin.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified InstCombinePhi has this code: // We sometimes end up with phi cycles that non-obviously end up being the // same value, for example: // z = some value; x = phi (y, z); y = phi (x, z) // where the phi nodes don't necessarily need to be in the same block. Do a // quick check to see if the PHI node only contains a single non-phi value, if // so, scan to see if the phi cycle is actually equal to that value. First, such code is impossible in minimal SSA. It should actually be impossible with the SSAUpdater too, since it generates minimal SSA. So i'm not sure what would generate it in the first place. I can't find a non-handmade testcase either. My suggestion would be to either make it a statistic, or remove it. Second, this is the ultra slow way of doing it. If it does minimize all cases, it does so non optimally (IE it is performed more than it needs to be). It's a bit hard to analyze to determine if it actually minimizes all cases. The algorithm to minimize these phis is precisely the phi minimization algorithm added to the new ssaupdater, which is an SCC algorithm that will minimize all phis in as short a time as possible. (it depends on the cycle depth. In the case given as an example above, it will be one pass). You can run this exactly once on the CFG, at the beginning or end of instcombine, and feel confident it is minimal ssa again. -- 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 31868] New: NewGVN needs support for multiple fake expressions for instructions
https://llvm.org/bugs/show_bug.cgi?id=31868 Bug ID: 31868 Summary: NewGVN needs support for multiple fake expressions for instructions Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: dber...@dberlin.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Some canonicalizations can only be represented as multiple expressions. For example, F(phi(a,b), phi(c, d)) == phi(F(a, c), F(b, d)) In the attached example, the multiplication%21 = mul nsw i64 %18, %19 is completely redundant we do not detect it because one of the multiplications is in one of the above forms, and the other is in the other. If we canonicalize both to the same (instcombine does this), we would discover it's completely redundant). WE can either move that code out of instcombine, and run it first, or we could support multiple fake expressions that get inserted at elimination time. We end up needing the latter support for PRE anyway... -- 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
