[Bug c/106757] New: Incorrect "writing 1 byte into a region of size 0" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106757
Bug ID: 106757
Summary: Incorrect "writing 1 byte into a region of size 0"
warning
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jonathan.leffler at gmail dot com
Target Milestone: ---
Created attachment 53515
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53515&action=edit
Source code (gcc-bug.c) for the repro
GCC 11.2.0 is happy with this code (and I believe it is correct). Neither GCC
12.1.0 nor GCC 12.2.0 are happy with this code (and I believe this is a bug).
There are no preprocessor directives in the source code.
$ /usr/gcc/v12.2.0/bin/gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/work1/gcc/v12.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-12.2.0/configure --prefix=/usr/gcc/v12.2.0
CC=/usr/bin/gcc CXX=/usr/bin/g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (GCC)
$
Compilation:
$ /usr/gcc/v11.2.0/bin/gcc -c -std=c99 -O3 -Wall -Werror -pedantic -Wextra
gcc-bug.c
$ /usr/gcc/v12.2.0/bin/gcc -c -std=c99 -O3 -Wall -Werror -pedantic -Wextra
gcc-bug.c
gcc-bug.c: In function ‘pqr_scanner’:
gcc-bug.c:16:24: error: writing 1 byte into a region of size 0
[-Werror=stringop-overflow=]
16 | tmpchar[k] = mbs[k];
| ~~~^~~~
gcc-bug.c:14:14: note: at offset 4 into destination object ‘tmpchar’ of size 4
14 | char tmpchar[MBC_MAX];
| ^~~
gcc-bug.c:16:24: error: writing 1 byte into a region of size 0
[-Werror=stringop-overflow=]
16 | tmpchar[k] = mbs[k];
| ~~~^~~~
gcc-bug.c:14:14: note: at offset 5 into destination object ‘tmpchar’ of size 4
14 | char tmpchar[MBC_MAX];
| ^~~
cc1: all warnings being treated as errors
$
The -Wall, -Wextra, -pedantic options are not necessary to generate the
warning; the -Werror gives an error instead of a warning, of course.
$ cat gcc-bug.i
# 0 "gcc-bug.c"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "gcc-bug.c"
enum { MBC_MAX = 4 };
extern int pqr_scanner(char *mbs);
extern int pqr_mbc_len(char *mbs, int n);
extern void pqr_use_mbs(const char *mbs, int len);
extern char *pqr_mbs_nxt(char *mbs);
int
pqr_scanner(char *mbs)
{
while (mbs != 0 && *mbs != '\0')
{
int len = pqr_mbc_len(mbs, MBC_MAX);
char tmpchar[MBC_MAX];
for (int k = 0; k < len; k++)
tmpchar[k] = mbs[k];
pqr_use_mbs(tmpchar, len);
mbs = pqr_mbs_nxt(mbs);
}
return 0;
}
$
The source code contains a comment noting that if I replace `mbs =
pqr_nbs_nxt(mbs);` with `mbs += len;`, the bug does not reproduce.
In the original code (which was doing work with multi-byte characters and
strings), the analogue of pqr_mbc_len() returns either -1 or a value
1..MBC_MAX.The code for the pqr_mbc_len() function was not part of the TU.
There was a test for `if (len < 0) return -1;` after the call to pqr_mbc_len()
but it wasn't needed for the repro.
Just in case - GCC 11.2.0 specs and output from uname -a:
$ /usr/gcc/v11.2.0/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/gcc/v11.2.0/bin/gcc
COLLECT_LTO_WRAPPER=/work1/gcc/v11.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-11.2.0/configure --prefix=/usr/gcc/v11.2.0
CC=/usr/bin/gcc CXX=/usr/bin/g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.0 (GCC)
$ uname -a
Linux njdc-ldev04 3.10.0-693.el7.x86_64 #1 SMP Thu Jul 6 19:56:57 EDT 2017
x86_64 x86_64 x86_64 GNU/Linux
$
The original function was 100 lines of code in a file of 2600 lines, including
20 headers directly.
[Bug c/106039] New: Inconsistent error reporting for printf() when format string is a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106039 Bug ID: 106039 Summary: Inconsistent error reporting for printf() when format string is a macro Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jonathan.leffler at gmail dot com Target Milestone: --- Created attachment 53176 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53176&action=edit Preprocessed output The problem is inconsistent error (warning) reporting from GCC (home-built versions 8.2.0, 9.3.0, 10.3.0, 11.2.0, 12.1.0 tested on RHEL 7.4) with respect to the location of the problem. (The test case is reduced from 5600 lines and 43 headers to 26 lines with two headers. The code is thoroughly anonymized.) There is no doubt that the errors reported are correct on a 64-bit system; the problem is in the way that the location of the error is reported. The errors reported by GCC 12.1.0 (errors because of -Werror) are shown below. Other versions produce essentially the same output, though the error formatting in 8.2.0 is somewhat different. The first error correctly lists the line causing the problem (line 18) as expected and desired. The other errors do not list the line causing the problem properly. The problem is surprisingly sensitive to the format string defined by the macro and the arguments provided to the printf() call. Some of the variations which 'fix' the error reporting are mentioned in the comments in the source. Reordering the printf() statements doesn't alter which printf() statements have the inconsistent error reporting. If the format string is placed directly in the printf() statement, the line is reported correctly. Neither the optimization level (-O) nor the debugging options (-g) seem to alter the behaviour. Using -Wall enables the relevant option; using -Werror ensures that rerunning 'make' attempts to rebuild the object file. The standard specified does not seem to alter the behaviour (in either -std=cXX or -std=gnuXX formats). Adding the -save-temps option to the compilation command line (to generate the .i file as requested in the 'Reporting Bugs' page) completely alters the error messages generated, giving the correct line numbers but odd-ball highlighting of what's wrong. $ gcc -std=c99 -Werror -Wall -c gcc-bug.c gcc-bug.c: In function ‘print_lock’: gcc-bug.c:4:23: error: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long int’ [-Werror=format=] 4 | #define PRT_BR_HDR"%-16x\n" | ^ gcc-bug.c:18:12: note: in expansion of macro ‘PRT_BR_HDR’ 18 | printf(PRT_BR_HDR, (intptr_t) val1); |^~ gcc-bug.c:4:28: note: format string is defined here 4 | #define PRT_BR_HDR"%-16x\n" |^ || |unsigned int |%-16lx gcc-bug.c:5:23: error: format ‘%x’ expects argument of type ‘unsigned int’, but argument 3 has type ‘long int’ [-Werror=format=] 5 | #define PRT_BR_LN1"%-21s %-16x %-16x %-18s %-18s\n" | ^ gcc-bug.c:5:23: note: in definition of macro ‘PRT_BR_LN1’ 5 | #define PRT_BR_LN1"%-21s %-16x %-16x %-18s %-18s\n" | ^ gcc-bug.c:5:34: note: format string is defined here 5 | #define PRT_BR_LN1"%-21s %-16x %-16x %-18s %-18s\n" | ^ | | | unsigned int | %-16lx gcc-bug.c:5:23: error: format ‘%x’ expects argument of type ‘unsigned int’, but argument 4 has type ‘long int’ [-Werror=format=] 5 | #define PRT_BR_LN1"%-21s %-16x %-16x %-18s %-18s\n" | ^ gcc-bug.c:5:23: note: in definition of macro ‘PRT_BR_LN1’ 5 | #define PRT_BR_LN1"%-21s %-16x %-16x %-18s %-18s\n" | ^ gcc-bug.c:5:40: note: format string is defined here 5 | #define PRT_BR_LN1"%-21s %-16x %-16x %-18s %-18s\n" |^ || |unsigned int |%-16lx gcc-bug.c:6:23: error: format ‘%x’ expects argument of type ‘unsigned int’, but argument 4 has type ‘long int’ [-Werror=format=] 6 | #define PRT_BR_LN2"%-12s %-8s %-16x %-16x %-18s %-18s\n" | ^~ gcc-bug.c:6:23: note: in definition of macro ‘PRT_BR_LN2’ 6 | #define PRT_BR_LN2"%-12s %-8s %-16x
[Bug c/106039] Inconsistent error reporting for printf() when format string is a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106039 --- Comment #1 from Jonathan Leffler --- Created attachment 53177 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53177&action=edit Close to minimal source (4 format strings; 4 printf statements; some comments) Close to minimal source code. It has 4 format strings and 4 printf statements where 1 of each would be minimal. It has some comments about changes that 'fix' the error reporting.
[Bug c/106039] Inconsistent error reporting for printf() when format string is a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106039 --- Comment #2 from Jonathan Leffler --- Created attachment 53178 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53178&action=edit Output from gcc -v when compiling the test case
[Bug c/106039] Inconsistent error reporting for printf() when format string is a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106039
--- Comment #4 from Jonathan Leffler ---
Thank you for looking at this.
In the second and subsequent errors, the line number of the macro is used
in all three lines of the error report, whereas in the first, the second
line of the messages is the `printf()` line and not the macro line again.
On Mon, Jun 20, 2022 at 19:10 pinskia at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106039
>
> --- Comment #3 from Andrew Pinski ---
> I don't see an issue with the diagnostic here really.
>
> For the single line case (without the format as a macro):
> printf("%-21s %-16x %-16x %-18s %-18s\n", "GHI", (intptr_t) val1,
> (intptr_t) val1, "ABC", "DEF");
>
>
> We get:
>
> :22:23: warning: format '%x' expects argument of type 'unsigned
> int',
> but argument 3 has type 'long int' [-Wformat=]
>22 | printf("%-21s %-16x %-16x %-18s %-18s\n", "GHI", (intptr_t)
> val1,
> (intptr_t) val1, "ABC", "DEF");
> | ^
> ~~~
> | | |
> | unsigned int long int
> | %-16lx
> :22:29: warning: format '%x' expects argument of type 'unsigned
> int',
> but argument 4 has type 'long int' [-Wformat=]
>22 | printf("%-21s %-16x %-16x %-18s %-18s\n", "GHI", (intptr_t)
> val1,
> (intptr_t) val1, "ABC", "DEF");
> | ^
>
> ~~~
> | |
>|
> | unsigned int
>
> long int
> | %-16lx
>
> are you asking to point out where the arguments were for the macro case?
>
> --
> You are receiving this mail because:
> You reported the bug.
[Bug c/106039] Inconsistent error reporting for printf() when format string is a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106039 --- Comment #5 from Jonathan Leffler --- I got an email from pinskia — thank you. I responded from an iPhone and got a message back about 'HTML attachments are not allowed'. I'm not sure if that got through. Anyway, what I said (tried to say) was: Thank you for looking at this. In the second and subsequent errors, the line number of the macro is used in all three lines of the error report, whereas in the first, the second line of the messages is the `printf()` line and not the macro line again. Amplifying on that somewhat terse response — for example: gcc-bug.c:5:23: error: format ‘%x’ expects argument of type ‘unsigned int’, but argument 3 has type ‘long int’ [-Werror=format=] 5 | #define PRT_BR_LN1"%-21s %-16x %-16x %-18s %-18s\n" gcc-bug.c:5:23: note: in definition of macro ‘PRT_BR_LN1’ 5 | #define PRT_BR_LN1"%-21s %-16x %-16x %-18s %-18s\n" gcc-bug.c:5:34: note: format string is defined here 5 | #define PRT_BR_LN1"%-21s %-16x %-16x %-18s %-18s\n" All three lines reference the macro on line 5, whereas in the first error messate, the middle part of the message refers to line 18 where the print statement is found: gcc-bug.c:4:23: error: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long int’ [-Werror=format=] 4 | #define PRT_BR_HDR"%-16x\n" gcc-bug.c:18:12: note: in expansion of macro ‘PRT_BR_HDR’ 18 | printf(PRT_BR_HDR, (intptr_t) val1); gcc-bug.c:4:28: note: format string is defined here 4 | #define PRT_BR_HDR"%-16x\n" This is a lot more helpful than reporting the macro line 3 times.
[Bug c/111249] New: Aggressive loop optimization reports "iteration 2147483645 invokes undefined behavior"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111249
Bug ID: 111249
Summary: Aggressive loop optimization reports "iteration
2147483645 invokes undefined behavior"
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jonathan.leffler at gmail dot com
Target Milestone: ---
The problem occurs with GCC 12.2.0 and GCC 13.2.0. It is difficult to see how
the loop could ever reach iteration 2147483645. It would have had undefined
behaviour from iteration 3 onwards, anyway.
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/work1/gcc/v13.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-13.2.0/configure --prefix=/usr/gcc/v13.2.0
CC=/usr/gcc/v12.2.0/bin/gcc CXX=/usr/gcc/v12.2.0/bin/g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)
Command line:
gcc -std=c99 -O3 -Wall -pedantic -Wold-style-definition -Wold-style-declaration
-Wnested-externs -Wmissing-prototypes -Wextra -Werror -save-temps -c
gcc-inline-bug.c
Resulting errors:
In function ‘sbt_subclass_put’:
cc1: error: iteration 2147483645 invokes undefined behavior
[-Werror=aggressive-loop-optimizations]
In function ‘sbt_sendbuffer’,
inlined from ‘sbt_subclass_put’ at gcc-inline-bug.c:95:15:
gcc-inline-bug.c:52:23: note: within this loop
52 | for (int i = 0; i < n_info; i++)
| ~~^~~~
cc1: all warnings being treated as errors
Output file (gcc-inline-bug.i):
# 0 "gcc-inline-bug.c"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "gcc-inline-bug.c"
enum { E_Success = 0, E_Failure = -1 };
typedef long long LSN_t;
typedef struct BUF_s BUF_t;
typedef struct
{
LSN_t slri_lsn;
BUF_t *slri_buf;
} SLR_t;
typedef struct SBT_s SBT_t;
typedef struct
{
int (*sbtop_put)(SBT_t *objp, LSN_t a_lsn, BUF_t *a_buf);
} OPS_t;
typedef struct
{
SLR_t *slri_info;
} VAR_t;
struct SBT_s
{
SBT_t *sbtv_next;
LSN_t sbtv_last;
OPS_t sbtv_ops;
VAR_t sbtv_vars[24];
};
typedef struct
{
int sish_txid;
} ISH_t;
extern int sbt_subclass_put(SBT_t *objp, LSN_t a_lsn, BUF_t *a_buf);
extern int ISH_read(BUF_t *inbufp, ISH_t *in_header);
extern int sbt_putbuf(SBT_t *objp, LSN_t a_lsn, BUF_t *a_buf);
extern int sbt_seterr(SBT_t *objp, int rc, int s);
extern void slri_decref(BUF_t *slrip, const char *file, int line);
extern void slri_set_empty(SLR_t *slrip);
static int
sbt_sendbuffer(SBT_t *objp, SLR_t **info, int n_info)
{
int rc = E_Success;
for (int i = 0; i < n_info; i++)
{
SLR_t *pendp = info[i];
if (rc == E_Success)
{
int s = sbt_putbuf(objp->sbtv_next, pendp->slri_lsn,
pendp->slri_buf);
if (s == E_Success)
objp->sbtv_last = pendp->slri_lsn;
else
rc = sbt_seterr(objp, s, 39);
}
slri_decref(pendp->slri_buf, "gcc-inline-bug.c", 68);
slri_set_empty(pendp);
}
return rc;
}
int
sbt_subclass_put(SBT_t *objp, LSN_t a_lsn, BUF_t *a_buf)
{
BUF_t *inbufp = a_buf;
ISH_t in_header;
int rc;
if ((rc = ISH_read(inbufp, &in_header)) != E_Success)
return E_Failure;
VAR_t *vars = &objp->sbtv_vars[0];
SLR_t *pendp = &vars->slri_info[in_header.sish_txid];
ISH_t bef_header;
if ((rc = ISH_read(pendp->slri_buf, &bef_header)) != E_Success)
return E_Failure;
SLR_t aft_bufinfo = { .slri_lsn = a_lsn, .slri_buf = inbufp };
SLR_t *tosend[2] = { pendp, &aft_bufinfo };
if ((rc = sbt_sendbuffer(objp, tosend, 2)) != E_Success)
return E_Failure;
return E_Success;
}
I was given a list of possible duplicates: 57199, 59651, 79517, 84867, 88272,
103724, and 106842. Of those, 103724 (closed because the GCC 10 code line is
closed) and 106482 could be related, but neither deals with a function being
inlined and then producing the warning. The others seem loosely related but
not relevant.
The original source code (gcc-inline-big.c) has some comments in it that the
preprocessor removes:
enum { E_Success = 0, E_Failure = -1 };
typedef long long LSN_t;
typedef struct BUF_s BUF_t;
typedef struct
{
LSN_t slri_lsn;
BUF_t *slri_buf;
} SLR_t;
typedef struct SBT_s SBT_t;
typedef struct
{
int (*sbtop_put)(SBT_t *objp, LSN_t a_lsn, BUF_t *a_buf);
} OPS_t;
typedef struct
{
SLR_t *slri_info;
} VAR_t;
struct SBT_s
{
SBT_t *sbtv_next;
LSN_t sbtv_last;
OPS_t sbtv_ops;
VAR_t sbtv_vars[24];
};
typedef struct
{
int sish_txid;
} ISH_t;
/* Entry point to module */
extern int sbt_subclass_put(SBT_t *objp, LSN_t a_lsn, BUF_t *a_buf);
/* Functions used by module */
extern int ISH_read(BUF_t *inbufp, ISH_t *in_header);
extern int sbt_putbuf(SBT_
[Bug c/111489] New: Incorrect "-Wmaybe-uninitialized" warning from GCC 13.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111489
Bug ID: 111489
Summary: Incorrect "-Wmaybe-uninitialized" warning from GCC
13.2.0
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jonathan.leffler at gmail dot com
Target Milestone: ---
The problem occurs with GCC 13.2.0, and the submitted code also produces the
warning in GCC 12.2.0, but minor variations on the code tested while reducing
the production code did not always reproduce with 12 even though it did with
13. I also tested versions 7.3.0, 8.2.0, 9.3.0, 10.3.0, 11.2.0; none of them
produced the warning for me. I'm not clear if this is a regression in 13 (and
12), or whether the older versions are oblivious to the and 12 and 13 are
trying to spot a problem but not recognizing why there isn't a problem in the
code.
The gist of the problem is that a variable is defined but not initialized
immediately:
uint16_t pg_version;
…
if (flags == PGR_VERSION)
pg_version = GET_PGVERS(pg_old);
…
for (…)
{
…
if (flags == PGR_VERSION)
{
cur_rowid = ROWID(PAGE(sav_rowid), i, PT_BIGRID(cur_partp));
pg_expand(GET_SLOTPTR(pg_old, old_slot), row_data, pg_version);
}
}
GCC complains that pg_version may be used uninitialized, but pg_value is only
used in the loop body if the condition that assigned it a value outside the
loop applies inside the body too.
The workaround is simple: initialize pg_version to 0 when it is defined.
Compiler information:
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-13.2.0/configure --prefix=/usr/gcc/v13.2.0
CC=/usr/gcc/v12.2.0/bin/gcc CXX=/usr/gcc/v12.2.0/bin/g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)
Command line:
gcc -std=c18 -O3 -Wall -Wextra -Werror -save-temps -v -c -o gcc-bug.o gcc-bug.c
Compilation output:
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-13.2.0/configure --prefix=/usr/gcc/v13.2.0
CC=/usr/gcc/v12.2.0/bin/gcc CXX=/usr/gcc/v12.2.0/bin/g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)
COLLECT_GCC_OPTIONS='-std=c17' '-O3' '-Wall' '-Wextra' '-Werror' '-save-temps'
'-v' '-c' '-o' 'gcc-bug.o' '-mtune=generic' '-march=x86-64'
/work1/gcc/v13.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.2.0/cc1 -E -quiet
-v -iprefix /work1/gcc/v13.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/
gcc-bug.c -mtune=generic -march=x86-64 -std=c17 -Wall -Wextra -Werror -O3
-fpch-preprocess -o gcc-bug.i
ignoring nonexistent directory
"/work1/gcc/v13.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory
"/work1/gcc/v13.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/13.2.0/include"
ignoring duplicate directory
"/work1/gcc/v13.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/13.2.0/include-fixed"
ignoring nonexistent directory
"/work1/gcc/v13.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/work1/gcc/v13.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/include
/work1/gcc/v13.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/include-fixed
/usr/local/include
/work1/gcc/v13.2.0/bin/../lib/gcc/../../include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-std=c17' '-O3' '-Wall' '-Wextra' '-Werror' '-save-temps'
'-v' '-c' '-o' 'gcc-bug.o' '-mtune=generic' '-march=x86-64'
/work1/gcc/v13.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.2.0/cc1
-fpreprocessed gcc-bug.i -quiet -dumpbase gcc-bug.c -dumpbase-ext .c
-mtune=generic -march=x86-64 -O3 -Wall -Wextra -Werror -std=c17 -version -o
gcc-bug.s
GNU C17 (GCC) version 13.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 13.2.0, GMP version 6.3.0, MPFR version
4.2.0, MPC version 1.3.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 76c675c9da56a319124364c69f2f4d48
gcc-bug.c: In function ‘pg_reorg’:
gcc-bug.c:186:13: error: ‘pg_version’ may be used uninitialized
[-Werror=maybe-uninitialized]
186 | pg_expand(GET_SLOTPTR(pg_old, old_slot), row_data,
pg_version);
|
^~~
gcc-bug.c:141:14: note: ‘pg_version’ was declared here
141 | uint16_t pg_version;
| ^~
cc1: all warnings being treated as errors
The code is as reduced as I could make it, but not as minimal as I'd like. It
does not use any headers; I copied definitions for size_t and [u]intN_t from
and to the top of the file (before it was compi
[Bug c/111693] New: Online manual mentions -Wuse-after-free but does not document it further
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111693 Bug ID: 111693 Summary: Online manual mentions -Wuse-after-free but does not document it further Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jonathan.leffler at gmail dot com Target Milestone: --- In the 13.2.0 documentation (https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Warning-Options.html), the list of options enabled by "-Wall" includes "-Wuse-after-free=2", but there is no further mention of the option on the page. Similarly, in the 12.3.0 documentation (https://gcc.gnu.org/onlinedocs/gcc-12.3.0/gcc/Warning-Options.html), the list of options enabled by "-Wall" includes "-Wuse-after-free=3", but there is no further mention of the option on the page. It is not mentioned at all in earlier manuals, presumably because it wasn't available in the earlier versions. It would be helpful to know what the values 2 and 3 mean, and presumably what 1 and 0 mean too.
[Bug c/111695] New: Spurious -Wuse-after-free when managing two arrays in parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111695 Bug ID: 111695 Summary: Spurious -Wuse-after-free when managing two arrays in parallel Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jonathan.leffler at gmail dot com Target Milestone: --- Created attachment 56047 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56047&action=edit Variation 1 (two arrays in parallel) Related to meta-bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075 (bogus/missing -Wuse-after-free). Related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106578 (spurious -Wuse-after-free=2 after conditional free() when not optimizing), but the symptoms are different. There are 4 (smallish) source files. Files gcc-bug-1.c and gcc-bug-3.c use one algorithm for handling old and new values; files gcc-bug-2.c and gcc-bug-4.c use a slight different algorithm. Files gcc-bug-1.c and gcc-bug-2.c manage two arrays 'in parallel' — the names and sizes arrays are handled by separate allocations using the same size controls and report spurious 'use-after-free' errors. Files gcc-bug-3.c and gcc-bug-4.c manage a single array and do not report any (spurious) 'use-after-free' error. The problem reproduces with GCC 13.2.0 and also with GCC 12.2.0. Since there is no mention of -Wuse-after-free in the GCC 11 manual (or any earlier versions), there is no surprise that none of them report the error. Compiler version information: gcc -v -std=c11 -O3 -Werror -Wall -c gcc-bug-1.c Using built-in specs. COLLECT_GCC=gcc Target: x86_64-pc-linux-gnu Configured with: ../gcc-13.2.0/configure --prefix=/usr/gcc/v13.2.0 CC=/usr/gcc/v12.2.0/bin/gcc CXX=/usr/gcc/v12.2.0/bin/g++ Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.2.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-std=c11' '-O3' '-Werror' '-Wall' '-c' '-mtune=generic' '-march=x86-64' /work1/gcc/v13.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.2.0/cc1 -quiet -v -iprefix /work1/gcc/v13.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/ gcc-bug-1.c -quiet -dumpbase gcc-bug-1.c -dumpbase-ext .c -mtune=generic -march=x86-64 -O3 -Werror -Wall -std=c11 -version -o /tmp/ccX3ka4K.s GNU C11 (GCC) version 13.2.0 (x86_64-pc-linux-gnu) compiled by GNU C version 13.2.0, GMP version 6.3.0, MPFR version 4.2.0, MPC version 1.3.1, isl version isl-0.24-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/work1/gcc/v13.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/include" ignoring duplicate directory "/work1/gcc/v13.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/13.2.0/include" ignoring duplicate directory "/work1/gcc/v13.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/13.2.0/include-fixed" ignoring nonexistent directory "/work1/gcc/v13.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /work1/gcc/v13.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/include /work1/gcc/v13.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/include-fixed /usr/local/include /work1/gcc/v13.2.0/bin/../lib/gcc/../../include /usr/include End of search list. Compiler executable checksum: 76c675c9da56a319124364c69f2f4d48 Reported errors (gcc-bug-1.c): gcc-bug-1.c: In function ‘function’: gcc-bug-1.c:34:21: error: pointer ‘names’ may be used after ‘realloc’ [-Werror=use-after-free] 34 | free(old_names); | ^~~ gcc-bug-1.c:28:21: note: call to ‘realloc’ here 28 | names = realloc(names, max_names * sizeof(names[0])); | ^~~~ gcc-bug-1.c:38:21: error: pointer ‘sizes’ may be used after ‘realloc’ [-Werror=use-after-free] 38 | free(old_sizes); | ^~~ gcc-bug-1.c:29:21: note: call to ‘realloc’ here 29 | sizes = realloc(sizes, max_names * sizeof(sizes[0])); | ^~~~ cc1: all warnings being treated as errors Reported errors (gcc-bug-2.c): gcc -std=c11 -O3 -Werror -Wall -c gcc-bug-2.c gcc-bug-2.c: In function ‘function’: gcc-bug-2.c:32:21: error: pointer ‘names’ may be used after ‘realloc’ [-Werror=use-after-free] 32 | free(names); | ^~~ gcc-bug-2.c:26:32: note: call to ‘realloc’ here 26 | char **new_names = realloc(names, max_names * sizeof(names[0])); | ^~~~ gcc-bug-2.c:36:21: error: pointer ‘sizes’ may be used after ‘realloc’ [-Werror=use-after-free]
[Bug c/111695] Spurious -Wuse-after-free when managing two arrays in parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111695 Jonathan Leffler changed: What|Removed |Added CC||jonathan.leffler at gmail dot com --- Comment #1 from Jonathan Leffler --- Created attachment 56048 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56048&action=edit gcc-bug-2.c — Variation 2 (two arrays in parallel)
[Bug c/111695] Spurious -Wuse-after-free when managing two arrays in parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111695 --- Comment #2 from Jonathan Leffler --- Created attachment 56049 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56049&action=edit gcc-bug-3.c — Variation 3 (one array: does not generate -Wuse-after-free warnings)
[Bug c/111695] Spurious -Wuse-after-free when managing two arrays in parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111695 --- Comment #3 from Jonathan Leffler --- Created attachment 56050 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56050&action=edit gcc-bug-4.c — Variation 4 (one array — does not generate -Wuse-after-free warnings)
[Bug c/111695] Spurious -Wuse-after-free when managing two arrays in parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111695 Jonathan Leffler changed: What|Removed |Added Attachment #56047|0 |1 is obsolete|| --- Comment #4 from Jonathan Leffler --- Created attachment 56051 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56051&action=edit gcc-bug-1.c — Variatoion 1 (two arrays in parallel)
[Bug c/111693] Online manual mentions -Wuse-after-free but does not document it further
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111693 --- Comment #4 from Jonathan Leffler --- The link https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/C_002b_002b-Dialect-Options.html#index-Wuse-after-free is to the "Options Controlling C++ Dialect". I was using the C compiler, not the C++ compiler, so it is not at all obvious that I should look at that page — in fact, that page is irrelevant to users of the C compiler. The information there should be either copied to the C "Warnings Options" page, or linked to from the C page, where -Wuse-after-free is only mentioned and not defined. Incidentally, under "-Wuse-after-free=1" on the C++ page, there's a typo in: whether or not the call resulted in an actual reallocatio of memory The 'n' is missing from 'reallocation'.
[Bug c/111693] Online manual mentions -Wuse-after-free but does not document it further
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111693 --- Comment #5 from Jonathan Leffler --- The link https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/C_002b_002b-Dialect-Options.html#index-Wuse-after-free is to the "Options Controlling C++ Dialect". I was using the C compiler, not the C++ compiler, so it is not at all obvious that I should look at that page — in fact, that page is irrelevant to users of the C compiler. The information there should be either copied to the C "Warnings Options" page, or linked to from the C page, where -Wuse-after-free is only mentioned and not defined. Incidentally, under "-Wuse-after-free=1" on the C++ page, there's a typo in: whether or not the call resulted in an actual reallocatio of memory The 'n' is missing from 'reallocation'.
[Bug c/111693] Online manual mentions -Wuse-after-free but does not document it further
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111693 Jonathan Leffler changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #6 from Jonathan Leffler --- Apologies for the double comment — I got a "mid-air collision" message and wasn't at all sure how to deal with that.
[Bug tree-optimization/106757] [12/13 Regression] Incorrect "writing 1 byte into a region of size 0" on a vectorized loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106757 --- Comment #7 from Jonathan Leffler --- GCC 14.1.0 seems to produce "error: writing 8 bytes into a region of size 5 [-Werror=stringop-overflow=]" for two extra occurrences of almost the same code in the original source file. It still generates the original 4 warnings that triggered this bug report. The code now has 6 comments (instead of just 4) pointing out that the warning is probably incorrect and probably due to GCC bug 106757. I have not reduced the new situations to a bug like I did for the "error: writing 1 byte into a region of size 0" version of the message.
[Bug tree-optimization/106757] [12/13 Regression] Incorrect "writing 1 byte into a region of size 0" on a vectorized loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106757 --- Comment #8 from Jonathan Leffler --- I beg your pardon — I thought I was using GCC 14.1.0 when I was actually using GCC 13.2.0. My previous comment applies to GCC 13.2.0, with the spec. $ /usr/gcc/v13.2.0/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/gcc/v13.2.0/bin/gcc COLLECT_LTO_WRAPPER=/work1/gcc/v13.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-13.2.0/configure --prefix=/usr/gcc/v13.2.0 CC=/usr/gcc/v12.2.0/bin/gcc CXX=/usr/gcc/v12.2.0/bin/g++ Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.2.0 (GCC) $ Now to build 14.1.0 for this machine too and see whether there's still a problem. On another machine with 14.1.0 installed, the code compiles cleanly.
[Bug tree-optimization/106757] [12/13 Regression] Incorrect "writing 1 byte into a region of size 0" on a vectorized loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106757 --- Comment #9 from Jonathan Leffler --- I can confirm that GCC 14.1.0 does not report the problems, after all. GCC 13.2.0 and GCC 12.1.0 and 12.2.0 do. Apologies for the confusion.
