incorrect redundency of loading subreg of physical regs
Hello, I cannot figure out how the entire mechaism works in my case. I work on 4.5.2. e.g. I have 64 registers. But sometimes I need to 2 kinds of instructions (Xand Y)to fill these 64-bit registers. X fills the low 32 bit and Y fills the high 32 bit. I try to use subreg for the RTL patterns of X and Y. insn1 (set (subreg:SI (reg:DI) 0) (reg:SI)) insn2 (set (subreg:SI (reg:DI) 4) (reg:SI)) < Y rtl setting the high 32 bit> the problem is that register allocation seems to allocate the same register to both insns, and after register allocation (or more precisely postreload), I lose the subreg info in rtl. This makes the later phases think that insn2 kills insn1 and then insn1 is deleted. Can you give me some suggestion how to solve this problem? I can think of many possible solutions but I don't know what is the better one. how to let the compiler know that insn2 and insn1 write to the different parts of the same reg and insn1 should be retained? gcc internal says that use of subreg for physical regs are not encouraged. why? is that the reason that subreg is removed after IRA? if I use subreg of physical reg, will the phases avoid the incorrect code elimination problem? ordo I need some extra work to teach the later phases to work on subreg of physical regs? any example about supporting subreg of physical regs? thanks
Re: GNU MPC 1.0 release candidate
On 07/14/2012 11:02 AM, Mikael Pettersson wrote: > Andreas Enge writes: > > We are pleased to announce the immediate availability of the first release > > candidate for GNU MPC 1.0 at > >http://www.multiprecision.org/mpc/download/mpc-1.0.0rc1.tar.gz > >sha1sum 9acc8a54ba4ecd0ccf172c0d07fcc218220e79a3 > > > > Reports on successful installations and potential problems are very > welcome; > > please include the configuration triple of your platform, and the gcc, gmp > > and mpfr versions used (these are output at the end of 'make check'). > > > > The status of successful and failed builds can be seen at > >http://www.multiprecision.org/index.php?prog=mpc&page=platforms > > > > In particular, we need to compile on the primary and secondary gcc > platforms > > before the release. > > > > Thank you very much for your help, If this works well we should change the defaults in contrib/dlownload_prerequisites. Andrew.
Re: GNU MPC 1.0 release candidate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Enge inria.fr> writes: > We are pleased to announce the immediate availability of the first release > candidate for GNU MPC 1.0 at > http://www.multiprecision.org/mpc/download/mpc-1.0.0rc1.tar.gz sha1sum > 9acc8a54ba4ecd0ccf172c0d07fcc218220e79a3 > > Reports on successful installations and potential problems are very > welcome; please include the configuration triple of your platform, and the > gcc, gmp and mpfr versions used (these are output at the end of 'make > check'). > > The status of successful and failed builds can be seen at > http://www.multiprecision.org/index.php?prog=mpc&page=platforms > > In particular, we need to compile on the primary and secondary gcc > platforms before the release. > > Thank you very much for your help, > > Andreas Testing on x86_64-w64-mingw32: GMP: include 5.0.5, lib 5.0.5 MPFR: include 3.1.1, lib 3.1.1 MPC: include 1.0.0rc1, lib 1.0.0rc1 C compiler: gcc GCC: yes GCC version: 4.7.1 PASS: tget_version.exe === All 64 tests passed === Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAD1TwACgkQoUhjsh59BL4ANwCfVeB0xZzXP1WlnxI90/56+vei YTQAoMhxvFp2oVwUddVBEyg2A4VAb6mh =9qBk -END PGP SIGNATURE-
Re: The documentation of option -flto-partition=alg
On Sat, Jul 14, 2012 at 5:00 PM, Toon Moene wrote: > I have been using the option -flto-partition=none recently (with Debian > testing's gcc-4.7.1-2), but I'm not convinced - based on the documentation - > that I am using it correctly. > > I have: > > for C source code: > > CCFLAGS := -g -Ofast -flto -march=native -mtune=native > > for Fortran source code: > > FCFLAGS := -g -Ofast -flto -fprotect-parens -fbacktrace -march=native > -mtune=native -I$(HOME)/netcdf/include > > and for the final link stage: > > LDFLAGS := -g -Ofast -flto -flto-partition=none -fuse-linker-plugin > -fprotect-parens -fbacktrace -march=native -mtune=native > > 1. Is it correct to assume that -flto-partition=alg is only necessary during > the final link stage ? If so, shouldn't that be made clear in the > documentation ? Yes, -flto-partition is only relevant at link stage > 2. What is the relation with -flto=n; doesn't no-partitioning imply -flto=1 > ? If so, shouldn't that be made clear in the documentation ? -flto=n is just on how to parallelize the compile done at link stage. If you specify -flto-partition=none there is nothing to parallelize. For the default -flto-partition setting we generate up to 24 ltrans files (or was 42?) which are then built by make -jN (for -flto=N) or by means of picking up make flags (for -flto=jobserver). Richard. > -- > 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
Re: Allow use of ranges in copyright notices
I have now committed this patch to allow the use of ranges. -- Joseph S. Myers jos...@codesourcery.com
sync top level configure to binutils
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 binutils head top level configure still requires ppl. Now as the changes for ppl, isl and cloog are in, I think it's time to sync to binutils. Any comments? Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAELukACgkQoUhjsh59BL4Q+ACgjOWVXcBI+4+5pE+1POp9Y/o5 4VoAoLVsb8TT3JEsqput1Xg4MJQ/ZOyn =o2Lv -END PGP SIGNATURE-
Re: sync top level configure to binutils
On Mon, 16 Jul 2012, Rainer Emrich wrote: > binutils head top level configure still requires ppl. > Now as the changes for ppl, isl and cloog are in, I think it's > time to sync to binutils. Any comments? Both trees seem to have local changes not in the other, so it's not just a matter of copying from one tree to the other; someone needs to identify the specific patches needing applying to each tree to get them back in sync. -- Joseph S. Myers jos...@codesourcery.com
get email addr from username (was: Ad-hoc notes from the "pending patches" BOF at the GNU tools cauldron.)
Hello, I'm trying to write a small script that shows emails addresses for all committers of last year, for all files a patch touches. In the commit logs however all committers are referred to by username, and grepping the MAINTAINERS files sometimes doesn't bring up any email address (e.g. grep for jsm28). Any idea how I can get email address for a username? Thanks, Dimitris
Re: sync top level configure to binutils
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 16.07.2012 17:30, schrieb Joseph S. Myers: > On Mon, 16 Jul 2012, Rainer Emrich wrote: > >> binutils head top level configure still requires ppl. Now as the changes >> for ppl, isl and cloog are in, I think it's time to sync to binutils. Any >> comments? > > Both trees seem to have local changes not in the other, so it's not just a > matter of copying from one tree to the other; someone needs to identify > the specific patches needing applying to each tree to get them back in > sync. > Is a single patch for the configure machinery to apply the changes for ppl, isl and cloog on the binutils side acceptable? Richard Günther submitted the relevant changes between 2nd and 6th of July. Revision 189155, 189156, 189157, 189159, 189209, 189212, 189327 and 189328. Changes in the following files: configure.ac Makefile.def Makefile.tpl config/cloog.m4 New file: config/isl.m4 Regeneration of the dependend files. If acceptable I would like to prepare a patch. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAERm4ACgkQoUhjsh59BL7uDACgk/YFooidHeKZ3QIrUkJJWOwa 7CQAn1kweNKw8EtEYc6jFNa2Hu2OzEhN =Gfqg -END PGP SIGNATURE-
Re: get email addr from username (was: Ad-hoc notes from the "pending patches" BOF at the GNU tools cauldron.)
On Jul 16, 2012 5:28 PM, "Dimitrios Apostolou" wrote: > > Hello, > > I'm trying to write a small script that shows emails addresses for all > committers of last year, for all files a patch touches. In the commit logs > however all committers are referred to by username, and grepping the > MAINTAINERS files sometimes doesn't bring up any email address (e.g. grep for > jsm28). > > Any idea how I can get email address for a username? Add @gcc.gnu.org to it?
Re: problems in interaction between peephole on CALL_INSN and final_scan_insn
On 07/08/2012 02:46 PM, Alan Lehotsky wrote: > Or are you just talking about defining a sibcall_epilogue pattern? ... and appropriate sibcall + sibcall_value patterns, yes. I.e. add the patterns such that you enable the generic tail-call optimizations within the compiler, rather than trying to pattern match two adjacent insns quite late. r~
