From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1884 invoked by alias); 4 Feb 2015 18:44:09 -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 1797 invoked by uid 48); 4 Feb 2015 18:44:05 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/47781] warnings from custom printf format specifiers Date: Wed, 04 Feb 2015 18:44: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: 4.4.5 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement 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: 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-02/txt/msg00349.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D47781 --- Comment #14 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (In reply to Tom Tromey from comment #13) > I have been reconsidering the plugin approach given some new things > I learned about the details of the firefox code (namely that it doesn't > faithfully follow printf semantics, sigh). >=20 > One additional note for this bug is that it would be nice if any > such addition by a plugin worked properly with -Wmissing-format-attribute. Note that plugins can define attributes. Perhaps one way to go about this w= ould be to create a plugin that parsed some kind of GCC_printf_format_info attri= bute that matches GCC internal printf checking. Then move GCC own format checkin= g to use this attribute and enable the plugin by default when building GCC. This will give you as much flexibility as GCC format checking supports, and= the plugin will be developed, build, tested and distributed alongside GCC. Users outside GCC just need to use the plugin and add the attributes to their own printf-style functions. Moreover, since the plugin is developed alongside G= CC, it would be logical to add whatever hooks the plugin needs. Moreover, nothing stops users from creating some kind of intermediate langu= age that simplifies custom printf attribute syntax. Probably some C preprocessor magic could be enough. The challenge is the define the syntax of the attribute, but I think this challenge is unavoidable for whoever wants to implement this. You may prese= nt a simplified syntax to the user, but you still need to handle correctly all t= he complexity and corner cases in c-format.c. >>From gcc-bugs-return-476017-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Feb 04 18:45:31 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 9157 invoked by alias); 4 Feb 2015 18:45:30 -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 9092 invoked by uid 48); 4 Feb 2015 18:45:27 -0000 From: "pault at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 Date: Wed, 04 Feb 2015 18:45: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: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: pault at gcc dot gnu.org 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: 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-02/txt/msg00350.txt.bz2 Content-length: 1491 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921 --- Comment #8 from Paul Thomas --- (In reply to H.J. Lu from comment #7) > (In reply to Paul Thomas from comment #6) > > (In reply to H.J. Lu from comment #2) > > > I got > > > > > > Program received signal SIGSEGV: Segmentation fault - invalid memory > > > reference. > > > > > > Backtrace for this error: > > > #0 0xF763FACE > > > #1 0xF763EBDE > > > #2 0xF773CBBF > > > #3 0x8048BA5 in __final_main_T2.3337 at class_allocate_18.f90:? > > > #4 0x8048D68 in __final_main_T3.3328 at class_allocate_18.f90:? > > > #5 0x8048A59 in MAIN__ at class_allocate_18.f90:? > > > FAIL: gfortran.dg/class_allocate_18.f90 -O1 execution test > > > > > > But I couldn't reproduce it on another machine. I will keep an eye on it. > > > > Hi HJ, > > > > Given that the error is sporadic, are you sure that the offending revisions > > are not 220125 and 220130 - PR64230. The error messages that you are getting > > are remarkably similar to the original report for this PR. > > > > I don't know for sure. This failure seems more consistent on 4.9 branch > than on trunk. Dear HJ, I can confirm that the part of resolve.c modified in r220191 is not visited by the compilation of class_allocate_18.f90. If I have understood correctly, -fPIC is not supported on x86_64 and so, unless I am mistaken, I cannot help you further. Please let me know if there is anything that I can do to help. Best regards Paul