Suspicious missing tail call opportunity
In following example, call to sbfoo isn't a tail call with -O2. GCC
analyzes local variable may be referenced in sbfoo. Is it a reasonable
analysis? In another word, is it a legal program that bar stores
address of local to a static variable, and then for sbfoo to access
it?
This issue cause a missed tail call opportunity in newlib, thus
unnecessarily increased stack consumption.
a.c:
extern int sbfoo(void);
extern int bar(int *);
int foo()
{
int local = 0;
if (bar(&local)) return 0;
return sbfoo();
}
b.c:
int * g;
int bar(int *c) { g=c; return 0;}
int sbfoo() { return *g; }
Re: Suspicious missing tail call opportunity
On Sun, Jan 6, 2013 at 1:28 AM, Ye Joey wrote:
> In following example, call to sbfoo isn't a tail call with -O2. GCC
> analyzes local variable may be referenced in sbfoo. Is it a reasonable
> analysis? In another word, is it a legal program that bar stores
> address of local to a static variable, and then for sbfoo to access
> it?
Yes since local does not go out of scope until the return of foo which
is after the call to sbfoo.
Thanks,
Andrew Pinski
>
> This issue cause a missed tail call opportunity in newlib, thus
> unnecessarily increased stack consumption.
>
> a.c:
> extern int sbfoo(void);
> extern int bar(int *);
> int foo()
> {
> int local = 0;
> if (bar(&local)) return 0;
>
> return sbfoo();
> }
>
> b.c:
> int * g;
> int bar(int *c) { g=c; return 0;}
>
> int sbfoo() { return *g; }
Re: Align a POD srtuct on the stack (aliasing issue with gcc 4.6+)
On Sun, Jan 6, 2013 at 4:00 AM, pps . wrote:
> Question: How can I allocate random amount of stack space (using char
> arrays or alloca, and then align pointer to that stack space and
> reinterpret this chunk of memory as some structure that has some well
> defined layout that guarantees alignment of certain variables as long
> as the structure itself is aligned properly? How can I do so with 4.6+
> GCC with full optimizations enabled with strict aliasing enabled (e.g.
> without passing -fno-strict-aliasing).
>
> Pseudo code:
>
> struct my_array
> {
>char data[];
> };
>
> void * buffer = alloca(sizeof(my_array) + 32);
> void * buffer32 = (((uintptr_t)buffer) + 31) & (~31);
> assert( ((uintptr_t)buffer) % 32 == 0);
>
> my_array * data = (my_array*)buffer32;
>
> now use my_array, data->data is 32-byte aligned
The above code snippet is perfectly ok. Type-based aliasing only
works with the dynamic type of *data (which is determined by
the stores to the memory region). It should work this way since GCC 4.5, btw.
> I have a huge function that allocates multiple aligned arrays on the stack
> using this approach and now it doesn't produce correct results with GCC
> 4.6+ (on arm, I didn't test it on x86).
> I've spent 2 days trying to fix the issue, perhaps gcc mailing list is a
> good place to ask for appropriate workaround? I want to ensure that the
> function produces correct result even with strict-aliasing enabled.
The error must be elsewhere, not aliasing related.
Richard.
>
> Thanks.
Re: Align a POD srtuct on the stack (aliasing issue with gcc 4.6+)
On 01/05/13 21:00, pps . wrote:
> Question: How can I allocate random amount of stack space (using char
> arrays or alloca, and then align pointer to that stack space and
> reinterpret this chunk of memory as some structure that has some well
> defined layout that guarantees alignment of certain variables as long
> as the structure itself is aligned properly? How can I do so with 4.6+
> GCC with full optimizations enabled with strict aliasing enabled (e.g.
> without passing -fno-strict-aliasing).
>
> Pseudo code:
>
> struct my_array
> {
>char data[];
> };
>
> void * buffer = alloca(sizeof(my_array) + 32);
> void * buffer32 = (((uintptr_t)buffer) + 31) & (~31);
> assert( ((uintptr_t)buffer) % 32 == 0);
>
> my_array * data = (my_array*)buffer32;
>
> now use my_array, data->data is 32-byte aligned
>
>
> I have a huge function that allocates multiple aligned arrays on the stack
> using this approach and now it doesn't produce correct results with GCC
> 4.6+ (on arm, I didn't test it on x86).
> I've spent 2 days trying to fix the issue, perhaps gcc mailing list is a
> good place to ask for appropriate workaround? I want to ensure that the
> function produces correct result even with strict-aliasing enabled.
>
>
> Thanks.
I assume by gcc you mean the c compiler and not the c++ compiler.
Otherwise, you could use c++ alignas.
http://en.cppreference.com/w/cpp/language/alignas
Are you, for some reason, limited to using just c?
-regards,
Larry
Re: Align a POD srtuct on the stack (aliasing issue with gcc 4.6+)
On Sat, Jan 5, 2013 at 7:00 PM, pps . wrote:
> Question: How can I allocate random amount of stack space (using char
> arrays or alloca, and then align pointer to that stack space and
> reinterpret this chunk of memory as some structure that has some well
> defined layout that guarantees alignment of certain variables as long
> as the structure itself is aligned properly? How can I do so with 4.6+
> GCC with full optimizations enabled with strict aliasing enabled (e.g.
> without passing -fno-strict-aliasing).
>
> Pseudo code:
>
> struct my_array
> {
>char data[];
> };
>
> void * buffer = alloca(sizeof(my_array) + 32);
> void * buffer32 = (((uintptr_t)buffer) + 31) & (~31);
> assert( ((uintptr_t)buffer) % 32 == 0);
>
> my_array * data = (my_array*)buffer32;
>
> now use my_array, data->data is 32-byte aligned
>
Why don't you let GCC to align struct my_array to
32 byte for you? You can do
struct my_array data __attribute__((aligned(32)));
--
H.J.
code hoisting with CCmode condition codes
I'm obvkously doing something stupid here; but I'm at a loss to figure it out.
Porting to a machine where most instructions set some condition codes and
before hoisting, we have
(insn 1205 1204 1206 65 (set (reg:CC_ZN 24 *cc)
(compare:CC_ZN (reg:SI 843)
(reg:SI 844)))
../../../../../uberbaum/newlib/libc/stdio/vfprintf.c:1046 83 {*cmpsi_zn}
(expr_list:REG_EQUAL (compare:CC_ZN (reg:SI 843)
(const_int 0 [0]))
(expr_list:REG_DEAD (reg:SI 844)
(nil
(jump_insn 1206 1205 1207 65 (set (pc)
(if_then_else (eq (reg:CC_ZN 24 *cc)
(const_int 0 [0]))
(label_ref 1215)
(pc))) ../../../../../uberbaum/newlib/libc/stdio/vfprintf.c:1046 86
{branch_insn}
(expr_list:REG_DEAD (reg:CC_ZN 24 *cc)
(nil))
-> 1215)
But after the hoist pass runs, we've inserted a (set (reg:1884) (plus (reg
674) (const_int 4)))
between the CC set and use.
(insn 1203 1202 1205 62 (clobber (reg:CC 24 *cc))
../../../../../uberbaum/newlib/libc/stdio/vfprintf.c:1046 -1
(expr_list:REG_UNUSED (reg:CC 24 *cc)
(nil)))
(insn 1205 1203 6262 62 (set (reg:CC_ZN 24 *cc)
(compare:CC_ZN (reg:SI 843)
(const_int 0 [0])))
../../../../../uberbaum/newlib/libc/stdio/vfprintf.c:1046 83 {*cmpsi_zn}
(expr_list:REG_EQUAL (compare:CC_ZN (reg:SI 843)
(const_int 0 [0]))
(expr_list:REG_DEAD (reg:SI 844)
(nil
(insn 6262 1205 1206 62 (set (reg/f:SI 1884 [ ap ])
(plus:SI (reg/v/f:SI 674 [ ap ])
(const_int 4 [0x4]))) 10 {*addsi}
(nil))
(jump_insn 1206 6262 1207 62 (set (pc)
(if_then_else (eq (reg:CC_ZN 24 *cc)
(const_int 0 [0]))
(label_ref 1215)
(pc))) ../../../../../uberbaum/newlib/libc/stdio/vfprintf.c:1046 86
{branch_insn}
(expr_list:REG_DEAD (reg:CC_ZN 24 *cc)
(nil))
-> 1215)
and this is a problem because that will codegen as a
move$rtemp,src
addi $rtemp,4
and both of those instructions end up setting condition codes, breaking the
dependency with the compare that actually sets the CCs..
I've looked at a number of the other CCmode ports, but can't see how they
prevent this from occurring.
Do I need to do something like change my define_expand for addsi3 to be
something like
[ (parallel [ (clobber:CCmode (reg:CCmode CCREG))
(set:SI (match_operand:SI 0 "" "")
(plus:SI (match_operand::SI 1 "" "" )
(match_operand:SI 2 ""
"")))])]
So that there's an explicitly stated dependency that would prevent motioning
before the use in the jump_insn?
But I don't see this construct used in other ports that have CCmode registers
as opposed to cc0
I'm porting of 4.6.1 - is there any better documentation of CCmode ports or a
reference port with
gcc-4.8-20130106 is now available
Snapshot gcc-4.8-20130106 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20130106/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 194954 You'll find: gcc-4.8-20130106.tar.bz2 Complete GCC MD5=234111006e41f5ffbd9e602397ae4568 SHA1=278fee641d7013dca85957fb2010b01aa20704a2 Diffs from 4.8-20121230 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Copyright assignment forms
On 4/01/2013, at 12:54 AM, Rainer Emrich wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I like to contribute some patches to gcc. Therefor im asking kindly for the > copyright assignment forms and advice. Hi Rainer, You need to forward your email to . It is the FSF, not the GCC project, that handles copyright assignment paperwork. You need to specify your name, the name of your employer, and the name and title of the person who will be signing on behalf of the company. You also need to list which FSF projects (e.g., GCC, Binutils, GDB, glibc -- or just blanket ALL) you wish to contribute to. Usually the FSF copyright office replies within 1-2 days, and feel free to ping us back here at gcc@ if FSF legal stalls. Thanks, -- Maxim Kuvyrkov
Re: question on "undefined reference to _gcov_init"
On 01/06/13 03:00, Gu, Forrest wrote: Hi, Nathan, I’ve seen your message with Qiong Cai on gcov link problem, from a mail of 19 Apr 2003… gcov has changed a lot since then. and you suggest to either: a)add -fprofile-arcs b)add -lgcov However, I succeed with a) but fail with b), it prompts: gcov: invalid option – ‘g’ usage: gcov [OPTION]… SOURCE|OBJ… It seems -lgcov is not a valid option for gcov command. Correct. -lgcov is an option to the compiler. IIRC -ftest-coverage -fprofile-arcs is the right invokation now. nathan -- Nathan Sidwell
