This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Linux/PPC gcc 2.95.2 - bad access generated when using inline func
- To: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Subject: Re: Linux/PPC gcc 2.95.2 - bad access generated when using inline func
- From: Richard Henderson <rth at cygnus dot com>
- Date: Thu, 6 Jul 2000 22:51:37 -0700
- Cc: rearnsha at arm dot com, Geoff Keating <geoffk at cygnus dot com>, cort at fsmlabs dot com, gcc-bugs at gcc dot gnu dot org
- References: <Your <4.3.2.7.2.20000630142601.00de6280@mail.lauterbach.com> <200006301244.NAA10398@cam-mail2.cambridge.arm.com> <4.3.2.7.2.20000630151430.033a7a20@mail.lauterbach.com>
On Fri, Jun 30, 2000 at 03:55:56PM +0200, Franz Sirl wrote:
> Find appended the current patch I'm working with and a testcase. Currently
> the testcase still aborts with even my patch, but this is due to bug in
> label handling in the current mainline...
This is not a bug. Your label is not the target of a goto, and
so plays no part in the CFG, and so is deleted. Your test case
does not do what you think it does. And anyway, it's not going
to work on quite a lot of architectures.
You might could try checking that the return value is between
two known points, such as
int main (void)
{
__label__ L1, L2;
static void (*func[3])(void) = { test1, test2, test3 };
static void *labels[2] = { &&L1, &&L2 };
int i;
/* Detect simple -freorder-blocks breakage of the test case. */
if (labels[0] >= labels[1])
return 0;
goto *labels[0];
L1:
for (i = 0; i < 3; i++)
{
func[i]();
if (ret_addr < labels[0] || ret_addr > labels[1])
abort ();
}
L2:
return 0;
}
But of course, this assumes that -freorder-blocks doesn't do something
completely wierd with the layout of the function.
r~