[Bug c/96407] New: LTO inlined functions don't inherit disabled warnings

2020-08-01 Thread rjones at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96407

Bug ID: 96407
   Summary: LTO inlined functions don't inherit disabled warnings
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rjones at redhat dot com
  Target Milestone: ---

This is a very reduced example from some real code where we are using -Werror
-Wstack-usage=5000.

We want most functions to have limited stack usage, but in some cases we have
carefully examined functions to ensure their stack usage isn't unbounded - but
it's hard to prove it - so we have disabled the warning for those functions.

--- test.c ---
#include 

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wstack-usage="

int
test (int i)
{
  char str[i];
  memset (str, 0, sizeof str);
  return str[0]+i;
}

#pragma GCC diagnostic pop

--- main.c ---
#include 

extern int test (int i);

int
main (int argc, char *argv[])
{
  int j = test (argc);
  printf ("%d\n", j);
  return 0;
}

---
$ gcc -O2 -flto main.c test.c -Werror -Wstack-usage=5000 -o a.out 
main.c: In function ‘main’:
main.c:6:1: error: stack usage might be unbounded [-Werror=stack-usage=]
6 | main (int argc, char *argv[])
  | ^
lto1: all warnings being treated as errors


Note that if you combine these two functions into a single file, it
does *not* warn/error, even though presumably it can easily inline the
test() function.  So LTO seems to be causing the difference.

[Bug c/96916] New: warning: ‘strndup’ specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]

2020-09-03 Thread rjones at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96916

Bug ID: 96916
   Summary: warning: ‘strndup’ specified bound
18446744073709551615 exceeds maximum object size
9223372036854775807 [-Wstringop-overflow=]
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rjones at redhat dot com
  Target Milestone: ---

I'm not certain this is really a bug, but I don't understand it.  A simple
reproducer:

--
#include 
#include 
#include 
#include 

const char *
copyn (const char *str, size_t n)
{
  return strndup (str, n);
}

const char *
copy (const char *str)
{
  return copyn (str, SIZE_MAX);
}
--

$ gcc -O2 -Wall -c test.c
In function ‘copyn’,
inlined from ‘copy’ at test.c:15:10:
test.c:9:10: warning: ‘strndup’ specified bound 18446744073709551615 exceeds
maximum object size 9223372036854775807 [-Wstringop-overflow=]
9 |   return strndup (str, n);
  |  ^~~~

$ gcc --version
gcc (GCC) 10.2.1 20200826 (Red Hat 10.2.1-3)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Note that it seems as if the compiler is claiming that strndup cannot cope with
a string larger than ssize_t (rather than size_t), which is unexpected.

[Bug c/52560] New: if (r == -1) causes 'assuming signed overflow does not occur when simplifying conditional to constant'

2012-03-12 Thread rjones at redhat dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52560

 Bug #: 52560
   Summary: if (r == -1) causes 'assuming signed overflow does not
occur when simplifying conditional to constant'
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rjo...@redhat.com


Here is the reproducer:

wget 'http://oirase.annexia.org/strict-overflow-warning.i.xz'
unxz strict-overflow-warning.i.xz
gcc -std=gnu99 -O2 -Wstrict-overflow -c strict-overflow-warning.i

The warning is:

  inspect_fs_unix.c: In function ‘check_fstab’:
  inspect_fs_unix.c:1075:6: warning: assuming signed overflow does not occur
when simplifying conditional to constant [-Wstrict-overflow]

However the code doesn't look like anything should be simplified,
or a warning:

  n_app_md_devices = map_app_md_devices (g, &app_map);
  if (n_app_md_devices == -1) goto error;

where map_app_md_devices is a function that returns an int:

  static int map_app_md_devices (guestfs_h *g, Hash_table **map);

and n_app_md_devices is also an int.

I've tried this on several versions of gcc:

gcc (GCC) 4.7.0 20120308 (Red Hat 4.7.0-0.19)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

(for further build info, go to:
http://koji.fedoraproject.org/koji/buildinfo?buildID=305760
and click 'build logs')

Same thing with this gcc from Ubuntu 11.10:

$ gcc --version
gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

We think this first started happening in gcc 4.5.1.

[Bug tree-optimization/52560] if (r == -1) causes 'assuming signed overflow does not occur when simplifying conditional to constant'

2012-03-12 Thread rjones at redhat dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52560

--- Comment #3 from Richard W.M. Jones  2012-03-12 
16:30:45 UTC ---
I see that this is actually a bug in our code.  I pushed
the following fix to libguestfs:
https://github.com/libguestfs/libguestfs/commit/d66dd2260c724bdfe57a8595aac37c8e9173cee5

[Bug c/88993] New: GCC 9 -Wformat-overflow=2 should reflect real libc limits

2019-01-22 Thread rjones at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993

Bug ID: 88993
   Summary: GCC 9 -Wformat-overflow=2 should reflect real libc
limits
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rjones at redhat dot com
  Target Milestone: ---

-Wformat-overflow=2 is the default when using gnulib manywarnings.m4, and
so is used by a bunch of GNU projects.  I've found with GCC 9 it is very
aggressive warning about any string it statically determine could be
longer than 4095 characters (see
https://stackoverflow.com/questions/8119914/printf-fprintf-maximum-size-according-to-c99?rq=1
for the presumed origin of that limit).

I am using a libc which does not have such a small limit (in fact, I believe
it's unlimited) and I think this warning should warn about the real
toolchain limit, not some peculiar corner of the C99 standard that vanishingly
small number of libcs are really limited by (and if they are - fix your libc).

Example below:

#include 
#include 
#include 

int
main (void)
{
  char s[4097];

  fgets (s, sizeof s, stdin);
  printf ("%.*s", (int) strlen (s), s);

//test.c:11:12: warning: ‘%.*s’ directive output between 0 and 4096 bytes may
exceed minimum required size of 4095 [-Wformat-overflow=]
//   11 |   printf ("%.*s", (int) strlen (s), s);
//  |^~~~ ~

  printf ("%s", s);

//test.c:12:12: warning: ‘%s’ directive output between 0 and 4096 bytes may
exceed minimum required size of 4095 [-Wformat-overflow=]
//   12 |   printf ("%s", s);
//  |^~   ~

  exit (0);
}

[Bug c/88993] GCC 9 -Wformat-overflow=2 should reflect real libc limits

2019-01-22 Thread rjones at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993

--- Comment #1 from Richard W.M. Jones  ---
Sorry, forgot the version.  It's:

gcc-9.0.0-0.3.fc30.x86_64

[Bug c/88993] GCC 9 -Wformat-overflow=2 should reflect real libc limits

2019-01-24 Thread rjones at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993

--- Comment #6 from Richard W.M. Jones  ---
I switched the warning off in libguestfs, but before it was
switched off I got all these warnings (errors in fact because
we use -Werror in development builds).

qemuopts.c: In function 'qemuopts_to_config_channel':
qemuopts.c:987:29: error: '%.*s' directive output between 0 and 2147483647
bytes may exceed minimum required size of 4095 [-Werror=format-overflow=]
  987 | fprintf (fp, "  %.*s = ", (int) k, values[j]);
  | ^~~~
qemuopts.c:987:26: note: assuming directive output of 1 byte
  987 | fprintf (fp, "  %.*s = ", (int) k, values[j]);
  |  ^~~

utils.c: In function 'guestfs_int_full_path':
utils.c:729:27: error: '%.*s' directive output between 0 and 2147483647 bytes
may exceed minimum required size of 4095 [-Werror=format-overflow=]
  729 | r = asprintf (&path, "%.*s", len, dir);
  |   ^~~~
utils.c:729:26: note: assuming directive output of 1 byte
  729 | r = asprintf (&path, "%.*s", len, dir);
  |  ^~
utils.c:727:27: error: '%.*s' directive output between 0 and 2147483647 bytes
may exceed minimum required size of 4095 [-Werror=format-overflow=]
  727 | r = asprintf (&path, "%.*s/%s", len, dir, name);
  |   ^~~~
utils.c:727:26: note: assuming directive output of 1 byte
  727 | r = asprintf (&path, "%.*s/%s", len, dir, name);
  |  ^
utils.c:727:26: note: assuming directive output of 1 byte

In file included from info.c:43:
info.c: In function 'parse_json':
info.c:205:13: error: '%.*s' directive output between 0 and 2147483647 bytes
may exceed minimum required size of 4095 [-Werror=format-overflow=]
  205 |   debug (g, "%s: qemu-img info JSON output:\n%.*s\n", __func__, (int)
len, input);
  | ^~~~
guestfs-internal.h:577:49: note: in definition of macro 'debug'
  577 |   do { if ((g)->verbose) guestfs_int_debug ((g),__VA_ARGS__); } while
(0)
  | ^~~
info.c:205:46: note: format string is defined here
  205 |   debug (g, "%s: qemu-img info JSON output:\n%.*s\n", __func__, (int)
len, input);
  |  ^~~~
In file included from info.c:43:
info.c:205:13: note: assuming directive output of 1 byte
  205 |   debug (g, "%s: qemu-img info JSON output:\n%.*s\n", __func__, (int)
len, input);
  | ^~~~
guestfs-internal.h:577:49: note: in definition of macro 'debug'
  577 |   do { if ((g)->verbose) guestfs_int_debug ((g),__VA_ARGS__); } while
(0)
  | ^~~

btrfs.c: In function 'do_btrfs_filesystem_show':
btrfs.c:2127:27: error: '%.*s' directive output between 0 and 2147483647 bytes
may exceed minimum required size of 4095 [-Werror=format-overflow=]
 2127 |   add_sprintf (&ret, "%.*s", (int) (end - p), p);
  |   ^~~~
btrfs.c:2127:26: note: assuming directive output of 1 byte
 2127 |   add_sprintf (&ret, "%.*s", (int) (end - p), p);
  |  ^~

log.c: In function 'do_log':
log.c:390:17: error: '%.*s' directive output between 0 and 2147483647 bytes may
exceed minimum required size of 4095 [-Werror=format-overflow=]
  390 |   printf (" %.*s", (int) comm_len, comm);
  | ^~~~
log.c:390:15: note: assuming directive output of 1 byte
  390 |   printf (" %.*s", (int) comm_len, comm);
  |   ^~~
log.c:388:17: error: '%.*s' directive output between 0 and 2147483647 bytes may
exceed minimum required size of 4095 [-Werror=format-overflow=]
  388 |   printf (" %.*s", (int) identifier_len, identifier);
  | ^~~~
log.c:388:15: note: assuming directive output of 1 byte
  388 |   printf (" %.*s", (int) identifier_len, identifier);
  |   ^~~
log.c:394:17: error: '%.*s' directive output between 0 and 2147483647 bytes may
exceed minimum required size of 4095 [-Werror=format-overflow=]
  394 |   printf ("[%.*s]", (int) pid_len, pid);
  | ^~~~
log.c:394:15: note: assuming directive output of 1 byte
  394 |   printf ("[%.*s]", (int) pid_len, pid);
  |   ^~~~
log.c:404:17: error: '%.*s' directive output between 0 and 2147483647 bytes may
exceed minimum required size of 4095 [-Werror=format-overflow=]
  404 |   printf (" %.*s", (int) message_len, message);
  | ^~~~
log.c:404:15: note: assuming directive output of 1 byte
  404 |   printf (" %.*s", (int) message_len, message);
  |   ^~~

../common/utils/utils.c: In function 'guestfs_int_full_path':
../common/utils/utils.c:729:27: error: '%.*s' directive output betw

[Bug driver/85142] Wrong -print-multi-os-directory & -print-multi-lib output for riscv64 + multilib

2018-03-31 Thread rjones at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85142

--- Comment #2 from Richard W.M. Jones  ---
The build log is here:
https://fedorapeople.org/groups/risc-v/logs/gcc-7.3.1-5.2.riscv64.fc28.src.rpm/build.log

Grep the log for "../configure" to see configure line(s).

[Bug target/85142] Wrong -print-multi-os-directory & -print-multi-lib output for riscv64 + multilib

2018-03-31 Thread rjones at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85142

--- Comment #5 from Richard W.M. Jones  ---
I'm not the original reporter but you could give us a few *minutes*
at least to resolve these questions by just asking.

The patch in question is this one.  (I didn't write it, it was written
by David the reporter.)

ff --git a/gcc/config/riscv/t-linux-multilib
b/gcc/config/riscv/t-linux-multilib
index 298547f..5f08626 100644
--- a/gcc/config/riscv/t-linux-multilib
+++ b/gcc/config/riscv/t-linux-multilib
@@ -20,27 +20,4 @@ rv64gc ilp32 \
 ilp32d \
 lp64 \
 lp64d
-MULTILIB_REQUIRED = march=rv32imac/mabi=ilp32 \
-march=rv32imafdc/mabi=ilp32d \
-march=rv64imac/mabi=lp64 \
-march=rv64imafdc/mabi=lp64d
-MULTILIB_REUSE = march.rv32imac/mabi.ilp32=march.rv32ima/mabi.ilp32 \
-march.rv32imac/mabi.ilp32=march.rv32imaf/mabi.ilp32 \
-march.rv32imac/mabi.ilp32=march.rv32imafd/mabi.ilp32 \
-march.rv32imac/mabi.ilp32=march.rv32imafc/mabi.ilp32 \
-march.rv32imac/mabi.ilp32=march.rv32imafdc/mabi.ilp32 \
-march.rv32imac/mabi.ilp32=march.rv32g/mabi.ilp32 \
-march.rv32imac/mabi.ilp32=march.rv32gc/mabi.ilp32 \
-march.rv32imafdc/mabi.ilp32d=march.rv32imafd/mabi.ilp32d \
-march.rv32imafdc/mabi.ilp32d=march.rv32gc/mabi.ilp32d \
-march.rv32imafdc/mabi.ilp32d=march.rv32g/mabi.ilp32d \
-march.rv64imac/mabi.lp64=march.rv64ima/mabi.lp64 \
-march.rv64imac/mabi.lp64=march.rv64imaf/mabi.lp64 \
-march.rv64imac/mabi.lp64=march.rv64imafd/mabi.lp64 \
-march.rv64imac/mabi.lp64=march.rv64imafc/mabi.lp64 \
-march.rv64imac/mabi.lp64=march.rv64imafdc/mabi.lp64 \
-march.rv64imac/mabi.lp64=march.rv64g/mabi.lp64 \
-march.rv64imac/mabi.lp64=march.rv64gc/mabi.lp64 \
-march.rv64imafdc/mabi.lp64d=march.rv64imafd/mabi.lp64d \
-march.rv64imafdc/mabi.lp64d=march.rv64gc/mabi.lp64d \
-march.rv64imafdc/mabi.lp64d=march.rv64g/mabi.lp64d
+MULTILIB_REQUIRED = march=rv64imafdc/mabi=lp64d

[Bug target/85142] Wrong -print-multi-os-directory & -print-multi-lib output for riscv64 + multilib

2018-03-31 Thread rjones at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85142

--- Comment #6 from Richard W.M. Jones  ---
The paste removed the "di" from "diff" but the patch is otherwise
as posted.

[Bug c/88270] -Wformat-XXX option for flagging %m

2018-11-29 Thread rjones at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88270

--- Comment #4 from Richard W.M. Jones  ---
FWIW I was testing:
gcc (FreeBSD Ports Collection) 7.3.0

$ cat test.c
#include 

int
main (int argc, char *argv[])
{
  printf ("%m\n");
  return 0;
}

$ gcc -Wformat test.c
(no warnings)

$ gcc -Wformat -Wpedantic test.c 
test.c: In function 'main':
test.c:6:13: warning: ISO C does not support the '%m' gnu_printf format
[-Wformat=]
   printf ("%m\n");
 ^

[Bug c/78665] New: Unexpected warning about "assuming signed overflow does not occur when simplifying conditional"

2016-12-03 Thread rjones at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78665

Bug ID: 78665
   Summary: Unexpected warning about "assuming signed overflow
does not occur when simplifying conditional"
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rjones at redhat dot com
  Target Milestone: ---

size_t seg_len;
//...
if (seg_len <= 4 || (seg_len & 3) != 0) {

gives:

handle.c: In function 'hivex_open':
handle.c:273:10: error: assuming signed overflow does not occur when
simplifying conditional [-Werror=strict-overflow]
   if (seg_len <= 4 || (seg_len & 3) != 0) {
  ^

The original code is:

https://github.com/libguestfs/hivex/blob/4b024fa031251fbeacb6ecf2821d8d027d59de0d/lib/handle.c#L273

$ gcc --version
gcc (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2)
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compilation command is:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../gnulib/lib -I../gnulib/lib
-I. -W -Wabi -Waddress -Waggressive-loop-optimizations -Wall -Wattributes
-Wbad-function-cast -Wbool-compare -Wbuiltin-macro-redefined -Wcast-align
-Wchar-subscripts -Wchkp -Wclobbered -Wcomment -Wcomments -Wcoverage-mismatch
-Wcpp -Wdate-time -Wdeprecated -Wdeprecated-declarations -Wdesignated-init
-Wdisabled-optimization -Wdiscarded-array-qualifiers -Wdiscarded-qualifiers
-Wdiv-by-zero -Wdouble-promotion -Wempty-body -Wendif-labels -Wenum-compare
-Wextra -Wformat-contains-nul -Wformat-extra-args -Wformat-nonliteral
-Wformat-security -Wformat-signedness -Wformat-y2k -Wformat-zero-length
-Wfree-nonheap-object -Wignored-qualifiers -Wimplicit
-Wimplicit-function-declaration -Wimplicit-int -Wincompatible-pointer-types
-Winit-self -Winline -Wint-conversion -Wint-to-pointer-cast
-Winvalid-memory-model -Winvalid-pch -Wlogical-not-parentheses -Wlogical-op
-Wmain -Wmaybe-uninitialized -Wmemset-transposed-args -Wmissing-braces
-Wmissing-declarations -Wmissing-field-initializers -Wmissing-include-dirs
-Wmissing-parameter-type -Wmissing-prototypes -Wmultichar -Wnarrowing
-Wnested-externs -Wnonnull -Wodr -Wold-style-declaration -Wold-style-definition
-Wopenmp-simd -Woverflow -Woverlength-strings -Woverride-init
-Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-sign
-Wpointer-to-int-cast -Wpragmas -Wreturn-local-addr -Wreturn-type
-Wsequence-point -Wshadow -Wshift-count-negative -Wshift-count-overflow
-Wsizeof-array-argument -Wsizeof-pointer-memaccess -Wstack-protector
-Wstrict-aliasing -Wstrict-overflow -Wstrict-prototypes
-Wsuggest-attribute=const -Wsuggest-attribute=format
-Wsuggest-attribute=noreturn -Wsuggest-final-methods -Wsuggest-final-types
-Wswitch -Wswitch-bool -Wswitch-default -Wsync-nand -Wtrampolines -Wtrigraphs
-Wtype-limits -Wuninitialized -Wunknown-pragmas -Wunsafe-loop-optimizations
-Wunused -Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-function
-Wunused-label -Wunused-local-typedefs -Wunused-macros -Wunused-parameter
-Wunused-result -Wunused-value -Wunused-variable -Wvarargs -Wvariadic-macros
-Wvector-operation-performance -Wvolatile-register-var -Wwrite-strings
-Warray-bounds=2 -Wnormalized=nfc -Wno-unused-parameter
-Wno-missing-field-initializers -Wno-logical-op -Wno-array-bounds
-fdiagnostics-show-option -Werror -g -O2 -MT libhivex_la-handle.lo -MD -MP -MF
.deps/libhivex_la-handle.Tpo -c handle.c  -fPIC -DPIC -o
.libs/libhivex_la-handle.o

[Bug c/78665] Unexpected warning about "assuming signed overflow does not occur when simplifying conditional"

2016-12-13 Thread rjones at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78665

--- Comment #2 from Richard W.M. Jones  ---
The code which calculates seg_len is surely quite interesting in that case:

  size_t seg_len = block_len (h, blkoff, &used);
  if (seg_len <= 4 || (seg_len & 3) != 0) {

The block_len function which is probably inlined is:

static inline size_t
block_len (hive_h *h, size_t blkoff, int *used)
{
  struct ntreg_hbin_block *block;
  block = (struct ntreg_hbin_block *) ((char *) h->addr + blkoff);

  int32_t len = le32toh (block->seg_len);
  if (len < 0) {
if (used) *used = 1;
len = -len;
  } else {
if (used) *used = 0;
  }

  return (size_t) len;
}

The original data format (a Windows NT registry) encodes a 32 bit block
length into every header, and negates this length field if the block is
marked as "used" (it's positive if the block is free).

I can't recall if converting int32_t -> (64 bit) size_t is safe or not.

[Bug middle-end/78665] Unexpected warning about "assuming signed overflow does not occur when simplifying conditional"

2016-12-19 Thread rjones at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78665

--- Comment #4 from Richard W.M. Jones  ---
Created attachment 40363
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40363&action=edit
handle.i

Preprocessed source.  The full command to produce this was:

gcc -DHAVE_CONFIG_H -I. -I.. -I../gnulib/lib -I../gnulib/lib -I. -W -Wabi
-Waddress -Waggressive-loop-optimizations -Wall -Wattributes
-Wbad-function-cast -Wbool-compare -Wbuiltin-macro-redefined -Wcast-align
-Wchar-subscripts -Wchkp -Wclobbered -Wcomment -Wcomments -Wcoverage-mismatch
-Wcpp -Wdate-time -Wdeprecated -Wdeprecated-declarations -Wdesignated-init
-Wdisabled-optimization -Wdiscarded-array-qualifiers -Wdiscarded-qualifiers
-Wdiv-by-zero -Wdouble-promotion -Wempty-body -Wendif-labels -Wenum-compare
-Wextra -Wformat-contains-nul -Wformat-extra-args -Wformat-nonliteral
-Wformat-security -Wformat-signedness -Wformat-y2k -Wformat-zero-length
-Wfree-nonheap-object -Wignored-qualifiers -Wimplicit
-Wimplicit-function-declaration -Wimplicit-int -Wincompatible-pointer-types
-Winit-self -Winline -Wint-conversion -Wint-to-pointer-cast
-Winvalid-memory-model -Winvalid-pch -Wlogical-not-parentheses -Wlogical-op
-Wmain -Wmaybe-uninitialized -Wmemset-transposed-args -Wmissing-braces
-Wmissing-declarations -Wmissing-field-initializers -Wmissing-include-dirs
-Wmissing-parameter-type -Wmissing-prototypes -Wmultichar -Wnarrowing
-Wnested-externs -Wnonnull -Wodr -Wold-style-declaration -Wold-style-definition
-Wopenmp-simd -Woverflow -Woverlength-strings -Woverride-init
-Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-sign
-Wpointer-to-int-cast -Wpragmas -Wreturn-local-addr -Wreturn-type
-Wsequence-point -Wshadow -Wshift-count-negative -Wshift-count-overflow
-Wsizeof-array-argument -Wsizeof-pointer-memaccess -Wstack-protector
-Wstrict-aliasing -Wstrict-overflow -Wstrict-prototypes
-Wsuggest-attribute=const -Wsuggest-attribute=format
-Wsuggest-attribute=noreturn -Wsuggest-final-methods -Wsuggest-final-types
-Wswitch -Wswitch-bool -Wswitch-default -Wsync-nand -Wtrampolines -Wtrigraphs
-Wtype-limits -Wuninitialized -Wunknown-pragmas -Wunsafe-loop-optimizations
-Wunused -Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-function
-Wunused-label -Wunused-local-typedefs -Wunused-macros -Wunused-parameter
-Wunused-result -Wunused-value -Wunused-variable -Wvarargs -Wvariadic-macros
-Wvector-operation-performance -Wvolatile-register-var -Wwrite-strings
-Warray-bounds=2 -Wnormalized=nfc -Wno-unused-parameter
-Wno-missing-field-initializers -Wno-logical-op -Wno-array-bounds
-fdiagnostics-show-option -Werror -g -O2 -MT libhivex_la-handle.lo -MD -MP -MF
.deps/libhivex_la-handle.Tpo -c handle.c  -fPIC -DPIC -o
.libs/libhivex_la-handle.o -save-temps

[Bug c/79546] New: Strange error: missed loop optimization, the loop counter may overflow [-Werror=unsafe-loop-optimizations]

2017-02-15 Thread rjones at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79546

Bug ID: 79546
   Summary: Strange error: missed loop optimization, the loop
counter may overflow
[-Werror=unsafe-loop-optimizations]
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rjones at redhat dot com
  Target Milestone: ---

#include 
#include 

int f (size_t len);

int
main (int argc, char *argv[])
{
  size_t len;

  if (argc < 2) abort ();
  if (sscanf (argv[1], "%zu", &len) != 1) abort ();

  f (len);

  exit (0);
}

int
f (size_t len)
{
  size_t i;

  i = 0;
  while (i < len) {
i += 0x1000;
printf ("page %zu\n", i);
  }
}
---

When compiled with:

$ gcc -O2 -Werror=unsafe-loop-optimizations test.c -o test
test.c: In function ‘main’:
test.c:25:9: error: missed loop optimization, the loop counter may overflow
[-Werror=unsafe-loop-optimizations]
   while (i < len) {
 ^
test.c: In function ‘f’:
test.c:25:9: error: missed loop optimization, the loop counter may overflow
[-Werror=unsafe-loop-optimizations]
   while (i < len) {
 ^
cc1: some warnings being treated as errors

---

What I don't understand is what the error means, nor how to correct it.

---

$ gcc --version
gcc (GCC) 7.0.1 20170204 (Red Hat 7.0.1-0.6)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

From Fedora 26.

[Bug c/79546] Strange error: missed loop optimization, the loop counter may overflow [-Werror=unsafe-loop-optimizations]

2017-02-16 Thread rjones at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79546

Richard W.M. Jones  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Richard W.M. Jones  ---
I think the warning is enabled by the build system.  It's not something we
enable explicitly.  Anyhow I have disabled it since it seems as if this warning
doesn't indicate a bug in the code.

[Bug other/63509] Misleading error message when building gcc without C++ compiler installed

2015-02-26 Thread rjones at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63509

Richard W.M. Jones  changed:

   What|Removed |Added

 CC||rjones at redhat dot com

--- Comment #3 from Richard W.M. Jones  ---
Can confirm this happens also on Fedora 23.
Installing gcc-c++ fixes it.

[Bug tree-optimization/48022] [4.6 Regression] -Wstrict-overflow warning on code that doesn't have overflows

2011-03-07 Thread rjones at redhat dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48022

--- Comment #1 from rjones at redhat dot com  
2011-03-07 16:51:14 UTC ---
Report on Fedora devel mailing list:
http://lists.fedoraproject.org/pipermail/devel/2011-March/thread.html#149342

[Bug analyzer/99716] New: -Wanalyzer-double-fclose when fclose is called inside a loop

2021-03-22 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99716

Bug ID: 99716
   Summary: -Wanalyzer-double-fclose when fclose is called inside
a loop
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: rjones at redhat dot com
  Target Milestone: ---

This seems pretty bogus to me:

#include 
#include 

int
main ()
{
  int i;

  for (i = 0; i < 2; ++i) {
FILE *fp = fopen ("/tmp/test", "w");
fprintf (fp, "hello");
fclose (fp);
  }
  exit (EXIT_SUCCESS);
}

$ gcc -O2 -fanalyzer /tmp/fclose-loop.c -o /tmp/fclose-loop
/tmp/fclose-loop.c: In function ‘main’:
/tmp/fclose-loop.c:12:5: warning: double ‘fclose’ of FILE ‘fp’
[-Wanalyzer-double-fclose]
   12 | fclose (fp);
  | ^~~
  ‘main’: events 1-7
|
|9 |   for (i = 0; i < 2; ++i) {
|  |   ~~^~~
|  | |
|  | (1) following ‘true’ branch (when ‘i != 2’)...
|  | (5) following ‘true’ branch (when ‘i != 2’)...
|   10 | FILE *fp = fopen ("/tmp/test", "w");
|  |
|  ||
|  |(2) ...to here
|  |(3) opened here
|  |(6) ...to here
|   11 | fprintf (fp, "hello");
|   12 | fclose (fp);
|  | ~~~  
|  | |
|  | (4) first ‘fclose’ here
|  | (7) second ‘fclose’ here; first ‘fclose’ was at (4)

This is with:
gcc-11.0.0-0.19.fc35.x86_64

I do not have any later version of GCC to test, but also I don't see any
other bug about this.

[Bug analyzer/99716] -Wanalyzer-double-fclose when fclose is called inside a loop

2021-03-23 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99716

--- Comment #3 from Richard W.M. Jones  ---
FYI the original code is:
https://github.com/libguestfs/libguestfs/blob/e0a11061035d47b118c95706240bcc17fd576edc/tests/mount-local/test-parallel-mount-local.c#L299-L335

[Bug c/99193] New: Bogus "should have been deallocated with 'free' but was deallocated with 'realloc' [CWE-762] [-Werror=analyzer-mismatching-deallocation]"

2021-02-22 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193

Bug ID: 99193
   Summary: Bogus "should have been deallocated with 'free' but
was deallocated with 'realloc' [CWE-762]
[-Werror=analyzer-mismatching-deallocation]"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
      Reporter: rjones at redhat dot com
  Target Milestone: ---

https://github.com/libguestfs/libguestfs/blob/f19fd566f6387ce7e4d82409528c9dde374d25e0/daemon/command.c#L115

This fails to compile with:
gcc -DHAVE_CONFIG_H -I. -I..  -DCAML_NAME_SPACE -I/usr/lib64/ocaml
-I/usr/lib64/ocaml/hivex -I../gnulib/lib -I../gnulib/lib -I../lib -I../lib
-I../common/errnostring -I../common/errnostring -I../common/protocol
-I../common/protocol -I../common/utils -I../common/utils  -fanalyzer
-fno-common -Wall -Warith-conversion -Wbad-function-cast -Wcast-align=strict
-Wdate-time -Wdisabled-optimization -Wdouble-promotion -Wduplicated-branches
-Wduplicated-cond -Wextra -Wformat-signedness -Winit-self -Winvalid-pch
-Wlogical-op -Wmissing-declarations -Wmissing-include-dirs -Wmissing-prototypes
-Wnested-externs -Wnull-dereference -Wold-style-definition -Wopenmp-simd
-Wpointer-arith -Wstrict-overflow -Wstrict-prototypes -Wsuggest-attribute=cold
-Wsuggest-attribute=format -Wsuggest-attribute=noreturn -Wsuggest-final-methods
-Wsuggest-final-types -Wsync-nand -Wtrampolines -Wuninitialized
-Wunknown-pragmas -Wunused-macros -Wvariadic-macros
-Wvector-operation-performance -Wwrite-strings -Warray-bounds=2
-Wattribute-alias=2 -Wformat-overflow=2 -Wformat=2 -Wformat-truncation=2
-Wimplicit-fallthrough=5 -Wshift-overflow=2 -Wunused-const-variable=2
-Wno-analyzer-double-free -Wno-analyzer-malloc-leak
-Wno-analyzer-null-dereference -Wno-analyzer-use-after-free
-Wno-unused-parameter -Wno-missing-field-initializers -fdiagnostics-show-option
-Wframe-larger-than=6000 -Wstack-usage=1 -Wimplicit-fallthrough=4
-Wformat-truncation=1 -Wformat-overflow=1 -Wno-pragmas -Werror
-I/usr/include/tirpc  -I/usr/include/libxml2  -O2 -g -fPIC
-fno-strict-overflow -Wno-strict-overflow -MT guestfsd-command.o -MD -MP -MF
.deps/guestfsd-command.Tpo -c -o guestfsd-command.o `test -f 'command.c' ||
echo './'`command.c

command.c: In function ‘commandrf’:
command.c:136:22: error: ‘argv’ should have been deallocated with ‘free’ but
was deallocated with ‘realloc’ [CWE-762]
[-Werror=analyzer-mismatching-deallocation]
  136 | const char **p = realloc (argv, sizeof (char *) * (++i));
  |  ^~~
  ‘commandrf’: events 1-4
|
|  125 |   argv = malloc (sizeof (char *) * i);
|  |  ^~~~
|  |  |
|  |  (1) allocated here (expects deallocation with ‘free’)
|  126 |   if (argv == NULL) {
|  |  ~
|  |  |
|  |  (2) assuming ‘argv’ is non-NULL
|  |  (3) following ‘false’ branch...
|..
|  130 |   argv[0] = (char *) name;
|  |   
|  |   |
|  |   (4) ...to here
|
  ‘commandrf’: events 5-7
|
|  135 |   while ((s = va_arg (args, char *)) != NULL) {
|  |  ^
|  |  |
|  |  (5) following ‘true’ branch
(when ‘s’ is non-NULL)...
|  136 | const char **p = realloc (argv, sizeof (char *) * (++i));
|  | ~~~~
|  | ||
|  | |(7) deallocated with ‘realloc’ here;
allocation at (1) expects deallocation with ‘free’
|  | (6) ...to here
|
cc1: all warnings being treated as errors
make[1]: *** [Makefile:3261: guestfsd-command.o] Error 1

This error appears to be bogus.

argv has __attribute__((cleanup)) which will call free(3) on return
paths out of the function, such as realloc failing.  If realloc
is successful then the old argv is freed and the new allocation
is assigned to argv.

[Bug c/99193] Bogus "should have been deallocated with 'free' but was deallocated with 'realloc' [CWE-762] [-Werror=analyzer-mismatching-deallocation]"

2021-02-22 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193

--- Comment #1 from Richard W.M. Jones  ---
Created attachment 50232
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50232&action=edit
preprocessed source (xz compressed)

[Bug c/99193] Bogus "should have been deallocated with 'free' but was deallocated with 'realloc' [CWE-762] [-Werror=analyzer-mismatching-deallocation]"

2021-02-22 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193

Richard W.M. Jones  changed:

   What|Removed |Added

Version|unknown |11.0

--- Comment #2 from Richard W.M. Jones  ---
Version of GCC:

gcc-11.0.0-0.19.fc35.x86_64

[Bug c/99193] Bogus "should have been deallocated with 'free' but was deallocated with 'realloc' [CWE-762] [-Werror=analyzer-mismatching-deallocation]"

2021-02-22 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193

--- Comment #3 from Richard W.M. Jones  ---
This seems to be the same thing at a different place in the code:

https://github.com/libguestfs/libguestfs/blob/f19fd566f6387ce7e4d82409528c9dde374d25e0/df/main.c#L404

  CC   virt_df-main.o
main.c: In function 'make_display_name':
main.c:404:11: error: 'ret' should have been deallocated with 'free' but was
deallocated with 'realloc' [CWE-762]
[-Werror=analyzer-mismatching-deallocation]
  404 | ret = realloc (ret, len + pluses + 1);
  |   ^~~
  'make_display_name': event 1
|
|  378 | make_display_name (struct drv *drvs)
|  | ^
|  | |
|  | (1) entry to 'make_display_name'
|
  'make_display_name': event 2
|
|  382 |   assert (drvs != NULL);
|  |   ^~
|  |   |
|  |   (2) following 'true' branch (when 'drvs' is non-NULL)...
|
  'make_display_name': events 3-4
|
|  385 |   if (drvs->next == NULL)
|  |   ^~ ~
|  |   |  |
|  |   |  (4) following 'false' branch...
|  |   (3) ...to here
|
  'make_display_name': event 5
|
|cc1:
| (5): ...to here
|
  'make_display_name': events 6-8
|
|  396 | while (drvs->next != NULL) {
|  |   ^
|  |   |
|  |   (6) following 'true' branch...
|  397 |   drvs = drvs->next;
|  |    
|  |   |
|  |   (7) ...to here
|..
|  401 | ret = single_drive_display_name (drvs);
|  |   
|  |   |
|  |   (8) calling 'single_drive_display_name' from
'make_display_name'
|
+--> 'single_drive_display_name': event 9
   |
   |  322 | single_drive_display_name (struct drv *drvs)
   |  | ^
   |  | |
   |  | (9) entry to 'single_drive_display_name'
   |
 'single_drive_display_name': event 10
   |
   |  327 |   assert (drvs != NULL);
   |  |   ^~
   |  |   |
   |  |   (10) following 'true' branch (when 'drvs' is non-NULL)...
   |
 'single_drive_display_name': event 11
   |
   |  328 |   assert (drvs->next == NULL);
   |  |   ^~
   |  |   |
   |  |   (11) ...to here
   |
 'single_drive_display_name': event 12
   |
   |  328 |   assert (drvs->next == NULL);
   |  |   ^~
   |  |   |
   |  |   (12) following 'true' branch...
   |
 'single_drive_display_name': events 13-19
   |
   |  330 |   switch (drvs->type) {
   |  |   ^~
   |  |   |
   |  |   (13) ...to here
   |  |   (14) following 'case 1:' branch...
   |..
   |  342 |   case drv_uri:
   |  |   
   |  |   |
   |  |   (15) ...to here
   |  343 | name = strdup (drvs->uri.orig_uri);
   |  344 | if (name == NULL)
   |  |~
   |  ||
   |  |(16) following 'false' branch (when 'name' is
non-NULL)...
   |..
   |  349 | p = strrchr (name, '/');
   |  | ~
   |  | |
   |  | (17) ...to here
   |..
   |  370 |   if (!name)
   |  |  ~
   |  |  |
   |  |  (18) following 'false' branch (when 'name' is
non-NULL)...
   |..
   |  373 |   return name;
   |  |   ~~
   |  |   |
   |  |   (19) ...to here
   |
<--+
|
  'make_display_name': events 20-21
|
|  401 | ret = single_drive_display_name (drvs);
|  |   ^~~~
|  |   |
|  |   (20) returning to 'make_display_name' from
'single_drive_display_name'
|..
|  404 | ret = realloc (ret, len + pluses + 1);
|  |   ~~~
|  |   |
|  |   (21) deallocated with 'realloc' here
|
cc1: all warnings being treated as errors

[Bug c/99196] New: GCC analyzer doesn't know that error (code != 0, ...) exits the program

2021-02-22 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99196

Bug ID: 99196
   Summary: GCC analyzer doesn't know that error (code != 0, ...)
exits the program
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rjones at redhat dot com
  Target Milestone: ---

https://github.com/libguestfs/libguestfs/blob/f19fd566f6387ce7e4d82409528c9dde374d25e0/daemon/tar.c#L108

tar.c: In function 'read_error_file':
tar.c:113:11: error: use of NULL 'str' where non-null expected [CWE-476]
[-Werror=analyzer-null-argument]
  113 | len = strlen (str);
  |   ^~~~
  'read_error_file': events 1-7
|
|  109 |   if (str == NULL) {
|  |  ^
|  |  |
|  |  (1) following 'true' branch (when 'str' is NULL)...
|  110 | str = strdup ("(no error)");
|  | ~~~   ~
|  | | |
|  | | (3) allocated here
|  | (2) ...to here
|  111 | if (str == NULL)
|  |~
|  ||
|  |(4) assuming 'str' is NULL
|  |(5) following 'true' branch (when 'str' is NULL)...
|  112 |   error (EXIT_FAILURE, errno, "strdup"); /* XXX */
|  |   ~
|  |   |
|  |   (6) ...to here
|  113 | len = strlen (str);
|  |   
|  |   |
|  |   (7) argument 1 ('str') NULL where non-null expected
|
In file included from ../gnulib/lib/string.h:41,
 from tar.c:23:
/usr/include/string.h:391:15: note: argument 1 of 'strlen' must be non-null
  391 | extern size_t strlen (const char *__s)
  |   ^~
cc1: all warnings being treated as errors

In the original code if str == NULL, error (EXIT_FAILURE, ...) is
called which exits the program.  Therefore strlen (NULL) cannot
be called so the warning is bogus.

https://www.man7.org/linux/man-pages/man3/error.3.html

   "If status has a nonzero value, then error() calls exit(3) to
   terminate the program using the given value as the exit status."

gcc-11.0.0-0.19.fc35.x86_64

[Bug c/99193] Bogus "should have been deallocated with 'free' but was deallocated with 'realloc' [CWE-762] [-Werror=analyzer-mismatching-deallocation]"

2021-02-22 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193

--- Comment #4 from Richard W.M. Jones  ---
And another:
https://github.com/libguestfs/libguestfs/blob/f19fd566f6387ce7e4d82409528c9dde374d25e0/daemon/debug.c#L115

debug.c: In function 'debug_help':
debug.c:129:9: error: 'r' should have been deallocated with 'free' but was
deallocated with 'realloc' [CWE-762]
[-Werror=analyzer-mismatching-deallocation]
  129 | p = realloc (r, len + 1);/* +1 for the final NUL */
  | ^~~~
  'debug_help': events 1-4
|
|  120 |   r = strdup ("Commands supported:");
|  |   ^~
|  |   |
|  |   (1) allocated here (expects deallocation with 'free')
|  121 |   if (!r) {
|  |  ~ 
|  |  |
|  |  (2) assuming 'r' is non-NULL
|  |  (3) following 'false' branch (when 'r' is non-NULL)...
|..
|  126 |   len = strlen (r);
|  |   ~~~  
|  |   |
|  |   (4) ...to here
|
  'debug_help': events 5-7
|
|  127 |   for (i = 0; cmds[i].cmd != NULL; ++i) {
|  |   ^
|  |   |
|  |   (5) following 'true' branch...
|  128 | len += strlen (cmds[i].cmd) + 1; /* space + new command */
|  | ~~~
|  | |
|  | (6) ...to here
|  129 | p = realloc (r, len + 1);/* +1 for the final NUL */
|  | 
|  | |
|  | (7) deallocated with 'realloc' here; allocation at (1)
expects deallocation with 'free'
|
cc1: all warnings being treated as errors

[Bug analyzer/99196] GCC analyzer doesn't know that error (code != 0, ...) exits the program

2021-02-22 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99196

--- Comment #3 from Richard W.M. Jones  ---
Note if errcode == 0 then error does NOT exit :-)

[Bug analyzer/99193] Bogus "should have been deallocated with 'free' but was deallocated with 'realloc' [CWE-762] [-Werror=analyzer-mismatching-deallocation]"

2021-02-25 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193

--- Comment #10 from Richard W.M. Jones  ---
Great stuff, I'll give this a go when GCC is updated
in Fedora Rawhide.

[Bug analyzer/99193] Bogus "should have been deallocated with 'free' but was deallocated with 'realloc' [CWE-762] [-Werror=analyzer-mismatching-deallocation]"

2021-02-25 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193

--- Comment #12 from Richard W.M. Jones  ---
There are quite a lot of these - I will try removing them
when we get the updated GCC in Fedora.

[Bug sanitizer/104158] [12 Regression] gcc no longer accepts -fsanitize-coverage=trace-pc,trace-cmp since r12-1177

2022-01-21 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104158

Richard W.M. Jones  changed:

   What|Removed |Added

 CC||rjones at redhat dot com

--- Comment #2 from Richard W.M. Jones  ---
Used by honggfuzz here:

https://github.com/google/honggfuzz/blob/master/hfuzz_cc/hfuzz-cc.c#L375

(Worked in GCC up to 11)

[Bug target/103395] [9/10/11/12 Regression] ICE on qemu in arm create_fix_barrier

2021-11-23 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103395

--- Comment #1 from Richard W.M. Jones  ---
Nice reproducer!

Here's the original thread where the bug was reported when compiling qemu on
Fedora Rawhide for armv7:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/GD3ABSWD6HHTNEKV2EJY4PXABQ245UCZ/

[Bug analyzer/99260] analyzer does not track outcomes of realloc

2021-08-31 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99260

--- Comment #6 from Richard W.M. Jones  ---
That's excellent news, thanks.  We'll get around to trying this
when GCC 12 appears in Rawhide.

[Bug analyzer/102233] New: Compiling a smallish binary with -fanalyzer seems to cause very very long compile times

2021-09-07 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102233

Bug ID: 102233
   Summary: Compiling a smallish binary with -fanalyzer seems to
cause very very long compile times
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: rjones at redhat dot com
  Target Milestone: ---

This is not so simple to reproduce.  It starts with checking out:

https://github.com/libguestfs/libguestfs

and compiling it.  On Fedora, following the instructions here:

https://libguestfs.org/guestfs-building.1.html#short-cut-for-fedora-or-red-hat-enterprise-linux-rhel-users

# dnf builddep libguestfs
# dnf install autoconf automake libtool gettext-devel

$ git clone https://github.com/libguestfs/libguestfs
$ git submodule update --init
$ autoreconf -i
$ ./configure CFLAGS=-fPIC
$ make

The thing which fails to compile is a unit test in lib/:

$ make -C lib clean
$ make -C lib
$ make -C lib unit-tests CFLAGS="-O2 -g -fanalyzer" V=1

For me this takes a very long time linking the unit-tests binary:

gcc -DHAVE_CONFIG_H -I. -I..  -I../gnulib/lib -I../gnulib/lib -I../common/utils
-I../common/utils -I../common/structs -I../common/structs -I../lib -I../include
-I.  -Wall -Werror -I/usr/include/tirpc  -O2 -g -fanalyzer -MT
unit_tests-unit-tests.o -MD -MP -MF .deps/unit_tests-unit-tests.Tpo -c -o
unit_tests-unit-tests.o `test -f 'unit-tests.c' || echo './'`unit-tests.c
mv -f .deps/unit_tests-unit-tests.Tpo .deps/unit_tests-unit-tests.Po
bash ../libtool-kill-dependency_libs.sh ../libtool  --tag=CC   --mode=link gcc
-Wall -Werror -I/usr/include/tirpc  -O2 -g -fanalyzer  -Wl,-z,relro
-Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld  -o
unit-tests unit_tests-unit-tests.o ../common/structs/libstructs.la
../common/utils/libutils.la libguestfs_la-actions-0.lo
libguestfs_la-actions-1.lo libguestfs_la-actions-2.lo
libguestfs_la-actions-3.lo libguestfs_la-actions-4.lo
libguestfs_la-actions-5.lo libguestfs_la-actions-6.lo
libguestfs_la-actions-support.lo libguestfs_la-actions-variants.lo
libguestfs_la-alloc.lo libguestfs_la-appliance.lo
libguestfs_la-appliance-cpu.lo libguestfs_la-appliance-kcmdline.lo
libguestfs_la-appliance-uefi.lo libguestfs_la-available.lo
libguestfs_la-bindtests.lo libguestfs_la-canonical-name.lo
libguestfs_la-command.lo libguestfs_la-conn-socket.lo
libguestfs_la-copy-in-out.lo libguestfs_la-create.lo libguestfs_la-drives.lo
libguestfs_la-errors.lo libguestfs_la-event-string.lo libguestfs_la-events.lo
libguestfs_la-file.lo libguestfs_la-fuse.lo libguestfs_la-guid.lo
libguestfs_la-handle.lo libguestfs_la-info.lo libguestfs_la-inspect-apps.lo
libguestfs_la-inspect-icon.lo libguestfs_la-inspect-osinfo.lo
libguestfs_la-journal.lo libguestfs_la-launch.lo libguestfs_la-launch-direct.lo
libguestfs_la-launch-libvirt.lo libguestfs_la-launch-uml.lo
libguestfs_la-launch-unix.lo libguestfs_la-libvirt-auth.lo
libguestfs_la-libvirt-domain.lo libguestfs_la-lpj.lo libguestfs_la-match.lo
libguestfs_la-mountable.lo libguestfs_la-private-data.lo libguestfs_la-proto.lo
libguestfs_la-qemu.lo libguestfs_la-rescue.lo libguestfs_la-stringsbuf.lo
libguestfs_la-structs-compare.lo libguestfs_la-structs-copy.lo
libguestfs_la-structs-free.lo libguestfs_la-tmpdirs.lo libguestfs_la-tsk.lo
libguestfs_la-uefi.lo libguestfs_la-umask.lo libguestfs_la-version.lo
libguestfs_la-wait.lo libguestfs_la-whole-file.lo libguestfs_la-yara.lo
../common/errnostring/liberrnostring.la ../common/protocol/libprotocol.la
../common/qemuopts/libqemuopts.la ../common/structs/libstructs.la
../common/utils/libutils.la -lpcre2-8  -lvirt  -lxml2  -lselinux -ljansson 
../gnulib/lib/libgnu.la -ltirpc  -lfuse -pthread  
libtool: link: gcc -Wall -Werror -I/usr/include/tirpc -O2 -g -fanalyzer -Wl,-z
-Wl,relro -Wl,--as-needed -Wl,-z -Wl,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o unit-tests
unit_tests-unit-tests.o .libs/libguestfs_la-actions-0.o
.libs/libguestfs_la-actions-1.o .libs/libguestfs_la-actions-2.o
.libs/libguestfs_la-actions-3.o .libs/libguestfs_la-actions-4.o
.libs/libguestfs_la-actions-5.o .libs/libguestfs_la-actions-6.o
.libs/libguestfs_la-actions-support.o .libs/libguestfs_la-actions-variants.o
.libs/libguestfs_la-alloc.o .libs/libguestfs_la-appliance.o
.libs/libguestfs_la-appliance-cpu.o .libs/libguestfs_la-appliance-kcmdline.o
.libs/libguestfs_la-appliance-uefi.o .libs/libguestfs_la-available.o
.libs/libguestfs_la-bindtests.o .libs/libguestfs_la-canonical-name.o
.libs/libguestfs_la-command.o .libs/libguestfs_la-conn-socket.o
.libs/libguestfs_la-copy-in-out.o .libs/libguestfs_la-create.o
.libs/libguestfs_la-drives.o .libs/libguestfs_la-errors.o
.libs/libguestfs_la-event-string.o .libs/libguestfs_la-events.o
.libs/libguestfs_la-file.o .libs/libguestfs_la-fuse.o
.libs/libguestfs_la-guid.o .lib

[Bug analyzer/102233] Compiling a smallish binary with -fanalyzer seems to cause very very long compile times

2021-09-07 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102233

--- Comment #1 from Richard W.M. Jones  ---
perf top shows:

  36.63%  lto1   [.] shortest_paths::shortest_paths

which it pretty much stuck permanently at 30-50% CPU.  The
machine has plenty of free memory and is not swapping.

The stack trace is:

#0  0x00d0b377 in shortest_paths::shortest_paths (this=, graph=...,
given_node=, sense=, this=,
graph=..., given_node=, sense=) at
../../gcc/shortest-paths.h:120
#1  0x00d0b8db in ana::epath_finder::explore_feasible_paths
(this=this@entry=0x7fffbfd72130, target_enode=target_enode@entry=0x49007ac0,
desc=desc@entry=0x18e81d6 "malloc_leak", diag_idx=diag_idx@entry=602) at
../../gcc/analyzer/diagnostic-manager.cc:349
#2  0x00d0bc1c in ana::epath_finder::get_best_epath
(this=this@entry=0x7fffbfd72130, enode=0x49007ac0, desc=0x18e81d6
"malloc_leak", diag_idx=diag_idx@entry=602,
out_problem=out_problem@entry=0x48f9dea0) at
../../gcc/analyzer/diagnostic-manager.cc:160
#3  0x00d0be22 in ana::saved_diagnostic::calc_best_epath
(this=this@entry=0x48f9de40, pf=pf@entry=0x7fffbfd72130) at
../../gcc/analyzer/diagnostic-manager.cc:685
#4  0x00d0c046 in ana::dedupe_winners::add (sd=0x48f9de40,
pf=0x7fffbfd72130, logger=, this=0x7fffbfd72170) at
../../gcc/analyzer/diagnostic-manager.cc:979
#5  ana::diagnostic_manager::emit_saved_diagnostics (this=0x7fffbfd724a0,
eg=...) at ../../gcc/analyzer/diagnostic-manager.cc:1096
#6  0x00a9ea51 in ana::impl_run_checkers (logger=) at
../../gcc/analyzer/exploded-graph.h:813
#7  0x00a9f143 in ana::run_checkers () at
../../gcc/analyzer/analyzer-logging.h:150
#8  0x00a6f7a6 in (anonymous namespace)::pass_analyzer::execute
(this=) at ../../gcc/analyzer/analyzer-pass.cc:87
#9  0x00e13ba9 in execute_one_pass (pass=0x2e3f540) at
../../gcc/passes.c:2567
#10 0x0127aa6b in execute_ipa_pass_list (pass=0x2e3f540) at
../../gcc/passes.c:2996
#11 0x01268538 in do_whole_program_analysis () at
../../gcc/lto/lto.c:469
#12 lto_main () at ../../gcc/lto/lto.c:637
#13 0x01264952 in compile_file () at ../../gcc/toplev.c:460
#14 0x0122aa1c in do_compile () at ../../gcc/toplev.c:2204
#15 toplev::main (this=this@entry=0x7fffbfd731ee, argc=,
argv=) at ../../gcc/toplev.c:2345
#16 0x01229d90 in main (argc=, argv=) at
../../gcc/main.c:39

[Bug analyzer/102233] Compiling a smallish binary with -fanalyzer seems to cause very very long compile times

2021-09-07 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102233

--- Comment #2 from Richard W.M. Jones  ---
I think since this seems to be LTO-related, you probably do need
to use LTO CFLAGS in the initial ./configure step.  My actual CFLAGS
were:

export CFLAGS="$(rpm --eval '%{optflags}')"
export CXXFLAGS="$(rpm --eval '%{optflags}')"
export LDFLAGS="$(rpm --eval '%{__global_ldflags}')"

which on current Fedora will use LTO.

[Bug analyzer/102233] LTO with -fanalyzer on a smallish binary causes very very long compile times

2021-09-07 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102233

--- Comment #5 from Richard W.M. Jones  ---
(In reply to David Malcolm from comment #4)
> (In reply to Richard W.M. Jones from comment #2)
> > I think since this seems to be LTO-related, you probably do need
> > to use LTO CFLAGS in the initial ./configure step.  My actual CFLAGS
> > were:
> > 
> > export CFLAGS="$(rpm --eval '%{optflags}')"
> > export CXXFLAGS="$(rpm --eval '%{optflags}')"
> > export LDFLAGS="$(rpm --eval '%{__global_ldflags}')"
> 
> For reference, what were the flags, specifically?  Thanks.

$ echo $CFLAGS 
-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection

$ echo $CXXFLAGS 
-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection

$ echo $LDFLAGS 
-Wl,-z,relro -Wl,--as-needed -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld

[Bug go/114699] New: gcc-go -buildmode=c-shared doesn't use -Wl,-z,nodelete so libraries crash when dlclosed

2024-04-11 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114699

Bug ID: 114699
   Summary: gcc-go -buildmode=c-shared doesn't use -Wl,-z,nodelete
so libraries crash when dlclosed
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: rjones at redhat dot com
  Target Milestone: ---

I was chasing a crash in nbdkit-golang-plugin
(https://gitlab.com/nbdkit/nbdkit/-/tree/master/plugins/golang?ref_type=heads).

This crash only happens with gcc-go (and quite reproducibly), but doesn't
happen with golang.  The crash happened when the plugin was being unloaded
with dlclose(3).

Long story short, this is a bug that has already been reported and "fixed"
(or more accurately, worked around) in golang:

https://github.com/golang/go/issues/11100

Because goroutines, the garbage collector, etc is basically running all
the time in golang programs, you cannot safely remove them from memory.
Any attempt to actually dlclose a golang plugin will crash most of the
time when a goroutine/the GC executes some code after dlclose.

golang works around this by linking shared libraries it creates with
-Wl,-z,nodelete:

https://github.com/golang/go/blob/1843464f014c946c1663de76249267486887626f/src/cmd/link/internal/ld/lib.go#L1587

Because gcc-go doesn't do this, the same shared libraries crash when
compiled with it.

Fix (or workaround) is probably to copy what golang does.

[Bug go/114699] gcc-go -buildmode=c-shared doesn't use -Wl,-z,nodelete so libraries crash when dlclosed

2024-04-11 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114699

--- Comment #1 from Richard W.M. Jones  ---
gcc 14.0.1-0.13.fc40 => crashes
golang-bin-1.22.2-1.fc40.x86_64 => works

I also checked this by stracing the linking process and
seeing -Wl,-z,nodelete is being used by golang, but not by
gcc-go.

[Bug go/114699] gcc-go -buildmode=c-shared doesn't use -Wl,-z,nodelete so libraries crash when dlclosed

2024-04-11 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114699

--- Comment #2 from Richard W.M. Jones  ---
This was the stack trace of the crashing thread with gcc-go:

Thread 7 (Thread 0x7ff5c1af3a40 (LWP 2819340)):
#0  0x7ff5c24d67cb in __GI_munmap () at
../sysdeps/unix/syscall-template.S:117
#1  0x7ff5c24c916a in _dl_unmap_segments (l=0x563fc0eba080) at
./dl-unmap-segments.h:32
#2  _dl_unmap (map=map@entry=0x563fc0eba080) at ../sysdeps/x86_64/tlsdesc.c:31
#3  0x7ff5c24b5ff5 in _dl_close_worker (map=,
map@entry=0x563fc0eb9a90, force=force@entry=false) at dl-close.c:628
#4  0x7ff5c24b663b in _dl_close (_map=0x563fc0eb9a90) at dl-close.c:793
#5  0x7ff5c24b5523 in __GI__dl_catch_exception
(exception=exception@entry=0x7fffe1bbd500, operate=0x7ff5c24b6600 <_dl_close>,
args=0x563fc0eb9a90) at dl-catch.c:237
#6  0x7ff5c24b5679 in _dl_catch_error (objname=0x7fffe1bbd568,
errstring=0x7fffe1bbd570, mallocedp=0x7fffe1bbd567, operate=,
args=) at dl-catch.c:256
#7  0x7ff5c20a4913 in _dlerror_run (operate=,
args=) at dlerror.c:138
#8  0x7ff5c20a4656 in __dlclose (handle=) at dlclose.c:31
#9  0x563fb3951239 in backend_unload (b=b@entry=0x563fc0ebbf60,
unload=0x7ff5c1ae43b0) at /home/rjones/d/nbdkit/server/backend.c:154
#10 0x563fb39512bc in plugin_free (b=0x563fc0ebbf60) at
/home/rjones/d/nbdkit/server/plugins.c:64
#11 0x563fb394ed51 in main (argc=, argv=) at
/home/rjones/d/nbdkit/server/main.c:838

[Bug go/114699] gcc-go -buildmode=c-shared doesn't use -Wl,-z,nodelete so libraries crash when dlclosed

2024-04-11 Thread rjones at redhat dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114699

--- Comment #3 from Richard W.M. Jones  ---
(Edit comment 2: To be clear, that wasn't the thread where the
segfault occurred, which was some golang thread, that was the
thread that was unmapping the memory at the same time.  Using
nodelete avoids this by not actually unmapping the code.)