Re: [cfe-users] Why does this testcase fail in clang-60?
I believe the default standard did change to c++14. How did you compile?
Could you make a case in godbolt.org?
Am 27.03.2018 um 04:52 schrieb Yuri via cfe-users:
> This testcase:
>
> # include
> # include
>
> # define _I ((complex_t)(1i))
> typedef std::complex complex_t;
>
> complex_t f(const double omega) {
> complex_t p = cos (omega) + _I * sin (omega);
> return p;
> }
>
> works in clang40 and clang50, but fails in clang60:
>
> c.c:9:32: error: implicit conversion from '_Complex int' to 'double'
> is not permitted in C++
> complex_t p = cos (omega) + _I * sin (omega);
> ^~
> c.c:5:26: note: expanded from macro '_I'
> # define _I ((complex_t)(1i))
> ~ ^~
> 1 error generated.
>
>
> Yuri
>
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] C++ Scoring Tool
+cfe-dev The people familiar with clang-format are more likely active there :) Am 17.04.2018 um 09:40 schrieb Daniel via cfe-users: > > Hello, > > For the senior project in my undergraduate studies, my team and I are > developing a tool that will evaluate the format and code conventions > of a c++ program, outputting a score and displaying useful messages, > very much like pylint for python. > > The idea is kind of like clang-format except no alterations to the > code should be made. The tool would be used as a teaching aid and > automatic grader. To handle the beautiful diversity of c++, it > shouldn't constrain the author to any particular style (although it > should be able to do that too). For example: open curly braces on same > line as function declaration compared to having them on a new line. In > this case, the tool could check for consistency only. As long as the > entire file has the same format, you will get a perfect score. If, > however, there are 10 places of braces on same line and 9 on newline, > there will be a penalty to the score, larger than if 18 on same line > and 1 on newline. The idea is to enforce consistency without getting > in the way of authors preferred style. This should give professors a > robust tool to teach c++. > > I was hoping the clang community could help me understand the inner > workings of clang a little bit better. Right now, my hangup is trying > to get format data to work in conjunction with clangs AST. What I'm > trying to do is get back the whitespace, comment, and bracket > information that is loss during AST buildup. Suppose I want to check > that all operators have consistent spacing format, something like "(2 > * 2)" verses "(2*2)" verses "(2* 2)". The AST will be used to get the > semantics of that particular operator so as to not get it confused > with the array pointer operator, but I need to count the operator > whitespace prefix and postfix. The same concept will be applied to > statement whitespace circumfixs. If done right, I should be able to > refer to all operators the same way no matter the complexity of the > expression. Something like "(x - 4) / 3 * (2 +1)" would show an > inconsistency in the end part "(2 +1)" because of a missing space. > > My first thought was to use the SourceManager locational information > to point back to the source code, then process and identify the > whitespace from there; However, this seems wildly inefficient and > inelegant. My second thought was to somehow get clang to keep the > whitespace information and add it to the AST, but I believe there are > inherent difficulties with that. > > My biggest problem is lack of expertise within clangs source code. > Does anybody have any ideas on how I can get clang to give me the > information I need to support the above functionality? > > Thanks for any interest. I hope this is an appropriate mailing list to > post my question. > > Daniel. > > > > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] building clang for target off
+cfe-dev Am 30.04.2018 um 06:41 schrieb Jost, Gabriele (ARC-TNC)[CSRA, LLC] via cfe-users: > Hello, > I am trying to build clang with GPU support, in particular with > support for OpenMP target offload. > I want to build for a Xeon+Nvidia GPU. > I did this: > git clone https://github.com/clang-ykt/openmp.git > and built the OpenMP libomp.so > Then I try this: > git clone https://github.com/clang-ykt/libomptarget.git > but now I am ask for a user name, guest does not seem to work: > > git clone https://github.com/clang-ykt/libomptarget.git > Cloning into 'libomptarget'... > Username for 'https://github.com': guest > Password for 'https://gu...@github.com': > > Is this not a public branch of the repo? > > I am interested to hear other peoples experience with this. > Thanks in advance, > Gabriele > > > > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] Fwd: 回复： [cfe-dev] building clang for target off
Forwarding, because the guy didnt include the mailing lists in the response. Weitergeleitete Nachricht Betreff:?? [cfe-dev] [cfe-users] building clang for target off Datum: Wed, 2 May 2018 20:32:26 +0800 Von: <772847...@qq.com> An: cfe-dev you may need git clone g...@github.com:clang-ykt/openmp.git. --?0?2?0?2-- *??:*?0?2"cfe-dev"; *:*?0?22018??5??2??(??) 7:47 *??:*?0?2"cfe-users";"cfe-...@lists.llvm.org"; *:*?0?2Re: [cfe-dev] [cfe-users] building clang for target off +cfe-dev Am 30.04.2018 um 06:41 schrieb Jost, Gabriele (ARC-TNC)[CSRA, LLC] via cfe-users: > Hello, > I am trying to build clang with GPU support, in particular with > support for OpenMP target offload. > I want to build for a Xeon+Nvidia GPU. > I did this: > git clone?0?2https://github.com/clang-ykt/openmp.git > and built the OpenMP libomp.so > Then I try this: > git clone?0?2https://github.com/clang-ykt/libomptarget.git > but now I am ask for a user name, guest does not seem to work: > > git clone https://github.com/clang-ykt/libomptarget.git > Cloning into 'libomptarget'... > Username for 'https://github.com': guest > Password for 'https://gu...@github.com':?0?2 > > Is this not a public branch of the repo??0?2 > > I am interested to hear other peoples experience with this. > Thanks in advance, > Gabriele > > > > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] add method to a existing class and save to source file
This is a question relating clang-refactor i guess. Maybe ask on cfe-dev
since its development specific.
Am 05.05.2018 um 02:22 schrieb ? ?? via cfe-users:
> Dear Clang users:
> I have a class named classA in a.h and a.cpp file. it have
> some methods, I want to add a new method definition to a.h and add new
> method body after last method use clang . How to do it ?
> I know the RecursiveASTVisitor::VisitCXXRecordDecl(...) can
> visit CXXRecordDecl and CXXMethodDecl , Rewriter be used to write
> code . but how to create new method definition and body to a.h and a.cpp?
>
> //a.h file
> classA {
> protected:
> int filed;
> public:
> void method1();
> void method2();
> //insert a new method
> }
>
> //a.cpp file
>
> void classA::method1()
> {
> ..
> }
>
> void classA::method2()
> {
> ...
> }
>
> // inset new method body
>
>
> Yours truly
>
> Robert
>
>
> lic...@hotmail.com
>
>
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] clang-tidy selects toolchain?
I dont think so. What do you want to achieve? Clang-tidy will just build the AST from Code and do its analysis on it. I do not see a reason for a different toolchain. Am 19.06.2018 um 11:30 schrieb kimmyzhang(张亚霏) via cfe-users: > > As is known, clang can select another toolchain through: > > clang --gcc-toolchain=/opt/gcc-7.3.0 -v > > clang++ --gcc-toolchain=/opt/gcc-7.3.0 –v > > > > Is there an equivalent option for clang-tidy? > > > > Thanks. > > > > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Question casually profiling Clang vs GCC
Hi, very interesting. My experience with normal compilation is, that clang is faster. Could it be, that there are some precompiled headers or similar present on the system, that GCC utilizes? Best Regards, Jonas Am 01.08.2018 um 13:23 schrieb Florian Berger via cfe-users: > Hi, > > I am a long term Gentoo Linux user, which, as a source-based meta > distribution, involves frequent (re-)compilation of a lot of packages > from scratch. > > Curious how Clang would perform against the system's gcc-7.3.0-r3 in > terms of compilation speed, I installed clang-5.0.2 (latest stable on > Gentoo) and compiled a handful of random packages: Python, unzip, > libopus, exim, nginx, postresql. Setting was -O2, LTO was disabled. > > Surprisingly, Clang consistently took considerably longer to compile > these packages than GCC, ranging from +28% (unzip) to +54% (postgresql), > with a median increase of +40% in compile time. That contradicts the > notion that Clang would be on par or quicker than GCC in terms of > compilation time. > > Is that expected behaviour? May I have been missing some vital switch or > setup? > > Any hints appreciated, and I'll gladly provide more information. > > Kind regards, > > Florian > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Backend error
Could you please report this as a bug at https://bugs.llvm.org/describecomponents.cgi?product=clang Best, Jonas Am 21.08.2018 um 08:01 schrieb Itaru Kitayama via cfe-users: > Hi, > I am seeing a application build error shown below: > > [ 7%] Building CXX object sli/CMakeFiles/sli_lib.dir/filesystem.cc.o > fatal error: error in backend: Cannot select: t42: i16,ch = > AtomicLoad<(volatile load acquire 1 from `i8 > addrspace(1)* bitcast (i64 addrspace(1)* > > @_ZGVZNK16FilesystemModule14TmpNamFunction7executeEP14SLIInterpreterE4seed > to i8 addrspace(1)*)`, align 8, > addrspace 1)> t7:1, t46 > t46: i64 = NVPTXISD::Wrapper TargetGlobalAddress:i64 addrspace(1)* > @_ZGVZNK16FilesystemModule14TmpNamFunction7executeEP14SLIInterpreterE4seed> > 0 > t45: i64 = TargetGlobalAddress @_ZGVZNK16FilesystemModule14TmpNamFunction7executeEP14SLIInterpreterE4seed> > 0 > In function: > _ZNK16FilesystemModule14TmpNamFunction7executeEP14SLIInterpreter > clang-8: error: clang frontend command failed with exit code 70 (use > -v to see invocation) > clang version 8.0.0 (https://github.com/llvm-mirror/clang > e20516350f5e2062f0b5f49efb56acd94c83e5e4) > (https://github.com/llvm-mirror/llvm > c04ae04bb3ce0d715190819fa3f5c001c471d969) > Target: powerpc64le-unknown-linux-gnu > Thread model: posix > InstalledDir: /gpfs/work/pcp0/pcp0151/opt/llvm+clang-upstream/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). > make[2]: *** [sli/CMakeFiles/sli_lib.dir/filesystem.cc.o] Error 70 > make[1]: *** [sli/CMakeFiles/sli_lib.dir/all] Error 2 > make: *** [all] Error 2 > > The LLVM/Clang toolchain I'm using is the trunk clang-8. > > > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] False positive -Wcomma with static_cast of dependent expression
Please open a bug report instead.
Best Jonas
Am 19.10.2018 um 00:39 schrieb Mat Sutcliffe via cfe-users:
> Hello list,
>
> The following code generates one false positive of the -Wcomma
> warning: (tested with clang trunk via Matt Godbolt's Compiler
> Explorer)
>
> template
> void foo()
> {
> (void)42, 0;// ok
> static_cast(42), 0; // ok
>
> (void)T{}, 0; // ok
> static_cast(T{}), 0; // false positive
> }
>
> The warning ignores comma expressions where the LHS is a CastExpr with
> a CastKind of CK_ToVoid, but the expression static_cast(T{}) has
> a CastKind of CK_Dependent (confirmed with Compiler Explorer's AST
> view).
>
> I came across this when trying to do the "expander trick" without a
> fold expression or C-style cast, as in
> https://stackoverflow.com/a/30563282/1639256
>
> Thanks
> Mat
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] build errors with MinGW-W64 GCC-8.1.0 on Windows
Hi Maarten, I am not a windows user and never build with mingw in my life. :) Did you try out building a release-version of LLVM first? Sometimes there are breaking changes committed that e.g. linux-users will not notice on their system. Our Buildbots have to catch up first before the issue is then fixed (http://lab.llvm.org:8011/console) I myself did build LLVM with gcc-8 when it got released, which worked. But I didnt retry since then. Best, Jonas Am 11.11.18 um 21:53 schrieb Maarten Verhage via cfe-users: > Dear LLVM/clang people, > > I’m new to LLVM. I used TDM-GCC toolchain with gcc version 5.1.0 before but > I want to move on getting LLVM and Clang to work on my system: Windows 7 > 64bit. > > I would like to go for a MinGW64 toolchain to build the newest version of > LLVM and clang. > > I downloaded MinGW-W64 GCC-8.1.0 from here: > https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/8.1.0/threads-posix/ > > There I selected the x86_64-posix-seh version believing that would be the > best one. I got llvm and clang plus the llvm libc++ standard library as > suggested on the getting started webpage. > > I put the mingw-w64 bin folder in my PATH. > gcc -dumpversion > shown 8.1.0 > > In the llvm build folder I did: > cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release .. > that completed succesfully > > mingw32-make -f Makefile > > It builds to 57%, then a bunch of errors: > 1) > C:\dev\llvm\projects\libcxx\src\support\win32\thread_win32.cpp:156:8: error: > 'InitOnceExecuteOnce' was not declared in this scope > 2) > C:\dev\llvm\projects\libcxx\src\support\win32\thread_win32.cpp:163:6: error: > redefinition of 'bool > std::__1::__libcpp_thread_id_equal(std::__1::__libcpp_thread_id, > std::__1::__libcpp_thread_id)' > 3) And a couple of more errors all in thread_win32.cpp. > > So I think it would have been better to select the Mingw-w64 > x86_64-win32-seh or even x86_64-win32-sjlj version instead? > > Is a recent Mingw-w64 toolchain version like 8.1.0 a good one to build > llvm/clang? Or would an older one be more stable? > > Thanks anyway for any suggestions. > Best regards, > Maarten Verhage > > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] My compiler crashes .... but the online godbolt one doesn't ?!
The snippet you show is already quite minimal, so its ok to file another
bug specifically for that one.
Am 10.12.18 um 19:17 schrieb David Blaikie via cfe-users:
> Possible that the online one isn't built with assertions enabled (you
> could test this with other known crashers to see if they reproduce on
> godbolt with assertion crash dumps or only with raw segfaults)? If
> that's the case,t hen it's possible that the codepath that should
> assert continues on and perhaps either has unexpected or even
> undefined behavior but not a crash.
>
> On Sat, Dec 8, 2018 at 3:08 PM Andy Gibbs via cfe-users
> mailto:cfe-users@lists.llvm.org>> wrote:
>
> Hi,
>
> Crazy question, but would someone kind be able to help me a little
> here. I have
> a clang 4.0 installation on my linux laptop, which crashes when
> compiling this
> code fragment:
>
> template
> constexpr auto fn1() { return X; }
>
> template
> auto fn2()
> {
> return ([]() {
> static constexpr auto value = 12;
> return fn1();
> })();
> }
>
> auto test()
> {
> return fn2();
> }
>
> However, doing the same on the godbolt clang 4.0.0 compiler
> doesn't crash. What
> I can't work out is why!?
>
> The is the command I run on my machine (using a clean checkout
> from the clang
> svn repository) and the output given (the problem seems to be a
> non-instantiated
> VarDecl in "LocalInstantiationScope::findInstantiationOf()" if you
> add debug
> information to the compiler code at this point):
>
>
> $ ~/Toolchains/clang-4.0/bin/clang++ -std=c++1z -O2 -S -o -
> test.cpp -v
>
> clang version 4.0.0 (branches/release_40)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> InstalledDir: /home/user/Toolchains/clang-4.0/bin
> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.3.0
> Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.3.0
> Candidate multilib: .;@m64
> Selected multilib: .;@m64
> "/home/user/Toolchains/clang-4.0/bin/clang-4.0" -cc1 -triple
> x86_64-unknown-linux-gnu -S -disable-free -main-file-name test.cpp
> -mrelocation-model static -mthread-model posix -fmath-errno
> -masm-verbose
> -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu
> x86-64
> -momit-leaf-frame-pointer -v -dwarf-column-info -debugger-tuning=gdb
> -coverage-notes-file /home/user/test/-.gcno -resource-dir
> /home/user/Toolchains/clang-4.0/bin/../lib/clang/4.0.0
> -internal-isystem
> /usr/lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0
> -internal-isystem
>
> /usr/lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/x86_64-linux-gnu/c++/6.3.0
> -internal-isystem
>
> /usr/lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/x86_64-linux-gnu/c++/6.3.0
> -internal-isystem
> /usr/lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/backward
>
> -internal-isystem /usr/local/include -internal-isystem
> /home/user/Toolchains/clang-4.0/bin/../lib/clang/4.0.0/include
> -internal-externc-isystem /usr/include/x86_64-linux-gnu
> -internal-externc-isystem /include -internal-externc-isystem
> /usr/include -O2
> -std=c++1z -fdeprecated-macro -fdebug-compilation-dir /home/user/test
> -ferror-limit 19 -fmessage-length 92 -fobjc-runtime=gcc
> -fcxx-exceptions
> -fexceptions -fdiagnostics-show-option -fcolor-diagnostics
> -vectorize-loops
> -vectorize-slp -o - -x c++ test.cpp
> clang -cc1 version 4.0.0 based upon LLVM 4.0.0 default target
> x86_64-unknown-linux-gnu
> ignoring nonexistent directory "/include"
> ignoring duplicate directory
>
> "/usr/lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/x86_64-linux-gnu/c++/6.3.0"
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0
>
> /usr/lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/x86_64-linux-gnu/c++/6.3.0
>
> /usr/lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/backward
> /usr/local/include
> /home/user/Toolchains/clang-4.0/bin/../lib/clang/4.0.0/include
> /usr/include/x86_64-linux-gnu
> /usr/include
> End of search list.
> clang-4.0:
> /home/user/Toolchains/clang-4.0/source/tools/clang/lib/Sema/
> SemaTemplateInstantiate.cpp:2814: llvm::PointerUnion LocalInstantiationScope::DeclArgumentPack *>
> *clang::LocalInstantiationScope::findInstantiationOf(const
> clang::Decl *):
> Assertion `isa(D) && "declaration not instantiated in
> this scope"'
> failed.
> 0 clang-4.0 0x01ac29e5
> llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
> 1 clang-4.0 0x0
Re: [cfe-users] [run-clang-tidy] new replacement overlaps with an existing replacement
Hi Mateusz,
comments inline.
Am 10.12.18 um 22:14 schrieb Mateusz Loskot via cfe-users:
> Hi,
>
> I'm running clang-tidy 7.0 (also tried 5.0) to modernise some aspects
> of Boost.GIL (https://github.com/boostorg/gil) source code.
>
> I've noticed, clang-tidy 7.0 (also 5.0) does not apply fixes for some of
> modernize-use-* checks, especially modernize-use-using.
>
> I run it this way:
>
> ```
> cd ${BOOST_ROOT}/libs/gil
> cmake -S . -B _build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON ..
> run-clang-tidy.py -p=_build -header-filter='boost\/gil\/.*'
> -checks='-*,modernize-use-using' -fix
> ```
>
> Then, I see huge number of "The new replacement overlaps with an
> existing replacement." diagnostics.
> Below, I copied an extract that hopefully is useful to figure out what
> is happening and going wrong.
>
> Basically, there are two class templates and a bunch of tag types:
>
> 1. file_stream_device
> https://github.com/boostorg/gil/blob/e0288ece9ec50534e7d02166863d6799a5932e25/include/boost/gil/io/device.hpp#L49
> 2. get_write_device with partial specialisations, `enable_if`-ed
> https://github.com/boostorg/gil/blob/e0288ece9ec50534e7d02166863d6799a5932e25/include/boost/gil/io/get_write_device.hpp#L19-L59
>
> The file_stream_device is specialised for a tag and final
> get_write_device specialisation is matched.
>
> And, clang-tidy tries to substitute this alias in get_write_device
>
> typedef detail::file_stream_device< FormatTag > type;
>
> not with
>
> using type = detail::file_stream_device< FormatTag > ;
>
> but with `using type` for each FormatTag-based specialisation
>
> ```
> New replacement:
> /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp:
> 1885:+52:"using type = detail::file_stream_device"
> Existing replacement:
> /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp:
> 1885:+52:"using type = detail::file_stream_device"
> The new replacement overlaps with an existing replacement.
> New replacement:
> /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp:
> 1885:+52:"using type = detail::file_stream_device"
> Existing replacement:
> /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp:
> 1885:+52:"using type = detail::file_stream_device"
> The new replacement overlaps with an existing replacement.
> New replacement:
> /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp:
> 1885:+52:"using type = detail::file_stream_device"
> Existing replacement:
> /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp:
> 1885:+52:"using type = detail::file_stream_device"
> The new replacement overlaps with an existing replacement.
> New replacement:
> /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp:
> 1885:+52:"using type = detail::file_stream_device"
> Existing replacement:
> /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp:
> 1885:+52:"using type = detail::file_stream_device"
> The new replacement overlaps with an existing replacement.
> New replacement:
> /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp:
> 1885:+52:"using type = detail::file_stream_device"
> Existing replacement:
> /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp:
> 1885:+52:"using type = detail::file_stream_device"
> The new replacement overlaps with an existing replacement.
> New replacement:
> /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp:
> 1885:+52:"using type = detail::file_stream_device"
> Existing replacement:
> /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp:
> 1885:+52:"using type = detail::file_stream_device"
> The new replacement overlaps with an existing replacement.
> New replacement:
> /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp:
> 1885:+52:"using type = detail::file_stream_device"
> Existing replacement:
> /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp:
> 1885:+52:"using type = detail::file_stream_device"
> The new replacement overlaps with an existing replacement.
> New replacement:
> /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp:
> 1885:+52:"using type = detail::file_stream_device"
> Existing replacement:
> /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp:
> 1885:+52:"using type = detail::file_stream_device"
> The new replacement overlaps with an existing replacement.
> New replacement:
> /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp:
> 1885:+52:"using type = detail::file_stream_device"
> Existing replacement:
> /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp:
> 1885:+52:"using type = detail::file_stream_device"
> The new replacement overlaps with an existing replacement.
> New replacement:
> /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp:
> 1885:+52:"using type = detail::file_stream_device"
> Existing replacement:
> /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_devic
[cfe-users] Fwd: floor is vectorized, but not sin, cos or exp
I am forwarding this to cfe-dev as it might this sounds like a bug and
cfe-users is not read that much.
Weitergeleitete Nachricht
Betreff:[cfe-users] floor is vectorized, but not sin, cos or exp
Datum: Tue, 11 Dec 2018 16:47:16 +0100
Von:Klaus Leppkes via cfe-users
Antwort an: Klaus Leppkes
An: cfe-users@lists.llvm.org
Hi,
according to the doc
(https://releases.llvm.org/7.0.0/docs/Vectorizers.html) floor, sin, cos
should be vectorized.
I can confirm (using the great https://gcc.godbolt.org/ tool) that using
the flags "-Ofast -mavx2 -fopenmp -ffast-math" the right avx2 opcode
(vroundps) is emited for floor (in foo), but unfortunately not for sin,
cos or exp (e.g. see sin in bar below).
GCC 8.1+ and the Intel Compiler icc 13+ insert call to vectorized
implementations (_ZGVbN4v_sinf or __svml_sinf4 ), but clang seems to
have nothing like this.
Here is my small testcode:
#include
voidfoo(float* __restrict__attribute((aligned(32))) x
, float* __restrict__attribute((aligned(32))) y) {
for(inti = 0; i < 4; ++i)
y[i] = floor(x[i]);
}
voidbar(float* __restrict__attribute((aligned(32))) x
, float* __restrict__attribute((aligned(32))) y) {
for(inti = 0; i < 4; ++i)
y[i] = sin(x[i]);
}
I have reproduced this behavior on different machines. Maybe I am doing
s.th. wrong here, but it seems like there is no vectorized
implementation for sin, cos etc. I am using h2lib for now
(http://h2lib.org/doc/d1/d89/simd__avx_8h_source.html) as a workaround,
but I expect clang to do this job.
Can anybody comment on this please?
Cheers
Klaus
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] [run-clang-tidy] new replacement overlaps with an existing replacement
Great to hear! Am 12.12.18 um 00:11 schrieb Mateusz Loskot via cfe-users: >> I suspect that is the case indeed. >> >> I have created new test in GIL which generates single .cpp file >> that includes all headers (https://github.com/boostorg/gil/pull/184): >> I generated compile_commands.json and manually removed all commands >> but the one with .cpp including all headers. >> Finally, I run clang-tidy against it, I get no warning about overlapping >> replacements and all typedef-s are replaced with correct using declaration. >> >> I think think that is the optimal workflow for the header-only Boost.GIL >> libary. >> >> Thanks for help! >> >> Best regards, ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] misc-new-delete-overloads
Hey Tom,
thank you for reporting this issue!
Tt looks like the check is confusing these overloads somehow. Looking
through the code it could be, that the second version is considered as
placement-overload which are ignored, but that is just a guess.
Are you by any chance compiling with C++17? It added versions to both
operators the check might not expect.
I created a bug-report: https://bugs.llvm.org/show_bug.cgi?id=40174
You could help with producing a minimal reproducer-file with
C++-Standard and build-configuration added that we can attach to the
bug-report. Having such a file would help a lot adressing the issue!
Best, Jonas
Am 24.12.18 um 10:13 schrieb Tom Hulton-Harrop via cfe-users:
> Hi there,
>
> Apologies if this is the wrong place to ask about this - if it is I'd
> be very grateful if you'd point me in the right direction :)
>
> I'm seeing the clang-tidy warning 'misc-new-delete-overloads' when
> using the two parameter version of class member delete, however when
> using the single parameter version the warning goes away.
>
> class Type
> {
> void* operator new(size_t) { ... }
> void operator delete(void*) { ... } // no warning
> void operator delete (void*, size_t) { ... } // warning
> };
>
> When using the second version I don't think this warning should be
> reported. Is this correct or am I missing something?
>
> I've been double checking things here:
>
> https://en.cppreference.com/w/cpp/memory/new/operator_new (Items 15, 16)
> https://en.cppreference.com/w/cpp/memory/new/operator_delete (Items
> 17, 18 and 21, 22)
>
> I'm using clang on Windows and using Clang Power Tools in Visual
> Studio to invoke clang-tidy.
>
> Any info would be greatly appreciated!
>
> Thank you for your time,
>
>
> Tom
>
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Updated documentation on cross building LLVM for Musl
A patch for the LLVM documentation or at least a link in it to your gist would be great! Am 13.02.19 um 20:07 schrieb Croepha via cfe-users: > I spent some time figuring out how to get Clang and related tools to > build against musl starting from a GNU libc system. The result is a > GNU-less (no libgcc, libstdc++, and GNU LD, AR...) toolchain. I > figured I'd share in the hopes that someone else may find it useful... > > Note: Clang and friends works as expected, but I couldn't get the > sanitizers to build against Musl, so that is the only limitation that > I am aware of... > > Full doc > here: https://gist.github.com/croepha/cdaf30638109b1a949f35aa215a7c86d > > --Dave > > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] clang 11rc1 - target aarch64 -mharden-sls warning
Hi Milan, just to be sure: Are you doing a multi-stage build? On which stage is the warning emitted? The architecture you are building on itself is ARM or are you doing cross compilation? The argument itself is a compatibility-option for GCC, which might be added after clang-11 was branched? (https://github.com/llvm/llvm-project/commit/0ee176edc8b4a6f20527e907bfd026b07a27e7ef seems to have it included though!) The generic warning message is emitted when that specified option is not utilized because it does not apply in this instance. For example, I have seen this when compiling C code with C++-specific arguments. So your specific setup would be relevant to know. Best Regards Jonas Am 01.08.20 um 13:22 schrieb Milan Buška via cfe-users: > Good day. > I am testing a compilation of clang ver. 11rc1 using the > clang-11.0.0rc1 compiler. > > CFLAGS and CXXFLAGS I have set "-march=armv8-a -mharden-sls=all -pipe" > > When compiling, I get a message: > clang-11: warning: argument unused during compilation: -mharden-sls=all > > Is this warning caused by my incorrect settings or there is an error in the > code > > Best regards > > Milan ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Matcher for templated variable
Hey Robert,
I can highely recommend `godbolt.org`, it has support for clang-query as
additional tool when you select clang as the compiler as well as AST output.
Additionally: https://clang.llvm.org/docs/LibASTMatchersReference.html
There you get all the possible matchers you can combine. You can check
out clang-tidy code for checks do something similar and get inspiration
on how to combine matchers, too!
---
Step 1:
Check the AST output and what nodes you want to retrieve.
Step 2:
Do a wide matching with normal node matchers.
Step 3:
Narrow the matches down with special additional properties that you can
filter for.
---
Match 2 is related to a `declRefExpr`. You can match on a variable and
then find all references to that variable through `declRefExpr()`. It
might be the operator-call you are interested too (or both ;)).
Match 3 is a `fieldDecl` that you need to narrow down.
Match 4 is a `memberExpr`.
You will mostly figure out what to look for once you see the AST.
If you want one matcher to find them all you need some specialized
sub-matchers. You can then combine them with `anyOf() / allOf() / unless()`.
It might help to create a small little clang-tidy check and just do your
matching there and write some warnings for each match. I think its
easier to test on real code once the matchers get more complicated or
you want to test it out on a project.
I am unsure if `clang-query` can already perform such an operation on a
project, I know that there was work on this! Maybe you can research that
first to save some work.
---
Beware of templates: every instantiation might create the AST matches
again (you will see in the AST).
It really depends on what you want to do.
If you want to create some transformations the multiple instantiations
might interfere.
If you develop on windows you must ensure that the templates are
actually instantiated or use `-fno-delayed-template-parsing`.
I hope this mostly general answer guides you into a good direction. If
not, don't hesitate to ask again! :) (But I am likely slow to answer,
sry :/)
Best Regards
Am 09.08.21 um 00:37 schrieb Robert Ankeney via cfe-users:
> I'm looking to create AST matchers for variables that are templated.
> For example, in the code:
>
> template class Class // template <(class or typename or
> int/float/etc) T>
> {
> public:
>
> void Func(T* Param) // 1) match Param
> {
> Param = nullptr; // 2) match Param
> }
>
> T* Var = nullptr; // 3) match Var
> };
>
> int main()
> {
> Class MyClass;
> float FloatVal;
> MyClass.Var = &FloatVal; // 4) match Var
> }
>
> Ideally, I'd like one matcher to find each of the 4 matches, but I
> suspect I need individual matchers for each of them. For the first
> match above I have varDecl(hasType(templateTypeParmType())), but I
> haven't had luck with clang-query in finding the other 3. Any help
> would be much appreciated!
>
> Thanks,
> Robert
>
>
>
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
