[llvm-bugs] [Bug 31525] New: Unnecessarily selects memory operand and misaligns stack
https://llvm.org/bugs/show_bug.cgi?id=31525
Bug ID: 31525
Summary: Unnecessarily selects memory operand and misaligns
stack
Product: clang
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: doug...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I am writing code that will run in kernel mode on x86-64. I have a function
which uses inline assembly to load the task register. This is my function:
typedef unsigned short uint16_t;
void cpu_set_tr(uint16_t tr)
{
__asm__ __volatile__ (
"ltr %w0\n\t"
:
: "rm" (tr)
: "memory"
);
}
Here's a link to godbolt for your convenience: https://godbolt.org/g/ijwQ7K
This is the generated code:
cpu_set_tr(unsigned short):# @cpu_set_tr(unsigned
short)
subq$2, %rsp
movw%di, (%rsp)
ltrw(%rsp)
addq$2, %rsp
retq
Note that I am using -mno-red-zone because in kernel mode, it won't switch to
another stack when an interrupt or exception occurs.
Note that there are two problems with the code:
1) It misaligns the stack. It subtracts 2 from rsp. If an interrupt occurs
here, the CPU will do many (about 46, counting context save and restore)
misaligned accesses.
2) It unnecessarily selects the memory operand alternative.
There's no reason for it to select a memory operand for this code. I expected
this:
ltr %di
retq
If I remove the "m" constraint, it does just that. This seems like a really
trivial case for it to be misaligning the stack to store a value to memory
unnecessarily, followed by reloading the stored value, due to a poorly selected
memory operand alternative.
I suspect that this bug has went unnoticed because it usually doesn't need to
adjust the stack pointer when the red zone is enabled. I have no hypothesis for
its selection of the memory operand. clang usually generates better code than
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 31527] New: llvm/lib/LTO/LTO.cpp:909: local variable 'Partition' set but not used ?
https://llvm.org/bugs/show_bug.cgi?id=31527 Bug ID: 31527 Summary: llvm/lib/LTO/LTO.cpp:909: local variable 'Partition' set but not used ? Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: dcb...@hotmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified llvm/lib/LTO/LTO.cpp:909]: (style) Variable 'Partition' is modified but its new value is never used. $ fgrep Partition trunk/llvm/lib/LTO/LTO.cpp ... // Partition numbers for ThinLTO jobs start at 1 (see comments for unsigned Partition = 1; ++Partition; $ Suggest either use the variable or delete 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 31528] New: llvm/lib/Support/NativeFormatting.cpp:244: local variable 'Len' set but not used ?
https://llvm.org/bugs/show_bug.cgi?id=31528 Bug ID: 31528 Summary: llvm/lib/Support/NativeFormatting.cpp:244: local variable 'Len' set but not used ? Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: dcb...@hotmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified llvm/lib/Support/NativeFormatting.cpp:244]: (style) Variable 'Len' is modified but its new value is never used. Source code is unsigned Len; Len = format(Spec.c_str(), N).snprint(Buf, sizeof(Buf)); if (Style == FloatStyle::Percent) ++Len; S << Buf; if (Style == FloatStyle::Percent) S << '%'; } I am not sure if local variable 'Len' needs to be used in some way, or can be safely deleted. -- 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 31529] New: llvm/lib/Target/X86/X86ISelLowering.cpp:13056: local variable 'NumSentinelElements' set but not used ?
https://llvm.org/bugs/show_bug.cgi?id=31529 Bug ID: 31529 Summary: llvm/lib/Target/X86/X86ISelLowering.cpp:13056: local variable 'NumSentinelElements' set but not used ? Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: dcb...@hotmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified llvm/lib/Target/X86/X86ISelLowering.cpp:13056]: (style) Variable 'NumSentinelElements' is modified but its new value is never used. $ fgrep NumSentinelElements trunk/llvm/lib/Target/X86/X86ISelLowering.cpp int NumV1Elements = 0, NumV2Elements = 0, NumSentinelElements = 0; ++NumSentinelElements; $ I am not sure if this local variable should be used in some way or can be safely deleted. -- 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 31530] New: UINT16_TYPE and INT16_TYPE are defined as short instead of int for AVR
https://llvm.org/bugs/show_bug.cgi?id=31530 Bug ID: 31530 Summary: UINT16_TYPE and INT16_TYPE are defined as short instead of int for AVR Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: dylanmcka...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified UINT16_TYPE and INT16_TYPE are implicitly defined by the preprocessor to the short type, rather than int. While shorts and ints are both 16 bits wide on the avr, gcc picks ints to represent 16 bits wherever possible, and picking short can cause issues with C++ name mangling (see https://reviews.llvm.org/D27123#615854). Therefore, clang should define the two types to short. Clang's lib/Frontend/InitPreprocessor.cpp::DefineExactWidthIntType does not use TargetInfo::getIntTypeByWidth. Instead, InitializePredefinedMacros calls the function with the specific type (SignedShort/UnsignedShort), because getShortWidth() > getCharWidth(), but getIntWidth() == getShortWidth(). -- 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 31532] New: Test driver/opt-record.c fails on targets that default to -no-integrated-as
https://llvm.org/bugs/show_bug.cgi?id=31532 Bug ID: 31532 Summary: Test driver/opt-record.c fails on targets that default to -no-integrated-as Product: clang Version: 3.9 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: f...@flametop.co.uk CC: llvm-bugs@lists.llvm.org Classification: Unclassified The test driver/opt-record.c attempts to check that the -fsave-optimization-record switch creates the correct output file when used with -c and -o FOO. However, if the target is a compiler which defaults to -no-integrated-as, the -fsave-optimization-record creates a file based on the temporary output .s file not the -o filename. For example, on windows clang -c -no-integrated-as -v -fsave-optimization-record -o FOO opt-record.c generates -opt-record-file "d:\\temp\\opt-record-7ecc39.opt.yaml" I am unsure if this should be treated as an error in the test or that the -fsave-optimization-record handling in the driver should ensure it uses the -o filename and not the intermediate .s file. -- 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 31534] New: AVX-512 No optimal lowering for mask_blend intrinsics.
https://llvm.org/bugs/show_bug.cgi?id=31534
Bug ID: 31534
Summary: AVX-512 No optimal lowering for mask_blend
intrinsics.
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: igor.bre...@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
In case mask is constant mask_blend intrinsic generate not optimal sequence.
It should generate vpblendm instruction.
__m512i test_mm512_mask_blend_epi32(__m512i __A, __m512i __W) {
return _mm512_mask_blend_epi32(0x,__A,__W);
}
define <8 x i64> @test_mm512_mask_blend_epi32(<8 x i64> %__A, <8 x i64> %__W)
local_unnamed_addr #0 {
entry:
%0 = bitcast <8 x i64> %__W to <16 x i32>
%1 = bitcast <8 x i64> %__A to <16 x i32>
%2 = shufflevector <16 x i32> %0, <16 x i32> %1, <16 x i32>
%3 = bitcast <16 x i32> %2 to <8 x i64>
ret <8 x i64> %3
}
# BB#0: # %entry
vmovdqa32.LCPI2_0(%rip), %zmm2 # zmm2 =
[0,17,2,19,4,21,6,23,8,25,10,27,12,29,14,31]
vpermt2d%zmm1, %zmm2, %zmm0
retq
.Lfunc_end2:
--
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 31535] New: std::sort and std::unique can not use std::function with -std=c++14
https://llvm.org/bugs/show_bug.cgi?id=31535
Bug ID: 31535
Summary: std::sort and std::unique can not use std::function
with -std=c++14
Product: libc++
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: d...@gmx.net
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
The following two minimal examples both compile with
clang++ -std=c++11 main.cpp
but do not with
clang++ -std=c++14 main.cpp
// example 1
#include
#include
#include
int main()
{
std::vector xs = {0,1,2};
std::function cmp = [](int x, int y)
{ return x < y; };
std::sort(std::begin(xs), std::end(xs), cmp);
}
// example 2
#include
#include
#include
int main()
{
std::vector xs = {0,1,2};
std::function p = [](int x, int y)
{ return x == y; };
std::unique(std::begin(xs), std::end(xs), p);
}
The error message looks like this:
In file included from
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/algorithm:61:
In file included from
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/stl_algobase.h:71:
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/predefined_ops.h:123:31:
error: indirection requires pointer operand ('int' invalid)
{ return bool(_M_comp(*__it1, *__it2)); }
The used version is the default one from the package manager in Ubuntu 16.04:
clang++ --version
clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
--
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 31536] New: Assertion failed: (NodeToMatch->getOpcode() != ISD::DELETED_NODE && "NodeToMatch was removed partway through selection"), function SelectCodeCommon
https://llvm.org/bugs/show_bug.cgi?id=31536
Bug ID: 31536
Summary: Assertion failed: (NodeToMatch->getOpcode() !=
ISD::DELETED_NODE && "NodeToMatch was removed partway
through selection"), function SelectCodeCommon
Product: new-bugs
Version: 3.9
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
As noted in bug 28705, the following test case, reduced from
https://bugs.freebsd.org/215649:
//
// clang -cc1 -triple x86_64 -S -O2 -vectorize-loops testcase.cpp
double x0;
int x1, x2, x3, x4;
double *x5;
void x6() {
x4 = (x1 & 512 - 1) + 1;
for (; x3; x3++, x5 += x4)
for (; x2 < 0; x2++)
x5[x2] = x0;
}
//
results in:
Assertion failed: (NodeToMatch->getOpcode() != ISD::DELETED_NODE &&
"NodeToMatch was removed partway through selection"), function
SelectCodeCommon, file lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp, line
3387.
It turned out that this assertion already fired in the very first
release_39 branch point, r275826, and has not been fixed during the
3.9.0 and 3.9.1 release cycles.
When I followed trunk from r275826 onwards, I ended up at Wei Mi's r276136,
which seemed to fix this assertion. However, in bug 28705 he agrees that
r276136, and its follow-ups r278160 and r278161 just seem to paper over it.
Thus I am filing this bug as a separate case. It may or may not be related to
bug 30775, which is about the same assertion (but with a different test case,
and it still occurs with the latest trunk, as of 2017-01-01).
--
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 31535] std::sort and std::unique can not use std::function with -std=c++14
https://llvm.org/bugs/show_bug.cgi?id=31535 Marshall Clow (home) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Marshall Clow (home) --- This is not a libc++ bug. The errors that you're getting show that you're using libstdc++ as your standard library. (Specifically, the path elements like '/5.4.0/bits/stl_algobase.h') Both of your test programs compile w/o errors (On Mac OS X) using either Apple's released version of clang + libc++, or ToT clang + libc++. -- 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 31528] llvm/lib/Support/NativeFormatting.cpp:244: local variable 'Len' set but not used ?
https://llvm.org/bugs/show_bug.cgi?id=31528 Eric Christopher changed: What|Removed |Added Status|NEW |RESOLVED CC||echri...@gmail.com Resolution|--- |FIXED --- Comment #1 from Eric Christopher --- I think it's just dead and so... Fixed thusly: echristo@dzur ~/s/llvm> git svn dcommit Committing to https://llvm.org/svn/llvm-project/llvm/trunk ... M lib/Support/NativeFormatting.cpp Committed r290995 Thanks! -- 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 31529] llvm/lib/Target/X86/X86ISelLowering.cpp:13056: local variable 'NumSentinelElements' set but not used ?
https://llvm.org/bugs/show_bug.cgi?id=31529 Eric Christopher changed: What|Removed |Added Status|NEW |RESOLVED CC||echri...@gmail.com Resolution|--- |FIXED --- Comment #1 from Eric Christopher --- Looks like it was completely dead. Fixed thusly: echristo@dzur ~/s/llvm> git svn dcommit Committing to https://llvm.org/svn/llvm-project/llvm/trunk ... M lib/Target/X86/X86ISelLowering.cpp Committed r290998 -- 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 31527] llvm/lib/LTO/LTO.cpp:909: local variable 'Partition' set but not used ?
https://llvm.org/bugs/show_bug.cgi?id=31527 Davide Italiano changed: What|Removed |Added Status|NEW |RESOLVED CC||dav...@freebsd.org Resolution|--- |FIXED --- Comment #1 from Davide Italiano --- r291000. -- 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 31537] New: std::sort and std::unique can not use std::function with -std=c++14
https://llvm.org/bugs/show_bug.cgi?id=31537
Bug ID: 31537
Summary: std::sort and std::unique can not use std::function
with -std=c++14
Product: clang
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++14
Assignee: unassignedclangb...@nondot.org
Reporter: d...@gmx.net
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The following two minimal examples both compile with
clang++ -std=c++11 main.cpp
but do not with
clang++ -std=c++14 main.cpp
// example 1
#include
#include
#include
int main()
{
std::vector xs = {0,1,2};
std::function cmp = [](int x, int y)
{ return x < y; };
std::sort(std::begin(xs), std::end(xs), cmp);
}
// example 2
#include
#include
#include
int main()
{
std::vector xs = {0,1,2};
std::function p = [](int x, int y)
{ return x == y; };
std::unique(std::begin(xs), std::end(xs), p);
}
The error message looks like this:
In file included from
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/algorithm:61:
In file included from
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/stl_algobase.h:71:
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/predefined_ops.h:123:31:
error: indirection requires pointer operand ('int' invalid)
{ return bool(_M_comp(*__it1, *__it2)); }
The used version is the default one from the package manager in Ubuntu 16.04:
clang++ --version
clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
--
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 31538] New: FreeBSD head (12) buildkernel based on clang FReeBSD's 3.9.1 stops for mfpmr and mtpmr instructions not being supported (used in dev/hwpmc/hwpmc_e500.c )
https://llvm.org/bugs/show_bug.cgi?id=31538
Bug ID: 31538
Summary: FreeBSD head (12) buildkernel based on clang FReeBSD's
3.9.1 stops for mfpmr and mtpmr instructions not being
supported (used in dev/hwpmc/hwpmc_e500.c )
Product: libraries
Version: 3.9
Hardware: Macintosh
OS: FreeBSD
Status: NEW
Severity: normal
Priority: P
Component: Backend: PowerPC
Assignee: unassignedb...@nondot.org
Reporter: mar...@dsl-only.net
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
[This report likely should be added to the depends on list in:
Bug 25780 - [META] Using Clang as the FreeBSD/ppc system compiler
Also stable/11 recently updated to 3.9.1 as well and also has the
use of the rejected instructions. (I've not done an explicit build
there as yet.) So it is not just head (12) that has the issue.
]
Attempting to buildkernel for FreeBSD head (12) rejects required instructions
for a standard FreeBSD build:
--- hwpmc_e500.o ---
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error:
unrecognized instruction mnemonic
uint32_t pmgc0 = mfpmr(PMR_PMGC0);
^
./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
__asm __volatile("mfpmr %0,%1" : "=r"(val) : "K"(reg)); \
^
:1:2: note: instantiated into assembly here
mfpmr 3,400
^
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:478:2: error:
unrecognized instruction mnemonic
mtpmr(PMR_PMGC0, pmgc0);
^
./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr'
__asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
^
:1:2: note: instantiated into assembly here
mtpmr 400,3
^
. . . (more examples of those instructions) . . .
A partial patch that someone provided (no instruction scheduling
logic or other such) was:
Index: /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
===
--- /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td(revision
309656)
+++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td(working copy)
@@ -2300,6 +2300,12 @@
def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR),
"mftb $RT, $SPR", IIC_SprMFTB>;
+def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN),
+ "mfpmr $RT, $PMRN", IIC_IntGeneral>;
+
+def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS),
+ "mtpmr $PMRN, $RS", IIC_IntGeneral>;
+
// A pseudo-instruction used to implement the read of the 64-bit cycle counter
// on a 32-bit target.
let hasSideEffects = 1, usesCustomInserter = 1 in
This patch was enough for buildkernel to no longer stop for these two
instructions. (I've been using the patch for some time, which explains
the 309656 revision reference above.)
(The person that provided the patch reports not having time to do
more for the instructions.)
--
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 31513] libc++ makes some tuple_size specializations complete types, breaking decomposition declarations
https://llvm.org/bugs/show_bug.cgi?id=31513 Eric Fiselier changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Eric Fiselier --- Fixed in r291019 (v4.0). Unfortunately the fix is entirely non-standard, but the standard is clearly incorrect here. I'll submit a new resolution for LWG 2770 which mirrors what libc++ actually implements shortly. -- 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 31539] New: Assertion failed: ParentSEHFn && "No CurSEHParent!" when using pre-compiled headers
https://llvm.org/bugs/show_bug.cgi?id=31539 Bug ID: 31539 Summary: Assertion failed: ParentSEHFn && "No CurSEHParent!" when using pre-compiled headers Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: tcosproje...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17802 --> https://llvm.org/bugs/attachment.cgi?id=17802&action=edit clang command line When using the ASIO network library with clang nightly LLVM-vs2014 under visual studio and using pre-compiled headers the compiler crashes with the following error: Assertion failed: ParentSEHFn && "No CurSEHParent!", file D:\src\llvm_package_288665\llvm\tools\clang\lib\CodeGen\CGException.cpp, line 1632 1>clang-cl.exe : error : clang frontend command failed due to signal (use -v to see invocation) 1> clang version 4.0.0 (trunk) 1> Target: i686-pc-windows-msvc 1> Thread model: posix 1> InstalledDir: C:\Program Files (x86)\LLVM\msbuild-bin Attaching the crash dump, pre-processed source and command line args for clang. -- 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 31500] llvm/tools/clang/lib/AST/Decl.cpp:2426: clang::Expr* clang::ParmVarDecl::getDefaultArg(): Assertion `!hasUninstantiatedDefaultArg() && "Default argument is not yet instantiated
https://llvm.org/bugs/show_bug.cgi?id=31500 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Reid Kleckner --- Really marking fixed in r291045 -- 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 26961] Enumeration type std::pointer_safety incorrectly implemented as a struct
https://llvm.org/bugs/show_bug.cgi?id=26961 Eric Fiselier changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedclangbugs@nondot. |e...@efcs.ca |org | --- Comment #3 from Eric Fiselier --- Alright. Fixed in v4.0 by r291059 and r291046. The two relevant changes are: 1) libc++ now implements std::pointer_safety as an enum type in ABI v2. 2) The fallback struct type now provides a default constructor. -- 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 31540] New: libc++ puts libc++abi headers in wrong place in build area
https://llvm.org/bugs/show_bug.cgi?id=31540 Bug ID: 31540 Summary: libc++ puts libc++abi headers in wrong place in build area Product: libc++ Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: richard-l...@metafoo.co.uk CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified libc++'s cmake/Modules/HandleLibCXXABI.cmake copies the libc++abi into the build area. However, instead of copying it to $BUILD/include/c++/v1, it copies it to $BUILD/include. That seems broken -- a clang binary in $BUILD/bin doesn't look there, so running the compiler from the build area results in our being unable to find , which means that header is not available in stage2 of a simple bootstrap (with no explicit install step). The cxxabi.h headers should be put next to the libc++ headers in the build area, just like they are in the install area. However, this appears to cause the libc++ build itself to fail, because it /does/ have an include path of $BUILD/include and /does not/ have an include path of $BUILD/include/c++/v1 (which seems reasonable -- we don't want it including headers from some stale build of the same library). So either we should put these headers in both places in the build area, or when building libc++ it should pick up cxxabi.h directly from $SRC/projects/libcxxabi/include. -- 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 31540] libc++ puts libc++abi headers in wrong place in build area
https://llvm.org/bugs/show_bug.cgi?id=31540 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Smith --- Fixed in r291065. -- 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 31043] Assertion `(Cand->FailureKind == ovl_fail_too_many_arguments) || (Cand->FailureKind == ovl_fail_bad_deduction && Cand->DeductionFailure.Result == Sema::TDK_TooManyArguments)' f
https://llvm.org/bugs/show_bug.cgi?id=31043 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |FIXED --- Comment #6 from Richard Smith --- Fixed in r291064. -- 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 31541] New: clang 3.9.1 targeting powerpc rejects "cmp 0, %r1, %r3" in a .S file for "too few operands for instruction" (FreeBSD buildkernel context)
https://llvm.org/bugs/show_bug.cgi?id=31541 Bug ID: 31541 Summary: clang 3.9.1 targeting powerpc rejects "cmp 0, %r1, %r3" in a .S file for "too few operands for instruction" (FreeBSD buildkernel context) Product: libraries Version: 3.9 Hardware: Macintosh OS: FreeBSD Status: NEW Severity: normal Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: mar...@dsl-only.net CC: llvm-bugs@lists.llvm.org Classification: Unclassified [lib/Target/PowerPC is a guess on my part for where the issue would be addressed.] In attempting to buildkernel via FreeBSD's clang 3.9.1 variant the attempt stops with the following for code that has been in place in FreeBSD for a very long time (historically gcc 4.2.1 toolchain use): --- locore.o --- /usr/src/sys/powerpc/aim/trap_subr32.S:409:2: error: too few operands for instruction cmp 0, %r1, %r3 ^ *** [locore.o] Error code 1 make[2]: stopped in /usr/obj/powerpcvtsc_clang_kernel/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG .ERROR_TARGET='locore.o' .ERROR_META_FILE='/usr/obj/powerpcvtsc_clang_kernel/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG/locore.o.meta' # Meta data file /usr/obj/powerpcvtsc_clang_kernel/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG/locore.o.meta CMD cc -target powerpc-unknown-freebsd12.0 --sysroot=/usr/obj/powerpcvtsc_clang_kernel/powerpc.powerpc/usr/src/tmp -B/usr/obj/powerpcvtsc_clang_kernel/powerpc.powerpc/usr/src/tmp/usr/bin -c -x assembler-with-cpp -DLOCORE -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -msoft-float -fPIC -fno-omit-frame-pointer -mno-altivec -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -msoft-float -std=iso9899:1999 -Werror /usr/src/sys/powerpc/aim/locore.S CWD /usr/obj/powerpcvtsc_clang_kernel/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODBG TARGET locore.o -- command output -- /usr/src/sys/powerpc/aim/trap_subr32.S:409:2: error: too few operands for instruction cmp 0, %r1, %r3 ^ *** Error code 1 clang 3.9.1 is not allowing the optional crD to be optional in the instruction format: cmp [crD,]L,rA,rB The following: # svnlite diff /usr/src/sys/powerpc/aim/trap_subr32.S Index: /usr/src/sys/powerpc/aim/trap_subr32.S === --- /usr/src/sys/powerpc/aim/trap_subr32.S (revision 311147) +++ /usr/src/sys/powerpc/aim/trap_subr32.S (working copy) @@ -406,7 +406,7 @@ mtctr %r1 /* load counter */ im1: lwzu %r1, 8(%r2)/* get next pte */ - cmp 0, %r1, %r3 /* see if found pte */ + cmp 0, 0, %r1, %r3 /* see if found pte */ bdnzf 2, im1/* dec count br if cmp ne and if * count not zero */ bne instr_sec_hash /* if not found set up second hash allows buildkernel to progress past this. (The above filled in the default value explicltly.) [So FreeBSD can avoid the specific issue. This issue is unlikely to be considered an issue that contributes to why the system compiler for powerpc can not be clang yet.] Materials around such as: http://www.tentech.ca/downloads/other/PPC_Quick_Ref_Card-Rev1_Oct12_2010.pdf show the optional status for crD. My guess is that the clang toolchain is incomplete in its coverage for the intended notation. (I've no clue if there are other such optional-syntax issues in general. If there are then FreeBSD does not seem to have examples of hitting any of the other examples via its clang 3.9.1 variant.) -- 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 31542] New: AddressSanitizer-Unit::AddressSanitizer.ThreadedOneSizeMallocStressTest is flaky
https://llvm.org/bugs/show_bug.cgi?id=31542 Bug ID: 31542 Summary: AddressSanitizer-Unit::AddressSanitizer.ThreadedOneSiz eMallocStressTest is flaky Product: compiler-rt Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: richard-l...@metafoo.co.uk CC: k...@google.com, llvm-bugs@lists.llvm.org, samso...@google.com Classification: Unclassified See: http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/2078 Note that no relevant changes were made here, and the prior and next runs both passed. -- 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 31402] UBSan complains about map::__find_equal_key (invalid upcast)
https://llvm.org/bugs/show_bug.cgi?id=31402 Eric Fiselier changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Eric Fiselier --- Fixed in r291087 (4.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 30705] std::array doesn't implement C++17 refinements for constexpr
https://llvm.org/bugs/show_bug.cgi?id=30705 Marshall Clow (home) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Marshall Clow (home) --- Implemented in r290976 -- 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
