[Bug fortran/92311] Fortran and OpenMP use_device_ptr and OpenACC attach_ptr/dettach_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92311 --- Comment #5 from Jakub Jelinek --- (In reply to Nichols A. Romero from comment #3) > Created attachment 47156 [details] > OpenMP equivalent to OpenACC detach/attach map(from:...) means the variable is allocated, but uninitialized on the device, but you are then reading the variables and expecting them to have meaningful values. IMHO you want map(from:check_sign) and map(to:...) for the other variables. Also, at least with GCC, for optimal performance when you offload to nvptx (and would use some larger array, 100 iterations this simple certainly isn't worth offloading), you want to use simd too, so target teams distribute parallel for simd (or in OpenMP 5.0 just target teams loop).
[Bug tree-optimization/92328] [10 Regression] ICE in eliminate_stmt, at tree-ssa-sccvn.c:5497
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92328 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-02 CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r276882.
[Bug libstdc++/91906] std::timed_mutex::try_lock_until may not wait for timeout to expire when called with user-defined clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91906 --- Comment #2 from Mike Crowe --- v2 series posted at https://gcc.gnu.org/ml/libstdc++/2019-10/msg00055.html .
[Bug libstdc++/78237] std::timed_mutex::try_lock_for/until affected by system realtime clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78237 Mike Crowe changed: What|Removed |Added Target Milestone|--- |10.0
[Bug libstdc++/91906] std::timed_mutex::try_lock_until may not wait for timeout to expire when called with user-defined clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91906 Mike Crowe changed: What|Removed |Added Target Milestone|--- |10.0
[Bug libstdc++/78237] std::timed_mutex::try_lock_for/until affected by system realtime clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78237 --- Comment #4 from Mike Crowe --- v2 series posted at https://gcc.gnu.org/ml/libstdc++/2019-10/msg00055.html .
[Bug c++/66099] _Pragma diagnostic 'ignored' in macro with strict-overflow not suppressing warning fully with -Werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66099 Manuel López-Ibáñez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Manuel López-Ibáñez --- Wstrict-overflow was deprecated in GCC 8 and nothing replaced it. So this bug cannot reproduced or fixed anymore.
[Bug middle-end/92330] New: Wstrict-overflow documentation does not say that it is deprecated and has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92330 Bug ID: 92330 Summary: Wstrict-overflow documentation does not say that it is deprecated and has no effect Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: manu at gcc dot gnu.org CC: msebor at gcc dot gnu.org, rguenth at gcc dot gnu.org Target Milestone: --- According to GCC 8, Wstrict-overflow is deprecated. However, the documentation of the warning says nothing about this, not even in trunk: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstrict-overflow Also, there are many open bugs about Wstrict-overflow. Should those be closed?
[Bug c++/55881] #pragma GCC diagnostic ignored ignored when inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55881 Manuel López-Ibáñez changed: What|Removed |Added Last reconfirmed|2013-01-07 00:00:00 |2019-11-2 --- Comment #8 from Manuel López-Ibáñez --- : In function 'int main(int, char**)': :6:15: warning: 'n' may be used uninitialized in this function [-Wmaybe-uninitialized] 6 | return n->i + 10; |~~~^ :14:16: note: 'n' was declared here 14 | struct I i, *n; |^ Still valid. The main issue is that the stack of inlining locations is lost. Once that is recovered the #pragma can check whether any location in the stack is within the range and act.
[Bug tree-optimization/91890] [10 Regression] -Warray-bounds warning testing glibc not suppressed by pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91890 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez --- (In reply to Martin Sebor from comment #1) > Confirmed. The diagnostic pragmas don't work very well for the middle-end > warnings (e.g., with inlining, as discussed in bug 55881). In this test > case, moving the #pragma GCC diagnostic ignored above the strcpy calls does > the trick. I haven't looked into why. Something similar was reported in > bug 66099. Manu had some ideas for how to make it work more reliably but I > haven't had the time to work on it and don't expect to for GCC 10. I don't think this is the same issue. In this case, the diagnostic is emitted within the range affected by the #pragma. In those other cases, the location at which the warning is emitted is not within the range silenced by the #pragma (due to middle-end transformations or inlining) so there is no way the #pragma can silence it.
[Bug middle-end/92330] Wstrict-overflow documentation does not say that it is deprecated and has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92330 --- Comment #1 from Manuel López-Ibáñez --- Actually, it is not even deprecated. There are still a bunch of Wstrict-overflow warnings, just some of them got removed. Is there a way to tell which ones are still active and update the documentation? https://github.com/gcc-mirror/gcc/search?q=OPT_Wstrict_overflow&unscoped_q=OPT_Wstrict_overflow
[Bug tree-optimization/91890] [10 Regression] -Warray-bounds warning testing glibc not suppressed by pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91890
--- Comment #4 from Manuel López-Ibáñez ---
I'm 100% convinced this has nothing to do with locations and all to do with how
-Warray-bounds and -Wstringop-overflow= interact.
Change the ignored for error,
char one[50];
char two[50];
void
test_strncat (void)
{
(void) __builtin_strcpy (one, "gh");
(void) __builtin_strcpy (two, "ef");
#pragma GCC diagnostic ignored "-Wstringop-overflow"
#pragma GCC diagnostic error "-Warray-bounds"
(void) __builtin_strncat (one, two, 99);
}
and run with -Wall -O2 -Wno-array-bounds and we get:
:10:28: error: 'char* __builtin_strncat(char*, const char*, long
unsigned int)' forming offset [50, 98] is out of the bounds [0, 50] of object
'one' with type 'char [50]' [-Werror=array-bounds]
so the #pragma has an effect, but there is something weird with ignored and
-Wstringop-overflow interaction.
[Bug tree-optimization/91890] [10 Regression] -Warray-bounds warning testing glibc not suppressed by pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91890
--- Comment #5 from Manuel López-Ibáñez ---
333 Warray-bounds
334 LangEnabledBy(C ObjC C++ LTO ObjC++)
335 ; in common.opt
This seems wrong, the second argument ", Wall" is missing. Moreover, this
probably should be an Alias for some -Warray-bounds= option.
Nevertheless, there is indeed something weird going on with the locations of
the #pragma:
char one[50];
char two[50];
void
test_strncat (void)
{
#pragma GCC diagnostic error "-Warray-bounds"
(void) __builtin_strncat (one, two, 99);
(void) __builtin_strcpy (one, "gh");
#pragma GCC diagnostic warning "-Warray-bounds"
(void) __builtin_strcpy (two, "ef");
(void) __builtin_strncat (one, two, 99);
}
// -O2 -Warray-bounds
gives 2 errors. It seems that if the #pragma is at the start of the function,
it has effect, otherwise it doesn't.
[Bug rtl-optimization/92331] New: ICE on incorrect code with VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92331
Bug ID: 92331
Summary: ICE on incorrect code with VLA
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: coillol at yandex dot ru
Target Milestone: ---
The following text triggers ICE in gcc (at least on 9.2.0 and trunk --
https://godbolt.org/z/WHnZCJ):
int foo();
int main() {
using X = int[foo()];
struct S { S() { X x; } } s;
}
Compiling it using gcc-9.2.0 with no additional options gives this stacktrace:
during RTL pass: expand
doublekill.cpp: In constructor ‘main()::S::S()’:
doublekill.cpp:4:22: internal compiler error: in expand_expr_real_1, at
expr.c:10012
4 | using X = int[foo()];
| ^
0x5c5d88 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../.././gcc/expr.c:10012
0x8eb0ab store_expr(tree_node*, rtx_def*, int, bool, bool)
../.././gcc/expr.c:5674
0x8ec2b0 expand_assignment(tree_node*, tree_node*, bool)
../.././gcc/expr.c:5436
0x7ee5a8 expand_gimple_stmt_1
../.././gcc/cfgexpand.c:3752
0x7ee5a8 expand_gimple_stmt
../.././gcc/cfgexpand.c:3850
0x7f34bf expand_gimple_basic_block
../.././gcc/cfgexpand.c:5890
0x7f583e execute
../.././gcc/cfgexpand.c:6513
[Bug c++/90058] False Positive in undefined-sanitizer only with GCC8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90058 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez --- Without a reduced testcase, this is basically un-debug-able. https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
[Bug c++/89976] missing uninitialized warning for uninitialized struct member (VOPs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89976
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-11-02
CC||manu at gcc dot gnu.org
Depends on||49754, 79658
Summary|missing uninitialized |missing uninitialized
|warning: laundering via |warning for uninitialized
|passing object through a|struct member (VOPs)
|function|
Ever confirmed|0 |1
--- Comment #3 from Manuel López-Ibáñez ---
I guess it doesn't warn because it gets converted to memory access.
bar ()
{
int x$x;
int _1;
[local count: 1073741825]:
# DEBUG BEGIN_STMT
# DEBUG BEGIN_STMT
# DEBUG this => &x
# DEBUG D#1 => {CLOBBER}
# DEBUG x$x => D#1
# DEBUG D#2 => {CLOBBER}
# DEBUG x$y => D#2
# DEBUG x$y => 0
# DEBUG this => NULL
# DEBUG BEGIN_STMT
# DEBUG D#3 => {CLOBBER}
# DEBUG x$x => D#3
# DEBUG D#4 => {CLOBBER}
# DEBUG x$y => D#4
# DEBUG x$x => x$x_3(D)
# DEBUG x$y => 0
# DEBUG x$x => NULL
# DEBUG BEGIN_STMT
_1 = x$x_3(D) + 2;
# DEBUG x$x => _1
# DEBUG BEGIN_STMT
# DEBUG D#5 => {CLOBBER}
# DEBUG x$x => D#5
return _1;
}
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49754
[Bug 49754] Wuninitialized does not work with structs/unions/arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79658
[Bug 79658] [-Wuninitialized] referencing uninitialized field of POD struct
should warn
[Bug tree-optimization/89202] missing -Wnonnull-dereference or -Wuninitialized for a certain bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89202 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-02 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez --- For the Wuninit, this is PR18501
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 89192, which changed state. Bug 89192 Summary: -Wuninitialized doesn't warn about a vector initialization with uninitialized field https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89192 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808 Manuel López-Ibáñez changed: What|Removed |Added CC||Hi-Angel at yandex dot ru --- Comment #46 from Manuel López-Ibáñez --- *** Bug 89192 has been marked as a duplicate of this bug. ***
[Bug c++/89192] -Wuninitialized doesn't warn about a vector initialization with uninitialized field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89192 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Manuel López-Ibáñez --- Duplicated *** This bug has been marked as a duplicate of bug 19808 ***
[Bug rtl-optimization/92331] ICE on incorrect code with VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92331 Eric Gallager changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code CC||egallager at gcc dot gnu.org Blocks||16994 Severity|normal |minor Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994 [Bug 16994] [meta-bug] VLA and C++
[Bug middle-end/88175] Showing header file instead of source code line for uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #16 from Manuel López-Ibáñez ---
Reduced testcase for "-Wall -O1" (with -O2 the copy is now elided and we hit
missing warning bugs)
struct string {
char *data;
string() : data(0) {};
string(const string &x) : data(x.data) {};
};
typedef struct info
{
int registered;
string dummy;
} info_t;
void test(info_t temp)
{
info_t copy;
temp = copy;
__builtin_printf("%d\n", copy.registered);
}
int main()
{
info_t temp;
test(temp);
}
(In reply to Jonny Grant from comment #15)
> Does the implicitly created copy-constructor get saved to a file at all? Or
> can it be saved to a file like -save-temps does?
No, it doesn't. It is not generated as C++ code.
(In reply to Jonny Grant from comment #13)
> Where there is an implicit copy constructor, it shows the wrong file, and
> wrong function.
It is not the wrong function, it is where tem.info()::registered is declared.
This is what happens when there is no location for the use. No location happens
here because the unintialized use happens within the implicit copy constructor
and there is source code to show for that.
https://godbolt.org/z/BPyIMe
[./example.cpp:7:16] # .MEM_6 = VDEF <.MEM_4(D)>
[./example.cpp:7:16] *this_5(D) ={v} {CLOBBER};
[./example.cpp:7:16] # VUSE <.MEM_6>
_1 = _7(D)->registeredD.2353;
[./example.cpp:7:16] # .MEM_8 = VDEF <.MEM_6>
[./example.cpp:7:16] this_5(D)->registeredD.2353 = _1;
The above is what GCC sees at the time of warning.
(In reply to Jonny Grant from comment #14)
> Wondering, if there is an implicitly created copy-constructor, can the
> warning clarify that? Perhaps there is some attribute or flag set so later
> code can know it was implicitly created?
Probably yes. Even if the info is lost, it is easy to check that the location
of the declaration of the copy-constructor is exactly the same as the location
of the class, indicating that it was implicitly created. More useful would be
to not warn within the implicit constructor but somehow pass the uninitialized
info back to the caller and warn there.
Warning within artificial code is mostly useless for users.
[Bug c++/92332] New: invalid optimization in certain situations involving placement new on i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92332
Bug ID: 92332
Summary: invalid optimization in certain situations involving
placement new on i686
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cbcode at gmail dot com
Target Milestone: ---
Created attachment 47157
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47157&action=edit
minimal example showing problem
See code below and attached (running ubuntu linux on intel).
g++-9 -m64 compiles and runs fine, all optimization levels.
g++-9 -m32 -O1 and below compile and run fine.
g++-9 -m32 -O2 and above generate incorrect warning and incorrect code.
g++-8 (8.3.0) behaves same as g++-9.
#include
#include
#include
using std::size_t;
using std::uint32_t;
using std::uint64_t;
template struct myarray {
T data[N];
};
myarray mul(uint32_t a, uint32_t b) noexcept {
alignas(uint64_t) myarray ab;
#if 1 //no bug for #if 0
::new(&ab) uint64_t(uint64_t(a) * b);
#else
uint64_t const c = uint64_t(a) * b;
ab.data[0] = uint32_t(c); ab.data[1] = uint32_t(c >> 32);
#endif
return ab;
}
struct bar : myarray {
bar& operator+=(uint32_t a) noexcept {
this->data[0] += a; //no bug when commented out
this->data[1] += a; //no bug when commented out
return *this;
}
};
struct foo : myarray {
foo() noexcept {
static_cast(*::new(this) myarray(mul(0xdeadbeef,
0xdeadbeef))) += 1;
}
};
int main() {
foo f;
std::printf("0x%x, 0x%x\n", f.data[0], f.data[1]);
std::printf("0x%x, 0x%x\n", 0x216da322, 0xc1b1cd13);
return 0;
}
/*
$ g++-9 -m64 -Wall -O2 -o bug bug.cpp //OK
$ g++-9 -m32 -Wall -O1 -o bug bug.cpp //Ok
$ g++-9 -m32 -Wall -O2 -o bug bug.cpp
bug.cpp: In function ‘int main()’:
bug.cpp:24:23: warning: ‘f.bar::.myarray::data[0]’
is used uninitialized in this function [-Wuninitiali
24 | this->data[0] += a; //no bug when commented out
| ~~^~~~
bug.cpp:35:9: note: ‘f.bar::.myarray::data[0]’ was
declared here
35 | foo f;
| ^
bug.cpp:25:23: warning: ‘f.bar::.myarray::data[1]’
is used uninitialized in this function [-Wuninitiali
25 | this->data[1] += a; //no bug when commented out
| ~~^~~~
bug.cpp:35:9: note: ‘f.bar::.myarray::data[1]’ was
declared here
35 | foo f;
| ^
*/
[Bug c++/92332] invalid optimization in certain situations involving placement new on i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92332 --- Comment #1 from Andrew Pinski --- two things, One is you are violating C++ aliasing rules I think. Second is after "operator new", the value that is contained in the pointer is undefined/unspecified. NOTE in C++2a (or c++20), there is an operator new which has the property of the value is kept defined. (BUT GCC Does not implement that yet).
[Bug c++/66670] "template argument deduction/substitution failed" with function pointers and multiple parameter packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66670
schlaffi at users dot sourceforge.net changed:
What|Removed |Added
CC||schlaffi at users dot
sourceforge.
||net
--- Comment #3 from schlaffi at users dot sourceforge.net ---
This still affects g++ 9.2.1.
clang fixed this between 6.0.0 and 7.0.0, icc 13 and msvc 19 also work.
This has nothing to do with class functions:
static void foo( int, int ) { }
template
void bar1( void ( * )( int, T... ) ) { }
template
void bar2( void ( * )( T..., int ) ) { }
int main() {
bar1( foo );
bar2( foo );
}
Because we have twice "int" in foo, the error message is slightly different:
arg_deduct.cc: In function ‘int main()’:
arg_deduct.cc:11:18: error: no matching function for call to ‘bar2(void
(&)(int, int))’
11 | bar2( foo );
| ^
arg_deduct.cc:7:6: note: candidate: ‘template void bar2(void (*)(T
..., int))’
7 | void bar2( void ( * )( T..., int ) ) { }
| ^~~~
arg_deduct.cc:7:6: note: template argument deduction/substitution failed:
arg_deduct.cc:11:18: note: candidate expects 1 argument, 2 provided
11 | bar2( foo );
| ^
The analogous construction with classes works like charm:
template
struct Foo {};
static Foo foo;
template typename C>
void bar1( C ) {}
template typename C>
void bar2( C ) {}
int main() {
bar1( foo );
bar2( foo );
}
[Bug middle-end/92333] New: missing variable name referencing VLA in warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92333
Bug ID: 92333
Summary: missing variable name referencing VLA in warnings
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
When referencing a VLA in late warnings like -Warray-bounds or
-Wstringop-overflow GCC neglects to mention the VLA's name or point at its
declaration, instead printing the generic like ‘({anonymous})’ because the VLA
is a DECL with no name and pointing to the closing curly brace of the function
body.
$ cat z.c && gcc -O2 -S -Wall z.c
const int a[] = { 1, 2, 3, 4, 5 };
void f (void*);
void g (void)
{
unsigned nelts = sizeof a / sizeof *a;
char vla[nelts];
__builtin_memcpy (vla, a, nelts * sizeof *a);
f (vla);
}
void h (void)
{
const int a[] = { 1, 2, 3, 4, 5 };
unsigned nelts = sizeof a / sizeof *a;
char vla[nelts];
__builtin_memcpy (vla, a, nelts * sizeof *a);
f (vla);
}
z.c: In function ‘g’:
z.c:9:3: warning: writing 20 bytes into a region of size 5
[-Wstringop-overflow=]
9 | __builtin_memcpy (vla, a, nelts * sizeof *a);
| ^~~~
z.c:20:1: note: destination object declared here
20 | }
| ^
z.c: In function ‘h’:
z.c:18:3: warning: array subscript 2 is outside array bounds of ‘unsigned
char[5]’ [-Warray-bounds]
18 | __builtin_memcpy (vla, a, nelts * sizeof *a);
| ^~~~
z.c:20:1: note: while referencing ‘({anonymous})’
20 | }
| ^
z.c:18:3: warning: array subscript 3 is outside array bounds of ‘unsigned
char[5]’ [-Warray-bounds]
18 | __builtin_memcpy (vla, a, nelts * sizeof *a);
| ^~~~
z.c:20:1: note: while referencing ‘({anonymous})’
20 | }
| ^
z.c:18:3: warning: array subscript 4 is outside array bounds of ‘unsigned
char[5]’ [-Warray-bounds]
18 | __builtin_memcpy (vla, a, nelts * sizeof *a);
| ^~~~
z.c:20:1: note: while referencing ‘({anonymous})’
20 | }
| ^
z.c:18:3: warning: writing 4 bytes into a region of size 1
[-Wstringop-overflow=]
18 | __builtin_memcpy (vla, a, nelts * sizeof *a);
| ^~~~
z.c:20:1: note: destination object declared here
20 | }
| ^
[Bug middle-end/92333] missing variable name referencing VLA in warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92333
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2019-11-02
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
The otherwise untested change below changes the output to:
gcc -O2 -S -Wall pr92333.c
pr92333.c: In function ‘g’:
pr92333.c:9:3: warning: writing 20 bytes into a region of size 5
[-Wstringop-overflow=]
9 | __builtin_memcpy (vla, a, nelts * sizeof *a);
| ^~~~
pr92333.c:8:8: note: at offset 0 to object ‘vla.10’ with size 5 declared here
8 | char vla[nelts];
|^~~
pr92333.c: In function ‘h’:
pr92333.c:18:3: warning: array subscript 2 is outside array bounds of ‘unsigned
char[5]’ [-Warray-bounds]
18 | __builtin_memcpy (vla, a, nelts * sizeof *a);
| ^~~~
pr92333.c:17:8: note: while referencing ‘vla.12’
17 | char vla[nelts];
|^~~
pr92333.c:18:3: warning: array subscript 3 is outside array bounds of ‘unsigned
char[5]’ [-Warray-bounds]
18 | __builtin_memcpy (vla, a, nelts * sizeof *a);
| ^~~~
pr92333.c:17:8: note: while referencing ‘vla.12’
17 | char vla[nelts];
|^~~
pr92333.c:18:3: warning: array subscript 4 is outside array bounds of ‘unsigned
char[5]’ [-Warray-bounds]
18 | __builtin_memcpy (vla, a, nelts * sizeof *a);
| ^~~~
pr92333.c:17:8: note: while referencing ‘vla.12’
17 | char vla[nelts];
|^~~
pr92333.c:18:3: warning: writing 4 bytes into a region of size 1
[-Wstringop-overflow=]
18 | __builtin_memcpy (vla, a, nelts * sizeof *a);
| ^~~~
pr92333.c:17:8: note: at offset 0 to object ‘vla.12’ with size 5 declared here
17 | char vla[nelts];
|^~~
diff --git a/gcc/tree-ssa-ccp.c b/gcc/tree-ssa-ccp.c
index a8d0738fbb0..567aef8bc26 100644
--- a/gcc/tree-ssa-ccp.c
+++ b/gcc/tree-ssa-ccp.c
@@ -,7 +,25 @@ fold_builtin_alloca_with_align (gimple *stmt)
elem_type = build_nonstandard_integer_type (BITS_PER_UNIT, 1);
n_elem = size * 8 / BITS_PER_UNIT;
array_type = build_array_type_nelts (elem_type, n_elem);
- var = create_tmp_var (array_type);
+
+ if (tree ssa_name = SSA_NAME_IDENTIFIER (lhs))
+{
+ /* Give the temporary a name derived from the name of the VLA
+declaration so it can be referenced in diagnostics. */
+ const char *name = IDENTIFIER_POINTER (ssa_name);
+ var = create_tmp_var (array_type, name);
+}
+ else
+var = create_tmp_var (array_type);
+
+ if (gimple *lhsdef = SSA_NAME_DEF_STMT (lhs))
+{
+ /* Set the temporary's location to that of the VLA declaration
+so it can be pointed to in diagnostics. */
+ location_t loc = gimple_location (lhsdef);
+ DECL_SOURCE_LOCATION (var) = loc;
+}
+
SET_DECL_ALIGN (var, TREE_INT_CST_LOW (gimple_call_arg (stmt, 1)));
if (uid != 0)
SET_DECL_PT_UID (var, uid);
[Bug middle-end/92334] New: incorrect __builtin_object_size result for negative offsets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92334
Bug ID: 92334
Summary: incorrect __builtin_object_size result for negative
offsets
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
When the pointer argument to __builtin_object_size() is at a negative offset
from the beginning of an object the function seems to return the sum of the
absolute value of the offset and the size of the object rather than zero, thus
defeating the _FORTIFY_SOURCE protection against out of bounds writes. The
-Warray-bounds and -Wstringop-overflow warnings do detect some of these bugs.
$ cat z.c && gcc -O2 -S -Wall -fdump-tree-strlen=/dev/stdout z.c
void sink (void*);
void f (const void *p)
{
int i = -7;
char a[3];
char *q = a + i;
__builtin___memcpy_chk (q, p, 10, __builtin_object_size (p, 1));
sink (a);
}
void g (const void *p)
{
int i = -7;
char a[3];
char *q = a + i;
__builtin___memcpy_chk (q, p, 13, __builtin_object_size (p, 1));
sink (a);
}
z.c: In function ‘f’:
z.c:8:9: warning: array subscript -7 is outside array bounds of ‘char[3]’
[-Warray-bounds]
8 | char *q = a + i;
| ^
z.c:7:8: note: while referencing ‘a’
7 | char a[3];
|^
;; Function f (f, funcdef_no=0, decl_uid=1932, cgraph_uid=1, symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
f (const void * p)
{
char a[3];
[local count: 1073741824]:
__builtin_memcpy (&MEM [(void *)&a + -7B], p_3(D), 10);
sink (&a);
a ={v} {CLOBBER};
return;
}
z.c: In function ‘g’:
z.c:20:9: warning: array subscript -7 is outside array bounds of ‘char[3]’
[-Warray-bounds]
20 | char *q = a + i;
| ^
z.c:19:8: note: while referencing ‘a’
19 | char a[3];
|^
;; Function g (g, funcdef_no=1, decl_uid=1938, cgraph_uid=2, symbol_order=1)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
g (const void * p)
{
char a[3];
[local count: 1073741824]:
__builtin_memcpy (&MEM [(void *)&a + -7B], p_3(D), 13);
sink (&a);
a ={v} {CLOBBER};
return;
}
z.c:22:3: warning: ‘__builtin_memcpy’ writing 13 bytes into a region of size 10
overflows the destination [-Wstringop-overflow=]
22 | __builtin___memcpy_chk (q, p, 13, __builtin_object_size (p, 1));
| ^~~
[Bug middle-end/92334] incorrect __builtin_object_size result for negative offsets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92334
--- Comment #1 from Martin Sebor ---
Whoops. There's a typo in the test case in comment #0 (wrong pointer passed to
__builtin_object_size). Here's a corrected test case:
$ cat z.c && gcc -O2 -S -Wall -fdump-tree-strlen=/dev/stdout z.c
void sink (void*);
void f (const void *p)
{
int i = -7;
char a[3];
char *q = a + i;
__builtin___memcpy_chk (q, p, 10, __builtin_object_size (q, 1));
sink (a);
}
void g (const void *p)
{
int i = -7;
char a[3];
char *q = a + i;
__builtin___memcpy_chk (q, p, 13, __builtin_object_size (q, 1));
sink (a);
}
z.c: In function ‘f’:
z.c:8:9: warning: array subscript -7 is outside array bounds of ‘char[3]’
[-Warray-bounds]
8 | char *q = a + i;
| ^
z.c:7:8: note: while referencing ‘a’
7 | char a[3];
|^
;; Function f (f, funcdef_no=0, decl_uid=1932, cgraph_uid=1, symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
f (const void * p)
{
char a[3];
[local count: 1073741824]:
__builtin_memcpy (&MEM [(void *)&a + -7B], p_2(D), 10);
sink (&a);
a ={v} {CLOBBER};
return;
}
z.c: In function ‘g’:
z.c:20:9: warning: array subscript -7 is outside array bounds of ‘char[3]’
[-Warray-bounds]
20 | char *q = a + i;
| ^
z.c:19:8: note: while referencing ‘a’
19 | char a[3];
|^
;; Function g (g, funcdef_no=1, decl_uid=1938, cgraph_uid=2, symbol_order=1)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
g (const void * p)
{
char a[3];
[local count: 1073741824]:
__builtin___memcpy_chk (&MEM [(void *)&a + -7B], p_2(D), 13, 10);
sink (&a);
a ={v} {CLOBBER};
return;
}
z.c:22:3: warning: ‘__builtin___memcpy_chk’ writing 13 bytes into a region of
size 10 overflows the destination [-Wstringop-overflow=]
22 | __builtin___memcpy_chk (q, p, 13, __builtin_object_size (q, 1));
| ^~~
[Bug middle-end/92334] incorrect __builtin_object_size result for negative offsets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92334 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Andrew Pinski --- > int i = -7; char a[3]; char *q = a + i; The value of q is undefined and is officially not pointing to any object.
