Vararg templates. GCC vs Clang
--- the forwarded message follows ---
--- Begin Message ---
Code:
#include
#include
template
void f(std::tuple )
{
std::cout << "std::tuple\n";
}
template
void f(std::tuple )
{
std::cout << "std::tuple\n";
}
int main()
{
f(std::tuple{});
}
GCC accepts this code silently. But Clang generates error:
test.cpp:18:5: error: call to 'f' is ambiguous
f(std::tuple{});
^
test.cpp:5:6: note: candidate function [with Head = int,
Tail = <>]
void f(std::tuple )
^
test.cpp:11:6: note: candidate function [with Head = int]
void f(std::tuple )
^
Which compiler is right? Isn't it abiguity in fact?
--- End Message ---
[autovect] autovect-branch reopened from latest trunk
I've reopened a new branch autovect-branch, taken off the trunk as of today. The branchpoint revision is 120362. The old branch went way out of synch with mainline so I've moved it to branches/dead/old-autovect-branch in svn repository. New autovect-branch has initialized merge tracking support for svnmerge.py tool to facilitate merges from trunk in future. -- Victor
Re: Scheduling an early complete loop unrolling pass?
Richard Guenther <[EMAIL PROTECTED]> wrote on 06.02.2007 11:19:15: > On Tue, 6 Feb 2007, Dorit Nuzman wrote: > > After sleeping on it, it actually makes a lot of sense to me to schedule > > complete loop unrolling before vectorization - I think it would either > > simplify loops (sometimes creating more opportunities for vectorization), > > or prevent vectorization of loops we probably don't want to vectorize > > anyhow, and even that - only temporarily - until we have straight-line-code > > vectorization in place. So I'm all for it. > > Ok, I'll dig out the patches I had for this and will do some SPEC > runs. As soon as I have time for this (no hurry necessary here I think). We have some benchmarks where complete unrolling of innermost loop expose an opportunity to vectorize an outer loop. Usually complete unrolling reveal some opportunities for constant propagation and dead code elimination, so, probably there is need to rerun ccp, store_cpp, dse and dce between complete unrolling and vectorizer. I would be glad to help with running of SPEC on PPC. -- Victor
Re: Fw: Cross Compiler to Native Compiler
Just use your cross-compiler to build a compiler for the target system that'll run on the target system. Then it could be good idea to use new native compiler on its hardware to rebuild gcc once again natively. Two compilers from last two steps should be identical. It's a good way to make sure your cross and native compilers are working correctly, and generating code that actually runs. Have a look at how canadian cross compiler are built, that might give you a hint. Some hacking the script for building canadian cross-compiler may help (See CrossGCC FAQ for details - http://vmlinux.org/crash/mirror/www.objsw.com/CrossGCC/). But be sure to edit specs and change cross_compile to 0 later as specs are dumped by cross-compiler. you can find some more info in this thread: http://sourceware.org/ml/crossgcc/2005-02/msg5.html -- Victor > > Cross Compiler to Native Compiler > > Hi, > > I am porting/developing GCC onto a new platform. > This platform already have a cross tool chain. > Can anybody give me a roadmap to port GCC in native > environment from scratch? or > Way to convert, Croos-Compiler to Native-Compiler? > > Thanks n Regards, > Kapil
Re: Problem with building libgfortran on PPC
I have obtained the same error on my ppc64 yellow dog linux: /bin/sh ./libtool --mode=compile /home/victork/mainline-vanila/build/./gcc/gfortran -B/home/victork/mainline-vanila/build/./gcc/ -B/home/victork/mainline-vanila/usr/ppc64-yellowdog-linux/bin/ -B/home/victork/mainline-vanila/usr/ppc64-yellowdog-linux/lib/ -isystem /home/victork/mainline-vanila/usr/ppc64-yellowdog-linux/include -isystem /home/victork/mainline-vanila/usr/ppc64-yellowdog-linux/sys-include -m64 -fPIC -mstrict-align -DHAVE_CONFIG_H -I. -I../../../../gcc/libgfortran -I. -iquote../../../../gcc/libgfortran/io -I../../../../gcc/libgfortran/../gcc -I../../../../gcc/libgfortran/../gcc/config -I../../.././gcc -D_GNU_SOURCE -I . -Wall -fno-repack-arrays -fno-underscoring -fallow-leading-underscore -g -O2 -m64 -fPIC -mstrict-align -c -o _sign_r10.lo `test -f '../../../../gcc/libgfortran/generated/_sign_r10.F90' || echo '../../../../gcc/libgfortran/'`../../../../gcc/libgfortran/generated/_sign_r10.F90 collect2: ld terminated with signal 11 [Segmentation fault] make[8]: *** [libstdc++.la] Error 1 make[8]: Leaving directory `/home/victork/mainline-vanila/build/ppc64-yellowdog-linux/64/libstdc++-v3/src' make[7]: *** [all-recursive] Error 1 make[7]: Leaving directory `/home/victork/mainline-vanila/build/ppc64-yellowdog-linux/64/libstdc++-v3' make[6]: *** [all] Error 2 make[6]: Leaving directory `/home/victork/mainline-vanila/build/ppc64-yellowdog-linux/64/libstdc++-v3' make[5]: *** [multi-do] Error 1 make[5]: Leaving directory `/home/victork/mainline-vanila/build/ppc64-yellowdog-linux/libstdc++-v3' make[4]: *** [all-multi] Error 2 make[4]: Leaving directory `/home/victork/mainline-vanila/build/ppc64-yellowdog-linux/libstdc++-v3' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/victork/mainline-vanila/build/ppc64-yellowdog-linux/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/victork/mainline-vanila/build/ppc64-yellowdog-linux/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 % uname -a Linux mac-victork.haifa.ibm.com 2.6.10-1.yhpc.1smp #1 SMP Thu Mar 17 19:38:06 MST 2005 ppc64 ppc64 ppc64 GNU/Linux svn main trunk revision = 123035 configuration: ../gcc/configure \ --prefix=/home/victork/mainline-vanila/usr \ --enable-shared \ --enable-threads=posix \ --with-system-zlib \ --enable-__cxa_atexit \ --enable-symvers=gnu \ --host=ppc64-yellowdog-linux \ --build=ppc64-yellowdog-linux \ --target=ppc64-yellowdog-linux \ --with-cpu=default32 \ --enable-biarch \ --enable-languages=c,c++,fortran -- Victor > I get the following error on PPC while bootstrapping mainline. > Re-runing make I get: > collect2: ld terminated with signal 11 [Segmentation fault] > make[8]: *** [libstdc++.la] Error 1 > Thanks, > Revital
arm,gcc and dsp instructions
Hello all, I`m working with an arm core 9260EJ-S under Linux (Linux kernel 2.6.15; armv5l-linux toolchain with compiler gnu gcc 3.4.2). I would like to take advantage of the asm DSP like functions the core provides. I compile this way: arm-linux-gnu -msoft-float -mtune=arm926ejs -S mul.c Code generated uses these assembly dsp instructions sometimes (I think critical parts should be assembly written), but it exists any kind of patch or derivative to "tell" gcc to improve the code generated using these kind of 1 cycle instructions more offently? Thanks in advance. Victor Librado Sancho
Is it possible to catch overflow in long long multiply ?
Hi,
I'm using gcc "long long" type for my calculator. I have to check
integer overflow. I'm using sign compare to check overflow, but it
doesn't work for 10^16 * 10^4 :
1 * 1
Here you have my code to check overflow :
long long produit = a * b; // a,b: long long
bool ok;
if (0 < a) {
if (0 < b)
ok = (produit > 0); // (+)*(+) -> (+) ?
else if (b == 0)
ok = true;
else
ok = (produit < 0); // (+)*(-) -> (-) ?
} else if (a == 0) {
ok = true;
} else {
if (0 < b)
ok = (produit < 0); // (-)*(+) -> (-) ?
else if (b == 0)
ok = true;
else
ok = (produit > 0); // (-)*(-) -> (+) ?
}
The problem is that "1 * 1" give
7766279631452241920. It's not the "expected result".
I know that GMP is the best solution, but I don't want to use it, I
prefer to just use long long.
I search in gcc code, but I didn't found the __multi3 function. I just
found #define __muldi3 __multi3 in gcc/libgcc2.h.
Any idea ?
Bye, Haypo
Using profile guided optimization in shared library error
Hi I am trying to optimize python for some specific benchmarks. I am testing the PGO ( FDO ) implementation in python Make file : make profile-opt. 430 # Compile a binary with gcc profile guided optimization. 431 profile-opt: 432 @echo "Building with support for profile generation:" 433 $(MAKE) clean 434 $(MAKE) build_all_generate_profile 435 @echo "Running benchmark to generate profile data:" 436 $(MAKE) profile-removal 437 $(MAKE) run_profile_task 438 @echo "Rebuilding with profile guided optimizations:" 439 $(MAKE) clean 440 $(MAKE) build_all_use_profile 441 442 build_all_generate_profile: 443 $(MAKE) all CFLAGS="$(CFLAGS) -fprofile-generate" LIBS="$(LIBS) -lgcov" 444 445 run_profile_task: 446 : # FIXME: can't run for a cross build 447 ./$(BUILDPYTHON) $(PROFILE_TASK) 448 449 build_all_use_profile: 450 $(MAKE) all CFLAGS="$(CFLAGS) -fprofile-use" It woks fine if I do not add the --enable-shared flag to the configure 740 Building a shared libpython 741 --- 742 743 Starting with Python 2.3, the majority of the interpreter can be built 744 into a shared library, which can then be used by the interpreter 745 executable, and by applications embedding Python. To enable this feature, 746 configure with --enable-shared. 747 748 If you enable this feature, the same object files will be used to create 749 a static library. In particular, the static library will contain object 750 files using position-independent code (PIC) on platforms where PIC flags 751 are needed for the shared library. but I got the following error: make run_profile_task make[1]: Entering directory '/builddir/build/BUILD/Python-2.7.10' : # FIXME: can't run for a cross build ./python ./Tools/pybench/pybench.py -n 2 --with-gc --with-syscheck ./python: symbol lookup error: ./python: undefined symbol: __gcov_indirect_call_callee Makefile:456: recipe for target 'run_profile_task' failed make[1]: Leaving directory '/builddir/build/BUILD/Python-2.7.10' make[1]: *** [run_profile_task] Error 127 Makefile:442: recipe for target 'profile-opt' failed make: *** [profile-opt] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.XWTCtn (%build) Bad exit status from /var/tmp/rpm-tmp.XWTCtn (%build) This is due to the lack of gcov symbols for the shared libraries ( as far as I ca see ) . If I remove the --enable-shared option is fine. However is going to he hard to have a deployable python without the .so & .so.& files After a little bit of search I found this issue has been here before: https://gcc.gnu.org/ml/gcc-help/2010-06/msg00011.html http://stackoverflow.com/questions/2961203/is-profile-guided-optimization-possible-with-shared-libraries-in-gcc http://stackoverflow.com/questions/8837744/gcc-profile-guided-optimization-with-shared-library-with-no-control-over-executa But not sure how to deal with this now (This happen in gcc 4 and 5 ) All the help is more than welcome Regards Victor Rodriguez
Dumping CPP symbol table stats
I would like to tweak cpp to dump some usage stats from its symbol table -- like dumping which #defines were not used at all, etc. I'm wondering if someone can help me figure out where in the code I would look to start to do this. (I know that I'll need to add a command-line argument, and I'm sure I could figure that part out.) Thanks. Prof. Victor Norman Computer Science Calvin College vnor...@calvin.edu - "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." -- Antoine de Saint Exupéry
Re: GCC 4.2 Status Report (2006-04-19)
[EMAIL PROTECTED] wrote on 20-04-2006 12:47:54 AM: > > 3) autovectorization improvements > > Good autovectorization is becoming ever more-important in performance > evaluation. Is there someone who can review this patch? > > Are there other things that are approximately ready for inclusion that > we should try to get into 4.2? We have submitted for mainline 4.2 two patches for review. Still waiting for approvement: 1. Vectorize type conversions: support vectorization in the presence of data-types of different sizes. part1 - http://gcc.gnu.org/ml//gcc-patches/2006-02/msg00940.html (cleanup) part2 - http://gcc.gnu.org/ml//gcc-patches/2006-02/msg00941.html (multiple-types for loads/stores) part3 - http://gcc.gnu.org/ml//gcc-patches/2006-02/msg00942.html (multiple-types for simple operations) part4 - http://gcc.gnu.org/ml//gcc-patches/2006-02/msg00943.html (multiple-types for reduction) part5 - http://gcc.gnu.org/ml//gcc-patches/2006-02/msg00944.html (type demotion) part6 - http://gcc.gnu.org/ml//gcc-patches/2006-02/msg01453.html (type promotion) entire patch - http://gcc.gnu.org/ml//gcc-patches/2006-02/msg01454.html 2. Interleaved memory access: support vectorization in the presence of strided loads in the loop. http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01679.html Additionaly we are working on tree-vectorize and tree-ifcvt enhancements to enable vectorization of EEMBC telecom/vitervi benchmark. This is expected to be ready at early May/2006. Should we consider this for 4.2 too? thanks, -- Victor
Re: libitm.a and sjlj.o object
On 09/20/13 17:20, Richard Henderson wrote: On 09/12/2013 03:22 AM, Víctor Martínez wrote: Why is sjlj.o the only one built for armv4 while the rest of objects are armv5t? Is this behaviour expected? Or is there something wrong trying to configure gcc with these options? There are co-processor instructions in there that can't be encoded with thumb1, as present on armv5t. It is as expected. r~ Thank you very much for the clarification. -- Learning bit by bit Victor Martinez | http://lokalix.dyndns.org
Re: Memory leaks in compiler
> When a loop is vectorized, some statements are removed from the basic > blocks, but the vectorizer information attached to these BBs is never > freed. This is because the attached information is freed by walking > the statements of the basic blocks: see tree-vectorizer.c:1750, but > the transformed code does not contain all the stmts of the original > code. I can't find out a good solution for tracking these stmts, but > one solution could be to free the stmt_info when the stmts are removed > from a BB. Sebastian, thanks for bringing this to our attention. I'll look into this. I hope that removing stmts from a BB can be easily localized. -- Victor
Re: GCC 10.1 Release Candidate available from gcc.gnu.org
On Tue, May 5, 2020 at 7:57 AM William Seurer via Gcc wrote: > > I tried it on powerpc64 LE on power 8 and 9 and BE on power 7 and 8 and > all looks well. > > On 4/30/20 4:21 PM, Jakub Jelinek via Gcc wrote: > > The first release candidate for GCC 10.1 is available from > > > > https://gcc.gnu.org/pub/gcc/snapshots/10.1.0-RC-20200430/ > > ftp://gcc.gnu.org/pub/gcc/snapshots/10.1.0-RC-20200430 > > > > and shortly its mirrors. It has been generated from git revision > > r10-8080-g591d857164c37cd0bb96da2a293148e01f280e0f. > > > > I have so far bootstrapped and tested the release candidate on > > x86_64-linux and i686-linux. Please test it and report any issues to > > bugzilla. > > > > If all goes well, I'd like to release 10.1 on Thursday, May 7th. > > Thanks for this I tried on an Intel i7-4700MQ CPU and all works fine I will recompile some minimal packages to build a Linux system (kernel , systemd, glibc and others) Has someone found issues on common packages that require patches for GCC 10? Thanks Victor Rodriguez
Re: Question about indirect functions and PGO
On Mon, Jul 13, 2020 at 6:41 AM Erick Ochoa wrote: > > Hi, > > I just wanted to answer myself. > It seems that there are two thresholds that need to be met if a function > is to be specialized within a particular context: > > 1. --param=hot-bb-count-ws-permille=. This option controls the hotness > threshold of basic blocks and is needed for function specialization > during LTO. If a callsite is not in a hot basic block, it seems that the > callsite will not be specialized for a particular parameter. > 2. --param=ipa-cp-eval-threshold=. This option controls a heuristic that > lets constant propagation happen if a function is a good candidate for > cloning. This parameter is used for both: function specialization within > a particular context and for all contexts. > > On 10/07/2020 13:19, Erick Ochoa wrote: > > Forgot to mention that these functions take a function pointer as a > > parameter and as a result, the specialized functions are able to replace > > the indirect function call with a direct function call. > > > > On 10/07/2020 13:17, Erick Ochoa wrote: > >> Hello, > >> > >> I'm working on an optimization and I encountered this interesting > >> behaviour. There are a couple of functions that are specialized when > >> the program is not compiled with PGO (-fprofile-generate and > >> -fprofile-use) > >> > >> However, when the program is compiled with PGO the compiler does not > >> specialize the function calls. > >> > >> I printing the program just after materializing all clones. > >> > >> I am running this version of GCC: > >> Author: GCC Administrator > >> Date: Fri Jul 10 00:16:28 2020 + > >> > >> Daily bump. > >> > >> I can imagine that the profiling information was used to determine > >> that specializing these functions is a bad tradeoff between binary > >> size and speed. But I do not know this for sure. How can I find out > >> why these functions were not specialized? (I.e. is there a threshold > >> that wasn't met, and if so, where is it located and what's its value?) > >> Have you tried the new option-fprofile-partial-training ? -fprofile-partial-training can now be used to inform the compiler that code paths not covered by the training run should not be optimized for size. I tested by myself this week and it literally do not optimize at all the functions not touched by the training Regards Victor Rodriguez > >> Thanks!
Lack of latest binutils in gcc 11 docker image
HI team I am trying to use the gcc 11 docker hub image to build AMX code but it fails /usr/local/lib/gcc/x86_64-linux-gnu/11.1.0/include/amxtileintrin.h: Assembler messages: /usr/local/lib/gcc/x86_64-linux-gnu/11.1.0/include/amxtileintrin.h:42: Error: no such instruction: `ldtilecfg (%rdi)' /usr/local/lib/gcc/x86_64-linux-gnu/11.1.0/include/amxtileintrin.h:49: Error: no such instruction: `sttilecfg -72(%rsp)' /usr/local/lib/gcc/x86_64-linux-gnu/11.1.0/include/amxtileintrin.h:42: Error: no such instruction: `ldtilecfg -72(%rsp)' src/basic/test.c:11: Error: no such instruction: `tdpbssd %tmm3,%tmm2,%tmm1' /usr/local/lib/gcc/x86_64-linux-gnu/11.1.0/include/amxtileintrin.h:56: Error: no such instruction: `tilerelease' src/basic/test.c:11: Error: no such instruction: `tdpbssd %tmm3,%tmm2,%tmm1' /usr/local/lib/gcc/x86_64-linux-gnu/11.1.0/include/amxtileintrin.h:56: Error: no such instruction: `tilerelease' I was wondering where can we send a patch to add binutils (latest ) to that docker hub image Thanks https://hub.docker.com/layers/gcc/library/gcc/11.1.0/images/sha256-1b844ca17da259215eb25ad8b3cdd7a547ff9e482a5b8477606ab028203717f4?context=explore
Re: Lack of latest binutils in gcc 11 docker image
On Fri, Jun 11, 2021 at 4:39 AM Jonathan Wakely wrote: > > > I was wondering where can we send a patch to add binutils (latest ) > > to that docker hub image > > Those images are maintained by Docker Inc. and nothing to do with the > GCC project: > > https://docs.docker.com/docker-hub/official_images/ > > "All Official Images contain a User Feedback section in their > documentation which covers the details for that specific repository. > In most cases, the GitHub repository which contains the Dockerfiles > for an Official Repository also has an active issue tracker. General > feedback and support questions should be directed to #docker-library > on Freenode IRC." > Thanks a lot, i will contact the community and let them know Regards
CFI technologies in GCC
Hello, I'm interested in learning about any forward edge control-flow integrity (CFI) technologies in GCC. I was able to find information about the Virtual Table Verification, Indirect Branch Tracking and Reuse Attack Protector technologies. Are there any other technologies in GCC to protect indirect calls? I'm particularly curious about more general solutions since VTV is limited to virtual calls, IBT is limited to x86 and Intel hardware, and RAP requires a GRSecurity license. Thanks, Victor
Re: CFI technologies in GCC
Bumping this thread. Would anyone be interested in CFI technology contributions to GCC? From: Victor Tong Sent: Tuesday, August 3, 2021 5:49 PM To: gcc@gcc.gnu.org Subject: CFI technologies in GCC Hello, I'm interested in learning about any forward edge control-flow integrity (CFI) technologies in GCC. I was able to find information about the Virtual Table Verification, Indirect Branch Tracking and Reuse Attack Protector technologies. Are there any other technologies in GCC to protect indirect calls? I'm particularly curious about more general solutions since VTV is limited to virtual calls, IBT is limited to x86 and Intel hardware, and RAP requires a GRSecurity license. Thanks, Victor
