[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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 running linux and not hpux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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 FAIL: gcc.c-torture/execute/20020108-1.c execution, -O0 FAIL: gcc.c-torture/execute/20020108-1.c execution, -O1 FAIL: gcc.c-torture/execute/pr39240.c execution, -O0 FAIL: gcc.c-torture/execute/pr39240.c execution, -O1 FAIL: gcc.c-torture/execute/pr39240.c execution, -O2 FAIL: gcc.c-torture/execute/pr39240.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/pr39240.c execution, -O3 -g FAIL: gcc.c-torture/execute/pr39240.c execution, -Os FAIL: gfortran.dg/compiler-directive_1.f90 -O (test for errors, line 42) FAIL: gfortran.dg/compiler-directive_1.f90 -O (test for excess errors) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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 not signaled because unsignedp is passed by reference to
promote_function_mode.
Index: gcc/stmt.c
===
--- gcc/stmt.c (branch promote-function-mode2)
+++ gcc/stmt.c (working copy)
@@ -1517,8 +1517,8 @@ expand_value_return (rtx val)
rtx return_reg = DECL_RTL (decl);
if (return_reg != val)
{
- int unsignedp;
tree funtype = TREE_TYPE (current_function_decl);
tree type = TREE_TYPE (decl);
+ int unsignedp = TYPE_UNSIGNED (type);
enum machine_mode old_mode = DECL_MODE (decl);
enum machine_mode mode = promote_function_mode (type, old_mode,
I'll also bootstrap the patch overnight on x86_64-pc-linux-gnu, and plan to
rename the last argument of the hook now.
--
bonzini at gnu dot org changed:
What|Removed |Added
Attachment #18309|0 |1
is obsolete||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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 (const_tree typ
const_tree fntype ATTRIBUTE_UNUSED,
int for_return)
{
- if (for_return != 1)
+ if (for_return == 0)
return mode;
return promote_mode (type, mode, punsignedp);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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 stage2/stage3 comparision failed. I cut down fortran/io.c into test4.c, and when I compile this test case with the stage1-gcc/cc1 I get unsigned extraction instructions in the code stream but with stage2-gcc/cc1 I get signed extraction instructions. I think the signed extractions are wrong since format_string is a pointer to an unsigned int, but then again we are putting the value into a signed char. Ouch, this means stage2 is being miscompiled. The testcase is very useful, but now one needs to understand _where_ the miscompiled code is and minimize that testcase. If you can give me access to the HPUX machine, I can debug it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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 differences in the results of stage2 and stage3. When I remove your patch, the bootstrap on PA is fine. Comparing stages 2 and 3 warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1-checksum.o differs warning: hppa2.0w-hp-hpux11.11/libgcc/lib2funcs.o differs warning: hppa2.0w-hp-hpux11.11/libgcc/lib2funcs_s.o differs Bootstrap comparison failure! gcc/fortran/io.o differs gcc/fortran/scanner.o differs gcc/fortran/intrinsic.o differs make[2]: *** [compare] Error 1 I will see if I can get more info on what the object differences are. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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 started working but the pa bootstrap (hppa2.0w-hp-hpux11.11) started failing. The stage2/stage3 comparision failed. I cut down fortran/io.c into test4.c, and when I compile this test case with the stage1-gcc/cc1 I get unsigned extraction instructions in the code stream but with stage2-gcc/cc1 I get signed extraction instructions. I think the signed extractions are wrong since format_string is a pointer to an unsigned int, but then again we are putting the value into a signed char. If I make the function an 'unsigned char' then the problem goes away. Originally the function was just 'char' and it also had the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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 still legal C++ but it generates the same error that I was getting during the libstdc++-v3 build. No special options are needed, it will fail with: x.cc: In member function 'virtual std::string std::generic_error_category::message(int) const': x.cc:14:61: internal compiler error: in expand_expr_real_1, at expr.c:7427 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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 actually nicer because there's no distinction
between RESULT_DECL and PARM_DECL. for_return == 2 now means simply the
register in/from which a PARM_DECL/RESULT_DECL is copied.
This means that the only code that needs to special case promote_function_mode
is code copying from parameter registers (calls.c) and into the result
(expand_value_return in stmt.c). I checked the pre-patch code and everybody
else used to guard the call to promote_mode(..., 1) with a call to the
promote_args/promote_return hook; this means that now they can call
promote_function_mode with a final argument that is 0 or 1.
BTW here is a minimal testcase:
struct A
{
A (const A __str);
A (const char * __s);
};
struct B
{
virtual A a (void) const { return A (hi); }
};
const B b;
--
bonzini at gnu dot org changed:
What|Removed |Added
Attachment #18304|0 |1
is obsolete||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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 generate wrong code, just different (technically better) code. In this case on IA64 HP-UX we no longer generate some addp4 instructions to extend pointer arguments from 32 bits to 64 bits. In this code the addp4's are not needed but I am guessing somewhere in gengtype they are not getting generated and are needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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 with 'addp4 r32 = 0, r32' and that is fine. In the new code we combine the addp4 with a move and generate 'addp4 r8 = r32, r0' This is wrong, if we generated 'addp4 - r0, r32' then we would be OK. addp4 is not a symetrical operation and the first argument should be an offset (often zero) and the second argument should be a 32 bit pointer that we want to extend to 64 bits before dereferencing. addp4 uses the REG_POINTER attribute to distinguish between offsets and pointers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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 new code promoted_nominal_mode is set to SImode (the same as data-promoted_node) and so we don't enter the if statement where the ptr_extend conversion is done in the old code. promoted_nominal_mode was set by a call to promote_function_node and is now being set by a call to promote_mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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 types. In the new code we call promote_function_mode and this code doesn't have that ifdef. So I think, for HP-UX, I need to define TARGET_PROMOTE_FUNCTION_MODE, assuming we don't want the ifdef POINTERS_EXTEND_UNSIGNED in promote_function_mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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 out that it's needed in another place and that it can be defined relatively easily in the documentation. I'll try bootstrapping it tomorrow. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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 'std::__exception_ptr::exception_ptr std::current_exception()': /proj/opensrc/nightly/src/trunk/libstdc++-v3/libsupc++/eh_ptr.cc:176:31: internal compiler error: in expand_expr_real_1, at expr.c:7427 /proj/opensrc/nightly/src/trunk/libstdc++-v3/src/ios_locale.cc: In member function 'std::locale std::ios_base::imbue(const std::locale)': /proj/opensrc/nightly/src/trunk/libstdc++-v3/src/ios_locale.cc:50:20: internal compiler error: in expand_expr_real_1, at expr.c:7427 /proj/opensrc/nightly/src/trunk/libstdc++-v3/src/locale.cc: In member function 'std::string std::locale::name() const': /proj/opensrc/nightly/src/trunk/libstdc++-v3/src/locale.cc:124:12: internal compiler error: in expand_expr_real_1, at expr.c:7427 and a few more, all dieing at line 7427 of expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
[Bug middle-end/40952] version 150336 broke bootstrap on ia64-hp-hpux11.23
--- 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
