Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
2010/1/26 Dave Korn: > On 25/01/2010 22:38, Dave Korn wrote: >> > On 25/01/2010 20:58, Paolo Bonzini wrote: > >>> >> Does this fix it for you? >> > >> > That succeeded for "rm -rf i686-pc-cygwin/libgomp; make >> > configure-target-libgomp all-target-libgomp". I'll leave a full bootstrap >> > running overnight > > That completed fine. I confirm. -- Cheers, /ChJ
Tree-SSA question
Hi,
I am working to knw the details of the tree-ssa pass.I had this small
piece of code as my test case:
void func()
{
int x=10;
int a=5;
if(a==x)
{
x=x+1;
}
else
{
x=x-1;
}
a=x;
}
and when i did a
> gcc -fdump-ftree-ssa -O3 foo.c
I got the following output :
func ()
{
int a;
int x;
:
x_2 = 10;
a_3 = 5;
if (a_3 == x_2)
goto ;
else
goto ;
:
x_4 = x_2 + 1;
goto ;
:
x_5 = x_2 + -1;
:
# x_1 = PHI
a_6 = x_1;
return;
}
Well..now I want to know what is the structure which this pass
maintains to emit these statements.Where can i find it (In which
source files)and can it be modified?
I chiefly want to separate the predicate of the if condition, the if
block and the else block..can it be done?
Point to me to the sources please.
Thanks In Advance
--
cheers
sandy
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
On Mon, Jan 25, 2010 at 12:58 PM, Paolo Bonzini wrote: > >> This probably is a new version of PR41418 then. We have the problem >> that >> fortran is turned on in --enable-languages, so libgomp configure expects >> the >> fortran compiler to be available. > > Does this fix it for you? > > Index: configure.ac > === > --- configure.ac (revision 155240) > +++ configure.ac (working copy) > @@ -146,7 +146,11 @@ case `echo $GFORTRAN` in > -* | no* ) > FC=no ;; > *) > - FC="$GFORTRAN" ;; > + if test -x "$GFORTRAN"; then > + FC="$GFORTRAN" > + else > + FC=no > + fi ;; > esac > AC_PROG_FC(gfortran) > FCFLAGS="$FCFLAGS -Wall" > > (untested) > > Paolo > This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42872 -- H.J.
Re: Tree-SSA question
sandeep soni writes: > Well..now I want to know what is the structure which this pass > maintains to emit these statements.Where can i find it (In which > source files)and can it be modified? It's GIMPLE, defined mainly in gimple.def, gimple.h, and gimple.c. Yes, it can be modified. > I chiefly want to separate the predicate of the if condition, the if > block and the else block..can it be done? I don't understand how you can separate this things. Given a GIMPLE_COND statement, you can certainly look at the condition and the two goto statements. You may want to look at tree-ssa-ifcombine.c. Ian
Re: Help-The possible places where insn is splitted in greg pass
2010/1/25 Ulrich Weigand : > Qifei Fan wrote: > >> > But insn#479 is not recognized by recog() in insn-recog.c and the >> > compilation failed. (recog only recognizes RTL defined in md, right?) >> > Here the backtrace is >> > reload--->cleanup_subreg_operands--->extract_insn_cached--->extract_insn-= >> -->recog_memoized--->recog. >> > There is no machine instruction(r3=3Dr1*4+r2) match the pattern of >> > insn#479. Though there is pattern r3=3Dmem(r1*4+r2). >> > I don=92t quite understand the generation of reload information. > > There's two issues here. The first issue is that reload makes the > fundamental assumption that everything that is a valid address, can > be loaded into a register as well, if necessary. On many platforms > this is true, either because there is some sort of "load address" > instruction, or because the form of valid addresses matches standard > arithmetic instruction patterns. Reload will simply emit a naked > "set" of some register to the address -- if the back-end doesn't > support that, you'll get the failure you saw. > > If this doesn't work on your particular platform, you could either > try to set things up so that reload never thinks it needs to reload > an address (but this may be difficult to achieve). The safe option > would be to tell reload how to achieve computing an address by > providing a "secondary reload" pattern. See e.g. s390_secondary_reload > (in config/s390/s390.c) and the associated "reload_plus" pattern. > > The second issue is as you notice here: > >> Actually the second reload is not needed if there is already the first relo= >> ad. >> If (plus:SI (reg/f:SI 16 SP) (const_int 96 [0x60]) is replaced by >> (reg:SI 12 a12), then (plus:SI (mult:SI (reg:SI 9 a9 [204]) >> (const_int 4 [0x4])) (reg:SI 12 a12) ) is a valid memory address. >> But in function find_reloads, I can=92t find the related code that >> deciding whether the second reload should be generated by regarding >> the previous reload. The function is too complex. :-( > > The first reload, loading sp + 96 into a register, is generated from > within find_reloads_address. After this is done, it is assumed that > the address is now valid. > > However, something else later in find_reloads apparently assumes there > is still some problem with the operand, and decides to reload the > whole address. It is hard to say exactly what the problem is, without > seeing the insn constraints, but the most likely cause seems to be that > this instruction pattern does not have a general "m" constraint, but > a more restricted memory constraint. > > If this is the case, the back-end procedure called to verify the > constraint probably rejects it. This runs into another fundamental > assumption reload makes: it assumes such procedures take other > actions done by reload into account implicitly. This means the > constraint checker ought to *accept* addresses of the form > reg*const + (sp + const) > because it ought to know that reload will already load the (sp + const) > into a register anyway. > > If this is *not* the case, please send me the instruction pattern > and constraints for the insn pattern that matched insn 320 before > reload so I can investigate in more detail. > > (Please note that I'm currently travelling with restricted access > to email, so it might be a couple of days before I'm able to reply; > sorry ...) > > Bye, > Ulrich > > -- > Dr. Ulrich Weigand > GNU Toolchain for Linux on System z and Cell BE > ulrich.weig...@de.ibm.com > For the second issue, there is indeed a strict constraint(back-end procedure) that rejects the pattern. The back-end procedure is composed of macros like EXTRA_MEMORY_CONSTRAINT/EXTRA_CONSTRAINT. These macros are defined in config/cpu.c and used in around Line3376 of reload.c(gcc4.3.2). So it's the constraint checker's job to know whether reload will load the (sp+const) into a register and use such information to decide whether to accept the pattern or not, right? Is there any other architecture which checks address by using previous determined reload info? I think this may be the proper way to resolve this problem. It may be easy to implement too. I will dig into all the issues and possible options, and provide more information later. As I am not familiar with it, it may take some time. Thanks very much!! -Qifei Fan
gccgo language contribution accepted
I am pleased to announce that the GCC Steering Committee has accepted the contribution of the gccgo front-end and gcc-specific runtime for the Go language with Ian Taylor appointed maintainer. The GCC Release Managers will decide the details about the timing of the merge and inclusion in GCC 4.5 or later. Please join me in congratulating and thanking Ian and the Go language developers. Please update your listing in the MAINTAINERS file. Happy hacking! David
Re: gccgo language contribution accepted
David Edelsohn writes: > Please join me in congratulating and thanking Ian and the Go > language developers. Please update your listing in the MAINTAINERS file. Done as follows. Thanks. Ian 2010-01-26 Ian Lance Taylor * MAINTAINERS: Add myself as Go frontend maintainer. Index: MAINTAINERS === --- MAINTAINERS (revision 156259) +++ MAINTAINERS (working copy) @@ -136,6 +136,7 @@ Fortran Paul Brook p...@codesourcery. c++ Jason Merrill ja...@redhat.com c++ Mark Mitchell m...@codesourcery.com c++ Nathan Sidwell nat...@codesourcery.com +go Ian Lance Taylor i...@airs.com java Per Bothner p...@bothner.com java Andrew Haley a...@redhat.com java Tom Tromey tro...@redhat.com
Re: can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
On 01/26/2010 08:57 AM, Paolo Bonzini wrote: On 01/25/2010 11:38 PM, Dave Korn wrote: On 25/01/2010 20:58, Paolo Bonzini wrote: This probably is a new version of PR41418 then. We have the problem that fortran is turned on in --enable-languages, so libgomp configure expects the fortran compiler to be available. Does this fix it for you? That succeeded for "rm -rf i686-pc-cygwin/libgomp; make configure-target-libgomp all-target-libgomp". I'll leave a full bootstrap running overnight but it looks sound to me. Committed, I think we can revert Joern's second patch, I'll check in the next 1-2 days. In the meanwhile, this needs to be committed to fix failures in libgomp.fortran: 2010-01-26 Paolo Bonzini * configure.ac: Test for executability of _the first word_ of GFORTRAN. * configure: Regenerate. Index: configure.ac === --- configure.ac(revision 156244) +++ configure.ac(working copy) @@ -146,7 +146,8 @@ case `echo $GFORTRAN` in -* | no* ) FC=no ;; *) -if test -x "$GFORTRAN"; then +set dummy $GFORTRAN; ac_word=$2 +if test -x "$ac_word"; then FC="$GFORTRAN" else FC=no Paolo
Re: gccgo language contribution accepted
On Tue, Jan 26, 2010 at 8:13 PM, David Edelsohn wrote: > I am pleased to announce that the GCC Steering Committee has > accepted the contribution of the gccgo front-end and gcc-specific runtime > for the Go language with Ian Taylor appointed maintainer. The GCC > Release Managers will decide the details about the timing of the merge and > inclusion in GCC 4.5 or later. > > Please join me in congratulating and thanking Ian and the Go > language developers. Please update your listing in the MAINTAINERS file. What is the status of Go as far as building by default and release criteria are concerned (I'm worried that we accept a relatively new non-standardized language frontend)? Will the frontend inclusion need to be reviewed like new backeds do? I hope the frontend plays well with its integration with the middle-end and isn't a maintainance burden. (who uses Go anyway?) Richard. > Happy hacking! > David > >
Re: gccgo language contribution accepted
Richard Guenther writes: > What is the status of Go as far as building by default and release criteria > are concerned (I'm worried that we accept a relatively new non-standardized > language frontend)? Go does not and should not build by default. It builds with --enable-languages=go. > Will the frontend inclusion need to be reviewed like new backeds do? > I hope the frontend plays well with its integration with the middle-end and > isn't a maintainance burden. Yes, the frontend should ideally be reviewed. > (who uses Go anyway?) It's an experimental language. I'm not personally proposing Go for 4.5, as it has some middle-end patches which would add new features (basically, -fsplit-stack) and would need review. Ian
gcc-4.4-20100126 is now available
Snapshot gcc-4.4-20100126 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100126/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 156264 You'll find: gcc-4.4-20100126.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20100126.tar.bz2 C front end and core compiler gcc-ada-4.4-20100126.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20100126.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20100126.tar.bz2 C++ front end and runtime gcc-java-4.4-20100126.tar.bz2 Java front end and runtime gcc-objc-4.4-20100126.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20100126.tar.bz2The GCC testsuite Diffs from 4.4-20100119 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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.
Questions about compute_transpout in gcse.c code hoisting implementation
Hello Jeff and other interested readers :-)
There is a function compute_transpout() in gcse.c and there are a
couple of things about this functions that I don't understand exactly.
First, there is this comment before the function says:
"An expression is transparent to an edge unless it is killed by
the edge itself. This can only happen with abnormal control flow,
when the edge is traversed through a call. This happens with
non-local labels and exceptions. "
What does this mean, exactly? The implementation of the function
simply kills all expressions that are MEM_P if a basic block ends with
a CALL_INSN (with a wrong comment about something flow did in the gcc
dark ages, say 15 years ago). But I don't see how compute_transpout
handles non-local labels. And what about non-call exceptions?
Second, it looks like gcc says that an expression can be in VBEOUT,
but can not be hoisted. In hoist_code this is expressed like so:
if (TEST_BIT (hoist_vbeout[bb->index], i)
&& TEST_BIT (transpout[bb->index], i))
{
/* We've found a potentially hoistable expression, now
we look at every block BB dominates to see if it
computes the expression. */
Why does the code hoisting pass not do the same as the LCM-PRE pass:
Eliminate expressions it cannot handle early on? In this case,
wouldn't it be easier (better?) to eliminate expressions that are not
TRANSPOUT from VBEOUT in compute_vbeinout? Would it be OK if I teach
compute_vbeinout to eliminate expressions that may trap from VEBOUT,
if there are exception edges to successor blocks? This is similar to
what LCM-PRE does in compute_pre_data (well, more or less, sort-of,
etc.).
Hope you can help me understand this code better,
Ciao!
Steven
Re: gccgo language contribution accepted
On Tue, 26 Jan 2010, David Edelsohn wrote: > I am pleased to announce that the GCC Steering Committee has > accepted the contribution of the gccgo front-end and gcc-specific runtime > for the Go language with Ian Taylor appointed maintainer. The GCC What has been decided about copyright assignment requirements? -- Joseph S. Myers jos...@codesourcery.com
