Message ID | 47637d16-2b7d-7813-b83a-4bc590221b7f@linux.ibm.com |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1DFE1385840F for <patchwork@sourceware.org>; Wed, 2 Feb 2022 16:36:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1DFE1385840F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1643819777; bh=06k7B46L5q0UrYx56Zql2q9hiyC8MDQBoZyoDFqcbh8=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=PsVUQm/YTJ5X0RUY40lWam3s6HqgMfbkHOyys99nPIMvuxpK71j2sAf2X1V0B/wEm qNb9NpIgirU3SsXajJJT5VtnZ/OLcRdLt1fzU2CxtmZnnKXvqPIZRuk651Ki8J8qs0 4km3cfTJqrGhpOBslyQzruQTYR9a8Qqtuai7B5VE= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id E6FBB3858C2C for <gcc-patches@gcc.gnu.org>; Wed, 2 Feb 2022 16:35:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E6FBB3858C2C Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 212Febn2021874 for <gcc-patches@gcc.gnu.org>; Wed, 2 Feb 2022 16:35:47 GMT Received: from ppma03fra.de.ibm.com (6b.4a.5195.ip4.static.sl-reverse.com [149.81.74.107]) by mx0b-001b2d01.pphosted.com with ESMTP id 3dyveh1mu7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <gcc-patches@gcc.gnu.org>; Wed, 02 Feb 2022 16:35:47 +0000 Received: from pps.filterd (ppma03fra.de.ibm.com [127.0.0.1]) by ppma03fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 212GWZqp002211 for <gcc-patches@gcc.gnu.org>; Wed, 2 Feb 2022 16:35:45 GMT Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by ppma03fra.de.ibm.com with ESMTP id 3dvw79we9c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <gcc-patches@gcc.gnu.org>; Wed, 02 Feb 2022 16:35:45 +0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 212GZd9D34800066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 2 Feb 2022 16:35:39 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9A58AA405D; Wed, 2 Feb 2022 16:35:39 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5E63FA4055; Wed, 2 Feb 2022 16:35:39 +0000 (GMT) Received: from [9.171.22.122] (unknown [9.171.22.122]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Wed, 2 Feb 2022 16:35:39 +0000 (GMT) Content-Type: multipart/mixed; boundary="------------kLI2Y0740dvPaLT4HIpOMNro" Message-ID: <47637d16-2b7d-7813-b83a-4bc590221b7f@linux.ibm.com> Date: Wed, 2 Feb 2022 17:35:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: GCC Patches <gcc-patches@gcc.gnu.org>, Andreas Krebbel <krebbel@linux.ibm.com> Subject: s390: Fix bootstrap -Wformat-diag errors X-TM-AS-GCONF: 00 X-Proofpoint-GUID: b7LNbB62dYpnnAbgMzVSjCl2wBX_0TBq X-Proofpoint-ORIG-GUID: b7LNbB62dYpnnAbgMzVSjCl2wBX_0TBq X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-02_08,2022-02-01_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 lowpriorityscore=0 priorityscore=1501 phishscore=0 mlxscore=0 bulkscore=0 mlxlogscore=999 adultscore=0 suspectscore=0 malwarescore=0 clxscore=1015 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202020092 X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Robin Dapp via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Robin Dapp <rdapp@linux.ibm.com> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
s390: Fix bootstrap -Wformat-diag errors
|
|
Commit Message
Robin Dapp
Feb. 2, 2022, 4:35 p.m. UTC
Hi, this fixes the s390 bootstrap errors caused by -Werror=format-diag. It simply splits the problematic format strings. Bootstrapped and regtested with -march=z15. Is it OK? Regards Robin -- gcc/ChangeLog: * config/s390/s390.cc (s390_valid_target_attribute_inner_p): Split format strings.
Comments
On 2/2/22 09:35, Robin Dapp via Gcc-patches wrote: > Hi, > > this fixes the s390 bootstrap errors caused by -Werror=format-diag. It > simply splits the problematic format strings. Either this: error ("%<attribute(target(\"%s\"))%> is unknown", orig_p); or this would be better: error ("attribute %<target(\"%s\")%> is unknown", orig_p); The %< %> directives will render it in single quotes like keywords and identifiers. Using %qs would render it in double quotes like a string, which wouldn't be quite right. Martin > > Bootstrapped and regtested with -march=z15. > > Is it OK? > > Regards > Robin > > -- > > gcc/ChangeLog: > > * config/s390/s390.cc (s390_valid_target_attribute_inner_p): Split > format strings.
Hi Martin, > Either this: > > error ("%<attribute(target(\"%s\"))%> is unknown", orig_p); > > or this would be better: > > error ("attribute %<target(\"%s\")%> is unknown", orig_p); > > The %< %> directives will render it in single quotes like keywords and > identifiers. Using %qs would render it in double quotes like a string, > which wouldn't be quite right. the x86 backend will print the error message in a different format using single quotes e.g. bla.cc:2:5: error: attribute ‘bleh’ argument ‘target’ is unknown I don't find that better to be frank but maybe it would make sense for us to also adopt this error message style and not use a different one? They use %qs, though - or is there an intention to also change x86's error messages? I guess in general it's better to have similar error messages across targets for the same problem. Regards Robin
On 2/3/22 09:24, Robin Dapp via Gcc-patches wrote: > Hi Martin, > >> Either this: >> >> error ("%<attribute(target(\"%s\"))%> is unknown", orig_p); >> >> or this would be better: >> >> error ("attribute %<target(\"%s\")%> is unknown", orig_p); >> >> The %< %> directives will render it in single quotes like keywords and >> identifiers. Using %qs would render it in double quotes like a string, >> which wouldn't be quite right. > > the x86 backend will print the error message in a different format using > single quotes e.g. > > bla.cc:2:5: error: attribute ‘bleh’ argument ‘target’ is unknown > > I don't find that better to be frank but maybe it would make sense for > us to also adopt this error message style and not use a different one? > They use %qs, though - or is there an intention to also change x86's > error messages? I guess in general it's better to have similar error > messages across targets for the same problem. > > Regards > Robin Hello. I've just coincidentally fixed the issue with r12-7013-g0415470c8d6620 where I use the same error format as i386 does. Martin
On 2/3/22 01:59, Martin Liška wrote: > On 2/3/22 09:24, Robin Dapp via Gcc-patches wrote: >> Hi Martin, >> >>> Either this: >>> >>> error ("%<attribute(target(\"%s\"))%> is unknown", orig_p); >>> >>> or this would be better: >>> >>> error ("attribute %<target(\"%s\")%> is unknown", orig_p); >>> >>> The %< %> directives will render it in single quotes like keywords and >>> identifiers. Using %qs would render it in double quotes like a string, >>> which wouldn't be quite right. >> >> the x86 backend will print the error message in a different format using >> single quotes e.g. >> >> bla.cc:2:5: error: attribute ‘bleh’ argument ‘target’ is unknown That's a bug in the i386 back end: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90524 >> I don't find that better to be frank but maybe it would make sense for >> us to also adopt this error message style and not use a different one? >> They use %qs, though - or is there an intention to also change x86's >> error messages? I guess in general it's better to have similar error >> messages across targets for the same problem. >> >> Regards >> Robin > > Hello. > > I've just coincidentally fixed the issue with r12-7013-g0415470c8d6620 > where I use the same error format as i386 does. The change repeats the i386 mistake in the s360 back end. If the error is supposed to point out that orig_p is not a valid argument to attribute target as I believe is the case then the new call should be: error ("attribute %<target%> argument %qs is unknown", orig_p); Martin
On 2/3/22 17:43, Martin Sebor wrote: > On 2/3/22 01:59, Martin Liška wrote: >> On 2/3/22 09:24, Robin Dapp via Gcc-patches wrote: >>> Hi Martin, >>> >>>> Either this: >>>> >>>> error ("%<attribute(target(\"%s\"))%> is unknown", orig_p); >>>> >>>> or this would be better: >>>> >>>> error ("attribute %<target(\"%s\")%> is unknown", orig_p); >>>> >>>> The %< %> directives will render it in single quotes like keywords and >>>> identifiers. Using %qs would render it in double quotes like a string, >>>> which wouldn't be quite right. >>> >>> the x86 backend will print the error message in a different format using >>> single quotes e.g. >>> >>> bla.cc:2:5: error: attribute ‘bleh’ argument ‘target’ is unknown > > That's a bug in the i386 back end: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90524 > >>> I don't find that better to be frank but maybe it would make sense for >>> us to also adopt this error message style and not use a different one? >>> They use %qs, though - or is there an intention to also change x86's >>> error messages? I guess in general it's better to have similar error >>> messages across targets for the same problem. >>> >>> Regards >>> Robin >> >> Hello. >> >> I've just coincidentally fixed the issue with r12-7013-g0415470c8d6620 >> where I use the same error format as i386 does. > > The change repeats the i386 mistake in the s360 back end. If > the error is supposed to point out that orig_p is not a valid > argument to attribute target as I believe is the case then > the new call should be: > > error ("attribute %<target%> argument %qs is unknown", orig_p); > > Martin Yeah, fixed with g:9db03cd0caf6bbde1de302bf3509dc26ca8bff2b. Cheers, Martin
On 2/3/22 09:45, Martin Liška wrote: > On 2/3/22 17:43, Martin Sebor wrote: >> On 2/3/22 01:59, Martin Liška wrote: >>> On 2/3/22 09:24, Robin Dapp via Gcc-patches wrote: >>>> Hi Martin, >>>> >>>>> Either this: >>>>> >>>>> error ("%<attribute(target(\"%s\"))%> is unknown", orig_p); >>>>> >>>>> or this would be better: >>>>> >>>>> error ("attribute %<target(\"%s\")%> is unknown", orig_p); >>>>> >>>>> The %< %> directives will render it in single quotes like keywords and >>>>> identifiers. Using %qs would render it in double quotes like a >>>>> string, >>>>> which wouldn't be quite right. >>>> >>>> the x86 backend will print the error message in a different format >>>> using >>>> single quotes e.g. >>>> >>>> bla.cc:2:5: error: attribute ‘bleh’ argument ‘target’ is unknown >> >> That's a bug in the i386 back end: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90524 >> >>>> I don't find that better to be frank but maybe it would make sense for >>>> us to also adopt this error message style and not use a different one? >>>> They use %qs, though - or is there an intention to also change x86's >>>> error messages? I guess in general it's better to have similar error >>>> messages across targets for the same problem. >>>> >>>> Regards >>>> Robin >>> >>> Hello. >>> >>> I've just coincidentally fixed the issue with r12-7013-g0415470c8d6620 >>> where I use the same error format as i386 does. >> >> The change repeats the i386 mistake in the s360 back end. If >> the error is supposed to point out that orig_p is not a valid >> argument to attribute target as I believe is the case then >> the new call should be: >> >> error ("attribute %<target%> argument %qs is unknown", orig_p); >> >> Martin > > Yeah, fixed with g:9db03cd0caf6bbde1de302bf3509dc26ca8bff2b. Great, thank you! Martin > > Cheers, > Martin
commit 41270791b1d1235d580b6d81c315c74ad07c1807 Author: Robin Dapp <rdapp@linux.ibm.com> Date: Tue Feb 1 10:13:52 2022 +0100 s390: Fix bootstrap by splitting format string. Recently -Werror=format-diag was turned on for bootstrap which broke s390 bootstrap. This patch splits the problematic format strings and changes quoting from explicit \" to %qs. Bootstrapped and regtested on s390x. diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc index 58064bfb525..d2faa1371eb 100644 --- a/gcc/config/s390/s390.cc +++ b/gcc/config/s390/s390.cc @@ -15879,6 +15879,9 @@ s390_valid_target_attribute_inner_p (tree args, /* Handle multiple arguments separated by commas. */ next_optstr = ASTRDUP (TREE_STRING_POINTER (args)); + const char err_prefix[] = "attribute(target("; + const char err_suffix[] = "))"; + while (next_optstr && *next_optstr != '\0') { char *p = next_optstr; @@ -15938,7 +15941,7 @@ s390_valid_target_attribute_inner_p (tree args, /* Process the option. */ if (!found) { - error ("attribute(target(\"%s\")) is unknown", orig_p); + error ("%s%qs%s is unknown", err_prefix, orig_p, err_suffix); return false; } else if (attrs[i].only_as_pragma && !force_pragma) @@ -15988,7 +15991,7 @@ s390_valid_target_attribute_inner_p (tree args, } else { - error ("attribute(target(\"%s\")) is unknown", orig_p); + error ("%s%qs%s is unknown", err_prefix, orig_p, err_suffix); ret = false; } } @@ -16005,7 +16008,7 @@ s390_valid_target_attribute_inner_p (tree args, global_dc); else { - error ("attribute(target(\"%s\")) is unknown", orig_p); + error ("%s%qs%s is unknown", err_prefix, orig_p, err_suffix); ret = false; } }