On 03/08/2013 10:26 PM, Jonathan Wakely wrote:
On 8 March 2013 20:16, François Dumont wrote:
This is indeed better so I applied the patch as you proposed.
Thanks, can you also make the same changes to the 4.7 branch? If not I
can do so.
Attached patch tested under Linux x86_64 and applied to
Hi,
just avoid spurious fails with -Wunused (or -Wall
-Wno-unused-local-typdefs, which is what I often actually try).
Thanks,
Paolo.
2013-03-09 Paolo Carlini
* testsuite/20_util/function_objects/mem_fn/55463.cc: Avoid
-Wunused warnings.
Index: testsuit
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the German team of translators. The file is available at:
http://translationproject.org/latest/cpplib/de.po
(This file, 'cpplib-4.8-b20130224.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the German team of translators. The file is available at:
http://translationproject.org/latest/cpplib/de.po
(This file, 'cpplib-4.8-b20130224.
On Fri, Mar 8, 2013 at 10:24 PM, Vladimir Makarov wrote:
> LRA branch has been merged with trunk @ 196555.
>
> The branch was successfully bootstrapped on x86/x86-64.
Also on powerpc64-unknown-linux-gnu, and ia64-unknown-linux-gnu, as
well as cross to mipsisa64-elf.
There is one powerpc64 failur
Hello,
Debugging a DSE bug, I found the dumps to be almost unusable because
they are so verbose. For my test case, the -fdump-rtl-dse1 dump is a
~17GB file without the attached patch (the test case has ~5
insns). With the patch, all this extra information is only dumped with
-fdump-rtl-dse1-de
Hello,
The attached patch fixes one of the (at least) three scalability
problems reported in PR middle-end/39326. This problem is that combine
takes forever and increases the memory footprint from ~650MB to >7GB.
The cause is DSE creating a lot of new registers in replace_read, and
those registers
Hello,
The attached patch fixes another one of the scalability problems
reported in PR middle-end/39326.
This problem is that tree loop-invariant code motion explodes on basic
blocks with many memory references. Compile time is quadratic in the
number of memory references in the basic block, and
Hi,
in cxx_eval_array_reference we don't check whether the subscript is
negative and we end up either ICEing or emitting wrong code. Adding the
check seems trivial, but I'm not sure if there is something more subtle
to the issue which I'm missing.
Also note that in principle we could have so
