GROW 2011: deadline extended to 7 February 2011
The submission deadline for the 3rd Workshop on GCC Opportunities has been extended until 7 February 2011. CALL FOR PAPERS 3rd Workshop on GCC Research Opportunities (GROW 2011) http://grow2011.inria.fr 3 April 2011, Chamonix, France (co-located with CGO 2011) The GROW workshop focuses on current challenges in research and development of compiler analyses and optimizations based on the free GNU Compiler Collection (GCC). The goal of this workshop is to bring together people from industry and academia that are interested in conducting research based on GCC and enhancing this compiler suite for research needs. The workshop will promote and disseminate compiler research (recent, ongoing or planned) with GCC, as a robust industrial-strength vehicle that supports free and collaborative research. The program will include an invited talk and a discussion panel on future research and development directions of GCC. Topics of interest Any issue related to innovative program analysis, optimizations and run-time adaptation with GCC including but not limited to: * Classical compiler analyses, transformations and optimizations * Power-aware analyses and optimizations * Language/Compiler/HW cooperation * Optimizing compilation tools for heterogeneous/reconfigurable/ multicore systems * Tools to improve compiler configurability and retargetability * Profiling, program instrumentation and dynamic analysis * Iterative and collective feedback-directed optimization * Case studies and performance evaluations * Techniques and tools to improve usability and quality of GCC * Plugins to enhance research capabilities of GCC Paper Submission Guidelines Submitted papers should be original and not published or submitted for publication elsewhere; papers similar to published or submitted work must include an explicit explanation. Papers should use the LNCS format and should be 12 pages maximum. Papers will be refereed by the Program Committee and if accepted, and if the authors wish, will be made available on the workshop web site. Important Dates Deadline for submission: 31 January 2011 --> EXTENDED 7 February Decision notification: 28 February 2011 Workshop: 3 April 2011 full-day Organizers David Edelsohn, IBM, USA Erven Rohou, INRIA, France Program Committee Zbigniew Chamski, Infrasoft IT Solutions, Poland Albert Cohen, INRIA, France David Edelsohn, IBM, USA Björn Franke, University of Edinburgh, UK Grigori Fursin, EXATEC Lab, France Benedict Gaster, AMD, USA Jan Hubicka, SUSE Paul H.J. Kelly, Imperial College of London, UK Ondrej Lhotak, University of Waterloo, Canada Hans-Peter Nilsson, Axis Communications, Sweden Diego Novillo, Google, Canada Dorit Nuzman, IBM, Israel Andrea Ornstein, STMicroelectronics, Italy Sebastian Pop, AMD, USA Erven Rohou, INRIA, France Ian Lance Taylor, Google, USA Chengyong Wu, ICT, China Kenneth Zadeck, NaturalBridge, USA Ayal Zaks, IBM, Israel
Re: GCC 4.3.5 Status Report (2010-05-22)
On Sat, Jan 29, 2011 at 5:51 AM, Dongsheng Song wrote: > On Mon, May 24, 2010 at 03:44, Richard Guenther > wrote: >> >> It would be nice if the scripts could check whether only DATESTAMP >> changes were done since the last snapshot ... > > Just for curiousness, why we bump the DATESTAMP when the last commit is > DATESTAMP changes on the branch ? I wonder why we keep DATESTAMP at all now that we have a global source revision number (remember, CVS did not have that). Richard.
Re: GCC 4.3.5 Status Report (2010-05-22)
On Sun, Jan 30, 2011 at 11:13 AM, Richard Guenther wrote: > On Sat, Jan 29, 2011 at 5:51 AM, Dongsheng Song > wrote: >> On Mon, May 24, 2010 at 03:44, Richard Guenther >> wrote: >>> >>> It would be nice if the scripts could check whether only DATESTAMP >>> changes were done since the last snapshot ... >> >> Just for curiousness, why we bump the DATESTAMP when the last commit is >> DATESTAMP changes on the branch ? > > I wonder why we keep DATESTAMP at all now that we have a global > source revision number (remember, CVS did not have that). > You get revision number only with contrib/gcc_update and not everyone uses it. See: http://gcc.gnu.org/ml/gcc-testresults/2011-01/ I primarily use GIT mirror which doesn't use subversion number. -- H.J.
Re: GCC 4.3.5 Status Report (2010-05-22)
On Sun, 30 Jan 2011, Richard Guenther wrote: > On Sat, Jan 29, 2011 at 5:51 AM, Dongsheng Song > wrote: > > On Mon, May 24, 2010 at 03:44, Richard Guenther > > wrote: > >> > >> It would be nice if the scripts could check whether only DATESTAMP > >> changes were done since the last snapshot ... > > > > Just for curiousness, why we bump the DATESTAMP when the last commit is > > DATESTAMP changes on the branch ? > > I wonder why we keep DATESTAMP at all now that we have a global > source revision number (remember, CVS did not have that). The point of such things as DATESTAMP is to be globally meaningful in contexts where sources may have been obtained from snapshots, imported into other version control systems, etc.; an SVN revision number is not meaningful without consulting a particular repository (and a git revision ID would be even less meaningful to human readers of --version output etc.). -- Joseph S. Myers jos...@codesourcery.com
gcc-4.3-20110130 is now available
Snapshot gcc-4.3-20110130 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20110130/ 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 169416 You'll find: gcc-4.3-20110130.tar.bz2 Complete GCC (includes all of below) MD5=f5c5fc89606e86b180570f615e81a24a SHA1=8639e05f40d2abcb20affe1513be295670162c17 gcc-core-4.3-20110130.tar.bz2C front end and core compiler MD5=8a372142ed290f7aa692a803503277f4 SHA1=15298ba00ca9fcb232f0454641fa6b8c2755cbfd gcc-ada-4.3-20110130.tar.bz2 Ada front end and runtime MD5=adfab0a3f2cc86f0f42cefd44f89014a SHA1=e58d5d514955047305ecd0356b755fcbd51dc412 gcc-fortran-4.3-20110130.tar.bz2 Fortran front end and runtime MD5=dd7e3a0fd76ffc42d1e4a9d0de66fcb9 SHA1=2aed5888419f79466921140e90a5358aa8d2c30b gcc-g++-4.3-20110130.tar.bz2 C++ front end and runtime MD5=2271a93537ea59cf3d8ef1c1e8d035ac SHA1=827103cdd095324de83892584d9ecd5d6722bf73 gcc-go-4.3-20110130.tar.bz2 Go front end and runtime MD5=ba95a93f73ea65190de92f5d949a61c2 SHA1=df7c6efb31658e6fc772ea7d14fa27e55dbb3cdc gcc-java-4.3-20110130.tar.bz2Java front end and runtime MD5=8a2eeb252859f158d15835f23f11101a SHA1=89719ee38920ef5d466fb9a671f3df5110526c50 gcc-objc-4.3-20110130.tar.bz2Objective-C front end and runtime MD5=74bbdf8be03e6b7213ef9242f48a88fb SHA1=ecae3c6e5e94ea6dfa99d0784848cf9933441b9c gcc-testsuite-4.3-20110130.tar.bz2 The GCC testsuite MD5=cc3b45fe40dde94de1622cad34b17320 SHA1=26c077a9cfcf0d9e9be377a748a89af7c2e01d69 Diffs from 4.3-20110123 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: GCC 4.3.5 Status Report (2010-05-22)
On Sat, 29 Jan 2011, Dongsheng Song wrote: > Just for curiousness, why we bump the DATESTAMP when the last commit > is DATESTAMP changes on the branch ? As far as I am concerned, that's a bug (or a missing feature). The script in question is maintainer-scripts/update_version_svn in the GCC source repository. I already made some simplifications today and am planning to do a bit more tonight. Are you interested in improving the script to address this issue? Gerald
Re: Target deprecations for 4.6
On Fri, 28 Jan 2011, Joseph S. Myers wrote: > Here is a concrete list I propose for deprecation in 4.6; please send > any other suggestions, or say if you wish to volunteer to maintain one > of these targets to avoid deprecation Thanks for doing this, Joseph! I am not sure how to formally handle this, but we are removing the last bits of support for FreeBSD 1.x with GCC 4.6. I am pretty confident this has not worked for years (that platform did not have dynamic libraries), but there was a bit of machinery that's on it's way out. Gerald
Re: Target deprecations for 4.6
On Mon, 31 Jan 2011, Gerald Pfeifer wrote: > On Fri, 28 Jan 2011, Joseph S. Myers wrote: > > Here is a concrete list I propose for deprecation in 4.6; please send > > any other suggestions, or say if you wish to volunteer to maintain one > > of these targets to avoid deprecation > > Thanks for doing this, Joseph! > > I am not sure how to formally handle this, but we are removing the last > bits of support for FreeBSD 1.x with GCC 4.6. I am pretty confident this > has not worked for years (that platform did not have dynamic libraries), > but there was a bit of machinery that's on it's way out. My inclination would be to move the *-*-freebsd[12] | *-*-freebsd[12].* | *-*-freebsd*aout*) # This is the place-holder for the generic a.out configuration # of FreeBSD. No actual configuration resides here since # there was only ever a bare-bones ix86 configuration for # a.out and it exists solely in the machine-specific section. # This place-holder must exist to avoid dropping into # the generic ELF configuration of FreeBSD (i.e. it must be # ordered before that section). ;; case up to # Unsupported targets list. Do not put an entry in this list unless # it would otherwise be caught by a more permissive pattern. The list # should be in alphabetical order. so that those cases get an error at configure time, and close PR 47094. Addressing PR 47123 in a similar way would also be good. -- Joseph S. Myers jos...@codesourcery.com
Re: Making gcc -no-canonical-prefixes the default?
On Fri, 28 Jan 2011, Ian Lance Taylor wrote: > Some archealogy turned up this as the reason canonicalization was > inserted: > > http://gcc.gnu.org/ml/gcc/2003-02/msg01121.html > http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01697.html > > Also relevant here is http://gcc.gnu.org/PR29931 . I am quite sure that the current behavior where one can have a symlink point to an installation of GCC anywhere else (outside of any path even) has been in place for quite a bit longer than 2003. On Sat, 29 Jan 2011, Dave Korn wrote: > I think the case which is particularly common is the alternatives > system, which has a chain of symlinks finally pointing to a real gcc. > (That works just fine with the current default, AFAIK, although that > may be only because the real gcc is in $PATH?) Nope, only the symlink(s) need to be in the path. And indeed this usecase that you and also Joseph describe is how I've been using it for many years. Given that this has een default behavior for so long (more than a decade from what I can tell), I'd recommend not changing it. Gerald
Re: NetBSD bootstrap (was: Target deprecations for 4.6)
Hi, On Sat, Jan 29, 2011 at 5:24 PM, Jonathan Wakely wrote: > Ah, I did look in the NetBSD cvs repository and the other arches I > looked at just used _ANSI_H_, I obviously didn't check the ones you > identified. > >From a quick look, dreamcast, landisk, hpcsh, usermode and evbsh3 use fancy header protection guard for . Should the bug report be re-opened agaist those arch, or can it be expected that nobody will ever use a recent gcc on those arch ? - Arnaud > We only have a bug report concerning x86, and I didn't want to make > such a large change. Presumably GCC's stddef.h is/was needed for some > older NetBSD versions, and I don't have resources or time to find that > out or test a patch. > > I've committed my patch (approved by Ian) so maybe someone else will > do a more complete fix later. > > Jonathan >
Lilika Namzilma dod padomu Tev nevis trakot, bet
Nocheko so majaslapu un saac pelnit naudu jau tagad pec pamacibas luukojies sheit: http://www.negaiss-ir-prom.info Dailonis un Volmars jau pelna!
Re: NetBSD bootstrap (was: Target deprecations for 4.6)
On 31 January 2011 00:25, Arnaud Lacombe wrote: > Hi, > > On Sat, Jan 29, 2011 at 5:24 PM, Jonathan Wakely > wrote: >> Ah, I did look in the NetBSD cvs repository and the other arches I >> looked at just used _ANSI_H_, I obviously didn't check the ones you >> identified. >> > From a quick look, dreamcast, landisk, hpcsh, usermode and evbsh3 use > fancy header protection guard for . Should the bug > report be re-opened agaist those arch, or can it be expected that > nobody will ever use a recent gcc on those arch ? I have no objection to it being reopened, but I don't plan to work on it myself.
HEADS UP: [wwwdocs] Fix description of maintainer/reviewer privileges
I realized that our documentation has not been adjusted to (not so) recent changes and clarifications around the concepts of maintainers and reviewers we use. In fact, we don't have global maintainers any more and introduced the concept of reviewers. On the way I also tried to clarify that documentation web pages, and testcases are covered by maintainership/reviewership in an area, too. This is not supposed to constitute any change in policy. Rather it adjusts documentation thereof to reality. I went ahead and committed the change. If there is anything I missed or that could be clarified, please advise! Gerald Index: svnwrite.html === RCS file: /cvs/gcc/wwwdocs/htdocs/svnwrite.html,v retrieving revision 1.19 diff -u -r1.19 svnwrite.html --- svnwrite.html 21 Dec 2009 08:22:31 - 1.19 +++ svnwrite.html 31 Jan 2011 00:59:12 - @@ -92,39 +92,40 @@ Write access policies -The GCC project grants some developers various levels of write -access to the GCC master sources. SVN doesn't provide fine grained -control over access to the repository; therefore, we depend on each -developer to follow the appropriate policies. +The GCC project grants developers various levels of write access to +and review authority over the GCC master sources. We have not put any +technical enforcement in place, rather we rely on everyone to follow +the appropriate policies. - Global write permission. - A very limited number of developers have global write - permission over the entire repository. They may check in changes to - any part of the compiler without approval from anyone else. They - may also approve other people's changes to any part of the - compiler. + Global reviewers. + A limited number of developers have global review permission + and can approve other people's changes to any part of the compiler. + Localized write permission. This is for people who have primary responsibility for ports, - front ends, or significant hunks of code in the compiler. These - folks are allowed to make changes in code they maintain and - documentation related to that code without - approval from anyone else, and approve other people's changes in - those areas. They must get approval from the appropriate maintainers - for changes elsewhere in the compiler. - - Maintainers of a port maintain the files in config/port/, - the configure fragments for the port, documentation for the port and - test cases for features or bugs specific to this port. Port - maintainers do not have approval rights in other files. + front ends, or other specific aspects of the compiler. These folks + are allowed to make changes to areas they maintain and related + documentation, web pages, and test cases without approval from + anyone else, and approve other people's changes in those areas. They + must get approval for changes elsewhere in the compiler. + + Maintainers of a port maintain the relevant files in + gcc/config, documentation, web pages, and test cases + and aspects of these relevant to that port. Port maintainers do + not have approval rights beyond this. + + Localized review permission. + This is similar to localized write permission, except + that reviewers required approval for their own changes. Write after approval. This is folks that make regular contributions, but do not - fall into one of the two previous categories. People with write + fall into one of the previous categories. People with write after approval need to submit their patches to the list; once the patches have been approved by the appropriate maintainers the - patches may be checked into the GCC sources. The steering committee + patches may be checked in. The steering committee or a well-established GCC maintainer (including, but not limited to global write maintainers) can approve for write access any person with GNU copyright assignment
Re: Heads up: please help documenting *internal* GCC changes for 4.6
On Fri, 28 Jan 2011, Basile Starynkevitch wrote: > I am not sure to understand the technical ways to modify that; is CVS > still mandatory? Yes, the web pages reside in CVS. Not a lot different from SVN in terms of operations, just `cvs update`, `cvs diff`, `cvs commit` instead of the same svn commands. ;-) On Fri, 28 Jan 2011, Ian Lance Taylor wrote: > I would say that any gcc maintainer may update the changes file without > explicit review. The patch must be valid HTML, and Gerald runs a script > which verifies that. Patches must be sent to gcc-patc...@gcc.gnu.org. > > Only make changes that are correct. If you feel uncertain, you should > get a review. That review can come from any other gcc maintainer. > > (Anyone: please let me know if you disagree with the above.) I think you hit the nail on the head. I do offer the service of reviewing all web pages, either up front or after the fact, but especially for the release notes nobody should be hesitant. ;-) Realizing that our documentation could, and should, be more clear around this I just applied the following documentation update: http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02244.html Gerald
Re: HEADS UP: [wwwdocs] Fix description of maintainer/reviewer privileges
On 31 January 2011 01:02, Gerald Pfeifer wrote: > > Write after approval. > This is folks that make regular contributions, but do not > - fall into one of the two previous categories. People with write > + fall into one of the previous categories. People with write > after approval need to submit their patches to the list; once the > patches have been approved by the appropriate maintainers the > - patches may be checked into the GCC sources. The steering committee > + patches may be checked in. The steering committee > or a well-established GCC maintainer (including, but not limited to > global write maintainers) can > approve for write access any person with GNU copyright assignment Should this mention of global write maintainers be changed to global reviewers too?
Re: GCC 4.3.5 Status Report (2010-05-22)
It's very simple (only for trunk, although it maybe more useful for branches):
Index: update_version_svn
===
--- update_version_svn (revision 169428)
+++ update_version_svn (working copy)
@@ -42,6 +42,12 @@
SVNROOT2=${SVNROOT}/branches/${BRANCH}
fi
+ LAST_COMMITER=`${SVN} log -q -l 1 ${SVNROOT2} | awk '{if (NR==2)
{print $3; exit}}'`
+ if test "${LAST_COMMITER}" = "gccadmin"; then
+echo "The last commiter is gccadmin, bump DATASTAMP skipped."
+continue
+ fi
+
for i in $datestamp_FILES; do
${SVN} -q co -N ${SVNROOT2}/`dirname $i` `basename $i`
done
On Mon, Jan 31, 2011 at 06:23, Gerald Pfeifer wrote:
>
> On Sat, 29 Jan 2011, Dongsheng Song wrote:
> > Just for curiousness, why we bump the DATESTAMP when the last commit
> > is DATESTAMP changes on the branch ?
>
> As far as I am concerned, that's a bug (or a missing feature). The
> script in question is maintainer-scripts/update_version_svn in the GCC
> source repository. I already made some simplifications today and am
> planning to do a bit more tonight. Are you interested in improving
> the script to address this issue?
>
> Gerald
Re: GCC 4.3.5 Status Report (2010-05-22)
Oh, update_version_svn can be apply to
trunk/gcc-4.5-branch/gcc-4.4-branch/gcc-4.3-branch, not only trunk.
On Mon, Jan 31, 2011 at 10:45, Dongsheng Song wrote:
> It's very simple (only for trunk, although it maybe more useful for branches):
>
> Index: update_version_svn
> ===
> --- update_version_svn (revision 169428)
> +++ update_version_svn (working copy)
> @@ -42,6 +42,12 @@
> SVNROOT2=${SVNROOT}/branches/${BRANCH}
> fi
>
> + LAST_COMMITER=`${SVN} log -q -l 1 ${SVNROOT2} | awk '{if (NR==2)
> {print $3; exit}}'`
> + if test "${LAST_COMMITER}" = "gccadmin"; then
> + echo "The last commiter is gccadmin, bump DATASTAMP skipped."
> + continue
> + fi
> +
> for i in $datestamp_FILES; do
> ${SVN} -q co -N ${SVNROOT2}/`dirname $i` `basename $i`
> done
>
> On Mon, Jan 31, 2011 at 06:23, Gerald Pfeifer wrote:
>>
>> On Sat, 29 Jan 2011, Dongsheng Song wrote:
>> > Just for curiousness, why we bump the DATESTAMP when the last commit
>> > is DATESTAMP changes on the branch ?
>>
>> As far as I am concerned, that's a bug (or a missing feature). The
>> script in question is maintainer-scripts/update_version_svn in the GCC
>> source repository. I already made some simplifications today and am
>> planning to do a bit more tonight. Are you interested in improving
>> the script to address this issue?
>>
>> Gerald
>
Confusion in setting default options for non-C/C++ languages
Currently toplev_main calls init_options_once init_options_struct lang_hooks.init_options_struct which all make sense. It then calls decode_options which calls default_options_optimization which sets various options based on the optimization level. That is fine provided all languages agree on which options are optimization-dependent and which are not. Unfortunately, they do not agree. For example, both Fortran and Go do opts->x_flag_errno_math = 0; in the init_options_struct language hook. That is a useless step now, as that is overridden by default_options_optimization, which sets either -ffast-math or -fno-fast-math based on whether -Ofast is used, and -fno-fast-math implies -ferrno-math. Similarly, Java does opts->x_flag_trapping_math = 0; and that too is now ineffective. I think that the call to lang_hooks.init_option_struct must be moved after the call to default_options_optimization, one way or another. Ian
