From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24918 invoked by alias); 13 Jan 2014 10:59:48 -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 24879 invoked by uid 48); 13 Jan 2014 10:59:45 -0000 From: "ubizjak at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug preprocessor/59782] libcpp does not avoid bug #48326 when compiled by older GCC Date: Mon, 13 Jan 2014 10:59:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: preprocessor X-Bugzilla-Version: 4.8.2 X-Bugzilla-Keywords: build 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: --- 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: 2014-01/txt/msg01339.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D59782 --- Comment #3 from Uro=C5=A1 Bizjak --- (In reply to Jakub Jelinek from comment #2) > I'd say for GCC 4.8 we should just replace the conditional with GCC_VERSI= ON > >=3D 4008 and for 4.9 with >=3D 4009, better trust only the latest versio= n for > target attribute. libcpp is bootstrapped and thus for bootstraps it will > DTRT. According to [1], 4.7.1 is already OK, so > 4007 should be enough. [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D48326#c3 >>From gcc-bugs-return-440198-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jan 13 11:18:17 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 1040 invoked by alias); 13 Jan 2014 11:18:16 -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 388 invoked by uid 48); 13 Jan 2014 11:18:09 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug testsuite/59494] [4.9 Regression] FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f scan-tree-dump-times optimized "vect_[^\\n]*\\+ " 13 Date: Mon, 13 Jan 2014 11:18:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: testsuite 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: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.0 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: 2014-01/txt/msg01340.txt.bz2 Content-length: 1649 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59494 --- Comment #6 from Richard Biener --- (In reply to Jakub Jelinek from comment #5) > Alternatively we should just remove that scan-tree-dump-times from the test > altogether, counting additions where either lhs or rhs1 of addition has > vect_ in name is quite flawed, we have lots of other vector additions that > just use anonymous SSA_NAMEs without any name (_114 etc.), but still have > vector types. > > Counting addps etc. insns doesn't work though, there are 23 before and after > the r156043 change. > > Richard, what is your preference here? Well, ! we want to check that predictive commoning did something on the ! vectorized loop, which means we have to have exactly 13 vector ! additions. which means to look at the pcom dump (and maybe enhance it). On x86_64 the interesting line in -details is "Unrolling 2 times." dumped from /* Execute the predictive commoning transformations, and possibly unroll the loop. */ if (unroll) { struct epcc_data dta; if (dump_file && (dump_flags & TDF_DETAILS)) fprintf (dump_file, "Unrolling %u times.\n", unroll_factor); ... } else { if (dump_file && (dump_flags & TDF_DETAILS)) fprintf (dump_file, "Executing predictive commoning without unrolling.\n"); execute_pred_commoning (loop, chains, tmp_vars); } a common "Executing predictive commoning on loop %d" would be possibly useful. Eventually with "on %d chains" as well. All of this even without -details and within the opt-dumping framework (MSG_OPTIMIZED_LOCATIONS).