Bug 32338 - [4.3 Regression] Error: .prologue within prologue
Summary: [4.3 Regression] Error: .prologue within prologue
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.3.0
: P1 normal
Target Milestone: 4.3.0
Assignee: Jakub Jelinek
URL: http://gcc.gnu.org/ml/gcc-patches/200...
Keywords: assemble-failure
Depends on:
Blocks:
 
Reported: 2007-06-14 10:41 UTC by Martin Michlmayr
Modified: 2007-09-17 22:30 UTC (History)
6 users (show)

See Also:
Host:
Target: ia64-linux-gnu
Build:
Known to work: 4.2.0
Known to fail: 4.3.0
Last reconfirmed: 2007-07-18 14:14:14


Attachments
gcc43-pr32338-1.patch (737 bytes, patch)
2007-07-18 14:15 UTC, Jakub Jelinek
Details | Diff
gcc43-pr32338-2.patch (747 bytes, patch)
2007-07-18 14:16 UTC, Jakub Jelinek
Details | Diff
gcc43-pr32338-3.patch (1.77 KB, patch)
2007-07-18 14:16 UTC, Jakub Jelinek
Details | Diff
gcc43-pr32338-3.patch (1.71 KB, patch)
2007-07-19 07:03 UTC, Jakub Jelinek
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Michlmayr 2007-06-14 10:41:04 UTC
I'm getting the following assembler error with current gcc 4.3.  This
worked with 20070604 and is probably due to the dataflow merge.  This is
possible the same as, or related to, PR32337, but I cannot tell for sure.

tbm@coconut0:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O2 -fno-omit-frame-pointer skalibs-dns_transmit.c
/tmp/cc1yk7fL.s: Assembler messages:
/tmp/cc1yk7fL.s:93: Warning: .restore outside of body region
/tmp/cc1yk7fL.s:101: Error: .prologue within prologue

Testcase:


struct dns_transmit
{
};
firstudp (struct dns_transmit *d)
{
}
firsttcp (struct dns_transmit *d)
{
}
dns_transmit_start (struct dns_transmit *d, char const *q)
{
  unsigned int len;
  len = dns_domain_length (q);
  if (len > 512)
    return firsttcp (d);
  return firstudp (d);
}
Comment 1 Steve Ellcey 2007-07-02 21:27:02 UTC
I can make the warning message go away by using -fno-schedule-insns2.
Comment 2 Jakub Jelinek 2007-07-18 14:14:13 UTC
The thing that changed is that new dataflow now allows moving around the
(set (r12) (something)) frame related instructions within EBBs during scheduling
more easily.  These are generated for the sibcall epilogues before sibling
calls and also for epilogue before br.ret.
ia64.c unwind generation code assumes that the frame related r12 setting
insns say in the same BB (while scheduling works with EBBs) and emits .body and
.copy_state at the start of next BB after .label_state, but in this case we
want it another BB later.

I'll attach 3 possible fixes, one is to add blockage like we do for
current_frame_info.total_size != 0 or cfun->machine->ia64_eh_epilogue_sp
functions when we need frame pointer (and thus emit the r12 = something frame related insn), the other is the same but only emit the blockage in sibcall epilogues.  The last one I'm ATM bootstrapping/regtesting doesn't limit the scheduling in anyway, instead adds a little state machine to control the addition
of .label_state/.restore sp, .prologue, .body and .copy_state.  If that works,
it would e.g. also fix unnecessary .body directives when already in .body region.
Comment 3 Jakub Jelinek 2007-07-18 14:15:47 UTC
Created attachment 13934 [details]
gcc43-pr32338-1.patch
Comment 4 Jakub Jelinek 2007-07-18 14:16:10 UTC
Created attachment 13935 [details]
gcc43-pr32338-2.patch
Comment 5 Jakub Jelinek 2007-07-18 14:16:29 UTC
Created attachment 13936 [details]
gcc43-pr32338-3.patch
Comment 6 Jakub Jelinek 2007-07-19 07:03:11 UTC
Created attachment 13938 [details]
gcc43-pr32338-3.patch

Testing showed I was wrong with the .body and we need duplicate .body
even when there was no second .prologue.  This updated patch has been
bootstrapped/regtested on ia64-linux.
Comment 7 Martin Michlmayr 2007-08-21 14:39:32 UTC
Can an ia64-maintainer approve one of the patches Jakub has suggested?