slice valarrays with std::string -> segfault
Please consider the program below (backtrace included (gcc 4.0.2
(Ubuntu))). The program crashes when doing a std::slice on a valarray
containing a structure with a string element in it.
Is what I am doing there undefined behaviour? I've read 26.3.4 from
the standard but got no clues.
As you can see in the backtrace the segfault happens when trying to
assign this string:
(gdb) print *__a
...
y = {
static npos = 18446744073709551615,
_M_dataplus = {
> = {
<__gnu_cxx::__mt_alloc >> = {
<__gnu_cxx::__mt_alloc_base> = {}, }, },
members of
std::basic_string,std::allocator
>::_Alloc_hider:
_M_p = 0x2adb9958 ""
}
to this string:
(gdb) print *__b
...
y = {
static npos = 18446744073709551615,
_M_dataplus = {
> = {
<__gnu_cxx::__mt_alloc >> = {
<__gnu_cxx::__mt_alloc_base> = {}, }, },
members of
std::basic_string,std::allocator
>::_Alloc_hider:
_M_p = 0x0
}
I am not sure why *__b is a 0x0-string, and who should be responsible
to initialize it correctly (__b is initialized in the C++ library). It
is mandated by the standard that only POD types are allowed in a
valarray?
Thanks,
(The program crashes with gcc 3.x und gcc 4.x, it works with Visual
Studio though :-().
--8<---cut here---start->8---
#include
struct element
{
int x;
std::string y;
element ()
{
x = 0;
y = "";
}
element const & operator = (element const & e)
{
if (this != &e)
{
x = e.x;
y = e.y; // Why is this.y = 0x0 ?
}
return *this;
}
};
int main (int argc, char **argv)
{
std::valarray y (element (), 1);
std::valarray z =
std::valarray (y [std::slice (0, 1, 1)]);
return 0;
}
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0 0x2ac80d52 in __gnu_cxx::__exchange_and_add () from
/usr/lib/libstdc++.so.6
(gdb) bt
#0 0x2ac80d52 in __gnu_cxx::__exchange_and_add () from
/usr/lib/libstdc++.so.6
#1 0x2ac61edc in std::string::assign () from /usr/lib/libstdc++.so.6
#2 0x00400c33 in element::operator= (this=0x502030, [EMAIL PROTECTED])
at valarray_segfault.cpp:19
#3 0x00400f9f in std::__valarray_copy (__a=0x502010, __n=1,
__s=1, __b=0x502030) at valarray_array.h:293
#4 0x00400ff9 in std::__valarray_copy (__a={_M_data =
0x502010}, __n=1, __s=1, __b={_M_data = 0x502030}) at valarray_array.h:457
#5 0x00401065 in valarray (this=0x7ffb1980, [EMAIL PROTECTED]) at
valarray:587
#6 0x00400961 in main (argc=1, argv=0x7ffb1ad8) at
valarray_segfault.cpp:30
(gdb) frame 3
#3 0x00400f9f in std::__valarray_copy (__a=0x502010, __n=1,
__s=1, __b=0x502030) at valarray_array.h:293
293 *__b = *__a;
(gdb) print *__b
$1 = {
x = 0,
y = {
static npos = 18446744073709551615,
_M_dataplus = {
> = {
<__gnu_cxx::__mt_alloc >> = {
<__gnu_cxx::__mt_alloc_base> = {}, }, },
members of
std::basic_string,std::allocator
>::_Alloc_hider:
_M_p = 0x0
}
}
}
(gdb) print *__a
$2 = {
x = 0,
y = {
static npos = 18446744073709551615,
_M_dataplus = {
> = {
<__gnu_cxx::__mt_alloc >> = {
<__gnu_cxx::__mt_alloc_base> = {}, }, },
members of
std::basic_string,std::allocator
>::_Alloc_hider:
_M_p = 0x2adb9958 ""
}
}
}
(gdb)
--8<---cut here---end--->8---
--
--Jhair
PGP key available from public servers - ID: 0xBAA600D0
Re: htsearch broken?
On Fri, Dec 09, 2005 at 08:40:24PM -0800, Will L (sent by Nabble.com) wrote: > > Try search Nabble, the gcc user list is archived here: > http://www.nabble.com/gcc---General-f1157.html Please note this is NOT, I repeat NOT, a GCC users list - this is a GCC developers list. There have been several mails sent via nabble.com to this list that should have been sent to gcc-help instead. jon -- "Convictions cause convicts" - Mal2
Re: funny problem with g++
On Wed, Dec 07, 2005 at 11:50:49PM +, Tristan Wibberley wrote: > > IMHO, this is a good extension, at least until boost::array gets > standardised. #include in GCC 4.0 jon
I can not catch the exception of Ada.
Hello, excuse my poor english. I can not catch the exception of Ada after gcc-4.1-20051125 on Windows. I confirmed with 4.1.0 20051202 and 4.1.0 20051209. I think, it seems probrem: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01075.html That patch removed calling builtin_longjmp from a-except.adb's Process_Raise_Exception. It supposed Zero_Cost_Exceptions /= 0 always, but gcc on Windows(MinGW, Cygwin) is still using sjlj exception. I think calling builtin_longjmp is need still. YT p.s. Some bit gcc-4.1 building probrems on MinGW and MSYS (my system only?): - failed to copy platform-independent gnat runtime to build directory gcc/ada/rts. - "makeinfo -o doc/gnat_ugn_unw.info doc/gnat_ugn_unw.texi" failed, needs --force. - as(shellscript) is called as.exe. - gnatdll.exe is not build. - libgcc.map is empty, fail to link for making cross-compiler. (target: FreeBSD4)
I can not catch the exception of Ada.
I can not catch the exception of Ada after gcc-4.1-20051125. I think, it seems probrem: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01075.html That patch removed calling builtin_longjmp from a-except.adb's Process_Raise_Exception. YT p.s.
Re: I can not catch the exception of Ada.
> I can not catch the exception of Ada after gcc-4.1-20051125 on Windows. > I confirmed with 4.1.0 20051202 and 4.1.0 20051209. Hmm, I guess the following patch will fix this. The issue is that we're using GCC dwarf2 EH mechanim by default under Windows, using yet to be submitted mingw patches, so this support cannot be enabled yet at the FSF. The patch is preapproved, assuming it fixes the issue. Arno -- --- Makefile.in.old 2005-12-10 11:08:01.779604000 -0500 +++ Makefile.in 2005-12-10 11:08:09.039416000 -0500 @@ -1164,7 +1164,6 @@ ifeq ($(strip $(filter-out cygwin32% min mlib-tgt.adb
Re: GNAT package GNAT.Traceback.Symbolic
BTW, has someone ported the binutils-2.13.2.1 libaddr2line patches to binutils-2.16? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
gcc-4.2-20051210 is now available
Snapshot gcc-4.2-20051210 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20051210/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 108355 You'll find: gcc-4.2-20051210.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20051210.tar.bz2 C front end and core compiler gcc-ada-4.2-20051210.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20051210.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20051210.tar.bz2 C++ front end and runtime gcc-java-4.2-20051210.tar.bz2 Java front end and runtime gcc-objc-4.2-20051210.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20051210.tar.bz2The GCC testsuite Diffs from 4.2-20051203 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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: I can not catch the exception of Ada.
Thank you, I confirmed to catch the exception with 4.1.0-20051209. > The issue is that we're using GCC dwarf2 EH mechanim by default under Windows, > using yet to be submitted mingw patches, so this support cannot be > enabled yet at the FSF. It's wonderful that zero cost exception comes to Windows! YT Arnaud Charlet wrote: I can not catch the exception of Ada after gcc-4.1-20051125 on Windows. I confirmed with 4.1.0 20051202 and 4.1.0 20051209. Hmm, I guess the following patch will fix this. The issue is that we're using GCC dwarf2 EH mechanim by default under Windows, using yet to be submitted mingw patches, so this support cannot be enabled yet at the FSF. The patch is preapproved, assuming it fixes the issue. Arno -- --- Makefile.in.old 2005-12-10 11:08:01.779604000 -0500 +++ Makefile.in 2005-12-10 11:08:09.039416000 -0500 @@ -1164,7 +1164,6 @@ ifeq ($(strip $(filter-out cygwin32% min mlib-tgt.adb - EH_MECHANISM=-gcc MISCLIB = -lwsock32 GMEM_LIB = gmemlib PREFIX_OBJS = $(PREFIX_REAL_OBJS)
Re: htsearch broken?
Jonathan Wakely wrote: > > Please note this is NOT, I repeat NOT, a GCC users list - this is a GCC > developers list. There have been several mails sent via nabble.com > to this list that should have been sent to gcc-help instead. > > jon > Jon, Sorry for the confusion. I just corrected the info on Nabble, and I quoted your remarks in the description. The url is now: http://www.nabble.com/gcc---Dev-f1157.html Nabble will develop a feature that will allow a user like you to correct this type of mistake by yourself. It will be kind of like wiki. But for now, thanks again for pointing this out. Regards, Will L Nabble.com -- Sent from the gcc - Dev forum at Nabble.com: http://www.nabble.com/htsearch-broken--t704225.html#a1884523
Re: Interesting observations wrt FDO and tramp3d-v4
> > I have added FDO runs to the daily tramp3d tester and am observing > "intersting" things there. First of all, compile time with > -fprofile-generate (w/o leafify) skyrocketed from ~120s to 440s. > For reference, here's the hot spots in -ftime-report: > > life analysis : 24.66 ( 6%) usr 0.00 ( 0%) sys 24.52 ( 5%) > wall 16086 kB ( 0%) ggc > integration : 13.67 ( 3%) usr 0.05 ( 0%) sys 13.67 ( 3%) > wall 806431 kB (23%) ggc > tree PTA : 10.17 ( 2%) usr 0.10 ( 1%) sys 10.24 ( 2%) > wall 20425 kB ( 1%) ggc > tree SSA incremental : 19.58 ( 5%) usr 0.21 ( 2%) sys 20.28 ( 5%) > wall 27383 kB ( 1%) ggc > tree operand scan : 11.87 ( 3%) usr 4.51 (35%) sys 16.62 ( 4%) > wall 94887 kB ( 3%) ggc > dominator optimization: 16.60 ( 4%) usr 0.06 ( 0%) sys 16.24 ( 4%) > wall 210301 kB ( 6%) ggc > expand: 23.51 ( 5%) usr 0.10 ( 1%) sys 23.15 ( 5%) > wall 310872 kB ( 9%) ggc > CSE : 52.40 (12%) usr 0.05 ( 0%) sys 52.44 (12%) > wall 24796 kB ( 1%) ggc > loop analysis : 20.06 ( 5%) usr 0.12 ( 1%) sys 20.23 ( 5%) > wall 26703 kB ( 1%) ggc > CSE 2 : 25.68 ( 6%) usr 0.01 ( 0%) sys 25.88 ( 6%) > wall1360 kB ( 0%) ggc > global alloc : 14.93 ( 3%) usr 0.08 ( 1%) sys 14.86 ( 3%) > wall 65979 kB ( 2%) ggc > reload CSE regs : 16.20 ( 4%) usr 0.04 ( 0%) sys 16.56 ( 4%) > wall 49571 kB ( 1%) ggc > rename registers : 10.76 ( 2%) usr 0.03 ( 0%) sys 10.67 ( 2%) > wall6109 kB ( 0%) ggc > TOTAL : 434.7112.95 448.78 > 3461889 kB > > look at those CSE numbers! (this is all with release checking only) > > 2nd, runtime of the profile generating binary raised by a factor of 50 > (this is just an -O2 compile, basically) > > Now, the interesting thing is, that with -fprofile-use, compile time > halved from the 120s to 62s. Nice. And the performance is exactly > the same as a non-FDO (non leafify) binary, which suggests, that we > can improve inlining heuristics wrt compile-time without regressing > in runtime performance. > > The profile generating numbers suggest we're either doing something > stupid, or that we want some heuristics applied to not instrument > every edge, but only interesting ones. I would not want into busyness of having partially profiled programs. This makes the number of cases you have to think of bigger and results more dependent on heuristics. So lets try to concentrate on getting the costs down for the moment. For most program I would believe that the current algorithm to instrumentate only non-spanning-tree edges should work just well enough. I actually believe large port of the slowdown is the fact that we understand little the aliasing of counters. We assume them to be caller clobberred, aliased with each other and so on as we do on global variables. If there was some easy way to tell aliasing that these are well behaved, the SSA representation should simplify a lot. As for CSE, we are excercising the same problem - your testcase has the property that very many basic blocks before inliing gets merged together so we get large basic blocks with many increments of different global vars and because of the quadratic behaviour of our aliasing information there, we degrade. While this can, in theory, be solved similar way as for SSA representation by somehow bypassing the aliasing info, perhaps more consistently with our plan, we can trottle down the CSE tables. Irritantingly all CSE knows is to throw away all tables after fixed number of instructions set to 1000 right now, while it really wants something like trottling down the amount of entries in hashtable. Adding some counters on number of entries and trottling them down to lower number probably will work. I can try to look into it once I get out of issues I am swamped in right now unless someone beats me ;) Honza > > Richard.
Re: slice valarrays with std::string -> segfault
Jhair Tocancipa Triana wrote: >Please consider the program below (backtrace included (gcc 4.0.2 >(Ubuntu))). The program crashes when doing a std::slice on a valarray >containing a structure with a string element in it. > > Just wanted to say that this has nothing to do with string specifically, happens also together with a completely different implementation of string or, e.g., together with a deque data member. I think something is going wrong with types characterized by ""non-trivial"" constructors, e.g., doing memory allocation from the heap. Gaby can you look into this? Thanks for your report, Paolo.
Re: slice valarrays with std::string -> segfault
Paolo Carlini wrote: >I think something is going wrong with types characterized by >""non-trivial"" constructors, e.g., doing memory allocation from the heap. > >Gaby can you look into this? > > Gaby, I see __valarray_copy used (instead of __valarray_copy_construct) by the conversion constructor from slice_array for any type T: i.e., no placement new, that cannot possibly work a T such as 'struct element' in the posted snippet. Indeed, lots and lots of errors from valgrind... Maybe there is something I'm missing in the Specs of valarray for the conversion constructors? Paolo.
Re: slice valarrays with std::string -> segfault
Jhair Tocancipa Triana <[EMAIL PROTECTED]> writes: [...] | I am not sure why *__b is a 0x0-string, and who should be responsible | to initialize it correctly (__b is initialized in the C++ library). It | is mandated by the standard that only POD types are allowed in a | valarray? The reason is because a careless thinking has led the implementor of valarray to use _copy instead of _copy_construct. -- Gaby
Re: slice valarrays with std::string -> segfault
Paolo Carlini <[EMAIL PROTECTED]> writes: | Jhair Tocancipa Triana wrote: | | >Please consider the program below (backtrace included (gcc 4.0.2 | >(Ubuntu))). The program crashes when doing a std::slice on a valarray | >containing a structure with a string element in it. | > | > | Just wanted to say that this has nothing to do with string specifically, | happens also together with a completely different implementation of | string or, e.g., together with a deque data member. | | I think something is going wrong with types characterized by | ""non-trivial"" constructors, e.g., doing memory allocation from the heap. | | Gaby can you look into this? yes -- see my other message. I could not read mails before now. The main fault is my thoughtless use of _copy instead of _copy_construct. -- Gaby
Re: slice valarrays with std::string -> segfault
Paolo Carlini <[EMAIL PROTECTED]> writes: | Paolo Carlini wrote: | | >I think something is going wrong with types characterized by | >""non-trivial"" constructors, e.g., doing memory allocation from the heap. | > | >Gaby can you look into this? | > | > | Gaby, I see __valarray_copy used (instead of __valarray_copy_construct) | by the conversion constructor from slice_array for any type T: i.e., no | placement new, that cannot possibly work a T such as 'struct element' in | the posted snippet. Indeed, lots and lots of errors from valgrind... Yes, you're right. Anything that puts elements into a valarray being constructed should use _copy_construct. -- Gaby
[C, C++] fundamental type object representation
Hi, Does GCC support any target where the object representation of a fundamental type T (e.g. int, float, double, pointers) whose all bits are zero does not hold value (T)0? Thanks, -- Gaby
Re: [C, C++] fundamental type object representation
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> Does GCC support any target where the object representation of a
> fundamental type T (e.g. int, float, double, pointers) whose all bits
> are zero does not hold value (T)0?
Surprisingly, the answer seems to be yes. For the C4X target, a
single precision floating point zero is apparently represented as
0x8000 (for double precision there is another 32 zero bits).
That said, it doesn't actually work correctly. Compiling
float f;
float g = 0.0;
struct s { int i; float f; int j; };
struct s sv = { 1, 0.0, 2 };
gives me
.file "foo.c"
.version40
.data
data_sec:
.global _g
.globl _g
.bss_g,1
.global _sv
.data
_sv:
.word 1
.word -2147483648
.word 2
.globl _f
.bss_f,1
.end
In other words, the floating point zero is only generated correctly
when gcc is forced to output the initializer for some other reason.
Given that doesn't work, it is probably reasonably safe to assume gcc
is always going to generate all zero bits for a fundamental types
initialized to zero.
Ian
Re: [C, C++] fundamental type object representation
Ian Lance Taylor writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| > Does GCC support any target where the object representation of a
| > fundamental type T (e.g. int, float, double, pointers) whose all bits
| > are zero does not hold value (T)0?
|
| Surprisingly, the answer seems to be yes.
Oh gosh.
| For the C4X target, a
| single precision floating point zero is apparently represented as
| 0x8000 (for double precision there is another 32 zero bits).
Very interesting.
| That said, it doesn't actually work correctly. Compiling
|
| float f;
| float g = 0.0;
| struct s { int i; float f; int j; };
| struct s sv = { 1, 0.0, 2 };
|
| gives me
|
| .file "foo.c"
| .version40
|
| .data
| data_sec:
| .global _g
| .globl _g
| .bss_g,1
| .global _sv
| .data
| _sv:
| .word 1
| .word -2147483648
| .word 2
| .globl _f
| .bss_f,1
| .end
|
| In other words, the floating point zero is only generated correctly
| when gcc is forced to output the initializer for some other reason.
I guess, this is not something C4X maintainers will correct in the future?
| Given that doesn't work, it is probably reasonably safe to assume gcc
| is always going to generate all zero bits for a fundamental types
| initialized to zero.
OK, thanks. I was rewriting part of valarray and I saw I made that
assumption, and since it is bug chasing time I thought I should make
sure my use of memset() isn't going to bomb out.
-- Gaby
