[llvm-bugs] [Bug 41854] New: Regression since "Reject attempts to call non-static member functions on objects outside their lifetime in constant expressions."
https://bugs.llvm.org/show_bug.cgi?id=41854
Bug ID: 41854
Summary: Regression since "Reject attempts to call non-static
member functions on objects outside their lifetime in
constant expressions."
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: mar...@martin.st
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Created attachment 21939
--> https://bugs.llvm.org/attachment.cgi?id=21939&action=edit
Original non-reduced reproduction source
Since "Reject attempts to call non-static member functions on objects outside
their lifetime in constant expressions.", SVN r360538, compiling harfbuzz
fails. It can be reproduced with the following reduced (and broken) piece of
code:
$ cat reduced.cpp
struct e { operator int( } struct f { e c}
int a f &d = reinterpret_cast< f & >(a;
unsigned b = d.c
$ clang -target x86_64-w64-mingw32 -c reduced.cpp
clang-9: ../tools/clang/lib/AST/ExprConstant.cpp:306: bool
{anonymous}::SubobjectDesignator::isOnePastTheEnd() const: Assertion `!Invalid'
failed.
Stack dump:
0. Program arguments: /home/martin/clang-nightly-mon/bin/clang-9 -cc1
-triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-main-file-name reduced.cpp -mrelocation-model static -mthread-model posix
-mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases
-munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info
-debugger-tuning=gdb -coverage-notes-file
/home/martin/code/reduce-harfbuzz/reduced.gcno -resource-dir
/home/martin/clang-nightly-mon/lib/clang/9.0.0 -internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/7.4.0/../../../../include/c++/7.4.0
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/7.4.0/../../../../include/x86_64-linux-gnu/c++/7.4.0
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/7.4.0/../../../../include/x86_64-linux-gnu/c++/7.4.0
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/7.4.0/../../../../include/c++/7.4.0/backward
-internal-isystem /usr/local/include -internal-isystem
/home/martin/clang-nightly-mon/lib/clang/9.0.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdeprecated-macro -fdebug-compilation-dir /home/martin/code/reduce-harfbuzz
-ferror-limit 19 -fmessage-length 0 -fobjc-runtime=gcc -fcxx-exceptions
-fexceptions -fdiagnostics-show-option -o reduced.o -x c++ reduced.cpp
-faddrsig
1. parser at end of file
#0 0x556f9d3a038a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/home/martin/clang-nightly-mon/bin/clang-9+0x1e8338a)
#1 0x556f9d39e034 llvm::sys::RunSignalHandlers()
(/home/martin/clang-nightly-mon/bin/clang-9+0x1e81034)
#2 0x556f9d39e172 (/home/martin/clang-nightly-mon/bin/clang-9+0x1e81172)
#3 0x7f850c0f2890 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
#4 0x7f850ada3e97 gsignal
/build/glibc-OTsEL5/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
#5 0x7f850ada5801 abort /build/glibc-OTsEL5/glibc-2.27/stdlib/abort.c:81:0
#6 0x7f850ad9539a __assert_fail_base
/build/glibc-OTsEL5/glibc-2.27/assert/assert.c:89:0
#7 0x7f850ad95412 (/lib/x86_64-linux-gnu/libc.so.6+0x30412)
#8 0x556f9f21c1da (/home/martin/clang-nightly-mon/bin/clang-9+0x3cff1da)
#9 0x556f9c09b79e _init
(/home/martin/clang-nightly-mon/bin/clang-9+0xb7e79e)
#10 0x556f9c0a3b6c _init
(/home/martin/clang-nightly-mon/bin/clang-9+0xb86b6c)
#11 0x556f9f2414cb (/home/martin/clang-nightly-mon/bin/clang-9+0x3d244cb)
#12 0x556f9f2330dd (/home/martin/clang-nightly-mon/bin/clang-9+0x3d160dd)
#13 0x556f9f23511e (/home/martin/clang-nightly-mon/bin/clang-9+0x3d1811e)
#14 0x556f9f2359bf clang::Expr::EvaluateAsRValue(clang::Expr::EvalResult&,
clang::ASTContext const&, bool) const
(/home/martin/clang-nightly-mon/bin/clang-9+0x3d189bf)
#15 0x556f9ea7d535 (/home/martin/clang-nightly-mon/bin/clang-9+0x3560535)
#16 0x556f9ea8c7df (/home/martin/clang-nightly-mon/bin/clang-9+0x356f7df)
#17 0x556f9ea900bb (/home/martin/clang-nightly-mon/bin/clang-9+0x35730bb)
#18 0x556f9ea920f2 clang::Sema::CheckCompletedExpr(clang::Expr*,
clang::SourceLocation, bool)
(/home/martin/clang-nightly-mon/bin/clang-9+0x35750f2)
#19 0x556f9ecbe311 clang::Sema::ActOnFinishFullExpr(clang::Expr*,
clang::SourceLocation, bool, bool)
(/home/martin/clang-nightly-mon/bin/clang-9+0x37a1311)
#20 0x556f9eb15aa3 clang::Sema::AddInitializerToDecl(clang::Decl*,
clang::Expr*, bool) (/home/martin/clang-nightly-mon/bin/clang-9+0x35f8aa3)
#21 0x556f9e9189de
clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&,
clang::Parser::ParsedTempla
[llvm-bugs] [Bug 41852] Regression since "[Attribute/Diagnostics] Print macro if definition is an attribute declaration"
https://bugs.llvm.org/show_bug.cgi?id=41852 Martin Storsjö changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Martin Storsjö --- Thanks, I can confirm that it is fixed now. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41854] Regression since "Reject attempts to call non-static member functions on objects outside their lifetime in constant expressions."
https://bugs.llvm.org/show_bug.cgi?id=41854 Richard Smith changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Richard Smith --- Thanks for the great testcase, fixed in r360560. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41855] New: [DAGCombiner] Incorrect alias analysis leads to wrong codegen.
https://bugs.llvm.org/show_bug.cgi?id=41855 Bug ID: 41855 Summary: [DAGCombiner] Incorrect alias analysis leads to wrong codegen. Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: clement.cour...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 21940 --> https://bugs.llvm.org/attachment.cgi?id=21940&action=edit c++ reproducer Reproducer is attached (thanks Eric). Introduced in r357070. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41845] Crash when expanding an empty fold expression
https://bugs.llvm.org/show_bug.cgi?id=41845 Richard Smith changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Richard Smith --- Thanks for the report, fixed in r360563. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41855] [DAGCombiner] Incorrect alias analysis leads to wrong codegen.
https://bugs.llvm.org/show_bug.cgi?id=41855 Clement Courbet changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Clement Courbet --- Fixed by r360566/dcab1079b16. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41856] New: CP15 barrier instructions should be emitted before the exclusives loops
https://bugs.llvm.org/show_bug.cgi?id=41856 Bug ID: 41856 Summary: CP15 barrier instructions should be emitted before the exclusives loops Product: new-bugs Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: rvo...@me.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 21941 --> https://bugs.llvm.org/attachment.cgi?id=21941&action=edit Never ending loop ## Symptoms * Rustup hangs (unable to install Rust) * Tracked down to parking_lot issue: https://github.com/Amanieu/parking_lot/issues/130 * Not just Rust related, Swift has this problem as well * https://forums.balena.io/t/cloud-build-fails-but-local-device-build-works-on-raspberry-pi-zero/4994 strex never succeeds and is looping indefinitely. ## Environment * Linux kernel with CP15_BARRIER_EMULATION=y * abi.cp15_barrier set to 1 (emulate) * arm-unknown-linux-gnueabihf toolchain ## CP15 barrier instructions * They're deprecated since armv7 * Linux kernel can emulate or HW exec them: https://www.kernel.org/doc/Documentation/arm64/legacy_instructions.txt * abi.cp15_barrier is set to 2 (HW exec) -> there's no issue * The CPU must support them * ARMv8 in our case, which still supports them * abi.cp15_barrier is set to 1 (emulate) -> there's this issue ## Issue description parking_lot author: > This seems to be closer to an LLVM bug than a parking_lot bug. The source > of the problem is the CP15 emulation in the kernel. Essentially the > mcr p15, #0x0, r12, c7, c10, #0x5 is trapping to the kernel every time, > which invalidates the exclusive monitor between the ldrex and strex > instructions. This results in the strex never succeeding and looping > indefinitely. See attached loop.png image. ARM engineer (Will Deacon) response on this: > Hi again, Robert, > > Just a quick update on this: > > 1. CP15 barriers remain deprecated in the Armv8 architecture, and so >may be removed entirely from future CPUs. > > 2. Because of (1), the kernel defaults to trap+emulate, so that it can >warn about the use of these instructions. I think this is the right >thing to do because, once the instructions have been removed, we >will have no choice but to trap+emulate (this happened for the SWP >instruction already). This trapping will prevent your exclusives loop >from ever succeeding. > > 3. The right place to address this issue is in LLVM, where atomic >read-modify-write operations with conditional release semantics (i.e. >release on success) should actually emit the CP15 barrier before the >exclusives loop. Assuming that contention is rare (which it kind of >needs to be for performant compare-and-swap anyway), I don't see this >having a meaningful impact on performance. > > I've reached out to one of our upstream LLVM developers, and I'll be talking > with him face-to-face next week about getting this fixed. > > Will ## Solution Will's third point: > Atomic read-modify-write operations with conditional release semantics (i.e. > release on success) should actually emit the CP15 barrier before the > exclusives loop. Assuming that contention is rare (which it kind of > needs to be for performant compare-and-swap anyway), I don't see this > having a meaningful impact on performance. ## No fix People aren't / won't be able to use Rust / Swift / ... on Linux with CP15_BARRIER_EMULATION=y & abi.cp15_barrier=1 (emulation, default value) & arm-unknown-linux-gnueabihf toolchain. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41835] Assertion failure in clang::ASTContext::adjustExceptionSpec
https://bugs.llvm.org/show_bug.cgi?id=41835 Mikhail Maltsev changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Mikhail Maltsev --- Works for me. Thanks for a quick fix. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41857] New: Clang frontend crash when using -o /dev/null with wasm
https://bugs.llvm.org/show_bug.cgi?id=41857 Bug ID: 41857 Summary: Clang frontend crash when using -o /dev/null with wasm Product: clang Version: 8.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: jus...@postgresql.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 21942 --> https://bugs.llvm.org/attachment.cgi?id=21942&action=edit Bugpoint simplified bitcode which the crash happens with Stumbled on an unexpected bug with clang when using -o /dev/null, that seems to happen only when generating for wasm: $ clang --compile -v --target=wasm32-unknown-unknown-wasm -o /dev/null bugpoint-reduced-simplified.ll clang version 8.0.1 (https://git.llvm.org/git/clang.git 0a125120dc2ee0fe914542b605996bebaf0b8e9a) (https://git.llvm.org/git/llvm.git 45a188afecbea2d2409cc282bdb91bf58da8b0c8) Target: wasm32-unknown-unknown-wasm Thread model: single InstalledDir: /opt/llvm8/bin "/opt/llvm8/bin/clang-8" -cc1 -triple wasm32-unknown-unknown-wasm -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name bugpoint-reduced-simplified.ll -mrelocation-model static -mthread-model single -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu generic -fvisibility hidden -dwarf-column-info -debugger-tuning=gdb -momit-leaf-frame-pointer -v -coverage-notes-file /dev/null.gcno -resource-dir /opt/llvm8/lib/clang/8.0.1 -fdebug-compilation-dir /home/jc/git_repos/src/github.com/tinygo-org/tinygo/src/examples/wasm/main -ferror-limit 19 -fmessage-length 144 -fobjc-runtime=gnustep -fno-common -fdiagnostics-show-option -fcolor-diagnostics -o /dev/null -x ir bugpoint-reduced-simplified.ll clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target x86_64-unknown-linux-gnu fatal error: error in backend: section size does not fit in a uint32_t clang-8: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 8.0.1 (https://git.llvm.org/git/clang.git 0a125120dc2ee0fe914542b605996bebaf0b8e9a) (https://git.llvm.org/git/llvm.git 45a188afecbea2d2409cc282bdb91bf58da8b0c8) Target: wasm32-unknown-unknown-wasm Thread model: single InstalledDir: /opt/llvm8/bin clang-8: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script. clang-8: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs. When giving any output filename (eg not /dev/null), the code generation works: $ clang --compile -v --target=wasm32-unknown-unknown-wasm -o stuff bugpoint-reduced-simplified.ll clang version 8.0.1 (https://git.llvm.org/git/clang.git 0a125120dc2ee0fe914542b605996bebaf0b8e9a) (https://git.llvm.org/git/llvm.git 45a188afecbea2d2409cc282bdb91bf58da8b0c8) Target: wasm32-unknown-unknown-wasm Thread model: single InstalledDir: /opt/llvm8/bin "/opt/llvm8/bin/clang-8" -cc1 -triple wasm32-unknown-unknown-wasm -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name bugpoint-reduced-simplified.ll -mrelocation-model static -mthread-model single -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu generic -fvisibility hidden -dwarf-column-info -debugger-tuning=gdb -momit-leaf-frame-pointer -v -coverage-notes-file /home/jc/git_repos/src/github.com/tinygo-org/tinygo/src/examples/wasm/main/stuff.gcno -resource-dir /opt/llvm8/lib/clang/8.0.1 -fdebug-compilation-dir /home/jc/git_repos/src/github.com/tinygo-org/tinygo/src/examples/wasm/main -ferror-limit 19 -fmessage-length 144 -fobjc-runtime=gnustep -fno-common -fdiagnostics-show-option -fcolor-diagnostics -o stuff -x ir bugpoint-reduced-simplified.ll clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target x86_64-unknown-linux-gnu $ ls -la stuff -rw-rw-r--. 1 jc jc 4090 May 13 21:21 stuff Using /dev/null with non-wasm seems fine: $ clang --compile -v -o /dev/null bugpoint-reduced-simplified.ll clang version 8.0.1 (https://git.llvm.org/git/clang.git 0a125120dc2ee0fe914542b605996bebaf0b8e9a) (https://git.llvm.org/git/llvm.git 45a188afecbea2d2409cc282bdb91bf58da8b0c8) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /opt/llvm8/bin Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.5 Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.5 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 "/opt/llvm8/bin/clang-8" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-valu
[llvm-bugs] [Bug 41755] omp_sched_monotonic declaration causes error when building the compiler
https://bugs.llvm.org/show_bug.cgi?id=41755 Andrey Churbanov changed: What|Removed |Added Status|NEW |RESOLVED CC||k...@ca.ibm.com Resolution|--- |FIXED --- Comment #4 from Andrey Churbanov --- I added Kelvin to CC list just in case, as a Fortran expert. I am sorry, I could be too rigorous in my initial comment without enough details, as I referred to the Fortran 2008 standard (ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1830.pdf). Indeed, for the F03, things are not so clear, because it only states that the boz-literal-constant should behave in our case (given that we've fixed non-standard assignment) as INT(INT(0x8000, kind=16), kind=4), and I failed to find what should happen during conversion of 128-bit value into 32-bit value in the F03 standard. > 2. 0x8000 = 2,147,483,648. This cannot be represented by a signed 4-byte > integer; it requires an unsigned 4-byte integer. That sounds a bit ambiguous to me. I'd say that definitely 0x8000 = 2147483648_16 given gfortran supports 128-byte integers. And then 2147483648_16 = -2147483648_4. Which is perfectly valid 32-bit integer. And that is what gfortran does with -fno-range-check flag. I agree that possibly gfortran has the right to treat the integer conversion the way it does (C-style, as opposed to Fortran bit model), and complain on integer overflow. But the F03 does not require it to behave this way, as there are no details on what the integer conversion should do. According to bit model (section 13.3. of F03) our code looks fine. And I don't think we should treat F08 to be in contradiction with F03 here. I'd rather treat F08 as a clarification of F03, in which case again gfortan behaves wrong by default. > c). Finally, even if the code is changed to be standard-conforming, its > extensive use of digit-strings as kind type parameters makes it > non-portable... We try to not use digit strings as kinds, so the code still looks pretty portable (we use c_int and propagate it to all integer kinds of default size). If some implementation only supports 16-bit integers, than that can be a problem. But as Johnny noted, here we follow OpenMP specification which hardcoded the value in the text. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41858] New: Spurious “has different definitions in different modules” error
https://bugs.llvm.org/show_bug.cgi?id=41858
Bug ID: 41858
Summary: Spurious “has different definitions in different
modules” error
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Modules
Assignee: unassignedclangb...@nondot.org
Reporter: steinar+l...@gunderson.no
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Created attachment 21943
--> https://bugs.llvm.org/attachment.cgi?id=21943&action=edit
Patch on top of MySQL for prototype module support/use
Hi,
I'm trying to convert MySQL to modules as an experiment (both to learn about
modules, and to see if it could help with things like compile times), but I
keep running into error messages that are either wrong or just seem wrong (and
thus should be reworded somehow).
I don't know how to make a minimal sample with anything involving modules (you
can't really give preprocessed files, and this bug seems to involve the
interaction between several build steps), so I'm going to give a small HOWTO on
how to reproduce instead. FWIW, I'm starting on Debian buster, with clang++-9
from experimental (9.0.0-svn358327-1~exp1) and cmake installed.
git clone https://github.com/mysql/mysql-server # current SHA is 124c7ab1
cd mysql-server
patch -p1 -d . < ~/mysql-module-hacks.diff # attached to bug
mkdir obj
cd obj
cmake .. -DDOWNLOAD_BOOST=1 -DWITH_BOOST=/tmp/boost -DWITH_ROUTER=0
-DCMAKE_C_COMPILER=clang-9 -DCMAKE_CXX_COMPILER=clang++-9
-DCMAKE_CXX_FLAGS="-O2 -fmodules -fmodules-ts"
make -j20 -k # -k is needed to ignore some issues with code that uses reserved
words etc.
Given some patience, you will eventually get this error:
In module 'MEM_ROOT' imported from
/home/sesse/nmu/mysql-server/sql/sql_class.h:44:
/home/sesse/nmu/mysql-server/include/my_alloc.h:373:13: warning: inline
function 'destroy' is not defined [-Wundefined-inline]
inline void destroy(T *ptr) {
^
/home/sesse/nmu/mysql-server/sql/sql_list.h:212:5: note: used here
destroy(*prev);
^
However, it's certainly defined; it's defined right there where the compiler
puts the diagnostic! Is this a bug or just a very confusing warning? (It
doesn't happen without modules.) If I remove the inline keyword, it compiles
but then later gives this:
In file included from /home/sesse/nmu/mysql-server/sql/error_handler.h:32:
/home/sesse/nmu/mysql-server/sql/sql_error.h:254:3: error: 'ErrConvString' has
different definitions in different modules; first difference is defined here
found constructor with 1st parameter of type 'const MYSQL_TIME *'
ErrConvString(const MYSQL_TIME *ltime, uint dec);
^~~~
/home/sesse/nmu/mysql-server/sql/sql_error.h:254:3: note: but in 'thd' found
constructor with 1st parameter of type 'const MYSQL_TIME *'
ErrConvString(const MYSQL_TIME *ltime, uint dec);
^~~~
These declarations look identical to me; they're even from the same line in the
same file. The only thing I can imagine is that MYSQL_TIME has a different
declaration, but if so, the error really needs to show the difference(s)
between the two more specifically. (I've seen similar issues with GCC and LTO,
where different compilation units specified subtly different definitions of a
struct and caused ODR warnings, and they eventually made these warnings a lot
clearer.) Again, this is either a compiler bug or an unhelpful diagnostic.
Similarly:
In file included from ../sql/create_field.h:32:
../sql/sql_list.h:479:6: error: 'List' has different definitions in different
modules; first difference is defined here found method 'operator[]' with body
T *operator[](uint index) const {
~~~^~
../sql/sql_list.h:479:6: note: but in 'thd' found method 'operator[]' with
different body
T *operator[](uint index) const {
~~~^~
Again, the body is exactly the same as far as I can tell. I thought adding
“config_macros DBUG_OFF, NDEBUG” to all the modules in the module map would
make the error go away, but evidently, it doesn't; there's _something_ about
the DBUG_ASSERT macro, but it's not clear what. I guess the warning in itself
could still be a lot more friendly; in particular, it could list differences in
the active preprocessor flags in the two contexts when giving such an error.
I don't know if this is zero, one, two or three bugs; feel free to split. :-)
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41859] New: Match GNU objdump behaviour for --disassemble-all
https://bugs.llvm.org/show_bug.cgi?id=41859 Bug ID: 41859 Summary: Match GNU objdump behaviour for --disassemble-all Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-objdump Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: llvm-bugs@lists.llvm.org llvm-objdump --disassemble-all disassembles every section in an ELF object, whereas GNU only dumps some sections. In particular, it doesn't dump the string table(s) or symbol table. There may be other sections that it also doesn't dump, but I haven't looked. On the principle of output compatibility, we should probably limit things here too, but I'm not against keeping things as they are (despite there being no sense in disassembling such sections). -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41860] New: Merge r360512 into the 8.0 branch : [X86] Don't emit MOVNTDQA loads from fast-isel without SSE4.1.
https://bugs.llvm.org/show_bug.cgi?id=41860 Bug ID: 41860 Summary: Merge r360512 into the 8.0 branch : [X86] Don't emit MOVNTDQA loads from fast-isel without SSE4.1. Product: new-bugs Version: 8.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: tstel...@redhat.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Blocks: 41221 Is it OK to merge the following revision(s) to the 8.0 branch? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=41221 [Bug 41221] [meta] 8.0.1 Release Blockers -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13148 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-strength_reduce: ASSERT: (!F.ScaledReg || !F.ScaledReg->isZero()) && "Zero allocated in a scaled register
Updates: Labels: Deadline-Approaching Comment #2 on issue 13148 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-strength_reduce: ASSERT: (!F.ScaledReg | | !F.ScaledReg->isZero()) && "Zero allocated in a scaled register https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13148#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13161 in oss-fuzz: llvm/llvm-isel-fuzzer--wasm32-O2: ASSERT: PromotedOp.getNode() && "Operand wasn't promoted?"
Updates: Labels: Deadline-Approaching Comment #2 on issue 13161 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--wasm32-O2: ASSERT: PromotedOp.getNode() && "Operand wasn't promoted?" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13161#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13195 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-strength_reduce: Floating-point-exception in LSRInstance::GenerateAllReuseFormulae
Updates: Labels: Deadline-Approaching Comment #2 on issue 13195 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-strength_reduce: Floating-point-exception in LSRInstance::GenerateAllReuseFormulae https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13195#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13174 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: isa(Val) && "cast() argument of incompatible type!"
Updates: Labels: Deadline-Approaching Comment #2 on issue 13174 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: isa(Val) && "cast() argument of incompatible type!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13174#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41861] New: Compilation errors when including iostream in OpenMP NVPTX offloading code
https://bugs.llvm.org/show_bug.cgi?id=41861
Bug ID: 41861
Summary: Compilation errors when including iostream in OpenMP
NVPTX offloading code
Product: OpenMP
Version: unspecified
Hardware: Other
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: p.atkin...@bristol.ac.uk
CC: llvm-bugs@lists.llvm.org
The following code will fail to compile with Clang configured to use OpenMP
NVPTX offloading.
#include
#include
int main()
{
#pragma omp target
{
printf("foo\n");
}
}
Compiler output:
~ $ clang++ test.cpp -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda
-Xopenmp-target -march=sm_60
In file included from test.cpp:2:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/iostream:39:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/ostream:38:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/ios:42:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/ios_base.h:39:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/ext/atomicity.h:35:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/x86_64-redhat-linux/bits/gthr.h:148:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/x86_64-redhat-linux/bits/gthr-default.h:35:
In file included from /usr/include/pthread.h:24:
/usr/include/time.h:189:16: error: functions that differ only in their return
type cannot be overloaded
extern clock_t clock (void) __THROW;
~~~ ^
/lustre/home/br-patkinson/modules/x86_64/llvm/install/lib/clang/9.0.0/include/__clang_cuda_device_functions.h:1496:16:
note: previous definition is here
__DEVICE__ int clock() { return __nvvm_read_ptx_sreg_clock(); }
~~~ ^
In file included from test.cpp:2:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/iostream:39:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/ostream:38:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/ios:42:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/ios_base.h:41:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/locale_classes.h:40:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/string:52:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/basic_string.h:2815:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/ext/string_conversions.h:41:
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/cstdlib:166:3:
error: declaration conflicts with target of using declaration already in scope
abs(long __i) { return __builtin_labs(__i); }
^
/lustre/home/br-patkinson/modules/x86_64/llvm/install/lib/clang/9.0.0/include/__clang_cuda_cmath.h:40:17:
note: target of using declaration
__DEVICE__ long abs(long __n) { return ::labs(__n); }
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/cstdlib:122:11:
note: using declaration
using ::abs;
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/cstdlib:174:3:
error: declaration conflicts with target of using declaration already in scope
abs(long long __x) { return __builtin_llabs (__x); }
^
/lustre/home/br-patkinson/modules/x86_64/llvm/install/lib/clang/9.0.0/include/__clang_cuda_cmath.h:39:22:
note: target of using declaration
__DEVICE__ long long abs(long long __n) { return ::llabs(__n); }
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/cstdlib:122:11:
note: using declaration
using ::abs;
^
3 errors generated.
It seems there's a declaration conflict between the C standard library headers
and the '__clang_cuda' headers.
When '#include ' is removed from the above example, the code compiles
and works fine.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40542] unsupported flag -n
https://bugs.llvm.org/show_bug.cgi?id=40542 Peter Smith changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||360593 --- Comment #16 from Peter Smith --- committed https://reviews.llvm.org/D61688 as r360593. Resolving for now, will reopen if there are any further changes required. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 14731 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in GetFullTypeForDeclarator
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2019-05-13 Type: Bug New issue 14731 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in GetFullTypeForDeclarator https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14731 Detailed report: https://oss-fuzz.com/testcase?key=5702736739303424 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffeec54be68 Crash State: GetFullTypeForDeclarator clang::Sema::GetTypeForDeclarator clang::Sema::ActOnBlockArguments Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201905090310:201905100308 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5702736739303424 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32433] [X86] Failure to use HADDPS for partial register result
https://bugs.llvm.org/show_bug.cgi?id=32433 Simon Pilgrim changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Fixed By Commit(s)|rL353923|rL353923,rL360594,rL360596 --- Comment #10 from Simon Pilgrim --- Resolving, we were able to deal with this in the backend by relaxing the hasOneUse limits in lowerAddSubToHorizontalOp -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41862] New: llvm-objdump should emit an error if --start-address and --stop-address specify the same value
https://bugs.llvm.org/show_bug.cgi?id=41862 Bug ID: 41862 Summary: llvm-objdump should emit an error if --start-address and --stop-address specify the same value Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-objdump Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: llvm-bugs@lists.llvm.org GNU objdump emits an error if the value of --start-address is greater than or equal to that of --stop-address. llvm-objdump only does it if the value is strictly greater than. Having an equal value makes no sense, since the specified range would be empty. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41528] llvm-dwarfdump --statistics does not handle .dwo/.dwp files
https://bugs.llvm.org/show_bug.cgi?id=41528 Caroline Tice changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Caroline Tice --- Fixed in D61755. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38161] Fixed-Point works poorly with octal/integer literals.
https://bugs.llvm.org/show_bug.cgi?id=38161 Leonard Chan 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41863] New: [C++17] std:variant fails with libstdc++ from gcc-9.1.0
https://bugs.llvm.org/show_bug.cgi?id=41863
Bug ID: 41863
Summary: [C++17] std:variant fails with libstdc++ from
gcc-9.1.0
Product: clang
Version: 8.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++'17
Assignee: unassignedclangb...@nondot.org
Reporter: or...@riseup.net
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Created attachment 21944
--> https://bugs.llvm.org/attachment.cgi?id=21944&action=edit
variant demo which reproduces the problem
On Slackware64-current gcc was updated from 8.3.0 to 9.1.0 and I found that
clang++ which uses libstdc++ now fails to build C++17 projects which use
'#include '. The issue does not occur with libc++.
I have attached a small demo which I have found online which can reproduce this
issue, but I first encountered the issue in the current master for dolphin-emu.
https://github.com/dolphin-emu/dolphin/commit/1d5dd5db914d94f3f612c13c6c5e1d5e711b49b5
With the example it can be reproduced:
clang++ -std=c++17 variant.cpp -o variant -v
While both of these work:
g++ -std=c++17 variant.cpp -o variant -v
clang++ -std=c++17 -stdlib=libc++ variant.cpp -o variant -v
In Slackware current llvm is compiled as a single mostly complete package with
these cmake arguments.
cd build
cmake \
-DCMAKE_C_COMPILER="clang" \
-DCMAKE_CXX_COMPILER="clang++" \
-DCMAKE_C_FLAGS:STRING="$SLKCFLAGS" \
-DCMAKE_CXX_FLAGS:STRING="$SLKCFLAGS" \
-DCMAKE_INSTALL_PREFIX=/usr \
-DLLVM_LIBDIR_SUFFIX=${LIBDIRSUFFIX} \
-DCMAKE_BUILD_TYPE=Release \
-DBUILD_SHARED_LIBS=OFF \
-DCLANG_BUILD_SHARED_LIBS=ON \
-DLLVM_BUILD_LLVM_DYLIB=ON \
-DLLVM_LINK_LLVM_DYLIB=ON \
-DLLVM_USE_LINKER=gold \
-DLLVM_ENABLE_RTTI=ON \
-DLLVM_ENABLE_FFI=ON \
-DLLVM_ENABLE_ASSERTIONS=OFF \
-DLLVM_USE_OPROFILE=ON \
-DLLVM_INSTALL_UTILS=ON \
-DLLVM_BINUTILS_INCDIR=/usr/include \
-DCLANG_RESOURCE_DIR="../lib${LIBDIRSUFFIX}/clang/${VERSION}" \
.. || exit 1
For further details please see this link.
https://mirrors.slackware.com/slackware/slackware64-current/source/d/llvm/
I will add further attachments with details.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41864] New: Register Coalescing: missed optimization opportunity
https://bugs.llvm.org/show_bug.cgi?id=41864 Bug ID: 41864 Summary: Register Coalescing: missed optimization opportunity Product: libraries Version: 8.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: mgu...@gmail.com CC: llvm-bugs@lists.llvm.org In the course of our work, we came across an example which (as we believe) proves that it is profitable to add a heuristics to decide the order in which RegisterCoalescer looks at copies in a basic block. We have the following pattern generated from an innermost loop with one basic block body (unfortunately, we cannot post the exact IR): # *** IR Dump After Live Variable Analysis ***: BB#24: derived from LLVM BB %for.body181 %vreg381 = PHI %vreg361, , %vreg378, ; %vreg382 = PHI %vreg361, , %vreg378, ; ... STORE %vreg381, %vreg385, -2; mem:ST2[%269](noalias=!11); ... %vreg373 = INST %vreg381, %vreg387, %vreg382, 1; ... %vreg378 = INST %vreg373, %vreg370, %vreg382, 0; ... CONDITIONAL_BRANCH ; # *** IR Dump After Two-Address instruction pass ***: BB#24: derived from LLVM BB %for.body181 Predecessors according to CFG: BB#23 BB#24 %vreg382 = COPY %vreg639; %vreg381 = COPY %vreg639; STORE %vreg381, %vreg385, -2; ... %vreg373 = COPY %vreg381; %vreg373 = INST %vreg373, %vreg387, %vreg382, 1; ... %vreg378 = COPY %vreg373; %vreg378 = INST %vreg378, %vreg370, %vreg382, 0; ... %vreg639 = COPY %vreg378; ... CONDITIONAL_BRANCH; The RegisterCoalescer works through the basic block from the first copy to last as follows: Remove %vreg382 = COPY %vreg639: %vreg381 = COPY %vreg639; %vreg369 = COPY %vreg639; ... %vreg373 = COPY %vreg381; %vreg373 = INSTR %vreg373, %vreg644, %vreg639, 1; ... %vreg378 = COPY %vreg373; %vreg378 = INSTR %vreg378, %vreg370, %vreg639, 0; ... %vreg639 = COPY %vreg378; ... CONDITIONAL_BRANCH; Remove %vreg381 = COPY %vreg639: BB#24: derived from LLVM BB %for.body181 Predecessors according to CFG: BB#23 BB#24 STORE %vreg639, %vreg642, -2; ... %vreg373 = COPY %vreg639; %vreg373 = INST %vreg373, %vreg644, %vreg373, 1; ... %vreg378 = COPY %vreg373; %vreg378 = INST %vreg378, %vreg370, %vreg639, 0; ... %vreg639 = COPY %vreg378; ... COND_BRANCH ; Remove %vreg373 = COPY %vreg639: Interference! Remove %vreg378 = COPY %vreg373: BB#24: derived from LLVM BB %for.body181 STORE %vreg639, %vreg642, -2; mem:ST2[%269](noalias=!11); ... %vreg378 = COPY %vreg639; %vreg378 = INSTR %vreg378, %vreg644, %vreg378, 1; ... %vreg378 = INSTR %vreg378, %vreg370, %vreg639, 0; ... %vreg639 = COPY %vreg378; ... CONDITIONAL_BRANCH Remove %vreg639 = COPY %vreg378: Interference! So we end up with the following assembly code: copy from v0 to v4 ... copy from v4 to v0 The last copy can be removed, as we have verified. We believe this problem can be fixed in RegisterCoalescer. We hacked the RegisterCoalescer so that it works through the copies in the problematic basic block in the reversed order of the original (from last copy to the first). With the reversed order the redundant copy disappears and correct assembly is generated. This lets us conclude that there should be some heuristic for ordering input copies or perhaps delaying the decision of coalescing. We would like to hear community opinion on how to approach this problem. In particular, should this kind of optimization be inside RegisterCoalescer? If yes, has any work been done in this direction? Ideally, we want to find a proper solution and contribute it to the llvm project. Thank you and looking forward to your suggestions, Mikhail Gudim -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41841] [WebAssembly] Assertion failure with fast-isel and cross-bb use of i128
https://bugs.llvm.org/show_bug.cgi?id=41841 Nikita Popov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||360616 --- Comment #3 from Nikita Popov --- Fixed by https://reviews.llvm.org/rL360616. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41865] New: [ms] #pragma bss_seg fails to apply to globals with user provided constructors
https://bugs.llvm.org/show_bug.cgi?id=41865
Bug ID: 41865
Summary: [ms] #pragma bss_seg fails to apply to globals with
user provided constructors
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: r...@google.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Consider:
$ cat t.cpp
struct Foo {
int x, y;
Foo() : x(1), y(2) {}
};
#pragma bss_seg("my_bss")
Foo gv;
$ cl -c t.cpp && dumpbin t.obj | grep bss
Microsoft (R) C/C++ Optimizing Compiler Version 19.20.27508.1 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
t.cpp
8 my_bss
$ clang-cl -c t.cpp && dumpbin t.obj | grep bss
8 .bss
Clang thinks `gv` has an initializer, so it would apply the most recently
active data_seg pragma, instead of bss_seg. The code to control this is here:
https://github.com/llvm/llvm-project/blob/master/clang/lib/Sema/SemaDecl.cpp#L11926
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41866] New: Building with -D LLVM_ENABLE_PROJECTS='clang; lldb' on macOS errors for missing dependency target "cxx"
https://bugs.llvm.org/show_bug.cgi?id=41866 Bug ID: 41866 Summary: Building with -D LLVM_ENABLE_PROJECTS='clang;lldb' on macOS errors for missing dependency target "cxx" Product: Build scripts Version: trunk Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: cmake Assignee: jry...@gmail.com Reporter: jry...@gmail.com CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org, stefan.graen...@gmail.com I typically try to limit the part of LLVM I build a config such as ``` -D LLVM_ENABLE_PROJECTS='clang;lldb' ``` but this particular combo currently fails on macOS with many errors like: CMake Error at cmake/modules/AddLLVM.cmake:1391 (add_dependencies): The dependency target "cxx" of target "check-all" does not exist. Call Stack (most recent call first): CMakeLists.txt:994 (add_lit_target) CMake Error at /Users/jryans/Projects/llvm-project/lldb/CMakeLists.txt:137 (add_dependencies): The dependency target "cxx" of target "lldb-test-deps" does not exist. CMake Error at /Users/jryans/Projects/llvm-project/lldb/test/CMakeLists.txt:13 (add_dependencies): The dependency target "cxx" of target "check-lldb-single" does not exist. Call Stack (most recent call first): /Users/jryans/Projects/llvm-project/lldb/test/CMakeLists.txt:108 (add_python_test_target) [... many more lines about "cxx" ...] The root cause here is that LLDB requires libcxx on macOS, but the errors above don't make that very clear, at least for those new to LLVM. I think this could be clarified with two changes: 1. Check whether `libcxx` is enabled as a project, and output a specific error about this if not 2. Update the LLDB docs to suggest a valid value of `LLVM_ENABLE_PROJECTS` -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41867] New: "note: member call on member 'endpoint' of union with active member 'interface' is not allowed in a constant expression" note should include the member name
https://bugs.llvm.org/show_bug.cgi?id=41867
Bug ID: 41867
Summary: "note: member call on member 'endpoint' of union with
active member 'interface' is not allowed in a constant
expression" note should include the member name
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: pho...@chromium.org
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
With the tip-of-tree Clang, this is failing to compile because the
-Winvalid-constexpr has gotten more strict after r360499
(https://github.com/llvm/llvm-project/commit/d05df0ef4362855405ae1df76572909fb0ff55b2):
usb-mass-storage.cpp:30:37: error: constexpr function never produces a
constant expression [-Winvalid-constexpr]
static constexpr usb_descriptor Create(usb_endpoint_descriptor_t
descriptor) {
^
usb-mass-storage.cpp:32:25: note: member call on member 'endpoint' of union
with active member 'interface' is not allowed in a constant expression
retval.endpoint = descriptor;
^
1 error generated.
It would be useful if the note also included the name of the member which is
being called (in this case it's operator= but that's not completely obvious
from the message).
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41868] New: Rejects valid on deprecated attributes with a non-narrow string literal
https://bugs.llvm.org/show_bug.cgi?id=41868 Bug ID: 41868 Summary: Rejects valid on deprecated attributes with a non-narrow string literal Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: C++11 Assignee: unassignedclangb...@nondot.org Reporter: aa...@aaronballman.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk The following code is valid in C2x and C++11, but is currently rejected by Clang: [[deprecated(L"We can't have nice things")]] int a; The problem is that Sema::checkStringLiteralArgumentAttr() requires the string to be ASCII so that it can call StringLiteral::getString() to get a StringRef to the contents. We could use StringLiteral::outputString() to stream it to a string buffer, but there are other parts of the APIs that expect a StringRef and not a std::string, so ClangAttrEmitter would need to be taught about this for VariadicStringArgument arguments. I think we might want to encode this as part of the attribute argument declaration itself. Some attributes may require any form of string literal (like deprecated does), while others may require ASCII (like section 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41817] The linkage changes in r359260 break MIDL code
https://bugs.llvm.org/show_bug.cgi?id=41817 Richard Smith changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Richard Smith --- Should be fixed in r360637. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36120] IR PGO Instr generation error for comdat + MSVC triple
https://bugs.llvm.org/show_bug.cgi?id=36120 Robbert Haarman changed: What|Removed |Added Fixed By Commit(s)||353547 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Robbert Haarman --- This was fixed by r353547. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41673] /DISCARD/ section should not be output
https://bugs.llvm.org/show_bug.cgi?id=41673 Fangrui Song changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||i...@maskray.me --- Comment #1 from Fangrui Song --- D61186 has been committed -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41653] lld produces invalid binary
https://bugs.llvm.org/show_bug.cgi?id=41653 Fangrui Song changed: What|Removed |Added CC||i...@maskray.me Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Fangrui Song --- Fixed by D61197/r359554 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
