CASES'10 paper related to MILEPOST GCC
Dear all, In case someone is interested, the paper with details on feature extraction plugin used in MILEPOST GCC/cTuning CC (practical aggregation of semantical program properties for machine learning based optimization) by M.Namolaru et al from CASES'10 is now available on-line: http://fursin.net/wiki/index.php5?title=Research:Dissemination#MCFP2010 Yours, Grigori Fursin
Re: Discussion about merging Go frontend
"H.J. Lu" writes: > Will put > > if [ Go is enabled ]; then > boot_language=yes > fi > > in cp/config-lang.in work? Probably, but why should I change cp/config-lang.in if I want to support Go? Everything required to support Go should, as much as possible, be in the Go frontend. Ian
Re: Discussion about merging Go frontend
Dave Korn writes: > On 30/10/2010 19:24, Richard Henderson wrote: >> On 10/30/2010 11:37 AM, Dave Korn wrote: Uh, really? I thought there were like a half-dozen lto sections... >>> Which we iterate over just once, and record them all in a hash table from >>> the per-section callback, unless I've missed something. >> >> Oh, right. Nevermind then. >> >> >> r~ > > It'd be worth putting a warning comment on the find_section (no "s") > function saying that it's pretty inefficient and that it is best practice to > call find_sections just once and record details rather than make multiple > calls to find_section. (Both lto FE and lto-plugin are already architected > that way.) > > cheers, > DaveK I added a sentence "Note that calling this multiple times is inefficient; use objfile_find_sections instead." I added the function because it's what the gccgo frontend needs: it only needs to find one section. Ian
Re: Discussion about merging Go frontend
Dave Korn writes: > Attached are the revised version of the file, and a diff to show what I > changed. With this version, all the tests in gcc.dg/lto/lto.exp pass as > before (i.e. there are still a couple of pre-existing FAILs that aren't > affected). Excellent, thanks. I have incorporated your objfile-coff.c in my working directory, and will commit it when I commit the whole patch set. I think it can be committed as soon as objfile-mach-o.c is working. Ian
Re: Discussion about merging Go frontend
* Ian Lance Taylor: > The Go frontend was approved for inclusion with gcc by the steering > committee a while back: http://gcc.gnu.org/ml/gcc/2010-01/msg00500.html . How general is the garbage collector and its support infrastructure in the compiler? AFAICS, it's precise, unlike the Boehm/Dehmers/Weiser collector used by the Java front end.
Re: TARGET_VALID_POINTER_MODE unused?
Paul Koning writes: > What triggered the question is that I'm trying to debug a testsuite > ICE in fortran, pdp11 target, where it aborts in > convert_memory_address_addr_space apparently trying to make a 32 bit > pointer. But only 16 bit pointers are valid, ptr_mode is HImode as > expected and as far as I can tell from gccint everything is set up > correctly for that to be the only pointer type. I don't have > TARGET_VALID_POINTER_MODE defined and from what the documentation says > it doesn't seem like I have to. So where should I look to find an > explanation for why the fortran compiler is trying to make an SImode > pointer? This should not happen and I agree that TARGET_VALID_POINTER_MODE is irrelevant here. This sounds like a bug somewhere but I don't know here. In the absence of additional information, like which test case is failing, all I can advise is to debug it to find out where the invalid pointer mode is coming from. Ian
Re: RFC: Add zlib source to src CVS resposity
f...@redhat.com (Frank Ch. Eigler) writes: > "H.J. Lu" writes: > >> [...] By default, the in-tree zlib is used. If you configure >> binutis using --with-system-zlib, system zlib will be used. [...] > > Can you summarize what modern platforms lack a system zlib, and what > justifies using the proposed in-tree copy by default? This is a good point. We need zlib in the gcc repository because we build it for the target, but this issue does not arise in the src repository. So this becomes a question for the binutils maintainers: do the binutils want to be self-contained, or do they want to follow the path of gcc and require additional libraries to be installed before a build can succeed? Ian
Re: Discussion about merging Go frontend
Florian Weimer writes: > * Ian Lance Taylor: > >> The Go frontend was approved for inclusion with gcc by the steering >> committee a while back: http://gcc.gnu.org/ml/gcc/2010-01/msg00500.html . > > How general is the garbage collector and its support infrastructure in > the compiler? AFAICS, it's precise, unlike the Boehm/Dehmers/Weiser > collector used by the Java front end. The garbage collector is a work in progress. What I say here is how it works at present, but everything will change in some as yet undetermined manner. At the moment the only compiler support for the garbage collector is that some allocations are marked as not containing pointers. Those blocks are ignored when scanning. When scanning memory blocks which may contain pointers, which includes the stack, the scanning is conservative: an integer value which happens to look like a pointer will cause the block to which it points to be marked as live. Ian
Re: RFC: Add zlib source to src CVS resposity
On Sun, Oct 31, 2010 at 11:42 AM, Ian Lance Taylor wrote: > f...@redhat.com (Frank Ch. Eigler) writes: > >> "H.J. Lu" writes: >> >>> [...] By default, the in-tree zlib is used. If you configure >>> binutis using --with-system-zlib, system zlib will be used. [...] >> >> Can you summarize what modern platforms lack a system zlib, and what >> justifies using the proposed in-tree copy by default? > > This is a good point. We need zlib in the gcc repository because we > build it for the target, but this issue does not arise in the src > repository. So this becomes a question for the binutils maintainers: do > the binutils want to be self-contained, or do they want to follow the > path of gcc and require additional libraries to be installed before a > build can succeed? zlib is in similar situation as intl. We include intl in binutils src and it can be disabled at configure time. For host zlib, should we check if it is available and fail back to in-tree zlib if there is no suitable host zlib? -- H.J.
dual result function & ABI (using extra register), e.g. for Go
Hello All (& Ian)
The Go language has functions which can give more than one result.
In my MELT experience, most multiple-results function calls have only two
results. Giving 3 results is very rare, and giving more than 3 results is
really exceptionnal (probably as exceptionnal as functions with more than 6
arguments).
>From what I learned from the Go tutorial at the GCC summit, The Go language
>also have several idioms with two results.
>From what I know of the AMD64 ABI, (but I might be false), functions are only
>supposed to return one result in a register (rax...).
I would imagine that most (& perhaps all) GCC target architectures have at
least two available registers to return values. So I would imagine that
defining a (e.g. Go specific) binary convention where a dual-result functions
gives the secondary result in another register (eg rbx on AMD64) would make
sense, and be quite quick, and be reasonably easy to implement.
However, I don't know much about GCC backends.
Does the Go language define a specific ABI convention for returning two values
from a function thru registers? If yes, how does GCC implement it? Or is it
some future work?
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
PATCH RFA: Do not build java by default
Currently we build the Java frontend and libjava by default. At the GCC
Summit we raised the question of whether should turn this off, thus only
building it when java is explicitly selected at configure time with
--enable-languages. Among the people at the summit, there was general
support for this, and nobody was opposed to it.
Here is a patch which implements that. I'm sending this to the mailing
lists gcc@ and java@, as well as the relevant -patches@ lists, because
it does deserve some broader discussion.
This is not a proposal to remove the Java frontend nor is it leading up
to that. It is a proposal to not build the frontend by default, putting
Java in the same category as Ada and Objective C++. The main argument
in favor of this proposal is twofold: 1) building libjava is a large
component of gcc bootstrap time, and thus a large component in the
amount of time it takes to test changes; 2) it is in practice very
unusual for middle-end or back-end changes to cause problems with Java
without also causing problems for C/C++, thus building and testing
libjava does not in practice help ensure the stability of the compiler.
A supporting argument is since Sun has released their Java tools under
the GPL, community interest seems to have shifted toward the Sun tools;
gcc's Java frontend is in maintenance mode, with little new development
currently planned.
This patch should not of course change whether or not distros choose to
package the Java compiler; undoubtedly they would continue to do so,
just as they package the Ada compiler today.
Comments? Approvals?
Ian
gcc/java/ChangeLog:
2010-10-31 Ian Lance Taylor
* config-lang.in (build_by_default): Set to no.
gcc/ChangeLog:
2010-10-31 Ian Lance Taylor
* doc/install.texi (Configuration): Note in two places that Java
is not enabled by default.
Index: gcc/java/config-lang.in
===
--- gcc/java/config-lang.in (revision 166080)
+++ gcc/java/config-lang.in (working copy)
@@ -36,5 +36,7 @@ gtfiles="\$(srcdir)/java/java-tree.h \$(
target_libs=${libgcj_saved}
lang_dirs="fastjar"
-#build_by_default=no
lang_requires=c++
+
+# Do not build java by default.
+build_by_default=no
Index: gcc/doc/install.texi
===
--- gcc/doc/install.texi (revision 166080)
+++ gcc/doc/install.texi (working copy)
@@ -1320,7 +1309,7 @@ Currently, you can use any of the follow
Building the Ada compiler has special requirements, see below.
If you do not pass this flag, or specify the option @code{all}, then all
default languages available in the @file{gcc} sub-tree will be configured.
-Ada and Objective-C++ are not default languages; the rest are.
+Java, Ada and Objective-C++ are not default languages; the rest are.
Re-defining @code{LANGUAGES} when calling @samp{make} @strong{does not}
work anymore, as those language sub-directories might not have been
configured!
@@ -1763,7 +1741,9 @@ tools.
@subheading Java-Specific Options
-The following option applies to the build of the Java front end.
+The following option applies to the build of the Java front end. Note
+that the Java front end is not built by default; in order to build it,
+use the @option{--enable-languages} option described above.
@table @code
@item --disable-libgcj
Re: dual result function & ABI (using extra register), e.g. for Go
Quoting Basile Starynkevitch : From what I know of the AMD64 ABI, (but I might be false), functions are only supposed to return one result in a register (rax...). That depends on how you view the return value. complex or structure value could be interpreted as multiple values, or vice versa. complex, structure, or multiple return values are just different kinds of syntactic sugar.
Re: RFC: Add zlib source to src CVS resposity
"H.J. Lu" writes: > On Sun, Oct 31, 2010 at 11:42 AM, Ian Lance Taylor wrote: >> f...@redhat.com (Frank Ch. Eigler) writes: >> >>> "H.J. Lu" writes: >>> [...] By default, the in-tree zlib is used. If you configure binutis using --with-system-zlib, system zlib will be used. [...] >>> >>> Can you summarize what modern platforms lack a system zlib, and what >>> justifies using the proposed in-tree copy by default? >> >> This is a good point. We need zlib in the gcc repository because we >> build it for the target, but this issue does not arise in the src >> repository. So this becomes a question for the binutils maintainers: do >> the binutils want to be self-contained, or do they want to follow the >> path of gcc and require additional libraries to be installed before a >> build can succeed? > > zlib is in similar situation as intl. We include intl in binutils src and > it can be disabled at configure time. For host zlib, should we check if > it is available and fail back to in-tree zlib if there is no suitable host > zlib? I assume that the reason we do that for intl is because it has complex interactions with the rest of the C library, so using the wrong intl library will cause confusing behaviour when the LC_ environment variables are set. That case does not arise for zlib. I think that if we do ship zlib with the binutils, we might as well always build it rather than using complex configure tests. This is just my opinion, and really I think the more active binutils and gdb maintainers should decide what to do here. Ian
Re: dual result function & ABI (using extra register), e.g. for Go
Basile Starynkevitch writes: >In my MELT experience, most multiple-results function calls have only >two results. Giving 3 results is very rare, and giving more than 3 >results is really exceptionnal (probably as exceptionnal as functions >with more than 6 arguments). > >From what I learned from the Go tutorial at the GCC summit, The Go >language also have several idioms with two results. I agree that Go code rarely returns more than two results, though for example runtime.Caller returns four results: func Caller(skip int) (pc uintptr, file string, line int, ok bool) >From what I know of the AMD64 ABI, (but I might be false), functions >are only supposed to return one result in a register (rax...). It's a little more complicated than that, as always. In some cases values may be returned on the floating point stack, or in the MMX registers, or in the SSE registers. When returning a value of type complex long or similar, the values will be returned in the two registers %rax/%rdx. The same is true when returning a struct with integer type fields whose size is 32 bytes or less. For the complex full set of rules, see the x86_64 ABI. > Does the Go language define a specific ABI convention for returning > two values from a function thru registers? If yes, how does GCC > implement it? Or is it some future work? The Go language does not define an ABI for returning multiple values. The gccgo frontend implements it by saying that a function which returns multiple values returns a struct with fields whose types are the types of the result parameter. It's desirable to make it possible to write C functions which return multiple values to Go code. For example, some of the runtime support functions work that way. Having the Go return a struct ensures that it is easy to write compatible C code. Ian
Re: PATCH RFA: Do not build java by default
Hello, Ian Lance Taylor wrote: > This is not a proposal to remove the Java frontend nor is it leading up > to that. It is a proposal to not build the frontend by default, putting > Java in the same category as Ada and Objective C++. The main argument > in favor of this proposal is twofold: 1) building libjava is a large > component of gcc bootstrap time, and thus a large component in the > amount of time it takes to test changes; 2) it is in practice very > unusual for middle-end or back-end changes to cause problems with Java > without also causing problems for C/C++, thus building and testing > libjava does not in practice help ensure the stability of the compiler. The argument against disabling java as a default language always was that there should be at least one default language that requires non-call exceptions. I recall testing many patches without trouble if I did experimental builds with just C, C++, and Fortran, only to find lots of java test suite failures in a complete bootstrap+test cycle. So the second point is, IMVHO, not really true. Is it possible to build and test java without all of libjava? Ciao! Steven
gcc-4.3-20101031 is now available
Snapshot gcc-4.3-20101031 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20101031/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 166113 You'll find: gcc-4.3-20101031.tar.bz2 Complete GCC (includes all of below) MD5=b2e8a4f58ddfcbf1464b68bc18a8f61c SHA1=e4c111631efe770b76ebf1de9a253d563052eb8f gcc-core-4.3-20101031.tar.bz2C front end and core compiler MD5=a13762fb17858121570d2fb70c480382 SHA1=3f88eefe019fc3d514129fe63ce0b806f689fd1f gcc-ada-4.3-20101031.tar.bz2 Ada front end and runtime MD5=6b4a9b6909a0433706e923e8afc97eb6 SHA1=5677ffcb333bc0f114c6be92228301335d5a600e gcc-fortran-4.3-20101031.tar.bz2 Fortran front end and runtime MD5=acec4338e4d4cc657f5270144f86c45e SHA1=ee35b40e12c281bed37e3c9baae3708c0cd05ce8 gcc-g++-4.3-20101031.tar.bz2 C++ front end and runtime MD5=8ddbcb742221b87aa4e78de5b0e42279 SHA1=381d1052323c3a86b84afd6cb538a6178fd0f24b gcc-java-4.3-20101031.tar.bz2Java front end and runtime MD5=119cbce52aae5157f626d242e0819645 SHA1=31a2f1508f57905d1fc2afdda9504e1e6ae77cf7 gcc-objc-4.3-20101031.tar.bz2Objective-C front end and runtime MD5=0493b4e4f739acc98ab9eb591f971fdd SHA1=5d7eb24796fe9cc98dc9310352694abfea870f42 gcc-testsuite-4.3-20101031.tar.bz2 The GCC testsuite MD5=278482d3a7ddcf8401ca32c2a5044756 SHA1=297658349e95af5da42d6fa8f00715ba62ad0ea9 Diffs from 4.3-20101024 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: PATCH RFA: Do not build java by default
On Sun, 31 Oct 2010, Steven Bosscher wrote: > Is it possible to build and test java without all of libjava? configure --disable-libgcj. I have been using this for my daily bootstraps for a while. Gerald
RE: RFC: Add zlib source to src CVS resposity
> -Original Message- > From: Ian Lance Taylor [mailto:i...@google.com] > Sent: Sunday, October 31, 2010 12:42 PM > To: Frank Ch. Eigler > Cc: H.J. Lu; Binutils; GCC Development; GDB > Subject: Re: RFC: Add zlib source to src CVS resposity > > f...@redhat.com (Frank Ch. Eigler) writes: > > > "H.J. Lu" writes: > > > >> [...] By default, the in-tree zlib is used. If you configure > >> binutis using --with-system-zlib, system zlib will be used. [...] > > > > Can you summarize what modern platforms lack a system zlib, and what > > justifies using the proposed in-tree copy by default? > > This is a good point. We need zlib in the gcc repository because we > build it for the target, but this issue does not arise in the src > repository. So this becomes a question for the binutils > maintainers: do > the binutils want to be self-contained, or do they want to follow the > path of gcc and require additional libraries to be installed before a > build can succeed? Typically, building for host=mingw runs into all sorts of non-standard stuff. I don't know for sure, but I highly doubt that there is a system zlib on that platform. For gcc dependencies, it just so happens that gmp, mpfr, and mpc build just fine for mingw. Eric Weddington
Re: PATCH RFA: Do not build java by default
On Sun, Oct 31, 2010 at 12:47 PM, Gerald Pfeifer wrote: > On Sun, 31 Oct 2010, Steven Bosscher wrote: >> Is it possible to build and test java without all of libjava? > > configure --disable-libgcj. I have been using this for my daily > bootstraps for a while. But it does not test java. Since the java testsuite depends on libjava. Thanks, Andrew Pinski
Re: PATCH RFA: Do not build java by default
On Oct 31, 2010, at 15:33, Steven Bosscher wrote: > The argument against disabling java as a default language always was > that there should be at least one default language that requires > non-call exceptions. I recall testing many patches without trouble if > I did experimental builds with just C, C++, and Fortran, only to find > lots of java test suite failures in a complete bootstrap+test cycle. > So the second point is, IMVHO, not really true. Feel free to enable Ada. Builds and tests faster than Java, and is known to expose many more middle end bugs, including ones that require non-call exceptions. -Geert
Re: PATCH RFA: Do not build java by default
Quoting Geert Bosch : On Oct 31, 2010, at 15:33, Steven Bosscher wrote: The argument against disabling java as a default language always was that there should be at least one default language that requires non-call exceptions. I recall testing many patches without trouble if I did experimental builds with just C, C++, and Fortran, only to find lots of java test suite failures in a complete bootstrap+test cycle. So the second point is, IMVHO, not really true. Feel free to enable Ada. Builds and tests faster than Java, and is known to expose many more middle end bugs, including ones that require non-call exceptions. But to get that coverage, testers will need to have gnat installed. Will that become a requirement for middle-end patch regression testing?
