From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87720 invoked by alias); 2 Sep 2015 00:30:11 -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 87657 invoked by uid 48); 2 Sep 2015 00:30:07 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/67429] [5/6 Regression] Missing part of error messages. Date: Wed, 02 Sep 2015 00:30: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: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: manu 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: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-09/txt/msg00107.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D67429 --- Comment #9 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- Even with the original patch applied to r227391, I cannot reproduce the err= or that you get. On x86_64-linux-gnu, I get: Starting program: /home/manuel/test1/226953M/build/gcc/f951 ~/test1/src/gcc/testsuite/gfortran.dg/pr65045.f90 /home/manuel/test1/src/gcc/testsuite/gfortran.dg/pr65045.f90:7:6: Error: Sy= mbol =E2=80=98i=E2=80=99 at (1) is not appropriate for an expression /home/manuel/test1/src/gcc/testsuite/gfortran.dg/pr65045.f90:9:59: else ! { dg-error "Unexpected ELSE statement" } 1 Error: Unexpected ELSE statement at (1) /home/manuel/test1/src/gcc/testsuite/gfortran.dg/pr65045.f90:10:6: Error: = =E2=80=98i=E2=80=99 at (1) is not a variable /home/manuel/test1/src/gcc/testsuite/gfortran.dg/pr65045.f90:11:6: end if ! { dg-error "Expecting END BLOCK statement" } 1 Error: Expecting END BLOCK statement at (1) /home/manuel/test1/src/gcc/testsuite/gfortran.dg/pr65045.f90:13:8: print*,i ! { dg-error "not appropriate for an expression" } 1 Error: Symbol =E2=80=98i=E2=80=99 at (1) is not appropriate for an expressi= on However, there is a bug indeed. The first caret line is not printed because there was a previous buffered error at the same location that later got cleared. However, clearing it does not reset context->last_location, which = is checked in gfc_diagnostic_starter. This patch seems to fix it: Index: error.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- error.c (revision 227391) +++ error.c (working copy) @@ -755,10 +755,13 @@ gfc_clear_pp_buffer (output_buffer *this pretty_printer *pp =3D global_dc->printer; output_buffer *tmp_buffer =3D pp->buffer; pp->buffer =3D this_buffer; pp_clear_output_area (pp); pp->buffer =3D tmp_buffer; + /* We need to reset last_location, otherwise we may skip caret lines + when we actually give a diagnostic. */ + global_dc->last_location =3D UNKNOWN_LOCATION; } However, it is not a very nice solution. It may happen that we give an erro= r at location X, then we buffer some errors, then we clear them, so we reset last location to UNKNOWN, then we give an error at location X and we will get a duplicated caret line. Thus, it would be better if last_location was only updated when we actually flush the output text. However, that would require some deeper changes, probably in diagnostic.c and in fortran/error.c to han= dle both buffered and not buffered output_buffers. On the other hand, I'm not s= ure the previous Fortran diagnostic machinery cared about duplicated caret line= s, thus perhaps the above is enough. BTW, you should use %qs instead of '%s' in order to get quoting localized to the user's language and color highlighting. >>From gcc-bugs-return-496130-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Sep 02 00:41:43 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 99798 invoked by alias); 2 Sep 2015 00:41:43 -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 99707 invoked by uid 48); 2 Sep 2015 00:41:39 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/67174] [6 regression] gfortran.dg/do_iterator.f90 FAILs Date: Wed, 02 Sep 2015 00: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: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: manu at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 6.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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/msg00108.txt.bz2 Content-length: 1472 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D67174 Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |manu at gcc dot gnu.org --- Comment #5 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (In reply to paul.richard.thomas@gmail.com from comment #4) > reworked to use the gcc error reporting mechanisms. There is now a > flag, which determines whether or not the line where the error occurs > is displayed or not. I suspect that something is causing this flag to https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.ht= ml#Diagnostic-Message-Formatting-Options The flag is -fdiagnostics-show-caret. The testsuite uses -fno-diagnostics-show-caret, since we actually cannot test the caret line (= the source line with the '(1)' or '(2)' or '^' symbol below) and the info given= by -fno-diagnostics-show-caret is enough to test precise locations. The Fortra= n FE testsuite uses several complicated regex to remove all possible forms of the caret line and keep only the location information and the diagnostic text, = but I think this should not be necessary anymore since everything was converted= to the common machinery and the output with -fno-diagnostics-show-caret is alr= eady in the desired form for the testsuite. >>From gcc-bugs-return-496131-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Sep 02 00:57:08 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 105997 invoked by alias); 2 Sep 2015 00:57:07 -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 105936 invoked by uid 48); 2 Sep 2015 00:57:04 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/67429] [5/6 Regression] Missing part of error messages. Date: Wed, 02 Sep 2015 00:57: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: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: manu 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: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-09/txt/msg00109.txt.bz2 Content-length: 1176 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D67429 --- Comment #10 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (In reply to Paul Thomas from comment #7) > The patch for PR65045 is the simplest manifestation that I have found. I = am > very grateful to Dominique for posting this PR because the problem has be= en > driving me crazy. I assumed that it was my patches that were wrong. Howev= er, > Dominique proved by going through different revisions that the December 2= 014 > patches to error.c are the culprits. (In reply to Dominique d'Humieres from comment #0) > Error: Expecting END BLOCK statement at (1) > (null):0: confused by earlier errors, bailing out Even if *I* cannot reproduce this, such an error should be easy to debug: J= ust put a break in diagnostic_report_diagnostic on the line that gives this mes= sage and go up to find out what triggered this code to run. My guess is that you= are somehow triggering an ICE while reporting an ICE. It would be interesting to understand where that strange location comes from (I guess it is UNKNOWN_LOCATION?). And also to harden that code to not try to print a null s.file pointer! >>From gcc-bugs-return-496132-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Sep 02 02:46:05 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 57403 invoked by alias); 2 Sep 2015 02:46:05 -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 57366 invoked by uid 48); 2 Sep 2015 02:46:00 -0000 From: "peter at cordes dot ca" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/42497] Generate conditional tail calls . Date: Wed, 02 Sep 2015 02:46: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: 4.5.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: peter at cordes dot ca 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: cc 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/msg00110.txt.bz2 Content-length: 1325 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42497 Peter Cordes changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |peter at cordes dot ca --- Comment #3 from Peter Cordes --- This bug is still present with gcc 5.2 -O3 (which does include -foptimize-sibling-calls). void fire_special_event(void); void conditional_call(int cond) { if(cond) fire_special_event(); } The above code compiles to (x86-64 gcc 5.2 -O3) testl %edi, %edi jne .L4 rep ret .L4: jmp fire_special_event This sequence would be better: testl %edi, %edi jne fire_special_event ret godbolt link: https://goo.gl/0K6EZx Later functions in that listing are related to http://stackoverflow.com/questions/97987/advantage-of-switch-over-if-else-statement Is there a linker limitation on relocations for conditional-branch targets that aren't part of the current compilation unit? neither clang 3.7 nor icc 13 do any better than gcc. It seems to work for me when modifying the asm by hand to jnz _Z18fire_special_eventv, and linking to a separately-compiled definition.