Re: GCC 4.2.0 Status Report (2007-03-04)

[Brooks Moses]

Mark Mitchell wrote:

However, I do think that it's important to eliminate some of the 139
open P2 and P1 regressions [2], especially those P1 regressions which
did not appear in GCC 4.1.x.


133, not 139.  Your search url returns six P3 bugs, one of which (29441) 
is not even a regression.


Does that count as six for my tally?  :)

- Brooks

Re: RTL insns getting deleted

[Florian Stock]

Rohit Arul Raj wrote:


1. emit_insn to set the flag (moving data to special registers).
2. emit_insn for add_float insn.
3. DONE

> [...]

Any specific reason why these are getting deleted and how to overcome this?


I think its maybe because there is no connection between 1. and 2. (or 
at least gcc thinks it). And because he wanted just 2. in the first 
place he thinks that he can optimize 1. away.


There are different ways to overcome this:

a. make the add_float-pattern not only match the add but also the 
setting of the flags, this way they kept together
b. make 1. volatile so he didnt optimize it away (but then it will also 
remain there if he can optimize 2. away)
c. add to the add_float (use special_reg) or whatever to tell him that 
he requires the special registers.


Florian

passes not maintaining CFG ?

[Sunzir Deepur]

hello all,

I would like to output a CFG (preferably in VCG format)
which describes the final binary.

Is it doable or do the last RTL passes change the CFG ?

I see that the last vcg outputable is file.c.49.stack.vcg - is it a good
description of the final binary flow ?

Thank you all
sunzir

Re: GCC 4.2.0 Status Report (2007-03-04)

[Manuel López-Ibáñez]

On 05/03/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:

After reviewing all of the traffic[1] that stemmed from my previous
status report, I've decided that, indeed, it makes sense to steam ahead
with GCC 4.2.0 based on current GCC 4.2.0 release branch.



I ask special permission to apply this patch:

http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01461.html

to GCC 4.2.0. This patch is trivial and it has been in GCC 4.3 for a
few weeks already.

It replaces two options that are introduced in GCC 4.2 with a single
switch -Waddress. I think we should replace them before releasing, to
minimise the effect of the change in users.

In addition, there are two trivial doc fixes for GCC 4.2, one in
invoke.texi and another in opts.c, where it says -Werror- and it
should say -Werror=
Can I commit them as obvious or do I need to submit a patch?

Cheers,

Manuel.

Re: GCC project participation in the 2007 Google Summer of Code program?

[James Youngman]

On 04 Mar 2007 16:22:33 -0800, Ian Lance Taylor  wrote:


Yes, we do plan to participate.  That link goes to the SoC page for
gcc.  Right now it's still the 2006 one, but I would assume it will
probably the right one once the 2007 setup gets going.


OK - I have updated
http://www.gnu.org/software/soc-projects/ideas.html accordingly.

James.

Re: Massive SPEC failures on trunk

[Eric Botcazou]

> I observe a massive compilation time regression for bootstrap on x86-64
> here, in particular libjava now appears to take *ages* to build:

I cannot reproduce today at the same revision:

real275m23.314s
user242m28.724s
sys 12m18.249s

Something went awry with kpowersave yesterday... sorry for the noise.

-- 
Eric Botcazou

Cross Compiler to Native Compiler

[kapil jain]

Hi,

I am porting/developing GCC onto a new platform.
This platform already have a cross tool chain.
Can anybody give me a roadmap to port GCC in native
environment from scratch? or
Way to convert, Croos-Compiler to Native-Compiler?

Thanks n Regards,
Kapil 



__
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/

Re: vcond implementation in altivec

[Sa Liu]

David Edelsohn <[EMAIL PROTECTED]> wrote on 02.03.2007 19:10:58:

> > Devang Patel writes:
> 
> >> Is there a reason why op0 is V4SF
> Devang> It is destination so, yes this is wrong.
> 
> >> and op1 is V4SI (and not V8HI)?
> 
> Devang> condition should be v4si, but it is not op1. So this is also
> not correct.
> 
> >> And also, why not use if_then_else instead of unspec (in all 
vcond's)?
> 
> Devang> I did not try that path. May be I did not know about it at that 
time.
> 
> 
>Patches welcome.
> 
> David
> 

I am working on the patch and will submit it soon.

Sa

Re: Fw: Cross Compiler to Native Compiler

[Victor Kaplansky]

Just use your cross-compiler to build a compiler for the target system
that'll run on the target system.  Then it could be good idea to use
new native compiler on its hardware to rebuild gcc once again natively.
Two compilers from last two steps should be identical.  It's a good way
to make sure your cross and native compilers are working correctly, and
generating code that actually runs.

Have a look at how canadian cross compiler are built, that might give you
a hint.  Some hacking the script for building canadian cross-compiler may
help (See CrossGCC FAQ for details -
http://vmlinux.org/crash/mirror/www.objsw.com/CrossGCC/).  But be sure to
edit specs and change cross_compile to 0 later as specs are dumped by
cross-compiler.

you can find some more info in this thread:

http://sourceware.org/ml/crossgcc/2005-02/msg5.html

-- Victor

>
> Cross Compiler to Native Compiler
>
> Hi,
>
> I am porting/developing GCC onto a new platform.
> This platform already have a cross tool chain.
> Can anybody give me a roadmap to port GCC in native
> environment from scratch? or
> Way to convert, Croos-Compiler to Native-Compiler?
>
> Thanks n Regards,
> Kapil

Re: Who should fix platforms broken by extern inline hack?

[Joseph S. Myers]

On Mon, 4 Mar 2007, Ian Lance Taylor wrote:

> FX Coudert <[EMAIL PROTECTED]> writes:
> 
> > I'd like to ping these two problems :)
> > 
> > i386-unknown-netbsdelf2.0.2 (and possibly newer versions) and i386-pc-
> > mingw32 (latest released version) are still completely broken on
> > mainline, as they have been for more that three months.
> 
> This patch (not yet approved) is my contribution to fixing the
> problem.
> 
> http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00021.html

I was supposing there would be a patch repost following 
 with the current 
versions of the patch for consideration.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: [RFC]possible improvements to --with-sysroot

[Daniel Jacobowitz]

On Sat, Mar 03, 2007 at 09:47:41PM +0800, Zhang Le wrote:
> Wouldn't it be great that we go one step further that we let ld look
> for libraries in the dir listed in $SYSROOT/etc/ld.so.conf, if this
> file ever exits? Of course for each entry in $SYSROOT/etc/ld.so.conf,
> we prefix $SYSROOT to it.

Did you try it?  This should already happen if you configured binutils
with a sysroot.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Improvements of the haifa scheduler

[Diego Novillo]

Maxim Kuvyrkov wrote on 03/05/07 02:14:

>o Fix passes that invalidate tree-ssa alias export.

Yes, this should be good and shouldn't need a lot of work.

>o { Fast but unsafe Gupta's aliasing patch, Unsafe tree-ssa alias 
> export } in scheduler's data speculation.

"unsafe" alias export?  I would definitely like to see the tree->rtl
alias information transfer fixed once and for all.  Finishing RAS's
tree->rtl work would probably make a good SoC project.

subreg pass

[Roman Zippel]

Hi,

The new subreg lowering pass seems to generate a bit worse code on m68k 
than before, let's take simple example:

unsigned long long f(unsigned long long a, unsigned long long b)
{
return a + b;
}

where currently gcc generates code like this:

move.l 16(%sp),%d1
move.l 20(%sp),%d2
move.l 8(%sp),%d0
add.l 12(%sp),%d2
addx.l %d0,%d1
move.l %d1,%d0
move.l %d2,%d1

whereas with -fno-split-wide-types it generates this:

move.l 16(%sp),%d0
move.l 20(%sp),%d1
move.l 8(%sp),%d2
add.l 12(%sp),%d1
addx.l %d2,%d0

How can I get rid of these extra move instructions?

Another more general question would be how should be wide registers 
handled in general. In the past I tried to avoid splitting instructions 
before reload, exactly because the extra subregs caused worse code. Has 
this changed? AFAICT this would mean in the back end to split DI values as 
early as possible, which could have its advantages, but also its 
challenges, as m68k is still a cc0 target and with instructions like 
addx.l above, so far I avoided splitting these at all.

bye, Roman

Re: Massive SPEC failures on trunk

[Vladimir Sysoev]

Hi, All

Try minimal reproducer for internal compiler error attached.
See go file for command line and report.log for issue reported by
trunk compiler/
-Vladimir


On 3/5/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:

> I observe a massive compilation time regression for bootstrap on x86-64
> here, in particular libjava now appears to take *ages* to build:

I cannot reproduce today at the same revision:

real275m23.314s
user242m28.724s
sys 12m18.249s

Something went awry with kpowersave yesterday... sorry for the noise.

--
Eric Botcazou



cutted.tgz
Description: GNU Zip compressed data

Re: GCC 4.2.0 Status Report (2007-03-04)

[Gerald Pfeifer]

On Mon, 5 Mar 2007, Manuel López-Ibáñez wrote:
> In addition, there are two trivial doc fixes for GCC 4.2, one in
> invoke.texi and another in opts.c, where it says -Werror- and it
> should say -Werror=
> Can I commit them as obvious or do I need to submit a patch?

Both. :-)  That is, go ahead and commit the patch but post it to the
gcc-patches list as well.

Gerald

Re: Improvements of the haifa scheduler

[Andrey Belevantsev]

Vladimir N. Makarov wrote:
Good aliasing is very important for the scheduler.  But I'd look at this 
more wider.  We need a good aliasing for many RTL optimizations.  What's 
happened to ISP RAS aliasing patch propagating SSA info to RTL?  Why is 
it stalled?
We'll plan to work on it further in the near future.  The initial plan 
was to update it to trunk, then to gather the new numbers of 
disambiguations and stuff, then to check the consistency of the saved 
information via some verifier.


As for Sanjiv Gupta's aliasing work, that was interesting but as I 
remember the patch made compiler too slow (like 40% slower).  You should 
make this approach faster to make it accepted as used by default.
Alexander Monakov was working on it in the last year (CC'd).  I have 
looked through his paper to recall what was done:


- instead of iterating over cfg, a single iteration in topological order 
was made to calculate address descriptors (which was enough for using 
this info in the scheduler);
- instead of one per-function hashtable for all address descriptors, 
separate per-bb hashtables were introduced, lowering the time needed to 
access hashtables;
- instead of saving out lists of descriptors for each bb, in lists were 
saved (and not recalculated several times);
- saving descriptors for each mem instead of each bb.  Earlier, when an 
aliasing query was made, we've searched for insns corresponding to mems 
via hashtable, then reanalyzed a basic block up to that insns, then 
answered on the query using calculated address descriptors.  After the 
fix, we've just got the final descriptor from the first hashtable, then 
answered the query.


After all fixes, bootstrap and cc1-i-files compiled slower on 2%.  The 
compiler built with the patch enabled compiled tramp3d on 0.5% faster 
and produced 0.6% faster code.  We'll dig out this patch together with 
the rest of aliasing patches and will send it as a RFC.  It is my 
mistake for not doing this earlier.


If you need benchmarking for machines (like ppc) you have no access to, 
I can provide the benchmarking.
That's great, because we have access to powerpc750 only.  I have used it 
to try the scheduler on ppc, but that was slow.


I really appreciate.  May be if you or ISP RAS could find students (e.g. 
from Moscow University) to do this as Google Summer Code, it could help 
you.  I think it is not too late.  You should ask Ian Taylor or Daniel 
Berlin, if you want to do this.
We'll work on aliasing anyways (see above).  Three students are working 
with us, but they are busy with different projects.  I'll ask my advisor 
about it.


Andrey

Re: Massive SPEC failures on trunk

[Vladimir Sysoev]

Hi, All

Sorry for my previous post. It was into wrong place.

There is minimal reproducer for cpu2006/h264ref is attached
use
gcc -O2 -c ./image.c

Compiler from trunk produces:
image.c: In function 'UnifiedOneForthPix':
image.c:35: internal compiler error: in set_value_range, at tree-vrp.c:267

-Vladimir


On 3/4/07, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote:

Grigory Zagorodnev wrote:
> Trunk GCC shows massive (2 compile-time and 6 run-time) failures on SPEC
> CPU2000 and CPU2006 at i386 and x86_64 on -O2 optimization level.
> Regression introduced somewhere between revision 122487 and 122478.
>
> http://gcc.gnu.org/viewcvs?view=rev&revision=122487
Almost all regressions are due to r122487
cpu2006: 403.gcc 416.gamess 434.zeusmp 464.h264ref 465.tonto
cpu2000: 178.galgel 186.crafty


> http://gcc.gnu.org/viewcvs?view=rev&revision=122484
cpu2006/447.dealII is due to revision 122484.

I'll bring more information and try to get minimal reproducers at Monday.

- Grigory

typedef unsigned char byte;//!< byte type definition

#define max(a, b) (((a) > (b)) ? (a) : (b))
#define min(a, b) (((a) < (b)) ? (a) : (b))

typedef long long int64;

#define imgpel unsigned short
#define pel_t imgpel


#define IMG_PAD_SIZE4   //!< Number of pixels padded around the reference 
frame (>=4)
#define MAX_LIST_SIZE 33
#define imgpel unsigned short

int**img4Y_tmp;  //!< for quarter pel interpolation

typedef struct storable_picture
{
  int size_x, size_y;
  imgpel **   imgY;  //!< Y picture component
} StorablePicture;


const int ONE_FOURTH_TAP[3][2] =
{
  {20,20},
  {-5,-4},
  { 1, 0},
};

void UnifiedOneForthPix (StorablePicture *s)
{
  int i, j, jj,is;
  imgpel  **imgY = s->imgY;
  
  for (i = -IMG_PAD_SIZE; i < s->size_x + IMG_PAD_SIZE; i++)
  {
  is =
(ONE_FOURTH_TAP[0][0] *
(imgY[jj][max (0, min (s->size_x - 1, i))] +
 imgY[jj][max (0, min (s->size_x - 1, i + 1))]) +
ONE_FOURTH_TAP[1][0] *
(imgY[jj][max (0, min (s->size_x - 1, i - 1))] +
 imgY[jj][max (0, min (s->size_x - 1, i + 2))]) +
ONE_FOURTH_TAP[2][0] *
(imgY[jj][max (0, min (s->size_x - 1, i - 2))] +
 imgY[jj][max (0, min (s->size_x - 1, i + 3))]));
  img4Y_tmp[j + IMG_PAD_SIZE][(i + IMG_PAD_SIZE) * 2 + 1] = is * 32;  // 
1/2 pix pos
  }

}

Re: Improvements of the haifa scheduler

[Maxim Kuvyrkov]

Diego Novillo wrote:

Maxim Kuvyrkov wrote on 03/05/07 02:14:


   o Fix passes that invalidate tree-ssa alias export.


Yes, this should be good and shouldn't need a lot of work.

   o { Fast but unsafe Gupta's aliasing patch, Unsafe tree-ssa alias 
export } in scheduler's data speculation.


"unsafe" alias export?  I would definitely like to see the tree->rtl
alias information transfer fixed once and for all.  Finishing RAS's
tree->rtl work would probably make a good SoC project.


"Unsafe" doesn't mean not fixed.  My thought is that it would be nice to 
have a switch in aliasing that will turn such operations as


join (pt_anything, points_to) -> pt_anything

into

join (pt_anything, points_to) -> points_to

This transformation will sacrifice correctness for sake of additional 
information.



Thanks,

Maxim

Re: Improvements of the haifa scheduler

[Vladimir Makarov]

Andrey Belevantsev wrote:


Vladimir N. Makarov wrote:

Good aliasing is very important for the scheduler.  But I'd look at 
this more wider.  We need a good aliasing for many RTL 
optimizations.  What's happened to ISP RAS aliasing patch propagating 
SSA info to RTL?  Why is it stalled?


We'll plan to work on it further in the near future.  The initial plan 
was to update it to trunk, then to gather the new numbers of 
disambiguations and stuff, then to check the consistency of the saved 
information via some verifier.


As for Sanjiv Gupta's aliasing work, that was interesting but as I 
remember the patch made compiler too slow (like 40% slower).  You 
should make this approach faster to make it accepted as used by default.


Alexander Monakov was working on it in the last year (CC'd).  I have 
looked through his paper to recall what was done:


- instead of iterating over cfg, a single iteration in topological 
order was made to calculate address descriptors (which was enough for 
using this info in the scheduler);
- instead of one per-function hashtable for all address descriptors, 
separate per-bb hashtables were introduced, lowering the time needed 
to access hashtables;
- instead of saving out lists of descriptors for each bb, in lists 
were saved (and not recalculated several times);
- saving descriptors for each mem instead of each bb.  Earlier, when 
an aliasing query was made, we've searched for insns corresponding to 
mems via hashtable, then reanalyzed a basic block up to that insns, 
then answered on the query using calculated address descriptors.  
After the fix, we've just got the final descriptor from the first 
hashtable, then answered the query.


After all fixes, bootstrap and cc1-i-files compiled slower on 2%.  The 
compiler built with the patch enabled compiled tramp3d on 0.5% faster 
and produced 0.6% faster code.  We'll dig out this patch together with 
the rest of aliasing patches and will send it as a RFC.  It is my 
mistake for not doing this earlier.


That is a real progress with Gupta's patch.  Thank you for working on it.



If you need benchmarking for machines (like ppc) you have no access 
to, I can provide the benchmarking.


That's great, because we have access to powerpc750 only.  I have used 
it to try the scheduler on ppc, but that was slow.


I'll do some PPC benchmarking of your branch on this week and send the 
results.

Re: Failed

[Gerald Pfeifer]

On Sun, 4 Mar 2007, Gerald Pfeifer wrote:
> I investigated a bit, and it seems that unlike gcc.gnu.org, www.gnu.org 
> lacks the latest revision (at least) of the bin/preprocess script in our 
> wwwdocs module:
> 
>   revision 1.43
>   date: 2006/06/10 21:52:24;  author: gerald;  state: Exp;  lines: +2 -0
>   Use sed to work around MetaHTML brokenness wrt. .
> 
> I have contacted the GNU sysadmins and asked them to update to the latest
> version of the script.

I got a heads up that they did that now, so the problem should be resolved
going forward.  Please give www.gnu.org twenty-four hours to sync up.

Gerald

question about PASSES

[Sunzir Deepur]

hi all,

these are the last passes:

 NEXT_PASS (pass_stack_regs);   // last pass to generate VCG file
 NEXT_PASS (pass_compute_alignments);
 NEXT_PASS (pass_duplicate_computed_gotos);
 NEXT_PASS (pass_variable_tracking);
 NEXT_PASS (pass_free_cfg);
 NEXT_PASS (pass_machine_reorg);
 NEXT_PASS (pass_purge_lineno_notes);
 NEXT_PASS (pass_cleanup_barriers);
 NEXT_PASS (pass_delay_slots);
 NEXT_PASS (pass_split_for_shorten_branches);
 NEXT_PASS (pass_convert_to_eh_region_ranges);
 NEXT_PASS (pass_shorten_branches);
 NEXT_PASS (pass_set_nothrow_function_flags);
 NEXT_PASS (pass_final); / translating to assembly (-->binary)

the pass_stack_regs is the last one which generates a vcg file (graph of flow).
the pass_final is of course the one which translates to assembly, therefore
after it I assume the flow of the code does not change.

my question is whether I can use the flow dumped by pass_stack_regs pass
and assume it is legal as the flow of the real binary ? of do any of the passes
between them change the flow ?

thank you all
sunzir

Re: reload.c as a bugzilla quip

[Joe Buck]

On Sun, Mar 04, 2007 at 09:45:13AM +0100, FX Coudert wrote:
> One of the bugzilla quips (the headlines appearing at random for each  
> bug list) is actually the head of gcc/reload.c (full text below).  

That is really obnoxious and should be removed.

Re: Improvements of the haifa scheduler

[Ian Lance Taylor]

Maxim Kuvyrkov <[EMAIL PROTECTED]> writes:

> So basically here are three Google Summer of Code projects:
> 
>o Scheduler -> RA
>o Fix passes that invalidate tree-ssa alias export.
>o { Fast but unsafe Gupta's aliasing patch, Unsafe tree-ssa alias
> export } in scheduler's data speculation.
> 
> Ian, Daniel, what do you think?

I think that any of these patches would be quite difficult for anybody
not already familiar with gcc.  But for somebody who already
understands the aliasing representation, they would make good
projects.

Can you add them somewhere on this page, or linked from this page:
http://gcc.gnu.org/wiki/SummerOfCode

Thanks!

Ian

Re: Who should fix platforms broken by extern inline hack?

[Ian Lance Taylor]

"Joseph S. Myers" <[EMAIL PROTECTED]> writes:

> On Mon, 4 Mar 2007, Ian Lance Taylor wrote:
> 
> > FX Coudert <[EMAIL PROTECTED]> writes:
> > 
> > > I'd like to ping these two problems :)
> > > 
> > > i386-unknown-netbsdelf2.0.2 (and possibly newer versions) and i386-pc-
> > > mingw32 (latest released version) are still completely broken on
> > > mainline, as they have been for more that three months.
> > 
> > This patch (not yet approved) is my contribution to fixing the
> > problem.
> > 
> > http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00021.html
> 
> I was supposing there would be a patch repost following 
>  with the current 
> versions of the patch for consideration.

I only made one of the changes Jakub suggested: I fixed a typo in the
documentation.  So I didn't bother sending another copy.

For clarity, here is the current version of the patch.

Ian


gcc/ChangeLog:
2007-03-05  Ian Lance Taylor  <[EMAIL PROTECTED]>

* c.opt (fgnu89-inline): New option.
* c-opts.c (c_common_post_options): Set default value for
flag_gnu89_inline.
* c-decl.c (WANT_C99_INLINE_SEMANTICS): Remove.
(pop_scope): Check flag_gnu89_inline rather than flag_isoc99 for
inline functions.
(diagnose_mismatched_decls, merge_decls, start_decl): Likewise.
(grokdeclarator, start_function): Likewise.
* c-cppbuiltin.c (c_cpp_builtins): Define either
__GNUC_GNU_INLINE__ or __GNUC_STDC_INLINE__.
* doc/invoke.texi (Option Summary): Mention -fgnu89-inline.
(C Dialect Options): Document -fgnu89-inline.
* doc/extend.texi (Function Attributes): Explain what the
gnu_inline attribute does.
* doc/cpp.texi (Common Predefined Macros): Document
__GNUC_GNU_INLINE__ and __GNUC_STDC_INLINE__.

gcc/testsuite/ChangeLog:
2007-03-05  Ian Lance Taylor  <[EMAIL PROTECTED]>

* gcc.dg/inline-18.c: New test.
* gcc.dg/inline-19.c: New test.
* gcc.dg/inline-20.c: New test.
* gcc.dg/inline-21.c: New test.


Index: gcc/doc/cpp.texi
===
--- gcc/doc/cpp.texi(revision 122560)
+++ gcc/doc/cpp.texi(working copy)
@@ -2014,6 +2014,28 @@ functions.  You should not use these mac
 sure that programs will execute with the same effect whether or not they
 are defined.  If they are defined, their value is 1.
 
[EMAIL PROTECTED] __GNUC_GNU_INLINE__
+GCC defines this macro if functions declared @code{inline} will be
+handled in GCC's traditional gnu89 mode.  In this mode an @code{extern
+inline} function will never be compiled as a standalone function, and
+an @code{inline} function which is neither @code{extern} nor
[EMAIL PROTECTED] will always be compiled as a standalone function.
+
[EMAIL PROTECTED] __GNUC_STDC_INLINE__
+GCC defines this macro if functions declared @code{inline} will be
+handled according to the ISO C99 standard.  In this mode an
[EMAIL PROTECTED] inline} function will always be compiled as a standalone
+externally visible function, and an @code{inline} function which is
+neither @code{extern} nor @code{static} will never be compiled as a
+standalone function.
+
+If this macro is defined, GCC supports the @code{gnu_inline} function
+attribute as a way to always get the gnu89 behaviour.  Support for
+this and @code{__GNUC_GNU_INLINE__} was added in GCC 4.1.3.  If
+neither macro is defined, an older version of GCC is being used:
[EMAIL PROTECTED] functions will be compiled in gnu89 mode, and the
[EMAIL PROTECTED] function attribute will not be recognized.
+
 @item __CHAR_UNSIGNED__
 GCC defines this macro if and only if the data type @code{char} is
 unsigned on the target machine.  It exists to cause the standard header
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 122560)
+++ gcc/doc/extend.texi (working copy)
@@ -1618,8 +1618,37 @@ if no optimization level was specified.
 
 @item gnu_inline
 @cindex @code{gnu_inline} function attribute
-This attribute on an inline declaration results in the old GNU C89
-inline behavior even in the ISO C99 mode.
+This attribute should be used with a function which is also declared
+with the @code{inline} keyword.  It directs GCC to treat the function
+as if it were defined in gnu89 mode even when compiling in C99 or
+gnu99 mode.
+
+If the function is declared @code{extern}, then this definition of the
+function is used only for inlining.  In no case is the function
+compiled as a standalone function, not even if you take its address
+explicitly.  Such an address becomes an external reference, as if you
+had only declared the function, and had not defined it.  This has
+almost the effect of a macro.  The way to use this is to put a
+function definition in a header file with this attribute, and put
+another copy of the function, without @code{extern}, in a library

Re: subreg pass

[Ian Lance Taylor]

Roman Zippel <[EMAIL PROTECTED]> writes:

> The new subreg lowering pass seems to generate a bit worse code on m68k 
> than before, let's take simple example:
> 
> unsigned long long f(unsigned long long a, unsigned long long b)
> {
>   return a + b;
> }
> 
> where currently gcc generates code like this:
> 
> move.l 16(%sp),%d1
> move.l 20(%sp),%d2
> move.l 8(%sp),%d0
> add.l 12(%sp),%d2
> addx.l %d0,%d1
> move.l %d1,%d0
> move.l %d2,%d1
> 
> whereas with -fno-split-wide-types it generates this:
> 
> move.l 16(%sp),%d0
> move.l 20(%sp),%d1
> move.l 8(%sp),%d2
> add.l 12(%sp),%d1
> addx.l %d2,%d0
> 
> How can I get rid of these extra move instructions?

The standard answer would be to add a define_split for the adddi3 insn
which triggers before reload.  But that is problematic on a CC0 system
where you want to preserve the overflow flag.  I'm not sure what to
suggest at the moment.  Note that there is still an extra move.l insn
in the -fno-split-wide-types version.

> Another more general question would be how should be wide registers 
> handled in general. In the past I tried to avoid splitting instructions 
> before reload, exactly because the extra subregs caused worse code. Has 
> this changed? AFAICT this would mean in the back end to split DI values as 
> early as possible, which could have its advantages, but also its 
> challenges, as m68k is still a cc0 target and with instructions like 
> addx.l above, so far I avoided splitting these at all.

Yes, it is in general better now to split double-word length
operations before reload.  It's not necessarily better to split as
early as possible, as that will essentially disable the RTL level loop
optimizations.  But it's still problematic to split before reload on a
CC0 system.

Ian

Re: [RFC]possible improvements to --with-sysroot

[Zhang Le]

First of all, my apology. It seems that I should have posted this
email to binutils's ML.
On 3/5/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:

On Sat, Mar 03, 2007 at 09:47:41PM +0800, Zhang Le wrote:
> Wouldn't it be great that we go one step further that we let ld look
> for libraries in the dir listed in $SYSROOT/etc/ld.so.conf, if this
> file ever exits? Of course for each entry in $SYSROOT/etc/ld.so.conf,
> we prefix $SYSROOT to it.

Did you try it?  This should already happen if you configured binutils
with a sysroot.

Yes, I have tried.
My distribution is Gentoo, I used the crossdev utility to build the
cross toolchain.
The related code is:
   is_cross && myconf="${myconf} --with-sysroot=/usr/${CTARGET}"
I was cross compiling KDE. However, it's failed because linker can't
find -lqt-mt.
I have used "strace -f" to check where linker looked for -lqt-mt. From
what I have observed, it seems that ld didn't use
$SYSROOT/etc/ld.so.conf.

--
Zhang Le, Robert
Linux Engineer/Trainer
http://zhllg.blogspot.com
http://zh.gentoo-wiki.com
http://savannah.nongnu.org/projects/pgubook
http://groups.google.com/group/gentoo-china
http://groups.google.com/group/szlug

Re: [RFC]possible improvements to --with-sysroot

[Daniel Jacobowitz]

On Tue, Mar 06, 2007 at 02:05:06AM +0800, Zhang Le wrote:
> I have used "strace -f" to check where linker looked for -lqt-mt. From
> what I have observed, it seems that ld didn't use
> $SYSROOT/etc/ld.so.conf.

Well, it's supposed to, so I suggest you check what's happened in ld.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC]possible improvements to --with-sysroot

[Zhang Le]

On 3/6/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:

On Tue, Mar 06, 2007 at 02:05:06AM +0800, Zhang Le wrote:
> I have used "strace -f" to check where linker looked for -lqt-mt. From
> what I have observed, it seems that ld didn't use
> $SYSROOT/etc/ld.so.conf.

Well, it's supposed to, so I suggest you check what's happened in ld.

Thanks, will do

--
Zhang Le, Robert
Linux Engineer/Trainer
http://zhllg.blogspot.com
http://zh.gentoo-wiki.com
http://savannah.nongnu.org/projects/pgubook
http://groups.google.com/group/gentoo-china
http://groups.google.com/group/szlug

RE: new auto-inc-dec pass

[Kenneth Zadeck]

> Hi,
> 
> I'mm currently looking at the dataflow branch for m68k mainly because of 
> the new auto-inc-dec pass, I worked a bit on the old code in flow.c, but 
> considering the new pass, I think it doesn't make much sense to continue 
> it.
> 
I agree.  With high probability the auto inc detection will be
replaced with the new auto-inc-dec.c on the dataflow branch.

I would certainly encourage you to enhance the new code in
auto-inc-dec.c where you find that it is lacking.  That code does get
all of the cases that were found by the old version of flow and does
get many things that were missed.  

But there is no expectation that this is the last word in auto-inc-dec
detection.  My main concern was to cleanly separate this function from
flow without any regressions.


> 
> 
> I'm attaching my current patch and some test cases, but before delving 
> deeper into the code, I have a few questions and I'd like to hear some 
> opinions. Currently I only looked at the output and it misses some 
> opportunities (not that my patch can do everything either :) ).

I agree that the auto-inc-dec code will already get much of this.  In
particular there is no longer (unless the machine requirres it) a
reliance that the increment match the size of the load or store. 
> 
> One case is about multiple increments, the tree optimizer merges them and 
> increments the register only once, so if one only looks at the size of the
> pointer value one misses them, e.g. something like this:
> 
>   (set (mem (reg)) (x))
>   (set (mem (plus (reg) (const_int 4))) (x))
>   (set (reg) (plus (reg) (const_int 8))
> 
> Another case are multiple uses of the register within an instruction, the 
> old code didn't do this at all, the new code seems to do a bit better, but 
> there as a rather tricky case I looked into, e.g.
> 
>   (set (mem) (plus (mem) (reg)))
> 
> could be turned into:
> 
>   (set (post_inc (mem)) (plus (mem) (reg)))
> 
I do find this a little wierd but if it makes a difference go for it.


> or
> 
>   (set (mem) (plus (pre_dec (mem)) (reg)))
> 
> This is at least what operands_match_p() accepts, but hasn't been 
> generated in a long time and has the potential to trigger bugs in the 
> back end (e.g. m68k only looks only at one of the operands).
> A question would be now if there is a general interest in reactivating 
> this, so gcc could generate a instruction like "add.l %d0,(%a0)+" for 
> m68k.
> 
> The more general question is whether someone is already working on further 
> improvements, so I won't duplicate anything (which wouldn't be before I 
> looked into the remaining m68k dataflow problems anyway. :) ).
> 
We have stopped development on this piece of code.  It is efficient
and works with no regressions on arm, ppc and ia-64.  So it meets the
minimun criteria for inclusion onto mainline with the upcoming merge.

However, that should in no way stop anyone else from enhancing it further.

> The dataflow porting document mentions other possible, but doesn't mention 
> any examples. Anything I might have to look out for regardings the m68k 
> post_inc/pre_dec addressing modes?
> 
> bye, Roman

Kenny

Re: Who should fix platforms broken by extern inline hack?

[Joseph S. Myers]

On Mon, 5 Mar 2007, Ian Lance Taylor wrote:

> I only made one of the changes Jakub suggested: I fixed a typo in the
> documentation.  So I didn't bother sending another copy.
> 
> For clarity, here is the current version of the patch.

This patch is OK.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: subreg pass

[Roman Zippel]

Hi,

On Mon, 5 Mar 2007, Ian Lance Taylor wrote:

> > whereas with -fno-split-wide-types it generates this:
> > 
> > move.l 16(%sp),%d0
> > move.l 20(%sp),%d1
> > move.l 8(%sp),%d2
> > add.l 12(%sp),%d1
> > addx.l %d2,%d0
> > 
> > How can I get rid of these extra move instructions?
> 
> The standard answer would be to add a define_split for the adddi3 insn
> which triggers before reload.  But that is problematic on a CC0 system
> where you want to preserve the overflow flag.  I'm not sure what to
> suggest at the moment.  Note that there is still an extra move.l insn
> in the -fno-split-wide-types version.

Actually it's correct, addx.l needs two registers. :)

> > Another more general question would be how should be wide registers 
> > handled in general. In the past I tried to avoid splitting instructions 
> > before reload, exactly because the extra subregs caused worse code. Has 
> > this changed? AFAICT this would mean in the back end to split DI values as 
> > early as possible, which could have its advantages, but also its 
> > challenges, as m68k is still a cc0 target and with instructions like 
> > addx.l above, so far I avoided splitting these at all.
> 
> Yes, it is in general better now to split double-word length
> operations before reload.  It's not necessarily better to split as
> early as possible, as that will essentially disable the RTL level loop
> optimizations. 

I was worried about that too, since some patterns would be more 
complicated, which may make some optimizations more difficult, e.g. where 
I noticed it first was mulsidi3, which currently looks like this:

  [(set (match_operand:SI 0 "register_operand" "=d")
(mult:SI (match_operand:SI 1 "register_operand" "%0")
  (match_operand:SI 2 "nonimmediate_operand" "dm")))
   (set (match_operand:SI 3 "register_operand" "=d")
(truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (match_dup 1))
   (zero_extend:DI (match_dup 2)))
  (const_int 32]

The dataflow branch doesn't like this due to the missing 
(strict_low_part), it's easy to fix by changing it to:

  [(set (match_operand:DI 0 "register_operand" "=d")
(mult:DI (zero_extend:DI (match_operand:SI 1 "register_operand" "%0"))
 (zero_extend:DI (match_operand:SI 2 "nonimmediate_operand" 
"dm"]

which is also easier to recognize as multiply for the rtl optimizers.
OTOH combine runs reasonably late, so it's quite easy to add a split to 
bring it back to the first form (plus strict_low_part).

> But it's still problematic to split before reload on a CC0 system.

I considered it splitting like this.

(parallel
  (set (op0) (plus (op1) (op2)))
  (set (cc0) (unspec [(op1) (op2)])))

(set (op0) (plus (plus (op1) (op2))
 (unspec [(cc0)])))

This should pass as cc0 setter/getter and probably needs additional work 
in notice_update_cc0().

bye, Roman

Re: Who should fix platforms broken by extern inline hack?

[Geoffrey Keating]

On 04/03/2007, at 12:25 AM, FX Coudert wrote:


I'd like to ping these two problems :)

i386-unknown-netbsdelf2.0.2 (and possibly newer versions) and i386- 
pc-mingw32 (latest released version) are still completely broken on  
mainline, as they have been for more that three months.


I spent some time on this but ran out.  The point I got up to was  
that I found out that the machine I was using apparently didn't have  
some tool (flex, or maybe bison) which I'd have to rebuild from source.



As it turns out, I do now have access to a NetBSD system, and will
look at that problem when I next get time.


Thanks. When you provid a patch, I will test it. (If someone else  
ever

wants access to a netbsd system, it's worth noting there's one on the
GCC compile farm!)


My understanding from 30589 is that a sufficiently recent version of
mingw32 has solved the problem.


The CVS version of mingw32 has the workaround, but most people aren't
using the CVS mingw32 (most people aren't using the last released
version anyway), so there'll be a need for a fix anyway.




smime.p7s
Description: S/MIME cryptographic signature

Re: new auto-inc-dec pass

[Rask Ingemann Lambertsen]

On Mon, Mar 05, 2007 at 03:44:20AM +0100, Roman Zippel wrote:
 
> The dataflow porting document mentions other possible, but doesn't mention 
> any examples. Anything I might have to look out for regardings the m68k 
> post_inc/pre_dec addressing modes?

   I have not checked what GCC currently generates for

void mystrcpy (char *dest, char *src)
{
while ((*dest++ = *src++))
;
}

but the loop should compile to (a1 = dest, a0 = src)

Loop:
move.b  (a0)+,  (a1)+
bne.s   Loop

at least for -Os or -mtune=68010.

-- 
Rask Ingemann Lambertsen

Re: Massive SPEC failures on trunk

[Ian Lance Taylor]

"Vladimir Sysoev" <[EMAIL PROTECTED]> writes:

> There is minimal reproducer for cpu2006/h264ref is attached
> use
> gcc -O2 -c ./image.c
> 
> Compiler from trunk produces:
> image.c: In function 'UnifiedOneForthPix':
> image.c:35: internal compiler error: in set_value_range, at tree-vrp.c:267

I just committed a patch for PR 31034 which may fix this.

Ian

Re: subreg pass

[Richard Henderson]

On Mon, Mar 05, 2007 at 02:29:05PM +0100, Roman Zippel wrote:
> challenges, as m68k is still a cc0 target and with instructions like 
> addx.l above, so far I avoided splitting these at all.

It would be possible to add an X register to model that one
bit from the flags, since X is generally preserved, and not
clobbered like the regular overflow bit.


r~

Signed overflow patches OK for 4.2?

[Ian Lance Taylor]

I'd like to backport the set of signed overflow patches for 4.2, now
that they are (almost) all in mainline.  These are the patches which
add -fstrict-overflow and -Wstrict-overflow.  It was the additional
reliance of strict signed overflow in 4.2 which led to a long
discussion a couple of months ago.

This would be a new feature for 4.2, of course.  Is it OK to do the
backport?

Thanks.

Ian

Re: Signed overflow patches OK for 4.2?

[Andrew Pinski]

On 05 Mar 2007 12:00:20 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:

This would be a new feature for 4.2, of course.  Is it OK to do the
backport?


Way too late.  Didn't Mark say he wanted to release a prelease soon?
Also isn't there still some regressions associated still with this change?
 for the reference of
the regressions.

Thanks,
Andrew Pinski

gcc and gmp/mpfr - order of build

[Kate Minola]

What is the recommended order of building gcc, gmp, mpfr?

I notice that now gcc depends on gmp and mpfr to build.

I believe the gmp recommends using gcc to build (although
it may build with other compilers).

What is the recommended order of building gcc, gmp, mpfr?
I can think of two options:

Option A.  Use the bootstrap compiler to first build gmp and mpfr,
then build gcc.

Option B.  Build gcc without gmp and mpfr.  Then use it to
build gmp and mpfr.  Now rebuild gcc using gmp and mpfr.

Are there other options?  What is recommended?

Kate Minola
University of Maryland, College Park

Re: Signed overflow patches OK for 4.2?

[Ian Lance Taylor]

"Andrew Pinski" <[EMAIL PROTECTED]> writes:

> On 05 Mar 2007 12:00:20 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> > This would be a new feature for 4.2, of course.  Is it OK to do the
> > backport?
> 
> Way too late.  Didn't Mark say he wanted to release a prelease soon?

If Mark agrees with you, then I'm unfortunately going to have to lobby
to disable VRP by default in 4.2.  I don't want to do that, but as
we've seen in the signed overflow thread from a couple of months ago,
reasonable users are surprised and disturbed by gcc 4.2's current
behaviour.  As you know, Paul Eggert has proposed having autoconf
automatically pass -fwrapv when compiling with gcc.  I think that
would be extremely unfortunate.  Disabling VRP by default will be the
lesser of two evils.


> Also isn't there still some regressions associated still with this change?
>  for the reference of
> the regressions.

That one is already fixed, I believe.

Ian

Re: gcc and gmp/mpfr - order of build

[Mike Stump]

gcc-help is a more appropriate list...

On Mar 5, 2007, at 12:19 PM, Kate Minola wrote:

What is the recommended order of building gcc, gmp, mpfr?


Any ordering is probably fine.


I notice that now gcc depends on gmp and mpfr to build.


Yes.


What is the recommended order of building gcc, gmp, mpfr?
I can think of two options:

Option A.  Use the bootstrap compiler to first build gmp and mpfr,
then build gcc.


Option A.

Re: Signed overflow patches OK for 4.2?

[Andrew Pinski]

On 05 Mar 2007 12:24:18 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:

"Andrew Pinski" <[EMAIL PROTECTED]> writes:

If Mark agrees with you, then I'm unfortunately going to have to lobby
to disable VRP by default in 4.2.


Then it should also be disabled by default also in 4.1.3 and should
have been disabled in 4.1.2 which was only released last month so
there is no reason why it has to be disabled in 4.2.0 if everyone is
using 4.1 anyways.

 As you know, Paul Eggert has proposed having autoconf
automatically pass -fwrapv when compiling with gcc.  I think that
would be extremely unfortunate.  Disabling VRP by default will be the
lesser of two evils.


but again 4.1.x still has VRP enabled so did you not agree for 4.1.2
to have VRP disabled at the begining of the year after you found out
about what Paul was going to do with autoconf?  I still don't see why
4.2.0 has to be different from 4.1.x in this respect.




> Also isn't there still some regressions associated still with this change?
>  for the reference of
> the regressions.

That one is already fixed, I believe.


They were referencing wrong code generation and the patch I thought
you did was only to fix the internal error.

Also I still say this changing of VRP and fold is too destructive to
put it on a release branch just after two days, I would wait at least
a month for these kind of patches really.

-- Pinski

Re: Signed overflow patches OK for 4.2?

[Eric Botcazou]

> Then it should also be disabled by default also in 4.1.3 and should
> have been disabled in 4.1.2 which was only released last month so
> there is no reason why it has to be disabled in 4.2.0 if everyone is
> using 4.1 anyways.

VRP has become more aggressive in 4.2.x than in 4.1.x though.

-- 
Eric Botcazou

Re: Signed overflow patches OK for 4.2?

[Diego Novillo]

Eric Botcazou wrote on 03/05/07 15:59:
>> Then it should also be disabled by default also in 4.1.3 and should
>> have been disabled in 4.1.2 which was only released last month so
>> there is no reason why it has to be disabled in 4.2.0 if everyone is
>> using 4.1 anyways.
> 
> VRP has become more aggressive in 4.2.x than in 4.1.x though.

Agreed.  I don't see the need to backport this functionality to 4.1.  It
has been out for quite some time now, used in various distros and we
have not been flooded with requests from users.

While this represents a new feature in 4.2, I don't think it's too
risky.  Whatever failures are triggered should be easy to identify and fix.

I personally don't like this feature very much as it may represent a
slippery slope into forcing us to warn in every optimization that
exploits undefined aspects of the standard.  But user pressure obviously
exists, so *shrug*.

Re: gcc and gmp/mpfr - order of build

[Andreas Schwab]

"Kate Minola" <[EMAIL PROTECTED]> writes:

> Option A.  Use the bootstrap compiler to first build gmp and mpfr,
> then build gcc.
>
> Option B.  Build gcc without gmp and mpfr.  Then use it to
> build gmp and mpfr.  Now rebuild gcc using gmp and mpfr.
>
> Are there other options?

Option C: unpack gmp and mpfr sources in the gcc toplevel and bootstrap
all of gcc, gmp, mpfr together.

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."

gcc-4.1-20070305 is now available

[gccadmin]

Snapshot gcc-4.1-20070305 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070305/
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/gcc-4_1-branch 
revision 122577

You'll find:

gcc-4.1-20070305.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20070305.tar.bz2 C front end and core compiler

gcc-ada-4.1-20070305.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20070305.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20070305.tar.bz2  C++ front end and runtime

gcc-java-4.1-20070305.tar.bz2 Java front end and runtime

gcc-objc-4.1-20070305.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20070305.tar.bz2The GCC testsuite

Diffs from 4.1-20070226 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
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.

Re: Signed overflow patches OK for 4.2?

[Ian Lance Taylor]

Diego Novillo <[EMAIL PROTECTED]> writes:

> Eric Botcazou wrote on 03/05/07 15:59:
> >> Then it should also be disabled by default also in 4.1.3 and should
> >> have been disabled in 4.1.2 which was only released last month so
> >> there is no reason why it has to be disabled in 4.2.0 if everyone is
> >> using 4.1 anyways.
> > 
> > VRP has become more aggressive in 4.2.x than in 4.1.x though.
> 
> Agreed.  I don't see the need to backport this functionality to 4.1.  It
> has been out for quite some time now, used in various distros and we
> have not been flooded with requests from users.
> 
> While this represents a new feature in 4.2, I don't think it's too
> risky.  Whatever failures are triggered should be easy to identify and fix.

I gather you are saying here that it is OK with you to backport
-fstrict-overflow/-Wstrict-overflow to 4.2.

> I personally don't like this feature very much as it may represent a
> slippery slope into forcing us to warn in every optimization that
> exploits undefined aspects of the standard.  But user pressure obviously
> exists, so *shrug*.

Yes, the overflow case, and the strict aliasing case, is clearly a
problem with real existing code, and is a problem for real users.

Ian

Re: gcc and gmp/mpfr - order of build

[Paul Brook]

On Monday 05 March 2007 22:00, Andreas Schwab wrote:
> "Kate Minola" <[EMAIL PROTECTED]> writes:
> > Option A.  Use the bootstrap compiler to first build gmp and mpfr,
> > then build gcc.
> >
> > Option B.  Build gcc without gmp and mpfr.  Then use it to
> > build gmp and mpfr.  Now rebuild gcc using gmp and mpfr.
> >
> > Are there other options?
>
> Option C: unpack gmp and mpfr sources in the gcc toplevel and bootstrap
> all of gcc, gmp, mpfr together.

Option D: Use a cross compiler.

Paul

Re: Signed overflow patches OK for 4.2?

[Diego Novillo]

Ian Lance Taylor wrote on 03/05/07 18:23:

> I gather you are saying here that it is OK with you to backport
> -fstrict-overflow/-Wstrict-overflow to 4.2.

Yes.

Re: Signed overflow patches OK for 4.2?

[Mark Mitchell]

Diego Novillo wrote:
> Ian Lance Taylor wrote on 03/05/07 18:23:
> 
>> I gather you are saying here that it is OK with you to backport
>> -fstrict-overflow/-Wstrict-overflow to 4.2.

It is OK with with me to backport the changes, even though this is
clearly late in the cycle.  None of the choices are particularly pretty.

Ian, please do the backport and check in the changes as soon as you can.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Massive SPEC failures on trunk

[Grigory Zagorodnev]

Ian Lance Taylor wrote:

"Vladimir Sysoev" <[EMAIL PROTECTED]> writes:

There is minimal reproducer for cpu2006/h264ref is attached

I just committed a patch for PR 31034 which may fix this.
Ian

Hi Ian,
patch for PR31034 fixes cpu2006/464.h264ref ICE only. Others are still 
failing - the root cause seems to be more general.

cpu2006: 403.gcc 416.gamess 434.zeusmp 465.tonto
cpu2000: 178.galgel 186.crafty

- Grigory