gcc 3.4.2 stack variable lifetime analysis
Can anyone tell me if there is a patch for this problem?
Consider:
void bar(char*);
void foo(int x)
{
if (x) { char y[4096]; bar(y); }
else { char z[4096]; bar(z); }
}
Cygwin gcc 3.4.2 -O2 yields:
pushl %ebp
movl$8216, %eax /* Should be about 4k */
movl%esp, %ebp
call__alloca
PPC cross compiler 3.4.2 -O2 yields:
cmpwi 7,3,0
mflr 0
stwu 1,-8208(1) /* Should be about 4k */
Earl
Seeking patch for ambiguous conversion
Is there a recent (3.4.2 or later) patch for the following problem?
Consider the short program fragment below. There are two failures, and
one success under gcc.
The entire fragment compiles ok with the latest Microsoft Visual Studio
and even one version before that.
With gcc 3.4.1 (Cygwin) and gcc 3.4.2, I obtain error messages like:
ambig.cpp: In function `bool fail1(const X&)':
ambig.cpp:16: error: ambiguous overload for 'operator==' in 'x == 4660'
ambig.cpp:16: note: candidates are: operator==(int, int)
ambig.cpp:5: note: bool operator==(short unsigned int, const C&)
ambig.cpp: In function `bool fail2(const X&)':
ambig.cpp:21: error: ambiguous overload for 'operator==' in 'x == 4660u'
ambig.cpp:21: note: candidates are: operator==(int, int)
ambig.cpp:5: note: bool operator==(short unsigned int, const C&)
It seems the compiler will not prefer the conversion from X to
unsigned short in order to compile the (subsequent unsigned short to
unsigned short) comparison and considers the competing conversions
to C as viable.
Earl Chew
---
class C
{
public:
C(unsigned short);
friend bool operator==(unsigned short, const C&);
};
class X
{
public:
operator unsigned short() const;
};
bool fail1(const X& x)
{
return x == 0x1234;
}
bool fail2(const X& x)
{
return x == (unsigned short) 0x1234;
}
bool succeeds(const X& x)
{
return (unsigned short) x == 0x1234;
}
Seeking patch for bug in lifetime of __cur in deque::_M_fill_initialize (powerpc dw2 EH gcc 3.4.2)
Is there a patch for the following problem?
I am having problems with _M_fill_initialize in deque on the powerpc
version compiled at -O2.
template
void
deque<_Tp,_Alloc>::
_M_fill_initialize(const value_type& __value)
{
_Map_pointer __cur;
try
{
for (__cur = this->_M_impl._M_start._M_node;
__cur < this->_M_impl._M_finish._M_node;
++__cur)
std::uninitialized_fill(*__cur, *__cur + _S_buffer_size(),
__value);
/ HERE /
std::uninitialized_fill(this->_M_impl._M_finish._M_first,
this->_M_impl._M_finish._M_cur,
__value);
}
catch(...)
{
std::_Destroy(this->_M_impl._M_start, iterator(*__cur, __cur));
__throw_exception_again;
}
}
The test code is reproduced below. The assembler output of the
salient part of _M_fill_initialize is:
.L222:
lwz 3,0(31)
mr 5,30
addi 6,1,8
addi 4,3,512
.LEHB3:
bl
_ZSt24__uninitialized_fill_auxIP9TestClassS0_EvT_S2_RKT0_12__false_ty
pe
lwz 0,36(29)
addi 31,31,4
cmplw 7,0,31
bgt+ 7,.L222
li 31,0
.L240:
Examining the output .L240 corresponds to /*** HERE ***/.
When the for() loop terminates, it appears __cur is in r31 and is
zapped with 0. I suspect the optimizer has marked __cur as dead
at this point.
An exception caught whilst executing the 2nd unitialized_fill()
attempts to use __cur, but is thwarted because the value has been
lost.
I'm working with a port of dw2 based EH for powerpc VxWorks on
gcc 3.4.2. The compiler builds and is working. I have ported the EH
test from STLport, and most of the tests run.
(BTW the ported EH tests run to completion on cygwin.)
Earl
-
bash-2.05b$ /gnu/local/bin/powerpc-wrs-vxworks-g++ -v -S -O2 bug.cpp
Reading specs from /gnu/local/lib/gcc/powerpc-wrs-vxworks/3.4.2/specs
Configured with: ../gcc-3.4.2/configure --target=powerpc-wrs-vxworks
--disable-libstdcxx-pch --disable-shared --with-included-gettext
--with-gnu-as --with-gnu-ld --with-ld=powerpc-wrs-vxworks-ld
--with-as=powerpc-wrs-vxworks-as --exec-prefix=/gnu/local
--prefix=/gnu/local --enable-languages=c,c++
Thread model: vxworks
gcc version 3.4.2
/gnu/local/libexec/gcc/powerpc-wrs-vxworks/3.4.2/cc1plus.exe -quiet -v
-DCPU_FAMILY=PPC -D__ppc -D__EABI__ -DCPU=PPC604 -D__hardfp bug.cpp
-mcpu=604 -mstrict-align -quiet -dumpbase bug.cpp -auxbase bug -O2
-version -o bug.s
ignoring nonexistent directory
"/gnu/local/lib/gcc/powerpc-wrs-vxworks/3.4.2/../
../../../powerpc-wrs-vxworks/sys-include"
ignoring nonexistent directory "*CYGWIN1512PATH"
#include "..." search starts here:
#include <...> search starts here:
/gnu/local/lib/gcc/powerpc-wrs-vxworks/3.4.2/../../../../include/c++/3.4.2
/gnu/local/lib/gcc/powerpc-wrs-vxworks/3.4.2/../../../../include/c++/3.4.2/powe
rpc-wrs-vxworks
/gnu/local/lib/gcc/powerpc-wrs-vxworks/3.4.2/../../../../include/c++/3.4.2/back
ward
/gnu/local/lib/gcc/powerpc-wrs-vxworks/3.4.2/include
/gnu/local/lib/gcc/powerpc-wrs-vxworks/3.4.2/../../../../powerpc-wrs-vxworks/in
clude
End of search list.
GNU C++ version 3.4.2 (powerpc-wrs-vxworks)
compiled by GNU C version 3.4.1 (cygming special).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
bug.cpp:6: warning: inline function `TestClass::TestClass()' used but
never defi
ned
bug.cpp:9: warning: inline function `TestClass::~TestClass()' used but
never def
ined
bug.cpp:8: warning: inline function `TestClass::TestClass(const
TestClass&)' use
d but never defined
bug.cpp:11: warning: inline function `TestClass&
TestClass::operator=(const Test
Class&)' used but never defined
-
#include
class TestClass
{
public:
inline TestClass();
inline TestClass( int value );
inline TestClass( const TestClass& rhs );
inline ~TestClass();
inline TestClass& operator=( const TestClass& rhs );
inline int value() const;
inline TestClass operator!() const;
bool operator==( const TestClass& rhs ) const;
bool operator<( const TestClass& rhs ) const;
protected:
static inline unsigned int get_random(unsigned range = UINT_MAX);
private:
inline void Init( int value );
};
template class std::deque;
Re: Changed resolution of anonymous namespace extern from gcc 3.4.2 to 4.1.0
Earl Chew wrote:
I can't make up my mind whether the new behaviour is incorrect,
or whether the old behaviour should never have been supported.
I'm pretty certain this is a defect because I can construct a
program that should work, but doesn't.
In any case, I've discovered that this was an aberration of
4.1.0, and does not appear in later versions.
Consider foo.cpp:
namespace { extern const char f[]; }
namespace { const char f[] = "abc"; }
const char* g = f;
Expect variable g to be global, but f to have non-global scope.
3.4.2 Pass
4.1.0 Fail
4.1.1 Pass
4.1.2 Fail
4.1.2 ***
PASS ***
.file "foo.cpp"
.globl g
.data
.align 8
.type g, @object
.size g, 8
g:
.quad _ZN36_GLOBAL__N_foo.cpp__2B2B2FAE1fE
.section.rodata
.type _ZN36_GLOBAL__N_foo.cpp__2B2B2FAE1fE, @object
.size _ZN36_GLOBAL__N_foo.cpp__2B2B2FAE1fE, 4
_ZN36_GLOBAL__N_foo.cpp__2B2B2FAE1fE:
.string "abc"
.ident "GCC: (GNU) 4.1.2 20070626 (Red Hat 4.1.2-14)"
.section.note.GNU-stack,"",@progbits
4.1.1 ***
PASS ***
.file "foo.cpp"
.globl g
.data
.align 4
.type g, @object
.size g, 4
g:
.long _ZN36_GLOBAL__N_foo.cpp__8E53D9441fE
.section.rodata
.type _ZN36_GLOBAL__N_foo.cpp__8E53D9441fE, @object
.size _ZN36_GLOBAL__N_foo.cpp__8E53D9441fE, 4
_ZN36_GLOBAL__N_foo.cpp__8E53D9441fE:
.string "abc"
.ident "GCC: (GNU) 4.1.1 20070105 (Red Hat 4.1.1-51)"
.section.note.GNU-stack,"",@progbits
4.1.0 ***
FAIL ***
.file "foo.cpp"
.globl _ZN36_GLOBAL__N_foo.cpp__54D6CB4D1fE
.section.rodata
.type _ZN36_GLOBAL__N_foo.cpp__54D6CB4D1fE, @object
.size _ZN36_GLOBAL__N_foo.cpp__54D6CB4D1fE, 4
_ZN36_GLOBAL__N_foo.cpp__54D6CB4D1fE:
.string "abc"
.globl g
.data
.align 4
.type g, @object
.size g, 4
g:
.long _ZN36_GLOBAL__N_foo.cpp__54D6CB4D1fE
.ident "GCC: (GNU) 4.1.0"
.section.note.GNU-stack,"",@progbits
3.4.2 ***
PASS ***
.file "foo.cpp"
.globl _ZN36_GLOBAL__N_foo_cpp__4C2300AC1fE
.section.rodata
.align 2
.type _ZN36_GLOBAL__N_foo_cpp__4C2300AC1fE, @object
.size _ZN36_GLOBAL__N_foo_cpp__4C2300AC1fE, 4
_ZN36_GLOBAL__N_foo_cpp__4C2300AC1fE:
.string "abc"
.globl g
.section".data"
.align 2
.type g, @object
.size g, 4
g:
.long _ZN36_GLOBAL__N_foo_cpp__4C2300AC1fE
.ident "GCC: (GNU) 3.4.2 (mingw-special)"
