[Bug c++/102609] [C++23] P0847R7 - Deducing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609 --- Comment #16 from waffl3x --- Just gotta note that the patch posted here had an oversight, it never worked as I hoped. The good news is, I submitted a finalized patch to the patch maillist, just before I have to leave. Thanks for the help everyone, I will check in but it will probably be a while before I can work on anything in a dedicated fashion for a while. I will certainly respond to any chatter on the thread of my patch if anything comes into question though. I have to go catch a plane now, thanks again.
[Bug target/111231] armhf: Miscompilation at O2 level (O1 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #4 from Mathieu Malaterre ---
Intermediate result (creduce Debian/sid):
#include "hwy/tests/test_util-inl.h"
namespace hwy {
namespace HWY_NAMESPACE {
struct a {
template void operator()(b, c d) {
using e = MakeUnsigned;
using f = MakeWide;
RepartitionToWide aa;
using g = Vec;
using h = Vec;
size_t z = Lanes(d);
size_t j = Lanes(aa);
RebindToUnsigned k;
g l;
h m;
auto ab = AllocateAligned(j), af = AllocateAligned(z),
u = AllocateAligned(z);
for (size_t n; 0;) {
b ac = b(n);
e o = e(ac);
ab[0] = o;
}
auto ad = Set(d, LimitsMin()), p = Set(d, LimitsMax()),
q = Set(k, LimitsMax()), r = Set(aa, LimitsMin()),
s = Set(aa, LimitsMax());
b t, ae(0);
for (size_t i = 0; i < z; i++) {
auto ag(t), v(0 ? ag : ae), ah(v + 20);
af[i] = u[i] = b(-ah);
}
auto w = Load(d, af.get());
HWY_ASSERT_VEC_EQ(aa, s, SatWidenMulPairwiseAdd(aa, q, p));
auto x = Load(d, u.get());
HWY_ASSERT_VEC_EQ(
aa, r,
SatWidenMulPairwiseAdd(aa, BitCast(k, w), InterleaveLower(x, ad)));
}
};
void y() { ForShrinkableVectors()(int8_t()); }
} // namespace HWY_NAMESPACE
} // namespace hwy
int main() { hwy::N_EMU128::y(); }
[Bug middle-end/111254] Dodgy variable name (*_11 = PHI <_1(25), _25(23)>.CargoPacket::Pool...) in -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111254 --- Comment #1 from Sam James --- I have a few more of these in clang and qt* but I figure this is a smaller test case. Can report the others if needed though.
[Bug middle-end/111254] New: Dodgy variable name (*_11 = PHI <_1(25), _25(23)>.CargoPacket::Pool...) in -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111254 Bug ID: 111254 Summary: Dodgy variable name (*_11 = PHI <_1(25), _25(23)>.CargoPacket::Pool...) in -Wmaybe-uninitialized Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- Created attachment 55824 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55824&action=edit cargopacket.cpp.ii.xz With gcc (Gentoo 14.0.0 p, commit d0b55776a4e1d2f293db5ba0e4a04aefed055ec4) 14.0.0 20230830 (experimental) c121afc3b6c96a1f229ba0c4a4de6bd4b6be9a53: ``` $ g++ -c cargopacket.cpp.ii -O2 -Wmaybe-uninitialized [...] In file included from /var/tmp/portage/games-simulation/openttd-13.4/work/openttd-13.4/src/base_station_base.h:13: In static member function ‘static void Pool::PoolItem::operator delete(void*) [with Pool* Tpool = (& _cargopacket_pool); Titem = CargoPacket; Tindex = unsigned int; long unsigned int Tgrowth_step = 1024; long unsigned int Tmax_size = 16773120; PoolType Tpool_type = PT_NORMAL; bool Tcache = true; bool Tzero = false]’, inlined from ‘static void Pool::PoolItem::operator delete(void*) [with Pool* Tpool = (& _cargopacket_pool); Titem = CargoPacket; Tindex = unsigned int; long unsigned int Tgrowth_step = 1024; long unsigned int Tmax_size = 16773120; PoolType Tpool_type = PT_NORMAL; bool Tcache = true; bool Tzero = false]’ at /var/tmp/portage/games-simulation/openttd-13.4/work/openttd-13.4/src/core/pool_type.hpp:256:15, inlined from ‘void Pool::CleanPool() [with Titem = CargoPacket; Tindex = unsigned int; long unsigned int Tgrowth_step = 1024; long unsigned int Tmax_size = 16773120; PoolType Tpool_type = PT_NORMAL; bool Tcache = true; bool Tzero = false]’ at /var/tmp/portage/games-simulation/openttd-13.4/work/openttd-13.4/src/core/pool_func.hpp:200:3: /var/tmp/portage/games-simulation/openttd-13.4/work/openttd-13.4/src/core/pool_type.hpp:261:45: warning: ‘*MEM[(struct CargoPacket * *)_13].CargoPacket::Pool::PoolItem<(& _cargopacket_pool)>.Pool::PoolItem<(& _cargopacket_pool)>::index’ may be used uninitialized [-Wmaybe-uninitialized] 261 | Tpool->FreeItem(pn->index); | ^ In static member function ‘static void Pool
[Bug tree-optimization/105490] unvectorized loop due to bool condition loaded from memory and different size data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105490
--- Comment #3 from rguenther at suse dot de ---
On Wed, 30 Aug 2023, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105490
>
> --- Comment #2 from Andrew Pinski ---
> Here is an even odder case:
> ```
> #define N 256
> typedef short T;
> extern T a[N];
> extern T b[N];
> extern T c[N];
> extern _Bool pb[N];
> extern _Bool pb1[N];
> extern _Bool pb2[N];
>
> void predicate_by_booland()
> {
> for (int i = 0; i < N; i++)
> c[i] = ((pb1[i] != pb[i]) != pb2[i]) ? a[i] : b[i];
> }
> ```
> This vectorizes currently with `-O3` but not with `-O3 -fno-tree-vrp`.
> IR with -fno-tree-vrp:
> ```
> _1 = pb1[i_15];
> _2 = pb[i_15];
> _3 = _1 != _2;
> _4 = pb2[i_15];
> iftmp.0_10 = a[i_15];
> _5 = _3 != _4;
> iftmp.0_9 = b[i_15];
> ```
> IR without (VRP turned on):
> ```
> _1 = pb1[i_15];
> _2 = pb[i_15];
> _3 = _1 ^ _2;
> _4 = pb2[i_15];
> iftmp.0_10 = a[i_15];
> _5 = _3 != _4;
> iftmp.0_9 = b[i_15];
> ```
>
> So it is even more confusing ...
This is usually due to limits/bugs in the vectorizer bool pattern
recognition code which is supposed to replace "mask" uses of
bool with x ? -1 : 0 (or make sure comparisons produce them)
and data uses with x ? 1 : 0 (or make sure "data" stmts produce them).
There are defenses in vectorizable_* to detect cases where that did
go wrong (which it does sometimes), leading to missed vectorizations
(or wrong code in the worst case).
It's a mess.
[Bug middle-end/111253] New: Dodgy pointer name (*_42 = PHI ...) in -Wfree-nonheap-object diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111253 Bug ID: 111253 Summary: Dodgy pointer name (*_42 = PHI ...) in -Wfree-nonheap-object diagnostic Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Blocks: 99098 Target Milestone: --- Created attachment 55823 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55823&action=edit object_cache.i With gcc-13 (Gentoo Hardened 13.2.1_p20230826 p7) 13.2.1 20230826: ``` /bin/sh ../libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I..-fvisibility=hidden -pthread -std=gnu99 -O2 -pipe -march=native -fdiagnostics-color=always -frecord-gcc-switch es -Wreturn-type -ggdb3 -Wall -Wmissing-prototypes -Wextra -DLT_BUILDING_DLL=1 -c -o data-struct/object_cache.lo data-struct/object_cache.c libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -fvisibility=hidden -pthread -std=gnu99 -O2 -pipe -march=native -fdiagnostics-color=always -frecord-gcc-switches -Wreturn-type -ggdb3 -Wall -Wmissing-prototypes -Wextra -DLT_BUILDING_DLL=1 -c data-struct/object_cache.c -fPIC -DPIC -o data-struct/.libs/object_cache.o In function 'resize_memory_caches', inlined from 'find_cache' at data-struct/object_cache.c:211:4: data-struct/object_cache.c:150:29: warning: 'realloc' called on pointer '*_42 = PHI .t_mem_caches' with nonzero offset 640 [-Wfree-nonheap-object] 150 | lcs->t_mem_caches = realloc(lcs->t_mem_caches, | ^~ 151 | lcs->t_mem_caches_total * sizeof(struct local_cache)); | ~ ``` gcc -O2 -c object_cache.i is enough to reproduce. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99098 [Bug 99098] invalid/missing -Wfree-nonheap-object warnings
[Bug target/96762] ICE in extract_insn, at recog.c:2294 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96762 --- Comment #6 from CVS Commits --- The master branch has been updated by HaoChen Gui : https://gcc.gnu.org/g:946b8967b905257ac9f140225db744c9a6ab91be commit r14-3587-g946b8967b905257ac9f140225db744c9a6ab91be Author: Haochen Gui Date: Thu Aug 31 13:41:50 2023 +0800 rs6000: call vector load/store with length only on 64-bit Power10 gcc/ PR target/96762 * config/rs6000/rs6000-string.cc (expand_block_move): Call vector load/store with length only on 64-bit Power10. gcc/testsuite/ PR target/96762 * gcc.target/powerpc/pr96762.c: New.
[Bug rtl-optimization/110034] The first popped allcono doesn't take precedence over later popped in ira coloring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110034 HaoChen Gui changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #6 from HaoChen Gui --- It's not a problem.
[Bug target/111252] LoongArch: Suboptimal code for (a & ~mask) | (b & mask) where mask is a constant with value ((1 << n) - 1) << m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111252 --- Comment #5 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #4) > Hmm, this seems a separate issue. The compiler knows to optimize (a & mask) > if mask is ((1 << a) - 1) << b iff a + b = 32 or b = 0, but not for any I mean "32 or 64". > other masks even if it's "expensive" to materialize the mask:
[Bug target/111252] LoongArch: Suboptimal code for (a & ~mask) | (b & mask) where mask is a constant with value ((1 << n) - 1) << m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111252
--- Comment #4 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #2)
> Interesting:
> int test(int a, int b)
> {
> return (a & ~0x8000) | (b & 0x8000);
> }
>
> Produces better code:
> lu12i.w $r12,-2147483648>>12 # 0x8000
> and $r12,$r12,$r5
> bstrpick.w $r4,$r4,30,0
> or $r4,$r4,$r12
> slli.w $r4,$r4,0
> jr $r1
Hmm, this seems a separate issue. The compiler knows to optimize (a & mask) if
mask is ((1 << a) - 1) << b iff a + b = 32 or b = 0, but not for any other
masks even if it's "expensive" to materialize the mask:
long test(long a, long b)
{
return a & 0xfl;
}
compiles to:
lu12i.w $r12,-65536>>12 # 0x
lu32i.d $r12,0xf>>32
and $r4,$r4,$r12
jr $r1
But the following is better:
bstrpick.d $r12, $r12, 35, 16
slli.d $r12, $r12, 16
[Bug tree-optimization/19832] don't remove an if when we know the value is the same as with the if (subtraction)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19832 --- Comment #9 from Andrew Pinski --- Created attachment 55822 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55822&action=edit Patch which I am testing
[Bug target/111252] LoongArch: Suboptimal code for (a & ~mask) | (b & mask) where mask is a constant with value ((1 << n) - 1) << m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111252 --- Comment #3 from Andrew Pinski --- The easiest fix for __builtin_copysignf128 is change expand_copysign_bit in optabs.cc to use extract_bit_field to do the extraction and store_bit_field for the insert instead of what it currently does of using ands and ors ...
[Bug target/111252] LoongArch: Suboptimal code for (a & ~mask) | (b & mask) where mask is a constant with value ((1 << n) - 1) << m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111252 Xi Ruoyao changed: What|Removed |Added Severity|normal |enhancement
[Bug target/111252] LoongArch: Suboptimal code for (a & ~mask) | (b & mask) where mask is a constant with value ((1 << n) - 1) << m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111252
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-08-31
Keywords||missed-optimization
--- Comment #2 from Andrew Pinski ---
Interesting:
int test(int a, int b)
{
return (a & ~0x8000) | (b & 0x8000);
}
Produces better code:
lu12i.w $r12,-2147483648>>12 # 0x8000
and $r12,$r12,$r5
bstrpick.w $r4,$r4,30,0
or $r4,$r4,$r12
slli.w $r4,$r4,0
jr $r1
But note the expansion of __builtin_copysignf128 should be using
extract_bit_field and friends to extract the bit and do the insertation. I have
not looked into that yet though.
[Bug target/111252] LoongArch: Suboptimal code for (a & ~mask) | (b & mask) where mask is a constant with value ((1 << n) - 1) << m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111252 Xi Ruoyao changed: What|Removed |Added CC||chenglulu at loongson dot cn, ||chenxiaolong at loongson dot cn Target||loongarch*-*-* --- Comment #1 from Xi Ruoyao --- In particular this issue causes the compiler to compile __builtin_copysignf128 into very stupid code.
[Bug target/111252] New: LoongArch: Suboptimal code for (a & ~mask) | (b & mask) where mask is a constant with value ((1 << n) - 1) << m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111252
Bug ID: 111252
Summary: LoongArch: Suboptimal code for (a & ~mask) | (b &
mask) where mask is a constant with value ((1 << n) -
1) << m
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: xry111 at gcc dot gnu.org
Target Milestone: ---
int test(int a, int b)
{
return (a & ~0x10) | (b & 0x10);
}
compiles to:
addi.w $r12,$r0,-17# 0xffef
and $r12,$r12,$r4
andi$r5,$r5,16
or $r12,$r12,$r5
slli.w $r4,$r12,0
jr $r1
It should be improved:
bstrpick.w $r4, $r4, 4, 4
bstrins.w $r5, $r4, 4, 4
or $r5, $r4, $r0
[Bug target/111234] RISC-V: ICE in vsetvl pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111234 --- Comment #2 from CVS Commits --- The trunk branch has been updated by Lehua Ding : https://gcc.gnu.org/g:ac55f9710fe82a4ed8cb132f57303775ce60e5d1 commit r14-3583-gac55f9710fe82a4ed8cb132f57303775ce60e5d1 Author: Lehua Ding Date: Wed Aug 30 17:48:00 2023 +0800 RISC-V: Fix vsetvl pass ICE This patch fix pr111234 (a vsetvl pass ICE) when fuse a mask any vlmax vsetvl_vtype_change_only insn with a mu vsetvl insn. PR target/111234 gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (gen_vsetvl_pat): Remove condition. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/vsetvl/pr111234.c: New test.
[Bug testsuite/111251] New: Relative line # support for dg-warning/dg-error is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111251 Bug ID: 111251 Summary: Relative line # support for dg-warning/dg-error is not documented Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- https://gcc.gnu.org/pipermail/gcc-patches/2016-September/457570.html added the support for them but there is no mention of them in https://gcc.gnu.org/onlinedocs/gccint/Directives.html#Verify-compiler-messages . I noticed this while helping someone write testcases today.
[Bug tree-optimization/19832] don't remove an if when we know the value is the same as with the if (subtraction)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19832
--- Comment #8 from Andrew Pinski ---
Xor should be handled too:
```
int f_xor(int i, int j)
{
if (i!=j)
return i ^ j;
return 0;
}
``
ior and and should be handled
```
int f_or(int i, int j)
{
if (i!=j)
return i | j;
return i; // could be j not just i
}
int f_and(int i, int j)
{
if (i!=j)
return i & j;
return i; // could be j not just i
}
```
So can plus and multiply:
```
int f_add(int i, int j)
{
if (i!=j)
return i + j;
return i+i;
}
int f_mult(int i, int j)
{
if (i!=j)
return i * j;
return i*i;
}
```
Note clang handles all of these except for f_add. f_mult might be handled via
the pull `i*` out of the conditional and then you have `i!=j?j:i` which then
will be reduced to j (that is they don't pattern match f_mult). They don't have
pattern matching for f_add either and `i+i` will change to `i*2` and not pulled
out of the condition.
[Bug libstdc++/111250] New: __glibcxx_requires_subscript assertions are not checked during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111250
Bug ID: 111250
Summary: __glibcxx_requires_subscript assertions are not
checked during constant evaluation
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
This means the following example from Peter Dimov only fails with
-D_GLIBCXX_ASSERTIONS or -D_GLIBCXX_DEBUG:
#include
constexpr bool f()
{
std::vector v{ 1, 2, 3 };
return &v[3] == &v.front();
}
constexpr bool b = f();
The __glibcxx_assert macro expands to a __glibcxx_constexpr_assert check that
is always checked during constant evaluation, even without
-D_GLIBCXX_ASSERTIONS. However, the __glibcxx_requires_subscript macro does not
use __glibcxx_assert and just expands to nothing. See :
#ifndef _GLIBCXX_ASSERTIONS
# define __glibcxx_requires_non_empty_range(_First,_Last)
# define __glibcxx_requires_nonempty()
# define __glibcxx_requires_subscript(_N)
#else
// Verify that [_First, _Last) forms a non-empty iterator range.
# define __glibcxx_requires_non_empty_range(_First,_Last) \
__glibcxx_assert(_First != _Last)
# define __glibcxx_requires_subscript(_N) \
__glibcxx_assert(_N < this->size())
// Verify that the container is nonempty
# define __glibcxx_requires_nonempty() \
__glibcxx_assert(!this->empty())
#endif
I think we should remove the #ifndef and just always expand those to
__glibcxx_assert expressions. That will mean they're checked during constant
evaluation.
[Bug testsuite/111216] [14 regression] instructions counts for vector tests change after r14-3258-ge7a36e4715c716
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111216 Peter Bergner changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org Status|NEW |ASSIGNED URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-August/ ||628871.html
[Bug tree-optimization/110915] vector version of `x == MIN & x > y` is not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110915 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-August/ ||628869.html --- Comment #3 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628869.html
[Bug ipa/111245] [12/13/14 Regression] miscompilation: missing assignment when exception thrown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111245 Jakub Jelinek changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Started with r12-5244-g64f3e71c302b4a13e61656ee509e7050b9bce978
[Bug tree-optimization/110755] [13 Regression] Wrong optimization of fabs on ppc64el at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110755 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Jakub Jelinek --- Fixed for 13.3+ and 14+.
[Bug analyzer/107646] RFE: can we reimplement gcc-python-plugin's cpychecker as a -fanalyzer plugin?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107646 --- Comment #10 from CVS Commits --- The trunk branch has been updated by Eric Feng : https://gcc.gnu.org/g:597b9ec69bca8acb7a3d65641c0a730de8b27ed4 commit r14-3580-g597b9ec69bca8acb7a3d65641c0a730de8b27ed4 Author: Eric Feng Date: Wed Aug 30 17:52:24 2023 -0400 analyzer: implement reference count checking for CPython plugin [PR107646] This patch introduces initial support for reference count checking of PyObjects in relation to the Python/C API for the CPython plugin. Additionally, the core analyzer underwent several modifications to accommodate this feature. These include: - Introducing support for callbacks at the end of region_model::pop_frame. This is our current point of validation for the reference count of PyObjects. - An added optional custom stmt_finder parameter to region_model_context::warn. This aids in emitting a diagnostic concerning the reference count, especially when the stmt_finder is NULL, which is currently the case during region_model::pop_frame. The current diagnostic we emit relating to the reference count appears as follows: rc3.c:23:10: warning: expected âitemâ to have reference count: â1â but ob_refcnt field is: â2â 23 | return list; | ^~~~ âcreate_py_objectâ: events 1-4 | |4 | PyObject* item = PyLong_FromLong(3); | |^~ | || | |(1) when âPyLong_FromLongâ succeeds |5 | PyObject* list = PyList_New(1); | |~ | || | |(2) when âPyList_Newâ succeeds |.. | 14 | PyList_Append(list, item); | | ~ | | | | | (3) when âPyList_Appendâ succeeds, moving buffer |.. | 23 | return list; | | | | | | | (4) here | This is a WIP in several ways: - Currently, functions returning PyObject * are assumed to always produce a new reference. - The validation of reference count is only for PyObjects created within a function body. Verifying reference counts for PyObjects passed as parameters is not supported in this patch. gcc/analyzer/ChangeLog: PR analyzer/107646 * engine.cc (impl_region_model_context::warn): New optional parameter. * exploded-graph.h (class impl_region_model_context): Likewise. * region-model.cc (region_model::pop_frame): New callback feature for region_model::pop_frame. * region-model.h (struct append_regions_cb_data): Likewise. (class region_model): Likewise. (class region_model_context): New optional parameter. (class region_model_context_decorator): Likewise. gcc/testsuite/ChangeLog: PR analyzer/107646 * gcc.dg/plugin/analyzer_cpython_plugin.c: Implements reference count checking for PyObjects. * gcc.dg/plugin/cpython-plugin-test-2.c: Moved to... * gcc.dg/plugin/cpython-plugin-test-PyList_Append.c: ...here (and added more tests). * gcc.dg/plugin/cpython-plugin-test-1.c: Moved to... * gcc.dg/plugin/cpython-plugin-test-no-Python-h.c: ...here (and added more tests). * gcc.dg/plugin/plugin.exp: New tests. * gcc.dg/plugin/cpython-plugin-test-PyList_New.c: New test. * gcc.dg/plugin/cpython-plugin-test-PyLong_FromLong.c: New test. Signed-off-by: Eric Feng
[Bug c/111249] New: Aggressive loop optimization reports "iteration 2147483645 invokes undefined behavior"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111249
Bug ID: 111249
Summary: Aggressive loop optimization reports "iteration
2147483645 invokes undefined behavior"
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jonathan.leffler at gmail dot com
Target Milestone: ---
The problem occurs with GCC 12.2.0 and GCC 13.2.0. It is difficult to see how
the loop could ever reach iteration 2147483645. It would have had undefined
behaviour from iteration 3 onwards, anyway.
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/work1/gcc/v13.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-13.2.0/configure --prefix=/usr/gcc/v13.2.0
CC=/usr/gcc/v12.2.0/bin/gcc CXX=/usr/gcc/v12.2.0/bin/g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)
Command line:
gcc -std=c99 -O3 -Wall -pedantic -Wold-style-definition -Wold-style-declaration
-Wnested-externs -Wmissing-prototypes -Wextra -Werror -save-temps -c
gcc-inline-bug.c
Resulting errors:
In function ‘sbt_subclass_put’:
cc1: error: iteration 2147483645 invokes undefined behavior
[-Werror=aggressive-loop-optimizations]
In function ‘sbt_sendbuffer’,
inlined from ‘sbt_subclass_put’ at gcc-inline-bug.c:95:15:
gcc-inline-bug.c:52:23: note: within this loop
52 | for (int i = 0; i < n_info; i++)
| ~~^~~~
cc1: all warnings being treated as errors
Output file (gcc-inline-bug.i):
# 0 "gcc-inline-bug.c"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "gcc-inline-bug.c"
enum { E_Success = 0, E_Failure = -1 };
typedef long long LSN_t;
typedef struct BUF_s BUF_t;
typedef struct
{
LSN_t slri_lsn;
BUF_t *slri_buf;
} SLR_t;
typedef struct SBT_s SBT_t;
typedef struct
{
int (*sbtop_put)(SBT_t *objp, LSN_t a_lsn, BUF_t *a_buf);
} OPS_t;
typedef struct
{
SLR_t *slri_info;
} VAR_t;
struct SBT_s
{
SBT_t *sbtv_next;
LSN_t sbtv_last;
OPS_t sbtv_ops;
VAR_t sbtv_vars[24];
};
typedef struct
{
int sish_txid;
} ISH_t;
extern int sbt_subclass_put(SBT_t *objp, LSN_t a_lsn, BUF_t *a_buf);
extern int ISH_read(BUF_t *inbufp, ISH_t *in_header);
extern int sbt_putbuf(SBT_t *objp, LSN_t a_lsn, BUF_t *a_buf);
extern int sbt_seterr(SBT_t *objp, int rc, int s);
extern void slri_decref(BUF_t *slrip, const char *file, int line);
extern void slri_set_empty(SLR_t *slrip);
static int
sbt_sendbuffer(SBT_t *objp, SLR_t **info, int n_info)
{
int rc = E_Success;
for (int i = 0; i < n_info; i++)
{
SLR_t *pendp = info[i];
if (rc == E_Success)
{
int s = sbt_putbuf(objp->sbtv_next, pendp->slri_lsn,
pendp->slri_buf);
if (s == E_Success)
objp->sbtv_last = pendp->slri_lsn;
else
rc = sbt_seterr(objp, s, 39);
}
slri_decref(pendp->slri_buf, "gcc-inline-bug.c", 68);
slri_set_empty(pendp);
}
return rc;
}
int
sbt_subclass_put(SBT_t *objp, LSN_t a_lsn, BUF_t *a_buf)
{
BUF_t *inbufp = a_buf;
ISH_t in_header;
int rc;
if ((rc = ISH_read(inbufp, &in_header)) != E_Success)
return E_Failure;
VAR_t *vars = &objp->sbtv_vars[0];
SLR_t *pendp = &vars->slri_info[in_header.sish_txid];
ISH_t bef_header;
if ((rc = ISH_read(pendp->slri_buf, &bef_header)) != E_Success)
return E_Failure;
SLR_t aft_bufinfo = { .slri_lsn = a_lsn, .slri_buf = inbufp };
SLR_t *tosend[2] = { pendp, &aft_bufinfo };
if ((rc = sbt_sendbuffer(objp, tosend, 2)) != E_Success)
return E_Failure;
return E_Success;
}
I was given a list of possible duplicates: 57199, 59651, 79517, 84867, 88272,
103724, and 106842. Of those, 103724 (closed because the GCC 10 code line is
closed) and 106482 could be related, but neither deals with a function being
inlined and then producing the warning. The others seem loosely related but
not relevant.
The original source code (gcc-inline-big.c) has some comments in it that the
preprocessor removes:
enum { E_Success = 0, E_Failure = -1 };
typedef long long LSN_t;
typedef struct BUF_s BUF_t;
typedef struct
{
LSN_t slri_lsn;
BUF_t *slri_buf;
} SLR_t;
typedef struct SBT_s SBT_t;
typedef struct
{
int (*sbtop_put)(SBT_t *objp, LSN_t a_lsn, BUF_t *a_buf);
} OPS_t;
typedef struct
{
SLR_t *slri_info;
} VAR_t;
struct SBT_s
{
SBT_t *sbtv_next;
LSN_t sbtv_last;
OPS_t sbtv_ops;
VAR_t sbtv_vars[24];
};
typedef struct
{
int sish_txid;
} ISH_t;
/* Entry point to module */
extern int sbt_subclass_put(SBT_t *objp, LSN_t a_lsn, BUF_t *a_buf);
/* Functions used by module */
extern int ISH_read(BUF_t *inbufp, ISH_t *in_header);
extern int sbt_putbuf(SBT_
[Bug ipa/111245] [12/13/14 Regression] miscompilation: missing assignment when exception thrown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111245 Andrew Pinski changed: What|Removed |Added Summary|miscompilation: missing |[12/13/14 Regression] |assignment when exception |miscompilation: missing |thrown |assignment when exception ||thrown Known to work||11.4.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |12.4 Last reconfirmed||2023-08-30 --- Comment #2 from Andrew Pinski --- Confirmed. I thought I saw another one almost the exact same but I can't find it right now.
[Bug target/111225] ICE in curr_insn_transform, unable to generate reloads for xor, since r14-2447-g13c556d6ae84be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111225 --- Comment #3 from Vladimir Makarov --- I've reproduced the bug. Just removing `else if (spilled_pseudo_p (op))` for CT_SPECIAL_MEMORY will break a lot targets but this is right that this code is a reason for the bug. I have ideas how to fix it and I'll fix it on the next week.
[Bug testsuite/111216] [14 regression] instructions counts for vector tests change after r14-3258-ge7a36e4715c716
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111216 --- Comment #3 from Peter Bergner --- (In reply to Peter Bergner from comment #2) > The code change that led to this looks correct to me. Are we possibly just > folding more than we used to (a good thing), and that is changing our > numbers? What are the actual and expected counts? So looking at the differences between "before" and "after", we're seeing: test6_nor: .LFB13: .cfi_startproc - xxlor 34,34,35 li 9,0 lvx 0,0,9 addi 10,1,-16 xxpermdi 32,32,32,2 stxvd2x 32,0,10 xxpermdi 32,32,32,2 - vsububm 2,0,2 - vspltisw 0,-1 + xxlnor 34,34,35 vaddubm 2,2,0 stvx 2,0,9 blr ...so yes, we are getting more folding than before and the generated code is better, so we should update the expected counts. It seems to be the same issue in all of the tests.
[Bug other/111248] test case gcc.dg/tree-ssa/copy-headers-8.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111248 Andrew Pinski changed: What|Removed |Added Keywords||testsuite-fail --- Comment #1 from Andrew Pinski --- I suspect it needs `--param logical-op-non-short-circuit=1` .
[Bug other/111248] New: test case gcc.dg/tree-ssa/copy-headers-8.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111248 Bug ID: 111248 Summary: test case gcc.dg/tree-ssa/copy-headers-8.c fails Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- I can't trace this definitely to a starting point because of compiler build failures. But I suspect it has failed since its introduction in r14-2675-gef28aadad6e5cf. make -k check-gcc RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/copy-headers-8.c" FAIL: gcc.dg/tree-ssa/copy-headers-8.c scan-tree-dump-times ch2 "Conditional combines static and invariant" 1 FAIL: gcc.dg/tree-ssa/copy-headers-8.c scan-tree-dump-times ch2 "Will duplicate bb" 2 # of expected passes2 # of unexpected failures2 commit ef28aadad6e5cff3d7494f3c97d435a6579a2e2d (HEAD) Author: Jan Hubicka Date: Thu Jul 20 15:41:39 2023 +0200 loop-ch improvements, part 3 * gcc.dg/tree-ssa/copy-headers-8.c: New test.
[Bug c++/111247] Very confusing diagnostic when attempting to initialize an incomplete type: "too many initializers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111247 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-08-30 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- GCC 7 and before used to also provide: ``` :7:23: error: invalid use of incomplete type 'class Incomplete' :2:7: note: forward declaration of 'class Incomplete' class Incomplete; ^~ ``` Confirmed.
[Bug c++/111247] New: Very confusing diagnostic when attempting to initialize an incomplete type: "too many initializers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111247
Bug ID: 111247
Summary: Very confusing diagnostic when attempting to
initialize an incomplete type: "too many initializers"
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chgros at synopsys dot com
Target Milestone: ---
Compiling this code with g++ 12 gives a very misleading diagnostic when
attempting to initialize an incomplete type:
class Incomplete;
void use(Incomplete &&);
void bad()
{
use(Incomplete{0, 2});
}
error: too many initializers for 'Incomplete'
7 | use(Incomplete{0, 2});
It took me a while to figure out I was missing a header.
[Bug libstdc++/111244] std::filesystem::path encoding mismatches locale on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111244 --- Comment #7 from Thiago Macieira --- (In reply to Costas Argyris from comment #6) > At this point I just meant embedding it in your example a.out executable > file, just to check if it will work correctly. Ah, got it. But that is not the conditions of the issue at hand, so proving it works doesn't help me in the conditions that do apply. > But yes, assuming this even works, embedding the UTF-8 manifest is part of > the build process of the application, so it would have to be accounted for > in the Makefiles etc. And I can't force my users to do that. If libstdc++ wants to enforce that or require it for use of std::filesystem, it's your choice.
[Bug fortran/31059] bounds-check does not detect nonconforming assignment arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31059 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #9 from anlauf at gcc dot gnu.org --- Created attachment 55821 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55821&action=edit Partial patch (proof of concept) The attached patch adds bounds-checking for the case that the r.h.s. has only an array constructor. Note the the original testcase is bogus, as it does not prevent (re)allocation on assignment, which became default in F2003. Adjusted testcase: program p integer :: jvec(3) = [1,2,3] integer, allocatable :: ivec(:) allocate (ivec(2)) ivec(:) = [4,5,6] ! shall be detected ivec(:) = jvec! already detected end
[Bug libstdc++/111244] std::filesystem::path encoding mismatches locale on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111244 --- Comment #6 from Costas Argyris --- > I can't embed a UTF-8 manifest in my DLL and much less in my .a. As a > library writer (I'm the QtCore maintainer), that's out of my hands - it is > an application decision. At this point I just meant embedding it in your example a.out executable file, just to check if it will work correctly. But FYI, you don't embed the UTF-8 manifest into every static/dynamic library - just to the executable.It is essentially just a new object file that you are linking your executable against, whose purpose is to make the resulting executable use UTF-8 as its active code page. But yes, assuming this even works, embedding the UTF-8 manifest is part of the build process of the application, so it would have to be accounted for in the Makefiles etc.
[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111246 --- Comment #4 from Luke Geeson --- Add Wilco also addressed this for AArch64 in GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108891
[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111246 --- Comment #3 from Luke Geeson --- According to the latest C/C++ and PPC models, yes. If x was non-atomic, then this would be a racy (UB) test, but making x atomic with relaxed order is well-defined according to the C model (and therefore any racy behaviour should not occur). In any case, a sequentially consistent load should not allow re-ordering. We reported (and are patching) a similar bug in LLVM for AArch64 (https://github.com/llvm/llvm-project/issues/62652)
[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111246 Andrew Pinski changed: What|Removed |Added Target||powerpc64le --- Comment #2 from Andrew Pinski --- You are sure this is correct. x is a relaxed order so the store could be reorded before all other atomics even.
[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111246 --- Comment #1 from Luke Geeson --- Edit: The godbolt link points to the same bug in LLVM I am reporting, here is the GCC godbolt link https://godbolt.org/z/Tan5jrvKa
[Bug ipa/111245] miscompilation: missing assignment when exception thrown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111245 --- Comment #1 from Brian Green --- It seems working on gcc 11.4 or earlier, but broken since gcc 12.1 on all versions I could test on godbolt.org.
[Bug target/111246] New: PPC64 Sequentially Consistent Load allows Reordering of Stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111246
Bug ID: 111246
Summary: PPC64 Sequentially Consistent Load allows Reordering
of Stores
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: luke.geeson at cs dot ucl.ac.uk
Target Milestone: ---
Consider the following litmus test that captures bad behaviour:
```
C test
{ *x = 0; *y = 0; } // fixed initial state where x and y are 0
// Concurrent threads
P0 (atomic_int* y,atomic_int* x) {
atomic_store_explicit(x,2,memory_order_relaxed);
atomic_thread_fence(memory_order_consume);
atomic_store_explicit(y,1,memory_order_seq_cst);
}
P1 (atomic_int* y,atomic_int* x) {
int r0 = atomic_load_explicit(y,memory_order_seq_cst);
atomic_thread_fence(memory_order_relaxed);
atomic_store_explicit(x,1,memory_order_relaxed);
}
exists ([x]=2 /\ 1:r0=1)
```
where 'P0:r0 = 0' means thread P0, local variable r0 has value 0. [x] means x
is a global.
When simulating this test under the C/C++ model from its initial state, the
outcome of execution in the exists clause is forbidden by the source model. The
allowed outcomes are:
```
{ P1:r0=0; [x]=1; }
{ P1:r0=0; [x]=2; }
{ P1:r0=1; [x]=1; }
```
When compiling to target PPC64le with GCC trunk `-c -g -O1 -pthread --std=c11
-ffreestanding -mabi=elfv1` (https://godbolt.org/z/xj9W7nr9G), the compiled
program has the following outcomes when simulated under the PPC model:
```
{ P1:r0=0; [x]=1; }
{ P1:r0=0; [x]=2; }
{ P1:r0=1; [x]=1; }
{ P1:r0=1; [x]=2; } <--- forbidden by source model, bug!
```
which occurs since the `b L0x50; isync` pattern allows the memory effect of the
load of y on thread P1 to be reordered after the store to x on P1. We observe
the execution:
{ P1:r0=0;[x]=0} -> P1:W[x]=1 -> P0:W[x]=2 -> P0:W[y]=1 -> P1:R[y]=0 -> {
P1:r0=1; [x]=2; }
where the local variable `r0` is stored in register r9 in the compiled code.
The problem is isync forces the instructions to finish, but not their memory
effects. Hence the forbidden outcome { P1:r0=1; [x]=2; } is allowed under the
ppc model.
```
PPC test
{ [P1_r0]=0;[x]=0;[y]=0;
uint64_t %P0_x=x; uint64_t %P0_y=y;
uint64_t %P1_P1_r0=P1_r0;uint64_t %P1_x=x;
uint64_t %P1_y=y }
(*)
(* the Telechat toolsuite*)
(* *)
(* Luke Geeson, University College London, UK. *)
(* *)
(*)
P0 | P1;
li r10,2 | sync ;
stw r10,0(%P0_x) | lwz r9,0(%P1_y) ;
lwsync| cmpw r9,r9 ;
sync | b L0x50;
li r10,1 | L0x50: isync ;
stw r10,0(%P0_y) | li r8,1 ;
| stw r8,0(%P1_x) ;
| stw r9,0(%P1_P1_r0) ;
exists ([x]=2 /\ P1_r0=1) // YES under PPC model
```
We have observed this behaviour with several hundred Message Passing and 'S'
pattern tests (the above is an S pattern test).
To fix this, we advise replacing the isync with lwfence to forbid the buggy
behaviour:
```
PPC test-fixed
{ [P1_r0]=0;[x]=0;[y]=0;
uint64_t %P0_x=x; uint64_t %P0_y=y;
uint64_t %P1_P1_r0=P1_r0;uint64_t %P1_x=x;
uint64_t %P1_y=y }
(*)
(* the Telechat toolsuite*)
(* *)
(* Luke Geeson, University College London, UK. *)
(* *)
(*)
P0 | P1;
li r10,2 | sync ;
stw r10,0(%P0_x) | lwz r9,0(%P1_y) ;
lwsync| cmpw r9,r9 ;
sync | b L0x50;
li r10,1 | L0x50: lwfence;
stw r10,0(%P0_y) | li r8,1 ;
| stw r8,0(%P1_x) ;
| stw r9,0(%P1_P1_r0) ;
exists ([x]=2 /\ P1_r0=1) // NO under PPC model
```
which no longer allows the buggy outcome under the ppc model:
```
{ P1:r0=0; [x]=1; }
{ P1:r0=0; [x]=2; }
{ P1:r0=1; [x]=1; }
```
I'm happy to discuss this as needed.
[Bug c++/111245] New: miscompilation: missing assignment when exception thrown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111245
Bug ID: 111245
Summary: miscompilation: missing assignment when exception
thrown
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: briangreenery at gmail dot com
Target Milestone: ---
gcc version 13.2.0 (Compiler-Explorer-Build-gcc--binutils-2.40)
Target: x86_64-linux-gnu
It looks like initialization is incorrectly skipped when:
* The initialization is overwritten by an unconditional assignment from a
function
* However, that function throws an exception which avoids the assignment
The following code should return 5, but it returns random garbage on -O1 or
-O2.
https://godbolt.org/z/T3qTnheYW
# 0 "/app/example.cpp"
# 1 "/app//"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "/app/example.cpp"
struct Int {
int value;
};
__attribute__((noipa)) Int always_throws() { throw 123; }
void foo(Int &x) {
try {
x = always_throws();
} catch (...) {
}
}
int main() {
Int x;
x.value = 5;
foo(x);
return x.value;
}
[Bug libstdc++/111244] std::filesystem::path encoding mismatches locale on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111244 --- Comment #5 from Thiago Macieira --- (In reply to Jonathan Wakely from comment #3) > Somebody else will have to fix this, I've already wasted too much of my life > making std:: filesystem (mostly) work on Windows. Same here. (In reply to Costas Argyris from comment #4) > I'm wondering if it will work after embedding a UTF-8 manifest into your > a.out executable, as described here: > > https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8- > code-page I can't embed a UTF-8 manifest in my DLL and much less in my .a. As a library writer (I'm the QtCore maintainer), that's out of my hands - it is an application decision. If GCC+Binutils team wants to enforce that for the future, be my guest. I'd support your decision; I think it's high time this happened. But I'm sure there would be a lot of push-back from people who can't do that because their existing Windows applications rely on the legacy encodings or those who deploy to Windows versions that didn't have such support. I have a vague memory of discussing this in the Qt development mailing list, but can't find it. A softer approach is for std::filesystem to declare that it only supports UTF-8-manifested applications (closing this bug as WONTFIX / working-as-designed). I'd again support your decision and will simply pass the requirement along to my users.
[Bug target/106562] PRU: Inefficient code for zero check of 64-bit (boolean) AND result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106562 Dimitar Dimitrov changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Dimitar Dimitrov --- Should be fixed now in trunk.
[Bug libstdc++/111244] std::filesystem::path encoding mismatches locale on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111244 Costas Argyris changed: What|Removed |Added CC||costas.argyris at gmail dot com --- Comment #4 from Costas Argyris --- I'm wondering if it will work after embedding a UTF-8 manifest into your a.out executable, as described here: https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
[Bug libstdc++/111244] std::filesystem::path encoding mismatches locale on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111244 --- Comment #3 from Jonathan Wakely --- Somebody else will have to fix this, I've already wasted too much of my life making std:: filesystem (mostly) work on Windows.
[Bug fortran/89891] [meta-bug] Accessing memory in rejected statements or expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89891 Bug 89891 depends on bug 48776, which changed state. Bug 48776 Summary: ICE(segfault) after -std=f95 diagnostic error involving PROCEDURE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/48776] ICE(segfault) after -std=f95 diagnostic error involving PROCEDURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776 Mikael Morin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Mikael Morin --- Fixed for gcc 14. Closing.
[Bug fortran/107923] ICE in lookup_function_fuzzy_find_candidates / check_interface0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107923 Mikael Morin changed: What|Removed |Added Resolution|--- |DUPLICATE CC||mikael at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #3 from Mikael Morin --- All the testcases here have been fixed by the fix for pr48776. Closing as duplicate. *** This bug has been marked as a duplicate of bug 48776 ***
[Bug fortran/48776] ICE(segfault) after -std=f95 diagnostic error involving PROCEDURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776 Mikael Morin changed: What|Removed |Added CC||gs...@t-online.de --- Comment #10 from Mikael Morin --- *** Bug 107923 has been marked as a duplicate of this bug. ***
[Bug libstdc++/111244] std::filesystem::path encoding mismatches locale on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111244 --- Comment #2 from Thiago Macieira --- (In reply to Andrew Pinski from comment #1) > Except the code page could be tuned via a manifest file even. > For an example GCC embeds a manifest into its own compiler to work around > this issue and just use UTF8 always. > > So ... Indeed, but won't MultiByteToWideChar() adapt to that and correctly convert from UTF-8 to UTF-16?
[Bug libstdc++/111244] std::filesystem::path encoding mismatches locale on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111244 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=108865 --- Comment #1 from Andrew Pinski --- For windows it is a bit more complex, than that even. > This is caused by std::filesystem::path interpreting the input as UTF-8. > On Windows, it's not; it must be decoded using the locale codec. Except the code page could be tuned via a manifest file even. For an example GCC embeds a manifest into its own compiler to work around this issue and just use UTF8 always. So ...
[Bug c++/111244] New: std::filesystem::path encoding mismatches locale on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111244
Bug ID: 111244
Summary: std::filesystem::path encoding mismatches locale on
Windows
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Test:
$ cat fstest.cpp
#include
#include
int main(int argc, char **argv)
{
for (int i = 1; i < argc; ++i) {
std::filesystem::path p(argv[i]);
if (std::filesystem::exists(p)) {
printf("%s %llu\n", argv[1], (unsigned long
long)std::filesystem::file_size(p));
} else {
printf("%s does not exist\n", argv[1]);
}
}
}
$ touch filæ
$ g++ fstest.cpp
$ ./a.out fstest.cpp filæ
On Linux (and any other Unix):
fstest.cpp 377
fstest.cpp 0
On Windows with libc++ or MS STL:
fstest.cpp 377
fstest.cpp 0
On Windows with libstdc++:
fstest.cpp 377
terminate called after throwing an instance of
'std::filesystem::__cxx11::filesystem_error'
what(): filesystem error: Cannot convert character sequence: Illegal byte
sequence
This is caused by std::filesystem::path interpreting the input as UTF-8. On
Windows, it's not; it must be decoded using the locale codec.
Strictly speaking, the same should apply to the conversion to Unicode on Unix
systems too, but a) they're almost all UTF-8 these days, so the corner cases
may be ignored by a policy decision and b) the mismatch of input does not lead
to inability to refer to files by fs::path alone.
[Bug target/106562] PRU: Inefficient code for zero check of 64-bit (boolean) AND result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106562 --- Comment #7 from CVS Commits --- The master branch has been updated by Dimitar Dimitrov : https://gcc.gnu.org/g:ee077d0c5793e1d4ad8d3b033ef2f0225ba6bd59 commit r14-3578-gee077d0c5793e1d4ad8d3b033ef2f0225ba6bd59 Author: Dimitar Dimitrov Date: Tue Jun 13 22:20:13 2023 +0300 pru: Add cstore expansion patterns Add cstore patterns for the two specific operations which can be efficiently expanded using the UMIN instruction: X != 0 X == 0 The rest of the operations are rejected, and left to be expanded by the common expansion code. PR target/106562 gcc/ChangeLog: * config/pru/predicates.md (const_0_operand): New predicate. (pru_cstore_comparison_operator): Ditto. * config/pru/pru.md (cstore4): New pattern. (cstoredi4): Ditto. gcc/testsuite/ChangeLog: * gcc.target/pru/pr106562-10.c: New test. * gcc.target/pru/pr106562-11.c: New test. * gcc.target/pru/pr106562-5.c: New test. * gcc.target/pru/pr106562-6.c: New test. * gcc.target/pru/pr106562-7.c: New test. * gcc.target/pru/pr106562-8.c: New test. * gcc.target/pru/pr106562-9.c: New test. Signed-off-by: Dimitar Dimitrov
[Bug target/111237] fp-int-convert-float64x.c fails on x86_64-apple-darwin with "ambiguous instructions require an explicit suffix"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111237 --- Comment #5 from Iain Sandoe --- (In reply to Francois-Xavier Coudert from comment #4) > INVALID, then. I need a better way to create this cross-compiler. The way to build cross compilers for GCC is: 1. build a native compiler for source 2. build a cross compiler from the same sources using (1). Trying to use clang as a cross-bootstrap for GCC is going to be (very) unreliable at best and most likely will fail (I quite regularly get non-bugs reported from attempts to do this). I regularly build crosses and native crosses and (apart from one small amount of magic needed to get the linker version passed to a native cross) it works reliably (including Ada).
[Bug c++/52953] function parameter name redeclarations not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52953 --- Comment #8 from Jakub Jelinek --- Created attachment 55820 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55820&action=edit gcc14-pr52953-2.patch Untested incremental patch to diagnose even extern redeclarations in the https://eel.is/c++draft/basic.scope#block-2 case. I'm not convinced this second part is correct though and there seems to be high implementation variance (g++ vs. clang++ vs. ICC vs. MSVC). Because https://eel.is/c++draft/basic.scope#block-2 talks about declarations whose target scope is the block scope of S, while https://eel.is/c++draft/basic.scope#scope-2.10 says that extern block-scope declarations target larger scope but bind a name in the immediate scope.
[Bug c++/91319] Designated initializer doesn't support direct-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91319 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed.
[Bug c++/91319] Designated initializer doesn't support direct-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91319
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:4a92205ef1da044eaf9490e61787836a3abe7d6c
commit r14-3577-g4a92205ef1da044eaf9490e61787836a3abe7d6c
Author: Marek Polacek
Date: Fri Aug 25 11:47:54 2023 -0400
c++: CWG 2359, wrong copy-init with designated init [PR91319]
This CWG clarifies that designated initializer support
direct-initialization.
Just be careful what Note 2 in [dcl.init.aggr]/4.2 says: "If the
initialization is by designated-initializer-clause, its form determines
whether copy-initialization or direct-initialization is performed." Hence
this patch sets CONSTRUCTOR_IS_DIRECT_INIT only when we are dealing with
".x{}", but not ".x = {}".
PR c++/91319
gcc/cp/ChangeLog:
* parser.cc (cp_parser_initializer_list): Set
CONSTRUCTOR_IS_DIRECT_INIT
when the designated initializer is of the .x{} form.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/desig30.C: New test.
[Bug c++/52953] function parameter name redeclarations not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52953 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Created attachment 55819 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55819&action=edit gcc14-pr52953-1.patch Untested patch to diagnose invalid redeclaration of parameter in function-try-block.
[Bug c++/111243] New: The -Og option inlines functions, making for a poor debugging experience.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243 Bug ID: 111243 Summary: The -Og option inlines functions, making for a poor debugging experience. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: amohr at amohr dot org Target Milestone: --- The docs recommend using -Og for debug builds, but that option inlines functions which makes single-stepping in debuggers difficult/impossible. Adding -fno-inline fixes it. The docs for -Og say that it disables -finline-functions-called-once. Should -Og also do -fno-inline? Here's a small example showing the difference between plain '-Og' and '-Og -fno-inline': https://godbolt.org/z/evs73cPT1
[Bug c++/111242] Out of bounds pointer arithmetic not caught in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111242 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-08-30 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- .
[Bug c++/111242] Out of bounds pointer arithmetic not caught in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111242
--- Comment #1 from Andrew Pinski ---
Confirmed reduced testcase:
```
#define size 3
constexpr auto tester() {
int *v = new int[size];
auto p = &v[size+1];
bool t = &v[0] == p;
delete[] v;
return t;
}
static_assert(!tester());
#if 0
constexpr auto tester1() {
int v[size];
auto p = &v[size+1];
bool t = &v[0] == p;
return t;
}
static_assert(!tester1());
#endif
```
GCC does catch the static allocated one; just not the dynamic allocated one.
[Bug target/111237] fp-int-convert-float64x.c fails on x86_64-apple-darwin with "ambiguous instructions require an explicit suffix"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111237 Francois-Xavier Coudert changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #4 from Francois-Xavier Coudert --- Hum, I think I understand what happens then. This is a cross-compiler from aarch64-apple-darwin22 to x86_64-apple-darwin22, configured with: configure --prefix=/tmp/irun --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl --with-zstd=/opt/homebrew/opt/zstd --target=x86_64-apple-darwin22 --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk AS_FOR_TARGET=/usr/bin/as LD_FOR_TARGET=/usr/bin/ld NM_FOR_TARGET=/usr/bin/nm RANLIB_FOR_TARGET=/usr/bin/ranlib AR_FOR_TARGET=/usr/bin/ar LIPO_FOR_TARGET=/usr/bin/lipo DSYMUTIL_FOR_TARGET=/usr/bin/dsymutil The tests are using AS_FOR_TARGET but not passing the arch, which is necessary because it's a multi-arch linker. The actual GCC cross-compiler knows that, and systematically passes an arch argument, but gcc_GAS_CHECK_FEATURE does not know that. INVALID, then. I need a better way to create this cross-compiler.
[Bug middle-end/111241] Extraordinary amount of time spent in "callgraph functions expansion"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111241 --- Comment #1 from Andrew Pinski --- With -fno-checking but still the default --enable-checking setting for the trunk: alias stmt walking : 18.90 ( 21%) 0.20 ( 7%) 25.86 ( 24%) 8960 ( 0%) df reaching defs : 9.96 ( 11%) 0.05 ( 2%) 9.90 ( 9%) 0 ( 0%) tree FRE : 9.07 ( 10%) 0.38 ( 13%) 9.49 ( 9%) 14M ( 3%) tree DSE : 9.43 ( 11%) 0.00 ( 0%) 9.45 ( 9%) 11k ( 0%) The rest are spread out. Note "callgraph functions expansion" is a "meta" timevar and includes the above really.
[Bug c++/111242] New: Out of bounds pointer arithmetic not caught in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111242
Bug ID: 111242
Summary: Out of bounds pointer arithmetic not caught in
constexpr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: llvm at rifkin dot dev
Target Milestone: ---
The following UB is not caught by gcc:
#include
constexpr auto tester() {
std::vector v = {1, 2, 3};
auto p = &v[v.size() + 1];
return &v[0] == p;
}
static_assert(!tester());
https://godbolt.org/z/Y3ofcb1b1
[Bug c/111241] New: Extraordinary amount of time spent in "callgraph functions expansion"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111241 Bug ID: 111241 Summary: Extraordinary amount of time spent in "callgraph functions expansion" Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 55818 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55818&action=edit gzipped C source code foundBugs $ time ~/gcc/results/bin/gcc -c -w -O1 -fno-var-tracking bug951.c real0m52.441s user0m51.038s sys 0m0.498s foundBugs $ (ulimit -t 300; time ~/gcc/results/bin/gcc -c -w -O2 -fno-var-tracking bug951.c) real2m18.781s user2m15.957s sys 0m1.205s foundBugs $ >From -ftime-report on the second compile: Time variable usr sys wall GGC phase setup: 0.00 ( 0%) 0.01 ( 0%) 0.00 ( 0%) 1832k ( 0%) phase parsing : 1.78 ( 1%) 2.83 ( 56%) 4.66 ( 3%) 55M ( 12%) phase opt and generate : 136.07 ( 99%) 2.18 ( 43%) 139.81 ( 97%) 411M ( 88%) garbage collection : 0.95 ( 1%) 0.02 ( 0%) 0.91 ( 1%) 0 ( 0%) callgraph construction : 0.16 ( 0%) 0.02 ( 0%) 0.16 ( 0%) 11M ( 2%) callgraph optimization : 0.15 ( 0%) 0.05 ( 1%) 0.22 ( 0%) 3272 ( 0%) callgraph functions expansion : 106.59 ( 77%) 1.39 ( 28%) 109.22 ( 76%) 299M ( 64%) callgraph ipa passes : 28.82 ( 21%) 0.74 ( 15%) 29.88 ( 21%) 84M ( 18%)
[Bug tree-optimization/111240] Incorrect warning from -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111240 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED
[Bug target/111237] fp-int-convert-float64x.c fails on x86_64-apple-darwin with "ambiguous instructions require an explicit suffix"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111237 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-08-30 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- HAVE_AS_IX86_FILDS should have been true. Which comes from: gcc_GAS_CHECK_FEATURE([filds and fists mnemonics], gcc_cv_as_ix86_filds,, [filds (%ebp); fists (%ebp)],, [AC_DEFINE(HAVE_AS_IX86_FILDS, 1, [Define if your assembler uses filds and fists mnemonics.])]) Can you attach the config.log from inside the gcc directory?
[Bug tree-optimization/105490] unvectorized loop due to bool condition loaded from memory and different size data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105490
--- Comment #2 from Andrew Pinski ---
Here is an even odder case:
```
#define N 256
typedef short T;
extern T a[N];
extern T b[N];
extern T c[N];
extern _Bool pb[N];
extern _Bool pb1[N];
extern _Bool pb2[N];
void predicate_by_booland()
{
for (int i = 0; i < N; i++)
c[i] = ((pb1[i] != pb[i]) != pb2[i]) ? a[i] : b[i];
}
```
This vectorizes currently with `-O3` but not with `-O3 -fno-tree-vrp`.
IR with -fno-tree-vrp:
```
_1 = pb1[i_15];
_2 = pb[i_15];
_3 = _1 != _2;
_4 = pb2[i_15];
iftmp.0_10 = a[i_15];
_5 = _3 != _4;
iftmp.0_9 = b[i_15];
```
IR without (VRP turned on):
```
_1 = pb1[i_15];
_2 = pb[i_15];
_3 = _1 ^ _2;
_4 = pb2[i_15];
iftmp.0_10 = a[i_15];
_5 = _3 != _4;
iftmp.0_9 = b[i_15];
```
So it is even more confusing ...
[Bug tree-optimization/111240] Incorrect warning from -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111240 --- Comment #4 from Bruce Momjian --- (In reply to Andrew Pinski from comment #2) > Can you provide the preprocessed source? Done. Sorry my previous file was 1.1MB and I didn't realize the attachment failed. I have gzipped the file.
[Bug tree-optimization/111240] Incorrect warning from -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111240 --- Comment #3 from Bruce Momjian --- Created attachment 55817 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55817&action=edit preprocessed C file
[Bug tree-optimization/111240] Incorrect warning from -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111240 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2023-08-30 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Can you provide the preprocessed source?
[Bug tree-optimization/111240] Incorrect warning from -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111240 --- Comment #1 from Andrew Pinski --- *** Bug 111239 has been marked as a duplicate of this bug. ***
[Bug c/111239] Incorrect warning from -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111239 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- . *** This bug has been marked as a duplicate of bug 111240 ***
[Bug c/111240] New: Incorrect warning from -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111240
Bug ID: 111240
Summary: Incorrect warning from -Wmaybe-uninitialized
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bruce at momjian dot us
Target Milestone: ---
Compiling this file from the PostgreSQL master source tree generates a warning
when I don't think it should. To reproduce, only -O1 produces the bug, not
-O0/-O2/-O3:
gcc -Wmaybe-uninitialized -O1 -c clauses.i
Yields:
clauses.c: In function ‘recheck_cast_function_args’:
clauses.c:4293:19: warning: ‘actual_arg_types’ may be used uninitialized
[-Wmaybe-uninitialized]
4293 | rettype = enforce_generic_type_consistency(actual_arg_types,
In file included from clauses.c:45:
../../../../src/include/parser/parse_coerce.h:82:17: note: by argument 1 of
type ‘const Oid *’ {aka ‘const unsigned int *’} to
‘enforce_generic_type_consistency’ declared here
82 | extern Oid enforce_generic_type_consistency(const Oid
*actual_arg_types,
| ^~~~
clauses.c:4279:24: note: ‘actual_arg_types’ declared here
4279 | Oid actual_arg_types[FUNC_MAX_ARGS];
| ^~
Here is the C code. nargs prevents uninitialized values from being used when
calling enforce_generic_type_consistency().
-
static void
recheck_cast_function_args(List *args, Oid result_type,
Oid *proargtypes, int pronargs,
HeapTuple func_tuple)
{
Form_pg_proc funcform = (Form_pg_proc) GETSTRUCT(func_tuple);
int nargs;
Oid actual_arg_types[FUNC_MAX_ARGS];
Oid declared_arg_types[FUNC_MAX_ARGS];
Oid rettype;
ListCell *lc;
if (list_length(args) > FUNC_MAX_ARGS)
elog(ERROR, "too many function arguments");
nargs = 0;
foreach(lc, args)
{
actual_arg_types[nargs++] = exprType((Node *) lfirst(lc));
}
Assert(nargs == pronargs);
memcpy(declared_arg_types, proargtypes, pronargs * sizeof(Oid));
rettype = enforce_generic_type_consistency(actual_arg_types,
declared_arg_types,
nargs,
funcform->prorettype,
false);
[Bug c++/111173] G++ allows constinit functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Marek Polacek --- Fixed.
[Bug testsuite/111228] [14 regression] gcc.target/powerpc/vsx-extract-6.c fails after r14-3381-g27de9aa152141e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111228 --- Comment #6 from Peter Bergner --- (In reply to Richard Biener from comment #5) > Should be fixed. Confirmed fixed. Thanks!
[Bug c++/111173] G++ allows constinit functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:c121afc3b6c96a1f229ba0c4a4de6bd4b6be9a53 commit r14-3576-gc121afc3b6c96a1f229ba0c4a4de6bd4b6be9a53 Author: Marek Polacek Date: Tue Aug 29 13:16:41 2023 -0400 c++: disallow constinit on functions [PR73] [dcl.constinit]/1: The constinit specifier shall be applied only to a declaration of a variable with static or thread storage duration. and while we detect constinit int fn(); we weren't detecting using F = int(); constinit F f; PR c++/73 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Disallow constinit on functions. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/constinit19.C: New test.
[Bug libstdc++/111238] libstdc++ tests should use -Wl,-gc-sections in more configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111238 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2023-08-30 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c/111239] New: Incorrect warning from -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111239 Bug ID: 111239 Summary: Incorrect warning from -Wmaybe-uninitialized Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bruce at momjian dot us Target Milestone: ---
[Bug rtl-optimization/110093] [12/13/14 Regression][avr] Move frenzy leading to code bloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093 --- Comment #5 from Vladimir Makarov --- (In reply to Georg-Johann Lay from comment #4) > > > So are you saying that the bug is actually in lower-subreg.cc ? No. lower subreg is fine. Sorry to be unclear. To generate a better code for the current test case (or analogous cases) we need live analysis on sub-register level. Currently it is done only on whole pseudo-register level. First of all DFA (data flow analysis framework) should be modified. As I showed DFA wrongly calculate that pseudo r44 lives at the start of BB2, although it is not (r44 value is not used before insn #37). It is a big job. The problem is also that the active development of DFA stopped long time ago and their developers do not work on gcc anymore. Secondly, after DFA modification RA (and may be other optimizations) should be modified to work with this information on BB-level. It is a medium size project for me and probably it would take 2-3 months of my work time. So looking at this situation, I would suggest to make -fno-split-wide-types a default for AVR target to solve this and and analogous PRs. May be it is not necessary for good performance of real avr applications. I am not user AVR and can not say how severe this problem for the real applications.
[Bug libstdc++/104167] Implement C++20 std::chrono::utc_clock, std::chrono::tzdb etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167 --- Comment #12 from Christophe Lyon --- (In reply to Jonathan Wakely from comment #11) > Please file a separate bug for these failures. Thanks for the pointers, I digged a bit more, and filed: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111238
[Bug libstdc++/111238] New: libstdc++ tests should use -Wl,-gc-sections in more configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111238 Bug ID: 111238 Summary: libstdc++ tests should use -Wl,-gc-sections in more configurations Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org CC: jwakely.gcc at gmail dot com Target Milestone: --- As a follow-up to bug #104167, I've looked in more detail after Jonathan's last comment there: > Does arm-eabi build libstdc++.a with -ffunction-sections? > The tests should be built with -Wl,--gc-sections which combined with > -ffunction-sections should mean that the tests do not pull in symbols > they don't need. So on arm-eabi, libstdc++'s configure correctly detects that -ffunction-sections is supported, and builds with it. However, when running the testsuite, it lacks -Wl,-gc-sections. I checked manually that adding this flag makes the link succeed for the offending testcase I reported in PR #104167. This happens because we are not in a native mode build, so configure.ac does not run GLIBCXX_CHECK_LINKER_FEATURES, and even when running the "cross target environment" part of the configuration, we do not even make use of GLIBCXX_CROSSCONFIG because I configure with --with-newlib. That being said, GLIBCXX_CROSSCONFIG makes use of -Wl,--gc-sections only for *-tpf targets, so even configuring without --with-newlib wouldn't help. Maybe we could call GLIBCXX_CHECK_LINKER_FEATURES only when not in canadian-cross mode?
[Bug target/111237] fp-int-convert-float64x.c fails on x86_64-apple-darwin with "ambiguous instructions require an explicit suffix"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111237 --- Comment #2 from Andrew Pinski --- Or the detection to see if the suffix is not exactly working correctly.
[Bug c/111237] fp-int-convert-float64x.c fails on x86_64-apple-darwin with "ambiguous instructions require an explicit suffix"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111237 --- Comment #1 from Francois-Xavier Coudert --- The failure was not seen on August 9 at https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/793205.html on x86_64-apple-darwin20, so either it is a regression, or the Apple assembler has become more strict between darwin20 and darwin22.
[Bug c/111237] New: fp-int-convert-float64x.c fails on x86_64-apple-darwin with "ambiguous instructions require an explicit suffix"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111237
Bug ID: 111237
Summary: fp-int-convert-float64x.c fails on x86_64-apple-darwin
with "ambiguous instructions require an explicit
suffix"
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
Many of these messages:
/var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccO1vBzR.s:16:2: error:
ambiguous instructions require an explicit suffix (could be 'filds', or
'fildl')
fild-8(%rbp)
^
/var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccO1vBzR.s:19:2: error:
ambiguous instructions require an explicit suffix (could be 'fisttps', or
'fisttpl')
fisttp -8(%rbp)
^
This is on a cross-compiler from aarch64-apple-darwin22 to
x86_64-apple-darwin22, but I think it would be the same on a native compiler.
Short reproducer:
$ cat toto.c
int main(void)
{
unsigned char ivin;
unsigned char ivout;
_Float64x fv1;
_Float64x fv2;
ivin = 0;
fv1 = 0;
fv2 = (_Float64x) ivin;
ivout = (unsigned char) fv1;
}
$ ./bin/x86_64-apple-darwin22-gcc toto.c -c
/var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccn0Y3rC.s:14:2: error:
ambiguous instructions require an explicit suffix (could be 'filds', or
'fildl')
fild-66(%rbp)
^
/var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccn0Y3rC.s:17:2: error:
ambiguous instructions require an explicit suffix (could be 'fisttps', or
'fisttpl')
fisttp -66(%rbp)
^
$ ./bin/x86_64-apple-darwin22-gcc toto.c -S
$ cat toto.s
.text
.globl _main
_main:
LFB0:
pushq %rbp
LCFI0:
movq%rsp, %rbp
LCFI1:
movb$0, -1(%rbp)
fldz
fstpt -32(%rbp)
movzbl -1(%rbp), %eax
movw%ax, -66(%rbp)
fild-66(%rbp)
fstpt -48(%rbp)
fldt-32(%rbp)
fisttp -66(%rbp)
movzwl -66(%rbp), %eax
movb%al, -49(%rbp)
movl$0, %eax
popq%rbp
LCFI2:
ret
LFE0:
.section
__TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
EH_frame1:
.set L$set$0,LECIE1-LSCIE1
.long L$set$0
LSCIE1:
.long 0
.byte 0x1
.ascii "zR\0"
.byte 0x1
.byte 0x78
.byte 0x10
.byte 0x1
.byte 0x10
.byte 0xc
.byte 0x7
.byte 0x8
.byte 0x90
.byte 0x1
.align 3
LECIE1:
LSFDE1:
.set L$set$1,LEFDE1-LASFDE1
.long L$set$1
LASFDE1:
.long LASFDE1-EH_frame1
.quad LFB0-.
.set L$set$2,LFE0-LFB0
.quad L$set$2
.byte 0
.byte 0x4
.set L$set$3,LCFI0-LFB0
.long L$set$3
.byte 0xe
.byte 0x10
.byte 0x86
.byte 0x2
.byte 0x4
.set L$set$4,LCFI1-LCFI0
.long L$set$4
.byte 0xd
.byte 0x6
.byte 0x4
.set L$set$5,LCFI2-LCFI1
.long L$set$5
.byte 0xc
.byte 0x7
.byte 0x8
.align 3
LEFDE1:
.ident "GCC: (GNU) 14.0.0 20230830 (experimental)"
.subsections_via_symbols
For the record, the assembler is called as:
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
-cc1as -triple x86_64-apple-macosx13.0.0 -filetype obj -main-file-name
ccImMDJg.s -target-cpu penryn -fdebug-compilation-dir=/tmp/irun
-dwarf-debug-producer "Apple clang version 14.0.3 (clang-1403.0.22.14.1)"
-dwarf-version=4 -mrelocation-model pic --mrelax-relocations -mllvm
-x86-pad-for-align=false -mllvm -disable-aligned-alloc-awareness=1 -o toto.o
/var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccImMDJg.s
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #55 from Jürgen Reuter --- Actually, according to my testing, the last commit where the gfortran produced failing code, ishttps://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c496d15954cdeab7f9039328f94a6f62cf893d5f (Aldy Hernandez A singleton irange etc.) and the first one working again is https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1f7e5a7b91862b999aab88ee0319052aaf00f0f1 (Vladimir Makarov) that seems to have fixed it. The commit from Vladimir fixed an issue in RTL, but I am not sure what to conclude from this.
[Bug fortran/48776] ICE(segfault) after -std=f95 diagnostic error involving PROCEDURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776 --- Comment #9 from CVS Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:d58150452976c4ca65ddc811fac78ef956fa96b0 commit r14-3572-gd58150452976c4ca65ddc811fac78ef956fa96b0 Author: Mikael Morin Date: Wed Aug 30 14:18:56 2023 +0200 fortran: Restore interface to its previous state on error [PR48776] Keep memory of the content of the current interface body being parsed and restore it to its previous state if it has been modified at the time a parse attempt fails. This fixes memory errors and random segmentation faults caused by dangling symbol pointers kept in interfaces' linked lists of symbols. If a parsing attempt fails and symbols are freed, they should also be removed from the current interface linked list. As the list of symbol is a linked list, and parsing only adds new symbols to the head of the list, all that is needed to track the previous content of the list is a pointer to its previous head. This adds such a pointer, and the restoration of the list of symbols to that pointer on error. PR fortran/48776 gcc/fortran/ChangeLog: * gfortran.h (gfc_drop_interface_elements_before): New prototype. (gfc_current_interface_head): Return a reference to the pointer. * interface.cc (gfc_current_interface_head): Ditto. (free_interface_elements_until): New function, generalizing gfc_free_interface. (gfc_free_interface): Use free_interface_elements_until. (gfc_drop_interface_elements_before): New function. * parse.cc (current_interface_ptr, previous_interface_head): New static variables. (current_interface_valid_p, get_current_interface_ptr): New functions. (decode_statement): Initialize previous_interface_head. (reject_statement): Restore current interface pointer to point to previous_interface_head. gcc/testsuite/ChangeLog: * gfortran.dg/interface_procedure_1.f90: New test.
[Bug testsuite/111228] [14 regression] gcc.target/powerpc/vsx-extract-6.c fails after r14-3381-g27de9aa152141e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111228 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Should be fixed.
[Bug testsuite/111228] [14 regression] gcc.target/powerpc/vsx-extract-6.c fails after r14-3381-g27de9aa152141e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111228 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:caa7a99a052929d5970677c5b639e1fa5166e334 commit r14-3571-gcaa7a99a052929d5970677c5b639e1fa5166e334 Author: Richard Biener Date: Wed Aug 30 11:57:47 2023 +0200 tree-optimization/111228 - combine two VEC_PERM_EXPRs The following adds simplification of two VEC_PERM_EXPRs where the later one replaces all elements from either the first or the second input of the earlier permute. This allows a three input permute to be simplified to a two input one. I'm following the existing two input simplification case and only allow non-VLA permutes. The now existing three cases and the single case in tree-ssa-forwprop.cc somehow ask for merging, I'm not doing this as part of this change though. PR tree-optimization/111228 * match.pd ((vec_perm (vec_perm ..) @5 ..) -> (vec_perm @x @5 ..)): New simplifications. * gcc.dg/tree-ssa/forwprop-42.c: New testcase.
[Bug ada/88610] ICE with new ACATS test c452003
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88610 --- Comment #4 from simon at pushface dot org --- This problem has been fixed for some time now - I think in GCC 11.
[Bug target/106271] Bootstrap on RISC-V on Ubuntu 22.04 LTS: bits/libc-header-start.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106271 --- Comment #7 from Thomas Koenig --- (In reply to Thomas Schwinge from comment #6) > I noticed recent commit r14-3387-g47f95bc4be4eb14730ab3eaaaf8f6e71fda47690 > "RISC-V: Add multiarch support on riscv-linux-gnu" -- but can't tell > off-hand whether that fixed all the issues here? As soon as gcc92 is back up, we can test... https://lists.tetaneutral.net/pipermail/cfarm-users/2023-August/000975.html
[Bug tree-optimization/111015] [11/12/13/14 Regression] __int128 bitfields optimized incorrectly to the 64 bit operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111015 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/110914] [11/12/13/14 Regression] Optimization eliminating necessary assignment before 0-byte memcpy since r10-5451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110914 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/110914] [11/12/13/14 Regression] Optimization eliminating necessary assignment before 0-byte memcpy since r10-5451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110914
--- Comment #8 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:cf3aa538317d6c525739f339b79010ae82dc20f5
commit r11-10969-gcf3aa538317d6c525739f339b79010ae82dc20f5
Author: Jakub Jelinek
Date: Wed Aug 30 11:21:45 2023 +0200
tree-ssa-strlen: Fix up handling of conditionally zero memcpy [PR110914]
The following testcase is miscompiled since r279392 aka
r10-5451-gef29b12cfbb4979
The strlen pass has adjust_last_stmt function, which performs mainly strcat
or strcat-like optimizations (say strcpy (x, "abcd"); strcat (x, p);
or equivalent memcpy (x, "abcd", strlen ("abcd") + 1); char *q = strchr (x,
0);
memcpy (x, p, strlen (p)); etc. where the first stmt stores '\0' character
at the end but next immediately overwrites it and so the first memcpy can
be
adjusted to store 1 fewer bytes. handle_builtin_memcpy called this
function
in two spots, the first one guarded like:
if (olddsi != NULL
&& tree_fits_uhwi_p (len)
&& !integer_zerop (len))
adjust_last_stmt (olddsi, stmt, false);
i.e. only for constant non-zero length. The other spot can call it even
for non-constant length but in that case we punt before that if that length
isn't length of some string + 1, so again non-zero.
The r279392 change I assume wanted to add some warning stuff and changed it
like
if (olddsi != NULL
- && tree_fits_uhwi_p (len)
&& !integer_zerop (len))
-adjust_last_stmt (olddsi, stmt, false);
+{
+ maybe_warn_overflow (stmt, len, rvals, olddsi, false, true);
+ adjust_last_stmt (olddsi, stmt, false);
+}
While maybe_warn_overflow possibly handles non-constant length fine,
adjust_last_stmt really relies on length to be non-zero, which
!integer_zerop (len) alone doesn't guarantee. While we could for
len being SSA_NAME ask the ranger or tree_expr_nonzero_p, I think
adjust_last_stmt will not benefit from it much, so the following patch
just restores the above condition/previous behavior for the
adjust_last_stmt
call only.
2023-08-30 Jakub Jelinek
PR tree-optimization/110914
* tree-ssa-strlen.c (strlen_pass::handle_builtin_memcpy): Don't
call
adjust_last_stmt unless len is known constant.
* gcc.c-torture/execute/pr110914.c: New test.
(cherry picked from commit 398842e7038ea0f34054f0f694014d0ecd656846)
[Bug tree-optimization/111015] [11/12/13/14 Regression] __int128 bitfields optimized incorrectly to the 64 bit operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111015 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:beabb96786e4b3e1a820e400c09b1c1c9ab06287 commit r11-10968-gbeabb96786e4b3e1a820e400c09b1c1c9ab06287 Author: Jakub Jelinek Date: Wed Aug 30 10:47:21 2023 +0200 store-merging: Fix up >= 64 bit insertion [PR111015] The following testcase shows that we mishandle bit insertion for info->bitsize >= 64. The problem is in using unsigned HOST_WIDE_INT shift + subtraction + build_int_cst to compute mask, the shift invokes UB at compile time for info->bitsize 64 and larger and e.g. on the testcase with info->bitsize happens to compute mask of 0x3f rather than 0x3f''. The patch fixes that by using wide_int wi::mask + wide_int_to_tree, so it handles masks in any precision (up to WIDE_INT_MAX_PRECISION ;) ). 2023-08-30 Jakub Jelinek PR tree-optimization/111015 * gimple-ssa-store-merging.c (imm_store_chain_info::output_merged_store): Use wi::mask and wide_int_to_tree instead of unsigned HOST_WIDE_INT shift and build_int_cst to build BIT_AND_EXPR mask. * gcc.dg/pr111015.c: New test. (cherry picked from commit 49a3b35c4068091900b657cd36e5cffd41ef0c47)
[Bug target/111236] New: ICE in in extract_insn, at recog.cc:2791 on s390x with -Og -march=z13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111236 Bug ID: 111236 Summary: ICE in in extract_insn, at recog.cc:2791 on s390x with -Og -march=z13 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: fkastl at suse dot cz Target Milestone: --- Host: x86_64-linux Target: s390x-linux-gnu With a cross compiler (revision 85ad41a494e) configured with: /home/worker/buildworker/tiber-gcc-trunk-s390x/build/configure --enable-languages=c,c++,fortran,rust,m2 --disable-bootstrap --disable-libsanitizer --disable-multilib --enable-checking=release --prefix=/home/worker/cross --target=s390x-linux-gnu --with-as=/usr/bin/s390x-suse-linux-as On the GCC testcase gcc/testsuite/gcc.dg/analyzer/torture/pr59037.c Running it with: ~/cross/bin/s390x-linux-gnu-gcc /home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/analyzer/torture/pr59037.c -Og -march=z13 Results in: In file included from /home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/analyzer/torture/pr59037.c:1: /home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/analyzer/torture/../../../c-c++-common/pr59037.c: In function ‘main’: /home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/analyzer/torture/../../../c-c++-common/pr59037.c:12:1: error: unrecognizable insn: 12 | } | ^ (insn 9 8 10 2 (set (reg:SI 60 [ _4 ]) (vec_select:SI (reg/v:V4SI 62 [ x ]) (parallel [ (const_int 4 [0x4]) ]))) "/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/analyzer/torture/../../../c-c++-common/pr59037.c":11:11 -1 (nil)) during RTL pass: vregs /home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/analyzer/torture/../../../c-c++-common/pr59037.c:12:1: internal compiler error: in extract_insn, at recog.cc:2791 0x626590 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/rtl-error.cc:108 0x6265ac _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/rtl-error.cc:116 0x6259e2 extract_insn(rtx_insn*) /home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/recog.cc:2791 0x8d5f30 instantiate_virtual_regs_in_insn /home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/function.cc:1610 0x8d5f30 instantiate_virtual_regs /home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/function.cc:1983 0x8d5f30 execute /home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/function.cc:2030
[Bug tree-optimization/110914] [11/12/13/14 Regression] Optimization eliminating necessary assignment before 0-byte memcpy since r10-5451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110914
--- Comment #7 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:487390818c6b10daa29dd1db205fa8566296c084
commit r12-9837-g487390818c6b10daa29dd1db205fa8566296c084
Author: Jakub Jelinek
Date: Wed Aug 30 11:21:45 2023 +0200
tree-ssa-strlen: Fix up handling of conditionally zero memcpy [PR110914]
The following testcase is miscompiled since r279392 aka
r10-5451-gef29b12cfbb4979
The strlen pass has adjust_last_stmt function, which performs mainly strcat
or strcat-like optimizations (say strcpy (x, "abcd"); strcat (x, p);
or equivalent memcpy (x, "abcd", strlen ("abcd") + 1); char *q = strchr (x,
0);
memcpy (x, p, strlen (p)); etc. where the first stmt stores '\0' character
at the end but next immediately overwrites it and so the first memcpy can
be
adjusted to store 1 fewer bytes. handle_builtin_memcpy called this
function
in two spots, the first one guarded like:
if (olddsi != NULL
&& tree_fits_uhwi_p (len)
&& !integer_zerop (len))
adjust_last_stmt (olddsi, stmt, false);
i.e. only for constant non-zero length. The other spot can call it even
for non-constant length but in that case we punt before that if that length
isn't length of some string + 1, so again non-zero.
The r279392 change I assume wanted to add some warning stuff and changed it
like
if (olddsi != NULL
- && tree_fits_uhwi_p (len)
&& !integer_zerop (len))
-adjust_last_stmt (olddsi, stmt, false);
+{
+ maybe_warn_overflow (stmt, len, rvals, olddsi, false, true);
+ adjust_last_stmt (olddsi, stmt, false);
+}
While maybe_warn_overflow possibly handles non-constant length fine,
adjust_last_stmt really relies on length to be non-zero, which
!integer_zerop (len) alone doesn't guarantee. While we could for
len being SSA_NAME ask the ranger or tree_expr_nonzero_p, I think
adjust_last_stmt will not benefit from it much, so the following patch
just restores the above condition/previous behavior for the
adjust_last_stmt
call only.
2023-08-30 Jakub Jelinek
PR tree-optimization/110914
* tree-ssa-strlen.cc (strlen_pass::handle_builtin_memcpy): Don't
call
adjust_last_stmt unless len is known constant.
* gcc.c-torture/execute/pr110914.c: New test.
(cherry picked from commit 398842e7038ea0f34054f0f694014d0ecd656846)
[Bug tree-optimization/111015] [11/12/13/14 Regression] __int128 bitfields optimized incorrectly to the 64 bit operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111015 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d04993b217f42b8e60b7a6d66647966b1e41302d commit r12-9836-gd04993b217f42b8e60b7a6d66647966b1e41302d Author: Jakub Jelinek Date: Wed Aug 30 10:47:21 2023 +0200 store-merging: Fix up >= 64 bit insertion [PR111015] The following testcase shows that we mishandle bit insertion for info->bitsize >= 64. The problem is in using unsigned HOST_WIDE_INT shift + subtraction + build_int_cst to compute mask, the shift invokes UB at compile time for info->bitsize 64 and larger and e.g. on the testcase with info->bitsize happens to compute mask of 0x3f rather than 0x3f''. The patch fixes that by using wide_int wi::mask + wide_int_to_tree, so it handles masks in any precision (up to WIDE_INT_MAX_PRECISION ;) ). 2023-08-30 Jakub Jelinek PR tree-optimization/111015 * gimple-ssa-store-merging.cc (imm_store_chain_info::output_merged_store): Use wi::mask and wide_int_to_tree instead of unsigned HOST_WIDE_INT shift and build_int_cst to build BIT_AND_EXPR mask. * gcc.dg/pr111015.c: New test. (cherry picked from commit 49a3b35c4068091900b657cd36e5cffd41ef0c47)
