Re: Hi : please please help me with c++ frontend
Naren KN wrote: Hi Nathan, Please copy the gcc list on these things. I was asking this question and didn't get much reply.. regarding the c++ frontend ... After calling the c_parse_file(), I wish to walk through the list of namespaces, inturn all the classes and functions inside them... could you help me with a sample code?? It will be very very help ful. If you can't atleast tell me the top level file handles for the following 1. namespaces 2. classes 3. functions Also show me (that is already in gcc of particular version) example codes which walk through these data structures. walk_global_namespaces is what you want. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Hi : please please help me with c++ frontend
Naren KN wrote: Hi Nathan, I was unable to find such a function in my source tree. I'm using the 4.0.2 version. Are you talking about the trunk version? sorry, walk_namespaces in cp/decl.c nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Can't build gcc trunk Fri May 19 10:52:05 UTC 2006 (revision 113904M) on cygwin: gcc/objc/objc-act.c:5573: warning: ....
Well, /usr/local/src/trunk/objdir/./prev-gcc/xgcc -B/usr/local/src/trunk/objdir/./prev-gcc/ -B/usr/local/i686-pc-cygwin/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror -DOBJCPLUS -I../../gcc/gcc/objc -I../../gcc/gcc/cp -fno-common -DHAVE_CONFIG_H -I. -Iobjcp -I../../gcc/gcc -I../../gcc/gcc/objcp -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber-I. -Iobjcp -I../../gcc/gcc -I../../gcc/gcc/objcp -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber ../../gcc/gcc/objc/objc-act.c -o objcp/objcp-act.o cc1: warnings being treated as errors ../../gcc/gcc/objc/objc-act.c: In function 'build_shared_structure_initializer': ../../gcc/gcc/objc/objc-act.c:5573: warning: implicit declaration of function 'default_conversion' ../../gcc/gcc/objc/objc-act.c:5573: warning: passing argument 2 of 'tree_cons_stat' makes pointer from integer without a cast make[3]: *** [objcp/objcp-act.o] Error 1 make[3]: Leaving directory `/usr/local/src/trunk/objdir/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/usr/local/src/trunk/objdir' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir' make: *** [bootstrap] Error 2 -- Cheers, /ChJ
Re: GCC 4.1.1 RC1
* Mark Mitchell <[EMAIL PROTECTED]> [2006-05-18 15:33]: > GCC 4.1.1 RC1 is available from: > ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.1-20060517 Running make check after make gives me: | Newly fixed header: ia64/sys/getppdp.h | | There were fixinclude test FAILURES -- Martin Michlmayr [EMAIL PROTECTED]
Revert patch for MIPS TImode functions for 4.1.1
Richard, Roger -- Roger, would you please revert your MIPS MIN_UNITS_PER_WORD change for MIPS on the GCC 4.1 branch? (My brain failed to digest the fact that the patch was on 4.1 as well as on mainline, perhaps in part because there doesn't seem to be a PR; Richard indicated to me that he would locate or open one now.) I understand that the patch added TImode functions, and that these are useful, but, as I understand it, we've removed other more commonly-used functions in the process, making for an incompatible libgcc. Ideally, we'd apply Richard's patch to 4.1.1, but I think that's too big a change to make now. Therefore, Roger, would you please revert your patch? Richard, your patch is OK for 4.1.2, after you feel the mainline version has proven itself. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Revert patch for MIPS TImode functions for 4.1.1
Mark Mitchell <[EMAIL PROTECTED]> writes: > (My brain failed to digest the fact that the patch was on 4.1 as well as > on mainline, perhaps in part because there doesn't seem to be a PR; > Richard indicated to me that he would locate or open one now.) Opened as 27681. (And Roger: sorry for all the hassle this patch has caused you. A good deed and all that...) Richard
PATCH: Update src/intl from gcc/intl
OK, Here is an official patch proposal to replace the contents of the src/intl tree with the bits from gcc/intl. I tested the change on HPPA and IA64 HP-UX and on IA64 Linux. The Linux build didn't prove much because it used the system gettext bits but the HP-UX builds built and used the new intl directory with no problems and I am willing to try and fix any problems caused by the change if other platforms have problems with it. 2006-05-19 Steve Ellcey <[EMAIL PROTECTED]> * MAINTAINERS: Change intl updating instructions. * config.rpath: Copy from GCC tree. * intl: Replace contents of intl directory with intl from GCC tree. *** MAINTAINERS.origWed May 17 11:58:10 2006 --- MAINTAINERS Wed May 17 12:01:37 2006 *** gdb/; readline/; sim/; GDB's part of inc *** 47,61 include/ See binutils/, gdb/, sid/, gcc/, libiberty/ etc. ! libiberty/; libiberty's part of include/ gcc: http://gcc.gnu.org Changes need to be done in tandem with the official GCC sources or submitted to the master file maintainer and brought ! in via a merge. Note: approved patches in gcc's libiberty ! are automatically approved in this libiberty also; feel free ! to merge them yourself if needed sooner than the next merge. ! Otherwise, changes are automatically merged, usually within ! a day. ltconfig; ltmain.sh; ltcf-*.sh libtool: http://www.gnu.org/software/libtool/ --- 47,61 include/ See binutils/, gdb/, sid/, gcc/, libiberty/ etc. ! intl/; config.rhost; libiberty/; libiberty's part of include/ gcc: http://gcc.gnu.org Changes need to be done in tandem with the official GCC sources or submitted to the master file maintainer and brought ! in via a merge. Note: approved patches in gcc's libiberty or ! intl are automatically approved in this libiberty and intl also; ! feel free to merge them yourself if needed sooner than the next ! merge. Otherwise, changes are automatically merged, usually ! within a day. ltconfig; ltmain.sh; ltcf-*.sh libtool: http://www.gnu.org/software/libtool/ *** winsup/ *** 99,105 See also winsup/MAINTAINERS. config-ml.in; makefile.vms; mkdep; setup.com; ! etc/; intl/; utils/; Any global maintainer can approve changes to these files and directories. --- 99,105 See also winsup/MAINTAINERS. config-ml.in; makefile.vms; mkdep; setup.com; ! etc/; utils/; Any global maintainer can approve changes to these files and directories.
Re: PATCH: Update src/intl from gcc/intl
Hi Steve, OK, Here is an official patch proposal to replace the contents of the src/intl tree with the bits from gcc/intl. 2006-05-19 Steve Ellcey <[EMAIL PROTECTED]> * MAINTAINERS: Change intl updating instructions. * config.rpath: Copy from GCC tree. * intl: Replace contents of intl directory with intl from GCC tree. Approved for binutils. Cheers Nick
Re: PATCH: Update src/intl from gcc/intl
On Fri, May 19, 2006 at 04:54:17PM +0100, Nick Clifton wrote: > Hi Steve, > > >OK, Here is an official patch proposal to replace the contents of the > >src/intl tree with the bits from gcc/intl. > > >2006-05-19 Steve Ellcey <[EMAIL PROTECTED]> > > > > * MAINTAINERS: Change intl updating instructions. > > * config.rpath: Copy from GCC tree. > > * intl: Replace contents of intl directory with intl from GCC tree. > > Approved for binutils. Fine for GDB, too. -- Daniel Jacobowitz CodeSourcery
Re: GCC 4.1.1 RC1
Bootstrap failure in gnattools for ia64-unknown-linux-gnu. Complaining on missing libunwind.so.7 gmake[3]: Entering directory `/disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.1-RC1/gcc-4.1.1-RC1/gnattools' rm -rf ../gcc/ada/tools mkdir -p ../gcc/ada/tools (cd ../gcc/ada/tools; ln -s ../sdefault.adb .) rm -f ../gcc/ada/tools/mlib-tgt.adb; ln -s /raid/tecosim/it/devel/projects/develtools/src/gcc-4.1.1-RC1/gcc/ada/mlib-tgt-linux.adb ../gcc/ada/tools/mlib-tgt.adb; rm -f ../gc c/ada/tools/indepsw.adb; ln -s /raid/tecosim/it/devel/projects/develtools/src/gcc-4.1.1-RC1/gcc/ada/indepsw-linux.adb ../gcc/ada/tools/indepsw.adb; touch ../gcc/stamp-tools # gnattools1 gmake -C ../gcc/ada/tools -f ../Makefile \ "CC=../../xgcc -B../../" "CFLAGS=-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes " "LDFLAGS=" "ADAFLAGS=-gnatpg -gnata" "INCLUDES=-I. -I.. -I../.. -I/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1.1-RC1/gcc/ada -I/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1.1-RC1/gcc/ada/../config -I/raid/tecosim/it/dev el/projects/develtools/src/gcc-4.1.1-RC1/gcc/ada/../../include -I/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1.1-RC1/gcc/ada/.." "ADA_INCLUDES=-I- -I../rts -I. -I/ra id/tecosim/it/devel/projects/develtools/src/gcc-4.1.1-RC1/gcc/ada" "exeext=" "fsrcdir=/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1.1-RC1/gcc/ada" "srcdir=/raid/teco sim/it/devel/projects/develtools/src/gcc-4.1.1-RC1/gcc/ada" "GNATBIND=../../gnatbind" "TOOLSCASE=native" \ ../../gnatmake ../../gnatlink ../../gnatbl gmake[4]: Entering directory `/disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.1-RC1/gcc-4.1.1-RC1/gcc/ada/tools' ../../xgcc -B../../ -c -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -gnatpg -gnata -g -O1 -fno-inline \ -I- -I../rts -I. -I/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1.1-RC1/gcc/ada ../rts/a-except.adb -o a-except.o ../../gnat1: error while loading shared libraries: libunwind.so.7: cannot open shared object file: No such file or directory gmake[4]: *** [a-except.o] Error 1 gmake[4]: Leaving directory `/disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.1-RC1/gcc-4.1.1-RC1/gcc/ada/tools' gmake[3]: *** [gnattools-native] Error 2 gmake[3]: Leaving directory `/disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.1-RC1/gcc-4.1.1-RC1/gnattools' gmake[2]: *** [all-gnattools] Error 2 gmake[2]: Leaving directory `/disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.1-RC1/gcc-4.1.1-RC1' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.1-RC1/gcc-4.1.1-RC1' gmake: *** [bootstrap] Error 2 find /disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.1-RC1/gcc-4.1.1-RC1 -name libunwind.so.7 /SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.1-RC1/gcc-4.1.1-RC1/gcc/libunwind.so.7 Some Ideas??? -- Mit freundlichen Grüßen/Best Regards Dipl.-Ing. Rainer Emrich Leiter IT/Softwareentwicklung TECOSIM Technische Simulation GmbH Im Eichsfeld 3 65428 Rüsselsheim Phone: +49 (0) 6142 8272 - 12 Mobile: +49 (0) 163 56 949 - 20 Fax.: +49 (0) 6142 8272 - 49 www.tecosim.com best partner for simulation
Re: Revert patch for MIPS TImode functions for 4.1.1
Hi Mark and Richard, On Fri, 19 May 2006, Mark Mitchell wrote: > Roger, would you please revert your MIPS MIN_UNITS_PER_WORD change > for MIPS on the GCC 4.1 branch? > > (My brain failed to digest the fact that the patch was on 4.1 as well as > on mainline, perhaps in part because there doesn't seem to be a PR; > Richard indicated to me that he would locate or open one now.) Please can you explicitly confirm that we want to reintroduce PR target/22209 as a regression from gcc 4.1.0, and break the build of libgfortran on all 64-bit MIPS platforms, including IRIX? The MIPS backend still claims that TImode is scalar_mode_supported_p, and it's therefore possible to write simple C and C++ testcases that will regress with this change. I know my testing of such a reversion will reintroduce at least 4800 new failures in the dejagnu testsuite, for no reported improvement vs gcc 4.1.0. It's a lesser of two evils issue, and it's only further development on mainline, and not a user reported problem, that's revealed the potential fallout in 4.1.0. The tradeoff is between unlinkable code in the default build on the affected platforms, vs. unlinkable code when explicitly using the -msoft-float flag, which isn't tested by the testsuite. I'm happy to revert the changes at a moment's notice, especially if that's what the realease manager and MIPS maintainers want, but I just want to be certain that everyone's aware of the tradeoffs, so that whatever the outcome, it's not my fault. I'll start a bootstrap and regression test of the reversion against the 4.1 branch straight away, it's not clear if recent backports have introduced additional dependencies, but these machines aren't the fastest on the planet, and it's still behind on evaluating the recent set of mainline patches/changes. Roger --
Re: Revert patch for MIPS TImode functions for 4.1.1
Hi Richard, On Fri, 19 May 2006, Richard Sandiford wrote: > Mark Mitchell <[EMAIL PROTECTED]> writes: > > (My brain failed to digest the fact that the patch was on 4.1 as well as > > on mainline, perhaps in part because there doesn't seem to be a PR; > > Richard indicated to me that he would locate or open one now.) > > Opened as 27681. (And Roger: sorry for all the hassle this patch has > caused you. A good deed and all that...) Indeed, no good deed ever goes unpunished. In fact, isn't it the MIPS backend's use of the GOFAST libraries which is one of the major blockers of adding -msoft-float tests to the testsuite? :-) My very strong recommendation is to add a "target-soft-float" predicate to the dejgnu testsuite's "require" predicates, that'll allow us to test -msoft-float functionality on most platforms, by explicitly disabling the handful of problematic non-libgcc soft FP targets. This will both prevent this sort of regression in the future, and actually allow us to (automatedly) confirm that you patch has improved things. The MIN_UNITS_PER_WORD trick is used on multiple platforms, including PowerPC, IA-64 and s390, so without such tests we've no way of knowing that your recent fix isn't also required on them in addition to MIPS. See, for example, http://gcc.gnu.org/ml/gcc/2003-03/msg01365.html which was the Ulrich's s390 change that inspired my problematic fix for mips.h. Roger --
Re: Revert patch for MIPS TImode functions for 4.1.1
On Fri, 19 May 2006, Roger Sayle wrote: > Indeed, no good deed ever goes unpunished. In fact, isn't it the MIPS > backend's use of the GOFAST libraries which is one of the major blockers The GOFAST support is almost certainly unused and can probably be removed; at least, no-one has cared enough to fix the GOFAST case of bug 24998. (The relevant code to remove is I think the enable_gofast check in config.gcc, the documentation in doc/tm.texi, the file config/gofast.h, all the GOFAST conditionals in fp-bit.c and fp-bit.h, the effectively dead use of config/gofast.h and gofast_maybe_init_libfuncs in sparc/sparc.c, the comment in mips/elforion.h, the support in mips/mips.c, the file mips/t-gofast, and the use of US_SOFTWARE_GOFAST in mips/t-sr71k; the US_SOFTWARE_GOFAST macro can then be poisoned.) -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: GCC 4.1.1 RC1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Michlmayr wrote: > * Mark Mitchell <[EMAIL PROTECTED]> [2006-05-18 15:33]: >> GCC 4.1.1 RC1 is available from: >> ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.1-20060517 > > Running make check after make gives me: > > | Newly fixed header: ia64/sys/getppdp.h > | > | There were fixinclude test FAILURES You should run "make -k check" instead. See: http://gcc.gnu.org/install/test.html Having said that, I did bootstrap this prerelease tarball successfully on i686-pc-linux-gnu (c,c++,java), but "make -k check" in the toplevel build folder always exited with an error for every sub-folder it traversed into (something about set_ld_library_path_env_vars). I'm sorry I didn't get the time to investigate this further to see if it's a genuine issue with the prerelease tarball or just some SNAFU in my setup. Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEbfdAYb1hx2wRS48RAuRjAJ9NEshOuXujYoMsALvL2MkX2xtqQwCfVpMZ 9L8hAshHFqCeGgGEOj3gPIE= =gEXN -END PGP SIGNATURE-
Re: Revert patch for MIPS TImode functions for 4.1.1
Roger Sayle wrote: > Hi Mark and Richard, > > On Fri, 19 May 2006, Mark Mitchell wrote: >> Roger, would you please revert your MIPS MIN_UNITS_PER_WORD change >> for MIPS on the GCC 4.1 branch? >> >> (My brain failed to digest the fact that the patch was on 4.1 as well as >> on mainline, perhaps in part because there doesn't seem to be a PR; >> Richard indicated to me that he would locate or open one now.) > > Please can you explicitly confirm that we want to reintroduce PR > target/22209 as a regression from gcc 4.1.0, and break the build > of libgfortran on all 64-bit MIPS platforms, including IRIX? Thank you for raising this issue. The other choice may be to delay 4.1.1 until we have sufficient confidence in Richard's patch. Am I correct PR 22209 is "only" a Fortran problem? This is not a rhetorical question; I'm trying to gather data -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Revert patch for MIPS TImode functions for 4.1.1
On May 19, 2006, at 9:59 AM, Mark Mitchell wrote: Am I correct PR 22209 is "only" a Fortran problem? This is not a rhetorical question; I'm trying to gather data No, you can invoke it via using the attribute mode(TI), yes people are not going to do that but who knows. -- Pinski
Re: Revert patch for MIPS TImode functions for 4.1.1
Andrew Pinski wrote: > > On May 19, 2006, at 9:59 AM, Mark Mitchell wrote: > >> >> Am I correct PR 22209 is "only" a Fortran problem? This is not a >> rhetorical question; I'm trying to gather data > > No, you can invoke it via using the attribute mode(TI) Sure, but I'm not worried about that case. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Revert patch for MIPS TImode functions for 4.1.1
On May 19, 2006, at 10:12 AM, Mark Mitchell wrote: Andrew Pinski wrote: On May 19, 2006, at 9:59 AM, Mark Mitchell wrote: Am I correct PR 22209 is "only" a Fortran problem? This is not a rhetorical question; I'm trying to gather data No, you can invoke it via using the attribute mode(TI) Sure, but I'm not worried about that case. If the back-end was not lying to the front-ends, this would never have been a problem, hint hint. Also why revert a patch which obvious works in the default configurations? -- Pinski
Re: Revert patch for MIPS TImode functions for 4.1.1
On Fri, 19 May 2006, Mark Mitchell wrote: > > No, you can invoke it via using the attribute mode(TI) > Sure, but I'm not worried about that case. That would be the only class of C or C++ failures that I could easily construct by hand. Although the RTL optimizers will introduce TImode moves and temporary registers, it looks like they won't introduce any arithmetic/logical operations without explicit pattern support from the backend. Hence, it's only things like configure scripts that identify the presence of __int128_t and __uint128_t, and then explicitly use 128-bit operations in their source code that will be affected. This is the source of the libgfortran failure, where the runtime library detects these types are available, and uses them. It's not a problem in the gfortran compiler itself, which treats INTEGER*8, exactly the same way the C/C++ treat __int128_t. If libstdc++-3's configure checked for __int128_t and provided a specialized STL instantiation, it would exhibit the same issue. Roger --
Re: PATCH: Update src/intl from gcc/intl
> ! intl/; config.rhost; libiberty/; libiberty's part > ! ... > ! merge. Otherwise, changes are automatically merged, usually > ! within a day. Who signed up to do the automatic merge?
Re: Revert patch for MIPS TImode functions for 4.1.1
Andrew Pinski wrote: > Also why revert a patch which obvious works in the default configurations? It eliminates a Fortran problem, but causes a C problem. I'm evaluating the options. It would be helpful if someone has time to apply and test Richard's patch on 4.1, as that would let us know whether that option is viable as well. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: PATCH: Update src/intl from gcc/intl
> > ! intl/; config.rhost; libiberty/; libiberty's part > > ! ... > > ! merge. Otherwise, changes are automatically merged, usually > > ! within a day. > > Who signed up to do the automatic merge? I will unless you want to add this to the libiberty merge you do now. intl changes even less than libiberty does. The src version of intl has 4 changes since January of 2002. The GCC version has 8 changes since Zack put the gettext 0.12.1 version in back in July 2003. Steve Ellcey [EMAIL PROTECTED]
Re: GCC 4.1.1 RC1
On Fri, May 19, 2006 at 06:00:09PM +0200, Rainer Emrich wrote: > Bootstrap failure in gnattools for ia64-unknown-linux-gnu. Complaining on > missing libunwind.so.7 > It is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17464 H.J.
Re: Revert patch for MIPS TImode functions for 4.1.1
> > Andrew Pinski wrote: > > > Also why revert a patch which obvious works in the default configurations? > > It eliminates a Fortran problem, but causes a C problem. I thought it only caused the problem with C code when supplying -msoft-float which is not a default configuration? It eliminates more than just a Fortran problem, it eliminates a C problem also. -- Pinski
Re: Revert patch for MIPS TImode functions for 4.1.1
Andrew Pinski wrote: >> Andrew Pinski wrote: >> >>> Also why revert a patch which obvious works in the default configurations? >> It eliminates a Fortran problem, but causes a C problem. > > I thought it only caused the problem with C code when supplying -msoft-float > which is not a default configuration? C code, compiled with -msoft-float, is very common on MIPS, whether or not it's a "default configuration". Obviously, if we have to choose, shipping a compiler that works with software floating-point C programs on MIPS is much more important than shipping a compiler that works with Fortran. Of course, we'd rather not have to choose. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
C FE question: Is this test even valid?
With the memory SSA patches we fail gcc.dg/noncompile/920507-1.c:
int *
x(void)
{
register int *a asm("unknown_register"); /* { dg-error "invalid
register" } */
int *v[1] = {a};
return v[1];
}
The expected error message on the invalid register used for 'a' does not
trigger because the store into v[0] is dead and the the check for
register validity is done during instantiation of RTL decl registers (in
the case of dead stores, no RTL is instantiated for 'a' because it
completely disappears from the IL stream).
This happens simply because we are never referencing v[0]:
x ()
{
int * v[1];
register int * a __asm__ (*unknown_register);
int * D.1526;
int * a.0;
# VUSE <.MEM_2(D)>
a.0_1 = a;
# SFT.1_3 = VDEF <.MEM_2(D)>
v[0] = a.0_1;
# VUSE <.MEM_2(D)>
D.1526_4 = v[1];
return D.1526_4;
}
Notice how the load from v[1] is (naturally) not affected by the store
to v[0].
Seems to me that this test should be changed to 'return v[0]'. In that
case, the error does trigger.
One could also argue that this check should be done closer to the FE,
but that's orthogonal to the validity of this test case.
Thanks.
Re: C FE question: Is this test even valid?
>
>
> With the memory SSA patches we fail gcc.dg/noncompile/920507-1.c:
>
> int *
> x(void)
> {
> register int *a asm("unknown_register"); /* { dg-error "invalid
> register" } */
> int *v[1] = {a};
> return v[1];
> }
This should fail in the front-end really.
Thanks,
Andrew Pinski
Re: C FE question: Is this test even valid?
Diego Novillo wrote:
> With the memory SSA patches we fail gcc.dg/noncompile/920507-1.c:
>
> int *
> x(void)
> {
> register int *a asm("unknown_register"); /* { dg-error "invalid
> register" } */
> int *v[1] = {a};
> return v[1];
> }
>
> The expected error message on the invalid register used for 'a' does not
> trigger because the store into v[0] is dead and the the check for
> register validity is done during instantiation of RTL decl registers (in
> the case of dead stores, no RTL is instantiated for 'a' because it
> completely disappears from the IL stream).
Yes, this test case is valid; the code is ill-formed GNU C, since the
machine in question know not have a register named "unknown register".
> One could also argue that this check should be done closer to the FE,
> but that's orthogonal to the validity of this test case.
Yes, I think the check should be done closer to the FE.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: C FE question: Is this test even valid?
Mark Mitchell wrote on 05/19/06 14:54: > Yes, this test case is valid; the code is ill-formed GNU C, since the > machine in question know not have a register named "unknown register". > ^ I can't parse this. > Yes, I think the check should be done closer to the FE. > OK, looks easy enough.
Re: PATCH: Update src/intl from gcc/intl
> I will unless you want to add this to the libiberty merge you do now. I don't mind adding it to my script, if people agree that's what they want. It's just that nobody asked :-P
identifying a BB representing a self-loop
Some basic blocks may represent a (self) loop, but GCC's internal basic
block representation won't show such information explicitly (i.e., it won't
store a self-loop edge).
My question is, when I walk through basic blocks, can I identify then
easily?
E.g., Let's say,
--demo.c
int main(){
int i;
int sum = 0;
for (i=0; i< 10; i++){
sum = sum+i;
}
}
-
If we compile this by "#gcc -c -O -da demo.c, we can see there are only
three BBs. Actually, BB1 is a self-looped basic block. But this loop
information is not explicitly expressed.
BB0-->BB1-->BB2 (see details in the attached .cfg file)
-cat demo.c.08.cfg-
;; Function main
70 registers.
Register 59 used 2 times across 0 insns; set 2 times; user var; dies in 0
places.
Register 60 used 1 times across 0 insns; set 1 time; dies in 0 places.
3 basic blocks, 5 edges.
Basic block 0 prev -1, next 1, loop_depth 0, count 0, freq 1000, maybe hot.
Predecessors: ENTRY (fallthru)
Successors: 1 (fallthru)
Basic block 1 prev 0, next 2, loop_depth 1, count 0, freq 1, maybe hot.
Predecessors: 0 (fallthru) 1
Successors: 1 2 (fallthru)
Basic block 2 prev 1, next -2, loop_depth 0, count 0, freq 1000, maybe hot.
Predecessors: 1 (fallthru)
Successors: EXIT (fallthru)
try_optimize_cfg iteration 1
(note 2 0 20 NOTE_INSN_DELETED)
;; Start of basic block 0, registers live: (nil)
(note 20 2 9 0 [bb 0] NOTE_INSN_BASIC_BLOCK)
(insn 9 20 15 0 (parallel [
(set (reg/f:SI 7 sp)
(and:SI (reg/f:SI 7 sp)
(const_int -16 [0xfff0])))
(clobber (reg:CC 17 flags))
]) 200 {*andsi_1} (nil)
(nil))
(insn 15 9 7 0 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -16 [0xfff0])))
(clobber (reg:CC 17 flags))
]) 140 {*addsi_1} (nil)
(nil))
(note 7 15 22 0 NOTE_INSN_FUNCTION_BEG)
(insn 22 7 44 0 (set (reg/v:SI 59 [ i ])
(const_int 0 [0x0])) 35 {*movsi_1} (nil)
(nil))
;; End of basic block 0, registers live:
(nil)
(note 44 22 23 NOTE_INSN_LOOP_BEG)
;; Start of basic block 1, registers live: (nil)
(code_label 23 44 24 1 2 "" [1 uses])
(note 24 23 26 1 [bb 1] NOTE_INSN_BASIC_BLOCK)
(insn 26 24 27 1 (parallel [
(set (reg/v:SI 59 [ i ])
(plus:SI (reg/v:SI 59 [ i ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))
(insn 27 26 28 1 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:SI 59 [ i ])
(const_int 10 [0xa]))) -1 (nil)
(nil))
(jump_insn 28 27 45 1 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0x0]))
(label_ref 23)
(pc))) -1 (nil)
(expr_list:REG_BR_PROB (const_int 9000 [0x2328])
(nil)))
;; End of basic block 1, registers live:
(nil)
(note 45 28 31 NOTE_INSN_LOOP_END)
(note 31 45 41 NOTE_INSN_FUNCTION_END)
;; Start of basic block 2, registers live: (nil)
(note 41 31 35 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 35 41 36 2 (clobber (reg/i:SI 0 ax)) -1 (nil)
(nil))
(insn 36 35 40 2 (clobber (reg:SI 60 [ ])) -1 (nil)
(nil))
(insn 40 36 0 2 (use (reg/i:SI 0 ax)) -1 (nil)
(nil))
;; End of basic block 2, registers live:
(nil)
_
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: identifying a BB representing a self-loop
sean yang wrote:
> Some basic blocks may represent a (self) loop, but GCC's internal basic
> block representation won't show such information explicitly (i.e., it won't
> store a self-loop edge).
> My question is, when I walk through basic blocks, can I identify then
> easily?
>
> E.g., Let's say,
> --demo.c
> int main(){
> int i;
> int sum = 0;
> for (i=0; i< 10; i++){
> sum = sum+i;
> }
> }
> -
> If we compile this by "#gcc -c -O -da demo.c, we can see there are only
> three BBs. Actually, BB1 is a self-looped basic block. But this loop
> information is not explicitly expressed.
>
What do you mean "not explicitly expressed".
If you call the loop finding routines (flow_loops_find), and look in the
result loop information, does it not give you a loop with a single node?
address order and BB numbering
Although "BASIC_BLOCK array contains BBs in an unspecified order" as the GCC internal doc says, can I assume that the final virtual address for an instruction in BB_m is always higher than the virtual address for an instruction in BB_n, when m < n. (Let's assume the linker for the target machine produce code from low address to high address.) It seems to be rigth to me. Just curious. Thanks, _ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
Re: address order and BB numbering
On May 19, 2006, at 12:48 PM, sean yang wrote: Although "BASIC_BLOCK array contains BBs in an unspecified order" as the GCC internal doc says, can I assume that the final virtual address for an instruction in BB_m is always higher than the virtual address for an instruction in BB_n, when m < n. (Let's assume the linker for the target machine produce code from low address to high address.) Definitely not. Various phases that need to know the order of insns produce a CUID for that phase, but it is not maintained globally.
Re: identifying a BB representing a self-loop
From: Daniel Berlin <[EMAIL PROTECTED]>
To: sean yang <[EMAIL PROTECTED]>
CC: gcc@gcc.gnu.org, [EMAIL PROTECTED]
Subject: Re: identifying a BB representing a self-loop
Date: Fri, 19 May 2006 15:41:30 -0400
sean yang wrote:
> Some basic blocks may represent a (self) loop, but GCC's internal basic
> block representation won't show such information explicitly (i.e., it
won't
> store a self-loop edge).
> My question is, when I walk through basic blocks, can I identify then
> easily?
>
> E.g., Let's say,
> --demo.c
> int main(){
> int i;
> int sum = 0;
> for (i=0; i< 10; i++){
> sum = sum+i;
> }
> }
> -
> If we compile this by "#gcc -c -O -da demo.c, we can see there are only
> three BBs. Actually, BB1 is a self-looped basic block. But this loop
> information is not explicitly expressed.
>
What do you mean "not explicitly expressed".
If you call the loop finding routines (flow_loops_find), and look in the
result loop information, does it not give you a loop with a single node?
I meant that there is no edge like BB1-->BB1, if BB1 itself is a loop. For
example,
for (i=0; i<5;i++){
for (j=0; j<5; j++){
sum +=j;
}
}
The control flow graph may looks like this (with -O option): B1 represents
the inner loop(but no edge showing it's an loop); however, edge "B3-->B0"
shows the outer loop explicitly.
B0 ---> B1->B2-->B3
^ |
|___|
But I think your answer (flow_loops_find) may have already answered my
original question (how to know B1 is a loop. Thanks for the reply!
_
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: Can't build gcc trunk Fri May 19 10:52:05 UTC 2006 (revision 113904M) on cygwin: gcc/objc/objc-act.c:5573: warning: ....
On May 19, 2006, at 6:57 AM, Christian Joensson wrote: ../../gcc/gcc/objc/objc-act.c:5573: warning: implicit declaration of function 'default_conversion' Update and build again... :-)
Re: C FE question: Is this test even valid?
On May 19, 2006, at 12:01 PM, Diego Novillo wrote: Mark Mitchell wrote on 05/19/06 14:54: Yes, this test case is valid; the code is ill-formed GNU C, since the machine in question know not have a register named "unknown register". ^ I can't parse this. known to not have a register named...
Re: address order and BB numbering
From: Dale Johannesen <[EMAIL PROTECTED]> To: sean yang <[EMAIL PROTECTED]> CC: Dale Johannesen <[EMAIL PROTECTED]>, gcc@gcc.gnu.org Subject: Re: address order and BB numbering Date: Fri, 19 May 2006 12:54:56 -0700 On May 19, 2006, at 12:48 PM, sean yang wrote: Although "BASIC_BLOCK array contains BBs in an unspecified order" as the GCC internal doc says, can I assume that the final virtual address for an instruction in BB_m is always higher than the virtual address for an instruction in BB_n, when m < n. (Let's assume the linker for the target machine produce code from low address to high address.) Definitely not. Various phases that need to know the order of insns produce a CUID for that phase, but it is not maintained globally. Thanks for the answer. Then this must be a very dummy question. How the compiler keep the instruction order in the RTL IR format in a function? By the information like "insn 50 56 51" ? e.g., (insn 50 56 51 4 (clobber (reg/i:SI 0 ax)) -1 (nil) ) _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
Re: address order and BB numbering
sean yang wrote on 05/19/06 15:48: > can I assume that the final virtual address for > an instruction in BB_m is always higher than the virtual address for an > instruction in BB_n, when m < n. > No. Think code insertion.
Re: address order and BB numbering
> Then this must be a very dummy question. How the compiler keep the > instruction order in the RTL IR format in a function? By the information > like "insn 50 56 51" ? e.g., > (insn 50 56 51 4 (clobber (reg/i:SI 0 ax)) -1 (nil) ) It's a linked list. The 56 and 51 link to the previous and next insn in the chain.
Re: C FE question: Is this test even valid?
Diego Novillo wrote: > Mark Mitchell wrote on 05/19/06 14:54: > >> Yes, this test case is valid; the code is ill-formed GNU C, since the >> machine in question know not have a register named "unknown register". >> ^ > I can't parse this. Sorry; "machine in question is known not to have ..." In other words, since there is no such register on whatever machine is being targeted, the code is ill-formed, and we should issue an error. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Revert patch for MIPS TImode functions for 4.1.1
Roger Sayle <[EMAIL PROTECTED]> writes: > Indeed, no good deed ever goes unpunished. In fact, isn't it the MIPS > backend's use of the GOFAST libraries which is one of the major blockers > of adding -msoft-float tests to the testsuite? :-) No. As I've explained earlier this week, -msoft-float code is simply not link-compatible with -mhard-float code. Mark Mitchell <[EMAIL PROTECTED]> writes: > Andrew Pinski wrote: >>> Andrew Pinski wrote: >>> Also why revert a patch which obvious works in the default configurations? >>> It eliminates a Fortran problem, but causes a C problem. >> >> I thought it only caused the problem with C code when supplying -msoft-float >> which is not a default configuration? > > C code, compiled with -msoft-float, is very common on MIPS, whether or > not it's a "default configuration". Right. What do people mean by "default configuration"? The primary interest in MIPS these days is as an embedded platform, and the main bare-metal targets (mips-elf, mips64-elf mipsisa32-elf, mipsisa64-elf) all have -msoft-float multilibs. You don't have to do anything special to get them. Richard
Re: Revert patch for MIPS TImode functions for 4.1.1
Andrew Pinski <[EMAIL PROTECTED]> writes: > If the back-end was not lying to the front-ends, this would never > have been a problem, hint hint. I'm not sure what you mean here. In what way is the back end lying to the front end? Richard
gcc-4.1-20060519 is now available
Snapshot gcc-4.1-20060519 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060519/ 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 113915 You'll find: gcc-4.1-20060519.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20060519.tar.bz2 C front end and core compiler gcc-ada-4.1-20060519.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20060519.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20060519.tar.bz2 C++ front end and runtime gcc-java-4.1-20060519.tar.bz2 Java front end and runtime gcc-objc-4.1-20060519.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20060519.tar.bz2The GCC testsuite Diffs from 4.1-20060512 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.
Re: PATCH: Update src/intl from gcc/intl
DJ Delorie wrote: >> I will unless you want to add this to the libiberty merge you do now. > > I don't mind adding it to my script, if people agree that's what they > want. It's just that nobody asked :-P I hereby request that you add automatic intl/ merging to your script. :-) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: [Ada] two regressions c64103c & cd5003g in 113391 vs. 113355
On 5/2/06, Christian Joensson <[EMAIL PROTECTED]> wrote: On 5/1/06, Eric Botcazou <[EMAIL PROTECTED]> wrote: > > Any ideas? > > Re-run the testsuite, they most likely will disappear. right... I somehow had memory kernel related issues... A new one now... c9a011b there is something weird about c9a011b, at least on sparc/sparc64 linux... I seem to loose it beyond control, the test run will not go past it, no abort is done (no timeout). The load on th ecpu goes down, I use ps aux|grep c9a011b to find a few processes, kill the "first" one and the test run continues... -- Cheers, /ChJ -- Cheers, /ChJ
