[Bug target/105447] argument passing of packed struct causes aligned read of non-packed struct size with information leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105447 Richard Biener changed: What|Removed |Added Target||x86_64-*-* i?86-*-* Summary|argument passing of packed |argument passing of packed |struct causes aligned read |struct causes aligned read |of non-packed struct size |of non-packed struct size ||with information leak --- Comment #1 from Richard Biener --- It probably happens on more targets. Am I correct you are worried about the information leak of the first two bytes of the next array element to the (possibly external and untrusted) function f1()?
[Bug target/105447] argument passing of packed struct causes aligned read of non-packed struct size with information leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105447 --- Comment #2 from Richard Biener --- clang 11 produces movlg_32(%rip), %eax movlg_32+4(%rip), %edi shlq$32, %rdi orq %rax, %rdi callq f1 which does the same just in a less efficient way.
[Bug tree-optimization/105437] [11/12/13 Regression] ICE on GIMPLE pass slp when vectorizer is enabled since r11-1801-g9e5508c2d006f2d4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105437 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:3a3eda000fdf4f8754c9a2535191091f1db0c2a2 commit r13-66-g3a3eda000fdf4f8754c9a2535191091f1db0c2a2 Author: Richard Biener Date: Mon May 2 09:30:27 2022 +0200 tree-optimization/105437 - BB vect with extern defs of throwing stmts We have to watch out for vectorized stmt insert locations if the def from the last stmt alters control flow. We constrain region building so we know the def is outside of the current region and thus we can insert at the region start point. 2022-05-02 Richard Biener PR tree-optimization/105437 * tree-vect-slp.cc (vect_schedule_slp_node): Handle the case where last_stmt alters control flow. * g++.dg/vect/pr105437.cc: New testcase.
[Bug tree-optimization/105437] [11/12 Regression] ICE on GIMPLE pass slp when vectorizer is enabled since r11-1801-g9e5508c2d006f2d4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105437 Richard Biener changed: What|Removed |Added Known to fail||11.3.1, 12.0 Known to work||13.0 Summary|[11/12/13 Regression] ICE |[11/12 Regression] ICE on |on GIMPLE pass slp when |GIMPLE pass slp when |vectorizer is enabled since |vectorizer is enabled since |r11-1801-g9e5508c2d006f2d4 |r11-1801-g9e5508c2d006f2d4 --- Comment #3 from Richard Biener --- Fixed on trunk sofar.
[Bug debug/105415] [9/10/11/12/13 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105415 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:02f03c5c826d0cb7c32398af0c4282921e6e072a commit r13-68-g02f03c5c826d0cb7c32398af0c4282921e6e072a Author: Jakub Jelinek Date: Mon May 2 11:30:58 2022 +0200 expand: Throw away non-external decls without varpool nodes [PR105415] The following testcase fails -fcompare-debug on aarch64-linux. The problem is that for the n variable we create a varpool node, then remove it again because the var isn't really used, but it keeps being referenced in debug stmts/insns with -g. Later during sched1 pass we ask whether the n var can be modified through some store to an anchored variable and with -g we create a new varpool node for it again just so that we can find its ultimate alias target. Even later on we create some cgraph node for the loop parallelization, but as there has been an extra varpool node creation in between, we get higher node->order with -g than without. The patch fixes that by throwing variables without varpool nodes away during expansion time, they are very unlikely to actually end up with useful debug info anyway. I've bootstrapped/regtested the following on x86_64-linux and i686-linux, then bootstrapped with the patch reverted, reapplied the patch and did make cc1plus in stage3. The debug section sizes are identical, .debug_info and .debug_loc is identical too, so I think we don't lose any debug info through it. So at least on cc1plus it makes no difference. 2022-05-02 Jakub Jelinek PR debug/105415 * cfgexpand.cc (expand_debug_expr): Don't make_decl_rtl_for_debug if there is no symtab node for the VAR_DECL. * gcc.dg/pr105415.c: New test.
[Bug debug/105415] [9/10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105415 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11/12/13 Regression] |[9/10/11/12 Regression] |'-fcompare-debug' failure |'-fcompare-debug' failure |w/ -O2 |w/ -O2 |-ftree-parallelize-loops=2 |-ftree-parallelize-loops=2 |since |since |r7-4900-g59ec925b1199f9 |r7-4900-g59ec925b1199f9 --- Comment #7 from Jakub Jelinek --- Fixed on the trunk. Not really sure about backports, the exact symtab order member values I think shouldn't actually affect code generations, so besides -fcompare-debug it probably isn't that urgent.
[Bug tree-optimization/105451] New: miss optimizations due to inconsistency in complex numbers associativity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105451
Bug ID: 105451
Summary: miss optimizations due to inconsistency in complex
numbers associativity
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: tnfchris at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
The two functions
#include
void f (complex double * restrict a, complex double *restrict b,
complex double *restrict c, complex double *res, int n)
{
for (int i = 0; i < n; i++)
res[i] = a[i] * (b[i] * c[i]);
}
and
void g (complex double * restrict a, complex double *restrict b,
complex double *restrict c, complex double *res, int n)
{
for (int i = 0; i < n; i++)
res[i] = (a[i] * b[i]) * c[i];
}
At -Ofast produce the same code, but internally they get there using different
SLP trees.
The former creates a chain of VEC_PERM_EXPR nodes as is expected
tinyurl.com/cmulslp1 however the latter avoids the need of the permutes by
duplicating the elements of the complex number https://tinyurl.com/cmulslp2
The former we can detect as back to back complex multiplication but the latter
we can't.
Not sure what the best way to get consistency here is.
[Bug libstdc++/105441] [12/13 Regression] The floating point overload of from_chars ignores 'P' for hex format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105441 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:576f975cabb0fd9843de152a2d247d486a967b08 commit r13-69-g576f975cabb0fd9843de152a2d247d486a967b08 Author: Patrick Palka Date: Mon May 2 07:00:48 2022 -0400 libstdc++: case-sensitivity in hexfloat std::from_chars [PR105441] The hexfloat parser for binary32/64 added in r12-6645-gcc3bf3404e4b1c overlooked that the exponent part can also begin with an uppercase 'P'. PR libstdc++/105441 libstdc++-v3/ChangeLog: * src/c++17/floating_from_chars.cc (__floating_from_chars_hex): Also accept 'P' as the start of the exponent. * testsuite/20_util/from_chars/7.cc: Add corresponding testcase.
[Bug libstdc++/103911] std::from_chars shouldn't call isdigit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103911 --- Comment #6 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:86d821ddf5615e693ead667b2580898f46de8eb9 commit r13-70-g86d821ddf5615e693ead667b2580898f46de8eb9 Author: Patrick Palka Date: Mon May 2 07:01:33 2022 -0400 libstdc++: Don't use std::tolower in [PR103911] As with std::isdigit in r12-6281-gc83ecfbe74a5cf, we shouldn't be using std::tolower in either. PR libstdc++/103911 libstdc++-v3/ChangeLog: * src/c++17/floating_from_chars.cc (find_end_of_float): Accept two delimeters for the exponent part in the form of a possibly NULL string of length two. Don't use std::tolower. (pattern): Adjust calls to find_end_of_float accordingly.
[Bug tree-optimization/104240] SLP discovery does not consider swapping comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104240 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:41e3db05d697405256b6002d8432955a93d249f1 commit r13-71-g41e3db05d697405256b6002d8432955a93d249f1 Author: Richard Biener Date: Mon May 2 12:01:51 2022 +0200 tree-optimization/104240 - SLP discovery with swapped comparisons The following extends SLP discovery to handle swapped operands in comparisons. 2022-05-02 Richard Biener PR tree-optimization/104240 * tree-vect-slp.cc (op1_op0_map): New. (vect_get_operand_map): Handle compares. (vect_build_slp_tree_1): Support swapped operands for tcc_comparison. * gcc.dg/vect/bb-slp-pr104240.c: New testcase.
[Bug tree-optimization/104240] SLP discovery does not consider swapping comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104240 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 104240, which changed state. Bug 104240 Summary: SLP discovery does not consider swapping comparisons https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104240 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/104265] Missed vectorization in 526.blender_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104265 Bug 104265 depends on bug 104240, which changed state. Bug 104240 Summary: SLP discovery does not consider swapping comparisons https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104240 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/105452] New: static_assert inside nameless nested union: invalid "inaccessible within this context" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105452
Bug ID: 105452
Summary: static_assert inside nameless nested union: invalid
"inaccessible within this context" error
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: foobarandfoo at gmail dot com
Target Milestone: ---
template
struct C {
union {
char v;
static_assert(sizeof(v) == sizeof(char), "");
};
};
int main() {
C x;
}
Fails to compile in every version I tried (including 13.0, 11.3.0, 11.2.0,
11.1.0, 10.3, 9.4) with "error: ‘char Cv’ is
inaccessible within this context static_assert(sizeof(v) == sizeof(char),
"");". If we modify struct C to be non-templated, the code compiles
successfully. Clang and MSVC compile the initial code.
https://godbolt.org/z/j171x1aGz
[Bug c++/105436] [13 Regression] parse error with >= operator expression in template argument list in C++14 mode since r13-40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105436
--- Comment #6 from Sergei Trofimovich ---
Noticed similar build failure on llvm-13:
[ 1%] Building CXX object
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/AsmMatcherEmitter.cpp.o
In file included from /build/source/llvm/include/llvm/ADT/Sequence.h:23,
from
/build/source/llvm/include/llvm/Support/MachineValueType.h:17,
from
/build/source/llvm/utils/TableGen/CodeGenInstruction.h:17,
from /build/source/llvm/utils/TableGen/CodeGenTarget.h:20,
from
/build/source/llvm/utils/TableGen/AsmMatcherEmitter.cpp:98:
/build/source/llvm/include/llvm/Support/MathExtras.h:400:37: error: '>=' should
be '> =' to terminate a template argument list
400 | constexpr inline std::enable_if_t= 64, bool> isUInt(uint64_t) {
| ^~
| > =
/build/source/llvm/include/llvm/Support/MathExtras.h:400:40: error: expected
unqualified-id before numeric constant
400 | constexpr inline std::enable_if_t= 64, bool> isUInt(uint64_t) {
|^~
[Bug tree-optimization/105451] miss optimizations due to inconsistency in complex numbers associativity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105451
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2022-05-02
--- Comment #1 from Richard Biener ---
It's difficult to even spot the difference in the SLP tree, but the
associatable multiplications make it somewhat random which of the valid SLP
tree representations we'll pick. All of the SLP discovery is a heuristically
greedy search for the _first_ match, not for the "best" even ("best"
interpreted as "largest" in case of BB vectorization).
The only thing that reliably happens at the moment is associating until the
leafs are all from one load group (until we support multiple load groups in
one leaf).
[Bug libstdc++/105441] [12/13 Regression] The floating point overload of from_chars ignores 'P' for hex format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105441 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:4a6d7da796e456115bbac92e056123f095a3780c commit r12-8327-g4a6d7da796e456115bbac92e056123f095a3780c Author: Patrick Palka Date: Mon May 2 07:00:48 2022 -0400 libstdc++: case-sensitivity in hexfloat std::from_chars [PR105441] The hexfloat parser for binary32/64 added in r12-6645-gcc3bf3404e4b1c overlooked that the exponent part can also begin with an uppercase 'P'. PR libstdc++/105441 libstdc++-v3/ChangeLog: * src/c++17/floating_from_chars.cc (__floating_from_chars_hex): Also accept 'P' as the start of the exponent. * testsuite/20_util/from_chars/7.cc: Add corresponding testcase. (cherry picked from commit 576f975cabb0fd9843de152a2d247d486a967b08)
[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Target Milestone|--- |12.0
--- Comment #8 from Richard Biener ---
Btw, requires -std=c++20 but -O2 is enough, -O3 not needed.
To quote again:
if (_22 >= &MEM [(void *)"5" + 1B])
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 44944954]:
if (_22 <= "5")
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 22472477]:
_48 = _22 - "5";
if (_48 == 1)
goto ; [34.00%]
else
goto ; [66.00%]
the "simple" thing we fail to thread is
if (_22 >= _1 + 1)
;
else
{
if (_22 <= _1)
; // this must be true, _22 < _1 is true even
}
in fact we fail to canonicalize _22 >= &MEM [(void *)"5" + 1B]
to _22 > "5". fold_comparison via maybe_canonicalize_comparison does such
thing but not for pointers or &MEM.
The following (too special) simplifies the above to
[local count: 89889908]:
if (_22 > &MEM [(void *)"5"])
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 44944954]:
if (_22 <= "5")
goto ; [50.00%]
else
goto ; [50.00%]
but we still won't simplify the second compare.
diff --git a/gcc/match.pd b/gcc/match.pd
index 6d691d302b3..cb16694a150 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -5397,6 +5397,18 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(if (known_eq (off, 0))
{ constant_boolean_node (cmp == EQ_EXPR, type); }
+(for cmp (ge le)
+ cmpp (gt lt)
+ (simplify
+ (cmp:c @0 addr@1)
+ (with
+{ tree m = TREE_OPERAND (@1, 0); }
+(if (TREE_CODE (m) == MEM_REF
+&& integer_onep (TREE_OPERAND (m, 1)))
+ (cmpp @0 { build1 (ADDR_EXPR, TREE_TYPE (@1),
+ build2 (MEM_REF, TREE_TYPE (m), TREE_OPERAND (m, 0),
+ build_zero_cst (TREE_TYPE (TREE_OPERAND (m,
1); })
+
/* Equality compare simplifications from fold_binary */
(for cmp (eq ne)
The ifcombine eventually arrives in
Breakpoint 5, tree_ssa_ifcombine_bb_1 (inner_cond_bb=, outer_cond_bb=,
then_bb=, else_bb=, phi_pred_bb=) at
/home/rguenther/src/gcc-12-branch/gcc/tree-ssa-ifcombine.cc:646
646 if (phi_pred_bb != else_bb
[local count: 89889908]:
if (_22 > &MEM [(void *)"5"])
goto ; [50.00%]
else
goto ; [50.00%]
$7 = void
[local count: 44944954]:
if (_22 <= "5")
goto ; [50.00%]
else
goto ; [50.00%]
$8 = void
but the CFG doesn't resemble any of the forms it handles and it does not
try to catch the case where the inner condition would simplify (basically
thread it without any code duplication). So it doesn't really fit
ifcombine.
The old VRP pass sees
[local count: 44944954]:
_112 = ASSERT_EXPR <_22, _22 <= &MEM [(void *)"5"]>;
if (_112 <= "5")
goto ; [50.00%]
else
goto ; [50.00%]
but concludes
xtract_range_from_stmt visiting:
_112 = ASSERT_EXPR <_22, _22 <= &MEM [(void *)"5"]>;
Found new range for _112: char * VARYING
extract_range_from_stmt visiting:
if (_112 <= "5")
Visiting conditional with predicate: if (_112 <= "5")
With known ranges
_112: char * VARYING
Predicate evaluates to: DON'T KNOW
it might reason that _22 <= &MEM [(void *)"5"] means
_22 == &"5" and track the range of _22 as constant.
That said, we relied on jump threading for these kind of simplifications
but we are not good at this particular case.
[Bug tree-optimization/104336] bogus -Wrestrict for std::string assignment with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104336 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Richard Biener --- let's mark this one as duplicate *** This bug has been marked as a duplicate of bug 105329 ***
[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329 Richard Biener changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #9 from Richard Biener --- *** Bug 104336 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/84774] [meta-bug] bogus/missing -Wrestrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774 Bug 84774 depends on bug 104336, which changed state. Bug 104336 Summary: bogus -Wrestrict for std::string assignment with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104336 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329 Richard Biener changed: What|Removed |Added CC||jwakely at redhat dot com --- Comment #10 from Richard Biener --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104336#c1 contains a workaround for libstdc++
[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329
--- Comment #11 from Richard Biener ---
(In reply to Richard Biener from comment #10)
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104336#c1 contains a workaround
> for libstdc++
Maybe
_GLIBCXX20_CONSTEXPR
basic_string&
assign(const _CharT* __s)
{
__glibcxx_requires_string(__s);
return _M_replace(size_type(0), this->size(), __s,
traits_type::length(__s));
}
isn't the most efficient way to assign a string (constant) looking at
the complexity of _M_replace and its overlap checks (that we all expect
to be optimized away but which are not). In fact the _M_disjunct check
isn't optimized because we cannot tell if the std::string storage
overlaps the constant pool ...
[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329
--- Comment #12 from Richard Biener ---
(In reply to Richard Biener from comment #11)
> (In reply to Richard Biener from comment #10)
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104336#c1 contains a workaround
> > for libstdc++
>
> Maybe
>
> _GLIBCXX20_CONSTEXPR
> basic_string&
> assign(const _CharT* __s)
> {
> __glibcxx_requires_string(__s);
> return _M_replace(size_type(0), this->size(), __s,
> traits_type::length(__s));
> }
>
> isn't the most efficient way to assign a string (constant) looking at
> the complexity of _M_replace and its overlap checks (that we all expect
> to be optimized away but which are not). In fact the _M_disjunct check
> isn't optimized because we cannot tell if the std::string storage
> overlaps the constant pool ...
Maybe
diff --git a/libstdc++-v3/include/bits/basic_string.h
b/libstdc++-v3/include/bits/basic_string.h
index c3fbc53953c..e83f3e8afa4 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -407,7 +407,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
bool
_M_disjunct(const _CharT* __s) const _GLIBCXX_NOEXCEPT
{
- return (less()(__s, _M_data())
+ return (__builtin_constant_p (__s)
+ || less()(__s, _M_data())
|| less()(_M_data() + this->size(), __s));
}
but oddly we folds the __builtin_constant_p to false early
but we treat __builtin_constant_p ("foo") as true. That's inconsistent in
fold_builtin_constant_p:
/* If this expression has side effects, show we don't know it to be a
constant. Likewise if it's a pointer or aggregate type since in
those case we only want literals, since those are only optimized
when generating RTL, not later.
And finally, if we are compiling an initializer, not code, we
need to return a definite result now; there's not going to be any
more optimization done. */
if (TREE_SIDE_EFFECTS (arg)
|| AGGREGATE_TYPE_P (TREE_TYPE (arg))
|| POINTER_TYPE_P (TREE_TYPE (arg))
|| cfun == 0
|| folding_initializer
|| force_folding_builtin_constant_p)
return integer_zero_node;
fixing that (removing POINTER_TYPE_P) makes the workaround work (and
the generated code simplifies greatly).
[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329
--- Comment #13 from Jakub Jelinek ---
I think this is quite related to the PR98465 discussions.
The warning is on dead code, for basic_string at least when using reasonable
allocators the _M_dataplus._M_p member will always point either into the
_M_local_buf embedded buffer, or to something that has been allocated by the
allocator. In particular, it should never point into .rodata objects, or when
using a reasonable allocator to global or automatic vars (with the exception of
the embedded buffer).
There is the _M_disjunct method that returns whether the std::string could
overlap with the second argument, if we'd say through some magic attribute on
the _M_dataplus._M_p were able to tell the optimizers perhaps through a
builtin that there is no overlap, we would optimize away the dead code and be
fine (not just for the questionable warnings, but more importantly for code
generation as well).
Another approach to deal with this exact case might be some builtin that would
find out if the argument must be in read-only memory ("5" in this case) and use
that as an additional check in _M_disjunct, say that then the arg must be
read-only, it must be disjunct because the string is necessarily writable.
As has been discussed, yet another possibility would be to handle the rare case
(not disjunct) in out of line (ideally libstdc++.so.6 contained (at least for
the usual instantiations)) code, which would also make the rare case smaller
and such warnings not really visible to the optimizers.
[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #14 from Jakub Jelinek ---
Here is an untested patch for the cold part of the function:
--- libstdc++-v3/include/bits/basic_string.h.jj 2022-01-21 22:48:42.220261654
+0100
+++ libstdc++-v3/include/bits/basic_string.h2022-05-02 15:51:42.381923962
+0200
@@ -2504,6 +2504,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
_M_replace_aux(size_type __pos1, size_type __n1, size_type __n2,
_CharT __c);
+ __attribute__((__noinline__, __noclone__, __cold__)) void
+ _M_replace_cold(pointer __p, size_type __len1, const _CharT* __s,
+ const size_type __len2, const size_type __how_much);
+
_GLIBCXX20_CONSTEXPR
basic_string&
_M_replace(size_type __pos, size_type __len1, const _CharT* __s,
--- libstdc++-v3/include/bits/basic_string.tcc.jj 2022-01-11
22:31:41.482757256 +0100
+++ libstdc++-v3/include/bits/basic_string.tcc 2022-05-02 15:51:38.630975348
+0200
@@ -471,6 +471,37 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
template
+__attribute__((__noinline__, __noclone__, __cold__)) void
+basic_string<_CharT, _Traits, _Alloc>::
+_M_replace_cold(pointer __p, size_type __len1, const _CharT* __s,
+ const size_type __len2, const size_type __how_much)
+{
+ // Work in-place.
+ if (__len2 && __len2 <= __len1)
+ this->_S_move(__p, __s, __len2);
+ if (__how_much && __len1 != __len2)
+ this->_S_move(__p + __len2, __p + __len1, __how_much);
+ if (__len2 > __len1)
+ {
+ if (__s + __len2 <= __p + __len1)
+ this->_S_move(__p, __s, __len2);
+ else if (__s >= __p + __len1)
+ {
+ // Hint to middle end that __p and __s overlap
+ // (PR 98465).
+ const size_type __poff = (__s - __p) + (__len2 - __len1);
+ this->_S_copy(__p, __p + __poff, __len2);
+ }
+ else
+ {
+ const size_type __nleft = (__p + __len1) - __s;
+ this->_S_move(__p, __s, __nleft);
+ this->_S_copy(__p + __nleft, __p + __len2, __len2 - __nleft);
+ }
+ }
+}
+
+ template
_GLIBCXX20_CONSTEXPR
basic_string<_CharT, _Traits, _Alloc>&
basic_string<_CharT, _Traits, _Alloc>::
@@ -500,7 +531,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
else
#endif
- if (_M_disjunct(__s))
+ if (__builtin_expect(_M_disjunct(__s),true))
{
if (__how_much && __len1 != __len2)
this->_S_move(__p + __len2, __p + __len1, __how_much);
@@ -508,32 +539,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
this->_S_copy(__p, __s, __len2);
}
else
- {
- // Work in-place.
- if (__len2 && __len2 <= __len1)
- this->_S_move(__p, __s, __len2);
- if (__how_much && __len1 != __len2)
- this->_S_move(__p + __len2, __p + __len1, __how_much);
- if (__len2 > __len1)
- {
- if (__s + __len2 <= __p + __len1)
- this->_S_move(__p, __s, __len2);
- else if (__s >= __p + __len1)
- {
- // Hint to middle end that __p and __s overlap
- // (PR 98465).
- const size_type __poff = (__s - __p) + (__len2 - __len1);
- this->_S_copy(__p, __p + __poff, __len2);
- }
- else
- {
- const size_type __nleft = (__p + __len1) - __s;
- this->_S_move(__p, __s, __nleft);
- this->_S_copy(__p + __nleft, __p + __len2,
- __len2 - __nleft);
- }
- }
- }
+ _M_replace_cold(__p, __len1, __s, __len2, __how_much);
}
else
this->_M_mutate(__pos, __len1, __s, __len2);
Note, on the #c0 testcase alone it actually results in larger generated code
(unless we arrange for it to be exported from libstdc++, for which it is quite
late for 12.1 right now), but say on:
#include
void f (std::string& s)
{
s = "5";
}
void g (std::string& s)
{
s = "56";
}
void h (std::string& s)
{
s = "6";
}
it is already smaller (note, obviously it doesn't need to be in the same TU).
[Bug c/105453] New: wrong choice of source in load instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105453
Bug ID: 105453
Summary: wrong choice of source in load instruction
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: absoler at smail dot nju.edu.cn
Target Milestone: ---
Created attachment 52917
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52917&action=edit
concurrent case
Here's the code:
int g_6[2] = {0x67D50F82L,0x67D50F82L};
int g_10 = 0L;
int func_1(void)
{
int *l_9 = &g_10;
(*l_9) = (g_6[0]);
if (g_6[1])
{
return g_10;
}
return 1;
}
and on gcc-11.3.0 with -O1 option, the assembly code are as follows:
0x0040114d <+0>: mov0x2eed(%rip),%eax# 0x404040
0x00401153 <+6>: mov%eax,0x2ef3(%rip)# 0x40404c
0x00401159 <+12>:cmpl $0x0,0x2ee4(%rip)# 0x404044
0x00401160 <+19>:mov$0x1,%eax
0x00401165 <+24>:cmovne 0x2ed4(%rip),%eax# 0x404040
0x0040116c <+31>:retq
yes, it assert that g_10 = g_6[0] and this may cause problem in concurrent
environment. The case files uploaded can show that the generated code is the
same as above in an environment that g_6 may be modified by other thread.
[Bug fortran/105454] New: DWARF has wrong decl_line for type defined inside program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105454 Bug ID: 105454 Summary: DWARF has wrong decl_line for type defined inside program Product: gcc Version: 9.4.1 Status: UNCONFIRMED Keywords: wrong-debug Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: nils-christian.kempke at intel dot com Target Milestone: --- This was tested with --- >> gfortran --version GNU Fortran (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0 --- Compiling the following code --- >> cat test.f90 program MAIN type :: localtype integer :: a end type localtype type(localtype) :: var var%a = 1 print *, var end program --- via --- >> gfortran -O0 -g ./test.f90 --- and looking at its DWARF output via objdump shows --- ... <1><2e>: Abbrev Number: 2 (DW_TAG_structure_type) <2f> DW_AT_name: (indirect string, offset: 0x10): localtype <33> DW_AT_byte_size : 4 <34> DW_AT_decl_file : 1 <35> DW_AT_decl_line : 1 <36> DW_AT_sibling : <0x45> <2><3a>: Abbrev Number: 3 (DW_TAG_member) <3b> DW_AT_name: a <3d> DW_AT_decl_file : 1 <3e> DW_AT_decl_line : 4 <3f> DW_AT_type: <0x45> <43> DW_AT_data_member_location: 0 <2><44>: Abbrev Number: 0 ... --- Note, that localtype has a DW_AT_decl_line 1 while in the actual source file it is line 3. Its member a however has correct source code correlation as it is, in fact, introduced on line 4. Correctly, gfortran should place the localtype on line 3, the first line for the declared type.
[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329 --- Comment #15 from Jakub Jelinek --- Note, while the patch makes the warning go away, it exports _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE15_M_replace_coldEPcmPKcmm@@GLIBCXX_3.4.21 _ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE15_M_replace_coldEPwmPKwmm@@GLIBCXX_3.4.21 which is certainly undesirable. Either we'd need to make sure it isn't exported, or export @@GLIBCXX_3.4.30 instead and somehow arrange for out of line copy being used from libstdc++ rather than emitted into every library or binary that uses it.
[Bug rtl-optimization/105455] New: ICE: verify_flow_info failed (error: verify_flow_info: REG_BR_PROB does not match cfg)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105455
Bug ID: 105455
Summary: ICE: verify_flow_info failed (error: verify_flow_info:
REG_BR_PROB does not match cfg)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc 12.0.1 20220424 snapshot (g:6b7441a46c771aa6ecdc0c8ed96197417d036b9a) ICEs
when compiling the following testcase w/ -O1 -fharden-conditional-branches
-funroll-loops --param max-loop-header-insns=1:
__attribute__ ((cold)) void
bar (void);
void
foo (int x)
{
if (x)
{
int i;
for (i = 0; i < 101; ++i)
bar ();
}
}
% gcc-12.0.1 -O1 -fharden-conditional-branches -funroll-loops --param
max-loop-header-insns=1 -c hkihrvjs.c
hkihrvjs.c: In function 'foo':
hkihrvjs.c:14:1: error: verify_flow_info: REG_BR_PROB does not match cfg
1073741831 7
14 | }
| ^
during RTL pass: loop2_unroll
hkihrvjs.c:14:1: internal compiler error: verify_flow_info failed
0x9df59e verify_flow_info()
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/cfghooks.cc:284
0xde0a8a execute_function_todo
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/passes.cc:2097
0xde0f9e execute_todo
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/passes.cc:2139
[Bug c++/101133] [coroutines] co_await doesn't accept a valid awaitable object if await_resume()'s return type is not a built-in type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101133 Niall Douglas changed: What|Removed |Added CC||s_gccbugzilla at nedprod dot com --- Comment #4 from Niall Douglas --- Looks like this fix didn't get backported into the 11 branch, as the 11.3 release is also broken. https://godbolt.org/z/ojo759Md1
[Bug libfortran/105456] New: Child I/O does not propage iostat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456 Bug ID: 105456 Summary: Child I/O does not propage iostat Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- The program module sk1 implicit none type char character :: ch end type char interface read (formatted) module procedure read_formatted end interface read (formatted) contains subroutine read_formatted (dtv, unit, iotype, vlist, iostat, iomsg) class (char), intent(inout) :: dtv integer, intent(in) :: unit character (len=*), intent(in) :: iotype integer, intent(in) :: vlist(:) integer, intent(out) :: iostat character (len=*), intent(inout) :: iomsg character :: ch read (unit,fmt='(A1)', advance="no", iostat=iostat, iomsg=iomsg) ch iostat = 42 dtv%ch = ch end subroutine read_formatted end module sk1 program skip1 use sk1 implicit none type (char) :: x open (10,status="scratch") write (10,'(A)') '', 'a' rewind (10) read (10,*) x write (*,'(10(A))') "Read: '",x%ch,"'" end program skip1 runs to completion, but it should propagate the iostat to the caller and error out on the read.
[Bug libfortran/105456] Child I/O does not propage iostat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456 Thomas Koenig changed: What|Removed |Added Blocks||105361 Keywords||wrong-code Target Milestone|--- |13.0 Version|unknown |12.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361 [Bug 105361] Incorrect end-of-file condition for derived-type I/O
[Bug c/105453] wrong choice of source in load instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105453 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- There is no issue here as there is no atomic barrier as required by the c11 and c++11 standards in their memory model
[Bug c/105453] wrong choice of source in load instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105453 Andrew Pinski changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Andrew Pinski --- .
[Bug testsuite/105433] FAIL: gcc.target/i386/iamcu/test_3_element_struct_and_unions.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105433 --- Comment #1 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:7e1f30d7edd433ca0fc28ae9ac1ce9b522790baf commit r13-75-g7e1f30d7edd433ca0fc28ae9ac1ce9b522790baf Author: H.J. Lu Date: Fri Apr 29 10:26:24 2022 -0700 x86: Add missing .note.GNU-stack to assembly source Add .note.GNU-stack assembly source to avoid linker warning: ld: warning: /tmp/ccPZSZ7Z.o: missing .note.GNU-stack section implies executable stack ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker FAIL: gcc.target/i386/iamcu/test_3_element_struct_and_unions.c compilation, -O0 PR testsuite/105433 * gcc.target/i386/iamcu/asm-support.S: Add .note.GNU-stack. * gcc.target/x86_64/abi/asm-support.S: Likewise. * gcc.target/x86_64/abi/avx/asm-support.S: Likewise. * gcc.target/x86_64/abi/avx512f/asm-support.S: Likewise. * gcc.target/x86_64/abi/avx512fp16/asm-support.S: Likewise. * gcc.target/x86_64/abi/avx512fp16/m256h/asm-support.S: Likewise. * gcc.target/x86_64/abi/avx512fp16/m512h/asm-support.S: Likewise. * gcc.target/x86_64/abi/ms-sysv/do-test.S: Likewise.
[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329
--- Comment #16 from Jakub Jelinek ---
(In reply to Richard Biener from comment #11)
> Maybe
>
> _GLIBCXX20_CONSTEXPR
> basic_string&
> assign(const _CharT* __s)
> {
> __glibcxx_requires_string(__s);
> return _M_replace(size_type(0), this->size(), __s,
> traits_type::length(__s));
> }
>
> isn't the most efficient way to assign a string (constant) looking at
For string constant sure, but unless we know that __s points to a string
literal, we need to do those overlap checks I'm afraid.
Or is something like:
void g (std::string& s)
{
s = s.c_str() + 16;
}
invalid if s is before known to contain a string longer than 16 chars?
[Bug c++/105324] std::from_chars() assertion at floating_from_chars.cc:78 when parsing 1.11111111....
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105324 Alexandre Oliva changed: What|Removed |Added Status|RESOLVED|REOPENED CC||aoliva at gcc dot gnu.org Resolution|FIXED |--- --- Comment #5 from Alexandre Oliva --- The from_chars overloads for floating-point types are guarded by #if _GLIBCXX_HAVE_USELOCALE The test fails with ugly overload resolution and template substitution messages over the template from_chars for integral types when the macro is not defined to nonzero. Should the test use a similar conditional? (I'll be happy to submit a patch)
[Bug c++/105324] std::from_chars() assertion at floating_from_chars.cc:78 when parsing 1.11111111....
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105324 --- Comment #6 from Jonathan Wakely --- It should depend on: #if __cpp_lib_to_chars >= 201611L
[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329 --- Comment #17 from Jonathan Wakely --- That's valid
[Bug rtl-optimization/105453] load introduced by ce1 for conditional loads at -O1, might cause issues with the C/C++ memory model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105453 Andrew Pinski changed: What|Removed |Added Summary|wrong choice of source in |load introduced by ce1 for |load instruction|conditional loads at -O1, ||might cause issues with the ||C/C++ memory model --- Comment #3 from Andrew Pinski --- The problem shows up in ce1. Someone who is more in tune with the C/C++ memory model should figure out if adding an extra load here is valid or not. I think it is valid still since there is no load barrier used.
[Bug c++/105457] New: error: '__builtin_huge_valq()' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105457
Bug ID: 105457
Summary: error: '__builtin_huge_valq()' is not a constant
expression
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follows:
template
struct infinity{};
template <> struct infinity<__float128> { static constexpr __float128 value =
__builtin_huge_valq(); };
int main() {
auto x = infinity<__float128>::value;
}
GCC 7.1+ accepts this code, but GCC 6.4 rejects it. I tried clang and other
compilers. They all reject the code:https://godbolt.org/z/qWb5oe4dx
The above code comes from kokkos:
https://github.com/mosra/corrade/commit/59823941093bee9f99e5a63cb4218b53a7bd5495
Look like a gcc bug?
[Bug c++/105457] error: '__builtin_huge_valq()' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105457 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- __float128 is an extension and so is __builtin_huge_valq. There is no bug. Many of gcc builtins are considered constant expressions.
[Bug tree-optimization/105458] New: [12/13 Regression] ICE in set_relation, at value-relation.cc:609
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105458 Bug ID: 105458 Summary: [12/13 Regression] ICE in set_relation, at value-relation.cc:609 Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gcc 12.0.1 20220424 snapshot (g:6b7441a46c771aa6ecdc0c8ed96197417d036b9a) ICEs when compiling gcc/testsuite/gcc.dg/torture/pr83418.c w/ -O1 -fexpensive-optimizations -fno-tree-dominator-opts: % gcc-12.0.1 -O1 -fexpensive-optimizations -fno-tree-dominator-opts -c gcc/testsuite/gcc.dg/torture/pr83418.c during GIMPLE pass: threadfull gcc/testsuite/gcc.dg/torture/pr83418.c: In function 'yj': gcc/testsuite/gcc.dg/torture/pr83418.c:4:1: internal compiler error: in set_relation, at value-relation.cc:609 4 | yj (int j4) | ^~ 0x7a2b0b value_relation::set_relation(tree_code, tree_node*, tree_node*) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/value-relation.cc:609 0x7a2b0b value_relation::value_relation(tree_code, tree_node*, tree_node*) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/value-relation.cc:630 0x7a2b0b path_oracle::register_relation(basic_block_def*, tree_code, tree_node*, tree_node*) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/value-relation.cc:1385 0x1c84309 fur_source::register_outgoing_edges(gcond*, irange&, edge_def*, edge_def*) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/gimple-range-fold.cc:1522 0x1c85106 fold_using_range::range_of_range_op(irange&, gimple*, fur_source&) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/gimple-range-fold.cc:665 0x1c87005 fold_using_range::fold_stmt(irange&, gimple*, fur_source&, tree_node*) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/gimple-range-fold.cc:554 0x1082e93 path_range_query::range_of_stmt(irange&, gimple*, tree_node*) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/gimple-range-path.cc:767 0x110a659 back_threader::find_taken_edge_cond(vec const&, gcond*) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/tree-ssa-threadbackward.cc:320 0x110b01f back_threader::maybe_register_path() /var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/tree-ssa-threadbackward.cc:232 0x110b7c4 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/tree-ssa-threadbackward.cc:419 0x110b762 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/tree-ssa-threadbackward.cc:459 0x110bb22 back_threader::find_paths(basic_block_def*, tree_node*) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/tree-ssa-threadbackward.cc:493 0x110bd41 back_threader::thread_blocks() /var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/tree-ssa-threadbackward.cc:901 0x110be23 execute /var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/tree-ssa-threadbackward.cc:1031
[Bug rtl-optimization/105459] New: ICE: Segmentation fault (in record_operand_costs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105459
Bug ID: 105459
Summary: ICE: Segmentation fault (in record_operand_costs)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc 12.0.1 20220424 snapshot (g:6b7441a46c771aa6ecdc0c8ed96197417d036b9a) ICEs
when compiling the following testcase w/ -O1 -flto:
double m;
int n;
__attribute__ ((optimize ("-funsafe-math-optimizations"))) void
bar (int x)
{
n = x;
m = n;
}
__attribute__ ((flatten)) void
foo (int x)
{
bar (x);
}
void
quux (void)
{
++n;
}
int
main (void)
{
foo (0);
quux ();
return 0;
}
% x86_64-unknown-linux-gnu-gcc-12.0.1 -O1 -flto qnipdldf.c
during RTL pass: ira
qnipdldf.c: In function 'main':
qnipdldf.c:30:1: internal compiler error: Segmentation fault
30 | }
| ^
0xd95abf crash_signal
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/toplev.cc:322
0xbabeb8 record_operand_costs
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/ira-costs.cc:1382
0xbac464 scan_one_insn
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/ira-costs.cc:1507
0xbac464 process_bb_for_costs
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/ira-costs.cc:1632
0xba2ae1 ira_traverse_loop_tree(bool, ira_loop_tree_node*, void
(*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*))
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/ira-build.cc:1800
0xbad545 find_costs_and_classes
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/ira-costs.cc:1728
0xbae639 ira_costs()
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/ira-costs.cc:2276
0xba806c ira_build()
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/ira-build.cc:3481
0xb9dd0c ira
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/ira.cc:5760
0xb9dd0c execute
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220424/work/gcc-12-20220424/gcc/ira.cc:6083
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/105460] New: sizeof (unsigned int) != sizeof (uint8_t *)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105460 Bug ID: 105460 Summary: sizeof (unsigned int) != sizeof (uint8_t *) Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zhonghao at pku dot org.cn Target Milestone: --- Clang's comments say there is an `unsigned int`-sized "reserved" member here, because when the objc4 modern runtime is used on LP64 platforms, there would otherwise be a 32-bit-sized hole here for alignment reasons. However, it doesn't actually add the "reserved" field to its AST data structures. GCC *does* add the field explicitly. On LP64, adding it or not is irrelevant. But on AVR, sizeof (unsigned int) == sizeof (uint8_t *), and it matters. An example is from:https://github.com/mhjacobson/avr-objc/commit/6187e336d706f1a87a7f0cbd9efa838f9d966737 This means that I have to compile Objective-C code either all with clang or all with GCC.
[Bug target/105460] sizeof (unsigned int) != sizeof (uint8_t *)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105460 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- #define INT_TYPE_SIZE (TARGET_INT8 ? 8 : 16) #define SHORT_TYPE_SIZE (INT_TYPE_SIZE == 8 ? INT_TYPE_SIZE : 16) #define LONG_TYPE_SIZE (INT_TYPE_SIZE == 8 ? 16 : 32) #define LONG_LONG_TYPE_SIZE (INT_TYPE_SIZE == 8 ? 32 : 64) #define FLOAT_TYPE_SIZE 32 #define DOUBLE_TYPE_SIZE (avr_double) #define LONG_DOUBLE_TYPE_SIZE (avr_long_double) #define SIZE_TYPE (INT_TYPE_SIZE == 8 ? "long unsigned int" : "unsigned int") #define PTRDIFF_TYPE (INT_TYPE_SIZE == 8 ? "long int" :"int") #define Pmode HImode mint8 Target Mask(INT8) Use an 8-bit 'int' type. What options are you using? Because GCC's default is an 8 bit int for avr. You should use -mno-int8 if you want it different from the default.
[Bug rtl-optimization/105453] load introduced by ce1 for conditional loads at -O1, might cause issues with the C/C++ memory model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105453
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2022-05-03
Known to work||12.0
Keywords||missed-optimization,
||needs-bisection
Status|UNCONFIRMED |NEW
--- Comment #4 from Richard Biener ---
With gcc 12 we get
_Z6func_1v:
.LFB0:
.cfi_startproc
movlg_6(%rip), %eax
movl%eax, g_10(%rip)
cmpl$0, g_6+4(%rip)
movl$1, %edx
cmove %edx, %eax
ret
the difference is that we somehow un-CSE the g_6 load at RTL expansion with GCC
11 and then things go downhill later:
;; Generating RTL for gimple basic block 2
;; _1 = g_6[0];
(insn 6 5 7 (set (reg/f:DI 84)
(symbol_ref:DI ("g_6") [flags 0x2] ))
"t.c":7:20 -1
(nil))
(insn 7 6 0 (set (reg:SI 83 [ ])
(mem/c:SI (reg/f:DI 84) [1 g_6[0]+0 S4 A64])) "t.c":7:20 -1
(nil))
;; g_10 = _1;
(insn 8 7 0 (set (mem/c:SI (symbol_ref:DI ("g_10") [flags 0x2] ) [1 g_10+0 S4 A32])
(reg:SI 83 [ ])) "t.c":7:12 -1
(nil))
;; if (_2 != 0)
(insn 9 8 10 (set (reg/f:DI 85)
(symbol_ref:DI ("g_6") [flags 0x2] ))
"t.c":8:14 -1
(nil))
(insn 10 9 11 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/c:SI (plus:DI (reg/f:DI 85)
(const_int 4 [0x4])) [1 g_6[1]+0 S4 A32])
(const_int 0 [0]))) "t.c":8:5 -1
(nil))
the same happens with GCC 12. CSE cleans this up so it's maybe not important
but in GCC 11 forwprop then does
4: NOTE_INSN_BASIC_BLOCK 2
2: NOTE_INSN_FUNCTION_BEG
-6: r84:DI=`g_6'
-7: r83:SI=[r84:DI]
- REG_DEAD r84:DI
+7: r83:SI=[`g_6']
8: [`g_10']=r83:SI
-9: r85:DI=`g_6'
- 10: flags:CCZ=cmp([r84:DI+0x4],0)
- REG_DEAD r85:DI
+ 10: flags:CCZ=cmp([const(`g_6'+0x4)],0)
which seems to confuse CE enough to emit the extra load:
4: NOTE_INSN_BASIC_BLOCK 2
2: NOTE_INSN_FUNCTION_BEG
7: r83:SI=[`g_6']
8: [`g_10']=r83:SI
- 10: flags:CCZ=cmp([const(`g_6'+0x4)],0)
- 11: pc={(flags:CCZ==0)?L24:pc}
- REG_DEAD flags:CCZ
- REG_BR_PROB 708669604
- ; pc falls through to BB 4
- 24: L24:
- 23: NOTE_INSN_BASIC_BLOCK 3
-3: r83:SI=0x1
- 17: L17:
- 20: NOTE_INSN_BASIC_BLOCK 4
+ 25: r88:SI=[`g_6']
+ 26: r87:SI=0x1
+ 27: flags:CCZ=cmp([const(`g_6'+0x4)],0)
+ 28: r83:SI={(flags:CCZ==0)?r87:SI:r88:SI}
18: ax:SI=r83:SI
disabling fwprop1 produces
+6: r84:DI=`g_6'
+7: r83:SI=[r84:DI]
+ REG_DEAD r84:DI
+8: [`g_10']=r83:SI
+ 26: r87:SI=0x1
+ 25: flags:CCZ=cmp([r84:DI+0x4],0)
+ 27: r83:SI={(flags:CCZ!=0)?r83:SI:r87:SI}
18: ax:SI=r83:SI
again. Likely the new SSA based forwprop "fixed" this, but maybe only
accidentially. On trunk fwprop1 does
-6: r84:DI=`g_6'
-7: r83:SI=[r84:DI]
- REG_DEAD r84:DI
+7: r83:SI=[`g_6']
8: [`g_10']=r83:SI
-9: r85:DI=`g_6'
- 10: flags:CCZ=cmp([r84:DI+0x4],0)
- REG_DEAD r85:DI
+ 10: flags:CCZ=cmp([const(`g_6'+0x4)],0)
[Bug rtl-optimization/105453] [9/10/11 Regression] load introduced by ce1 for conditional loads at -O1, might cause issues with the C/C++ memory model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105453 Richard Biener changed: What|Removed |Added Known to work||7.5.0 Summary|load introduced by ce1 for |[9/10/11 Regression] load |conditional loads at -O1, |introduced by ce1 for |might cause issues with the |conditional loads at -O1, |C/C++ memory model |might cause issues with the ||C/C++ memory model Target Milestone|--- |9.5 Known to fail||11.3.1, 9.4.1
[Bug tree-optimization/105458] [12/13 Regression] ICE in set_relation, at value-relation.cc:609
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105458 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-05-03 CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com Ever confirmed|0 |1 Target Milestone|--- |12.0 Status|UNCONFIRMED |NEW Keywords||ice-checking --- Comment #1 from Richard Biener --- Confirmed. There is the unfolded t3_t > t3_6 which eventually makes us run into the assert. We shouldn't assert that everything is correctly folded so we have to be forgiving here (maybe just not registering anything here). It might be that when setting name1 == name2 that we'd run into compile-time issues. Andrew should know how to avoid this ICE best. [local count: 117688337]: _7 = t3_6 > t3_6; _8 = t3_6 == j4_5(D); _9 = _8 | _7; if (_9 != 0) goto ; [7.19%] else goto ; [92.81%]
