|new []| better not overflow and crash with g++
once upon a time |calloc(BIG,BIG)| silently overflowed, now it is fixed. nowadays |new int[bignumber]| overflows as in: [1] volatile size_t n; n= 4+((size_t)-1)/sizeof(int); int *ptr; cout << "n=" << n << endl; ptr=new int[n]; cout << "ptr=" << ptr << endl; cout << "ptr[n/2]=" << ptr[n/2] << endl; ./a.out n=4611686018427387907 ptr=0x602010 Segmentation fault [2] |int| may be replaced by another |Class|. ironically, fixing with checking for overflow of sizeof(Class)*numclasses is not enough because g++ adds |epsilon| >= sizeof(size_t) probably to know how many |this| to destruct later. #define TYP CL n= ((size_t)-1)/sizeof(TYP); TYP *ptr; cout << "size=" << sizeof(CL) <
Re: Problem reading corefiles on ARM
Hi, I was reading the "Problem reading corefiles on ARM" thread at the gcc mailing list (from www-archive, I'm not subscribed) and the conclusions are incorrect: http://gcc.gnu.org/ml/gcc/2008-08/msg00075.html The problem in GCC noreturn attribute handling isn't how it optimizes calling of the noreturn functions, but how it optimizes noreturn functions themselves. This can be verified by compiling *just* the noreturn function with "-O0" as then backtraces work just fine in Gdb. A colleague of mine (who unlike me knows ARM assembly) looked at the generated assembly of the noreturn functions and the problem with the generated noreturn function code is that it clobbers the link register required by GCC for backtracing. Could this be fixed? - Eero PS: this concerns Gcc 4(.2.1). In Gcc 3.4.4 it was enough to use -fno-omit-frame-pointer for compiling noreturn functions. This was fairly easy to do in Glibc because each function is in a separate *.c file, -O0 is more awkward because disabling optimizations changes how Glibc headers work for those functions.
GCC 3.4.6 on x86_64: __builtin_frame_address(1) of topmost frame doesn't return 0x0
Hi,
in binaries compiled with gcc 3.4.6 on an x86_64 machine, I get the following
behaviour. I wrote a little testcase:
int main(int argc, char **argv)
{
unsigned long addr;
if ( (addr = (unsigned long)(__builtin_frame_address(0))) )
{
printf ("0x%08lx\n", addr);
if ( (addr = (unsigned long)(__builtin_frame_address(1))) )
{
printf ("0x%08lx\n", addr);
if ( (addr = (unsigned long)(__builtin_frame_address(2))) )
{
printf ("0x%08lx\n", addr);
// ... some more scopes ...
}
}
}
return 0;
}
This code is a bit ugly, I made it that way because of the part in gcc's
manpages:
"CC also has two builtins that can assist you, but which may or may not be
implemented fully on your architecture, and those are __builtin_frame_address
and __builtin_return_address. Both of which want an immediate integer level
(by immediate, I mean it can't be a variable)."
- but it doesn't change the outcome of the test, anyway.
I ran the test on three machines with the following results:
1)
[EMAIL PROTECTED] ~]$ uname -m
i686
[EMAIL PROTECTED] ~]$ gcc -v
Lese Spezifikationen von /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
Konfiguriert
mit: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread-Modell: posix
gcc-Version 3.4.6 20060404 (Red Hat 3.4.6-10)
[EMAIL PROTECTED] ~]$ gcc -o test test.c && ./test
0xbfefc048
0xbfefc0a8
[EMAIL PROTECTED] ~]$
2)
[EMAIL PROTECTED] ~]$ uname -m
x86_64
[EMAIL PROTECTED] ~]$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured
with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)
[EMAIL PROTECTED] ~]$ gcc -o test test.c && ./test
0x7fffc400c8c0
[EMAIL PROTECTED] ~]$
3)
[EMAIL PROTECTED] ~]$ uname -m
x86_64
[EMAIL PROTECTED] ~]$ gcc -v
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
Configured
with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-10)
[EMAIL PROTECTED] ~]$ gcc -o test test.c && ./test
0x7fb8c0
0x35952357a8
0x7fb9a8
0x7fbb7b
0x454d414e54534f48
Segmentation fault
[EMAIL PROTECTED] ~]$
So, on the 32bit machine and on the 64bit machine running gcc 4.x, the end of
the stack is found (__builtin_frame_address(n) returned 0x0). The output is a
bit different, apparently on the 32bit machine, the stackframe of the caller
of main() is also found, but that is not important for the error.
On the 64bit machine using gcc 3.4.6 however, at some point, garbage (?) is
returned.
My questions now are, is this known behaviour / a known issue? I didn't find a
fitting patch. Or, can the fix for it be backported from gcc 4.x to 3.4.x? I
cannot switch to gcc 4.x for some other reasons. If all this doesn't result
in a solution, is there maybe another way for me to determine which
stackframe is the topmost one? (Should I just compare the function name
with "main"? That'd be a bit dirty, wouldn't it?)
Thanks,
Tim München
Re: |new []| better not overflow and crash with g++
* Georgi Guninski: > once upon a time |calloc(BIG,BIG)| silently overflowed, now it is fixed. > > nowadays |new int[bignumber]| overflows as in: This is PR19351, first reported in 2002 (along with the calloc issue).
Warning when compiling dwarf2out.c with -ftree-parallelize-loops=4
Hi,
When enabling -ftree-parallelize-loops=4 , bootstrap fails:
cc1: warnings being treated as errors
../../gcc/gcc/dwarf2out.c: In function âdwarf2out_frame_debugâ:
../../gcc/gcc/dwarf2out.c:2393: error: array subscript is above array
bounds
../../gcc/gcc/dwarf2out.c:2394: error: array subscript is above array
bounds
The array ref for which the subscript exceeded the boundary is
regs_saved_in_regs[i].
The array is defined:
static GTY(()) struct reg_saved_in_data regs_saved_in_regs[4];
therefore the upper bound of the array regs_saved_in_regs is 3
and the subscript is i.
However, when autopar pass is enabled,
the following condition is inserted :
if (num_iterations > 400-1)
{ /* parallel code. */
GOMP_parallel_start
loopfn ();
GOMP_parallel_end
last iteration of the loop; /* accessing the array:
regs_saved_in_regs[i] */
}
else
goto serial code
After VRP propagation, 400 is marked as the up_sub.
Since VRP can now determine that the array subscript is a constant, the
check of validity fails.
if (TREE_CODE (up_sub) == INTEGER_CST
&& tree_int_cst_lt (up_bound, up_sub)
&& !tree_int_cst_equal (up_bound, up_sub)
&& (!ignore_off_by_one
|| !tree_int_cst_equal (int_const_binop (PLUS_EXPR, up_bound,
integer_one_node, 0), up_sub)))
warning (OPT_Warray_bounds, "%Harray subscript is above array
bounds", location);
As far as I get it, there is no real failure here.
Parloop, unaware of the array's upper bound, inserts the 'enough
iterations' condition (i>400-1), and thereby
makes the last iteration range from 400 upwards.
VRP now has a constant it can compare to the array's upper bound.
Correct programs that do not exceed the array bound will now fail because
VRP is not aware of the
fact that the parallel code (and last iteration it is looking at) is
actually not executed in these cases.
I'm not sure how to proceed, in order to avoid this warning.
Any ideas?
Thanks,
Razya
Re: GCC 3.4.6 on x86_64: __builtin_frame_address(1) of topmost frame doesn't return 0x0
__builtin_frame_address with non-zero arguments is not supported on most targets these days. It'll work on x86-64 if you also compile with -fno-omit-frame-pointer. That said, you almost certainly want to be using backtrace(3) instead. r~
Re: Warning when compiling dwarf2out.c with -ftree-parallelize-loops=4
Hi, > As far as I get it, there is no real failure here. > Parloop, unaware of the array's upper bound, inserts the 'enough > iterations' condition (i>400-1), and thereby > makes the last iteration range from 400 upwards. > VRP now has a constant it can compare to the array's upper bound. > Correct programs that do not exceed the array bound will now fail because > VRP is not aware of the > fact that the parallel code (and last iteration it is looking at) is > actually not executed in these cases. > > I'm not sure how to proceed, in order to avoid this warning. > Any ideas? I would propose changing the test expected_loop_iterations (loop) <= n_threads in tree-parloops.c to ((nit = estimated_loop_iterations_int (loop, false)) >= 0 && nit < MIN_PER_THREAD * n_threads) Which should prevent the parallelization for this loop, as we should be able to derive that the loop iterates at most 4 times due to the array access. Zdenek
Re: [RFC] Remove -frtl-abstract-sequences in 4.5
Diego Novillo wrote: On Mon, Nov 24, 2008 at 12:23, Mark Mitchell <[EMAIL PROTECTED]> wrote: David Edelsohn wrote: It currently is broken on many platforms. Why not remove it now? What is the purpose of keeping a pass that does not work correctly and developers cannot use? As a user I'd like to point out that I would jump up and down in joy if -frtl-abstract-sequences would work. I do a lot of embedded work for a wide range of targets using GCC and often I find myself in situations where another 20 to 30% of code-reduction could improve the performance of my code a lot. My targets often just have a simplistic 8k direct mapped code-cache. For critical things I did just what -frtl-abstract-sequences did (along with some hand optimizing) and I've seen performance improvements of 50% and more just by getting my working set of code to fit into the cache-size. Once the feature is removed: Will there ever be any chance that the feature will be re-implemented? Maybe someone with contacts could convince NXP, ARM, NEC or another low/middle end microcontroller manufacturer to pay someone to do fix the current code instead of removing it. These days probably noone do so, but maybe in a year or two when we're all less paranoid about the world economy someone could be convinced. The potential performance improvement for small cache architectures should not be underestimated: However, in the current state the feature is useless and should be removed. (in the tests I've done so far it hangs the gcc even with very simple code). Cheers, Nils
