public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/111249] New: Aggressive loop optimization reports "iteration 2147483645 invokes undefined behavior"
@ 2023-08-30 22:04 jonathan.leffler at gmail dot com
2023-08-31 10:55 ` [Bug tree-optimization/111249] [12/13 Regression] " rguenth at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: jonathan.leffler at gmail dot com @ 2023-08-30 22:04 UTC (permalink / raw)
To: gcc-bugs
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 "<built-in>"
# 0 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "<command-line>" 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_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)
{
/* This call is part of the reproduction */
int s = sbt_putbuf(objp->sbtv_next, pendp->slri_lsn,
pendp->slri_buf);
if (s == E_Success)
objp->sbtv_last = pendp->slri_lsn;
else
/* Change this to rc = E_Failure; and the bug goes away */
rc = sbt_seterr(objp, s, 39);
}
/* These lines are part of the reproduction - delete either and the bug
goes away */
slri_decref(pendp->slri_buf, __FILE__, __LINE__);
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;
}
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/111249] [12/13 Regression] Aggressive loop optimization reports "iteration 2147483645 invokes undefined behavior"
2023-08-30 22:04 [Bug c/111249] New: Aggressive loop optimization reports "iteration 2147483645 invokes undefined behavior" jonathan.leffler at gmail dot com
@ 2023-08-31 10:55 ` rguenth at gcc dot gnu.org
2023-10-25 6:51 ` sjames at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-08-31 10:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111249
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to fail| |13.2.1
Target Milestone|--- |12.4
Status|UNCONFIRMED |NEW
CC| |hubicka at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=111233
Ever confirmed|0 |1
Keywords| |wrong-code
Last reconfirmed| |2023-08-31
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
-fno-split-loops avoids this, so possibly related to PR111233. It's also a hit
at a wrong-code issue.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/111249] [12/13 Regression] Aggressive loop optimization reports "iteration 2147483645 invokes undefined behavior"
2023-08-30 22:04 [Bug c/111249] New: Aggressive loop optimization reports "iteration 2147483645 invokes undefined behavior" jonathan.leffler at gmail dot com
2023-08-31 10:55 ` [Bug tree-optimization/111249] [12/13 Regression] " rguenth at gcc dot gnu.org
@ 2023-10-25 6:51 ` sjames at gcc dot gnu.org
2023-10-25 6:51 ` sjames at gcc dot gnu.org
2024-05-13 11:31 ` rguenth at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: sjames at gcc dot gnu.org @ 2023-10-25 6:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111249
Sam James <sjames at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amacleod at redhat dot com
--- Comment #2 from Sam James <sjames at gcc dot gnu.org> ---
Bisecting from 11 (good) -> 12 (bad) gave r12-4871-g502ffb1f389011 as the
breaking commit.
Bisecting from 13 (bad) -> 14 (good) gave r14-2926-gee20be8325f7f2 as the fix
commit.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/111249] [12/13 Regression] Aggressive loop optimization reports "iteration 2147483645 invokes undefined behavior"
2023-08-30 22:04 [Bug c/111249] New: Aggressive loop optimization reports "iteration 2147483645 invokes undefined behavior" jonathan.leffler at gmail dot com
2023-08-31 10:55 ` [Bug tree-optimization/111249] [12/13 Regression] " rguenth at gcc dot gnu.org
2023-10-25 6:51 ` sjames at gcc dot gnu.org
@ 2023-10-25 6:51 ` sjames at gcc dot gnu.org
2024-05-13 11:31 ` rguenth at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: sjames at gcc dot gnu.org @ 2023-10-25 6:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111249
--- Comment #3 from Sam James <sjames at gcc dot gnu.org> ---
(In reply to Sam James from comment #2)
> Bisecting from 11 (good) -> 12 (bad) gave r12-4871-g502ffb1f389011 as the
> breaking commit.
>
> Bisecting from 13 (bad) -> 14 (good) gave r14-2926-gee20be8325f7f2 as the
> fix commit.
sorry I mean r14-2927-g399c8dd44ff44f for the last one
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/111249] [12/13 Regression] Aggressive loop optimization reports "iteration 2147483645 invokes undefined behavior"
2023-08-30 22:04 [Bug c/111249] New: Aggressive loop optimization reports "iteration 2147483645 invokes undefined behavior" jonathan.leffler at gmail dot com
` (2 preceding siblings ...)
2023-10-25 6:51 ` sjames at gcc dot gnu.org
@ 2024-05-13 11:31 ` rguenth at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-05-13 11:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111249
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-05-13 11:31 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-30 22:04 [Bug c/111249] New: Aggressive loop optimization reports "iteration 2147483645 invokes undefined behavior" jonathan.leffler at gmail dot com
2023-08-31 10:55 ` [Bug tree-optimization/111249] [12/13 Regression] " rguenth at gcc dot gnu.org
2023-10-25 6:51 ` sjames at gcc dot gnu.org
2023-10-25 6:51 ` sjames at gcc dot gnu.org
2024-05-13 11:31 ` rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).