Re: [Ada] multilib patch take three
> 1/ Ada multilib build is enabled unless --disable-multilib is used in > configure: this means that the Ada build has more opportunity to fail > because of code generation bugs or libada source selection issue, but in > this later case it will be a only few lines in gcc/ada/Makefile.in to > fix it once reported. Are you volunteering to make these changes when this will happen, or at least provide an easy work around (which does not involve --disable-multilib, since people probably want multilibs, at least for non Ada languages) ? > 2/ once built is installed no visible change for users, to use > multilib you have to follow directions above. > > The patch is missing some cleanup, comments, doc update and ChangeLog. > With those added and after the big tuple and gcc-interface changes are > in is this ok to resubmit and commit? If not what are the blocking > issues? Without seeing the changelog it's hard to comment in details, but I do not understand how installation works, and in particular why you commented out the 'install-gnatlib' target. I also do not understand how the selection of the right target run-time files is done in this scheme. I guess I need to see the changelog or some other explanation for that. Arno
Re: gcc will become the best optimizing x86 compiler
Raksit Ashok wrote: >There is a more optimized version for 64-bit: >http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/amd64/gen/memcpy.s >I think this looks similar to your implementation, Agner. Yes it is similar to my code. Gnu libc could borrow a lot of optimized functions from Opensolaris and Mac and other open source projects. They look better than Gnu libc, but there is still room for improvement. For example, Opensolaris does not use XMM registers for strlen, although this is simpler than using general purpose registers (see my code www.agner.org/optimize/asmlib.zip)
Re: [Ada] multilib patch take three
On Fri, 2008-07-25 at 09:00 +0200, Arnaud Charlet wrote: > > 1/ Ada multilib build is enabled unless --disable-multilib is used in > > configure: this means that the Ada build has more opportunity to fail > > because of code generation bugs or libada source selection issue, but in > > this later case it will be a only few lines in gcc/ada/Makefile.in to > > fix it once reported. > > Are you volunteering to make these changes when this will happen, or at least > provide an easy work around (which does not involve --disable-multilib, since > people probably want multilibs, at least for non Ada languages) ? Yes I volunteer. We're in stage1 so we have some time to sort out reported issues before release. > > 2/ once built is installed no visible change for users, to use > > multilib you have to follow directions above. > > > > The patch is missing some cleanup, comments, doc update and ChangeLog. > > With those added and after the big tuple and gcc-interface changes are > > in is this ok to resubmit and commit? If not what are the blocking > > issues? > > Without seeing the changelog it's hard to comment in details, but I do not > understand how installation works, and in particular > why you commented out the 'install-gnatlib' target. Only libada/Makefile.in install will be invoked for all multilib by the install machinery so gcc/ada/Makefile.in install cannot do properly the rts install work anymore, hence the change. The relevant libada/Makefile.in parts are now: +install-gnatlib: $(GCC_DIR)/ada/Makefile + $(MAKE) -C $(GCC_DIR)/ada $(LIBADA_FLAGS_TO_PASS) \ + libsubdir="$(libsubdir)" \ + install-gnatlib + # Installation rules. -install: +install: install-gnatlib + $(MULTIDO) DO=install multi-do # $(MAKE) I will remove instead of comment out. > I also do not understand how the selection of the right target run-time files > is done in this scheme. I guess I need to see the changelog or some other > explanation for that. It has to be done with ifeq on $(MULTISUBDIR) in gcc/ada/Makefile.in for all targets where there are multilib (according to gcc/config/*/t-*) and the rts sources are not generic. In the x86_64-linux case it was easy: +ifeq ($(strip $(filter-out %x86_64 linux%,$(arch) $(osys))),) + ifeq ($(strip $(MULTISUBDIR)),/32) +arch:=i686 + endif +endif Tactically I can submit the mechanical parts of the patch separately since it obscures the rest of the patch which is otherwise quite simple: << The patch touches lots of gcc/ada/Makefile.in but hopefully 99% of the change is mechanical: 1/ replace all use of "rts" by "$(RTSDIR)" 2/ replace all use of "stamp-gnatlib*" by "stamp-gnatlib*-$(RTSDIR)" Once these changes are in place by setting RTSDIR one can build multiple Ada rts without conflict from gcc/ada/Makefile.in >> I think this will help review and this is useful change on its own, should I test and submit this first part separately? Thanks in advance, Laurent PS: I did start some review of PAIRS but I could not find the "marte" runtime sources in SVN: a-exetim.adb
Re: lto gimple types and debug info
> When danny and it wrote the ipa-type-escape pass, mark mitchell was all > over us because we assumed that the type system had some semantic meaning. > We ended up with a pass that generally finds nothing useful. I would very > much like to redo that pass once we can mark a type as coming from a > language with a real type system. Did you enable Ada at this time ? What was this pass supposed to do ? Arno
Re: [Ada] multilib patch take three
> Yes I volunteer. We're in stage1 so we have some time to sort out > reported issues before release. OK. I'm still concerned that there is no simple fallback for all targets that will break, except for --disable-multilib which is too strong since it impacts other languages. I'd be much more confortable with e.g. adding a --disable-mutilibada or some such that would basically fall back to the previous state. > Only libada/Makefile.in install will be invoked for all multilib > by the install machinery so gcc/ada/Makefile.in install cannot > do properly the rts install work anymore, hence the change. The relevant > libada/Makefile.in parts are now: What about people using disable-multilib or --disable-libada ? I'd rather keep the part in ada/Makefile.in for these cases. > +install-gnatlib: $(GCC_DIR)/ada/Makefile > + $(MAKE) -C $(GCC_DIR)/ada $(LIBADA_FLAGS_TO_PASS) \ > + libsubdir="$(libsubdir)" \ > + install-gnatlib > + > > # Installation rules. > -install: > +install: install-gnatlib > + $(MULTIDO) DO=install multi-do # $(MAKE) Well, I still do not understand how install-gnatlib works in the new scheme, I guess I need more detailed explanation, since I am not familiar with multilib scheme. Could you explain in details how make install will install the various gnatlibs in the new scheme ? > Tactically I can submit the mechanical parts of the patch separately > since it obscures the rest of the patch which is otherwise quite simple: > > << > The patch touches lots of gcc/ada/Makefile.in but hopefully 99% of the > change is mechanical: > > 1/ replace all use of "rts" by "$(RTSDIR)" > 2/ replace all use of "stamp-gnatlib*" by "stamp-gnatlib*-$(RTSDIR)" > > Once these changes are in place by setting RTSDIR one can build > multiple Ada rts without conflict from gcc/ada/Makefile.in > >> It probably indeed makes sense to submit this separately. I see that you've modified this from your first patch for gnattools, right ? > I think this will help review and this is useful change on its own, > should I test and submit this first part separately? Yes, although I'd wait for the tuples branch and gcc-interface restructuration which will happen end of july/beginning of august. > PS: I did start some review of PAIRS but I could not find the "marte" > runtime sources in SVN: > a-exetim.adb Is it a commit oversight? This is not an oversight, this code is not suitable for the FSF (for one thing it is copyrighted). Having the Makefile change reduces the differences between AdaCore and FSF makefiles, which is highly desirable from a maintenance point of view. Arno
Re: [Ada] multilib patch take three
Arnaud Charlet wrote: Yes I volunteer. We're in stage1 so we have some time to sort out reported issues before release. OK. I'm still concerned that there is no simple fallback for all targets that will break, except for --disable-multilib which is too strong since it impacts other languages. I'd be much more confortable with e.g. adding a --disable-mutilibada or some such that would basically fall back to the previous state. I volunteer to check if there is support for --enable-multilib=libstdc++-v3,libjava and if not add it. Unfortunately, --disable-multilib=ada cannot work (because --disable-xxx is the same as --enable-multilib=no). As an alternative, people that don't want multilibbed libada can not use libada altogether. More on this in a second. Only libada/Makefile.in install will be invoked for all multilib by the install machinery so gcc/ada/Makefile.in install cannot do properly the rts install work anymore, hence the change. The relevant libada/Makefile.in parts are now: What about people using disable-multilib or --disable-libada ? I'd rather keep the part in ada/Makefile.in for these cases. Note that Laurent commented out install-gnatlib in ada/Make-lang.in. I agree though that it doesn't hurt to keep those targets, and I think that this hunk should not be included. Well, I still do not understand how install-gnatlib works in the new scheme, I guess I need more detailed explanation, since I am not familiar with multilib scheme. Could you explain in details how make install will install the various gnatlibs in the new scheme ? I guess everything will be more clear after the above: gcc/ada/Makefile.in is not changed, and both gcc/ada/Make-lang.in (once Laurent undoes that hunk) and libada/Makefile.in invoke it. The difference introduced by multilibbing is just a few lines like these: + $(MULTIDO) DO=all multi-do # $(MAKE) + $(MULTIDO) DO=install multi-do # $(MAKE) When multilibbing is disabled, MULTIDO=: and these lines is a no-op. When it is enabled, MULTIDO=$(MAKE) and they cause one recursive make invocation for each multilib (for example libada/32/Makefile). The multilibs differ in the default values of CFLAGS, and they know about this difference via another variable, MULTISUBDIR (which is for example /32 for libada/32/Makefile). This is what Laurent uses to conditionalize the PAIRS in gcc/ada/Makefile.in. Review of the patch follows: - -if [ -f gnat1$(exeext) ] ; \ - then \ - $(MAKE) $(FLAGS_TO_PASS) $(ADA_FLAGS_TO_PASS) install-gnatlib; \ - fi +# -if [ -f gnat1$(exeext) ] ; \ +# then \ +#$(MAKE) $(FLAGS_TO_PASS) $(ADA_FLAGS_TO_PASS) install-gnatlib; \ +# fi -install-gnatlib: - $(MAKE) -C ada $(FLAGS_TO_PASS) $(ADA_FLAGS_TO_PASS) install-gnatlib$(LIBGNAT_TARGET) +#install-gnatlib: +# $(MAKE) -C ada $(FLAGS_TO_PASS) $(ADA_FLAGS_TO_PASS) install-gnatlib$(LIBGNAT_TARGET) +# +#install-gnatlib-obj: +# $(MAKE) -C ada $(FLAGS_TO_PASS) $(ADA_FLAGS_TO_PASS) install-gnatlib-obj -install-gnatlib-obj: - $(MAKE) -C ada $(FLAGS_TO_PASS) $(ADA_FLAGS_TO_PASS) install-gnatlib-obj - ada.install-man: Revert as asked by Arnaud. +ifeq ($(strip $(filter-out %x86_64 linux%,$(arch) $(osys))),) + ifeq ($(strip $(MULTISUBDIR)),/32) +arch:=i686 + endif +endif Just $(filter-out %x86_64, $(arch)). No need to check for linux too, the /32 multilib name is pretty common. The same should be enough for both powerpc64 and sparc64. Index: libada/configure Don't include regenerated files in the patch, only in the ChangeLog. :-) +# GNU Make needs to see an explicit $(MAKE) variable in the command it +# runs to enable its job server during parallel builds. Hence the +# comments below. + +all-multi: + $(MULTIDO) $(AM_MAKEFLAGS) DO=all multi-do # $(MAKE) +install-multi: + $(MULTIDO) $(AM_MAKEFLAGS) DO=install multi-do # $(MAKE) + +.PHONY: all-multi install-multi + + +mostlyclean-multi: + $(MULTICLEAN) $(AM_MAKEFLAGS) DO=mostlyclean multi-clean # $(MAKE) +clean-multi: + $(MULTICLEAN) $(AM_MAKEFLAGS) DO=clean multi-clean # $(MAKE) +distclean-multi: + $(MULTICLEAN) $(AM_MAKEFLAGS) DO=distclean multi-clean # $(MAKE) +maintainer-clean-multi: + $(MULTICLEAN) $(AM_MAKEFLAGS) DO=maintainer-clean multi-clean # $(MAKE) + +.PHONY: mostlyclean-multi clean-multi distclean-multi maintainer-clean-multi + +install-exec-am: install-multi +## No uninstall rule? + + +## These cleaning rules are recursive. They should not be +## registered as dependencies of *-am rules. For instance +## otherwise running `make clean' would cause both +## clean-multi and mostlyclean-multi to be run, while only +## clean-multi is really expected (since clean-multi recursively +## call clean, it already do the job of mostlyclean). +mostlyclean: mostlyclean-multi +clean: clean-multi +distclean: distclean-multi +maintainer-clean: maintainer-clean-multi Not needed. +
Re: [Ada] multilib patch take three
Thanks Paolo for your explanations, things are getting much clearer! > I volunteer to check if there is support for > --enable-multilib=libstdc++-v3,libjava and if not add it. Unfortunately, > --disable-multilib=ada cannot work (because --disable-xxx is the same as > --enable-multilib=no). Does that mean that libgcc is implicitely multilibed if --enable-multilib= is used ? > As an alternative, people that don't want multilibbed libada can not use > libada altogether. More on this in a second. Still not clear to me what you mean here. > Note that Laurent commented out install-gnatlib in ada/Make-lang.in. I > agree though that it doesn't hurt to keep those targets, and I think that > this hunk should not be included. Agreed. > I guess everything will be more clear after the above: gcc/ada/Makefile.in > is not changed, and both gcc/ada/Make-lang.in (once Laurent undoes that > hunk) and libada/Makefile.in invoke it. Indeed, now things are clearer, thanks. >> +ifeq ($(strip $(filter-out %x86_64 linux%,$(arch) $(osys))),) >> + ifeq ($(strip $(MULTISUBDIR)),/32) >> +arch:=i686 >> + endif >> +endif > > Just $(filter-out %x86_64, $(arch)). No need to check for linux too, the > /32 multilib name is pretty common. Right. > The same should be enough for both powerpc64 and sparc64. I'd feel more confortable with ppc, sparc and x86 covered indeed, rather than just x86* Arno
Re: [Ada] multilib patch take three
Paolo Bonzini <[EMAIL PROTECTED]> writes: > Arnaud Charlet wrote: >>> Yes I volunteer. We're in stage1 so we have some time to sort out >>> reported issues before release. >> >> OK. I'm still concerned that there is no simple fallback for all targets >> that will break, except for --disable-multilib which is too strong since >> it impacts other languages. >> >> I'd be much more confortable with e.g. adding a --disable-mutilibada >> or some such that would basically fall back to the previous state. > > I volunteer to check if there is support for > --enable-multilib=libstdc++-v3,libjava and if not add it. Unfortunately, > --disable-multilib=ada cannot work (because --disable-xxx is the same as > --enable-multilib=no). But --enable-no-multilib=libada would work, or --disable-multilib-libada. 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: lto gimple types and debug info
On Fri, Jul 25, 2008 at 7:01 AM, Chris Lattner <[EMAIL PROTECTED]> wrote: >>> I dunno, this seems like a thing you could better figure out by trying >>> it and seeing where the problems are than by trying to anticipate >>> every single possible problem >>> (not that there should be no design, but that it would be better to >>> start with a design and iterate it than try to figure out perfect >>> ahead of time). >>> >> I agree that it is pointless to go thru the information bit by bit. On >> the other hand there may be other things like the typedefs that serve no >> purpose in the middle end but do take a lot of space and require time to >> traverse. >> However, at some point we are going to have to get down to the discussion >> of what it means for two types declared in two different compilation units >> to be "the same" and the less baggage that we have dragged in that is not >> relevant to that decision, the less unpleasant that process will be. > > Sure, typedefs in C/C++ seem clearly useless. I'm just curious how you plan > to go about deciding whether things are useless in a more general context. > How fine of a granularity do you intend to inspect bits? Trees have lots > of random stuff that are hard to identify and unify. Hopefully this will be > a good step towards making LTO actually be able to work with source files > that come from different languages. Does this mean that all > language-specific type info will be removed? Well, "removed" as in "transformed into bits of the common middle-end type system". As we get new fancy optimizations that require more information we can easily add to the middle-end type-system. In this light my advocacy for (1) becomes obvious ;) > More generally, can you detail what your plan is? Is it to remove specific > pieces (like typedefs, what else?) or just hack and slash random stuff if it > gets in your way? I'm more curious about your approach and "threshold for > usefulness" than an abstract statement about how you will remove useless > stuff and keep the useful stuff :) The approach would be to add pieces to an "empty" middle-end type system, not to remove things from what the frontends give us. This way we don't even need to look at all the stuff that is in the frontends, but can concentrate on what is useful and needed for the middle-end right now. Richard.
RE: --sysroot=yes
Something LIKE the below diff SEEMS "better".
It allows -with-build-sysroot to default like -with-sysroot.
I'm not sure that's really a goal. Depending on the direction,
it is reasonable. Or very unnecessary. Like, either I'm inventing
a new use of -with-build-sysroot, and then default it, or avoid
this new use. Before this diff, -with-build-sysroot is totally
not meant for my scenario. The compiler and linker already handled
the scenario just fine. But fixincludes, I don't see how.
This change does actually affect the compiler/linker in a somewhat
unintentional undesired but ok way. It ends up with a redundant
--sysroot flag -- redundant with how the compiler was already configured.
It makes -without-build-sysroot and -without-sysroot act "as expected".
I'm not sure that's really a goal, but comments indicated so.
It should/might/I-have-to-test allow "cross to native" to use
-with-build-sysroot to "fix" fixincludes.
Fixing cross to native fixincludes is the goal.
Requiring the -with-build-sysroot switch, not really, but maybe reasonable.
However, while this seems largely reasonable, and lets me do what I want a bit
easier:
perfectly correct:
configure -disable-bootstrap -build i686-pc-cygwin -host i686-pc-cygwin
-target sparc-sun-solaris2.10 -with-sysroot
fairly easy and works and makes some sense:
configure -disable-bootstrap -build i686-pc-cygwin -host
sparc-sun-solaris2.10 -target sparc-sun-solaris2.10 -with-build-sysroot
what I really think is reasonably is merely:
configure -disable-bootstrap -build i686-pc-cygwin -host
sparc-sun-solaris2.10 -target sparc-sun-solaris2.10
The last step has other options:
- use the fixed includes from the previous
But where are they?
- sniff the right headers to fix from gcc -v ?
Noticing it was configured with -with-sysroot?
Seems like it'd work, but also feels like a new and not good precedent.
(Not that I'd know..)
- sniff the right headers to fix from gcc -M ?
Seems like it'd work.
Requires gcc in an earlier step, but I believe that is very reasonable.
or, furthermore, there is an apparent option configure -without-fixproto.
There is an apparent nearby no longer active one configure -without-fixincludes.
(I haven't looked at history.)
That would also maybe help -- gcc can cope ok without the fixed includes?
This seems a bit of a cop out, since the headers are available.
On one hand, what I'm doing seems like a very normal scenario, once
you get away from purely native builds. But maybe not? Maybe
cross builds that don't have either glibc or newlib are rare? Or
maybe "crossing to native" is rare? Cross builds usually about either
crossing to embedded that can't run tools, or crossing from a faster
to slower host and not wanting to build on the slower host??
(I'm still stuck for terminology. It doesn't seem "Canadian" because
host=target, but it does seem "Canadian" because build != host...?)
--- gcc.orig\configure.ac 2008-02-01 19:29:30.0 -0800
+++ gcc.mine\configure.ac 2008-07-25 01:35:59.453125000 -0700
@@ -1644,15 +1644,20 @@
# To find our prefix, in gcc_cv_tool_prefix.
ACX_TOOL_DIRS
-copy_dirs=
+SYSROOT_CFLAGS_FOR_TARGET=
AC_ARG_WITH([build-sysroot],
[ --with-build-sysroot=SYSROOT
use sysroot as the system root during the build],
- [if test x"$withval" != x ; then
- SYSROOT_CFLAGS_FOR_TARGET="--sysroot=$withval"
- fi],
- [SYSROOT_CFLAGS_FOR_TARGET=])
+[
+ if test x"$with_build_sysroot" != x ; then
+if test x"$with_build_sysroot" != xno ; then
+ if test x"$with_build_sysroot" = xyes ; then
+with_build_sysroot='${exec_prefix}/${target_noncanonical}/sys-root'
+ fi
+ SYSROOT_CFLAGS_FOR_TARGET="--sysroot=$with_build_sysroot"
+fi
+ fi])
AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)
AC_ARG_WITH([debug-prefix-map],
@@ -1667,6 +1672,8 @@
[DEBUG_PREFIX_CFLAGS_FOR_TARGET=])
AC_SUBST(DEBUG_PREFIX_CFLAGS_FOR_TARGET)
+copy_dirs=
+
# Handle --with-headers=XXX. If the value is not "yes", the contents of
# the named directory are copied to $(tooldir)/sys-include.
if test x"${with_headers}" != x && test x"${with_headers}" != xno ; then
--- gcc.orig\gcc\configure.ac 2008-05-21 01:54:15.0 -0700
+++ gcc.mine\gcc\configure.ac 2008-07-25 01:35:59.65625 -0700
@@ -724,49 +724,82 @@
], [enable_shared=yes])
AC_SUBST(enable_shared)
-AC_ARG_WITH(build-sysroot,
- [ --with-build-sysroot=sysroot
- use sysroot as the system root during the build])
+
+#
+# Defaults for if neither -with-sysroot nor -with-build-sysroot are used.
+#
+TARGET_SYSTEM_ROOT=
+TARGET_SYSTEM_ROOT_DEFINE=
+CROSS_SYSTEM_HEADER_DIR='$(gcc_tooldir)/sys-include'
AC_ARG_WITH(sysroot,
[ --with-sysroot[=DIR] Search for usr/lib, usr/include, et al, within DIR.],
[
- case ${with_sysroot} in
- yes) TARGET_SYSTEM_ROOT='${exec_prefix}/${target_noncanonical}/sys-root' ;;
- *) TARGET_SYSTEM_ROOT=$wit
GCC, the GNU linker and the -z extract option
Hi, I'm a new poster here. I am porting some Solaris code over to Linux and using the GNU compiler and linker. Now I have a "meta library"(creating a "master" shared object from mayny shared objects) which creates fine in Solaris but in Linux it doesn't create as a meta library - ldd suggests that it depends on the libraries which were previously used to produce the meta library on solaris. Looking into this I can see that with every .so we effectively lose the identity and so with a metalibrary what we need to do is to "unravel" the .sos to produce the meta library. I do this in Solaris using the -z extract option. I can't see how to do this in Linux using the GNU linker. Anyone any ideas? Thanks -- View this message in context: http://www.nabble.com/GCC%2C-the-GNU-linker-and-the--z-extract-option-tp18647984p18647984.html Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: [Ada] multilib patch take three
I volunteer to check if there is support for --enable-multilib=libstdc++-v3,libjava and if not add it. Unfortunately, --disable-multilib=ada cannot work (because --disable-xxx is the same as --enable-multilib=no). Does that mean that libgcc is implicitely multilibed if --enable-multilib= is used ? No, I just meant "adding a parameter to --enable-multilib to specify what to multilib". As an alternative, people that don't want multilibbed libada can not use libada altogether. More on this in a second. Still not clear to me what you mean here. I was thinking about using --disable-libada and instead using the "make -C gcc gnatlib" target. You will get no multilibs but I'm not up-to-date as to how you build the tools without libada nowadays. Paolo
Re: [Ada] multilib patch take three
>>> As an alternative, people that don't want multilibbed libada can not use >>> libada altogether. More on this in a second. >> >> Still not clear to me what you mean here. > > I was thinking about using --disable-libada and instead using the "make -C > gcc gnatlib" target. You will get no multilibs but I'm not up-to-date as > to how you build the tools without libada nowadays. Well, this part requires some manual fiddling, so this would not be very user friendly as a way to 'revert to the previous state', so if it's not too difficult to add a --disable-multilib-libada, I think that'd be preferable, although I won't insist on it if it's too much extra work. Arno
Re: [Ada] multilib patch take three
On Fri, 2008-07-25 at 09:35 +0200, Arnaud Charlet wrote: > > I think this will help review and this is useful change on its own, > > should I test and submit this first part separately? > > Yes, although I'd wait for the tuples branch and gcc-interface restructuration > which will happen end of july/beginning of august. Ok, I'll wait for these events and then submit in two parts: the mechanical part and the multilib part with Paolo and your suggestions taken into account. Thanks for your review of this pre-patch. Laurent
RE: --sysroot=yes
On Fri, 25 Jul 2008, Jay wrote: > It allows -with-build-sysroot to default like -with-sysroot. The purpose of --with-build-sysroot is if you have installed your sysroot in a different location from the configured --prefix. For example, you have configured with --prefix=/opt/somewhere, the final location the toolchain will be configured for, but have installed the sysroot under /scratch/somewhere, a staging location used in the build, and will be installing with "make install prefix=/scratch/somewhere". There should be no need for or use of --with-build-sysroot except in configurations like this. -- Joseph S. Myers [EMAIL PROTECTED]
Re: [Ada] multilib patch take three
On Fri, 25 Jul 2008, Laurent GUERBY wrote: > The attached patch implements Arnaud suggestion of changing the arch > to select the appropriate source (done and tested for x86_64-linux only > for now) and doesn't touch anymore system-*.ads. As a general comment on x86_64 handling, not having checked the details of this patch: i686-linux-gnu --enable-targets=all and x86_64-linux-gnu are equivalent, differing only in whether the default is 32-bit or 64-bit. Do you select the right files for both multilibs of i686-linux-gnu, as well as for both multilibs of x86_64-linux-gnu? (Some targets have the 32-bit-default as the only or the normal target, e.g. Solaris and Darwin.) -- Joseph S. Myers [EMAIL PROTECTED]
Re: [Ada] multilib patch take three
On Fri, 2008-07-25 at 10:55 +, Joseph S. Myers wrote: > i686-linux-gnu --enable-targets=all and x86_64-linux-gnu are equivalent, > differing only in whether the default is 32-bit or 64-bit. Do you select > the right files for both multilibs of i686-linux-gnu, as well as for both > multilibs of x86_64-linux-gnu? (Some targets have the 32-bit-default as > the only or the normal target, e.g. Solaris and Darwin.) I didn't know about --enable-targets=all so I'd say this case is not handled by the current pre-patch on i686 but I will work on adding support for it. If you think of other configure flags having an impact on multilib machinery let me know. Thanks for the notice, Laurent
Re: [Ada] multilib patch take three
Laurent GUERBY wrote: On Fri, 2008-07-25 at 10:55 +, Joseph S. Myers wrote: i686-linux-gnu --enable-targets=all and x86_64-linux-gnu are equivalent, differing only in whether the default is 32-bit or 64-bit. Do you select the right files for both multilibs of i686-linux-gnu, as well as for both multilibs of x86_64-linux-gnu? (Some targets have the 32-bit-default as the only or the normal target, e.g. Solaris and Darwin.) I didn't know about --enable-targets=all so I'd say this case is not handled by the current pre-patch on i686 but I will work on adding support for it. I think you just need to check for a /64 multilib and change the arch accordingly. Paolo
Re: lto gimple types and debug info
Arnaud Charlet wrote: When danny and it wrote the ipa-type-escape pass, mark mitchell was all over us because we assumed that the type system had some semantic meaning. We ended up with a pass that generally finds nothing useful. I would very much like to redo that pass once we can mark a type as coming from a language with a real type system. Did you enable Ada at this time ? What was this pass supposed to do ? Arno I do not remember. The problem is not dealing with Ada, it is dealing with Ada as if it was C. What we do is correct for ada or java, it is just much more conservative that anyone would ever be if one were writing a compiler for those languages. the pass determines if all uses of a type are completely encapsulated within the compilation unit. Most types are generally not, but if you compile with -combine (which only works for C), then in theory there would be more of them. The idea is that if you have a fully encapsulated type, then the compiler would be free to implement any variables of this type as it saw fit (changing the alignment, reordering the fields, peeling ...). Kenny
Re: lto gimple types and debug info
On Fri, Jul 25, 2008 at 1:47 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > Arnaud Charlet wrote: >>> >>> When danny and it wrote the ipa-type-escape pass, mark mitchell was all >>> over us because we assumed that the type system had some semantic meaning. >>> We ended up with a pass that generally finds nothing useful. I would very >>> much like to redo that pass once we can mark a type as coming from a >>> language with a real type system. >>> >> >> Did you enable Ada at this time ? >> What was this pass supposed to do ? >> >> Arno >> > > I do not remember. The problem is not dealing with Ada, it is dealing with > Ada as if it was C. What we do is correct for ada or java, it is just much > more conservative that anyone would ever be if one were writing a compiler > for those languages. > the pass determines if all uses of a type are completely encapsulated within > the compilation unit. Most types are generally not, but if you compile with > -combine (which only works for C), then in theory there would be more of > them. > > The idea is that if you have a fully encapsulated type, then the compiler > would be free to implement any variables of this type as it saw fit > (changing the alignment, reordering the fields, peeling ...). I actually never understood why we need type escape analysis here. Can't we just see if the actual objects do escape? Richard.
Re: lto gimple types and debug info
Richard Guenther wrote: On Fri, Jul 25, 2008 at 1:47 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: Arnaud Charlet wrote: When danny and it wrote the ipa-type-escape pass, mark mitchell was all over us because we assumed that the type system had some semantic meaning. We ended up with a pass that generally finds nothing useful. I would very much like to redo that pass once we can mark a type as coming from a language with a real type system. Did you enable Ada at this time ? What was this pass supposed to do ? Arno I do not remember. The problem is not dealing with Ada, it is dealing with Ada as if it was C. What we do is correct for ada or java, it is just much more conservative that anyone would ever be if one were writing a compiler for those languages. the pass determines if all uses of a type are completely encapsulated within the compilation unit. Most types are generally not, but if you compile with -combine (which only works for C), then in theory there would be more of them. The idea is that if you have a fully encapsulated type, then the compiler would be free to implement any variables of this type as it saw fit (changing the alignment, reordering the fields, peeling ...). I actually never understood why we need type escape analysis here. Can't we just see if the actual objects do escape? Richard. If you do it on an object basis, you have to clone code, one version to handle the objects that were changed and one to handle the objects that did not change.
Re: lto gimple types and debug info
Richard Guenther wrote: On Fri, Jul 25, 2008 at 7:01 AM, Chris Lattner <[EMAIL PROTECTED]> wrote: I dunno, this seems like a thing you could better figure out by trying it and seeing where the problems are than by trying to anticipate every single possible problem (not that there should be no design, but that it would be better to start with a design and iterate it than try to figure out perfect ahead of time). I agree that it is pointless to go thru the information bit by bit. On the other hand there may be other things like the typedefs that serve no purpose in the middle end but do take a lot of space and require time to traverse. However, at some point we are going to have to get down to the discussion of what it means for two types declared in two different compilation units to be "the same" and the less baggage that we have dragged in that is not relevant to that decision, the less unpleasant that process will be. Sure, typedefs in C/C++ seem clearly useless. I'm just curious how you plan to go about deciding whether things are useless in a more general context. How fine of a granularity do you intend to inspect bits? Trees have lots of random stuff that are hard to identify and unify. Hopefully this will be a good step towards making LTO actually be able to work with source files that come from different languages. Does this mean that all language-specific type info will be removed? Well, "removed" as in "transformed into bits of the common middle-end type system". As we get new fancy optimizations that require more information we can easily add to the middle-end type-system. In this light my advocacy for (1) becomes obvious ;) Despite my bias towards (4), (1) really is a reasonable option. We do not do these transformations except at high optimization levels, and the code at that point is mostly undebuggable anyway. More generally, can you detail what your plan is? Is it to remove specific pieces (like typedefs, what else?) or just hack and slash random stuff if it gets in your way? I'm more curious about your approach and "threshold for usefulness" than an abstract statement about how you will remove useless stuff and keep the useful stuff :) The approach would be to add pieces to an "empty" middle-end type system, not to remove things from what the frontends give us. This way we don't even need to look at all the stuff that is in the frontends, but can concentrate on what is useful and needed for the middle-end right now. And if doing (4) means that the gimple type system is as fat as the front end one, then there will be no gimple type system. Richard.
Re: Length-Changing Prefixes problem with the x86 Backend
On Thu, 26 Jun 2008 Uros wrote: >Please also add a runtime test that can be used to analyze the problem. I am a temporary guest on the gcc mailing list and I haven't seen your mail before. In case your problem hasn't been solved yet, I can inform you that I have a disassembler which puts comments into the disassembly file in case of length-changing prefixes and other sub-optimal or illegal instruction codes. Just compile with -c to get an object file and run it on the disassembler: objconv -fasm yourfile.o yourfile.asm It supports all x86 instruction sets up to SSE4.2 and SSE5 (but not AVX and FMA yet). It may be useful for testing other compiler features as well, such as support for new instruction sets. Get it from www.agner.org/optimize/objconv.zip This is a cross-platform multi-purpose tool. The assembly output is in MASM format, not AT&T. Use .intel_syntax noprefix in case you want to assemble the disassembly on GAS.
Re: GCC, the GNU linker and the -z extract option
On Fri, Jul 25, 2008 at 2:06 AM, eoin <[EMAIL PROTECTED]> wrote: > > Hi, > I'm a new poster here. I am porting some Solaris code over to Linux and > using the GNU compiler and linker. Now I have a "meta library"(creating a > "master" shared object from mayny shared objects) which creates fine in > Solaris but in Linux it doesn't create as a meta library - ldd suggests that > it depends on the libraries which were previously used to produce the meta > library on solaris. > Looking into this I can see that with every .so we effectively lose the > identity and so with a metalibrary what we need to do is to "unravel" the > .sos to produce the meta library. > I do this in Solaris using the -z extract option. I can't see how to do > this in Linux using the GNU linker. Anyone any ideas? > This has nothing to do with gcc. Please ask it on binutils mailing list with an example. -- H.J.
Re: [Ada] multilib patch take three
Laurent GUERBY wrote: Joel did test (a previous iteration of) this patch on many RTEMS multilibed targets and it worked (RTEMS system.ads already use Standard attributes to be portable so no issue there). I thought I would follow up with some details. I tested on mips, powerpc, x86, and sparc. I ran the c, c++, and Ada tests with no change in results from this patch. I will follow up over the next few days with some tests on a couple of BSPs which require multilib variants to work. I can attempt to build other RTEMS targets (arm, sh, m68k, etc) if you guys want me to. Adding multilib variants sometimes trips new compiler bugs and building more will shake some of those out. For those who care, the RTEMS multilib set on the powerpc, mips, sparc, and i386 targets are attached. It is 31 variants across the 4 targets so a pretty good work out. --joel powerpc-rtems4.9 multilibs .;@[EMAIL PROTECTED]@mstrict-align m403;@[EMAIL PROTECTED]@[EMAIL PROTECTED] m505;@[EMAIL PROTECTED]@[EMAIL PROTECTED] m601;@[EMAIL PROTECTED]@[EMAIL PROTECTED] m603e;@[EMAIL PROTECTED]@[EMAIL PROTECTED] m604;@[EMAIL PROTECTED]@[EMAIL PROTECTED] m860;@[EMAIL PROTECTED]@[EMAIL PROTECTED] m7400;@[EMAIL PROTECTED]@[EMAIL PROTECTED] nof;@[EMAIL PROTECTED]@[EMAIL PROTECTED] m601/nof;@[EMAIL PROTECTED]@[EMAIL PROTECTED]@mstrict-align m603e/mpc8260;@[EMAIL PROTECTED]@[EMAIL PROTECTED]@mstrict-align m603e/nof;@[EMAIL PROTECTED]@[EMAIL PROTECTED]@mstrict-align m603e/mpc8260/nof;@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] m604/nof;@[EMAIL PROTECTED]@[EMAIL PROTECTED]@mstrict-align m7400/nof;@[EMAIL PROTECTED]@[EMAIL PROTECTED]@mstrict-align sparc-rtems4.9 multilibs .; soft;@msoft-float v8;@mcpu=v8 soft/v8;@[EMAIL PROTECTED] mips-rtems4.9 multilibs .; mips32;@mips32 soft-float;@msoft-float mips3/el;@[EMAIL PROTECTED] mips3/el/soft-float;@[EMAIL PROTECTED]@msoft-float mips32/soft-float;@[EMAIL PROTECTED] i386-rtems4.9 multilibs .; m486;@mtune=i486 mpentium;@mtune=pentium mpentiumpro;@mtune=pentiumpro soft-float;@msoft-float m486/soft-float;@[EMAIL PROTECTED]
Merging tuples branch into mainline today
We were discussing the status of the tuples branch on IRC today and we collectively agreed that it would be a good idea to merge the branch into mainline today. I am planning to start the merge process, but first I wanted to freeze mainline to minimize merge issues. Any objections to this plan? Thanks. Diego.
Re: Merging tuples branch into mainline today
Diego Novillo wrote: We were discussing the status of the tuples branch on IRC today and we collectively agreed that it would be a good idea to merge the branch into mainline today. I think it would be good to post a summary of the current state. Are there any regressions? Any known features that worked before that will not work after the merge? Other than that, no, I don't object. We want this in for 4.4, and, if it's ready, now is a good time. So, let's consider the mainline frozen as of 5PM PDT this afternoon. That will give folks a chance to complete any checkins that are already in flight. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Merging tuples branch into mainline today
On Fri, Jul 25, 2008 at 8:03 AM, Diego Novillo <[EMAIL PROTECTED]> wrote: > > We were discussing the status of the tuples branch on IRC today and we > collectively agreed that it would be a good idea to merge the branch into > mainline today. > > I am planning to start the merge process, but first I wanted to freeze > mainline to minimize merge issues. > > Any objections to this plan? > Mainline is currently broken on a few platforms: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907 I think we should fix it first before another big merge. -- H.J.
Re: Merging tuples branch into mainline today
H.J. Lu wrote: Mainline is currently broken on a few platforms: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907 I think we should fix it first before another big merge. Diego, what do you think? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: lto gimple types and debug info
On Jul 25, 2008, at 1:54 AM, Richard Guenther wrote: Sure, typedefs in C/C++ seem clearly useless. I'm just curious how you plan to go about deciding whether things are useless in a more general context. How fine of a granularity do you intend to inspect bits? Trees have lots of random stuff that are hard to identify and unify. Hopefully this will be a good step towards making LTO actually be able to work with source files that come from different languages. Does this mean that all language-specific type info will be removed? Well, "removed" as in "transformed into bits of the common middle-end type system". As we get new fancy optimizations that require more information we can easily add to the middle-end type-system. Ok. More generally, can you detail what your plan is? Is it to remove specific pieces (like typedefs, what else?) or just hack and slash random stuff if it gets in your way? I'm more curious about your approach and "threshold for usefulness" than an abstract statement about how you will remove useless stuff and keep the useful stuff :) The approach would be to add pieces to an "empty" middle-end type system, not to remove things from what the frontends give us. This way we don't even need to look at all the stuff that is in the frontends, but can concentrate on what is useful and needed for the middle-end right now. Sure, this makes plenty of sense to me (and sounds very *very* familiar). Do you intend to include things like TBAA in the initial type system? That is one example of extremely important information which requires pulling in almost the entire source type system. -Chris
Re: Merging tuples branch into mainline today
On Fri, 25 Jul 2008, Mark Mitchell wrote: > H.J. Lu wrote: > > > Mainline is currently broken on a few platforms: > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907 > > > > I think we should fix it first before another big merge. > > Diego, what do you think? Of the 7 platforms I can test (i586,x86_64,ia64,s390,s390x,ppc,ppc64) only ia64 is broken on the trunk right now and a patch was submitted which could go in before the merge. Richard.
Re: Merging tuples branch into mainline today
On 7/25/08 12:42 PM, Mark Mitchell wrote: H.J. Lu wrote: Mainline is currently broken on a few platforms: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907 I think we should fix it first before another big merge. Diego, what do you think? Well, what I understand is that the breakage is due to the function-specific patches, and both branches are pretty orthogonal. Merging tuples will neither help nor hinder fixing that problem, so in principle I would vote to merge just the same. In terms of regressions versus mainline, the only regressions introduced by tuples wrt mainline are the matrix-reorg pass that still has not been converted. It also fixes 4 libstdc++ testcases that are currently broken in trunk: Fixed regressions in tuples/00testsuite.x86_64.legolas/20080725/libstdc++.sum.gz: FAIL: ext/pb_ds/regression/hash_data_map_rand.cc (test for excess errors) FAIL: ext/pb_ds/regression/list_update_data_map_rand.cc (test for excess errors) FAIL: ext/pb_ds/regression/tree_data_map_rand.cc (test for excess errors) FAIL: ext/pb_ds/regression/trie_data_map_rand.cc (test for excess errors) Diego.
Re: Merging tuples branch into mainline today
Diego Novillo wrote: In terms of regressions versus mainline, the only regressions introduced by tuples wrt mainline are the matrix-reorg pass that still has not been converted. Why not fix that before merging, then? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: installed gnat files in multilib install
On Fri, 2008-07-25 at 08:40 -0500, Joel Sherrill wrote:
> Attached is the Ada library parts of my install
> tree with multilib'ed Ada for mips, powerpc, i386,
> and sparc on RTEMS. It is the output of doing this:
>
> cd ${prefix}
> find `find . -name adainclude` >ada-include.txt
> find . -name libgn*a >/tmp/ada-libs.txt
>
> FWIW the ACATS results are unchanged on the four
> targets I regularly test. I plan to test a couple
> of BSPs that have to use the multilib'ed libraries
> today.
Great news! mips/powerpc/x86/sparc cover the major
Ada native ports likely to have multilibs, your tests
show the probability of build failure is low.
> In adding multilib variants in the past, we have tripped
> new compiler bugs since RTEMS tends to build a lot of variants
> I am pleased to see that we have not tripped one yet
> on the four targets and their 31 multilib variants.
> Arnaud you are right to be concerned but so far things
> look good. There are other targets and variants though.
> I can try a build for arm, m68k, sh or bfin without
> much trouble. I can't run ACATS on them but can build
> them. Is there one you think Ada is in good shape on
> that you want me to try building?
m68k has one target in gcc/ada/Makefile.in (vxworks) so it would
be nice to test. arm, sh and bfin do not seem to appear although
arm would be nice to have too (I got an email from someone who
successfully built ada on arm target so may be there will be a
submission at some point).
Laurent
Re: Merging tuples branch into mainline today
On Fri, Jul 25, 2008 at 13:03, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Diego Novillo wrote: > >> In terms of regressions versus mainline, the only regressions introduced >> by tuples wrt mainline are the matrix-reorg pass that still has not been >> converted. > > Why not fix that before merging, then? Because it is not a pass that is run by default, it is not receiving active maintenance and the cost/benefit of doing it pre-merge is lower than fixing the pass post-merge. If that is a problem, we can keep delaying the merge until it's fixed, of course. I don't know how long will that take, I've got a partial patch that does it, but it needs some TLC, so it should be a few days. If I'm the one to finish it, though, it will have to wait until the 3rd week of August, as I will be traveling until then. Diego.
Re: Merging tuples branch into mainline today
Diego Novillo wrote: Why not fix that before merging, then? Because it is not a pass that is run by default, it is not receiving active maintenance and the cost/benefit of doing it pre-merge is lower than fixing the pass post-merge. If that is a problem, we can keep delaying the merge until it's fixed, of course. Normally, we try to get major new functionality to meet the no-regression test before merging. However, I can see that in the case of tuples it might be easier for everyone to stop having to worry about tuplifying new code. I think that someone, though, should be committed to fixing this pass ASAP after it's checked in; waiting until late August to fix it seems bad. Is there someone else who can commit to working on it as a high priority after the main tuples checkin? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: lto gimple types and debug info
Hi, On Fri, 25 Jul 2008, Chris Lattner wrote: > >the frontends, but can concentrate on what is useful and needed for the > >middle-end right now. > > Sure, this makes plenty of sense to me (and sounds very *very* > familiar). Do you intend to include things like TBAA in the initial > type system? I sure hope so. > That is one example of extremely important information which requires > pulling in almost the entire source type system. But not all the trees implementing those types (and all the cross-references between those, that are important for parsing but not interesting at all for the middle-end). All you need is a tag (alias set number) per type and a graph giving the conflicts between those tags. Ciao, Michael.
Re: Merging tuples branch into mainline today
On Fri, Jul 25, 2008 at 6:19 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Diego Novillo wrote: > >>> Why not fix that before merging, then? >> >> Because it is not a pass that is run by default, it is not receiving >> active maintenance and the cost/benefit of doing it pre-merge is lower >> than fixing the pass post-merge. If that is a problem, we can keep >> delaying the merge until it's fixed, of course. > > Normally, we try to get major new functionality to meet the no-regression > test before merging. However, I can see that in the case of tuples it might > be easier for everyone to stop having to worry about tuplifying new code. > > I think that someone, though, should be committed to fixing this pass ASAP > after it's checked in; waiting until late August to fix it seems bad. Is > there someone else who can commit to working on it as a high priority after > the main tuples checkin? If this pass is effectively unmaintained, why not just remove it? Unmaintained passes that are not enabled at any optimization level are usually broken anyway. Gr. Steven
RE: Merging tuples branch into mainline today
Diego Novillo wrote on 25 July 2008 17:15: > On Fri, Jul 25, 2008 at 13:03, Mark Mitchell <[EMAIL PROTECTED]> > wrote: >> Diego Novillo wrote: >> >>> In terms of regressions versus mainline, the only regressions introduced >>> by tuples wrt mainline are the matrix-reorg pass that still has not been >>> converted. >> >> Why not fix that before merging, then? > > Because it is not a pass that is run by default, it is not receiving > active maintenance and the cost/benefit of doing it pre-merge is lower > than fixing the pass post-merge. If that is a problem, we can keep > delaying the merge until it's fixed, of course. > > I don't know how long will that take, I've got a partial patch that > does it, but it needs some TLC, so it should be a few days. Maybe the pass should be temporarily disabled in the pass manager for the intervening duration then? Or the testcases marked XFAIL for that time? cheers, DaveK -- Can't think of a witty .sigline today
Re: Merging tuples branch into mainline today
Steven Bosscher wrote: If this pass is effectively unmaintained, why not just remove it? Unmaintained passes that are not enabled at any optimization level are usually broken anyway. That's an option, too; the question is whether it has any value. I don't know. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
RE: Merging tuples branch into mainline today
Mark Mitchell wrote on 25 July 2008 17:30: > Steven Bosscher wrote: > >> If this pass is effectively unmaintained, why not just remove it? >> Unmaintained passes that are not enabled at any optimization level are >> usually broken anyway. > > That's an option, too; the question is whether it has any value. I > don't know. Seems a bit of a shame though; it was only just contributed fairly recently, wasn't it? cheers, DaveK -- Can't think of a witty .sigline today
Re: Merging tuples branch into mainline today
> I think that someone, though, should be committed to fixing this pass ASAP > after it's checked in; waiting until late August to fix it seems bad. Is > there someone else who can commit to working on it as a high priority after > the main tuples checkin? I would obviously vote in favor of removal if the pass is unmaintained, but if it is agreed that it will be maintained, I can commit to working on it as soon as we merge. If it is maintained, I would count on having the maintainers provide me some consulting help throughout the conversion :). Aldy
Re: Merging tuples branch into mainline today
> In terms of regressions versus mainline, the only regressions introduced by > tuples wrt mainline are the matrix-reorg pass that still has not been > converted. It also fixes 4 libstdc++ testcases that are currently broken > in trunk: Apart from the matrix-reorg regressions, there are the Divide_[12] failures in libjava, which I think are actually one bug. I've been spinning my wheels on this the last day, and could use help from the java community, or someone more EH savvy than me. I am not sure if the last set of patches from Richi and friends has fixed Divide_[12] though. Aldy
Re: Merging tuples branch into mainline today
> > I think that someone, though, should be committed to fixing this pass ASAP > > after it's checked in; waiting until late August to fix it seems bad. Is > > there someone else who can commit to working on it as a high priority after > > the main tuples checkin? > > I would obviously vote in favor of removal if the pass is unmaintained, > but if it is agreed that it will be maintained, I can commit to working > on it as soon as we merge. For me, I see value of IPA struct reorg and matrix reorg passes primarily as an example of more advanced things we really want to do in future with our IPA framework. Making IPA framework to work resonably well for inliner is easy, for those passes we can test more of infrastructure - working with datastructure layout changes, aliasing and type escape info and so. So while the passes are probably now well in "benchmark toy" category and they will need many changes to be useful in general, I think it is good to have something we can test the framework at. We now have IPCP, struct reorg and matrix reorg, IPCP is hopefully getting closer for -O2/O3 candidate. But given this, I don't personally see this pass as blocker at all. I would be even happy if there was release with this pass non-functional before things mature enough. Honza > > If it is maintained, I would count on having the maintainers provide me > some consulting help throughout the conversion :). > > Aldy
Re: Merging tuples branch into mainline today
Jan Hubicka wrote: So while the passes are probably now well in "benchmark toy" category and they will need many changes to be useful in general, I think it is good to have something we can test the framework at. Do these passes actually help on benchmarks? I don't think we should be dismissive of "benchmark toy" passes if they actually improve benchmarks significantly. We don't have to like it, but we should accept that people are going to benchmark GCC against its proprietary competition, and that having good benchmark results matters. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Merging tuples branch into mainline today
Aldy Hernandez wrote: I would obviously vote in favor of removal if the pass is unmaintained, but if it is agreed that it will be maintained, I can commit to working on it as soon as we merge. My understanding is that this patch originated at IBM Haifa. Razya, can you commit to helping Aldy with this? Diego, I think that given Aldy's offer, we can remove this as an issue. Go ahead with the merge, if you're ready. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
I will not merge tuples into mainline today
While doing the final trunk->tuples merge, I was surprised to find several changes to the inliner and IPA cprop that I was convinced were not going to happen until after the branch was merged. So, I will now review the changes that Martin had posted for tuples, let him commit the reviewed patch and then try again the merge next week (probably next Thursday or Friday). Martin, Jan, does this sound OK to you? Diego.
Re: compressed pointer type implementation in gcc
Thanks for the help everyone. I would like to begin working on this (== supporting this natively in the compiler with a keyword/modifier (not sure about the correct term :))). What steps do I need to take before beginning in order to ensure this effort will go into the main branch once it's complete? Thanks! Yair
Re: I will not merge tuples into mainline today
On Fri, Jul 25, 2008 at 9:35 PM, Diego Novillo <[EMAIL PROTECTED]> wrote: > > While doing the final trunk->tuples merge, I was surprised to find several > changes to the inliner and IPA cprop that I was convinced were not going to > happen until after the branch was merged. > > So, I will now review the changes that Martin had posted for tuples, let him > commit the reviewed patch and then try again the merge next week (probably > next Thursday or Friday). I will try to organize another merge attempt on Monday. Please refrain from checking in large changes to trunk that do not help the merge. Thanks, Richard.
Re: Merging tuples branch into mainline today
> Mark Mitchell writes: Mark> Do these passes actually help on benchmarks? Mark> I don't think we should be dismissive of "benchmark toy" passes if they Mark> actually improve benchmarks significantly. We don't have to like it, Mark> but we should accept that people are going to benchmark GCC against its Mark> proprietary competition, and that having good benchmark results matters. The passes improve the performance of SPEC CPU2000 benchmark 179.art. While the analysis can discover and recommend some effective transformations in real-world applications, it is unclear whether GCC can determine when the transformation is profitable and whether GCC must be so conservative in its safety checks that it rarely an apply the transformations. In other words, the pass may be better an an analysis tool providing feedback to programmers instead of a completely automatic transformation pass. David
Re: Merging tuples branch into mainline today
> Jan Hubicka wrote: > >So while the passes are probably now well in "benchmark toy" category > >and they will need many changes to be useful in general, I think it is > >good to have something we can test the framework at. > > Do these passes actually help on benchmarks? Yes, those help signifcandly to SPEC2000 ART benchmark and some others. I didn't mean benchmark toy too mismissively here though, I like the idea overall and think there is great potential in this kind of transforms. Clearly for C++ we need optimization passes that reorganize the datastructure layout, are able to remove unnecesary abstraction and such. Ayal was mentioning struct reorg with hand tweaked escape analysis actualy can make over 10% improvement on some http server. The problem however is that with current strength of type-escape, lack of alias and points-to info and link time optimization, the passes themselves are not helping much real world applications. So I don't think we need to see them as major showstoppers for projects like tuples that actually makes LTO possible. At the same time I don't think they should be dropped completely. Lets just concentrate on infrastructure and update them as needed. Honza > > I don't think we should be dismissive of "benchmark toy" passes if they > actually improve benchmarks significantly. We don't have to like it, > but we should accept that people are going to benchmark GCC against its > proprietary competition, and that having good benchmark results matters. > > Thanks, > > -- > Mark Mitchell > CodeSourcery > [EMAIL PROTECTED] > (650) 331-3385 x713
Re: gcc will become the best optimizing x86 compiler
On Fri, Jul 25, 2008 at 09:08:42AM +0200, Agner Fog wrote: > Raksit Ashok wrote: > >There is a more optimized version for 64-bit: > >http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/amd64/gen/memcpy.s > >I think this looks similar to your implementation, Agner. > > Yes it is similar to my code. > > Gnu libc could borrow a lot of optimized functions from Opensolaris and > Mac and other open source projects. They look better than Gnu libc, but > there is still room for improvement. For example, Opensolaris does not > use XMM registers for strlen, although this is simpler than using > general purpose registers (see my code www.agner.org/optimize/asmlib.zip) Note, glibc can only take code that is appropriately licensed and donated to the FSF. In addition it must meet the coding standards for glibc. Also note, that it depends on the basic chip level what is fastest for the operation (for example, using XMM registers are not faster for current AMD platforms). Memcpy/memset optimizations were added to glibc 2.8, though when your favorite distribution will provide it is a different question: http://sourceware.org/ml/libc-alpha/2008-04/msg00050.html -- Michael Meissner email: [EMAIL PROTECTED] http://www.the-meissners.org
gcc-4.4-20080725 is now available
Snapshot gcc-4.4-20080725 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080725/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 138152 You'll find: gcc-4.4-20080725.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20080725.tar.bz2 C front end and core compiler gcc-ada-4.4-20080725.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20080725.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20080725.tar.bz2 C++ front end and runtime gcc-java-4.4-20080725.tar.bz2 Java front end and runtime gcc-objc-4.4-20080725.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20080725.tar.bz2The GCC testsuite Diffs from 4.4-20080718 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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: lto gimple types and debug info
Kenneth Zadeck wrote: 1) Screw the debugging. The motivation behind this option is that not only is it easy, but the reality is that we have changed the program so much that even if we did "fix up the types" so that the matched the generated program, that the code is so different from what the user expected that (s)he could not even debug if anyway. I think this would be very disappointing to users. One of the long-standing advantages of GCC is that you can in fact do some level of debugging with optimized code. It's true that if you tear apart structures, the debugger is going to have a hard time dealing with that at present, but it's also true that dropping all language-specific knowledge of types is going to make life very hard for users. And it's not like you're always going to mangle things beyond recognition; tossing out all the debug info is throwing out the baby with the bathwater. 2) Generate the debugging for the types early, and then add an interface that would parse and regenerate the debugging info with the changes. It is quite likely that this would lock gcc completely into dwarf, but that appears to only be a problem for AIX at this point, so that may not be that much of a problem. This is the approach I would suggest. Dump out the debug info for types before you throw away all the information, and then leave it aside. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: gcc-4.4-20080725 is now available
On Fri, Jul 25, 2008 at 10:45 PM, <[EMAIL PROTECTED]> wrote: > Snapshot gcc-4.4-20080725 is now available on > ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080725/ > and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. > > This snapshot has been generated from the GCC 4.4 SVN branch > with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 138152 Would be nice to have md5 sums there also $ /opt/csw/bin/openssl md5 gcc-4.4-20080725.tar.bz2 MD5(gcc-4.4-20080725.tar.bz2)= 865deaea79c12635f9a9b92937df8d41 etc etc Dennis Clarke
Re: lto gimple types and debug info
Mark Mitchell wrote: Kenneth Zadeck wrote: 1) Screw the debugging. The motivation behind this option is that not only is it easy, but the reality is that we have changed the program so much that even if we did "fix up the types" so that the matched the generated program, that the code is so different from what the user expected that (s)he could not even debug if anyway. I think this would be very disappointing to users. One of the long-standing advantages of GCC is that you can in fact do some level of debugging with optimized code. It's true that if you tear apart structures, the debugger is going to have a hard time dealing with that at present, but it's also true that dropping all language-specific knowledge of types is going to make life very hard for users. And it's not like you're always going to mangle things beyond recognition; tossing out all the debug info is throwing out the baby with the bathwater. 2) Generate the debugging for the types early, and then add an interface that would parse and regenerate the debugging info with the changes. It is quite likely that this would lock gcc completely into dwarf, but that appears to only be a problem for AIX at this point, so that may not be that much of a problem. This is the approach I would suggest. Dump out the debug info for types before you throw away all the information, and then leave it aside. I am coming to the conclusion, for other reasons that this is what we are going to have to do. kenny
Re: lto gimple types and debug info
On Jul 25, 2008, at 9:20 AM, Michael Matz wrote: That is one example of extremely important information which requires pulling in almost the entire source type system. But not all the trees implementing those types (and all the cross-references between those, that are important for parsing but not interesting at all for the middle-end). All you need is a tag (alias set number) per type and a graph giving the conflicts between those tags. With that level of information, how do you "link" the alias trees for different modules at LTO time? -Chris
gcc emit wrong symbols in multiple inheritance case
Hi Dear Gcc developers,
When I am trying to build Mozilla with gcc-mingw, I came across
the linkage error of undefined symbols in multiple inheritance case.
And I have made a simple test case to reproduce the problem. But the
test case is still very complex, I think. So, I came down to find the
what are the real problems. And now, I think I have, so I just
describe what I found here:
For a class hierarchy :
class SuperSuperBase {
public:
SuperSuperBase();
~SuperSuperBase();
virtual void __attribute__((__stdcall__)) funcSSB() = 0;
};
class SuperBase : public SuperSuperBase {
public:
SuperBase();
~SuperBase();
virtual void __attribute__((__stdcall__)) funcSB() = 0;
};
class Base : public SuperBase {
public:
Base();
~Base();
virtual void __attribute__((__stdcall__)) funcB() = 0;
};
class ChildA: public Base {
public:
ChildA();
~ChildA();
virtual void __attribute__((__stdcall__)) funcCA() = 0;
};
class ChildB: public SuperBase {
public:
ChildB();
~ChildB();
virtual void __attribute__((__stdcall__)) funcCB() = 0;
};
class DLL Child : public ChildA,
public ChildB {
public:
Child();
~Child();
virtual void __attribute__((__stdcall__)) funcSSB();
virtual void __attribute__((__stdcall__)) funcSB();
virtual void __attribute__((__stdcall__)) funcB();
virtual void __attribute__((__stdcall__)) funcCB();
virtual void __attribute__((__stdcall__)) funcCA();
};
I make the Child in a DLL and then I import it from the DLL to build a
test application. But I failed with the undefined symbols of
"funcSSB,funcSB,funcCB".
And the errors occurs when I build with gcc 4.3.0 but not with gcc
3.4.2. So, I use i686-mingw32-nm to dump the object file which
contains the definition of the Child class. And for the three
undefined functions, the two compiler output different symbols,
Gcc 3.4.2:
U __ZTVN10__cxxabiv117__class_type_infoE
U __ZTVN10__cxxabiv120__si_class_type_infoE
U __ZTVN10__cxxabiv121__vmi_class_type_infoE
T [EMAIL PROTECTED]
T [EMAIL PROTECTED]
T [EMAIL PROTECTED]
Gcc 4.3.0:
U __ZTVN10__cxxabiv117__class_type_infoE
U __ZTVN10__cxxabiv120__si_class_type_infoE
U __ZTVN10__cxxabiv121__vmi_class_type_infoE
0306 T __ZThn4_N5Child6funcCBEv
U [EMAIL PROTECTED]
02d7 T __ZThn4_N5Child6funcSBEv
U [EMAIL PROTECTED]
02c8 T __ZThn4_N5Child7funcSSBEv
U [EMAIL PROTECTED]
I think the difference here is the key point of the linkage error.
Could anybody help to give some more insight here? Any advice will be
appreciated very much!
Regards!
Bo
