Re: PATCH RFA: Build stages 2 and 3 with C++

2011-07-16 Thread Ian Lance Taylor 
Andrew Pinski  writes:

> On Fri, Jul 15, 2011 at 11:52 PM, Ian Lance Taylor  wrote:
>> I would like to propose this patch as a step toward building gcc using a
>> C++ compiler.  This patch builds stage1 with the C compiler as usual,
>> and defaults to building stages 2 and 3 with a C++ compiler built during
>> stage 1.  This means that the gcc installed and used by most people will
>> be built by a C++ compiler.  This will ensure that gcc is fully
>> buildable with C++, while retaining the ability to bootstrap with only a
>> C compiler, not a C++ compiler.  This will permit us to experiment with
>> optionally using C++ for some code, using a #ifdef to select the C
>> implementation or the C++ implementation.
>>
>> I would suggest that we consider releasing 4.7 this way, as a small
>> trial for building gcc with C++.
>
> Do you build libstdc++ at stage1 also?  That is what happens if you
> don't have a C++ compiler to begin with.

Yes.  With this patch, we build cc1plus at stage 1, and use it to build
libstdc++ at stage 1, and use both to build stage 2.

Ian

Re: PATCH RFA: Build stages 2 and 3 with C++

2011-07-16 Thread Basile Starynkevitch 
On Sat, 16 Jul 2011 00:04:58 -0700
Ian Lance Taylor  wrote:

> Andrew Pinski  writes:
> 
> > On Fri, Jul 15, 2011 at 11:52 PM, Ian Lance Taylor  wrote:
> >> I would like to propose this patch as a step toward building gcc using a
> >> C++ compiler.  This patch builds stage1 with the C compiler as usual,
> >> and defaults to building stages 2 and 3 with a C++ compiler built during
> >> stage 1.  
> >
> > Do you build libstdc++ at stage1 also?  That is what happens if you
> > don't have a C++ compiler to begin with.
> 
> Yes.  With this patch, we build cc1plus at stage 1, and use it to build
> libstdc++ at stage 1, and use both to build stage 2.


I think that we might also want to have some easy & documented way to build the 
stage1
directly with g++, assuming (or when) it is already available.

Regards
-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: Updating the CFG after function modifcation

2011-07-16 Thread Eric Botcazou 
> I have an IPA pass (implemented as a plugin) which executes after all IPA
> passes.  My pass transforms functions by adding code and also modifying the
> function prototypes.  I have had this work on a per-function basis, via a
> GIMPLE_PASS, which calls update_ssa verify_ssa and cleanup_cfg after each
> function is processed.  However, I have recently moved my plugin to execute
> after all IPA passes, so I can iterate over the cfg of the program.

Callgraph, not CFG, of the program.

> The e->call_stmt that the null basic block references is from a statement I
> have removed via gsi_remove during my transformation pass.  I need to clean
> up the cfg somehow, after I remove the statement.  My gimple pass, with
> this same functionality worked fine.  Something tells me that my plugin
> should be in a different position.  I also tried calling cleanup_tree_cfg()
> after my transformation pass, still no luck

Try invoking rebuild_cgraph_edges.

-- 
Eric Botcazou

Re: RFH: Impose code-movement restrictions and value assumption (for ASYNCHRONOUS/Coarrays)

2011-07-16 Thread Richard Guenther 
On Thu, Jul 14, 2011 at 5:31 PM, Michael Matz  wrote:
> Hi,
>
> On Thu, 14 Jul 2011, Richard Guenther wrote:
>
>> Sure ;)  What the middle-end currently lacks is explicit tracking of
>> what escapes through a function return as opposed to what escapes
>> somewhere else.  Once that is implemented a flag on the PARM_DECL that
>> tells it to use Fortran dummy argument rules is easy to implement (but
>> we have issues when that dummy argument is an array descriptor and the
>> dummy argument rules also apply to the actual array data - as opposed
>> to, I presume, a dummy argument of fortran aggregate type with a pointer
>> member).
>
> And the latter is also why such a flag/attribute needs to be ultimately
> placed on the type, so that we can form pointers to such parm_decls (or
> even members of array descriptors) without loosing the special guarantees,
> ala "not clobbered by calls".  That or flags on the MEM_REF (which
> magically needs to be set then, most probably again, by tracking such flag
> from the PARM_DECL, through types to the MEM_REF).
>
>> It's on my list to solve that function-return-escape thing, but as usual
>> my list of things to implement is rather large ;)
>>
>> For the record, the current way of using C restrict works reasonably
>> well and I don't think we will gain very much in real-world performance
>> if not using it
>
> Did you really want to say this?  Because I'm very sure we actually loose
> very much in real-world performance if we wouldn't be using it (or some
> alterntive that is specified somewhat cleaner).

I meant to say if we are not using restrict but another more frontend-specific
flag as suggested.  Not if we drop restrict without replacing it with
anything else.

Richard.

Re: PATCH RFA: Build stages 2 and 3 with C++

2011-07-16 Thread Diego Novillo 
On Sat, Jul 16, 2011 at 02:52, Ian Lance Taylor  wrote:

> 2011-07-15  Ian Lance Taylor  
>
>        * configure.ac: Add --enable-build-poststage1-with-cxx.  If set,
>        make C++ a boot_language.  Set and substitute
>        POSTSTAGE1_CONFIGURE_FLAGS.
>        * Makefile.tpl (POSTSTAGE1_CONFIGURE_FLAGS): New variable.
>        (STAGE[+id+]_CONFIGURE_FLAGS): Add $(POSTSTAGE1_CONFIGURE_FLAGS).
>        * configure, Makefile.in: Rebuild.

I agree with this change.  For reference, have you measured the
difference in bootstrap time?  Clearly, it will be slower, but how
much?


Diego.

[Melt] Runfile Mode and rest of compilation

2011-07-16 Thread Romain Geissler 
Hello,

I just noticed some strange behavior some days ago while trying the HelloWorld 
Melt tutorial. So a file as simple as

(code_chunk trace
#{
printf("Melt file is executed !\n");
}#
)

will print a trace as expected when using with -fmelt-mode=runfile 
-fmet-arg=trace.melt. But it seems that the rest of compilation is canceled, as 
the resulting test.o object file do not have the "main" symbol whereas test.c 
defines a main function. Is this behavior expected ?

Romain Geissler

Re: [Melt] Runfile Mode and rest of compilation

2011-07-16 Thread Basile Starynkevitch 
On Sat, 16 Jul 2011 18:11:07 +0200
Romain Geissler  wrote:

> Hello,
> 
> I just noticed some strange behavior some days ago while trying the 
> HelloWorld Melt tutorial. So a file as simple as
> 
> (code_chunk trace
>   #{
>   printf("Melt file is executed !\n");
>   }#
> )
> 
> will print a trace as expected when using with -fmelt-mode=runfile 
> -fmet-arg=trace.melt. But it seems that the rest of compilation is canceled, 
> as the resulting test.o object file do not have the "main" symbol whereas 
> test.c defines a main function. Is this behavior expected ?


No, you probably hit a bug. I will look at it next week.

Cheers.

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: [Gm2] gnu modula-2 + cygwin compilerfehler.... mit loesung

2011-07-16 Thread Dragiša Durić 
Bilo bi lijepo da se odgovor na ovo pitanje napiše i jezicima ostalih
učesnika na listi pošto ne sumnjam da i druge zanima tematika.

:)

Hvala,
dd

On Fri, 2011-07-15 at 15:38 +0200, Robert Bergermann wrote:
> Hallo gcc@gcc.gnu.org g...@nongnu.org !
> 
> Als erstes moechte ich meine Begeisterung zum Ausdruck bringen, da ich
> mich sehr
> darueber gefreut habe das es einen Modula2-Compiler gibt der recht
> aktuell ist
> und ger gepflegt wird! Super Sache!!
> 
> Aus Bequemlichkeit habe ich versucht gcc-4.1.2+gm2-cvs-latest.tar.gz
> nach der
> Anleitung auf http://www.nongnu.org/gm2/cygwin.html mit Cygwin unter
> Win7 zum
> laufen zu bekommmen. Ist mir auch gelungen, es gab jedoch 2 kleine
> Heraus-
> forderungen. Hier meine Systeminformationen:
> 
> $ ./config.guess
> i686-pc-cygwin
> 
> $ uname -a
> CYGWIN_NT-6.1-WOW64 ASUS 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
> 
> $ gcc -v
> Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
> Configured
> with: /managed/gcc-build/final-v3-bootstrap/gcc-3.4.4-999/configure
> --verbose --program-suffix=-3 --prefix=/usr --exec-prefix=/usr
> --sysconfdir=/etc
> --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-languages=c,ada,c
> ++,d,f77,pascal,java,objc
> --enable-nls --without-included-gettext
> --enable-version-specific-runtime-libs
> --without-x --enable-libgcj --disable-java-awt --with-system-zlib
> --enable-interpreter --disable-libgcj-debug --enable-threads=posix
> --enable-java-gc=boehm --disable-win32-registry
> --enable-sjlj-exceptions
> --enable-hash-synchronization --enable-libstdcxx-debug
> Thread model: posix
> gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
> 
> Die folgende Datei bereitete Probleme
> 
> ~/gcc-4.1.2+gm2-cvs-latest/libiberty/strsignal.c
> 
> die ich wie folgt geloest habe
> 
> In Zeile 31 einfuegen:
> #define DEFS_H 1
> da sonst /usr/include/string.h Zeile 92..94 Probleme bereitet und der
> Compiler mit Fehler abbricht! strsigno in strsignal.c/zeile 467 wird
> auch bereits durch ~/gcc-4.1.2+gm2-cvs-latest/include/libiberty.h als
> "extern const char *strsigno (int);" definiert.
> 
> 
> Zeile 552 aendern in
> psignal (int signo, char *message)
> da unsinged ebenfalls falsch ist und zum Abbruch fuehrt.
> 
> 
> Mit freundlichen Gruessen
> Robert Bergermann
> 
> 
> 
> $ gm2 -v
> Using built-in specs.
> Target: i686-pc-cygwin
> Configured with: ../gcc-4.1.2+gm2-cvs-latest/configure
> --prefix=/opt/gm2 --disable-multilib --enable-checking=all
> --enable-language=c,c++,gm2
> Thread model: single
> gcc version 4.1.2
> 
> $ gm2 --version
> GNU Modula-2  1.0.1  (20110715)
>   grafted onto GCC 4.1.2
> Copyright (C) 2011 Free Software Foundation, Inc.
> License GPLv2: GNU GPL version 2 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> 
> --
> ___
> gm2 mailing list
> g...@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gm2

-- 
Dragiša Durić

Re: PATCH RFA: Build stages 2 and 3 with C++

2011-07-16 Thread Toon Moene 

On 07/16/2011 08:52 AM, Ian Lance Taylor wrote:


I would like to propose this patch as a step toward building gcc using a
C++ compiler.  This patch builds stage1 with the C compiler as usual,
and defaults to building stages 2 and 3 with a C++ compiler built during
stage 1.


I just completed a run using the following language configure options:

../gcc/configure \
...
--enable-build-with-cxx \
--enable-languages=c,c++,fortran,ada \

on x86-64-unknown-linux-gnu.  As far as I can see it was successful:

http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg01852.html

For extra fun, the 0:20 UTC run at home using:

../gcc/configure \
...
--with-build-config=bootstrap-lto \

is going to use Ada as a language *of choice* instead of Fortran based 
on the value of $RANDOM in the bash shell :-)


language=fortran
if [ $RANDOM -lt 16384 ]
then
   language=ada
fi

../gcc/configure \
--prefix=/tmp/lto \
--enable-languages=$language \
--with-build-config=bootstrap-lto \

I'll see you tomorrow (evil cackle) :-)

All this is using:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-1' 
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr 
--program-suffix=-4.6 --enable-shared --enable-multiarch 
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id 
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu 
--without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.6 
--libdir=/usr/lib/x86_64-linux-gnu --enable-nls --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin 
--enable-objc-gc --with-arch-32=i586 --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu

Thread model: posix
gcc version 4.6.1 (Debian 4.6.1-1)

toon@super:~$ gnat -v
GNAT 4.6.1
...

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

possible race condition in make install?

2011-07-16 Thread Jack Howarth 
   I have had a report of i386 darwin10 failing to build gcc 4.4.6 in fink 
which I've reproduced
myself. The failure looks quite odd...

/usr/bin/install -c -m 644 ./libiberty.a 
/sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/`/sw/src/fink.build/gcc44-4.4.6-1001/darwin_objdir/./gcc/xgcc
 -B/sw/src/fink.build/gcc44-4.4.6-1001/darwin_objdir/./gcc/ 
-B/sw/lib/gcc4.4/i386-apple-darwin10.8.0/bin/ 
-B/sw/lib/gcc4.4/i386-apple-darwin10.8.0/lib/ -isystem 
/sw/lib/gcc4.4/i386-apple-darwin10.8.0/include -isystem 
/sw/lib/gcc4.4/i386-apple-darwin10.8.0/sys-include -g -O2   
-print-multi-os-directory`/./libiberty.an
mkdir /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/share/locale/zh_TW
mkdir 
/sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/share/locale/zh_TW/LC_MESSAGES
libtool: install: /usr/bin/install -c .libs/libssp.0.dylib 
/sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/x86_64/libssp.0.dylib
libtool: install: (cd 
/sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/x86_64 && { ln -s -f 
libssp.0.dylib libssp.dylib || { rm -f libssp.dylib && ln -s libssp.0.dylib 
libssp.dylib; }; })
libtool: install: /usr/bin/install -c .libs/libssp.lai 
/sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/x86_64/libssp.la
libtool: install: /usr/bin/install -c .libs/libssp.a 
/sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/x86_64/libssp.a
( cd /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/`gcc -g -O2 
-print-multi-os-directory` ; chmod 644 ./libiberty.an ;ranlib ./libiberty.an )
libtool: install: chmod 644 
/sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/x86_64/libssp.a
ranlib: file: ./libiberty.an is not an archive
libtool: install: ranlib -c 
/sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/x86_64/libssp.a
make[2]: *** [install_to_libdir] Error 1
make[1]: *** [install-libiberty] Error 2
make[1]: *** Waiting for unfinished jobs

and only occurs with parallel builds. Is it possible that the command...

/usr/bin/install -c -m 644 ./libiberty.a 
/sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/`/sw/src/fink.build/gcc44-4.4.6-1001/darwin_objdir/./gcc/xgcc
 -B/sw/src/fink.build/gcc44-4.4.6-1001/darwin_objdir/./gcc/ 
-B/sw/lib/gcc4.4/i386-apple-darwin10.8.0/bin/ 
-B/sw/lib/gcc4.4/i386-apple-darwin10.8.0/lib/ -isystem 
/sw/lib/gcc4.4/i386-apple-darwin10.8.0/include -isystem 
/sw/lib/gcc4.4/i386-apple-darwin10.8.0/sys-include -g -O2   
-print-multi-os-directory`/./libiberty.an

could be in a race condition with the later command...

( cd /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/`gcc -g -O2 
-print-multi-os-directory` ; chmod 644 ./libiberty.an ;ranlib ./libiberty.an )

if so what can be done about this. So far the only work around I've found is to 
use the --disable-java-multilib patch ala redhat
which seems to cause this issue to go latant again. Any ideas?
  Jack

Re: possible race condition in make install?

2011-07-16 Thread Jack Howarth 
On Sat, Jul 16, 2011 at 04:40:22PM -0400, Jack Howarth wrote:
>I have had a report of i386 darwin10 failing to build gcc 4.4.6 in fink 
> which I've reproduced
> myself. The failure looks quite odd...
> 
> /usr/bin/install -c -m 644 ./libiberty.a 
> /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/`/sw/src/fink.build/gcc44-4.4.6-1001/darwin_objdir/./gcc/xgcc
>  -B/sw/src/fink.build/gcc44-4.4.6-1001/darwin_objdir/./gcc/ 
> -B/sw/lib/gcc4.4/i386-apple-darwin10.8.0/bin/ 
> -B/sw/lib/gcc4.4/i386-apple-darwin10.8.0/lib/ -isystem 
> /sw/lib/gcc4.4/i386-apple-darwin10.8.0/include -isystem 
> /sw/lib/gcc4.4/i386-apple-darwin10.8.0/sys-include -g -O2   
> -print-multi-os-directory`/./libiberty.an
> mkdir 
> /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/share/locale/zh_TW
> mkdir 
> /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/share/locale/zh_TW/LC_MESSAGES
> libtool: install: /usr/bin/install -c .libs/libssp.0.dylib 
> /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/x86_64/libssp.0.dylib
> libtool: install: (cd 
> /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/x86_64 && { ln -s 
> -f libssp.0.dylib libssp.dylib || { rm -f libssp.dylib && ln -s 
> libssp.0.dylib libssp.dylib; }; })
> libtool: install: /usr/bin/install -c .libs/libssp.lai 
> /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/x86_64/libssp.la
> libtool: install: /usr/bin/install -c .libs/libssp.a 
> /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/x86_64/libssp.a
> ( cd /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/`gcc -g -O2 
> -print-multi-os-directory` ; chmod 644 ./libiberty.an ;ranlib ./libiberty.an )
> libtool: install: chmod 644 
> /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/x86_64/libssp.a
> ranlib: file: ./libiberty.an is not an archive
> libtool: install: ranlib -c 
> /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/x86_64/libssp.a
> make[2]: *** [install_to_libdir] Error 1
> make[1]: *** [install-libiberty] Error 2
> make[1]: *** Waiting for unfinished jobs
> 
> and only occurs with parallel builds. Is it possible that the command...
> 
> /usr/bin/install -c -m 644 ./libiberty.a 
> /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/`/sw/src/fink.build/gcc44-4.4.6-1001/darwin_objdir/./gcc/xgcc
>  -B/sw/src/fink.build/gcc44-4.4.6-1001/darwin_objdir/./gcc/ 
> -B/sw/lib/gcc4.4/i386-apple-darwin10.8.0/bin/ 
> -B/sw/lib/gcc4.4/i386-apple-darwin10.8.0/lib/ -isystem 
> /sw/lib/gcc4.4/i386-apple-darwin10.8.0/include -isystem 
> /sw/lib/gcc4.4/i386-apple-darwin10.8.0/sys-include -g -O2   
> -print-multi-os-directory`/./libiberty.an
> 
> could be in a race condition with the later command...
> 
> ( cd /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/`gcc -g -O2 
> -print-multi-os-directory` ; chmod 644 ./libiberty.an ;ranlib ./libiberty.an )
> 
> if so what can be done about this. So far the only work around I've found is 
> to use the --disable-java-multilib patch ala redhat
> which seems to cause this issue to go latant again. Any ideas?
>   Jack

 Also, I assume that this issue is coming from gcc-4.4.6/libiberty/Makefile.in 
at this section...

# This is tricky.  Even though CC in the Makefile contains
# multilib-specific flags, it's overridden by FLAGS_TO_PASS from the
# default multilib, so we have to take CFLAGS into account as well,
# since it will be passed the multilib flags.
MULTIOSDIR = `$(CC) $(CFLAGS) -print-multi-os-directory`
install_to_libdir: all
${mkinstalldirs} $(DESTDIR)$(libdir)/$(MULTIOSDIR)
$(INSTALL_DATA) $(TARGETLIB) 
$(DESTDIR)$(libdir)/$(MULTIOSDIR)/$(TARGETLIB)n
( cd $(DESTDIR)$(libdir)/$(MULTIOSDIR) ; chmod 644 $(TARGETLIB)n 
;$(RANLIB) $(TARGETLIB)n )
mv -f $(DESTDIR)$(libdir)/$(MULTIOSDIR)/$(TARGETLIB)n 
$(DESTDIR)$(libdir)/$(MULTIOSDIR)/$(TARGETLIB)
if test -n "${target_header_dir}"; then \
  case "${target_header_dir}" in \
/*)thd=${target_header_dir};; \
*) thd=${includedir}/${target_header_dir};; \
  esac; \
  ${mkinstalldirs} $(DESTDIR)$${thd}; \
  for h in ${INSTALLED_HEADERS}; do \
${INSTALL_DATA} $$h $(DESTDIR)$${thd}; \
  done; \
fi
@$(MULTIDO) $(FLAGS_TO_PASS) multi-do DO=install

I'm not very familar with the finer points of adjusting Makefile.in's to be 
parallel make friendly.
What keeps...

$(INSTALL_DATA) $(TARGETLIB) $(DESTDIR)$(libdir)/$(MULTIOSDIR)/$(TARGETLIB)n

from outrunning the execution of the next command...

( cd $(DESTDIR)$(libdir)/$(MULTIOSDIR) ; chmod 644 $(TARGETLIB)n 
;$(RANLIB) $(TARGETLIB)n )

on a multiprocessor machine with parallel make?
  Jack

Re: GSOC - Student Roundup

2011-07-16 Thread Gerald Pfeifer 
Pierre,

On Wed, 6 Jul 2011, Pierre Vittet wrote:
> I feel sad, not being able to use IRC from my web access (in my 
> school)... and so only communicating by mail with the GCC community. 

are you aware of http://www.mibbit.com/ and similar clients, that just
use plain http, or are you saying that, too, is being blocked by your
school?  (I just tried the above, and it works fine for me.)
 
Gerald

gcc-4.7-20110716 is now available

2011-07-16 Thread gccadmin 
Snapshot gcc-4.7-20110716 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20110716/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 176360

You'll find:

 gcc-4.7-20110716.tar.bz2 Complete GCC

  MD5=fb651a68a1334e24ddc59f7a93904898
  SHA1=ae862d1089c7b94ba86b09253287c0d7669d4562

Diffs from 4.7-20110709 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.7
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: PATCH RFA: Build stages 2 and 3 with C++

2011-07-16 Thread Ian Lance Taylor 
Diego Novillo  writes:

> On Sat, Jul 16, 2011 at 02:52, Ian Lance Taylor  wrote:
>
>> 2011-07-15  Ian Lance Taylor  
>>
>>        * configure.ac: Add --enable-build-poststage1-with-cxx.  If set,
>>        make C++ a boot_language.  Set and substitute
>>        POSTSTAGE1_CONFIGURE_FLAGS.
>>        * Makefile.tpl (POSTSTAGE1_CONFIGURE_FLAGS): New variable.
>>        (STAGE[+id+]_CONFIGURE_FLAGS): Add $(POSTSTAGE1_CONFIGURE_FLAGS).
>>        * configure, Makefile.in: Rebuild.
>
> I agree with this change.  For reference, have you measured the
> difference in bootstrap time?  Clearly, it will be slower, but how
> much?

I have not measured the change in bootstrap time, no.

Ian

Re: PATCH RFA: Build stages 2 and 3 with C++

2011-07-16 Thread Ian Lance Taylor 
Basile Starynkevitch  writes:

> I think that we might also want to have some easy & documented way to build 
> the stage1
> directly with g++, assuming (or when) it is already available.

We already do: configure with --enable-build-with-cxx.

Ian

PARM_DECL to SSA_NAME

2011-07-16 Thread Matt Davis 
Hello,
I have a PARM_DECL node that I am passing to a function.  Previously, my code
was working, but since I have made my optimization pass operate as an IPA pass,
versus a GIMPLE pass, I think I am missing some verification/resolution call
that I need to make.

Of course, when I pass the PARM_DECL to my function, I am now getting an error
from verify_ssa() suggesting that I should be passing a SSA_NAME instance.  I 
tried
using gimple_default_def() to obtain the SSA_NAME for that PARM_DECL, however,
the return value is NULL.  Is there some other way of accessing the SSA_NAME
information for this PARM_DECL node?  The SSA has been generated before my 
plugin
executes.  Also, I do call update_ssa() after the routines are processed by my
passes.

Thanks for any insight.

-Matt