[Bug c++/60969] New: ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[Bug c++/60969] New: ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[mliska at suse dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

            Bug ID: 60969
           Summary: ICE in output_129 in MMXMOV of mode MODE_SF for
                    march=pentium4
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mliska at suse dot cz

g++ -O2 pentium.cpp -c -ftree-vectorize -march=pentium4 -m32

BT:
#0  output_129 (operands=0x1413ac0 <recog_data>, insn=0x7ffff6e0d948) at
../../gcc/config/i386/i386.md:3177
#1  0x00000000007805e2 in final_scan_insn (insn=insn@entry=0x7ffff6e0d948,
file=file@entry=0x14c7370, optimize_p=optimize_p@entry=2,
nopeepholes=nopeepholes@entry=0, seen=seen@entry=0x7fffffffd55c) at
../../gcc/final.c:2918
#2  0x0000000000780ec7 in final (first=0x7ffff6dbc5c0, file=0x14c7370,
optimize_p=2) at ../../gcc/final.c:2023
#3  0x00000000007810f6 in rest_of_handle_final () at ../../gcc/final.c:4427
#4  (anonymous namespace)::pass_final::execute (this=<optimized out>) at
../../gcc/final.c:4502
#5  0x00000000008b3dba in execute_one_pass (pass=pass@entry=0x14a26c0) at
../../gcc/passes.c:2229
#6  0x00000000008b4006 in execute_pass_list (pass=0x14a26c0) at
../../gcc/passes.c:2282
#7  0x00000000008b4018 in execute_pass_list (pass=0x14a1940) at
../../gcc/passes.c:2283
#8  0x00000000008b4018 in execute_pass_list (pass=0x14a0800) at
../../gcc/passes.c:2283
#9  0x00000000006dccf6 in expand_function (node=node@entry=0x7ffff6dada40) at
../../gcc/cgraphunit.c:1774
#10 0x00000000006de5ed in expand_all_functions () at
../../gcc/cgraphunit.c:1908
#11 compile () at ../../gcc/cgraphunit.c:2252
#12 0x00000000006dea45 in finalize_compilation_unit () at
../../gcc/cgraphunit.c:2329
#13 0x00000000005940ec in cp_write_global_declarations () at
../../gcc/cp/decl2.c:4611
#14 0x000000000094dd9d in compile_file () at ../../gcc/toplev.c:562
#15 0x000000000094f970 in do_compile () at ../../gcc/toplev.c:1914
#16 toplev_main (argc=19, argv=0x7fffffffd8c8) at ../../gcc/toplev.c:1990
#17 0x00007ffff6e4ebe5 in __libc_start_main () from /lib64/libc.so.6
#18 0x000000000052c9a1 in _start () at ../sysdeps/x86_64/start.S:122

$ cat pentium4.cpp:

struct A
{
    float f0, f1, f2, f3;
    A() { }
    A(float v0, float v1, float v2)
        : f0(v0), f1(v1), f2(v2), f3(0.0f)
    {
    }
    A method(A & a, float t)
    {
        return A (f0 + a.f0 * t, f1 + a.f1 * t, f2 + a.f2 * t);
    }
};

A function(A & v1, A & v2, float t)
{
    return v1.method (v2, t);
}

void Foo(A & a1, A & a2, A & a3, A & a4, int i1, int i2)
{
    int MIN_TRIGGER = 7; // set below 7 and it compiles ok
    A * x = new A[i1 * i2];
    for (int i = 0; i < MIN_TRIGGER; i++) {
         A a1 = function (a1, a3, i / (float)i2);
         A a2 = function (a2, a4, i / (float)i2);
        for (int j = 0; j < MIN_TRIGGER; j++)
            x[i * i1 + j] = function (a1, a2, j / (float)i1);
    }
}

[Bug c++/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-04-25
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |rth at gcc dot gnu.org
   Target Milestone|---                         |4.9.1
            Summary|ICE in output_129 in MMXMOV |[4.9/4.10 Regression] ICE
                   |of mode MODE_SF for         |in output_129 in MMXMOV of
                   |march=pentium4              |mode MODE_SF for
                   |                            |march=pentium4
     Ever confirmed|0                           |1

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
struct A
{
  float f, g, h, k;
  A () {}
  A (float v0, float x, float y) : f(v0), g(x), h(y), k(0.0f) {}
  A bar (A &a, float t) { return A (f + a.f * t, g + a.g * t, h + a.h * t); }
};

A
baz (A &x, A &y, float t)
{
  return x.bar (y, t);
}

void
foo (A &s, A &t, A &u, A &v, int y, int z)
{
  A *x = new A[y * z];
  for (int i = 0; i < 7; i++)
    {
      A s = baz (s, u, i / (float) z);
      A t = baz (t, v, i / (float) z);
      for (int j = 0; j < 7; j++)
    x[i * y + j] = baz (s, t, j / (float) y);
    }
}

Started with r208587.

[Bug c++/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
-mfpmath=387 is also needed to reproduce ICE. This patch:

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 11770fe..6ec9734 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -3201,7 +3201,7 @@
        (const_string "1")
        (const_string "*")))
    (set (attr "mode")
-        (cond [(eq_attr "alternative" "3,4,9,10,13,14,15")
+        (cond [(eq_attr "alternative" "3,4,9,10,12,13,14,15")
          (const_string "SI")
            (eq_attr "alternative" "11")
          (const_string "DI")

fixes ICE.  But I don't think the generated code is correct since LRA uses
MMX registers and x87 registers, treating them as independent.

[Bug target/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |target

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
How did mmx usage get into the code when user did not use mmx. Mmx should not
be used by the autovectorizer at all.

[Bug target/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
BTW, it actually doesn't reproduce on the trunk starting with r209313, but
guess that just made the bug latent, supposedly because nothing actually uses
the x array, guess the testcase should be improved to pass it to some external
function.

struct A
{
  float f, g, h, k;
  A () {}
  A (float v0, float x, float y) : f(v0), g(x), h(y), k(0.0f) {}
  A bar (A &a, float t) { return A (f + a.f * t, g + a.g * t, h + a.h * t); }
};

A
baz (A &x, A &y, float t)
{
  return x.bar (y, t);
}

A *
foo (A &s, A &t, A &u, A &v, int y, int z)
{
  A *x = new A[y * z];
  for (int i = 0; i < 7; i++)
    {
      A s = baz (s, u, i / (float) z);
      A t = baz (t, v, i / (float) z);
      for (int j = 0; j < 7; j++)
        x[i * y + j] = baz (s, t, j / (float) y);
    }
  return x;
}

ICEs even with latest trunk.

[Bug target/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Andrew Pinski from comment #3)
> How did mmx usage get into the code when user did not use mmx. Mmx should
> not be used by the autovectorizer at all.

For

(insn 26 25 27 4 (set (reg:SF 147 [ D.2421 ])
        (float:SF (reg/v:SI 154 [ z ]))) 203 {*floatsisf2_i387}
     (expr_list:REG_DEAD (reg/v:SI 154 [ z ])
        (nil)))
(insn 27 26 28 4 (set (reg:SF 148 [ D.2421 ])
        (float:SF (reg/v:SI 153 [ y ]))) 203 {*floatsisf2_i387}
     (nil))

LRA generates

(insn 26 24 166 4 (set (reg:SF 9 st(1) [orig:147 D.2421 ] [147])
        (float:SF (mem/c:SI (plus:SI (reg/f:SI 7 sp)
                    (const_int 100 [0x64])) [5 z+0 S4 A32]))) 203
{*floatsisf2_i387}
     (nil))
(insn 166 26 167 4 (set (mem/c:SF (plus:SI (reg/f:SI 7 sp)
                (const_int 20 [0x14])) [6 %sfp+-28 S4 A32])
        (reg:SF 9 st(1) [orig:147 D.2421 ] [147])) 129 {*movsf_internal}
     (nil))
(insn 167 166 169 4 (set (reg:SF 29 mm0 [orig:147 D.2421 ] [147])
        (mem/c:SF (plus:SI (reg/f:SI 7 sp)
                (const_int 20 [0x14])) [6 %sfp+-28 S4 A32])) 129
{*movsf_internal}
     (nil))
(insn 169 167 27 4 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
                (const_int 20 [0x14])) [6 %sfp+-28 S4 A32])
        (reg/v:SI 6 bp [orig:153 y ] [153])) 90 {*movsi_internal}
     (nil))
(insn 27 169 168 4 (set (reg:SF 10 st(2) [orig:148 D.2421 ] [148])
        (float:SF (mem/c:SI (plus:SI (reg/f:SI 7 sp)
                    (const_int 20 [0x14])) [6 %sfp+-28 S4 A32]))) 203
{*floatsisf2_i387}
     (nil))

to load a SFmode value into mm0 for later use.

[Bug target/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
Since SSE2 vectorizer is enabled and SSE math is disabled, LRA can't use
SSE registers in *movsf_internal.

[Bug target/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> ---
It is a bad idea to enable SSE vectorizer without enabling SSE
math.

[Bug target/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

--- Comment #8 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to H.J. Lu from comment #2)
> -mfpmath=387 is also needed to reproduce ICE. This patch:
> 
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index 11770fe..6ec9734 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -3201,7 +3201,7 @@
>         (const_string "1")
>         (const_string "*")))
>     (set (attr "mode")
> -        (cond [(eq_attr "alternative" "3,4,9,10,13,14,15")
> +        (cond [(eq_attr "alternative" "3,4,9,10,12,13,14,15")
>  		 (const_string "SI")
>  	       (eq_attr "alternative" "11")
>  		 (const_string "DI")
> 
> fixes ICE.  But I don't think the generated code is correct since LRA uses
> MMX registers and x87 registers, treating them as independent.

Ops, this patch is OK and preapproved.
>From gcc-bugs-return-449927-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Apr 25 18:13:53 2014
Return-Path: <gcc-bugs-return-449927-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26112 invoked by alias); 25 Apr 2014 18:13:52 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 26053 invoked by uid 48); 25 Apr 2014 18:13:48 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4
Date: Fri, 25 Apr 2014 18:13:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.1
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60969-4-ml75x0Bn7v@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60969-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60969-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg01947.txt.bz2
Content-length: 291

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`969

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #7)
> It is a bad idea to enable SSE vectorizer without enabling SSE
> math.

I think you are incorrect here with respect to performance.

[Bug target/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

--- Comment #10 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to H.J. Lu from comment #5)

> to load a SFmode value into mm0 for later use.

MMX register should never be allocated for moves, unless absolutely necessary
to satisfy insn constraints. This was fine-tuned for reload by using "*" and
"!"  in MMX alternatives (please see "*movsf_internal" pattern) and for some
reason LRA works in a different way.
>From gcc-bugs-return-449929-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Apr 25 18:18:15 2014
Return-Path: <gcc-bugs-return-449929-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30655 invoked by alias); 25 Apr 2014 18:18:15 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 30601 invoked by uid 48); 25 Apr 2014 18:18:12 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4
Date: Fri, 25 Apr 2014 18:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.1
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-60969-4-SvmlCLi1SM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60969-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60969-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg01949.txt.bz2
Content-length: 821

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at gcc dot gnu.org

--- Comment #11 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #10)

> > to load a SFmode value into mm0 for later use.
> 
> MMX register should never be allocated for moves, unless absolutely
> necessary to satisfy insn constraints. This was fine-tuned for reload by
> using "*" and "!"  in MMX alternatives (please see "*movsf_internal"
> pattern) and for some reason LRA works in a different way.

This part is LRA problem with register preferences.
>From gcc-bugs-return-449930-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Apr 25 18:28:05 2014
Return-Path: <gcc-bugs-return-449930-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13917 invoked by alias); 25 Apr 2014 18:28:04 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 12843 invoked by uid 48); 25 Apr 2014 18:27:59 -0000
From: "thomas.sanchz at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/60966] std::call_once sometime hangs
Date: Fri, 25 Apr 2014 18:28:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: thomas.sanchz at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60966-4-lKNUMgyEUw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60966-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60966-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg01950.txt.bz2
Content-length: 2194

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`966

--- Comment #2 from Thomas Sanchez <thomas.sanchz at gmail dot com> ---
Hi,

Thanks for your answer,
(In reply to Jonathan Wakely from comment #1)
> (It would be easier to make sense of this if the line numbers in your gdb
> and valgrind output matched the code on github.)
>
Indeed, sorry, I added some debug that I did not commit, I'll create a branch
with this version tomorrow. The important things is that it is always on
set_value() that I hang.


> Blocking in pthread_once could be a symptom of using an invalid
> pthread_once_t that has already been destroyed, and the valgrind output
> indeed shows that the set_value() call is being made on a shared state that
> has been deleted already, when the promise that owned it went out of scope.
> It looks like that shouldn't have happened though.
>

I reached the same conclusion.

> Is it possible the task is getting run twice by the thread pool, so on the
> second run the reference to the promise is dangling?
Hum, since I'm using boost::asio (boost::asio::io_service::post/dispatch), I do
hope that this is not the case, but this is something I can check. I don't
remember however having a double log.

>
> When the process hangs could you use gdb to print &promise in both threads,
> where it is waiting on future::get and promise::set_value? The values should
> be the same, since the closure running in the thread pool should have a
> reference to the local object in the waiting thread.

Will do.

>
> Replacing the lambda in the destructor with a call to a member function
> would help to rule out a code generation problem due to the lambda, which is
> a remote possibility.
>

Will do.

> Can the problem be reproduced by one of the unit tests in the httpp repo?
>

Unfortunately I don't have anything to reproduce the bug each time.
I'll try something tomorrow.

>
> N.B. the std::move in Manager::cancelConnection is redundant, the return
> value from cancel_connection is already an rvalue.

Yes, I know, the problem is I have some hard time to avoid doing this as it is
more for me and what I expect the compiler to do or the semantics I want the
code to have :)

[Bug target/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[hjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

--- Comment #12 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> ---
Author: hjl
Date: Fri Apr 25 20:52:01 2014
New Revision: 209811

URL: http://gcc.gnu.org/viewcvs?rev=209811&root=gcc&view=rev
Log:
Set MODE to SI for alternative 12 in *movsf_internal

    PR target/60969
    * config/i386/i386.md (*movsf_internal): Set MODE to SI for
    alternative 12.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.md

[Bug target/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> ---
The matching pattern for:

(insn 26 25 27 4 (set (reg:SF 147 [ D.2421 ])
        (float:SF (reg/v:SI 154 [ z ]))) 203 {*floatsisf2_i387}
     (expr_list:REG_DEAD (reg/v:SI 154 [ z ])
        (nil)))

was removed by r208587. Without SSE math, MMX is used in *movsf_internal.

[Bug target/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

--- Comment #14 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to hjl@gcc.gnu.org from comment #12)
> Author: hjl
> Date: Fri Apr 25 20:52:01 2014
> New Revision: 209811

HJ, can you please backport this patch to 4.9?
>From gcc-bugs-return-450655-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 06 09:45:34 2014
Return-Path: <gcc-bugs-return-450655-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24139 invoked by alias); 6 May 2014 09:45:34 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 24118 invoked by uid 48); 6 May 2014 09:45:30 -0000
From: "denes.matetelki at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61075] New: parallel std::accumulate reduct type cannot be different than the iterated type
Date: Tue, 06 May 2014 09:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: denes.matetelki at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-61075-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg00347.txt.bz2
Content-length: 457

http://gcc.gnu.org/bugzilla/show_bug.cgi?ida075

            Bug ID: 61075
           Summary: parallel std::accumulate reduct type cannot be
                    different than the iterated type
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: denes.matetelki at gmail dot com

[Bug target/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com

--- Comment #15 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Uroš Bizjak from comment #14)
> (In reply to hjl@gcc.gnu.org from comment #12)
> > Author: hjl
> > Date: Fri Apr 25 20:52:01 2014
> > New Revision: 209811
> 
> HJ, can you please backport this patch to 4.9?

The backport will lead to wrong code on 4.9 branch.  We should
fix the mixing MMX/X87 instruction and backport the fix together.
>From gcc-bugs-return-450694-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 06 15:41:25 2014
Return-Path: <gcc-bugs-return-450694-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13175 invoked by alias); 6 May 2014 15:41:23 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 13125 invoked by uid 48); 6 May 2014 15:41:17 -0000
From: "tristanmoody at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/61069] Gfortran allows functions to be called as subroutines when defined in a separate source file
Date: Tue, 06 May 2014 15:41:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tristanmoody at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61069-4-QxOAZGUijt@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61069-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61069-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg00386.txt.bz2
Content-length: 3419

http://gcc.gnu.org/bugzilla/show_bug.cgi?ida069

--- Comment #4 from Tristan Moody <tristanmoody at gmail dot com> ---
I am fine with closing this, but I disagree with the "invalid" resolution.
While I appreciate the help offered from the previous comments, I believe they
miss the mark somewhat in terms of the issue I am raising.

Below are a few points and clarifications:

1.  Because the issue stems from a combination of the fundamental compile/link
structure (more or less every compiler, not just gcc) and a quirk/loophole in
the Fortran language standard, it would be perfectly fine to close it
"wontfix."  My interpretation of clause 1.5 of the Fortran 2008 standard would
say that it is not necessary to change the current behavior (as I said before,
Portland and Intel compilers do not catch the invalid code at all).

2.  Because this is an instance of the compiler allowing invalid code to be
executed, I believe it is worth at least a note in the gfortran documentation.

3.  The real source of this happening is that the Fortran language allows
implicit interfaces, as well as the use of names assumed to be in global scope
without explicitly declaring them, unlike, say, C or C++.  This then kicks the
issue of name resolution from the compiler to the linker.  This also causes the
compiler to be unable to detect when a subroutine is being called with the
wrong number or type of arguments, as it couldn't easily be detected until link
time if the subroutine and calling procedure are in separate files. (Again,
gfortran stands above others on this point, as it will at least catch this
problem when they are in the same file.  Portland and Intel compilers do not
catch this at all.)



(In reply to kargl from comment #3)

> This happens because gfortran can build the INTERFACEs for
> bar and baz.
>
> When you compile the main program and the 2 subprogram as separate
> files, each is valid fortran code.  The code in each file is standard
> conforming.  There is no non-standard behavior.
>

I concede this point: the standard only specifies that the compiler catch
nonconforming code within individual program units -- it does not make any
statement about how to handle when the nonconformance is specifically the
relationship between program units.  That is why I would agree with a "wontfix"
resolution.  Note 1.11 of the Fortran 2008 standard states that the compiler's
documentation should state what additional forms and relationships it allows.
I would take that to include instances such as this where nonconforming,
invalid code is accepted and executable.

>
> Now, to address your problem.  There are two mechanism you can use to
> fix the situation.  (1) Put bar() and baz() in a module and USE it; or,
> (2) Use INTERFACE statements to *explicitly* tell the compiler about
> bar and baz.
>
> Your favorite reference on modern Fortran should include a discussion
> on implicit and explicit interfaces.

I am well aware of the use of interfaces as a good practice.  It is, however,
not a requirement, and when a programmer is working to transition legacy code
from a state of, shall we say, less-good practice to a best practice,
intermediate states may exist, through the programmer's own fault, in which the
resulting code is invalid.  The fact that it compiles at all is due to a
loophole in the Fortran standard, and I believe that should be noted in the
documentation.

[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

--- Comment #17 from H.J. Lu <hjl.tools at gmail dot com> ---
As long as both MMX and X87 registers are available to register allocator,
they may be used at the same time even if MMX usage is disparaged. Can we
disable MMX registers when x87 registers used on a per-function basis?

[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

--- Comment #18 from Richard Henderson <rth at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #17)

That's probably the best solution long-term.  Sometime before
register allocation (but not too far before) inspect the insn
stream and see what's left.

If we see no mmx (explicit patterns, or asms using y constraint),
disable the mmx registers entirely.

If we see mmx, and we don't see modes that *require* 387
(i.e. SFmode present but 3dnow/sse1+ssemath enabled, or
DFmode present but sse2+ssemath enabled), then disable the 387
registers entirely.

If we've got a function that uses both mmx and 387... warn?
I can't imagine that the RA would do anything nice.

Really I'd love to be able to drop mmx support entirely.  I'd
be surprised if we couldn't emulate mmx builtins on sse2.  And
how many mmx-but-not-sse machines are really left alive?

[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

--- Comment #19 from H.J. Lu <hjl.tools at gmail dot com> ---
There is

#define VALID_MMX_REG_MODE_3DNOW(MODE) \
  ((MODE) == V2SFmode || (MODE) == SFmode)

and ix86_hard_regno_mode_ok returns TRUE for holding SFmode
in MMX registers.  It is wrong to tell RA that MMX registers
can have V2SFmode/SFmode when 3DNOW is disabled.  Even if 3DNOW
is enabled, we can't use MMX registers for floating point when
x87 registers are also used.

[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

--- Comment #20 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
The problem is ira-costs.c.  One pseudo gets equal costs for memory and all
classes.  Therefore when non-mmx hard regs are not enough, a mmx is used.

After initialization of costs of reg classes for the pseudo, the costs are
never updated as all alternatives of insns where the pseudo occurs are
rejected.

The insn and the code in ira-costs.c in consideration are

(insn 26 25 27 4 (set (reg:SF 147 [ D.2423 ])
        (float:SF (reg/v:SI 155 [ z ]))) 203 {*floatsisf2_i387}
     (expr_list:REG_DEAD (reg/v:SI 155 [ z ])
        (nil)))

(define_insn "*float<SWI48x:mode><MODEF:mode>2_i387"
  [(set (match_operand:MODEF 0 "register_operand" "=f")
        (float:MODEF (match_operand:SWI48x 1 "nonimmediate_operand" "m")))]


              if (classes[i] == NO_REGS)
                {
                  /* We must always fail if the operand is a REG, but           
                     we did not find a suitable class.                          

                     Otherwise we may perform an uninitialized read             
                     from this_op_costs after the `continue' statement          
                     below.  */
                  alt_fail = 1;

The code is originated from the old RA which is originated from reload in own
turn.  The reload was not enable to deal with only 'm' alternative (when LRA
works well with only 'm').

I am working on the patch and I hope to commit it today into the branch and
trunk.

[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

--- Comment #21 from H.J. Lu <hjl.tools at gmail dot com> ---
MMX and x87 registers are aliases of each others. They can't be used
at the same time.  Is there a way to pass this information to RA?

[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

--- Comment #22 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Author: vmakarov
Date: Fri May 16 17:21:04 2014
New Revision: 210519

URL: http://gcc.gnu.org/viewcvs?rev=210519&root=gcc&view=rev
Log:
2014-05-16  Vladimir Makarov  <vmakarov@redhat.com>

    PR rtl-optimization/60969
    * ira-costs.c (record_reg_classes): Allow only memory for pseudo.
    Calculate costs for this case.

2014-05-16  Vladimir Makarov  <vmakarov@redhat.com>

    PR rtl-optimization/60969
    * g++.dg/pr60969.C: New.



Added:
    branches/gcc-4_9-branch/gcc/testsuite/g++.dg/pr60969.C
Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/ira-costs.c
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

--- Comment #23 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Author: vmakarov
Date: Fri May 16 17:37:17 2014
New Revision: 210520

URL: http://gcc.gnu.org/viewcvs?rev=210520&root=gcc&view=rev
Log:
2014-05-16  Vladimir Makarov  <vmakarov@redhat.com>

    PR rtl-optimization/60969
    * ira-costs.c (record_reg_classes): Allow only memory for pseudo.
    Calculate costs for this case.

2014-05-16  Vladimir Makarov  <vmakarov@redhat.com>

    PR rtl-optimization/60969
    * g++.dg/pr60969.C: New.


Added:
    trunk/gcc/testsuite/g++.dg/pr60969.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ira-costs.c
    trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

--- Comment #24 from uros at gcc dot gnu.org ---
Author: uros
Date: Sat May 17 10:35:44 2014
New Revision: 210549

URL: http://gcc.gnu.org/viewcvs?rev=210549&root=gcc&view=rev
Log:
    Backport from mainline
    2014-04-25  H.J. Lu  <hongjiu.lu@intel.com>

    PR target/60969
    * config/i386/i386.md (*movsf_internal): Set MODE to SI for
    alternative 12.


Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/config/i386/i386.md

[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #25 from Uroš Bizjak <ubizjak at gmail dot com> ---
Fixed.
>From gcc-bugs-return-451809-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat May 17 11:55:36 2014
Return-Path: <gcc-bugs-return-451809-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13593 invoked by alias); 17 May 2014 11:55:36 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 13534 invoked by uid 48); 17 May 2014 11:55:31 -0000
From: "dcb314 at hotmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/61210] bootstrap failure with clang
Date: Sat, 17 May 2014 11:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dcb314 at hotmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61210-4-vY0BPZPOcX@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61210-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61210-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg01501.txt.bz2
Content-length: 381

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61210

--- Comment #2 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Manuel López-Ibáñez from comment #1)
> In which sense are they interesting?

They show bugs in gcc trunk.

Same as running cppcheck over gcc trunk shows bugs.

Both both cases, I've reported the ones that I think are worth fixing.
>From gcc-bugs-return-451810-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat May 17 12:10:47 2014
Return-Path: <gcc-bugs-return-451810-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24457 invoked by alias); 17 May 2014 12:10:46 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 24417 invoked by uid 48); 17 May 2014 12:10:42 -0000
From: "tprince at computer dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/61212] New: gcc build failure on "dos file system" due to warnings treated as errors
Date: Sat, 17 May 2014 12:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: fortran-dev
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tprince at computer dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-61212-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg01502.txt.bz2
Content-length: 1083

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61212

            Bug ID: 61212
           Summary: gcc build failure on "dos file system" due to warnings
                    treated as errors
           Product: gcc
           Version: fortran-dev
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tprince at computer dot org

gcc trunk and fortran-dev build failure
../../libcpp/files.c:393:56: error: suggest parentheses around ‘&&’ within ‘||’
[-Werror=parentheses]
       if (CPP_OPTION (pfile, canonical_system_headers) && file->dir->sysp
                                                        ^
cc1plus: all warnings being treated as errors



Adding the parens as suggested has been working:

      if ((CPP_OPTION (pfile, canonical_system_headers) && file->dir->sysp)
#ifdef HAVE_DOS_BASED_FILE_SYSTEM
          || !file->dir->sysp
#endif
         )


Apparently, this is exposed only on "dos based file system."
>From gcc-bugs-return-451811-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat May 17 12:23:54 2014
Return-Path: <gcc-bugs-return-451811-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29682 invoked by alias); 17 May 2014 12:23:53 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 29567 invoked by uid 48); 17 May 2014 12:23:47 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/61194] [4.9/4.10 Regression] vectorization failed with "bit-precision arithmetic not supported" even if conversion to int is requested
Date: Sat, 17 May 2014 12:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glisse at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.1
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61194-4-nb6Rw4JDDU@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61194-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61194-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg01503.txt.bz2
Content-length: 145

https://gcc.gnu.org/bugzilla/show_bug.cgi?ida194

--- Comment #15 from Marc Glisse <glisse at gcc dot gnu.org> ---
Seems related to PR 57328.

[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[doko at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

Matthias Klose <doko at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doko at gcc dot gnu.org

--- Comment #26 from Matthias Klose <doko at gcc dot gnu.org> ---
this fix causes PR61231 (bootstrap failure on powerpc64le-linux-gnu).

[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

--- Comment #28 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Author: vmakarov
Date: Thu May 22 21:10:26 2014
New Revision: 210825

URL: http://gcc.gnu.org/viewcvs?rev=210825&root=gcc&view=rev
Log:
2014-05-22  Vladimir Makarov  <vmakarov@redhat.com>

    PR rtl-optimization/60969
    * ira-costs.c (record_reg_classes): Process NO_REGS for matching
    constraints.  Set up mem cost for NO_REGS case.


Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/ira-costs.c

[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[christophe.lyon at st dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

christophe.lyon at st dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |christophe.lyon at st dot com

--- Comment #29 from christophe.lyon at st dot com ---
This fix caused PR61325.

[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[sje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

Steve Ellcey <sje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sje at gcc dot gnu.org

--- Comment #30 from Steve Ellcey <sje at gcc dot gnu.org> ---
This patch caused PR 61357, a MIPS optimization regression.

[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[macro@linux-mips.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

Maciej W. Rozycki <macro@linux-mips.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |macro@linux-mips.org

--- Comment #31 from Maciej W. Rozycki <macro@linux-mips.org> ---
PR 61397 is another fallout, on Power.