Re: C++ ABI: name mangling of operator new [bug 6057]
On Fri, 27 Jul 2007, Richard Smith wrote:
| Gabriel Dos Reis wrote:
|
| > On Wednesday July 18, 2007 I brought factual evidence to
| > that claim by showing g++ behaviour on all of the examples
| > discussed (including those from the "decltype" proposal).
| > (All I did was to encode call expressions, new expressions
| > and a few other tree nodes).
|
| I'm curious as to how this works with overloaded functions.
Good question.
There are two levels here: the C++ language level, and the compiler
internals level.
At the C++ language level, there are concerns of how to specify the
interaction. All I claimed was that the observable semantics
does not need further specification to make the examples work.
At the compiler internals level, how overloads are handled has a much
wider variety of practice and I do not think we should have a standard
that says exactly how that should be implemented, as opposed to what the
end behaviour should be.
At the moment, GCC/g++ would ICE claiming that it does not know how
mangle a call expression (and a few othr nodes). My claim is that if
that problem is solved (by whatever means), the overload and template
machinery does not need further modification to handle all the examples
officially presented so far.
| The general philosophy in the current ABI would seem to be
| that the expression is encoded in terms of its template
| parameters, and not with the evaluated expression with the
| subsituted argument.
That is correct. For a compiler, such as GCC, that uses parse trees
to represent a template declaration there is no additional
difficultly in mangling the expression, compared to the 'ordinary' case.
| That is, for
|
| template void fn( A<-I> );
|
| the specialisation fn<1> would be mangled as
|
| _Z2fnILi1EEv1AIXngT_EE void fn( A<-I> ) [with I=1]
|
| instead of, say,
|
| _Z2fnILi1EEv1AILin1EEvoid fn( A<-1> ) [with I=1]
|
| This has the result that all specialisations of this
| template have the mangled form
|
| _Z2fnI{parameters}Ev1AIXngT_EE
|
| (I'm not convinced this is absolutely necessary, even though
| it seems a good idea. The oft-quoted example is
|
| template A fn(A, A);
| template A fn(A, A);
|
| and then setting I=J=0. If you substuted the arguments,
| you'd get _Z2fnILi0ELi0EE1AILi0EES0_ILi0EES0_ILi0EE for
| both. However, by my reading of 14.5.5.1, these are
| functionally equivalent but not equivalent and thus render
| the program ill-formed; no diagnostic required.)
That is correct.
| However, the obvious strategy for dealing with overloaded
| functions is to perform overload resolution and then mangle
| the selected overload. For example, if we make up the
| syntax
|
|::= ...
|::= cl
The scheme I used is similar; the difference being that I also
encoded the number of arguments (counting the function to call as an
argument), so it looks like
cl
| to mangle a function call, and you could mangle the
| call to the non-overloaded function, foo:
|
| template int foo(T);
| template A {};
| template void bar( A );
|
| The obvious strategy is to encode bar as (I think)
|
| _Z3barIiLi42EEv1AIXszclL_Z3fooIiEiT_ET0__EE
|
| where _Z3fooIiEiT_ is the result of subsituting T=int into
| the definition of foo. But this means that the template
| parameters of bar are repeated and all the specialisations
| of bar no longer have the form
|
| _Z3barI{parameters}Ev1AIXszclL_Z3fooIiEiT_ET0__EE
|
| ... because the 'i' from T=int is repeated. (Again, this is
| only a problem if one wants to mangle two 'functionally
| equivalent' overloads.)
The killing point for GCC/g++ is to mangle the original template
declaration -- not just the result of instantiation -- that is close
to the 'same token stream' requirement of the C++ definition.
Note also that there are other cases that GCC/g++ does not distinguish:
implicit specialization vs. explicit instantiation vs. explicit
specialization.
-- Gaby
Re: RFC: Rename Non-Autpoiesis maintainers category
I liked the idea of 'Reviewers' more than any of the other options. I would like to go with this patch, unless we find a much better option? Thanks. Index: MAINTAINERS === --- MAINTAINERS (revision 126951) +++ MAINTAINERS (working copy) @@ -231,7 +231,7 @@ maintainers need approval to check in algorithmic changes or changes outside of the parts of the compiler they maintain. - Non-Autopoiesis Maintainers + Reviewers dataflow Daniel Berlin [EMAIL PROTECTED] dataflow Paolo Bonzini [EMAIL PROTECTED] @@ -251,10 +251,9 @@ FortranPaul Thomas [EMAIL PROTECTED] -Note that individuals who maintain parts of the compiler as -non-autopoiesis maintainers need approval changes outside of the parts -of the compiler they maintain and also need approval for their own -patches. +Note that individuals who maintain parts of the compiler as reviewers +need approval changes outside of the parts of the compiler they +maintain and also need approval for their own patches. Write After Approval(last name alphabetical order)
Re: RFC: Rename Non-Autpoiesis maintainers category
Hello, > I liked the idea of 'Reviewers' more than any of the other options. > I would like to go with this patch, unless we find a much better > option? to cancel this category of maintainers completely? I guess it was probably discussed before (I am too lazy to check), but the existence of non-self-approving maintainers does not make much sense to me. It definitely is a good idea to have someone else but you read your patch before committing it, but this general guideline should apply to everyone, not just to a special group of maintainers (and IMHO sending your patch to mailing list and waiting for people to comment on it before committing it is enough to achieve this). Let me state my reasons to dislike the existence of this category of maintainers. We have non-global maintainers for the following reasons: 1) to reduce the workload of the global maintainers, who would otherwise have to approve every single patch, and to do so, understand thoroughly every single component of the compiler. 2) to speed up the rate at which changes can be made to some specific components, by allowing the local maintainers to commit them without waiting for an external review. 3) to indicate what persons are responsible for bugs/features of the specific component. I will not mention this reason in further discussion, as it does not seem to be really all that important (there are other ways to share this information). The item 2) obviously does not apply to non-self-approving maintainers. Also, it does not make sense to have only one non-self-approving maintainer for some component, as most of the patches for the component would usually be written by him/her and would have to be approved by a global maintainer, thus making 1) not to apply as well. So the only situation when having non-self-approving maintainers makes at least some sense is when you have several co-maintainers for one component. However, in this case they usually work together and would discuss any significant changes to the component anyway, so making them as non-self-approving does not really change anything under normal circumstances. That being the case, I would prefer not to place formal restrictions on their maintainership and let them work out whatever mode of cooperation suits them the best (if it ever happened that co-maintainers of some component will not be willing to work together and cooperate, no artificial restriction will make this work, anyway). And finally, we will avoid the need to find weird words to describe this category of maintainers :-) Zdenek > Thanks. > > > > Index: MAINTAINERS > === > --- MAINTAINERS (revision 126951) > +++ MAINTAINERS (working copy) > @@ -231,7 +231,7 @@ > maintainers need approval to check in algorithmic changes or changes > outside of the parts of the compiler they maintain. > > - Non-Autopoiesis Maintainers > + Reviewers > > dataflow Daniel Berlin [EMAIL PROTECTED] > dataflow Paolo Bonzini [EMAIL PROTECTED] > @@ -251,10 +251,9 @@ > FortranPaul Thomas [EMAIL PROTECTED] > > > -Note that individuals who maintain parts of the compiler as > -non-autopoiesis maintainers need approval changes outside of the parts > -of the compiler they maintain and also need approval for their own > -patches. > +Note that individuals who maintain parts of the compiler as reviewers > +need approval changes outside of the parts of the compiler they > +maintain and also need approval for their own patches. > > Write After Approval(last name alphabetical order) >
Re: Creating gcc-newbies mailing list
On 27/07/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote: > On Thu, Jul 26, 2007 at 05:13:30PM -0400, Diego Novillo wrote: > > > I would like to propose the creation a new mailing list: > > [EMAIL PROTECTED] > >IMHO, DJ hit the nail on the head. Those people who can't figure out to > post to gcc-help@ instead of gcc@ surely won't figure out to post to > gcc-newbies@ instead of gcc@ either. New name, same problem. > I think you are talking about a different thing. The people that would post to gcc-newbies are different than the people that should post to gcc-help. Nonetheless (as a bit offtopic)... >If you ask me, we should rename gcc@ to gcc-development@ and maybe rename > gcc-help@ to [EMAIL PROTECTED] ... gcc-dev@, keep gcc@ as an alias for gcc-dev@, replace in the webpage gcc@ by gcc-dev@ and put gcc-help@ the first in the list. Anyway, as I said, I don't think this has much to do with the issues raised by Diego. Cheers, Manuel.
Re: Creating gcc-newbies mailing list
On Thu, Jul 26, 2007 at 05:13:30PM -0400, Diego Novillo wrote: > I would like to propose the creation a new mailing list: > [EMAIL PROTECTED] IMHO, DJ hit the nail on the head. Those people who can't figure out to post to gcc-help@ instead of gcc@ surely won't figure out to post to gcc-newbies@ instead of gcc@ either. New name, same problem. If you ask me, we should rename gcc@ to gcc-development@ and maybe rename gcc-help@ to [EMAIL PROTECTED] That way we'll catch those who post before they think about where to post to, Nabble users or otherwise. The trick here is that if they post before reading http://gcc.gnu.org/lists.html>, then they won't even know that there is a list called gcc-development@ and it would therefore be unlikely for them to post to [EMAIL PROTECTED] -- Rask Ingemann Lambertsen
Re: [tuples] meaning of DECL_SAVED_TREE while analyzing cgraph
> The test there is sort of hack, I would just remove it at this stage and > we can work out better fix for that testcase later. I hope that with my > plans for declaration merging pass we can get round such weird side > effects of in place declaration replacement. Will do. How about all the other uses of DECL_SAVED_TREE in cgraph_analyze_functions? DECL_SAVED_TREE shouldn't be used past the tree optimizers (??). Aldy
How to make use of instruction scheduling to improve performance?
I am working on gcc 4.1.1 and itanium2 architecture. I instrumented each ld and st instruction in final_scan_insn() by looking at the insn template (These instrumentations are used to do some security checks). These instrumentations incur high performance overhead when running specint benchmarks. However, these instrumentations contain high dependencies between instructions so that I want to use instruction scheduling to improve the performance. In the current implementation, the instrumentations are emitted as assembly instructions (not insns). What should I do to make use of the instruction scheduler? Any help is truely appreciated! 3x
Re: Creating gcc-newbies mailing list
> If we do not manage to answer such mails on gcc@ (due to ressource reasons > I suppose) than I doubt we will do better on a separate mailinglist. The > amount of traffic with "newbie" questions is not dominant on gcc@ or > gcc-patches@ anyway, so I see little point in directing them elsewhere > where the only thing they would probably get is even less attention. Agreed.
Re: Creating gcc-newbies mailing list
> I am not sure if a new list will help. Some have argued that long time > developers may be discouraged to participate in such list and that new > developers would be discouraged from participating in the main list. I > think both are pretty good arguments. That's my concern as well. Moreover, how would one transition from the "newbie" list to the main list?
Re: RFC: Rename Non-Autpoiesis maintainers category
> Since the whole file is about MAINTAINERS, I would suggest changing the > categories to: > > - Committers (i.e. committing maintainers) > - Reviewers (i.e. reviewing maintainers) > - Non-algorithmic committers I like the idea of "reviewers", but think "committers" is confusing. Perhaps "full" and "reviewers"?
Re: Creating gcc-newbies mailing list. Too many mailinglists? Unified mailing list?
On 26 Jul 2007, Andrew Pinski wrote: | On 7/26/07, Diego Novillo <[EMAIL PROTECTED]> wrote: | > >I would like to propose the creation a new mailing list: | > >[EMAIL PROTECTED] | > > | > >The purpose of this list is to attract and help new GCC developers who | > >might feel lost and intimidated by the more arcane traffic at gcc and | > >gcc-patches. In this list, no question regarding GCC development should | > >be considered offtopic nor treated with "RTFM" responses. | | On Thu, Jul 26, 2007 at 02:05:50PM -0700, Andrew Pinski wrote: | > I think this is the wrong aproach. I have not seen any "RTFM" | > response for questions of developing of GCC on the gcc@ list. | | Agreed. Also, I think that the charter that Diego describes sounds a | lot like the charter for gcc-help. And since everyone will read | "GCC development" as "development using GCC as the compiler" it would | quickly become a general Linux/BSD/Unix/GNU tools questions list. | What would go to gcc-help, and what to gcc-newbies? I think it's | good enough what we have now. Also, I don't see the point in tossing | junior or beginner gcc developers off of the main list. | I think that when we do steer someone to a different list, we could | take more care to be polite about it than we sometimes are. Other candidates: gcc-how-to-use@ gcc-using@ gcc-for-users@ ( i dislike java-for-users@, fortran-for-users@, ... ) gcc-hacks@ <- why not? Have we too many mailing lists? The users don't want to join and detach to many mailing lists to post only a message once by week or month. He wants to post quickly, not to post slowly more than 10 minutes. Why can't we have a unified mailing list using javascript in http://gcc.gnu.org/ml/ instead of http://gcc.gnu.org/ml/gcc/2007-07/? Join once, but post the message to the corresponding e-mail of the unified mailing list. Sincerely :)
Re: Creating gcc-newbies mailing list
[EMAIL PROTECTED] wrote: Since I have been around no more than one year, perhaps my perspective could have some interest for the discussion. Just an example. There are people that post patches in bugzilla and they seem interested in getting them integrated but normally they break coding style or don't have changelog or didn't even run the testsuite. Of course, the easiest answer is to point to the "how to contribute" webpage. I have done it too. But I must admit that it is a poor answer. When I started, I couldn't bring myself to read all that was required to post a proper patch. Fortunately for me, Ian had a lot of patience to mentor me and some folks were so kind to teach me how to submit a proper patch. However, I don't think that is the typical situation. No, it isn't. I have been around long enough to know that it frequently takes several years for a patch posted on bugzilla to be evaluated. Of course, it is stale long before then, and has to be reformulated anyway to make it work. So, there doesn't seem much point in an infrequent contributor posting a ready-to-go patch. Often, there are several ways to fix a problem, and it's not at all clear which if any would be accepted.
"Proceedings of the GCC Developers' Summit" now available
Available for download at: http://people.redhat.com/lockhart/.GCC2007-Proceedings.pdf -Ron /**/ Ron Chen Grid Engine Project: http://gridengine.sunsource.net/ http://www.gridengine.info/ /**/ Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
Re: "Proceedings of the GCC Developers' Summit" now available
On Fri, Jul 27, 2007 at 11:27:39AM -0400, Diego Novillo wrote: > On 7/27/07 8:27 AM, Ron Chen wrote: > > Available for download at: > > http://people.redhat.com/lockhart/.GCC2007-Proceedings.pdf > > John says that this location is temporary and will disappear shortly. He > may add a link to a permanent location soon. In the meantime, > I've added attached the proceedings in the front page of the wiki > (http://gcc.gnu.org/wiki). Why not provide a permanent home for the GCC summit proceedings at gcc.gnu.org? It seems the logical place.
Re: GCC 4.2.1 : bootstrap fails at stage 2. compiler produces wrong binary for wrong processor
"Dennis Clarke" <[EMAIL PROTECTED]> writes: > SUMMARY : the stage 2 compiler produces the wrong binary type for this machine This question is appropriate for the [EMAIL PROTECTED] mailing list rather than the gcc@gcc.gnu.org list. Please take any followups to gcc-help. Thanks. > In either case I think that the --host needs to be specified as well as > perhaps --with-cpu=foo or something like that in the ./configure line. It does seem from your description that you need to set the host explicitly. That is not documented because it is rarely necessary. Apparently the config.guess shell script produced the wrong results on your system. The option you want is --build, as in --build=sparc-sun-solaris2.8. I don't actually know which --build option you want here. I don't even know for sure that your old machine is supported. Ian
Re: Creating gcc-newbies mailing list. Too many mailinglists? Unified mailing list?
On Fri, Jul 27, 2007 at 04:22:31PM +0200, J.C. Pizarro wrote: > The users don't want to join and detach to many mailing lists to post > only a message once by week or month. He wants to post quickly, > not to post slowly more than 10 minutes. You're trying to optimize the wrong cost measure. It's not in our interest to have people "post quickly". The time cost to compose and post a message is less than the time cost of the thousands of people who will read that message, even if most kill it based on the subject line or sender's identity. Separate lists saves the time of those who aren't interested in certain types of messages, or those who must make sure that every message of a certain type (a patch, for example) gets processed. Also, you need not subscribe to a gcc list to post to it.
Re: "Proceedings of the GCC Developers' Summit" now available
On 7/27/07 8:27 AM, Ron Chen wrote: > Available for download at: > http://people.redhat.com/lockhart/.GCC2007-Proceedings.pdf John says that this location is temporary and will disappear shortly. He may add a link to a permanent location soon. In the meantime, I've added attached the proceedings in the front page of the wiki (http://gcc.gnu.org/wiki).
GPLv3 in LTO and GIMPLE branches ya?
http://gcc.gnu.org/svn/gcc/branches/lto/ChangeLog http://gcc.gnu.org/svn/gcc/branches/gimple-tuples-branch/ChangeLog 2007-07-17 Nick Clifton <[EMAIL PROTECTED]> * COPYING3: New file. Contains version 3 of the GNU General Public License. * COPYING3.LIB: New file. Contains version 3 of the GNU Lesser General Public License. 2007-07-16 ... http://gcc.gnu.org/svn/gcc/branches/lto/COPYING3 http://gcc.gnu.org/svn/gcc/branches/lto/COPYING3.LIB It's too early Nick Clifton! Delay a little until 31th of July, please. ;)
Re: Creating gcc-newbies mailing list
Since I have been around no more than one year, perhaps my perspective could have some interest for the discussion. I am not sure if a new list will help. Some have argued that long time developers may be discouraged to participate in such list and that new developers would be discouraged from participating in the main list. I think both are pretty good arguments. Nevertheless, I think the problems mentioned by Diego do exist. When you are starting most of the questions seem silly. Many of them actually are. When you gather the courage to send it, sometimes it gets ignored or worse they point you to an amount of documentation which is mostly irrelevant for the answer, or worst, it is incomplete or outdated. Of course, this is not always the case and there are very good reasons for it: people are busy, the question was unclear/confusing/plain-stupid. Just an example. There are people that post patches in bugzilla and they seem interested in getting them integrated but normally they break coding style or don't have changelog or didn't even run the testsuite. Of course, the easiest answer is to point to the "how to contribute" webpage. I have done it too. But I must admit that it is a poor answer. When I started, I couldn't bring myself to read all that was required to post a proper patch. Fortunately for me, Ian had a lot of patience to mentor me and some folks were so kind to teach me how to submit a proper patch. However, I don't think that is the typical situation. Another recent example: http://gcc.gnu.org/ml/gcc/2007-07/msg00456.html (Not a single answer). Summing up, I am not sure whether a separate list would help but in my opinion there are a few things that will: * Mentors: I think it has worked great for the Google Summer of Code. Why not make it something more common? I will propose that if someone wants to fix a bug or work on something, the maintainers on this area should try to find a willing and suitable mentor. However, don't wait until someone steps up. The maintainer knows who is knowledgeable in the area, so ask those people until someone agrees. Perhaps what we need is gcc-mentors@ * Documentation to learn. GCC has a lot of documentation. But it is mostly for reference, that is, if you forget some detail or it is under discussion, there is plenty of documentation. However, there is little aimed to teach (with examples) the steps of how to contribute. It is like telling people to learn programming by reading the ISO C standard. The wiki is slowly changing this, but it still needs a lot of work. Regarding this, there is a curious effect that I experienced myself. When I started one year ago I noticed the lack of simple howtos describing the basic things like "how to submit a patch", "how to prepare a testcase", etc. However, as soon as I learnt how to do it, the task of describing them for newbies felt extremely tedious. * Be careful with the answers and be explicit in what the next step should be. For example, for someone that does not follow gcc-patches it can be discouraging to get her patch rejected just because it lacks a changelog or some coding style issues. It is good to convey that this is not nit-picking, that the patch is welcome and that we want that person to please send the patch again. Rober Dewar says that "in my impression beginner *developers* get good/polite answers and indeed I think people usually go out of their way to help". I would say that this is true for people that have been able to commit their first patch. That kind of beginners know what it takes to submit and commit a patch, understand what a review is, understand what is worth discussing and how the decision-making procedure works. However, I don't think the situation is as good for people that are struggling to figure out how to commit that first patch. OK, I think this is far enough. Cheers, Manuel.
Re: Creating gcc-newbies mailing list
Laurent GUERBY wrote: On Thu, 2007-07-26 at 17:13 -0400, Diego Novillo wrote: Or maybe this is not a good idea, but I have certainly seen some folks that complain about our less than friendly practices. Alternative would be to keep gcc@ and document that emails with subject tag [BEGINNER] should not be answered by unfriendly developpers (who can filter them out easily) and should be answered as quickly and friendly as possible by those who care :). Laurent I must say that my impression is that beginner *developers* get good/polite answers and indeed I think people usually go out of their way to help. This is the way it should be, and if there are exceptions, we should work on eliminating them. In particular, if you see an answer that you think is unhelpful to a would-be developer, step in and help! People asking *language* questions are often told to go elsewhere, and that's reasonable. Actually my complaint there would be that too often, people on this list answer such off topic questions (which is fine), and copy the answers to the list (which is not so fine, since it causes more off-topic posts). I really see no reason for change here.
Re: RFC: Rename Non-Autpoiesis maintainers category
On Jul 27, 2007, at 07:54, Diego Novillo wrote: +Note that individuals who maintain parts of the compiler as reviewers +need approval changes outside of the parts of the compiler they +maintain and also need approval for their own patches. s/approval changes/approval for changes/ ?
Re: C++ ABI: name mangling of operator new [bug 6057]
Gabriel Dos Reis wrote:
> At the C++ language level, there are concerns of how to specify the
> interaction. All I claimed was that the observable semantics
> does not need further specification to make the examples work.
>
> At the compiler internals level, how overloads are handled has a much
> wider variety of practice and I do not think we should have a standard
> that says exactly how that should be implemented, as opposed to what the
> end behaviour should be.
Agreed.
> At the moment, GCC/g++ would ICE claiming that it does not know how
> mangle a call expression (and a few othr nodes). My claim is that if
> that problem is solved (by whatever means), the overload and template
> machinery does not need further modification to handle all the examples
> officially presented so far.
That sounds a reasonable claim.
> | The general philosophy in the current ABI would seem to be
> | that the expression is encoded in terms of its template
> | parameters, and not with the evaluated expression with the
> | subsituted argument.
>
> That is correct. For a compiler, such as GCC, that uses parse trees
> to represent a template declaration there is no additional
> difficultly in mangling the expression, compared to the 'ordinary' case.
My concern is how, practically, to mangle a call to an
overloaded function, as, if the philosophy of encoding the
expression in terms of template parameters is continued, you
have to introduce ways of mangling the linked list of
FUNCTION_DECLs in an OVERLOAD node. This is certainly not
impossible, but likely to be long-winded. And the
possibility of ADL means that the overload set won't be the
same for each instantiation of the template
E.g. in
int foo(int); long foo(long);
template A {};
template void bar( A );
we could introduce
O E
to represent a overload set and represent the sizeof
expression as
szcl2OL_Z3fooiEL_Z3foolEET0_
(where I've adopted your mangling of call expression rather
than the one I suggested).
A better approach might be to fall back to the token stream
and mangle the token stream representing the function being
called. E.g. in the same way that
sr
gives you a way of mangling sizeof( T::foo() ), a variant
could be introduced for unqualified names, e.g.
su
which would allow the original sizeof(foo(V)) to be mangled
as
szcl2su3fooT0_
which is much more concise than mangling the overload set,
and more accurately reflects the 'same token stream'
requirement of the standard. (Though, 14.6.4.1/7 already
makes the program ill-formed, no diagnostic required, if a
specialisation has different meanings at different points of
instantiation, so the difference can only affect ill-formed
programs, I think.)
> | to mangle a function call, and you could mangle the
> | call to the non-overloaded function, foo:
> |
> | template int foo(T);
> | template A {};
> | template void bar( A );
> |
> | The obvious strategy is to encode bar as (I think)
> |
> | _Z3barIiLi42EEv1AIXszclL_Z3fooIiEiT_ET0__EE
> |
> | where _Z3fooIiEiT_ is the result of subsituting T=int into
> | the definition of foo. But this means that the template
> | parameters of bar are repeated and all the specialisations
> | of bar no longer have the form
> |
> | _Z3barI{parameters}Ev1AIXszclL_Z3fooIiEiT_ET0__EE
> |
> | ... because the 'i' from T=int is repeated. (Again, this is
> | only a problem if one wants to mangle two 'functionally
> | equivalent' overloads.)
>
> The killing point for GCC/g++ is to mangle the original template
> declaration -- not just the result of instantiation -- that is close
> to the 'same token stream' requirement of the C++ definition.
But does this have to be a killing point for GCC?
Although it seems preferable to stick as close to the
original template declaration as possible, and the note in
14.5.5.8 suggests that as a QoI issue, a compiler should aim
to treat functionally equivalent declarations that are not
equivalent as distinct, the 'functionally equivalent not not
equivalent' [14.5.5.1/7] rule grants compilers licence to
ignore any particularly tricky cases. That said, I think
my suggestion, above, of mangling the unmangled, unqualified
name gets around this.
Richard Smith
Re: C++ ABI: name mangling of operator new [bug 6057]
On Fri, 27 Jul 2007, Richard Smith wrote:
| > | The general philosophy in the current ABI would seem to be
| > | that the expression is encoded in terms of its template
| > | parameters, and not with the evaluated expression with the
| > | subsituted argument.
| >
| > That is correct. For a compiler, such as GCC, that uses parse trees
| > to represent a template declaration there is no additional
| > difficultly in mangling the expression, compared to the 'ordinary' case.
|
| My concern is how, practically, to mangle a call to an
| overloaded function, as, if the philosophy of encoding the
| expression in terms of template parameters is continued, you
| have to introduce ways of mangling the linked list of
| FUNCTION_DECLs in an OVERLOAD node.
We discussed this issue in CWG. We don't need to encode the overload
set. In fact, the only requirement we have is we select the same
function in all contexts, not that the overload set must be the same.
| This is certainly not
| impossible, but likely to be long-winded. And the
| possibility of ADL means that the overload set won't be the
| same for each instantiation of the template
Yes, that is OK as long as the selected function is the same
for each instantiation with same template and same arguments.
| E.g. in
|
| int foo(int); long foo(long);
| template A {};
| template void bar( A );
|
| we could introduce
|
| O E
I would suggest to just represent the expression sizeof(foo(V))
as a simple (linerized) tree. I don't think we been to say which
foo() is to be selected. "foo" by itself is already a good representation
of the overload set implied.
| to represent a overload set and represent the sizeof
| expression as
|
| szcl2OL_Z3fooiEL_Z3foolEET0_
|
| (where I've adopted your mangling of call expression rather
| than the one I suggested).
|
|
| A better approach might be to fall back to the token stream
| and mangle the token stream representing the function being
| called.
I believe the representation of token stream is all that is needed
(that is what I did in my quick demo to CWG). Certainly simply
encoding the overload set will not match the semantics as implied
by the C++ standard.
| E.g. in the same way that
|
| sr
|
| gives you a way of mangling sizeof( T::foo() ), a variant
| could be introduced for unqualified names, e.g.
|
| su
|
| which would allow the original sizeof(foo(V)) to be mangled
| as
|
| szcl2su3fooT0_
Is the "su" to indicate that the "foo" really is unprocessed, as opposed
to one that is processed? Could we do without it?
| which is much more concise than mangling the overload set,
| and more accurately reflects the 'same token stream'
| requirement of the standard.
Yes.
| (Though, 14.6.4.1/7 already
| makes the program ill-formed, no diagnostic required, if a
| specialisation has different meanings at different points of
| instantiation, so the difference can only affect ill-formed
| programs, I think.)
Yes.
[...]
| > | _Z3barI{parameters}Ev1AIXszclL_Z3fooIiEiT_ET0__EE
| > |
| > | ... because the 'i' from T=int is repeated. (Again, this is
| > | only a problem if one wants to mangle two 'functionally
| > | equivalent' overloads.)
| >
| > The killing point for GCC/g++ is to mangle the original template
| > declaration -- not just the result of instantiation -- that is close
| > to the 'same token stream' requirement of the C++ definition.
|
| But does this have to be a killing point for GCC?
No, it does not have to. I was reporting the current situation.
-- Gaby
Re: Creating gcc-newbies mailing list
On 7/27/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > Another recent example: http://gcc.gnu.org/ml/gcc/2007-07/msg00456.html > (Not a single answer). > > Summing up, I am not sure whether a separate list would help but in my > opinion there are a few things that will: If we do not manage to answer such mails on gcc@ (due to ressource reasons I suppose) than I doubt we will do better on a separate mailinglist. The amount of traffic with "newbie" questions is not dominant on gcc@ or gcc-patches@ anyway, so I see little point in directing them elsewhere where the only thing they would probably get is even less attention. Just my 2c, Richard.
Re: GCC with formal testing docs
On Thu, Jul 26, 2007 at 12:36:19PM -0700, Ian Lance Taylor wrote: > Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes: > > >For example, several targets would build/bootstrap and regtest fine with > > reload's find_valid_class() implemented as gcc_abort(). And guess what, > > there seems to be an off-by-one error in the outer loop exit condition. > > I think it is correct. According to the documentation in tm.texi, > N_REG_CLASSES should always be one larger than the last valid register > class. tm.texi does not require that NO_REGS == 0, so the loop is > arguably wrong in that way. In practice all machine descriptions do > define NO_REGS to be 0, and that should probably be documented as a > requirement. My bad, I'm misremebering something here. I think that loop is fine. But the fact remanins that find_valid_class() doesn't get much, if any, testing. I had a few lines of code in it to log arguments and return value to a file, and the last time I check, only powerpc-unknown-eabispe ever produced any output. (The reason I put in the logging in the first place was that my 16-bit x86 port was tripping the assertions in find_valid_class(). But something changed enough that it isn't even called any more.) -- Rask Ingemann Lambertsen
Re: Creating gcc-newbies mailing list
On Fri, Jul 27, 2007 at 11:26:22AM +0100, Manuel López-Ibáñez wrote: > Just an example. There are people that post patches in bugzilla and > they seem interested in getting them integrated but normally they > break coding style or don't have changelog or didn't even run the > testsuite. Of course, the easiest answer is to point to the "how to > contribute" webpage. I have done it too. But I must admit that it is a > poor answer. When I started, I couldn't bring myself to read all that > was required to post a proper patch. I could. Easily. But I also knew that I was going to submit more than just one or two patches. Maybe we can figure out a simpler procedure for those who will likely submit just one or two patches, where someone volunteers to fix the formatting, write the ChangeLog entry, do the testing and anything else that needs to be done for the patch to go in. I think we should encourage people to submit changes to the FSF tree rather than keeping private trees. This would include some way of dealing with copyright assignments and disclaimers before lots of patched are contributed by people who will later be difficult to track down. For example, the Amiga GCC port (host, build and target) never made it into the FSF sources mainly because by the time the idea came up, it was just too unclear who had contributed what, making it impossible to ensure the paperwork could be done. > * Documentation to learn. GCC has a lot of documentation. But it is > mostly for reference, that is, if you forget some detail or it is > under discussion, there is plenty of documentation. "grep -B 15 -e '^name_of_fuction ' *.c" you mean. > However, there is > little aimed to teach (with examples) the steps of how to contribute. > It is like telling people to learn programming by reading the ISO C > standard. The wiki is slowly changing this, but it still needs a lot > of work. A lot is missing for people writing back ends. The recent example of GEN_INT() vs. gen_int_mode()[1] is a good one. Someone new to GCC has no chance of finding such a function other than by luck. I have already started writing a simple list of helper functions for back ends some time ago. It isn't in the Wiki simply because I didn't know what a Wiki is at the time. I'll get to it in a week or so. > Regarding this, there is a curious effect that I experienced > myself. When I started one year ago I noticed the lack of simple > howtos describing the basic things like "how to submit a patch", "how > to prepare a testcase", etc. However, as soon as I learnt how to do > it, the task of describing them for newbies felt extremely tedious. This part of the documentation is fragmented in a way such that I sometimes can't find what I'm looking for, even if I know it is there (somewhere). For example, when it comes to submitting patches, we have http://gcc.gnu.org/codingconventions.html> and http://gcc.gnu.org/contribute.html> which both say something about ChangeLog enties while neither mention the patch tracker. Another example is that both http://gcc.gnu.org/contribute.html> and http://gcc.gnu.org/install/test.html> document how to test GCC, so you have to find and read both. [1] http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01051.html -- Rask Ingemann Lambertsen
Re: Creating gcc-newbies mailing list
On 27/07/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote: > On Fri, Jul 27, 2007 at 11:26:22AM +0100, Manuel López-Ibáñez wrote: > > Just an example. There are people that post patches in bugzilla and > > they seem interested in getting them integrated but normally they > > break coding style or don't have changelog or didn't even run the > > testsuite. Of course, the easiest answer is to point to the "how to > > contribute" webpage. I have done it too. But I must admit that it is a > > poor answer. When I started, I couldn't bring myself to read all that > > was required to post a proper patch. > >I could. Easily. But I also knew that I was going to submit more than > just one or two patches. Maybe we can figure out a simpler procedure for > those who will likely submit just one or two patches, where someone > volunteers to fix the formatting, write the ChangeLog entry, do the testing > and anything else that needs to be done for the patch to go in. Really? You read everything that is linked from http://gcc.gnu.org/contribute.html ? (and that doesn't explain for example how to create testcases). Anyway, I never said that nobody will be able to learn to program by reading the ISO C standard. I am sure there are people like that out there. They are not the majority, though. About your idea, I will rather prefer to be taught how to do it and for people to have patience when I make a mistake (but point it out nonetheless so I can correct it). But, yes, perhaps people that are going to submit one or two patches cannot be bothered. Can't speak about that, it is not my case. Cheers, Manuel.
Re: Creating gcc-newbies mailing list. Too many mailinglists? Unified mailing list?
2007/7/27, Joe Buck <[EMAIL PROTECTED]> wrote: > On Fri, Jul 27, 2007 at 04:22:31PM +0200, J.C. Pizarro wrote: > > The users don't want to join and detach to many mailing lists to post > > only a message once by week or month. He wants to post quickly, > > not to post slowly more than 10 minutes. > > You're trying to optimize the wrong cost measure. Could be a wrong cost measure, but it depends from the user wasting time to post a message. > It's not in our interest to have people "post quickly". The > time cost to compose and post a message is less than the time cost > of the thousands of people who will read that message, even if most > kill it based on the subject line or sender's identity. Separate lists > saves the time of those who aren't interested in certain types of > messages, or those who must make sure that every message of a certain type > (a patch, for example) gets processed. I didn't know that posting a message can kill time to the people that was reading it. > Also, you need not subscribe to a gcc list to post to it. It's non-announced phrase was unknown for me until now.
Re: GPLv3 in LTO and GIMPLE branches ya?
On 7/27/07 11:53 AM, J.C. Pizarro wrote: > It's too early Nick Clifton! Delay a little until 31th of July, please. ;) These came in via merges with mainline. I doubt that either branch has any issues with this change. The tuples branch certainly welcomes these changes.
Re: How to make use of instruction scheduling to improve performance?
"吴曦" <[EMAIL PROTECTED]> writes: > I am working on gcc 4.1.1 and itanium2 architecture. I instrumented > each ld and st instruction in final_scan_insn() by looking at the insn > template (These instrumentations are used to do some security checks). > These instrumentations incur high performance overhead when running > specint benchmarks. However, these instrumentations contain high > dependencies between instructions so that I want to use instruction > scheduling to improve the performance. > In the current implementation, the instrumentations are emitted as > assembly instructions (not insns). What should I do to make use of the > instruction scheduler? If I understand your description, you are adding instrumentation code, and you want to expose that code to the scheduler. What you need to do in that case is to add the code as RTL instructions before the scheduling pass runs. You will need to figure out the RTL which will do what you want. Then you will need to insert it around the instructions which you want to instrument. You will probably want to do this right before the second scheduling pass. You will probably need to write a new RTL pass which walks the insns and adds the instrumentation. Ian
Re: "Proceedings of the GCC Developers' Summit" now available
On 7/27/07 11:55 AM, Joe Buck wrote: > Why not provide a permanent home for the GCC summit proceedings at > gcc.gnu.org? It seems the logical place. That's what I've done. The .pdf is *in* gcc.gnu.org. The others could be sucked in as well. They're now pointing to gccsummit.
Re: GCC 4.2.1 : bootstrap fails at stage 2. compiler produces wrong binary for wrong processor
> "Dennis Clarke" <[EMAIL PROTECTED]> writes: > >> SUMMARY : the stage 2 compiler produces the wrong binary type for this >> machine > > This question is appropriate for the [EMAIL PROTECTED] mailing list > rather than the gcc@gcc.gnu.org list. Please take any followups to > gcc-help. Thanks. I was not aware that this list was not a general gcc mail list. I figure that basic configure - make - make check is a general thing. >> In either case I think that the --host needs to be specified as well as >> perhaps --with-cpu=foo or something like that in the ./configure line. > > It does seem from your description that you need to set the host > explicitly. That is not documented because it is rarely necessary. Hardly a valid point. The terms "not documented" is just not a very open source way of doing things. Oh well ... I guess I have to hunt for that. > Apparently the config.guess shell script produced the wrong results on > your system. bash-3.2$ /export/home/dclarke/build/gcc-4.2.1/config.guess sparc-sun-solaris2.8 That looks to be correct. > The option you want is --build, as in --build=sparc-sun-solaris2.8. I'll slide that into the ./configure line and have another go at it. > I don't actually know which --build option you want here. > I don't even know for sure that your old machine is supported. Well the idea here is that any old generation sparc machine ( sun4m ) will produce binaries that run on everything all the way up to the new Niagara and Sun UltraSparc IV without issue. Any difference in performance is a secondary and minor consideration that boils down to clock speed anyways. At the moment GCC 4.2.1 seems to be tied to the UltraSparc processor and thus the older sun4m and 32-bit Sparc machines are being ignored. They are still out there and still running in various places. The real issue *should* be that I can build GCC for a basic Sparc target if I want. Thank you for the pointers and I'll have a look at that. As for the other mail list, do I really need to subscribe to yet another mail list? :-( Dennis
Re: GCC 4.2.1 : bootstrap fails at stage 2. compiler produces wrong binary for wrong processor
"Dennis Clarke" <[EMAIL PROTECTED]> writes: > > "Dennis Clarke" <[EMAIL PROTECTED]> writes: > > > >> SUMMARY : the stage 2 compiler produces the wrong binary type for this > >> machine > > > > This question is appropriate for the [EMAIL PROTECTED] mailing list > > rather than the gcc@gcc.gnu.org list. Please take any followups to > > gcc-help. Thanks. > > I was not aware that this list was not a general gcc mail list. The list gcc@gcc.gnu.org is for people developing gcc. The list [EMAIL PROTECTED] is for people using gcc. The list descriptions may be found at http://gcc.gnu.org/lists.html. I again request that you take any followups to gcc-help. Thanks. > >> In either case I think that the --host needs to be specified as well as > >> perhaps --with-cpu=foo or something like that in the ./configure line. > > > > It does seem from your description that you need to set the host > > explicitly. That is not documented because it is rarely necessary. > > Hardly a valid point. The terms "not documented" is just not a very > open source way of doing things. Oh well ... I guess I have to hunt > for that. We use configure scripts generated by autoconf. We do not document every possible option used by such scripts. We only document the ones which are specific to gcc and the ones which are likely to be useful for people using gcc. For the full documentation of generic autoconf options, please see http://www.gnu.org/software/autoconf/manual/autoconf-2.57/autoconf.html > Well the idea here is that any old generation sparc machine ( sun4m ) will > produce binaries that run on everything all the way up to the new Niagara > and Sun UltraSparc IV without issue. Any difference in performance is a > secondary and minor consideration that boils down to clock speed anyways. > > At the moment GCC 4.2.1 seems to be tied to the UltraSparc processor and > thus the older sun4m and 32-bit Sparc machines are being ignored. They are > still out there and still running in various places. The real issue > *should* be that I can build GCC for a basic Sparc target if I want. If I understand correctly, then your best bet here may be to not worry about --build, but to instead use the --with-cpu option when you run configure (e.g., --with-cpu=v7). It appears that for Solaris 2.8 gcc will assume --with-cpu=sparcv9 if you don't explicitly use --with-cpu itself. Ian
Bootstrap broken on i386-pc-mingw32; ICE while building libgfortran
Hi all,
Bootstrap including gfortran has been broken on native i386-pc-mingw32
for at least 10 days, with the C compiler having an ICE while
compiling libgfortran/io/write.c. I finally found the opportunity to
reduce the ICE to the following code:
$ cat write.i
extern void fflush (int);
extern __attribute__ ((__dllimport__)) int _iob[];
static int __gthrw_pthread_once () __attribute__
((__weakref__("pthread_once")));
void flush_if_preconnected ()
{
fflush (_iob[0]);
}
$ C:/msys/1.0.10/home/FX/ibin/gcc/cc1.exe write.i -quiet
write.i:8: internal compiler error: Segmentation fault
The backtrace I could get from gdb can be found at the bottom of this
mail, and looks seriously garbled. I was wondering:
1. if someone else sees this issue? (for native compilers? for cross
compilers?)
2. what to do next? I've filed PR32915 , but I don't know what I
could do to debug further... I've nether done much programming or
debugging with Windows
Thanks for advice,
FX
-
Program received signal SIGSEGV, Segmentation fault.
decl_assembler_name_equal (decl=0x2ae2360, asmname=0x2ae1930)
at ../../trunk/gcc/tree.c:323
323 if (IDENTIFIER_POINTER (decl_asmname)[0] == '*')
(gdb) where
#0 decl_assembler_name_equal (decl=0x2ae2360, asmname=0x2ae1930)
at ../../trunk/gcc/tree.c:323
#1 0x00512973 in decl_assembler_name_equal (decl=0x2ae1930,
asmname=0x290f200) at ../../trunk/gcc/tree.c:314
#2 0x00512973 in decl_assembler_name_equal (decl=0x0, asmname=0x3d2412)
at ../../trunk/gcc/tree.c:314
#3 0x00512973 in decl_assembler_name_equal (decl=0x3d2412, asmname=0x0)
at ../../trunk/gcc/tree.c:314
#4 0x00512973 in decl_assembler_name_equal (decl=0x3d2412, asmname=0x0)
at ../../trunk/gcc/tree.c:314
#5 0x00512973 in decl_assembler_name_equal (decl=0x0, asmname=0x0)
at ../../trunk/gcc/tree.c:314
#6 0x00512973 in decl_assembler_name_equal (decl=0x3, asmname=0x3d24a0)
at ../../trunk/gcc/tree.c:314
#7 0x00512973 in decl_assembler_name_equal (decl=0x3a, asmname=0x4)
at ../../trunk/gcc/tree.c:314
#8 0x00512973 in decl_assembler_name_equal (decl=0x1, asmname=0x9)
at ../../trunk/gcc/tree.c:314
#9 0x00512973 in decl_assembler_name_equal (decl=0x0, asmname=0x2)
at ../../trunk/gcc/tree.c:314
#10 0x00512973 in decl_assembler_name_equal (decl=0x401280, asmname=0x0)
at ../../trunk/gcc/tree.c:314
#11 0x00512973 in decl_assembler_name_equal (decl=)
at ../../trunk/gcc/tree.c:314
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Re: Creating gcc-newbies mailing list
So, the idea of a new mailing list does not seem to be too popular. I'm interested in trying to attract new developers and provide basic information to get folks started. The basic motivation was that I've heard from several people both outside and inside GCC development that we can be a pretty hostile bunch. The GCC Wiki is becoming an excellent resource for that. So, I've added a new section http://gcc.gnu.org/wiki/GettingStarted that would be a central point where we can add all these tidbits of information that may not be too useful for experienced contributors, but should help everyone trying to get started. In there, we would add links to tutorials, howtos and projects that people may be interested in helping with.
Re: CSE removing a load that is necessary
"Pranav Bhandarkar" <[EMAIL PROTECTED]> writes:
> I am working on a private port and am seeing the following problem.
> For a function returning a double the value is stored by the function
> in memory. cse removes one of the two loads (to retrieve this returned
> value) after the function is called.
>
> To elaborate, the following is the dump just before cse.
>
> (insn 44 43 45 2 test.c:388 (set (reg:SI 1 $c1)
> (reg/f:SI 112 *fp*)) 44 {*movsi} (expr_list:REG_LIBCALL_ID
> (const_int 2 [0x2])
> (nil)))
>
> (insn 45 44 46 2 test.c:388 (set (reg:SI 2 $c2)
> (reg:SI 136 [ D.1517 ])) 44 {*movsi} (expr_list:REG_LIBCALL_ID
> (const_int 2 [0x2])
> (nil)))
>
> (call_insn 46 45 49 2 test.c:388 (parallel [
> (call (mem:SI (symbol_ref:SI ("__floatunsidf") [flags
> 0x41]) [0 S4 A32])
> (const_int 0 [0x0]))
> (use (const_int 0 [0x0]))
> (clobber (reg:SI 31 $link))
> ]) 41 {*call_direct} (expr_list:REG_LIBCALL_ID (const_int 2 [0x2])
> (expr_list:REG_EH_REGION (const_int -1 [0x])
> (nil)))
> (expr_list:REG_DEP_TRUE (use (reg:SI 2 $c2))
> (expr_list:REG_DEP_TRUE (use (reg:SI 1 $c1))
> (nil
>
> (insn 49 46 116 2 test.c:388 (clobber (reg:SI 179)) -1
> (expr_list:REG_LIBCALL_ID (const_int 2 [0x2])
> (nil)))
>
> (insn 116 49 47 2 test.c:388 (clobber (reg:SI 180 [+4 ])) -1 (nil))
>
> (insn 47 116 48 2 test.c:388 (set (reg:SI 179)
> (mem/c/i:SI (reg/f:SI 112 *fp*) [7 S4 A32])) 44 {*movsi}
> (expr_list:REG_LIBCALL_ID (const_int 2 [0x2])
> (nil)))
>
> (insn 48 47 50 2 test.c:388 (set (reg:SI 180 [+4 ])
> (mem/c/i:SI (plus:SI (reg/f:SI 112 *fp*)
> (const_int 4 [0x4])) [7 S4 A32])) 44 {*movsi}
> (expr_list:REG_LIBCALL_ID (const_int 2 [0x2])
> (expr_list:REG_EQUAL (float:DF (reg:SI 136 [ D.1517 ]))
>
>
>
> cse modifies insn 48 as
>
> (insn 48 47 50 2 test.c:388 (set (reg:SI 180 [+4 ])
> (reg:SI 178 [+4 ])) 44 {*movsi} (expr_list:REG_LIBCALL_ID
> (const_int 2 [0x2])
> (expr_list:REG_EQUAL (float:DF (reg:SI 136 [ D.1517 ]))
> (nil
> (nil
>
> and also replaces every subsequent use of (reg:SI 180 [+4 ]) with
> (reg:SI 178 [+4 ]) thus making the above load dead, which gets
> subsequently removed. This way the result of the function call is
> lost.
Where does reg 178 come from? It does not appear in the other insns
you listed.
> My take is that insn 48 should have a REG_RETVAL note ( Infact it
> does have this but the note is removed by lower_subreg) and cse should
> be careful when REG_RETVAL and REG_EQUAL appear in the same insn. Is
> this the right way of going about it ?
Am I reading your code correctly when it appears that the
__floatunsidf function returns a value in memory rather than via a
register?
If lower-subreg split up the load from memory, then it was correct to
remove the REG_RETVAL note. There may be a bug here in that it should
also remove the REG_EQUAL note in that case. It may be that
remove_retval_note needs to look for and remove a REG_EQUAL note.
Ian
Re: GCC 4.2.1 : bootstrap fails at stage 2. compiler produces wrong binary for wrong processor
what options do I need to set on the configure line in order for this to work? See http://gcc.gnu.org/gcc-4.2/changes.html , SPARC section. -- Eric Botcazou
CSE removing a load that is necessary
Hi All,
I am working on a private port and am seeing the following problem.
For a function returning a double the value is stored by the function
in memory. cse removes one of the two loads (to retrieve this returned
value) after the function is called.
To elaborate, the following is the dump just before cse.
(insn 44 43 45 2 test.c:388 (set (reg:SI 1 $c1)
(reg/f:SI 112 *fp*)) 44 {*movsi} (expr_list:REG_LIBCALL_ID
(const_int 2 [0x2])
(nil)))
(insn 45 44 46 2 test.c:388 (set (reg:SI 2 $c2)
(reg:SI 136 [ D.1517 ])) 44 {*movsi} (expr_list:REG_LIBCALL_ID
(const_int 2 [0x2])
(nil)))
(call_insn 46 45 49 2 test.c:388 (parallel [
(call (mem:SI (symbol_ref:SI ("__floatunsidf") [flags
0x41]) [0 S4 A32])
(const_int 0 [0x0]))
(use (const_int 0 [0x0]))
(clobber (reg:SI 31 $link))
]) 41 {*call_direct} (expr_list:REG_LIBCALL_ID (const_int 2 [0x2])
(expr_list:REG_EH_REGION (const_int -1 [0x])
(nil)))
(expr_list:REG_DEP_TRUE (use (reg:SI 2 $c2))
(expr_list:REG_DEP_TRUE (use (reg:SI 1 $c1))
(nil
(insn 49 46 116 2 test.c:388 (clobber (reg:SI 179)) -1
(expr_list:REG_LIBCALL_ID (const_int 2 [0x2])
(nil)))
(insn 116 49 47 2 test.c:388 (clobber (reg:SI 180 [+4 ])) -1 (nil))
(insn 47 116 48 2 test.c:388 (set (reg:SI 179)
(mem/c/i:SI (reg/f:SI 112 *fp*) [7 S4 A32])) 44 {*movsi}
(expr_list:REG_LIBCALL_ID (const_int 2 [0x2])
(nil)))
(insn 48 47 50 2 test.c:388 (set (reg:SI 180 [+4 ])
(mem/c/i:SI (plus:SI (reg/f:SI 112 *fp*)
(const_int 4 [0x4])) [7 S4 A32])) 44 {*movsi}
(expr_list:REG_LIBCALL_ID (const_int 2 [0x2])
(expr_list:REG_EQUAL (float:DF (reg:SI 136 [ D.1517 ]))
cse modifies insn 48 as
(insn 48 47 50 2 test.c:388 (set (reg:SI 180 [+4 ])
(reg:SI 178 [+4 ])) 44 {*movsi} (expr_list:REG_LIBCALL_ID
(const_int 2 [0x2])
(expr_list:REG_EQUAL (float:DF (reg:SI 136 [ D.1517 ]))
(nil
(nil
and also replaces every subsequent use of (reg:SI 180 [+4 ]) with
(reg:SI 178 [+4 ]) thus making the above load dead, which gets
subsequently removed. This way the result of the function call is
lost.
My take is that insn 48 should have a REG_RETVAL note ( Infact it
does have this but the note is removed by lower_subreg) and cse should
be careful when REG_RETVAL and REG_EQUAL appear in the same insn. Is
this the right way of going about it ?
Sorry for a rather verbose post.
Thanks in advance,
Pranav
Re: CSE removing a load that is necessary
> Where does reg 178 come from? It does not appear in the other insns
> you listed.
I am sorry, my mistake. I meant to say that the dump was only a part
of the entire dump of the function. reg 178 is the result of a
previous call to __floatsidf and is defined by the following insn.
(insn 19 18 21 2 test.c:356 (set (reg:SI 178 [+4 ])
(mem/c/i:SI (plus:SI (reg/f:SI 112 *fp*)
(const_int 4 [0x4])) [7 S4 A32])) 44 {*movsi}
(expr_list:REG_LIBCALL_ID (const_int 1 [0x1])
(expr_list:REG_EQUAL (float:DF (reg:SI 136 [ D.1517 ]))
(nil
> Am I reading your code correctly when it appears that the
> __floatunsidf function returns a value in memory rather than via a
> register?
For our architecture, we have had to follow this convention of
returning a double value by storing it in memory and loading it after
the function call. The ABI reserves only one SI mode register for
return values and hence the use of memory for returning a double.
> If lower-subreg split up the load from memory, then it was correct to
> remove the REG_RETVAL note. There may be a bug here in that it should
> also remove the REG_EQUAL note in that case. It may be that
> remove_retval_note needs to look for and remove a REG_EQUAL note.
Ok, so the approach should be to fix remove_retval_note to have it
remove REG_EQUAL note too rather than not call remote_retval_note at
all. I will submit a patch for comments.
Thanks,
Pranav
Re: GCC 4.2.1 : bootstrap fails at stage 2. compiler produces wrong binary for wrong processor
>> what options do I need to set on the configure line in order for this to >> work? > > See http://gcc.gnu.org/gcc-4.2/changes.html , SPARC section. You Sir are magnificent and wonderful ! Thank you so very much. Dennis
Re: GCC 4.2.1 : bootstrap fails at stage 2. compiler produces wrong binary for wrong processor
Dennis Clarke wrote: At the moment GCC 4.2.1 seems to be tied to the UltraSparc processor and thus the older sun4m and 32-bit Sparc machines are being ignored. The default cpu is v8plus. You can change that by using the configure option --with-cpu=v8 or --with-cpu=v7 depending on how old your machine is. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: GCC 4.2.1 : bootstrap fails at stage 2. compiler produces wrong binary for wrong processor
> Dennis Clarke wrote: >> At the moment GCC 4.2.1 seems to be tied to the UltraSparc processor and >> thus the older sun4m and 32-bit Sparc machines are being ignored. > > The default cpu is v8plus. You can change that by using the configure > option --with-cpu=v8 or --with-cpu=v7 depending on how old your machine is. A number of people have fired this at me and the configure script is running now with --wite-cpu=v7 there. I realize that this hardware is at the end of its life. Probably well past. But I am doing this for experimental reasons only. This is my litmus test that allows me to verify that GCC is *still* the definitive free compiler which will run on virtually anything anywhere .. even on old old junk like this. After this is done and I submit the testsuite I will decommision this machine. Actually the definitive free compiler would be the Sun Studio 12 compiler but only if you run Solaris 9 and up. Dennis
RE: Help required on use of gcc on SFU 3.5
Hi Naren >From the description that you just gave me, it looks like you aren't doing >anything special, just compiling a simple hello world program on SFU3.5. The only known issues wrt to this is that you might have DEP(Data Execution Protection) enabled which could be causing this. We have recently issued a QFE to one of our customers for this. So pls verify if you have that enabled, disable it and try once more. If that works for you, I will loop you with our support who will point you to the QFE which allows you to compile with DEP enabled. Thanks Mayank From: Naren Santanam (Information Technology) [mailto:[EMAIL PROTECTED] Sent: Friday, July 27, 2007 3:43 PM To: Mayank Kumar Cc: gcc@gcc.gnu.org Subject: Help required on use of gcc on SFU 3.5 Hi Mayank, I was reading through a lot of emails that were answered by you on the gnu forum for gcc. I have been trying to use the gcc to compile some c programs, but havent been able to. Well, here's my set up: Windows XP SP2 SFU 3.5 (with the default version of gcc installed). When i attempt to compile a simple "hello world " c program, here's the output : $ gcc.exe -v -da -Q abcd.c Reading specs from /opt/gcc.3.3/lib/gcc-lib/i586-pc-interix3/3.3/specs Configured with: : (reconfigured) : (reconfigured) /dev/fs/C/gnu2.intel/egcs.s ource//configure --verbose --prefix=/opt/gcc.3.3 --disable-shared --with-stabs - -enable-nls --with-local-prefix=/opt/gcc.3.3 --with-gnu-as --with-gnu-ld --enabl e-targets=i586-pc-interix3 --enable-threads=posix Thread model: posix gcc version 3.3 /opt/gcc.3.3/lib/gcc-lib/i586-pc-interix3/3.3/cc1 -v -D__GNUC__=3 -D__GNUC_MINO R__=3 -D__GNUC_PATCHLEVEL__=0 abcd.c -dumpbase abcd.c -da -auxbase abcd -version -o /tmp/cc5yiaKf.s gcc.exe: Internal error: Segmentation fault (program cc1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. Would you be able to tell me if there are any settings that need to be changed or about any known issues on this ? Thanks, Naren. Disclaimer and confidentiality note The contents of this e-mail and any attachments relating to the official business of Capitec Bank Limited (Capitec) are proprietary to Capitec. It is confidential, legally privileged and protected by law. Capitec does not own and endorse any other content. Views and opinions are those of the sender unless clearly indicated as being that of Capitec. The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way. Capitec cannot assure that the integrity of this communication has been maintained or that it is free of errors, virus, interception or interference.
RFC: RTL sharing between decls and instructions
unshare_all_rtl used to unshare DECL_RTLs as well as expressions in the
instruction stream. That changed with:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00541.html
I think that patch was in itself the right thing to do. However, in
anticipation of the old unshare_all_rtl behaviour, unshare_all_rtl_again
used to reset the used flags on all those DECL_RTLs. I think that's no
longer correct. unshare_all_rtl_again is used after reload, which may
have introduced invalid sharing by converting pseudo registers into
non-register expressions. These sharing problems exist between
DECL_RTLs and the instruction stream as well as between instructions
themselves.
Thus I think the right thing now is to get unshare_all_rtl_again to
_set_ rather than reset the used flags on DECL_RTLs, so that if a
DECL_RTL mentions an ex-register, all references to that ex-register
in the instruction stream will be copied. This is what the old
unshare_all_decls did as a side effect.
Does that sound right? I've checked that this patch fixes the case
I'm seeing, but I'm not too familiar with this code, so I wanted to
check whether I was barking up the wrong tree.
Sorry in advance if this has been suggested before.
Richard
gcc/
* emit-rtl.c (reset_used_decls): Rename to...
(set_used_decls): ...this. Set the used flag rather than clearing it.
(unshare_all_rtl_again): Update accordingly. Set flags on argument
DECL_RTLs rather than resetting them.
Index: gcc/emit-rtl.c
===
--- gcc/emit-rtl.c (revision 126993)
+++ gcc/emit-rtl.c (working copy)
@@ -167,7 +167,7 @@ #define first_label_num (cfun->emit->x_f
static rtx make_call_insn_raw (rtx);
static rtx change_address_1 (rtx, enum machine_mode, rtx, int);
-static void reset_used_decls (tree);
+static void set_used_decls (tree);
static void mark_label_nuses (rtx);
static hashval_t const_int_htab_hash (const void *);
static int const_int_htab_eq (const void *, const void *);
@@ -2160,11 +2160,11 @@ unshare_all_rtl_again (rtx insn)
}
/* Make sure that virtual stack slots are not shared. */
- reset_used_decls (DECL_INITIAL (cfun->decl));
+ set_used_decls (DECL_INITIAL (cfun->decl));
/* Make sure that virtual parameters are not shared. */
for (decl = DECL_ARGUMENTS (cfun->decl); decl; decl = TREE_CHAIN (decl))
-reset_used_flags (DECL_RTL (decl));
+set_used_flags (DECL_RTL (decl));
reset_used_flags (stack_slot_list);
@@ -2353,20 +2353,28 @@ unshare_all_rtl_in_chain (rtx insn)
}
/* Go through all virtual stack slots of a function and mark them as
- not shared. */
+ shared. We never replace the DECL_RTLs themselves with a copy,
+ but expressions mentioned into a DECL_RTL cannot be shared with
+ expressions in the instruction stream.
+
+ Note that reload may convert pseudo registers into memories in-place.
+ Pseudo registers are always shared, but MEMs never are. Thus if we
+ reset the used flags on MEMs in the instruction stream, we must set
+ them again on MEMs that appear in DECL_RTLs. */
+
static void
-reset_used_decls (tree blk)
+set_used_decls (tree blk)
{
tree t;
/* Mark decls. */
for (t = BLOCK_VARS (blk); t; t = TREE_CHAIN (t))
if (DECL_RTL_SET_P (t))
- reset_used_flags (DECL_RTL (t));
+ set_used_flags (DECL_RTL (t));
/* Now process sub-blocks. */
for (t = BLOCK_SUBBLOCKS (blk); t; t = TREE_CHAIN (t))
-reset_used_decls (t);
+set_used_decls (t);
}
/* Mark ORIG as in use, and return a copy of it if it was already in use.
Updated ecj.jar
I have updated ecj.jar and ecj-source.tar.bz2 on sourceware.org. This is the "reference ecj" that is used to build the .class files in libjava. If you have a build where compiling from .java to .class is enabled, you must update your ecj.jar. You can do this by running contrib/download_ecj. I will check in the updated .class files shortly. This update is being done because we have found a few bugs in the earlier ecj. Since there is no GCC release relying on the previous ecj.jar, I have deleted it. Just as a reminder, our plan is to have versioned copies of the .jars for release branches. Tom
Re: Creating gcc-newbies mailing list
On Fri, Jul 27, 2007 at 02:51:00PM +0100, Manuel López-Ibáñez wrote: > On 27/07/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote: > >If you ask me, we should rename gcc@ to gcc-development@ and maybe rename > > gcc-help@ to [EMAIL PROTECTED] > > ... gcc-dev@, keep gcc@ as an alias for gcc-dev@, replace in the > webpage gcc@ by gcc-dev@ and put gcc-help@ the first in the list. "-dev" and "-development" could be mistaken for "dev[elopment] using GCC". So could "gcc-hackers" and "gcc-advanced", which were the next two possibilities which popped into my head. If we go to the trouble of renaming lists, let's really drive the point home and call it "gcc-internals" or "gcc-maintainters" or the like. Putting gcc-help as the first address mentioned in lists.html is a good idea. Aliasing gcc@ to anything other than gcc-help@ or to an autoresponder which points people to lists.html will not do much to address the problem, in my humble/harsh opinion... but then I'm something of an unforgiving hardnose when it comes to offtopic messages, so perhaps that opinion should be discounted. :-) -- what does your robot do, sam? it collects data about the surrounding environment, then discards it and drives into walls
[wwwdocs] PATCH for Re: Creating gcc-newbies mailing list
On Fri, 27 Jul 2007, Phil Edwards wrote: > Putting gcc-help as the first address mentioned in lists.html is a > good idea. That's a good idea. Done thusly. Gerald Index: lists.html === RCS file: /cvs/gcc/wwwdocs/htdocs/lists.html,v retrieving revision 1.100 diff -u -3 -p -r1.100 lists.html --- lists.html 19 Nov 2006 15:28:11 - 1.100 +++ lists.html 27 Jul 2007 22:31:26 - @@ -37,6 +37,10 @@ before subscribing< Open lists: + http://gcc.gnu.org/ml/gcc-help/";>gcc-help + is a relatively high volume list for people searching for help in + building or using GCC. + http://gcc.gnu.org/ml/gcc/";>gcc is a high volume list for general development discussions about GCC. Anything relevant to the development or testing of GCC and not @@ -53,10 +57,6 @@ before subscribing< sufficient to follow the major trends and important news in GCC's development process. - http://gcc.gnu.org/ml/gcc-help/";>gcc-help - is a relatively high volume list for people searching for help in building - or using GCC. - http://gcc.gnu.org/ml/gcc-bugs/";>gcc-bugs is a relatively high volume list with mails from our Bugzilla bug-tracking system.
gcc-4.3-20070727 is now available
Snapshot gcc-4.3-20070727 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070727/ 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/trunk revision 127002 You'll find: gcc-4.3-20070727.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070727.tar.bz2 C front end and core compiler gcc-ada-4.3-20070727.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070727.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070727.tar.bz2 C++ front end and runtime gcc-java-4.3-20070727.tar.bz2 Java front end and runtime gcc-objc-4.3-20070727.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070727.tar.bz2The GCC testsuite Diffs from 4.3-20070720 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: How to make use of instruction scheduling to improve performance?
> > > > I am working on gcc 4.1.1 and itanium2 architecture. I instrumented > > > > each ld and st instruction in final_scan_insn() by looking at the insn > > > > template (These instrumentations are used to do some security checks). > > > > These instrumentations incur high performance overhead when running > > > > specint benchmarks. However, these instrumentations contain high > > > > dependencies between instructions so that I want to use instruction > > > > scheduling to improve the performance. > > > > In the current implementation, the instrumentations are emitted as > > > > assembly instructions (not insns). What should I do to make use of the > > > > instruction scheduler? > > > > > > If I understand your description, you are adding instrumentation code, > > > and you want to expose that code to the scheduler. What you need to > > > do in that case is to add the code as RTL instructions before the > > > scheduling pass runs. You will need to figure out the RTL which will > > > do what you want. Then you will need to insert it around the > > > > > instructions which you want to instrument. You will probably want to > > ~ > > Before the second scheduling pass, how to identify that one insn will > > be output as a load instruction (or store instruction)? In the final, > > i use get_insn_template() to do this matching. Can I use the same > > method before the second scheduling pass? If not, would you mind > > giving some hints? thx > > Please send followups to the mailing list, not just to me. Thanks. > > You should just match on the RTL. I don't know enough about the > Itanium to tell you precisely what to look for. But, for example, you > might look for >s = single_set (PATTERN (insn)); >if (s != NULL && (MEM_P (SET_SRC (s) || MEM_P (SET_DEST (s) > ... > > Ian > Thanks. I observe that the 2nd instruction scheduling happens after the local and global allocation. However, in my instrumentation, I need several registers to do computation, can I allocate registers to do computation in the instrumentation code just before the 2nd instruction scheduling? If so, would you mind giving some hints on the interfaces that I could make use of. Besides, what happens if I move the insertion of instrumentation before register allocation, or even before the 1st scheduling pass, can I identify load/store instructions that early?
gcc register allocation
Hi I am in the process of verifying that gcc (3.3.2) produces traceable object code (ie. gcc does not introduce 'hidden' structure into the object code). I have created a file with several functions containing various combinations of C constructs and I intend to examine the resulting object code (PowerPC 604 target) to determine traceability. What I need and can't seem to find is a method of determining the register allocation (to specific variable) for each resulting object code function. This 'must' be available in some debug format(?) I could of course do this by inspection but this is subject to errors and is time consuming. Is there any convenient way I can get gcc to dump this information when I compile the code? Thanks Duncan DISCLAIMER: Unless indicated otherwise, the information contained in this message is privileged and confidential, and is intended only for the use of the addressee(s) named above and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message and/or attachments is strictly prohibited. The company accepts no liability for any damage caused by any virus transmitted by this email. Furthermore, the company does not warrant a proper and complete transmission of this information, nor does it accept liability for any delays. If you have received this message in error, please contact the sender and delete the message. Thank you.
Re: Creating gcc-newbies mailing list
On 26 Jul 2007 15:53:09 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > Joe Buck <[EMAIL PROTECTED]> writes: > > > I think that when we do steer someone to a different list, we could > > take more care to be polite about it than we sometimes are. > > I agree. I also think we should all try harder to avoid flippant or > non-responsive replies to new developers. I think it's important for > the long-term growth of gcc for us to encourage new developers. There were several presentations at OSCON that touched on these issues: Brian Fitzpatrick and Ben Collins-Sussman's "poisonous people" talk, while mostly about how to deal with difficult people, also touched on how to establish an expectation of courtesy and respect. The perceived leaders of the community need to make gentle but public corrections when someone doesn't reply well, even if the person being criticized is a leading contributor. The goal is to have everyone know the rules, and know that they apply to everyone. The first and third talks are the ones relevant here: http://conferences.oreillynet.com/cs/os2007/view/e_spkr/2762 And Karl Fogel's book goes into exactly these issues in detail: http://producingoss.com/en/setting-tone.html
Re: How to make use of instruction scheduling to improve performance?
Hi, On 7/28/07, 吴曦 <[EMAIL PROTECTED]> wrote: > > > > > I am working on gcc 4.1.1 and itanium2 architecture. I instrumented > > > > > each ld and st instruction in final_scan_insn() by looking at the insn > > > > > template (These instrumentations are used to do some security checks). > > > > > These instrumentations incur high performance overhead when running > > > > > specint benchmarks. However, these instrumentations contain high > > > > > dependencies between instructions so that I want to use instruction > > > > > scheduling to improve the performance. > > > > > In the current implementation, the instrumentations are emitted as > > > > > assembly instructions (not insns). What should I do to make use of the > > > > > instruction scheduler? > > > > > > > > If I understand your description, you are adding instrumentation code, > > > > and you want to expose that code to the scheduler. What you need to > > > > do in that case is to add the code as RTL instructions before the > > > > scheduling pass runs. You will need to figure out the RTL which will > > > > do what you want. Then you will need to insert it around the > > > > > > > instructions which you want to instrument. You will probably want to > > > ~ > > > Before the second scheduling pass, how to identify that one insn will > > > be output as a load instruction (or store instruction)? In the final, > > > i use get_insn_template() to do this matching. Can I use the same > > > method before the second scheduling pass? If not, would you mind > > > giving some hints? thx > > > > Please send followups to the mailing list, not just to me. Thanks. > > > > You should just match on the RTL. I don't know enough about the > > Itanium to tell you precisely what to look for. But, for example, you > > might look for > >s = single_set (PATTERN (insn)); > >if (s != NULL && (MEM_P (SET_SRC (s) || MEM_P (SET_DEST (s) > > ... > > > > Ian > > > > Thanks. I observe that the 2nd instruction scheduling happens after > the local and global allocation. However, in my instrumentation, I > need several registers to do computation, can I allocate registers to > do computation in the instrumentation code just before the 2nd > instruction scheduling? If so, would you mind giving some hints on the > interfaces that I could make use of. Generally you should be able to create new temporaries for such calculations before register allocation / reload . Otherwise you might have to resort to reserving a couple of registers in your ABI for such computations if you wanted these generated after reload (you could have a split that did that after reload but where in the function do you want to insert the instrumentation code ?) From what you are indicating - there isn't enough detail about where in the function body you are inserting such instrumentation code - If you are doing such instrumentation in the prologue or epilogue of a function, you could choose to use gen_reg_rtx to obtain a temporary register. So typically obtain a temporary register in the following manner rtx tmp_reg = gen_reg_rtx (mode); Use the tmp_reg in whatever instruction you want to generate using the corresponding register as one of the operands . For these you might want to use the corresponding gen_*** named functions . cheers Ramana >Besides, what happens if I move the insertion of instrumentation > before register allocation, or even before the 1st scheduling pass, > can I identify load/store instructions that early? > -- Ramana Radhakrishnan
