Re: odd array subscript is above array bounds error
2009/3/5 Dave Korn : > > of an array that only has size[4] is going one past the end. So the bug is > the missing warning for the simplified testcase, not that the warning is > somehow incorrect in the more complex one. No. The array is unused so it gets removed quite early. If you *do* return the array, then the warning appears. There is no bug here (except we could warn for unused array, that would be nice... if you wish to open a PR for that). > I would hope that in the simpler case the entire unused local array gets > optimised away, and the loop and 'a' go with it. That might explain why > there's no sign of an error. But your testcase invokes invalid behaviour, so > there's no reason why the compiler shouldn't handle it in differing and > inconsistent ways at different optimisation levels. In fact the simple local array gets removed by the moment we reach 034t.sdse. Cheers, Manuel.
Re: Fwd: gcc-4.2-20090304 is now available
On Thu, Mar 5, 2009 at 2:35 AM, Joseph S. Myers wrote: > On Wed, 4 Mar 2009, H.J. Lu wrote: > >> Do we really need a new snapshot when only DATESTAMP is updated? I >> think it is a waste >> of resources. It is. > When 4.4 has branched I plan to close 4.2 branch. Maybe we can remove DATESTAMP and updating it now that gcc_update understands to extract the SVN revision number? Richard.
Re: GCC at Google Summer of Code'2009
Hi Grigori, I'm a graduate student at the Institute Of Computing Technology Chinese Academy Of Sciences, and I'm interested in the Summer of Code projects you list in the gcc wiki, especially the one to extend the ICI/MILEPOST framework to enable fine-grain tunning. As compiler is my research area, I've read about the framework before, and now I'm looking forward to launch a SoC project on it. Cheers, Yuanjie > -Original Message- > From: Grigori Fursin [mailto:gfur...@gmail.com] On Behalf Of Grigori Fursin > Sent: Thursday, February 26, 2009 6:57 PM > To: gcc@gcc.gnu.org > Cc: 'Basile STARYNKEVITCH'; 'Diego Novillo'; 'Taras Glek'; 'Zbigniew > Chamski'; 'Sean Callanan'; 'Cupertino Miranda'; 'Joseph S. Myers'; 'Le-Chun > Wu'; 'Sebastian Pop'; 'Albert Cohen'; 'Michael O'Boyle'; 'Paul H J Kelly'; > 'Olivier Temam'; 'Chengyong Wu'; 'Ayal Zaks'; 'Bilha Mendelson'; 'Mircea > Namolaru'; 'Erven Rohou'; 'Cosmin Oancea'; 'David Edelsohn'; 'Kenneth > Zadeck' > Subject: GCC at Google Summer of Code'2009 > > Hello All, > > I just saw an announcement that a new Google Summer of Code'2009 > (http://code.google.com/soc) will be accepting project proposals > in a week or so. My colleagues and I would like to submit a few proposals > so wanted to ask if someone is interested in that to synchronize > submissions. > > 4) Extend GCC generic function cloning to be able to create > static binaries adaptable to different architectures at run-time. > Cupertino Miranda has been extending this work recently and we may > need to sync on that ... > > I am fine to mentor a few of them (particularly from 1-3) but would like to > see if someone > is interested to help with that ?.. I added these topics to the GCC GSOC > page: > http://gcc.gnu.org/wiki/SummerOfCode > and would be happy if you modify it or tell me if you are interested ... > > Thanks, > Grigori -- Yuanjie Huang
Re: [RFC] Better debug info by substitution tracking for inliner (and other passes eliminating whole user variables)
On Thu, 5 Mar 2009, Jan Hubicka wrote:
> Hi,
> this patch resulted from attempt to solve regression we have in
> gdb.opt/inline-locals.exp gdb testsuite and also problems with fact that when
> clonning function by ipa-cp we lose any information on function argument.
> (and yes, it solves it)
>
> The gdb.opt/inline-locals.exp testsuite shows common pattern
>
> func (argument)
> {
> }
>
> otherfunc (otherargument)
> {
> func (otherargument);
> }
>
> Where we now fully replace ARGUMENT by OTHERARGUMENT when inlining while older
> compilers actually substituted backwards, so ARGUMENT was available while
> OTHERARGUMENT was not. This is quite irritating behaviour when trying to
> debug since parameters of inlined functions tends to be lost.
>
> The patch adds mechanizm for tracking inline substitutions, so we
> actually note that on whole scope of its existence ARGUMENT is having
> same value as OTHERARGUMENT. This is represented by extending
> NONLOCALIZED_VAR vector to contain optimized out declaration and it's
> replacement
...
This sounds like a simplified (only track parameter "coalescing") form
of what we implemented on var-mappings-branch. As I see it would
work well for wrapper functions, or rather in case either name ends
up completely unused but will "break" once uses of both names
persist. So, do you see any practical use besides C++ wrapper
functions? Is it worth fixing them?
Thanks,
Richard.
Re: [RFC] Better debug info by substitution tracking for inliner (and other passes eliminating whole user variables)
On Thu, 5 Mar 2009, Richard Guenther wrote:
> On Thu, 5 Mar 2009, Jan Hubicka wrote:
>
> > Hi,
> > this patch resulted from attempt to solve regression we have in
> > gdb.opt/inline-locals.exp gdb testsuite and also problems with fact that
> > when
> > clonning function by ipa-cp we lose any information on function argument.
> > (and yes, it solves it)
> >
> > The gdb.opt/inline-locals.exp testsuite shows common pattern
> >
> > func (argument)
> > {
> > }
> >
> > otherfunc (otherargument)
> > {
> > func (otherargument);
> > }
> >
> > Where we now fully replace ARGUMENT by OTHERARGUMENT when inlining while
> > older
> > compilers actually substituted backwards, so ARGUMENT was available while
> > OTHERARGUMENT was not. This is quite irritating behaviour when trying to
> > debug since parameters of inlined functions tends to be lost.
> >
> > The patch adds mechanizm for tracking inline substitutions, so we
> > actually note that on whole scope of its existence ARGUMENT is having
> > same value as OTHERARGUMENT. This is represented by extending
> > NONLOCALIZED_VAR vector to contain optimized out declaration and it's
> > replacement
>
> ...
>
> This sounds like a simplified (only track parameter "coalescing") form
> of what we implemented on var-mappings-branch. As I see it would
> work well for wrapper functions, or rather in case either name ends
> up completely unused but will "break" once uses of both names
> persist. So, do you see any practical use besides C++ wrapper
> functions? Is it worth fixing them?
Btw, instead of trying to keep trees live and valid why not finally
start generating dwarf at the point we lose this information?
Richard.
constant propagation optimization
Hi every one,
I have a question about gcc optimization, I hope I am writing to the right list
I compiled a simple c++ program using gcc 4.0.1
#include
using namespace std;
intc;
calss Calcul
{
public: void affich()
{
cout << "hello world" << endl;
}
public void inc (int& c)
{
switch (c)
{
case 1 : c=c+1; break;
case 2 : c=c+2; break;
case 3 : c=c+3; break;
default : c=c+0;
}
};
int main()
{
Calcul ca;
c=3;
ca.affich();
ca.inc(c);
cout << "the value of c is" << c << endl;
return 0;
}
I am interested in cpp optimisation (constant propagation)
normally, if I compile it using g++ test.cpp -O3 -fdump-tree-all, the c
variable will be considered as constant (ca.inc(c); will be replaced only by c
= 6; )
This kind of optimization is well done if I declare c just before ca.inc(c)):
compiling the code bellow, the ca.inc(c) is replaced by c=6; (in the test1.dom1
file)
int main()
{
Calcul ca;
ca.affich();
c=3;
ca.inc(c);
cout << "the value of c is" << c << endl;
return 0;
}
Why in the fist code, c is not considered as a constant (in spite that affich()
does not change c)
Thank you very much
Asma
Re: [RFC] Better debug info by substitution tracking for inliner (and other passes eliminating whole user variables)
> On Thu, 5 Mar 2009, Jan Hubicka wrote:
>
> > Hi,
> > this patch resulted from attempt to solve regression we have in
> > gdb.opt/inline-locals.exp gdb testsuite and also problems with fact that
> > when
> > clonning function by ipa-cp we lose any information on function argument.
> > (and yes, it solves it)
> >
> > The gdb.opt/inline-locals.exp testsuite shows common pattern
> >
> > func (argument)
> > {
> > }
> >
> > otherfunc (otherargument)
> > {
> > func (otherargument);
> > }
> >
> > Where we now fully replace ARGUMENT by OTHERARGUMENT when inlining while
> > older
> > compilers actually substituted backwards, so ARGUMENT was available while
> > OTHERARGUMENT was not. This is quite irritating behaviour when trying to
> > debug since parameters of inlined functions tends to be lost.
> >
> > The patch adds mechanizm for tracking inline substitutions, so we
> > actually note that on whole scope of its existence ARGUMENT is having
> > same value as OTHERARGUMENT. This is represented by extending
> > NONLOCALIZED_VAR vector to contain optimized out declaration and it's
> > replacement
>
> ...
>
> This sounds like a simplified (only track parameter "coalescing") form
> of what we implemented on var-mappings-branch. As I see it would
> work well for wrapper functions, or rather in case either name ends
> up completely unused but will "break" once uses of both names
> persist. So, do you see any practical use besides C++ wrapper
I note substitution only for parameters that are completely replaced by
inliner, i.e. they are not set locally in function. That is only
in case we don't produce new declaration and copy statement, just
entry in NONLOCALIZED_VAR. I was thinking that perhaps I can also
handle case where parameter has more SSA names by noting the default
value and using DW_OP_default_value feature, but I am not sure it is
worth the effort and I guess var-mappings-branch or debug-branch
infrastructure shuld handle it.
The never modified function parameters are however quite case - you don't use
function parameter as
temporary variable most of time. So it works pretty well for GCC
sources (in fact it was about the main motivation that I tended to land
in tree-flow-inline and not having chance to inspect function
arguments).
It is not about wrapper functions, but also about parameters of
innermost function in the inline stack. For example in tree-ssa-ccp we
can track about 300 variables this way for most of the gimple
predicates:
{ Scope block #0
tree_code code;
static const char __FUNCTION__[23] = "gimple_assign_rhs_code";
{ Scope block #1202 (unused) ../../gcc/gimple.h:1832 Originating from :
static union tree_node * gimple_assign_rhs1 (const union gimple_statement_d *);
const union gimple_statement_d * gs = const union gimple_statement_d
*;replaced by:gs (nonlocalized)
{ Scope block #1203 (unused) Originating from :#0
static const char __FUNCTION__[19] = "gimple_assign_rhs1"; (nonlocalized)
{ Scope block #1204 (unused) ../../gcc/gimple.h:1730 Originating from :
static union tree_node * gimple_op (const union gimple_statement_d *, unsigned
int);
const union gimple_statement_d * gs = const union gimple_statement_d
*;replaced by:gs (nonlocalized)
unsigned int i = unsigned int;replaced by:1 (nonlocalized)
Without tracking we would get value of "gs" in the outer scope of the
function itself, but in inlined gimple_assign_rhs1 and gimple_op it
would end up optimized out.
Pre SSA inliner copmilers would behave other way, they would backward
propagate value to one of innermost inlined funcitions of "gs" but it
would not be available otherwise.
How would you expect to generate dwarf at the inlining time for those
variables? The substitutions has to combine in cascaded inlining and
has to be brought up to date for SRA and later get locations from RTL
land, so doing all this in in-memory dwarf structure seems bit
difficult..
Honza
> functions? Is it worth fixing them?
>
> Thanks,
> Richard.
Re: [RFC] Better debug info by substitution tracking for inliner (and other passes eliminating whole user variables)
Hello Jan, * Jan Hubicka wrote on Thu, Mar 05, 2009 at 11:54:31AM CET: > *** dwarf2out.c (revision 144621) > --- dwarf2out.c (working copy) > *** along with GCC; see the file COPYING3. > *** 89,94 > --- 89,95 > #include "hashtab.h" > #include "cgraph.h" > #include "input.h" > + #include "gimple.h" This needs Makefile.in adjustment. Cheers, Ralf
Re: ANNOUNCEMENT: Generic Data Flow Analyzer for GCC
Hi. Sorry for inconvenience. The link should work now. If it wont, then please have patience for few days. The work of server upgradation is going on, which might have coused problem. We are talking to system administrator for the same. The problem will be fixed within a couple of days. - Seema On Thu, Mar 5, 2009 at 6:46 AM, Albert Cohen wrote: > > Emmanuel Fleury wrote: >> >> Andrew Pinski wrote: >>> >>> On Wed, Mar 4, 2009 at 8:33 AM, Manuel López-Ibáñez >>> wrote: > > The proxy server received an invalid response from an upstream server. > I can access without problem. >>> >>> I get the same error message that Tom gets. I am on AT&T DSL so I >>> doubt it is my side which is having issues. >> >> I have no problem accessing it (from France network). > > It does NOT work for me either. > > Albert
Re: Fwd: gcc-4.2-20090304 is now available
On Thu, 5 Mar 2009, Richard Guenther wrote: > On Thu, Mar 5, 2009 at 2:35 AM, Joseph S. Myers > wrote: > > On Wed, 4 Mar 2009, H.J. Lu wrote: > > > >> Do we really need a new snapshot when only DATESTAMP is updated? I > >> think it is a waste > >> of resources. > > It is. > > > When 4.4 has branched I plan to close 4.2 branch. > > Maybe we can remove DATESTAMP and updating it now that > gcc_update understands to extract the SVN revision number? I think DATESTAMP serves a useful purpose in providing immediate identification of what trunk or release branch version given sources are based on, when those sources may be another branch last merged from trunk or a release branch a while back or imported into another version control system, so that a revision number does not give this information. Anyway, removing DATESTAMP would change the issue to new snapshots with no changes rather than with just DATESTAMP changes. -- Joseph S. Myers jos...@codesourcery.com
Re: Fwd: gcc-4.2-20090304 is now available
On Thu, Mar 5, 2009 at 2:47 PM, Joseph S. Myers wrote: > - Show quoted text - > On Thu, 5 Mar 2009, Richard Guenther wrote: > >> On Thu, Mar 5, 2009 at 2:35 AM, Joseph S. Myers >> wrote: >> > On Wed, 4 Mar 2009, H.J. Lu wrote: >> > >> >> Do we really need a new snapshot when only DATESTAMP is updated? I >> >> think it is a waste >> >> of resources. >> >> It is. >> >> > When 4.4 has branched I plan to close 4.2 branch. >> >> Maybe we can remove DATESTAMP and updating it now that >> gcc_update understands to extract the SVN revision number? > > I think DATESTAMP serves a useful purpose in providing immediate > identification of what trunk or release branch version given sources are > based on, when those sources may be another branch last merged from trunk > or a release branch a while back or imported into another version control > system, so that a revision number does not give this information. > > Anyway, removing DATESTAMP would change the issue to new snapshots with no > changes rather than with just DATESTAMP changes. Hm, is it maybe possible to adjust a REVISION in the svn repository by some pre-/post-commit hook so it automatically contains the revision of the last checkin? Then we'd bump such thing only if there are changes on the branch. Of course the snapshot generation would need to trigger only if there were checkins since the last snapshot. Richard.
Re: odd array subscript is above array bounds error
On Thu, Mar 05, 2009 at 10:05:15AM +0100, Manuel López-Ibáñez wrote: > 2009/3/5 Dave Korn : > > > > of an array that only has size[4] is going one past the end. So the bug is > > the missing warning for the simplified testcase, not that the warning is > > somehow incorrect in the more complex one. > > No. The array is unused so it gets removed quite early. If you *do* > return the array, then the warning appears. There is no bug here > (except we could warn for unused array, that would be nice... if you > wish to open a PR for that). > > > I would hope that in the simpler case the entire unused local array gets > > optimised away, and the loop and 'a' go with it. That might explain why > > there's no sign of an error. But your testcase invokes invalid behaviour, > > so > > there's no reason why the compiler shouldn't handle it in differing and > > inconsistent ways at different optimisation levels. > > In fact the simple local array gets removed by the moment we reach 034t.sdse. > > Cheers, > > Manuel. Manuel, It seems that the simplier testcase must be optimizing away the loop at all optimization levels. Are there any options that would suppress that optimization if one was just looking for array bounds errors with -Warray-bounds? Jack
Re: ANNOUNCEMENT: Generic Data Flow Analyzer for GCC
Hello Sir, On Wed, Mar 4, 2009 at 7:44 PM, Manuel López-Ibáñez wrote: > I am no expert in this area, so please consider that I may be > misunderstanding something. > > This seems a data flow analyzer for GIMPLE. So the analysis results > can be used by the FE, am I wrong? > ( I am assuming by FE you mean, front end and VRP is value range propagation) GIMPLE is a stage after front end perticularely after AST, type checking etc is done. So I can't visualize how it can be used in FE. As far as i know, Data flow analysis is used for the purpose of, 1. Optimizations 2. Producing dignostic information about source code. > Could it be used to propagate constant values? What about VRP in the FE? > We have implemented bit vector analysis framework only. Constant propagation is not implemented yet, so no VRP :) > What is the overhead involved? We are using existing IR, existing APIs for accessing GIMPLE data structure. Only new pass to perform DFA has been added to the GCC pass structure. The space overhead is interms of storage of data flow values using sbitmap. > > I ask because I know that Clang performs data flow analysis in the FE > to provide better warnings, and Chris Lattner said that the overhead > of doing this was very low. > The beauty of GDFA code lies within, the specifications provided for GDFA. One does not have to implement local analysis in order to incorporate new data flow analysis. (for time being, bit vector analysis) - Seema > Cheers, > > Manuel. > > 2009/3/4 Seema Ravandale : >> Announcement: gdfa - Generic data flow analyzer for GCC. >> Developed by: GCC resource center, IITB >> >> Patch and the Documentation can be found at the below link, >> >> http://www.cse.iitb.ac.in/grc/gdfa.html >> >> >> Ms. Seema S. Ravandale >> Project Engg, >> GCC Resource Center >> Department of Computer Science & Engg. >> IIT Bombay, Powai, Mumbai 400 076, India. >> email - se...@cse.iitb.ac.in >> >
Re: odd array subscript is above array bounds error
2009/3/5 Jack Howarth : > > Manuel, > It seems that the simplier testcase must be optimizing away the loop > at all optimization levels. Are there any options that would suppress that > optimization if one was just looking for array bounds errors with > -Warray-bounds? > Jack > I don't understand what you mean. The warning is given before the loop is removed. The warning is not given in your simple testcase because the array is unused. It has little to do with the loop. If you use the array (like if you return it), then the warning appears. Cheers, Manuel.
Re: Fwd: gcc-4.2-20090304 is now available
On Thu, Mar 5, 2009 at 5:47 AM, Joseph S. Myers wrote: > On Thu, 5 Mar 2009, Richard Guenther wrote: > >> On Thu, Mar 5, 2009 at 2:35 AM, Joseph S. Myers >> wrote: >> > On Wed, 4 Mar 2009, H.J. Lu wrote: >> > >> >> Do we really need a new snapshot when only DATESTAMP is updated? I >> >> think it is a waste >> >> of resources. >> >> It is. >> >> > When 4.4 has branched I plan to close 4.2 branch. >> >> Maybe we can remove DATESTAMP and updating it now that >> gcc_update understands to extract the SVN revision number? > > I think DATESTAMP serves a useful purpose in providing immediate > identification of what trunk or release branch version given sources are > based on, when those sources may be another branch last merged from trunk > or a release branch a while back or imported into another version control > system, so that a revision number does not give this information. > > Anyway, removing DATESTAMP would change the issue to new snapshots with no > changes rather than with just DATESTAMP changes. > My regression hunt script has # Get the new checkins since the last revision. svn log -r$LAST_REVISION:$REV $REP_URL | egrep -v "^r$LAST_REVISION" | egrep -v "gccadmin" | egrep "^r[0-9]+" > rev.log # Check if rev.log is empty. if [ ! -s rev.log ]; then echo No new checkins since revision $LAST_REVISION! rm -f lock exit 0 fi Of course, you have to remember the revision when the last snapshot was made. -- H.J.
Re: ANNOUNCEMENT: Generic Data Flow Analyzer for GCC
On Thu, Mar 5, 2009 at 3:09 PM, Seema Ravandale wrote: > Hello Sir, > > On Wed, Mar 4, 2009 at 7:44 PM, Manuel López-Ibáñez > wrote: >> I am no expert in this area, so please consider that I may be >> misunderstanding something. >> >> This seems a data flow analyzer for GIMPLE. So the analysis results >> can be used by the FE, am I wrong? >> > > ( I am assuming by FE you mean, front end and VRP is value range propagation) > > GIMPLE is a stage after front end perticularely after AST, type > checking etc is done. > So I can't visualize how it can be used in FE. > As far as i know, Data flow analysis is used for the purpose of, > 1. Optimizations > 2. Producing dignostic information about source code. > >> Could it be used to propagate constant values? What about VRP in the FE? >> > > We have implemented bit vector analysis framework only. Constant > propagation is not implemented yet, so no VRP :) > >> What is the overhead involved? > > We are using existing IR, existing APIs for accessing GIMPLE data structure. > Only new pass to perform DFA has been added to the GCC pass structure. > The space overhead is interms of storage of data flow values using sbitmap. > >> >> I ask because I know that Clang performs data flow analysis in the FE >> to provide better warnings, and Chris Lattner said that the overhead >> of doing this was very low. >> > > The beauty of GDFA code lies within, the specifications provided for GDFA. > One does not have to implement local analysis in order to incorporate > new data flow analysis. (for time being, bit vector analysis) Does it do data-flow analysis on memory or only on SSA_NAMEs? If it does data-flow analysis on memory, what is the granularity in case of structures/arrays and subsetting? Richard. > - Seema > - Show quoted text - >> Cheers, >> >> Manuel. >> >> 2009/3/4 Seema Ravandale : >>> Announcement: gdfa - Generic data flow analyzer for GCC. >>> Developed by: GCC resource center, IITB >>> >>> Patch and the Documentation can be found at the below link, >>> >>> http://www.cse.iitb.ac.in/grc/gdfa.html >>> >>> >>> Ms. Seema S. Ravandale >>> Project Engg, >>> GCC Resource Center >>> Department of Computer Science & Engg. >>> IIT Bombay, Powai, Mumbai 400 076, India. >>> email - se...@cse.iitb.ac.in >>> >> >
Re: [RFC] Better debug info by substitution tracking for inliner (and other passes eliminating whole user variables)
Jan Hubicka wrote: Hi, this patch resulted from attempt to solve regression we have in gdb.opt/inline-locals.exp gdb testsuite and also problems with fact that when clonning function by ipa-cp we lose any information on function argument. (and yes, it solves it) <...> I know that this is one of problems being solved on debug branch, but there is problem with DEBUG_INSN approach and scalability for C++ programs. In tramp3d and similar testcases we have >10 inlined function scopes for every instruction, so adding about 20 DEBUG_INSN markers into stream for every instruction would mean that we will need 20 times more declaratoins, statements, RTL instruction, track 20 times more variable locations and we would have to do that -g or not. So if we want to have DEBUG_INSN approach, those aproaches should combine themselves well: inline substitution tracking will handle most cases chaply and DEBUG_INSN will help to keep the substitutions valid. I'm also experimenting with an implementation prototype right now that overloads the source_location in expressions. An enhanced debuglocus tracks information regarding variables similar to kind of information DEBUG_INSNs provide, but without the additional instruction overhead. It shows promise at least within the tree-ssa infrastructure, but its still a hair too early to tell if it will work as a general solution. Its a few weeks from being able to compare to the example you have here to see how coverage compares. Andrew
Re: constant propagation optimization
On Thu, Mar 05, 2009 at 11:39:45AM +, charfi asma wrote:
> intc;
> int main()
>
> {
>
> Calcul ca;
>
> c=3;
>
> ca.affich();
>
> ca.inc(c);
>
> cout << "the value of c is" << c << endl;
>
> return 0;
>
> }
[...]
> int main()
>
> {
>
> Calcul ca;
>
> ca.affich();
>
> c=3;
>
> ca.inc(c);
>
> cout << "the value of c is" << c << endl;
>
> return 0;
>
> }
>
> Why in the fist code, c is not considered as a constant (in spite that
> affich() does not change c)
Because GCC does not currently do the necessary analysis to know that
affich() does not change c; it therefore makes the conservative
assumption that it does.
-Nathan
Re: New no-undefined-overflow branch
Hi Richard,
Great to see that you're addressing this issue. If I understand
correctly,
for RTL all operations are always wrapping, right?
I have been considering adding "V" variants for operations that trap on
overflow. The main reason I have not (yet) pursued this, is the daunting
task of teaching the folders about all these new codes. initially I'd
like to lower the "V" operations to explicit checks (calling abort() or
raising an exception, depending on the language) during gimplification,
but with the idea of eventually delaying expansion as more code learns
how to handle the new expressions. I already have most of the code
necessary
for the expansions, as I now do them during translation of Ada trees to
GENERIC trees. Actually, the new and saner wrapping semantics for
{PLUS,MINUS,MULT}_EXPR simplify these a bit, by avoiding the need to use
unsigned types.
As you obviously doing something very similar now by introducing "NV"
variants,
do you think this would fit in with your scheme? If so, I'd be happy
to try
and expand on your work to have, wrapping, no-overflow and overflow-
checking
variants for basic arithmetic.
-Geert
Re: Minimum required GNAT version for bootstrap of GNAT on gcc trunk
On Tue, 2009-02-24 at 20:40 +0100, Laurent GUERBY wrote: > On Tue, 2009-02-24 at 19:36 +, Dave Korn wrote: > > Laurent GUERBY wrote: > > > On Tue, 2009-02-24 at 18:59 +, Dave Korn wrote: > > >> Laurent GUERBY wrote: > > >> > > >>> I'm not sure 3.4 will work for trunk > > >> I was just entirely unable to get 3.4.4 to bootstrap a 4.3.2 compiler. > > >> I > > >> used 4.3.0 and it worked. I forget what I used to build the 4.3.0 with > > >> in the > > >> first place. I think the documentation needs updating to say you'll > > >> need to > > >> use an early/intermediate 4.x version to bootstrap your way past the > > >> 3.x/4.x > > >> boundary, but I couldn't say exactly where the break lies. > > > > > > Was this on cygwin or Linux? > > > > Cygwin. Would that be likely to make a difference? > > Depending on the error it could make a difference. The oldest > system I have access to is Ubuntu 5.10 which I believe > came with 4.0 GCC default and optional 3.4 GCC packages (the system is > offline right now so I rely on memory, I'll confirm > when it comes back online). The old system just came back online so I checked and GCC 3.4.6 (the oldest version I have, released Mar 06 2006) is able to bootstrap c,ada for 4.3.2 release (2008-08-27) on Linux i686. So at least 3.4.x is able to build 4.3.x with Ada enabled on Linux. I will build and test ability of 3.4.0 (released Apr 18 2004) to 5 to bootstrap 4.3.x in the coming weeks. Hope this helps, Laurent
Re : constant propagation optimization
thank you for your answer
If I change affich() code (I put as an example an incrementation of an other
variable named a),
the compiler consider c as a constant (he optimize well and remove all switch
cases in inc function).
So the problem comes from the <<() calls in affich.
Is the compiler lost when he find << calls ? (cause a lot of code is generated
to affich a string )
thank you for your help.
- Message d'origine
De : Nathan Froyd
À : charfi asma
Cc : gcc@gcc.gnu.org
Envoyé le : Jeudi, 5 Mars 2009, 17h33mn 28s
Objet : Re: constant propagation optimization
On Thu, Mar 05, 2009 at 11:39:45AM +, charfi asma wrote:
> intc;
> int main()
>
> {
>
> Calcul ca;
>
> c=3;
>
> ca.affich();
>
> ca.inc(c);
>
> cout << "the value of c is" << c << endl;
>
> return 0;
>
> }
[...]
> int main()
>
> {
>
> Calcul ca;
>
> ca.affich();
>
> c=3;
>
> ca.inc(c);
>
> cout << "the value of c is" << c << endl;
>
> return 0;
>
> }
>
> Why in the fist code, c is not considered as a constant (in spite that
> affich() does not change c)
Because GCC does not currently do the necessary analysis to know that
affich() does not change c; it therefore makes the conservative
assumption that it does.
-Nathan
GCC 4.3.X libgomp
Hi, Seems that libgomp is part of GCC and not a separate project right? So i am posting this here. I have a new target for this library that I want to add. Hence I am modifying configure.tgt, source files etc and also adding some new threads stuff on the configure.ac However when I recreate the configure with autoconf either the original version 2.59 or 2.63 and it runs during the bootstrap the resulting gcc-x.x.x/target-dir/libgomp/Makefile fails. Seems like some macros are missing? (.m4 files) The aclocal sees the libtool stuff in the main gcc-x-x.x directory but things in the libgomp/Makefile.in as @AMDEP_TRUE@@am__include@ @am__qu...@./$(DEPDIR)/affinity@am__quote@ or @AMDEP_TRUE@@am__fastdepCC_FALSE@ they never get resolved during configure time. So gmake will fail with "missing separator" errors. Anybody has seen that? Do we need also automake to re-create the configure script? If yes I dont really see why automake is needed if nothing relating to it has changed and we are using identical autoconf aka 2.59. Personaly I think autoconf 2.63 is one of the most stable autoconfs after the 2.1x branch but it requires a patch for the GCC's 4.3/4.4 libtool to work correctly. GCC 4.X should upgrade to this version soon. If anybody knows whats missing for running autoconf (even 2.59 version) succesfully for libgomp (aka getting a viable Makefile) let me know. Regards,
RE: GCC at Google Summer of Code'2009
Thank you for the info, Liang! We can sync off-line about potential project submissions ... Cheers, Grigori > -Original Message- > From: lpeng [mailto:pengli...@ict.ac.cn] > Sent: Thursday, March 05, 2009 7:29 AM > To: Grigori Fursin > Cc: gcc; cwu; fangshuangde; huangyuanjie > Subject: Re: GCC at Google Summer of Code'2009 > > > -Original Message- > > From: Grigori Fursin [mailto:gfur...@gmail.com] On Behalf Of Grigori Fursin > > Sent: Thursday, February 26, 2009 6:57 PM > > To: gcc@gcc.gnu.org > > Cc: 'Basile STARYNKEVITCH'; 'Diego Novillo'; 'Taras Glek'; 'Zbigniew > > Chamski'; 'Sean Callanan'; 'Cupertino Miranda'; 'Joseph S. Myers'; 'Le-Chun > > Wu'; 'Sebastian Pop'; 'Albert Cohen'; 'Michael O'Boyle'; 'Paul H J Kelly'; > > 'Olivier Temam'; 'Chengyong Wu'; 'Ayal Zaks'; 'Bilha Mendelson'; 'Mircea > > Namolaru'; 'Erven Rohou'; 'Cosmin Oancea'; 'David Edelsohn'; 'Kenneth > > Zadeck' > > Subject: GCC at Google Summer of Code'2009 > > > > Hello All, > > > > I just saw an announcement that a new Google Summer of Code'2009 > > (http://code.google.com/soc) will be accepting project proposals > > in a week or so. My colleagues and I would like to submit a few proposals > > so wanted to ask if someone is interested in that to synchronize > > submissions. > > > > 4) Extend GCC generic function cloning to be able to create > > static binaries adaptable to different architectures at run-time. > > Cupertino Miranda has been extending this work recently and we may > > need to sync on that ... > > > > I am fine to mentor a few of them (particularly from 1-3) but would like to > > see if someone > > is interested to help with that ?.. I added these topics to the GCC GSOC > > page: > > http://gcc.gnu.org/wiki/SummerOfCode > > and would be happy if you modify it or tell me if you are interested ... > > > > Thanks, > > Grigori > Hello Grigori, > I am a master student from Institute of Computing Technology of China, > my name is Liang Peng. I heard the news of Google Summer of Code'2009 from > your email, > and I am very interested in one of your projects:"Extend GCC generic function > cloning to be > able to create static binaries adaptable to different architectures at > run-time(including > multiple ISA generation)". > To data, my primary work is porting and optimizing GCC for > embedded-oriented cpu- > loongson232 in professor Chengyong Wu's group, and I have also got a > reasonable understanding > of function cloning and ICI, looking forward to participate in the work. > > Thanks > liang peng
RE: GCC at Google Summer of Code'2009
Hi Yanjie, Glad that you would like to extend GCC ICI/MILEPOST. We should sync with Diego and Sebastian about that project since they are interested as well ... In the mean time, me and Zbigniew are preparing the final release of the ICI2 for GCC 4.4 with the collaborative Wiki to continue developments - it should be ready with the official GCC 4.4 release ... Will keep in touch, Grigori > -Original Message- > From: huangyuan...@gmail.com [mailto:huangyuan...@gmail.com] On Behalf Of > Yuanjie Huang > Sent: Thursday, March 05, 2009 10:55 AM > To: Grigori Fursin; gcc-maillist > Cc: Chengyong Wu; fangshuan...@163.com; Liang Peng > Subject: Re: GCC at Google Summer of Code'2009 > > Hi Grigori, > I'm a graduate student at the Institute Of Computing Technology > Chinese Academy Of Sciences, and I'm interested in the Summer of Code > projects you list in the gcc wiki, especially the one to extend the > ICI/MILEPOST framework to enable fine-grain tunning. As compiler is my > research area, I've read about the framework before, and now I'm > looking forward to launch a SoC project on it. > > Cheers, > Yuanjie > > > -Original Message- > > From: Grigori Fursin [mailto:gfur...@gmail.com] On Behalf Of Grigori Fursin > > Sent: Thursday, February 26, 2009 6:57 PM > > To: gcc@gcc.gnu.org > > Cc: 'Basile STARYNKEVITCH'; 'Diego Novillo'; 'Taras Glek'; 'Zbigniew > > Chamski'; 'Sean Callanan'; 'Cupertino Miranda'; 'Joseph S. Myers'; 'Le-Chun > > Wu'; 'Sebastian Pop'; 'Albert Cohen'; 'Michael O'Boyle'; 'Paul H J Kelly'; > > 'Olivier Temam'; 'Chengyong Wu'; 'Ayal Zaks'; 'Bilha Mendelson'; 'Mircea > > Namolaru'; 'Erven Rohou'; 'Cosmin Oancea'; 'David Edelsohn'; 'Kenneth > > Zadeck' > > Subject: GCC at Google Summer of Code'2009 > > > > Hello All, > > > > I just saw an announcement that a new Google Summer of Code'2009 > > (http://code.google.com/soc) will be accepting project proposals > > in a week or so. My colleagues and I would like to submit a few proposals > > so wanted to ask if someone is interested in that to synchronize > > submissions. > > > > 4) Extend GCC generic function cloning to be able to create > > static binaries adaptable to different architectures at run-time. > > Cupertino Miranda has been extending this work recently and we may > > need to sync on that ... > > > > I am fine to mentor a few of them (particularly from 1-3) but would like to > > see if someone > > is interested to help with that ?.. I added these topics to the GCC GSOC > > page: > > http://gcc.gnu.org/wiki/SummerOfCode > > and would be happy if you modify it or tell me if you are interested ... > > > > Thanks, > > Grigori > > -- > Yuanjie Huang
Re: GCC 4.3.X libgomp
Hello Takis, * Takis Psarogiannakopoulos wrote on Thu, Mar 05, 2009 at 07:28:53PM CET: > Seems that libgomp is part of GCC and not a separate project right? > So i am posting this here. > I have a new target for this library that I want to add. Hence I am > modifying configure.tgt, source files etc and also adding some new > threads stuff on the configure.ac However when I recreate the configure > with autoconf either the original version 2.59 or 2.63 and it runs > during the bootstrap the resulting gcc-x.x.x/target-dir/libgomp/Makefile > fails. > Seems like some macros are missing? (.m4 files) If you are rerunning things manually, in libgomp you need to use aclocal -I .. -I ../config autoconf automake and within the GCC tree, you currently *have* to use exactly Autoconf 2.59 and Automake 1.9.6. > Personaly I think autoconf 2.63 is one of the most stable autoconfs after > the 2.1x branch [...] I have patches to update most of the GCC tree to current autotools, but that is 4.5 material. Hope that helps. Cheers, Ralf
Re: GCC 4.3.X libgomp
On Thu, 5 Mar 2009, Ralf Wildenhues wrote: > If you are rerunning things manually, in libgomp you need to use > aclocal -I .. -I ../config > autoconf > automake Well i dont run aclocal and automake as I have not mods that are related to those tools. I guess thats causing my issue. > and within the GCC tree, you currently *have* to use exactly Autoconf > 2.59 and Automake 1.9.6. > > I have patches to update most of the GCC tree to current autotools, > but that is 4.5 material. > I have used autoconf 2.63 to the gcc-4.3.3 source tree to recreate everything and it works fine apart from the directory libgomp. Of course it requires a libtool patch which mainly requires ltsugar to ve patched with m4_define([m4_custom_append], [m4_define([$1], m4_ifdef([$1], [m4_defn([$1])[$3]])[$2])]) and some relevant changes in libtool of course. Thanks for the help, Regards,
Libgomp ANSI/IEEE POSIX 1003.1
File libgomp/config/posix95/lock.c
It implemnts recursive mutexes with the intuitive idea (in the header)
typedef struct
{
pthread_mutex_t lock;
pthread_t owner;
int count;
} omp_nest_lock_t;
However when this is implemented in config/posix95/lock.c
void
omp_unset_nest_lock (omp_nest_lock_t *lock)
{
lock->count--;
if (lock->count == 0)
{
lock->owner = (pthread_t) 0;
pthread_mutex_unlock (&lock->lock);
}
}
Now I am looking my posix stanard IEEE POSIX 1003.1 (95) and I cannt see
nowhere why a thread shouldnt have ID 0. Moreover why this ID 0 thread
should be the main thread necessarily! It usually is but this is not what
the API requires.
Is anybody happens to have a later version that advises that thread ID 0
is really a null thread? or must be the leading thread on each process?
I would be greatful if you could advise on this.
Regards,
gcc-4.3-20090305 is now available
Snapshot gcc-4.3-20090305 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090305/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 144653 You'll find: gcc-4.3-20090305.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20090305.tar.bz2 C front end and core compiler gcc-ada-4.3-20090305.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20090305.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20090305.tar.bz2 C++ front end and runtime gcc-java-4.3-20090305.tar.bz2 Java front end and runtime gcc-objc-4.3-20090305.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20090305.tar.bz2The GCC testsuite Diffs from 4.3-20090226 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.
default_function_rodata_section bug?
In varasm.c default_function_rodata_section():
section *
default_function_rodata_section (tree decl)
{
if (decl != NULL_TREE && DECL_SECTION_NAME (decl))
{
const char *name = TREE_STRING_POINTER (DECL_SECTION_NAME (decl));
if (DECL_ONE_ONLY (decl) && HAVE_COMDAT_GROUP)
{
size_t len = strlen (name) + 3;
char* rname = (char *) alloca (len);
strcpy (rname, ".rodata");
strcat (rname, name + 5);
At this point, we haven't checked to see what the prefix of name is -
for example, it could be .gnu.* or .text.*. If the former, you end up
with sections like ".rodatalinkonce.t.*" which don't match the usual
.rodata.* linker script patterns.
Should we do something smarter here?
