CALL FOR PARTICIPATION: GROW'10 - 2nd Workshop on GCC Research Opportunities
Apologies if you receive multiple copies of this call. CALL FOR PARTICIPATION 2nd Workshop on GCC Research Opportunities (GROW'10) http://ctuning.org/workshop-grow10 January 23, 2010, Pisa, Italy (co-located with HiPEAC 2010 Conference) EARLY REGISTRATION DEADLINE: JAN. 6th, 2010 We invite you to participate in GROW 2010, the Workshop on GCC Research opportunities, to be held in Pisa, Italy in January 23, 2010, along with the conference on High-Performance Embedded Architectures and Compilers (HiPEAC). The Workshop Program includes: * Presentations of 8 selected papers * A Keynote talk by Diego Novillo, Google, Canada, on: "Using GCC as a toolbox for research: GCC plugins and whole-program compilation" * A panel on plugins and the future of GCC The Workshop Program is now available: http://ctuning.org/wiki/index.php/Dissemination:Workshops:GROW10:Program GROW workshop focuses on current challenges in research and development of compiler analyses and optimizations based on the free GNU Compiler Collection (GCC). The goal of this workshop is to bring together people from industry and academia that are interested in conducting research based on GCC and enhancing this compiler suite for research needs. The workshop will promote and disseminate compiler research (recent, ongoing or planned) with GCC, as a robust industrial-strength vehicle that supports free and collaborative research. The program will include an invited talk and a discussion panel on future research and development directions of GCC. Topics of interest Any issue related to innovative program analysis, optimizations and run-time adaptation with GCC including but not limited to: * Classical compiler analyses, transformations and optimizations * Power-aware analyses and optimizations * Language/Compiler/HW cooperation * Optimizing compilation tools for heterogeneous/reconfigurable/ multicore systems * Tools to improve compiler configurability and retargetability * Profiling, program instrumentation and dynamic analysis * Iterative and collective feedback-directed optimization * Case studies and performance evaluations * Techniques and tools to improve usability and quality of GCC * Plugins to enhance research capabilities of GCC Organizers Grigori Fursin, INRIA, France Dorit Nuzman, IBM, Israel Program Committee Arutyun I. Avetisyan, ISP RAS, Russia Zbigniew Chamski, Infrasoft IT Solutions, Poland Albert Cohen, INRIA, France David Edelsohn, IBM, USA Bjorn Franke, University of Edinburgh, UK Grigori Fursin, INRIA, France Benedict Gaster, AMD, USA Jan Hubicka, SUSE Paul H.J. Kelly, Imperial College of London, UK Ondrej Lhotak, University of Waterloo, Canada Hans-Peter Nilsson, Axis Communications, Sweden Diego Novillo, Google, Canada Dorit Nuzman, IBM, Israel Sebastian Pop, AMD, USA Ian Lance Taylor, Google, USA Chengyong Wu, ICT, China Kenneth Zadeck, NaturalBridge, USA Ayal Zaks, IBM, Israel Previous Workshops GROW'09: http://www.doc.ic.ac.uk/~phjk/GROW09 GREPS'07: http://sysrun.haifa.il.ibm.com/hrl/greps2007
Debugging lto1, how?
Hi, I am trying to see what is going on in lto1 for PR lto/42534. I can reproduce the reported ICE but I can't reproduce it inside gdb to see what is happening. Debugging lto1 is not trivial - just getting the arguments and input files right is hard. Apparently this is a known issue (http://gcc.gnu.org/ml/gcc/2009-11/msg00047.html). Could someone with experience in debugging lto1 perhaps add a HOWTO for this on the Wiki? Thanks, Ciao! Steven
Re: Debugging lto1, how?
2009/12/29 Steven Bosscher : > Hi, > > I am trying to see what is going on in lto1 for PR lto/42534. I can > reproduce the reported ICE but I can't reproduce it inside gdb to see > what is happening. Debugging lto1 is not trivial - just getting the > arguments and input files right is hard. > > Apparently this is a known issue > (http://gcc.gnu.org/ml/gcc/2009-11/msg00047.html). > > Could someone with experience in debugging lto1 perhaps add a HOWTO > for this on the Wiki? Have you been able to get the lto1 command line? I don't think I have seen a case where a direct invocation of lto1 would fail but it would work in gdb. Sounds like a memory problem, have you tried valgrind? Getting the command line is annoying. In part because of the many layers in part because of the use of @files. gcc -v -save-temps should print you the necessary command line, no? Are you using gold + plugin or collect2? > Thanks, > > Ciao! > Steven > Cheers, -- Rafael Ávila de Espíndola
Re: Debugging lto1, how?
On Tue, Dec 29, 2009 at 5:41 PM, Rafael Espindola wrote: > 2009/12/29 Steven Bosscher : >> Hi, >> >> I am trying to see what is going on in lto1 for PR lto/42534. I can >> reproduce the reported ICE but I can't reproduce it inside gdb to see >> what is happening. Debugging lto1 is not trivial - just getting the >> arguments and input files right is hard. >> >> Apparently this is a known issue >> (http://gcc.gnu.org/ml/gcc/2009-11/msg00047.html). >> >> Could someone with experience in debugging lto1 perhaps add a HOWTO >> for this on the Wiki? > > Have you been able to get the lto1 command line? I don't think I have > seen a case where a direct invocation of lto1 would fail but it would > work in gdb. Sounds like a memory problem, have you tried valgrind? I have the lto1 command line, yes. But that gives a different failure. When run from gcc, lto1 crashes with an ICE, and when I run lto1 standalone, it crashes with an error reading a hex number. > gcc -v -save-temps should print you the necessary command line, no? Yes. > Are you using gold + plugin or collect2? collect2. T.i.a. for any help you can give :-) Ciao! Steven
Re: Debugging lto1, how?
> I have the lto1 command line, yes. But that gives a different failure. > When run from gcc, lto1 crashes with an ICE, and when I run lto1 > standalone, it crashes with an error reading a hex number. Do you have a backtrace of that? You can also copy the gcc line and pass -wrapper to it. > > >> gcc -v -save-temps should print you the necessary command line, no? > > Yes. > > >> Are you using gold + plugin or collect2? > > collect2. > > T.i.a. for any help you can give :-) > > Ciao! > Steven > Cheers, -- Rafael Ávila de Espíndola
Re: Debugging lto1, how?
On Tue, Dec 29, 2009 at 6:50 PM, Rafael Espindola wrote: >> I have the lto1 command line, yes. But that gives a different failure. >> When run from gcc, lto1 crashes with an ICE, and when I run lto1 >> standalone, it crashes with an error reading a hex number. > > Do you have a backtrace of that? > You can also copy the gcc line and pass -wrapper to it. Here's what I'm trying to do: stev...@iowa:~/devel/build/gcc$ ./xgcc -B. -O2 -flto -c -o t.o t.c stev...@iowa:~/devel/build/gcc$ ./xgcc -B. -O2 -flto -r -o t.o t.c -nostdlib In file included from :0:0: t.c: In function 'foo': t.c:7:6: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. lto-wrapper: ././xgcc returned 1 exit status collect2: lto-wrapper returned 1 exit status stev...@iowa:~/devel/build/gcc$ ./xgcc -B. -O2 -flto -c -o t.o t.c stev...@iowa:~/devel/build/gcc$ ./xgcc -B. -O2 -flto -r -o t.o t.c -nostdlib -save-temps t.o: file not recognized: File truncated collect2: ld returned 1 exit status stev...@iowa:~/devel/build/gcc$ stev...@iowa:~/devel/build/gcc$ ./xgcc -B. -O2 -flto -r -o t.o t.c -nostdlib -Wl,-debug -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: ia64-unknown-linux-gnu Configured with: ../trunk/configure --with-gmp=/home/stevenb --with-mpfr=/home/stevenb --with-mpc=/home/stevenb --enable-languages=c --disable-nls --disable-bootstrap --disable-libmudflap --disable-checking Thread model: posix gcc version 4.5.0 20091229 (experimental) [trunk revision 155504] (GCC) COLLECT_GCC_OPTIONS='-B.' '-O2' '-flto' '-r' '-o' 't.o' '-nostdlib' '-v' ./cc1 -quiet -v -iprefix /home/stevenb/devel/build/gcc/../lib/gcc/ia64-unknown-linux-gnu/4.5.0/ -isystem ./include -isystem ./include-fixed t.c -quiet -dumpbase t.c -auxbase t -O2 -version -flto -o /tmp/ccrkWvWJ.s GNU C (GCC) version 4.5.0 20091229 (experimental) [trunk revision 155504] (ia64-unknown-linux-gnu) compiled by GNU C version 4.3.4, GMP version 4.2.4, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/home/stevenb/devel/build/gcc/../lib/gcc/ia64-unknown-linux-gnu/4.5.0/include" ignoring nonexistent directory "/home/stevenb/devel/build/gcc/../lib/gcc/ia64-unknown-linux-gnu/4.5.0/include-fixed" ignoring nonexistent directory "/home/stevenb/devel/build/gcc/../lib/gcc/ia64-unknown-linux-gnu/4.5.0/../../../../ia64-unknown-linux-gnu/include" ignoring nonexistent directory "/home/stevenb/devel/build/gcc/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.5.0/include" ignoring nonexistent directory "/home/stevenb/devel/build/gcc/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.5.0/include-fixed" ignoring nonexistent directory "/home/stevenb/devel/build/gcc/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.5.0/../../../../ia64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: ./include ./include-fixed /usr/local/include /usr/include End of search list. GNU C (GCC) version 4.5.0 20091229 (experimental) [trunk revision 155504] (ia64-unknown-linux-gnu) compiled by GNU C version 4.3.4, GMP version 4.2.4, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 32e44dfa726727a33cceaeab86c3ae9a COLLECT_GCC_OPTIONS='-B.' '-O2' '-flto' '-r' '-o' 't.o' '-nostdlib' '-v' ./as -x -o /tmp/ccKl30Yq.o /tmp/ccrkWvWJ.s COMPILER_PATH=./ LIBRARY_PATH=./:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-B.' '-O2' '-flto' '-r' '-o' 't.o' '-nostdlib' '-v' ./collect2 -flto -dynamic-linker /lib/ld-linux-ia64.so.2 -o t.o -r -L. /tmp/ccKl30Yq.o -debug Convert string './' into prefixes, separator = ':' - add prefix: ./ Convert string '/home/stevenb/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games' into prefixes, separator = ':' - add prefix: /home/stevenb/bin/ - add prefix: /usr/local/bin/ - add prefix: /usr/bin/ - add prefix: /bin/ - add prefix: /usr/bin/X11/ - add prefix: /usr/games/ Looking for 'real-ld' Looking for 'collect-ld' Looking for 'gnm' Looking for 'gnm' Looking for 'nm' Looking for 'gstrip' Looking for 'gstrip' Looking for 'strip' Looking for 'strip' Looking for './xgcc' collect2 version 4.5.0 20091229 (experimental) [trunk revision 155504] (IA-64) Linux ld_file_name= ./collect-ld c_file_name
Re: Debugging lto1, how?
> Hope this helps... Looks like something is getting really messed up in the argument parsing :-( The error for the hexadecimal number pursing is from the code that should handle things like fil...@offset This is probably from some @file not being expanded. What I would recommend is first debugging why -save-temps is not working. Can you try without -flto: $./xgcc -B. -O2 -c -o t.o t.c $ ./xgcc -B. -O2 -r -o t.o t.c -nostdlib -save-temps > Ciao! > Steven > Cheers, -- Rafael Ávila de Espíndola
Need an assembler consult!
Hi all,
I have picked up what seems to be a simple patch from PR36399, but I don't know
enough assembler to tell whether it's fixing it completely or not.
The following function:
#include
__m128i r(__m128 d1, __m128 d2, __m128 d3, __m128i r, int t, __m128i s) {return
r+s;}
is compiled by Apple's GCC into:
pushl %ebp
movl%esp, %ebp
subl$72, %esp
movaps %xmm0, -24(%ebp)
movaps %xmm1, -40(%ebp)
movaps %xmm2, -56(%ebp)
movdqa %xmm3, -72(%ebp) #
movdqa 24(%ebp), %xmm0 #
paddq -72(%ebp), %xmm0 #
leave
ret
Instead of lines marked with #, FSF's GCC gives:
movdqa 40(%ebp), %xmm1
movdqa 8(%ebp), %xmm0
paddq %xmm1, %xmm0
By fixing SSE_REGPARM_MAX in config/i386/i386.h (following Apple's compiler
value), I get GCC now generates:
movdqa %xmm3, -72(%ebp)
movdqa 24(%ebp), %xmm0
movdqa -72(%ebp), %xmm1
paddq %xmm1, %xmm0
The first two lines are identical to Apple, but the last two don't. They seem
OK to me, but I don't know enough assembler to be really sure. Could someone
confirm the two are equivalent?
Thanks,
FX
PS: the patch is:
> Index: gcc/config/i386/i386.h
> ===
> --- gcc/config/i386/i386.h(revision 155505)
> +++ gcc/config/i386/i386.h(working copy)
> @@ -1810,7 +1810,7 @@
> #define X86_64_SSE_REGPARM_MAX 8
> #define X86_64_MS_SSE_REGPARM_MAX 4
>
> -#define X86_32_SSE_REGPARM_MAX (TARGET_SSE ? 3 : 0)
> +#define X86_32_SSE_REGPARM_MAX (TARGET_SSE ? (TARGET_MACHO ? 4 : 3) : 0)
>
> #define SSE_REGPARM_MAX
> \
>(TARGET_64BIT ? (TARGET_64BIT_MS_ABI ? X86_64_MS_SSE_REGPARM_MAX \
no subject
test
problem posting to gdb-patc...@gnu.org
can someone please comment? greetz, michael
Objective-C 2.0 support
Hi, I would like to provide a kind of iPhone-like api on non apple hardware using Objective-C and I wanted to know if there will be one day support of Objective-C 2.0(at least property syntax) ? Thanks
Re: Need an assembler consult!
FX wrote:
Hi all,
I have picked up what seems to be a simple patch from PR36399, but I don't know
enough assembler to tell whether it's fixing it completely or not.
The following function:
#include
__m128i r(__m128 d1, __m128 d2, __m128 d3, __m128i r, int t, __m128i s) {return
r+s;}
is compiled by Apple's GCC into:
pushl %ebp
movl%esp, %ebp
subl$72, %esp
movaps %xmm0, -24(%ebp)
movaps %xmm1, -40(%ebp)
movaps %xmm2, -56(%ebp)
movdqa %xmm3, -72(%ebp) #
movdqa 24(%ebp), %xmm0 #
paddq -72(%ebp), %xmm0 #
leave
ret
Instead of lines marked with #, FSF's GCC gives:
movdqa 40(%ebp), %xmm1
movdqa 8(%ebp), %xmm0
paddq %xmm1, %xmm0
By fixing SSE_REGPARM_MAX in config/i386/i386.h (following Apple's compiler
value), I get GCC now generates:
movdqa %xmm3, -72(%ebp)
movdqa 24(%ebp), %xmm0
movdqa -72(%ebp), %xmm1
paddq %xmm1, %xmm0
The first two lines are identical to Apple, but the last two don't. They seem
OK to me, but I don't know enough assembler to be really sure. Could someone
confirm the two are equivalent?
Apparently the same as far as what is returned in xmm0.
gcc-4.4-20091229 is now available
Snapshot gcc-4.4-20091229 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20091229/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 155511 You'll find: gcc-4.4-20091229.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20091229.tar.bz2 C front end and core compiler gcc-ada-4.4-20091229.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20091229.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20091229.tar.bz2 C++ front end and runtime gcc-java-4.4-20091229.tar.bz2 Java front end and runtime gcc-objc-4.4-20091229.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20091229.tar.bz2The GCC testsuite Diffs from 4.4-20091222 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: problem posting to gdb-patc...@gnu.org
"g...@cyberfiber.org" writes: > can someone please comment? 1) This is definitely the wrong mailing list. Try sysad...@gnu.org. 2) Nobody can help you without much more information, like exactly what you tried to do and exactly what happened. 3) You probably want gdb-patc...@sourceware.org. Ian
