Build report for gcc 4.1.1 on powerpc-apple-darwin8.7.0
powerpc-apple-darwin8.7.0 /usr/local/bin/gcc -v Using built-in specs. Target: powerpc-apple-darwin8.7.0 Configured with: ../gcc-4.1.1/configure --disable-multilib Thread model: posix gcc version 4.1.1 Languages: default (c, c++, java, obj-c)
Re: Explicit field layout
Duncan Sands wrote: I am writing a new GCC front end. One of the features provided by my language (CIL) is explicit field layout and size for records. I don't know if any other languaje supported by GCC provides this feature. If that's the case, please point me to it so that I can see how to do it. Ada provides this. See for example section 13.5 of the reference manual (http://www.adaic.com/standards/index.html). Thanks, this is precisely what I need. Ada seems to provide the same features (actually, a superset of what CIL provides). Best regards, Ricardo.
Re: Explicit field layout
Bernd Jendrissek wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Sep 22, 2006 at 02:58:26PM +0200, Ricardo FERNANDEZ PASCUAL wrote: I am writing a new GCC front end. One of the features provided by my language (CIL) is explicit field layout and size for records. Any pointers would be greatly appreciated. Are you sure you want to do that, instead of using, say, rpcgen? I am sorry, but I fail to see the relation of this with rpcgen (which as far I know is a code generator for the RPC protocol). Am I looking at the wrong rpcgen? Best regards, Ricardo.
t-target file GCC 4.1.1 port
Hai everyone, I am trying to port GCC 4.1.1 for my target. My target doesn't support float variables. It does'nt have the hardware to support or recongnize float formats. With this in mind do i need to add Floating point emulation support in t-target file by providing # We want fine grained libraries, so use the new code # to build the floating point emulation libraries. FPBIT = fp-bit.c DPBIT = dp-bit.c fp-bit.c: $(srcdir)/config/fp-bit.c echo ’#define FLOAT’ > fp-bit.c cat $(srcdir)/config/fp-bit.c >> fp-bit.c dp-bit.c: $(srcdir)/config/fp-bit.c cat $(srcdir)/config/fp-bit.c > dp-bit.c Can someone help me? Regards, Shafi.
RE: t-target file GCC 4.1.1 port
On 25 September 2006 12:29, Mohamed Shafi wrote: > I am trying to port GCC 4.1.1 for my target. > My target doesn't support float variables. > It does'nt have the hardware to support or recongnize float formats. > With this in mind do i need to add Floating point emulation support in > t-target file by providing Yes. cheers, DaveK -- Can't think of a witty .sigline today
Re: Missing elements in VECTOR_CST
On Mon, 18 Sep 2006, Mark Mitchell wrote:
> Andrew Pinski wrote:
> > The documention on VECTOR_CST is not clear if we can have missing
> > elements in that the remaining elements are zero. Right we produce such
> > VECTOR_CST for things like:
> > #define vector __attribute__((vector_size(16) ))
> > vector int a = {1, 2};
> >
> > But is that valid? We currently produce a VECTOR_CST with just two
> > elements instead of 4. Should we always have the same number of
> > elements in a VECTOR_CST as there are elements in the vector type?
>
> I think it is reasonable for front-ends to elide initializers and to
> follow the usual C semantics that elided initializers are (a) zero, if
> the constant is appearing as an initializer for static storage, or (b)
> unspecified, "random" values elsewhere.
Maybe you didn't mean what I read, but it's not just "for static
storage". By my reading (of the May 6, 2005 ISO/IEC 9899:TC2
for reference), all items in arrays and named structure members
not mentioned in the initializer should be 0-initialized (the
"all subobjects that are not initialized explicitly shall be
initialized implicitly the same as objects that have static
storage duration" part in 6.7.8:19).
brgds, H-P
Where does tree-ssa.c read the variable names for -Wuninitialized messages?
Hi,
I'm trying to understand PR 13615, where a used-uninitialized Fortran
character string induces the following diagnostic:
'c[1]{lb: 1 sz: 1}t.f: In function 'warn_character':
t.f:33: warning: ' is used uninitialized in this function
I see that this error message is emitted from tree-ssa.c, but I'm not
skilled enough in middle-end magic to understand whether the fault is
on the front-end not setting something correctly, or the middle-end
not understanding what this variable is. I hope someone here could,
without too much trouble, help me.
Thanks,
FX
Re: Where does tree-ssa.c read the variable names for -Wuninitialized messages?
François-Xavier Coudert wrote on 09/25/06 08:35:
> Hi,
>
> I'm trying to understand PR 13615, where a used-uninitialized Fortran
> character string induces the following diagnostic:
>
> 'c[1]{lb: 1 sz: 1}t.f: In function 'warn_character':
> t.f:33: warning: ' is used uninitialized in this function
>
> I see that this error message is emitted from tree-ssa.c, but I'm not
> skilled enough in middle-end magic to understand whether the fault is
> on the front-end not setting something correctly, or the middle-end
> not understanding what this variable is. I hope someone here could,
> without too much trouble, help me.
>
The analysis is done over SSA names. The variable name is taken from
SSA_NAME_VAR, which is a _DECL that had been gathered during the initial
into SSA phase (find_referenced_vars and rewrite_into_ssa).
I'd say the FE is not setting the name properly into whatever _DECL we
found.
Set a breakpoint at the end of tree-ssa.c:warn_uninit to examine the
_DECL node.
Re: IPA branch
> Jan -- > > I'm trying to plan for GCC 4.3 Stage 1. The IPA branch project is > clearly a good thing, and you've been working on it for a long time, so > I'd really like to get it into GCC 4.3. However, I'm a little > concerned, in reading the project description, that it's not all that > far along. I'm hoping that I'm just not reading the description well, > and that you can explain things in a way that makes it obvious to me > that the work is actually almost done. > > The Wiki page says "first part of patches was already sent", but I can't > tell how much that is, or how many of the "modifications required" steps > are already done. Have you completed all the work on the IPA branch > itself, so that it's just a problem of merging? How much of the merging > have you actually done? What version of mainline corresponds to the > root of the IPA branch? Have maintainers with appropriate write > privileges reviewed the patches? Mark, I intended to write the overview in a way to express that some work will be needed. In general IPA branch infrastructure is done (and was done for last version too, I just was traveling and doing scientific work during almost whole stage 1) and the branch was synchronized with mainline two weeks ago. It was also used for building SPEC/c++ benchmarks on IA-64/x86 and by Haifa people on PPC so it received some testing. There is some bitrot from long merging and little SVN problem I got shortly after summit, but I plan to clean this up while reviewing the whole diff next week. I think that rest of work needs to be done on-the-fly while merging as there are involved interfaces that are touching plans of multiple people The patch I am referring to is http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00567.html that is by far the most noisy patch from the planned series. I am planning to merge the branch incrementally (same way as I did for all my past work) - first localizing the variables, then adding infrastructure for holding multiple SSA forms, teaching inliner to handle both SSA and non-SSA and finally switch to it. Then the optimizations from Haifa folks and my inliner changes can go in independently. I was trying to take care to keep the things organized in a way so the merge should be relatively safe ie if we stop in middle - I hope we won´t, we won´t end up with too much dead code or compiler ready for complete revert) The non-SSA path needs to be preserved for -O0 compilation and the inliner simply handles the SSA datastructures as additional IL feature rather than having two different implementations of same thing. What I am most concerned about is the second step as there are some datastructure changes (in particular the annotations on variables needs to be partly privatized as they are shared across multiple functions for static variables). IPA branch does it in a somewhat kludgy way I discussed with rth and Diego on the summit. (I simply keep the annotations around for static variables for duration of whole compilation but most of data are reset when new function is being compiled, that is bit nonsential memory-wise) While we don't have much better answer (other posibility discussed with rth is simply bring all annotations to on-side hashtable and modify the single accestor function, that is cleaner in design but more exensive way to get into same place). It is probably desirable to move away from annotations, so I would like to have some time in stage1 to simply drop off as much as possible making my kludge smaller. So the plan would be to do incremental changes to move the pass local data present in annotations (actually almost everything except for pointer analysis information) into on-the-side datastructures that is now hopefully official plan to reduce memory usage too. The inliner changes/passmanager changes should be all pretty much fine - only problems I hit there is that inliner occasionally needs fixing because it does more constant propagation than mainline (instead of const declared variables, I do all direct uses of SSA name of incomming parameter) and the constant propagation in inliner is a bit broken, but most of fixes was pushed upstream and I didn't seen any for a longer while. There was other issues with SSA updating across EH edges, but we resolved it on the summit with rth. There was no reviews from maintainers so far (I hoped to get ones while possibly merging the stuff to LTO branch), but I hope it will go fluently ;)) I also organized my plans so I will be in Prague from day after tomorrow to November and should have time for stage1 work. Honza > > I'm not in any way trying to send a negative signal about this work. I > have every hope that it will be merged soon. I just want to better > understand the situation. > > Thanks, > > -- > Mark Mitchell > CodeSourcery > [EMAIL PROTECTED] > (650) 331-3385 x713
Re: Where does tree-ssa.c read the variable names for -Wuninitialized messages?
I'd say the FE is not setting the name properly into whatever _DECL we found. unit size align 8 symtab 0 alias set 4 precision 8 min max pointer_to_this > used unsigned QI file pr13615.f line 7 size unit size align 8 context > I'll try to understand why this $1 behaves so badly in the error message, and why it is set that way in the first place. FX
Re: t-target file GCC 4.1.1 port
From: Mohamed Shafi <[EMAIL PROTECTED]> Subject: t-target file GCC 4.1.1 port Date: Mon, 25 Sep 2006 04:29:04 -0700 (PDT) > Hai everyone, > > I am trying to port GCC 4.1.1 for my target. > My target doesn't support float variables. > It does'nt have the hardware to support or recongnize float formats. > > With this in mind do i need to add Floating point emulation support in > t-target file by > providing > > # We want fine grained libraries, so use the new code > # to build the floating point emulation libraries. > FPBIT = fp-bit.c > DPBIT = dp-bit.c > > fp-bit.c: $(srcdir)/config/fp-bit.c > echo ’#define FLOAT’ > fp-bit.c > cat $(srcdir)/config/fp-bit.c >> fp-bit.c > > dp-bit.c: $(srcdir)/config/fp-bit.c > cat $(srcdir)/config/fp-bit.c > dp-bit.c > > > Can someone help me? > > Regards, > Shafi. > > It seemed that your answer lies in newlib. I tried them on ARM7TDMI, and some of them works. Good luck Regards Wang Hao
preprocessing question
Can anyone set me strait on why, in the following code fragment
int x(unsigned);
struct alt_x {
unsigned val;
};
#define xalt_x
#define alt_x(p) x(p+1)
int test(struct x *p) {
return x(p->val);
}
the function invoked in test() is alt_x (rather than x)? I would have
expected that the preprocessor
- finds that x is an object like macro, and replaces it with alt_x
- finds that alt_x is a function-like macro and replaces it with x(...)
- finds that again x is an object like macro, but recognizes that it
already participated in expansion, so doesn't replace x by alt_x a
second time.
Our compiler team also considers this misbehavior, but since I
tested three other compilers, and they all behave the same, I
continue to wonder if I'm mis-reading something in the standard.
Thanks a lot, Jan
Re: preprocessing question
One explanation could be:
- Original Message -
From: "Jan Beulich" <[EMAIL PROTECTED]>
To:
Sent: Monday, September 25, 2006 11:23 AM
Subject: preprocessing question
Can anyone set me strait on why, in the following code fragment
int x(unsigned);
struct alt_x {
unsigned val;
};
#define xalt_x
#define alt_x(p) x(p+1)
since "x" is already defined as a object-like macro, "x" is replaced by
"alt_x", so this essentially is: #define alt_x(p) alt_x(p+1)
Since C99 (6.10.3.9) describes:
... defines an object-like macro that causes each subsequent instance of the
macro name to be replaced by the replacement list of preprocessing tokens
that constitute the remainder of the directive.
Since the "x" in the replacement list of "alt_x" macro definition is a
"subsequent instance of the macro name", so it is replaced by "x"'s
replaement list, which is "alt_x".
int test(struct x *p) {
return x(p->val);
}
the function invoked in test() is alt_x (rather than x)? I would have
expected that the preprocessor
- finds that x is an object like macro, and replaces it with alt_x
- finds that alt_x is a function-like macro and replaces it with x(...)
- finds that again x is an object like macro, but recognizes that it
already participated in expansion, so doesn't replace x by alt_x a
second time.
Our compiler team also considers this misbehavior, but since I
tested three other compilers, and they all behave the same, I
continue to wonder if I'm mis-reading something in the standard.
Thanks a lot, Jan
Re: preprocessing question
"Michael Gong" <[EMAIL PROTECTED]> writes:
> One explanation could be:
>
> - Original Message -
> From: "Jan Beulich" <[EMAIL PROTECTED]>
> To:
> Sent: Monday, September 25, 2006 11:23 AM
> Subject: preprocessing question
>
>
>> Can anyone set me strait on why, in the following code fragment
>>
>> int x(unsigned);
>>
>> struct alt_x {
>> unsigned val;
>> };
>>
>> #define xalt_x
>> #define alt_x(p) x(p+1)
>
> since "x" is already defined as a object-like macro, "x" is replaced by
> "alt_x", so this essentially is: #define alt_x(p) alt_x(p+1)
>
> Since C99 (6.10.3.9) describes:
> ... defines an object-like macro that causes each subsequent instance of
> the macro name to be replaced by the replacement list of preprocessing
> tokens that constitute the remainder of the directive.
Macro expansion does not operate on preprocessing directives unless noted
otherwise.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: preprocessing question
The output with cpp 4.0.3:
int test(struct alt_x *p) {
return alt_x(p->val+1);
}
It seems that:
1) "x" expands to alt_x
2) "alt_x(p->val)" expands to "x(p->val+1)"
3) "x" expands (again!) to alt_x
or maybe something else?
Re: preprocessing question
Yes. You are right.
- Original Message -
From: "Andreas Schwab" <[EMAIL PROTECTED]>
To: "Michael Gong" <[EMAIL PROTECTED]>
Cc: "Jan Beulich" <[EMAIL PROTECTED]>;
Sent: Monday, September 25, 2006 12:08 PM
Subject: Re: preprocessing question
"Michael Gong" <[EMAIL PROTECTED]> writes:
One explanation could be:
- Original Message -
From: "Jan Beulich" <[EMAIL PROTECTED]>
To:
Sent: Monday, September 25, 2006 11:23 AM
Subject: preprocessing question
Can anyone set me strait on why, in the following code fragment
int x(unsigned);
struct alt_x {
unsigned val;
};
#define xalt_x
#define alt_x(p) x(p+1)
since "x" is already defined as a object-like macro, "x" is replaced by
"alt_x", so this essentially is: #define alt_x(p) alt_x(p+1)
Since C99 (6.10.3.9) describes:
... defines an object-like macro that causes each subsequent instance of
the macro name to be replaced by the replacement list of preprocessing
tokens that constitute the remainder of the directive.
Macro expansion does not operate on preprocessing directives unless noted
otherwise.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: preprocessing question
On Mon, Sep 25, 2006 at 05:23:34PM +0200, Jan Beulich wrote:
> Can anyone set me strait on why, in the following code fragment
>
> int x(unsigned);
>
> struct alt_x {
> unsigned val;
> };
>
> #define xalt_x
> #define alt_x(p) x(p+1)
>
> int test(struct x *p) {
> return x(p->val);
> }
>
> the function invoked in test() is alt_x (rather than x)? I would have
> expected that the preprocessor
> - finds that x is an object like macro, and replaces it with alt_x
> - finds that alt_x is a function-like macro and replaces it with x(...)
> - finds that again x is an object like macro, but recognizes that it
> already participated in expansion, so doesn't replace x by alt_x a
> second time.
Why do you think that x has already participated in expansion? It
hasn't paricipated in the expansion of the function-like macro
alt_x, which is what is being considered, if I'm reading c99 right,
because no nested replacement of x occurred within the processing
of alt_x(). It's a different scan.
--
Daniel Jacobowitz
CodeSourcery
Re: preprocessing question
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> On Mon, Sep 25, 2006 at 05:23:34PM +0200, Jan Beulich wrote:
>> Can anyone set me strait on why, in the following code fragment
>>
>> int x(unsigned);
>>
>> struct alt_x {
>> unsigned val;
>> };
>>
>> #define xalt_x
>> #define alt_x(p) x(p+1)
>>
>> int test(struct x *p) {
>> return x(p->val);
>> }
>>
>> the function invoked in test() is alt_x (rather than x)? I would have
>> expected that the preprocessor
>> - finds that x is an object like macro, and replaces it with alt_x
>> - finds that alt_x is a function-like macro and replaces it with x(...)
>> - finds that again x is an object like macro, but recognizes that it
>> already participated in expansion, so doesn't replace x by alt_x a
>> second time.
>
> Why do you think that x has already participated in expansion? It
> hasn't paricipated in the expansion of the function-like macro
> alt_x, which is what is being considered, if I'm reading c99 right,
> because no nested replacement of x occurred within the processing
> of alt_x(). It's a different scan.
>From my reading of 6.10.3.4#1:
After all parameters in the replacement list have been substituted and #
and ## processing has taken place, all placemarker preprocessing tokens
are removed. Then, the resulting preprocessing token sequence is
rescanned, along with all subsequent preprocessing tokens of the source
^^
file, for more macro names to replace.
the rescanning of the expansion of x is still in progress when alt_x is
expanded. Unfortunately, the examples at the end of 6.10.3 do not contain
any of this kind.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: mprec.c:104: error: static declaration of 'calloc' follows non-static declaration
> "ChJ" == Christian Joensson <[EMAIL PROTECTED]> writes: ChJ> again, on cygwin/winxp, I get an error ChJ> ../../../../../../gcc/libjava/classpath/native/fdlibm/mprec.c:104: ChJ> error: static declaration of 'calloc' follows non-static declaration ChJ> am I doing something seriously wrong here? Nope, there was a build bug on cygwin. I've checked in a fix. It also fixes the other error you were seeing. Tom
Call for 4.3 project reviewers
Hello, in accordance with http://gcc.gnu.org/ml/gcc/2006-09/msg00454.html, I am looking for reviewers for my 4.3 projects. I would like to get someone "responsible" for reviewing each project soon, so that I may discuss the changes he considers necessary with him. For each project, the list of touched areas of compiler together with estimates of the extent of the changes is provided (not all the changes necessarily have to be merged as part of the project, some of them qualify as bugfixes or independent improvements). Code for predictive commoning is available on predcom branch. Regarding the remaining three projects, at the moment I have them only available locally; I plan to put them on branch soon (I must first decide whether I want to create a separate branch for each of them, or just one common): stage 1: predictive commoning (http://gcc.gnu.org/wiki/PredictiveCommoning): The predictive commoning pass itself (2.5kloc). Significant changes to loop manipulation (unrolling, updating of frequencies). Uses affine expressions framework (http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00345.html). Changes to dependence analysis (more correct handling of aliasing). 6.5kloc diff in total. stage 2: autoparallelization (http://gcc.gnu.org/wiki/AutomaticParallelization): In addition the the autoparallelization pass (1.5kloc), minor changes to gomp framework. 2kloc diff in total. prefetching improvements (http://gcc.gnu.org/wiki/PrefetchingImprovements): In addition to the changes to prefetching (tree-ssa-loop-prefetch.c): New cross-loop reuse analysis pass (2.5kloc). Significant changes to # of iterations estimation. Minor changes to rtl expansion (expr.c, optabs, ...) to enable generation of non-temporal store instructions. Minor changes to loop manipulation functions. Some cleanups to tree-data-ref.c (to enable sharing of code with reuse analysis). 6.5kloc diff in total. preserving loop structures during optimizations (http://gcc.gnu.org/wiki/PreservingLoops): Major changes to jump threading infrastructure (tree-ssa-threadupdate.c) and optimizers using it (dom, vrp), and loop structure updating functions (cfgloop*.c). Minor changes to many tree-ssa optimizers, and pass manager. Volunteers, please? Zdenek
Re: Explicit field layout
On Sep 25, 2006, at 1:04 AM, Ricardo FERNANDEZ PASCUAL wrote: Bernd Jendrissek wrote: Are you sure you want to do that, instead of using, say, rpcgen? I am sorry, but I fail to see the relation of this with rpcgen (which as far I know is a code generator for the RPC protocol). Am I looking at the wrong rpcgen? No, you're looking at the right one, it wasn't a suggestion from a compiler writer, you can safely ignore it.
Re: Call for 4.3 project reviewers
Zdenek Dvorak wrote on 09/25/06 14:33: > autoparallelization (http://gcc.gnu.org/wiki/AutomaticParallelization): > In addition the the autoparallelization pass (1.5kloc), minor changes > to gomp framework. 2kloc diff in total. > I can help you with this one. > prefetching improvements (http://gcc.gnu.org/wiki/PrefetchingImprovements): > In addition to the changes to prefetching (tree-ssa-loop-prefetch.c): > New cross-loop reuse analysis pass (2.5kloc). Significant changes to > # of iterations estimation. Minor changes to rtl expansion (expr.c, > optabs, ...) to enable generation of non-temporal store instructions. > Minor changes to loop manipulation functions. Some cleanups to > tree-data-ref.c (to enable sharing of code with reuse analysis). > 6.5kloc diff in total. > > preserving loop structures during optimizations > (http://gcc.gnu.org/wiki/PreservingLoops): > Major changes to jump threading infrastructure > (tree-ssa-threadupdate.c) and optimizers using it (dom, vrp), and > loop structure updating functions (cfgloop*.c). Minor changes to many > tree-ssa optimizers, and pass manager. > If you can't find anyone for these two, I may be able to help. But I don't want to commit as I can't guarantee that I'll be able to give you timely feedback.
Re: Call for 4.3 project reviewers
On 9/25/06, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: Hello, in accordance with http://gcc.gnu.org/ml/gcc/2006-09/msg00454.html, I am looking for reviewers for my 4.3 projects. I would like to get someone "responsible" for reviewing each project soon, so that I may discuss the changes he considers necessary with him. For each project, the list of touched areas of compiler together with estimates of the extent of the changes is provided (not all the changes necessarily have to be merged as part of the project, some of them qualify as bugfixes or independent improvements). Code for predictive commoning is available on predcom branch. Regarding the remaining three projects, at the moment I have them only available locally; I plan to put them on branch soon (I must first decide whether I want to create a separate branch for each of them, or just one common): stage 1: predictive commoning (http://gcc.gnu.org/wiki/PredictiveCommoning): The predictive commoning pass itself (2.5kloc). Significant changes to loop manipulation (unrolling, updating of frequencies). Uses affine expressions framework (http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00345.html). Changes to dependence analysis (more correct handling of aliasing). 6.5kloc diff in total. stage 2: autoparallelization (http://gcc.gnu.org/wiki/AutomaticParallelization): In addition the the autoparallelization pass (1.5kloc), minor changes to gomp framework. 2kloc diff in total. prefetching improvements (http://gcc.gnu.org/wiki/PrefetchingImprovements): In addition to the changes to prefetching (tree-ssa-loop-prefetch.c): New cross-loop reuse analysis pass (2.5kloc). Significant changes to # of iterations estimation. Minor changes to rtl expansion (expr.c, optabs, ...) to enable generation of non-temporal store instructions. Minor changes to loop manipulation functions. Some cleanups to tree-data-ref.c (to enable sharing of code with reuse analysis). 6.5kloc diff in total. preserving loop structures during optimizations (http://gcc.gnu.org/wiki/PreservingLoops): Major changes to jump threading infrastructure (tree-ssa-threadupdate.c) and optimizers using it (dom, vrp), and loop structure updating functions (cfgloop*.c). Minor changes to many tree-ssa optimizers, and pass manager. Volunteers, please? If you post the patches, i can help with the data-ref and dependence changes in each one.
