[Bug c++/110681] bogus warning -Wreturn-type for lambda in tparam list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110681 Andrew Pinski changed: What|Removed |Added Keywords||c++-lambda Blocks||107430 --- Comment #1 from Andrew Pinski --- Lambda inside a decltype definitely one place where GCC is known to be broken. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107430 [Bug 107430] [meta-bug] lambda in decltype
[Bug c++/110681] New: bogus warning -Wreturn-type for lambda in tparam list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110681 Bug ID: 110681 Summary: bogus warning -Wreturn-type for lambda in tparam list Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eric.niebler at gmail dot com Target Milestone: --- The following valid C++20 code causes gcc trunk to erroneously warn about a missing return statement. template constexpr auto y = X; template using C = decltype(y<>); using D = C; : In substitution of 'template using C = decltype (y< >) [with T = int]': :27:18: required from here :21:22: warning: no return statement in function returning non-void [-Wreturn-type] 21 | template | ^~~~ Compiler returned: 0
[Bug c++/110680] erroneous error "non-template type 'C' used as a template"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110680 Andrew Pinski changed: What|Removed |Added Blocks||107430 Keywords||c++-lambda --- Comment #1 from Andrew Pinski --- I bet there is already a dup of this one. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107430 [Bug 107430] [meta-bug] lambda in decltype
[Bug c++/110680] New: erroneous error "non-template type 'C' used as a template"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110680
Bug ID: 110680
Summary: erroneous error "non-template type 'C' used as a
template"
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
The following valid C++20 is rejected by gcc trunk:
template
struct S {
auto f() { return X; }
};
template
using C = decltype(S().f());
using D = C;
:29:16: error: non-template type 'C' used as a template
29 | using D = C;
|^
Compiler returned: 1
https://godbolt.org/z/b3eY8fWTv
[Bug tree-optimization/95923] Failure to optimize bool checks into and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95923 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > So there are some patterns for non boolean as for boolean values ~(a^b) is > converted to a==b so we need to support the == case for these: The non-boolean ones were originally added by r8-4395-ge268a77b59cb78
[Bug tree-optimization/95923] Failure to optimize bool checks into and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95923 --- Comment #4 from Andrew Pinski --- So there are some patterns for non boolean as for boolean values ~(a^b) is converted to a==b so we need to support the == case for these: ``` /* (a | b) & ~(a ^ b) --> a & b */ (simplify (bit_and:c (bit_ior @0 @1) (bit_not (bit_xor:c @0 @1))) (bit_and @0 @1)) /* a | ~(a ^ b) --> a | ~b */ (simplify (bit_ior:c @0 (bit_not:s (bit_xor:c @0 @1))) (bit_ior @0 (bit_not @1))) /* (a & b) | ~(a ^ b) --> ~(a ^ b) */ (simplify (bit_ior:c (bit_and:c @0 @1) (bit_not@2 (bit_xor @0 @1))) @2) ``` So mine.
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #8 from Xi Ruoyao ---
In local-fnsummary2:
__attribute__((always_inline, target ("avx2")))
void aa::aa (struct aa * const this)
{
[local count: 1073741824]:
return;
}
this seems correct. But:
void __static_initialization_and_destruction_0 ()
{
:
aa::aa (&_M_impl);
return;
}
Note that __static_initialization_and_destruction_0 is not attributed with
avx2.
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 Xi Ruoyao changed: What|Removed |Added CC||gcc.gnu.org at aryanc403 dot com --- Comment #7 from Xi Ruoyao --- *** Bug 110675 has been marked as a duplicate of this bug. ***
[Bug target/110675] Using std::set with avx2 pragma is broken on latest gcc version (compilation fails)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110675 Xi Ruoyao changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Xi Ruoyao --- Now I think it's definitely PR109753 (considering the simple reduced test case in PR109753)... *** This bug has been marked as a duplicate of bug 109753 ***
[Bug tree-optimization/110679] Missed optimization opportunity with countr_zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110679
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-07-15
Target||x86_64-linux-gnu
Component|middle-end |tree-optimization
Keywords||missed-optimization
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Confirmed, simplified testcase:
```
int tst(unsigned char &x) {
if (!x) return 8;
return __builtin_ctz(x);
}
int tst1(unsigned char &x) {
unsigned t = x;
t |= 256;
return __builtin_ctz(t);
}
```
Something like:
```
(simplify
(cond
(ne @0 integer_zerop)
(CTZ (convert@2 @0))
(INTEGER_CST@1))
(if (TYPE_UNSIGNED (TREE_TYPE (@0))
&& TYPE_PRECISION (TREE_TYPE (@0)) < TYPE_PRECISION (type)
&& wi::to_wide (@1) == TYPE_PRECISION (TREE_TYPE (@0)))
(CTZ (bit_ior @2 { build_int_cst (1u << (TYPE_PRECISION (TREE_TYPE (@0)) -
1), TREE_TYPE (@2)); }))
```
Note this is not exactly correct as `1u <<` won't work always, need to use
wide_int with the type precision of type.
Also it won't work as phiopt does not handle the extra cast yet.
[Bug c++/110679] New: Missed optimization opportunity with countr_zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110679
Bug ID: 110679
Summary: Missed optimization opportunity with countr_zero
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.yaroshevskij at gmail dot com
Target Milestone: ---
Clang better optimizes the following code:
```
int tst(std::uint8_t x) {
if (!x) return 8;
return std::countr_zero(x);
}
```
https://godbolt.org/z/dqr5Eddn4
[Bug gcov-profile/110678] New: UBSAN error: signed integer overflow: 249946095246429448 * 100 cannot be represented in type 'long int' when compiling pr103513.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110678 Bug ID: 110678 Summary: UBSAN error: signed integer overflow: 249946095246429448 * 100 cannot be represented in type 'long int' when compiling pr103513.c Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org Blocks: 63426 Target Milestone: --- Host: x86_64-linux-gnu Target: x86_64-linux-gnu With master revision r14-2537-g18dac101678b8c and ubsan-bootstrapped compiler, I am getting the following error when compiling our own test gcc/testsuite/gcc.c-torture/compile/pr103513.c: worker@tiber:~/buildworker/tiber-gcc-ubsan/objdir/gcc> UBSAN_OPTIONS="halt_on_error=1 print_stacktrace=1" /home/worker/buildworker/tiber-gcc-ubsan/objdir/gcc/xgcc -B/home/worker/buildworker/tiber-gcc-ubsan/objdir/gcc/ -fdiagnostics-plain-output -O2 -w -c -o /tmp/pr103513.o /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/testsuite/gcc.c-torture/compile/pr103513.c /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/profile-count.cc:137:34: runtime error: signed integer overflow: 249946095246429448 * 100 cannot be represented in type 'long int' #0 0x22e0cd7 in profile_count::differs_from_p(profile_count) const /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/profile-count.cc:137 #1 0x226f90d in rebuild_frequencies() /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/predict.cc:4352 #2 0x22706ec in execute /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/predict.cc:4446 #3 0x21c9400 in execute_one_pass(opt_pass*) /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/passes.cc:2648 #4 0x21cc0d4 in execute_pass_list_1 /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/passes.cc:2757 #5 0x21cc11b in execute_pass_list_1 /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/passes.cc:2758 #6 0x21cc1e5 in execute_pass_list(function*, opt_pass*) /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/passes.cc:2768 #7 0x10f8076 in cgraph_node::expand() /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/cgraphunit.cc:1841 #8 0x10f8076 in cgraph_node::expand() /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/cgraphunit.cc:1794 #9 0x110a24f in expand_all_functions /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/cgraphunit.cc:2024 #10 0x110a24f in symbol_table::compile() /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/cgraphunit.cc:2398 #11 0x110a24f in symbol_table::compile() /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/cgraphunit.cc:2309 #12 0x110af4a in symbol_table::finalize_compilation_unit() /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/cgraphunit.cc:2583 #13 0x27753b1 in compile_file /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/toplev.cc:471 #14 0xa726f5 in do_compile /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/toplev.cc:2126 #15 0xa726f5 in toplev::main(int, char**) /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/toplev.cc:2282 #16 0xa75821 in main /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/main.cc:39 #17 0x7f1ef8817baf in __libc_start_call_main (/lib64/libc.so.6+0x27baf) (BuildId: 1390809fc3a065502adfa6735d294c2c86aebe4d) #18 0x7f1ef8817c78 in __libc_start_main_alias_1 (/lib64/libc.so.6+0x27c78) (BuildId: 1390809fc3a065502adfa6735d294c2c86aebe4d) #19 0xa75c64 in _start ../sysdeps/x86_64/start.S:115 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug fortran/110677] New: UBSAN error: load of value 1818451807, which is not a valid value for type 'expr_t' when compiling pr49213.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110677 Bug ID: 110677 Summary: UBSAN error: load of value 1818451807, which is not a valid value for type 'expr_t' when compiling pr49213.f90 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org Blocks: 63426 Target Milestone: --- Host: x86_64-linux-gnu Target: x86_64-linux-gnu With master revision r14-2537-g18dac101678b8c and ubsan-bootstrapped compiler, I am getting the following error when compiling our own test gcc/testsuite/gfortran.dg/pr49213.f90: worker@tiber:~/buildworker/tiber-gcc-ubsan/objdir/gcc> UBSAN_OPTIONS="halt_on_error=1 print_stacktrace=1" /home/worker/buildworker/tiber-gcc-ubsan/objdir/gcc/testsuite/gfortran3/../../gfortran -B/home/worker/buildworker/tiber-gcc-ubsan/objdir/gcc/testsuite/gfortran3/../../ -B/home/worker/buildworker/tiber-gcc-ubsan/objdir/x86_64-pc-linux-gnu/./libgfortran/ /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/testsuite/gfortran.dg/pr49213.f90 -fdiagnostics-plain-output -fdiagnostics-plain-output -O0 -pedantic-errors -B/home/worker/buildworker/tiber-gcc-ubsan/objdir/x86_64-pc-linux-gnu/./libgfortran/.libs -L/home/worker/buildworker/tiber-gcc-ubsan/objdir/x86_64-pc-linux-gnu/./libgfortran/.libs -L/home/worker/buildworker/tiber-gcc-ubsan/objdir/x86_64-pc-linux-gnu/./libgfortran/.libs -L/home/worker/buildworker/tiber-gcc-ubsan/objdir/x86_64-pc-linux-gnu/./libatomic/.libs -B/home/worker/buildworker/tiber-gcc-ubsan/objdir/x86_64-pc-linux-gnu/./libquadmath/.libs -L/home/worker/buildworker/tiber-gcc-ubsan/objdir/x86_64-pc-linux-gnu/./libquadmath/.libs -L/home/worker/buildworker/tiber-gcc-ubsan/objdir/x86_64-pc-linux-gnu/./libquadmath/.libs -lm -o /tmp/pr49213.exe /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/fortran/resolve.cc:1401:30: runtime error: load of value 1818451807, which is not a valid value for type 'expr_t' #0 0x79124e in resolve_structure_cons /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/fortran/resolve.cc:1401 #1 0xda4d76 in resolve_generic_f /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/fortran/resolve.cc:2852 #2 0xda4d76 in resolve_function /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/fortran/resolve.cc:3367 #3 0xda839e in gfc_resolve_expr(gfc_expr*) /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/fortran/resolve.cc:7313 #4 0xda839e in gfc_resolve_expr(gfc_expr*) /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/fortran/resolve.cc:7275 #5 0xdef0e0 in gfc_resolve_code(gfc_code*, gfc_namespace*) /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/fortran/resolve.cc:12314 #6 0xdfe227 in resolve_codes /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/fortran/resolve.cc:18027 #7 0xdfe09a in resolve_codes /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/fortran/resolve.cc:18008 #8 0xd8965a in gfc_resolve(gfc_namespace*) /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/fortran/resolve.cc:18062 #9 0xd8965a in gfc_resolve(gfc_namespace*) /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/fortran/resolve.cc:18041 #10 0xd3f387 in resolve_all_program_units /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/fortran/parse.cc:6862 #11 0xd3f387 in gfc_parse_file() /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/fortran/parse.cc:7118 #12 0xed0bfe in gfc_be_parse_file /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/fortran/f95-lang.cc:229 #13 0x2adde20 in compile_file /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/toplev.cc:444 #14 0xab5e55 in do_compile /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/toplev.cc:2126 #15 0xab5e55 in toplev::main(int, char**) /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/toplev.cc:2282 #16 0xab8fb1 in main /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/main.cc:39 #17 0x7fd8e6557baf in __libc_start_call_main (/lib64/libc.so.6+0x27baf) (BuildId: 1390809fc3a065502adfa6735d294c2c86aebe4d) #18 0x7fd8e6557c78 in __libc_start_main_alias_1 (/lib64/libc.so.6+0x27c78) (BuildId: 1390809fc3a065502adfa6735d294c2c86aebe4d) #19 0xab93f4 in _start ../sysdeps/x86_64/start.S:115 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #12 from Jonathan Wakely ---
(In reply to dave.anglin from comment #11)
> Yes, this works.
Great, thanks.
> hppa64-hpux does not have have strtof. Could std::stof be implemented using
> strtod in this case?
Maybe something like this:
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -4153,6 +4153,25 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
inline float
stof(const string& __str, size_t* __idx = 0)
{ return __gnu_cxx::__stoa(&std::strtof, "stof", __str.c_str(), __idx); }
+#else
+ inline float
+ stof(const string& __str, size_t* __idx = 0)
+ {
+double __d = std::stod(__str, __idx);
+if (__builtin_isfinite(__d))
+ {
+ double __abs_d = __builtin_fabs(__d);
+ if (__abs_d < __FLT_MIN__)
+ errno = ERANGE;
+ else if (__abs_d > __FLT_MAX__)
+ {
+ errno = ERANGE;
+ float __f = __builtin_huge_valf();
+ return __d > 0.0 ? __f : -__f;
+ }
+ }
+return __d;
+ }
#endif
#if _GLIBCXX_USE_C99_STDLIB || _GLIBCXX_HAVE_STRTOLD
> I'm thinking a test to check the presence and maybe compliance of these
> routines might be good.
We have some:
testsuite/21_strings/basic_string/numeric_conversions/char/stof.cc
testsuite/21_strings/basic_string/numeric_conversions/char/stold.cc
But they depend on { dg-require-string-conversions "" } which is only true if
we have the full set of them:
return [check_v3_target_prop_cached et_string_conversions {
set cond "_GLIBCXX_USE_C99_STDIO && _GLIBCXX_USE_C99_STDLIB"
set cond "$cond && _GLIBCXX_USE_C99_WCHAR"
set cond "$cond && !defined _GLIBCXX_HAVE_BROKEN_VSWPRINTF"
return [v3_check_preprocessor_condition string_conversions $cond]
}]
[Bug middle-end/110586] [14 Regression] 10% fatigue2 regression on zen since r14-2369-g3a61ca1b925653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110586 Andrew Pinski changed: What|Removed |Added Keywords|needs-bisection | Summary|[13/14 Regression] 10% |[14 Regression] 10% |fatigue2 regression on zen |fatigue2 regression on zen |since |since |r14-2369-g3a61ca1b925653|r14-2369-g3a61ca1b925653 Target Milestone|13.2|14.0 Version|13.1.0 |14.0
[Bug middle-end/110586] [13/14 Regression] 10% fatigue2 regression on zen since r14-2369-g3a61ca1b925653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110586 Martin Jambor changed: What|Removed |Added CC||jamborm at gcc dot gnu.org Summary|[13/14 Regression] 10% |[13/14 Regression] 10% |fatigue2 regression on zen |fatigue2 regression on zen |between |since |g:8377cf1bf41a0a9d9d49de807 |r14-2369-g3a61ca1b925653 |b2341f0bf5d30cf and | |g:3a61ca1b9256535e1bfb19b2d | |46cde21f3908a5d | --- Comment #1 from Martin Jambor --- This unfortunately also bisects to: 3a61ca1b9256535e1bfb19b2d46cde21f3908a5d is the first bad commit commit 3a61ca1b9256535e1bfb19b2d46cde21f3908a5d Author: Jan Hubicka Date: Thu Jul 6 18:56:22 2023 +0200 Improve profile updates after loop-ch and cunroll
[Bug middle-end/51770] dump gimple lineno when dumping bb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51770 --- Comment #3 from Andrew Pinski --- Created attachment 0 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=0&action=edit Patch which will fix this There are a few more tweaks I would like to make but I thought I post a first pass patch here. 1) There is no documentation yet. 2) the style of file/line changes should be improved. 3) Still deciding if the only the line changes print file out again?
[Bug sanitizer/110676] [11/12/13/14 Regression] strlen of array[1] should not be optimized to 1 if using ASAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110676 --- Comment #3 from nrk at disroot dot org --- Oops, forgot about https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107395. But that bug was for missed warning opportunity, while this one is about ASan. So I suppose both the bugs can coexist.
[Bug sanitizer/110676] [11/12/13/14 Regression] strlen of array[1] should not be optimized to 1 if using ASAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110676 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.5 Known to fail||10.1.0, 8.1.0, 8.5.0 Known to work||7.5.0 Summary|strlen of array[1] should |[11/12/13/14 Regression] |not be optimized to 1 if|strlen of array[1] should |using ASAN |not be optimized to 1 if ||using ASAN --- Comment #2 from Andrew Pinski --- This is actually a regression ...
[Bug sanitizer/110676] strlen of array[1] should not be optimized to 1 if using ASAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110676
Andrew Pinski changed:
What|Removed |Added
Summary|builtin optimization|strlen of array[1] should
|prevents ASan from |not be optimized to 1 if
|detecting OOB reads |using ASAN
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-07-15
--- Comment #1 from Andrew Pinski ---
Confirmed. It is only an array of size 1 which is going to cause this issue.
array of size 2 is always fine, e.g.:
```
#include
int main(void)
{
char s[2] = "AA";
return strlen(s);
}
```
gives the expected error message.
[Bug sanitizer/110676] New: builtin optimization prevents ASan from detecting OOB reads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110676
Bug ID: 110676
Summary: builtin optimization prevents ASan from detecting OOB
reads
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: nrk at disroot dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Minimal reproducible code-snippet:
#include
int main(void)
{
char s[1] = "A";
return strlen(s);
}
Compile command: gcc -O0 -g3 -fsanitize=address,undefined
Expected behavior: ASan should catch the OOB access.
Reality: It gets optimized out and returns 0 always.
Note: adding `-fno-builtin` allows ASan to be effective.
[Bug fortran/110360] ABI issue with character,value dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #25 from David Edelsohn ---
The problem on big endian systems is that GFortran is passing the character
with the wrong padding.
I have changed val() to print both c and x, and not halt.
subroutine val (x, c)
character(kind=1), intent(in) :: x ! control: pass by reference
character(kind=1), value :: c
print *, "by value(kind=1): ", x
print *, "by value(kind=1): ", c
!if (c /= x) stop 1
c = "*"
if (c /= "*") stop 2
end
The output is:
by value(kind=1): B
by value(kind=1): B
by value(kind=1): A
by value(kind=1): A
by value(kind=1): A
by value(kind=1):<- c
by value(kind=1): A
by value(kind=1):<- c
by value(kind=1): A
by value(kind=1):<- c
by value(kind=1): 1
by value(kind=1):<- c
by value(kind=1): 1
by value(kind=1):<- c
The assembly language for the first few calls is
# call val ("B","B")
lwz 31,LC..5(2) LOAD ADDRESS of x
mr 3,31 COPY address to first parameter
li 6,1
li 5,1
lbzu 4,148(3)LOAD BYTE of c as second parameter
slwi 4,4,24 SHIFT c 24 bits
bl .val.4
# call val ("A",char(65))
mr 30,31 COPY ADDRESS of x
li 6,1
li 5,1
lbzu 4,152(30) LOAD BYTE of c as second parameter
slwi 4,4,24 SHIFT c 24 bits
mr 3,30 COPY address of first parameter
bl .val.4
# call val ("A",char(a))
li 6,1
li 5,1
li 4,65 <- c NOT SHIFTED
mr 3,30 <- x
bl .val.4
# call val ("A",mychar(65))
li 6,1
li 5,1
li 4,65 <- c NOT SHIFTED
mr 3,30 <- x
bl .val.4
# call val ("A",mychar(a))
li 6,1
li 5,1
li 4,65 <- c NOT SHIFTED
mr 3,30 <- x
bl .val.4
GFortran is not taking account of endianness for the layout of values in memory
compared to constants loaded into registers. This isn't an ABI issue of the
target, this is a memory layout and register layout issue of GFortran.
Let me know if you need more information or tests.
[Bug tree-optimization/93080] insert of an extraction on the same location is not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93080 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug target/110675] Using std::set with avx2 pragma is broken on latest gcc version (compilation fails)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110675 --- Comment #2 from Xi Ruoyao --- Clearly related to PR109753, but I'm not sure if it's OK to just mark it as a dup.
[Bug rtl-optimization/110587] [14 regression] 96% pr28071.c compile time regression since r14-2337-g37a231cc7594d1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110587 Andrew Pinski changed: What|Removed |Added Target||x86_64-linux-gnu --- Comment #2 from Andrew Pinski --- Would be interesting to see if it is the register allocator and where (which function) in GCC the compile time slow down happens.
[Bug middle-end/110587] [14 regression] 96% pr28071.c compile time regression since r14-2337-g37a231cc7594d1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110587 Andrew Pinski changed: What|Removed |Added Summary|96% pr28071.c compile time |[14 regression] 96% |regression since|pr28071.c compile time |r14-2337-g37a231cc7594d1|regression since ||r14-2337-g37a231cc7594d1 Target Milestone|--- |14.0 Keywords||compile-time-hog, ra Version|13.1.0 |14.0
[Bug middle-end/110673] [14 regression] ICE when buliding opus (internal compiler error: in gimple_phi_arg_def_from_edge, at gimple.h:4699)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110673 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug other/110669] [14 regression] ICE in gcc.dg/torture/pr105132.c since r14-2515-gb77161e60bce7b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110669 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug target/59172] pdp11-aout makes a wrong code at the epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59172 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.0
[Bug target/59178] Stack corruption on register save/restore when using frame pointer on pdp-11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59178 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c++/110674] Structured binding fails with partial specialization of `std::tuple_element` without `std::size_t` NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110674 Andrew Pinski changed: What|Removed |Added Depends on||60679 --- Comment #2 from Andrew Pinski --- Or a dup of bug 60679 (and the C++ standard defect: https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1647 ). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60679 [Bug 60679] [DR1647] class specialization not instantiated even though it is a better match than the primary template
[Bug c++/110674] Structured binding fails with partial specialization of `std::tuple_element` without `std::size_t` NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110674 Andrew Pinski changed: What|Removed |Added Depends on||83426 --- Comment #1 from Andrew Pinski --- I think this is a dup of bug 83426. See bug 83426 comment #6 on why. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83426 [Bug 83426] template argument involves template parameters with implicit integral conversion
[Bug target/110675] Using std::set with avx2 pragma is broken on latest gcc version (compilation fails)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110675 Andrew Pinski changed: What|Removed |Added Depends on||110334 --- Comment #1 from Andrew Pinski --- See bug 110334 comment #19 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334 [Bug 110334] [13/14 Regresssion] unused functions not eliminated before LTO streaming
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #11 from dave.anglin at bell dot net ---
On 2023-07-14 5:58 a.m., redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
>
> --- Comment #10 from Jonathan Wakely ---
> And this should fix it:
>
> --- a/libstdc++-v3/include/c_global/cstdlib
> +++ b/libstdc++-v3/include/c_global/cstdlib
> @@ -256,6 +256,20 @@ namespace std
> using ::__gnu_cxx::strtold;
> } // namespace std
>
> +#else // ! _GLIBCXX_USE_C99_STDLIB
> +
> +// We also check for strtof and strtold separately from
> _GLIBCXX_USE_C99_STDLIB
> +
> +#if _GLIBCXX_HAVE_STRTOF
> +#undef strtof
> +namespace std { using ::strtof; }
> +#endif
> +
> +#if _GLIBCXX_HAVE_STRTOLD
> +#undef strtold
> +namespace std { using ::strtold; }
> +#endif
> +
> #endif // _GLIBCXX_USE_C99_STDLIB
>
> } // extern "C++"
Yes, this works.
hppa64-hpux does not have have strtof. Could std::stof be implemented using
strtod in this case?
I'm thinking a test to check the presence and maybe compliance of these
routines might be good.
[Bug middle-end/110587] 96% pr28071.c compile time regression betwen g:8377cf1bf41a0a9d9d49de807b2341f0bf5d30cf and g:3a61ca1b9256535e1bfb19b2d46cde21f3908a5d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110587 Martin Jambor changed: What|Removed |Added CC||jamborm at gcc dot gnu.org, ||liuhongt at gcc dot gnu.org Last reconfirmed||2023-07-15 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Jambor --- I have bisected this to 37a231cc7594d12ba0822077018aad751a6fb94e is the first bad commit commit 37a231cc7594d12ba0822077018aad751a6fb94e Author: liuhongt Date: Wed Jul 5 13:45:11 2023 +0800 Disparage slightly for the alternative which move DFmode between SSE_REGS and GENERAL_REGS.
[Bug c++/110524] [C++20] ICE with use of function template name with no prior declaration in decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110524 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org Target Milestone|--- |13.2 Status|NEW |ASSIGNED --- Comment #5 from Patrick Palka --- Fixed for GCC 14 so far.
[Bug c++/110441] c++17: temporary causes static member function call to confuse required copy elision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110441 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Target Milestone|--- |14.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Patrick Palka --- Should be fixed for GCC 14, thanks for the report.
[Bug c++/110441] c++17: temporary causes static member function call to confuse required copy elision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110441 --- Comment #6 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:0de651db45c758f54e9ed917069795a3835499de commit r14-2539-g0de651db45c758f54e9ed917069795a3835499de Author: Patrick Palka Date: Sat Jul 15 09:50:51 2023 -0400 c++: copy elision w/ obj arg and static memfn call [PR110441] Here the call A().f() is represented as a COMPOUND_EXPR whose first operand is the otherwise unused object argument A() and second operand is the call result (both are TARGET_EXPRs). Within the return statement, this outermost COMPOUND_EXPR ends up foiling the copy elision check in build_special_member_call, resulting in us introducing a bogus call to the deleted move constructor. (Within the variable initialization, which goes through ocp_convert instead of convert_for_initialization, we've already been eliding the copy -- despite the outermost COMPOUND_EXPR -- ever since r10-7410-g72809d6fe8e085 made ocp_convert look through COMPOUND_EXPR). In contrast I noticed '(A(), A::f())' (which should be equivalent to the above call) is represented with the COMPOUND_EXPR inside the RHS's TARGET_EXPR initializer thanks to a special case in cp_build_compound_expr. So this patch fixes this by making keep_unused_object_arg use cp_build_compound_expr as well. PR c++/110441 gcc/cp/ChangeLog: * call.cc (keep_unused_object_arg): Use cp_build_compound_expr instead of building a COMPOUND_EXPR directly. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/elide8.C: New test.
[Bug c++/110524] [C++20] ICE with use of function template name with no prior declaration in decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110524 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:97ceaa110e1607ec8f4f1223200868e1642f3cc7 commit r14-2538-g97ceaa110e1607ec8f4f1223200868e1642f3cc7 Author: Patrick Palka Date: Sat Jul 15 09:47:36 2023 -0400 c++: mangling template-id of unknown template [PR110524] This fixes a crash when mangling an ADL-enabled call to a template-id naming an unknown template (as per P0846R0). PR c++/110524 gcc/cp/ChangeLog: * mangle.cc (write_expression): Handle TEMPLATE_ID_EXPR whose template is already an IDENTIFIER_NODE. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/fn-template26.C: New test.
[Bug libstdc++/110675] New: Compilation fails for a simple C++ program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110675
Bug ID: 110675
Summary: Compilation fails for a simple C++ program
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc.gnu.org at aryanc403 dot com
Target Milestone: ---
Created attachment 55549
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55549&action=edit
All files (.cpp, .ii, .s) inclusing logs.zip
Code
```
#pragma GCC target ("avx2")
#include
int main(void) {
std::set s;
return 0;
}
```
Compilation command -
```
g++ -static -std=c++20 a.cpp
```
Expected behaviour - Program compiles successfully.
Actual behaviour - Program fails to compile.
Compiler logs (Detailed logs attached) -
```
/usr/include/c++/13.1.1/bits/allocator.h: In destructor ‘constexpr
std::_Rb_tree, std::less,
std::allocator >::_Rb_tree_impl, true>::~_Rb_tree_impl()’:
/usr/include/c++/13.1.1/bits/allocator.h:184:7: error: inlining failed in call
to ‘always_inline’ ‘constexpr std::allocator<
>::~allocator() noexcept [with _Tp = std::_Rb_tree_node]’: target specific
option mismatch
184 | ~allocator() _GLIBCXX_NOTHROW { }
| ^
/usr/include/c++/13.1.1/bits/stl_tree.h:662:16: note: called from here
662 | struct _Rb_tree_impl
```
System - Arch Linux (fully updated 2-3 days ago)
[Bug c++/110674] New: Structured binding fails with partial specialization of `std::tuple_element` without `std::size_t` NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110674
Bug ID: 110674
Summary: Structured binding fails with partial specialization
of `std::tuple_element` without `std::size_t` NTTP
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
Target Milestone: ---
See GCC trunk fail: <https://compiler-explorer.com/z/zevzr89e7>.
See GCC trunk pass: <https://compiler-explorer.com/z/j65vE3os9>.
See GCC 9.5 fail: <https://compiler-explorer.com/z/35fbexaEb>.
See GCC 9.5 pass: <https://compiler-explorer.com/z/5hEPzo7nn>.
```C++
#include
#include
struct t { };
struct u {
union { t a; };
template t& get() { return a; }
};
template<> struct std::tuple_size : std::integral_constant { };
template struct std::tuple_element : std::type_identity { };
int main() {
auto [a] = u{};
}
```
```output
: In function 'int main()':
:11:9: error: invalid use of incomplete type 'struct
std::tuple_element<0, u>'
11 | auto [a] = u{};
| ^
In file included from
/opt/compiler-explorer/gcc-trunk-20230715/include/c++/14.0.0/bits/stl_pair.h:62,
from
/opt/compiler-explorer/gcc-trunk-20230715/include/c++/14.0.0/tuple:38,
from :1:
/opt/compiler-explorer/gcc-trunk-20230715/include/c++/14.0.0/bits/utility.h:80:12:
note: declaration of 'struct std::tuple_element<0, u>'
80 | struct tuple_element;
|^
:11:9: note: in initialization of structured binding variable 'a'
11 | auto [a] = u{};
| ^
Compiler returned: 1
```
[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #15 from Mikael Morin ---
rs6000_pass_by_reference returns true with -m32, and false with -m64.
So the second argument is passed by reference with -m32, and by value with
-m64.
So the code in val looks right, it is the code in p calling val which isn't.
val is declared as:
void val (character(kind=1)[1:1] & restrict x, character(kind=1)[1:1] c,
integer(kind=8) _x, integer(kind=8) _c)
so the second argument has array type, whereas p calls val with:
void p ()
{
...
character(kind=1) char.5_3;
:
...
val (&"A"[1]{lb: 1 sz: 1}, char.5_3, 1, 1); [static-chain: &FRAME.6]
so the second actual argument has non-array type.
[Bug target/59178] Stack corruption on register save/restore when using frame pointer on pdp-11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59178 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #2 from Mikael Pettersson --- This was fixed for gcc-9.1.0, see PR59172.
[Bug target/29256] [11/12/13/14 regression] loop performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256 --- Comment #75 from Andrew Pinski --- This looks fixed in GCC 11+; I tried x86_64, i686, powerpc (powerpc-spe is no longer supported). For 32bit powerpc we get: tuned_STREAM_Copy: .LFB0: .cfi_startproc lis 9,.LANCHOR0@ha lis 10,0x3 la 3,.LANCHOR0@l(9) ori 0,10,0xd090 addis 4,3,0xf4 mtctr 0 addi 5,3,-8 addi 8,4,9208 .L2: lwz 6,8(5) lwz 7,12(5) lfd 2,16(5) lfd 4,24(5) lfd 6,32(5) lfd 8,40(5) lfd 10,48(5) lfd 12,56(5) lfdu 0,64(5) stw 6,8(8) stw 7,12(8) stfd 2,16(8) stfd 4,24(8) stfd 6,32(8) stfd 8,40(8) stfd 10,48(8) stfd 12,56(8) stfdu 0,64(8) bdnz .L2 blr Which seems to the best. gimple level for the loop is: [local count: 1063004409]: # ivtmp.10_8 = PHI # ivtmp.12_14 = PHI ivtmp.10_7 = ivtmp.10_8 + 8; _18 = (void *) ivtmp.10_7; _1 = MEM[(double *)_18]; ivtmp.12_15 = ivtmp.12_14 + 8; _19 = (void *) ivtmp.12_15; MEM[(double *)_19] = _1; if (ivtmp.10_7 != _21) goto ; [99.00%] else goto ; [1.00%]
[Bug fortran/99139] ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139 --- Comment #9 from Steve Kargl --- On Sat, Jul 15, 2023 at 06:15:44AM +, pault at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139 > > --- Comment #8 from Paul Thomas --- > (In reply to anlauf from comment #7) > > Updating known-to-work/known to fail version. > > > > Paul/Steve: do you want to assign this PR to one of you? > > I am of two minds as to whether or not to backport the patch or to close the > PRs as resolved. > > Thoughts? > Is this patch a "side-effect" of your larger attack on ASSOCIATE bugs? If it's independent of that effort, I see no reason to backport.
[Bug rtl-optimization/21182] [11/12/13/14 Regression] gcc can use registers but uses stack instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2006-01-15 20:37:58 |2023-7-15 --- Comment #36 from Andrew Pinski --- turning off TER still helps.
