--- Comment #24 from bonzini at gnu dot org 2009-08-12 16:29 ---
patch committed as r150700
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #23 from sje at cup dot hp dot com 2009-08-11 17:18 ---
I don't have complete results because my builds failed due to a bad libstdc++
checkin (that has been fixed) but the C and Fortran parts all looked good.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
--- Comment #18 from sje at cup dot hp dot com 2009-08-10 15:33 ---
I tried the pa.c change, it didn't help. I will do a non-bootstrap build with
tests. All my HP-UX machines are behind the HP firewall unfortunately. I see
we have a PA box in the compile farm but I think it is
--- Comment #19 from sje at cup dot hp dot com 2009-08-10 19:32 ---
Here are the unexpected failures I see when running the testsuite using a
non-bootstrap PA compiler. The compiler I built includes the patch from
comment #17.
FAIL: 22_locale/ctype/narrow/char/2.cc execution test
--- Comment #20 from bonzini at gnu dot org 2009-08-10 20:09 ---
Created an attachment (id=18337)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18337action=view)
patch fixing hpux differences
This patch squashes in the following too. It is a stupid used-uninitialized
bug that was
--- Comment #21 from sje at cup dot hp dot com 2009-08-10 20:18 ---
That seems to have fixed pr39240.c in the testsuite. I will try a complete
bootstrap again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
--- Comment #22 from sje at cup dot hp dot com 2009-08-10 21:30 ---
A hppa2.0w-hp-hpux11.11 bootstrap was successful with the v3 patch and running
the broken tests also looks OK now. I will let my normal nightly process do a
full test run tonight on PA but it looks good.
--
--- Comment #16 from bonzini at gnu dot org 2009-08-08 07:57 ---
Can you try running the testsuite on a non-bootstrapped hppa-hpux compiler?
However, I have an idea and will provide a patch soon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
--- Comment #17 from bonzini at gnu dot org 2009-08-08 08:18 ---
Try squashing this in:
Index: pa/pa.c
===
--- pa/pa.c (revision 150359)
+++ pa/pa.c (working copy)
@@ -9199,7 +9199,7 @@ pa_promote_function_mode
--- Comment #15 from bonzini at gnu dot org 2009-08-07 07:24 ---
Subject: Re: version 150336 broke bootstrap on ia64-hp-hpux11.23
After applying the most recent patch the ia64 bootstrap started working but
the
pa bootstrap (hppa2.0w-hp-hpux11.11) started failing. The
--- Comment #13 from sje at cup dot hp dot com 2009-08-06 16:57 ---
I have good news and I have bad news (as the saying goes). My IA64 bootstrap
completed successfully and the testing also went fine. But, I also did an
hppa2.0w-hp-hpux11.11 bootstrap and that bootstrap failed with
--- Comment #14 from sje at cup dot hp dot com 2009-08-06 17:44 ---
Created an attachment (id=18312)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18312action=view)
test case where stage1 and stage2 generate different code
After applying the most recent patch the ia64 bootstrap
--- Comment #10 from bonzini at gnu dot org 2009-08-05 06:09 ---
preprocessed testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
--- Comment #11 from sje at cup dot hp dot com 2009-08-05 21:36 ---
Created an attachment (id=18308)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18308action=view)
C++ test case that fails with plausible patch
This is cut down from libstdc++-v3 sources. I am not sure it is
--- Comment #12 from bonzini at gnu dot org 2009-08-05 23:09 ---
Created an attachment (id=18309)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18309action=view)
another patch
This failure is related to NRV, which is why there is no C failure.
If I take care of it the patch is
--- Comment #3 from sje at cup dot hp dot com 2009-08-04 14:59 ---
No, the patch in comment #2 did not fix the problem. I did a non-bootstrap
build followed by a testsuite run hoping I would get a failure there with a
nice small test case but I didn't get any unexpected failures.
--
--- Comment #4 from sje at cup dot hp dot com 2009-08-04 17:09 ---
Created an attachment (id=18300)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18300action=view)
Testcase
This test case shows the difference in generated code between r150335 and
r150336. It does not actually
--- Comment #5 from sje at cup dot hp dot com 2009-08-04 17:46 ---
Created an attachment (id=18301)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18301action=view)
Better test case
Here is a better test case that actually shows bad code being generated. In
r150335, we extend r32
--- Comment #6 from sje at cup dot hp dot com 2009-08-04 21:04 ---
I am currently looking at assign_parm_setup_reg, in the old code with test2.c,
we set promoted_nominal_mode being set to DImode and then we get a conversion
because promoted_nominal_mode != data-promoted_mode. In the
--- Comment #7 from sje at cup dot hp dot com 2009-08-04 21:23 ---
I think I got things backwards in my last comment. In the old code
promoted_nominal_mode was set by a call to promote_mode which had the ifdef
POINTERS_EXTEND_UNSIGNED in it to set unsignedp for REFERENCE and POINTER
--- Comment #8 from bonzini at gnu dot org 2009-08-04 22:30 ---
Created an attachment (id=18304)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18304action=view)
plausible patch
The patch adds back the mode of operation corresponding to
promote_nominal_mode's assignment. It turns
--- Comment #9 from sje at cup dot hp dot com 2009-08-04 23:48 ---
Well, it got a lot further using the patch but it didn't completely bootstrap.
The compiler built but while building libstdc++-v3 I got:
/proj/opensrc/nightly/src/trunk/libstdc++-v3/libsupc++/eh_ptr.cc: In function
--- Comment #1 from bonzini at gnu dot org 2009-08-03 20:54 ---
Well, stage2 is better than stage3 :-)
Can you post a preprocessed testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
23 matches
Mail list logo
