[Bug target/59405] New: Incorrect FP<->MMX transition during call/ret

[Bug target/59405] New: Incorrect FP<->MMX transition during call/ret

[kirill.yukhin at intel dot com]

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

            Bug ID: 59405
           Summary: Incorrect FP<->MMX transition during call/ret
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kirill.yukhin at intel dot com

Hello,
Attached test reproduces the error:
  $ gcc -m32 -mmmx 1.c
  $ ./a.out
  Aborted (core dumped)

Disassembly of the foo is:
foo32x2_be:
.LFB0:
        pushl   %ebp    # 22    *pushsi2        [length = 1]
        movl    %esp, %ebp      # 23    *movsi_internal/1       [length = 2]
        subl    $16, %esp       # 24    pro_epilogue_adjust_stack_si_add/1     
[length = 3]
        movq    %mm0, -8(%ebp)  # 3     *movv2sf_internal/9     [length = 4]
        movl    -4(%ebp), %eax  # 7     *movsf_internal/4       [length = 3]
        movl    %eax, -12(%ebp) # 14    *movsf_internal/5       [length = 3]
        flds    -12(%ebp)       # 21    *movsf_internal/1       [length = 3]
        leave   # 27    leave   [length = 1]
        ret     # 28    simple_return_internal  [length = 1]

We're passing v2sf vector using MMX register, which aliased to x87 stack.
Then we're trying to load FP to it, which leds to NaN.

As far as I understand, we need `emms' instruction between last MMX use and
before first x87 use.

Reproduces everywhere, up to 4.7.2 (may be earlier, I have no such).

[Bug target/59405] Incorrect FP<->MMX transition during call/ret

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
There is no testcase attached, but you need to *manually* insert _mm_empty (==
emms) to switch from MMX to x87 state.

The compiler does not automatically insert emms for you.
>From gcc-bugs-return-436817-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Dec 06 11:17:48 2013
Return-Path: <gcc-bugs-return-436817-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11086 invoked by alias); 6 Dec 2013 11:17:48 -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 10495 invoked by uid 48); 6 Dec 2013 11:17:42 -0000
From: "aivchenk at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/59226] [4.9 Regression] ICE: in record_target_from_binfo, at ipa-devirt.c:661
Date: Fri, 06 Dec 2013 11:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: aivchenk at gmail dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-59226-4-Tx0S3si2qw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59226-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59226-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: 2013-12/txt/msg00472.txt.bz2
Content-length: 466

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

Alexander Ivchenko <aivchenk at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aivchenk at gmail dot com

--- Comment #4 from Alexander Ivchenko <aivchenk at gmail dot com> ---
This broke Android image build with trunk compiler (in addition to pr58585)..

[Bug target/59405] Incorrect FP<->MMX transition during call/ret

[kirill.yukhin at intel dot com]

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

--- Comment #2 from Yukhin Kirill <kirill.yukhin at intel dot com> ---
Created attachment 31389
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31389&action=edit
Testcase

[Bug target/59405] Incorrect FP<->MMX transition during call/ret

[kirill.yukhin at intel dot com]

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

--- Comment #3 from Yukhin Kirill <kirill.yukhin at intel dot com> ---
(In reply to Uroš Bizjak from comment #1)
> There is no testcase attached, but you need to *manually* insert _mm_empty
> (== emms) to switch from MMX to x87 state.
> 
> The compiler does not automatically insert emms for you.

Well, then problem is different, test as simple as empty call.
I doubt we should emit wrong code here.
>From gcc-bugs-return-436820-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Dec 06 11:23:18 2013
Return-Path: <gcc-bugs-return-436820-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17646 invoked by alias); 6 Dec 2013 11:23:18 -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 17597 invoked by uid 48); 6 Dec 2013 11:23:14 -0000
From: "Joost.VandeVondele at mat dot ethz.ch" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/59188] [4.9 Regression] lib64/libtsan.so: undefined reference to `sigsetjmp'
Date: Fri, 06 Dec 2013 11:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: Joost.VandeVondele at mat dot ethz.ch
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-59188-4-yVB5zLkVIG@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59188-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59188-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: 2013-12/txt/msg00475.txt.bz2
Content-length: 583

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

Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed:

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

--- Comment #12 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
(In reply to Kostya Serebryany from comment #11)
> planing next merge from llvm to gcc in ~1 week.

Fixed in current trunk. Thanks!

[Bug target/59405] Incorrect FP<->MMX transition during call/ret

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Yukhin Kirill from comment #3)
> (In reply to Uroš Bizjak from comment #1)
> > There is no testcase attached, but you need to *manually* insert _mm_empty
> > (== emms) to switch from MMX to x87 state.
> > 
> > The compiler does not automatically insert emms for you.
> 
> Well, then problem is different, test as simple as empty call.
> I doubt we should emit wrong code here.

You need:

float
foo32x2_be (float32x2_t x)
{
  __builtin_ia32_emms();
  return x[1];
}

This is documented somewhere in Intel's ISA manual, so the testcase is probably
invalid.
>From gcc-bugs-return-436823-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Dec 06 11:26:04 2013
Return-Path: <gcc-bugs-return-436823-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20633 invoked by alias); 6 Dec 2013 11:26: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 20568 invoked by uid 48); 6 Dec 2013 11:26:00 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/59402] [4.9 Regression] bootstrap failure on x32
Date: Fri, 06 Dec 2013 11:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: kcc at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-59402-4-3lFMGWvSSM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59402-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59402-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: 2013-12/txt/msg00478.txt.bz2
Content-length: 821

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-12-06
     Ever confirmed|0                           |1

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Kostya Serebryany from comment #1)
> Thanks for the report, H.J. I'll try to respond properly on Monday (-ish).

Can I check my patches into trunk to unblock x32 build and revert them
after we find a better fix?

> Long term, everyone would benefit if you could setup a public build bot
> upstream.

Can you find a machine with Ubuntu 13.04 or newer?

[Bug target/59405] Incorrect FP<->MMX transition during call/ret

[kirill.yukhin at intel dot com]

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

--- Comment #5 from Yukhin Kirill <kirill.yukhin at intel dot com> ---
I see. So, it seems like a limitation to passing vectors as arguments in 32-bit
mode. We may implement something similar to `vzerroupper' autogeneration or
simply close the bug as `user misunderstanding.'

[Bug target/59405] Incorrect FP<->MMX transition during call/ret

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
I think this is a dup of PR48397.

[Bug target/59405] Incorrect FP<->MMX transition during call/ret

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to H.J. Lu from comment #6)
> I think this is a dup of PR48397.

No, this one happens due to missing interdependencies between x87 and MMX
registers. We could make all MMX instructions dependant on st(0) register, but
this would mean that no MMX instruction whatsoever will be reordered.
>From gcc-bugs-return-436834-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Dec 06 12:36:41 2013
Return-Path: <gcc-bugs-return-436834-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2787 invoked by alias); 6 Dec 2013 12:36:41 -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 2738 invoked by uid 48); 6 Dec 2013 12:36:35 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/59405] Incorrect FP<->MMX transition during call/ret
Date: Fri, 06 Dec 2013 12:36: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: 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-59405-4-nvQ28fQlKe@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59405-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59405-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: 2013-12/txt/msg00489.txt.bz2
Content-length: 551

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

--- Comment #8 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Yukhin Kirill from comment #5)
> I see. So, it seems like a limitation to passing vectors as arguments in
> 32-bit mode. We may implement something similar to `vzerroupper'
> autogeneration or simply close the bug as `user misunderstanding.'

We already tried this. Please see PR19161.

There is however, one problem - gcc warns about SSE vector argument without SSE
on 32bit targets. I will fix type_natural_mode.
>From gcc-bugs-return-436835-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Dec 06 12:39:39 2013
Return-Path: <gcc-bugs-return-436835-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5613 invoked by alias); 6 Dec 2013 12:39:39 -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 5473 invoked by uid 55); 6 Dec 2013 12:39:35 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/59288] [4.7/4.8 Regression] ICE in get_initial_def_for_induction
Date: Fri, 06 Dec 2013 12:39: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:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth 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.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59288-4-EmmFU5AuJ7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59288-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59288-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: 2013-12/txt/msg00490.txt.bz2
Content-length: 1822

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Fri Dec  6 12:39:32 2013
New Revision: 205739

URL: http://gcc.gnu.org/viewcvs?rev 5739&root=gcc&view=rev
Log:
2013-12-06  Richard Biener  <rguenther@suse.de>

    Backport from mainline
    2013-11-27  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/59288
    * tree-vect-loop.c (get_initial_def_for_induction): Do not
    re-analyze the PHI but use STMT_VINFO_LOOP_PHI_EVOLUTION_PART.

    * gcc.dg/torture/pr59288.c: New testcase.

    2013-11-19  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/59164
    * tree-vect-loop.c (vect_analyze_loop_operations): Adjust
    check whether we can create an epilogue loop to reflect the
    cases where we create one.

    * gcc.dg/torture/pr59164.c: New testcase.

    2013-09-05  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/58137
    * tree-vect-stmts.c (get_vectype_for_scalar_type_and_size):
    Do not create vectors of pointers.
    * tree-vect-loop.c (get_initial_def_for_induction): Use proper
    types for the components of the vector initializer.
    * tree-cfg.c (verify_gimple_assign_binary): Remove special-casing
    allowing pointer vectors with PLUS_EXPR/MINUS_EXPR.

    * gcc.target/i386/pr58137.c: New testcase.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr59164.c
    branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr59288.c
    branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr58137.c
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_8-branch/gcc/tree-cfg.c
    branches/gcc-4_8-branch/gcc/tree-vect-loop.c
    branches/gcc-4_8-branch/gcc/tree-vect-stmts.c

[Bug target/59405] Incorrect FP<->MMX transition during call/ret

[uros at gcc dot gnu.org]

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

--- Comment #9 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Dec  6 17:16:52 2013
New Revision: 205753

URL: http://gcc.gnu.org/viewcvs?rev=205753&root=gcc&view=rev
Log:
    PR target/59405
    * config/i386/i386.c (type_natural_mode): Properly handle
    size 8 for !TARGET_64BIT.

testsuite/ChangeLog:

    PR target/59405
    * gcc.target/i386/pr59405.c: New test.


Added:
    trunk/gcc/testsuite/gcc.target/i386/pr59405.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/testsuite/ChangeLog

[Bug target/59405] Incorrect FP<->MMX transition during call/ret

[ubizjak at gmail dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID
   Target Milestone|---                         |4.7.4

--- Comment #10 from Uroš Bizjak <ubizjak at gmail dot com> ---
The warning is fixed, the testcase without _mm_empty () is invalid.
>From gcc-bugs-return-436887-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Dec 06 17:36:18 2013
Return-Path: <gcc-bugs-return-436887-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1093 invoked by alias); 6 Dec 2013 17:36:14 -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 631 invoked by uid 48); 6 Dec 2013 17:36:09 -0000
From: "kcc at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/59410] tsan tests fail with address randomization disabled
Date: Fri, 06 Dec 2013 17:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kcc 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: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59410-4-GGrhH9kru0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59410-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59410-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: 2013-12/txt/msg00542.txt.bz2
Content-length: 2372

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

--- Comment #20 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
> >
> > # readelf -lW a.out
>
> Your address must be sensible.  Otherwise kernel will ignore it.
> Please try "-Ttext-segment 0x855555000000".

How is 0x855555000000 censible if it's beyond the address space?
(Or I miss something?)

Anyway, here is an experiment that proves that on my box
-Ttext-segment is ignored if ASLR is off.

% cat print_main.cc
#include <stdio.h>
int main() {
  printf("main: %p\n", &main);
}
% g++ print_main.cc -fPIE -pie  -Wl,-Ttext-segment=0x6ABC55000000 &&  ./a.out
main: 0x6abc5500072c
% g++ print_main.cc -fPIE -pie  -Wl,-Ttext-segment=0x6ABC55000000 &&  setarch
x86_64 -R ./a.out
main: 0x55555555472c
% readelf -lW ./a.out

Elf file type is DYN (Shared object file)
Entry point 0x6abc55000630
There are 9 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz
  Flg Align
  PHDR           0x000040 0x00006abc55000040 0x00006abc55000040 0x0001f8
0x0001f8 R E 0x8
  INTERP         0x000238 0x00006abc55000238 0x00006abc55000238 0x00001c
0x00001c R   0x1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x000000 0x00006abc55000000 0x00006abc55000000 0x00091c
0x00091c R E 0x200000
  LOAD           0x000e00 0x00006abc55200e00 0x00006abc55200e00 0x000228
0x000238 RW  0x200000
  DYNAMIC        0x000e28 0x00006abc55200e28 0x00006abc55200e28 0x000190
0x000190 RW  0x8
  NOTE           0x000254 0x00006abc55000254 0x00006abc55000254 0x000044
0x000044 R   0x4
  GNU_EH_FRAME   0x000848 0x00006abc55000848 0x00006abc55000848 0x00002c
0x00002c R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000
0x000000 RW  0x8
  GNU_RELRO      0x000e00 0x00006abc55200e00 0x00006abc55200e00 0x000200
0x000200 R   0x1

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr
.gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata
.eh_frame_hdr .eh_frame
   03     .ctors .dtors .jcr .dynamic .got .got.plt .data .bss
   04     .dynamic
   05     .note.ABI-tag .note.gnu.build-id
   06     .eh_frame_hdr
   07
   08     .ctors .dtors .jcr .dynamic .got

[Bug target/59405] Incorrect FP<->MMX transition during call/ret

[uros at gcc dot gnu.org]

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

--- Comment #11 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Dec  8 14:20:42 2013
New Revision: 205790

URL: http://gcc.gnu.org/viewcvs?rev=205790&root=gcc&view=rev
Log:
    Backport from mainline
    2013-12-06  Uros Bizjak  <ubizjak@gmail.com>

    PR target/59405
    * config/i386/i386.c (type_natural_mode): Properly handle
    size 8 for !TARGET_64BIT.

testsuite/ChangeLog

    Backport from mainline
    2013-12-06  Uros Bizjak  <ubizjak@gmail.com>

    PR target/59405
    * gcc.target/i386/pr59405.c: New test.


Added:
    branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr59405.c
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/config/i386/i386.c
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug target/59405] Incorrect FP<->MMX transition during call/ret

[ubizjak at gmail dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.4                       |4.8.3

--- Comment #12 from Uroš Bizjak <ubizjak at gmail dot com> ---
The warning was a regression from 4.7, now fixed on 4.8+.
>From gcc-bugs-return-436989-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Dec 08 15:34:14 2013
Return-Path: <gcc-bugs-return-436989-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21062 invoked by alias); 8 Dec 2013 15:34:13 -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 20978 invoked by uid 48); 8 Dec 2013 15:34:08 -0000
From: "jamborm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/58253] IPA-SRA creates calls with different arguments that the callee accepts
Date: Sun, 08 Dec 2013 15:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jamborm at gcc dot gnu.org
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: bug_status resolution
Message-ID: <bug-58253-4-DwXdRFU9PT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58253-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58253-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: 2013-12/txt/msg00644.txt.bz2
Content-length: 1125

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

Martin Jambor <jamborm at gcc dot gnu.org> changed:

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

--- Comment #10 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Jorn Wolfgang Rennecke from comment #8)
> The idea of a function is that there can be multiple callers, using
> different actual arguments, thus you shoud pick one formal argument type
> for each argument, and stick with it for all callers and the callee.
> The formal argument type determines how the argument is passed.

Well, currently that is not the case (and that has nothing to do with
IPA-SRA or any other optimization).  If you think that is a mistake,
feel free to submit a patch fixing the type parameter of the call to
targetm.calls.function_arg in initialize_argument_information (and
possibly elsewhere) in calls.c.

Meanwhile, the reported issue should now be considered fixed.