On Fri, 2018-11-09 at 12:11 +0100, Jakub Jelinek wrote:
> On Fri, Nov 09, 2018 at 12:04:54PM +0100, Jakub Jelinek wrote:
> > On Fri, Nov 09, 2018 at 11:34:48AM +0100, Dominique d'Humières
> > wrote:
> > > Bootstrapping r265942 on darwin failed with
> > > 
> > > In file included from /Applications/Xcode-
> > > 6.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SD
> > > Ks/MacOSX10.9.sdk/usr/include/stdio.h:490,
> > >                  from ../../../work/libgomp/affinity-fmt.c:28:
> > > ../../../work/libgomp/affinity-fmt.c: In function
> > > 'gomp_display_affinity':
> > > ../../../work/libgomp/affinity-fmt.c:369:17: error: format '%x'
> > > expects argument of type 'unsigned int', but argument 5 has type
> > > 'long unsigned int' -Werror=format=]
> > >   369 |   sprintf (buf, "0x%x", (uintptr_t) handle);
> > >       |                 ^~~~~~  ~~~~~~~~~~~~~~~~~~
> > 
> > Weird, the above prints a line which just isn't there, line 369 is:
> >                 sprintf (buf, "0x%x", (int) handle);
> > not
> >                 sprintf (buf, "0x%x", (uintptr_t) handle);
> > 
> > What is pthread_t on your platform?  An integral type (which one),
> > pointer
> > or something different (e.g. an aggregate)?
> 
> The "but argument 5" in there is also weird, sprintf has 3 arguments.
> Doesn't current gcc emit warnings like:
> /tmp/j.c: In function ‘main’:
> /tmp/j.c:8:21: warning: format ‘%x’ expects argument of type
> ‘unsigned int’, but argument 3 has type ‘long unsigned int’ [-
> Wformat=]
>     8 |   sprintf (buf, "0x%x", l);
>       |                    ~^   ~
>       |                     |   |
>       |                     |   long unsigned int
>       |                     unsigned int
>       |                    %lx
> ?
> So, what exact compiler is compiling this code?

I agree that that looks weird.  I wonder if this is showing a bug in
the substring-locations.c or c-format.c code?  (I've changed these in
the last couple of months; maybe I messed up?)  Or is the compiler
picking up the wrong code?

The fact that it fails to use the location *within* the string in the
initial error but then prints a supporting "note" with it suggests to
me that there are macros involved.  Is sprintf a macro on this
configuration?  Maybe that's got something to do with it.

Dave

Reply via email to