[Bug c/101432] New: NULL dereferences aren't assumed to be unreachable even with -fdelete-null-pointer-checks -fno-isolate-erroneous-paths-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101432
Bug ID: 101432
Summary: NULL dereferences aren't assumed to be unreachable
even with -fdelete-null-pointer-checks
-fno-isolate-erroneous-paths-dereference
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: josephcsible at gmail dot com
Target Milestone: ---
Target: x86_64-linux-gnu
Consider this C code:
#include
int f(_Bool x) {
if(x) {
int *null = NULL;
return *null;
} else {
return 42;
}
}
I want this assembly:
f:
movl$42, %eax
ret
But even with -O3 -fdelete-null-pointer-checks
-fno-isolate-erroneous-paths-dereference, I get this assembly:
f:
movl$42, %eax
testb %dil, %dil
je .L1
movl0, %eax
.L1:
ret
[Bug c++/92505] Using mutable in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92505 Christopher Di Bella changed: What|Removed |Added CC||cjdb.ns at gmail dot com --- Comment #3 from Christopher Di Bella --- Gentle ping, this has started to cause issues in the libc++ GCC CI for ranges.
[Bug testsuite/100166] Some vold-vec-{load,store} tests fail when built with compiler configured with --with-cpu=power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100166 --- Comment #4 from CVS Commits --- The master branch has been updated by Michael Meissner : https://gcc.gnu.org/g:063eba7ca73030139a3bf822ed127cf09b2fc226 commit r12-2266-g063eba7ca73030139a3bf822ed127cf09b2fc226 Author: Michael Meissner Date: Tue Jul 13 00:36:43 2021 -0400 Deal with prefixed loads/stores in tests, PR testsuite/100166 This patch updates the various tests in the testsuite to treat plxv and pstxv as being vector loads/stores. This shows up if you run the testsuite with a compiler configured with the option: --with-cpu=power10. 2021-07-13 Michael Meissner gcc/testsuite/ PR testsuite/100166 * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c: Update insn counts to account for power10 prefixed loads and stores. * gcc.target/powerpc/fold-vec-load-builtin_vec_xl-char.c: Likewise. * gcc.target/powerpc/fold-vec-load-builtin_vec_xl-double.c: Likewise. * gcc.target/powerpc/fold-vec-load-builtin_vec_xl-float.c: Likewise. * gcc.target/powerpc/fold-vec-load-builtin_vec_xl-int.c: Likewise. * gcc.target/powerpc/fold-vec-load-builtin_vec_xl-longlong.c: Likewise. * gcc.target/powerpc/fold-vec-load-builtin_vec_xl-short.c: Likewise. * gcc.target/powerpc/fold-vec-load-vec_vsx_ld-char.c: Likewise. * gcc.target/powerpc/fold-vec-load-vec_vsx_ld-double.c: Likewise. * gcc.target/powerpc/fold-vec-load-vec_vsx_ld-float.c: Likewise. * gcc.target/powerpc/fold-vec-load-vec_vsx_ld-int.c: Likewise. * gcc.target/powerpc/fold-vec-load-vec_vsx_ld-longlong.c: Likewise. * gcc.target/powerpc/fold-vec-load-vec_vsx_ld-short.c: Likewise. * gcc.target/powerpc/fold-vec-load-vec_xl-char.c: Likewise. * gcc.target/powerpc/fold-vec-load-vec_xl-double.c: Likewise. * gcc.target/powerpc/fold-vec-load-vec_xl-float.c: Likewise. * gcc.target/powerpc/fold-vec-load-vec_xl-int.c: Likewise. * gcc.target/powerpc/fold-vec-load-vec_xl-longlong.c: Likewise. * gcc.target/powerpc/fold-vec-load-vec_xl-short.c: Likewise. * gcc.target/powerpc/fold-vec-splat-floatdouble.c: Likewise. * gcc.target/powerpc/fold-vec-splat-longlong.c: Likewise. * gcc.target/powerpc/fold-vec-store-builtin_vec_xst-char.c: Likewise. * gcc.target/powerpc/fold-vec-store-builtin_vec_xst-double.c: Likewise. * gcc.target/powerpc/fold-vec-store-builtin_vec_xst-float.c: Likewise. * gcc.target/powerpc/fold-vec-store-builtin_vec_xst-int.c: Likewise. * gcc.target/powerpc/fold-vec-store-builtin_vec_xst-longlong.c: Likewise. * gcc.target/powerpc/fold-vec-store-builtin_vec_xst-short.c: Likewise. * gcc.target/powerpc/fold-vec-store-vec_vsx_st-char.c: Likewise. * gcc.target/powerpc/fold-vec-store-vec_vsx_st-double.c: Likewise. * gcc.target/powerpc/fold-vec-store-vec_vsx_st-float.c: Likewise. * gcc.target/powerpc/fold-vec-store-vec_vsx_st-int.c: Likewise. * gcc.target/powerpc/fold-vec-store-vec_vsx_st-longlong.c: Likewise. * gcc.target/powerpc/fold-vec-store-vec_vsx_st-short.c: Likewise. * gcc.target/powerpc/fold-vec-store-vec_xst-char.c: Likewise. * gcc.target/powerpc/fold-vec-store-vec_xst-double.c: Likewise. * gcc.target/powerpc/fold-vec-store-vec_xst-float.c: Likewise. * gcc.target/powerpc/fold-vec-store-vec_xst-int.c: Likewise. * gcc.target/powerpc/fold-vec-store-vec_xst-longlong.c: Likewise. * gcc.target/powerpc/fold-vec-store-vec_xst-short.c: Likewise. * gcc.target/powerpc/lvsl-lvsr.c: Likewise. * gcc.target/powerpc/pr86731-fwrapv-longlong.c: Likewise.
[Bug debug/101431] gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101431 --- Comment #1 from roc at ocallahan dot org --- Clang follows the spec (clang 12, -fdebug-default-version=5): The Directory Table: 0 /tmp/pernosco-submit-test 1 out The File Name Table Entry Dir TimeSizeMD5 Name 0 0 0 0 F596F6F042BF2AD9E2B1C6B62633739A out/file.c 1 1 0 0 5E2CEC2A6335E978DEB5A35D865C41E2 message.h So I'm not sure what to do anymore when consuming DWARF5 line number information. I guess we could try "treat all relative directory entries as relative to the DW_AT_comp_dir" and hope that clang's directory entry 0 always matches DW_AT_comp_dir...
[Bug debug/101431] New: gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101431 Bug ID: 101431 Summary: gcc-generated DWARF5 .debug_line directory entries violate the DWARF5 spec Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: roc at ocallahan dot org Target Milestone: --- For the "Line Number Program Header" "directories" field, the DWARF5 spec says "The first entry is the current directory of the compilation. Each additional path entry is either a full path name or is relative to the current directory of the compilation." In a simple testcase (see below) I get the following tables emitted (gcc 11.1.1): The Directory Table: 0 out 1 out 2 /usr/include The File Name Table Entry Dir TimeSizeName 0 0 0 0 file.c 1 1 0 0 file.c 2 1 0 0 message.h 3 2 0 0 stdio.h The compilation unit info from .debug_info is UNIT: dwo_id = 0x6ef97fe679da < 0><0x0014> DW_TAG_skeleton_unit DW_AT_low_pc0x00201728 DW_AT_high_pc 21 DW_AT_stmt_list <.debug_line+0x00bd> DW_AT_dwo_name out/main.dwo DW_AT_comp_dir /tmp/pernosco-submit-test DW_AT_GNU_pubnames yes DW_AT_addr_base <.debug_addr+0x0030> The correct path for 'file.c' is /tmp/pernosco-submit-test/out/file.c. Clearly, treating directory entry 1 as relative to directory entry 0 would give the wrong file path (something containing 'out/out'). It looks like gcc intends all directory entries to be treated as relative to the DW_AT_comp_dir from the .debug_info unit? Note that if the latter is true, then that violates the intent of the new behavior in DWARF5: > In DWARF Version 5, the current directory is explicitly present in the directories field. This is needed to support the common practice of stripping all but the line number sections ( .debug_line and .debug_line_str ) from an executable. To reproduce this bug: git clone --recurse-submodules https://github.com/Pernosco/pernosco-submit-test cd pernosco-submit-test ./build.sh dwarfdump -l out/main.debug
[Bug middle-end/93086] build_nonstandard_integer_type should take signop instead of int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93086 --- Comment #3 from Andrew Pinski --- Created attachment 51145 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51145=edit Patch in test This patch is bigger than I wanted it to be as there has been many more uses of build_nonstandard_integer_type than when I originally looked into it.
[Bug c++/88252] Deduction guide assume the constructor parameter is a forwarding reference if constructor defined outside class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88252 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org
[Bug target/101395] [11/12 regression] Compile failure with -march=native -m32 on sapphirerapids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101395 --- Comment #10 from Hongyu Wang --- (In reply to H.J. Lu from comment #9) > Created attachment 51143 [details] > A patch > > Try this instead. This also works.
[Bug c++/101430] New: Passing a lambda as a template argument causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101430
Bug ID: 101430
Summary: Passing a lambda as a template argument causes
internal compiler error
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jorg.brown at gmail dot com
Target Milestone: ---
This code causes gcc 11.1.0 to ICE:
extern "C" {
int printf(const char *, ...);
}
void g(int n) { printf("%d\n", n); }
template void f(decltype(Lambda) x = {}) {
x();
}
int main() {
constexpr auto a = []{ g(3); };
//f();
f<[]{g(2);}>();
f();
}
Output when compiled:
x86-64 gcc 11.1 (Editor #1, Compiler #1) C++
x86-64 gcc 11.1
-std=c++20
123
# For more information see the output window
x86-64 gcc 11.1 - cached
Output of x86-64 gcc 11.1 (Compiler #1)
: In substitution of 'template void f(decltype (Lambda))
[with auto Lambda = ]':
:17:6: required from here
:7:33: internal compiler error: in convert_nontype_argument, at
cp/pt.c:7652
7 | template void f(decltype(Lambda) x = {}) {
| ^
0x1780bf9 internal_error(char const*, ...)
???:0
0x677e40 fancy_abort(char const*, int, char const*)
???:0
0x7f3b4b fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0x68eda2 build_new_function_call(tree_node*, vec**, int)
???:0
0x8070f0 finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x7c0cab c_parse_file()
???:0
0x892aa2 c_common_parse_file()
???:0
Compiler Explorer link: https://godbolt.org/z/Evcd7oaz5
Interestingly, if I comment out the definition of `a`, it compiles and runs
properly.
And if I comment out either of the last two calls to f(), it compiles and runs
properly. Whether or not f(); is commented out.
[Bug go/101407] non-determinism in -fdump-go-spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101407 --- Comment #4 from Toolybird --- Your patch solves the problem for me. Thank you very much!
[Bug libstdc++/101361] Bogus -Wstringop-overread warning with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101361
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2021-07-12
CC||jwakely.gcc at gmail dot com,
||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Blocks||97048
Status|UNCONFIRMED |NEW
Component|c++ |libstdc++
--- Comment #3 from Martin Sebor ---
The warning triggers for the memcmp_eq() call in the IL below, so it's working
as designed, and the problem is that optimization exposes invalid but likely
unreachable code:
_77 = __builtin_memcmp_eq (_27, _86, 18446744073709551615);
The test case in attachment 51130 has the same issue:
[local count: 1013569139]:
# i_141 = PHI
# prephitmp_26 = PHI
D.47043 ={v} {CLOBBER};
MEM[(struct _Alloc_hider *)] ={v} {CLOBBER};
MEM[(struct _Alloc_hider *)]._M_p = [(void *)
+ 16B];
_46 = MEM[(const struct basic_string *)s2_10(D)]._M_dataplus._M_p;
_50 = MIN_EXPR ;
_51 = _46 + _50;
std::__cxx11::basic_string::_M_construct.isra (, _46, _51);
_21 = D.47043._M_string_length;
_22 = D.47043._M_dataplus._M_p;
_18 = MEM[(const struct basic_string *)s1_7(D)]._M_string_length;
_19 = MEM[(const struct basic_string *)s1_7(D)]._M_dataplus._M_p;
if (_18 >= _21)
goto ; [33.00%]
...
[local count: 334477814]:
_130 = .SUB_OVERFLOW (_18, _21);
_40 = REALPART_EXPR <_130>;
_2 = IMAGPART_EXPR <_130>;
if (_2 != 0)
goto ; [0.04%]
else
goto ; [99.96%]
...
[local count: 334344023]:
if (_21 != 18446744073709551615)
goto ; [34.00%]
else
goto ; [66.00%]
...
[local count: 220667054]:
_125 = _19 + _40;
_107 = __builtin_memcmp_eq (_125, _22, 18446744073709551615);
The IL is the result of the string ends_with function passing npos to compare
as a shorthand for "the rest of the string:"
bool
ends_with(basic_string_view __x) const noexcept
{
return this->size() >= __x.size()
&& this->compare(this->size() - __x.size(), npos, __x) == 0;
}
Getting rid of npos also avoid the warning. I think the following should be
equivalent:
bool
ends_with(basic_string_view __x) const noexcept
{
return this->size() >= __x.size()
&& this->compare(this->size() - __x.size(), __x.size(), __x) == 0;
}
Jonathan, would this (or something like it) work?
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048
[Bug 97048] [meta-bug] bogus/missing -Wstringop-overread warnings
[Bug libstdc++/101429] __replacement_assert should be marked as noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101429 --- Comment #1 from cqwrteur --- By the way, i think if _GLIBCXX_VERBOSE==0, it should be just an __builtin_abort(). This will make optimizers much happier. The bounds checking will be only once. https://godbolt.org/z/7MxMoe3Yn
[Bug libstdc++/101429] New: __replacement_assert should be marked as noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101429 Bug ID: 101429 Summary: __replacement_assert should be marked as noexcept Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- https://godbolt.org/z/eThdeW3Mv The function does not throw exception. However, clang still generate std::terminate() landing pad. You need to mark it as noexcept.
[Bug c++/79501] member deduction guide not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79501 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:8d75b8830e9dafb4e0c400c723653512adf40295 commit r12-2260-g8d75b8830e9dafb4e0c400c723653512adf40295 Author: Patrick Palka Date: Mon Jul 12 16:35:18 2021 -0400 c++: permit deduction guides at class scope [PR79501] This adds support for declaring (class-scope) deduction guides for a member class template. Fortunately it seems only a couple of changes are needed in order for the existing CTAD machinery to handle them properly: we need to make sure to give them a FUNCTION_TYPE instead of a METHOD_TYPE, and we need to avoid using a BASELINK when looking them up. PR c++/79501 PR c++/100983 gcc/cp/ChangeLog: * decl.c (grokfndecl): Don't require that deduction guides are declared at namespace scope. Check that class-scope deduction guides have the same access as the member class template. (grokdeclarator): Pretend class-scope deduction guides are static. * search.c (lookup_member): Don't use a BASELINK for (class-scope) deduction guides. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/class-deduction92.C: New test. * g++.dg/cpp1z/class-deduction93.C: New test. * g++.dg/cpp1z/class-deduction94.C: New test. * g++.dg/cpp1z/class-deduction95.C: New test.
[Bug c++/100983] Deduction guide for member template class rejected at class scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100983 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:8d75b8830e9dafb4e0c400c723653512adf40295 commit r12-2260-g8d75b8830e9dafb4e0c400c723653512adf40295 Author: Patrick Palka Date: Mon Jul 12 16:35:18 2021 -0400 c++: permit deduction guides at class scope [PR79501] This adds support for declaring (class-scope) deduction guides for a member class template. Fortunately it seems only a couple of changes are needed in order for the existing CTAD machinery to handle them properly: we need to make sure to give them a FUNCTION_TYPE instead of a METHOD_TYPE, and we need to avoid using a BASELINK when looking them up. PR c++/79501 PR c++/100983 gcc/cp/ChangeLog: * decl.c (grokfndecl): Don't require that deduction guides are declared at namespace scope. Check that class-scope deduction guides have the same access as the member class template. (grokdeclarator): Pretend class-scope deduction guides are static. * search.c (lookup_member): Don't use a BASELINK for (class-scope) deduction guides. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/class-deduction92.C: New test. * g++.dg/cpp1z/class-deduction93.C: New test. * g++.dg/cpp1z/class-deduction94.C: New test. * g++.dg/cpp1z/class-deduction95.C: New test.
[Bug tree-optimization/96697] Failure to optimize mod+div to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96697 --- Comment #5 from Andrew Macleod --- (In reply to Andrew Macleod from comment #4) > (In reply to Jakub Jelinek from comment #2) > > Shall we do that as a specific matcher or e.g. in the ranger once it gets > > code for symbolic comparisons? I mean, for signed t = x % y note that t is > > in [-y + 1, y + 1] and on the division use that information to determine the > > division result range to be [0, 0] ? > > It could then handle even e.g. ((unsigned) x % y) / (y + 32) for signed y > > etc. > > IN theory the ranger should handle this when relations are available. > > : > _1 = x_2(D) % y_3(D); // Establish relation _1 < y_3 > _4 = _1 / y_3(D); > return _4; > > IT should recognize the relation _1 < y_3 from the first statement and when > we calculate _1 / y_3, it again ought to then apply the relation and > determine that _4 = [0,0] hum. but that'd only work for unsigned I guess? If y_3 is negative, then _1 > y_3 I believe. so if y_3 is VARYING, relations won't solve this issue :-P
[Bug ipa/97565] -flto -ipa-pta ICE: at cgraph_node::get_untransformed_body()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97565 --- Comment #4 from Xi Ruoyao --- This issue still exists in trunk. "-fno-builtin-abort" can be used as a workaround for SpiderMonkey though. Any progress?
[Bug target/101424] [12 Regression] ICE in extract_insn, at recog.c:2771 since r12-2085-gf65878178ab05180
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101424 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Uroš Bizjak --- Fixed.
[Bug target/101424] [12 Regression] ICE in extract_insn, at recog.c:2771 since r12-2085-gf65878178ab05180
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101424 --- Comment #3 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:8d980e84240c82502661758fbecd5f456018ea89 commit r12-2259-g8d980e84240c82502661758fbecd5f456018ea89 Author: Uros Bizjak Date: Mon Jul 12 21:06:32 2021 +0200 i386: Fix vec_set expanders [PR101424] AVX does not support 32-byte integer compares, required by ix86_expand_vector_set_var. The following patch fixes vec_set expanders by introducing new vec_setm_avx2_operand predicate for AVX vector modes. gcc/ 2021-07-12 Uroš Bizjak PR target/101424 * config/i386/predicates.md (vec_setm_sse41_operand): Rename from vec_setm_operand. (vec_setm_avx2_operand): New predicate. * config/i386/sse.md (vec_set): Use V_128 mode iterator. Use vec_setm_sse41_operand as operand 2 predicate. (vec_set PR target/101424 * gcc.target/i386/pr101424.c: New test.
[Bug tree-optimization/101335] [12 Regression] wrong code at -O2 and above (casts between signed and unsigned) by r12-1796
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101335 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Andrew Macleod --- fixed.
[Bug tree-optimization/101335] [12 Regression] wrong code at -O2 and above (casts between signed and unsigned) by r12-1796
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101335 --- Comment #3 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:a1539b797a06e03b08e1f1de28ad0d19a3956616 commit r12-2258-ga1539b797a06e03b08e1f1de28ad0d19a3956616 Author: Andrew MacLeod Date: Mon Jul 12 11:38:17 2021 -0400 Do not register a cast as an equivalence. Registering an equivalence between objects of the same size in a cast can cause other relations to be incorrect. gcc/ PR tree-optimization/101335 * range-op.cc (operator_cast::lhs_op1_relation): Delete. gcc/testsuite/ * gcc.dg/tree-ssa/pr101335.c: New.
[Bug tree-optimization/60669] VRP misses asserts for some already defined statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60669 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #3 from Andrew Macleod --- I believe ranger resolves this now in EVRP?
[Bug libstdc++/101411] missing constraint in std::as_writable_bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101411 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-07-12 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Target Milestone|--- |10.4 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #2 from Jonathan Wakely --- Fixed on trunk so far.
[Bug libstdc++/101411] missing constraint in std::as_writable_bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101411 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:9d4393af9d2b37b78eb5b1f84f5d4da3a6f7fba6 commit r12-2257-g9d4393af9d2b37b78eb5b1f84f5d4da3a6f7fba6 Author: Jonathan Wakely Date: Mon Jul 12 16:09:34 2021 +0100 libstdc++: Constrain std::as_writable_bytes [PR101411] The std::as_writable_bytes function should be constrained to only accept writable spans. Currently it can be called but then gives an error in the function body. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/101411 * include/std/span (as_writable_bytes): Add requires-clause. * testsuite/23_containers/span/101411.cc: New test.
[Bug middle-end/101397] [11/12 Regression] spurious warning writing to the result of stpcpy minus 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101397 Martin Sebor changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #2 from Martin Sebor --- *** Bug 101415 has been marked as a duplicate of this bug. ***
[Bug middle-end/101415] [12 Regression] Bogus -Warray-bounds warning with stpcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101415 Martin Sebor changed: What|Removed |Added Resolution|--- |DUPLICATE CC||msebor at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Martin Sebor --- I'm tracking this in pr101397. *** This bug has been marked as a duplicate of bug 101397 ***
[Bug tree-optimization/101394] [9/10/11 Regression] ICE on valid code with -O2: SSA corruption: Unable to coalesce ssa_names 10 and 19 which are marked as MUST COALESCE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101394 --- Comment #6 from Andrew Pinski --- (In reply to Martin Liška from comment #3) > Just for the record, started with r9-2475-g4864297f7858617a. That definitely looks more like it was exposing the issue really as that was to VRP while the fix in comment #4 is for PRE.
[Bug tree-optimization/101394] [9/10/11 Regression] ICE on valid code with -O2: SSA corruption: Unable to coalesce ssa_names 10 and 19 which are marked as MUST COALESCE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101394 Andrew Pinski changed: What|Removed |Added Summary|ICE on valid code with -O2: |[9/10/11 Regression] ICE on |SSA corruption: Unable to |valid code with -O2: SSA |coalesce ssa_names 10 and |corruption: Unable to |19 which are marked as MUST |coalesce ssa_names 10 and |COALESCE. |19 which are marked as MUST ||COALESCE. Target Milestone|--- |9.5
[Bug target/101384] wrong code at -Og and above with vector shift/multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101384
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Simpler testcase with no vector type casts which is also works for both
endians:
typedef unsigned char __attribute__((__vector_size__ (16))) U;
U u;
U
foo (void)
{
U y = (U) { 0x80, 0xff, 0xff, 0xff, 0x80, 0xff, 0xff, 0xff,
0x80, 0xff, 0xff, 0xff, 0x80, 0xff, 0xff, 0xff } + u;
return y;
}
int
main ()
{
U x = (U) foo ();
for (unsigned i = 0; i < 16; i++)
if (x[i] != ((i & 3) ? 0xff : 0x80))
__builtin_abort ();
return 0;
}
[Bug c++/51851] [core/1001] Overriding a function with a parameter of dependent type fails to override.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51851 Marek Polacek changed: What|Removed |Added CC||nickhuang99 at hotmail dot com --- Comment #3 from Marek Polacek --- *** Bug 101402 has been marked as a duplicate of this bug. ***
[Bug c++/101402] [DR 1001] top cv qualifier not dropped for array type typedef in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101402 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE Status|SUSPENDED |RESOLVED --- Comment #2 from Marek Polacek --- We already have a bug for this. *** This bug has been marked as a duplicate of bug 51851 ***
[Bug fortran/101199] program changes the value of a dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101199 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=30373 --- Comment #7 from Thomas Koenig --- This is indeed a problem with aliasing and INTENT(OUT). When passing this to initoriginal_struct, specifying intent(out) is telling the compiler that this%var1 contains random garbage, in other words, that you could also write subroutine initoriginal_struct(this, var1) class(original_struct), intent(out) :: this real, intent(in) :: var1 call random_number(this%var1) print*, 'head of initoriginal_struct, the input argument var1 = ', var1 this%var1 = var1 end subroutine initoriginal_struct This will then show up the aliasing problem because var1 is aliased to this%var1. gfortran currently does not detect this. There is a longstanding feature request about this, PR 30373. Resolving as invalid.
[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050 Franz Sirl changed: What|Removed |Added CC||sirl at gcc dot gnu.org --- Comment #17 from Franz Sirl --- (In reply to Segher Boessenkool from comment #13) > Author: segher > Date: Mon Jul 15 20:57:53 2019 > New Revision: 273498 > > URL: https://gcc.gnu.org/viewcvs?rev=273498=gcc=rev > Log: > rs6000: Always output .machine > > We now can always output .machine (if we output it at all for the > current target). > > > PR target/91050 > * config/rs6000/rs6000.c (rs6000_file_start): Never skip emitting a > .machine directive. > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/config/rs6000/rs6000.c This caused PR target/101393
[Bug tree-optimization/101419] [9/10/11/12 Regression] collapsing memset() calls can break __builtin_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419 --- Comment #20 from Jakub Jelinek --- Created attachment 51144 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51144=edit gcc12-pr101419.patch Updated patch.
[Bug target/101395] [11/12 regression] Compile failure with -march=native -m32 on sapphirerapids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101395 H.J. Lu changed: What|Removed |Added Attachment #51142|0 |1 is obsolete|| --- Comment #9 from H.J. Lu --- Created attachment 51143 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51143=edit A patch Try this instead.
[Bug tree-optimization/101335] [12 Regression] wrong code at -O2 and above (casts between signed and unsigned) by r12-1796
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101335 --- Comment #2 from Andrew Macleod --- yeah, it because we have been treating casts to objects of the same precision as equivalences.This normally works fine, but in this case we have c_9 = (int)_2 c_9 == _2 _3 = c_9 - 10 so _3 is < c_9 d_10 = (unsigned)_3d_10 == _3 if (_2 < d_10) with the equivalences, it now thinks that d_10 < _2. So I have to either not allow compounding relations thru casting equivalences (painful), or something else. -fwrapv make its work because we don't register the relation _3 < c_9 if wrapping is on. I'm running an experiment... When the recomputation code was introduced, it completely eliminated the need to track downcasts. It seems that removing all equivalences between casts doesn't miss anything either, so perhaps this older bit isn't needed anymore. I'm running it thru the testsuite now...
[Bug target/101395] [11/12 regression] Compile failure with -march=native -m32 on sapphirerapids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101395 --- Comment #8 from H.J. Lu --- (In reply to Jakub Jelinek from comment #7) > Comment on attachment 51142 [details] > A patch > > Can't you use one single local_cpu_detect and pass it 2 arguments (arch/tune > and 32/64) instead of just one (arch/tune)? > Then you could check that second arg only for the uintr... I can and host_detect_local_cpu needs to parse "arch32/tune32/arch64/tune64".
[Bug target/101395] [11/12 regression] Compile failure with -march=native -m32 on sapphirerapids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101395 --- Comment #7 from Jakub Jelinek --- Comment on attachment 51142 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51142 A patch Can't you use one single local_cpu_detect and pass it 2 arguments (arch/tune and 32/64) instead of just one (arch/tune)? Then you could check that second arg only for the uintr...
[Bug target/101395] [11/12 regression] Compile failure with -march=native -m32 on sapphirerapids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101395 H.J. Lu changed: What|Removed |Added Attachment #51125|0 |1 is obsolete|| --- Comment #6 from H.J. Lu --- Created attachment 51142 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51142=edit A patch Please try this.
[Bug fortran/101199] program changes the value of a dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101199 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #6 from Thomas Koenig --- (In reply to Jürgen Reuter from comment #5) > (In reply to ygal klein from comment #4) > >) > > > > Thank you for the reply. > > > > After posting the bug report - I saw that implementing (inout) as your > > number 1 suggestion - dodges the problem - though as you mentioned having > > inout for this in an init routine is somewhat unnatural. > > > > The 2nd suggestion is something that I was trying to avoid in the first > > place - i.e copying a whole type (this minimal example is a small type - but > > originally it is a type with a lot of instances and procedures) > > > > In fact - I could have had advance as a function that returns a type - but > > then I would be paying the price of copyin assignment of a big type. > > > > Anyway - you conclude that gfortran is behaving as it should and that the > > fact that ifort works - is somewhat a coincidence? > > Let's see what the gfortran developers have to say about this. In any case > it looks strange if you try to call an init routine from a different TBP of > the same object. An init routine is usually called only at the very > instantiation of the object. If you want a shallow copy then you need a > pointer. I can confirm Jürgen's analysis.
[Bug tree-optimization/101373] PRE hoists trapping instructions over possibly throwing calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101373 Richard Biener changed: What|Removed |Added Known to work||12.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #16 from Richard Biener --- Fixed on trunk.
[Bug tree-optimization/101373] PRE hoists trapping instructions over possibly throwing calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101373 --- Comment #15 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:fedcf3c476aff7533741a1c61071200f0a38cf83 commit r12-2254-gfedcf3c476aff7533741a1c61071200f0a38cf83 Author: Richard Biener Date: Thu Jul 8 09:52:49 2021 +0200 tree-optimization/101373 - avoid PRE across externally throwing call PRE already tries to avoid hoisting possibly trapping expressions across calls that might not return normally but fails to consider const calls that throw externally. The following fixes that and also plugs the hole of trapping references not pruned in case they are not catched by the actuall call clobbering it. At -Os we hit the same issue in RTL PRE and postreload-gcse has even more incomplete checks so the patch adjusts both of those as well. 2021-07-08 Richard Biener PR tree-optimization/101373 * tree-ssa-pre.c (prune_clobbered_mems): Also prune trapping references when the BB may not return. (compute_avail): Pass in the function we're working on and replace cfun references with it. Externally throwing const calls also possibly terminate the function. (pass_pre::execute): Pass down the function we're working on. * gcse.c (compute_hash_table_work): Externally throwing const/pure calls also need record_last_mem_set_info. * postreload-gcse.c (record_opr_changes): Looping or externally throwing const/pure calls also need record_last_mem_set_info. * g++.dg/torture/pr101373.C: New testcase, XFAILed. * gnat.dg/opt95.adb: Likewise.
[Bug tree-optimization/101419] [9/10/11/12 Regression] collapsing memset() calls can break __builtin_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419 --- Comment #19 from rguenther at suse dot de --- On Mon, 12 Jul 2021, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419 > > --- Comment #18 from Jakub Jelinek --- > (In reply to rguent...@suse.de from comment #16) > > Well, my point was to avoid pessimizing the VN done from cunrolli ;) > > Of course any duplication / threading can improve __bos precision, > > but then any transform also risks breaking it. Your example > > is IMHO too artificial as good argument. > > Is that VN so important for cunrolli itself (I mean, what harm will be there > if > it is only VN simplified during FRE after it)? Does it affect anything but > the > number of statements that perhaps is used to determine whether to unroll > completely or not? Sure, if you have address comparisons inside the loop body that resolve by unrolling (by making the index into an array part constant), then this changes the size estimate used for further unrolling outer loops. > My testcase was artificial, sure, but I was worrying about short loops (say 2 > iterations) doing some strcpy/memcpy etc. where having more precise object > size > would improve security. Well, we can always find examples where security is improved and we can find examples where optimization is pessimized. We can't unfortunately both have the cake and also eat it.
[Bug libstdc++/101406] poor codegen for shared_ptr copy & destory, compared to boost::shared_ptr and libc++'s implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101406 Marc Mutz changed: What|Removed |Added Resolution|WONTFIX |FIXED --- Comment #3 from Marc Mutz --- Ok, it doesn't seem to affect execution speed much, but oh my, the code size :/
[Bug target/101395] [11/12 regression] Compile failure with -march=native -m32 on sapphirerapids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101395
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
Wouldn't it work to instead wrap the -muintr option from local_cpu_detect into
%{m64|mx32:-muintr} or %{!m32:-muintr} depending on TARGET_64BIT_DEFAULT ?
-muintr-native is ugly...
[Bug c++/101421] ICE: in lookup_template_class_1, at cp/pt.c:10005
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101421 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2021-07-12
[Bug fortran/100227] [9/10/11/12 Regression] write with implicit loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100227 Thomas Koenig changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Thomas Koenig --- Fixed by https://gcc.gnu.org/g:d7e3855d5dd8c001bb65dc7da1cda0249bfc2986 https://gcc.gnu.org/g:ba58662d013aa14d408a0e7172765e3da707a9eb https://gcc.gnu.org/g:750d7364d9719e70b444d0c25d53550c65f180d1 https://gcc.gnu.org/g:5f8227f7c91fc59e4ad2d35114bed1272f7b0b2d respectively for 12,11,10 and 9. Why the commits did not hit bugzilla I do not know. Thanks for the bug report! Author: Thomas Koenig Date: Tue Jul 6 07:04:09 2021 +0200 Do not replace variable op variable in I/O implied DO loop replacement. This PR came about because index expressions of the form k+k in implied DO loops in I/O statements were considered for replacement by array slices. Fixed by only doing the transformation if the expression is of the type expr OP contastant. gcc/fortran/ChangeLog: PR fortran/100227 * frontend-passes.c (traverse_io_block): Adjust test for when a variable is eligible for the transformation to array slice. gcc/testsuite/ChangeLog: PR fortran/100227 * gfortran.dg/implied_do_io_7.f90: New test.
[Bug c++/101405] [12 Regression] internal compiler error: in reshape_init_class, at cp/decl.c:6483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101405 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2021-07-12 Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |12.0 Priority|P3 |P1 Ever confirmed|0 |1 Summary|internal compiler error: in |[12 Regression] internal |reshape_init_class, at |compiler error: in |cp/decl.c:6483 |reshape_init_class, at ||cp/decl.c:6483 --- Comment #1 from Jakub Jelinek --- Started with r12-954-g84fd1b5dff70cd74aee7e8b18f66959d8b8e1ce7
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- cross toolchain fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 Ofer Shinaar changed: What|Removed |Added CC||ofer.shinaar at wdc dot com --- Comment #18 from Ofer Shinaar --- (In reply to Jonathan Wakely from comment #16) > I don't think the patch is sufficient, I think I had a complete one. Can the patch be shared before the 11.2 cycle?
[Bug tree-optimization/101419] [9/10/11/12 Regression] collapsing memset() calls can break __builtin_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419 --- Comment #18 from Jakub Jelinek --- (In reply to rguent...@suse.de from comment #16) > Well, my point was to avoid pessimizing the VN done from cunrolli ;) > Of course any duplication / threading can improve __bos precision, > but then any transform also risks breaking it. Your example > is IMHO too artificial as good argument. Is that VN so important for cunrolli itself (I mean, what harm will be there if it is only VN simplified during FRE after it)? Does it affect anything but the number of statements that perhaps is used to determine whether to unroll completely or not? My testcase was artificial, sure, but I was worrying about short loops (say 2 iterations) doing some strcpy/memcpy etc. where having more precise object size would improve security. (In reply to rguent...@suse.de from comment #17) > Yes, I think it's needed for GIMPLE FE testcase correctness. Ok, will change it then to earlyobjsz and objsz then.
[Bug debug/101398] Multiple DW_TAG_formal_parameter DIEs for the same parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101398 --- Comment #2 from Will Cohen --- Created attachment 51141 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51141=edit The uv_irq.i file The uv_irq.i file was created from 98f7fdced2e0efb1599a37b3e57671a7884f3a25 of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git on Fedora 34 using gcc-11.1.1-3.fc34.x86_64 using the following command in the top-level directory of the Linux kenrel source: gcc -Wp,-MMD,arch/x86/platform/uv/.uv_irq.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/11/include -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector -Wimplicit-fallthrough -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-stack-clash-protection -g -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wno-packed-not-aligned-DKBUILD_MODFILE='"arch/x86/platform/uv/uv_irq"' -DKBUILD_BASENAME='"uv_irq"' -DKBUILD_MODNAME='"uv_irq"' -D__KBUILD_MODNAME=kmod_uv_irq -c -o arch/x86/platform/uv/uv_irq.o arch/x86/platform/uv/uv_irq.c -save-temps
[Bug tree-optimization/101419] [9/10/11/12 Regression] collapsing memset() calls can break __builtin_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419 --- Comment #17 from rguenther at suse dot de --- On Mon, 12 Jul 2021, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419 > > --- Comment #15 from Jakub Jelinek --- > (In reply to Richard Biener from comment #13) > > Note usually we still run all property providers but the way you set > > the property outside of pass->properties_provided breaks this. Thus > > maybe split objsz into two separate passes rather than using the > > flag so you can use properties_provided. > > I wanted to avoid having two separate passes, but if you prefer it, it can be > done. Will be a user visible change in the dumps and for -fdisable-tree-* > etc. > (though we do such changes all the time). Yes, I think it's needed for GIMPLE FE testcase correctness. As for dumpfile renaming, yeah - that's unfortunate. I'm always hoping somebody bites the bullet and implements NEXT_PASS (pass_late_object_size, "objsz2") aka specifying the dump suffix explicitely.
[Bug tree-optimization/101419] [9/10/11/12 Regression] collapsing memset() calls can break __builtin_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #16 from rguenther at suse dot de ---
On Mon, 12 Jul 2021, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
>
> --- Comment #14 from Jakub Jelinek ---
> I agree about most of the passes you are moving, but I have an (albeit
> artificial) testcase that proves that cunrolli does affect objsz:
> __SIZE_TYPE__ a[10];
>
> void
> foo (void)
> {
> char *p = __builtin_malloc (64);
> for (int i = 0; i < 4; i++)
> {
> a[i] = __builtin_object_size (p, 0);
> p += 6;
> }
> }
>
> When objsz is done before cunrolli, a[0] to a[3] will all be 64, while
> when it is done after cunrolli, it will be 64, 58, 52, 46.
>
> So, what about a mix of your and my patch, add
> --- gcc/passes.def
> +++ gcc/passes.def
> @@ -194,14 +194,14 @@ along with GCC; see the file COPYING3. If not see
> They ensure memory accesses are not indirect wherever possible. */
>NEXT_PASS (pass_strip_predict_hints, false /* early_p */);
>NEXT_PASS (pass_ccp, true /* nonzero_p */);
> - NEXT_PASS (pass_post_ipa_warn);
>/* After CCP we rewrite no longer addressed locals into SSA
> form if possible. */
> + NEXT_PASS (pass_post_ipa_warn);
>NEXT_PASS (pass_complete_unrolli);
> + NEXT_PASS (pass_object_sizes, false /* insert_min_max_p */);
>NEXT_PASS (pass_backprop);
>NEXT_PASS (pass_phiprop);
>NEXT_PASS (pass_forwprop);
> - NEXT_PASS (pass_object_sizes, false /* insert_min_max_p */);
>/* pass_build_alias is a dummy pass that ensures that we
> execute TODO_rebuild_alias at this point. */
>NEXT_PASS (pass_build_alias);
> to my patch?
Well, my point was to avoid pessimizing the VN done from cunrolli ;)
Of course any duplication / threading can improve __bos precision,
but then any transform also risks breaking it. Your example
is IMHO too artificial as good argument.
[Bug go/101407] non-determinism in -fdump-go-spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101407 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|ian at airs dot com|jakub at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-07-12 --- Comment #3 from Jakub Jelinek --- Created attachment 51140 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51140=edit gcc12-pr101407.patch I can reproduce it. The problem is that hash_set for pointers by default uses ptr_hash, which hashes the pointer values rather than strings they point to, and that hash_set is then traversed and type lines are emitted during that traversal. So, with address space randomization the strings hash differently between different runs. This patch changes it to hash the strings instead and that should be reproduceable.
[Bug inline-asm/101422] register variable uninitialised before passing to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101422
--- Comment #7 from Simon Willcocks ---
(In reply to Jakub Jelinek from comment #6)
> Moving the line is the right fix
Thanks for the confirmation.
> It is recommended to initialize normal automatic variables first and then
> only initialize register vars to those automatic variables right before the
> inline asm, with no other code in between.
In retrospect, I see that that is what this paragraph in
https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/Local-Register-Variables.html is
trying to say:
"Warning: In the above example, be aware that a register (for example r0) can
be call-clobbered by subsequent code, including function calls and library
calls for arithmetic operators on other variables (for example the
initialization of p2). In this case, use temporary variables for expressions
between the register assignments:"
For a coder to identify if they've encountered "this case" is very difficult
(at least, it took me several days), I think perhaps a hard-and-fast rule would
be more helpful? (With a change to the example to match.)
"Warning: any expression used to initialise a local register variable more
complex than a simple assignment from a local variable may involve a
compiler-generated function call that could invalidate previously initialised
register variables. Therefore, it is recommended that programs only initialize
register variables to the values of previously initialised automatic variables
just before the inline asm, with no other code in between."
int *p1value = …;
int *p2value = …;
register int *p1 asm ("r0") = p1value;
register int *p2 asm ("r1") = p2value;
register int *result asm ("r0");
asm ("sysint" : "=r" (result) : "0" (p1), "r" (p2));
(I would still like to see a warning like "local register variable may not be
used as expected", but there can't be all that many people using this feature.)
[Bug tree-optimization/101419] [9/10/11/12 Regression] collapsing memset() calls can break __builtin_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419 --- Comment #15 from Jakub Jelinek --- (In reply to Richard Biener from comment #13) > Note usually we still run all property providers but the way you set > the property outside of pass->properties_provided breaks this. Thus > maybe split objsz into two separate passes rather than using the > flag so you can use properties_provided. I wanted to avoid having two separate passes, but if you prefer it, it can be done. Will be a user visible change in the dumps and for -fdisable-tree-* etc. (though we do such changes all the time).
[Bug tree-optimization/101419] [9/10/11/12 Regression] collapsing memset() calls can break __builtin_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #14 from Jakub Jelinek ---
I agree about most of the passes you are moving, but I have an (albeit
artificial) testcase that proves that cunrolli does affect objsz:
__SIZE_TYPE__ a[10];
void
foo (void)
{
char *p = __builtin_malloc (64);
for (int i = 0; i < 4; i++)
{
a[i] = __builtin_object_size (p, 0);
p += 6;
}
}
When objsz is done before cunrolli, a[0] to a[3] will all be 64, while
when it is done after cunrolli, it will be 64, 58, 52, 46.
So, what about a mix of your and my patch, add
--- gcc/passes.def
+++ gcc/passes.def
@@ -194,14 +194,14 @@ along with GCC; see the file COPYING3. If not see
They ensure memory accesses are not indirect wherever possible. */
NEXT_PASS (pass_strip_predict_hints, false /* early_p */);
NEXT_PASS (pass_ccp, true /* nonzero_p */);
- NEXT_PASS (pass_post_ipa_warn);
/* After CCP we rewrite no longer addressed locals into SSA
form if possible. */
+ NEXT_PASS (pass_post_ipa_warn);
NEXT_PASS (pass_complete_unrolli);
+ NEXT_PASS (pass_object_sizes, false /* insert_min_max_p */);
NEXT_PASS (pass_backprop);
NEXT_PASS (pass_phiprop);
NEXT_PASS (pass_forwprop);
- NEXT_PASS (pass_object_sizes, false /* insert_min_max_p */);
/* pass_build_alias is a dummy pass that ensures that we
execute TODO_rebuild_alias at this point. */
NEXT_PASS (pass_build_alias);
to my patch?
[Bug tree-optimization/101419] [9/10/11/12 Regression] collapsing memset() calls can break __builtin_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419 --- Comment #13 from Richard Biener --- (In reply to Richard Biener from comment #12) > (In reply to Jakub Jelinek from comment #10) > > Created attachment 51139 [details] > > gcc12-pr101419.patch > > > > Full untested patch. > > I guess that's certainly what was intended (and after the patch more > explicit). Whether it's good to not CSE any addresses in unrolled loop > bodies is another question (but see my proposed pass order change which > would fix this). Note it might "break" GIMPLE FE testcases with startwith after the objsz pass - break in the sense that later FRE will behave differently. Note usually we still run all property providers but the way you set the property outside of pass->properties_provided breaks this. Thus maybe split objsz into two separate passes rather than using the flag so you can use properties_provided.
[Bug tree-optimization/101419] [9/10/11/12 Regression] collapsing memset() calls can break __builtin_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419 --- Comment #12 from Richard Biener --- (In reply to Jakub Jelinek from comment #10) > Created attachment 51139 [details] > gcc12-pr101419.patch > > Full untested patch. I guess that's certainly what was intended (and after the patch more explicit). Whether it's good to not CSE any addresses in unrolled loop bodies is another question (but see my proposed pass order change which would fix this).
[Bug tree-optimization/101419] [9/10/11/12 Regression] collapsing memset() calls can break __builtin_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419 --- Comment #11 from Richard Biener --- I think none of NEXT_PASS (pass_complete_unrolli); NEXT_PASS (pass_backprop); NEXT_PASS (pass_phiprop); NEXT_PASS (pass_forwprop); are useful for objsize so IMHO we should move pass_object_sizes earlier. CCP and it's into SSA are probably useful though. Like the following (untested): diff --git a/gcc/passes.def b/gcc/passes.def index 945d2bc797c..fd38e1f2d8e 100644 --- a/gcc/passes.def +++ b/gcc/passes.def @@ -194,14 +194,14 @@ along with GCC; see the file COPYING3. If not see They ensure memory accesses are not indirect wherever possible. */ NEXT_PASS (pass_strip_predict_hints, false /* early_p */); NEXT_PASS (pass_ccp, true /* nonzero_p */); - NEXT_PASS (pass_post_ipa_warn); /* After CCP we rewrite no longer addressed locals into SSA form if possible. */ + NEXT_PASS (pass_object_sizes, false /* insert_min_max_p */); + NEXT_PASS (pass_post_ipa_warn); NEXT_PASS (pass_complete_unrolli); NEXT_PASS (pass_backprop); NEXT_PASS (pass_phiprop); NEXT_PASS (pass_forwprop); - NEXT_PASS (pass_object_sizes, false /* insert_min_max_p */); /* pass_build_alias is a dummy pass that ensures that we execute TODO_rebuild_alias at this point. */ NEXT_PASS (pass_build_alias);
[Bug tree-optimization/101419] [9/10/11/12 Regression] collapsing memset() calls can break __builtin_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2021-07-12 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #10 from Jakub Jelinek --- Created attachment 51139 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51139=edit gcc12-pr101419.patch Full untested patch.
[Bug tree-optimization/101419] [9/10/11/12 Regression] collapsing memset() calls can break __builtin_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419 --- Comment #9 from Jakub Jelinek --- The above patch will slightly pessimize optimizations during the NEXT_PASS (pass_remove_cgraph_callee_edges); /* Initial scalar cleanups before alias computation. They ensure memory accesses are not indirect wherever possible. */ NEXT_PASS (pass_strip_predict_hints, false /* early_p */); NEXT_PASS (pass_ccp, true /* nonzero_p */); NEXT_PASS (pass_post_ipa_warn); /* After CCP we rewrite no longer addressed locals into SSA form if possible. */ NEXT_PASS (pass_complete_unrolli); NEXT_PASS (pass_backprop); NEXT_PASS (pass_phiprop); NEXT_PASS (pass_forwprop); passes right after IPA, where we currently only pessimize it before and during IPA.
[Bug tree-optimization/101419] [9/10/11/12 Regression] collapsing memset() calls can break __builtin_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419 --- Comment #8 from Jakub Jelinek --- --- gcc/tree-pass.h.jj 2021-01-27 10:10:00.525903635 +0100 +++ gcc/tree-pass.h 2021-07-12 13:10:59.621933276 +0200 @@ -208,6 +208,7 @@ protected: #define PROP_gimple_lcf(1 << 1)/* lowered control flow */ #define PROP_gimple_leh(1 << 2)/* lowered eh */ #define PROP_cfg (1 << 3) +#define PROP_objsz (1 << 4)/* object sizes computed */ #define PROP_ssa (1 << 5) #define PROP_no_crit_edges (1 << 6) #define PROP_rtl (1 << 7) --- gcc/tree-object-size.c.jj 2021-01-04 10:25:39.911221618 +0100 +++ gcc/tree-object-size.c 2021-07-12 13:19:50.021568629 +0200 @@ -1450,6 +1450,8 @@ pass_object_sizes::execute (function *fu } fini_object_sizes (); + if (!insert_min_max_p) +fun->curr_properties |= PROP_objsz; return 0; } --- gcc/tree-ssa-sccvn.c.jj 2021-06-09 10:20:08.988342285 +0200 +++ gcc/tree-ssa-sccvn.c2021-07-12 13:14:33.482962387 +0200 @@ -925,12 +925,10 @@ copy_reference_ops_from_ref (tree ref, v + (wi::to_offset (bit_offset) >> LOG2_BITS_PER_UNIT)); /* Probibit value-numbering zero offset components of addresses the same before the pass folding - __builtin_object_size had a chance to run - (checking cfun->after_inlining does the - trick here). */ + __builtin_object_size had a chance to run. */ if (TREE_CODE (orig) != ADDR_EXPR || maybe_ne (off, 0) - || cfun->after_inlining) + || (cfun->curr_properties & PROP_objsz)) off.to_shwi (); } } seems to work for both testcases.
[Bug c++/101338] Redeclaration of template members in subclass fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101338 --- Comment #2 from Josip Palavra --- (In reply to Jonathan Wakely from comment #1) > All your examples are missing a semi-colon after the struct definition. Oops, thanks for pointing that out! The problem persists even with all the semicolons in their right places though...
[Bug libstdc++/101318] [10 only] Comparison operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101318 Jonathan Wakely changed: What|Removed |Added Target Milestone|10.4|10.3
[Bug libstdc++/96851] operator< on std::array does not work in constexpr, for sizeof(T) == 1, and N > 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851 Jonathan Wakely changed: What|Removed |Added CC||tobias.bruell at gmail dot com --- Comment #8 from Jonathan Wakely --- *** Bug 101318 has been marked as a duplicate of this bug. ***
[Bug libstdc++/101318] [10 only] Comparison operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101318 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- Already fixed for GCC 10.3, you should upgrade. *** This bug has been marked as a duplicate of bug 96851 ***
[Bug libstdc++/101268] Refer manual readers to cppreference.com for API details
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101268 --- Comment #5 from Jonathan Wakely --- Thanks. Please submit patches to the mailing lists as required by: https://gcc.gnu.org/contribute.html#patches Please capitalize "an" at the start of every sentence, and use markdown `...` instead of @c ... Please change the terms "superiority" and "inferiority" to something defined in the standard. The indentation of the new comments looks wrong too.
[Bug c++/101343] ICE in tsubst_copy, at cp/pt.c:15732
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101343
Martin Liška changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #3 from Martin Liška ---
Reduced test-case:
template using ElementIdArray = int;
template struct QStaticStringData;
struct GraphModelImpl;
struct __uniq_ptr_impl {
struct _Ptr {
using type = GraphModelImpl *;
};
using pointer = _Ptr::type;
};
struct unique_ptr {
using pointer = __uniq_ptr_impl::pointer;
pointer operator->();
};
struct GraphModel {
unique_ptr _;
void buildVisualisations();
} __trans_tmp_2;
template struct VisualisationsBuilder {
VisualisationsBuilder(GraphModel, ElementIdArray);
void build() {
[](auto) {
enum { Size };
QStaticStringData qstring_literal;
};
}
};
using NodeVisuals = int;
struct GraphModelImpl {
NodeVisuals _mappedNodeVisuals;
};
void GraphModel::buildVisualisations() {
VisualisationsBuilder nodeVisualisationsBuilder(__trans_tmp_2,
_->_mappedNodeVisuals);
nodeVisualisationsBuilder.build();
}
[Bug c++/101338] Redeclaration of template members in subclass fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101338
Jonathan Wakely changed:
What|Removed |Added
Target|x86-64 |
Build|Homebrew GCC 11.1.0_1 |
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-07-12
Host|macOS 11.4 |
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
All your examples are missing a semi-colon after the struct definition.
The corrected last example is:
struct A
{
template struct Inner;
template struct Inner<0, i> {};
};
struct B: A
{
template struct Inner; // OK, shadows declaration in A
template struct Inner<0, i> {};
template struct Inner; // Fail, redeclaration.
};
[Bug c++/101344] braced-init-list not supported in an aggregate deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101344
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-07-12
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Jonathan Wakely ---
N.B. the code requires -std=gnu++20 to compile.
(In reply to Fedor Chelnokov from comment #0)
>A a{{1, 2}}; // ok in gcc
>B b{{1, 2}}; // error in gcc (ok in other compilers, e.g. msvc)
FWIW MSVC seems to be the only compiler that accepts it. Clang and Intel do not
accept either line, due to incomplete C++20 support.
[Bug tree-optimization/101419] [9/10/11/12 Regression] collapsing memset() calls can break __builtin_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419 --- Comment #7 from Jakub Jelinek --- It is the cunrolli pass where things go wrong (it VNs the >c for both __builtin_object_size calls while previously only the first one was >c and the second was >i). Now, objsz2 obviously needs to be done after IPA opts (most importantly inlining), but what other opt passes we want in between IPA and objsz2 is a question: PUSH_INSERT_PASSES_WITHIN (pass_all_optimizations) NEXT_PASS (pass_remove_cgraph_callee_edges); /* Initial scalar cleanups before alias computation. They ensure memory accesses are not indirect wherever possible. */ NEXT_PASS (pass_strip_predict_hints, false /* early_p */); NEXT_PASS (pass_ccp, true /* nonzero_p */); NEXT_PASS (pass_post_ipa_warn); /* After CCP we rewrite no longer addressed locals into SSA form if possible. */ NEXT_PASS (pass_complete_unrolli); NEXT_PASS (pass_backprop); NEXT_PASS (pass_phiprop); NEXT_PASS (pass_forwprop); NEXT_PASS (pass_object_sizes, false /* insert_min_max_p */); I bet the rewriting no longer addressed locals into SSA form if possible done for ccp could be sometimes relevant, because when an address is stored into a previously address taken local and read back, then __bos could see it if in SSA form and not otherwise. And in theory the cunrolli could reveal some cases, though not sure. So, either do the TODO_update_address_taken sooner (e.g. at end of pass_remove_cgraph_callee_edges - does ccp itself bring any address taken removal opportunities?) and then do objsz2, or schedule another objsz pass with insert_minmax right at the start of pass_all_optimizations? Out of ideas and it is still just mitigation. Another way would be change SCCVN to handle it conservatively for __bos (x, 1) but that could break the rarely used __bos (x, 3) - but it can break randomly for both now. E.g. in the _8 = _5(D)->c; use (_8); ... _9 = _5(D)->i; use2 (_9); case when objsz2 wasn't done yet (check with property) and perhaps if any __bos (x, 1) are seen (cfun flag propagated conservatively during inlining), compute __bos (ptr, 1) for both and rewrite the setter to the larger one, i.e. not optimize into: _8 = _5(D)->c; use (_8); ... use2 (_8); but _8 = _5(D)->i; use (_8); ... use2 (_8);
[Bug c++/101402] [DR 1001] top cv qualifier not dropped for array type typedef in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101402 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2021-07-12 Summary|top cv qualifier not|[DR 1001] top cv qualifier |dropped for array type |not dropped for array type |typedef in template class |typedef in template class |(core 1001) | --- Comment #1 from Jonathan Wakely --- (In reply to nick huang from comment #0) > This example code from core > 1001(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1001) is > still giving no matching template declaration error. The issue is still open and has not been resolved yet. > 2. C++ standard requires top level cv qualifier being dropped when forming > function type.(https://timsong-cpp.github.io/cppwp/dcl.fct#5) Yes, that's what the issue quotes, and it also says "It is not clear how or whether this adjustment should be applied to parameters of function templates when the parameter has a dependent type, however." > > 3. When both 'const' are removed from template function and specialization, > there is no error which proves array type works as long as there is no top > level cv qualifier. > > 4. I feel this is rather a high-profile bug as the example code is listed in > active core language issues long ago, The issue is still active, meaning the standard has not been fixed to say what the correct behaviour is.
[Bug tree-optimization/101419] [9/10/11/12 Regression] collapsing memset() calls can break __builtin_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419 --- Comment #6 from Richard Biener --- Nothing can "fix" __builtin_object_size here (on sub-objects) without changing how we represent and CSE addresses, esp. if you consider inlining where we want to interpret __builtin_object_size (p, ..) as having passed not literal 'p' but the value 'p' has at this point. Thus any pointer CSE that happens on the value of 'p' before inlining happens will "break" our expectation on it. So suppose for a moment we'd have ADDR_WITH_SIZE_EXPR which we could lower to just ADDR_EXPR after the final object-size pass. Then during all early opts we couldn't CSE addresses with different sizes or simplify equality conditionals on them. And we'd have to do that everywhere as for example an LTO link might expose a caller/callee with __builtin_object_size. Maybe we could somehow lower ADDR_WITH_SIZE_EXPR that do not "escape" (but we'd need to compute that). That said, my point is that sth like __builtin_object_size is quite fundamentally broken [for an optimizing compiler].
[Bug libstdc++/101406] poor codegen for shared_ptr copy & destory, compared to boost::shared_ptr and libc++'s implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101406
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WONTFIX
--- Comment #2 from Jonathan Wakely ---
(In reply to Marc Mutz from comment #0)
> Consider
>
> // https://godbolt.org/z/efTW6MoEh
N.B. -DNDEBUG has no effect on anything in libstdc++, it's not allowed to use
anywhere.
> void test_copy(const std::shared_ptr )
> { auto copy = sp; }
>
> vs.
>
> // https://godbolt.org/z/3aoGq1f9P
> void test_copy(const boost::shared_ptr )
> { auto copy = sp; }
>
> In the first cast, over 70 lines of assembler are emitted, in the second,
> around 30. This seems to be in large part because in
> _Sp_counted_base::_M_add_ref_copy(), you're using __atomic_add_dispatch()
> even if _Lp is _S_atomic.
That's by design:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/memory.html#shared_ptr.policy
"For all three policies, reference count increments and decrements are done via
the functions in ext/atomicity.h, which detect if the program is
multi-threaded. If only one thread of execution exists in the program then less
expensive non-atomic operations are used."
> It seems to me that a specialisation of this
> function template for _S_atomic calling just __atomic_add() is missing:
No, the _S_atomic policy doesn't mean "use atomics unconditionally". We still
go through __atomic_add_dispatch so that we avoid the atomics in
single-threaded programs.
With a new glibc the check for multiple threads is cheaper and should optimize
better.
[Bug libstdc++/101427] [11/12 Regression] std::get should refuse to compile if type is provided and it is duplicated in std::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101427 Jonathan Wakely changed: What|Removed |Added Known to work||10.3.0 Summary|std::get should refuse to |[11/12 Regression] std::get |compile if type is provided |should refuse to compile if |and it is duplicated in |type is provided and it is |std::tuple |duplicated in std::tuple Ever confirmed|0 |1 Last reconfirmed||2021-07-12 Target Milestone|--- |11.2 Known to fail||11.1.0, 12.0 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED
[Bug tree-optimization/101419] [9/10/11/12 Regression] collapsing memset() calls can break __builtin_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
Jakub Jelinek changed:
What|Removed |Added
CC||siddhesh at redhat dot com
--- Comment #5 from Jakub Jelinek ---
Note, for the above patch I was worried about something like:
struct S { int a; char b[36]; int c; };
static inline __SIZE_TYPE__
foo (char *p)
{
return __builtin_object_size (p, 1);
}
__SIZE_TYPE__
bar (void)
{
struct S s;
return foo ([0]);
}
with -O2 -fno-early-inlining, but in that case we actually don't perform that
at all - the MIN_EXPR is added only if __bos can be computed during the objsz1
pass to something other than the "unknown" value. If it is, then there
shouldn't be pointer passed from caller as one of the possible values, so maybe
it is safe.
Of course this shows that the objsz1 pass is just mitigation pass, because when
the function with __builtin_object_size calls isn't early inlined or some
caller of that and ultimately objsz1 pass isn't able to compute a known value,
then any SCCVN pointer replacement with different subobject sizes that could
feed a subobject __bos (1 or 3) could change the user visible value.
E.g.
struct S { char b[36]; int c; };
void baz (char *);
static inline __SIZE_TYPE__
foo (char *p)
{
return __builtin_object_size (p, 1);
}
__SIZE_TYPE__
bar (void)
{
struct S *p = __builtin_malloc (2 * sizeof (struct S)) + sizeof (struct S);
baz ((char *) p);
return foo (>b[0]);
}
doesn't reproduce it, we still pass
p_5 = _1 + 40;
baz (p_5);
_2 = [(struct S *)_1 + 40B].b[0];
_8 = __builtin_object_size (_2, 1);
and don't figure out that _2 == p_5.
But modified #c0 testcase triggers it at -O2:
typedef __SIZE_TYPE__ size_t;
void baz (int, int) __attribute__((__warning__("detected overflow")));
union U {
int i;
char c;
};
static void
qux (void *p, size_t q)
{
if (__builtin_object_size (p, 1) < q)
baz (__builtin_object_size (p, 1), q);
__builtin_memset (p, 0, q);
}
static void
foo (union U *u)
{
qux (>c, sizeof (u->c));
qux (>i, sizeof (u->i));
}
void
bar (union U *u)
{
int i, j;
for (i = 0; i < 1; i++)
{
foo (u);
for (j = 0; j < 2; j++)
asm volatile ("");
}
}
and this patch doesn't fix it.
[Bug tree-optimization/101394] ICE on valid code with -O2: SSA corruption: Unable to coalesce ssa_names 10 and 19 which are marked as MUST COALESCE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101394 Richard Biener changed: What|Removed |Added Known to work||12.0 --- Comment #5 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/100778] [11 Regression] Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100778 Bug 100778 depends on bug 101423, which changed state. Bug 101423 Summary: [12 Regression] ICE in vect_schedule_slp_node, at tree-vect-slp.c:7113 since r12-1951-ga3aaba68405751ba https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101423 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 101423, which changed state. Bug 101423 Summary: [12 Regression] ICE in vect_schedule_slp_node, at tree-vect-slp.c:7113 since r12-1951-ga3aaba68405751ba https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101423 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/101423] [12 Regression] ICE in vect_schedule_slp_node, at tree-vect-slp.c:7113 since r12-1951-ga3aaba68405751ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101423 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug tree-optimization/101394] ICE on valid code with -O2: SSA corruption: Unable to coalesce ssa_names 10 and 19 which are marked as MUST COALESCE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101394 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:92343e0ba4d47f21ae20ffcb83d736bdbc15dae0 commit r12-2244-g92343e0ba4d47f21ae20ffcb83d736bdbc15dae0 Author: Richard Biener Date: Mon Jul 12 10:49:03 2021 +0200 tree-optimization/101394 - fix PRE full redundancy wrt abnormals This avoids adding a copy from an abnormal picked up from PHI translation much like we'd avoid inserting the translated expression on pred edges. 2021-07-12 Richard Biener PR tree-optimization/101394 * tree-ssa-pre.c (do_pre_regular_insertion): Avoid inserting copies from abnormals for a full redundancy. * gcc.dg/torture/pr101394.c: New testcase.
[Bug tree-optimization/101423] [12 Regression] ICE in vect_schedule_slp_node, at tree-vect-slp.c:7113 since r12-1951-ga3aaba68405751ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101423 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:123d0a597beb6d9865f808bf15b0d67f2a8fd5b2 commit r12-2243-g123d0a597beb6d9865f808bf15b0d67f2a8fd5b2 Author: Richard Biener Date: Mon Jul 12 10:26:25 2021 +0200 middle-end/101423 - internal calls do not trap This adjusts gimple_could_trap_p to not consider internal function calls to trap compared to indirect calls or calls to weak functions. 2021-07-12 Richard Biener PR middle-end/101423 * gimple.c (gimple_could_trap_p_1): Internal function calls do not trap. * tree-eh.c (tree_could_trap_p): Likewise.
[Bug target/101424] [12 Regression] ICE in extract_insn, at recog.c:2771 since r12-2085-gf65878178ab05180
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101424 Uroš Bizjak changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Status|NEW |ASSIGNED --- Comment #2 from Uroš Bizjak --- Created attachment 51138 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51138=edit Proposed patch
[Bug tree-optimization/101403] [12 Regression] wrong code with __builtin_bswap16() at -O1 by r12-2137
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101403 --- Comment #8 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:0192c3eedbc7e6fe703abd8b321f400ddb02adf7 commit r12-2242-g0192c3eedbc7e6fe703abd8b321f400ddb02adf7 Author: Roger Sayle Date: Mon Jul 12 10:59:08 2021 +0100 Tweak testcase for PR tree-optimization/101403. Initialize unused variable u in compound expression. Committed as obvious. 2021-07-12 Roger Sayle Jakub Jelinek gcc/testsuite/ChangeLog PR tree-optimization/101403 * gcc.dg/pr101403.c: Avoid (unimportant) uninitialized variable.
[Bug tree-optimization/101419] [9/10/11/12 Regression] collapsing memset() calls can break __builtin_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #4 from Jakub Jelinek ---
--- gcc/tree-object-size.c.jj 2021-01-04 10:25:39.911221618 +0100
+++ gcc/tree-object-size.c 2021-07-12 11:28:51.328120222 +0200
@@ -1393,6 +1393,11 @@ pass_object_sizes::execute (function *fu
{
tree tem = make_ssa_name (type);
gimple_call_set_lhs (call, tem);
+ if (object_size_type == 1)
+ {
+ ost = build_zero_cst (TREE_TYPE (ost));
+ gimple_call_set_arg (call, 1, ost);
+ }
enum tree_code code
= object_size_type == 1 ? MIN_EXPR : MAX_EXPR;
tree cst = build_int_cstu (type, bytes);
works, but unfortunately only for __builtin_object_size (, 1).
When I did that also for 3 (to turn it into 2), it breaks several
gcc.dg/builtin-object-size*.c tests.
0 is defined as an upper bound of the object size, subobjects not taken into
account
1 is defined similarly, but subobjects are taken into account
2 is defined as a lower bound of the object size, subobjects not taken into
account
3 is 2 with subobjects
-D_FORTIFY_SOURCE={1,2} typically only uses 0 and 1 modes, 2 and 3 are rare,
and are useful e.g. when somebody wants to find out if the object size is exact
or not (for exact case the upper and lower bounds are equal).
[Bug target/66791] [ARM] Replace builtins with gcc vector extensions code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66791 --- Comment #10 from CVS Commits --- The master branch has been updated by Prathamesh Kulkarni : https://gcc.gnu.org/g:6785eb595981abd93ad85edcfdf1d2e43c0841f5 commit r12-2241-g6785eb595981abd93ad85edcfdf1d2e43c0841f5 Author: prathamesh.kulkarni Date: Mon Jul 12 15:18:21 2021 +0530 arm/66791: Replace builtins for unsigned and fp vmul_n intrinsics. gcc/ChangeLog: PR target/66791 * config/arm/arm_neon.h (vmul_n_u32): Replace call to builtin with __a * __b. (vmulq_n_u32): Likewise. (vmul_n_f32): Gate __a * __b on __FAST_MATH__. (vmulq_n_f32): Likewise. (vmul_n_f16): Likewise. (vmulq_n_f16): Likewise. gcc/testsuite/ChangeLog: PR target/66791 * gcc.target/arm/armv8_2-fp16-neon-2.c: Adjust.
[Bug target/101428] [10/11/12 Regression] ICE: 'asm' clobber conflict with output operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101428 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.4
[Bug other/86656] [meta-bug] Issues found with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656 Bug 86656 depends on bug 101425, which changed state. Bug 101425 Summary: [12 Regression] AddressSanitizer: heap-buffer-overflow at candidates_list_and_hint since r12-1903-gaf9987e817f54806 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101425 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug sanitizer/101425] [12 Regression] AddressSanitizer: heap-buffer-overflow at candidates_list_and_hint since r12-1903-gaf9987e817f54806
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101425 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Martin Liška --- Fixed.
[Bug sanitizer/101425] [12 Regression] AddressSanitizer: heap-buffer-overflow at candidates_list_and_hint since r12-1903-gaf9987e817f54806
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101425 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:9b8b37d1b6301855213b8d4860feaeb74d464c6b commit r12-2240-g9b8b37d1b6301855213b8d4860feaeb74d464c6b Author: Martin Liska Date: Mon Jul 12 10:59:06 2021 +0200 offloading: fix -foffload hinting PR sanitizer/101425 gcc/ChangeLog: * gcc.c (check_offload_target_name): Call candidates_list_and_hint only if we have a candidate.
[Bug c/101313] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in count_type_elements, at expr.c:6273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101313 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Last reconfirmed||2021-07-12 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- It's very old (4.9.0+).
[Bug fortran/101330] [openmp]ICE in free_expr0(): Bad expr type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101330 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Btw. started with r12-1108-g9a5de4d5af1c10a8.
[Bug c++/101343] ICE in tsubst_copy, at cp/pt.c:15732
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101343 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Keywords|needs-bisection | --- Comment #2 from Martin Liška --- Started with r11-7993-g9f4c41147a41d08a, so very likely dup of PR95317. Anyway, I'm reducing that right now.
[Bug debug/101398] Multiple DW_TAG_formal_parameter DIEs for the same parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101398 Martin Jambor changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #1 from Martin Jambor --- Could you please generate and attach pre-processed source code of the source file with the problematic function?
[Bug tree-optimization/101394] ICE on valid code with -O2: SSA corruption: Unable to coalesce ssa_names 10 and 19 which are marked as MUST COALESCE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101394 --- Comment #3 from Martin Liška --- Just for the record, started with r9-2475-g4864297f7858617a.
[Bug c++/101421] ICE: in lookup_template_class_1, at cp/pt.c:10005
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101421 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r11-86-gef3479afc5ab415f.
[Bug tree-optimization/101419] [9/10/11/12 Regression] collapsing memset() calls can break __builtin_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419 --- Comment #3 from Richard Biener --- (In reply to Jakub Jelinek from comment #2) > Started with r9-2635-g78ea9abc2018243af7f7ada6135144ac90c6ad27 > I wonder if objsz pass when insert_min_max_p shouldn't in addition to adding > MIN_EXPR or MAX_EXPR around the result of __bos also drop the least > significant bit from the __bos second argument. But then isn't this wrong as well? Btw, I never get what the second bit means, it's documented as "The second bit determines if maximum or minimum of remaining bytes is computed." but does it compute the maximum size when the bit is set or when it is not set? For the least significant bit the situation is better: "If the least significant bit is clear, objects are whole variables, if it is set, a closest surrounding subobject is considered the object a pointer points to." Unfortunately the examples also only use 0 and 1.
[Bug c++/101420] ICE in build_special_member_call, at cp/call.c:10179
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101420 --- Comment #18 from Avi Kivity --- It's still >7MB long, so I'll stop reducing.
[Bug c++/98056] ICE tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.c:9862 since r11-2183-g0f66b8486cea8668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056 --- Comment #10 from Iain Sandoe --- *** Bug 101420 has been marked as a duplicate of this bug. ***
