Why is this a problem in the C++ bootstrap and not the normal one ?
My C++-fu is pretty non-existent; I tried a C++ bootstrap and got this: http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg01129.html Why is that a problem in the C++ bootstrap and not the normal one ? Cheers, -- Toon Moene, KNMI (Weer/Onderzoek), The Netherlands Phone: +31 30 2206443; e-mail: mo...@knmi.nl
Re: Why is this a problem in the C++ bootstrap and not the normal one ?
On 11 May 2011 13:58, Toon Moene wrote: > My C++-fu is pretty non-existent; I tried a C++ bootstrap and got this: > > http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg01129.html > > Why is that a problem in the C++ bootstrap and not the normal one ? -Wconversion-null is C++ only 'false' is a valid null pointer constant so the code is valid, but changing false to NULL would stop the warning.
Bugzilla new bug page
Can we increase the size of the text at the top of the Enter Bug page? "Before reporting a bug, please read the bug writing guidelines, please look at the list of most frequently reported bugs, and please search for the bug." It's not very prominent. Also, Bugzilla mails to the gcc-bugs list seem to be very slow at the moment, taking 5 mins or more to appear. This one took an hour: http://gcc.gnu.org/ml/gcc-bugs/2011-05/msg00933.html
Re: basic bloc chaining: using dominance
On 10/05/2011 16:23, Ian Lance Taylor wrote: Pierre Vittet writes: I am working on a plugin at the GIMPLE state, I am parsing basic blocks and I need to check that a call to foo() is only present once in a function. Howerver, it can be present several times if it is in different basic blocks and only one is executed at execution time. I think the most convenient way is to use dominance relation between the basic blocks: I can warn in a basic block A calling the foo() function only if there is a block B calling foo and dominating A. In others cases, I cannot be sure that there is several calls to foo(). In the file gcc/dominance.c, there is a dominated_by_p function which allows to test dominance between 2 basic blocks and I would like to use it to solve this problem. I would like to have your opinion, does it looks the google solution to the problem or is there another way to do this? If this is a good solution, I will implement a primitive in MELT allowing to use dominated_by_p function in MELT. Yes, dominated_by_p and friends are the right way to test for basic block dominance. Note that you have to build the graph first; see uses of calculate_dominance_info. Ian First, thanks for your help. I have looked at several function using calculate_dominance_info(). From what I understand, when you have finish to use it, you have to clear the structure by making a free_dominance_info(). In the function flow_loops_find (file gcc/cfgloop.c), there is a call to calculate_dominance_info() without call to free_dominance_info(). I feel it is a bug, no?
Re: Why is this a problem in the C++ bootstrap and not the normal one ?
On 05/11/2011 02:58 PM, Toon Moene wrote: My C++-fu is pretty non-existent; I tried a C++ bootstrap and got this: http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg01129.html Why is that a problem in the C++ bootstrap and not the normal one ? For completeness, the message is generated by the attached script, run by cron at 18:10 UTC. The build is a native one on x86_64-unknown-linux-gnu. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news #!/bin/sh export TMPDIR=/scratch/toon/tmp$$ mkdir $TMPDIR cd $HOME/compilers/gcc && \ svn up && \ echo "`date -u` (revision `svnversion .`)" >> LAST_UPDATED && \ cd ../obj-t && \ rm -rf * ( \ ../gcc/configure \ --prefix=/tmp/c++ \ --enable-build-with-cxx \ --with-gnu-ld \ --disable-multilib \ --disable-nls \ --with-arch=native \ --with-tune=native && \ make -j 8 \ ) >& $TMPDIR/log if [ $? -eq 0 ] then make -k -j 8 check ../gcc/contrib/test_summary | sh else tail -90 $TMPDIR/log | \ Mail -s \ "Trunk C++ Bootstrap of `tail -1 ../gcc/LAST_UPDATED` FAILED" \ gcc-testresu...@gcc.gnu.org fi rm -rf $TMPDIR exit 0
Re: basic bloc chaining: using dominance
Pierre Vittet writes: > First, thanks for your help. I have looked at several function using > calculate_dominance_info(). From what I understand, when you have > finish to use it, you have to clear the structure by making a > free_dominance_info(). > In the function flow_loops_find (file gcc/cfgloop.c), there is a call > to calculate_dominance_info() without call to free_dominance_info(). I > feel it is a bug, no? Not in this case, no. The caller or a later pass is responsible for freeing it in this case. There should ideally be a comment about this. Ian
Non-optimal stack usage with C++ temporaries
I've noticed some behavior with g++ that seems strange to me. I don't
know if there's some technicality in the C++ standard that requires
this, or if it's just a limitation to the optimization code, but it
seemed strange so I thought I'd see if anybody could shed more light
on it.
Here's a test program that illustrates the behavior:
struct Foo {
char buf[256];
Foo() {} // suppress automatically-generated constructor code for clarity
~Foo() {}
};
void func0(const Foo &);
void func1(const Foo &);
void func2(const Foo &);
void func3(const Foo &);
void f()
{
func0(Foo());
func1(Foo());
func2(Foo());
func3(Foo());
}
Compiling with -O2 and "-fno-stack-protector -fno-exceptions" for
clarity, on g++ 4.4.3, gives the following:
:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 81 ec 18 04 00 00 sub$0x418,%esp
9: 8d 85 f8 fb ff ff lea-0x408(%ebp),%eax
f: 89 04 24mov%eax,(%esp)
12: e8 fc ff ff ff call 13 <_Z1fv+0x13>
17: 8d 85 f8 fc ff ff lea-0x308(%ebp),%eax
1d: 89 04 24mov%eax,(%esp)
20: e8 fc ff ff ff call 21 <_Z1fv+0x21>
25: 8d 85 f8 fd ff ff lea-0x208(%ebp),%eax
2b: 89 04 24mov%eax,(%esp)
2e: e8 fc ff ff ff call 2f <_Z1fv+0x2f>
33: 8d 85 f8 fe ff ff lea-0x108(%ebp),%eax
39: 89 04 24mov%eax,(%esp)
3c: e8 fc ff ff ff call 3d <_Z1fv+0x3d>
41: c9 leave
42: c3 ret
The function makes four function calls, each of which constructs a
temporary for the parameter. The compiler dutifully allocates stack
space to construct these, but it seems to allocate separate stack
space for each of the temporaries. This seems unnecessary--since
their lifetimes don't overlap, the same stack space could be used for
each of them. The real-life code I adapted this example from had a
fairly large number of temporaries strewn throughout it, each of which
were quite large, so this behavior caused the generated function to
use up a pretty substantial amount of stack, for what seems like no
good reason.
My question is, is this expected behavior? My understanding of the
C++ standard is that each of those temporaries goes away at the
semicolon, so it seems like they have non-overlapping lifetimes, but I
know there are some exceptions to that rule. Could someone comment on
whether this is an actual bug, or required for some reason by the
standard, or just behavior that not enough people have run into
problems with?
Thanks,
Matt
Re: basic block chaining: using dominance
On Wed, 11 May 2011 13:03:16 -0700
Ian Lance Taylor wrote:
> Pierre Vittet writes:
>
> > First, thanks for your help. I have looked at several function using
> > calculate_dominance_info(). From what I understand, when you have
> > finish to use it, you have to clear the structure by making a
> > free_dominance_info().
I can't understand why the dominance information is not garbage
collected. Why is it not GTY-ed? Has it been GTY-ed in the past?
As you imagine, my preference is to GTY more data, not less. Because I
feel it improves a lot (as the dominance information demonstrates) the
maintainability & readability of the GCC compiler (which, in my
personal opinion, is even more important than the CPU time spent in
cc1, because the rare resources are GCC developers, not processors.).
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Why is this a problem in the C++ bootstrap and not the normal one ?
Toon Moene wrote: On 05/11/2011 02:58 PM, Toon Moene wrote: My C++-fu is pretty non-existent; I tried a C++ bootstrap and got this: http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg01129.html Why is that a problem in the C++ bootstrap and not the normal one ? For completeness, the message is generated by the attached script, run by cron at 18:10 UTC. The build is a native one on x86_64-unknown-linux-gnu. I thought that adding --disable-werror would bring us further, but as it turns out - not by much: http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg01224.html says: /home/toon/compilers/obj-t/./prev-gcc/g++ -B/home/toon/compilers/obj-t/./prev-gcc/ -B/tmp/c++/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/home/toon/compilers/obj-t/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -I/home/toon/compilers/obj-t/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/toon/compilers/obj-t/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/toon/compilers/gcc/libstdc++-v3/libsupc++ -L/home/toon/compilers/obj-t/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -c -g -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -Iobjc -I../../gcc/gcc -I../../gcc/gcc/objc -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber ../../gcc/gcc/objc/objc-next-runtime-abi-02.c -o objc/objc-next-runtime-abi-02.o ../../gcc/gcc/objc/objc-next-runtime-abi-02.c: In function 'const char* newabi_append_ro(const char*)': ../../gcc/gcc/objc/objc-next-runtime-abi-02.c:1885:29: error: invalid conversion from 'const char*' to 'char*' [-fpermissive] I have to see if it is useful to keep on testing the C++ bootstrap daily, because apparently, some bitrot already set in ... -- Toon Moene, KNMI (Weer/Onderzoek), The Netherlands Phone: +31 30 2206443; e-mail: mo...@knmi.nl
