Re: Parameter not passed in call expr

[Ludovic Courtès]

Hi Dodji,

Dodji Seketeli  writes:

> ludovic.cour...@inria.fr (Ludovic Courtès) a écrit:

[...]

>>   parm = build_decl (loc, PARM_DECL,
>>   create_tmp_var_name ("parm"),
>>   void_ptr);
>
>
> It looks like a:
>
> DECL_ARG_TYPE (parm) = void_ptr;
>
> might be helpful here.

Arrrgh, indeed.

Thanks for making my day brighter!  ;-)

Ludo’.

A question about handling debug_insn in schedulers

[Revital Eres]

Hello,

I wonder how the instruction scheduler deals with debug_insn?
Looking at how SMS handles notes I wonder if this mechanism is adopted to
handle debug_insn in other schedulers:  notes are ignored during the
scheduling procedure
and are carefully placed before the instruction that follow them in the
original order of the loop after the scheduling is done.

Thanks,
Revital

RE: Frame Pointer Usage

[Iyer, Balaji V]

Thanks Ian for your help. If I set the frame pointer required hook (using 
SUBTARGET_FRAME_POINTER_REQUIRED and TARGET_FRAME_POINTER_REQUIRED) it will set 
the frame-pointer for all the functions..am I correct?  I would like to force 
it to use the frame-pointer for a certain functions in a program that I figure 
out during compile time. Is there a feature to do this? If one doesn't exist, 
then how much of a major change is this to the GCC mainline for me to add this 
functionality?

Thanks,

Balaji V. Iyer.


-Original Message-
From: Ian Lance Taylor [mailto:i...@google.com] 
Sent: Friday, April 08, 2011 6:32 PM
To: Iyer, Balaji V
Cc: gcc@gcc.gnu.org
Subject: Re: Frame Pointer Usage

"Iyer, Balaji V"  writes:

>   I have a question regarding using frame pointers. I have a scenario 
> where I need to use the frame for certain functions and for the other 
> functions it can optimize it out. I see there is a flag called  
> "-fno-omit-frame-pointer", which will keep the frame pointer for all the 
> functions. Is there a way I can keep/remove the frame for a per-function 
> basis? If this functionality is not present in GCC and if I want to add such 
> a functionality, where/how should I go about implementing it?

That is how gcc behaves anyhow.  It will use a frame pointer if it needs
one, whether or not -fomit-frame-pointer is in effect.  To control this
in your backend, see the frame_pointer_required target hook.

Ian

Re: [RFC] gfortran's coarray (library version): configure/build and the testsuite

[Mikael Morin]

On Tuesday 05 April 2011 22:01:03 Tobias Burnus wrote:
> Hello,
> 
> Fortran 2008 has a build in parallelization (Coarray [Fortran], CAF)
> [1]. gfortran did the first steps to a communication-library version
> [2]. The library will be based MPI.
> 
> There are two issues I like to discuss in this email:
> 
> a) configuring and building
> b) Test-suite support
> 
> 
> Let's start with (b) which is more important for me. The current scheme
> is that the user somehow compiles the communication library (libcaf) [2]
> and then builds and links doing something like:
>mpif90 -fcoarray=lib  fortran.f90 -lcaf_mpi
> or alternatively
>gfortran -fcoarray=lib fortran.f90 -lcaf_mpi
> -I/usr/lib64/mpi/gcc/openmpi/include -L/usr/lib64/mpi/gcc/openmpi/lib64
> -lmpi
> with some -I, -L -l are added. (Cf. "mpif90 -show" of
> some MPI implementations.) The resulting program is then run using, e.g.,
>mpiexec -n 3 ./a.out
> Alternatively, it could be just "-lcaf_single" which is run like normal
> ("./a.out").
> 
> Thus, one needs some means to add link and compile options - and a means
> to add an (optional) run command. Those one would probably pass via
> environment variables.
As I said in the other mail, I think we should try to test everything that is 
testable without the user requiring it or configuring anything.
We could have a gfortran.dg/caf (like gomp,vect,...) dir in which every test 
is tested against -fcoarray=single and with -fcoarray=lib for every libcaf_*.

> 
> One would then either only run the tests if the environment variable is
> set - or if "libcaf_single.a" is installed by default (cf. below),  one
> could default to linking that version if no environment variable is set.
> Then "make check-gfortran" could then always run the CAF library checks
> - otherwise, only conditionally.
> 
> What do you think? Do you have comments how this should be done? I also
> wouldn't mind if someone could help as I am not really comfortable with
> the test-suite setup nor do I know Lisp well.
All is well, it is TCL, not Lisp. ;-)


> Thus, the first question is: Should one build and install single.c
> (libcaf_single.a) by default? (Might also relate to (a), namely how the
> test suite is handled.)
It is a small library to be put in a gcc-owned (thus it shouldn't be too 
disturbing) directory. So, yes, in my opinion, we can install it by default.
The same goes for libcaf_mpi. Not as small, yet still reasonable.
We should install it if mpi is available.

> 
> And the second question is: Should one be able to configure and build
> mpi.c (libcaf_mpi.a) by some means? I think users interested in could
> also do the procedure of [2] - or let their admin do it. (For Linux
> distributions one would run into the problem that they typically offer
> several MPI implementations, e.g. Open MPI and MPICH2, which couldn't be
> handled that way.)
We should try to have [2] done automatically if possible.
After all, all that is needed is a mpicc in the PATH (and the corresponding 
mpif90 for the testsuite) so the corresponding autoconf code shouldn't be too 
convoluted.

For the multiple MPI implementations, either we accept to choose only one at 
configure time, or we could ship a stripped down mpi.h containing only the 
interfaces we care about. As the interfaces are standard (aren't they?) we 
could link with any standard-compliant implementation afterwards. 
With that, no configury needed, we install unconditianally the libcaf_mpi.a 
file, but some manual tweaking is needed at make check time to choose one mpi 
implementation. Another downside is a burden on us to keep the file up-to-
date.


Mikael

Re: Frame Pointer Usage

[Ian Lance Taylor]

"Iyer, Balaji V"  writes:

> Thanks Ian for your help. If I set the frame pointer required hook (using 
> SUBTARGET_FRAME_POINTER_REQUIRED and TARGET_FRAME_POINTER_REQUIRED) it will 
> set the frame-pointer for all the functions..am I correct?  I would like to 
> force it to use the frame-pointer for a certain functions in a program that I 
> figure out during compile time. Is there a feature to do this? If one doesn't 
> exist, then how much of a major change is this to the GCC mainline for me to 
> add this functionality?

In current gcc, the frame pointer required hook is a function
implemented in the backend.  Your backend can decide, on a
function-by-function basis, whether a frame pointer is required.  It
seems to me that that is what you want.  Please let me know if I
misunderstand.

I'm not sure why you are referring to SUBTARGET_FRAME_POINTER_REQUIRED.
A few backends define that macro, most do not.

Ian

RE: Frame Pointer Usage

[Iyer, Balaji V]

Yes, that is what I want. Thank you!

-Balaji V. Iyer.

-Original Message-
From: Ian Lance Taylor [mailto:i...@google.com] 
Sent: Monday, April 11, 2011 4:40 PM
To: Iyer, Balaji V
Cc: gcc@gcc.gnu.org
Subject: Re: Frame Pointer Usage

"Iyer, Balaji V"  writes:

> Thanks Ian for your help. If I set the frame pointer required hook (using 
> SUBTARGET_FRAME_POINTER_REQUIRED and TARGET_FRAME_POINTER_REQUIRED) it will 
> set the frame-pointer for all the functions..am I correct?  I would like to 
> force it to use the frame-pointer for a certain functions in a program that I 
> figure out during compile time. Is there a feature to do this? If one doesn't 
> exist, then how much of a major change is this to the GCC mainline for me to 
> add this functionality?

In current gcc, the frame pointer required hook is a function
implemented in the backend.  Your backend can decide, on a
function-by-function basis, whether a frame pointer is required.  It
seems to me that that is what you want.  Please let me know if I
misunderstand.

I'm not sure why you are referring to SUBTARGET_FRAME_POINTER_REQUIRED.
A few backends define that macro, most do not.

Ian

Re: [RFC] gfortran's coarray (library version): configure/build and the testsuite

[Jorge D'ELIA]

- Mensaje original -
> De: "Ralf Wildenhues" 
> Para: "Jorge D'ELIA" 
> CC: "Tobias Burnus" , 
> "gfortran" , 
> "GCC Mailing List" , 
> "Rainer Orth" CeBiTec.Uni-Bielefeld.DE>
> Enviados: Sábado, 9 de Abril 2011 6:34:05
> Asunto: Re: [RFC] gfortran's coarray (library version): 
> configure/build and the testsuite
>
> Hello,
> 
> * Jorge D'ELIA wrote on Wed, Apr 06, 2011 at 01:24:58AM CEST:
> > Here there are few comments from my college Lisandro Dalcin,
> > an external developer of PETSc, e.g. see
> 
> > - Mensaje original -
> > > The current scheme is that the user somehow compiles
> > > the communication library (libcaf) [2] and then builds
> > > and links doing something like:
> > >
> > > mpif90 -fcoarray=lib fortran.f90 -lcaf_mpi
> > >
> > > or alternatively
> > >
> > > gfortran -fcoarray=lib fortran.f90 -lcaf_mpi
> > > -I/usr/lib64/mpi/gcc/openmpi/include
> > > -L/usr/lib64/mpi/gcc/openmpi/lib64
> > > -lmpi
> > >
> > > with some -I, -L -l are added.
> > > (Cf. "mpif90 -show" of some MPI implementations.)
> > >
> > > The resulting program is then run using, e.g.,
> > >
> > > mpiexec -n 3 ./a.out
> > >
> > > Alternatively, it could be just "-lcaf_single"
> > > which is run like normal ("./a.out").
> 
> I think one of the most important things is that you allow to override
> both the running of mpif90 and the mpiexec commands, so as to allow
> batch environments (qsub, llrun). Although, parsing of output might
> need to be more complex in that case, too. But if only to allow for
> different mpiexec.* incarnations this would be good.
> 
> > > (In any case, only static libraries should be created;
> > > the libraries could then be installed
> > > in $PREFIX/$lib/gcc/$target/$version/, where
> > > already libgcc.a etc. are located.)
> >
> > COMMENT: well, using shared libraries would certainly help
> > users to switch the underlying MPI implementation at runtime.
> > This is an feature should be considered.
> 
> The MPI implementations I know all have pairwise incompatible ABIs,
> prohibiting any kind of switching at run time. If anything, GCC
> might consider making it easy to build and install in parallel the
> library for multiple MPI implementations.
> 
> Cheers,
> Ralf


Hi Ralf,


It is clear that the present discussion is due to that 
the MPI's binaries are not compatibles yet among the MPI 
implementations.

To ensure that the compiler is as neutral as possible 
with respect to an end user, we should see how to 
overcome that problem.

Among other possibilities we consider 5 options, from 
the simplest to more elaborates:

1) A static library "libcaf_mpi.a", that was proposed previously 
in another thread. It uses a specific MPI implementation when 
the library is built (e.g. openmpi or mpich). This possibility 
is the simplest one. However, it only works with the MPI 
distribution available when the library is built.

2) A dynamic library "libcaf_mpi.so" that uses a specific MPI
implementation (e.g. openmpi or mpich) when the library is 
built. However, again, it only works with the MPI implementation 
available when the library is built. From an usability point of 
view, this option is not too much different than the previous 
one.

3) A symbolic link "libcaf_mpi.so" points to "libcaf_mpich.so" 
or "libcaf_openmpi.so". The sysadmin can manage the link using 
tools like "alternatives". Linux distributions usually take care
of this infrastructure by themselves, no more work required
from Gfortran side. However, regular (non-root) users cannot 
switch the backend MPI. This only available on POSIX systems.

4) Different dynamic libraries named "libcaf_mpi.so" are 
built for each MPI implementation, but they are installed
in differente directories, e.g.  

/mpich/libcaf_mpi.so or 
/openmpi/libcaf_mpi.so.

By using the "modules" tool, users can select the preferred
MPI implementation (e.g. "module load mpich2-x86_64" in 
Fedora). This works by adding entries in the LD_LIBRARY_PATH 
enviroment variable. Linux distributions usually take care 
of this infrastructure by themselves, no more work required
from Gfortran side. Regular users are able to choose
the prefered MPI implementation, the dynamic linker loads
the appropiate "libcaf_mpi.so" .

5) A dynamic library a "libcaf_mpi.so" built using the 
dlopen() tool. This option could be practical if the number 
of MPI functions would be no too large (BTW, how many?), 
and with a bonus that it can be built on both Linux and 
Windows systems. If there is interest, we can contribute 
something in this direction.

5) A dynamic library "libcaf_mpi.so" is not linked 
with MPI, but uses the dlopen() and dlsym(), to load 
and access the contents of a specific "MPI-linked" 
dynamic library "libcaf_mpi_{mpich2|openmpi|other}.so".
This way "libcaf_mpi.so" does not depend on any MPI 
implementation, but acts as a thin wrapper to the 
specific caf + MPI library. By using enviroment 
variables or rc configuration files, user can choose 
the pr

WPA/LTRANS vs COMDAT vs linker plugin confusion.

[Dave Korn]

Hi all,

  From http://gcc.gnu.org/wiki/whopr/driver:

> When the WPA phase produces the definition of the COMDAT symbol in a new
> object file, that definition should not be in a COMDAT group.

  But it appears that it is:

> davek@gcc10:~/gcc/obj.patched/gcc/testsuite/g++$ grep section 
> g++-dg-lto-200811
> 09-1-01.ltrans0.s
> .section.gcc_except_table,"a",@progbits
> .section.data.rel.ro._ZTI3Foo,"awG",@progbits,_ZTI3Foo,comdat
> .section.rodata._ZTS3Foo,"aG",@progbits,_ZTS3Foo,comdat
> .section
> .data.DW.ref._ZTI3Foo,"awG",@progbits,DW.ref._ZTI3Foo,co
> mdat
> .section
> .data.DW.ref.__gxx_personality_v0,"awG",@progbits,DW.ref
> .__gxx_personality_v0,comdat
> .section.note.GNU-stack,"",@progbits
> davek@gcc10:~/gcc/obj.patched/gcc/testsuite/g++$

  Note in particular _ZTI3Foo and _ZTS3Foo, they have comdat groupnames.  The
GAS manual doesn't even suggest a way to make a single comdat section without
a group for ELF.

  Am I misunderstanding what that line from the documentation means?  Does it
maybe just mean that WPA should pass it to LTRANS without specifying a comdat
group but LTRANS should go ahead and do so?

cheers,
  DaveK

Re: GCC Gathering in London 17/Jun to 19/Jun 2011

[Philip Herron]

On 8 April 2011 21:15, Diego Novillo  wrote:
> We are organizing a gathering of GCC developers and interested parties
> at the Google office in London, UK for the weekend of 17-Jun-2011.
> The gathering will be Friday evening, all day Saturday, and Sunday
> until some time in the afternoon.
>
> The idea is to simply get together and discuss current/future work,
> coordinate efforts, and perhaps do some collective GCC hacking.
>
> The format is going to be an informal unconference:
>
> - No papers.
> - No prepared presentations (unless it's really interesting).
> - No attendance fees.
>
> Google will provide meeting facilities and food.  We have space for
> about 100 people.  Attendees are responsible for travel and
> accommodations.  We will meet Friday evening and coordinate a list of
> topics for discussion.  We could also work something out in advance.
>
> At the moment, we need to know how many developers would attend.
> Please RSVP before 22-Apr-2011.  Let us know if you might come; it's
> not a commitment.
>
> The Google London office is near Victoria Station at
>
> Belgrave House
> 76 Buckingham Palace Road
> London SW1W 9TQ
> United Kingdom
>
> http://maps.google.com/?q=Google%20London@51.495238,-0.146663&hl=en
>
> Diego and Ian.
>

I may actually be in England around that time to see my brother but
not sure yet might be cool to pop along and say hi if i am to be in
england at that time at least :)

Have fun anyways.

--Phil

RE: Frame Pointer Usage

[Sumanth Gundapaneni]

Hi,

FYI besides what Ian had mentioned, you can refer to gcc/function.h file for 
the classification of functions by GCC. You can check out how GCC 
categorizes a function by debugging cc1 using "gdb --args" 
(http://gcc.gnu.org/wiki/DebuggingGCC). You can probably put a break point 
at your prologue function and can see the contents of structure "cfun". 
Correct me if I am wrong. 

Gcc allows you to control the same at application level using attributes.
An attribute to function like  
__attribute__((optimize("-fno-omit-frame-pointer"))) 
may not omit the frame pointer for the concerned function.   

-Sumanth G

-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Iyer, 
Balaji V
Sent: Tuesday, April 12, 2011 2:27 AM
To: Ian Lance Taylor
Cc: gcc@gcc.gnu.org
Subject: RE: Frame Pointer Usage

Yes, that is what I want. Thank you!

-Balaji V. Iyer.

-Original Message-
From: Ian Lance Taylor [mailto:i...@google.com] 
Sent: Monday, April 11, 2011 4:40 PM
To: Iyer, Balaji V
Cc: gcc@gcc.gnu.org
Subject: Re: Frame Pointer Usage

"Iyer, Balaji V"  writes:

> Thanks Ian for your help. If I set the frame pointer required hook (using 
> SUBTARGET_FRAME_POINTER_REQUIRED and TARGET_FRAME_POINTER_REQUIRED) it will 
> set the frame-pointer for all the functions..am I correct?  I would like to 
> force it to use the frame-pointer for a certain functions in a program that I 
> figure out during compile time. Is there a feature to do this? If one doesn't 
> exist, then how much of a major change is this to the GCC mainline for me to 
> add this functionality?

In current gcc, the frame pointer required hook is a function
implemented in the backend.  Your backend can decide, on a
function-by-function basis, whether a frame pointer is required.  It
seems to me that that is what you want.  Please let me know if I
misunderstand.

I'm not sure why you are referring to SUBTARGET_FRAME_POINTER_REQUIRED.
A few backends define that macro, most do not.

Ian