gcc-4.1-20070903 is now available

Snapshot gcc-4.1-20070903 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070903/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: RFC: Hack to make restrict more useful

On 9/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > On 9/3/07, Richard Guenther <[EMAIL PROTECTED]> wrote: > > On 9/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > > > On 9/2/07, Paul Brook <[EMAIL PROTECTED]> wrote: > > > > > > That said, second, my understanding of restrict, from reading the

Re: RFC: Hack to make restrict more useful

On 9/3/07, Richard Guenther <[EMAIL PROTECTED]> wrote: > On 9/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > > On 9/2/07, Paul Brook <[EMAIL PROTECTED]> wrote: > > > > > That said, second, my understanding of restrict, from reading the c99 > > > > > standard, is that it is perfectly valid for res

Re: RFC: Hack to make restrict more useful

Mark Mitchell wrote: > Joseph S. Myers wrote: > >> The rules that unmodified memory may alias were a deliberate change in the >> FDIS relative to the previous public draft; see >> : > > That explains why I had no memory of this, despite

Re: RFC: Hack to make restrict more useful

> In any case, I guess we should consider my patch withdrawn. Although, > if the new meaning of "restrict" matches standard Fortran semantics, > then our Fortran handling must be wrong, since all my patch did was make > us match our current Fortran semantics. In Fortran the pointers are not expos

Re: RFC: Hack to make restrict more useful

Joseph S. Myers wrote: > The rules that unmodified memory may alias were a deliberate change in the > FDIS relative to the previous public draft; see > : That explains why I had no memory of this, despite having researched "restrict" pre

About allocating registers for instrumentation

Hi, I am working on gcc-4.1.1 and Itanium architecture. Current now I have finished instrumenting ld and st instructions before the second scheduling pass by reserving two global registers at backend. However, in order to enhance the performance (e.g. make the scheduling better), I choose to alloca

has_volatile_ops and early optimization w/o alias information

We set has_volatile_ops on all(?) memory references during early optimization because we don't have alias information. But we do it inconsistently for loads. For example I see D.2574_23 = *D.2573_22; (no volatile) and D.2565_28 ={v} tab[D.2560_27].__delta; (volatile). Because for indire

Re: question about rtl loop-iv analysis

Zdenek's patch here - http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02291.html - solved the problem. Kenny, Zdenek - many thanks for solving this issue! dorit > "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]> wrote on > 29/08/2007 01:01:42: > > > On 8/28/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:

Re: DFA Scheduler - unable to pipeline loads

Matt Lee wrote: Hi, I am working with GCC-4.1.1 on a simple 5-pipe stage simple scalar RISC processors with the following description for loads and stores, (define_insn_reservation "integer" 1 (eq_attr "type" "branch,jump,call,arith,darith,icmp,nop") "issue,iu,wb") (define_insn_reservation

Re: RFC: Hack to make restrict more useful

On Sun, 2 Sep 2007, Mark Mitchell wrote: > Daniel Berlin wrote: > > > Again, I'd love to just ignore this and say "we don't care". > > Ugh. I think you're right that the standard says that we only get to > assume non-aliasing when the pointed-to memory is modified, so > all-parameters-restrict

RE: DFA Scheduler - unable to pipeline loads

Matt, I just started working on pipeline description and I'm confused one thing in your description. For "integer", your cpu have a 1-cycle latency, but with 3 units stages "issue,iu,wb". What does that mean? My understanding is that the number of units seperated by "," should be equal to late

Re: RFC: Hack to make restrict more useful

On 9/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > On 9/2/07, Paul Brook <[EMAIL PROTECTED]> wrote: > > > > That said, second, my understanding of restrict, from reading the c99 > > > > standard, is that it is perfectly valid for restrict pointers to alias > > > > each other during *loads*.. IE