Maybe bug in call function to static declaration variable?
Hi colleagues,
The follow program is an abstraction of on application where it
produce an error in runtime and i don't know why it's success.
The program compile very good in all cases with Visual Studio 2005,
2008, 2010, MinGW 4.5.1 on Windows 7 and with GCC 4.3 on GNU Debian.
Though, it produce an error in runtime when it's compiled with MinGW
or GCC and next it's executed.
Anybody can help me to distinguish whether it's an error of my source
code or a bug of gcc?
=== source code ===
template
class reference
{
public:
reference(T& p)
{
}
};
struct schema
{
};
template
struct schema_descriptor
{
typedef schema type;
};
template
inline schema* type_schema()
{
typedef typename schema_descriptor::type type_type;
static type_type result;
return &result;
};
template
struct reference_schema : schema
{
reference_schema():
schema()
{
schema* _delegate = type_schema();
}
};
struct basic_schema : schema
{
public:
template
void caster()
{
schema *src = type_schema();
}
};
template
struct object_schema : basic_schema
{
template
void implements()
{
typedef reference my_ref;
typedef reference their_ref;
caster();
}
};
template
struct dynamic_object_schema : object_schema
{
dynamic_object_schema()
{
this->template implements();
}
};
class sponge_object
{
};
struct sponge_object_schema : dynamic_object_schema
{
};
template <>
struct schema_descriptor
{
typedef sponge_object_schema type;
};
template <>
struct schema_descriptor< reference >
{
typedef reference_schema type;
};
int main()
{
reference_schema exploit;
return 0;
}
=== source code ===
I began to debug the source code with GDB and this is the result
that i got.
1 - reference_schema
// it's specialize
2 - type_schema
3 - sponge_object_schema
4 - dynamic_object_schema
5 - object_schema ::implements ();
6 - basic_schema::caster ,
reference, ...>();
// it's specialize
7 - type_schema < reference >
// at this point it begin to repeat
8 - reference_schema
// here it exploit and i don't know why
// if it's a static declaration
9 - type_schema
Like you see, the points 1 and 8 are equal, and then 2 and 9 are equal
too, but the static declaration inside 'type_schema'
static type_type result;
don't have to created again, since it's created already in the point
2, because it's a static declaration. In GNU Debian Linux it's produce
the error:
terminate called after throwing an instance of
'--gnu_cxx::recursive_init_error' what : std::exceptions.
and in Windows it stay sleeping until the application is closed by
Windows.
--
Best regards,
Gilberto Cuba Ricardo
PD: Sorry for the long extension of the message and for my bad
english.
Re: Maybe bug in call function to static declaration variable?
Hi Gilberto,
On Sun, Nov 14, 2010 at 09:47:43AM -0500, Gilberto Cuba Ricardo wrote:
> Hi colleagues,
>
> The follow program is an abstraction of on application where it
> produce an error in runtime and i don't know why it's success.
>
> The program compile very good in all cases with Visual Studio 2005,
> 2008, 2010, MinGW 4.5.1 on Windows 7 and with GCC 4.3 on GNU Debian.
> Though, it produce an error in runtime when it's compiled with MinGW
> or GCC and next it's executed.
>
> Anybody can help me to distinguish whether it's an error of my source
> code or a bug of gcc?
I believe it's a problem of your code.
If I reduce your example code to a minimal example showing the problem,
I obtain:
void type_schema();
struct sponge_object_schema
{
sponge_object_schema(){
type_schema();
}
};
void type_schema()
{
static sponge_object_schema result;
};
int main()
{
type_schema();
}
This creates the same runtime-error:
terminate called after throwing an instance of '__gnu_cxx::recursive_init_error'
what(): std::exception
In this more simple example, one can see the problem: In order to create
the static object "result" in the function "type_schema", the function
"type_schema" is called itself (from the constructor needed for "type"):
this is not possible:
- the code executes "type_schema", and allocates memory for the
variable "result".
- then the constructor "sponge_object_schema" is called.
- the constructor calls "type_schema"
- and now in "type_shema", it is not possible to access/use the static
object "result", as its constructor is NOT FINISHED YET
So you have a problem.
I have no idea, whether the compiler could/should detect this problem at
compile-time (well, in this particular example it could, but in general
it is impossible), but at least it's detected at runtime :-)
In your example code, the same thing happens:
"type_schema" calls the constructor for the static object
-- but then "type_schema" is again called from this
constructor.
I don't see a way how the compiler COULD create working code which
solves this problem -- For your code it would be necessary to USE the
static object before its constructor is finished...
HTH,
Axel
gcc-4.3-20101114 is now available
Snapshot gcc-4.3-20101114 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20101114/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 166735 You'll find: gcc-4.3-20101114.tar.bz2 Complete GCC (includes all of below) MD5=1d67eab5cf7afdbb9310c21f0dea798e SHA1=da80a55e548510f859895cca65361e6de05155e8 gcc-core-4.3-20101114.tar.bz2C front end and core compiler MD5=63b04768bf5211aa02ab74704317351d SHA1=27d85e496e644019ddbc83abc4eba1bfb9ab401b gcc-ada-4.3-20101114.tar.bz2 Ada front end and runtime MD5=b384222d1cbdc8bb9f393359b30e63b4 SHA1=2ccfc4ebdf3297716a4130a94451980f6ba91f7f gcc-fortran-4.3-20101114.tar.bz2 Fortran front end and runtime MD5=d8f08746c720641a9dd6bde0242e5cbb SHA1=15ed388e0a78e0f900261d0c1d2fe4fa678f062c gcc-g++-4.3-20101114.tar.bz2 C++ front end and runtime MD5=07a8f49efd7150bd34321fac4eaddb9a SHA1=a607793d30f089d39a654ead98e30f6daa52c650 gcc-java-4.3-20101114.tar.bz2Java front end and runtime MD5=0eb6c4a42853524df3b820af0f041ba2 SHA1=9fa921b15b42acd37bfb32f84fc6d3b789bfcf7b gcc-objc-4.3-20101114.tar.bz2Objective-C front end and runtime MD5=ebf0c5fb1d6138d64eac93fa52ccffb0 SHA1=aa68f57a58b34208b04a5806c33a34399e01b503 gcc-testsuite-4.3-20101114.tar.bz2 The GCC testsuite MD5=e95e1a129dbc36fcac83bb153564ea52 SHA1=0072217c42210e304f412f4a9ca2be7c3a85787c Diffs from 4.3-20101107 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
reload_combine vs. exceptions
It appears that reload_combine does not take exceptions into account. When it encounters a BARRIER it forgets all register uses after this point. But an exception can transfer control to any of the CODE_LABELs and jump back to after the BARRIER, with the registers still in use. See PR46395 for a test case. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: I propose Ralf Wildenhues for build machinery maintainer
On Mon, 8 Nov 2010, Gerald Pfeifer wrote: >> To the steering committee: I propose Ralf Wildenhues as a new >> maintainer for the build machinery. > I've relayed this proposal, thanks Ian. I am happy to announce Ralf's appointment as build machinery maintainer. As usual, happy hacking, Ralf -- and please update the MAINTAINERS file accordingly. Gerald
Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?
Gcc 4.5.1 running on an amd64 box "cross"-compiling for a P3 i8k fails to compile the module since commit 6b4e81db2552bad04100e7d5ddeed7e848f53b48 with: CC drivers/char/i8k.o drivers/char/i8k.c: In function ‘i8k_smm’: drivers/char/i8k.c:149:2: error: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’ drivers/char/i8k.c:149:2: error: ‘asm’ operand has impossible constraints -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?
On Sun, Nov 14, 2010 at 4:52 PM, James Cloos wrote: > Gcc 4.5.1 running on an amd64 box "cross"-compiling for a P3 i8k fails > to compile the module since commit 6b4e81db2552bad04100e7d5ddeed7e848f53b48 > with: > > CC drivers/char/i8k.o > drivers/char/i8k.c: In function ‘i8k_smm’: > drivers/char/i8k.c:149:2: error: can't find a register in class > ‘GENERAL_REGS’ while reloading ‘asm’ > drivers/char/i8k.c:149:2: error: ‘asm’ operand has impossible constraints At this point, I think this falls clearly under "unresolvable gcc bug". Quite frankly, I think gcc was buggy to begin with: since we had a memory clobber, the "+m" (*regs) should not have mattered. The fact that "*regs" may be some local variable doesn't make any difference what-so-ever, since we took the address of the variable. So the memory clobber _clearly_ can change that variable. So when Richard Gunther says "a memory clobber doesn't cover automatic storage", to me that very clearly spells "gcc is buggy as hell". Because automatic storage with its address taken _very_ much gets clobbered by things like memset etc. If the compiler doesn't understand that, the compiler is just broken. And now, if even the (superfluous) "+m" isn't working, it sounds like we have no sane options left. Except to say that gcc-4.5.1 is totally broken wrt asms. Can we just get gcc to realize that when you pass the address of automatic storage to an asm, that means that "memory" really does clobber it? Because clearly that is the case. Linus
Symbolic range analysis
Hi All, Does it perform symbolic range analysis or array section analysis in GCC-4.6 ? Thanks, Hongtao Yu Purdue University
Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64
Thanks, this works. gcc vs llvm 176.gcc: +3.7% 252.eon: +6.1% David On Sat, Nov 13, 2010 at 3:14 PM, H.J. Lu wrote: > On Sat, Nov 13, 2010 at 1:08 PM, Xinliang David Li wrote: >> >> Though gcc leads LLVM in performance overrall, there are a couple of >> benchmarks gcc is worse: vpr and crafty (64bit and 32bit), parser and >> twolf (32bit), vortex (64bit). This needs to be triaged. gcc >> miscompiles gcc and eon in 32bit -- is there a bug tracking the >> problem? >> > > GCC trunk compiles and runs SPEC CPU 2K correctly at > -O2 and -O3 for both 32bit and 64bit on x86: > > http://gcc.gnu.org/ml/gcc-testresults/2010-11/msg00977.html > http://gcc.gnu.org/ml/gcc-testresults/2010-11/msg00983.html > > You need alternate source for eon. I use: > > 252.eon=default=default=default: > CXXPORTABILITY = -DHAS_ERRLIST > EXTRA_CXXFLAGS=-ffast-math -mpc64 > EXTRA_LDFLAGS = -ffast-math -mpc64 > srcalt=gcc43 > > 176.gcc=default=default=default: > CPORTABILITY = -Dalloca=_alloca > > > -- > H.J. >
