new file for testsuite gcc.dj
i ran with this file under testsuite/gcc.dj and it aborted with -O2. It is for the optimization bug that i reported few days back. If we don't have this test can someone add ths. bug_powO2.c Description: Binary data
Enabling IPCP by default
Hi, Since most of issues with IPCP should be fixed now and it should be as strong as possible with the elementary textbook quality algorithm it uses, I would like to enable it by default. I've tested it on SPEC and C++ behcmarks yeterday and didn't measured any significant improvments. There is quite a lot of clonning happening now (as can be seen on size increase) on SPECint, but the benchmark performance don't care much. Today I fixed some isses and added code to avoid code size growth, so I expect IPCP to be mostly neutral. Will re-run the tests tonight. To some degree I would say it is expected as all those codebases are quite well hand optimized and this is kind of optimization one does by hand if needed. Ipcp can now run in tow modes: in pure constant propagation when clonning is not happening (well, in fact it does. We clone the function and the remove the original as in place replacement is not implement (yet)) and with clonning. With clonning overall unit growth is limited to 10% and ipcp performs very simplistic analysis of effectivity and will clone functions until the limit is met in priority order. On CC1 binarry I get following results: stripped size clonned functions no ipcp 8863256 0 ipcp only 8773432 45 ipcp&clonning 8772344 154 (with unlimited clonning we get about 180 clones) Additionally ipcp and ipcp&clonning binary seems consistently 0.7%-1.5% faster on compiling C objects. Since IPCP seems essentially free for compile time (i.e. intraprocedural analysis is performed for inlining anyway and interprocedural step is very cheap when nothing is transformed) and cause 1% code size savings on cc1 and speeds it up enough to pay back, I would like to propose: - enable IPCP for -O2 and -Os - enable IPCP clonning for -O3 Ipcp also carries basic IPA infrastructure we want to keep excercised (jump function analysis, clonning, propagation to function bodies and infrastructure to solve cgraph updates for future whopr mode). I would still like to work on better ipcp cost model (i.e. estimates on how much function will simplify with constant propagation) and also to allow producing multiple clones when function is called with multiple constant arguments. If there are no complains, I will enable ipcp as proposed after remaining patches are tested and comitted (that would be about day after tomorrow) Honza
Re: Enabling IPCP by default
Jan Hubicka <[EMAIL PROTECTED]> writes: > If there are no complains, I will enable ipcp as proposed after remaining > patches are tested and comitted (that would be about day after tomorrow) It breaks Ada on ia64: /tmp/cvs/gcc-20080824/Build/./prev-gcc/xgcc -B/tmp/cvs/gcc-20080824/Build/./prev-gcc/ -B/tmp/cvs/gcc-20080824/Build/root/ia64-suse-linux/bin/ -c -g -O2 -gnatpg -gnata -nostdinc -I- -I. -Iada -I../../gcc/ada -I../../gcc/ada/gcc-interface ../../gcc/ada/sem_ch12.adb -o ada/sem_ch12.o +===GNAT BUG DETECTED==+ | 4.4.0 20080824 (experimental) [trunk revision 139531] (ia64-suse-linux-gnu) GCC error:| | in expand_call_inline, at tree-inline.c:3106 | | Error detected around ../../gcc/ada/sem_ch12.adb:6296| #1 0x41040730 in expand_call_inline (bb=0x224519e0, stmt=0x223bc000, id=0x607ffee06378) at ../../gcc/tree-inline.c:3106 3106 gcc_assert (dest->needed); Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Enabling IPCP by default
> Jan Hubicka <[EMAIL PROTECTED]> writes: > > > If there are no complains, I will enable ipcp as proposed after remaining > > patches are tested and comitted (that would be about day after tomorrow) > > It breaks Ada on ia64: I was hitting same problem on x86_64 and it should be fixed now. Honza > > /tmp/cvs/gcc-20080824/Build/./prev-gcc/xgcc > -B/tmp/cvs/gcc-20080824/Build/./prev-gcc/ > -B/tmp/cvs/gcc-20080824/Build/root/ia64-suse-linux/bin/ -c -g -O2 -gnatpg > -gnata -nostdinc -I- -I. -Iada -I../../gcc/ada -I../../gcc/ada/gcc-interface > ../../gcc/ada/sem_ch12.adb -o ada/sem_ch12.o > +===GNAT BUG DETECTED==+ > | 4.4.0 20080824 (experimental) [trunk revision 139531] (ia64-suse-linux-gnu) > GCC error:| > | in expand_call_inline, at tree-inline.c:3106 | > | Error detected around ../../gcc/ada/sem_ch12.adb:6296| > > #1 0x41040730 in expand_call_inline (bb=0x224519e0, > stmt=0x223bc000, id=0x607ffee06378) > at ../../gcc/tree-inline.c:3106 > 3106 gcc_assert (dest->needed); > > Andreas. > > -- > Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] > SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany > PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different."
Re: c++0x 4.4, =default definition outside template class fails.
.. never mind, the problem you are seeing is at *link* time, ok... Paolo.
Re: c++0x 4.4, =default definition outside template class fails.
.. and I would suggest filing a normal Bugzilla PR, to the attention of [EMAIL PROTECTED] in CC, because it seems indeed a bug to me: we even have in the testsuite a very similar run-type test different only because the class isn't a template. Paolo.
Re: c++0x 4.4, =default definition outside template class fails.
Hi,
=== THIS CODE FAILS TO COMPILE ===
template
class foo {
public:
foo() =default; // <<--- this works fine.
~foo();
};
template
foo::~foo() =default; <<--- ERROR: This doesn't get built by the compiler.
// foo::~foo() {}; <<-- replacing with this line fixes the error.
int main() {
foo fi;
return 0;
}
===
The above compiles just fine for me. Are you using current mainline or
by chance an old snapshot?
Paolo.
\testsuite\ext\stdio_filebuf\char\10063-1.cc
Hello,
I am trying to port the testsuite to an embedded environment.
I have gotten all of the needed tests to compile, and am debugging
those test that fail at runtime now.
\ext\stdio_filebuf\char\10063-1.cc fails.
The area it fails in is in the test1() rountine at:
{
__gnu_cxx::stdio_filebuf sbuf(file, ios_base::out);
sbuf.sputc('2');
sbuf.sputc('3');
}
This code does not affect the output file (sgetn reads back "145",
not "12345"), even
though the surrounding writes to the file work.
As I step through the code, when sbuf gets instantiated, its _M_mode
variable
at the basic_filebuf level gets set to std::_S_out. (non-zero).
When I step through the sbuf.sputc(), and I get down to the
std::basic_filebuf >::overflow(int)
routine,
I see the code check the variable _M_mode in fstream.tcc at the
overflow template
at the line:
const bool __testout = _M_mode & ios_base::out;
__testout gets set to 0 because this->_M_mode at this level reads as
0 in the debugger.
When I look up the stack, sbuf->_M_mode indeed is still std::_S_out.
but in overflow(), this->_M_mode is 0.
I feel like I am missing something here that might be obvious to
someone else.
Thanks for any help/advice/pointers you can give me.
-Karl
Re: Better GCC diagnostics
2008/8/20 Arnaud Charlet <[EMAIL PROTECTED]>: >> Not just that, probably Fortran/Ada are already duplicating stuff that >> is in libcpp or they are implementing their own version of stuff that >> C/C++ are lacking (caret diagnostics? character encodings?). > > Well, clearly, the preprocessor and handling of #include is very > C/C++ specific, and not used by Ada or Fortran. Both Ada and Fortran are linked with libcpp.a. > As for diagnostics, Ada does use its own mechanism, mainly because it's > much more powerful than the one in libcpp, and handles e.g. multiple > locations related to cascaded generic package instantiations (C++ templates), > as well as many other goodies already described by Robert is previous > messages. Even if you do not use line-map.o, the middle-end does, so you still have the duplication. > It has also handled column info from day one (and we would not want any > of the e.g. -fshow-column stuff: why would you *not* want to display > column information ? :-) Yes, why? > So from GNAT's point of view, what's the point in duplicating all this > work done and written in Ada in another less capable language (which would > also > make it more painful for GNAT developers to use), in particular if this > capability is only available in very recent GCC versions. The point is that other front-ends would be able to use it. And non-Ada developers would be able to fix it and extend it. Moreover, even if GNAT won't use it, moving all this out of libcpp and making it modular would allow to link only to the things that you really need. Finally, the middle-end is using it anyway, so gnat is using it. Cheers, Manuel.
