From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17737 invoked by alias); 14 Jul 2014 18:30:50 -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 17532 invoked by uid 48); 14 Jul 2014 18:30:45 -0000 From: "dominiq at lps dot ens.fr" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/61632] Memory corruption on error when writing formatted data Date: Mon, 14 Jul 2014 18: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: 4.8.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dominiq at lps dot ens.fr X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jvdelisle 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-07/txt/msg00908.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D61632 --- Comment #11 from Dominique d'Humieres --- > Its not really a glitch. In this case reversion has occurred so i can on= ly > approximate where in the string the error occured. I can improve on it w= ith: > > offset =3D fmt->reversion_ok ? fmt->format_string_len + 2: > dtp->format_len - fmt->format_string_len; > > I don't think I can do better for now. Of course we want diagnostics to = be > helpful, but they can not be perfect. I would suggest we commit the patc= h for now. What about the following? if (f !=3D NULL) - fmt->format_string =3D f->source; + fmt->format_string_len =3D strrchr (f->source, ')') - &f->source[0] + = 1; It is clumsy, but it does the trick. If accepted, I can write a test case f= or it. >>From gcc-bugs-return-456318-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 14 18:37:57 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 333 invoked by alias); 14 Jul 2014 18:37:56 -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 32462 invoked by uid 48); 14 Jul 2014 18:37:43 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/61803] error reports macro location first, but should not Date: Mon, 14 Jul 2014 18:37:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: manu 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: bug_status cf_reconfirmed_on cc component everconfirmed 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-07/txt/msg00909.txt.bz2 Content-length: 1832 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D61803 Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2014-07-14 CC| |manu at gcc dot gnu.org Component|c |c++ Ever confirmed|0 |1 --- Comment #1 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (In reply to Tom Tromey from comment #0) > This is not really a C-specific bug but I wasn't sure > where else to file it. I would suggest file it against C++, just because there are more regular contributors to C++ (Jason and Paolo) than to C (only Joseph and not nearly= as regular). In C++, we get: test.c:1:23: error: cannot convert =E2=80=98int*=E2=80=99 to =E2=80=98doubl= e*=E2=80=99 in return #define Nil ((int *) 0) ^ test.c:5:10: note: in expansion of macro =E2=80=98Nil=E2=80=99 return Nil; ^ It is strange that it points to the closing parenthesis. > I think instead it would be better to emit the warning at the "final" > location and then print the macro definition information as notes. In this case yes, but this is not always the case: See PR5252. Perhaps this should be configurable per diagnostic, with the most common case being the default. The default of Clang is the opposite of GCC, for this very reason: test.c:5:10: error: cannot initialize return object of type 'double *' with= an rvalue of type 'int *' return Nil; ^~~ test.c:1:13: note: expanded from macro 'Nil' #define Nil ((int *) 0) ^~~~~~~~~~~ >>From gcc-bugs-return-456319-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 14 18:57:52 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 7681 invoked by alias); 14 Jul 2014 18:57:50 -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 7402 invoked by uid 48); 14 Jul 2014 18:57:39 -0000 From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking Date: Mon, 14 Jul 2014 18:57: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.10.0 X-Bugzilla-Keywords: build X-Bugzilla-Severity: normal X-Bugzilla-Who: law at redhat dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.10.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: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-07/txt/msg00910.txt.bz2 Content-length: 737 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Jeffrey A. Law changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |law at redhat dot com --- Comment #30 from Jeffrey A. Law --- Richi -- in response to your question in c#26. I'll be looking at a handful of DOM issues while in transit to the Cauldron. That'll include another evaluation of whether or not we want to thread across back edges at all. Invalidation of equivalences after traversing a backedge has been extremely problematical and I really question it's value in the real world.