This makes 27_io/basic_istream/extractors_character/char/9826.cc fail (see e.g. http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg01098.html). I'll attach a semi-reduced test case. Doesn't seem to happen on other platforms. Profiling shows prominently "alpha_sa_mask" and "reload". Adding -da makes the problem go away...
Created attachment 8072 [details] Test case. Compile with no options
Is this a regression?
(In reply to comment #2) > Is this a regression? Yes, g++ 3.4 compiles this fine , and 3.3 too if I s/class/struct/.
Is this a recent problem, ie. any idea when this started to FAIL?
Whoops.
(In reply to comment #4) > Is this a recent problem, ie. any idea when this started to FAIL? With 20041209, I get a segfault. With 20050116 or 20050120, I get the infinite loop. I don't have any other old versions around. Seems to indicate memory corruption...
Some sort of reload bug. We keep allocating new spill slots.
Not a reload bug. RTL state gets mangled by pop_function_context_from called underneath mangle_decl_string. We may be able to work around this problem like so, but I'm still not certain that we're not borking something. This can only be truely fixed by not doing such gross push/pop state changes within the c++ front end. Index: passes.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/passes.c,v retrieving revision 2.65 diff -u -p -d -r2.65 passes.c --- passes.c 1 Feb 2005 10:03:09 -0000 2.65 +++ passes.c 10 Feb 2005 01:57:18 -0000 @@ -1530,6 +1530,12 @@ rest_of_compilation (void) if (rtl_dump_and_exit || flag_syntax_only || errorcount || sorrycount) goto exit_rest_of_compilation; + /* Make sure rtl for the current function is set at this point. This + may recurse in "interesting" ways for c++, which can hork passes. + It is 100% certain that we'll need this rtl, so this does not cause + extra work. */ + (void) DECL_RTL (current_function_decl); + rest_of_handle_jump (); rest_of_handle_eh ();
This is related PR 18683 which is a related problem.
RTH, you added the wrong mark before.
True enough, and one could indeed "fix" this problem on Alpha by adding a similar check to samegp_function_operand. However, I don't think this is the right approach to this problem. How many other places in other targets need to be changed? I'd very much prefer a solution that fixes all such potential problems all at once. It *is* 100% certain that once we've started generating rtl for a function, that we'll need the DECL_ASSEMBLER_NAME in order to emit it. We might as well do this in one place, rather than having to recurse in some random place later during code generation. And for the record, the problem here has to do with reseting virtuals_instantiated instead of reg_renumber.
I agree that the C++ recursion is very ugly. The last time I looked at this, I concluded it would be hard to fix, but now I'm not entirely certain that's true. The problem comes from the call to push_access_scope in get_mostly_instantiated_function_type. There's certainly no need to do access control in this context; we could just save and restore flag_access_control. The comment says "make sure that we can see identifiers" -- but I don't think that makes any sense. If that doesn't work, I think that rth's proposed fix is a reasonable work-around. I'd be worried, though, that in the process of compiling the function, after this point, we might need to mangle some other function (say, one called from this one), and run into the same problem because of that.
patch: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00490.html
Fixed.