[Bug c/109352] New: Feature request: warn about "u64 = u32 * u32" and similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109352
Bug ID: 109352
Summary: Feature request: warn about "u64 = u32 * u32" and
similar
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhangboyang.id at gmail dot com
Target Milestone: ---
Hi,
Please consider give warnings about "u64 = u32 * u32" and similar statements.
In most cases, programmers want "u64 = (uint64_t) u32 * (uint64_t) u32" instead
of "u64 = (uint32_t) u32 * (uint32_t) u32".
This cause real world problems. In a security bug of GNU GRUB2 (CVE-2022-2601,
reported by me), a similar expression causes interger overflow therefore heap
overwrite. The simplified code is like below:
struct bitmap {
uint32_t width, height;
uint8_t pixel[];
};
bmp = malloc(sizeof(struct bitmap) + width * height / 8);
In the above example, if width==65536 and height==65536, then width*height will
overflow to 0. Thus the allocated memory is smaller than expected.
I'm not a compiler expert, so I can't give a precise definition of which
statements should be warned. But I come up with some example code, please see
below:
1)
uint64_t pow2(int n)
{
return 1 << n; // I think almost everyone was hit by this :)
return 1U << n; // or this
}
2)
double area(float b, float h)
{
return b * h / 2.0; // lose precision
}
3)
uint64_t add(uint64_t base, uint32_t a, uint32_t b)
{
return base + (a + b); // it's different from "base + a + b"
}
By the way, if a programmer think a warning is unnecessary, it should be able
to suppressed by "u64 = (uint32_t)(u32 * u32);"
Zhang Boyang
[Bug fortran/101047] Pointer explicit initialization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101047 Paul Thomas changed: What|Removed |Added Last reconfirmed||2023-03-31 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||pault at gcc dot gnu.org --- Comment #4 from Paul Thomas --- (In reply to Jerry DeLisle from comment #3) > Did we let this fall in a crack or was there some other holdup? I cannot speak for anybody else but it came up during my long break from gfortran support and so I certainly missed it. I feel that this is sufficiently obtrusive that it will have to wait for 14.0.0 to open. That said, I have put it on my TODO list to review. I discovered that pointer initialization is an issue just yesterday after taking a peek at recent posts by Peter Klausler on clf. Paul
[Bug c/109352] Feature request: warn about "u64 = u32 * u32" and similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109352 --- Comment #1 from Andrew Pinski --- "similar expression causes interger overflow ". No it causes wrapping.
[Bug c/24542] potential integer overflow should be warned on assignment to wider variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24542 Andrew Pinski changed: What|Removed |Added CC||zhangboyang.id at gmail dot com --- Comment #11 from Andrew Pinski --- *** Bug 109352 has been marked as a duplicate of this bug. ***
[Bug c/109352] Feature request: warn about "u64 = u32 * u32" and similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109352 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup. We rejected implementing this back in 2006. The code has a well defined behavior and the warning will most likely find way too many false positives. *** This bug has been marked as a duplicate of bug 24542 ***
[Bug tree-optimization/109350] FAIL: g++.dg/warn/Wstringop-overflow-4.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109350
Richard Biener changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment #2 from Richard Biener ---
Hmm, the same reproduces with r_imin_imax as ptrdiff_t but the IL is a bit
more obvious:
[local count: 1073741824]:
_27 ={v} signed_value_source;
_4 = (unsigned long) _27;
_8 = _4 + 2147483648;
if (_8 > 4294967295)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
_30 = _27 + 1;
_28 = (sizetype) _30;
if (_4 <= 4611686018427387900)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 268435458]:
_12 = operator new [] (18446744073709551615);
__builtin_memcpy (_12, &MEM [(void
*)"0123456789abcdefghijklmnopqrstuvwxyz" + 35B], 2);
sink (_12);
if (_28 <= 4611686018427387900)
goto ; [100.00%]
else
goto ; [0.00%]
[local count: 0]:
iftmp.2_37 = _28 * 2;
_39 = operator new [] (iftmp.2_37);
__builtin_memcpy (_39, &MEM [(void
*)"0123456789abcdefghijklmnopqrstuvwxyz" + 34B], 3);
so we have (unsigned long)[int_min, int_max] > 4611686018427387900
&& (unsigned long)[int_min+1, int_max+1] <= 4611686018427387900 to
constrain _4. I don't see how we can arrive at [0,0] for iftmp.2_37.
In fact if I put this into a separate testcase like
void __attribute__((noipa))
foo (long signed_value_source)
{
unsigned long temu = signed_value_source;
if (temu + 2147483648 > 4294967295)
;
else
{
long tems = signed_value_source + 1;
unsigned long temu2 = tems;
if (temu > 4611686018427387900)
if (temu2 <= 4611686018427387900)
{
unsigned long iftmp = temu2 * 2;
if (iftmp == 0)
__builtin_abort ();
}
}
}
then we optimize this to
[local count: 1073741824]:
temu_3 = (long unsigned int) signed_value_source_2(D);
_1 = temu_3 + 2147483648;
if (_1 > 4294967295)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
if (signed_value_source_2(D) == -1)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin_abort ();
and the outer if doesn't change the inner range result.
[Bug target/109328] [13 Regression] Build fail in RISC-V port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109328 --- Comment #6 from CVS Commits --- The master branch has been updated by Kito Cheng : https://gcc.gnu.org/g:608388486a54afe98aed0f105a6101ae7a9ff66c commit r13-6954-g608388486a54afe98aed0f105a6101ae7a9ff66c Author: Kito Cheng Date: Fri Mar 31 14:40:36 2023 +0800 RISC-V: Fix missing file dependency in RISC-V back-end [PR109328] gcc/ChangeLog: PR target/109328 * config/riscv/t-riscv: Add missing dependencies. Co-authored-by: Andrew Pinski
[Bug tree-optimization/109029] __builtin_signbit for 64bit fp does not vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109029 --- Comment #9 from Hongtao.liu --- (In reply to Hongtao.liu from comment #8) > > > > One solution is handling it in ix86_builtin_vectorized_function just like > > other math functions which has different input/output sizes. > > Or extend vectorizable_call to handle NARROW/WIDEN cases when output of ifn > is same-sized vector integer of vectype_in, and do NARROW/WIDEN between > ifn_output and vectype_out. > > 3472 /* For now, we only vectorize functions if a target specific builtin > 3473 is available. TODO -- in some cases, it might be profitable to > 3474 insert the calls for pieces of the vector, in order to be able > 3475 to vectorize other operations in the loop. */ > 3476 fndecl = NULL_TREE; > 3477 internal_fn ifn = IFN_LAST; > 3478 tree callee = gimple_call_fndecl (stmt); > 3479 > 3480 /* First try using an internal function. */ > 3481 tree_code convert_code = ERROR_MARK; Another alternative it's we can recognize signbit as shift in the vectorizer.
[Bug target/109328] [13 Regression] Build fail in RISC-V port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109328 Kito Cheng changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Kito Cheng --- Verified with crosstool-ng, also fixed several missing dependency in t-riscv
[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 --- Comment #23 from rguenther at suse dot de --- On Thu, 30 Mar 2023, hubicka at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 > > --- Comment #21 from Jan Hubicka --- > Zen 1-3 changes were intentional in the original tuning patch (it is also > briefly mentioned in the commit message). By allowing 256 bit AVX moves > instead of 64bit integer moves (or 128bit) we can move bigger blocks of memory > without loops and it was faster in micro-benchmarks I made on all zens, even > on > znver1. > We also automatically go for 128bit moves when ISA allows that. Sure, but this change is IMHO surprising for people on the branch so I'd rather not do this.
[Bug target/85048] [missed optimization] vector conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85048
--- Comment #12 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #9)
> With the patch, we can generate optimized code expect for those 16 {u,}qq
> cases, since the ABI doesn't support 1024-bit vector.
Can't these be vectorized using partial vectors? GCC generates:
_Z9vcvtqq2psDv16_l:
vmovq 56(%rsp), %xmm0
vmovq 40(%rsp), %xmm1
vmovq 88(%rsp), %xmm2
vmovq 120(%rsp), %xmm3
vpinsrq $1, 64(%rsp), %xmm0, %xmm0
vpinsrq $1, 48(%rsp), %xmm1, %xmm1
vpinsrq $1, 96(%rsp), %xmm2, %xmm2
vpinsrq $1, 128(%rsp), %xmm3, %xmm3
vinserti128 $0x1, %xmm0, %ymm1, %ymm1
vcvtqq2psy 8(%rsp), %xmm0
vcvtqq2psy %ymm1, %xmm1
vinsertf128 $0x1, %xmm1, %ymm0, %ymm0
vmovq 72(%rsp), %xmm1
vpinsrq $1, 80(%rsp), %xmm1, %xmm1
vinserti128 $0x1, %xmm2, %ymm1, %ymm1
vmovq 104(%rsp), %xmm2
vcvtqq2psy %ymm1, %xmm1
vpinsrq $1, 112(%rsp), %xmm2, %xmm2
vinserti128 $0x1, %xmm3, %ymm2, %ymm2
vcvtqq2psy %ymm2, %xmm2
vinsertf128 $0x1, %xmm2, %ymm1, %ymm1
vinsertf64x4$0x1, %ymm1, %zmm0, %zmm0
where clang manages to vectorize the function to:
vcvtqq2ps 16(%rbp), %ymm0
vcvtqq2ps 80(%rbp), %ymm1
vinsertf64x4 $1, %ymm1, %zmm0, %zmm0
[Bug tree-optimization/109353] New: FAIL: 23_containers/vector/bool/allocator/copy.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109353 Bug ID: 109353 Summary: FAIL: 23_containers/vector/bool/allocator/copy.cc (test for excess errors) Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- After the last ranger changes this test now FAILs with In file included from /home/rguenther/obj-trunk-g/x86_64-pc-linux-gnu/libstdc++-v3/include/vector:62, from /home/rguenther/src/trunk/libstdc++-v3/testsuite/23_containers/vector/bool/allocator/copy.cc:20: In static member function 'static _Up* std::__copy_move<_IsMove, true, std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp = long unsigned int; _Up = long unsigned int; bool _IsMove = false]', inlined from '_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove = false; _II = long unsigned int*; _OI = long unsigned int*]' at /home/rguenther/obj-trunk-g/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:506, inlined from '_OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove = false; _II = long unsigned int*; _OI = long unsigned int*]' at /home/rguenther/obj-trunk-g/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:533, inlined from '_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove = false; _II = long unsigned int*; _OI = long unsigned int*]' at /home/rguenther/obj-trunk-g/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:540, inlined from '_OI std::copy(_II, _II, _OI) [with _II = long unsigned int*; _OI = long unsigned int*]' at /home/rguenther/obj-trunk-g/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:633, inlined from 'std::vector::iterator std::vector::_M_copy_aligned(const_iterator, const_iterator, iterator) [with _Alloc = __gnu_test::propagating_allocator]' at /home/rguenther/obj-trunk-g/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_bvector.h:1303, inlined from 'void std::vector::_M_insert_aux(iterator, bool) [with _Alloc = __gnu_test::propagating_allocator]' at /home/rguenther/obj-trunk-g/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/vector.tcc:945, inlined from 'void std::vector::push_back(bool) [with _Alloc = __gnu_test::propagating_allocator]' at /home/rguenther/obj-trunk-g/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_bvector.h:1121, inlined from 'void test01()' at /home/rguenther/src/trunk/libstdc++-v3/testsuite/23_containers/vector/bool/allocator/copy.cc:33: /home/rguenther/obj-trunk-g/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:437: warning: 'void* __builtin_memmove(void*, const void*, long unsigned int)' writing between 9 and 9223372036854775807 bytes into a region of size 8 overflows the destination [-Wstringop-overflow=] In file included from /home/rguenther/obj-trunk-g/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/c++allocator.h:33, from /home/rguenther/obj-trunk-g/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/allocator.h:46, from /home/rguenther/obj-trunk-g/x86_64-pc-linux-gnu/libstdc++-v3/include/vector:63: In member function '_Tp* std::__new_allocator<_Tp>::allocate(size_type, const void*) [with _Tp = long unsigned int]', inlined from 'static _Tp* std::allocator_traits >::allocate(allocator_type&, size_type) [with _Tp = long unsigned int]' at /home/rguenther/obj-trunk-g/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/alloc_traits.h:482, inlined from '__gnu_test::uneq_allocator::pointer __gnu_test::uneq_allocator::allocate(size_type, const void*) [with Tp = long unsigned int; Alloc = std::allocator]' at /home/rguenther/src/trunk/libstdc++-v3/testsuite/util/testsuite_allocator.h:360, inlined from 'static std::allocator_traits< >::pointer std::allocator_traits< >::allocate(_Alloc&, size_type) [with _Alloc = __gnu_test::propagating_allocator >]' at /home/rguenther/obj-trunk-g/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/alloc_traits.h:333, inlined from 'std::_Bvector_base<_Alloc>::_Bit_pointer std::_Bvector_base<_Alloc>::_M_allocate(std::size_t) [with _Alloc = __gnu_test::propagating_allocator]' at /home/rguenther/obj-trunk-g/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_bvector.h:643, inlined from 'void std::vector::_M_insert_aux(iterator, bool) [with _Alloc = __gnu_test::propagating_allocator]' at /home/rguenther/obj-trunk-g/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/vector.tcc:943, inlined from 'void std::vector::push_back(bool) [with _Alloc = __gnu_test::propagating_allocator]' at /home/rguenther/obj-trunk-g/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_bvector.h:1121, inlined from 'void test01()' at /home/rguenther/src/trunk/libstdc++-v3/testsuite/23_containers/vector/bool/allocator/copy.cc:33: /home/rguenther/
[Bug rtl-optimization/109351] RA uses lowest cost for the mode of different reg_classes w/o considering hard_regno_mode_ok.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109351 Uroš Bizjak changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #1 from Uroš Bizjak --- Cc added.
[Bug tree-optimization/109353] FAIL: 23_containers/vector/bool/allocator/copy.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109353
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords||missed-optimization
CC||jwakely.gcc at gmail dot com
Last reconfirmed||2023-03-31
Status|UNCONFIRMED |NEW
--- Comment #1 from Richard Biener ---
[local count: 86938296]:
D.70713 ={v} {CLOBBER(eol)};
_74 = v1.D.60930._M_impl.D.60395._M_start.D.16824._M_p;
_638 = (long int) _74;
_261 = -_638;
_383 = (long unsigned int) _261;
if (_638 < -8)
goto ; [90.00%]
else
goto ; [10.00%]
[local count: 78244465]:
__builtin_memmove (_216, _74, _383);
so _383 is > 8, the reported access size looks good here. We determine
the destination size as 8 which is also good since
_216 = operator new (8);
so the diagnostic seems legit. The alternative code taken isn't very much
better:
[local count: 8693830]:
if (_74 == -8B)
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 2955901]:
_266 = MEM[(long unsigned int *)-8B];
*_216 = _266;
[local count: 86938296]:
_268 = _216 + _383;
_324 = MEM[(_Bit_type *)_268];
_327 = _324 & 18446744073709551614;
so definitely bb13 looks to be better unreachable as well.
I have difficulties in tracing libstdc++ back to the ultimate caller but
the above control flow is from stl_algobase.h:435 which is
template
struct __copy_move<_IsMove, true, random_access_iterator_tag>
{
template
_GLIBCXX20_CONSTEXPR
static _Up*
__copy_m(_Tp* __first, _Tp* __last, _Up* __result)
{
const ptrdiff_t _Num = __last - __first;
if (__builtin_expect(_Num > 1, true))
__builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
else if (_Num == 1)
std::__copy_move<_IsMove, false, random_access_iterator_tag>::
__assign_one(__result, __first);
return __result + _Num;
}
};
but the assign-one seems to be odd. So I suppose this all happens before
v1.push_back(T());
and thus _Num == 0.
v1.D.60930._M_impl.D.60395._M_start.D.16824._M_p is probably NULL at this
point but 'v1' escapes to _M_deallocate so the intervening
operator new calls and an __atomic_load_1 / __cxa_guard_acquire prevent
CSE of this value.
It might be possible (again) to CSE this manually in libstdc++ to help
code generation.
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #32 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #31 from Jakub Jelinek --- > If the important side-effect is allocation of some GC memory, then perhaps > (assuming you also see just 5 initialize_cfun calls with 2xint, TFmode float, > uint and bool) testing hack might be: I haven't verified this yet. > --- a/gcc/tree-inline.cc > +++ b/gcc/tree-inline.cc > @@ -2787,6 +2787,8 @@ initialize_cfun (tree new_fndecl, tree callee_fndecl, > profile_count count) >/* Get clean struct function. */ >push_struct_function (new_fndecl, true); >targetm.target_option.relayout_function (new_fndecl); > + if (INTEGRAL_TYPE_P (TREE_TYPE (DECL_RESULT (new_fndecl > +gen_raw_REG (GET_MODE (TYPE_MODE (DECL_RESULT (new_fndecl))), 8); > >/* We will rebuild these, so just sanity check that they are empty. */ >gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL); This doesn't compile as is: In file included from /var/gcc/reghunt/master/gcc/tree-inline.cc:26: /var/gcc/reghunt/master/gcc/tree-inline.cc: In function ‘void initialize_cfun(tree, tree, profile_count)’: /var/gcc/reghunt/master/gcc/rtl.h:728:54: error: base operand of ‘->’ is not a pointer 728 | #define GET_MODE(RTX) ((machine_mode) (RTX)->mode) | ^~ /var/gcc/reghunt/master/gcc/tree-inline.cc:2791:18: note: in expansion of macro ‘GET_MODE’ 2791 | gen_raw_REG (GET_MODE (TYPE_MODE (DECL_RESULT (new_fndecl))), 8); | ^~~~
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #33 from Jakub Jelinek --- Oops, sorry. gen_raw_REG (TYPE_MODE (DECL_RESULT (new_fndecl)), 8);
[Bug tree-optimization/109353] FAIL: 23_containers/vector/bool/allocator/copy.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109353
--- Comment #2 from Richard Biener ---
So it seems to be
_M_insert_aux(iterator __position, bool __x)
{
if (this->_M_impl._M_finish._M_p != this->_M_impl._M_end_addr())
{
std::copy_backward(__position, this->_M_impl._M_finish,
this->_M_impl._M_finish + 1);
*__position = __x;
++this->_M_impl._M_finish;
}
else
{
const size_type __len =
_M_check_len(size_type(1), "vector::_M_insert_aux");
_Bit_pointer __q = this->_M_allocate(__len);
iterator __start(std::__addressof(*__q), 0);
iterator __i = _M_copy_aligned(begin(), __position, __start); // <--
*__i++ = __x;
where the compiler fails to optimize the case of no existing allocation.
Since that's from the push_back () itself no caching of the null start
in libstdc++ is possible.
Disabling early threading avoids the diagnostic because we then inline
very differently, not exposing most of the above.
[Bug tree-optimization/109353] FAIL: 23_containers/vector/bool/allocator/copy.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109353 --- Comment #3 from Richard Biener --- So if it's possible to refactor things as to key the copy size dispatching on the destination size (that seems to be known here) rather than the source that might help (unless we then diagnose overread from the source in other cases ...)
[Bug c/24542] potential integer overflow should be warned on assignment to wider variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24542 --- Comment #12 from Zhang Boyang --- Hi, Sorry for filled a duplicate bug. But I'd like to suggest reconsider this feature request. Here are two reasons: 1) "u64 = 1 << u32", "u64 = u32 * u32" are common mistakes in beginners, 2) These expressions may introduce vulnerability especially on now-widely-used 64-bit machines: On a typical 64-bit machine, it's ok to write: unsigned x = ...; malloc(sizeof(...) + x) but it will introduce vulnerability with a trivial change of "*2", i.e.: malloc(sizeof(...) + x * 2) If expression is very long, it's very hard to find out where is the bug. Instead of warn on multiplys, I suggest a new "-Wexpr-conversion", it will detect and warn on implicit conversions if and only if: 1) convert to wider variable, and 2) value is real expression (i.e. result of operands, like a*b; but not variable or function call or explicit cast) For example, it should warn on: uint64_t u64 = ...; uint32_t u32 = ...; u64 = 1 << u32; // // suggests "u64 = (uint64_t)1 << (uint64_t)u32" // suppressed by "u64 = (uint32_t)(1 << u32)" But not on: u64 = u32; u64 = (u32)(...); u64 = f(...); This might be a kind of noisy warning like "-Wconversion" but I believe it will help some people (we can just disable it by default). Zhang Boyang
[Bug debug/109354] New: [arm32] Parameter stored on stack gets wrong debug info with -Og or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109354
Bug ID: 109354
Summary: [arm32] Parameter stored on stack gets wrong debug
info with -Og or higher
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
Hi,
this small testcase
class c1
{
struct s1
{
unsigned int m_n1;
};
struct s2
{
s1 sM1;
s1 sM2;
};
s2 m_s2;
int m_bsoM1;
int m_bsoM2;
struct OnOffP {
unsigned int count;
int so;
s1 *ts;
};
void OnI(struct OnOffP *p);
void OffI(struct OnOffP *p);
virtual void OnOff(unsigned int nCount, bool bOff, bool bM1);
};
void c1::OnOff(unsigned int nCount, bool bOff, bool bM1)
{
struct OnOffP eOffP;
// 2 variables only added to better show the behaviour
volatile int xxx = 0xaa00aa;
volatile int xyz = 0xab00ab;
eOffP.count = nCount;
eOffP.so = m_bsoM2;
eOffP.ts = &(m_s2.sM2);
if (bM1) {
eOffP.so = m_bsoM1;
eOffP.ts = &(m_s2.sM1);
}
if (!bOff)
OnI(&eOffP);
else
OffI(&eOffP);
xxx++;
xyz++;
}
compiled with "arm-none-eabi-g++-13 -c -mcpu=cortex-r5 -mfpu=vfpv3-d16
-mfloat-abi=hard -fno-exceptions -g -Og" generates wrong debug info for the
nCount parameter.
llvm-dwarfdump-16.0.0 --name nCount --name eOffP -name xyz
arm-debug-info-bug1.o shows:
arm-debug-info-bug1.o: file format elf32-littlearm
0x01c5: DW_TAG_formal_parameter
DW_AT_name("nCount")
DW_AT_decl_file ("arm-debug-info-bug1.cpp")
DW_AT_decl_line (31)
DW_AT_decl_column (0x1d)
DW_AT_type(0x002c "unsigned int")
DW_AT_location(0x005c:
[0x, 0x0028): DW_OP_reg1 R1
[0x0028, 0x0054): DW_OP_fbreg -28
[0x0054, 0x0057): DW_OP_breg1 R1+0
[0x0057, 0x0078): DW_OP_GNU_entry_value( f5 01 25 f7 2c f7 00 9f
[0x0078, 0x007c): DW_OP_fbreg -28
[0x007c, 0x007f): DW_OP_breg1 R1+0
[0x007f, 0x0084): DW_OP_GNU_entry_value( f5 01 25 f7 2c f7 00 9f)
DW_AT_GNU_locviews(0x004e)
0x0201: DW_TAG_variable
DW_AT_name("eOffP")
DW_AT_decl_file ("arm-debug-info-bug1.cpp")
DW_AT_decl_line (33)
DW_AT_decl_column (0x10)
DW_AT_type(0x008b "c1::OnOffP")
DW_AT_location(DW_OP_fbreg -20)
0x021f: DW_TAG_variable
DW_AT_name("xyz")
DW_AT_decl_file ("arm-debug-info-bug1.cpp")
DW_AT_decl_line (35)
DW_AT_decl_column (0x0f)
DW_AT_type(0x0163 "volatile int")
DW_AT_location(DW_OP_fbreg -28)
So according to this the debug info says that "nCount" (DW_OP_fbreg -28)
overlaps with "xyz" (DW_OP_fbreg -28), when in fact it overlaps with
"eOffP.count" (DW_OP_fbreg -20).
It's unclear if this is caused by wrong debug info generation, wrong lifetime
or both. When we see cases like this, a common point seems to be that the
offset difference is always 8 (-20 vs -28).
The bug seems to be long-standing though, we saw it with 10.4.0, 12.2.1 and
13.0.1 so far.
[Bug middle-end/109128] [Offload][OpenMP][OpenACC] Static linking with unused offload function will lead to mismatch number of offload fn/symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109128 Thomas Schwinge changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Thomas Schwinge --- I'm very likely missing some crucial "minor detail" here: (In reply to Tobias Burnus from comment #3) > My initial thought was to handle it via lto1. This works well if all > relevant files are compiled with "-flto" as then the callers of the offload > functions, the offload functions themselves are available, permitting to > generate __OFFLOAD_TABLE__ directly. I don't understand why '-flto', that is, why looking at *LTO data*. My idea had been that we'd have a mode for host-side 'lto1' where it reads the *offloading data*. (I'd, by the way think, that having a separate 'offload1' instead of piggy-backing offloading handling on 'lto1' might be clearer generally -- especially once we get to actual offloading-LTO?) > However, if -flto is not used or not used for all translation units (with > offload code), this approach will fail due to visibility problems. > > Namely, the offload functions have local binding. This could be solved by > forcing global binding (with visibility hidden), but this approach will fail > if the assembler name is not unique. That is, my understanding was that the *offloading data* contains all the information that we need?
[Bug ipa/109303] [13 Regression] ICE in push_agg_values_from_plats, at ipa-cp.cc:1458 since r13-3358-ge0403e95689af7d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303 --- Comment #9 from Martin Jambor --- I have proposed the fix on the mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614943.html
[Bug c/24542] potential unwanted truncation of operation overflow should be warned on assignment to wider variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24542 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-03-31 Status|RESOLVED|NEW Resolution|WONTFIX |--- Summary|potential integer overflow |potential unwanted |should be warned on |truncation of operation |assignment to wider |overflow should be warned |variable|on assignment to wider ||variable Ever confirmed|0 |1 --- Comment #13 from Richard Biener --- Let me re-open this. I agree that it sounds useful to have a diagnostic that would catch these cases but I also think it might have many false positives. But that's similar to diagnosing if (a || b && c). That said, the burden is on whoever is going to prototype patch with extensive enough test coverage. The question is whether to diagnose int x1, x2; long y1; y1 = x1 * x2; since when x1 * x2 overflows that even invokes undefined behavior (so it's even worse than the unsigned case). The description is misleading, there's no "overflow on assignment" but the operation itself might overflow and the truncated value is then widened on assignment. The assignment is a mere hint that a wider result might have been intended (and a good enough hint IMHO).
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #34 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #33 from Jakub Jelinek --- > Oops, sorry. > gen_raw_REG (TYPE_MODE (DECL_RESULT (new_fndecl)), 8); While this compiles, I run into during IPA pass: inline In function ‘gcov_topn_add_value.constprop’: cc1: internal compiler error: tree check: expected class ‘type’, have ‘declaration’ (result_decl) in initialize_cfun, at tree-inline.cc:2791 0x1f6fc8f tree_class_check_failed(tree_node const*, tree_code_class, char const*, int, char const*) /var/gcc/reghunt/master/gcc/tree.cc:8931 0xd8af2b tree_class_check(tree_node*, tree_code_class, char const*, int, char const*) /var/gcc/reghunt/master/gcc/tree.h:3663 0x1b601a3 initialize_cfun /var/gcc/reghunt/master/gcc/tree-inline.cc:2791 0x1b6df53 tree_function_versioning(tree_node*, tree_node*, vec*, ipa_param_adjustments*, bool, bitmap_head*, basic_block_def*) /var/gcc/reghunt/master/gcc/tree-inline.cc:6239 0x115d2d3 cgraph_node::materialize_clone() /var/gcc/reghunt/master/gcc/cgraphclones.cc:1156 0x1140993 cgraph_node::get_untransformed_body() /var/gcc/reghunt/master/gcc/cgraph.cc:3995 0x15debaf maybe_materialize_called_clones /var/gcc/reghunt/master/gcc/ipa-inline-transform.cc:720 0x15def5b inline_transform(cgraph_node*) /var/gcc/reghunt/master/gcc/ipa-inline-transform.cc:777 0x189818f execute_one_ipa_transform_pass /var/gcc/reghunt/master/gcc/passes.cc:2343 0x1898547 execute_all_ipa_transforms(bool) /var/gcc/reghunt/master/gcc/passes.cc:2406 0x115358b cgraph_node::expand() /var/gcc/reghunt/master/gcc/cgraphunit.cc:1826 0x115410b expand_all_functions /var/gcc/reghunt/master/gcc/cgraphunit.cc:2016 0x115522b symbol_table::compile() /var/gcc/reghunt/master/gcc/cgraphunit.cc:2390 0x1155917 symbol_table::finalize_compilation_unit() /var/gcc/reghunt/master/gcc/cgraphunit.cc:2575 e.g. building stage 1 libgcc (_gcov_merge_topn).
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #35 from Jakub Jelinek --- Sorry for wasting your time. --- a/gcc/tree-inline.cc +++ b/gcc/tree-inline.cc @@ -2787,6 +2787,8 @@ initialize_cfun (tree new_fndecl, tree callee_fndecl, profile_count count) /* Get clean struct function. */ push_struct_function (new_fndecl, true); targetm.target_option.relayout_function (new_fndecl); + if (INTEGRAL_TYPE_P (TREE_TYPE (DECL_RESULT (new_fndecl +gen_raw_REG (DECL_MODE (DECL_RESULT (new_fndecl)), 8); /* We will rebuild these, so just sanity check that they are empty. */ gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL); or could be gen_raw_REG (TYPE_MODE (TREE_TYPE (DECL_RESULT (new_fndecl))), 8);
[Bug c/24542] potential unwanted truncation of operation overflow should be warned on assignment to wider variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24542 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #14 from rsandifo at gcc dot gnu.org --- Heh, was in the process of reopening this too, but Richard beat me too it. FWIW, I agree this is worth providing as an option. Another justification is the different promotion handling between u32 = u16 op u16 and u64 = u32 op u32. "auto" (which wasn't a thing when the PR was first filed) might also increase the chances of accidentally pushing promotions to the root of a multi-statement calculation. I don't think the false positive/negative ratio matters too much for the option itself. If it works then I think it's worth having. IMO the ratio only becomes important if we're considering enabling this by default (unlikely), -Wall (unsure) or -Wextra (seems feasible).
[Bug web/109355] New: Add a text warning to old gcc online manual stating it is out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109355 Bug ID: 109355 Summary: Add a text warning to old gcc online manual stating it is out of date Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: jg at jguk dot org Target Milestone: --- Could old GCC documentation release HTML web pages have a text warning at the top making it clear the documentation is out of date? ie: "Warning: This GCC manual is not the latest online documentation " eg searching for "gcc function attributes error" gives me: https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html I noticed popular search engines often suggest out of date GCC docs, eg this one from 2012. So I manually browse to https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html Which is fine, I just find it myself, but it would be nice if there was a reminder at the top of each page, in case someone doesn't check the URL.
[Bug bootstrap/101834] make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #13 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:79d1e0b2c2b8ff4f4b1118549a80945faa1cb356 commit r13-6955-g79d1e0b2c2b8ff4f4b1118549a80945faa1cb356 Author: Jonathan Wakely Date: Thu Mar 30 13:03:11 2023 +0100 c++tools: Fix Makefile to properly clean and rebuild [PR101834] The c++tools makefile doesn't remove progressively more files in each of mostlyclean, clean, and distclean. Instead, each removes a different set of files (and some files are not removed by any target). Use prerequisites so that everything is removed. Also, building in the $objdir/c++tools directory doesn't work, because the INSTALL variable is never set. It works when building from the top-level because INSTALL is set in the environment when recursively invoking make for sub-directories. c++tools/ChangeLog: PR bootstrap/101834 * Makefile.in (INSTALL): Set variable. (mostlyclean): Mark as a phony target. (clean): Add mostlyclean as a prerequisite. (distclean): Add clean as a prerequisite and remove more files. (maintainer-clean): Add distclean as a prerequisite.
[Bug bootstrap/101834] make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #14 from Jonathan Wakely --- Fixed on trunk for now, backports planned.
[Bug libstdc++/109339] [12/13 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339
--- Comment #4 from Jonathan Wakely ---
(In reply to Richard Biener from comment #2)
> The diagnostic is intentional I think. We see
>
> [local count: 1073741824]:
> ss ={v} {CLOBBER};
> std::stop_token::_Stop_state_ref::_Stop_state_ref (&ss._M_state, &ss);
> std::stop_source::~stop_source (&ss);
> ss ={v} {CLOBBER(eol)};
> return 0;
>
> and the call to _Stop_state_ref passes references to uninitialized 'ss'
> (tree-ssa-uninit.cc:maybe_warn_pass_by_reference). The &ss argument
> is a const reference and the function does
>
> _Stop_state_ref(const _Stop_state_ref& __other) noexcept
That function is never used in this code though. Why is code being emitted for
it?
We don't copy a _Stop_state_ref, we construct one using this constructor:
_Stop_state_ref(const stop_source&)
: _M_ptr(new _Stop_state_t())
{ }
This has a reference to ss but doesn't inspect it at all.
> : _M_ptr(__other._M_ptr)
> {
> if (_M_ptr)
>_M_ptr->_M_add_owner();
> }
>
> so it inspects __other._M_ptr. It looks like for some reason the NSDMI
> init of _M_ptr isn't happening?
Because an NSDMI is not used if the constructor inits it explicitly, like this
one does. But this constructor is never used anyway, it's an unused inline
function so should not be emitted, and we should not get warnings for it.
[Bug libstdc++/109339] [12/13 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339
--- Comment #5 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Richard Biener from comment #2)
> > The diagnostic is intentional I think. We see
> >
> > [local count: 1073741824]:
> > ss ={v} {CLOBBER};
> > std::stop_token::_Stop_state_ref::_Stop_state_ref (&ss._M_state, &ss);
> > std::stop_source::~stop_source (&ss);
> > ss ={v} {CLOBBER(eol)};
> > return 0;
> >
> > and the call to _Stop_state_ref passes references to uninitialized 'ss'
> > (tree-ssa-uninit.cc:maybe_warn_pass_by_reference). The &ss argument
> > is a const reference and the function does
> >
> > _Stop_state_ref(const _Stop_state_ref& __other) noexcept
>
> That function is never used in this code though. Why is code being emitted
> for it?
Actually I don't think any code is being emitted for it, so that's fine. That
function is a red herring, but not involved here at all.
The warning is for this one:
> We don't copy a _Stop_state_ref, we construct one using this constructor:
>
> _Stop_state_ref(const stop_source&)
> : _M_ptr(new _Stop_state_t())
> { }
>
> This has a reference to ss but doesn't inspect it at all.
It can't inspect it, because it's not even named. The function has no way to
possibly access the uninitialized object through that reference.
[Bug c++/109356] New: Enhancement idea to provide clearer missing brace line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356
Bug ID: 109356
Summary: Enhancement idea to provide clearer missing brace line
number
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
Target Milestone: ---
Sometimes due to human error there is a missing brace.
Enhancement idea to provide the missing brace line number. Is that possible?
Godbolt trunk gcc does show there is an error, but doesn't pick out line 5.
Would be great if it could
https://godbolt.org/z/nE13h1r13
:8:2: error: expected '}' before ';' token
8 | };
| ^
:2:1: note: to match this '{'
2 | {
| ^
:8:2: error: too many initializers for 'const char* [2]'
8 | };
| ^
static const char * list[][2] =
{
{"A", "B"},
{"C", "D"},
{"E", "F",
{"G", "H"},
{"I", "J"}
};
int main()
{
}
[Bug target/105523] Wrong warning array subscript [0] is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523 David Crocker changed: What|Removed |Added CC||dcrocker at eschertech dot com --- Comment #16 from David Crocker --- This issue is not specific to AVR target. I get the same spurious warning from gcc 12.2 arm-none-eabi when I compile the following code for ARM Cortex M0+ and M4 targets: const char *bootloaderVersionText = *reinterpret_cast(0x20); I haven't found a workaround other than to use a pragma to disable the warning for that line of code.
[Bug tree-optimization/109353] FAIL: 23_containers/vector/bool/allocator/copy.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109353
--- Comment #4 from Jonathan Wakely ---
This doesn't help:
--- a/libstdc++-v3/include/bits/vector.tcc
+++ b/libstdc++-v3/include/bits/vector.tcc
@@ -936,15 +936,25 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
*__position = __x;
++this->_M_impl._M_finish;
}
+ else if (!this->_M_impl._M_start._M_p)
+ {
+ _Bit_pointer __q = this->_M_allocate(1);
+ iterator __i(std::__addressof(*__q), 0);
+ this->_M_impl._M_end_of_storage = __q + 1;
+ this->_M_impl._M_start = __i;
+ *__i = __x;
+ this->_M_impl._M_finish = ++__i;
+ }
else
{
const size_type __len =
_M_check_len(size_type(1), "vector::_M_insert_aux");
+ const iterator __begin = begin(), __end = end();
_Bit_pointer __q = this->_M_allocate(__len);
iterator __start(std::__addressof(*__q), 0);
- iterator __i = _M_copy_aligned(begin(), __position, __start);
+ iterator __i = _M_copy_aligned(__begin, __position, __start);
*__i++ = __x;
- iterator __finish = std::copy(__position, end(), __i);
+ iterator __finish = std::copy(__position, __end, __i);
this->_M_deallocate();
this->_M_impl._M_end_of_storage = __q + _S_nword(__len);
this->_M_impl._M_start = __start;
[Bug c++/109356] Enhancement idea to provide clearer missing brace line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356 Jonathan Wakely changed: What|Removed |Added Severity|normal |enhancement Keywords||diagnostic
[Bug sanitizer/107374] Please expand the size of flag_sanitize to uint64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107374 Xi Ruoyao changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED CC||xry111 at gcc dot gnu.org --- Comment #3 from Xi Ruoyao --- Invalid then.
[Bug sanitizer/107048] GCC lacks -fsanitize=kcfi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107048 Xi Ruoyao changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW CC||xry111 at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-03-31
[Bug c++/109357] New: GCC 13.0.1: internal compiler error in cp/constexpr.cc:1685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109357
Bug ID: 109357
Summary: GCC 13.0.1: internal compiler error in
cp/constexpr.cc:1685
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kgledits at cisco dot com
Target Milestone: ---
Created attachment 54797
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54797&action=edit
C++ file triggering internal compiler error
See also https://godbolt.org/z/obn7vvjje . Using the attached CPP file:
$ g++ --version
g++ (GCC) 13.0.1 20230318 (Red Hat 13.0.1-0)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++ -std=c++20 -O2 -o - input-reduced.cpp
input-reduced.cpp: In destructor ‘s2::~s2()’:
input-reduced.cpp:15:19: warning: ISO C++ forbids converting a string constant
to ‘char*’ [-Wwrite-strings]
15 | s2::~s2() { s1 = {"", ""}; }
| ^~
input-reduced.cpp:15:23: warning: ISO C++ forbids converting a string constant
to ‘char*’ [-Wwrite-strings]
15 | s2::~s2() { s1 = {"", ""}; }
| ^~
input-reduced.cpp: In destructor ‘s2::~s2()’:
input-reduced.cpp:15:28: internal compiler error: in adjust_temp_type, at
cp/constexpr.cc:1685
15 | s2::~s2() { s1 = {"", ""}; }
|^
Please submit a full bug report, with preprocessed source.
See for instructions.
Preprocessed source stored into /tmp/ccN3KzRp.out file, please attach this to
your bugreport.
[Bug fortran/109358] New: Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 Bug ID: 109358 Summary: Wrong formatting with T-descriptor during stream output Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: baradi09 at gmail dot com Target Milestone: --- This is a very minor bug, but probably easy to fix. It seems, that the T data edit descriptor handling is non-standard conforming when using formatted stream I/O: Given the following MWE: program tabformat implicit none integer :: fd open(newunit=fd, file="test.stream.txt", access="stream", form="formatted") write(fd, "(a)") "1234567890123" write(fd, "(a, t10, a)") "1234", "0123" ! A-descriptor, file positioning allowed write(fd, "(i4, t10, i4.4)") 1234, 0123 ! I-descriptor, file positioning not allowed close(fd) end program tabformat The resulting file contains 1234567890123 1234 0123 # 9 spaces between blocks 1234 0123 # 9 spaces between blocks Apparently, a file positioning takes place during the execution of the write statement. However, if I understand 13.7.1 §1 correctly, file positioning may only happen with the A-descriptor (and it is optional even there). So the standard conforming output would be either (if file positioning happens after the A-descriptor) 1234567890123 1234 0123# 9 spaces 1234 0123# 5 spaces or (if no file positioning happens after the A-descriptor) 1234567890123 1234 0123# 5 spaces 1234 0123# 5 spaces I personally would prefer latter, and it would be also equivalent to the behavior of the Intel and NAG compilers.
[Bug c++/109356] Enhancement idea to provide clearer missing brace line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #1 from Xi Ruoyao --- I believe attempting to doing so would result exponential time complexity.
[Bug ipa/107769] [12/13 Regression] -flto with -Os/-O2/-O3 emitted code with gcc 12.x segfaults via mutated global in .rodata since r12-2887-ga6da2cddcf0e959d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107769 --- Comment #6 from Martin Jambor --- Yes, you identified the correct commit. The same jump function is double counted (once during iPA-CP and then again during inlining) when we drop references and so an address reference is replaced with a read one. I will make this bug a priority next week.
[Bug web/109355] Add a text warning to old gcc online manual stating it is out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109355 --- Comment #1 from Andrew Pinski --- There is another bug about adding a version to the manual pages. Thar would be better. Touching old generated html files is not a good solution. Plus the version is in the url.
[Bug web/109355] Add a text warning to old gcc online manual stating it is out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109355 --- Comment #2 from Andrew Pinski --- Oh and the manual is not exactly out of date for that version of gcc. So the text you have would be wrong.
[Bug libstdc++/109339] [12/13 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #6 from Richard Biener ---
OK, I suppose I was misled by trying to trace how the construction works. The
first half of my comment#2 still stands - we diagnose
ss ={v} {CLOBBER};
std::stop_token::_Stop_state_ref::_Stop_state_ref (&ss._M_state, &ss);
by (maybe broken) design, the &ss argument is a const reference which
we decide implies read. In this case we could even use modref to
see the parameter is unused - but the call happens through an alias
and in the -Og pipeline we do not run late modref.
The called body is
void std::stop_token::_Stop_state_ref::_Stop_state_ref (struct _Stop_state_ref
* const this, const struct stop_source & D.79270)
{
void * _5;
[local count: 1073741824]:
_5 = operator new (24);
MEM[(struct _Stop_state_t *)_5]._M_owners.D.16955._M_i = 0;
MEM[(struct _Stop_state_t *)_5]._M_value.D.16955._M_i = 0;
MEM[(struct _Stop_state_t *)_5]._M_head = 0B;
MEM[(struct _Stop_state_t *)_5]._M_requester._M_thread = 0;
MEM[(struct __atomic_base *)_5]._M_i = 1;
MEM[(struct __atomic_base *)_5 + 4B]._M_i = 4;
MEM[(struct id *)_5 + 16B]._M_thread = 0;
this_2(D)->_M_ptr = _5;
return;
}
but since this function can be interposed even modref doesn't help (when
scheduled and enabled) since it throws away this knowledge :/ Maybe
we need some optimistic mode for diagnostic code (or add
EAF_LIKELY_UNUSED).
But as said (late) modref isn't in the -Og pipeline and it's only enabled
with -O2+ anyway.
The other possible heuristic adjustment would be noticing &ss is also
passed as first non-const reference argument.
[Bug ipa/109318] [12/13 Regression] csmith: -fipa-cp seems to cause trouble since r12-2523-g13586172d0b70c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109318 --- Comment #9 from Martin Jambor --- Most likely a duplicate of PR 107769.
[Bug web/109355] Add a text warning to old gcc online manual stating it is out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109355 --- Comment #3 from Jonathan Wakely --- We could add server rules to insert a banner into the HTML on every page, but it's not trivial. You might be thinking of PR 65699.
[Bug libstdc++/109339] [12/13 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339 --- Comment #7 from Jonathan Wakely --- OK I suppose we can change the library to avoid passing a reference there.
[Bug middle-end/97048] [meta-bug] bogus/missing -Wstringop-overread warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048 Bug 97048 depends on bug 107087, which changed state. Bug 107087 Summary: [12/13 Regression] bits/stl_algobase.h:431: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' reading between 8 and 2147483644 bytes from a region of size 4 [-Wstringop-overread] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug tree-optimization/107087] [12/13 Regression] bits/stl_algobase.h:431: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' reading between 8 and 2147483644 bytes from a region of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087
Richard Biener changed:
What|Removed |Added
Summary|[13 Regression] |[12/13 Regression]
|bits/stl_algobase.h:431:|bits/stl_algobase.h:431:
|warning: 'void* |warning: 'void*
|__builtin_memcpy(void*, |__builtin_memcpy(void*,
|const void*, unsigned int)' |const void*, unsigned int)'
|reading between 8 and |reading between 8 and
|2147483644 bytes from a |2147483644 bytes from a
|region of size 4|region of size 4
|[-Wstringop-overread] |[-Wstringop-overread]
Status|RESOLVED|REOPENED
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Resolution|FIXED |---
Target Milestone|13.0|12.3
--- Comment #8 from Richard Biener ---
Only comment#1 is fixed, the original testcase is 22_locale/money_get/cons/3.cc
which still fails with the settings from comment#7
We have
[local count: 268328082]:
_187 = MEM[(struct _Rep *)&_S_empty_rep_storage].D.58774._M_length;
_189 = MIN_EXPR <_170, _187>;
if (_189 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 134164041]:
if (_189 == 1)
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 45615775]:
MEM[(struct char_type *)_172] = MEM[(const struct character
&)&_S_empty_rep_storage + 12];
goto ; [100.00%]
[local count: 88548267]:
_173 = _189 * 4;
__builtin_memcpy (_172, &MEM [(void *)&_S_empty_rep_storage +
12B], _173); // <--- diagnosed
[local count: 268328083]:
__negative_sign ={v} {CLOBBER};
so we know that _173 is [2, +INF] * 4 and that's enough to diagnose the
call as we seem to have an idea about the source size (the embedded
string length).
There's an intervening operator new preventing CSE of the length of the
destination and while there's a condition of != &_S_empty_rep_storage
control flow converges again before this, so it seems we handle both
here.
It's incredibly branchy code :/
[Bug c/15450] Ability to turn selected warnings into errors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15450 --- Comment #3 from Andrew Pinski --- Note for long long, you can use -Wno-long-long which is documented here: https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wlong-long Been around since 3.1: https://gcc.gnu.org/onlinedocs/gcc-3.1.1/gcc/Warning-Options.html#Warning%20Options -Wlong-long Warn if long long type is used. This is default. To inhibit the warning messages, use -Wno-long-long. Flags -Wlong-long and -Wno-long-long are taken into account only when -pedantic flag is used.
[Bug c/16794] should warn about switched memset arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16794 Andrew Pinski changed: What|Removed |Added Resolution|WONTFIX |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 61294 *** This bug has been marked as a duplicate of bug 61294 ***
[Bug tree-optimization/91645] Missed optimization with sqrt(x*x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91645
--- Comment #14 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e02c9d9116f243643c0daba8dbcc5d1795c827c3
commit r13-6956-ge02c9d9116f243643c0daba8dbcc5d1795c827c3
Author: Jakub Jelinek
Date: Fri Mar 31 13:41:34 2023 +0200
range-op-float, value-range: Fix up handling of UN{LT,LE,GT,GE,EQ}_EXPR and
handle comparisons in get_tree_range [PR91645]
When looking into PR91645, I've noticed we handle UN{LT,LE,GT,GE,EQ}_EXPR
comparisons incorrectly.
All those are unordered or ..., we correctly return [1, 1] if one or
both operands are known NANs, and correctly ask the non-UN prefixed
op to fold_range if neither operand may be NAN.
But for the case where one or both operands may be NAN, we always
return [0, 1]. The UN* fold_range tries to handle it by asking
the non-UN prefixed fold_range and if it returns [1, 1] return that,
if it returns [0, 0] or [0, 1] return [0, 1], which makes sense,
because the maybe NAN means that it is the non-UN prefixed fold_range
unioned with [1, 1] in case the maybe NAN is actually NAN at runtime.
The problem is that the non-UN prefixed fold_range always returns [0, 1]
because those fold_range implementations are like:
if (op1.known_isnan () || op2.known_isnan ())
r = range_false (type);
else if (!maybe_isnan (op1, op2))
{
...
}
else
r = range_true_and_false (type);
and so if maybe_isnan, they always return [0, 1]. Now, thinking about it,
this is unnecessary pessimization, for the case where the ... block
returns range_false (type) we actually could do it also if maybe_isnan
(op1,
op2), because if one or both operands are NAN, the comparison will be
false,
and if neither is NAN, the comparison will be also false. Will fix
incrementally today.
Anyway, the following patch fixes it by asking the non-UN prefixed
fold_range on ranges with NAN cleared, which I think does the right
thing in all cases.
Another change in the patch is that range_query::get_tree_range
always returned VARYING for comparisons, this patch allows to ask about
those as well (they are very much like binary ops, except they take
the important type from the types of the operands rather than result).
Initially I've developed this patch together with changes to
tree-call-cdce.cc,
but those result in one regression and apparently aren't actually needed to
fix this bug, the range-op-float.cc changes are enough.
2023-03-31 Jakub Jelinek
PR tree-optimization/91645
* range-op-float.cc (foperator_unordered_lt::fold_range,
foperator_unordered_le::fold_range,
foperator_unordered_gt::fold_range,
foperator_unordered_ge::fold_range,
foperator_unordered_equal::fold_range): Call the ordered
fold_range on ranges with cleared NaNs.
* value-query.cc (range_query::get_tree_range): Handle also
COMPARISON_CLASS_P trees.
* gcc.target/i386/pr103559-1.c: New test.
* gcc.target/i386/pr103559-2.c: New test.
* gcc.target/i386/pr103559-3.c: New test.
* gcc.target/i386/pr103559-4.c: New test.
[Bug middle-end/61294] [4.9 Regression] erroneous memset used with constant zero length parameter warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61294 Andrew Pinski changed: What|Removed |Added CC||martin at v dot loewis.de --- Comment #16 from Andrew Pinski --- *** Bug 16794 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/107087] [12/13 Regression] bits/stl_algobase.h:431: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' reading between 8 and 2147483644 bytes from a region of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087
--- Comment #9 from Jonathan Wakely ---
This prevents the warning:
--- a/libstdc++-v3/include/bits/cow_string.h
+++ b/libstdc++-v3/include/bits/cow_string.h
@@ -911,13 +911,25 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
/// null-termination.
size_type
size() const _GLIBCXX_NOEXCEPT
- { return _M_rep()->_M_length; }
+ {
+#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0 && __OPTIMIZE__
+ if (_M_rep() == &_S_empty_rep() && _M_rep()->_M_length != 0)
+ __builtin_unreachable();
+#endif
+ return _M_rep()->_M_length;
+ }
/// Returns the number of characters in the string, not including any
/// null-termination.
size_type
length() const _GLIBCXX_NOEXCEPT
- { return _M_rep()->_M_length; }
+ {
+#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0 && __OPTIMIZE__
+ if (_M_rep() == &_S_empty_rep() && _M_rep()->_M_length != 0)
+ __builtin_unreachable();
+#endif
+ return _M_rep()->_M_length;
+ }
/// Returns the size() of the largest possible %string.
size_type
[Bug middle-end/80922] #pragma diagnostic ignored not honoured with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug middle-end/65534] tailcall not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65534 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug ipa/83582] GCC is unable to fold the code of identical lambda-expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83582 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug tree-optimization/109353] FAIL: 23_containers/vector/bool/allocator/copy.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109353 --- Comment #5 from Richard Biener --- (In reply to Jonathan Wakely from comment #4) > This doesn't help: > > --- a/libstdc++-v3/include/bits/vector.tcc > +++ b/libstdc++-v3/include/bits/vector.tcc > @@ -936,15 +936,25 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER > *__position = __x; > ++this->_M_impl._M_finish; > } > + else if (!this->_M_impl._M_start._M_p) yes, we can't CSE this load from the = nullptr assignment so we'd still diagnose the else case ...
[Bug libstdc++/109339] [12/13 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek ---
What is the
explicit
_Stop_state_ref(const stop_source&)
: _M_ptr(new _Stop_state_t())
{ }
there for, can't you use some completely unrelated type there instead (bool,
stop_source*, some enum, whatever), or drop the const at least?
The passing pointer to uninitialized const object or reference to uninitialized
const object to function we don't know anything about is I think one of the
design goals of Martin's change which probably not everybody will agree with,
but it is true that it can sometimes find bugs in code.
[Bug libstdc++/109339] [12/13 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339
--- Comment #9 from Jonathan Wakely ---
Yes, we can pass something else there instead.
It would be nice if this worked to silence the warning though:
--- a/libstdc++-v3/include/std/stop_token
+++ b/libstdc++-v3/include/std/stop_token
@@ -395,10 +395,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
_Stop_state_ref() = default;
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
+ __attribute__((__access__(__none__, 1)))
explicit
_Stop_state_ref(const stop_source&)
: _M_ptr(new _Stop_state_t())
{ }
+#pragma GCC diagnostic pop
_Stop_state_ref(const _Stop_state_ref& __other) noexcept
: _M_ptr(__other._M_ptr)
It has no effect at all (putting the pragmas around the caller works though).
Now that we have the access attribute, why doesn't access(none, N) help here?
It seems to express exactly what I want to express here, but the warning
doesn't care.
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #36 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #35 from Jakub Jelinek --- > Sorry for wasting your time. No worries: it's mostly the SPARC box doing the compiles ;-) > --- a/gcc/tree-inline.cc > +++ b/gcc/tree-inline.cc > @@ -2787,6 +2787,8 @@ initialize_cfun (tree new_fndecl, tree callee_fndecl, > profile_count count) >/* Get clean struct function. */ >push_struct_function (new_fndecl, true); >targetm.target_option.relayout_function (new_fndecl); > + if (INTEGRAL_TYPE_P (TREE_TYPE (DECL_RESULT (new_fndecl > +gen_raw_REG (DECL_MODE (DECL_RESULT (new_fndecl)), 8); > >/* We will rebuild these, so just sanity check that they are empty. */ >gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL); This one passed the build.
[Bug libstdc++/109339] [12/13 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339 --- Comment #10 from Jakub Jelinek --- __attribute__((__access__(__none__, 2))) on the ctor works, no need to add pragmas.
[Bug tree-optimization/109334] tree-object-size: Improve size computation in arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109334 --- Comment #2 from Siddhesh Poyarekar --- That seems OK; I had added that to be conservative since I really only intended to add support for the access attribute back then and not the implicit attributes. Could you please post that on the ML and have it reviewed? Thanks!
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #37 from Jakub Jelinek --- (In reply to r...@cebitec.uni-bielefeld.de from comment #36) > > --- a/gcc/tree-inline.cc > > +++ b/gcc/tree-inline.cc > > @@ -2787,6 +2787,8 @@ initialize_cfun (tree new_fndecl, tree callee_fndecl, > > profile_count count) > >/* Get clean struct function. */ > >push_struct_function (new_fndecl, true); > >targetm.target_option.relayout_function (new_fndecl); > > + if (INTEGRAL_TYPE_P (TREE_TYPE (DECL_RESULT (new_fndecl > > +gen_raw_REG (DECL_MODE (DECL_RESULT (new_fndecl)), 8); > > > >/* We will rebuild these, so just sanity check that they are empty. */ > >gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL); > > This one passed the build. That is kind of bad news for trying to debug where the problem is, because the above patch has only effect of doing 4 extra GC allocations, so the -fno-checking vs. -fchecking=1 bug was just latent before, perhaps some code generation decision is done from pointer comparisons or something similar. If the problem without this patch is reliably reproduceable even with the same d21 binary but not after enabling all the dumps, perhaps another attempt would be try to see if enabling just one dump somewhere would make it latent again as well or if it would still reproduce. So rather than trying to -fdump-tree-all -da, perhaps just try -fdump-tree-optimized, or -fdump-rtl-vregs or -fdump-rtl-postreload etc. If the assemblies differ even with just one of those dumps enabled, you can see if there is any difference in the dump or not. Other option would be only side-by-side debugging but without the dumps actually working it is much harder to find out where to look at.
[Bug c++/109359] New: Compile-time rounding of double literal to float is incorrect with -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359
Bug ID: 109359
Summary: Compile-time rounding of double literal to float is
incorrect with -frounding-math
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rcopley at gmail dot com
Target Milestone: ---
The following program should print:
0.001914
0.630538
With "g++ -frounding-math", it prints instead:
-8023756970655744.00
0.872496
This bug is present in trunk, and since gcc 12.1, and does not appear to be
platform specific.
Compiler explorer link: https://godbolt.org/z/aMhcYcY66
#include
float xs[] = {0.001914, 0.630539};
int main() {
std::size_t size = sizeof xs / sizeof xs[0];
for (std::size_t i = 0; i != size; ++i) {
std::printf("%f\n", xs[i]);
}
}
[Bug libstdc++/109339] [12/13 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #11 from Jonathan Wakely --- Oh good! Testing that now then ...
[Bug rtl-optimization/90706] [10/11/12/13 Regression] Useless code generated for stack / register operations on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 --- Comment #20 from CVS Commits --- The releases/gcc-12 branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:88792f04e5c63025506244b9ac7186a3cc10c25a commit r12-9372-g88792f04e5c63025506244b9ac7186a3cc10c25a Author: Vladimir N. Makarov Date: Thu Mar 2 16:29:05 2023 -0500 IRA: Use minimal cost for hard register movement This is the 2nd attempt to fix PR90706. IRA calculates wrong AVR costs for moving general hard regs of SFmode. This was the reason for spilling a pseudo in the PR. In this patch we use smaller move cost of hard reg in its natural and operand modes. PR rtl-optimization/90706 gcc/ChangeLog: * ira-costs.cc: Include print-rtl.h. (record_reg_classes, scan_one_insn): Add code to print debug info. (record_operand_costs): Find and use smaller cost for hard reg move. gcc/testsuite/ChangeLog: * gcc.target/avr/pr90706.c: New.
[Bug tree-optimization/107087] [12/13 Regression] bits/stl_algobase.h:431: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' reading between 8 and 2147483644 bytes from a region of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087
--- Comment #10 from Jonathan Wakely ---
I wonder if some other hints about properties of the empty rep would help
codegen:
--- a/libstdc++-v3/include/bits/cow_string.h
+++ b/libstdc++-v3/include/bits/cow_string.h
@@ -204,6 +204,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
bool
_M_is_leaked() const _GLIBCXX_NOEXCEPT
{
+#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0 && __OPTIMIZE__
+ if (_S_empty_rep()._M_refcount != 0)
+ __builtin_unreachable();
+#endif
+
#if defined(__GTHREADS)
// _M_refcount is mutated concurrently by _M_refcopy/_M_dispose,
// so we need to use an atomic load. However, _M_is_leaked
@@ -218,6 +223,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
bool
_M_is_shared() const _GLIBCXX_NOEXCEPT
{
+#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0 && __OPTIMIZE__
+ if (_S_empty_rep()._M_refcount != 0)
+ __builtin_unreachable();
+#endif
+
#if defined(__GTHREADS)
// _M_refcount is mutated concurrently by _M_refcopy/_M_dispose,
// so we need to use an atomic load. Another thread can drop last
@@ -907,17 +917,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
public:
// Capacity:
+
/// Returns the number of characters in the string, not including any
/// null-termination.
size_type
size() const _GLIBCXX_NOEXCEPT
- { return _M_rep()->_M_length; }
+ {
+#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0 && __OPTIMIZE__
+ if (_S_empty_rep()._M_length != 0)
+ __builtin_unreachable();
+#endif
+ return _M_rep()->_M_length;
+ }
/// Returns the number of characters in the string, not including any
/// null-termination.
size_type
length() const _GLIBCXX_NOEXCEPT
- { return _M_rep()->_M_length; }
+ { return size(); }
/// Returns the size() of the largest possible %string.
size_type
[Bug rtl-optimization/90706] [10/11/12/13 Regression] Useless code generated for stack / register operations on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 --- Comment #21 from Vladimir Makarov --- (In reply to CVS Commits from comment #20) > The releases/gcc-12 branch has been updated by Vladimir Makarov > : > > https://gcc.gnu.org/g:88792f04e5c63025506244b9ac7186a3cc10c25a > > The trunk with the patch behaved good for a few weeks. So I backported it to gcc-12 branch. GCC-12 branch with the patch was successfully tested and bootstrapped on x86-64.
[Bug web/109355] Add a text warning to old gcc online manual stating it is out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109355 --- Comment #4 from Jonny Grant --- (In reply to Andrew Pinski from comment #2) > Oh and the manual is not exactly out of date for that version of gcc. So the > text you have would be wrong. Sorry, you're completely right. A script could search for and insert after: Warning: This GCC manual is not the https://gcc.gnu.org/onlinedocs/gcc-latest-stable-redirect";>latest GCC release
[Bug testsuite/109360] New: RFE: check that generated .sarif files validate against the SARIF schema
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109360 Bug ID: 109360 Summary: RFE: check that generated .sarif files validate against the SARIF schema Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- Created attachment 54798 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54798&action=edit WIP progress patch I have a partially-working patch to scansarif.exp that validates the .sarif files generated by -fdiagnostics-format=sarif-file against the sarif schema. Filing here to keep track of merging this to trunk
[Bug other/109163] SARIF (and other JSON) output files are non-deterministic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109163 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #5 from David Malcolm --- Should be fixed by the above patch on trunk for GCC 13.
[Bug analyzer/109361] New: RFE: SARIF output could contain timing/profile information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109361 Bug ID: 109361 Summary: RFE: SARIF output could contain timing/profile information Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- My integration tests for -fanalyzer don't yet track how long the analyzer takes on the real-world cases. It would be nice for the .sarif files generated by -fdiagnostics-format=sarif-file to contain profiling or timing information.
[Bug analyzer/109361] RFE: SARIF output could contain timing/profile information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109361 --- Comment #1 from David Malcolm --- Some existing SARIF properties we could generate: 3.20.7 startTimeUtc property An invocation object MAY contain a property named startTimeUtc whose value is a string in the format specified in §3.9, specifying the UTC date and time at which the invocation started. 3.20.8 endTimeUtc property An invocation object MAY contain a property named endTimeUtc whose value is a string in the format specified in §3.9, specifying the UTC date and time at which the invocation ended. 3.38.12 executionTimeUtc property A threadFlowLocation object MAY contain a property named executionTimeUtc whose value is a string in the format specified in §3.9, specifying the UTC date and time at which the thread of execution through the code reached this location. 3.48.2 firstDetectionTimeUtc property A resultProvenance object MAY contain a property named firstDetectionTimeUtc whose value is a string in the format specified in §3.9, specifying the UTC date and time at which the result was first detected. It SHOULD specify the start time of the run in which the result was first detected, as opposed to, for example, the time within the run at which the result was actually generated. NOTE: Using the run’s start time makes it possible to group together results that were first detected in the same run. 3.48.3 lastDetectionTimeUtc property A resultProvenance object MAY contain a property named lastDetectionTimeUtc whose value is a string in the format specified in §3.9, specifying the UTC date and time at which the result was most recently detected. It SHOULD specify the start time of the run in which the result was most recently detected, as opposed to, for example, the time within the run at which the result was actually generated. NOTE: Using the run’s start time makes it possible to group together results that were detected in the same run. If lastDetectionTimeUtc is absent, its default value SHALL be determined as follows: 1. If run.invocations is present, and if the startTimeUtc property (§3.20.7) is present on any of the invocation objects (§3.20) in that array, then the default is the earliest of those times. 2. Otherwise, there is no default. 3.58.8 timeUtc property A notification object MAY contain a property named timeUtc whose value is a string in the format specified §3.9, specifying the UTC date and time at which the analysis tool generated the notification. or perhaps we could use a property bag (e.g. to capture timevar information)
[Bug c++/109359] [12/13 Regression] Compile-time rounding of double literal to float is incorrect with -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-03-31 Target Milestone|--- |12.3 Summary|Compile-time rounding of|[12/13 Regression] |double literal to float is |Compile-time rounding of |incorrect with |double literal to float is |-frounding-math |incorrect with ||-frounding-math Keywords||needs-bisection, wrong-code Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- With -frounding-math: xs: .long -639366012 .long 1063214053 .long 536561674 .long 1071918432 without: xs: .long 989519663 .long 1059154689 it looks like we fail to convert the double constant to single precision and then end up outputting the double precision constants ... The C frontend works.
[Bug c++/109359] [12/13 Regression] Compile-time rounding of double literal to float is incorrect with -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Keywords|needs-bisection | --- Comment #2 from Jakub Jelinek --- Started with r12-4764-ga84b9d5373c7e67fd0ab2a
[Bug c++/109362] New: codegen adds unnecessary extra add when reading atomic member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109362
Bug ID: 109362
Summary: codegen adds unnecessary extra add when reading atomic
member
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
This program:
#include
struct S {
long size;
std::atomic read_ptr;
auto peek() const -> const char* {
return read_ptr.load(std::memory_order_acquire);
}
};
auto with_atomic(S const& v) {
while (true) {
if (v.peek()) {
return true;
}
}
}
emits (on gcc 12.2 -O3):
with_atomic(S const&):
add rdi, 8
.L2:
mov rax, QWORD PTR [rdi]
testrax, rax
je .L2
mov eax, 1
ret
But that add is completely necessary, the mov could just be:
mov rax, QWORD PTR [rdi + 8]
which is what clang (16.0 -O3) generates:
with_atomic(S const&):# @with_atomic(S const&)
.LBB0_1:# =>This Inner Loop Header: Depth=1
mov rax, qword ptr [rdi + 8]
testrax, rax
je .LBB0_1
mov al, 1
ret
It's not just an extra add, it's consuming an extra register - which has more
downstream optimization effects.
[Bug c++/109359] [12/13 Regression] Compile-time rounding of double literal to float is incorrect with -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 CC||jason at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I think the fold-const.cc change is right though. I wonder if for constant evaluation (constexpr, constinit) we shouldn't arrange for those to be evaluated with temporarily -fno-rounding-math, I think C uses fold_init and its START_FOLD_INIT ... END_FOLD_INIT for this purpose.. And otherwise perhaps we want dynamic initialization and do the conversion at runtime? Or disable the -frounding-math for all initializer folding? What we emit is definitely wrong, Variable which claims to have 8 bytes in size but actually has 16 under the hood, with constants in different mode.
[Bug tree-optimization/109350] FAIL: g++.dg/warn/Wstringop-overflow-4.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109350
--- Comment #3 from Andrew Macleod ---
On 3/31/23 03:17, rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109350
>
> Richard Biener changed:
>
> What|Removed |Added
>
> CC||amacleod at redhat dot com
>
> --- Comment #2 from Richard Biener ---
> Hmm, the same reproduces with r_imin_imax as ptrdiff_t but the IL is a bit
> more obvious:
>
> [local count: 1073741824]:
> _27 ={v} signed_value_source;
> _4 = (unsigned long) _27;
> _8 = _4 + 2147483648;
> if (_8 > 4294967295)
>goto ; [50.00%]
> else
>goto ; [50.00%]
>
> [local count: 536870913]:
> _30 = _27 + 1;
> _28 = (sizetype) _30;
> if (_4 <= 4611686018427387900)
>goto ; [50.00%]
> else
>goto ; [50.00%]
>
> [local count: 268435458]:
> _12 = operator new [] (18446744073709551615);
> __builtin_memcpy (_12, &MEM [(void
> *)"0123456789abcdefghijklmnopqrstuvwxyz" + 35B], 2);
> sink (_12);
> if (_28 <= 4611686018427387900)
>goto ; [100.00%]
> else
>goto ; [0.00%]
>
> [local count: 0]:
> iftmp.2_37 = _28 * 2;
> _39 = operator new [] (iftmp.2_37);
> __builtin_memcpy (_39, &MEM [(void
> *)"0123456789abcdefghijklmnopqrstuvwxyz" + 34B], 3);
>
> so we have (unsigned long)[int_min, int_max] > 4611686018427387900
> && (unsigned long)[int_min+1, int_max+1] <= 4611686018427387900 to
> constrain _4. I don't see how we can arrive at [0,0] for iftmp.2_37.
Looking at what ranger produces for vrp2 (same code just a few passes
later):
=== BB 2
Imports: _28
Exports: _4 _10 _28
_4 : _28(I)
_10 : _4 _28(I)
Partial equiv (_4 pe64 _28)
Relational : (_10 != _4)
[local count: 1073741824]:
_28 ={v} signed_value_source;
_4 = (unsigned long) _28;
_10 = _4 + 2147483648;
if (_10 > 4294967295)
goto ; [50.00%]
else
goto ; [50.00%]
2->3 (F) _4 : [irange] unsigned long [0,
2147483647][18446744071562067968, +INF]
2->3 (F) _10 : [irange] unsigned long [0, 4294967295] NONZERO
0x
2->3 (F) _28 : [irange] long int [-2147483648, 2147483647]
on entry top BB3 , _28 has the full range of a signed int in a long int
body.
=== BB 3
_4 [irange] unsigned long [0, 2147483647][18446744071562067968, +INF]
_28 [irange] long int [-2147483648, 2147483647]
Partial equiv (r_imin_imax_8 pe32 _28)
Relational : (_31 > r_imin_imax_8)
[local count: 536870913]:
r_imin_imax_8 = (int) _28; << THIs is
varying, which is why it isnt printed anywhere
_31 = r_imin_imax_8 + 1; << signed traps on overflowt, so
this would be [min+1, +INF]
_29 = (sizetype) _31; << sizetype is a larger unsigned
object,so the possible values for it are [0,
2147483647][18446744071562067969, +INF]
if (_4 <= 4611686018427387900) << this leaves _4 with
possible values of [18446744071562067968, +INF] on the FALSE branch.
goto ; [50.00%]
else
goto ; [50.00%]
_29 : [irange] sizetype [0, 2147483647][18446744071562067969, +INF]
_31 : [irange] int [-2147483647, +INF]
When we recalculate values based on the range of _4 on the false
branch, intersected with their knowns ranges, it comes up with this
3->5 (F) _4 : [irange] unsigned long [18446744071562067968, +INF]
3->5 (F) r_imin_imax_8 : [irange] int [-INF, -1]
3->5 (F) _28 : [irange] long int [-2147483648, -1]
3->5 (F) _29 : [irange] sizetype [0, 0][18446744071562067969, +INF]
3->5 (F) _31 : [irange] int [-2147483647, 0]
when we feed that value of _4 into
[18446744071562067968, +INF] = (unsigned long)28
in BB2, we discover the only possible valiues of _28 are [-2147483648,
-1] on this branch.
We now go an recalculate r_imin_imax_8, _31 and _29 based on this new
value of _28 and come up with those ranges
that means when we get to bb5, and see
if (_29 <= 4611686018427387900)
goto ; [100.00%]
the only possible value of _29 on this branch is a [0,0] And thats a
direct result of _31 = [-INF, -1] + 1 before _20 is created with the cast.
yikes. talk about convoluted...
>
> In fact if I put this into a separate testcase like
>
> void __attribute__((noipa))
> foo (long signed_value_source)
> {
>unsigned long temu = signed_value_source;
>if (temu + 2147483648 > 4294967295)
> ;
>else
> {
> long tems = signed_value_source + 1;
> unsigned long temu2 = tems;
> if (temu > 4611686018427387900)
> if (temu2 <= 4611686018427387900)
> {
> unsigned long iftmp = temu2 * 2;
> if (iftmp == 0)
> __builtin_abort ();
> }
> }
> }
>
> then we optimize this to
>
> [local count: 1073741824]:
>temu_3 = (long unsigned int) signed_val
[Bug rtl-optimization/90706] [10/11/12/13 Regression] Useless code generated for stack / register operations on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 Georg-Johann Lay changed: What|Removed |Added Known to fail||10.0, 11.0, 12.0, 9.0 Status|NEW |RESOLVED Resolution|--- |FIXED Known to work||13.0 --- Comment #22 from Georg-Johann Lay --- Fixed in 12.3+
[Bug c++/109362] codegen adds unnecessary extra add when reading atomic member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109362
--- Comment #1 from Barry Revzin ---
Sorry, in this reduced example, it doesn't actually consume an extra register -
only rdi is used.
In this slightly less reduced example:
#include
struct S {
std::atomic size;
std::atomic read_ptr;
auto peek() const -> const char* {
auto const s = size.load(std::memory_order_acquire);
return read_ptr.load(std::memory_order_acquire);
}
};
auto with_atomic(S const& v) {
while (true) {
if (v.peek()) {
return true;
}
}
}
the codegen is:
with_atomic(WithAtomic const&):
lea rdx, [rdi+8]
.L2:
mov rax, QWORD PTR [rdi]
mov rax, QWORD PTR [rdx]
testrax, rax
je .L2
mov eax, 1
ret
which now does consume rdx unnecessarily.
[Bug middle-end/56183] [meta-bug][avr] Problems with register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183 Bug 56183 depends on bug 90706, which changed state. Bug 90706 Summary: [10/11/12/13 Regression] Useless code generated for stack / register operations on AVR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/109104] [13 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1171 with -fzero-call-used-regs=all -march=rv64gv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109104 Yanzhang, Wang changed: What|Removed |Added CC||yanzhang.wang at intel dot com --- Comment #5 from Yanzhang, Wang --- We are still working on it. Hope it can be pushed soon.
[Bug libstdc++/109339] [12/13 Regression] stop_token compiled with -Og yields maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339 --- Comment #12 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a35e8042fbc7a3eb9cece1fba4cdd3b6cdfb906f commit r13-6958-ga35e8042fbc7a3eb9cece1fba4cdd3b6cdfb906f Author: Jonathan Wakely Date: Fri Mar 31 13:38:14 2023 +0100 libstdc++: Avoid -Wmaybe-uninitialized warning in std::stop_source [PR109339] We pass a const-reference to *this before it's constructed, and GCC assumes that all const-references are accessed. Add the access attribute to say it's not accessed. libstdc++-v3/ChangeLog: PR libstdc++/109339 * include/std/stop_token (_Stop_state_ptr(const stop_source&)): Add attribute access with access-mode 'none'. * testsuite/30_threads/stop_token/stop_source/109339.cc: New test.
[Bug target/109093] [13 regression] csmith: a February runtime bug ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093 --- Comment #22 from Jakub Jelinek --- It is true that with r13-6661 + r13-6691 this bug is just latent, so perhaps it doesn't need to be P1 unless somebody comes up with a reproducer.
[Bug target/109087] [13 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109087 --- Comment #18 from Jakub Jelinek --- It is true that with r13-6661 + r13-6691 this bug is just latent, so perhaps it doesn't need to be P1 unless somebody comes up with a reproducer.
[Bug rtl-optimization/109052] Unnecessary reload with -mfpmath=both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052 --- Comment #8 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:e9910e002d610db6e08230583c2976c9a557131b commit r13-6959-ge9910e002d610db6e08230583c2976c9a557131b Author: Vladimir N. Makarov Date: Fri Mar 31 11:04:44 2023 -0400 LRA: Implement commutative operands exchange for combining secondary memory reload and original insn The patch implements trying commutative operands exchange for combining secondary memory reload and original insn. PR rtl-optimization/109052 gcc/ChangeLog: * lra-constraints.cc: (combine_reload_insn): New function. gcc/testsuite/ChangeLog: * gcc.target/i386/pr109052-2.c: New.
[Bug target/109093] csmith: a February runtime bug ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P3 Summary|[13 regression] csmith: a |csmith: a February runtime |February runtime bug ? |bug ?
[Bug libstdc++/105580] [12/13 Regression] warning "potential null pointer dereference" raised when using istreambuf_iterator and any "-O" flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105580 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-03-31 --- Comment #4 from Jonathan Wakely --- (In reply to Jason Merrill from comment #1) > Why does _M_get clear _M_sbuf? Because that's what the standard implies should happen: If the end of stream is reached (streambuf_type::sgetc() returns traits::eof()), the iterator becomes equal to the end-of-stream iterator value." charT operator*() const; 1 Returns: The character obtained via the streambuf member sbuf_->sgetc(). But this means that a dereferenceable iterator can become non-dereferenceable as a result of dereferencing it ... which seems very wrong indeed. It seems better to check for EOF on operator++ and only clear _M_sbuf in that function, but we need to basically rewrite the entire class (without ABI changes) to do that.
[Bug target/109087] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109087 Jakub Jelinek changed: What|Removed |Added Summary|[13 Regression] csmith: end |csmith: end of year runtime |of year runtime bug since |bug since |r13-4839-geef81eefcdc2a581 |r13-4839-geef81eefcdc2a581 Priority|P1 |P3
[Bug c++/109362] codegen adds unnecessary extra add when reading atomic member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109362 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- This got fixed with r13-137-gee1cb43bc76de800efa0ade6 on the trunk.
[Bug c++/109362] codegen adds unnecessary extra add when reading atomic member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109362
--- Comment #3 from Jakub Jelinek ---
Reduced C testcase would be
struct S { long a, b; };
int
foo (struct S *v)
{
while (1)
{
__atomic_load_n (&v->a, __ATOMIC_ACQUIRE);
if (__atomic_load_n (&v->b, __ATOMIC_ACQUIRE))
return 1;
}
}
[Bug c++/109362] codegen adds unnecessary extra add when reading atomic member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109362 --- Comment #4 from Barry Revzin --- Awesome!
[Bug tree-optimization/109363] New: [13 Regression] gcc.dg/tree-ssa/pr23109.c cris-elf reciptmp with r13-6945-g429a7a88438cc8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109363 Bug ID: 109363 Summary: [13 Regression] gcc.dg/tree-ssa/pr23109.c cris-elf reciptmp with r13-6945-g429a7a88438cc8 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: amacleod at redhat dot com Target Milestone: --- Target: cris-elf Created attachment 54799 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54799&action=edit failing pr23109.c.189t.recip (at r13-6956-ge02c9d9116f2) With r13-6944-ga23b33a1bdeff7 this test passed. At r13-6945-g429a7a88438cc8 I see for the first time: FAIL: gcc.dg/tree-ssa/pr23109.c scan-tree-dump-not recip "reciptmp" In gcc.log: Executing on host: /x/cris-elf/gccobj/gcc/xgcc -B/x/cris-elf/gccobj/gcc/ /x/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr23109.c\ -fdiagnostics-plain-output -O2 -funsafe-math-optimizations -ftrapping-math -fdump-tree-recip -fdump-tree-lim2 -S \ -isystem /x/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem /x/gcc/newlib/libc/include -o pr23109.s(timeo\ ut = 300) spawn -ignore SIGHUP /x/cris-elf/gccobj/gcc/xgcc -B/x/cris-elf/gccobj/gcc/ /x/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr23109\ .c -fdiagnostics-plain-output -O2 -funsafe-math-optimizations -ftrapping-math -fdump-tree-recip -fdump-tree-lim2 -S -is\ ystem /x/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem /x/gcc/newlib/libc/include -o pr23109.s^M cc1: warning: '-fassociative-math' disabled; other options take precedence^M PASS: gcc.dg/tree-ssa/pr23109.c at line 3 (test for warnings, line ) PASS: gcc.dg/tree-ssa/pr23109.c (test for excess errors) PASS: gcc.dg/tree-ssa/pr23109.c scan-tree-dump-not lim2 "reciptmp" FAIL: gcc.dg/tree-ssa/pr23109.c scan-tree-dump-not recip "reciptmp" I'm attaching pr23109.c.189t.recip
[Bug c++/109357] [12/13 Regression] internal compiler error in cp/constexpr.cc:1685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109357 Xi Ruoyao changed: What|Removed |Added Target Milestone|--- |12.3 Known to work||11.3.0 CC||xry111 at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2023-03-31 Ever confirmed|0 |1 Summary|GCC 13.0.1: internal|[12/13 Regression] internal |compiler error in |compiler error in |cp/constexpr.cc:1685|cp/constexpr.cc:1685 Known to fail||12.2.0
[Bug c++/109357] [12/13 Regression] internal compiler error in cp/constexpr.cc:1685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109357 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Started with r12-6329-g4f6bc28fc7dd86bd9e7408cbf
[Bug web/109355] Add a text warning to old gcc online manual stating it is out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109355 --- Comment #5 from joseph at codesourcery dot com --- As I mentioned in previous discussions of this idea: any implementation should *not* involve simply editing the old generated files in place; it needs to involve keeping an unmodified copy of those files (which it might not readily be possible to regenerate now with current Texinfo) and having a properly automated process that goes from the unmodified source to the modified version served on the website, with the ability to rerun a new version of that process at any time.
[Bug c++/109364] New: Missing return statement in a non void function gives only a warning but produces a forced crash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364
Bug ID: 109364
Summary: Missing return statement in a non void function gives
only a warning but produces a forced crash.
Product: gcc
Version: 13.0
URL: https://www.reddit.com/r/gcc/comments/123ojov/no_retur
n_in_function_binary_crashes_with/
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: contact at thunderperfectwitchcraft dot org
Target Milestone: ---
Calling
int Test()
{
std::cout << "Test";
}
from main causes the program to crash, even though only a warning is given.
As pointed out in this thread
https://www.reddit.com/r/gcc/comments/123ojov/no_return_in_function_binary_crashes_with/
this is because a invalid instruction is returned to cause the crash to prevent
people from letting out the return statement. But here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43943
it is stated that it should be only a warning since it can work if the return
value isn't used anywhere. This is no longer the case, as there is no way to
bring this code to run as far as I can see. To reduce the confusion it should
be a error by default, everything else is only frustrating.
[Bug c++/43943] "warning: no return statement in function returning non-void" should be an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43943 Andrew Pinski changed: What|Removed |Added CC||contact@thunderperfectwitch ||craft.org --- Comment #9 from Andrew Pinski --- *** Bug 109364 has been marked as a duplicate of this bug. ***
[Bug c++/109364] Missing return statement in a non void function gives only a warning but produces a forced crash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- >it should be only a warning since it can work if the return value isn't used >anywhere No that is for C, for C++: "The point being that it's undefined behaviour to /return/ from such a function, not to /write/ such a function." See comment #5 *** This bug has been marked as a duplicate of bug 43943 ***
