Re: SSE2 generation bug with 4.1.2 and -O3
Am Samstag 17 März 2007 schrieb Prakash Punnoor: > Now filed under > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31245 > > at David's request. I noticed another SSE2 related bug, filed under http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31361 -- (°= =°) //\ Prakash Punnoor /\\ V_/ \_V pgpNS2HfTZega.pgp Description: PGP signature
Re: A question on ACX_BUGURL
Paolo Bonzini <[EMAIL PROTECTED]> writes:
>> + no) BUGURL="";
>
> just BUGURL= (no useless trailing semicolon).
>
>> + case ${BUGURL} in
>
> Please quote this as "$BUGURL".
That would be useless quotes. :-)
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: A question on ACX_BUGURL
Andreas Schwab wrote:
> Paolo Bonzini <[EMAIL PROTECTED]> writes:
>
>>> + no) BUGURL="";
>> just BUGURL= (no useless trailing semicolon).
>>
>>> + case ${BUGURL} in
>> Please quote this as "$BUGURL".
>
> That would be useless quotes. :-)
Uh, you're right. Word split does not apply in a case
statement too; I had forgotten about that. Thanks.
Paolo
how to obtain SSA form
hi all, I'm trying to make some optimizations in gcc, and I need to manipulate control flow graph when code is translated in SSA form. I wrote optimization code, but I noticed that when my code is executed the code isn't in SSA form, it's only in GIMPLE form. How can I obtain the SSA form to apply my code? Is there an option from command line, or any flag to be setted? Thanks to all Andrea
Re: 4.3 bootstrap broken on i386-linux
FX Coudert writes: > Hi all, > > My nightly bootstrap of mainline on i386-linux failed tonight, on > revision 123192, with: > > /home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../libdecnumber/ > decLibrary.c: In function ?isinfd64?: > /home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../libdecnumber/ > decLibrary.c:65: error: unrecognizable insn: > (insn 11 10 12 3 /home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../ > libdecnumber/decLibrary.c:62 (set (reg/f:SI 61) > (pre_dec:SI (reg/f:SI 7 sp))) -1 (nil) > (nil)) > /home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../libdecnumber/ > decLibrary.c:65: internal compiler error: in extract_insn, at recog.c: > 2119 > > The last revision known to compile OK on that particular setup was: > 123178. I filed it as PR 31344 in bugzilla. The compilation fails for > -mtune=i[345]86 while it doesn't ICE for -mtune=i686. I see another bootstrap failure with a compiler configured for i486-linux-gnu. configure --enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang --prefix=/usr/lib/gcc-snapshot --enable-shared --with-system-zlib --disable-nls --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-maintainer-mode --enable-java-awt=gtk --enable-gtk-cairo --enable-plugin --with-java-home=/usr/lib/gcc-snapshot/jre --with-ecj-jar=/usr/share/java/ecj.jar --enable-mpfr --disable-werror --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu [...] /scratch/packages/gcc/snap/gcc-snapshot-20070326/build/./gcc/xgcc -B/scratch/packages/gcc/snap/gcc-snapshot-20070326/build/./gcc/ -B/usr/lib/gcc-snapshot/i486-linux-gnu/bin/ -B/usr/lib/gcc-snapshot/i486-linux-gnu/lib/ -isystem /usr/lib/gcc-snapshot/i486-linux-gnu/include -isystem /usr/lib/gcc-snapshot/i486-linux-gnu/sys-include -g -fkeep-inline-functions -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../src/libgcc -I../../../src/libgcc/. -I../../../src/libgcc/../gcc -I../../../src/libgcc/../include -I../../../src/libgcc/../libdecnumber/no -I../../../src/libgcc/../libdecnumber -I../../libdecnumber -o decLibrary.o -MT decLibrary.o -MD -MP -MF decLibrary.dep -c ../../../src/libgcc/../libdecnumber/decLibrary.c ../../../src/libgcc/../libdecnumber/decLibrary.c:32:24: error: decimal128.h: No such file or directory ../../../src/libgcc/../libdecnumber/decLibrary.c:33:23: error: decimal64.h: No such file or directory ../../../src/libgcc/../libdecnumber/decLibrary.c:34:23: error: decimal32.h: No such file or directory ../../../src/libgcc/../libdecnumber/decLibrary.c:36: error: expected declaration specifiers or '...' before 'decimal32' ../../../src/libgcc/../libdecnumber/decLibrary.c:37: error: expected declaration specifiers or '...' before 'decimal64' ../../../src/libgcc/../libdecnumber/decLibrary.c:38: error: expected declaration specifiers or '...' before 'decimal128' ../../../src/libgcc/../libdecnumber/decLibrary.c: In function 'isinfd32': ../../../src/libgcc/../libdecnumber/decLibrary.c:48: error: 'decNumber' undeclared (first use in this function) ../../../src/libgcc/../libdecnumber/decLibrary.c:48: error: (Each undeclared identifier is reported only once ../../../src/libgcc/../libdecnumber/decLibrary.c:48: error: for each function it appears in.) ../../../src/libgcc/../libdecnumber/decLibrary.c:48: error: expected ';' before 'dn' ../../../src/libgcc/../libdecnumber/decLibrary.c:49: error: 'decimal32' undeclared (first use in this function) ../../../src/libgcc/../libdecnumber/decLibrary.c:49: error: expected ';' before 'd32' ../../../src/libgcc/../libdecnumber/decLibrary.c:51: error: 'd32' undeclared (first use in this function) ../../../src/libgcc/../libdecnumber/decLibrary.c:51: error: too many arguments to function '__host_to_ieee_32' ../../../src/libgcc/../libdecnumber/decLibrary.c:52: warning: implicit declaration of function 'decimal32ToNumber' ../../../src/libgcc/../libdecnumber/decLibrary.c:52: error: 'dn' undeclared (first use in this function) ../../../src/libgcc/../libdecnumber/decLibrary.c:53: warning: implicit declaration of function 'decNumberIsInfinite' ../../../src/libgcc/../libdecnumber/decLibrary.c: In function 'isinfd64': ../../../src/libgcc/../libdecnumber/decLibrary.c:59: error: 'decNumber' undeclared (first use in this function) ../../../src/libgcc/../libdecnumber/decLibrary.c:59: error: expected ';' before 'dn' ../../../src/libgcc/../libdecnumber/decLibrary.c:60: error: 'decimal64' undeclared (first use in this
Re: how to obtain SSA form
On 3/26/07, Andrea Callia D'Iddio <[EMAIL PROTECTED]> wrote: I'm trying to make some optimizations in gcc, and I need to manipulate control flow graph when code is translated in SSA form. I wrote optimization code, but I noticed that when my code is executed the code isn't in SSA form, it's only in GIMPLE form. How can I obtain the SSA form to apply my code? Is there an option from command line, or any flag to be setted? See passes.c, look for "into" and "ssa". Gr. Steven
Where is ld.so and libdl.so built from
In gcc packages, I could not find ld.so and libdl.so Binutils only contains ld. Where can I find the gnu source code for libdl.so and ld.so Thanks Mayank
Re: [patch] generated string libraries & -Wformat
On Sun, 25 Mar 2007, Mark Mitchell wrote: > Joseph S. Myers wrote: > > On Sat, 24 Mar 2007, Bruce Korb wrote: > > > >> This bootstraps in Linux i686 & I can use -Wno-format-contains-nul to > >> suppress that warning. OK? > > > > This is not a complete patch submission, I await one with documentation > > and testcases (both for the option disabling the diagnostic and for the > > use of -Wformat-contains-nul being diagnosed just as other such "ignored > > without" diagnostics are tested in gcc.dg/format/opt-*.c). > > But, you do think the option is useful overall, then, and that Bruce > should proceed with the additional steps you mention? I have no > opinion, but it might help Bruce to know for sure whether he's heading > in a direction you're likely to approve. Yes, I think it makes sense in principle (and the existing patch is probably a reasonable start on the implementation). -- Joseph S. Myers [EMAIL PROTECTED]
Google Summer of Code: Mentor wanted for Fortran project
Hello, I just applied to Google Summer of Code for working on GCC this summer. I want to implement some Fortran 2003 features, in particular procedure pointers and type-bound procedures. You can find my complete application at http://www.stud.uni-giessen.de/~su5092/gsoc/application.pdf Now I learned that there are currently no Fortran developers signed up as SoC mentors for GCC. It would be really great if someone with a decent knowledge of gfortran would be willing to be my mentor, so I can work on this project. This really wouldn't take up too much of your time. I just need someone to answer some of my questions every now and then and to give me some hints on how to proceed. For more info on the SoC program, check out http://code.google.com/soc/. I would be very grateful if someone could do the job. I really think gfortran urgently needs some decent object oriented features. Cheers, Janus
Re: A question on ACX_BUGURL
On Mon, Mar 26, 2007 at 09:13:30AM +0200, Paolo Bonzini wrote: > Please do this instead: > > [EMAIL PROTECTED] "$BUGURL" | sed 's/@/@@/g'`} > Will it work with spaces in $BUGURL? H.J.
Re: Adding Profiling support - GCC 4.1.1
Jim Wilson wrote: Rohit Arul Raj wrote: 1. The function mcount: While building with native gcc, the mcount function is defined in glibc. Is the same mcount function available in newlib? or is it that we have to define it in our back-end as SPARC does (gmon-sol2.c). Did you try looking at newlib? Try something like this find . -type f | xargs grep mcount That will show you all of the mcount support in newlib/libgloss. sparc-solaris is a special case. Early versions of Solaris shipped without the necessary support files. (Maybe it still does? I don't know, and don't care to check.) I think that there were part of the add-on extra-cost compiler. This meant that people using gcc only were not able to use profiling unless gcc provided the mcount library. Otherwise it never would have been put here. mcount belongs in the C library. 2. Is it possible to reuse the existing mcount definition or is it customized for every backend? It must be customized for every backend. 3. Any other existing back-ends that support profiling. Pretty much all targets do, at least ones for operating systems. It is much harder to make mcount work for an embedded target with no file system. If you want to learn how mcount works, just pick any existing target with mcount support, and study it. You might take a look at the profiling support in the GNU tool chain for the Xscale that Intel distributes. There was some support to use GDB to read the required information out of the embedded target even if it didn't have a file system. -Will
Re: A question on ACX_BUGURL
H. J. Lu wrote: > On Mon, Mar 26, 2007 at 09:13:30AM +0200, Paolo Bonzini wrote: >> Please do this instead: >> >> [EMAIL PROTECTED] "$BUGURL" | sed 's/@/@@/g'`} >> > > Will it work with spaces in $BUGURL? Yes, it will. You need quoting in the echo command, but not in the variable assignment. Quoting both the echo command-line and the variable assignment is not portable. Variable assignments (and case statements, as Andreas pointed out) do not perform word splitting of variables. Paolo
Re: Application for Google Summer of Code with GCC.
Dmitry Zhurikhin wrote: Hello, I want to propose a project for Google Summer of Code on title "New static scheduling heuristic". I hope that Vlad Makarov from Redhat or Andrey Belevantsev from ISP RAS will menthor this application. I will appreciate any feedback and will try to answer any questions regarding my application. Dmitry, I've just submitted my application to be a mentor of this project. You definetly have an experience to do this work and the project is of right size for SoC. Although it is more a research project with unknown outcome. It is always hard to predict how heuristic will work finaly (will they be better). But your project addresses to real and well known problems of widely used insn scheduler heuristics and somebody should do this work for gcc. Vlad
Re: gcc4.1 compilation issue on solaris 10
> "Nitesh" == Nitesh Shende <[EMAIL PROTECTED]> writes: Nitesh> I am trying to build gcc with java support on solaris 10 I am getting Nitesh> lot of errors Sorry, there isn't enough information here to go by. Make sure you've followed all the build instructions: http://gcc.gnu.org/install/ ... including the special ones for Solaris, if any. If that still fails, report the exact error message you got, along with all your system config information. Please read: http://gcc.gnu.org/bugs.html Nitesh> This e-mail is bound by the terms and conditions described at Nitesh> http://www.subexazure.com/mail-disclaimer.html I didn't read this, but you may want to look at: http://gcc.gnu.org/lists.html#policies thanks, Tom
Re: [patch] generated string libraries & -Wformat
On 3/26/07, Joseph S. Myers <[EMAIL PROTECTED]> wrote: > > use of -Wformat-contains-nul > > But, you do think the option is useful overall, then, and that Bruce > should proceed with the additional steps you mention? Yes, I think it makes sense in principle (and the existing patch is probably a reasonable start on the implementation). Thank you, Joseph. I'll take a swing at getting it polished next weekend. - Bruce
Re: 4.3 bootstrap broken on i386-linux
* Matthias Klose <[EMAIL PROTECTED]> [2007-03-26 12:39]: > I see another bootstrap failure with a compiler configured for > i486-linux-gnu. > > ../../../src/libgcc/../libdecnumber/decLibrary.c:36: error: expected > declaration specifiers or '...' before 'decimal32' I found the reason for this yesterday; hopefully HJL or Michael will fix it soon. See http://gcc.gnu.org/ml/gcc/2007-03/msg00941.html -- Martin Michlmayr [EMAIL PROTECTED]
Re: 4.3 bootstrap broken on i386-linux
Hello, I get similar error with recent mainline on PPC. ../../../../gcc/libgcc/../libdecnumber/decLibrary.c:71: error: expected ';' before 'd128' ../../../../gcc/libgcc/../libdecnumber/decLibrary.c:73: error: 'd128' undeclared (first use in this function) ../../../../gcc/libgcc/../libdecnumber/decLibrary.c:73: error: too many arguments to function '_128' ../../../../gcc/libgcc/../libdecnumber/decLibrary.c:74: warning: implicit declaration of function 'decimal128ToNumber' ../../../../gcc/libgcc/../libdecnumber/decLibrary.c:74: error: 'dn' undeclared (first use in this function) make[4]: *** [decLibrary.o] Error 1 make[4]: Leaving directory `/home/eres/spec_store_cpp_dse/build/ppc64-yellowdog-linux/64/libgcc' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/home/eres/spec_store_cpp_dse/build/ppc64-yellowdog-linux/libgcc' make[2]: *** [all-multi] Error 2 make[2]: Leaving directory `/home/eres/spec_store_cpp_dse/build/ppc64-yellowdog-linux/libgcc' make[1]: *** [all-target-libgcc] Error 2 Revital
Re: Where is ld.so and libdl.so built from
On 3/26/07, Mayank Kumar <[EMAIL PROTECTED]> wrote: In gcc packages, I could not find ld.so and libdl.so Binutils only contains ld. Where can I find the gnu source code for libdl.so and ld.so They come from glibc which I doubt MS uses as they have their own shared library (dll) loader and libc. -- pinski
Re: SoC Project: Propagating array data dependencies from Tree-SSA to RTL
On Sun, 25 Mar 2007, Daniel Berlin wrote: Ayal has not signed up to be a mentor (as of yet). If he doesn't, i'd be happy to mentor you here, since i wrote part of tree-data-ref.c Thanks, I'll be very glad to work with you. On Mon, 26 Mar 2007, Ayal Zaks wrote: Sorry, I fear I may have too little time to devote to this; plus, it would be very useful to start with a good understanding of tree-data-ref from which to start propagating the dep info. Vladimir Yanovsky and I will be able to help when it comes to what/how to feed the modulo scheduler. Thank you for your attention. I hope I will have a chance to ask you for help in the frame of GSoC project. -- Alexander Monakov
RE: Where is ld.so and libdl.so built from
Thanks for this information. I wanted to take a look at the code. Yes MS has its own shared library loader and libc. Thanks Mayank -Original Message- From: Andrew Pinski [mailto:[EMAIL PROTECTED] Sent: Monday, March 26, 2007 9:36 PM To: Mayank Kumar Cc: gcc@gcc.gnu.org Subject: Re: Where is ld.so and libdl.so built from On 3/26/07, Mayank Kumar <[EMAIL PROTECTED]> wrote: > In gcc packages, I could not find ld.so and libdl.so > Binutils only contains ld. > > Where can I find the gnu source code for libdl.so and ld.so They come from glibc which I doubt MS uses as they have their own shared library (dll) loader and libc. -- pinski
Re: --disable-multilib broken on x86_64
On Sat, Mar 24, 2007 at 07:01:40PM +, Martin Michlmayr wrote: > The following change broke --disable-multilib: > > 2007-03-23 Michael Meissner <[EMAIL PROTECTED]> > H.J. Lu <[EMAIL PROTECTED]> > > ../src/configure --enable-languages=c --disable-multilib x86_64-linux-gnu > > /home/tbm/build/gcc-snapshot-20070324/build/./gcc/xgcc > -B/home/tbm/build/gcc-snapshot-20070324/build/./gcc/ > -B/usr/lib/gcc-snapshot/x86_64-linux-gnu/bin/ > -B/usr/lib/gcc-snapshot/x86_64-linux-gnu/lib/ -isystem > /usr/lib/gcc-snapshot/x86_64-linux-gnu/include -isystem > /usr/lib/gcc-snapshot/x86_64-linux-gnu/sys-include -g -fkeep-inline-functions > -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g > -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. > -I../.././gcc -I../../../src/libgcc -I../../../src/libgcc/. > -I../../../src/libgcc/../gcc -I../../../src/libgcc/../include > -I../../../src/libgcc/../libdecnumber/no > -I../../../src/libgcc/../libdecnumber -I../../libdecnumber -o decLibrary.o > -MT decLibrary.o -MD -MP -MF decLibrary.dep -c > ../../../src/libgcc/../libdecnumber/decLibrary.c > ../../../src/libgcc/../libdecnumber/decLibrary.c:32:24: error: decimal128.h: > No such file or directory > ../../../src/libgcc/../libdecnumber/decLibrary.c:33:23: error: decimal64.h: > No such file or directory > ../../../src/libgcc/../libdecnumber/decLibrary.c:34:23: error: decimal32.h: > No such file or directory > ../../../src/libgcc/../libdecnumber/decLibrary.c:36: error: expected > declaration specifiers or '...' before 'decimal32' > ../../../src/libgcc/../libdecnumber/decLibrary.c:37: error: expected > declaration specifiers or '...' before 'decimal64' > ../../../src/libgcc/../libdecnumber/decLibrary.c:38: error: expected > declaration specifiers or '...' before 'decimal128' > ../../../src/libgcc/../libdecnumber/decLibrary.c: In function 'isinfd32': > ... > > -- > Martin Michlmayr > http://www.cyrius.com/ > Note, the gcc mailing list is perhaps not the best place to post bug reports (following up to the mail with the patch in gcc-patches or posting in gcc-bugs may be better places to post this). As I replied in gcc-patches, I think the following patch fixes the problem, simpler than using AC_CANONICAL. Sorry, I always build with canonical names, and didn't notice that x86_64-linux-gnu wouldn't build: libgcc/ 2007-03-26 Michael Meissner <[EMAIL PROTECTED]> * configure.ac (--enable-decimal-float): Change x86 targets to just x86_64*-linux* and i?86*-linux* so that a non-canonical target of x86_64-linux will be handled. * configure: Regenerate. --- libgcc/configure.ac.~1~ 2007-03-24 13:25:28.593802000 -0400 +++ libgcc/configure.ac 2007-03-26 13:17:46.577488000 -0400 @@ -121,7 +121,7 @@ Valid choices are 'yes', 'bid', 'dpd', a ], [ case $target in -powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux*) +powerpc*-*-linux* | i?86*-linux* | x86_64*-linux*) enable_decimal_float=yes ;; *) @@ -133,7 +133,7 @@ Valid choices are 'yes', 'bid', 'dpd', a # x86's use BID format instead of DPD if test x$enable_decimal_float = xyes; then case $target in -i?86*-*-linux* | x86_64*-*-linux*) +i?86*-linux* | x86_64*-linux*) enable_decimal_float=bid ;; *) --- libgcc/configure.~1~2007-03-26 13:17:14.691407000 -0400 +++ libgcc/configure2007-03-26 13:17:55.282777000 -0400 @@ -3306,7 +3306,7 @@ Valid choices are 'yes', 'bid', 'dpd', a else case $target in -powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux*) +powerpc*-*-linux* | i?86*-linux* | x86_64*-linux*) enable_decimal_float=yes ;; *) @@ -3319,7 +3319,7 @@ fi; # x86's use BID format instead of DPD if test x$enable_decimal_float = xyes; then case $target in -i?86*-*-linux* | x86_64*-*-linux*) +i?86*-linux* | x86_64*-linux*) enable_decimal_float=bid ;; *) -- Michael Meissner, AMD 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA [EMAIL PROTECTED]
Re: --disable-multilib broken on x86_64
* Michael Meissner <[EMAIL PROTECTED]> [2007-03-26 13:57]: > * configure.ac (--enable-decimal-float): Change x86 targets to > just x86_64*-linux* and i?86*-linux* so that a non-canonical > target of x86_64-linux will be handled. In case this is acceptable: powerpc needs the same change. -- Martin Michlmayr http://www.cyrius.com/
Re: --disable-multilib broken on x86_64
On Mon, Mar 26, 2007 at 01:57:52PM -0400, Michael Meissner wrote: > On Sat, Mar 24, 2007 at 07:01:40PM +, Martin Michlmayr wrote: > > The following change broke --disable-multilib: > > > > 2007-03-23 Michael Meissner <[EMAIL PROTECTED]> > > H.J. Lu <[EMAIL PROTECTED]> > > > > ../src/configure --enable-languages=c --disable-multilib x86_64-linux-gnu > > > > /home/tbm/build/gcc-snapshot-20070324/build/./gcc/xgcc > > -B/home/tbm/build/gcc-snapshot-20070324/build/./gcc/ > > -B/usr/lib/gcc-snapshot/x86_64-linux-gnu/bin/ > > -B/usr/lib/gcc-snapshot/x86_64-linux-gnu/lib/ -isystem > > /usr/lib/gcc-snapshot/x86_64-linux-gnu/include -isystem > > /usr/lib/gcc-snapshot/x86_64-linux-gnu/sys-include -g > > -fkeep-inline-functions -O2 -O2 -g -O2 -DIN_GCC-W -Wall > > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > > -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT > > -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc > > -I../../../src/libgcc -I../../../src/libgcc/. -I../../../src/libgcc/../gcc > > -I../../../src/libgcc/../include -I../../../src/libgcc/../libdecnumber/no > > -I../../../src/libgcc/../libdecnumber -I../../libdecnumber -o decLibrary.o > > -MT decLibrary.o -MD -MP -MF decLibrary.dep -c > > ../../../src/libgcc/../libdecnumber/decLibrary.c > > ../../../src/libgcc/../libdecnumber/decLibrary.c:32:24: error: > > decimal128.h: No such file or directory > > ../../../src/libgcc/../libdecnumber/decLibrary.c:33:23: error: decimal64.h: > > No such file or directory > > ../../../src/libgcc/../libdecnumber/decLibrary.c:34:23: error: decimal32.h: > > No such file or directory > > ../../../src/libgcc/../libdecnumber/decLibrary.c:36: error: expected > > declaration specifiers or '...' before 'decimal32' > > ../../../src/libgcc/../libdecnumber/decLibrary.c:37: error: expected > > declaration specifiers or '...' before 'decimal64' > > ../../../src/libgcc/../libdecnumber/decLibrary.c:38: error: expected > > declaration specifiers or '...' before 'decimal128' > > ../../../src/libgcc/../libdecnumber/decLibrary.c: In function 'isinfd32': > > ... > > > > -- > > Martin Michlmayr > > http://www.cyrius.com/ > > > > Note, the gcc mailing list is perhaps not the best place to post bug reports > (following up to the mail with the patch in gcc-patches or posting in gcc-bugs > may be better places to post this). > > As I replied in gcc-patches, I think the following patch fixes the problem, > simpler than using AC_CANONICAL. Sorry, I always build with canonical names, > and didn't notice that x86_64-linux-gnu wouldn't build: > > libgcc/ > 2007-03-26 Michael Meissner <[EMAIL PROTECTED]> > > * configure.ac (--enable-decimal-float): Change x86 targets to > just x86_64*-linux* and i?86*-linux* so that a non-canonical > target of x86_64-linux will be handled. > * configure: Regenerate. > > --- libgcc/configure.ac.~1~ 2007-03-24 13:25:28.593802000 -0400 > +++ libgcc/configure.ac 2007-03-26 13:17:46.577488000 -0400 > @@ -121,7 +121,7 @@ Valid choices are 'yes', 'bid', 'dpd', a > ], > [ >case $target in > -powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux*) > +powerpc*-*-linux* | i?86*-linux* | x86_64*-linux*) >enable_decimal_float=yes >;; It won't work with powerpc-linux, pentium4-linux, . H.J.
GCC mini-summit at Google during Gelato conference
Several gcc developers are presenting at the Gelato conference in San Jose this April. Google is inviting them and all other interested parties to a gcc mini-summit at Google's Mountain View campus. The mini-summit will be on Wednesday, April 18, in Google building 40, from 10am to 5pm. The goal is simply to give gcc developers a place and time to talk face to face about where gcc should go and how it should get there. If you are interested in attending, please let me know. You don't have to commit to being here all day. Probably the first item of the day will be to set a schedule of things to discuss. If you have specific areas you would like to cover, please let me know that as well. I hope it will be both interesting and fun. Ian
Re: [Martin Michlmayr <[EMAIL PROTECTED]>] Documenting GCC 4.2 changes
> 2006-02-07 Eric Botcazou <[EMAIL PROTECTED]> > config/sol26.h (CPP_SUBTARGET_SPEC): Accept -pthread. > doc/invoke.texi (SPARC options): Document -pthread. It's only an alias for the existing -pthreads, not worth mentioning IMO. -- Eric Botcazou
Re: [Martin Michlmayr <[EMAIL PROTECTED]>] Documenting GCC 4.2 changes
On Mon, Mar 26, 2007 at 09:28:44PM +0200, Eric Botcazou wrote: > > 2006-02-07 Eric Botcazou <[EMAIL PROTECTED]> > > config/sol26.h (CPP_SUBTARGET_SPEC): Accept -pthread. > > doc/invoke.texi (SPARC options): Document -pthread. > > It's only an alias for the existing -pthreads, not worth mentioning IMO. So why is it there? Compatibility with some other compiler?
Re: [Martin Michlmayr <[EMAIL PROTECTED]>] Documenting GCC 4.2 changes
> So why is it there? Compatibility with some other compiler? To work around some laziness in libgomp. :-) Other platforms only have -pthread it seems. -- Eric Botcazou
gcc-4.1-20070326 is now available
Snapshot gcc-4.1-20070326 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070326/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 123235 You'll find: gcc-4.1-20070326.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20070326.tar.bz2 C front end and core compiler gcc-ada-4.1-20070326.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20070326.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20070326.tar.bz2 C++ front end and runtime gcc-java-4.1-20070326.tar.bz2 Java front end and runtime gcc-objc-4.1-20070326.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20070326.tar.bz2The GCC testsuite Diffs from 4.1-20070319 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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.
gengtype future directions
So I've just checked in a patch series which accomplishes about half of what I was originally aiming to achieve with gengtype, and I'd like to review what I think should still be done. My ultimate goal - not just with gengtype - is to remove all hardwired kludges and dependencies on target header files from all of the programs run at build time, so that one might (in principle) build GCC targeting wholly different processors without needing to recompile any of the gen* programs. I don't expect to personally achieve this in the foreseeable future, at my current rate of about one substantial patch (series) a year, but perhaps others will find it a project worthy of contributing to. Most of gengtype's hardwired kludges exist because it does not do preprocessing, and therefore my recommendation is that we work toward a state where gengtype can use libcpp to do that (we already have a preprocessor library, let's use it :) If libcpp is too slow for this application that should be dealt with by improvements to libcpp. There are two major obstacles to doing this. First, gengtype currently discards most of the input text in the lexical scanner; only declarations/definitions that are "interesting" make it to the parser. libcpp cannot do this and should not be made to do it. Instead, gengtype's parser should be revised so that it accepts exactly the tokens of C translation phase six, which is what libcpp will give you, and discards "uninteresting" content (like function bodies) itself. A related problem is that gengtype currently treats array length declarations, '[' integer-constant-expression ']' in the C grammar, as string tokens (!) -- this needs to change. It should not be necessary to parse expressions, only to scan forward for the balancing close bracket and store a serialized sequence of tokens as text. The other major obstacle is from libcpp's side: gengtype will need a mechanism (presumably a new callback function) for telling libcpp to ignore #include directives, and a policy to determine which ones should be included. The obvious answer of "all of them" does not work, because we will need at least some macros to be visible (otherwise there would be no need for kludges around the unavailability of macros). Hopefully "most of them" will be a feasible answer, though. A related problem is that we currently have no way of telling gengtype about the set of system-header-defined types (size_t, ino_t, etc) and it really isn't a good idea for gengtype to have to parse system headers -- for one thing, how does it know where they are? for another, it's amazing what gremlins lurk in there. The immediate benefits of having preprocessing in gengtype are that we could eliminate the kludges for VECs and input.h (it should, however, be mentioned that the input.h mess could vanish if the USE_MAPPED_LOCATION conversion were completed) and that we would not need Flex for a build of GCC (unless treelang were desired). We could also easily cause gengtype to process all structure definitions, thus eliminating the need for a vacuous GTY(()) on all GC-relevant-types (the only reason I didn't do that in this patch series is because it would have required several more kludges around the lack of a preprocesor). A slightly more remote benefit is more from the better approximation to the type grammar that the new parser uses than from preprocessing, but I wouldn't do it until after textual skipping in the lexical analyzer is eliminated, at least. That is, we could teach the parser to recognize GTY((...)) as if it were "just another" type qualifier, rather than a very special case. The major win from that would be that we could recognize a GTY(()) tag on the *definition* of a program-scope global, rather than its "extern" declaration as is now necessary; that in turn would simplify the logic for deciding what mark routines need to be written where. It might render some of the gtype-* files unnecessary, even. (I haven't looked at this in detail.) It would be nice to eliminate the #includes of a few .def files in gengtype.c. I think that could be done with preprocessing plus real support for enums in gengtype. That might also help with the removal or reduction of the extensive special-case support for the tree and RTL types. zw
Re: gengtype future directions
On 26/03/2007, at 3:12 PM, Zack Weinberg wrote: Most of gengtype's hardwired kludges exist because it does not do preprocessing, and therefore my recommendation is that we work toward a state where gengtype can use libcpp to do that (we already have a preprocessor library, let's use it :) If libcpp is too slow for this application that should be dealt with by improvements to libcpp. I considered doing something like this during the original design of gengtype, and rejected it. I don't see that it's necessarily possible to make libcpp as fast as gengtype. libcpp has to do much more work than gengtype does because libcpp processes every token whereas gengtype spends most of its time scanning source looking for a few keywords and does not need to understand every weird thing that someone might do (like putting a GTY marker inside a string). gengtype does not even need to examine every character in its input source files (although I don't know if flex is smart enough to do this). Although it might seem like a benefit that gengtype could deduce which types are relevant for GC by itself, the existing GTY(()) markers actually have a significant documentation use: they inform users of the structure that the structure is supposed to be allocated in GC-managed memory. So I would recommend keeping these whether they are necessary or not, and if possible verifying that they are consistent. I doubt the remaining benefit of doing this (making some parts of the design of gengtype conceptually simpler) exceeds the cost of doing the work plus the cost of maintaining the larger gengtype front-end plus the cost of maintaining the libcpp changes needed to bend it to this fairly unnatural purpose. If I was writing something like gengtype for any project other than GCC, I would do it differently: I would write a tool which read DWARF from .o files instead of reading source code directly. This approach would allow use of any part of C or even C++, and would be even faster than the existing gengtype. However, GCC needs to be more portable than this would allow. smime.p7s Description: S/MIME cryptographic signature
Re: core changes for mep port
> Coprocessor types - the MeP chip has optional coprocessors, each with
> their own register sets. They need their own internal types (mostly
> to keep track of which unit to use), which we've created by prefixing
> the existing types with COP (i.e. COPSImode, COPDFmode, etc). This
> affects the generators, some MI files, etc. The types don't exist
> unless the target calls for them.
Here's the first pass at this portion of the patch, originally written
by Richard over three years ago. No regressions on i686-linux.
2007-03-26 Richard Sandiford <[EMAIL PROTECTED]>
DJ Delorie <[EMAIL PROTECTED]>
* tree.h (signed_copro_types, unsigned_copro_types): Declare.
* machmode.h (copro_modes): Declare.
(COPRO_MODE_P): New macro.
(COPRO_MODE, NON_COPRO_MODE): New macros.
* rtl.h (COPRO_VALUE_P): New macro.
* expr.c (convert_move): Handle conversions involving coprocessor
modes by converting to the equivalent non-coprocessor mode.
Remove truncation handling.
(subreg_strength, change_int_mode): New functions.
(emit_move_insn_1): Consider changing between coprocessor and
non-coprocessor modes if doing so would avoid a subreg.
(expand_expr_real_1): Treat coprocessor targets like normal
REGs. Don't set SUBREG_PROMOTED_VAR_P if a decl's mode is the
coprocessor equivalent of the type's mode. Return a SUBREG
for coprocessor variables.
* optabs.c (expand_unop, expand_binop): Handle coprocessor modes
like the equivalent non-coprocessor mode, then convert the result.
* tree.c (signed_copro_types, unsigned_copro_types): Define.
(build_common_tree_nodes): Initialize them.
* c-common.c (c_common_type_for_mode): Handle coprocessor modes.
* postreload.c (reload_cse_move2add): Don't look for strict lowparts
of coprocessor modes.
* reload.c (find_reloads_toplev): Fix order of coprocessor-related
reg_equiv_constant check.
* genmodes.c (struct mode_data): Add copro_p field.
(blank_mode): Add an entry for it in the initializer.
(mode_prefixes): New array.
(for_all_mode_prefixes): New macro.
(COPRO_MODE): Redefine.
(make_copro_mode): New function.
(tagged_printf): Take a prefix as argument.
(emit_insn_modes_h): Iterate over each mode prefix.
(emit_mode_name, emit_mode_class, emit_mode_bitsize): Likewise.
(emit_mode_size, emit_mode_unit_size, emit_mode_wider): Likewise.
(emit_mode_mask, emit_mode_inner, emit_mode_base_align): Likewise.
(emit_real_format_for_mode): Likewise.
(emit_class_narrowest_mode): Update call to tagged_printf.
(emit_copro_table): New function.
(emit_insn_modes_c): Call it.
* emit-rtl.c (insn_emit_once): Create tiny constants for COP?I modes.
* c-typeck.c (convert_for_assignment): Don't relax reference check.
* expmed.c (expand_mult): If the variable operand is a coprocessor
value, use a coprocessor accumulator.
Index: machmode.h
===
--- machmode.h (revision 123248)
+++ machmode.h (working copy)
@@ -41,12 +41,25 @@ enum mode_class { MODE_CLASSES, MAX_MODE
/* Get the general kind of object that mode MODE represents
(integer, floating, complex, etc.) */
extern const unsigned char mode_class[NUM_MACHINE_MODES];
#define GET_MODE_CLASS(MODE) mode_class[MODE]
+extern const unsigned char copro_modes[NUM_MACHINE_MODES][2];
+
+/* Return the coprocessor mode for MODE, or MODE itself if there
+ is none. */
+#define COPRO_MODE(MODE) copro_modes[MODE][1]
+
+/* The reverse of COPRO_MODE. */
+#define NON_COPRO_MODE(MODE) copro_modes[MODE][0]
+
+/* True if MODE is a coprocessor mode. */
+#define COPRO_MODE_P(MODE) (NON_COPRO_MODE (MODE) != MODE)
+
+
/* Nonzero if MODE is an integral mode. */
#define INTEGRAL_MODE_P(MODE) \
(GET_MODE_CLASS (MODE) == MODE_INT \
|| GET_MODE_CLASS (MODE) == MODE_PARTIAL_INT \
|| GET_MODE_CLASS (MODE) == MODE_COMPLEX_INT \
|| GET_MODE_CLASS (MODE) == MODE_VECTOR_INT)
Index: optabs.c
===
--- optabs.c(revision 123248)
+++ optabs.c(working copy)
@@ -1254,12 +1254,21 @@ expand_binop (enum machine_mode mode, op
|| binoptab->code == ROTATE
|| binoptab->code == ROTATERT);
rtx entry_last = get_last_insn ();
rtx last;
bool first_pass_p = true;
+ if (COPRO_MODE_P (mode))
+{
+ if (target)
+ target = gen_lowpart (NON_COPRO_MODE (mode), target);
+ return gen_lowpart (mode, expand_binop (NON_COPRO_MODE (mode),
+ binoptab, op0, op1,
+ target, unsignedp, methods));
+}
+
class = GET_M
Re: core changes for mep port
DJ Delorie <[EMAIL PROTECTED]> writes: > > Coprocessor types - the MeP chip has optional coprocessors, each with > > their own register sets. They need their own internal types (mostly > > to keep track of which unit to use), which we've created by prefixing > > the existing types with COP (i.e. COPSImode, COPDFmode, etc). This > > affects the generators, some MI files, etc. The types don't exist > > unless the target calls for them. > > Here's the first pass at this portion of the patch, originally written > by Richard over three years ago. No regressions on i686-linux. It's hard for me to be happy with a patch like this. As far as I can see you're using new modes to drive register class preferences. This isn't done in a general way: you've simply permitted doubling the standard modes. It's not immediately obvious how you get values in the new modes. Presumably there is something processor specific that generates them. The code itself is not general even within these constraints: e.g., the change to find_reloads_toplev. And there is no documentation. Earlier you sent out a patch preventing inlining. That suggests that you can not compile code to run on both the main processor and the coprocessor at the same time. If that is correct, then why do you need these coprocessor modes? For example, why can't you set the mode in struct machine_function and check that when recognizing insns? Ian
Re: core changes for mep port
> Earlier you sent out a patch preventing inlining. That suggests that
> you can not compile code to run on both the main processor and the
> coprocessor at the same time.
No, that's not how it works. We always support both the main
processor and the coprocessor at the same time, in the same
compilation, in the same function. The inlining keeps us from mixing
VLIW and non-VLIW mode at the same time, since VLIW mode has a wider
range (superset) of opcodes, so if you use a __builtin_* or asm() that
only works in VLIW mode, you can't inline it into a non-VLIW function
because those __builtin's or asm()'s won't work.
What you're suggesting is similar to having to move all i686 floating
point operations into a separate file from the integer operations.
> If that is correct, then why do you need these coprocessor modes?
> For example, why can't you set the mode in struct machine_function
> and check that when recognizing insns?
No, it's more like this:
typedef int copsi __attribute__((mode(COPSI)));
void foo (int *a, copsi *b, int i)
{
while (i--)
{
*a *= 2;
*b *= 2;
}
}
This will keep both the core multiplier and the coprocessor multiplier
busy.
Since both units run simultaneously, we need two sets of modes, one
for each unit, so the programmer can indicate which unit each
operation belongs on.
Re: core changes for mep port
DJ Delorie <[EMAIL PROTECTED]> writes:
> > If that is correct, then why do you need these coprocessor modes?
> > For example, why can't you set the mode in struct machine_function
> > and check that when recognizing insns?
>
> No, it's more like this:
>
> typedef int copsi __attribute__((mode(COPSI)));
>
> void foo (int *a, copsi *b, int i)
> {
> while (i--)
> {
> *a *= 2;
> *b *= 2;
> }
> }
>
> This will keep both the core multiplier and the coprocessor multiplier
> busy.
>
> Since both units run simultaneously, we need two sets of modes, one
> for each unit, so the programmer can indicate which unit each
> operation belongs on.
Well, it's an interesting feature. And if it only required modifying
the mode support routines I might not worry about it. But I'm
concerned about the changes to the other files. I think it's going to
be quite difficult to maintain them over time. And I think it's going
to be difficult to rip out the support when we drop the MEP. I find
it very hard to imagine that any other processor is ever going to use
this.
Your example seems a little odd, though I'm sure you have better ones.
Is this a proper type, in that foo must be called with a copsi
argument? If so, shouldn't we express this in the type system? If
not, I would find it more natural to express this either by having the
scheduler schedule automatically onto the coprocessor, or by requiring
the use of a builtin function.
I'd be interested in hearing comments from other maintainers.
Ian
Re: core changes for mep port
On 3/27/07, DJ Delorie <[EMAIL PROTECTED]> wrote: * postreload.c (reload_cse_move2add): Don't look for strict lowparts of coprocessor modes. This changes is not in your patch. * c-typeck.c (convert_for_assignment): Don't relax reference check. And neither is this one. You have machine modes for a co-processor. Somehow that doesn't feel right to me. What if there comes a new architecture with two different kind of co-processors? Will we have COPRO2_MODE_P/copro2_modes/etc.? Also: * expmed.c (expand_mult): If the variable operand is a coprocessor value, use a coprocessor accumulator. Why? Isn't this an architecture specific decision to make? Iff this will ever be useful to other architectures than MEP (which I seriously doubt), it could be better for that arch to use a normal mode. So shouldn't this change be guarded by some kind of kost or profitability checks, etc.? Likewise for all other places where you appear to just take a coprocessor mode if it is available. - && reg_equiv_constant[regno] != 0) + && reg_equiv_constant[regno] != 0 + /* Symbolic constants have no representation in coprocessor +modes. Just handle known constants. */ + && (!COPRO_MODE_P (GET_MODE (x)) + || GET_CODE (reg_equiv_constant[regno]) == CONST_INT + || GET_CODE (reg_equiv_constant[regno]) == CONST_DOUBLE)) Architecture specific? Also, documentation is missing of the new coprocessor modes, and what one is allowed to use them for and do with them. All of this feels (to me anyway) like adding a lot of code to the middle end to support MEP specific arch features. I understand it is in the mission statement that more ports is a goal for GCC, but I wonder if this set of changes is worth the maintenance burden... Gr. Steven
Re: core changes for mep port
On Tue, 2007-03-27 at 07:47 +0200, Steven Bosscher wrote: > On 3/27/07, DJ Delorie <[EMAIL PROTECTED]> wrote: > >* postreload.c (reload_cse_move2add): Don't look for strict lowparts > >of coprocessor modes. > > This changes is not in your patch. > > > >* c-typeck.c (convert_for_assignment): Don't relax reference check. > > And neither is this one. > > You have machine modes for a co-processor. Somehow that doesn't feel > right to me. What if there comes a new architecture with two different > kind of co-processors? Will we have COPRO2_MODE_P/copro2_modes/etc.? There's certainly processors with multiple co-processors; the original MEP designs certainly had multiple co-processors in mind as well. You can model this by simply globbing all the co-processor modes together. It's far from ideal though. > > Also: > > > * expmed.c (expand_mult): If the variable operand is a coprocessor > > value, use a coprocessor accumulator. > > Why? Isn't this an architecture specific decision to make? Iff this > will ever be useful to other architectures than MEP (which I seriously > doubt), it could be better for that arch to use a normal mode. Oh, it could definitely be useful on other architectures; I've done GCC work on architectures were it would certainly have been advantageous to have this capability. You could even model the MIPS in this manner and probably get better code for integer multiply-accumulate operations :-) Note my comments say absolutely nothing about this particular implementation... I haven't looked at the changes at all. > So shouldn't this change be guarded by some kind of kost or > profitability checks, etc.? It's probably always going to be profitable on the architectures that have these kind of capabilities. Moving values between the main unit and co-processors it typically slow, very slow, often they have to go through memory or at least flush the pipeline. Jeff
