On Sat, 1 Mar 2014, Paolo Carlini wrote:

Hi

On 28/feb/2014, at 23:48, Marc Glisse <marc.gli...@inria.fr> wrote:

Hello,

this is a stage 1 patch, and I'll ping it then, but if you have comments now...

Passes bootstrap+testsuite on x86_64-linux-gnu.

2014-02-28  Marc Glisse  <marc.gli...@inria.fr>

   PR tree-optimization/57742
gcc/
   * tree-ssa-forwprop.c (simplify_malloc_memset): New function.
   (simplify_builtin_call): Call it.
gcc/testsuite/
   * g++.dg/tree-ssa/calloc.C: New testcase.
   * gcc.dg/tree-ssa/calloc.c: Likewise.

--
Marc Glisse
Index: gcc/testsuite/g++.dg/tree-ssa/calloc.C
===================================================================
--- gcc/testsuite/g++.dg/tree-ssa/calloc.C    (revision 0)
+++ gcc/testsuite/g++.dg/tree-ssa/calloc.C    (working copy)
@@ -0,0 +1,35 @@
+/* { dg-do compile } */
+/* { dg-options "-std=gnu++11 -O3 -fdump-tree-optimized" } */
+
+#include <new>
+#include <vector>
+#include <cstdlib>
+
+void g(void*);
+inline void* operator new(std::size_t sz) _GLIBCXX_THROW (std::bad_alloc)

Unless *really* necessary I would recommend not including the large <vector> (that also couples quite seriously the front-end testsuite to the library testsuite, we already discussed those topics in the past). Using the internal macros seems also unnecessary.

I think it might be the first time I include large headers in a compiler testcase (note that there are already 16 other testcases including <vector> in g++.dg). In this case, it seems to be what I want to test though. I already have some elementary tests in gcc.dg. This testcase is the original motivation for working on this. It requires a combination of quite a few optimizations (inlining, recognizing that a loop is a memset, aliasing, this optimization (the complicated version with a PHI node)), and I want to test that we won't for instance shuffle the passes in a way that breaks it. Also, if the library changes vector enough that this doesn't optimize anymore, I want to know about it, either the library change was wrong or the middle-end needs to improve some optimization before the next release.


I wanted to keep the implementation of new as close to the one in libsupc++ as possible (mimic LTO), so I copy-pasted (and slightly edited, I may propose a patch to libsupc++ later). I agree that I should remove the exception specification (since I am compiling in C++11 to have access to get_new_handler) and replace _GLIBCXX_THROW_OR_ABORT with just throw, and I just did it locally, thanks.

--
Marc Glisse

Reply via email to