gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103220 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:74faa9834a9ad208e34f67b08c854c20b0fcfe92 commit r12-5430-g74faa9834a9ad208e34f67b08c854c20b0fcfe92 Author: Andrew Pinski Date: Sat Nov 20 01:37:54 2021 + Fix tree-optimization/103220: Another missing folding of (type) X op CST where type is a nop convert The problem here is that int_fits_type_p will return false if we just change the sign of things like -2 (or 254) so we should accept the case where we just change the sign (and not the precision) of the type. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/103220 gcc/ChangeLog: * match.pd ((type) X bitop CST): Don't check if CST fits into the type if only the sign changes. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr103220-1.c: New test. * gcc.dg/tree-ssa/pr103220-2.c: New test. * gcc.dg/pr25530.c: Update test to check for 4294967294 in the case -2 is not matched.
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103220 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- Fixed.
[Bug middle-end/31531] A microoptimization of isnegative of signed integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31531 Andrew Pinski changed: What|Removed |Added Attachment #26645|0 |1 is obsolete|| --- Comment #17 from Andrew Pinski --- Created attachment 51841 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51841&action=edit Patch which I am testing Attached patch which I am testing. should resolve this fully.
[Bug tree-optimization/102872] If statement is always false but not figured out at gimple level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102872
--- Comment #3 from Andrew Pinski ---
I wonder if we should just do this:
(for neeq (ne eq)
(simplify
(neeq (convert:s @0) integer_zerop@1)
(with
{
tree inside_type = TREE_TYPE (@0);
tree outer_type = TREE_TYPE (@1);
}
(if (TYPE_PRECISION (inside_type) > TYPE_PRECISION (outer_type))
(neeq (bit_and @0
{ wide_int_to_tree (type0,
wi::mask (TYPE_PRECISION (inside_type),
false,
TYPE_PRECISION (outer_type))); })
{ build_zero_cst (inside_type); })
)
Or does the bit_and to a convert make better sense? I don't care either way
really but it would be a good idea to chose one or the other really.
[Bug tree-optimization/103266] [12 regression] llvm-13 miscompilation: __builtin_assume_aligned causes over-aggressive dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103266 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jan Hubicka --- fixed.
[Bug tree-optimization/101541] Missing ABSU detection at gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101541 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Andrew Pinski --- Mine, let me try to figure out the best way to fix this.
[Bug preprocessor/103165] [12 Regression] ICE unspellable token PRAGMA since r12-4797-g0078a058a5693871
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103165 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 51842 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51842&action=edit gcc12-pr103165.patch So what about this instead? Doesn't regress on make check-gcc check-g++, but not tested beyond that so far.
[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328 --- Comment #17 from Avi Kivity --- Created attachment 51843 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51843&action=edit valid-code reproducer (compiles with -O0) Uploaded a valid-code reproducer (if you don't mind warnings). Compiles with -O0, ICEs with -O2.
[Bug libstdc++/103340] New: constexpr std::string is incompatible with --enable-libstdcxx-allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103340 Bug ID: 103340 Summary: constexpr std::string is incompatible with --enable-libstdcxx-allocator Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- Only __gnu_cxx::new_allocator is usable in constant expressions. We need to either disable constexpr std::string when other allocator base classes are used, or make the changes needed to all/some of the allocator base classes to e.g. add constexpr destructors.
[Bug libstdc++/103340] [12 Regression] constexpr std::string is incompatible with --enable-libstdcxx-allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103340 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0 Known to work||11.2.1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Summary|constexpr std::string is|[12 Regression] constexpr |incompatible with |std::string is incompatible |--enable-libstdcxx-allocato |with |r |--enable-libstdcxx-allocato ||r Ever confirmed|0 |1 Last reconfirmed||2021-11-20 Keywords||build Known to fail||12.0 Priority|P3 |P1 --- Comment #1 from Jonathan Wakely --- This breaks bootstrap for users who are using a non-default allocator impl.
[Bug ipa/103227] [12 Regression] 58% exchange2 regression with -Ofast -march=native on zen3 since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227 --- Comment #8 from hubicka at kam dot mff.cuni.cz --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227 > > --- Comment #7 from Martin Jambor --- > (In reply to hubicka from comment #5) > > > I like the idea of transformation phases better than putting > > > everything into tree-inline (and by extension ipa-param-manipulation) > > > but perhaps we have to do aggregate constant replacements there too? > > > > So the situation is that we inline call A->B (where both A and B are > > clones of the main function) and while we place uses of the constant > > parmater in A we miss replacement in B because transform is not run on > > it. > > No, we miss it everywhere, even in A (see that the code above is from > BB 2) or probably also without any cloning whatsoever. This happens > when IPA-SRA does its thing on the same parameter on which IPA-CP > decided to propagate aggregate constants. > > In the IPA analysis stage (which creates the virtual clones), IPA-CP > runs before IPA-SRA. But in the transformation phase, it is > apparently the other way round - well, not exactly, IPA-SRA does not > formally have a transformation phase, it happens as part of > tree_function_versioning, but the effect is the same. OK, so the problem is that we don't do ipa-sra changes "in place" as a well behaved transform pass but it i merged into versioning code while ipa-cp is the other way around. So one fix would be alo to make ipa-cp understand that changes to signature happened and update its summary just like we do for modref? We will need it also for ... > > > > > I think proper solution here (discussed also few years ago) is to keep > > the optimization summaries and teach value numbering to look up the > > constant from the summary. > > > > Yes, but this is another (but different) problem that we probably also > should try to solve now. ... fixing this problem properly. I just loked into thi again and we already have code that preserves propagates bits on pointer parmeters (since these do not have value ranges). Same way we need to preserve the known partial aggregates and hook it up into sccvn's vn_reference_lookup_2 and _3. Honza
[Bug libstdc++/64135] Allocator base classes should use reserved names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64135
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> Another option would be to drop the base class from std::allocator when
> configured to derive from new_allocator, and just inline that code into
> std::allocator. That's an ABI break, because it would no longer have a base
> class of type __gnu_cxx::new_allocator, but maybe it's one that wouldn't
> cause any problems in practice.
I think we can mitigate the ABI break by giving __gnu_cxx::new_allocator and
std::allocator a common base class, which would still prevent them from being
potentially-overlapping subobjects as is the case today.
Testcase for the current ABI properties:
#include
#include
struct A : __gnu_cxx::new_allocator { };
struct B : std::allocator, A { };
struct C : std::allocator { A a; };
static_assert( sizeof(B) == 2 );
static_assert( sizeof(C) == 2 );
[Bug ipa/103227] [12 Regression] 58% exchange2 regression with -Ofast -march=native on zen3 since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227 --- Comment #9 from hubicka at kam dot mff.cuni.cz --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227 > ... fixing this problem properly. > I just loked into thi again and we already have code that preserves > propagates bits on pointer parmeters (since these do not have value > ranges). Same way we need to preserve the known partial aggregates and > hook it up into sccvn's vn_reference_lookup_2 and _3. Also note that with this implemented I think we should be able to remove the ipa-cp transformation code :)
[Bug target/102117] s390: Inefficient code for 64x64=128 signed multiply for <= z13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102117 Roger Sayle changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com CC||roger at nextmovesoftware dot com Last reconfirmed||2021-11-20 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Roger Sayle --- Patch proposed: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585067.html
[Bug bootstrap/103306] [12 Regression] parallel build hangs since r12-5234-g04c5a9 when /usr/include includes broken symbolic links
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103306 Xi Ruoyao changed: What|Removed |Added CC||bkorb at gnu dot org --- Comment #17 from Xi Ruoyao --- (In reply to Zdenek Sojka from comment #16) > (In reply to Xi Ruoyao from comment #15) > > patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584815.html > > Thank you for the patch; it fixes non-bootstrap build for me. I didn't check > full bootstrap yet. > > Is there a chance to check why is there the strange behavior now, with the > abort() in fixincludes? > - parallel build hangs (eg. no "Error" or "Waiting for unfinished jobs" > message from make) > - non-parallel build succeeds (even though fixincludes aborted) I think the reason is when fixinc.sh invokes fixincl executable, it does not check if fixincl succeeds. Then if fixincl fails, it may leave the building into a inconsistent status. On my system the parallel build fails with "cannot find config.status".
[Bug other/103331] There should be a rule to make build.log in the top-level Makefile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103331 Eric Gallager changed: What|Removed |Added CC||neroden at gcc dot gnu.org --- Comment #1 from Eric Gallager --- git blame says the dependency has been there since Nathanael Nerode first created Makefile.tpl back in g:95ddd785 in 2002...
[Bug libstdc++/103305] Cannot build libstdc++ with newlib on aarch64-none-elf or bfin-elf with new version of newlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
Pekka S changed:
What|Removed |Added
CC||p...@gcc-bugzilla.mail.kaps
||i.fi
--- Comment #14 from Pekka S ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> > static const mask blank= space;
>
> We might want to use blank = _ISspace | _ISblank for this last one, but I
> don't really understand what newlib defines those categories as:
>
>
> #define isblank(__c) \
> __extension__ ({ __typeof__ (__c) __x = (__c); \
> (__ctype_lookup(__x)&_B) || (int) (__x) == '\t';})
> (__ctype_lookup(__x)&_ISblank) || (int) (__x) == '\t';})
>
> This definition is weird ... why is '\t' not already handled by _ISblank?
It has been attempted in the past:
https://sourceware.org/legacy-ml/newlib/2009/threads.html#00342
The used 8-bit mask is simply not wide enough to disambiguate all POSIX
character classes; Namely space, blank and print classes are the problematic
ones to distinguish properly. The naming of newlib character classes does not
fully align with POSIX, and this has to do with the restrictions that come from
space concerns and limitations.
Also, libstdc++-v3/config/locale/newlib/ctype_members.cc does not handle blank
class even though newlib supports wctype("blank"). As explained above, in this
case it really doesn't matter, since matching a character to a (true POSIX)
class using a mask bit alone is not possible.
Anyway, I made a similar patch but never got around submitting it. I also used
_ISblank | _ISspace since IMHO it is "less wrong" than _ISspace (or equal to
space) alone and added a note explaining the issue.
(Yes, I was about to repeat the history.)
[Bug other/103335] new test case gcc.dg/tree-ssa/modref-dse-4.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103335
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2021-11-20
Target|powerpc64-linux-gnu |
Ever confirmed|0 |1
Host|powerpc64-linux-gnu |
Build|powerpc64-linux-gnu |
Status|UNCONFIRMED |NEW
--- Comment #1 from H.J. Lu ---
It also fails on Linux/x86 with
make check RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/modref-dse-4.c
--target_board='unix{-m32\ -march=cascadelake}'"
[Bug libstdc++/103305] Cannot build libstdc++ with newlib on aarch64-none-elf or bfin-elf with new version of newlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305 --- Comment #15 from Jonathan Wakely --- Thanks for the explanation! If you have other suggestions to make things less wrong they'll be welcome.
[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 --- Comment #22 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:7950c96ca667ddaab9d6e894da3958ebc2e2dccb commit r12-5432-g7950c96ca667ddaab9d6e894da3958ebc2e2dccb Author: Jeff Law Date: Sat Nov 20 11:20:07 2021 -0500 Clobber the condition code in the bfin doloop patterns Per Aldy's excellent, but tough to follow analysis in PR 103226, this patch fixes the bfin-elf regression. In simplest terms the doloop patterns on this port may clobber the condition code register, but they do not expose that until after register allocation. That would be fine, except that other patterns have exposed CC earlier. As a result the dataflow, particularly for CC, is incorrect. This leads the register allocators to assume that a value in CC outside the loop is still valid inside the loop when in fact, the value has been clobbered. This is what caused pr80974 to start failing. With this fix, not only do we fix the pr80974 regression, but we fix ~20 other execution failures in the port. It also reduces test time for the port from ~90 minutes to ~60 minutes. PR tree-optimization/103226 gcc/ * config/bfin/bfin.md (doloop pattern, splitter and expander): Clobber CC.
[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #23 from Jeffrey A. Law --- Fixed on the trunk.
[Bug analyzer/103217] analyzer false positive on leak warning when using indirect strdup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103217 --- Comment #6 from David Malcolm --- (In reply to Dominique Martinet from comment #4) [...snip...] Thanks for re-testing it, and the new test cases. > (What do you prefer to move forward -- I've tried reopening the bug but you > really fixed something so should I open a new bz instead and keep this > resolved?) For now, let's just reuse this bug ID, to keep the conversation in one place, and since the reproducers have such similarity (regardless of whether the underlying causes are different).
[Bug libstdc++/103340] [12 Regression] constexpr std::string is incompatible with --enable-libstdcxx-allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103340 --- Comment #2 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #0) > Only __gnu_cxx::new_allocator is usable in constant expressions. And __gnu_cxx::malloc_allocator. Making the others work isn't difficult.
[Bug c++/103341] New: ICE type of variable instantiation constrained on template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103341
Bug ID: 103341
Summary: ICE type of variable instantiation constrained on
template parameter
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
Target Milestone: ---
See https://godbolt.org/z/68GYeKqK4.
```C++
template struct is_same { };
template concept same_as = is_same::value;
template inline constexpr same_as auto trait_v{1};
using _ [[maybe_unused]] = decltype(trait_v);
```
Output:
```
: In instantiation of 'constexpr const auto [requires
::same_as<, T>] trait_v':
:4:37: required from here
:3:52: internal compiler error: tree check: accessed elt 1 of
'tree_vec' with 0 elts in hash, at cp/constraint.cc:2503
3 | template inline constexpr same_as auto trait_v{1};
|^~~
0x206d4e9 internal_error(char const*, ...)
???:0
0x6da40c tree_vec_elt_check_failed(int, int, char const*, int, char const*)
???:0
0x85fca0 sat_hasher::hash(sat_entry*)
???:0
0x85aed7 satisfaction_cache::satisfaction_cache(tree_node*, tree_node*,
sat_info)
???:0
0x85f01a constraints_satisfied_p(tree_node*, tree_node*)
???:0
0xa3384b do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
???:0
0x8d2c1d cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0xa46987 instantiate_decl(tree_node*, bool, bool)
???:0
0x8e7c9e maybe_instantiate_decl(tree_node*)
???:0
0x8e9760 mark_used(tree_node*, int)
???:0
0xabe557 finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*,
bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned int)
???:0
0xa0cc65 c_parse_file()
???:0
0xb94bf2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/101541] Missing ABSU detection at gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101541 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > Mine, let me try to figure out the best way to fix this. Basically the patterns starting with: /* abs/negative simplifications moved from fold_cond_expr_with_comparison, Need to handle (A - B) case as fold_cond_expr_with_comparison does. Need to handle UN* comparisons. need to add nop_convertN? handling. There is 6 patterns.
[Bug ipa/103052] [9/10/11/12 Regression] Function is found to be pure looping but has a call to a noreturn function in it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103052 --- Comment #11 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:a0e99d5bb741d3db74a67d492f47b28217fbf88a commit r12-5433-ga0e99d5bb741d3db74a67d492f47b28217fbf88a Author: Jan Hubicka Date: Sun Nov 21 00:35:22 2021 +0100 Fix looping flag discovery in ipa-pure-const The testcase shows situation where there is non-trivial cycle in the callgraph involving a noreturn call. This cycle is important for const function discovery but not important for pure. IPA pure const uses same strongly connected components for both propagations which makes it to get suboptimal result (does not detect the pure flag). However local pure const gets the situation right becaue it processes functions in right order. This hits rarely executed code in propagate_pure_const that merge results with previously known state that has long standing bug in it that makes it to throw away the looping flag. Bootstrapped/regtested x86_64-linux. gcc/ChangeLog: 2021-11-21 Jan Hubicka PR ipa/103052 * ipa-pure-const.c (propagate_pure_const): Fix merging of loping flag. gcc/testsuite/ChangeLog: 2021-11-21 Jan Hubicka PR ipa/103052 * gcc.c-torture/execute/pr103052.c: New test.
[Bug ipa/103052] [9/10/11/12 Regression] Function is found to be pure looping but has a call to a noreturn function in it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103052 --- Comment #12 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:ce2dbf943ac8ffefe048016ac3abfd3b6a4518d4 commit r12-5434-gce2dbf943ac8ffefe048016ac3abfd3b6a4518d4 Author: Jan Hubicka Date: Sun Nov 21 00:39:42 2021 +0100 Fix ignore_nondeterminism_p in ipa-modref Improve debug output in ipa-modref and fix ignore_nondeterminism predicate: looping pures and cont are still deterministic. gcc/ChangeLog: 2021-11-21 Jan Hubicka PR ipa/103052 * ipa-modref.c (ignore_nondeterminism_p): Allow looping pure/cont. (merge_call_side_effects): Improve debug output.
[Bug lto/81847] ICE with LTO enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81847 Andrew Pinski changed: What|Removed |Added Known to fail||7.5.0 --- Comment #7 from Andrew Pinski --- This seems be to fixed in GCC 8.
[Bug fortran/103342] New: [OPENMP]Missing barrier for linear clause within loop simd construct which not directly contained by parrellel construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103342 Bug ID: 103342 Summary: [OPENMP]Missing barrier for linear clause within loop simd construct which not directly contained by parrellel construct Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: xiao@compiler-dev.com Target Milestone: --- The test case is, program p integer, parameter :: N = 1 integer :: a(N) integer :: i, j j = 0 !$omp parallel do simd linear(j: 2) do i = 1, N a(i) = a(i) + j j = j + 2 enddo j = 0 !$omp parallel call subr(a) !$omp end parallel contains subroutine subr(x) integer :: x(N) !$omp do simd linear(j: 2) do i = 1, N x(i) = x(i) + j j = j + 2 enddo end subroutine end program After complier with, gfortran-10 test.f90 -fopenmp -fdump-tree-all In the file test.f90.007t.omplower, I found "builtin_GOMP_barrier" in "p", but none in "subr". And when I convert to C-style testcase, found "builtin_GOMP_barrier" in both. Except the missing of barrier, there is an ICE for gfortran when removed "simd" in "subr".
[Bug c/103343] New: Invalid codegen when comparing pointer to one past the end and then dereferencing that pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103343
Bug ID: 103343
Summary: Invalid codegen when comparing pointer to one past the
end and then dereferencing that pointer
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
extern int x[1], y;
int f(int *p, int *q) {
*q = y;
if (p == (x + 1)) {
*p = 2;
return y;
}
return 0;
}
GCC trunk currently outputs the following code with -O3:
f:
mov eax, DWORD PTR y[rip]
mov DWORD PTR [rsi], eax
cmp rdi, OFFSET FLAT:x+4
je .L5
xor eax, eax
ret
.L5:
mov DWORD PTR x[rip+4], 2
ret
Which is incorrect because `p` could point to `y`, for example if `f` was
called as such:
int whatever;
f(&y, &whatever);
and `y` could happen to be located in memory right after `x`.
Also, although the comparison invokes unspecified behavior, this still means
only two results are possible according to the standard:
- if `p == (x + 1)` results in `false`, then the result of `f` is 0
- if `p == (x + 1)` results in `true`, then the result of `f` is 2 since we do
`*p = 2` and `p` points to `y`.
GCC's optimization makes it so the result can also be the previous value of
`y`, which could be something else than 0 or 2.
It seems that GCC assumes that because `p == (x + 1)` it can replace all
occurrences of `p` with `x + 1` without any regard to provenance, and doing
that change manually would indeed mean the `return y;` could be optimized to
use the previous store (and the store to `x + 1` would be UB, too...), but this
isn't the case here: `p` could simultaneously validly point to `y` and be equal
to `x + 1`.
PS: This also results in plenty of invalid warnings when compiling with -Wall:
: In function 'f':
:6:9: warning: array subscript 1 is outside array bounds of 'int[1]'
[-Warray-bounds]
6 | *p = 2;
| ^~
:1:12: note: at offset 4 into object 'x' of size 4
1 | extern int x[1], y;
|^
[Bug c/103343] Invalid codegen when comparing pointer to one past the end and then dereferencing that pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103343 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 61502. (or a dup of bug 93052 or many others). *** This bug has been marked as a duplicate of bug 61502 ***
[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 Andrew Pinski changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment #45 from Andrew Pinski --- *** Bug 103343 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #46 from Andrew Pinski --- Note this came up on twitter the other day: https://twitter.com/rep_stosq_void/status/1461635511009828864
[Bug rtl-optimization/46265] Missing ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46265 Andrew Pinski changed: What|Removed |Added Known to work|7.1.0 | Target Milestone|--- |11.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- The original testcase in comment #0 was fixed for GCC 7 by r7-1935. The one in comment #2 was fixed for GCC 8 I think by r8-7372. The one in comment #3 was fixed for GCC 11 by some patches to tree-ssa-loop-im.c (I cannot figure out right now). The one in comment #4 was fixed for GCC 6 by a few changes to ifcvt.c So I am just going to close this as fixed since all testcases are fixed.
[Bug middle-end/45410] constant not optimized / propagated across printf calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45410 Andrew Pinski changed: What|Removed |Added Summary|constant not optimized /|constant not optimized / |propagated |propagated across printf ||calls --- Comment #7 from Andrew Pinski --- I think the real issue is we don't know that printf does not change the value of ss.j
