[llvm-bugs] [Bug 24798] clang crashes on invalid code on x86_64-linux-gnu
https://llvm.org/bugs/show_bug.cgi?id=24798 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED CC||david.majne...@gmail.com, ||dgre...@apple.com Component|-New Bugs |C++ Resolution|--- |FIXED --- Comment #1 from David Majnemer --- Fixed in r247535. -- 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 24802] wrong code at -O1 and above on x86_64-linux-gnu
https://llvm.org/bugs/show_bug.cgi?id=24802 James Molloy changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from James Molloy --- This looks like a duplicate of PR24801. Sanjoy's patch in that defect fixes this crash. *** This bug has been marked as a duplicate of bug 24801 *** -- 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 24808] New: functions with weak_odr linkage place in 32-bit code section in arm coff
https://llvm.org/bugs/show_bug.cgi?id=24808
Bug ID: 24808
Summary: functions with weak_odr linkage place in 32-bit code
section in arm coff
Product: libraries
Version: trunk
Hardware: Other
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: pagin...@163.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
given
target datalayout =
"e-m:e-p:32:32-i1:8:32-i8:8:32-i16:16:32-i64:64-v128:64:128-a:0:32-n32-S64"
target triple = "thumbv7--windows-msvc"
; Function Attrs: inlinehint nounwind
define weak_odr arm_aapcs_vfpcc i32 @vsprintf(i8* %_Buffer, i8* %_Format, i8*
%_ArgList) #0 {
%1 = alloca i8*, align 4
%2 = alloca i8*, align 4
%3 = alloca i8*, align 4
store i8* %_ArgList, i8** %1, align 4
store i8* %_Format, i8** %2, align 4
store i8* %_Buffer, i8** %3, align 4
%4 = load i8** %1, align 4
%5 = load i8** %2, align 4
%6 = load i8** %3, align 4
%7 = call arm_aapcs_vfpcc i32 @_vsnprintf_l(i8* %6, i32 -1, i8* %5,
%struct.__crt_locale_pointers* null, i8* %4)
ret i32 %7
}
Section selection for "vsprintf" is wrong. In generated coff object file,
vsprintf is placed in 32-bit code section. When linking with other object
files, instructions calling this function will be fixed with a "blx". This will
cause a run time crash since it will trigger a mode switch from thumb-2 into
arm, while instruction set for windows on arm is strictly limited to thumb-2.
A possible fix:
const MCSection *TargetLoweringObjectFileCOFF::
SelectSectionForGlobal(const GlobalValue *GV, SectionKind Kind,
Mangler &Mang, const TargetMachine &TM) const {
// If we have -ffunction-sections then we should emit the global value to a
// uniqued section specifically for it.
bool EmitUniquedSection;
if (Kind.isText())
EmitUniquedSection = TM.getFunctionSections();
else
EmitUniquedSection = TM.getDataSections();
// If this global is linkonce/weak and the target handles this by emitting it
// into a 'uniqued' section name, create and return the section now.
// Section names depend on the name of the symbol which is not feasible if
the
// symbol has private linkage.
if ((GV->isWeakForLinker() || EmitUniquedSection || GV->hasComdat()) &&
!Kind.isCommon()) {
const char *Name = getCOFFSectionNameForUniqueGlobal(Kind);
unsigned Characteristics = getCOFFSectionFlags(Kind);
Characteristics |= COFF::IMAGE_SCN_LNK_COMDAT;
int Selection = getSelectionForCOFF(GV);
if (!Selection)
Selection = COFF::IMAGE_COMDAT_SELECT_NODUPLICATES;
const GlobalValue *ComdatGV;
if (GV->hasComdat())
ComdatGV = getComdatGVForCOFF(GV);
else
ComdatGV = GV;
if (!ComdatGV->hasPrivateLinkage()) {
MCSymbol *Sym = TM.getSymbol(ComdatGV, Mang);
StringRef COMDATSymName = Sym->getName();
+ if (Kind.isText()) {
+const Triple &T = getContext().getObjectFileInfo()->getTargetTriple();
+if (T.getArch() == Triple::arm || T.getArch() == Triple::thumb)
+ Characteristics |= COFF::IMAGE_SCN_MEM_16BIT;
+ }
return getContext().getCOFFSection(Name, Characteristics, Kind,
COMDATSymName, Selection);
}
}
--
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 24800] wrong code at -Os and above on x86_64-linux-gnu
https://llvm.org/bugs/show_bug.cgi?id=24800 James Molloy changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from James Molloy --- *** This bug has been marked as a duplicate of bug 24801 *** -- 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 24809] New: MS-COFF: incorrect thumb Code16Directive and comment string
https://llvm.org/bugs/show_bug.cgi?id=24809
Bug ID: 24809
Summary: MS-COFF: incorrect thumb Code16Directive and comment
string
Product: libraries
Version: trunk
Hardware: Other
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Backend: ARM
Assignee: unassignedb...@nondot.org
Reporter: pagin...@163.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Assembly file generated by llc compiler uses incorrect ".code16" directive.
At the same time, comment string starts with "#".
A possible fix:
ARMCOFFMCAsmInfoMicrosoft::ARMCOFFMCAsmInfoMicrosoft() {
AlignmentIsInBytes = false;
+ CommentString = "@";
+ Code16Directive = ".thumb";
PrivateGlobalPrefix = "$M";
}
--
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 24810] New: Incorrect lookup of subobject members
https://llvm.org/bugs/show_bug.cgi?id=24810 Bug ID: 24810 Summary: Incorrect lookup of subobject members Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++14 Assignee: unassignedclangb...@nondot.org Reporter: r...@gmx.net CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 14876 --> https://llvm.org/bugs/attachment.cgi?id=14876&action=edit Testcase. The static_assertion fires, although there is no ambiguity; [class.member.lookup]/4 explicitly states that > the declaration set contains every declaration of f declared in C **that > satisfies the requirements of the language construct in which the lookup > occurs**. -- 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 24811] New: Include search paths not honored for asm(".include foo.s");
https://llvm.org/bugs/show_bug.cgi?id=24811
Bug ID: 24811
Summary: Include search paths not honored for asm(".include
foo.s");
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: jykni...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
If you write a C file "foo.c" that says:
asm(".include \"test-asm.s\"");
And have an asm file named "/whatever/test-asm.s".
And if you run:
clang -I /whatever -c foo.c
Then, what should happen:
a) With integrated assembler, the search paths should be used by the integrated
assembler to find the file.
b) Without an integrated assembler, the -I path arguments should be passed to
the /usr/bin/as program, so it can handle the .include with the right paths.
(note: gcc does indeed do this)
What happens now:
It fails to find the test-asm.s file, because search paths aren't passed into
either assembler. It can the file (and does include it properly, even!), if the
path is specified as relative to your current working directory.
Of course, writing C code like this is INCREDIBLY EVIL and nobody should ever
do it. So I'm not planning to fix this. But, having discovered it, I thought
I'd at least record a bug.
(Of course if you use this feature, -M can't work, because that stops after
preprocessing, and this .include is not processed in the preprocessor. -MD
could be made to work, IF you're using the integrated assembler, but that might
be a bit of a confusing distinction?)
--
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 24812] New: Expression evaluation crashes when definition of class not available for a class
https://llvm.org/bugs/show_bug.cgi?id=24812 Bug ID: 24812 Summary: Expression evaluation crashes when definition of class not available for a class Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: tbergham...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 14877 --> https://llvm.org/bugs/attachment.cgi?id=14877&action=edit Source to reproduce the bug Steps to reproduce: * Compile the attached inferior with clang++ (tested with clang-3.5 on Linux x86_64) with the following command line: "clang++ -g ss.cpp" * lldb a.out * (lldb) breakpoint set -n main * (lldb) run * (lldb) next * (lldb) expression f * Observed behavior: LLDB crashes with "llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp:2868: const clang::ASTRecordLayout &clang::ASTContext::getASTRecordLayout(const clang::RecordDecl *) const: Assertion `D && "Cannot get layout of forward declarations!"' failed" * Expected behavior: The content off the variable displayed correctly * Acceptable behavior: LLDB displays an error message without crashing The root cause of the problem is that clang only includes the declaration of std::string in the debug info and expects that the debugger can access to it from a different source. If "-fno-limit-debug-info" is specified to the compiler, then the error disappears. The crash can happen during any part of the debug session (e.g. single stepping, back tracing), but reproducing it in those cases is more difficult. -- 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 24813] New: TestBatchMode is not remote-ready
https://llvm.org/bugs/show_bug.cgi?id=24813 Bug ID: 24813 Summary: TestBatchMode is not remote-ready Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: lab...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified The test fails for remote platforms as it does not know how to run processes remotely. -- 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 24814] New: Cases in test/CodeGen/ARM/fp16-promote.ll should be tested with -vfp2
https://llvm.org/bugs/show_bug.cgi?id=24814 Bug ID: 24814 Summary: Cases in test/CodeGen/ARM/fp16-promote.ll should be tested with -vfp2 Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: pir...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Currently, - some functions in this test don't compile - all the functions need a new set of CHECKs for when both f32 and f16 are illegal. -- 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 24815] New: clang and GCC disagree on attribute usage for explicitly instantiated templates
https://llvm.org/bugs/show_bug.cgi?id=24815
Bug ID: 24815
Summary: clang and GCC disagree on attribute usage for
explicitly instantiated templates
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: dch...@google.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Sorry, I don't really know the build magic so I don't have any good examples.
In Chrome, we have some templated classes with explicit instantiations that
look something like this:
#define EXPORT __attribute((visibility("default")))
template
class EXPORT Property {
// ...
};
extern template class Property;
extern template class Property;
// etc
When building with clang, uses of the explicitly instantiated templates outside
the shared library fail to link: the linker complains that there are undefined
references to Property's constructor, destructor, etc.
To fix this for clang, I tried exporting the explicit template instantiations:
extern template class EXPORT Property;
extern template class EXPORT Property;
But now this doesn't compile in GCC:
../../dbus/property.h:437:42: error: type attributes ignored after type is
already defined [-Werror=attributes]
extern template class CHROME_DBUS_EXPORT Property;
^
../../dbus/property.h:447:42: error: type attributes ignored after type is
already defined [-Werror=attributes]
extern template class CHROME_DBUS_EXPORT Property;
It turns out GCC ignores attributes on explicit template instantiations
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17470): their fix for this was to
change it so the original template definition controls visibility, and any
attributes on explicit instantiations are ignored (and trigger a
warning/error).
--
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 24816] New: clang: error: clang frontend command failed due to signal
https://llvm.org/bugs/show_bug.cgi?id=24816 Bug ID: 24816 Summary: clang: error: clang frontend command failed due to signal Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: a...@chromium.org CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified -- 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 24793] SEH __try / __except in always_inline functions generates bad IR
https://llvm.org/bugs/show_bug.cgi?id=24793 Evgeniy Stepanov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Evgeniy Stepanov --- I've reverted the alwaysinline commit in r247620. -- 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 24595] clang-cl fails to compile vswriter.h header from Windows SDK 8.1 in 32 bit mode
https://llvm.org/bugs/show_bug.cgi?id=24595 Andrey Bokhanko changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andrey Bokhanko --- Fixed in r247619. Andrey -- 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 24817] New: inefficient floating point register ld/st instructions are generated when -mcpu=power8 is specified
https://llvm.org/bugs/show_bug.cgi?id=24817
Bug ID: 24817
Summary: inefficient floating point register ld/st instructions
are generated when -mcpu=power8 is specified
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: PowerPC
Assignee: unassignedb...@nondot.org
Reporter: car...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The simple test case is:
int foo(float *p)
{
float f1 = p[1];
float f2 = p[2];
return f1 > f2;
}
Compiler command line and output
clang -S t8.c --target=powerpc -m64 -mcpu=power8 -O2
li 4, 4 // A
li 5, 8 // B
lxsspx 0, 3, 4 // C
lxsspx 1, 3, 5 // D
li 3, 0
li 4, 1
fcmpu 0, 0, 1
isel 3, 4, 3, 1
blr
If I change -mcpu=power8 to -mcpu=power7, I got
lfs 0, 4(3)// E
lfs 1, 8(3)// F
li 3, 0
li 4, 1
fcmpu 0, 0, 1
isel 3, 4, 3, 1
blr
Instructions AC are replaced by E
Instructions BD are replaced by F
--
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 24807] clang++ -O1 evaluates wrong branch in C++ ternary operator ?:
https://llvm.org/bugs/show_bug.cgi?id=24807 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |INVALID --- Comment #6 from Richard Smith --- >From the C standard: "If part of a program tests floating-point status flags, sets floating-point control modes, or runs under non-default mode settings, but was translated with the state for the FENV_ACCESS pragma "off", the behavior is undefined." Since the FENV_ACCESS pragma is not part of C++, and Clang's only supported state for it is "off", and in any case you didn't use it, your call to feenableexcept invokes undefined behavior. Resolving invalid as your code invokes UB, but this is morally a duplicate of bug 8100 (it would be a duplicate if you had used the necessary pragma). -- 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 24818] New: hoisting expensive ops like FP division is bad for perf
https://llvm.org/bugs/show_bug.cgi?id=24818
Bug ID: 24818
Summary: hoisting expensive ops like FP division is bad for
perf
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Test case based on bug 24807:
double foo(double a, double b) {
return (a > 0.0) ? b/a : 0.0;
}
If 'a' is always less than zero, then we should never clog up an FPU with a
potentially very expensive, non-pipelined division instruction. But we're
hoisting that op with 'opt' built from r247615:
target triple = "x86_64-apple-macosx10.10.0"
define double @foo(double %a, double %b) #0 {
entry:
%cmp = fcmp ogt double %a, 0.00e+00
%div = fdiv double %b, %a
%cond = select i1 %cmp, double %div, double 0.00e+00
ret double %cond
}
This is a relatively recent change; it doesn't happen with the clang shipped
with Xcode based on 3.6.0:
define double @foo(double %a, double %b) #0 {
%1 = fcmp ogt double %a, 0.00e+00
br i1 %1, label %2, label %4
; :2 ; preds = %0
%3 = fdiv double %b, %a
br label %4
; :4 ; preds = %0, %2
%5 = phi double [ %3, %2 ], [ 0.00e+00, %0 ]
ret double %5
}
--
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
