https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19746
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2005-05-09 01:18:53 |2016-1-27
CC| |msebor at gcc dot gnu.org
Known to fail| |5.3.0, 6.0
--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
The behavior is still present on trunk and currently supported versions. The
test case below shows the difference between the expected call sequence (in
bar_long) and the actual call sequence (in foo, which matches that in
bar_short).
That said, I don't think this is a target-specific problem. The same issue
exists in other back ends, and is likely caused by some early folding not
taking into account differences in attributes or the presence of user-defined
declarations (as suggested by the patch in comment #2).
It seems that this bug should be reclassified as middle-end?
$ cat t.c && /build/sysroot/powerpc-eabispe/bin/powerpc-eabispe-gcc -O2 -S -o
/dev/stdout t.c
int printf (const char*, ...) __attribute__ ((__longcall__));
int puts (const char*) __attribute__ ((__longcall__));
void foo (void) { printf (" \n"); }
int puts_long (const char*) __attribute__ ((__longcall__));
int puts_short (const char*) __attribute__ ((__shortcall__));
void bar_long (void) { puts_long (" "); }
void bar_short (void) { puts_short (" "); }
.file "t.c"
.section ".text"
.align 2
.globl foo
.type foo, @function
foo:
lis 3,.LC0@ha
la 3,.LC0@l(3)
b puts
.size foo, .-foo
.align 2
.globl bar_long
.type bar_long, @function
bar_long:
stwu 1,-8(1)
lis 9,puts_long@ha
mflr 0
la 9,puts_long@l(9)
lis 3,.LC0@ha
stw 0,12(1)
la 3,.LC0@l(3)
mtctr 9
bctrl
lwz 0,12(1)
addi 1,1,8
mtlr 0
blr
.size bar_long, .-bar_long
.align 2
.globl bar_short
.type bar_short, @function
bar_short:
lis 3,.LC0@ha
la 3,.LC0@l(3)
b puts_short
.size bar_short, .-bar_short
.section .rodata.str1.4,"aMS",@progbits,1
.align 2
.LC0:
.string " "
.ident "GCC: (GNU) 6.0.0 20160121 (experimental)"
