[Bug middle-end/110091] New: bogus -Wdangling-pointer on non-pointer values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110091
Bug ID: 110091
Summary: bogus -Wdangling-pointer on non-pointer values
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: patrickdepinguin at gmail dot com
Target Milestone: ---
Following reduced testcase gives a bogus -Wdangling-pointer:
struct tEntry
{
int value;
};
struct tOut
{
int outvalue;
};
extern struct tOut *out;
extern int otherfunc(struct tEntry *);
extern void anotherfunc(int val);
void bar()
{
struct tEntry entry = { 0 };
if (otherfunc() != 0)
{
return;
}
if (out)
{
out->outvalue = entry.value;
}
anotherfunc(5);
}
void foo()
{
bar();
}
$ gcc -O2 -Wall -Werror /opt/test.c
/opt/test.c: In function 'bar':
/opt/test.c:26:30: error: dangling pointer to 'entry' may be used
[-Werror=dangling-pointer=]
26 | out->outvalue = entry.value;
| ~^~
/opt/test.c:17:19: note: 'entry' declared here
17 | struct tEntry entry = { 0 };
| ^
In function 'bar',
inlined from 'foo' at /opt/test.c:34:5:
/opt/test.c:26:30: error: dangling pointer to 'entry' may be used
[-Werror=dangling-pointer=]
26 | out->outvalue = entry.value;
| ~^~
/opt/test.c: In function 'foo':
/opt/test.c:17:19: note: 'entry' declared here
17 | struct tEntry entry = { 0 };
| ^
cc1: all warnings being treated as errors
entry is a local struct, initialized to 0, and passed as pointer to an external
function.
But the use being warned about is not using any pointer.
Tested with 12.2.0 (Debian), 12.2.1 (Gentoo), 12.3.0 (official gcc docker
image), 13.1.0 (official gcc docker image).
[Bug c++/90809] -finstrument-functions-exclude-function-list mishandles comma escaping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90809 Thomas De Schampheleire changed: What|Removed |Added CC||patrickdepinguin at gmail dot com --- Comment #3 from Thomas De Schampheleire --- A fix for this issue seems to have been applied as (git) commit efab3e3a7326ad503532955ccd31f953851e388a. This bug can thus be closed.
[Bug c++/90816] -finstrument-functions-exclude-function-list improperly handles namespace/class definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90816 Thomas De Schampheleire changed: What|Removed |Added CC||patrickdepinguin at gmail dot com --- Comment #3 from Thomas De Schampheleire --- A fix for this issue seems to have been applied as (git) commit efab3e3a7326ad503532955ccd31f953851e388a. This bug can thus be closed.
[Bug tree-optimization/103173] strncpy output may be truncated copying 32 bytes from a string of length 1439 (bogus) [-Werror=stringop-truncation]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103173 --- Comment #4 from Thomas De Schampheleire --- Note also that in the test program of comment #3, there is no problem if using the 'password' or 'application' fields, rather than 'user', which is first in the structure.
[Bug tree-optimization/103173] strncpy output may be truncated copying 32 bytes from a string of length 1439 (bogus) [-Werror=stringop-truncation]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103173
--- Comment #3 from Thomas De Schampheleire
---
While the original test program failed on gcc 11.2.0 but not on gcc 9.4.0, I
now encounter a very similar case that does fail on gcc 9.4.0:
--
#include
#define MAX_NR_USERS 10
struct user_data {
char user[32];
char password[32];
char application[32];
};
struct user_data users[MAX_NR_USERS];
void login_process()
{
char tmp_user[33];
for (int i = 0; i < MAX_NR_USERS; i++)
{
snprintf(tmp_user, sizeof(tmp_user), "%s", &(users[i].user[0]));
}
}
--
arm-cortex_a53-linux-gnueabi-gcc /tmp/gcc-9-test.c -c -Wall -O2
/tmp/gcc-9-test.c: In function 'login_process':
/tmp/gcc-9-test.c:19:47: warning: '%s' directive output may be truncated
writing up to 959 bytes into a region of size 33 [-Wformat-truncation=]
19 | snprintf(tmp_user, sizeof(tmp_user), "%s",
&(users[i].user[0]));
| ^~
/tmp/gcc-9-test.c:19:9: note: 'snprintf' output between 1 and 960 bytes into a
destination of size 33
19 | snprintf(tmp_user, sizeof(tmp_user), "%s",
&(users[i].user[0]));
| ^~~
Here, the claimed 960 bytes are the total size of 'users' (3 * 32 * 10), while
the copied 'user' field is only 33 byte and there should be no problem.
The error is now -Wformat-truncation instead of -Wstringop-truncation but
otherwise this looks to be the same underlying problem.
This compiler is:
Using built-in specs.
COLLECT_GCC=.../buildroot-toolchains-bis/output/host/opt/ext-toolchain/bin/arm-cortex_a53-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=.../buildroot-toolchains-bis/output/host/opt/ext-toolchain/arm/bin/../libexec/gcc/arm-cortex_a53-linux-gnueabi/9.4.0/lto-wrapper
Target: arm-cortex_a53-linux-gnueabi
Configured with:
.../ctng/crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/src/gcc/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=arm-cortex_a53-linux-gnueabi
--prefix=.../ctng/crosstool-ng/targets/arm-cortex_a53-linux-gnueabi
--exec_prefix=.../ctng/crosstool-ng/targets/arm-cortex_a53-linux-gnueabi
--with-sysroot=.../ctng/crosstool-ng/targets/arm-cortex_a53-linux-gnueabi/arm-cortex_a53-linux-gnueabi/sysroot
--enable-languages=c,c++,fortran --with-cpu=cortex-a53 --with-fpu=neon-fp-armv8
--with-float=hard --with-pkgversion='crosstool-NG 1.24.0.487_10ac846'
--enable-__cxa_atexit --disable-tm-clone-registry --disable-libmudflap
--disable-libgomp --disable-libssp --disable-libquadmath
--disable-libquadmath-support --disable-libsanitizer --disable-libmpx
--with-gmp=.../ctng/crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--with-mpfr=.../ctng/crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--with-mpc=.../ctng/crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--with-isl=.../ctng/crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--disable-lto --without-zstd --enable-threads=posix --enable-target-optspace
--disable-plugin --disable-nls --disable-multilib
--with-local-prefix=.../ctng/crosstool-ng/targets/arm-cortex_a53-linux-gnueabi/arm-cortex_a53-linux-gnueabi/sysroot
--enable-long-long
Thread model: posix
gcc version 9.4.0 (crosstool-NG 1.24.0.487_10ac846)
[Bug other/103736] New: snprintf bogus format-truncation, disregarding modulo on argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103736
Bug ID: 103736
Summary: snprintf bogus format-truncation, disregarding modulo
on argument
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: patrickdepinguin at gmail dot com
Target Milestone: ---
gcc 11.2.0 and gcc 9.4.0 give a bogus format-truncation warning on following
test case compiled with -Wall and -O2:
#include
#include
void func(void) {
extern int8_t timezoneval;
char timezone[1+2+1];
if(timezoneval < 0)
{
snprintf(timezone, sizeof(timezone),"-%02d",-(timezoneval % 100));
}
else
{
snprintf(timezone, sizeof(timezone),"+%02d", timezoneval % 100);
}
}
Warning:
/tmp/test.cpp: In function 'void func()':
/tmp/test.cpp:15:52: warning: 'snprintf' output may be truncated before the
last format character [-Wformat-truncation=]
15 | snprintf(timezone, sizeof(timezone),"+%02d", timezoneval %
100);
|^
/tmp/test.cpp:15:18: note: 'snprintf' output between 4 and 5 bytes into a
destination of size 4
15 | snprintf(timezone, sizeof(timezone),"+%02d", timezoneval %
100);
|
^~~
Since timezoneval is used modulo 100, it will not take up more than two digits
(note that if timezoneval is negative, its value is negated first, so the
string representation will be positive). Together with the literal sign
character, and the null-termination, max. total size is 4 bytes. Yet, gcc
considers that 5 bytes may be needed.
When the parentheses in the first snprintf are omitted, causing the modulo
operator to operate on the negated timezoneval, the warning disappears. Funnily
enough, the warning is about the _second_, unmodified, snprintf:
#include
#include
void func(void) {
extern int8_t timezoneval;
char timezone[1+2+1];
if(timezoneval < 0)
{
snprintf(timezone, sizeof(timezone),"-%02d",-timezoneval % 100);
}
else
{
snprintf(timezone, sizeof(timezone),"+%02d", timezoneval % 100);
}
}
I found some possibly related older bugs, but was unsure if it's the same and
known to still apply on gcc 11. Feel free to mark this one as duplicated to the
relevant one.
Bug #78969 - bogus snprintf truncation warning due to missing range info
Bug #77721 - -Wformat-truncation not uses arg range for converted vars
Bug #94021 - -Wformat-truncation false positive due to excessive integer range
[Bug other/103542] New: bogus -Warray-bounds while index is limited by switch/case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103542
Bug ID: 103542
Summary: bogus -Warray-bounds while index is limited by
switch/case
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: patrickdepinguin at gmail dot com
Target Milestone: ---
gcc 11.2.0 reports the following on a reduced test case:
$ powerpc-linux-gcc -c array-bounds-fruit.c -O2 -Wall -Werror
array-bounds-fruit.c: In function 'get_default_config.part.0':
array-bounds-fruit.c:69:37: error: array subscript 4 is above array bounds of
'struct fruit_config[4]' [-Werror=array-bounds]
69 | do_something(id, [id].num_lemons);
| ~~^~~~
array-bounds-fruit.c:19:28: note: while referencing 'config'
19 | static struct fruit_config config[4];
|^~
cc1: all warnings being treated as errors
Above is for powerpc, but I have the same problem with ARM.
The offending line is inside a switch/case, within the block where 'id' is
tested to be 0, 1, 2, or 3.
gcc/g++ is considering a case where 'id' becomes 4, which is not possible in
this code.
If I make any more changes (even seemingly unrelated changes) to the test case,
the error disappears.
Test code:
#include
#include
#include
enum {
ID_0 = 0,
ID_1 = 1,
ID_2 = 2,
ID_3 = 3,
MAX_IDS,
};
#define MAX_ENTRIES 256
struct fruit_config {
uint32_t num_apples;
uint32_t num_lemons;
uint32_t * lemons;
};
static struct fruit_config config[4];
static uint32_t unrelated_table[MAX_IDS][MAX_ENTRIES];
uint32_t do_something(const uint32_t id, uint32_t * number_of_entries)
{
uint32_t error = 0;
switch (id) {
/* merging these case statements with identical body removes the issue
*/
case ID_0: {
*number_of_entries = 0;
break;
}
case ID_1: {
*number_of_entries = 0;
break;
}
case ID_2: {
*number_of_entries = 0;
break;
}
case ID_3: {
*number_of_entries = 0;
break;
}
default: {
error = 0xff;
*number_of_entries = 0;
break;
}
}
return error;
}
struct fruit_config * get_default_config(const uint32_t id)
{
switch (id) {
case ID_0:
case ID_1:
case ID_2:
case ID_3:
{
uint32_t entry = 0;
for (entry = 0; entry
[Bug tree-optimization/103173] New: strncpy output may be truncated copying 32 bytes from a string of length 1439 (bogus) [-Werror=stringop-truncation]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103173
Bug ID: 103173
Summary: strncpy output may be truncated copying 32 bytes from
a string of length 1439 (bogus)
[-Werror=stringop-truncation]
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: patrickdepinguin at gmail dot com
Target Milestone: ---
gcc 11.2.0 gives a bogus warning of type 'stringop-truncation' on below reduced
test case.
.../arm-cortex_a53-linux-gnueabi-gcc -O2 -Wall -Werror -c /tmp/test.c -o
/tmp/foo.o
/tmp/test.c: In function 'func':
/tmp/test.c:22:5: error: 'strncpy' output may be truncated copying 32 bytes
from a string of length 1439 [-Werror=stringop-truncation]
22 | strncpy(dest, data[j].name, sizeof(dest));
| ^
cc1: all warnings being treated as errors
-
#include
struct data_struct {
char name[32];
int bar;
};
void func()
{
extern struct data_struct data[40];
extern char dest[32];
int j=0;
strncpy(dest, data[j].name, sizeof(dest));
};
-
Here 'dest' is correctly interpreted as an array of size 32, but 'data[j].name'
is interpreted as having size 1439 which is incorrect, as it should also have
size 32 (name member of struct data_struct).
Following factors influence the reported size 1439:
* if data_struct is given more or less additional members, like 'bar'
* if the array length of 'data' (40) is changed
* if the length of the 'name' array in data_struct is changed
If 'j' is replaced by 0 directly, as in:
strncpy(dest, data[0].name, sizeof(dest));
the error disappears.
This problem did not occur on our previous toolchain with gcc 7.4.0 for the
same architecture, nor for x86_64 with gcc 7.5.0.
Info from gcc -v:
Using built-in specs.
COLLECT_GCC=.../buildroot-toolchains/output/host/opt/ext-toolchain/bin/arm-cortex_a53-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=.../buildroot-toolchains/output/host/opt/ext-toolchain/arm/bin/../libexec/gcc/arm-cortex_a53-linux-gnueabi/11.2.0/lto-wrapper
Target: arm-cortex_a53-linux-gnueabi
Configured with:
.../crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/src/gcc/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=arm-cortex_a53-linux-gnueabi
--prefix=.../crosstool-ng/targets/arm-cortex_a53-linux-gnueabi
--exec_prefix=.../crosstool-ng/targets/arm-cortex_a53-linux-gnueabi
--with-sysroot=.../crosstool-ng/targets/arm-cortex_a53-linux-gnueabi/arm-cortex_a53-linux-gnueabi/sysroot
--enable-languages=c,c++,fortran --with-cpu=cortex-a53 --with-fpu=neon-fp-armv8
--with-float=hard --with-pkgversion='crosstool-NG 1.24.0.487_10ac846'
--enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp
--disable-libquadmath --disable-libquadmath-support --disable-libsanitizer
--disable-libmpx
--with-gmp=.../crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--with-mpfr=.../crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--with-mpc=.../crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--with-isl=.../crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--disable-lto --without-zstd --enable-threads=posix --enable-target-optspace
--disable-plugin --disable-nls --disable-multilib
--with-local-prefix=.../crosstool-ng/targets/arm-cortex_a53-linux-gnueabi/arm-cortex_a53-linux-gnueabi/sysroot
--enable-long-long
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.0 (crosstool-NG 1.24.0.487_10ac846)
[Bug tree-optimization/88240] [9 Regression] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240 --- Comment #23 from Thomas De Schampheleire --- Thanks a lot!
[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176 --- Comment #33 from Thomas De Schampheleire --- (In reply to Andrew Pinski from comment #32) > >I'm currently using -march=octeon3 or -march=octeon2 as appropriate. > > Can you report this to Marvell (Cavium)? O32 was not used much on Octeon. Yes, I will. However, please note that I am using N32, not O32.
[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #31 from Thomas De Schampheleire ---
(In reply to Maciej W. Rozycki from comment #27)
> Yes, it is the same problem, the same address calculation occurs here,
> and the lack of 32-bit address space wraparound is a part of the n32
> Linux ABI, which implies support for processors that do not support such
> a wraparound in hardware (no CP0.Status.PX bit).
>
> You may try experimenting with ISA/ASE selection options, so that LWX is
> not considered a valid instruction by GCC. Otherwise I can't help with
> finding a workaround as I don't know one offhand and I'm not involved
> with MIPS development anymore, sorry. And neither is Doug BTW.
>
> This really ought to be fixed properly in GCC.
I'm currently using -march=octeon3 or -march=octeon2 as appropriate.
I'm not really confident in changing this, as there will be other impact too.
As a quick workaround/test, I will try letting the '-mno-lxc1-sxc1' flag also
control the use of the lwx and similar instructions, as follows:
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index 23e1672b586..5dee3fbe29f 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -1194,17 +1194,17 @@ struct mips_cpu_info {
/* ISA has lwxs instruction (load w/scaled index address. */
#define ISA_HAS_LWXS ((TARGET_SMARTMIPS || TARGET_MICROMIPS) \
-&& !TARGET_MIPS16)
+&& !TARGET_MIPS16 && mips_lxc1_sxc1)
/* ISA has lbx, lbux, lhx, lhx, lhux, lwx, lwux, or ldx instruction. */
-#define ISA_HAS_LBX(TARGET_OCTEON2)
-#define ISA_HAS_LBUX (ISA_HAS_DSP || TARGET_OCTEON2)
-#define ISA_HAS_LHX(ISA_HAS_DSP || TARGET_OCTEON2)
-#define ISA_HAS_LHUX (TARGET_OCTEON2)
-#define ISA_HAS_LWX(ISA_HAS_DSP || TARGET_OCTEON2)
-#define ISA_HAS_LWUX (TARGET_OCTEON2 && TARGET_64BIT)
+#define ISA_HAS_LBX(TARGET_OCTEON2 && mips_lxc1_sxc1)
+#define ISA_HAS_LBUX ((ISA_HAS_DSP || TARGET_OCTEON2) &&
mips_lxc1_sxc1)
+#define ISA_HAS_LHX((ISA_HAS_DSP || TARGET_OCTEON2) &&
mips_lxc1_sxc1)
+#define ISA_HAS_LHUX (TARGET_OCTEON2 && mips_lxc1_sxc1)
+#define ISA_HAS_LWX((ISA_HAS_DSP || TARGET_OCTEON2) &&
mips_lxc1_sxc1)
+#define ISA_HAS_LWUX (TARGET_OCTEON2 && TARGET_64BIT &&
mips_lxc1_sxc1)
#define ISA_HAS_LDX((ISA_HAS_DSP || TARGET_OCTEON2) \
-&& TARGET_64BIT)
+&& TARGET_64BIT && mips_lxc1_sxc1)
/* The DSP ASE is available. */
#define ISA_HAS_DSP(TARGET_DSP && !TARGET_MIPS16)
[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176 --- Comment #30 from Thomas De Schampheleire --- (In reply to mpf from comment #29) > I don't remember the detail of this issue but I believe I was convinced that > it is down to the lack of setting PX appropriately in HW. UX==0, PX==1. The > PX control bit forces address calculations i.e. base + imm or base + reg to > be performed with 32-bit rules but allows 64 instruction usage. Since there > is a processor mode that is perfectly capable of meeting the requirements of > a program with 64bit data and 32bit pointers then the solution is to set PX > for N32 rather than UX. This would have to be done by the kernel when switching to an application, correct? And then only for n32 applications, not for n64 or others.
[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176 --- Comment #26 from Thomas De Schampheleire --- (In reply to Thomas De Schampheleire from comment #25) > Is it possible that this same problem is applicable on the 'lwx' instruction? > I am using MIPS64 n32. > > I first saw the original problem as described in this bug with instruction > 'lwxc1'. I then used the suggested compilation flag -mno-lxc1-sxc1 which > removed that problem. > > However, in another place in the code I get a SIGBUS on following > instruction: > > lwx v1,a5(v1) > > where: > v1: eb623870 > a5: 8a4ee1c4 > > The exception shows: > badvaddr: 75b11a34 > > If you sum the lower 32 bits of v1+a5 you get '175b11a34' (i.e. 33 bits). > Truncated to 32 bits, this is the value you see in badvaddr. > Nevertheless, this address is inside a mapped and read/writable memory > range, from /proc/PID/maps: > > 75b0-75b21000 rw-p 00:00 0 > > This behavior looks very similar to this bug's description. > > If this same problem indeed also applies to 'lwx', is there a workaround for > it? This is observed with gcc 7.3.0.
[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176 --- Comment #25 from Thomas De Schampheleire --- Is it possible that this same problem is applicable on the 'lwx' instruction? I am using MIPS64 n32. I first saw the original problem as described in this bug with instruction 'lwxc1'. I then used the suggested compilation flag -mno-lxc1-sxc1 which removed that problem. However, in another place in the code I get a SIGBUS on following instruction: lwx v1,a5(v1) where: v1: eb623870 a5: 8a4ee1c4 The exception shows: badvaddr: 75b11a34 If you sum the lower 32 bits of v1+a5 you get '175b11a34' (i.e. 33 bits). Truncated to 32 bits, this is the value you see in badvaddr. Nevertheless, this address is inside a mapped and read/writable memory range, from /proc/PID/maps: 75b0-75b21000 rw-p 00:00 0 This behavior looks very similar to this bug's description. If this same problem indeed also applies to 'lwx', is there a workaround for it?
[Bug debug/24551] [meta-bug] -feliminate-unused-debug-types issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24551 --- Comment #4 from Thomas De Schampheleire --- Could it not be that #14167 is now fixed after fixing #86964 ?
[Bug debug/86964] [7/8 Regression] Too many debug symbols included, especially for extern globals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964 --- Comment #18 from Thomas De Schampheleire --- Second version of patch, fixing testsuite failures, was posted: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01403.html
[Bug debug/86964] [7/8 Regression] Too many debug symbols included, especially for extern globals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964 --- Comment #17 from Thomas De Schampheleire --- Thanks, see: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00922.html
[Bug debug/86964] [7/8 Regression] Too many debug symbols included, especially for extern globals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964 --- Comment #15 from Thomas De Schampheleire --- Created attachment 46361 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46361=edit Make -feliminate-unused-debug-symbols the default Attached patch makes -feliminate-unused-debug-symbols the default. I also updated the documentation (I hope it is correct). Note that I removed the explicit reference to 'stabs' format, as it seems no longer correct as DWARF is supported too. Is this the correct way forward?
[Bug debug/86964] [7/8 Regression] Too many debug symbols included, especially for extern globals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964 --- Comment #13 from Thomas De Schampheleire --- I have applied the patch on a gcc 7.4 PPC toolchain, and tested on a code base where the problem existed. The original ELF object size (of one example source file) in a pre-gcc-7 toolchain (gcc 4.9.2) was 219K. With an unpatched gcc 7 based toolchain, this had become 6.2M. With the patch applied, with the same command-line as before, there is no change, i.e. object size is still 6.2M. Only by adding the extra option -feliminate-unused-debug-symbols, the object size drops back to a reasonable 218K. My question is now: why is it needed to explicitly specify -feliminate-unused-debug-symbols? Is this an intended behavior change compared to e.g gcc 4.9?
[Bug debug/86964] [7/8 Regression] Too many debug symbols included, especially for extern globals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964 --- Comment #11 from Thomas De Schampheleire --- It seems the necessary patch is applied now, are these the only changes The target milestone is set 7.5. Do you have any rough idea when that would be released?
[Bug tree-optimization/88240] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240 --- Comment #11 from Thomas De Schampheleire --- Any feedback? With the reduced testcase qemu is out of the picture. Do you agree that this is a bug in gcc?
[Bug debug/86964] Too many debug symbols included, especially for extern globals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964 --- Comment #4 from Thomas De Schampheleire --- I am suffering from this same problem using gcc 7.3.0 on a Broadcom SDK. Due to this, compiled object files increase from 90 KiB (using gcc 4.9.2) to 15 MiB (gcc 7.3.0). This size increase is enormous. Aside from the fact that the disk space need becomes very large (don't know the total number, but it is definitely larger than 32 GiB), the final link step actually failed due to it.
[Bug tree-optimization/88240] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240
--- Comment #10 from Thomas De Schampheleire ---
I was able to further investigate and reduce the problem.
Qemu is now out of the picture, I can reproduce the issue directly on a real
CPU. All I need to do is enable the 'underflow' exception bit using
feenableexcept. Note that, as you will see below in the gdb output, the
denormal exception is not enabled.
Toolchain is still the same: gcc 7.3.0, glibc 2.27, binutils 2.30. See details
in bug description.
Below is the simplified test program, based on [1] with the addition of the
exception enabling code.
#define _GNU_SOURCE
#include
#include
#include
static int callback(void *NotUsed, int argc, char **argv, char **azColName){
int i;
for(i=0; i end of added code
rc = sqlite3_open(argv[2], );
if( rc ){
fprintf(stderr, "Can't open database: %s\n", sqlite3_errmsg(db));
sqlite3_close(db);
return(1);
}
rc = sqlite3_exec(db, argv[3], callback, 0, );
if( rc!=SQLITE_OK ){
fprintf(stderr, "SQL error: %s\n", zErrMsg);
sqlite3_free(zErrMsg);
}
sqlite3_close(db);
return 0;
}
I compiled this code and sqlite3 (version 321, but I don't think the exact
version matters much) with the mentioned toolchain.
Compilation command used for the test program:
/home/tdescham/repo/isam/buildroot-qemu/output/host/opt/ext-toolchain/bin/i686-pc-linux-gnu-gcc
--sysroot
/home/tdescham/repo/isam/buildroot-qemu/output/host/i686-buildroot-linux-gnu/sysroot
-march=pentiumpro -o sqlite-test sqlite-test.c -lsqlite3 -lm -g -O0
To reproduce, first create a simple database, not yet enabling exceptions:
$ env
LD_LIBRARY_PATH=/home/tdescham/repo/isam/buildroot-qemu/output/staging/usr/lib
./sqlite-test 0 /tmp/foo.db "create table foobar (id int primary key, name
text)"
Not enabling exceptions.
fctrl = 037f
Now, we can trigger the bug by showing some SQL output, if we enable the
underflow exception:
$ env
LD_LIBRARY_PATH=/home/tdescham/repo/isam/buildroot-qemu/output/staging/usr/lib
./sqlite-test 1 /tmp/foo.db "select sql from sqlite_master where sql not NULL;"
Enabling exception: FE_UNDERFLOW
fctrl = 036f
fish: Job 2, 'env LD_LIBRARY_PATH=/home/tdesc…' terminated by signal SIGFPE
(Floating point exception)
If we do not enable the underflow exception, everything is fine:
$ env
LD_LIBRARY_PATH=/home/tdescham/repo/isam/buildroot-qemu/output/staging/usr/lib
./sqlite-test 0 /tmp/foo.db "select sql from sqlite_master where sql not NULL;"
Not enabling exceptions.
fctrl = 037f
sql = CREATE TABLE foobar (id int primary key, name text)
Here is the output of a debug session using gdb:
$ env
LD_LIBRARY_PATH=/home/tdescham/repo/isam/buildroot-qemu/output/staging/usr/lib
gdb ./sqlite-test
GNU gdb (Gentoo 8.1 p1) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
[Bug tree-optimization/88240] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240 --- Comment #8 from Thomas De Schampheleire --- To clarify the situation with underflow / denormal exception I will debug the issue again and inspect the corresponding registers. I'm not familiar with 'NaNs': is it a specific value that I can see in the union variable? During debugging, the union value was '3'.
[Bug tree-optimization/88240] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240 --- Comment #6 from Thomas De Schampheleire --- (In reply to Florian Weimer from comment #5) > (In reply to Thomas De Schampheleire from comment #4) > > When analyzing this problem with gdb, we looked at the floating-point status > > register before the fldl call, then after, and only the underflow bit was > > new. But there were already other bits present, we probably should have set > > the register to 0 first. Nevertheless, the underflow bit got set. > > This is QEMU with TCG, right? It could be an i387 emulation bug. I don't think so. Isn't it so that KVM and TCG are mutually exclusive choices? We see the problem if we pass --enable-kvm and don't see the problem if we don't pass that flag. From my limited understanding of qemu, not paying the flag means that the default TCG emulation is used. Am I wrong?
[Bug tree-optimization/88240] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240 --- Comment #4 from Thomas De Schampheleire --- (In reply to Uroš Bizjak from comment #2) > (In reply to Thomas De Schampheleire from comment #0) > > gcc 7.3.0 optimizes below code in a way that may cause a floating-point > > underflow (SIGFPE with underflow flag) on x86. The underflow occurs on an > > 'fldl' instruction. > > FLD will generate _denormal_ (#DE) exception for denormal single and double > FP operand ([1], 8.5.2). This is a non-standard exception, and has to be > distinguished from numeric underflow exception (#UE). Is there a reason for > denormal exception to be unmasked? > > [1] http://home.agh.edu.pl/~amrozek/x87.pdf I don't think we intentionally set any such flags from the application code. How would the denormal exception be enabled? Is that with feenableexcept ? When analyzing this problem with gdb, we looked at the floating-point status register before the fldl call, then after, and only the underflow bit was new. But there were already other bits present, we probably should have set the register to 0 first. Nevertheless, the underflow bit got set.
[Bug other/88240] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240 --- Comment #1 from Thomas De Schampheleire --- Created attachment 45112 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45112=edit gzipped source file, part 2
[Bug other/88240] New: Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240
Bug ID: 88240
Summary: Potential optimization bug: invalid pre-load of
floating-point value could cause SIGFPE-underflow if
value is integer
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: patrickdepinguin at gmail dot com
Target Milestone: ---
Created attachment 45111
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45111=edit
gzipped source file, part 1
gcc 7.3.0 optimizes below code in a way that may cause a floating-point
underflow (SIGFPE with underflow flag) on x86. The underflow occurs on an
'fldl'
instruction.
It seems that no optimization should cause such behavior and as
such it would be categorized as a compiler bug, but I may be wrong here.
The code was originally compiled with gcc 4.9.2, no problem was seen in that
case.
This underflow behavior was observed when running the code in question in qemu
with KVM enabled. This means that most instructions will be executed by the
host
machine, rather than being emulated by qemu itself. If KVM is not enabled, and
thus qemu emulates the instructions, the problem is not seen.
The emulated machine in qemu is a 32-bit PC, and qemu itself is running on a
64-bit x86_64 host.
The full source file is in attachment (sqlite3.c).
Because the file is very big, and due to attachment size restrictions, I had to
gzip and split the file. Please cat the pieces together, then gunzip.
The md5sum of the source file is: 4ff9898461684927dff175c06f0df24b .
The source snippet in question is (inside function sqlite3VdbeMemStringify):
if( fg & MEM_Int ){
sqlite3_snprintf(nByte, pMem->z, "%lld", pMem->u.i);
}else{
assert( fg & MEM_Real );
sqlite3_snprintf(nByte, pMem->z, "%!.15g", pMem->u.r);
}
Here, fg is a flag value, pMem->u is a union with possible types integer (u.i)
and real (u.r).
The problem is that the loading of the real value is already done before the
result of the if-check is known. If the union 'u' happens to be an integer,
then
the loading of the real can cause an underflow.
The file is compiled with following command-line:
/home/tdescham/repo/isam/buildroot-x86/output/host/opt/ext-toolchain/bin/i686-pc-linux-gnu-gcc
--sysroot
/home/tdescham/repo/isam/buildroot-x86/output/host/i686-buildroot-linux-gnu/sysroot
-march=prescott -DPACKAGE_NAME="sqlite" -DPACKAGE_TARNAME="sqlite"
-DPACKAGE_VERSION="3.21.0" -DPACKAGE_STRING="sqlite 3.21.0"
-DPACKAGE_BUGREPORT="http://www.sqlite.org; -DPACKAGE_URL="" -DPACKAGE="sqlite"
-DVERSION="3.21.0" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
-DLT_OBJDIR=".libs/" -DHAVE_FDATASYNC=1 -DHAVE_USLEEP=1 -DHAVE_LOCALTIME_R=1
-DHAVE_GMTIME_R=1 -DHAVE_DECL_STRERROR_R=1 -DHAVE_STRERROR_R=1
-DHAVE_POSIX_FALLOCATE=1 -I. -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -D_REENTRANT=1 -DSQLITE_THREADSAFE=1
-DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -g2 -c sqlite3.c -fPIC -DPIC
-o .libs/sqlite3.o
Disassembly of the complete problematic function is below.
I marked with '#' the lines that are the problem (offsets 1c209 - 1c20d).
0001c1cb :
SQLITE_PRIVATE int sqlite3VdbeMemStringify(Mem *pMem, u8 enc, u8 bForce){
1c1cb: 55 push %ebp
1c1cc: 89 e5 mov%esp,%ebp
1c1ce: 57 push %edi
1c1cf: 56 push %esi
1c1d0: 53 push %ebx
1c1d1: 83 ec 2csub$0x2c,%esp
1c1d4: e8 fc ff ff ff call 1c1d5
1c1d9: 81 c3 02 00 00 00 add$0x2,%ebx
1c1df: 89 c6 mov%eax,%esi
1c1e1: 89 55 d8mov%edx,-0x28(%ebp)
1c1e4: 89 4d d4mov%ecx,-0x2c(%ebp)
int fg = pMem->flags;
1c1e7: 8b 40 08mov0x8(%eax),%eax
1c1ea: 66 89 45 de mov%ax,-0x22(%ebp)
if( sqlite3VdbeMemClearAndResize(pMem, nByte) ){
1c1ee: ba 20 00 00 00 mov$0x20,%edx
1c1f3: 89 f0 mov%esi,%eax
1c1f5: e8 5d bb ff ff call 17d57
1c1fa: 85 c0 test %eax,%eax
1c1fc: 74 0b je 1c209
pMem->enc = 0;
1c1fe: c6 46 0a 00 movb $0x0,0xa(%esi)
return SQLITE_NOMEM_BKPT;
1c202: bf 07 00 00 00 mov$0
[Bug other/85398] g++ reports "array subscript is above array bounds" when it cannot be sure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85398 --- Comment #3 from Thomas De Schampheleire --- (In reply to Richard Biener from comment #2) > > We could change the warning to have a "may be above array bounds" form > for your case but that wouldn't handle the bar() case. The problem with giving warnings about potential-but-not-definite issues is that projects that compile with '-Wall -Werror' assume zero warnings to guard quality. But if some warnings are false-positives, this strategy no longer works. The project will fail to compile even though it is perfectly fine. You'd need a way to tell gcc that this code is fine, or put such cases in a separate warning category that is not included in Wall or can be disabled explicitly.
[Bug other/85398] New: g++ reports "array subscript is above array bounds" when it cannot be sure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85398
Bug ID: 85398
Summary: g++ reports "array subscript is above array bounds"
when it cannot be sure
Product: gcc
Version: 6.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: patrickdepinguin at gmail dot com
Target Milestone: ---
In following test program:
--
#define NB_DEV 1
extern unsigned int max;
unsigned long left[NB_DEV];
unsigned long right[NB_DEV];
void foo()
{
unsigned int i;
for (i=1; i < max; i++)
left[i] = right[i-1];
}
--
compiled with:
$(CXX) -Werror -Wall -O2 -c reprod.cc
g++ gives following warning/error:
reprod.cc: In function 'void foo()':
reprod.cc:13:13: error: array subscript is above array bounds
[-Werror=array-bounds]
left[i] = right[i-1];
~~^
cc1plus: all warnings being treated as errors
make: *** [Makefile:4: all] Error 1
While there _could_ be an array overflow, g++ cannot know for sure because the
loop boundary 'max' is an external variable. The code is perfectly fine in case
max == 1. In that case, the loop does nothing.
This is a reduced version of real code where the arrays left and right are
dimensioned to some maximum value NB_DEV, and 'max' will be at most that NB_DEV
but possibly smaller. We are thus sure there will not be an array overflow.
Going back to the reproduction code above, if you change NB_DEV to 2 (for
example), no warning is thrown, even though there could still be an overflow in
case max == 5, for example.
According to me, no warning should be thrown because g++ cannot surely say
there is a problem.
Same problem is seen if you compile this as C code rather than C++.
Problem is not seen with -O1, only with -O2 or -O3.
This problem was tested with gcc 6.4.0 (x86_64), gcc 6.3.0 (armeb), gcc 5.4.0
(armeb) and gcc 4.9.4 (armeb).
