From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125011 invoked by alias); 17 Sep 2015 13:13:08 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 124308 invoked by uid 48); 17 Sep 2015 13:13:04 -0000 From: "ubizjak at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd Date: Thu, 17 Sep 2015 13: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: 5.2.1 X-Bugzilla-Keywords: ra, wrong-code X-Bugzilla-Severity: major X-Bugzilla-Who: ubizjak at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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: 2015-09/txt/msg01384.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D67609 --- Comment #3 from Uro=C5=A1 Bizjak --- The doc says: When used as an lvalue, 'subreg' is a word-based accessor. Storing to a 'subreg' modifies all the words of REG that overlap the 'subreg', but it leaves the other words of REG alone. When storing to a normal 'subreg' that is smaller than a word, the other bits of the referenced word are usually left in an undefined state. This laxity makes it easier to generate efficient code for such instructions. To represent an instruction that preserves all the bits outside of those in the 'subreg', use 'strict_low_part' or 'zero_extract' around the 'subreg'. However, we expand assignment to v[0] with: ;; v[0] =3D b_4(D); (insn 7 6 0 (set (subreg:DF (reg/v:TI 90 [ v ]) 0) (reg/v:DF 88 [ b ])) pr67609.c:8 -1 (nil)) According to the above explanation, a strict_low_part should be used here. I think this is middle-end, not a target problem. >>From gcc-bugs-return-497407-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Sep 17 13:42:37 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 19395 invoked by alias); 17 Sep 2015 13:42:37 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 19348 invoked by uid 48); 17 Sep 2015 13:42:33 -0000 From: "ebotcazou at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/66790] Invalid uninitialized register handling in REE Date: Thu, 17 Sep 2015 13:42:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ebotcazou at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: 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: In-Reply-To: References: 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: 2015-09/txt/msg01385.txt.bz2 Content-length: 2638 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #22 from Eric Botcazou --- > A native English speaker would say that this could be written better. I > would suggest the term "on at least one path" and this is what a MAY problem > is generally defined as. Thanks. Here's a proposed amended wording: Index: df-problems.c =================================================================== --- df-problems.c (revision 227819) +++ df-problems.c (working copy) @@ -1309,22 +1309,23 @@ df_lr_verify_transfer_functions (void) /*---------------------------------------------------------------------------- - LIVE AND MUST-INITIALIZED REGISTERS. + LIVE AND MAY-INITIALIZED REGISTERS. This problem first computes the IN and OUT bitvectors for the - must-initialized registers problems, which is a forward problem. - It gives the set of registers for which we MUST have an available - definition on any path from the entry block to the entry/exit of - a basic block. Sets generate a definition, while clobbers kill + may-initialized registers problems, which is a forward problem. + It gives the set of registers for which we MAY have an available + definition, i.e. for which there is an available definition on + at least one path from the entry block to the entry/exit of a + basic block. Sets generate a definition, while clobbers kill a definition. In and out bitvectors are built for each basic block and are indexed by regnum (see df.h for details). In and out bitvectors in struct - df_live_bb_info actually refers to the must-initialized problem; + df_live_bb_info actually refers to the may-initialized problem; Then, the in and out sets for the LIVE problem itself are computed. These are the logical AND of the IN and OUT sets from the LR problem - and the must-initialized problem. + and the may-initialized problem. ----------------------------------------------------------------------------*/ /* Private data used to verify the solution for this problem. */ @@ -1531,7 +1532,7 @@ df_live_confluence_n (edge e) } -/* Transfer function for the forwards must-initialized problem. */ +/* Transfer function for the forwards may-initialized problem. */ static bool df_live_transfer_function (int bb_index) @@ -1555,7 +1556,7 @@ df_live_transfer_function (int bb_index) } -/* And the LR info with the must-initialized registers, to produce the LIVE info. */ +/* And the LR info with the may-initialized registers, to produce the LIVE info. */ static void df_live_finalize (bitmap all_blocks)