> In fact, after looking at the latest gcc-patches messages, I think it may be
> due to this commit: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01107.html
> (based purely on the fact that the unrecognized insn is a call, and the patch
> deals with CALL_EXPR).
Duh. No, it’s not, cause it’s app
In fact, after looking at the latest gcc-patches messages, I think it may be
due to this commit: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01107.html
(based purely on the fact that the unrecognized insn is a call, and the patch
deals with CALL_EXPR).
FX
> I am testing trunk on darwin14 (M
Hi,
I am testing trunk on darwin14 (Mac OS X Yosemite), and I am seeing a lot of
(800 so far) C++ failures, in the form of internal compiler errors, like this:
> vbase1.C:17:1: error: unrecognizable insn:
> }
> ^
> (call_insn/j 4 3 5 (call (mem/u/c:DI (const:DI (unspec:DI [
>
On 13 September 2014 02:04:51 Jakub Jelinek wrote:
On Fri, Sep 12, 2014 at 04:42:25PM -0700, Mike Stump wrote:
> curious, when I run atomic.exp=stdatom\*.c:
>
> gcc.dg/atomic/atomic.exp completed in 30 seconds.
>
> atomic.exp=c\*.c takes 522 seconds with 3, 2, 5 and 4 being the worst
offende
On 12 September 2014 19:46:33 Mike Stump wrote:
On Sep 12, 2014, at 9:32 AM, Jakub Jelinek wrote:
> Here is my latest version of the patch.
>
> With this patch I get identical test_summary output on make -k check
> (completely serial testing) and make -j48 -k check from toplevel directory.
>
>
On 12.09.2014 18:10, Manuel López-Ibáñez wrote:
Hi Maxim, Many thanks for your leadership and hard work administering this.
Also thanks from my side.
I would be interested in reading about the results of the projects and
evaluations. Please student (and mentors), could you provide some
detail
