combined enable-build-with-cxx bootstrap comparison failure

[Ralf Wildenhues]

If I combine GCC and binutils-gdb, bootstrap, enable gold, use
--enable-build-with-cxx:

configured by ../src/configure, generated by GNU Autoconf 2.64,
  with options " '-C' '--enable-maintainer-mode' '--enable-objc-gc' 
'--enable-libssp' '--enable-sim' '--enable-gold' '--enable-build-with-cxx' 
'CC=/home/ralf/recent/bin/gcc' 'CXX=/home/ralf/recent/bin/g++' 
'--enable-languages=c,c++,fortran,java,objc,obj-c++'"

and a very recent GCC as $build compiler:
| gcc (GCC) 4.5.0 20090916 (experimental)

GMP 4.2.1, MPFR 3.0.0.dev, then I get a bootstrap comparison failure:

Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
Bootstrap comparison failure!
gold/i386.o differs
gold/stringpool.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/eh_alloc.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/eh_globals.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/vec.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/mt_allocator.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/system_error.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/future.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/pool_allocator.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/basic_file.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/atomic.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/locale.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/mt_allocator.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/system_error.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/future.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/pool_allocator.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/basic_file.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/atomic.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/locale.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/locale_init.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/debug.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/locale_init.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/debug.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/eh_alloc.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/eh_globals.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/guard.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/vec.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/mt_allocator.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/system_error.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/future.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/pool_allocator.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/basic_file.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/atomic.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/locale.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/mt_allocator.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/system_error.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/future.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/pool_allocator.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/basic_file.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/atomic.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/locale.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/locale_init.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/debug.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/locale_init.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/debug.o differs
make[2]: *** [compare] Error 1

Now, what do I do to (help) debug this?  Open a PR?  Attach some of the
object files (which)?  How do I know this is the same as (or different
from) ?

Note the comparison failure does not occur if I
- don't build from a combined tree (i.e., using binutils for Debian
  2.18.0.20080103), or
- turn off both of --enable-gold --enable-build-with-cxx (I cannot turn
  off the latter without turning off the former, see mail on gcc-patches.)

Thanks,
Ralf

Re: combined enable-build-with-cxx bootstrap comparison failure

[Dave Korn]

Ralf Wildenhues wrote:

> Comparing stages 2 and 3

> Bootstrap comparison failure!

> Now, what do I do to (help) debug this?  Open a PR?  Attach some of the
> object files (which)?  

  Well, ultimately, you could rebuild everything with --save-temps and take a
look at the .s files to see whether the difference in the .o files originates
there, or if it's purely a binutils problem - I'd imagine the former, and when
you see what the differences are you'll know where to look next.

> How do I know this is the same as (or different
> from) ?

  That will probably not be apparent until both bugs are analyzed a bit more.

cheers,
  DaveK

Anyone for slush?

[Dave Korn]

  Should we perhaps, again?  I'm having trouble fixing one bootstrap-breaking
bug because of a second one that's piled in on top of it right now; how is it
for other targets?

cheers,
  DaveK

RE: the cause of PR41260 is new additional epilog unwind information

[Joseph S. Myers]

On Fri, 18 Sep 2009, Jack Howarth wrote:

>I can confirm that the second proposed solution of passing 
> -Wl,-no_compact_unwind
> to the linkage of the g++.dg/torture/stackalign/eh-vararg-2.C test cases 
> eliminates
> the execution error on x86_64-apple-darwin10 so that option works. This leads 
> to a
> dejagnu question. I want to do a quick and dirty test to see that 
> -Wl,-no_compact_unwind
> suppresses all of the regressions that appeared at r147995, however I can't 
> puzzle out
> how to formulate...
> 
> make -k check RUNTESTFLAGS="--target_board=unix'{-Wl,-no_compact_unwind}'"
> 
> such that -Wl,-no_compact_unwind is interpreted as a single run with
> one flag being passed (ie not one run with -Wl and one run with
> -no_compact_unwind). Any ideas?

The -Xlinker spelling may be useful - try 
"--target_board=unix/-Xlinker/-no_compact_unwind".

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: i370 port

[Paul Edwards]

C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CON
FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I
../include
 varasm.c
(insn 117 429 118 7 (parallel [
(set (reg:SI 64)
(compare:SI (mem/s:BLK (plus:SI (reg/f:SI 21
virtual-stack-vars)

(const_int 456 [0x1c8])) [232 value+0 S196 
A64])

(mem:BLK (plus:SI (reg/v/f:SI 61 [ desc ])
(const_int 8 [0x8])) [0 A8])))
(use (const_int 196 [0xc4]))
]) -1 (nil)
(nil))
varasm.c: In function `force_const_mem':
varasm.c:3021: internal compiler error: in 
instantiate_virtual_regs_lossage,

at function.c:3767


OK, so what goes on here is that GCC attempts to replace the "virtual"
register 21 (virtual-stack-vars) with some real register, that is
frame pointer + STARTING_FRAME_OFFSET.  It seems for the i370 port,
this should resolve to
 register 13 + STACK_POINTER_OFFSET + current_function_outgoing_args_size

Overall, the middle-end would therefore replace "reg 21 + 456" with
"reg 13 + X", where X is constant computed from 456 + STACK_POINTER_OFFSET
+ current_function_outgoing_args_size.

It will then re-process the insn pattern constraints to verify that the
resulting insn is still valid.  At this stage, it appears we're running
into the above error.  I'm not quite sure why this would be case, this
will require some further debugging why the insn was not recognized ...


Ok, I spent today trying to solve this problem.  Although I didn't succeed
in solving it properly, I did at least find a workaround for the one 
instance.

I found that in the failing circumstance, neither of the two things being
compared fell into the "force copy" situation.  I don't know whether that
is right or wrong, but at least I can detect whether a "force copy" was
done.  If no force copy was done, I stop doing the short CLC and let
it do the CLCL instead.  See below where I have introduced the "copy"
variable.  Unfortunately it affects other things, ie good CLCs have been
converted into CLCL also, which is a shame.  However, it may at least
mean the compiler doesn't have a bug as far as the end user is
concerned, ie it generates valid code.

I have a theory that if both displacements in the S-type (ie register plus
displacement) address are non-zero, that something fails.  So the
next thing I will do is see if I can detect just that situation, and stop
it going into the CLC.

Some of these md constructs are beginning to make more sense.  :-)

BFN.  Paul.



;
; cmpmemsi instruction pattern(s).
;

(define_expand "cmpmemsi"
 [(set (match_operand:SI 0 "general_operand" "")
  (compare (match_operand:BLK 1 "general_operand" "")
(match_operand:BLK 2 "general_operand" "")))
(use (match_operand:SI 3 "general_operand" ""))
(use (match_operand:SI 4 "" ""))]
  ""
  "
{
 rtx op1, op2;
 int copy = 0;

 op1 = XEXP (operands[1], 0);
 if (GET_CODE (op1) == REG
 || (GET_CODE (op1) == PLUS && GET_CODE (XEXP (op1, 0)) == REG
  && GET_CODE (XEXP (op1, 1)) == CONST_INT
  && (unsigned) INTVAL (XEXP (op1, 1)) < 4096))
   {
 op1 = operands[1];
   }
 else
   {
 op1 = gen_rtx_MEM (BLKmode, copy_to_mode_reg (SImode, op1));
 copy = 1;
   }

 op2 = XEXP (operands[2], 0);
 if (GET_CODE (op2) == REG
 || (GET_CODE (op2) == PLUS && GET_CODE (XEXP (op2, 0)) == REG
  && GET_CODE (XEXP (op2, 1)) == CONST_INT
  && (unsigned) INTVAL (XEXP (op2, 1)) < 4096))
   {
 op2 = operands[2];
   }
 else
   {
 op2 = gen_rtx_MEM (BLKmode, copy_to_mode_reg (SImode, op2));
 copy = 1;
   }

 /* so long as at least one operand was copied, this seems safe */
 if (copy &&
 GET_CODE (operands[3]) == CONST_INT && INTVAL (operands[3]) < 256)
   {
 emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2,
 gen_rtx_SET (VOIDmode, operands[0],
  gen_rtx_COMPARE (SImode, op1, op2)), /* was VOIDmode */
 gen_rtx_USE (VOIDmode, operands[3];
   }
 else
   {
   /* implementation suggested by  Richard Henderson  
*/

   rtx reg1 = gen_reg_rtx (DImode);
   rtx reg2 = gen_reg_rtx (DImode);
   rtx result = operands[0];
   rtx mem1 = operands[1];
   rtx mem2 = operands[2];
   rtx len = operands[3];
   if (!CONSTANT_P (len))
 len = force_reg (SImode, len);

   /* Load up the address+length pairs.  */
   emit_insn (gen_rtx_CLOBBER (VOIDmode, reg1));
   emit_move_insn (gen_rtx_SUBREG (SImode, reg1, 0),
   force_operand (XEXP (mem1, 0), NULL_RTX));
   emit_move_insn (gen_rtx_SUBREG (SImode, reg1, GET_MODE_SIZE 
(SImode)), len);


   emit_insn (gen_rtx_CLOBBER (VOIDmode, reg2));
   emit_move_insn (gen_rtx_SUBREG (SImode, reg2, 0),
   force_operand (XEXP (mem2, 0), NULL_RTX));
   emit_move_insn (gen_rtx_SUBREG (SImode, reg2, GET_MODE_SIZE 
(SImode)), len);


   /* Compare! */
   emit_insn (gen_cmpmemsi_1 (result, reg1, reg2));
 

Re: Anyone for slush?

[NightStrike]

On Sat, Sep 19, 2009 at 5:51 AM, Dave Korn
 wrote:
>
>  Should we perhaps, again?  I'm having trouble fixing one bootstrap-breaking
> bug because of a second one that's piled in on top of it right now; how is it
> for other targets?
>
>    cheers,
>      DaveK
>
>

What is slush?

Re: Anyone for slush?

[Dave Korn]

NightStrike wrote:
> On Sat, Sep 19, 2009 at 5:51 AM, Dave Korn
>  wrote:
>>  Should we perhaps, again?  I'm having trouble fixing one bootstrap-breaking
>> bug because of a second one that's piled in on top of it right now; how is it
>> for other targets?
>>
>>cheers,
>>  DaveK
>>
>>
> 
> What is slush?

  A phase of development when we stop adding new code and merging new features
for a while and go into bug-fix only mode to let trunk stabilise when there
are significant numbers of high-impact open PRs impeding the smooth progress
of development.

  From the lack of a response I'd guess that most of the maintainers around
this morning are finding HEAD to be in a reasonably workable state for
whatever they're doing right now.

cheers,
  DaveK

Re: Anyone for slush?

[Dominique Dhumieres]

>   Should we perhaps, again?  I'm having trouble fixing one bootstrap-breaking
> bug because of a second one that's piled in on top of it right now; how is it
> for other targets?

Bad for darwin!-(bootstrap failing since at least r151822, see pr41405).
If you add pr41407+others, a slush should be applied untill the whole mess
is sorted out.

Just my 1c of advice.

Cheers

Dominique

Re: the cause of PR41260 is new additional epilog unwind information

[Peter O'Gorman]

Joseph S. Myers wrote:
> On Fri, 18 Sep 2009, Jack Howarth wrote:
> 
>>I can confirm that the second proposed solution of passing 
>> -Wl,-no_compact_unwind
>> to the linkage of the g++.dg/torture/stackalign/eh-vararg-2.C test cases 
>> eliminates
>> the execution error on x86_64-apple-darwin10 so that option works. This 
>> leads to a
>> dejagnu question. I want to do a quick and dirty test to see that 
>> -Wl,-no_compact_unwind
>> suppresses all of the regressions that appeared at r147995, however I can't 
>> puzzle out
>> how to formulate...
>>
>> make -k check RUNTESTFLAGS="--target_board=unix'{-Wl,-no_compact_unwind}'"
>>
>> such that -Wl,-no_compact_unwind is interpreted as a single run with
>> one flag being passed (ie not one run with -Wl and one run with
>> -no_compact_unwind). Any ideas?
> 
> The -Xlinker spelling may be useful - try 
> "--target_board=unix/-Xlinker/-no_compact_unwind".
> 

Or try building with this patch (it always adds -no_compact_unwind with
-lSystem for 10.6 and later, but beware mailer wrapping). I didn't test
it because mainline fails to build for me, dsymutil crashes so
'configure: error: cannot compute sizeof (long long)'.

Peter


Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h (revision 151878)
+++ gcc/config/darwin.h (working copy)
@@ -372,7 +372,9 @@

 /* Machine dependent libraries.  */

-#define LIB_SPEC "%{!static:-lSystem}"
+#define LIB_SPEC "%{!static:\
+   %:version-compare(>= 10.6 mmacosx-version-min=
-no_compact_unwind)  \
+   -lSystem}"

 /* Support -mmacosx-version-min by supplying different (stub)
libgcc_s.dylib
libraries to link against, and by not linking against libgcc_s on

Re: Anyone for slush?

[Angelo Graziosi]

Dave Korn wrote:

A phase of development when we stop adding new code and merging new features
for a while and go into bug-fix only mode to let trunk stabilise when there
are significant numbers of high-impact open PRs impeding the smooth progress
of development.


+1

Cheers,
Angelo.

Re: Anyone for slush?

[Joel Sherrill]

Dave Korn wrote:

NightStrike wrote:
  

On Sat, Sep 19, 2009 at 5:51 AM, Dave Korn
 wrote:


 Should we perhaps, again?  I'm having trouble fixing one bootstrap-breaking
bug because of a second one that's piled in on top of it right now; how is it
for other targets?

   cheers,
 DaveK


  

What is slush?



  A phase of development when we stop adding new code and merging new features
for a while and go into bug-fix only mode to let trunk stabilise when there
are significant numbers of high-impact open PRs impeding the smooth progress
of development.

  From the lack of a response I'd guess that most of the maintainers around
this morning are finding HEAD to be in a reasonably workable state for
whatever they're doing right now.

  

I need to get run baseline test results on 4.3 and 4.4 for C and
C++.  But the GNAT/RTEMS Ada results show a large number of
failures on the head that were not present in 4.3 and 4.4. 


SPARC and MIPS went from 2 to 319
x86 went from about 20 (mostly qemu issues) to 225

I emailed the list about it but given the number of
introduced failures and the fact the SPARC and MIPS
have the same failures, it leads me to believe something
is broken on the head.

So I would be +1.

--joel

Re: Anyone for slush?

[Eric Botcazou]

> I need to get run baseline test results on 4.3 and 4.4 for C and
> C++.  But the GNAT/RTEMS Ada results show a large number of
> failures on the head that were not present in 4.3 and 4.4.
>
> SPARC and MIPS went from 2 to 319
> x86 went from about 20 (mostly qemu issues) to 225

OK, but the number of Ada failures is exactly 0 on x86/Linux, x86-64/Linux, 
ia64/Linux, SPARC/Solaris and SPARC64/Solaris and 1 on PowerPC64/Linux so 
you'll have to find out why it's so different for RTEMS.

-- 
Eric Botcazou

Re: Anyone for slush?

[H.J. Lu]

On Sat, Sep 19, 2009 at 7:58 AM, Eric Botcazou  wrote:
>> I need to get run baseline test results on 4.3 and 4.4 for C and
>> C++.  But the GNAT/RTEMS Ada results show a large number of
>> failures on the head that were not present in 4.3 and 4.4.
>>
>> SPARC and MIPS went from 2 to 319
>> x86 went from about 20 (mostly qemu issues) to 225
>
> OK, but the number of Ada failures is exactly 0 on x86/Linux, x86-64/Linux,
> ia64/Linux, SPARC/Solaris and SPARC64/Solaris and 1 on PowerPC64/Linux so
> you'll have to find out why it's so different for RTEMS.
>

It may be:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395


-- 
H.J.

Re: Anyone for slush?

[Kai Tietz]

2009/9/19 H.J. Lu :
> On Sat, Sep 19, 2009 at 7:58 AM, Eric Botcazou  wrote:
>>> I need to get run baseline test results on 4.3 and 4.4 for C and
>>> C++.  But the GNAT/RTEMS Ada results show a large number of
>>> failures on the head that were not present in 4.3 and 4.4.
>>>
>>> SPARC and MIPS went from 2 to 319
>>> x86 went from about 20 (mostly qemu issues) to 225
>>
>> OK, but the number of Ada failures is exactly 0 on x86/Linux, x86-64/Linux,
>> ia64/Linux, SPARC/Solaris and SPARC64/Solaris and 1 on PowerPC64/Linux so
>> you'll have to find out why it's so different for RTEMS.
>>
>
> It may be:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395

And http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39886

Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: Anyone for slush?

[Laurent GUERBY]

On Sat, 2009-09-19 at 16:58 +0200, Eric Botcazou wrote:
> > I need to get run baseline test results on 4.3 and 4.4 for C and
> > C++.  But the GNAT/RTEMS Ada results show a large number of
> > failures on the head that were not present in 4.3 and 4.4.
> >
> > SPARC and MIPS went from 2 to 319
> > x86 went from about 20 (mostly qemu issues) to 225
> 
> OK, but the number of Ada failures is exactly 0 on x86/Linux, x86-64/Linux, 
> ia64/Linux, SPARC/Solaris and SPARC64/Solaris and 1 on PowerPC64/Linux so 
> you'll have to find out why it's so different for RTEMS.

Joel reported results for 4.5.0 20090910 r151592 and state of GCC
changed a lot in the past 9 days. RTEMS is also a sjlj target IIRC.

Sincerely,

Laurent

Re: Anyone for slush?

[Eric Botcazou]

> Joel reported results for 4.5.0 20090910 r151592 and state of GCC
> changed a lot in the past 9 days. RTEMS is also a sjlj target IIRC.

Then, if EH is totally broken, a PR should be opened with a reduced testcase.

-- 
Eric Botcazou

Re: Anyone for slush?

[Joel Sherrill]

Laurent GUERBY wrote:

On Sat, 2009-09-19 at 16:58 +0200, Eric Botcazou wrote:
  

I need to get run baseline test results on 4.3 and 4.4 for C and
C++.  But the GNAT/RTEMS Ada results show a large number of
failures on the head that were not present in 4.3 and 4.4.

SPARC and MIPS went from 2 to 319
x86 went from about 20 (mostly qemu issues) to 225
  
OK, but the number of Ada failures is exactly 0 on x86/Linux, x86-64/Linux, 
ia64/Linux, SPARC/Solaris and SPARC64/Solaris and 1 on PowerPC64/Linux so 
you'll have to find out why it's so different for RTEMS.



  

On what date?

Joel reported results for 4.5.0 20090910 r151592 and state of GCC
changed a lot in the past 9 days. RTEMS is also a sjlj target IIRC.

  

Laurent.. are you suggesting that it might have improved
in the past 9 days?  That I should rerun with the latest GCC
and report again?

--joel

Sincerely,

Laurent



  

Re: Anyone for slush?

[Joel Sherrill]

Eric Botcazou wrote:

Joel reported results for 4.5.0 20090910 r151592 and state of GCC
changed a lot in the past 9 days. RTEMS is also a sjlj target IIRC.



Then, if EH is totally broken, a PR should be opened with a reduced testcase.

  

I will rebuild with the head and run ACATS on
one of the broken ones.  If still bad, then
I will try with some simple exception tests
Laurent put together the last time it broke.
Maybe they are useful again. :)

--joel

Re: Anyone for slush?

[Eric Botcazou]

> I will rebuild with the head and run ACATS on
> one of the broken ones.  If still bad, then
> I will try with some simple exception tests
> Laurent put together the last time it broke.
> Maybe they are useful again. :)

Were they added to the gnat.dg testsuite?  If no, they should.

-- 
Eric Botcazou

Re: Anyone for slush?

[Eric Botcazou]

> On what date?

See http://gcc.gnu.org/ml/gcc-testresults/2009-09

-- 
Eric Botcazou

Re: Anyone for slush?

[Paolo Bonzini]

And http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39886


This one is relatively rare, so no.  Feel free to pick up the patch, I 
already have too many approved patches that I cannot get round to test 
and commit.


Paolo

Re: the cause of PR41260 is new additional epilog unwind information

[Richard Guenther]

On Fri, 18 Sep 2009, Jack Howarth wrote:

> Richard,
>We have an analysis on the cause of the breakage of
> exception handling at r147995 on x86_64-apple-darwin10 (PR41260)...
> 
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025908.html
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025909.html
> 
> The additional epilog unwind information is breaking the
> 'running' of the dwarf unwind info. The options to fix it are either
> to 1) not add epilog unwind information for Darwin or 2) have the
> gcc driver implicitly add -no_compact_unwind to the link line for
> Darwin.
>Can you propose a patch to achieve the first solution of not
> adding the additional epilog unwind information on darwin so I
> can test that solution? Thanks in advance.

I'm the wrong Richard to address here.

Richard.

GCC 4.5 Status Report (2009-09-19)

[Richard Guenther]

Status
==

The trunk is in Stage 1.  Stage 1 will end on Sep 30th.  After Stage 1
Stage 3 follows with only bugfixes and no new features allowed. 
Stage 3 will end Nov 30th.

Since the last status report we have merged the VTA branch and pieces
of the LTO branch.  The named address-spaces changes are still pending
review but I expect it to be merged before the end of Stage 1.
The rest of the LTO branch will be merged last, which practically
means after Stage 1 is over.  Thus, starting Oct 1st the trunk will
be frozen for the LTO merge and I'll announce Stage 3 once the merge
is completed.

There are still new ports pending review and approval.  As usual
new ports can be accepted also during Stage 3.

We've been accumulating quite a number of P1 bugs.  Entering Stage 3
should allow to improve considerably here in a short time.

Quality Data


Priority  # Change from Last Report
--- ---
P1   22 + 6
P2  111 + 7
P36 + 6
--- ---
Total   139 +19

Previous Report
===

http://gcc.gnu.org/ml/gcc/2009-08/msg00427.html

The next report will be sent by me announcing Stage 3 begin.

-- 
Richard Guenther 
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

Re: GCC 4.5 Status Report (2009-09-19)

[Steven Bosscher]

On Sat, Sep 19, 2009 at 10:57 PM, Richard Guenther  wrote:
> Since the last status report we have merged the VTA branch and pieces
> of the LTO branch.  The named address-spaces changes are still pending
> review but I expect it to be merged before the end of Stage 1.
> The rest of the LTO branch will be merged last, which practically
> means after Stage 1 is over.  Thus, starting Oct 1st the trunk will
> be frozen for the LTO merge and I'll announce Stage 3 once the merge
> is completed.

Is there a set of release criteria for all these major new features?
For example:

* testsuite for C/C++/Fortran should pass with LTO

* idem with WHOPR?

* GDB test suite should pass with -O1

* SPEC should pass with graphite

* ...


Also, IMHO a new requirement should be added for merging big new
features: Update changes.html.  As usual for the last, say, 4
releases, most of the interesting new features are not yet described
in the changes.html for the upcoming release (see
http://gcc.gnu.org/gcc-4.5/changes.html).

Ciao!
Steven

Re: GCC 4.5 Status Report (2009-09-19)

[Richard Guenther]

On Sun, 20 Sep 2009, Steven Bosscher wrote:

> On Sat, Sep 19, 2009 at 10:57 PM, Richard Guenther  wrote:
> > Since the last status report we have merged the VTA branch and pieces
> > of the LTO branch.  The named address-spaces changes are still pending
> > review but I expect it to be merged before the end of Stage 1.
> > The rest of the LTO branch will be merged last, which practically
> > means after Stage 1 is over.  Thus, starting Oct 1st the trunk will
> > be frozen for the LTO merge and I'll announce Stage 3 once the merge
> > is completed.
> 
> Is there a set of release criteria for all these major new features?
> For example:
> 
> * testsuite for C/C++/Fortran should pass with LTO
> * idem with WHOPR?

Worthwhile goals.  It mostly does.

> * GDB test suite should pass with -O1

Which GDB version?

> * SPEC should pass with graphite
> 
> * ...

There will be bugs in new features, but not merging them will not
make you know them.  The premise is of course that a new feature
is usable within documented constraints.

> Also, IMHO a new requirement should be added for merging big new
> features: Update changes.html.

Yes.  Well, updating changes.html before the release.  Note that
changes.html is for user visible changes - that may or may not apply
for VTA (we don't document every new command-line flag in changes.html).

> As usual for the last, say, 4
> releases, most of the interesting new features are not yet described
> in the changes.html for the upcoming release (see
> http://gcc.gnu.org/gcc-4.5/changes.html).

Bugs for omissions are certainly welcome, likewise patches to fix them.

Thanks,
Richard.

Running gcc testsuite outside of gcc's sourcetree.

[Nicolas Noble]

Hello,

  Long story short, I'm looking for a way to test a distribution's
compiler by running the latest gcc testsuite on it, but so far, I've
only seem to run it on the same gcc sourcetree it's on. I actually
wonder if it's possible and/or relevant to do this on the
distribution's compiler.

  My problem resides in RedHat's gcc (which version seems to be gcc
(GCC) 4.1.2 20071124 (Red Hat 4.1.2-42)). I recently discovered that
this compiler hosts a bunch of known gcc bugs that have been reported
and fixed in the gcc mainstream, but it seems the bugfixes never got
ported back in RedHat's.

  Now only one of these bugs bit me, and bit me hard, and that's how I
discovered the whole thing. I manually ran a bunch of the testcases in
the gcc testsuite, and I already found 15 bugs active there. But
running of all them by hand is difficult and painful, but I don't see
how to do that automatically on the system's compiler from the
testsuite's documentation. My ultimate goal is to evaluate to which
extend I can trust this compiler, and use these results to convince my
management that we're most probably going to face a lot more trouble
if we continue using a compiler that's containing known bugs.

  Is it possible to run the testsuite on the system's compiler ? I've
seen that some of the testcases might not be relevant as they're
trying to check some of gcc's new features that might not be in that
old version. Or would there be another, simpler testsuite I could run
natively ?

  Thanks!

  -- Nicolas Noble

Re: Running gcc testsuite outside of gcc's sourcetree.

[Dave Korn]

Nicolas Noble wrote:

>   Is it possible to run the testsuite on the system's compiler ?

  See contrib/test_installed

cheers,
  DaveK

Re: GCC 4.5 Status Report (2009-09-19)

[Jack Howarth]

On Sat, Sep 19, 2009 at 10:57:38PM +0200, Richard Guenther wrote:
> 
> We've been accumulating quite a number of P1 bugs.  Entering Stage 3
> should allow to improve considerably here in a short time.
> 

Richard,
   Will the graphite code be under strict stage 3 rules or will it
have more leeway under stage 3? We still aren't seeing uniform code
improvements from graphite in benchmarks yet and it would be a shame
to postpone that until gcc 4.6.
 Jack

Re: GCC 4.5 Status Report (2009-09-19)

[Geert Bosch]

On Sep 19, 2009, at 18:02, Steven Bosscher wrote:

* GDB test suite should pass with -O1


Apparently, the current GDB test suite can only work at -O0,
because code reorganization messes up the scripting.

  -Geert

Re: GCC 4.5 Status Report (2009-09-19)

[Dave Korn]

Richard Guenther wrote:

> The trunk is in Stage 1.  Stage 1 will end on Sep 30th.  After Stage 1
> Stage 3 follows with only bugfixes and no new features allowed. 
> Stage 3 will end Nov 30th.

  I don't think this is the best time to do that.  Trunk's been broken most of
last week and will probably not be buildable for at least several days yet, so
a big chunk of that warning period is going to be useless to many people.

> We've been accumulating quite a number of P1 bugs.  Entering Stage 3
> should allow to improve considerably here in a short time.

  So aren't we now likely to lose the first few days of what little remains of
stage 1 waiting for trunk to start working again, then have a mad rush of
people falling all over each other to get their new features in in the last
couple of days?  One of which will inevitably break trunk again and block all
the others and then stage 1 will be over and it'll all be too late?

  Ten days isn't even that much warning in the first place; it's less time
than you'd generally let elapse before pinging a patch.  Can I at least raise
the suggestion that a plan that might work well would be for us to go slush
for however long - less than a week, I'd suppose - it takes us to get trunk
really properly stable, and then push back the end of stage 1 by that amount?

cheers,
  DaveK

Re: Running gcc testsuite outside of gcc's sourcetree.

[Jeff Law]

On 09/19/09 18:14, Nicolas Noble wrote:

Hello,

   Long story short, I'm looking for a way to test a distribution's
compiler by running the latest gcc testsuite on it, but so far, I've
only seem to run it on the same gcc sourcetree it's on. I actually
wonder if it's possible and/or relevant to do this on the
distribution's compiler.
   
It's certainly possible.  Under the hood the Makefile just invokes 
runtest.  I don't think people do this that often anymore, so you might 
have to set some environment variables and/or set some paths, but when 
it's all said and done you can probably do something like


cd /gcc/testsuite
runtest --tool=gcc
runtest --tool=g++

Which should run the gcc & g++ testsuites with your system compiler.


   My problem resides in RedHat's gcc (which version seems to be gcc
(GCC) 4.1.2 20071124 (Red Hat 4.1.2-42)). I recently discovered that
this compiler hosts a bunch of known gcc bugs that have been reported
and fixed in the gcc mainstream, but it seems the bugfixes never got
ported back in RedHat's.
   
The fact of the matter is that every compiler has bugs.  Backporting 
every bugfix to old releases isn't practical, particularly if the fix 
has the potential to introduce new regressions.  It's a balancing act 
our engineers deal with daily.  Customers (of course) have input into 
how we balance those decisions, and if you are a customer I would 
strongly encourage you to file a bug report with Red Hat.



Jeff

question about speculative scheduling in gcc

[Amker.Cheng]

Hi :
I'm puzzled when looking into speculative scheduling in gcc, the 4.2.4 version.

First, I noticed the document describing IBM haifa instruction
scheduler(as PowerPC Reference Compiler Optimization Project).

It presents that the instruction motion from bb s(dominated by t)
to t is speculative when split_blocks(s, t) not empty.

Second, There is SCED_FLAGS like DO_SPECULATION in codes.

Here goes questions.
1, Does the DO_SPECULATION flag constrol whether do the
mentioned speculative motion or not?
2, For mips target, which has the DO_SPECULATION bit cleared,
gcc still does speculative motion when scheduling(first pass),
so it seems the answer of question 1 is negative, but then
what the DO_SPECULATION flag for?

I must have missed something important, Please help out.
Thanks

-- 
Best Regards.