From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 78E63385D0C6; Wed, 26 Oct 2022 12:04:58 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 78E63385D0C6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1666785898;
	bh=snA6yDBRvdnriU6n/+PxTbuNiu42ALXfq3mqgM+vpYI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=uxgQWB7rc9be/jVrsLhX1Yo6vs1EzFDKW9htL1B9WladzTbS1z6Mp1kw+y3repCqv
	 4Suf/7EPpCtVWn8gfWUXtZHtln6YIXUgYbrJ6VstP+6o10I+xjikhmfaqWHgoN0Swa
	 r9eLI5x/dd/okXzwgwFkCABx8IxXPxfh7NjwMBQs=
From: "tomas.kalibera at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf
 in mingw
Date: Wed, 26 Oct 2022 12:04:57 +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: 9.1.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tomas.kalibera at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
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: <bug-95130-4-Lm9ZM8mntL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-95130-4@http.gcc.gnu.org/bugzilla/>
References: <bug-95130-4@http.gcc.gnu.org/bugzilla/>
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
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95130

--- Comment #11 from Tomas Kalibera <tomas.kalibera at gmail dot com> ---
(In reply to LIU Hao from comment #10)
> (In reply to Tomas Kalibera from comment #7)
> > I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patch=
es
> > mailing list in May:
> >=20
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html
> >=20
> > The patches still apply to current 10,11,12 and trunk. Please see the e=
mail
> > linked above for more information.
>=20
>=20
> Thanks for the patch. Updated locally. I will test it against trunk as so=
on
> as I get a little time.

Thanks. Re Jeff's comment from the mailing list:

> I guess we're going to depend on the builtin-format always appearing=20
> first in the chain?  While it's probably true in practice, I doubt we=20
> really want to depend on that.
>
> Is there any sensible way to distinguish between the builtin format and=20
> one that comes from the source?

I didn't find any elegant way to find out whether a format attribute is a
built-in attribute in check_function_format(). So unless I overlooked somet=
hing
(which is very much possible), it would make the patch more intrusive.

handle_format_attribute() has that information in flags (ATTR_FLAG_BUILT_IN=
).
Maybe handle_format_attribute() could add the flags (or only a boolean whet=
her
it is a builtin attribute) to the attribute tree, so that
check_function_format() can access it, e.g. similarly to how no_sanitize do=
es
it. Would this be better? And if so, is there a recommended place in the fo=
rmat
attribute tree where it should be added to?=