[llvm-bugs] [Bug 33941] New: utils/lit/tests/max-failures.py fails on Windows
https://bugs.llvm.org/show_bug.cgi?id=33941 Bug ID: 33941 Summary: utils/lit/tests/max-failures.py fails on Windows Product: Test Suite Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: lit Assignee: unassignedb...@nondot.org Reporter: modoca...@gmail.com CC: dan...@zuster.org, llvm-bugs@lists.llvm.org As described in utils/lit/README.txt, lit has its own test suite, which can be run like so: ``` # From within your LLVM source directory. utils/lit/lit.py \ --path /path/to/your/llvm/build/bin \ utils/lit/tests ``` However, when this command is run on a Windows host, the test utils/lit/tests/max-failures.py fails. -- 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 33944] New: utils/lit/tests/shtest-timeout.py fails on Windows
https://bugs.llvm.org/show_bug.cgi?id=33944 Bug ID: 33944 Summary: utils/lit/tests/shtest-timeout.py fails on Windows Product: Test Suite Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: lit Assignee: unassignedb...@nondot.org Reporter: modoca...@gmail.com CC: dan...@zuster.org, llvm-bugs@lists.llvm.org As described in utils/lit/README.txt, lit has its own test suite, which can be run like so: ``` # From within your LLVM source directory. utils/lit/lit.py \ --path /path/to/your/llvm/build/bin \ utils/lit/tests ``` However, when this command is run on a Windows host, the test utils/lit/tests/shtest-timeout.py fails. -- 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 33942] New: utils/lit/tests/unit/TestRunner.py fails on Windows
https://bugs.llvm.org/show_bug.cgi?id=33942 Bug ID: 33942 Summary: utils/lit/tests/unit/TestRunner.py fails on Windows Product: Test Suite Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: lit Assignee: unassignedb...@nondot.org Reporter: modoca...@gmail.com CC: dan...@zuster.org, llvm-bugs@lists.llvm.org As described in utils/lit/README.txt, lit has its own test suite, which can be run like so: ``` # From within your LLVM source directory. utils/lit/lit.py \ --path /path/to/your/llvm/build/bin \ utils/lit/tests ``` However, when this command is run on a Windows host, the test utils/lit/tests/unit/TestRunner.py fails. -- 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 33940] New: utils/lit/tests/shtest-shell.py fails on Windows
https://bugs.llvm.org/show_bug.cgi?id=33940 Bug ID: 33940 Summary: utils/lit/tests/shtest-shell.py fails on Windows Product: Test Suite Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: lit Assignee: unassignedb...@nondot.org Reporter: modoca...@gmail.com CC: dan...@zuster.org, llvm-bugs@lists.llvm.org As described in utils/lit/README.txt, lit has its own test suite, which can be run like so: ``` # From within your LLVM source directory. utils/lit/lit.py \ --path /path/to/your/llvm/build/bin \ utils/lit/tests ``` However, when this command is run on a Windows host, the test utils/lit/tests/shtest-shell.py fails. -- 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 33943] New: utils/lit/tests/unittest-adaptor.py fails on Windows
https://bugs.llvm.org/show_bug.cgi?id=33943 Bug ID: 33943 Summary: utils/lit/tests/unittest-adaptor.py fails on Windows Product: Test Suite Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: lit Assignee: unassignedb...@nondot.org Reporter: modoca...@gmail.com CC: dan...@zuster.org, llvm-bugs@lists.llvm.org As described in utils/lit/README.txt, lit has its own test suite, which can be run like so: ``` # From within your LLVM source directory. utils/lit/lit.py \ --path /path/to/your/llvm/build/bin \ utils/lit/tests ``` However, when this command is run on a Windows host, the test utils/lit/tests/unittest-adaptor.py fails. -- 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 33938] New: utils/lit/tests/shtest-output-printing.py fails on Windows
https://bugs.llvm.org/show_bug.cgi?id=33938 Bug ID: 33938 Summary: utils/lit/tests/shtest-output-printing.py fails on Windows Product: Test Suite Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: lit Assignee: unassignedb...@nondot.org Reporter: modoca...@gmail.com CC: dan...@zuster.org, llvm-bugs@lists.llvm.org As described in utils/lit/README.txt, lit has its own test suite, which can be run like so: ``` # From within your LLVM source directory. utils/lit/lit.py \ --path /path/to/your/llvm/build/bin \ utils/lit/tests ``` However, when this command is run on a Windows host, the test utils/lit/tests/shtest-output-printing.py fails. -- 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 33939] New: utils/lit/tests/shtest-format.py fails on Windows
https://bugs.llvm.org/show_bug.cgi?id=33939 Bug ID: 33939 Summary: utils/lit/tests/shtest-format.py fails on Windows Product: Test Suite Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: lit Assignee: unassignedb...@nondot.org Reporter: modoca...@gmail.com CC: dan...@zuster.org, llvm-bugs@lists.llvm.org As described in utils/lit/README.txt, lit has its own test suite, which can be run like so: ``` # From within your LLVM source directory. utils/lit/lit.py \ --path /path/to/your/llvm/build/bin \ utils/lit/tests ``` However, when this command is run on a Windows host, the test utils/lit/tests/shtest-format.py fails. -- 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 33935] New: utils/lit/tests/googletest-upstream-format.py fails on Windows
https://bugs.llvm.org/show_bug.cgi?id=33935 Bug ID: 33935 Summary: utils/lit/tests/googletest-upstream-format.py fails on Windows Product: Test Suite Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: lit Assignee: unassignedb...@nondot.org Reporter: modoca...@gmail.com CC: dan...@zuster.org, llvm-bugs@lists.llvm.org As described in utils/lit/README.txt, lit has its own test suite, which can be run like so: ``` # From within your LLVM source directory. utils/lit/lit.py \ --path /path/to/your/llvm/build/bin \ utils/lit/tests ``` However, when this command is run on a Windows host, the test utils/lit/tests/googletest-upstream-format.py fails. -- 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 33937] New: utils/lit/tests/selecting.py fails on Windows
https://bugs.llvm.org/show_bug.cgi?id=33937 Bug ID: 33937 Summary: utils/lit/tests/selecting.py fails on Windows Product: Test Suite Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: lit Assignee: unassignedb...@nondot.org Reporter: modoca...@gmail.com CC: dan...@zuster.org, llvm-bugs@lists.llvm.org As described in utils/lit/README.txt, lit has its own test suite, which can be run like so: ``` # From within your LLVM source directory. utils/lit/lit.py \ --path /path/to/your/llvm/build/bin \ utils/lit/tests ``` However, when this command is run on a Windows host, the test utils/lit/tests/selecting.py fails. -- 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 33933] New: utils/lit/tests/googletest-format.py fails on Windows
https://bugs.llvm.org/show_bug.cgi?id=33933 Bug ID: 33933 Summary: utils/lit/tests/googletest-format.py fails on Windows Product: Test Suite Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: lit Assignee: unassignedb...@nondot.org Reporter: modoca...@gmail.com CC: dan...@zuster.org, llvm-bugs@lists.llvm.org As described in utils/lit/README.txt, lit has its own test suite, which can be run like so: ``` # From within your LLVM source directory. utils/lit/lit.py \ --path /path/to/your/llvm/build/bin \ utils/lit/tests ``` However, when this command is run on a Windows host, the test utils/lit/tests/googletest-format.py fails. -- 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 33936] New: utils/lit/tests/shtest-encoding.py fails on Windows
https://bugs.llvm.org/show_bug.cgi?id=33936 Bug ID: 33936 Summary: utils/lit/tests/shtest-encoding.py fails on Windows Product: Test Suite Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: lit Assignee: unassignedb...@nondot.org Reporter: modoca...@gmail.com CC: dan...@zuster.org, llvm-bugs@lists.llvm.org As described in utils/lit/README.txt, lit has its own test suite, which can be run like so: ``` # From within your LLVM source directory. utils/lit/lit.py \ --path /path/to/your/llvm/build/bin \ utils/lit/tests ``` However, when this command is run on a Windows host, the test utils/lit/tests/shtest-encoding.py fails. -- 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 33934] New: utils/lit/tests/googletest-timeout.py fails on Windows
https://bugs.llvm.org/show_bug.cgi?id=33934 Bug ID: 33934 Summary: utils/lit/tests/googletest-timeout.py fails on Windows Product: Test Suite Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: lit Assignee: unassignedb...@nondot.org Reporter: modoca...@gmail.com CC: dan...@zuster.org, llvm-bugs@lists.llvm.org As described in utils/lit/README.txt, lit has its own test suite, which can be run like so: ``` # From within your LLVM source directory. utils/lit/lit.py \ --path /path/to/your/llvm/build/bin \ utils/lit/tests ``` However, when this command is run on a Windows host, the test utils/lit/tests/googletest-timeout.py fails. -- 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 33932] New: utils/lit/tests/discovery.py fails on Windows
https://bugs.llvm.org/show_bug.cgi?id=33932 Bug ID: 33932 Summary: utils/lit/tests/discovery.py fails on Windows Product: Test Suite Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: lit Assignee: unassignedb...@nondot.org Reporter: modoca...@gmail.com CC: dan...@zuster.org, llvm-bugs@lists.llvm.org As described in utils/lit/README.txt, lit has its own test suite, which can be run like so: ``` # From within your LLVM source directory. utils/lit/lit.py \ --path /path/to/your/llvm/build/bin \ utils/lit/tests ``` However, when this command is run on a Windows host, the test utils/lit/tests/discovery.py fails. Here's its output: https://gist.github.com/modocache/e5a5d22d6a7f3c401c378c0cbe77544e -- 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 33908] clang now depends on libxml2, apparently accidentally
https://bugs.llvm.org/show_bug.cgi?id=33908 Eric Beckmann changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Eric Beckmann --- r309070 -- 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 33931] New: Static variable in inline function having duplicates with shared library (compiled with GCC)
https://bugs.llvm.org/show_bug.cgi?id=33931
Bug ID: 33931
Summary: Static variable in inline function having duplicates
with shared library (compiled with GCC)
Product: clang
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: mikebentle...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Created attachment 18847
--> https://bugs.llvm.org/attachment.cgi?id=18847&action=edit
minimal reproducible example
This is a strange use case, but it is my use case.
Suppose you have an inline function with a static variable, such as
inline std::map& get_tests() {
static std::map tests;
return tests;
}
that is defined in a header file for a shared library. Seems reasonable,
right? Now suppose the shared library is compiled with GCC 5.4.0, also
reasonable. Then you create an application that uses this inline function and
compile your application with Clang. What happens is that the shared library,
when it calls this function, will have one copy of the static variable
different from the one in the application.
I have attached code that can duplicate this problem. This has been tested
with GCC 5.4.0 (and a little with GCC 6.1). I notice that this problem is NOT
there with GCC 4.9. So, I actually do not know if this is a Clang bug or a GCC
bug.
In the example code, I demonstrate that everything is okay when using a static
integer, but it fails when using a static map. I don't know what other kinds
of objects would have this problem.
Tested with the following versions of Clang:
- 3.9.0 final release
- 3.9.1 final release
- 4.0.0 final release
- 4.0.1 final release
- 5.0.0
- This is the one I have installed from building cling
- http://root.cern.ch/git/clang.git 1f8b137c7eb06ed8e321649ef7e3f3e7a96f361c
- http://root.cern.ch/git/llvm.git 2a34248cb945d63ded5ee55128e68efd7e5b87c8
--
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 33825] clang boostrap fails at link time with TLS errors
https://bugs.llvm.org/show_bug.cgi?id=33825 Fedor Sergeev changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Fedor Sergeev --- Fixed with: rL308978: [Sparc] invalid adjustments in TLS_LE/TLS_LDO relocations removed -- 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 33930] New: Assertion `OpN.isUniqued() && "Only uniqued operands cannot be mapped immediately"' failed.
https://bugs.llvm.org/show_bug.cgi?id=33930
Bug ID: 33930
Summary: Assertion `OpN.isUniqued() && "Only uniqued operands
cannot be mapped immediately"' failed.
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: paul_robin...@playstation.sony.com
CC: llvm-bugs@lists.llvm.org
Created attachment 18845
--> https://bugs.llvm.org/attachment.cgi?id=18845&action=edit
repro script
Crashes with trunk r308954. Okay with 4.0, haven't tried 5.0.
$ cat bz181281.cpp
struct Alpha {
virtual void bravo(...);
};
struct Charlie {
virtual ~Charlie() {}
};
struct CharlieImpl : Charlie, Alpha {
void bravo(...) {}
} delta;
$ clang -c -g bz181281.cpp
clang-5.0:
/home/probinson/projects/llvm-org/trunk/llvm/lib/Transforms/Utils/ValueMapper.cpp:640:
llvm::MDNode*
{anonymous}::MDNodeMapper::visitOperands({anonymous}::MDNodeMapper::UniquedGraph&,
const llvm::MDOperand*&, llvm::MDNode::op_iterator, bool&): Assertion
`OpN.isUniqued() && "Only uniqued operands cannot be mapped immediately"'
failed.
--
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 33849] [meta] 5.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=33849 Bug 33849 depends on bug 33881, which changed state. Bug 33881 Summary: ubsan: Program instrumented with -fsanitize=vptr may crash https://bugs.llvm.org/show_bug.cgi?id=33881 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 33881] ubsan: Program instrumented with -fsanitize=vptr may crash
https://bugs.llvm.org/show_bug.cgi?id=33881 Vedant Kumar changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Vedant Kumar --- Fixes landed in: clang/r309007 compiler-rt/r309008 -- 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 33929] New: -Wcast-qual should not warn about dropping 'const' when casting to ObjC types
https://bugs.llvm.org/show_bug.cgi?id=33929
Bug ID: 33929
Summary: -Wcast-qual should not warn about dropping 'const'
when casting to ObjC types
Product: clang
Version: trunk
Hardware: All
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: jordan_r...@apple.com
CC: llvm-bugs@lists.llvm.org
// clang -fsyntax-only -x objective-c -Weverything -
id reinterpretAsObject(const void *ptr) {
return (id)ptr;
}
:2:14: warning: cast from 'const void *' to 'id' drops const qualifier
[-Wcast-qual]
return (id)ptr;
^
...however, there's no way to avoid this warning; you can't const-qualify
Objective-C object types inside the pointer. It might have been better if this
weren't a common idiom on Apple platforms, but it is---both 'const void *' and
opaque pointers to const struct types are sometimes valid Objective-C objects,
and casts to 'id', 'Class', or concrete object pointer types like 'NSString *'
are considered common and acceptable.
(If we /were/ to start warning on these all the time, they should be silenced
by adding '__bridge', and the warning should have a fix-it. But even that's
probably too much churn for Apple platforms.)
--
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 33925] lld incorrectly creates manifest files by default
https://bugs.llvm.org/show_bug.cgi?id=33925 Nico Weber changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Nico Weber --- r308998 -- 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 33802] Address of _DYNAMIC symbol is incorrect when creating a shared object
https://bugs.llvm.org/show_bug.cgi?id=33802 Rafael Ávila de Espíndola changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33928] New: After r308791 there are numerous est case failures in bootstrap build
https://bugs.llvm.org/show_bug.cgi?id=33928 Bug ID: 33928 Summary: After r308791 there are numerous est case failures in bootstrap build Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: seu...@linux.vnet.ibm.com CC: llvm-bugs@lists.llvm.org You can see the failures here in the buildbot results: http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/3289 Failures were occurring earlier but were masked by a compilation problem introduced by an even earlier revision. Failing Tests (9): Clang :: CodeGen/avx512-reduceIntrin.c Clang :: CodeGen/avx512-reduceMinMaxIntrin.c Clang :: CodeGen/avx512f-builtins.c Clang :: CodeGen/vector-alignment.c Clang :: CodeGen/x86-inline-asm-v-constraint.c Clang :: CodeGen/x86_64-arguments.c Clang :: OpenMP/simd_metadata.c Clang :: Preprocessor/predefined-arch-macros.c Clang :: Preprocessor/x86_target_features.c Expected Passes: 33554 Expected Failures : 178 Unsupported Tests : 938 Unexpected Failures: 9 Some of the details: FAIL: Clang :: CodeGen/avx512-reduceMinMaxIntrin.c (5240 of 34679) TEST 'Clang :: CodeGen/avx512-reduceMinMaxIntrin.c' FAILED Script: -- /home/seurer/llvm/build/llvm-test/./bin/clang -cc1 -internal-isystem /home/seurer/llvm/build/llvm-test/lib/clang/6.0.0/include -nostdsysteminc -ffreestanding /home/seurer/llvm/llvm-test/tools/clang/test/CodeGen/avx512-reduceMinMaxIntrin.c -O2 -triple=x86_64-apple-darwin -target-cpu skylake-avx512 -emit-llvm -o - -Wall -Werror |/home/seurer/llvm/build/llvm-test/./bin/opt -instnamer -S |/home/seurer/llvm/build/llvm-test/./bin/FileCheck /home/seurer/llvm/llvm-test/tools/clang/test/CodeGen/avx512-reduceMinMaxIntrin.c -- Exit Code: 1 Command Output (stderr): -- /home/seurer/llvm/llvm-test/tools/clang/test/CodeGen/avx512-reduceMinMaxIntrin.c:9:12: error: expected string not found in input // CHECK: %tmp = icmp slt <8 x i64> %shuffle1.i, %__W ^ :11:2: note: scanning from here %tmp = icmp sgt <8 x i64> %__W, %shuffle1.i ^ -- TEST 'Clang :: CodeGen/vector-alignment.c' FAILED Script: -- /home/seurer/llvm/build/llvm-test/./bin/clang -cc1 -internal-isystem /home/seurer/llvm/build/llvm-test/lib/clang/6.0.0/include -nostdsysteminc -w -triple x86_64-apple-darwin10 -emit-llvm -o - /home/seurer/llvm/llvm-test/tools/clang/test/CodeGen/vector-alignment.c | /home/seurer/llvm/build/llvm-test/./bin/FileCheck /home/seurer/llvm/llvm-test/tools/clang/test/CodeGen/vector-alignment.c --check-prefix=ALL --check-prefix=SSE /home/seurer/llvm/build/llvm-test/./bin/clang -cc1 -internal-isystem /home/seurer/llvm/build/llvm-test/lib/clang/6.0.0/include -nostdsysteminc -w -triple i386-apple-darwin10 -emit-llvm -o - /home/seurer/llvm/llvm-test/tools/clang/test/CodeGen/vector-alignment.c | /home/seurer/llvm/build/llvm-test/./bin/FileCheck /home/seurer/llvm/llvm-test/tools/clang/test/CodeGen/vector-alignment.c --check-prefix=ALL --check-prefix=SSE /home/seurer/llvm/build/llvm-test/./bin/clang -cc1 -internal-isystem /home/seurer/llvm/build/llvm-test/lib/clang/6.0.0/include -nostdsysteminc -w -triple x86_64-apple-darwin10 -target-feature +avx -emit-llvm -o - /home/seurer/llvm/llvm-test/tools/clang/test/CodeGen/vector-alignment.c | /home/seurer/llvm/build/llvm-test/./bin/FileCheck /home/seurer/llvm/llvm-test/tools/clang/test/CodeGen/vector-alignment.c --check-prefix=ALL --check-prefix=AVX /home/seurer/llvm/build/llvm-test/./bin/clang -cc1 -internal-isystem /home/seurer/llvm/build/llvm-test/lib/clang/6.0.0/include -nostdsysteminc -w -triple i386-apple-darwin10 -target-feature +avx -emit-llvm -o - /home/seurer/llvm/llvm-test/tools/clang/test/CodeGen/vector-alignment.c | /home/seurer/llvm/build/llvm-test/./bin/FileCheck /home/seurer/llvm/llvm-test/tools/clang/test/CodeGen/vector-alignment.c --check-prefix=ALL --check-prefix=AVX /home/seurer/llvm/build/llvm-test/./bin/clang -cc1 -internal-isystem /home/seurer/llvm/build/llvm-test/lib/clang/6.0.0/include -nostdsysteminc -w -triple x86_64-apple-darwin10 -target-feature +avx512f -emit-llvm -o - /home/seurer/llvm/llvm-test/tools/clang/test/CodeGen/vector-alignment.c | /home/seurer/llvm/build/llvm-test/./bin/FileCheck /home/seurer/llvm/llvm-test/tools/clang/test/CodeGen/vector-alignment.c --check-prefix=ALL --check-prefix=AVX512 /home/seurer/llvm/build/llvm-test/./bin/clang -cc1 -internal-isystem /home/seurer/llvm/build/llvm-test/lib/clang/6.0.0/include -nostdsysteminc -w -triple i386-apple-darwin10 -target-feature +avx512f -emit-llvm -o - /home/seurer/llvm/llvm-test/tools/clang/test/CodeGen/vector-alignment.c | /home/seurer/llvm
[llvm-bugs] [Bug 33926] attribute declaration must precede definition
https://bugs.llvm.org/show_bug.cgi?id=33926 zahira.ammarguel...@intel.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from zahira.ammarguel...@intel.com --- Closed as this is not a 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 33927] New: ISL object leak in DependenceInfo
https://bugs.llvm.org/show_bug.cgi?id=33927 Bug ID: 33927 Summary: ISL object leak in DependenceInfo Product: Polly Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: isl Assignee: polly-...@googlegroups.com Reporter: l...@meinersbur.de CC: llvm-bugs@lists.llvm.org Created attachment 18844 --> https://bugs.llvm.org/attachment.cgi?id=18844&action=edit erc_do_i_0.ll The attached test case leaks an isl_space. This has likely to to with the max-operations counter exceeding in the middle of the dependency computation. $ opt -polly-opt-isl erc_do_i_0.ll WARNING: You're attempting to print out a bitcode file. This is inadvisable as it may cause display problems. If you REALLY want to taste LLVM bitcode first-hand, you can force output with the `-f' option. /root/src/llvm/tools/polly/lib/External/isl/isl_ctx.c:253: isl_ctx freed, but some objects still reference it Valgrind report: ==32305== 24,118 (56 direct, 24,062 indirect) bytes in 1 blocks are definitely lost in loss record 48 of 50 ==32305==at 0x6144B55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==32305==by 0x3378031: isl_calloc_or_die (isl_ctx.c:75) ==32305==by 0x33A46D8: isl_map_alloc_space (isl_map.c:5921) ==32305==by 0x33A49B2: isl_map_empty (isl_map.c:6009) ==32305==by 0x332FE48: isl_map_from_pw_multi_aff (isl_aff.c:4392) ==32305==by 0x33A7122: isl_map_partial_lexopt_aligned (isl_map.c:6808) ==32305==by 0x33A6EAD: isl_map_partial_lexopt (isl_map_lexopt_templ.c:182) ==32305==by 0x33A7182: isl_map_partial_lexmax (isl_map.c:6821) ==32305==by 0x337BBC2: restricted_partial_lexmax (isl_flow.c:589) ==32305==by 0x337BEBC: last_source (isl_flow.c:650) ==32305==by 0x337D567: compute_val_based_dependences (isl_flow.c:1189) ==32305==by 0x337DC61: access_info_compute_flow_core (isl_flow.c:1308) ==32305==by 0x3380B52: compute_single_flow (isl_flow.c:3050) ==32305==by 0x3380E61: compute_flow_schedule (isl_flow.c:3134) ==32305==by 0x3380F64: isl_union_access_info_compute_flow (isl_flow.c:3185) ==32305==by 0x2C1A220: buildFlow(isl_union_map*, isl_union_map*, isl_union_map*, isl_schedule*) (DependenceInfo.cpp:297) ==32305==by 0x2C1A2D5: buildWAR(isl_union_map*, isl_union_map*, isl_union_map*, isl_schedule*) (DependenceInfo.cpp:372) ==32305==by 0x2C1A9F0: polly::Dependences::calculateDependences(polly::Scop&) (DependenceInfo.cpp:542) ==32305==by 0x2C1C65D: polly::DependenceInfo::recomputeDependences(polly::Dependences::AnalysisLevel) (DependenceInfo.cpp:967) ==32305==by 0x2C1C5C2: polly::DependenceInfo::getDependences(polly::Dependences::AnalysisLevel) (DependenceInfo.cpp:961) ==32305==by 0x2BF24FF: (anonymous namespace)::IslScheduleOptimizer::runOnScop(polly::Scop&) (ScheduleOptimizer.cpp:1460) ==32305==by 0x2CC59F0: polly::ScopPass::runOnRegion(llvm::Region*, llvm::RGPassManager&) (ScopPass.cpp:29) ==32305==by 0x1AB12AD: llvm::RGPassManager::runOnFunction(llvm::Function&) (RegionPass.cpp:98) ==32305==by 0x21BB035: llvm::FPPassManager::runOnFunction(llvm::Function&) (LegacyPassManager.cpp:1514) ==32305==by 0x21BB1CE: llvm::FPPassManager::runOnModule(llvm::Module&) (LegacyPassManager.cpp:1535) ==32305==by 0x21BB549: (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) (LegacyPassManager.cpp:1591) ==32305==by 0x21BBC5E: llvm::legacy::PassManagerImpl::run(llvm::Module&) (LegacyPassManager.cpp:1694) ==32305==by 0x21BBE6A: llvm::legacy::PassManager::run(llvm::Module&) (LegacyPassManager.cpp:1725) ==32305==by 0x141C491: main (opt.cpp:756) Valgrind report (without refcounting): ==31878== 14,776 (80 direct, 14,696 indirect) bytes in 1 blocks are definitely lost in loss record 29 of 31 ==31878==at 0x6142B8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==31878==by 0x3377FCC: isl_malloc_or_die (isl_ctx.c:65) ==31878==by 0x341D9EC: isl_space_alloc (isl_space.c:32) ==31878==by 0x342080C: isl_space_join (isl_space.c:1206) ==31878==by 0x3420D7A: isl_space_range_product (isl_space.c:1322) ==31878==by 0x333B2CE: isl_multi_union_pw_aff_range_product_aligned (isl_multi_templ.c:786) ==31878==by 0x333B25F: isl_multi_union_pw_aff_align_params_multi_multi_and (isl_multi_templ.c:763) ==31878==by 0x333B402: isl_multi_union_pw_aff_range_product (isl_multi_templ.c:818) ==31878==by 0x333B7C2: isl_multi_union_pw_aff_flat_range_product (isl_multi_templ.c:989) ==31878==by 0x33FC56E: collect_filter_prefix_update (isl_schedule_node.c:563) ==31878==by 0x33FC6FB: collect_filter_prefix (isl_schedule_node.c:634) ==31878==by 0x33FCABA: isl_schedule_node_get_prefix_schedule_relation (isl_schedule_node.c:799) ==31878==by 0x33806F2: collect_sink_source (isl_flow.c:2887) ==31878==
[llvm-bugs] [Bug 33926] New: attribute declaration must precede definition
https://bugs.llvm.org/show_bug.cgi?id=33926
Bug ID: 33926
Summary: attribute declaration must precede definition
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: zahira.ammarguel...@intel.com
CC: llvm-bugs@lists.llvm.org
bash-4.2$ cat t3.c
extern __inline int foo (int __goo) {
return __goo;
}
extern __typeof(foo) foo __asm__("");
bash-4.2$
bash-4.2$ gcc -v
gcc version 4.8.5 (GCC)
bash-4.2$
bash-4.2$ gcc -c t3.c
bash-4.2$
bash-4.2$ ../llorg_ws/builds/llorgefi2linux_debug/llvm/bin/clang -v
clang version 6.0.0 (cfe/trunk 308973)
bash-4.2$
bash-4.2$ clang -c -Xclang -ast-dump t3.c | grep foo
t3.c:4:34: warning: attribute declaration must precede definition
[-Wignored-attributes]
extern __typeof(foo) foo __asm__("");
^
t3.c:1:21: note: previous definition is here
extern __inline int foo (int __goo) {
^
1 warning generated.
|-FunctionDecl 0xb5c40b0 line:1:21 referenced foo 'int
(int)' extern inline
`-FunctionDecl 0xb5c42e8 prev 0xb5c40b0 col:22 foo 'int
(int)' extern
bash-4.2$
gcc doesn't generate a warning. clang does. We can see that foo has 2 different
attributes.
--
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 33925] New: lld incorrectly creates manifest files by default
https://bugs.llvm.org/show_bug.cgi?id=33925
Bug ID: 33925
Summary: lld incorrectly creates manifest files by default
Product: lld
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: COFF
Assignee: unassignedb...@nondot.org
Reporter: nicolaswe...@gmx.de
CC: llvm-bugs@lists.llvm.org
C:\src\chrome\src>type test.cc
int main() {}
C:\src\chrome\src>cl /nologo /c test.cc
test.cc
C:\src\chrome\src>link.exe /nologo test.obj
C:\src\chrome\src>type test.exe.manifest
The system cannot find the file specified.
C:\src\chrome\src>"third_party\llvm-build\Release+Asserts\bin\lld-link.exe"
test.obj
C:\src\chrome\src>type test.exe.manifest
lld-link creates a .manifest file by default while link.exe doesn't (unless you
pass in /manifest). lld-link should match link.exe's behavior.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33924] New: Unexpected error "definition with same mangled name as another definition"
https://bugs.llvm.org/show_bug.cgi?id=33924
Bug ID: 33924
Summary: Unexpected error "definition with same mangled name as
another definition"
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Modules
Assignee: unassignedclangb...@nondot.org
Reporter: pank...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Created attachment 18843
--> https://bugs.llvm.org/attachment.cgi?id=18843&action=edit
Files that reproduce the error
It triggers on the following piece of code when we try to instantiate templated
function `format` in 2 separate modules:
// -- format.h
class Formatter {
public:
template
void doFormat(T& out) {}
};
template
void format(T t) {
Formatter f;
auto lambda = [] {};
f.doFormat(lambda);
}
(see full set of files in attachment)
Error message:
In module 'foo1' imported from main.cpp:1:
In module 'format' imported from ./foo1.h:3:
./format.h:6:8: error: definition with same mangled name as another
definition
void doFormat(T& out) {}
^
./format.h:6:8: note: previous definition is here
Seems like this is related to passing lambda from templated function. If I try
to call `doFormat` on regular class or move body of `format` into module `foo`
itself, then the error goes away.
Worth noting there is also assertion triggering when using clang built from
source in debug mode:
llvm/lib/IR/Value.cpp:402: void llvm::Value::doRAUW(llvm::Value*, bool):
Assertion `New->getType() == getType(
) && "replaceAllUses of value with new value of different type!"' failed.
Repro command line:
clang++ --std=c++14 -I . -fmodules -fcxx-modules
-fmodules-cache-path=./modules_out/_module_cache -c main.cpp -o main.o
A non-modular compilation that uses the same set of files finishes fine.
Let me know if you need any extra information.
--
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 33923] New: getGlobalID() always returns 0
https://bugs.llvm.org/show_bug.cgi?id=33923 Bug ID: 33923 Summary: getGlobalID() always returns 0 Product: clang Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: m...@tiferrei.com CC: llvm-bugs@lists.llvm.org Created attachment 18842 --> https://bugs.llvm.org/attachment.cgi?id=18842&action=edit Source file, output and test file Hello there, I was trying to get some kind of ID for each node that Clang passes me, I needed this to later detect if functions are repeatedly called, and I'd use the ID to match functions. So I decided to take a look at `getGlobalID()` (clang::Decl::getGlobalID) and see if this would give me some unique identifiers. Oddly enough, this seems to always return an ID of "0" for all functions. So after some googling I also found this post: http://clang-developers.42468.n3.nabble.com/Getting-the-unique-ID-for-a-clang-Decl-td4052968.html which seems to get to this same conclusion. I am a beginner in clang generally and so I don't know if this is just something that I'm doing incorrectly or really a bug. I have attached the specific source file and some example output. PS: The ideal for me would be to actually get the hex code that is shown right after each node's type (in "CompoundStmt 0x7f8c39807198 " I'd like to get "0x7f8c39807198") Thank you, tiferrei -- 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 33922] New: [OpenMP 5.0] New ident_t flags for __kmpc_for_static_init()
https://bugs.llvm.org/show_bug.cgi?id=33922 Bug ID: 33922 Summary: [OpenMP 5.0] New ident_t flags for __kmpc_for_static_init() Product: OpenMP Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Clang Compiler Support Assignee: unassignedclangb...@nondot.org Reporter: olga.malysh...@intel.com CC: llvm-bugs@lists.llvm.org OpenMP 5.0 will include OpenMP Tools interface that requires distinguishing different worksharing constructs. Since the same entry point (__kmp_for_static_init(ident_t *loc, kmp_int32 global_tid,)) is called in case static loop/sections/distribute it is suggested using 'flags' field of the ident_t structure to pass the type of the construct. Please add the following flags and set them properly OMP_IDENT_WORK_LOOP = 0x200 // static loop OMP_IDENT_WORK_SECTIONS = 0x400 //sections OMP_IDENT_WORK_DISTRIBUTE = 0x800 //distribute -- 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 33921] New: ARM NEON vectorization miscompiles code in 5.0
https://bugs.llvm.org/show_bug.cgi?id=33921 Bug ID: 33921 Summary: ARM NEON vectorization miscompiles code in 5.0 Product: libraries Version: 5.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: mar...@martin.st CC: llvm-bugs@lists.llvm.org Starting with SVN r306803, some C code that wasn't vectorized before now is vectorized. This seems to break e.g. some VP9 inverse transforms in libavcodec, in code like this: https://git.libav.org/?p=libav.git;a=blob;f=libavcodec/vp9dsp.c;h=7f863943284b8970744c81b0b7d749e5c9cf8bdf;hb=2b1324bd167553f49736e4eaa94f96da9982925e#l947 with the idct8_1d and iadst8_1d functions. If this file is built with -fno-tree-vectorize, the issue disappears. This regressed when upgrading from SVN r305659 to the 5.0 branch point: https://fate.libav.org/armv7-win32-clang-5.0 Bisecting this leads to SVN r306803. The same issue can also be reproduced when targeting linux, not only windows. It should be reproducable by building libav and running "make fate-checkasm-vp9dsp", which should pass unless this is miscompiled. I will dig into it further, hopefully soon, to fill in with a better reproducable testcase of the 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 33920] New: Backport SVN r308950 to 5.0
https://bugs.llvm.org/show_bug.cgi?id=33920 Bug ID: 33920 Summary: Backport SVN r308950 to 5.0 Product: libraries Version: 5.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AArch64 Assignee: unassignedb...@nondot.org Reporter: mar...@martin.st CC: llvm-bugs@lists.llvm.org Please backport r308950 ([AArch64] Reserve a 16 byte aligned amount of fixed stack for win64 varargs) to 5.0. This fixes an issue with the new win/arm64 calling convention. The support for targeting win/arm64 itself is still immature, but the calling convention handling in itself should be mature enough, and can be used by Wine for clang >= 5.0 if this is backported. This carries no regression risk as it only touches code in new codepaths that aren't used before. -- 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 33714] Size sanity check is pessimistic
https://bugs.llvm.org/show_bug.cgi?id=33714 George Rimar changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from George Rimar --- r308955 -- 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
