Solaris 8/SPARC bootstrap broken building 64-bit libgcc

Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Rainer Orth]

Current mainline fails to bootstrap on bi-arch sparc-sun-solaris2.8:

/vol/gcc/obj/gcc-3.4-20030704/8-gcc/gcc/xgcc -B/vol/gcc/obj/gcc-3.4-20030704/8-gcc/gcc/ -B/vol/gcc/share/sparc-sun-solaris2.8/bin/ -B/vol/gcc/share/sparc-sun-solaris2.8/lib/ -isystem /vol/gcc/share/sparc-sun-solaris2.8/include -isystem /vol/gcc/share/sparc-sun-solaris2.8/sys-include -O2  -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I/vol/gnu/src/gcc/gcc-dist/gcc -I/vol/gnu/src/gcc/gcc-dist/gcc/. -I/vol/gnu/src/gcc/gcc-dist/gcc/config -I/vol/gnu/src/gcc/gcc-dist/gcc/../include  -m64 -DL__gcc_bcmp -c /vol/gnu/src/gcc/gcc-dist/gcc/libgcc2.c -o libgcc/sparcv9/__gcc_bcmp.o
/vol/gcc/obj/gcc-3.4-20030704/8-gcc/gcc/xgcc -B/vol/gcc/obj/gcc-3.4-20030704/8-gcc/gcc/ -B/vol/gcc/share/sparc-sun-solaris2.8/bin/ -B/vol/gcc/share/sparc-sun-solaris2.8/lib/ -isystem /vol/gcc/share/sparc-sun-solaris2.8/include -isystem /vol/gcc/share/sparc-sun-solaris2.8/sys-include -O2  -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I/vol/gnu/src/gcc/gcc-dist/gcc -I/vol/gnu/src/gcc/gcc-dist/gcc/. -I/vol/gnu/src/gcc/gcc-dist/gcc/config -I/vol/gnu/src/gcc/gcc-dist/gcc/../include  -m64 -DL_gcov -c /vol/gnu/src/gcc/gcc-dist/gcc/libgcov.c -o libgcc/sparcv9/_gcov.o
/vol/gnu/src/gcc/gcc-dist/gcc/libgcc2.c: In function `__gcc_bcmp':
/vol/gnu/src/gcc/gcc-dist/gcc/libgcc2.c:1519: error: head insn 102 for block 0 not found in the insn stream
/vol/gnu/src/gcc/gcc-dist/gcc/libgcc2.c:1519: internal compiler error: Segmentation Fault

The current state of mainline gets increasingly annoying: it's almost
impossible to get any work done when at any random time at least one of
your platforms doesn't bootstrap at all, while more often than not most of
them don't.  I spend more time tracking down the culprit patches than
anything else ;-(

	Rainer

-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Andrew Pinski]

On Friday, Jul 4, 2003, at 08:51 US/Eastern, Rainer Orth wrote:

> Current mainline fails to bootstrap on bi-arch sparc-sun-solaris2.8:
>
> /vol/gcc/obj/gcc-3.4-20030704/8-gcc/gcc/xgcc 
> -B/vol/gcc/obj/gcc-3.4-20030704/8-gcc/gcc/ 
> -B/vol/gcc/share/sparc-sun-solaris2.8/bin/ 
> -B/vol/gcc/share/sparc-sun-solaris2.8/lib/ -isystem 
> /vol/gcc/share/sparc-sun-solaris2.8/include -isystem 
> /vol/gcc/share/sparc-sun-solaris2.8/sys-include -O2  -DIN_GCC    -W 
> -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes 
> -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 
> -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I/vol/gnu/src/gcc/gcc-dist/gcc 
> -I/vol/gnu/src/gcc/gcc-dist/gcc/. 
> -I/vol/gnu/src/gcc/gcc-dist/gcc/config 
> -I/vol/gnu/src/gcc/gcc-dist/gcc/../include  -m64 -DL__gcc_bcmp -c 
> /vol/gnu/src/gcc/gcc-dist/gcc/libgcc2.c -o libgcc/sparcv9/__gcc_bcmp.o
> /vol/gcc/obj/gcc-3.4-20030704/8-gcc/gcc/xgcc 
> -B/vol/gcc/obj/gcc-3.4-20030704/8-gcc/gcc/ 
> -B/vol/gcc/share/sparc-sun-solaris2.8/bin/ 
> -B/vol/gcc/share/sparc-sun-solaris2.8/lib/ -isystem 
> /vol/gcc/share/sparc-sun-solaris2.8/include -isystem 
> /vol/gcc/share/sparc-sun-solaris2.8/sys-include -O2  -DIN_GCC    -W 
> -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes 
> -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 
> -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I/vol/gnu/src/gcc/gcc-dist/gcc 
> -I/vol/gnu/src/gcc/gcc-dist/gcc/. 
> -I/vol/gnu/src/gcc/gcc-dist/gcc/config 
> -I/vol/gnu/src/gcc/gcc-dist/gcc/../include  -m64 -DL_gcov -c 
> /vol/gnu/src/gcc/gcc-dist/gcc/libgcov.c -o libgcc/sparcv9/_gcov.o
> /vol/gnu/src/gcc/gcc-dist/gcc/libgcc2.c: In function `__gcc_bcmp':
> /vol/gnu/src/gcc/gcc-dist/gcc/libgcc2.c:1519: error: head insn 102 for 
> block 0 not found in the insn stream
> /vol/gnu/src/gcc/gcc-dist/gcc/libgcc2.c:1519: internal compiler error: 
> Segmentation Fault
>
> The current state of mainline gets increasingly annoying: it's almost
> impossible to get any work done when at any random time at least one of
> your platforms doesn't bootstrap at all, while more often than not 
> most of
> them don't.  I spend more time tracking down the culprit patches than
> anything else ;-(

Actually the patch which causes this error is causing most platforms to 
die while bootstrapping,
those who do not die via bootstrapping have regression.
No need to track this one down I as tracked it down as soon as the 
regression tester died:
The patch which causes this is:
+Thu Jul  3 20:36:47 CEST 2003  Jan Hubicka  <jh@suse.cz>
+
+	* basic-block.h (create_basic_block, merge_blocks_nomove): Kill.
+	* cfgcleanup.c (merge_blocks): Rename to merge_blocks_move.
+	(merge_blocks_move_predecessor_nojumps,
+	 merge_blocks_move_successor_nojumps): Use merge_blocks.
+	(try_optimize_cfg): Use merge_blocks_move.
+	* cfgrtl.c (create_basic_block): Rename to rtl_create_basic_block.
+	(merge_blocks_nomove): Rename to rtl_merge_blocks.
+	(cfg_layout_create_basic_block): New.
+	(rtl_can_merge_blocks): New.
+	(cfg_layout_split_block): Do not alloc aux by hand.
+	* cfghooks.h (cfg_hooks): Add create_basic_block, can_merge_blocks_p,
+	merge_blocks.
+	(create_basic_block, can_merge_blocks_p, merge_blocks): New macros.
+	* cfglayout.c (cfg_layout_duplicate_bb): Do not allocate aux by hand.
+	* cfgloopmanip.c (loop_split_edge_with): Likewise.
+	* ifcvt.c (merge_if_block): Use merge_blocks_nomove.
+
+	* basic-block.h (basic_block_def): Add field 'rbi'.
+	* bb-reorder.c (find_traces, rotate_loop, mark_bb_visited,
+	find_traces_1_round, copy_bb, connect_traces): Update use of rbi.
+	* cfg.c (entry_exit_blocks): Add new field.
+	* cfglayout.c: Include alloc-pool.h;
+	(cfg_layout_pool): New.
+	(record_effective_endpoints, fixup_reorder_chain,
+	fixup_fallthru_exit_predecessor, cfg_layout_duplicate_bb): Update use
+	of rbi.
+	(cfg_layout_initialize_rbi): New function.
+	(cfg_layout_initialize): Use it.
+	(cfg_layout_finalize): Clear rbi fields.
+	* cfglayout.h (RBI): Kill.
+	(cfg_layout_initialize_rbi): Declare.
+	* cfgloopmanip.c (copy_bbs): Use rbi.
+	(record_exit_edges): Likewise.
+	(duplicate_loop_to_header_edge): Likewise.
+	* cfgrtl.c (cfg_layout_create_basic_block): Use
+	cfg_layout_initialize_rbi.
+	(cfg_layout_split_block): Use rbi.
+	(cfg_layout_delete_block): Likewise.
+	* loop-init.c (loop_optimizer_finalize): Likewise.
+	* loop-unswitch.c (unswitch_loop): Likewise.
+	* tracer.c (seen, tail_duplicate, layout_superblocks): Likewise.
+
+	* cfgrtl.c: Update comments.
+	(try_redirect_by_replacing_jump): New argument.
+	(redirect_branch_edge): Break out from ...
+	(rtl_redirect_edge_and_branch): ... this one.
+	(update_cfg_after_block_merging): Break out from ...
+	(rtl_merge_blocks): ... this one.
+	(cfg_layout_split_edge): New.
+	(cfg_layout_merge_blocks): New.
+	(cfg_layout_can_merge_blocks_p): New.
+	(cfg_layout_redirect_edge_and_branch): Reorganize.
+	(cfg_layout_rtl_cfg_hooks): Fill in.
+	(cfg_layout_delete_block): Kill barriers.
+	* cfganal.c (can_fallthru): Deal with exit blocks
+	* cfglayout.c (cfg_layout_function_header): New function
+	(record_effective_endpoints): Record function header.
+	(fixup_reorder_chain): Fixup dead jumptables; place header
+
+	* basic-block.h (CLEANUP_CFGLAYOUT): New flag.
+	* bb-reorder.c (cfg_layout_initialize): Update call.
+	* cfgcleanup.c (try_optimize_cfg): Supress optimizations of fallthru
+	edges in cfglayout mode.
+	* cfglayout.c (cleanup_unconditional_jumps): Kill.
+	(cfg_layout_initialize): Kill agrument loops; use cfgcleanup.
+	* cfglayout.h (cfg_layout_initialize): Update prototype.
+	* cfgloop.h (CP_INSIDE_CFGLAYOUT): Kill.
+	* cfgloopmanip.c (loop_split_edge_with): Use split_edge.
+	* flow.c (propagate_block): Do not crash when basic block ends
+	by first insn in the chain.
+	* loop-init.c (loop_optimizer_init):  First enter cfglayout mode; 
later
+	do loop discovery.
+	* tracer.c (tracer): Update call of cfg_layout_initialize.

Thanks,
Andrew Pinski

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Phil Edwards]

On Fri, Jul 04, 2003 at 02:51:42PM +0200, Rainer Orth wrote:
> The current state of mainline gets increasingly annoying: it's almost
> impossible to get any work done when at any random time at least one of
> your platforms doesn't bootstrap at all, while more often than not most of
> them don't.

3.3 went out the door with some amazing problems; I'm just now discovering
them for myself.  I submit that, at present, the following statement is
essentially true.

    The sparc-sun-solaris2.* platform is not supported.

Proving this statement false would be wonderful.  A number of people
have been tirelessly hunting down bugs (most recently, yourself and Eric
Botcazou).  The expanding time required for a build-and-test cycle is
what's defeating us.

For unrelated reasons, I need to try and build an x86/linux to s-s-s cross
compiler.  If it works, I might try doing that regularly, on hardware that
can finish a cycle in a reasonable amount of time.


> I spend more time tracking down the culprit patches than

Possibly the only thing that can help here are more autobuilders, running
in a tighter cycle (i.e., fewer number of patches between runs).  Anybody
have spare Suns...?


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Eric Botcazou]

> 3.3 went out the door with some amazing problems; I'm just now discovering
> them for myself.  I submit that, at present, the following statement is
> essentially true.
>
>     The sparc-sun-solaris2.* platform is not supported.

That's a bit unfair. You haven't cared about this platform for some time, 
suddendly you decide to give it a try and you run into some problems. This 
is to be expected on this platform, they are many nits to overcome. Instead 
of trying to understand them, you say that everything is broken.

You seem to be using a non-standard configuration (for example, I skimmed 
through dozen and dozen of bug reports for Solaris and never saw the 'sed' 
problem reported; you use bash to bootstrap, we explicitly recommend ksh).
Because of the shortage of resources, we are forced to support only a single 
procedure.

You reported that GCC 3.3 wasn't able to bootstrap itself and aborted with 
the exact same error as GCC 3.0.2. I answered that GCC 3.3 is able to 
bootstrap the current 3.3 branch and that you might not have properly 
reconfigured. Did you try another time?

You reported some installation problems with multilibs. I submitted a patch 
three weeks before the 3.3 release, but it was not reviewed quickly enough 
and missed the release.

Sure, sparc-sun-solaris2.* is not a first-class platform and the .0 releases
are very likely to have many regressions. But they will eventually be 
squashed in the subsequent .x releases. And take a look at the testsuite 
results on the 3.3 branch, they are on par with those of mainstream 
platforms.

> Proving this statement false would be wonderful.  A number of people
> have been tirelessly hunting down bugs (most recently, yourself and Eric
> Botcazou).  The expanding time required for a build-and-test cycle is
> what's defeating us.

Simply the lack of testing I'd say. The mainline is simply not tested on 
SPARC for development, period. So it is very likely that, during phase1, the 
platform will badly regress. So be it. In the meantime, we are fixing the 
most serious regressions on the branch.

-- 
Eric Botcazou

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Phil Edwards]

On Sat, Jul 05, 2003 at 12:52:25AM +0200, Eric Botcazou wrote:
> > 3.3 went out the door with some amazing problems; I'm just now discovering
> > them for myself.  I submit that, at present, the following statement is
> > essentially true.
> >
> >     The sparc-sun-solaris2.* platform is not supported.
> 
> That's a bit unfair. You haven't cared about this platform for some time, 
> suddendly you decide to give it a try and you run into some problems.

It has nothing to do with caring.  I didn't have a sparc "for some time."
Now I do.


> is to be expected on this platform, they are many nits to overcome. Instead 
> of trying to understand them, you say that everything is broken.

I do understand them.  They /are/ broken.  (Well, except for the preprocessor
one.  I don't understand that bug at all.)


> You seem to be using a non-standard configuration (for example, I skimmed 
> through dozen and dozen of bug reports for Solaris and never saw the 'sed' 
> problem reported; you use bash to bootstrap, we explicitly recommend ksh).
> Because of the shortage of resources, we are forced to support only a single 
> procedure.

I reported the sed problem well before 3.3.  It's in the mailing lists.

If using the most recent version of bash instead of ksh88 introduces more
problems, then that's another bug, and we need to explicity note that bash
is not to be used (even though it's recommended for other platforms).


> You reported that GCC 3.3 wasn't able to bootstrap itself and aborted with 
> the exact same error as GCC 3.0.2. I answered that GCC 3.3 is able to 
> bootstrap the current 3.3 branch and that you might not have properly 
> reconfigured. Did you try another time?

It wasn't reconfigured.  (I don't reconfigure troublesome trees.  I kill
them and start over.)  It was a brand new empty build directory.


> You reported some installation problems with multilibs. I submitted a patch 
> three weeks before the 3.3 release, but it was not reviewed quickly enough 
> and missed the release.

Pity.  Well, at least it's in now.


> Simply the lack of testing I'd say. The mainline is simply not tested on 
> SPARC for development, period.

Exactly.  That's why I made the statement I did.


> So it is very likely that, during phase1, the 
> platform will badly regress. So be it. In the meantime, we are fixing the 
> most serious regressions on the branch.

With any luck, I'll be able to start testing the trunk again.  If I retain
access to a SPARC, of course.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Eric Botcazou]

> I reported the sed problem well before 3.3.  It's in the mailing lists.

Did you file a PR by that time?

> > Simply the lack of testing I'd say. The mainline is simply not tested on
> > SPARC for development, period.
>
> Exactly.  That's why I made the statement I did.

Ok, but between "The mainline is simply not tested on SPARC for development" 
and "The sparc-sun-solaris2.* platform is not supported", there is room for 
a more balanced statement.

> With any luck, I'll be able to start testing the trunk again.  If I retain
> access to a SPARC, of course.

Kaveh already tests the trunk regularly, both on SPARC and SPARC64, so we 
have a pretty good picture of which (sets of) patches break what on the 
platforms. I sometimes use his results to bug developers about new problems 
(for example, Mark quickly fixed the minor problems his overhaul of the 
testsuite had introduced) but we can't permanently do that, otherwise the 
responsiveness will quickly decrease.

In any cases, mores testing is always welcome!

-- 
Eric Botcazou

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Gerald Pfeifer]

On Sat, 5 Jul 2003, Eric Botcazou wrote:
> Sure, sparc-sun-solaris2.* is not a first-class platform and the .0 releases
> are very likely to have many regressions.

sparc-sun-solaris2.7 is a primary evaluation platform for our releases
and as such should be regression tested before releases without any
regressions.

(I know that the situation for SPARC as well as Solaris hasn't been
perfect, but your strong efforts to fix that certainly were very
noticable!)

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Phil Edwards]

On Mon, Jul 07, 2003 at 12:10:19AM +0200, Gerald Pfeifer wrote:
> On Sat, 5 Jul 2003, Eric Botcazou wrote:
> > Sure, sparc-sun-solaris2.* is not a first-class platform and the .0 releases
> > are very likely to have many regressions.
> 
> sparc-sun-solaris2.7 is a primary evaluation platform for our releases
> and as such should be regression tested before releases without any
> regressions.

I've been meaning to ask Kaveh about this, but since the subject has come up:

Given an cross compiler hosted x86-linux targeting s-s-s2.*, has anyone
ever found a way to run the testsuite?  Doesn't look like dejagnu or sim
are set up for that.  Obviously there will be no open source UltraSPARC
simulators, but are there any chips "close enough"?


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Eric Botcazou]

> sparc-sun-solaris2.7 is a primary evaluation platform for our releases
> and as such should be regression tested before releases without any
> regressions.

3.3.0 had no testsuite regressions over 3.2.3, except for a few ones in 
libjava. Yet it miscompiles GNU tar, GNU emacs and ICE on KDE 3.1.2, which 
were correctly compiled by 3.2.3 AFAIK.

This platform is not as much exercised as the others before the .0 releases, 
so this is probably unavoidable.

> (I know that the situation for SPARC as well as Solaris hasn't been
> perfect, but your strong efforts to fix that certainly were very
> noticable!)

Thanks!

-- 
Eric Botcazou

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Eric Botcazou]

> 3.3.0 had no testsuite regressions over 3.2.3, except for a few ones in
> libjava. Yet it miscompiles GNU tar, GNU emacs and ICE on KDE 3.1.2, which
> were correctly compiled by 3.2.3 AFAIK.

Correction: it doesn't technically miscompile GNU Emacs 21.3 (the primary 
executable is clean) but Emacs uses a PCH-like mechanism that makes 
assumptions about the contents of the .data and .bss sections, which are not 
valid anymore for GCC 3.3.x.

-- 
Eric Botcazou

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Jeff Sturm]

On Mon, 7 Jul 2003, Gerald Pfeifer wrote:
> sparc-sun-solaris2.7 is a primary evaluation platform for our releases
> and as such should be regression tested before releases without any
> regressions.

Has there been any thought given to bumping this requirement to some
non-ancient release like Solaris 8 or 9?  I for one haven't had access to
a 2.7 machine in nearly two years.

The differences can be significant, as evidenced by a late fix prior to
releasing 3.3.  (Of course we wouldn't like to introduce regressions on
any release, but in practice it's becoming difficult to support anything
prior to 2.7 now.  Similarly, on GNU/Linux certain old glibc releases are
gradually being dropped as I understand it.)

Jeff

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Gerald Pfeifer]

On Sun, 6 Jul 2003, Jeff Sturm wrote:
>> sparc-sun-solaris2.7 is a primary evaluation platform for our releases
>> and as such should be regression tested before releases without any
>> regressions.
> Has there been any thought given to bumping this requirement to some
> non-ancient release like Solaris 8 or 9?  I for one haven't had access to
> a 2.7 machine in nearly two years.

Good point.  Concerning version updates on other platforms we have been
"liberal" in the past (not requiring Steering Committee intervention or
some such), so I'm Cc:ing Mark.

> The differences can be significant, as evidenced by a late fix prior to
> releasing 3.3.  (Of course we wouldn't like to introduce regressions on
> any release, but in practice it's becoming difficult to support anything
> prior to 2.7 now.

Mark, how about updating sparc-sun-solaris2.7 to sparc-sun-solaris2.8?

I agree that this looks like a god idea.

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Mark Mitchell]

> > The differences can be significant, as evidenced by a late fix prior to
> > releasing 3.3.  (Of course we wouldn't like to introduce regressions on
> > any release, but in practice it's becoming difficult to support anything
> > prior to 2.7 now.
> 
> Mark, how about updating sparc-sun-solaris2.7 to sparc-sun-solaris2.8?

That makes sense to me!

> I agree that this looks like a god idea.

Well, good at least.  :-)

> Gerald
-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Release criteria (was: PATCH for Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc)

[Gerald Pfeifer]

[ gcc->gcc-patches, Cc: trimmed ]

On Wed, 9 Jul 2003, Rainer Orth wrote:
> Besides, aside from news.html (with a link to gcc-3.1/criteria.html), there
> seems to be no link to any of those criteria.html files at all ;-(  They
> certainly need to be linked somewhere so this information is not only found
> by accident.

I intentionally didn't link any criterial.html file from a prominent place
because it was clear (to me) that the criteria were not really up-to-date
and we were not taking them really serious as far as performing the various
tests are concerned.

That's something we should revisit for 3.4 after 3.3.1 is out the door,
and in fact I suspect that Mark will want to suggest some updated criteria
for GCC 3.4, so I think we ought to defer the creating of
 http://gcc.gnu.org/gcc-3.4/criteria.html
until then.

(If Mark tells me otherwise, I'll of course copy over the previous
criteria and link them from the main page right away.)

Gerald

Re: Release criteria (was: PATCH for Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc)

[Mark Mitchell]

On Mon, 2003-07-14 at 07:48, Gerald Pfeifer wrote:
> [ gcc->gcc-patches, Cc: trimmed ]
> 
> On Wed, 9 Jul 2003, Rainer Orth wrote:
> > Besides, aside from news.html (with a link to gcc-3.1/criteria.html), there
> > seems to be no link to any of those criteria.html files at all ;-(  They
> > certainly need to be linked somewhere so this information is not only found
> > by accident.
> 
> I intentionally didn't link any criterial.html file from a prominent place
> because it was clear (to me) that the criteria were not really up-to-date
> and we were not taking them really serious as far as performing the various
> tests are concerned.
> 
> That's something we should revisit for 3.4 after 3.3.1 is out the door,
> and in fact I suspect that Mark will want to suggest some updated criteria
> for GCC 3.4, so I think we ought to defer the creating of
>  http://gcc.gnu.org/gcc-3.4/criteria.html
> until then.

I agree.

I think those criteria are good, but think that the reality is that we
do not have sufficient resources to meet those criteria.  We should come
up with a scaled-back version that represents something that we can do
with the resources that we have available.

The good news is that high bandwidth and our open model are getting us a
lot of testing.  That, together with the *very* good triage work being
done by people processing incoming bugzilla data, is giving me a lot
more confidence in the quality of our software.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Phil Edwards]

A couple of comments:

> You seem to be using a non-standard configuration (for example, I skimmed 
> through dozen and dozen of bug reports for Solaris and never saw the 'sed' 
> problem reported;

You've since traced this down to POSIX sed, not the older native sed.
Should we add a note in the solaris-specific installation docs that,
ironically, the POSIX-standard version of these tools can cause problems,
and the older native tools (for which workarounds specifically exist)
should be used instead?

(You also pointed out that the test has since been rewritten, so this
particular example is moot.  I just use this as a starting point for
discussion.)

> you use bash to bootstrap, we explicitly recommend ksh).

http://gcc.gnu.org/install/prerequisites.html says, "see the specific
instructions for your platform, or use Bash to be sure."

If using Bash as the configuration shell doesn't work, that's a bug.

(I've just upgrade my bash installation from 2.04 to 2.05b, and a number of
oddities have gone away.  Possibly that should be mentioned in the docs too.)


> Because of the shortage of resources, we are forced to support only a single 
> procedure.

I can't argue with that.  We should decide, before 3.3.1 goes out, whether
the POSIX tools in /usr/xpg4/bin are supported during bootstrap.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Eric Botcazou]

> You've since traced this down to POSIX sed, not the older native sed.
> Should we add a note in the solaris-specific installation docs that,
> ironically, the POSIX-standard version of these tools can cause problems,
> and the older native tools (for which workarounds specifically exist)
> should be used instead?

There are already many notes in the SPARC/Solaris specific sections of the 
installation docs, so I think we should try to not overload them. As I 
already said, AFAIK you're the only one to have reported this problem in the 
bugs database and the problem doesn't occur on a typical Solaris 
installation, so I'm personally not in favor of adding yet another note. But 
I understand that the opposite decision could be made for the sake of 
completeness.

Btw, why on earth don't you have /usr/bin at the beginning of your PATH 
variable? :-)

> (You also pointed out that the test has since been rewritten, so this
> particular example is moot.  I just use this as a starting point for
> discussion.)

Yes, maybe the former test was deemed too fragile.

> http://gcc.gnu.org/install/prerequisites.html says, "see the specific
> instructions for your platform, or use Bash to be sure."

This is IMHO overly optimistic, specific Bash versions may have bugs on 
exotic (read non-Linux) platforms. I think the host-specific installation 
notes should prevail.

> If using Bash as the configuration shell doesn't work, that's a bug.

I presume you mean a Bash bug :-)

> I can't argue with that.  We should decide, before 3.3.1 goes out, whether
> the POSIX tools in /usr/xpg4/bin are supported during bootstrap.

They are not, and this is not a regression so we cannot change it at this 
point. As to whether we should mention it in the installation notes, I 
already gave my viewpoint above.

-- 
Eric Botcazou

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Phil Edwards]

On Tue, Jul 15, 2003 at 12:32:16AM +0200, Eric Botcazou wrote:
> 
> Btw, why on earth don't you have /usr/bin at the beginning of your PATH 
> variable? :-)

Because I got really, really sick of my scripts working everywhere except
Solaris, thanks to the weird non-standard command-line options and semantic
behavior of the traditional Solaris tools.

Sun has decided to not fix any of those problems in the name of backwards
compatability, but relented enough to ship versions conforming to the
XPG4 publications.

Basically, it's the same reason we don't support /bin/sh under Solaris,
but request /bin/ksh[*] instead.  Just apply the reasoning to other tools.

[*]  aka /usr/xpg4/bin/sh, so that when our users run "sh script.sh", we
     get the good shell, not the crappy one.


> They are not, and this is not a regression so we cannot change it at this 
> point. As to whether we should mention it in the installation notes, I 
> already gave my viewpoint above.

One sentence more can't hurt...


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Eric Botcazou]

> Because I got really, really sick of my scripts working everywhere except
> Solaris, thanks to the weird non-standard command-line options and
> semantic behavior of the traditional Solaris tools.

Then install Linux ;-)

> One sentence more can't hurt...

Yes, but I'm afraid that it might confuse the reader, given that you pointed 
out that /usr/bin/ksh is nothing else than /usr/xpg4/bin/sh.

But I might be underestimating your skills as a technical writer, so maybe we 
can agree about a way of formulating it.

-- 
Eric Botcazou

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Phil Edwards]

On Tue, Jul 15, 2003 at 01:00:00AM +0200, Eric Botcazou wrote:
> > Because I got really, really sick of my scripts working everywhere except
> > Solaris, thanks to the weird non-standard command-line options and
> > semantic behavior of the traditional Solaris tools.
> 
> Then install Linux ;-)

As cool as that would be, my employer, coworkers, and users would be very,
very surprised.  As would all of our 64-bit applications.


> Yes, but I'm afraid that it might confuse the reader, given that you pointed 
> out that /usr/bin/ksh is nothing else than /usr/xpg4/bin/sh.

That's an exception, not the rule.

> But I might be underestimating your skills as a technical writer, so maybe we 
> can agree about a way of formulating it.

Thanks for your vote of confidence.  :-)  Here are two attempts.


Index: doc/install.texi
===================================================================
RCS file: /home/pme/Repositories/GCC/gcc/gcc/doc/install.texi,v
retrieving revision 1.214
diff -u -4 -r1.214 install.texi
--- doc/install.texi    11 Jul 2003 23:04:48 -0000      1.214
+++ doc/install.texi    14 Jul 2003 23:54:56 -0000
@@ -3115,8 +3115,11 @@
 @file{/usr/ucb} to install GCC has been observed to cause trouble.
 For example, the linker may hang indefinitely.  The fix is to remove
 @file{/usr/ucb} from your @env{PATH}.

+If you have the @code{SUNWxcu4} package installed, we recommend placing
+@file{/usr/bin} before @file{/usr/xpg4/bin} in your @env{PATH}.
+
 All releases of GNU binutils prior to 2.11.2 have known bugs on this
 platform.  We recommend the use of GNU binutils 2.11.2 or the vendor
 tools (Sun @command{as}, Sun @command{ld}).



Another possibility, which I think is more clear:


Index: doc/install.texi
===================================================================
RCS file: /home/pme/Repositories/GCC/gcc/gcc/doc/install.texi,v
retrieving revision 1.214
diff -u -4 -r1.214 install.texi
--- doc/install.texi    11 Jul 2003 23:04:48 -0000      1.214
+++ doc/install.texi    14 Jul 2003 23:59:10 -0000
@@ -3115,8 +3115,11 @@
 @file{/usr/ucb} to install GCC has been observed to cause trouble.
 For example, the linker may hang indefinitely.  The fix is to remove
 @file{/usr/ucb} from your @env{PATH}.

+If you have @file{/usr/xpg4/bin} in your @env{PATH}, we recommend placing
+@file{/usr/bin} before @file{/usr/xpg4/bin} for the duration of the build.
+
 All releases of GNU binutils prior to 2.11.2 have known bugs on this
 platform.  We recommend the use of GNU binutils 2.11.2 or the vendor
 tools (Sun @command{as}, Sun @command{ld}).

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Eric Botcazou]

> Another possibility, which I think is more clear:

Looks good, but we could give a short explanation, for example:

Index: doc/install.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/install.texi,v
retrieving revision 1.151.2.45
diff -u -r1.151.2.45 install.texi
--- doc/install.texi    11 Jul 2003 23:08:47 -0000      1.151.2.45
+++ doc/install.texi    15 Jul 2003 06:42:20 -0000
@@ -3109,6 +3109,10 @@
 For example, the linker may hang indefinitely.  The fix is to remove
 @file{/usr/ucb} from your @env{PATH}.

+The build process works more smoothly with the legacy Sun tools so,
+if you have @file{/usr/xpg4/bin} in your @env{PATH}, we recommend placing
+@file{/usr/bin} before @file{/usr/xpg4/bin} for the duration of the build.
+
 All releases of GNU binutils prior to 2.11.2 have known bugs on this
 platform.  We recommend the use of GNU binutils 2.11.2 or the vendor
 tools (Sun @command{as}, Sun @command{ld}).


I'm not a native English speaker, so feel free to improve and commit on the 
3.3 branch (I think this obviously falls under the "obvious rule").

Btw, did you see other problems with the POSIX tools on mainline?

-- 
Eric Botcazou

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Phil Edwards]

On Tue, Jul 15, 2003 at 08:51:02AM +0200, Eric Botcazou wrote:
> > Another possibility, which I think is more clear:
> 
> Looks good, but we could give a short explanation, for example:
> 
> Index: doc/install.texi
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/doc/install.texi,v
> retrieving revision 1.151.2.45
> diff -u -r1.151.2.45 install.texi
> --- doc/install.texi    11 Jul 2003 23:08:47 -0000      1.151.2.45
> +++ doc/install.texi    15 Jul 2003 06:42:20 -0000
> @@ -3109,6 +3109,10 @@
>  For example, the linker may hang indefinitely.  The fix is to remove
>  @file{/usr/ucb} from your @env{PATH}.
> 
> +The build process works more smoothly with the legacy Sun tools so,
> +if you have @file{/usr/xpg4/bin} in your @env{PATH}, we recommend placing
> +@file{/usr/bin} before @file{/usr/xpg4/bin} for the duration of the build.
> +
>  All releases of GNU binutils prior to 2.11.2 have known bugs on this
>  platform.  We recommend the use of GNU binutils 2.11.2 or the vendor
>  tools (Sun @command{as}, Sun @command{ld}).
> 
> 
> I'm not a native English speaker, so feel free to improve and commit on the 
> 3.3 branch (I think this obviously falls under the "obvious rule").

If this passes "make doc", and I see no reason why it wouldn't, I agree
that this should go in 3.3 and trunk.


> Btw, did you see other problems with the POSIX tools on mainline?

Not with current sources, no.  Now that this has come up, I'll keep my
eye out for such problems, and will periodically try building using the
POSIX tools, just to check.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Eric Botcazou]

> If this passes "make doc", and I see no reason why it wouldn't, I agree
> that this should go in 3.3 and trunk.

Maybe can we put it only on the branch in light of...

> Not with current sources, no.  Now that this has come up, I'll keep my
> eye out for such problems, and will periodically try building using the
> POSIX tools, just to check.

...that?

-- 
Eric Botcazou

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Phil Edwards]

On Wed, Jul 16, 2003 at 10:09:28PM +0200, Eric Botcazou wrote:
> > If this passes "make doc", and I see no reason why it wouldn't, I agree
> > that this should go in 3.3 and trunk.
> 
> Maybe can we put it only on the branch in light of...
> 
> > Not with current sources, no.  Now that this has come up, I'll keep my
> > eye out for such problems, and will periodically try building using the
> > POSIX tools, just to check.
> 
> ...that?

Well, the configure test causing the most difficulty got rewritten on
mainline.  The addition to the manual would still be true.  We haven't really
solved the problem, we've just avoided the situation that points it out.

Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Eric Botcazou]

> Well, the configure test causing the most difficulty got rewritten on
> mainline.  The addition to the manual would still be true.  We haven't
> really solved the problem, we've just avoided the situation that points it
> out.

Agreed, let's be conservative.

-- 
Eric Botcazou

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[Andreas Jaeger]

This might be fixed (it does for me on x86_64) by Zdenek's patch that
he send yesterday on gcc-patches (Subject: Re: cfg_cleanup and loop
discovery in cfg_layout mode).  Does it help?

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[John David Anglin]

I have seen the same error but in a different place for the past two days:

stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c   -gstabs -O2 -DIN
_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedant
ic -Wno-long-long -Werror -fno-common   -DHAVE_CONFIG_H -DGENERATOR_FILE    -I.
-I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../
include -I../intl ../../gcc/gcc/genautomata.c -o genautomata.o
../../gcc/gcc/genautomata.c: In function `automata_list_eq_p':
../../gcc/gcc/genautomata.c:4463: error: head insn 90 for block 0 not found in t
he insn stream
../../gcc/gcc/genautomata.c:4463: internal compiler error: Segmentation fault

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Solaris 8/SPARC bootstrap broken building 64-bit libgcc

[John David Anglin]

> I have seen the same error but in a different place for the past two days:
> 
> stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c   -gstabs -O2 -DIN
> _GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedant
> ic -Wno-long-long -Werror -fno-common   -DHAVE_CONFIG_H -DGENERATOR_FILE    -I.
> -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../
> include -I../intl ../../gcc/gcc/genautomata.c -o genautomata.o
> ../../gcc/gcc/genautomata.c: In function `automata_list_eq_p':
> ../../gcc/gcc/genautomata.c:4463: error: head insn 90 for block 0 not found in t
> he insn stream
> ../../gcc/gcc/genautomata.c:4463: internal compiler error: Segmentation fault

Zdenek's patch

  http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00457.html

fixed the above failure.  However, there are still a bunch of new segmentation
faults in the testsuite.  For example,

Executing on host: /home/dave/gcc-3.4/objdir/gcc/xgcc -B/home/dave/gcc-3.4/objdi
r/gcc/   -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  -w -c
-o 20000728-1.o /home/dave/gcc-3.4/gcc/gcc/testsuite/gcc.c-torture/compile/20000
728-1.c    (timeout = 300)
/home/dave/gcc-3.4/gcc/gcc/testsuite/gcc.c-torture/compile/20000728-1.c: In func
tion `foo':
/home/dave/gcc-3.4/gcc/gcc/testsuite/gcc.c-torture/compile/20000728-1.c:15: inte
rnal compiler error: Segmentation fault

The stack backtrace is:

#0  0x000ec654 in verify_dominators (dom=0x486f58)
    at ../../gcc/gcc/dominance.c:695
#1  0x002f4bcc in unroll_and_peel_loops (loops=0x486e48, flags=4739680)
    at ../../gcc/gcc/loop-unroll.c:145
#2  0x0029b614 in rest_of_handle_loop2 (decl=0x486e48, insns=0x401d1ba0)
    at ../../gcc/gcc/toplev.c:3303
#3  0x0029bda4 in rest_of_compilation (decl=0x401d0a80)
    at ../../gcc/gcc/toplev.c:3576
#4  0x0003e438 in c_expand_body_1 (fndecl=0x401d0a80, nested_p=0)
    at ../../gcc/gcc/c-decl.c:6379
#5  0x002d4500 in cgraph_expand_function (node=0x40017340)
    at ../../gcc/gcc/cgraphunit.c:282
#6  0x002d46c8 in cgraph_expand_functions () at ../../gcc/gcc/cgraphunit.c:372
#7  0x002d49d0 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:462
#8  0x0007dfe0 in c_objc_common_finish_file ()
    at ../../gcc/gcc/c-objc-common.c:363
#9  0x00019d3c in yyparse () at c-parse.y:339
#10 0x0006f398 in c_common_parse_file (set_yydebug=4732136)
    at ../../gcc/gcc/c-opts.c:1188
#11 0x00298e20 in compile_file () at ../../gcc/gcc/toplev.c:2069
#12 0x0029e3d0 in do_compile () at ../../gcc/gcc/toplev.c:4959
#13 0x0029e44c in toplev_main (argc=18, argv=0xfaf005b0)
    at ../../gcc/gcc/toplev.c:4990

It appears dom_bb is 0x0.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)