Re: Clustering switch cases
On Wed, Sep 1, 2010 at 1:34 AM, Paul Brook wrote: >> > In fact we might want to move switch optimization up to the tree level >> > (just because it's way easier to deal with there). Thus, lower switch >> > to a mixture of binary tree & jump-tables (possibly using perfect >> > hashing). >> >> Doing the optimisation at the tree-level was exactly my initial idea. >> By splitting the switches at the tree-level, before expand_case, would >> then allow for expand_case to transform it either to a jump table or >> binary tree depending on the situation. > > I'd kinda hope that doing the optimization at the tree level means expand_case > doesn't have to handle both types. The tree code converts sparse case ranges > to explicit conditionals (or a switch on a compact perfect hash), so anything > left to RTL expansion must be a jump table. Yes, that was my idea. Richard. > Paul >
Adding official support into the main tree for SPARC Leon
Hi, I'm Vitorio working in Leon due to my Ph.D. and discussing with Konrad Eisele form Aeroflex Gaisler, maintainers of Leon SPARC, we would like to create a main tree for Leon on GCC, and providing the commits we already have, and any further modifications, right now we had our codes separated, but we are working to join efforts and keep the things going on Leon. So we would like to put the code into the main tree and maintain it, this way anyone who wants to work with Leon or even contribute specifically in the compilers field would know where to find the, also this way we keep the compiler for Leon up-to-date and the development transparent. Also we expect to encourage the groups of research that are working around the Globe and have some modification for Leon to contribute and post it officially. I'm sending this to the GCC main list because I expect to reach the Steering Committee and know if we can have they're approval and the formal procedures for us to commit and push the code into the main tree and maintain it. Best Regards, Vitorio Cargnini. smime.p7s Description: S/MIME cryptographic signature
Re: Clustering switch cases
Richard Guenther writes: >> >> I'd kinda hope that doing the optimization at the tree level means >> expand_case >> doesn't have to handle both types. The tree code converts sparse case ranges >> to explicit conditionals (or a switch on a compact perfect hash), so anything >> left to RTL expansion must be a jump table. > You are right, I haven't thought about it but it does make sense. If I want to provide a patch for this, would it be ok if its a patch against gcc 4.4.4, or would it be better if its against the latest 4.5.1? Is there any policy regarding this? > Yes, that was my idea. > Good! I will get to work! Cheers, -- PMatos
Re: Clustering switch cases
On Wed, Sep 1, 2010 at 11:11 AM, Paulo J. Matos wrote: > Richard Guenther writes: > >>> >>> I'd kinda hope that doing the optimization at the tree level means >>> expand_case >>> doesn't have to handle both types. The tree code converts sparse case >>> ranges >>> to explicit conditionals (or a switch on a compact perfect hash), so >>> anything >>> left to RTL expansion must be a jump table. >> > > You are right, I haven't thought about it but it does make sense. If I > want to provide a patch for this, would it be ok if its a patch against > gcc 4.4.4, or would it be better if its against the latest 4.5.1? Is > there any policy regarding this? Patches should be submitted against SVN trunk head as this is a new feature and thus will not go on the 4.4 or 4.5 branches. Richard.
Re: Clustering switch cases
Richard Guenther writes: > > Patches should be submitted against SVN trunk head as this is a new > feature and thus will not go on the 4.4 or 4.5 branches. Sure. Thanks. -- PMatos
Re: Adding official support into the main tree for SPARC Leon
Luís Vitório Cargnini writes: > I'm Vitorio working in Leon due to my Ph.D. and discussing with Konrad Eisele > form Aeroflex Gaisler, maintainers of Leon SPARC, we would like to create a > main tree for Leon on GCC, and providing the commits we already have, and any > further modifications, right now we had our codes separated, but we are > working to join efforts and keep the things going on Leon. > > So we would like to put the code into the main tree and maintain it, this way > anyone who wants to work with Leon or even contribute specifically in the > compilers field would know where to find the, also this way we keep the > compiler for Leon up-to-date and the development transparent. > > Also we expect to encourage the groups of research that are working around > the Globe and have some modification for Leon to contribute and post it > officially. > > I'm sending this to the GCC main list because I expect to reach the Steering > Committee and know if we can have they're approval and the formal procedures > for us to commit and push the code into the main tree and maintain it. Anybody who has signed the copyright assignment with the FSF and who has write access to the SVN repository is permitted to create and maintain a branch in the source code repository. Steering committee approval is not required. The policies may be found here: http://gcc.gnu.org/svnwrite.html . So your first step is going to be to sign the FSF copyright assignment, and your second step is going to be to find a sponsor for SVN write access. Thanks for your interest in gcc. Ian
Re: Adding official support into the main tree for SPARC Leon
> Anybody who has signed the copyright assignment with the FSF and who has > write access to the SVN repository is permitted to create and maintain a > branch in the source code repository. Steering committee approval is > not required. The policies may be found here: > http://gcc.gnu.org/svnwrite.html . > > So your first step is going to be to sign the FSF copyright assignment, > and your second step is going to be to find a sponsor for SVN write > access. Leon is a conforming implementation of the SPARC V7/V8 architecture so it should be possible to support it alongside the other SPARC implementations in the SPARC back-end of the mainline compiler. I'd be happy to review patches to this effect (and I presume the other SPARC maintainers are OK with this). So I'd suggest that Luís Vitório and/or Konrad do the required paperwork, and then start to post their patches on the gcc-patches@ list. I'll sponsor them for write access at that point. -- Eric Botcazou
Re: Adding official support into the main tree for SPARC Leon
On Wed, 1 Sep 2010 18:04:31 0200, Eric Botcazou wrote: Anybody who has signed the copyright assignment with the FSF and who has > > write access to the SVN repository is permitted to create and maintain a > > branch in the source code repository. Steering committee approval is > > not required. The policies may be found here: > > http://gcc.gnu.org/svnwrite.html . > > > > So your first step is going to be to sign the FSF copyright assignment, > > and your second step is going to be to find a sponsor for SVN write > > access. > > Leon is a conforming implementation of the SPARC V7/V8 architecture so it > should be possible to support it alongside the other SPARC implementations in > the SPARC back-end of the mainline compiler. I'd be happy to review patches > to this effect (and I presume the other SPARC maintainers are OK with this). > > So I'd suggest that Luís Vitório and/or Konrad do the required paperwork, and > then start to post their patches on the gcc-patches@ list. I'll sponsor them > for write access at that point. This is kind news. I gladly take this offer from Eric Botcazou. As for I'm just a employee, I have cc'd this also to Jiri Gaisler the CTO of Aeroflex Gaisler, so that he can sign rhe copyleft agreement. Is there a pdf that he can print out, sign and fax to the FSF? Is there maybe a link that describes the procedure? -- Konrad > -- > Eric Botcazou > >
Error message formatting feature request
When compiling a program such as:
template
void foo(T, typename T::type c) {c.y();}
struct x {typedef int type;};
void f() {foo(x(), 3);}
GCC 4.5.0 (correctly) produces the error message:
foo.cpp: In function ‘void foo(T, typename T::type) [with T = x, typename
T::type = int]’:
foo.cpp:4:21: instantiated from here
foo.cpp:2:34: error: request for member ‘y’ in ‘c’, which is of non-class
type ‘x::type’
My feature request is to have the comma between "T = x" and "typename
T::type = int" replaced by a semicolon. In larger programs, the types
given in the error message often themselves contain commas, while they do
not typically contain semicolons. Thus, this change would make the error
messages easier to understand (and, in particular, to skim).
-- Jeremiah Willcock
Re: Error message formatting feature request
Jeremiah Willcock writes:
> When compiling a program such as:
>
> template
> void foo(T, typename T::type c) {c.y();}
> struct x {typedef int type;};
> void f() {foo(x(), 3);}
>
> GCC 4.5.0 (correctly) produces the error message:
>
> foo.cpp: In function ‘void foo(T, typename T::type) [with T = x,
> typename T::type = int]’:
> foo.cpp:4:21: instantiated from here
> foo.cpp:2:34: error: request for member ‘y’ in ‘c’, which is of
> non-class type ‘x::type’
>
> My feature request is to have the comma between "T = x" and "typename
> T::type = int" replaced by a semicolon. In larger programs, the types
> given in the error message often themselves contain commas, while they
> do not typically contain semicolons. Thus, this change would make the
> error messages easier to understand (and, in particular, to skim).
Thanks for the suggestion. Please open a feature request at
http://gcc.gnu.org/bugzilla/ for this. Otherwise I'm afraid this
suggestion will just be lost in the noise.
Ian
Re: Error message formatting feature request [C++]
2010/9/1 Jeremiah Willcock : > > My feature request is to have the comma between "T = x" and "typename > T::type = int" replaced by a semicolon. In larger programs, the types given > in the error message often themselves contain commas, while they do not > typically contain semicolons. Thus, this change would make the error > messages easier to understand (and, in particular, to skim). If you get a C++ or diagnostics maintainer to approve such change, I will write a patch and test it. Maintainers are listed in the MAINTAINERS file. Cheers, Manuel.
Re: Adding official support into the main tree for SPARC Leon
> As for I'm just a employee, I have cc'd this also to Jiri Gaisler the CTO > of Aeroflex Gaisler, so that he can sign rhe copyleft agreement. Is there a > pdf that he can print out, sign and fax to the FSF? Is there maybe a link > that describes the procedure? I believe everything is documented on http://gcc.gnu.org/contribute.html Ian, would you mind sending them the appropriate form? Thanks in advance. -- Eric Botcazou
Re: Adding official support into the main tree for SPARC Leon
Eric Botcazou writes: > Ian, would you mind sending them the appropriate form? Thanks in advance. Done. Ian
