[Bug c/105713] [gimplefe] need a way to specify TREE_ADDRESSABLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105713 --- Comment #2 from Richard Biener --- Similarly DECL_NOT_GIMPLE_REG_P. "easiest" to do with attributes on the declaration I guess. GIMPLE FE specific attributes should be not recognized without -fgimple and should be prefixed g_addressable, g_not_gimple_reg_p? Optimistic clearing is going to be difficult, we'd need to have a lot of attributes that way. There's a narrow subset of cases we "ignore" & for addressability and __MEM parsing is separate so eventually we can introduce a flag into the C frontend to not set TREE_ADDRESSABLE when in some "context".
[Bug target/106902] [11/12/13/14 Regression] Program compiled with -O3 -mfma produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 --- Comment #24 from Richard Biener --- (In reply to Andrew Pinski from comment #23) > (In reply to Alexander Monakov from comment #22) > > Created attachment 55105 [details] > > patch 1/3 > > > > (In reply to Richard Biener from comment #21) > > > > > > Sounds reasonable. Though I wouldn't use GENERIC folding but instead > > > some folding-like code in c-family/ that for example would get invoked > > > by genericization or via the gimplification hook? If we'd add GENERIC > > > folding in fold-const.cc or match.pd the chance is that it will pick up > > > FMAs "late". > > > > Agreed, thank you. I'm working on it. The attached patch implements this via > > c_gimplify_expr and passes bootstrap+regtest under 'configure > > --with-cpu=znver2' (i.e. with fma available by default). > > Hmm, seems like this should not be in the C family but the generic part of > gimplifier. Because IIRC Fortran has similar rules but IIRC fortran > front-end emits PAREN_EXPR a lot more which improves the situtation there ... The actual worker can be put into generic code but frontends need to set the rules here I think as they might differ slightly. As of the patch it looks good, I wonder if we want to check for OPTIMIZE_BOTH though since at least when no extra negations are required the contraction should also be a win when optimizing for size? Also I wondered about the PROP_gimple_any check - do we get into the gimplification langhook after lowering? I see we are not resetting the langhook after lowering (only in free-lang-data, but that only runs with LTO). We probably at least should gate the langhook invocation in the gimplifier with what you added in the patch or specify whether the gimplifier is invoked from the middle-end via the gimplifier context. If we go for c-family only the genericize entry could be another place to handle this. Did you run into any of NON_LVALUE / C_MAYBE_CONST wrappings of the multiplication btw?
[Bug tree-optimization/109441] missed optimization when all elements of vector are known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109441 --- Comment #4 from Richard Biener --- (In reply to AK from comment #3) > > But IMHO it's academic, right? > > yes. i was just messing with vector codegen. But in case all the elements of > a vector/array are same, maybe the loop can be replaced with equivalent > computation? Yes. GCC doesn't currently have the ability to constant propagate or value-number defs defined by cycles [that actually iterate]. In general doing that is computationally expensive and only in very few cases you can short-cut simulating all iterations (final value replacement does this, but the case in this PR is already too complicated because it involves a memory load). For the case in this PR when simplified to not require removal of all the C++ abstraction via inlining we'd need to handle a loopy memory definition and a loopy memory use. The loopy memory def we can probably pattern match to a memset and the loopy memory use could be (but isn't currently) identified to be always zero. Pass ordering still stands in the way then though.
[Bug c++/101853] [12/13/14 Regression] g++.dg/modules/xtreme-header-5_b.C ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101853 --- Comment #17 from Jiu Fu Guo --- > But "nobody" counts that close, so better say "no xtreme-header-* failures > since r13-5702-g72058eea9d407e". :) Since these failures occur erratically, so maybe reopen this or open a new one if the failures are reproduced. As two xtreme-header-5_ failures (not ICE) occur in Results for 14.0.0 20230518: https://gcc.gnu.org/pipermail/gcc-testresults/2023-May/784674.html.
[Bug c++/100052] [11/12/13/14 regression] ICE in compiling g++.dg/modules/xtreme-header-3_b.C after r11-8118
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100052 --- Comment #15 from Jiu Fu Guo --- (In reply to seurer from comment #14) > The failures occur erratically so one clean run doesn't mean much. Scanning > the test results mailing list I see failures for this just today in trunk. Yeap, thanks for in time comment! so it seems still erratic.
[Bug tree-optimization/109901] Optimization opportunity: ((((a) > (b)) - ((a) < (b))) < 0) -> ((a) < (b))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109901 --- Comment #7 from Richard Yao --- Two more rules: bool0 - bool1 >= 0 -> bool0 | !bool1 -> bool1 >= bool0 bool0 - bool1 <= 0 -> !bool0 | bool1 -> bool0 <= bool1
[Bug tree-optimization/106020] Spurious warnings about stringop overflows with -march=skylake -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=106074 CC||ed at catmur dot uk --- Comment #12 from Andrew Pinski --- *** Bug 106074 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 106074, which changed state. Bug 106074 Summary: Spurious Wstringop-overflow for int-to-string with SSE4 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106074 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/106074] Spurious Wstringop-overflow for int-to-string with SSE4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106074 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=106020 Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- I just reduced a very similar testcase for PR 106020. Marking this as a dup. The Date is exactly what I reduced really. *** This bug has been marked as a duplicate of bug 106020 ***
[Bug sanitizer/99476] 'PATH_MAX' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99476 YunQiang Su changed: What|Removed |Added CC||syq at debian dot org --- Comment #2 from YunQiang Su --- Since commit 59e4c98173a79fcaa2c33253261409f38856c384 You can add an configure option --includedir=/you/sysroot/include to solve this problem. /you/sysroot/include should contains a real workable limits.h. The reason is due to that if gcc cannot find a limits.h, it will use its ./gcc/glimits.h, which has no PATH_MAX defined.
[Bug tree-optimization/106020] Spurious warnings about stringop overflows with -march=skylake -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-05-18 Ever confirmed|0 |1 --- Comment #11 from Andrew Pinski --- Confirmed at this point even with a nice reduced testcase for someone to look into.
[Bug tree-optimization/106020] Spurious warnings about stringop overflows with -march=skylake -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020 Andrew Pinski changed: What|Removed |Added Attachment #55107|0 |1 is obsolete|| --- Comment #10 from Andrew Pinski --- Created attachment 55108 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55108=edit Self contained testcase Still need `-O3 -march=skylake`
[Bug tree-optimization/106020] Spurious warnings about stringop overflows with -march=skylake -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020
Andrew Pinski changed:
What|Removed |Added
Keywords|lto |
--- Comment #9 from Andrew Pinski ---
Reduced much further (still has includes):
```
#include
#include
void f(const char*);
typedef char CharT;
void read(unsigned u)
{
CharT buf[std::numeric_limits::digits10+2u] = {};
CharT* e = buf;
do
{
*e++ = static_cast(CharT(u % 10) + CharT{'0'});
u /= 10;
} while (u > 0);
e[0] = 0;
std::reverse(buf, e);
f(buf);
}
```
Just compile with `-std=c++20 -O3 -march=skylake` is enough to get the warning.
[Bug libstdc++/109883] Stack Overflow in functions with types and -std=c++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109883 Xi Ruoyao changed: What|Removed |Added Target Milestone|--- |13.2
[Bug tree-optimization/106020] Spurious warnings about stringop overflows with -march=skylake -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020 Andrew Pinski changed: What|Removed |Added Summary|Spurious warnings about |Spurious warnings about |stringop overflows only |stringop overflows with |with LTO|-march=skylake -O3 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #7) > Created attachment 55107 [details] > single file testcase > > `-O3 -W -Wall t.cc -flto -march=skylake` is enough to invoke the warning. > > NOTE -march=skylake is important. > I think this might be a dup of another vectorizer issue with this warning > then. Oh you don't need -flto to invoke the warning either.
[Bug tree-optimization/106020] Spurious warnings about stringop overflows only with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020 --- Comment #7 from Andrew Pinski --- Created attachment 55107 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55107=edit single file testcase `-O3 -W -Wall t.cc -flto -march=skylake` is enough to invoke the warning. NOTE -march=skylake is important. I think this might be a dup of another vectorizer issue with this warning then.
[Bug bootstrap/105831] Nonportable syntax in "test" and "[" commands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105831 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-05-18 Status|UNCONFIRMED |NEW
[Bug bootstrap/105831] Nonportable syntax in "test" and "[" commands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105831 --- Comment #3 from Andrew Pinski --- Note I think most folks on AIX, uses CONFIG_SHELL=bash due to the speed of /bin/sh and configure : https://gcc.gnu.org/install/specific.html#x-ibm-aix So the patch to configure.ac while good does not do much. And IIRC nvptx target is really only tested on GNU/Linux so nvptx/gen-opt.sh will most likely only be invoked with bash (dash?). So while good, will not do much.
[Bug tree-optimization/109901] Optimization opportunity: ((((a) > (b)) - ((a) < (b))) < 0) -> ((a) < (b))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109901 --- Comment #6 from Richard Yao --- (In reply to Andrew Pinski from comment #1) > bool0 - bool1 == 1 -> bool0 & !bool1 -> bool0 < bool1 > bool0 - bool1 > 0 -> bool0 & !bool1 -> bool0 < bool1 That should be: bool0 - bool1 == 1 -> bool0 & !bool1 -> bool0 > bool1 bool0 - bool1 > 0 -> bool0 & !bool1 -> bool0 > bool1
[Bug c++/106026] [11/12/13 Regression] ICE: error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106026 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Target Milestone|--- |11.4 --- Comment #4 from Andrew Pinski --- I am suspecting this and PR 100557 were caused by the same revision. Note clang does not reject the reduced testcase .
[Bug c++/100557] [11/12/13 Regression] Internal compiler error: Error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100557 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.4 Known to fail||11.1.0 Summary|[concepts] Internal |[11/12/13 Regression] |compiler error: Error |Internal compiler error: |reporting routines |Error reporting routines |re-entered. |re-entered. --- Comment #4 from Andrew Pinski --- This is a regression from GCC 10.
[Bug c++/106026] [11/12/13 Regression] ICE: error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106026 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-05-18 Ever confirmed|0 |1 Keywords|rejects-valid |ice-on-valid-code Summary|ICE: error reporting|[11/12/13 Regression] ICE: |routines re-entered.|error reporting routines ||re-entered.
[Bug c++/106026] ICE: error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106026
--- Comment #3 from Andrew Pinski ---
Reduced to:
```
struct k {
template
auto operator()(CPO cpo, Args &&...args) const
-> decltype(tag_invoke(cpo, args...))
{
return tag_invoke(cpo, args...);
}
};
k j{};
struct nn {
template
friend void tag_invoke(nn, T &&) { }
auto operator()(auto x) const {
return j(*this, x);
}
};
constexpr nn h;
template concept has_extents = requires(T t) { h(t); };
template constexpr void tag_invoke(nn, T &&) {}
static_assert(has_extents);
```
[Bug tree-optimization/109901] Optimization opportunity: ((((a) > (b)) - ((a) < (b))) < 0) -> ((a) < (b))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109901 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=107881 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > (In reply to Andrew Pinski from comment #3) > > (In reply to Andrew Pinski from comment #1) > > > bool0 - bool1 == 0 -> !bool0 & !bool1 -> !(bool0 | bool1) > > Sorry I messed this one up: > > bool0 - bool1 == 0 -> (bool0 & bool1) | (!bool0 & !bool1) > > or rather just bool0 == bool1 Which then that makes it related to PR 107881 too.
[Bug tree-optimization/109901] Optimization opportunity: ((((a) > (b)) - ((a) < (b))) < 0) -> ((a) < (b))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109901 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > (In reply to Andrew Pinski from comment #1) > > bool0 - bool1 == 0 -> !bool0 & !bool1 -> !(bool0 | bool1) > Sorry I messed this one up: > bool0 - bool1 == 0 -> (bool0 & bool1) | (!bool0 & !bool1) or rather just bool0 == bool1
[Bug tree-optimization/109901] Optimization opportunity: ((((a) > (b)) - ((a) < (b))) < 0) -> ((a) < (b))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109901 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > bool0 - bool1 == 0 -> !bool0 & !bool1 -> !(bool0 | bool1) Sorry I messed this one up: bool0 - bool1 == 0 -> (bool0 & bool1) | (!bool0 & !bool1)
[Bug tree-optimization/109901] Optimization opportunity: ((((a) > (b)) - ((a) < (b))) < 0) -> ((a) < (b))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109901 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-05-18 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- .
[Bug tree-optimization/109901] Optimization opportunity: ((((a) > (b)) - ((a) < (b))) < 0) -> ((a) < (b))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109901 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101807, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101703 --- Comment #1 from Andrew Pinski --- Confirmed. Basically the rule is bool0 - bool1 < 0 -> !bool0 & bool1 -> bool1 < bool0 bool0 - bool1 == -1 -> !bool0 & bool1 -> bool1 < bool0 bool0 - bool1 == 0 -> !bool0 & !bool1 -> !(bool0 | bool1) bool0 - bool1 == 1 -> bool0 & !bool1 -> bool0 < bool1 bool0 - bool1 > 0 -> bool0 & !bool1 -> bool0 < bool1 and see if that reduces. Note !bool0 & bool1 -> bool1 < bool0 (see PR 101807 for the opposite there)
[Bug tree-optimization/109901] Optimization opportunity: ((((a) > (b)) - ((a) < (b))) < 0) -> ((a) < (b))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109901 Andrew Pinski changed: What|Removed |Added Component|middle-end |tree-optimization Severity|normal |enhancement Keywords||missed-optimization
[Bug middle-end/109901] New: Optimization opportunity: ((((a) > (b)) - ((a) < (b))) < 0) -> ((a) < (b))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109901 Bug ID: 109901 Summary: Optimization opportunity: a) > (b)) - ((a) < (b))) < 0) -> ((a) < (b)) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: richard.yao at alumni dot stonybrook.edu Target Milestone: --- LLVM/Clang also misses this optimization opportunity, so I also filed an issue with them: https://github.com/llvm/llvm-project/issues/62790 The following transformations can be done as an optimization: a) > (b)) - ((a) < (b))) < 0) -> ((a) < (b)) a) > (b)) - ((a) < (b))) <= 0) -> ((a) <= (b)) a) > (b)) - ((a) < (b))) == -1) -> ((a) < (b)) a) > (b)) - ((a) < (b))) == 1) -> ((a) > (b)) a) > (b)) - ((a) < (b))) == 0) -> ((a) == (b)) a) > (b)) - ((a) < (b))) > 0) -> ((a) > (b)) a) > (b)) - ((a) < (b))) >= 0) -> ((a) >= (b)) a) >= (b)) - ((a) <= (b))) < 0) -> ((a) < (b)) a) >= (b)) - ((a) <= (b))) <= 0) -> ((a) <= (b)) a) >= (b)) - ((a) <= (b))) == -1) -> ((a) < (b)) a) >= (b)) - ((a) <= (b))) == 1) -> ((a) > (b)) a) >= (b)) - ((a) <= (b))) == 0) -> ((a) == (b)) a) >= (b)) - ((a) <= (b))) > 0) -> ((a) > (b)) a) >= (b)) - ((a) <= (b))) >= 0) -> ((a) >= (b)) Both (((a) > (b)) - ((a) < (b))) and (((a) >= (b)) - ((a) <= (b))) will generate -1, 0 or 1 when comparing two integers (signed or unsigned). When comparators using this trick are inlined into the caller, the above transformations become applicable. I noticed that neither compiler exploits this high level optimization opportunity when I was working on using a faster binary search implementation for the OpenZFS b-tree code. It relied on a macro to achieve C++-style inlining of the comparator into the implementation by making different versions of the same function. The following example at godbolt does not use a macro to make it easier to see which lines of assembly correspond to which lines of high level C: https://gcc.godbolt.org/z/cdedccxae On amd64, GCC generates 15 instructions for the loop. If you comment out line 35 and uncomment line 37, GCC will generate 11 instructions for the loop. This is the output GCC would produce if it supported that high level optimization. Had the comparator returned 1 for less than and 0 for greater than or equal to, we would have had the 11-instruction version of the loop without any need for this optimization. Changing the semantics because our compilers lack this optimization would be painful in part because the entire code base expects the -1, 0 or 1 return value semantics and other code depends on these comparators. It would be nice if GCC implemented this optimization.
[Bug target/109896] Missed optimisation: overflow detection in multiplication instructions for operator new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109896 --- Comment #5 from Thiago Macieira --- (In reply to Andrew Pinski from comment #4) > If you are that picky for cycles, these cycles are not going to be a problem > compared to the dynamic allocation that is just about to happen .. Yeah, I realised that after I posted the reply. If the calculation is successful, we're going to allocate memory and that's neither fast nor determinstic. If it overflows, we're going to unwind the stack, which is even worse. I had only looked at the multiplication and failed to consider what comes after it. So, yeah, do this if it's a low-hanging fruit.
[Bug c++/106026] ICE: error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106026 --- Comment #2 from Andrew Pinski --- Reducing ...
[Bug c++/101853] [12/13/14 Regression] g++.dg/modules/xtreme-header-5_b.C ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101853 --- Comment #16 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #15) > Fixed for cris-elf after r12-6062-gba64166bf81b6e but before-and-inclusive > r12-6066-g6bcb6ed5a44b6f. That was just counting g++.dg/modules/xtreme-header-5_* failures. But "nobody" counts that close, so better say "no xtreme-header-* failures since r13-5702-g72058eea9d407e".
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 101853, which changed state. Bug 101853 Summary: [12/13/14 Regression] g++.dg/modules/xtreme-header-5_b.C ICE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101853 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/101853] [12/13/14 Regression] g++.dg/modules/xtreme-header-5_b.C ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101853 Hans-Peter Nilsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Hans-Peter Nilsson --- Fixed for cris-elf after r12-6062-gba64166bf81b6e but before-and-inclusive r12-6066-g6bcb6ed5a44b6f.
[Bug target/109896] Missed optimisation: overflow detection in multiplication instructions for operator new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109896 --- Comment #4 from Andrew Pinski --- (In reply to Thiago Macieira from comment #3) > 5 instructions, 4 cycles (not including front-end decode), so roughly the > same as the imulq example above (4 cycles), but with far more ports to > dispatch to. If you are that picky for cycles, these cycles are not going to be a problem compared to the dynamic allocation that is just about to happen ..
[Bug target/109896] Missed optimisation: overflow detection in multiplication instructions for operator new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109896 --- Comment #3 from Thiago Macieira --- (In reply to H.J. Lu from comment #2) > (In reply to Andrew Pinski from comment #1) > > I suspect the overflow code was added before __builtin_*_overflow were added > > which is why the generated code is this way. > > Should the C++ front-end use __builtin_mul_overflow? That's what that code is doing, yes. But mind you that not all examples are doing actual multiplications. That's why I had the weird size of 47. A size that is a power of 2 is just doing bit checks. For example, 16: movq%rdi, %rax shrq$59, %rax jne .L2 Other sizes do the compare, but there's no multiplication involved. For 24: movabsq $384307168202282325, %rax cmpq%rdi, %rax jb .L2 leaq(%rdi,%rdi,2), %rdi salq$3, %rdi 5 instructions, 4 cycles (not including front-end decode), so roughly the same as the imulq example above (4 cycles), but with far more ports to dispatch to.
[Bug middle-end/105910] [11/12/13/14 Regression] __builtin_return_address expansion with a large # causes a compile time issues and even ICEs sometimes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105910 Andrew Pinski changed: What|Removed |Added Known to work||10.1.0, 4.7.2, 9.5.0 Keywords||needs-bisection Summary|__builtin_return_address|[11/12/13/14 Regression] |expansion with a large #|__builtin_return_address |causes a compile time |expansion with a large # |issues and even ICEs|causes a compile time |sometimes |issues and even ICEs ||sometimes Known to fail||11.1.0 --- Comment #6 from Andrew Pinski --- Hmm, this used to work with GCC 10.1.0 and before.
[Bug middle-end/105910] __builtin_return_address expansion with a large # causes a compile time issues and even ICEs sometimes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105910 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-05-17 Status|UNCONFIRMED |NEW --- Comment #5 from Andrew Pinski --- Confirmed.
[Bug middle-end/105910] __builtin_return_address expansion with a large # causes a compile time issues and even ICEs sometimes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105910 Andrew Pinski changed: What|Removed |Added Known to fail||4.1.2 Summary|ICE: with -O1 optimization |__builtin_return_address |level and code calling |expansion with a large # |__builtin_return_address|causes a compile time ||issues and even ICEs ||sometimes Component|rtl-optimization|middle-end --- Comment #4 from Andrew Pinski --- Instead of producing 524288 instructions, I suspect we could expand that as a loop and such.
[Bug c/105875] Toggling an atomic_bool is inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105875
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|tree-optimization |c
Ever confirmed|0 |1
Last reconfirmed||2023-05-17
--- Comment #2 from Andrew Pinski ---
It is the front-end that is producing the worse code:
TARGET_EXPR ;
TARGET_EXPR (__atomic_load_1 ((const volatile void *) ,
5)))>;
:;
TARGET_EXPR (__atomic_load_1 ((const volatile void *) ,
5)))> ^ D.2818) != 0>;
if (__atomic_compare_exchange_1 ((volatile void *) , (void *) ,
(int) VIEW_CONVERT_EXPR(D.2820), 0, 5, 5))
{
goto ;
}
goto ;
:;, D.2820;
vs:
TARGET_EXPR , 5)>;, D.2827;
So confirmed.
Using __atomic_xor_fetch_1 directly works.
That is:
__atomic_xor_fetch_1 (, 1, 5);
Produces:
lock xorb $1, b(%rip)
[Bug c/105713] [gimplefe] need a way to specify TREE_ADDRESSABLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105713 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-05-17 --- Comment #1 from Andrew Pinski --- .
[Bug target/109900] New: _mm256_abs_epi8 is not expanded on gimple level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109900
Bug ID: 109900
Summary: _mm256_abs_epi8 is not expanded on gimple level
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-linux-gnu
Take (at -O3 -march=x86-64-v3):
```
#include
__m256i
should_be_cmpeq_abs0 ()
{
return _mm256_set1_epi8 (1);
}
__m256i
should_be_cmpeq_abs1 ()
{
return _mm256_abs_epi8(_mm256_set1_epi8 (-1));
}
```
I would have expected these two produce the same code generation.
In the end, we still have a builtin function in the IR rather than ABS_EXPR.
The RTL level uses abs.
In fact combine tries to combine the two instructions:
Trying 5 -> 6:
5: r85:V32QI=const_vector
6: r84:V32QI=abs(r85:V32QI)
REG_DEAD r85:V32QI
REG_EQUAL const_vector
Failed to match this instruction:
(set (reg:V32QI 84)
(const_vector:V32QI [
(const_int 1 [0x1]) repeated x32
]))
[Bug target/106060] Inefficient constant broadcast on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106060 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug target/106060] Inefficient constant broadcast on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106060 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-05-17 --- Comment #3 from Andrew Pinski --- Confirmed, I think HJL's patch definitely improves things. Though I wonder if they could be improved further.
[Bug c++/109899] [12/13/14 Regression] ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899
--- Comment #3 from Andrew Pinski ---
A little further reduced:
```
struct class1 {
class1();
~class1();
};
template using array = T[1];
template
auto f1() -> decltype(sizeof(array{}));
```
[Bug c++/109899] [12/13/14 Regression] ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-17
Keywords||ice-on-valid-code
Target Milestone|--- |12.4
Known to work||11.3.0
Summary|ICE in check_noexcept_r, at |[12/13/14 Regression] ICE
|cp/except.cc:1065 |in check_noexcept_r, at
||cp/except.cc:1065
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Known to fail||12.1.0
--- Comment #2 from Andrew Pinski ---
Reduced testcase to this valid testcase:
```
class class0 {
~class0() noexcept {}
friend class class1;
};
struct class1 {
class0 field0;
class1();
~class1();
};
template using array = T[1];
template
auto f1() noexcept
-> decltype(sizeof(array{}));
```
[Bug tree-optimization/94899] Failure to optimize out add before compare with INT_MIN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94899 Andrew Pinski changed: What|Removed |Added CC||davidfromonline at gmail dot com --- Comment #9 from Andrew Pinski --- *** Bug 105768 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/105768] Missed optimization: shifting signed to unsigned range before comparison not removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105768 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED Component|middle-end |tree-optimization --- Comment #1 from Andrew Pinski --- Dup of bug 94899 which is fixed for GCC 13. *** This bug has been marked as a duplicate of bug 94899 ***
[Bug c++/109899] ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899 --- Comment #1 from Andrew Pinski --- Reducing ...
[Bug c++/109899] New: ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899
Bug ID: 109899
Summary: ICE in check_noexcept_r, at cp/except.cc:1065
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jeanmichael.celerier at gmail dot com
Target Milestone: ---
Created attachment 55106
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55106=edit
Preprocessed source causing the bug
Repro:
#include
#include
#include
struct T {
struct {
// Works fine for value == std::array or std::string directly
std::array value;
} X;
};
int main() {
boost::pfr::detail::fields_count();
}
On godbolt: https://gcc.godbolt.org/z/xd48obMTv
Preprocessed source attached.
g++ 13.1.1 up-to-date in Arch Linux as of today, and it fails on any Boost
version that has (from 1.75 to 1.82+).
[Bug tree-optimization/105689] Bogus `-Wstringop-overflow=` after accessing field, then containing struct (wrong "region size")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105689 --- Comment #4 from Andrew Pinski --- I thought we had another bug for this CSEing ...
[Bug libfortran/81985] several sanitizer undefined runtime errors in sanitized libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81985 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from anlauf at gcc dot gnu.org --- I don't see the issue here anymore as we inline expand intrinsic MVBITS since gcc-11 and do no longer generate libgfortran calls. The issue might still exist in gcc-10. Shall we close this one as fixed?
[Bug tree-optimization/105689] Bogus `-Wstringop-overflow=` after accessing field, then containing struct (wrong "region size")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105689 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-05-17 Status|UNCONFIRMED |NEW --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug rtl-optimization/105904] Predicated mov r0, #1 with opposite conditions could be hoisted, between 1 and 1<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105904 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-05-17 Status|UNCONFIRMED |NEW Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug other/109898] New: 'make install -j' sometimes corrupts 'dir' file for .info files due to parallel 'install-info' calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109898 Bug ID: 109898 Summary: 'make install -j' sometimes corrupts 'dir' file for .info files due to parallel 'install-info' calls Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- In https://github.com/NixOS/nixpkgs/issues/229470 Arnout Engelen noticed that 'make install -j' sometimes installs incomplete '$prefix/share/info/dir' file. This happens because 'make install-info' when running in parallel is executing equivalent of: if /<>/bash-5.2-p15/bin/bash -c 'install-info --version' >/dev/null 2>&1; then \ install-info --dir-file=/<>/x86_64-unknown-linux-musl-stage-static-gcc-14.0.0/share/info/dir /<>/x86_64-unknown-linux-musl-stage-static-gcc-14.0.0/share/info/gcc.info; \ if /<>/bash-5.2-p15/bin/bash -c 'install-info --version' >/dev/null 2>&1; then \ install-info --dir-file=/<>/x86_64-unknown-linux-musl-stage-static-gcc-14.0.0/share/info/dir /<>/x86_64-unknown-linux-musl-stage-static-gcc-14.0.0/share/info/gccinstall.info; \ if /<>/bash-5.2-p15/bin/bash -c 'install-info --version' >/dev/null 2>&1; then \ install-info --dir-file=/<>/x86_64-unknown-linux-musl-stage-static-gcc-14.0.0/share/info/dir /<>/x86_64-unknown-linux-musl-stage-static-gcc-14.0.0/share/info/cppinternals.info; \ if /<>/bash-5.2-p15/bin/bash -c 'install-info --version' >/dev/null 2>&1; then \ install-info --dir-file=/<>/x86_64-unknown-linux-musl-stage-static-gcc-14.0.0/share/info/dir /<>/x86_64-unknown-linux-musl-stage-static-gcc-14.0.0/share/info/cpp.info; \ if /<>/bash-5.2-p15/bin/bash -c 'install-info --version' >/dev/null 2>&1; then \ install-info --dir-file=/<>/x86_64-unknown-linux-musl-stage-static-gcc-14.0.0/share/info/dir /<>/x86_64-unknown-linux-musl-stage-static-gcc-14.0.0/share/info/gccint.info; \ On it's own 'install-info' does not lock $prefix/share/info/dir file atomically. As a result multiple parallel executions of 'install-info' compete and occasionally throw away work of one another. Right now `nixpkgs` works it around as https://github.com/NixOS/nixpkgs/pull/229898: --- gcc-12.2.0/gcc/Makefile.in 2022-08-19 10:09:52.280658631 +0200 +++ gcc-12.2.0-new/gcc/Makefile.in 2023-05-04 14:35:44.401420184 +0200 @@ -3781,6 +3781,11 @@ fi; \ fi +# We don't care about the order in which the info files are built, but +# install-info doesn't support multiple parallel invocations writing to +# the same `dir-file`, so we have to disable parallelism for that reason: +.NOTPARALLEL: install-info + # Install the info files. # $(INSTALL_DATA) might be a relative pathname, so we can't cd into srcdir # to do the install. It might not be enough to handle language-specific 'install-info' targets. What would be the best way to handle this race condition?
[Bug target/109896] Missed optimisation: overflow detection in multiplication instructions for operator new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109896 --- Comment #2 from H.J. Lu --- (In reply to Andrew Pinski from comment #1) > I suspect the overflow code was added before __builtin_*_overflow were added > which is why the generated code is this way. Should the C++ front-end use __builtin_mul_overflow?
[Bug tree-optimization/105776] Failure to recognize __builtin_mul_overflow pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105776 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-05-17 --- Comment #4 from Andrew Pinski --- The difference between f3 and f4 for the IR: y.3_4 = (int) y_7(D); _10 = _3 == y.3_4; vs _5 = (unsigned int) _4; _6 = _5 == y_9(D); The pass must be only ready for f3 comparison rather than the one in f4. Both are the same really, casting to `unsigned int` one side rather than the other side casting to `int` is both valid thing to do.
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #7 from Richard Biener --- There is nothing to sink really, loop header copying introduces a PHI and there's not partial redundancies but only partial-partial and those are not obvious to CSE because of the introduced PHI. I believe we have to teach SRA to decompose 'cur' and maybe also 'stack', there's no scalar optimization going to do it also because we have aggregate copies involved.
[Bug libfortran/109897] Incorrect bad namelist object reported in error message when bad data appears after a valid array component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109897 --- Comment #2 from W.H.Ball at bham dot ac.uk --- > Can you confirm this? Yes, I get the same. I also get a nicer error message with -std=f2008. Thanks for finding this, since that's already a potential workaround I can investigate in the code that prompted this.
[Bug libfortran/109897] Incorrect bad namelist object reported in error message when bad data appears after a valid array component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109897 anlauf at gcc dot gnu.org changed: What|Removed |Added Component|fortran |libfortran Priority|P3 |P5 Last reconfirmed||2023-5-17 Severity|normal |enhancement --- Comment #1 from anlauf at gcc dot gnu.org --- I get a nicer error message when I specify the compiler flag -std=f2018 on the command line: Fortran runtime error: Cannot match namelist object name bad_namelist So there might have been some attempt so support legacy stuff so that you don't get the best user experience by default. Can you confirm this?
[Bug fortran/104352] ICE in gfc_conv_intrinsic_anyall, at fortran/trans-intrinsic.cc:4481 (etc.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104352 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14. Closing. Thanks for the report!
[Bug fortran/95374] ICE: gfc_array_size failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95374 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #4 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14. Closing. Thanks for the report!
[Bug fortran/104352] ICE in gfc_conv_intrinsic_anyall, at fortran/trans-intrinsic.cc:4481 (etc.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104352 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:7bafe652dba9167b65e7b5ef24e77eceb49709ba commit r14-950-g7bafe652dba9167b65e7b5ef24e77eceb49709ba Author: Harald Anlauf Date: Wed May 17 20:39:18 2023 +0200 Fortran: set shape of initializers of zero-sized arrays [PR95374,PR104352] gcc/fortran/ChangeLog: PR fortran/95374 PR fortran/104352 * decl.cc (add_init_expr_to_sym): Set shape of initializer also for zero-sized arrays, so that bounds violations can be detected later. gcc/testsuite/ChangeLog: PR fortran/95374 PR fortran/104352 * gfortran.dg/zero_sized_13.f90: New test.
[Bug fortran/95374] ICE: gfc_array_size failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95374 --- Comment #3 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:7bafe652dba9167b65e7b5ef24e77eceb49709ba commit r14-950-g7bafe652dba9167b65e7b5ef24e77eceb49709ba Author: Harald Anlauf Date: Wed May 17 20:39:18 2023 +0200 Fortran: set shape of initializers of zero-sized arrays [PR95374,PR104352] gcc/fortran/ChangeLog: PR fortran/95374 PR fortran/104352 * decl.cc (add_init_expr_to_sym): Set shape of initializer also for zero-sized arrays, so that bounds violations can be detected later. gcc/testsuite/ChangeLog: PR fortran/95374 PR fortran/104352 * gfortran.dg/zero_sized_13.f90: New test.
[Bug fortran/109897] New: Incorrect bad namelist object reported in error message when bad data appears after a valid array component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109897 Bug ID: 109897 Summary: Incorrect bad namelist object reported in error message when bad data appears after a valid array component Product: gcc Version: og12 (devel/omp/gcc-12) Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: W.H.Ball at bham dot ac.uk Target Milestone: --- Hi, A user on a Fortran project was confused by the error message they received when they provided incorrect parameters in a Fortran namelist. To reproduce, I created this small program: $ cat bna.f90 program bna implicit none integer :: iounit, array(3) namelist /test/ array open(newunit=iounit, file='test.nml', status='old') read(iounit, nml=test) close(iounit) end program bna with this associated namlist `test.nml`: $ cat test.nml array(1) = 2 bad_namelist = 3 / Compiling (with default options) and running leads to this error message: $ ./bna.x At line 10 of file bna.f90 Fortran runtime error: Bad data for namelist object array <...backtrace...> This also happens if I set the value for `array(2)` instead of `array(1)` but works correctly if I set the value for `array(3)`, which is conspicuously the last element: $ cat test.nml array(3) = 2 bad_namelist = 3 / $ ./bna.x At line 10 of file bna.f90 Fortran runtime error: Cannot match namelist object name bad_namelist This isn't a major issue but it would help if, in the first case, the error message would correctly identify `bad_namelist` as being the invalid parameter. I'm personally using gcc 12.3.1 on Fedora 37 but it was reported from and separately reproduced on other systems (whose details I don't know). I searched the list of known bugs for "namelist" in the Fortran component but didn't come across anything that looked specifically like this bug. Cheers, Warrick
[Bug tree-optimization/109892] SLP failure with explicit fma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109892 Richard Biener changed: What|Removed |Added Blocks||53947 --- Comment #2 from Richard Biener --- x86 has no vector variant of the FMA builtin and/or we do not try the fma vector optabs when seeing __builtin_fma. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug libstdc++/109889] [13/14 Regression] Segfault in __run_exit_handlers since r13-5309-gc3c6c307792026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |13.2
[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #19 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8618aed89650bbeec450191aecab3037124851b1 commit r12-9543-g8618aed89650bbeec450191aecab3037124851b1 Author: Jakub Jelinek Date: Wed May 17 10:15:50 2023 +0200 c++: Don't try to initialize zero width bitfields in zero initialization [PR109868] My GCC 12 change to avoid removing zero-sized bitfields as they are important for ABI and are needed for layout compatibility traits apparently causes zero sized bitfields to be initialized in the IL, which at least in 13+ results in ICEs in the ranger which is upset about zero precision types. I think we could even avoid initializing other unnamed bitfields, but unfortunately !CONSTRUCTOR_NO_CLEARING doesn't mean in the middle-end clearing of padding bits and until we have some new flag that represents the request to clear padding bits, I think it is better to keep zeroing non-zero sized unnamed bitfields. In addition to skipping those fields, I have changed the logic how UNION_TYPEs are handled, the current code was a little bit weird in that e.g. if first non-static data member had error_mark_node type, we'd happily zero initialize the second non-static data member, etc. 2023-05-17 Jakub Jelinek PR c++/109868 * init.cc (build_zero_init_1): Don't initialize zero-width bitfields. For unions only initialize the first FIELD_DECL. * g++.dg/init/pr109868.C: New test. (cherry picked from commit 78327cf06e6b65fc9c614622c98f6a3f3bfb7784)
[Bug c/105775] GCC uses an invalid assumption in numeric limits of char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105775
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Andrew Pinski ---
So let's take the 2 functions:
int is_ascii( char cChar){return cChar >= 0 && cChar <= 127;}
int is_ascii_printable( char cChar){return cChar >= 32 && cChar <= 127;}
In C, char can be either signed or unsigned depending on the implementation.
For GCC, it depends on the target ABI (which can be changed at compile time
also with -fsigned-char and -funsigned-char too). (a side note is `char` is a
distinct type from `unsigned char` and `signed char`).
So obvious for is_ascii, GCC will warn when char defaults to signed (<= 127) or
unsigned (>= 0) and for is_ascii_printable, GCC will warn when char defaults to
signed only (<= 127).
Also this is what -Wtype-limits documentation says:
https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Warning-Options.html#index-Wtype-limits
```
Warn if a comparison is always true or always false due to the limited range of
the data type, but do not warn for constant expressions. For example, warn if
an unsigned variable is compared against zero with < or >=.
```
So yes this warning is by design.
[Bug libstdc++/109883] Stack Overflow in functions with types and -std=c++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109883 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Jakub Jelinek --- Fixed for 13.2/14.1.
[Bug c++/109884] __builtin_Xq returns _Float128 instead of __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109884 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Jakub Jelinek --- Fixed for 13.2/14.1.
[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Jakub Jelinek --- Fixed.
[Bug libstdc++/109883] Stack Overflow in functions with types and -std=c++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109883
--- Comment #11 from CVS Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:c42950e2d380d0da26203fb1eb39497c0a400b2d
commit r13-7341-gc42950e2d380d0da26203fb1eb39497c0a400b2d
Author: Jakub Jelinek
Date: Wed May 17 21:21:23 2023 +0200
libstdc++: Fix up some templates [PR109883]
As can be seen on the following testcase, for
std::{atan2,fmod,pow,copysign,fdim,fmax,fmin,hypot,nextafter,remainder,remquo,fma}
if one operand type is std::float{16,32,64,128}_t or std::bfloat16_t and
another one some integral type or some other floating point type which
promotes to the other operand's type, we can end up with endless recursion.
This is because of a declaration ordering problem in , where the
float, double and long double overloads of those functions come before
the templates which use __gnu_cxx::__promote_{2,3}, but the
std::float{16,32,64,128}_t and std::bfloat16_t overloads come later in the
file. If the result of those promotions is _Float{16,32,64,128} or
__gnu_cxx::__bfloat16_t, say std::pow(_Float64, int) calls
std::pow(_Float64, _Float64) and the latter calls itself.
The following patch fixes that by moving those templates later in the file,
so that the calls from those templates see also the other overloads.
I think other templates in the file like e.g. isgreater etc. shouldn't be
a problem, because those just use __builtin_isgreater etc. in their bodies.
2023-05-17 Jakub Jelinek
PR libstdc++/109883
* include/c_global/cmath (atan2, fmod, pow): Move
__gnu_cxx::__promote_2 using templates after _Float{16,32,64,128}
and
__gnu_cxx::__bfloat16_t overloads.
(copysign, fdim, fmax, fmin, hypot, nextafter, remainder, remquo):
Likewise.
(fma): Move __gnu_cxx::__promote_3 using template after
_Float{16,32,64,128} and __gnu_cxx::__bfloat16_t overloads.
* testsuite/26_numerics/headers/cmath/constexpr_std_c++23.cc: New
test.
(cherry picked from commit 883f1e25dc7907c9bb37f480b900336a050218f1)
[Bug c++/109884] __builtin_Xq returns _Float128 instead of __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109884
--- Comment #10 from CVS Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:1ce8a5472f4fd98318b5f3575797b56b814b8ad9
commit r13-7340-g1ce8a5472f4fd98318b5f3575797b56b814b8ad9
Author: Jakub Jelinek
Date: Wed May 17 20:59:54 2023 +0200
i386: Fix up types in __builtin_{inf,huge_val,nan{,s},fabs,copysign}q
builtins [PR109884]
When _Float128 support has been added to C++ for 13.1, float128t_type_node
tree has been added - in C float128_type_node and float128t_type_node is
the same and represents both _Float128 and __float128, but in C++ they
are distinct types which have different handling in the FEs.
When doing that change, I mistakenly forgot to change FLOAT128 primitive
type, which is used for the __builtin_{inf,huge_val,nan{,s},fabs,copysign}q
builtins results and some of their arguments (and nothing else).
The following patch fixes that.
On ia64 we already use float128t_type_node for those builtins, pa while
it has __float128 that type is the same as long double and so those
builtins
have long double types and on powerpc seems we don't have these builtins
but instead define macros which map them to __builtin_*f128. That will
not work properly in C++, perhaps we should change those macros to be
function-like and cast to __float128.
2023-05-17 Jakub Jelinek
PR c++/109884
* config/i386/i386-builtin-types.def (FLOAT128): Use
float128t_type_node rather than float128_type_node.
* c-c++-common/pr109884.c: New test.
(cherry picked from commit c8da62cfc6475c4b7213b2164c2c0ec8ea6d96b6)
[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868 --- Comment #17 from CVS Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:72225ff27217b1a060a24d80cb21bdc1e583ef26 commit r13-7339-g72225ff27217b1a060a24d80cb21bdc1e583ef26 Author: Jakub Jelinek Date: Wed May 17 10:15:50 2023 +0200 c++: Don't try to initialize zero width bitfields in zero initialization [PR109868] My GCC 12 change to avoid removing zero-sized bitfields as they are important for ABI and are needed for layout compatibility traits apparently causes zero sized bitfields to be initialized in the IL, which at least in 13+ results in ICEs in the ranger which is upset about zero precision types. I think we could even avoid initializing other unnamed bitfields, but unfortunately !CONSTRUCTOR_NO_CLEARING doesn't mean in the middle-end clearing of padding bits and until we have some new flag that represents the request to clear padding bits, I think it is better to keep zeroing non-zero sized unnamed bitfields. In addition to skipping those fields, I have changed the logic how UNION_TYPEs are handled, the current code was a little bit weird in that e.g. if first non-static data member had error_mark_node type, we'd happily zero initialize the second non-static data member, etc. 2023-05-17 Jakub Jelinek PR c++/109868 * init.cc (build_zero_init_1): Don't initialize zero-width bitfields. For unions only initialize the first FIELD_DECL. * g++.dg/init/pr109868.C: New test. (cherry picked from commit 78327cf06e6b65fc9c614622c98f6a3f3bfb7784)
[Bug libstdc++/109883] Stack Overflow in functions with types and -std=c++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109883
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:883f1e25dc7907c9bb37f480b900336a050218f1
commit r14-949-g883f1e25dc7907c9bb37f480b900336a050218f1
Author: Jakub Jelinek
Date: Wed May 17 21:21:23 2023 +0200
libstdc++: Fix up some templates [PR109883]
As can be seen on the following testcase, for
std::{atan2,fmod,pow,copysign,fdim,fmax,fmin,hypot,nextafter,remainder,remquo,fma}
if one operand type is std::float{16,32,64,128}_t or std::bfloat16_t and
another one some integral type or some other floating point type which
promotes to the other operand's type, we can end up with endless recursion.
This is because of a declaration ordering problem in , where the
float, double and long double overloads of those functions come before
the templates which use __gnu_cxx::__promote_{2,3}, but the
std::float{16,32,64,128}_t and std::bfloat16_t overloads come later in the
file. If the result of those promotions is _Float{16,32,64,128} or
__gnu_cxx::__bfloat16_t, say std::pow(_Float64, int) calls
std::pow(_Float64, _Float64) and the latter calls itself.
The following patch fixes that by moving those templates later in the file,
so that the calls from those templates see also the other overloads.
I think other templates in the file like e.g. isgreater etc. shouldn't be
a problem, because those just use __builtin_isgreater etc. in their bodies.
2023-05-17 Jakub Jelinek
PR libstdc++/109883
* include/c_global/cmath (atan2, fmod, pow): Move
__gnu_cxx::__promote_2 using templates after _Float{16,32,64,128}
and
__gnu_cxx::__bfloat16_t overloads.
(copysign, fdim, fmax, fmin, hypot, nextafter, remainder, remquo):
Likewise.
(fma): Move __gnu_cxx::__promote_3 using template after
_Float{16,32,64,128} and __gnu_cxx::__bfloat16_t overloads.
* testsuite/26_numerics/headers/cmath/constexpr_std_c++23.cc: New
test.
[Bug ipa/109886] UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-05-17
Blocks||63426
Keywords||ice-on-valid-code
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Breakpoint 6, range_cast (r=..., type=) at
/home/apinski/src/upstream-gcc/gcc/gcc/range-op.cc:4853
4853 Value_Range tmp (r);
Confirmed.
The code looks like:
```
int g_5, func_1_l_32, func_50___trans_tmp_31;
...
int func_1() { func_50(g_3_4, g_5, func_1_l_32, 8, 3); }
...
struct S0 *func_50(int p_51, struct S0 p_52, struct S1 p_53, int p_54,
int p_55) {
...
}
```
Code in gcc:
if (TREE_CODE (arg) == SSA_NAME
&& param_type
/* Limit the ranger query to integral types as the rest
of this file uses value_range's, which only hold
integers and pointers. */
&& irange::supports_p (TREE_TYPE (arg))
&& get_range_query (cfun)->range_of_expr (vr, arg)
&& !vr.undefined_p ())
{
value_range resvr = vr;
range_cast (resvr, param_type);
if (!resvr.undefined_p () && !resvr.varying_p ())
ipa_set_jfunc_vr (jfunc, );
else
gcc_assert (!jfunc->m_vr);
}
else
gcc_assert (!jfunc->m_vr);
Maybe there should be an extra check for `irange::supports_p (param_type)` too
to catch the case where param_type type is not supported at all.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug c++/109884] __builtin_Xq returns _Float128 instead of __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109884
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c8da62cfc6475c4b7213b2164c2c0ec8ea6d96b6
commit r14-944-gc8da62cfc6475c4b7213b2164c2c0ec8ea6d96b6
Author: Jakub Jelinek
Date: Wed May 17 20:59:54 2023 +0200
i386: Fix up types in __builtin_{inf,huge_val,nan{,s},fabs,copysign}q
builtins [PR109884]
When _Float128 support has been added to C++ for 13.1, float128t_type_node
tree has been added - in C float128_type_node and float128t_type_node is
the same and represents both _Float128 and __float128, but in C++ they
are distinct types which have different handling in the FEs.
When doing that change, I mistakenly forgot to change FLOAT128 primitive
type, which is used for the __builtin_{inf,huge_val,nan{,s},fabs,copysign}q
builtins results and some of their arguments (and nothing else).
The following patch fixes that.
On ia64 we already use float128t_type_node for those builtins, pa while
it has __float128 that type is the same as long double and so those
builtins
have long double types and on powerpc seems we don't have these builtins
but instead define macros which map them to __builtin_*f128. That will
not work properly in C++, perhaps we should change those macros to be
function-like and cast to __float128.
2023-05-17 Jakub Jelinek
PR c++/109884
* config/i386/i386-builtin-types.def (FLOAT128): Use
float128t_type_node rather than float128_type_node.
* c-c++-common/pr109884.c: New test.
[Bug tree-optimization/106409] GCC with LTO: Warning: argument 1 value ‘18...615’ (SIZE_MAX) exceeds maximum object size with new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106409 --- Comment #8 from Thiago Macieira --- (In reply to Andrew Pinski from comment #7) > See PR 58525 also which added that code path. That explains why it won't call __cxa_throw_bad_array_new_length, but not why it will call operator new[](-1). My suggestion is to keep __cxa_throw_bad_array_new_length for the exceptions case and add a new function for the non-exceptional case. This function could: * call operator new[], which would probably cause the stack unwinder to terminate the application * call std::terminate() directly, possibly after printing something to stderr * return null pointer * something else (generate debug break, raise(SIGKILL), etc.)
[Bug target/106902] [11/12/13/14 Regression] Program compiled with -O3 -mfma produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 --- Comment #23 from Andrew Pinski --- (In reply to Alexander Monakov from comment #22) > Created attachment 55105 [details] > patch 1/3 > > (In reply to Richard Biener from comment #21) > > > > Sounds reasonable. Though I wouldn't use GENERIC folding but instead > > some folding-like code in c-family/ that for example would get invoked > > by genericization or via the gimplification hook? If we'd add GENERIC > > folding in fold-const.cc or match.pd the chance is that it will pick up > > FMAs "late". > > Agreed, thank you. I'm working on it. The attached patch implements this via > c_gimplify_expr and passes bootstrap+regtest under 'configure > --with-cpu=znver2' (i.e. with fma available by default). Hmm, seems like this should not be in the C family but the generic part of gimplifier. Because IIRC Fortran has similar rules but IIRC fortran front-end emits PAREN_EXPR a lot more which improves the situtation there ...
[Bug fortran/95374] ICE: gfc_array_size failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95374 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104352 Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-May/059307.html
[Bug target/106902] [11/12/13/14 Regression] Program compiled with -O3 -mfma produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 --- Comment #22 from Alexander Monakov --- Created attachment 55105 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55105=edit patch 1/3 (In reply to Richard Biener from comment #21) > > Sounds reasonable. Though I wouldn't use GENERIC folding but instead > some folding-like code in c-family/ that for example would get invoked > by genericization or via the gimplification hook? If we'd add GENERIC > folding in fold-const.cc or match.pd the chance is that it will pick up > FMAs "late". Agreed, thank you. I'm working on it. The attached patch implements this via c_gimplify_expr and passes bootstrap+regtest under 'configure --with-cpu=znver2' (i.e. with fma available by default).
[Bug tree-optimization/106409] GCC with LTO: Warning: argument 1 value ‘18...615’ (SIZE_MAX) exceeds maximum object size with new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106409 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=58525 --- Comment #7 from Andrew Pinski --- (In reply to Thiago Macieira from comment #6) > Suggestion: add a function to libgcc to be called instead of > __cxa_throw_bad_array_new_length when exceptions are disabled. That function > can be a mere two instructions, but it provides two advantages: > * no need to stream something into LTO Except there is still a generic issue (which I did link, PR 80922). > * allows post-compilation tools to know what's happened (Valgrind, > debuggers, etc.) > > I don't know if this is an acceptable solution, but I thought I'd make the > suggestion. See PR 58525 also which added that code path.
[Bug target/109896] Missed optimisation: overflow detection in multiplication instructions for operator new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109896 --- Comment #1 from Andrew Pinski --- I suspect the overflow code was added before __builtin_*_overflow were added which is why the generated code is this way.
[Bug tree-optimization/106900] Regression after memchr optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106900 --- Comment #8 from Jan-Benedict Glaw --- Thanks a lot! I scheduled builds for the three affected targets (from my target list.) The box is quite loaded right now (and a few jobs a before those three), so I guess it'll take a few hours.
[Bug tree-optimization/106409] GCC with LTO: Warning: argument 1 value ‘18...615’ (SIZE_MAX) exceeds maximum object size with new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106409 --- Comment #6 from Thiago Macieira --- Suggestion: add a function to libgcc to be called instead of __cxa_throw_bad_array_new_length when exceptions are disabled. That function can be a mere two instructions, but it provides two advantages: * no need to stream something into LTO * allows post-compilation tools to know what's happened (Valgrind, debuggers, etc.) I don't know if this is an acceptable solution, but I thought I'd make the suggestion.
[Bug target/109896] New: Missed optimisation: overflow detection in multiplication instructions for operator new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109896
Bug ID: 109896
Summary: Missed optimisation: overflow detection in
multiplication instructions for operator new
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
In the following code:
struct S
{
char buf[47]; // weird size
};
void *f(unsigned long paramCount)
{
return new S[paramCount];
}
GCC generates (see https://gcc.godbolt.org/z/o5eocj5n9):
movabsq $196241958230952676, %rax
cmpq%rdi, %rax
jb .L2
imulq $47, %rdi, %rdi
jmp operator new[](unsigned long)
f(unsigned long) [clone .cold]:
.L2:
pushq %rax
call__cxa_throw_bad_array_new_length
That's a slight pessimisation of the typical, non-exceptional case because of
the presence of the compare instructions. On modern x86, that's 3 retire slots
and 2 uops, in addition to the multiplication's 3 cycles (which may be
speculated and start early). But the presence of a 10-byte instruction and the
fact that the jump is further than 8-bit displacement range mean those three
instructions occupy 18 bytes, meaning the front-end is sub-utilised, requiring
2 cycles to decode the 5 instructions (pre-GLC [I think] CPUs decode 4
instructions in 16 bytes per cycle).
Instead, GCC should emit the multiplication and check if the overflow flag was
set. I believe the optimal code for GCC would be:
imulq $47, %rdi, %rdi
jo .L2
jmp operator new[](unsigned long)
That's 15 bytes, so 1 cycle for the decoder to decode all 3 instructions.
That's 3+1 cycles and 2 retire slots before the JMP.
In the Godbolt link above, Clang and MSVC emitted a CMOV:
mulq%rcx
movq$-1, %rdi
cmovnoq %rax, %rdi
jmp operator new[](unsigned long)@PLT
This is slightly worse (19 bytes, 4 instructions, though also 3+1 cycles). For
GCC's -fno-exceptions case, I recommend keeping the IMUL+JO case and only load
-1 in the .text.unlikely section. But see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109895
[Bug tree-optimization/109895] -Walloc-size-larger-than complains about code it generated itself under -flto -fno-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109895 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED Keywords||lto --- Comment #1 from Andrew Pinski --- This is a dup of bug 106409. *** This bug has been marked as a duplicate of bug 106409 ***
[Bug tree-optimization/106409] GCC with LTO: Warning: argument 1 value ‘18...615’ (SIZE_MAX) exceeds maximum object size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106409 Andrew Pinski changed: What|Removed |Added CC||thiago at kde dot org --- Comment #5 from Andrew Pinski --- *** Bug 109895 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/106409] GCC with LTO: Warning: argument 1 value ‘18...615’ (SIZE_MAX) exceeds maximum object size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106409
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=80922
Ever confirmed|0 |1
Keywords||lto
Last reconfirmed|2022-07-22 00:00:00 |2023-05-17
Status|UNCONFIRMED |NEW
--- Comment #4 from Andrew Pinski ---
I suspect the issue is for LTO we don't stream out the ignore part .
Anyways confirmed, you can reproduce it with the following single file
testcase:
```
typedef struct st_mysql_bind
{
int t;
int t1;
int t2;
int t3;
} bb;
[[gnu::noipa]]
void *f(unsigned long paramCount)
{
if (paramCount == 0)
return nullptr;
return new bb[paramCount]();
}
int main(void)
{
f(100);
}
```
Compile it with `-flto -W -Wall -O2` and see the warning.
[Bug c++/87628] Redundant check of pointer when operator delete is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87628 --- Comment #6 from AK --- Opened a bug for clang as well: https://github.com/llvm/llvm-project/issues/62783
[Bug driver/109605] -fno-tree-vectorize does not disable vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109605
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-05-17
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
Confirmed.
Take a simple LP64 testcase (just to make the aliasing happy):
```
int f1(long long *a, long *b, long *c)
{
long a0, a1;
a[0] = b[0] + c[0];
a[1] = b[1] + c[1];
}
```
At `-O2`, SLP vectorizers it.
`-O2 -fno-tree-vectorize` disables the SLP vectorizer
But if you did:
`-O2 -ftree-slp-vectorize -fno-tree-vectorize` the SLP vectorizer is turned on
still. This is what is definitely counter-intuitive really.
[Bug c++/109895] New: -Walloc-size-larger-than complains about code it generated itself under -flto -fno-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109895 Bug ID: 109895 Summary: -Walloc-size-larger-than complains about code it generated itself under -flto -fno-exceptions Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: thiago at kde dot org Target Milestone: --- Reference: https://bugreports.qt.io/browse/QTBUG-113603 Code in question: const auto paramCount = mysql_stmt_param_count(d->stmt); if (paramCount > 0) // allocate memory for outvalues d->outBinds = new MYSQL_BIND[paramCount](); mysql_stmt_param_count returns unsigned long. GCC 13.1 with -flto -fno-exceptions produced: src/plugins/sqldrivers/mysql/qsql_mysql.cpp: In member function ‘prepare’: src/plugins/sqldrivers/mysql/qsql_mysql.cpp:891:50: warning: argument 1 value ‘18446744073709551615’ exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=] 891 | d->outBinds = new MYSQL_BIND[paramCount](); | ^ /usr/include/c++/13/new:128:26: note: in a call to allocation function ‘operator new []’ declared here 128 | _GLIBCXX_NODISCARD void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc) | ^ Disassembling the code shows it looks similar to this: https://godbolt.org/z/9eKPxbEMY movq$-1, %rdi cmpq%rbx, %rax jb .L2 ... .L2: calloperator new[](unsigned long)@PLT So that 18446744073709551615 value is the -1 inserted by GCC itself to deal with the multiplication overflow.
[Bug c++/87628] Redundant check of pointer when operator delete is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87628 --- Comment #5 from AK --- As per: https://en.cppreference.com/w/cpp/memory/new/operator_delete """ In all cases, if ptr is a null pointer, the standard library deallocation functions do nothing. If the pointer passed to the standard library deallocation function was not obtained from the corresponding standard library allocation function, the behavior is undefined. """ So it should be fine to remove the check `if(p)`
[Bug tree-optimization/109441] missed optimization when all elements of vector are known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109441 --- Comment #3 from AK --- > But IMHO it's academic, right? yes. i was just messing with vector codegen. But in case all the elements of a vector/array are same, maybe the loop can be replaced with equivalent computation?
[Bug ipa/109770] [10/11/12/13/14 Regression] wrong(?) devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109770 --- Comment #9 from Jonathan Wakely --- (In reply to Richard Biener from comment #0) > Base *p = new B; I think if there isn't really a B at this address, then the derived-to-base conversion would be undefined. So on that basis, the compiler should be allowed to assume that there really is a B there.
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #17 from Andrew Pinski --- Since there is no GCC bug changing the issue status to invalid.
[Bug libstdc++/109891] Null pointer special handling in ostream's operator << for C-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891 --- Comment #5 from Jonathan Wakely --- (In reply to Michel Morin from comment #3) > From the safety point of view, I agree with you. But, at the same time, I > thought that detectable UB (with the help of sanitizers) is useful than > silent bug. Detectable UB doesn't guarantee detection. Sanitizers are not suitable for production code. Introducing UB here would be strictly less safe, full stop. And the bug isn't silent, it makes the stream unusable. > How about `throw`ing as in std::string's constructor? Set the exception flag on the stream and you get an exception when badbit is set.
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 GARY.WHITE at ColoState dot edu changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #16 from GARY.WHITE at ColoState dot edu --- I resolved the issue. The parameter ir was declared intent(out) in subroutine mc11ad, but there was a check in an if statement to see if ir == 0, meaning ir was defined on input. This check followed code that set ir when n == 1, and this was never executed when the code did not produce correct answers. Anyway, changing intent(out) to intent(in out) resolved the -O3 optimization issue and the code works as expected. I guess its too much to expect that the compiler would detect that a parameter was actually being access before being set if the parameter is declared intent(out) only.
