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



--- Comment #8 from Steven Bosscher <steven at gcc dot gnu.org> 2013-04-08 
18:43:25 UTC ---

(In reply to comment #7)

> (In reply to comment #6)

> > Do you recall when that was? Must have been long, long ago...

> > I've tried to find where it happened, and the rewrite was done before

> > at least r43893 (Tue Jul 10 10:38:10 2001 UTC (11 years, 9 months ago).

> 

> I would have said it was much more recent than that, but I just checked

> gcc 4.2 and you're right that we'd already switched away from these notes

> somewhere prior to 2009.

> 

> > Does that mean alpha ev4 and ev5 fp exceptions have been broken for

> > maybe 12 years? If that's really the case then I'd say the proper way

> > forward is to remove support for those alpha variants as they're

> > obviously not used and/or tested by anyone...

> 

> It's not as bad as all that.  It's only the extremely uncommon case of

> throwing a c++ exception in response to an fp exception, with a handler

> in the same function.  My guess is that no one at all does this, and so

> the wrong-code is somewhat theoretical.

> 

> Normal fp code without c++ exceptions is working fine.

> 

> Which is why I would not suggest writing new eh code for this, but

> instead moving the existing code to later in the pass list where merely

> adding an insn is good enough to have the insn included in the region.



I really don't like that idea. As it is, these notes are already de facto

alpha specific.  The only references to these notes:



Emitters:

except.c:               note = emit_note_before (NOTE_INSN_EH_REGION_BEG,

except.c:               note = emit_note_after (NOTE_INSN_EH_REGION_END,

except.c:                   note = emit_note_before (NOTE_INSN_EH_REGION_BEG,

except.c:               note = emit_note_after (NOTE_INSN_EH_REGION_END,

except.c:               note = emit_note_before (NOTE_INSN_EH_REGION_BEG,

iter);

except.c:      note = emit_note_after (NOTE_INSN_EH_REGION_END,

last_action_insn);



Printers / doc:

print-rtl.c:          case NOTE_INSN_EH_REGION_BEG:

print-rtl.c:          case NOTE_INSN_EH_REGION_END:

sched-vis.c:      case NOTE_INSN_EH_REGION_BEG:

sched-vis.c:      case NOTE_INSN_EH_REGION_END:

insn-notes.def:INSN_NOTE (EH_REGION_BEG)

insn-notes.def:INSN_NOTE (EH_REGION_END)

doc/rtl.texi:@findex NOTE_INSN_EH_REGION_BEG

doc/rtl.texi:@findex NOTE_INSN_EH_REGION_END

doc/rtl.texi:@item NOTE_INSN_EH_REGION_BEG

doc/rtl.texi:@itemx NOTE_INSN_EH_REGION_END



Actual uses of the notes:

final.c:        case NOTE_INSN_EH_REGION_BEG:

final.c:        case NOTE_INSN_EH_REGION_END:

config/alpha/alpha.c:       case NOTE_INSN_EH_REGION_BEG:

config/alpha/alpha.c:       case NOTE_INSN_EH_REGION_END:





FWIW my r43893 reference is based on inspection of toplev.c around

that time.  See e.g.:

http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/toplev.c?revision=43872&view=markup



Just before "integrate" (RTL inlining!) there is a call on line 2801 to 

"convert_from_eh_region_ranges ()" to come from INSN_NOTE based regions

to REG_NOTE based regions.  Just before shorten_branches, on line 3742,

the INSN_NOTE representation is restored via convert_to_eh_region_ranges.

The machine-dependent reorg pass runs before it, see line 3689.



Continuing the archaeology a bit with "svn blame -r43872 toplev.c":



40924 rth /* Convert from NOTE_INSN_EH_REGION style notes, and do other

40924 rth    sorts of eh initialization.  Delay this until after the

40924 rth    initial rtl dump so that we can see the original nesting.  */

40924 rth convert_from_eh_region_ranges ();



and:



40924 rth

40924 rth   convert_to_eh_region_ranges ();



The commit log for http://gcc.gnu.org/r40924 (Mar 28 2001) is:

"IA-64 ABI Exception Handling."



The part of alpha EH that depends on the notes must have been been

broken since than, more than 12 years.  Without anyone noticing...



I really, really wouldn't like to keep this code in alpha alive, and

with it these REG_EH_REGION notes, for barely (if at all) used ages-old

alpha targets...

Reply via email to