Re: [gsoc2015] Is Gimple FE eligible for gsoc this year?
On Sun, Mar 22, 2015 at 02:36:31PM +0800, xue yinsong wrote:
> I add the following code in parser.c to replace htab:
>
> …
> struct gimple_symtab_hasher : ggc_cache_hasher *>
> {
> /* Return the hash value of the declaration name of a
> gimple_symtab_entry_def
> object pointed by ENTRY. */
> static hashval_t hash(struct gimple_symtab_entry_def *base){return
> IDENTIFIER_HASH_VALUE(base->id);}
> /* Returns non-zero if ENTRY1 and ENTRY2 point to gimple_symtab_entry_def
> objects corresponding to the same declaration. */
> static bool equal (const struct gimple_symtab_entry_def *base1, const
> struct gimple_symtab_entry_def *base2){return base1->id == base2->id;}
> static void
> handle_cache_entry(struct gimple_symtab_entry_def *&m)
> {
> extern void gt_ggc_mx (struct gimple_symtab_entry_def *&);
> if (m == HTAB_EMPTY_ENTRY || m == HTAB_DELETED_ENTRY)
> return;
> else if (ggc_marked_p (m->id))
> gt_ggc_mx (m);
> else
> m = static_cast (HTAB_DELETED_ENTRY);
> }
> };
>
> /* Gimple symbol table. */
> static GTY((cache)) hash_table *gimple_symtab;
> …
>
> But I got undefined symbols when compiling it:
> …
> Undefined symbols for architecture x86_64:
> "gt_ggc_mx(gimple_symtab_entry_def*&)", referenced from:
> gt_clear_caches_gt_gimple_parser_h() in parser.o
> "gt_pch_nx(gimple_symtab_entry_def*&)", referenced from:
> gt_pch_nx_hash_table_gimple_symtab_hasher_(void*) in parser.o
> "_c_global_trees", referenced from:
> gimple_main() in parser.o
> ld: symbol(s) not found for architecture x86_64
> collect2: error: ld returned 1 exit status
> make[3]: *** [gimple1] Error 1
> make[2]: *** [all-stage2-gcc] Error 2
> make[1]: *** [stage2-bubble] Error 2
> make: *** [all] Error 2
>
> Could someone tell me how to fix this?
I believe making the GTY marker for gimple_symtab_entry_def GTY
((for_user)) will cause gengtype to generate the needed marking routines
and so fix the link error.
Trev
>
>
>
> —
> Regards,
> Yinsong
> >
>
Re: GCC 5 Status Report (2015-03-20)
On 03/20/2015 07:18 AM, Richard Biener wrote: We've come a long way towards the release criteria of zero P1 bugs. I thought I would pass along a couple of data points from the *-rtems targets. Fourteen *-rtems target build OK on the head. The following do not even complete building gcc+newlib. v850 - PR65501. New and must be relatively recent. I built a C/C++ toolset on January 15. m32c - PR63683. Reported against 4.9 branch. DJ may have a patch for this. The avr is still broken. I don't know that it is worth the trouble to even dig up the PRs anymore. I disable C++ for the v850 and have managed to build RTEMS for all targets using this toolset. --joel sherrill
Re: future versions
Is this the policy going forward for the 6.0 release as well? If it is being done just to avoid the stigma of a .0 release, it really smacks of being too cute by half. On Sat, Mar 21, 2015 at 1:27 PM, Markus Trippelsdorf wrote: > On 2015.03.21 at 12:11 -0400, Jack Howarth wrote: >> On Sat, Mar 21, 2015 at 1:45 AM, Markus Trippelsdorf >> wrote: >> > On 2015.03.20 at 20:08 -0400, Jack Howarth wrote: >> >> What was the final decision concerning future versioning of FSF >> >> gcc post-5.0? In particular, I am confused about the designation of >> >> maintenance releases of 5.0. Will the next maintenance release be 5.1 >> >> or 5.0.1? I assume if it is 5.1, then after branching for release of >> >> 5.0, trunk will become 6.0, no? >> > >> > http://gcc.gnu.org/develop.html#num_scheme >> >> So according to that webpage, trunk becomes 6.0 and the first >> maintenance release of 5.0 becomes 5.1 (with 5.0.1 being the >> pre-release state of the gcc-5_0-branch prior to the actual 5.1 >> maintenance release). What is confusing me is all of these references >> in the mailing list to postponing bug fixes until 5.2 instead of 5.1 >> (https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01129.html for >> example). What is that all about? > > The first release of gcc-5 will be 5.1.0. There will be no 5.0.0 > release... > > -- > Markus
Re: future versions
On 22 March 2015 at 17:28, Jack Howarth wrote: > Is this the policy going forward for the 6.0 release as well? Yes, as it says on that webpage. > If it is > being done just to avoid the stigma of a .0 release, it really smacks > of being too cute by half. That's not the reason, there's a rationale on the webpage too. If someone says they have 4.9.0 it could be the final release or a trunk build from 9 months earlier, which would be a very different compiler. Similarly, 4.9.1 would be the final release or a build on the branch from the day after 4.9.0 was released. With the new scheme the __GNUC_PATCHLEVEL__ component is different for final releases and snapshots.
Re: future versions
So effectlvely the old usage of the major version has been discarded with the previous usage of the minor version mapped to it. Likewise for the previous usage of the patch version now mapped to the minor version. I am just trying to clarify this as I have to adjust my packaging of FSF gcc in the fink project. For example, previously we used -program-suffix=-fsf-4.9 but now this will have to be -program-suffix=-fsf-5. Likewise we buried the release with --prefix=%p/lib/gcc4.9 but now this will have to be --prefix=%p/lib/gcc5 for the gcc 5 release series. On Sun, Mar 22, 2015 at 1:57 PM, Jonathan Wakely wrote: > On 22 March 2015 at 17:28, Jack Howarth wrote: >> Is this the policy going forward for the 6.0 release as well? > > Yes, as it says on that webpage. > >> If it is >> being done just to avoid the stigma of a .0 release, it really smacks >> of being too cute by half. > > That's not the reason, there's a rationale on the webpage too. > > If someone says they have 4.9.0 it could be the final release or a > trunk build from 9 months earlier, which would be a very different > compiler. Similarly, 4.9.1 would be the final release or a build on > the branch from the day after 4.9.0 was released. > > With the new scheme the __GNUC_PATCHLEVEL__ component is different for > final releases and snapshots.
[gsoc] Generic addressing mode selection
Hi all, I'm Erik Krisztián Varga, a 2nd year Electrical Engineering student, and I'd be interested in contributing to gcc as part of GSoC 2015. I'd like to work on adding an addressing mode selection pass to the RTL based on the ideas described in Eckstein et. al.'s paper on the subject [1]. The basic idea is to reduce the problem to a Partitioned Boolean Quadratic Programming (PBQP) problem and to find a close-to-optimal solution with a heuristic algorithm. It should be possible to model a lot of addressing modes with the cost matrix approach described in the paper, so this would be a generic way to do AMS for different architectures. Quite a few things would have to be done to implement the algorithm, like finding the correct models for the various addressing instructions in the supported architectures, or implementing an efficient representation of the cost vectors and matrices, but I think it should be possible in the scope of a Summer to have at least a working prototype ready. Would someone be interested in mentoring this project for GSoC? Is there anything similar currently being worked on? I think Oleg Endo has started implementing such a pass a while ago (mentioned in PR56590). Best regards, Erik [1] http://sydney.edu.au/engineering/it/~scholz/publications/cgo03.pdf
Re: [gsoc] Generic addressing mode selection
On Sun, 2015-03-22 at 21:21 +0100, Erik Varga wrote: > Hi all, > > I'm Erik Krisztián Varga, a 2nd year Electrical Engineering student, > and I'd be interested in contributing to gcc as part of GSoC 2015. > I'd like to work on adding an addressing mode selection pass to the > RTL based on the ideas described in Eckstein et. al.'s paper on the > subject [1]. > The basic idea is to reduce the problem to a Partitioned Boolean > Quadratic Programming (PBQP) problem and to find a close-to-optimal > solution with a heuristic algorithm. It should be possible to model a > lot of addressing modes with the cost matrix approach described in the > paper, so this would be a generic way to do AMS for different > architectures. > > Quite a few things would have to be done to implement the algorithm, > like finding the correct models for the various addressing > instructions in the supported architectures, or implementing an > efficient representation of the cost vectors and matrices, but I think > it should be possible in the scope of a Summer to have at least a > working prototype ready. > Would someone be interested in mentoring this project for GSoC? Is > there anything similar currently being worked on? I think Oleg Endo > has started implementing such a pass a while ago (mentioned in > PR56590). > > Best regards, > Erik > > [1] http://sydney.edu.au/engineering/it/~scholz/publications/cgo03.pdf Very nice! I did start doing some research in that area and started writing down some ideas. Unfortunately, whenever I started writing code, something else came along etc. I have accumulated a pile of use/test cases, some papers on other approaches than PBQP and a rough plan how I think it should be done. Although my point of view is a bit SH biased, I believe that once it's working on SH, other platforms will benefit from it. The problem is quite difficult, especially the "generic" part. The PBQP approach is indeed very tempting, but there are a lot more things to it than just the solver. To get good improvements of the generated code, the optimization also has to be able to reorder memory accesses and perform other transformations such as converting pre-inc into post-inc modes in loops etc. The scope would need to be narrowed down a bit for a GSoC project, but if you want, we could give it a try and I would step forward as a mentor. Cheers, Oleg
gcc-5-20150322 is now available
Snapshot gcc-5-20150322 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150322/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 221575 You'll find: gcc-5-20150322.tar.bz2 Complete GCC MD5=5503ae72eb8455c66f27361ff86f6e7b SHA1=63866acaf548fb338880b42140a2b3c5034cf9a9 Diffs from 5-20150315 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 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 5 Status Report (2015-03-20)
Joel Sherrill a écrit: I thought I would pass along a couple of data points from the *-rtems targets. Fourteen *-rtems target build OK on the head. The following do not even complete building gcc+newlib. v850 - PR65501. New and must be relatively recent. I built a C/C++ toolset on January 15. m32c - PR63683. Reported against 4.9 branch. DJ may have a patch for this. The avr is still broken. I don't know that it is worth the trouble to even dig up the PRs anymore. Like some other 3ary platforms, avr is plagued by spill fails, summarized as meta PR56183. Apart from that the device selection scheme changed some while ago: Setting -mmcu= will trigger a target specific spec file to be applied. The initial version didn't factor out libc and focused solely on avr-libc. I tried to rectify that in PR65296, i.e. spec files generator is now sensitive to avr-*-rtems configuration. What does not yet work is spaces in the installation path. Some of the avr core architectures are not well suited for "big" system like rtems + newlib. There are even devices without RAM so that for some of the core architecture it makes hardly any sense to build newlib variants for them, in particular "avr1" and "avrtiny" maybe even more. If parts of the device spec files are not generated as needed by rtems, it might be the case that the avr backend needs more adjustments, in particular specs.h, rtems.h, gen-avr-mmcu-specs.c, maybe also t-multilib and its generator genmultilib.awk. Johann
Re: Mirror
Hi William, On Wed, 10 Dec 2014, William Laeder wrote: > On the page: https://www.gnu.org/software/gcc/mirrors.html > > The St. Louis Mirror is not configured properly, all it shows is a > welcome page from apache. The gcc's file system structure (assuming > its the same for all mirrors) does not also exist. this is to follow-up that the mirror has been re-added and is working again. That said, Sergey, there is now a bit (too) much of link farming going on there. One or two links are fine, but can you please tone down the current set of six or so? Gerald
Re: GCC 5 Status Report (2015-03-20)
On 3/22/2015 5:39 PM, Georg-Johann Lay wrote: > Joel Sherrill a écrit: >> I thought I would pass along a couple of data points from >> the *-rtems targets. >> >> Fourteen *-rtems target build OK on the head. The following >> do not even complete building gcc+newlib. >> >> v850 - PR65501. New and must be relatively recent. I built >> a C/C++ toolset on January 15. >> m32c - PR63683. Reported against 4.9 branch. DJ may have a >> patch for this. >> >> The avr is still broken. I don't know tha t it is worth the trouble >> to even dig up the PRs anymore. > Like some other 3ary platforms, avr is plagued by spill fails, > summarized as meta PR56183. This is what we seem to run into over and over. > Apart from that the device selection scheme changed some while ago: > Setting -mmcu= will trigger a target specific spec file to be applied. > The initial version didn't factor out libc and focused solely on > avr-libc. I tried to rectify that in PR65296, i.e. spec files generator > is now sensitive to avr-*-rtems configuration. What does not yet work > is spaces in the installation path. Well no one should do that. :) > Some of the avr core architectures are not well suited for "big" system > like rtems + newlib. There are even devices without RAM so that for > some of the core architecture it makes hardly any sense to build newlib > variants for them, in particular "avr1" and "avrtiny" maybe even more. Funny to refer to rtems as a big system but we are still working to push down further and further. The ATMega128 is the smallest target CPU we even attempt right now. It is a work in progress and gives us a goal for reducing footprint. Our focus on smaller CPUs also helps since we target 16, 32, and 64-bit SPARC V9. This helps push the odd code that assumes CPU word size. > If parts of the device spec files are not generated as needed by rtems, > it might be the case that the avr backend needs more adjustments, in > particular specs.h, rtems.h, gen-avr-mmcu-specs.c, maybe also t-multilib > and its generator genmultilib.awk. I don't think we have seen any of this. We might even benefit from trimming our multilibs to the larger models. > Johann > -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: GCC 5 Status Report (2015-03-20)
On 03/22/2015 09:31 AM, Joel Sherrill wrote: On 03/20/2015 07:18 AM, Richard Biener wrote: We've come a long way towards the release criteria of zero P1 bugs. I thought I would pass along a couple of data points from the *-rtems targets. Fourteen *-rtems target build OK on the head. The following do not even complete building gcc+newlib. v850 - PR65501. New and must be relatively recent. I built a C/C++ toolset on January 15. Presumably v850 was working before, so this BZ needs a regression marker. Jeff
