[hjl@gnu-bdx-1 tmp]$ cat x.c
#include <string.h>
#include <stdio.h>
char *str_error_r(char *buf, size_t buflen)
{
	snprintf(buf, buflen, "(%p, %zd)", buf, buflen);
	return buf;
}
[hjl@gnu-bdx-1 tmp]$ /usr/gcc-8.0.1-x32/bin/gcc -O2 -S -Wall x.c
x.c: In function ‘str_error_r’:
x.c:5:2: warning: passing argument 1 to restrict-qualified parameter aliases with argument 4 [-Wrestrict]
  snprintf(buf, buflen, "(%p, %zd)", buf, buflen);
  ^~~~~~~~
[hjl@gnu-bdx-1 tmp]$

This is caused by r258455.

Umm, isn't that invalid code?  The whole point of the warning is to catch precisely this kind of broken idiom.  Right?

(In reply to Jeffrey A. Law from comment #3)
> Umm, isn't that invalid code?  The whole point of the warning is to catch
> precisely this kind of broken idiom.  Right?

Why is it invalid?  Argument 4 is for %p. It looks valid to me.

Yeah, only arguments corresponding to %s/%ls/%S/%n or whatever else can actually dereference the pointer (for *scanf of course all the pointers).

On the other side, the warning matches the documented behavior and it might be too difficult to add all the exceptions when we know that the argument will not be really dereferenced.

(In reply to Jakub Jelinek from comment #6)
> On the other side, the warning matches the documented behavior and it might
> be too difficult to add all the exceptions when we know that the argument
> will not be really dereferenced.

How many exceptions are there, beside %p?

Not aware of any right now, but 1) if the format string is not compile time known, we don't know if it is %p or not 2) the format string parsing is done in other passes (-Wformat code in FEs, and gimple-ssa-sprintf.c) compared to the restrict warning.

(In reply to Jakub Jelinek from comment #8)
> Not aware of any right now, but 1) if the format string is not compile time
> known, we don't know if it is %p or not 2) the format string parsing is done

We only need to handle the known format string case.

> in other passes (-Wformat code in FEs, and gimple-ssa-sprintf.c) compared to
> the restrict warning.

This shouldn't be the reason not to do it.

(In reply to H.J. Lu from comment #9)
> (In reply to Jakub Jelinek from comment #8)
> > Not aware of any right now, but 1) if the format string is not compile time
> > known, we don't know if it is %p or not 2) the format string parsing is done
> 
> We only need to handle the known format string case.
> 
> > in other passes (-Wformat code in FEs, and gimple-ssa-sprintf.c) compared to
> > the restrict warning.
> 
> This shouldn't be the reason not to do it.

If there is no way to fix it, we should warn (char *) cases under -Wextra,
not under -Wall.

The warning will go away once -Wrestrict is implemented for sprintf, hopefully in GCC 9 (the patch I submitted in July didn't make it to GCC 8: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00036.html), and the handling for the built-in functions removed from the front-end.  This is being tracked in bug 83688.

Until then, the only way to avoid the warning that I can think of is to exclude from checking arguments passed through the ellipsis, but that will result in some false negatives for sprintf et al.  So the question is: do the benefits of the warning outweigh the cost of the false positives.

The potential for false positives here also isn't limited to sprintf.  It's a general problem that affects user-defined functions as well.  For example:

$ cat z.c && gcc -S -Wall z.c
void f (char* restrict, const char* restrict, const void*);

void g (char *s)
{
  f (s, "", s);
}

z.c: In function ‘g’:
z.c:5:3: warning: passing argument 1 to restrict-qualified parameter aliases with argument 3 [-Wrestrict]
   f (s, "", s);
   ^

The only way to avoid these false positives (and negatives) is to add some annotation to let users indicate how each argument is used (e.g., such as the attributes read_only and write_only that I've been working on).  This is being tracked in bug 83859.

(In reply to Martin Sebor from comment #11)
> 
> Until then, the only way to avoid the warning that I can think of is to
> exclude from checking arguments passed through the ellipsis, but that will
> result in some false negatives for sprintf et al.  So the question is: do
> the benefits of the warning outweigh the cost of the false positives.
> 

It is a regression that GCC 8 can't compile lib/str_error_r.c in Linux kernel
without modifications.

I think this needs to defer to gcc-9.

(In reply to Jeffrey A. Law from comment #13)
> I think this needs to defer to gcc-9.

It's gcc-9 now.

GCC 9.1 has been released.

GCC 9.2 has been released.

The patch below avoids the warning.  Unfortunately, as a result of bug 92666, it triggers another bogus warning during bootstrap.

Index: gcc/c-family/c-common.c
===================================================================
--- gcc/c-family/c-common.c	(revision 278975)
+++ gcc/c-family/c-common.c	(working copy)
@@ -5763,8 +5763,26 @@ check_function_arguments (location_t loc, const_tr
   if (warn_format)
     check_function_sentinel (fntype, nargs, argarray);
 
-  if (warn_restrict)
-    warned_p |= check_function_restrict (fndecl, fntype, nargs, argarray);
+  if (fndecl && fndecl_built_in_p (fndecl, BUILT_IN_NORMAL))
+    {
+      switch (DECL_FUNCTION_CODE (fndecl))
+	{
+	case BUILT_IN_SPRINTF:
+	case BUILT_IN_SPRINTF_CHK:
+	case BUILT_IN_SNPRINTF:
+	case BUILT_IN_SNPRINTF_CHK:
+	  /* Let the sprintf pass handle these.  */
+	  return warned_p;
+
+	default:
+	  break;
+	}
+    }
+
+  /* check_function_restrict sets the DECL_READ_P for arguments
+     so it must be called unconiditionally.  */
+  warned_p |= check_function_restrict (fndecl, fntype, nargs, argarray);
+
   return warned_p;
 }

GCC 10 patch: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01471.html

The master branch has been updated by Martin Sebor <msebor@gcc.gnu.org>:

https://gcc.gnu.org/g:8a990ffafaaa18981c6e91d4ed88f05ed74c5f3f

commit r10-6170-g8a990ffafaaa18981c6e91d4ed88f05ed74c5f3f
Author: Martin Sebor <msebor@redhat.com>
Date:   Thu Jan 23 11:37:02 2020 +0100

    PR c/84919 - bogus -Wrestrict on sprintf %p with destination as argument
    
    gcc/c-family/ChangeLog:
    
    	PR c/84919
    	* c-common.c (check_function_arguments): Avoid overlap checking
    	of sprintf functions.
    
    gcc/testsuite/ChangeLog:
    
    	PR c/84919
    	* gcc.dg/Wrestrict-20.c: New test.

Fixed on trunk (GCC 10).  The fix cannot be backported on its own without introducing false negatives.

GCC 9.3.0 has been released, adjusting target milestone.

(In reply to Martin Sebor from comment #20)
> Fixed on trunk (GCC 10).  The fix cannot be backported on its own without
> introducing false negatives.

so... if it can't be backported... then does this bug need to stay open?

I think that's a question for the release managers.  I thought they like to keep regressions open until all the affected branches have closed, but I could be wrong.  One way to find out is to close it and let them reopen it :)

(In reply to Martin Sebor from comment #23)
> I think that's a question for the release managers.  I thought they like to
> keep regressions open until all the affected branches have closed, but I
> could be wrong.  One way to find out is to close it and let them reopen it :)

ok, I'll do that

Hello.

I'm trying to configure and compile GVT-g to enable the passthrough of the integrated GPU that I have on my motherboard,the model "Intel Corporation UHD Graphics 630 (Desktop 9 Series) (rev 02)". This is the tutorial that I'm following :

https://lists.freedesktop.org/archives/intel-gvt-dev/2017-June/001238.html

I reached this point and then the compilation stopped for an error that it seems to be the same as this.

root@ziomario-z390aoruspro:/etc/xen/gvt-linux# make
  CHK     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  CHK     include/generated/timeconst.h
  CHK     include/generated/bounds.h
  CHK     include/generated/asm-offsets.h
  CALL    scripts/checksyscalls.sh
  DESCEND  objtool
  CC       /etc/xen/gvt-linux/tools/objtool/pager.o
  CC       /etc/xen/gvt-linux/tools/objtool/parse-options.o
  CC       /etc/xen/gvt-linux/tools/objtool/run-command.o
  CC       /etc/xen/gvt-linux/tools/objtool/sigchain.o
  CC       /etc/xen/gvt-linux/tools/objtool/subcmd-config.o
  LD       /etc/xen/gvt-linux/tools/objtool/libsubcmd-in.o
  AR       /etc/xen/gvt-linux/tools/objtool/libsubcmd.a
  GEN      /etc/xen/gvt-linux/tools/objtool/arch/x86/insn/inat-tables.c
  CC       /etc/xen/gvt-linux/tools/objtool/arch/x86/decode.o
  LD       /etc/xen/gvt-linux/tools/objtool/arch/x86/objtool-in.o
  CC       /etc/xen/gvt-linux/tools/objtool/builtin-check.o
  CC       /etc/xen/gvt-linux/tools/objtool/elf.o
  CC       /etc/xen/gvt-linux/tools/objtool/special.o
  CC       /etc/xen/gvt-linux/tools/objtool/objtool.o
  CC       /etc/xen/gvt-linux/tools/objtool/libstring.o
  CC       /etc/xen/gvt-linux/tools/objtool/str_error_r.o
../lib/str_error_r.c: In function ‘str_error_r’:
../lib/str_error_r.c:24:3: error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]
   24 |   snprintf(buf, buflen, "INTERNAL ERROR: strerror_r(%d, %p, %zd)=%d", errnum, buf, buflen, err);
      |   ^~~~~~~~
cc1: all warnings being treated as errors
mv: impossibile eseguire stat di '/etc/xen/gvt-linux/tools/objtool/.str_error_r.o.tmp': File o directory non esistente
make[3]: *** [Build:18: /etc/xen/gvt-linux/tools/objtool/str_error_r.o] Errore 1
make[2]: *** [Makefile:40: /etc/xen/gvt-linux/tools/objtool/objtool-in.o] Errore 2
make[1]: *** [Makefile:61: objtool] Errore 2
make: *** [Makefile:1616: tools/objtool] Errore 2

I don't understand where is the patch ?

I'm using ubuntu 20.04 and gcc 9.3

The fix was applied to GCC 10 but not to GCC 9 or 8.  It will not be backported there.  It can be suppressed by introducing a named temporary copy of the pointer and using it as one other other argument to the function.

void f (char *p)
{
  char *q = p;
  sprintf (p, "%p", q);
}

I'm not a coder. can u explain to me carefully what should I do ? thanks.

Il giorno gio 20 ago 2020 alle ore 16:40 msebor at gcc dot gnu.org <
gcc-bugzilla@gcc.gnu.org> ha scritto:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84919
>
> --- Comment #27 from Martin Sebor <msebor at gcc dot gnu.org> ---
> The fix was applied to GCC 10 but not to GCC 9 or 8.  It will not be
> backported
> there.  It can be suppressed by introducing a named temporary copy of the
> pointer and using it as one other other argument to the function.
>
> void f (char *p)
> {
>   char *q = p;
>   sprintf (p, "%p", q);
> }
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

I get this error :

gcc -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O2 -fomit-frame-pointer -nostdinc -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include /etc/xen/igvtg-xen/xen/include/xen/config.h '-D__OBJECT_FILE__="trace.o"' -Wa,--strip-local-absolute -MMD -MF ./.trace.o.d -I/etc/xen/igvtg-xen/xen/include -I/etc/xen/igvtg-xen/xen/include/asm-x86/mach-generic -I/etc/xen/igvtg-xen/xen/include/asm-x86/mach-default -DXEN_IMG_OFFSET=0x200000 '-D__OBJECT_LABEL__=common$trace.o' -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -DHAVE_GAS_VMX -DHAVE_GAS_SSE4_2 -DHAVE_GAS_EPT -DHAVE_GAS_RDRAND -DHAVE_GAS_FSGSBASE -DHAVE_GAS_RDSEED -U__OBJECT_LABEL__ -DHAVE_GAS_QUOTED_SYM '-D__OBJECT_LABEL__=common/trace.o' -mno-red-zone -mno-sse -fpic -fno-asynchronous-unwind-tables -DGCC_HAS_VISIBILITY_ATTRIBUTE -c trace.c -o trace.o
trace.c: In function ‘__trace_hypercall’:
trace.c:829:19: error: taking address of packed member of ‘struct ’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
829 | uint32_t *a = d.args;
| ^
cc1: all warnings being treated as errors

(In reply to Marietto from comment #28)
> I'm not a coder. can u explain to me carefully what should I do ? thanks.

Usually packages provide a mechanism to prevent compiler warnings from causing errors (by avoiding -Werror).  I don't know how this one does it.  I'd try adding WERROR=0 to the invocation of the command you are using to build it.  The link is a diff from a Wiki edit, not a guide.  This also isn't the right place to get help with third party software.   I'd talk to the Intel GVT-g developers.

they don't reply to messages and they don't fix old bugs. And new users aren't interested to use xen anymore. So,it's a waste of time.