This is the mail archive of the
mailing list for the GCC project.
Re: Frame pointer, bug or feature? (x86)
- From: Andrew Pinski <pinskia at gmail dot com>
- To: Hendrik Greving <hendrik dot greving dot intel at gmail dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Mon, 18 Nov 2013 10:55:04 -0800
- Subject: Re: Frame pointer, bug or feature? (x86)
- Authentication-results: sourceware.org; auth=none
- References: <CANc4vhoN4_zvYsSCpa-kjZ3XBT1KMNbAkHNCy=ORrt=fihquwg at mail dot gmail dot com> <CA+=Sn1=pK13xk0xVCiJiPjHdX38KXU3V43T1TEpwXeUyMuNYvQ at mail dot gmail dot com> <CANc4vhqm0fajt9v540oGpfwta2d2G+aeTocvvxJBRkDDs6Ry7g at mail dot gmail dot com>
On Mon, Nov 18, 2013 at 10:47 AM, Hendrik Greving
> What's the difference in the C vs. the C++ spec that makes it a VLA in GNU-C?
max in C++ is considered an integer constant expression while in C it
is just an expression.
> On Fri, Nov 15, 2013 at 10:07 AM, Andrew Pinski <firstname.lastname@example.org> wrote:
>> On Fri, Nov 15, 2013 at 9:31 AM, Hendrik Greving
>> <email@example.com> wrote:
>>> In the below test case, "CASE_A" actually uses a frame pointer, while
>>> !CASE_A doesn't. I can't imagine this is a feature, this is a bug,
>>> isn't it? Is there any reason the compiler couldn't know that
>>> loop_blocks never needs a dynamic stack size?
>> Both a feature and a bug. In the CASE_A case (with GNU C) it is a VLA
>> while in the !CASE_A case (or in either case with C++), it is a normal
>> array definition. The compiler could have converted the VLA to a
>> normal array but does not depending on the size of the array.
>> Andrew Pinski
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>> #define MY_DEFINE 100
>>> #define CASE_A 1
>>> extern init(int (*a));
>>> #if CASE_A
>>> const int max = MY_DEFINE * 2;
>>> int loop_blocks[max];
>>> int loop_blocks[MY_DEFINE * 2];
>>> return loop_blocks;
>>> int i = foo();
>>> printf("is is %d\n", i);
>>> Hendrik Greving