[llvm-bugs] [Bug 25787] SLPVectorizer finds incorrect reduction value
https://llvm.org/bugs/show_bug.cgi?id=25787 Mattias Eriksson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Mattias Eriksson --- I have verified that the fix does indeed solve my original problem. Thank you! -- 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 25861] New: clang failes to compile std::experimental::filesystem::path
https://llvm.org/bugs/show_bug.cgi?id=25861
Bug ID: 25861
Summary: clang failes to compile
std::experimental::filesystem::path
Product: clang
Version: 3.7
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: d.m.b...@web.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Clang fails to compile the simple test program, while gcc (5.3) compiles it
without errors.
The Program:
#include
int main() {
std::experimental::filesystem::path p( "/home" );
return 0;
}
I don't know if this really is a clang bug or rather a libstdc++ bug.
--
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 25862] New: AlignConsecutiveAssignments fail on operator=
https://llvm.org/bugs/show_bug.cgi?id=25862
Bug ID: 25862
Summary: AlignConsecutiveAssignments fail on operator=
Product: clang
Version: 3.7
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: jfreder...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Classification: Unclassified
// wrong formatted:
template
VBiIterator& operator=(const VBiIterator& other) {
mIterator = other.Iterator();
^^^ that's wrong!
return *this;
}
// well formatted:
template
VBiIterator& operator=(const VBiIterator& other) {
mIterator = other.Iterator();
return *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 25863] New: powerpc target cross compiling fails when /usr/lib32 path exists
https://llvm.org/bugs/show_bug.cgi?id=25863
Bug ID: 25863
Summary: powerpc target cross compiling fails when /usr/lib32
path exists
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Driver
Assignee: unassignedclangb...@nondot.org
Reporter: lordar...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Hello everbody,
I have a very simple C hello world that does not cross compile into ppc32.
#include
int main(){
printf("Hello\n");
return 0;
}
clang -target powerpc-linux ./main.c -L /usr/powerpc-linux-gnu/lib/ -v
clang version 3.8.0 (trunk 255649)
Target: powerpc--linux
Thread model: posix
InstalledDir: MY_LLVM_PATH/build/bin
Found candidate GCC installation: /usr/lib/gcc-cross/powerpc-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc-cross/powerpc-linux-gnu/4.9.2
Selected GCC installation: /usr/lib/gcc-cross/powerpc-linux-gnu/4.9
Candidate multilib: .;@m32
Candidate multilib: 64;@m64
Selected multilib: .;@m32
"MY_LLVM_PATH/build/bin/clang-3.8" -cc1 -triple powerpc--linux -emit-obj
-mrelax-all -disable-free -main-file-name main.c -mrelocation-model static
-mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -fuse-init-array -target-cpu ppc -mfloat-abi hard -v
-dwarf-column-info -resource-dir MY_LLVM_PATH/build/bin/../lib/clang/3.8.0
-internal-isystem /usr/local/include -internal-isystem
MY_LLVM_PATH/build/bin/../lib/clang/3.8.0/include -internal-externc-isystem
/include -internal-externc-isystem /usr/include -fdebug-compilation-dir
/tmp/hello -ferror-limit 19 -fmessage-length 140 -fno-signed-char
-fobjc-runtime=gcc -fdiagnostics-show-option -o /tmp/main-261e40.o -x c
./main.c
clang -cc1 version 3.8.0 based upon LLVM 3.8.0svn default target
x86_64-unknown-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
MY_LLVM_PATH/build/bin/../lib/clang/3.8.0/include
/usr/include
End of search list.
"/usr/lib/gcc-cross/powerpc-linux-gnu/4.9/../../../../powerpc-linux-gnu/bin/ld"
-z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf32ppclinux
-dynamic-linker /lib/ld.so.1 -o a.out
/usr/lib/gcc-cross/powerpc-linux-gnu/4.9/../../../../lib32/crt1.o
/usr/lib/gcc-cross/powerpc-linux-gnu/4.9/../../../../lib32/crti.o
/usr/lib/gcc-cross/powerpc-linux-gnu/4.9/crtbegin.o
-L/usr/powerpc-linux-gnu/lib/ -L/usr/lib/gcc-cross/powerpc-linux-gnu/4.9
-L/usr/lib/gcc-cross/powerpc-linux-gnu/4.9/../../../../lib32 -L/lib/../lib32
-L/usr/lib/../lib32
-L/usr/lib/gcc-cross/powerpc-linux-gnu/4.9/../../../../powerpc-linux-gnu/lib
-L/usr/lib/gcc-cross/powerpc-linux-gnu/4.9/../../..
-LMY_LLVM_PATH/build/bin/../lib -L/lib -L/usr/lib /tmp/main-3a1191.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc-cross/powerpc-linux-gnu/4.9/crtend.o
/usr/lib/gcc-cross/powerpc-linux-gnu/4.9/../../../../lib32/crtn.o
/usr/lib/gcc-cross/powerpc-linux-gnu/4.9/../../../../powerpc-linux-gnu/bin/ld:
/usr/lib/gcc-cross/powerpc-linux-gnu/4.9/../../../../lib32/crt1.o: Réadressages
en format ELF générique (EM: 3)
/usr/lib/gcc-cross/powerpc-linux-gnu/4.9/../../../../lib32/crt1.o: error adding
symbols: Fichier dans un mauvais format
clang-3.8: error: linker command failed with exit code 1 (use -v to see
invocation)
The error is due to crt1.o, crri.o, crtn.o objects, in fact
'powerpc-linux-gnu-ld' tries to link the main.o (ppc format) with
/usr/lib32/crt1.o (and crti.o crtn.o) (x86 32bit format).
I notice if I remove the /usr/lib32 repertory the compilation works because the
crt1.o used is the correct one (in /usr/powerpc-linux-gnu/lib/)
Here my clang version :
clang version 3.8.0 (trunk 255649)
Target: x86_64-unknown-linux-gnu
Thread model: posix
And my llvm version :
LLVM (http://llvm.org/):
LLVM version 3.8.0svn
DEBUG build with assertions.
Built Dec 15 2015 (17:49:25).
Default target: x86_64-unknown-linux-gnu
Host CPU: sandybridge
I tried to seach the file concerned in the source code, the only interesting
file that matches "crl1.o" is "/lib/Driver/ToolChains.cpp"
https://github.com/llvm-mirror/clang/blob/815cde37f487611c4a710a04c849983b37ca4974/lib/Driver/ToolChains.cpp#L3070-L3075
The detection of /usr/lib32/crt1.o is hard-coded when target is x86 or ppc but
I maybe wrong because the code seems to concern only FreeBSD and not Linux
What do you think about this bug ?
Best Regards
--
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 25864] New: Divergence Analysis: Constant load in branch considered divergent
https://llvm.org/bugs/show_bug.cgi?id=25864 Bug ID: 25864 Summary: Divergence Analysis: Constant load in branch considered divergent Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Global Analyses Assignee: unassignedb...@nondot.org Reporter: tstel...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15479 --> https://llvm.org/bugs/attachment.cgi?id=15479&action=edit Test case I've run into this issue with the DivergenceAnalysis pass, and I'm not sure if it is a bug or if it is expected behavior. Attached is the test case, which can be reproduced by applying this patch: http://reviews.llvm.org/D15608 opt -analyze -divergence -mtriple=amdgcn-- divergent-test.ll The output I get from the divergence analysis pass is this: DIVERGENT: float %arg1 DIVERGENT: %tmp2 = fcmp ueq float %arg1, 0.00e+00 DIVERGENT: br i1 %tmp2, label %bb7, label %bb3 DIVERGENT: %tmp4 = phi i1 [ false, %bb7 ], [ true, %bb ] DIVERGENT: br i1 %tmp4, label %bb5, label %bb9 DIVERGENT: %tmp6 = call float @llvm.SI.load.const(<16 x i8> %tmp, i32 16) ^ This last line is what I think it incorrect. This is a constant load intrinsic, which takes a non-divergent argument, so it shouldn't be divergent. I have verified that AMDGPU's implementation of TargetTransformInfo::isSourceOfDivergence() returns false for this intrinsic. Based on brief debugging of the issue I think the problem may be that the DivergenceAnalysis pass incorrectly things this test case contains a loop, but I'm not really sure. -- 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 25062] Switch Xcode build away from build-swig-wrapper-classes.sh and use pure-Python approach
https://llvm.org/bugs/show_bug.cgi?id=25062 Todd Fiala changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Todd Fiala --- I switched over the bindings preparation code a few weeks back on the OS X side. We all now use the same prepare_bindings.py script. I'll treat the finalization steps as a separate script in the future. -- 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 25653] Cannot inspect const static variable
https://llvm.org/bugs/show_bug.cgi?id=25653 Ewan Crawford changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Ewan Crawford --- Fixed in revision r255887 -- 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 25865] New: Unnecessary relocation with __aeabi_unwind_cpp_pr0
https://llvm.org/bugs/show_bug.cgi?id=25865 Bug ID: 25865 Summary: Unnecessary relocation with __aeabi_unwind_cpp_pr0 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: rafael.espind...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Given .fnstart .fnend .fnstart .fnend gas produces one relocation to __aeabi_unwind_cpp_pr0, MC produces two. -- 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 25866] New: Gentoo Linux build breaks in some scenarios when both Python 2 and Python 3 are present
https://llvm.org/bugs/show_bug.cgi?id=25866 Bug ID: 25866 Summary: Gentoo Linux build breaks in some scenarios when both Python 2 and Python 3 are present Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified This may be the same thing as the issue on Arch Linux; however, one of the threads on this indicated some tweaking of build environment variables allowed this to work. I suspect the fix for handling python 2 and python 3 simultaneously with preferential treatment for python 2 would handle this. Filing in case this is a different issue. -- 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 25867] New: Inconsistency in dereferencing of void pointers
https://llvm.org/bugs/show_bug.cgi?id=25867
Bug ID: 25867
Summary: Inconsistency in dereferencing of void pointers
Product: clang
Version: 3.7
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: baranniko...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Consider the following example:
void f()
{
void *p1;
volatile void *p2;
*p1;
*p2;
p1[0];
p2[0];
}
All of operations on p1 and p2 are dereferencing operations ((C99 6.5.2.1p2 The
definition of the subscript operator [] is that E1[E2] is identical to
(*((E1)+(E2))).), but they are treated differently when generating llvm IR:
// %p1 = alloca i8*, align 4
// %p2 = alloca i8*, align 4
*p1;
// %0 = load i8*, i8** %p1, align 4
*p2;
// %1 = load i8*, i8** %p2, align 4
p1[0];
// %2 = load i8*, i8** %p1, align 4
// %arrayidx = getelementptr inbounds i8, i8* %2, i32 0
// %3 = load i8, i8* %arrayidx
p2[0];
// %4 = load i8*, i8** %p2, align 4
// %arrayidx1 = getelementptr inbounds i8, i8* %4, i32 0
// ret void
Operation p1[0] does load, others do not.
Also, '*p2' and 'p2[0]' are lvalues, while '*p1' and 'p1[0]' are not:
|-UnaryOperator 0xf688c88 'void' prefix '*'
| `-ImplicitCastExpr 0xf688c78 'void *'
| `-DeclRefExpr 0xf688c60 'void *' lvalue Var 0xf688ba0 'p1'
'void *'
|-UnaryOperator 0xf688cc8 'volatile void' lvalue prefix
'*'
| `-ImplicitCastExpr 0xf688cb8 'volatile void *'
| `-DeclRefExpr 0xf688c9c 'volatile void *' lvalue Var 0xf688c18
'p2' 'volatile void *'
|-ArraySubscriptExpr 0xf688d20 'void'
| |-ImplicitCastExpr 0xf688d10 'void *'
| | `-DeclRefExpr 0xf688cdc 'void *' lvalue Var 0xf688ba0 'p1'
'void *'
| `-IntegerLiteral 0xf688cf8 'int' 0
`-ArraySubscriptExpr 0xf688d78 'volatile void' lvalue
|-ImplicitCastExpr 0xf688d68 'volatile void *'
| `-DeclRefExpr 0xf688d34 'volatile void *' lvalue Var 0xf688c18
'p2' 'volatile void *'
`-IntegerLiteral 0xf688d50 'int' 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 25862] AlignConsecutiveAssignments fail on operator=
https://llvm.org/bugs/show_bug.cgi?id=25862 Jens Frederich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25868] New: test/tools/gold/X86/disable-verify.ll should pass -m elf_x86_64 to gold invocations
https://llvm.org/bugs/show_bug.cgi?id=25868 Bug ID: 25868 Summary: test/tools/gold/X86/disable-verify.ll should pass -m elf_x86_64 to gold invocations Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: hjl.to...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Since X86/disable-verify.ll has target triple = "x86_64-unknown-linux-gnu" we need to pass -m elf_x86_64 to gold invocations. Otherwise it would fail if the default was not elf_x86_64. -- 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 25850] non-virtual destructor not detected with friend
https://llvm.org/bugs/show_bug.cgi?id=25850 Andy Gibbs changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Andy Gibbs --- Ah, yes -Wdelete-non-virtual-dtor. I'm afraid I didn't think of that! Too many warning flags to remember them all :o) I'll mark this as closed out. 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 25869] New: OS X lldb crashed during test: ProcessGDBRemote/Broadcaster cleanup segfault
https://llvm.org/bugs/show_bug.cgi?id=25869 Bug ID: 25869 Summary: OS X lldb crashed during test: ProcessGDBRemote/Broadcaster cleanup segfault Product: lldb Version: unspecified Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15480 --> https://llvm.org/bugs/attachment.cgi?id=15480&action=edit crashlog This is on my home iMac, running against lldb r255893. Crashlog attached. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25870] New: rfc: column limit for comments
https://llvm.org/bugs/show_bug.cgi?id=25870 Bug ID: 25870 Summary: rfc: column limit for comments Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: jfreder...@gmail.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Classification: Unclassified ColumnLimit: 120 // means break my C++ code on 120 characters ColumnLimitComments: 80 // means break my C++ comments on 80 characters -- 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 25871] New: Enum constants defined in Support/MachO.h conflict with system header
https://llvm.org/bugs/show_bug.cgi?id=25871 Bug ID: 25871 Summary: Enum constants defined in Support/MachO.h conflict with system header Product: libraries Version: 3.7 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: Support Libraries Assignee: unassignedb...@nondot.org Reporter: d...@danburkert.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified The OS X mach-o/loader.h system header defines a set of constants as macros, and the LLVM Support/MachO.h header redefines those constants as enum variants (MH_MAGIC is one example). The result is that in applications that import both headers, the enum identifier in Support/MachO.h is replaced with the value, and compilation fails. OS X system header: https://opensource.apple.com/source/xnu/xnu-1456.1.26/EXTERNAL_HEADERS/mach-o/loader.h LLVM header: https://github.com/llvm-mirror/llvm/blob/856a0380260e2735f51b059822674bd47961c050/include/llvm/Support/MachO.h#L24-L80 -- 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 25872] New: OS X: TestGlobalVariables dwarf is not finding the static const int g_file_static_int
https://llvm.org/bugs/show_bug.cgi?id=25872 Bug ID: 25872 Summary: OS X: TestGlobalVariables dwarf is not finding the static const int g_file_static_int Product: lldb Version: unspecified Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified This looks like it started happening very recently: runCmd: frame variable --show-types --scope --show-globals --no-args output: STATIC: (const char *) g_func_static_cstr = 0x000103c65f69 "g_func_static_cstr" STATIC: (const char *) g_file_static_cstr = 0x000103c65f83 "g_file_static_cstr" STATIC: (const char *) g_func_static_cstr = 0x000103c65f69 "g_func_static_cstr" GLOBAL: (const char *) g_file_global_cstr = 0x000103c65f56 "g_file_global_cstr" GLOBAL: (int) g_common_1 = 21 GLOBAL: (int) g_file_global_int = 42 Expecting sub string: GLOBAL: (int) g_file_global_int = 42 Matched Expecting sub string: STATIC: (const int) g_file_static_int = 2 Not matched FAIL >>: success Traceback (most recent call last): File "/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2263, in dwarf_test_method return attrvalue(self) File "/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 608, in wrapper func(*args, **kwargs) File "/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lang/c/global_variables/TestGlobalVariables.py", line 60, in test 'GLOBAL: (int) g_common_1 = 21']) File "/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2715, in expect msg if msg else EXP_MSG(str, exe)) AssertionError: False is not True : Variable(s) displayed correctly Config=x86_64-clang Session info generated @ Thu Dec 17 10:46:37 2015 To rerun this test, issue the following command from the 'test' directory: ./dotest.py -A x86_64 -C clang -v -t -f GlobalVariablesTestCase.test_dwarf OS X 10.11.2 (15C50) Xcode 7.2 (7C68) -- 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 25857] Clang hangs in template instantiation after diagnosing C++11 narrowing in NTTP.
https://llvm.org/bugs/show_bug.cgi?id=25857 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED CC||r...@google.com Resolution|--- |DUPLICATE --- Comment #1 from Reid Kleckner --- Looks like an accidental dupe from double form submission. *** This bug has been marked as a duplicate of bug 25856 *** -- 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 25859] MSVC: Segfault with cleanupret to catchswitch
https://llvm.org/bugs/show_bug.cgi?id=25859 Alex Crichton changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Alex Crichton --- Ok cool, sounds like it's a fault on our end then. Thanks for the info! -- 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 25873] New: Assignment of structure being optimized out
https://llvm.org/bugs/show_bug.cgi?id=25873
Bug ID: 25873
Summary: Assignment of structure being optimized out
Product: clang
Version: trunk
Hardware: All
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: sunil_srivast...@playstation.sony.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Following example shows a wrong optimization with current trunk (r255918)
#include
struct point {
float x, y;
public:
point() { x = 0.0f; y = 0.0f; }
};
struct p2 {
pointa, b;
public:
p2(): a(), b() {}
};
int main() {
p2 p,q;
q.a.x = 1.0f;
q.a.y = 2.0f;
q.b = q.a; // set q.b to same as q.a
p = q; // hence p.a must be same as p.b
printf( "p.a=( %f, %f ), p.b=( %f, %f )\n", p.a.x, p.a.y, p.b.x, p.b.y );
}
with -O, it gives
p.a=( 1.00, 2.00 ), p.b=( 0.00, 0.00 )
I have tried it on linux/pc, but I think other platforms have same issue.
It is a regression. 3.5 did not have this bug. I will pin down further as to
when it happened.
The problem does not show if x and y are ints.
--
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 25758] [Polly] Fold Polly into the pass pipeline [Metabug]
https://llvm.org/bugs/show_bug.cgi?id=25758 Bug 25758 depends on bug 25759, which changed state. Bug 25759 Summary: [Polly] Timout when compiling timerwolfmc and yacr2 with -polly-position=before-vectorizer https://llvm.org/bugs/show_bug.cgi?id=25759 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25759] [Polly] Timout when compiling timerwolfmc and yacr2 with -polly-position=before-vectorizer
https://llvm.org/bugs/show_bug.cgi?id=25759 Roman Gareev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25868] test/tools/gold/X86/disable-verify.ll should pass -m elf_x86_64 to gold invocations
https://llvm.org/bugs/show_bug.cgi?id=25868 Rafael Ávila de Espíndola changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Rafael Ávila de Espíndola --- Fixed in r255930. -- 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 25874] New: test cxa_thread_atexit_test.pass.cpp fails
https://llvm.org/bugs/show_bug.cgi?id=25874 Bug ID: 25874 Summary: test cxa_thread_atexit_test.pass.cpp fails Product: libc++abi Version: 3.7 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: burk...@rice.edu CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified On RedHat 6.5, cxa_thread_atexit_test.pass.cpp fails. >From Clang Documentation http://blog.llvm.org/2013/04/clang-support-for-c11-and-beyond.html: // Clang now supports C++11s thread_local keyword, including dynamic // initialization and destruction of thread-local objects. Dynamic // destruction requires a C++ runtime library which provides // __cxa_thread_atexit, which is currently only provided by the g++4.8 // C++ runtime library. I had to add "// XFAIL: linux" to get around this issue. This is a build using gpp/clang-3.7 to build clant3.7/clang3.7 Let me know what other information I need to supply to help with this problem. -- 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 25875] New: differing results between clang-cl and MSVC when preprocessing
https://llvm.org/bugs/show_bug.cgi?id=25875
Bug ID: 25875
Summary: differing results between clang-cl and MSVC when
preprocessing
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: froy...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The following test case, reduced from real-world code in Firefox, generates
valid C++ source code when preprocessed with MSVC 2013 (and gcc/clang on Linux)
and produces errors with clang-cl:
/* from configure */
# define JS_CODEGEN_X86 1
/* from mozilla/MacroArgs.h */
#define MOZ_PASTE_PREFIX_AND_ARG_COUNT(aPrefix, ...) \
MOZ_MACROARGS_ARG_COUNT_HELPER((__VA_ARGS__, \
aPrefix##50, aPrefix##49, aPrefix##48, aPrefix##47, aPrefix##46, \
aPrefix##45, aPrefix##44, aPrefix##43, aPrefix##42, aPrefix##41, \
aPrefix##40, aPrefix##39, aPrefix##38, aPrefix##37, aPrefix##36, \
aPrefix##35, aPrefix##34, aPrefix##33, aPrefix##32, aPrefix##31, \
aPrefix##30, aPrefix##29, aPrefix##28, aPrefix##27, aPrefix##26, \
aPrefix##25, aPrefix##24, aPrefix##23, aPrefix##22, aPrefix##21, \
aPrefix##20, aPrefix##19, aPrefix##18, aPrefix##17, aPrefix##16, \
aPrefix##15, aPrefix##14, aPrefix##13, aPrefix##12, aPrefix##11, \
aPrefix##10, aPrefix##9, aPrefix##8, aPrefix##7, aPrefix##6, \
aPrefix##5, aPrefix##4, aPrefix##3, aPrefix##2, aPrefix##1,
aPrefix##0))
#define MOZ_MACROARGS_ARG_COUNT_HELPER(aArgs) \
MOZ_MACROARGS_ARG_COUNT_HELPER2 aArgs
#define MOZ_MACROARGS_ARG_COUNT_HELPER2( \
a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, \
a11, a12, a13, a14, a15, a16, a17, a18, a19, a20, \
a21, a22, a23, a24, a25, a26, a27, a28, a29, a30, \
a31, a32, a33, a34, a35, a36, a37, a38, a39, a40, \
a41, a42, a43, a44, a45, a46, a47, a48, a49, a50, \
a51, ...) a51
/*
* MOZ_ARGS_AFTER_N expands to its arguments excluding the first |N|
* arguments. For example:
*
* MOZ_ARGS_AFTER_2(a, b, c, d) expands to: c, d
*/
#define MOZ_ARGS_AFTER_1(a1, ...) __VA_ARGS__
#define MOZ_ARGS_AFTER_2(a1, a2, ...) __VA_ARGS__
/*
* MOZ_ARG_N expands to its |N|th argument.
*/
#define MOZ_ARG_1(a1, ...) a1
#define MOZ_ARG_2(a1, a2, ...) a2
/* from mozilla/MacroForEach.h */
#define MOZ_FOR_EACH_EXPAND_HELPER(...) __VA_ARGS__
#define MOZ_FOR_EACH_GLUE(a, b) a b
#define MOZ_FOR_EACH(aMacro, aFixedArgs, aArgs) \
MOZ_FOR_EACH_GLUE( \
MOZ_PASTE_PREFIX_AND_ARG_COUNT(MOZ_FOR_EACH_, \
MOZ_FOR_EACH_EXPAND_HELPER aArgs), \
(aMacro, aFixedArgs, aArgs))
#define MOZ_FOR_EACH_HELPER_GLUE(a, b) a b
#define MOZ_FOR_EACH_HELPER(aMacro, aFixedArgs, aArgs) \
MOZ_FOR_EACH_HELPER_GLUE( \
aMacro, \
(MOZ_FOR_EACH_EXPAND_HELPER aFixedArgs MOZ_ARG_1 aArgs))
#define MOZ_FOR_EACH_1(m, fa, a) \
MOZ_FOR_EACH_HELPER(m, fa, a)
#define MOZ_FOR_EACH_2(m, fa, a) \
MOZ_FOR_EACH_HELPER(m, fa, a) MOZ_FOR_EACH_1(m, fa, (MOZ_ARGS_AFTER_1 a))
/* from MacroAssembler.h */
# define DEFINED_ON_x86
# define DEFINED_ON_x64
# define DEFINED_ON_x86_shared
# define DEFINED_ON_arm
# define DEFINED_ON_arm64
# define DEFINED_ON_mips32
# define DEFINED_ON_mips64
# define DEFINED_ON_mips_shared
# define DEFINED_ON_none
// Specialize for each architecture.
#if defined(JS_CODEGEN_X86)
# undef DEFINED_ON_x86
# define DEFINED_ON_x86 define
# undef DEFINED_ON_x86_shared
# define DEFINED_ON_x86_shared define
#elif defined(JS_CODEGEN_X64)
# undef DEFINED_ON_x64
# define DEFINED_ON_x64 define
# undef DEFINED_ON_x86_shared
# define DEFINED_ON_x86_shared define
#elif defined(JS_CODEGEN_ARM)
# undef DEFINED_ON_arm
# define DEFINED_ON_arm define
#elif defined(JS_CODEGEN_ARM64)
# undef DEFINED_ON_arm64
# define DEFINED_ON_arm64 define
#elif defined(JS_CODEGEN_MIPS32)
# undef DEFINED_ON_mips32
# define DEFINED_ON_mips32 define
# undef DEFINED_ON_mips_shared
# define DEFINED_ON_mips_shared define
#elif defined(JS_CODEGEN_MIPS64)
# undef DEFINED_ON_mips64
# define DEFINED_ON_mips64 define
# undef DEFINED_ON_mips_shared
# define DEFINED_ON_mips_shared define
#elif defined(JS_CODEGEN_NONE)
# undef DEFINED_ON_none
# define DEFINED_ON_none crash
#else
# error "Unknown architecture!"
#endif
# define DEFINED_ON_RESULT_crash { MOZ_CRASH(); }
# define DEFINED_ON_RESULT_define
# define DEFINED_ON_RESULT_= delete
# define DEFINED_ON_DISPATCH_RESULT_2(Macro, Result) \
Macro ## Result
# define DEFINED_ON_DISPATCH_RESULT(...) \
DEFINED_ON_DISPATCH_RESULT_2(DEFINED_ON_RESULT_, __VA_ARGS__)
// We need to let the evaluation of MOZ_FOR_EACH terminate.
# define DEFINED_ON_EXPAND_ARCH_RESULTS_3(ParenResult) \
DEFINED_ON_DISPATCH_RESULT ParenResult
# define DEFINED_ON_EXPAND_ARCH_RESULTS_2(ParenResult) \
DEFINED_ON_EXPAND_ARCH_RESULTS_3 (Pa
[llvm-bugs] [Bug 25876] New: -Wliteral-conversion warns about implicit conversion changing 0.99 to false
https://llvm.org/bugs/show_bug.cgi?id=25876
Bug ID: 25876
Summary: -Wliteral-conversion warns about implicit conversion
changing 0.99 to false
Product: clang
Version: 3.7
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: gpak...@pempek.net
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The following program makes clang 3.7 emit a curious warning:
~ clang main.c
main.c:6:10: warning: implicit conversion from 'float' to 'bool' changes value
from 0.99 to false [-Wliteral-conversion]
return 0.99f;
~~ ^
1 warning generated.
---
#include
#include
bool f()
{
return 1.99f;
}
int main(int argc, char* argv[])
{
if (f())
{
printf("yep!\n");
}
else
{
printf("nope!\n");
}
printf("\n¯\\_(ツ)_/¯\n");
return 0;
}
---
~ clang --version
clang
version 3.7.0 (tags/RELEASE_370/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
~
--
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 25391] [PATCH] libc++ is too pessimistic about features supported by current gcc
https://llvm.org/bugs/show_bug.cgi?id=25391 Eric Fiselier changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Eric Fiselier --- All changes have been committed, There are only 2 C++11 failures and 14 C++14 failures. -- 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 25877] New: Segfault when creating archive from lib.exe-created archive
https://llvm.org/bugs/show_bug.cgi?id=25877 Bug ID: 25877 Summary: Segfault when creating archive from lib.exe-created archive Product: tools Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: llvm-ar Assignee: unassignedb...@nondot.org Reporter: a...@crichton.co CC: llvm-bugs@lists.llvm.org Classification: Unclassified Over in Rust-land we've got some custom code to create an archive by merging in archives from other sources, often lib.exe created archives. Some of the generated archives by LLVM end up being corrupted, spurring on some investigation. To reproduce this, the following sequence of steps should suffice. This is currently specific to MSVC, but I suspect the bug is not Windows-specific: 1. Create an object file foo.obj from cl.exe 2. Create a directory named "reallylongname" and put foo.obj inside 3. Run "lib.exe /out:foo.lib reallylongname/foo.obj" 4. Create the following MRI script create libfoo.a addlib foo.lib save end 5. Run "llvm-ar.exe -M < script" That should suffice in segfaulting llvm-ar (at least it does locally). In some of our own tests we haven't seen segfaults but instead corrupt archives, but I think it's all basically the same. What I believe is going on here is that lib.exe creates archives where the name of each member typically contains the full path rather than just the filename component. For example the if you run `llvm-ar.exe t foo.lib` it will print "reallylongname/foo.obj". Upon inspecting the archive it looks like lib.exe handles these long file names via the standard put-the-name-in-the-string-table method. In the code for writeArchive, however, there's some disagreement about whether filename(Name) or Name is emitted as the name of an entry. For example when creating the string table (the writeStringTable function), the test for whether an entry is emitted is based on filename(I.getName()). When emitting an old entry, however, the name of the entry is I.getName() (in writeArchive). This disagreement causes the StringMapIndexIter value to overrun the end of the vector its iterating over, causing the segfault. I believe we only see this on MSVC because lib.exe stores full paths whereas most other archivers store file names (e.g. filename(Name) == Name). tl;dr;, I think the fix is to change the call to printMemberHeader to use filename(I.getName()), but I could be wrong! If you need any more info, just let me know. -- 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 25878] New: Error compiling an OpenMP program
https://llvm.org/bugs/show_bug.cgi?id=25878 Bug ID: 25878 Summary: Error compiling an OpenMP program Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Clang Compiler Support Assignee: unassignedclangb...@nondot.org Reporter: sim...@cs.utah.edu CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15481 --> https://llvm.org/bugs/attachment.cgi?id=15481&action=edit Archive with source and file generated for the bug report The error happens when try to compile an OpenMP program. It does not happen if I remove the "-fopenmp" flag and if I compile it with gcc. -- 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
