Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

us to write the same code over and over again. kenny On 10/31/2012 02:19 PM, Kenneth Zadeck wrote: Jakub, it is hard from all of the threads to actually distill what the real issues are here. So let me start from a clean slate and state them simply. Richi has three primary objections

Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

On 11/01/2012 09:10 AM, Richard Sandiford wrote: Kenneth Zadeck writes: I would like you to respond to at least point 1 of this email. In it there is code from the rtl level that was written twice, once for the case when the size of the mode is less than the size of a HWI and once for the

Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

kenny On 11/01/2012 09:10 AM, Richard Sandiford wrote: Kenneth Zadeck writes: I would like you to respond to at least point 1 of this email. In it there is code from the rtl level that was written twice, once for the case when the size of the mode is less than the size of a HWI and once for th

Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

On 11/04/2012 11:54 AM, Richard Biener wrote: On Thu, Nov 1, 2012 at 2:10 PM, Richard Sandiford wrote: Kenneth Zadeck writes: I would like you to respond to at least point 1 of this email. In it there is code from the rtl level that was written twice, once for the case when the size of

Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

Jakub and Richi, At this point I have decided to that i am not going to get the rest of the wide-int patches into a stable enough form for this round. The combination of still living without power at my house and some issues that i hit with the front ends has made it impossible to get this fi

a question for the c/c++ front end / standards people.

i have been trying to change the representation of INT_CSTs so that they do not carry around the limitation that they can only represent numbers as large as 2 host_wide_ints (HWI). I have chosen a variable length implementation that uses an array of HWIs that is just large enough to hold the s

Re: a question for the c/c++ front end / standards people.

On 11/05/2012 01:08 PM, Ian Lance Taylor wrote: On Mon, Nov 5, 2012 at 10:02 AM, Kenneth Zadeck wrote: The question is why is having a case label of 256 on a unsigned char switch legal? Are you asking why it is valid in the C language? Or are you asking why it is valid in GIMPLE? I guess

Re: a question for the c/c++ front end / standards people.

On 11/05/2012 03:37 PM, Joseph S. Myers wrote: On Mon, 5 Nov 2012, Kenneth Zadeck wrote: This switch to doing math within the precision causes many test cases to behave differently. However, I want to know if differently means "incorrectly" or "I have fixed problems that we ha

Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

On 11/26/2012 10:03 AM, Richard Biener wrote: On Mon, Nov 5, 2012 at 2:59 PM, Kenneth Zadeck wrote: On 11/04/2012 11:54 AM, Richard Biener wrote: On Thu, Nov 1, 2012 at 2:10 PM, Richard Sandiford wrote: Kenneth Zadeck writes: I would like you to respond to at least point 1 of this email

Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

I remind you that the purpose of these patches is to solve problems that exist in the current compiler that we have papered over for years. If someone needs wide-ints in some way that is not foreseen then they can change it. kenny On 11/26/2012 11:30 AM, Richard Biener wrote: On Mon, Nov

Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

time. kenny On 11/27/2012 05:03 AM, Richard Biener wrote: On Tue, Nov 27, 2012 at 1:06 AM, Kenneth Zadeck wrote: Richard, I spent a good part of the afternoon talking to Mike about this. He is on the c++ standards committee and is a much more seasoned c++ programmer than I am. He convinced

Re: Fwd: cselib_record_set breaks due to auto_inc_dec

if i had to guess what was going on here, and since i do not have the example or even know the platform, i am just guessing, i would say that at some earlier pass, the sub expression in the regnote and the second set in the parallel were the same expression and that someone changed the second s

Re: Fwd: cselib_record_set breaks due to auto_inc_dec

you need to talk to someone with a higher rtl rating than myself. sorry. On 12/20/2012 08:41 AM, Paulo Matos wrote: -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Kenneth Zadeck Sent: 20 December 2012 12:46 To: David Edelsohn; GCC Development

question about section 10.12

the definition of vec_duplicate in section 10.12 seems to restrictive. i have seen examples where the "small vector" is really a scalar. Should the doc be "small vector or scalar"? kenny

Re: question about section 10.12

this looks good to me. does your patch also address the vec_concat issue that marc raised? On 01/26/2013 09:59 PM, Hans-Peter Nilsson wrote: From: Kenneth Zadeck Date: Sat, 26 Jan 2013 16:19:40 +0100 the definition of vec_duplicate in section 10.12 seems to restrictive. i have seen examples

Re: Segmentation fault in df-scan.c

It is most likely that this bug is actually caused by one of the modifications that you have made to the backend. In 4.3, the rtl backend is very picky about the kinds of modifications that can be made to insns and in particular the api's that are used to modify, insert or delete insns or even w

Re: interesting case of DCE with dataflow.

Ramana Radhakrishnan wrote: > Hi , > > I've been investigating an interesting case with the following > testcase in my private port. I know this is a slightly theoretical > case but I believe one that should be handled cleanly. > > I haven't yet been able to replicate this on any other port yet whi

Re: interesting case of DCE with dataflow.

Daniel Jacobowitz wrote: > On Wed, Feb 06, 2008 at 10:59:12AM -0500, Kenneth Zadeck wrote: > >>> The final code generated appears something like the following. >>> >>> foo: >>> cmpslt $c6,$zero,$c1 >>> brz $c6,$link &g

lto

diego and honza diego asked on irc were we planning to be able to serialize out all of the combined declarations. My response we could certainly use the machinery that we currently have to do this. However, I believe that Deigo's motivation is somewhat flawed, and for that matter the plans in the

Re: lto

Jan Hubicka wrote: > Hi, > >> diego and honza >> >> diego asked on irc were we planning to be able to serialize out all of >> the combined declarations. >> My response we could certainly use the machinery that we currently have >> to do this. >> >> However, I believe that Deigo's motivation is s

Re: API for callgraph and IPA passes for whole program optimization

> > Thanks for the detailed plan. Yes, please add it to the whopr wiki. > The only aspects that are not too clear to me are what exactly do you > plan to do in mainline. > > One idea would be to do all the basic framework during stage 1 and > leave it in mainline. I would suggest doing as much

birthpoints in rtl.

I want to start a discussion about some possible changes to the RTL level of GCC. This discussion is motivated by some of the issues raised in bug 26854. We have addressed many of the issues in this bug, but the remaining issue is cost, in both time and space, for the UD and DU chains built by se

Re: birthpoints in rtl.

on community without knowledge of Reif and Lewis, but i need to check this for sure. Jeff Law wrote: > Kenneth Zadeck wrote: >> jeff, >> >> i posted this earlier today to the gcc mailing list. I was wondering >> what your feelings were on this. I know you had a hand in the

Re: birthpoints in rtl.

Andrew MacLeod wrote: > Kenneth Zadeck wrote: >> >> Birthpoints are not nearly as useful as phi-functions because the >> algorithms that use birthpoints do not generally leave the birthpoints >> in the right places when they are finished. There is a lot of value >

Re: birthpoints in rtl.

Steven Bosscher wrote: > On Thu, Feb 28, 2008 at 2:32 PM, Paolo Bonzini <[EMAIL PROTECTED]> wrote: > >> > Thanks for the quick response. As it turns out, the libcall issue will >> > soon be gone, as bonzini will be deleting them. We have finally >> > overcome that issue. >> >> Not really.

Re: Issues stopping us from removing libcall notes

Steven Bosscher wrote: > Hello, > > Every time someone brings up the idea to remove libcall notes, people > have to think really hard why GCC still has them. It seemed like a > good idea to record and collect these issues in a meta-bug. Thus, see > PR35413. Please open a new bug report (enhanceme

Re: birthpoints in rtl.

Diego Novillo wrote: > On 2/29/08 7:04 PM, Steven Bosscher wrote: > >> I am not sure what would happen if GCC would start using FUD chains. >> Is it like in SSA that every register is assigned only once? > > But this would only affect the UD chains built by the DF code. My > idea is to build the s

Re: birthpoints in rtl.

Diego Novillo wrote: > What if you treated subregs as total writes (like we do arrays) and > libcalls as clobbering points? Though I guess that may not be > sufficient. > > it is more productive to spend the cycles getting rid of the libcalls rather than figuring out the edge cases. as steven

Re: birthpoints in rtl.

Steven Bosscher wrote: > On Tue, Mar 4, 2008 at 7:58 PM, Diego Novillo <[EMAIL PROTECTED]> wrote: > >> Both PHIs and birthpoints are merely factoring devices that let you cut >> down the number of UD links. They don't need to be part of the IL, much >> like none of the DF objects are part of

Re: birthpoints in rtl.

Richard Sandiford wrote: > "Steven Bosscher" <[EMAIL PROTECTED]> writes: > >> For the location of the extra instructions, I would *not* keep them on >> the side. If you have something special going on, my motto is: "Make >> it explicit". >> > > Going back to something discussed upthread: w

Re: birthpoints in rtl.

Jan Hubicka wrote: > Hi, > >> 1) In ssa, the operands of the phis and the renaming contain >> information. The operands are paired with the cfg edges that the >> values come in on. In fud/birthpoints there is no such pairing or >> renaming. For some problems, like conditional constant, thi

Re: API for callgraph and IPA passes for whole program optimization

Jan Hubicka wrote: This looks mostly fine to me. note that i added you to pr35094 since this patch will resolve that issue. I guess that one of the questions that i would have is why not have there be a base structure for the core passmanager fields, and then a union that contains a one of the

Re: [trunk] Addition to subreg section of rtl.text.

Jeff, DJ and Richard, Richard Sandiford and I have taken on the task of trying to fully explain subregs in the gcc docs. This is an area where that traditionally has been very confusing to outsiders and even insiders who were not rtl maintainers. As the community of active developers has

Re: [trunk] Addition to subreg section of rtl.text.

Richard Sandiford wrote: Hi Joern, Thanks for the answer, Joern Rennecke <[EMAIL PROTECTED]> writes: Thanks very much for replying to this. We were starting to get worried that no one was going to reply and we would be left out in the cold. kenny 1) Is it possible to have a MODE_PARTI

Re: [trunk] Addition to subreg section of rtl.text.

Richard Sandiford wrote: Richard Sandiford <[EMAIL PROTECTED]> writes: - A MODE_PARTIAL_INT mode behaves like the corresponding MODE_INT mode. ...except that (as the docs said) an unknown number of bits read as undefined. Richard I would add two things to the section. One is to

comments do not match code.

in reorg.c:3155 there is the following code: /* If we reach a CALL which is not calling a const function or the callee pops the arguments, then give up. */ if (CALL_P (our_prev) && (! CONST_OR_PURE_CALL_P (our_prev) || GET_CODE (pat) != SET || GET_CODE (SET_SRC (pat))

Re: improving auto increment expressions detection across basic blocks.

The auto-increment code was a quick hack based on the code that existed in flow.c. I moved it to a new pass and generalized it quite a bit, but it is at its core, basicly the same local code. The right way to implement this is as a global, or at least loop by loop problem where du or ud chains gu

Re: improving auto increment expressions detection across basic blocks.

Mark Mitchell wrote: Kenneth Zadeck wrote: The majority of the new bugs were places where the rest of the compiler was just not expecting to see auto inc or dec instructions. If you want to take on doing this kind of extension, be prepared for the additional cost. Kenny, do you have any

Re: improving auto increment expressions detection across basic blocks.

Kenneth Zadeck wrote: Mark Mitchell wrote: Kenneth Zadeck wrote: The majority of the new bugs were places where the rest of the compiler was just not expecting to see auto inc or dec instructions. If you want to take on doing this kind of extension, be prepared for the additional cost

Re: No rule to make target `df-byte-scan.c' at rev. 134523

Dominique Dhumieres wrote: At revision 134523, bootstraping fails on i686-apple-darwin9 with: ... gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -

Re: IRA for GCC 4.4

Vladimir Makarov wrote: Peter Bergner wrote: On Mon, 2008-04-28 at 16:01 -0400, Vladimir Makarov wrote: Thanks, Peter. That was clever and email is very enlightening. I have analogous idea for more compact conflict matrix representation. IRA builds allocno live ranges first (they are ran

Re: Redundant malloc in structure optimization? (testsuite/gcc.dg/struct/wo_prof_global_var.c)

); p.0.3 = (struct struct.0_sub.0 *) D.2240; D.2242 = malloc (4000); p.0.4 = (struct struct.0_sub.1 *) D.2242; p = (struct str_t *) D.2215; p.1 = p.0.4; p.0 = p.0.3; -Original Message- From: Olga Golovanevsky [mailto:[EMAIL PROTECTED] Sent: 01 May 2008 13:19 To: Bingfeng Me

Re: [lto] Streaming out language-specific DECL/TYPEs

Diego Novillo wrote: In g++.dg/torture/20070621-1.C we are trying to stream out a structure that contains a TEMPLATE_DECL. This currently causes a failure in lto-function-out.c:output_tree because not only TEMPLATE_DECL is C++-specific, we can't even access its fields from lto-function-out.c. T

Re: [lto] Streaming out language-specific DECL/TYPEs

Diego Novillo wrote: On Tue, Jun 3, 2008 at 09:28, Jan Hubicka <[EMAIL PROTECTED]> wrote: Sure if it works, we should be lowering the types during gimplification so we don't need to store all this in memory... But C++ FE still use its local data later in stuff like thunks, but we will need t

Re: [lto] Streaming out language-specific DECL/TYPEs

Michael Matz wrote: Hi, On Tue, 3 Jun 2008, Diego Novillo wrote: On Tue, Jun 3, 2008 at 04:51, Richard Guenther <[EMAIL PROTECTED]> wrote: You may want to read http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00349.html Thanks. I think I will try to incorporate this in LTO so w

Re: [whopr] Design/implementation alternatives for the driver and WPA

Diego Novillo wrote: On Tue, Jun 3, 2008 at 22:26, Chris Lattner <[EMAIL PROTECTED]> wrote: and whopr here. Is LTO the mode "normal people" will use, and whopr is the mode where "people with huge clusters" will use? Will LTO/whopr support useful optimization on common multicore machines?

Re: [whopr] Design/implementation alternatives for the driver and WPA

Ian Lance Taylor wrote: Kenneth Zadeck <[EMAIL PROTECTED]> writes: I think that one thing that the gcc community should understand is that to a great extent whopr is a google thing. All of the documents are drafted by google people, in meetings that are only open to google people

Re: [whopr] Design/implementation alternatives for the driver and WPA

Ollie Wild wrote: On Wed, Jun 4, 2008 at 9:14 AM, Chris Lattner <[EMAIL PROTECTED] > wrote: 1) start with all code in memory and see how far you can get. It seems that on reasonable developer machines (e.g. 2GB memory) that we can handle C programs on the

ln -r and cherry picking.

I want to point out that the current implementation of lto is not compatible with "ln -r", and will need to be modified to support "cherry picking" the function bodies. In the current implementation, each lto section (such as what holds a function body or the streamed information from an ipa pass

Re: ln -r and cherry picking.

Arnaud Charlet wrote: I want to point out that the current implementation of lto is not compatible with "ln -r", and will need to be modified to support "cherry picking" the function bodies. I assume you mean "ld -r", right ? Arno yes, of course. Dennis Richie's curse: two letter comm

Re: ln -r and cherry picking.

Cary Coutant wrote: 2) LTO sections need to be able to find "their index" of decls and types. By "their index" I mean the index that each section used to reference the decls and types when the section was generated. Can't you just put an ELF symbol (can be an unnamed local -- could eve

Re: [lto] function to DECL associations for WPA repackaging

Richard Guenther wrote: On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild <[EMAIL PROTECTED]> wrote: Doug, Yesterday, we spoke briefly about the need to efficiently determine the DECL's required by each function. Here's a more detailed overview. During the WPA phase of WHOPR, we will be reading

Re: [lto] function to DECL associations for WPA repackaging

Daniel Berlin wrote: On Wed, Jun 11, 2008 at 9:13 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: Richard Guenther wrote: On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild <[EMAIL PROTECTED]> wrote: Doug, Yesterday, we spoke briefly about the need to efficiently determin

Re: [lto] function to DECL associations for WPA repackaging

Richard Guenther wrote: On Thu, Jun 12, 2008 at 3:53 AM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: Daniel Berlin wrote: On Wed, Jun 11, 2008 at 9:13 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: Richard Guenther wrote: On Wed, Jun 11, 2008 at 11:33 PM

Re: [lto] function to DECL associations for WPA repackaging

Diego Novillo wrote: On 2008-06-11, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: my sense is not to associate put this directly in the cgraph but to keep it as a side table that is indexed by something like the cgraph node id. The reason for leaning in this direction is that "w

Re: [lto] function to DECL associations for WPA repackaging

Diego Novillo wrote: On 2008-06-12, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: I think that if you want to cast this as we need to have a symbol table for the compiler in general then that is fine. Yes, but we only need a symbol table for globals. Temporaries and locals need

gimple type system

Diego has asked me to look into what would be needed in a gimple type system. This is an issue that has been brought to a head because now it is time to merge types for lto. There are a lot of questions that need to be answered before designing such a system and i would like to handle them o

Re: gimple type system

Richard Guenther wrote: On Fri, Jul 18, 2008 at 11:25 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: Diego has asked me to look into what would be needed in a gimple type system. This is an issue that has been brought to a head because now it is time to merge types for lto. There are

lto gimple types and debug info

I have been working on a design for gimple types. The overall plan is to gimplify the types, as we gimplify the executable code. Then we can release the front end types and recover the space. There are difficulties with this plan and most of them have to do with the generation of debug informa

Re: lto gimple types and debug info

Chris Lattner wrote: On Jul 24, 2008, at 9:26 AM, Kenneth Zadeck wrote: 3) Generate the debugging for the types late. The problem here is that we want the gimple type system to be stripped of the front end specific information, so any front end specific info that is only necessary for the

Re: lto gimple types and debug info

Arnaud Charlet wrote: In this same vein, I am very interested in using the gimple type system as a way to start moving gcc from being a C compiler that accommodates other languages to a compiler that handles different languages on an equal footing. The freedom that C and C++ "enjoy" to basically

Re: lto gimple types and debug info

Daniel Berlin wrote: On Thu, Jul 24, 2008 at 2:13 PM, Chris Lattner <[EMAIL PROTECTED]> wrote: On Jul 24, 2008, at 10:16 AM, Kenneth Zadeck wrote: I thought the whole idea of the LTO project was to keep as much language specific type information as late as possible. If you

Re: lto gimple types and debug info

Arnaud Charlet wrote: I do not know Fortran but from the description above, this is similar in Ada: you cannot freely mix different pointers, and you cannot make a pointer out of any variable, unless variables are marked 'aliased'. This semantic is already expressed today in GCC trees, so I'm not

Re: lto gimple types and debug info

Arnaud Charlet wrote: When danny and it wrote the ipa-type-escape pass, mark mitchell was all over us because we assumed that the type system had some semantic meaning. We ended up with a pass that generally finds nothing useful. I would very much like to redo that pass once we can mark a typ

Re: lto gimple types and debug info

Richard Guenther wrote: On Fri, Jul 25, 2008 at 1:47 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: Arnaud Charlet wrote: When danny and it wrote the ipa-type-escape pass, mark mitchell was all over us because we assumed that the type system had some semantic meaning. We ended u

Re: lto gimple types and debug info

Richard Guenther wrote: On Fri, Jul 25, 2008 at 7:01 AM, Chris Lattner <[EMAIL PROTECTED]> wrote: I dunno, this seems like a thing you could better figure out by trying it and seeing where the problems are than by trying to anticipate every single possible problem (not that there should be no

Re: lto gimple types and debug info

Mark Mitchell wrote: Kenneth Zadeck wrote: 1) Screw the debugging. The motivation behind this option is that not only is it easy, but the reality is that we have changed the program so much that even if we did "fix up the types" so that the matched the generated program, tha

Re: lto gimple types and debug info

Daniel Berlin wrote: On Sun, Jul 27, 2008 at 1:18 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: David Edelsohn wrote: I do not expect LTO (or WHOPR) to work on AIX -- at least not without a lot of work on wrappers around the AIX linker. However, I do not understand why enhancing

Re: lto gimple types and debug info

Daniel Berlin wrote: On Sun, Jul 27, 2008 at 3:10 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: Daniel Berlin wrote: I agree that, at least in principle, it should be possible to emit the debug info (whether the format is DWARF, Stabs, etc.) once. No, you can't. You would at l

Re: lto gimple types and debug info

Paolo Bonzini wrote: Mark Mitchell wrote: For that matter, "print sizeof(X)" should print the same value when debugging optimized code as when debugging unoptimized code, even if the compiler has optimized X away to an empty structure! I disagree. sizeof(X) in the code will return a value as

Re: [dataflow] partial register handling

Roman Zippel wrote: > Hi, > > On Thu, 10 May 2007, I wrote: > > >> I have a few problems with the m68k mulsidi3 pattern on the dataflow >> branch. >> > > To illustrate the problem here is what happens during combine: > > -(insn 7 28 8 2 ../gcc/gcc/testsuite/gcc.c-torture/execute/20001108-1.

dataflow branch merge plans.

At this point the entire branch has been reviewed by Ian Taylor. It is expected that all of the changes that he has asked for will be committed either tonight or tomorrow. Danny Berlin will do another merge with the trunk tonight and we will test that. As of last week, the dataflow branch was c

Re: Miscompilations for cris-elf on dataflow-branch

Seongbae Park (박성배, 朴成培) wrote: > This little patch: > > diff -r 9e2b1e62931a gcc/combine.c > --- a/gcc/combine.c Wed Jun 06 23:08:38 2007 + > +++ b/gcc/combine.c Mon Jun 11 05:39:25 2007 + > @@ -4237,7 +4237,7 @@ subst (rtx x, rtx from, rtx to, int in_d > > So force this insn not to match

Re: Some regressions from the dataflow merge

Richard Guenther wrote: > On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have > on x86_64 some performance regressions with Botan (a collection of > cryptographic algorithms (see > http://www.suse.de/~gcctest/c++bench/botan/)) - those are reasonably > small enough to investigate, bu

Re: Some regressions from the dataflow merge

Richard Guenther wrote: > On Tue, 12 Jun 2007, Kenneth Zadeck wrote: > > >> Richard Guenther wrote: >> >>> On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have >>> on x86_64 some performance regressions with Botan (a collection of >

Re: Some regressions from the dataflow merge

Dave Korn wrote: > On 12 June 2007 15:05, Kenneth Zadeck wrote: > > >> Richard Guenther wrote: >> >>> On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have >>> on x86_64 some performance regressions with Botan (a collection of >

Re: Some regressions from the dataflow merge

Seongbae Park (???, ???) wrote: > On 6/12/07, Richard Guenther <[EMAIL PROTECTED]> wrote: >> On Tue, 12 Jun 2007, Richard Guenther wrote: >> >> > >> > On ia64 SPEC2000 I see fma3d and applu now miscompare. >> >> On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO: >> >> /gcc/spec/sb-haydn-fdo-6

Re: Sparc bootstrap failure, dataflow related?

Kaveh R. GHAZI wrote: > I'm getting a new bootstrap failure today on sparc-sun-solaris2.10 which > I've filed under PR bootstrap/32312. GCC dies in stage1 building libgcc2, > I see that it's getting a SEGV because the variable "df" is nil. It might > be related to the dataflow merge. > > There's

Re: Blackfin eh broken with dataflow merge

Bernd Schmidt wrote: > There is a reference to current_function_uses_eh_return in dse.c, but > it's not clear to me what it's trying to achieve. Anyway, turning the > store into an unspec_volatile solves the problem. I've committed the > following. > > I will look into this. kenny

Re: Some regressions from the dataflow merge

Richard Guenther wrote: > On Tue, 12 Jun 2007, Richard Guenther wrote: > > >> On ia64 SPEC2000 I see fma3d and applu now miscompare. >> > > On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO: > > /gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o > zscal.o

RE: Some thoughts about steering committee work

> Sorry, my first reaction to latest SC announcements was to write > immediately. But I took time to think more about the situation (now > seing a discussion about "Non-Autopoiesis Maintainers" I am more > convinced in my decision). Here is my thoughts. I apologize in advance > if somebody feel

Re: [patch,committed] Make Fortran maintainers "Non-Autopoiesis Maintainers"

> On Thu, Jun 14, 2007 at 10:28:58PM -0700, Brooks Moses wrote: > > At 09:40 PM 6/14/2007, Steve Kargl wrote: > > >On Thu, Jun 14, 2007 at 08:48:22PM -0700, Brooks Moses wrote: > > >> I have no objection to this as a custom for GFortran, certainly -- I > > >> think it's a very good idea, and as a c

Re: Fixing m68hc11 reorg after dataflow merge

> On 6/16/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote: > >I need some help making m68hc11_reorg() work after the dataflow merge, in > > particular this bit: > > > > /* Re-create the REG_DEAD notes. These notes are used in the machine > > description to use the best assembly d

Re: Fixing m68hc11 reorg after dataflow merge

Rask Ingemann Lambertsen wrote: > On Sat, Jun 16, 2007 at 11:36:00PM -0400, Kenneth Zadeck wrote: > >>> Try: >>> >>> df_note_add_problem (); >>> df_analyze (); >>> -- >>> #pragma ident "Seongbae Park, compiler, http://seongbae.bl

virtual stack regs.

I would like to get some more information about pr32374. I do not know what virtual_stack_vars are and there is no documentation in the doc directory. 1) What are these? 2) Why are they uninitialized? 3) If they really are uninitialized, why is it a problem to assign zero to them. 4) If they a

Re: virtual stack regs.

Rask Ingemann Lambertsen wrote: > On Tue, Jun 19, 2007 at 11:11:54AM +0200, Uros Bizjak wrote: > >> On 6/19/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote: >> >>> It is possible to mess up the substitution that the vregs pass performs. >>> IIRC, it happened to me once because I ac

Re: m68k bootstrap problem

Roman Zippel wrote: > Hi, > > m68k currently doesn't bootstrap, which I think is dataflow related, the > whole precompiled file is at http://www.xs4all.nl/~zippel/expmed.i.gz, but > the small test below should be enough to demonstrate the problem > (although it doesn't crash): > > int fi1(int);

Re: m68k bootstrap problem

Roman Zippel wrote: > Hi, > > m68k currently doesn't bootstrap, which I think is dataflow related, the > whole precompiled file is at http://www.xs4all.nl/~zippel/expmed.i.gz, but > the small test below should be enough to demonstrate the problem > (although it doesn't crash): > > int fi1(int);

Re: m68k bootstrap problem

Roman Zippel wrote: > Hi, > > On Tue, 19 Jun 2007, Kenneth Zadeck wrote: > > > > Another question I have is about DF_REF_MAY_CLOBBER, any function call > would also clobber the return value and I see defs generated for calls, > but they are only marked with DF_REF_M

Re: m68k bootstrap problem

Roman Zippel wrote: > Hi, > > On Wed, 20 Jun 2007, Kenneth Zadeck wrote: > > >> For certain regs, the subroutine may or may not modify the value. The >> better information alluded to is information that one might get by doing >> interprocedural analysis. Wit

Re: m68k bootstrap problem

Roman Zippel wrote: > Hi, > > On Wed, 20 Jun 2007, Kenneth Zadeck wrote: > > >>> I don't understand, wouldn't the consertive approach be that the value >>> simply doesn't survive? >>> >>> >> No, the conservative is

Re: m68k bootstrap problem

Roman Zippel wrote: > Hi, > > On Wed, 20 Jun 2007, Kenneth Zadeck wrote: > > >> If we add the dead note there we are asserting that the value is >> modified by the caller. however it might not be and someone could write >> a piece of asm right after the call t

Re: m68k bootstrap problem

Paolo Bonzini wrote: > >>> having the dead note there is asserting to the register allocator that >>> they are free to use that reg after the calll in any way that it wants >>> and there is a (small) possibility that is wrong. >> >> IMO there is nothing wrong with this. > > I agree with Roman. You

Re: m68k bootstrap problem

Bernd Schmidt wrote: > Kenneth Zadeck wrote: >> Paolo Bonzini wrote: >>>>> having the dead note there is asserting to the register allocator >>>>> that >>>>> they are free to use that reg after the calll in any way that it >>>

Re: m68k bootstrap problem

Roman Zippel wrote: > Hi, > > On Wed, 20 Jun 2007, Paolo Bonzini wrote: > > >>> This is one of the places where i slavishly copied what flow did. if >>> you want to change this, go test it on at least 7 platforms and fix all >>> of the problems that it causes. >>> >> I see. Can one of yo

Re: m68k bootstrap problem

Roman Zippel wrote: > Hi, > > On Wed, 20 Jun 2007, Kenneth Zadeck wrote: > > >> If we add the dead note there we are asserting that the value is >> modified by the caller. however it might not be and someone could write >> a piece of asm right after the call t

Re: m68k bootstrap problem

Paolo Bonzini wrote: > + > + /* However a may or must clobber still still needs to > + kill the reg. */ > > Add here "so that REG_DEAD notes are later placed appropriately". Ok, > thanks! > > Paolo so is this an ok to commit with this change?

Re: m68k bootstrap problem

Roman Zippel wrote: > Hi, > > On Wed, 20 Jun 2007, I wrote: > > >> Index: gcc/df-problems.c >> === >> --- gcc/df-problems.c(revision 125811) >> +++ gcc/df-problems.c(working copy) >> @@ -1574,7 +1574,7 @@ >>/* Ca

Re: m68k bootstrap problem

Roman Zippel wrote: > Hi, > > On Fri, 22 Jun 2007, Kenneth Zadeck wrote: > > >>> Index: gcc/gcc/reg-stack.c >>> === >>> --- gcc.orig/gcc/reg-stack.c >>> +++ gcc/gcc/reg-stack.c &g

Re: LTO reader support for MEMORY_PARTITION_TAG

Mark Mitchell wrote: > Kenny -- > > I tried to get the simplest C program containing a function: > > void f() {} > > to go through LTO today, but the LTO reader says: > > ./empty-function.o:0: internal compiler error: in lto_static_init_local, > at lto-tree-flags.def:747 > > Apparently, this is b

<    1   2   3   >