[Bug fortran/111674] [13/14 regression] Failure to finalize an allocatable subobject of a non-finalizable type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111674 --- Comment #3 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:84284e1c490e9235fca5cb85269ecfcb87eef4f1 commit r14-4390-g84284e1c490e9235fca5cb85269ecfcb87eef4f1 Author: Paul Thomas Date: Wed Oct 4 08:26:35 2023 +0100 Fortran: Alloc comp of non-finalizable type not finalized [PR111674] 2023-10-04 Paul Thomas gcc/fortran PR fortran/37336 PR fortran/111674 * trans-expr.cc (gfc_trans_scalar_assign): Finalize components on deallocation if derived type is not finalizable. gcc/testsuite/ PR fortran/37336 PR fortran/111674 * gfortran.dg/allocate_with_source_25.f90: Final count in tree dump reverts from 4 to original 6. * gfortran.dg/finalize_38.f90: Add test for fix of PR111674.
[Bug fortran/37336] [F03] Finish derived-type finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 --- Comment #36 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:84284e1c490e9235fca5cb85269ecfcb87eef4f1 commit r14-4390-g84284e1c490e9235fca5cb85269ecfcb87eef4f1 Author: Paul Thomas Date: Wed Oct 4 08:26:35 2023 +0100 Fortran: Alloc comp of non-finalizable type not finalized [PR111674] 2023-10-04 Paul Thomas gcc/fortran PR fortran/37336 PR fortran/111674 * trans-expr.cc (gfc_trans_scalar_assign): Finalize components on deallocation if derived type is not finalizable. gcc/testsuite/ PR fortran/37336 PR fortran/111674 * gfortran.dg/allocate_with_source_25.f90: Final count in tree dump reverts from 4 to original 6. * gfortran.dg/finalize_38.f90: Add test for fix of PR111674.
[Bug c/111684] enhancement: gcc doesn't warn about pointless tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111684 --- Comment #3 from David Binderman --- (In reply to David Binderman from comment #2) > I've had a quick look at the linux-6.6-rc4 kernel code > and found about a dozen examples of this problem, so there > would be some customers for a solution. A full look suggests there are about 30 examples. Surprising.
[Bug tree-optimization/111668] [12/13/14 Regression] vrp2 (match and simplify) introduces invalid wide signed Boolean values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111668 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7ab01269396203d5200fff8579768da54dcfde5d commit r14-4391-g7ab01269396203d5200fff8579768da54dcfde5d Author: Jakub Jelinek Date: Wed Oct 4 09:27:40 2023 +0200 match.pd: Fix up a ? cst1 : cst2 regression on signed bool [PR111668] My relatively recent changes to these simplifiers to avoid doing build_nonstandard_integer_type (primarily for BITINT_TYPE) broke PR111668, a recurrence of the PR110487 bug. I thought the build_nonstandard_integer_type isn't ever needed there, but there is one special case where it is. For the a ? -1 : 0 and a ? 0 : -1 simplifications there are actually 3 different cases. One is for signed 1-bit precision types (signed kind of implied from integer_all_onesp, because otherwise it would match integer_onep earlier), where the simplifier wierdly was matching them using the a ? powerof2cst : 0 -> a << (log2(powerof2cst)) simplification and then another simplifier optimizing away the left shift when log2(powerof2cst) was 0. Another one is signed BOOLEAN_TYPE with precision > 1, where indeed we shouldn't be doing the negation in type, because it isn't well defined in that type, the type only has 2 valid values, 0 and -1. As an alternative, we could also e.g. cast to signed 1-bit precision BOOLEAN_TYPE and then extend to type. And the last case is what we were doing for types which have both 1 and -1 (all all ones) as valid values (i.e. all signed/unsigned ENUMERAL_TYPEs, INTEGRAL_TYPEs and BITINT_TYPEs with precision > 1). The following patch avoids the hops through << 0 for 1-bit precision and uses build_nonstandard_integer_type solely for the BOOLEAN_TYPE types (where we have a guarantee the precision is reasonably small, nothing ought to be created 129+ bit precision BOOLEAN_TYPEs). 2023-10-04 Jakub Jelinek PR tree-optimization/111668 * match.pd (a ? CST1 : CST2): Handle the a ? -1 : 0 and a ? 0 : -1 cases before the powerof2cst cases and differentiate between 1-bit precision types, larger precision boolean types and other integral types. Fix comment pastos and formatting.
[Bug c++/111690] New: Redefinition of operator == not detected with friend <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111690
Bug ID: 111690
Summary: Redefinition of operator == not detected with friend
<=>
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the example:
```
#include
struct Foo {
friend auto operator<=>(const Foo&, const Foo&) = default;
};
bool operator==(const Foo& x, const Foo& y) noexcept {
return true;
}
void Test() {
Foo{} == Foo{};
}
```
If my reading of [class.compare.default] p4 correct, then an == operator
function is already declared implicitly due to operator<=>.
So there should be an error of redeclaring or redefining the operator==.
Godbolt playground: https://godbolt.org/z/YP5vEMeYs
[Bug middle-end/111369] [14 Regression] ICE in handle_cast, gimple-lower-bitint.cc:1486 with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111369 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:64eeec25f11e31bed844ef0a95ef0f9661c3ab37 commit r14-4392-g64eeec25f11e31bed844ef0a95ef0f9661c3ab37 Author: Jakub Jelinek Date: Wed Oct 4 09:30:15 2023 +0200 match.pd: Avoid other build_nonstandard_integer_type calls [PR111369] In the light of the PR111668 patch which shows that build_nonstandard_integer_type is needed (at least for some signed prec > 1 BOOLEAN_TYPEs if we use e.g. negation), I've reworked this patch and handled the last problematic build_nonstandard_integer_type call in there as well. In the x == cstN ? cst4 : cst3 optimization it uses build_nonstandard_integer_type solely for BOOLEAN_TYPEs (I really don't see why ENUMERAL_TYPEs would be a problem, we treat them in GIMPLE as uselessly convertible to same precision/sign INTEGER_TYPEs), for INTEGER_TYPEs it is really a no-op (might return a different type, but always INTEGER_TYPE with same TYPE_PRECISION same TYPE_UNSIGNED) and for BITINT_TYPE with larger precisions really harmful (we shouldn't create large precision INTEGER_TYPEs). The a?~t:t optimization just omits the negation of a in type for 1-bit precision types or any BOOLEAN_TYPEs. I think that is correct, because for both signed and unsigned 1-bit precision type, cast to type of a bool value yields already 0, -1 or 0, 1 values and for 1-bit precision negation of that is still 0, -1 or 0, 1 (except for invoking sometimes UB). And for signed larger precision BOOLEAN_TYPEs I think it is correct as well, cast of [0, 1] to type yields 0, -1 and those can be xored with 0 or -1 to yield the proper result, any other values would be UB. This fixes PR111369, where one of the bitint*.c tests FAILs with GCC_TEST_RUN_EXPENSIVE=1. 2023-10-04 Jakub Jelinek PR middle-end/111369 * match.pd (x == cstN ? cst4 : cst3): Use build_nonstandard_integer_type only if type1 is BOOLEAN_TYPE. Fix comment typo. Formatting fix. (a?~t:t -> (-(a))^t): Always convert to type rather than using build_nonstandard_integer_type. Perform negation only if type has precision > 1 and is not signed BOOLEAN_TYPE.
[Bug tree-optimization/111668] [12/13 Regression] vrp2 (match and simplify) introduces invalid wide signed Boolean values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111668 Jakub Jelinek changed: What|Removed |Added Summary|[12/13/14 Regression] vrp2 |[12/13 Regression] vrp2 |(match and simplify)|(match and simplify) |introduces invalid wide |introduces invalid wide |signed Boolean values |signed Boolean values --- Comment #7 from Jakub Jelinek --- Fixed on the trunk. No idea about 12/13, I think the problem there is in phiopt instead and we don't really have a reproducer.
[Bug middle-end/111369] [14 Regression] ICE in handle_cast, gimple-lower-bitint.cc:1486 with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111369 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Jakub Jelinek --- Should be fixed now.
[Bug target/111600] [14 Regression] RISC-V bootstrap time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 --- Comment #16 from Robin Dapp --- Confirming that it's the compilation of insn-emit.cc which takes > 10 minutes. The rest (including auto generating of files) is reasonably fast. Going to do some experiments with it and see which pass takes the most time.
[Bug fortran/37336] [F03] Finish derived-type finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 --- Comment #37 from CVS Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:29cd67f93f00cc7a9b08eae4f3e12e67ed568f19 commit r13-7934-g29cd67f93f00cc7a9b08eae4f3e12e67ed568f19 Author: Paul Thomas Date: Wed Oct 4 08:26:35 2023 +0100 Fortran: Alloc comp of non-finalizable type not finalized [PR111674] 2023-10-04 Paul Thomas gcc/fortran PR fortran/37336 PR fortran/111674 * trans-expr.cc (gfc_trans_scalar_assign): Finalize components on deallocation if derived type is not finalizable. gcc/testsuite/ PR fortran/37336 PR fortran/111674 * gfortran.dg/allocate_with_source_25.f90: Final count in tree dump reverts from 4 to original 6. * gfortran.dg/finalize_38.f90: Add test for fix of PR111674. (cherry picked from commit 84284e1c490e9235fca5cb85269ecfcb87eef4f1)
[Bug fortran/111674] [13/14 regression] Failure to finalize an allocatable subobject of a non-finalizable type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111674 --- Comment #4 from CVS Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:29cd67f93f00cc7a9b08eae4f3e12e67ed568f19 commit r13-7934-g29cd67f93f00cc7a9b08eae4f3e12e67ed568f19 Author: Paul Thomas Date: Wed Oct 4 08:26:35 2023 +0100 Fortran: Alloc comp of non-finalizable type not finalized [PR111674] 2023-10-04 Paul Thomas gcc/fortran PR fortran/37336 PR fortran/111674 * trans-expr.cc (gfc_trans_scalar_assign): Finalize components on deallocation if derived type is not finalizable. gcc/testsuite/ PR fortran/37336 PR fortran/111674 * gfortran.dg/allocate_with_source_25.f90: Final count in tree dump reverts from 4 to original 6. * gfortran.dg/finalize_38.f90: Add test for fix of PR111674. (cherry picked from commit 84284e1c490e9235fca5cb85269ecfcb87eef4f1)
[Bug fortran/111674] [13/14 regression] Failure to finalize an allocatable subobject of a non-finalizable type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111674 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Paul Thomas --- Fixed on 13-branch and trunk. Paul
[Bug fortran/37336] [F03] Finish derived-type finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 Bug 37336 depends on bug 111674, which changed state. Bug 111674 Summary: [13/14 regression] Failure to finalize an allocatable subobject of a non-finalizable type https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111674 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/111600] [14 Regression] RISC-V bootstrap time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 --- Comment #17 from rguenther at suse dot de --- On Wed, 4 Oct 2023, rdapp at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 > > --- Comment #16 from Robin Dapp --- > Confirming that it's the compilation of insn-emit.cc which takes > 10 > minutes. > The rest (including auto generating of files) is reasonably fast. Going to do > some experiments with it and see which pass takes the most time. And in which function(s) please. IIRC -Q will announce each function entering post-IPA passses (announce_function), you could eventually dump the current time there as well.
[Bug libstdc++/106201] filesystem::directory_iterator is a borrowable range?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106201 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.3 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Jonathan Wakely --- I'm not planning to backport the workaround to gcc-11, so I'm going to close this as fixed for 12.3
[Bug ipa/111643] __attribute__((flatten)) with -O1 runs out of memory (killed cc1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-10-04
--- Comment #6 from Richard Biener ---
Something like
#pragma GCC inline
foo ();
or
[[gnu::inline]] foo ();
was mentioned a few times but nobody bothered to implement it (setting a flag
on the CALL_EXPR).
Will post/push
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index b4770f1a149..645c76f23e9 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -3109,7 +3109,9 @@ file descriptor opened with @code{O_RDONLY}.
@cindex @code{flatten} function attribute
@item flatten
Generally, inlining into a function is limited. For a function marked with
-this attribute, every call inside this function is inlined, if possible.
+this attribute, every call inside this function is inlined including the
+calls such inlining introduces to the function (but not recursive calls
+to the function itself), if possible.
Functions declared with attribute @code{noinline} and similar are not
inlined. Whether the function itself is considered for inlining depends
on its size and the current inlining parameters.
[Bug tree-optimization/111648] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since r14-3243-ga7dba4a1c05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111648 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/111652] [14 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111652 Richard Biener changed: What|Removed |Added Version|unknown |14.0 Priority|P3 |P1
[Bug bootstrap/111653] make bootstrap4 fails for -fchecking=2 code generation changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111653 --- Comment #1 from Richard Biener --- IMHO we should try harder to make -fchecking=2 _not_ generate different code.
[Bug c/111691] New: [OpenMP][5.2] C/C++ handle 'omp declare variant([base–name:]variant-name)' - i.e. with 'base-name'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111691
Bug ID: 111691
Summary: [OpenMP][5.2] C/C++ handle 'omp declare
variant([base–name:]variant-name)' - i.e. with
'base-name'
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: openmp, rejects-valid
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
OpenMP 5.2 has:
omp declare variant([base–name:]variant-name)
for C/C++/Fortran; in OpenMP 5.1, the 'base-name:' was Fortran, only.
(Example loosely based on
https://github.com/SOLLVE/sollve_vv/blob/master/tests/5.1/declare_variant/test_begin_end_declare_variant.c
)
It seems as if the following should be valid:
void add(int *arr){
for (int i = 0; i < N; i++){ // Base function adds 1 to array values
arr[i] = i+1;
}
}
#pragma omp begin declare variant match(construct={parallel})
void add(int *arr){
#pragma omp for
for (int i = 0; i < N; i++){
arr[i] = i + 2;
}
}
void add_my(int *arr){
#pragma omp for
for (int i = 0; i < N; i++){
arr[i] = i + 3;
}
}
#pragma omp declare variant(add : add_my) match(construct={target})
#pragma omp end declare variant // Note: delimited declare variant ending
here!
[Bug middle-end/111655] [11/12/13/14 Regression] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655 Richard Biener changed: What|Removed |Added Known to work||4.8.5 Target Milestone|--- |11.5 --- Comment #10 from Richard Biener --- And this conservatively has to apply to all FP divisions where we might infer "nonnegative" unless we can also infer !zerop? On the side of replacing all uses I'd error on simply not folding. Note 6.5.5/6 says "In both operations, if the value of the second operand is zero, the behavior is undefined." only remotely implying this doesn't apply to non-integer types (remotely by including modulo behavior in this sentence). Possibly in some other place the C standard makes FP division by zero subject to other rules.
[Bug c++/111660] [14 Regression] Compilation of constexpr function returning enum takes exponential time with -std=c++2a since r14-4140-g6851e3423c2b5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111660 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug bootstrap/111664] [14 regression] Fails to build with mawk (error in gcc/opt-read.awk) after r14-4354-ge4a4b8e983bac8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111664 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
[Bug fortran/111666] [OpenMP] Fortran FE creates too many temporaries for clauses / 'omp target'+'omp team' #teams/#threads optimize_target_teams optimization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111666 --- Comment #1 from Richard Biener --- Why not delay this "evaluate now" to gimplification time?
[Bug tree-optimization/111668] [12/13 Regression] vrp2 (match and simplify) introduces invalid wide signed Boolean values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111668 Richard Biener changed: What|Removed |Added Known to work||14.0 Target Milestone|14.0|12.4
[Bug tree-optimization/111671] [14 Regression] ICE in get_default_value, at tree-ssa-ccp.cc:312
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111671 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-10-04 Target Milestone|--- |14.0 Keywords||ice-on-valid-code Summary|ICE in get_default_value, |[14 Regression] ICE in |at tree-ssa-ccp.cc:312 |get_default_value, at ||tree-ssa-ccp.cc:312 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed. Might be an issue in IPA VRP / ranger not properly normalizing the value part.
[Bug libstdc++/111685] Segfault while sorting on array element address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111685
--- Comment #8 from Jonathan Wakely ---
The standard only defines sorting in terms of comparisons on "every iterator i
pointing to the sequence", which seems to preclude using a temporary object on
the stack that is outside the sequence.
That said, the comparison object seems like nonsense and I don't see any great
need to support this case.
We could define the linear insertion in terms of swaps, something like:
template
_GLIBCXX20_CONSTEXPR
void
__unguarded_linear_insert(_RandomAccessIterator __last,
_Compare __comp)
{
_RandomAccessIterator __next = __last;
--__next;
while (__comp(*__last, __next))
{
std::iter_swap(__last, __next);
__last = __next;
--__next;
}
}
However, that would perform 3N copies, where the current code does N.
Alternatively, find the partition point first and then do N copies, something
like:
template
_GLIBCXX20_CONSTEXPR
void
__unguarded_linear_insert(_RandomAccessIterator __last,
_Compare __comp)
{
_RandomAccessIterator __next = __last;
--__next;
while (__comp(*__last, __next))
--__next;
typename iterator_traits<_RandomAccessIterator>::value_type
__val = _GLIBCXX_MOVE(*__last);
_RandomAccessIterator __prev = __last;
--__prev;
while (__prev != __next)
{
*__last = _GLIBCXX_MOVE(*__prev);
__last = __prev;
}
*__last = _GLIBCXX_MOVE(__val);
}
But this traverses the sequence twice, where the original does it in one
traversal.
[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683 Richard Biener changed: What|Removed |Added Known to fail||13.2.1 --- Comment #2 from Richard Biener --- Just to say, -fno-strict-aliasing -fstack-reuse=none doesn't help. convn_script can be made 'noipa' and still reproduces the failure. -fno-tree-vectorize changes code and result but still differs from -O2.
[Bug other/111686] [13 regression] excess errors in 23_containers/vector/bool/allocator/copy.cc after r13-7931-ge6d26b141bf03a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111686 Richard Biener changed: What|Removed |Added Keywords||diagnostic, testsuite-fail Target Milestone|--- |13.3
[Bug bootstrap/111688] [14 regression] bootstrap failure after r14-4383-g14d0c509898b03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111688 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
[Bug libstdc++/111685] Segfault while sorting on array element address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111685 --- Comment #9 from Jonathan Wakely --- The sketches above are completely untested (and incorrect) but just demonstrating the ideas.
[Bug libstdc++/99327] ENOTSUP macro does not exist on djgpp crt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:6ae7641a3e34dfb79f8538965b48e411d825b90f commit r11-11034-g6ae7641a3e34dfb79f8538965b48e411d825b90f Author: Jonathan Wakely Date: Tue May 11 18:47:18 2021 +0100 libstdc++: Avoid unconditional use of errc::not_supported [PR 99327] The errc::not_supported constant is only defined if ENOTSUP is defined, which is not true for all targets. Many uses of errc::not_supported in the filesystem library do not actually match the intended meaning of ENOTSUP described by POSIX. They should be using ENOSYS instead (i.e. errc::function_not_supported). This change ensures that appropriate error codes are used by the filesystem library. The remaining uses of errc::not_supported are replaced with a call to a new helper function so that an alternative value will be used on targets that don't support errc::not_supported. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/99327 * src/filesystem/ops-common.h (__unsupported): New function to return a suitable error code for missing functionality. (posix::off_t): New typedef. (posix::*): Set errno to ENOSYS instead of ENOTSUP for no-op fallback implementations. (do_copy_file): Replace uses of errc::not_supported. * src/c++17/fs_ops.cc (fs::copy, fs::copy_file, create_dir) (fs::create_directory, fs::create_directory_symlink) (fs::create_hard_link, fs::create_symlink, fs::current_path) (fs::equivalent, do_stat, fs::file_size, fs::hard_link_count) (fs::last_write_time, fs::permissions, fs::read_symlink): Replace uses of errc::not_supported. (fs::resize_file): Qualify off_t. * src/filesystem/ops.cc (fs::copy, fs::copy_file, create_dir) (fs::create_directory, fs::create_directory_symlink) (fs::create_hard_link, fs::create_symlink, fs::current_path) (fs::equivalent, do_stat, fs::file_size, fs::last_write_time) (fs::permissions, fs::read_symlink, fs::system_complete): Replace uses of errc::not_supported. (fs::resize_file): Qualify off_t and enable unconditionally. * testsuite/19_diagnostics/system_error/cons-1.cc: Likewise. (cherry picked from commit 59ffa3e3dba5a7805585c61dd4387c5644249d52)
[Bug libstdc++/104161] Potential Security Vulnerability: remove_all and symbolic link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104161
--- Comment #10 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:5e6ce4031ce6eba3ea8b2b75bcacb869b591b92c
commit r11-11037-g5e6ce4031ce6eba3ea8b2b75bcacb869b591b92c
Author: Jonathan Wakely
Date: Tue Feb 1 22:04:46 2022 +
libstdc++: Fix filesystem::remove_all races [PR104161]
This fixes the remaining filesystem::remove_all race condition by using
POSIX openat to recurse into sub-directories and using POSIX unlinkat to
remove files. This avoids the remaining race where the directory being
removed is replaced with a symlink after the directory has been opened,
so that the filesystem::remove("subdir/file") resolves to "target/file"
instead, because "subdir" has been removed and replaced with a symlink.
The previous patch only fixed the case where the directory was replaced
with a symlink before we tried to open it, but it still used the full
(potentially compromised) path as an argument to filesystem::remove.
The first part of the fix is to use openat when recursing into a
sub-directory with recursive_directory_iterator. This means that opening
"dir/subdir" uses the file descriptor for "dir", and so is sure to open
"dir/subdir" and not "symlink/subdir". (The previous patch to use
O_NOFOLLOW already ensured we won't open "dir/symlink/" here.)
The second part of the fix is to use unlinkat for the remove_all
operation. Previously we used a directory_iterator to get the name of
each file in a directory and then used filesystem::remove(iter->path())
on that name. This meant that any checks (e.g. O_NOFOLLOW) done by the
iterator could be invalidated before the remove operation on that
pathname. The directory iterator contains an open DIR stream, which we
can use to obtain a file descriptor to pass to unlinkat. This ensures
that the file being deleted really is contained within the directory
we're iterating over, rather than using a pathname that could resolve to
some other file.
The filesystem::remove_all function previously used a (non-recursive)
filesystem::directory_iterator for each directory, and called itself
recursively for sub-directories. The new implementation uses a single
filesystem::recursive_directory_iterator object, and calls a new __erase
member function on that iterator. That new __erase member function does
the actual work of removing a file (or a directory after its contents
have been iterated over and removed) using unlinkat. That means we don't
need to expose the DIR stream or its file descriptor to the remove_all
function, it's still encapuslated by the iterator class.
It would be possible to add a __rewind member to directory iterators
too, to call rewinddir after each modification to the directory. That
would make it more likely for filesystem::remove_all to successfully
remove everything even if files are being written to the directory tree
while removing it. It's unclear if that is actually prefereable, or if
it's better to fail and report an error at the first opportunity.
The necessary APIs (openat, unlinkat, fdopendir, dirfd) are defined in
POSIX.1-2008, and in Glibc since 2.10. But if the target doesn't provide
them, the original code (with race conditions) is still used.
This also reduces the number of small memory allocations needed for
std::filesystem::remove_all, because we do not store the full path to
every directory entry that is iterated over. The new filename_only
option means we only store the filename in the directory entry, as that
is all we need in order to use openat or unlinkat.
Finally, rather than duplicating everything for the Filesystem TS, the
std::experimental::filesystem::remove_all implementation now just calls
std::filesystem::remove_all to do the work.
libstdc++-v3/ChangeLog:
PR libstdc++/104161
* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check for dirfd
and unlinkat.
* config.h.in: Regenerate.
* configure: Regenerate.
* include/bits/fs_dir.h (recursive_directory_iterator): Declare
remove_all overloads as friends.
(recursive_directory_iterator::__erase): Declare new member
function.
* include/bits/fs_fwd.h (remove, remove_all): Declare.
* src/c++17/fs_dir.cc (_Dir): Add filename_only parameter to
constructor. Pass file descriptor argument to base constructor.
(_Dir::dir_and_pathname, _Dir::open_subdir, _Dir::do_unlink)
(_Dir::unlink, _Dir::rmdir): Define new member functions.
(directory_iterator): Pass filename_only argument to _Dir
constructor.
(recursive_directory_iterator::_Dir_stack): Adjust constructor
par
[Bug libstdc++/104161] Potential Security Vulnerability: remove_all and symbolic link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104161 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e20b1c711f70d8d251d45694c50c02e66a4d9f7b commit r11-11036-ge20b1c711f70d8d251d45694c50c02e66a4d9f7b Author: Jonathan Wakely Date: Sun Jan 23 21:45:16 2022 + libstdc++: Avoid symlink race in filesystem::remove_all [PR104161] This adds a new internal flag to the filesystem::directory_iterator constructor that makes it fail if the path is a symlink that resolves to a directory. This prevents filesystem::remove_all from following a symlink to a directory, rather than deleting the symlink itself. We can also use that new flag in recursive_directory_iterator to ensure that we don't follow symlinks if the follow_directory_symlink option is not set. This also moves an error check in filesystem::remove_all after the while loop, so that errors from the directory_iterator constructor are reproted, instead of continuing to the filesystem::remove call below. libstdc++-v3/ChangeLog: PR libstdc++/104161 * acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check for fdopendir. * config.h.in: Regenerate. * configure: Regenerate. * src/c++17/fs_dir.cc (_Dir): Add nofollow flag to constructor and pass it to base class constructor. (directory_iterator): Pass nofollow flag to _Dir constructor. (fs::recursive_directory_iterator::increment): Likewise. * src/c++17/fs_ops.cc (do_remove_all): Use nofollow option for directory_iterator constructor. Move error check outside loop. * src/filesystem/dir-common.h (_Dir_base): Add nofollow flag to constructor and when it's set use ::open with O_NOFOLLOW and O_DIRECTORY. * src/filesystem/dir.cc (_Dir): Add nofollow flag to constructor and pass it to base class constructor. (directory_iterator): Pass nofollow flag to _Dir constructor. (fs::recursive_directory_iterator::increment): Likewise. * src/filesystem/ops.cc (remove_all): Use nofollow option for directory_iterator constructor. Move error check outside loop. (cherry picked from commit c8bd4dc8212e43b2f9af08b80df97f90cdb0df4f)
[Bug libstdc++/104161] Potential Security Vulnerability: remove_all and symbolic link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104161 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e742c6baa92403767b4ba8227f34fc7919db28e0 commit r11-11039-ge742c6baa92403767b4ba8227f34fc7919db28e0 Author: Jonathan Wakely Date: Mon Feb 7 23:36:47 2022 + libstdc++: Fix filesystem::remove_all for Windows [PR104161] The recursive_directory_iterator::__erase member was failing for Windows, because the entry._M_type value is always file_type::none (because _Dir_base::advance doesn't populate it for Windows) and top.unlink uses fs::remove which sets an error using the system_category. That meant that ec.value() was a Windows error code and not an errno value, so the comparisons to EPERM and EISDIR failed. Instead of depending on a specific Windows error code for attempting to remove a directory, just use directory_entry::refresh() to query the type first. This doesn't avoid the TOCTTOU races with directory symlinks, but we can't avoid them on Windows without openat and unlinkat, and creating symlinks requires admin privs on Windows anyway. This also fixes the fs::remove_all(const path&) overload, which was supposed to use the same logic as the other overload, but I forgot to change it before my previous commit. libstdc++-v3/ChangeLog: PR libstdc++/104161 * src/c++17/fs_dir.cc (fs::recursive_directory_iterator::__erase): [i_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Refresh entry._M_type member, instead of checking for errno values indicating a directory. * src/c++17/fs_ops.cc (fs::remove_all(const path&)): Use similar logic to non-throwing overload. (fs::remove_all(const path&, error_code&)): Add comments. * src/filesystem/ops-common.h: Likewise. (cherry picked from commit 5750952bec1e632d1f804f4a1bed2f74c0f3b189)
[Bug libstdc++/108178] Filesystem::copy_file can't copy from /proc on Linux machines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108178 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d69407149194e2a7ee20537c76acb1976c8659be commit r11-11048-gd69407149194e2a7ee20537c76acb1976c8659be Author: Jonathan Wakely Date: Tue Mar 21 12:29:08 2023 + libstdc++: Make std::filesystem::copy_file work for procfs [PR108178] The size reported by stat is always zero for some special files such as those under /proc, which means the current copy_file implementation thinks there is nothing to copy. Instead of trusting the stat value, try to read a character from a streambuf and check for EOF. For the backport, we also need to avoid trying to use sendfile when stat reports a zero size, so that we use streambufs to copy the file. libstdc++-v3/ChangeLog: PR libstdc++/108178 * src/filesystem/ops-common.h (do_copy_file): Check for empty files by trying to read a character. * testsuite/27_io/filesystem/operations/copy_file_108178.cc: New test. (cherry picked from commit 07a0e108247f23fcb919c61595adae143f1ea02a)
[Bug libstdc++/97731] terminate called in std::experimental::filesystem::recursive_directory_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97731 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:9eed5712110b63a0021358cbf195d32c5b372638 commit r11-11049-g9eed5712110b63a0021358cbf195d32c5b372638 Author: Jonathan Wakely Date: Tue Feb 1 14:02:56 2022 + libstdc++: Add more tests for filesystem directory iterators The PR 97731 test was added to verify a fix to the Filesystem TS code, but we should also have the same test to avoid similar regressions in the C++17 std::filesystem code. Also add tests for directory_options::follow_directory_symlink libstdc++-v3/ChangeLog: * testsuite/27_io/filesystem/iterators/97731.cc: New test. * testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc: Check follow_directory_symlink option. * testsuite/experimental/filesystem/iterators/recursive_directory_iterator.cc: Likewise. (cherry picked from commit 2dc2f417288d4f0839b4bc01388e676ee343f941)
[Bug libstdc++/99327] ENOTSUP macro does not exist on djgpp crt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327 Jonathan Wakely changed: What|Removed |Added Target Milestone|12.0|11.5 --- Comment #9 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > Should be fixed on trunk. I don't plan to backport this. It turned out that some other backports (including the PR 104161 fixes) were easier with this one in place, so I backported it for 11.5
[Bug libstdc++/104161] Potential Security Vulnerability: remove_all and symbolic link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104161 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.5 --- Comment #12 from Jonathan Wakely --- Fixed for 11.5 and later.
[Bug libstdc++/108178] Filesystem::copy_file can't copy from /proc on Linux machines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108178 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jonathan Wakely --- Fixed for 11.5, 12.4 and 13.2
[Bug target/111616] On Zen2 7% 519.lbm_r regression between g:1d17d58c284fa8c3 (2023-09-14 02:39) and g:c8e9a75085f9725c (2023-09-18 13:09)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111616 Filip Kastl changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Filip Kastl --- I'm not sure which commit fixed the slowdown but it is now gone. 519.lbm_r performance is back to where it was at g:1d17d58c284fa8c3. Marking as fixed.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 111616, which changed state. Bug 111616 Summary: On Zen2 7% 519.lbm_r regression between g:1d17d58c284fa8c3 (2023-09-14 02:39) and g:c8e9a75085f9725c (2023-09-18 13:09) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111616 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/111655] [11/12/13/14 Regression] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655 --- Comment #11 from Alexander Monakov --- (In reply to Richard Biener from comment #10) > And this conservatively has to apply to all FP divisions where we might infer > "nonnegative" unless we can also infer !zerop? Yes, I think the logic in tree_binary_nonnegative_warnv_p is incorrect for floating-point division. Likewise for multiplication: it returns true for 'x * x', but when x is a NaN, 'x * x' is also a NaN (potentially with the same sign). > On the side of replacing all uses I'd error on simply not folding. Yes, as preceding transforms might have duplicated the division already. We can only do such folding very early, when we are sure no duplication might have taken place. > Note 6.5.5/6 says "In both operations, if the value of the second operand is > zero, the behavior is undefined." only remotely implying this doesn't > apply to non-integer types (remotely by including modulo behavior in this > sentence). > > Possibly in some other place the C standard makes FP division by zero subject > to other rules. I think the intention is that Annex F makes it follow IEEE rules (returns an Inf/NaN and sets FE_DIVBYZERO/FE_INVALID), but it doesn't seem to be clearly worded, afaict.
[Bug other/111692] New: ICE in output_constant at varasm:cc:5267 during RTL "final" pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111692
Bug ID: 111692
Summary: ICE in output_constant at varasm:cc:5267 during RTL
"final" pass
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: fkastl at suse dot cz
CC: jamborm at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux
Target: x86_64-linux
Running gcc on a test from the testsuite with -Os and -frounding-math:
gcc src/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_structs.c -Os
-frounding-math
results in an ICE
during RTL pass: final
../src/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_structs.c: In
function ‘avx512f_test’:
../src/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_structs.c:65:1:
internal compiler error: in output_constant, at varasm.cc:5267
65 | }
| ^
0x867e58 output_constant
../../src/gcc/varasm.cc:5267
0x1317655 output_constructor_regular_field
../../src/gcc/varasm.cc:5610
0x1317655 output_constructor
../../src/gcc/varasm.cc:5876
0x1317655 output_constructor_regular_field
../../src/gcc/varasm.cc:5610
0x1317655 output_constructor
../../src/gcc/varasm.cc:5876
0x13190e5 assemble_constant_contents
../../src/gcc/varasm.cc:3621
0x131a3f8 output_constant_def_contents
../../src/gcc/varasm.cc:3666
0x131a67c mark_constants_in_pattern
../../src/gcc/varasm.cc:4241
0x131ef07 mark_constants
../../src/gcc/varasm.cc:4273
0x131ef07 mark_constant_pool
../../src/gcc/varasm.cc:4289
0x131ef07 output_constant_pool
../../src/gcc/varasm.cc:4504
0x131ef07 assemble_start_function(tree_node*, char const*)
../../src/gcc/varasm.cc:1876
0xbfdaa1 rest_of_handle_final
../../src/gcc/final.cc:4236
0xbfdaa1 execute
../../src/gcc/final.cc:4318
This assert fails:
5265
5266 case REAL_TYPE:
5267 gcc_assert (size == thissize);
5268 if (TREE_CODE (exp) != REAL_CST)
5269 error ("initializer for floating value is not a floating
constant");
[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110643 Mathieu Malaterre changed: What|Removed |Added Attachment #56015|0 |1 is obsolete|| --- Comment #16 from Mathieu Malaterre --- Created attachment 56045 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56045&action=edit inf6.cc
[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110643 --- Comment #17 from Mathieu Malaterre --- (In reply to Andrew Pinski from comment #15) > That returns a address to a local variable ... Sorry I am having a hard time driving cvise correctly. Here is the latest version: g++-13 -g -o works inf6.cc -O0 -Wall -Wextra -Werror -Wfatal-errors -> no issue valgrind --error-exitcode=1 ./works -> should only report a memleak clang++-16 -fsanitize=undefined -g -o works0 inf6.cc -Wall -Wextra -Werror -Wfatal-errors -> no issue You can reproduce the abort using: g++-13 -g -o fails inf6.cc -O1 -Wall -Wextra -Werror -Wfatal-errors -> abort Please note that my version of g++-11 & g++-12 compile the TU just fine using -O1. Could you please run a regression to identify which commit along GCC-13 branch introduce the change at least to get the ball rolling ? Thanks !
[Bug target/111600] [14 Regression] RISC-V bootstrap time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 --- Comment #18 from Robin Dapp --- Just finished an initial timing run, sorted, first 10: Time variable usr sys wall GGC phase opt and generate : 567.60 ( 97%) 38.23 ( 87%) 608.13 ( 97%) 22060M ( 90%) callgraph functions expansion : 491.16 ( 84%) 31.48 ( 72%) 524.60 ( 83%) 18537M ( 75%) integration: 90.09 ( 15%) 11.68 ( 27%) 103.25 ( 16%) 13408M ( 54%) tree CFG cleanup : 74.43 ( 13%) 1.02 ( 2%) 74.66 ( 12%) 201M ( 1%) callgraph ipa passes : 70.16 ( 12%) 6.21 ( 14%) 76.66 ( 12%) 2921M ( 12%) tree STMT verifier : 64.03 ( 11%) 3.52 ( 8%) 67.61 ( 11%) 0 ( 0%) tree CCP : 44.78 ( 8%) 2.91 ( 7%) 47.65 ( 8%) 314M ( 1%) integrated RA : 42.82 ( 7%) 0.86 ( 2%) 42.71 ( 7%) 880M ( 4%) `- tree CFG cleanup: 30.57 ( 5%) 0.38 ( 1%) 32.03 ( 5%) 198M ( 1%) `- tree CCP: 29.78 ( 5%) 0.05 ( 0%) 29.87 ( 5%) 168M ( 1%) tree SSA verifier : 28.07 ( 5%) 1.42 ( 3%) 30.91 ( 5%) 0 ( 0%) Per-function sorted expansion time (first 10): insn_code maybe_code_for_pred_indexed_store(int, machine_mode, machine_mode); 3.05 insn_code maybe_code_for_pred_indexed_load(int, machine_mode, machine_mode); 2.68 insn_code maybe_code_for_pred(int, machine_mode); 1.49 rtx_insn* gen_split_4213(rtx_insn*, rtx_def**); 1.33 insn_code maybe_code_for_pred_scalar(rtx_code, machine_mode); 1.18 rtx_insn* gen_split_1266(rtx_insn*, rtx_def**); 0.70 insn_code maybe_code_for_pred_slide(int, machine_mode); 0.51 insn_code maybe_code_for_pred_scalar(int, machine_mode); 0.34 insn_code maybe_code_for_pred_dual_widen(rtx_code, rtx_code, machine_mode); 0.30 insn_code maybe_code_for_pred_dual_widen_scalar(rtx_code, rtx_code, machine_mode); 0.29 Expanding all splitter functions (~8000) takes 214s, so roughly 40% of the expansion time. This we wouldn't get rid of even when not using insn helpers.
[Bug target/111692] ICE in output_constant at varasm:cc:5267 during RTL "final" pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111692
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|other |target
Ever confirmed|0 |1
Last reconfirmed||2023-10-04
--- Comment #1 from Richard Biener ---
Confirmed. We end up with
{(float) 4.8393999835154085303656756877899169921875e+1, (float)
3.92971578290569595992565155029296875e+1, (float)
-3.978772626324556767940521240234375e+2, (float)
3.48499094947017729282379150390625e+3, (float)
-8.3941278976924368180334568023681640625e+0, (float)
-9.32971578290569595992565155029296875e+1, (float)
7.9003552713678800500929355621337890625e+0, (float)
8.493772626324556767940521240234375e+1, (float)
4.8394100167119651450775563716888427734375e+1, (float)
3.931227373675443232059478759765625e+1, (float)
-3.97910002501110429875552654266357421875e+2, (float)
3.484909985448084771633148193359375e+3, (float)
-8.39409998948396751075051724910736083984375e+0, (float)
-9.331227373675443232059478759765625e+1, (float)
7.910142108547152020037174224853515625e+0, (float)
8.49410002501110429875552654266357421875e+1}
because the non-constant CTOR is classified valid by categorize_ctor_elements
during gimplification and initializer_constant_valid_p whose handling
of CASE_CONVERT wasn't updated with some recent changes to output_constant
(ideally both would be merged with a flag indicating analysis vs. actual
output).
[Bug target/111600] [14 Regression] RISC-V bootstrap time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 --- Comment #19 from Richard Biener --- Compiling insn-emit.ii on a x86_64 host with a 13.2 release compiler shows most time is spent in inlining and CFG cleanup (the latter possibly in functions with a very large number of conditionals). For CCP it's interesting that most of the time is spent in ccp_finalize (doing the substitute_and_fold step). That engine was made more and more complicated (instead of getting rid of it ...).
[Bug target/111600] [14 Regression] RISC-V bootstrap time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 --- Comment #20 from Robin Dapp --- Mhm, why is your profile so different from mine? I'm also on an x86_64 host with a 13.2.1 host compiler (Fedora). Is it because of the preprocessed source? Or am I just reading the timing report wrong?
[Bug bootstrap/111688] [14 regression] bootstrap failure after r14-4383-g14d0c509898b03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111688 --- Comment #1 from Martin Jambor --- I was not able to reproduce this error on gcc112 on compile farm (powerpc64le-unknown-linux-gnu).
[Bug c++/111682] valgrind error in tsubst_template_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111682 Patrick Palka changed: What|Removed |Added Last reconfirmed||2023-10-04 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Target Milestone|--- |14.0 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Keywords||ice-on-valid-code CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Likely started with r14-3160-gca2676654736e6, before which we rejected the testcase. With --enable-checking GCC trunk ICEs on the testcase for me: :16:56: internal compiler error: tree check: expected var_decl or function_decl or field_decl or type_decl or concept_decl or template_decl, have ggc_freed in tsubst_template_decl, at cp/pt.cc:14686
[Bug bootstrap/111664] [14 regression] Fails to build with mawk (error in gcc/opt-read.awk) after r14-4354-ge4a4b8e983bac8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111664 --- Comment #4 from CVS Commits --- The master branch has been updated by Kito Cheng : https://gcc.gnu.org/g:027a94cf32be0b53d163e252e3c9e4800ad8f5f4 commit r14-4395-g027a94cf32be0b53d163e252e3c9e4800ad8f5f4 Author: Kito Cheng Date: Mon Oct 2 10:50:42 2023 +0800 options: Prevent multidimensional arrays [PR111664] Multidimensional arrary is gawk extension, and we accidentally introduced that in recent commit[1]. [1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e4a4b8e983bac865eb435b11798e38d633b98942 gcc/ChangeLog: PR bootstrap/111664 * opt-read.awk: Drop multidimensional arrays. * opth-gen.awk: Ditto.
[Bug bootstrap/111688] [14 regression] bootstrap failure after r14-4383-g14d0c509898b03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111688 --- Comment #2 from Martin Jambor --- I made a mistake checking out the correct commit, so please disregard comment #1, I'm trying again.
[Bug ipa/111672] Inappropriate function splitting during pass_split_functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111672 --- Comment #7 from Hanke Zhang --- Created attachment 56046 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56046&action=edit preprocessed source
[Bug ipa/111672] Inappropriate function splitting during pass_split_functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111672 --- Comment #8 from Hanke Zhang --- (In reply to Andrew Pinski from comment #5) > Add -save-temps and attach the resulting .i (or .ii) file. Thank you. I have attached it.
[Bug fortran/111661] [OpenACC] Detach+Attach of DT component gives libgomp: [0x405140,96] is not mapped when running 'acc update' on DT var itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111661 --- Comment #1 from Patrick Bégou --- With tab an instantiation of an r2tab type described above by Tobias Burnus this is what I am doing to enlarge the allocatable tab%val attribute to [n,m] elements with gcc13.2. !$acc exit data delete(tab%val) finalize !$acc exit data delete(tab) finalize deallocate(tab%val) allocate(tab%val(n,m)) tab%dim1=n tab%dim2=m !$acc enter data copyin(tab) !$acc enter data create(tab%val) Previously (with nvfortran or ftn) I was using: !$acc exit data delete(tab%val) finalize deallocate(tab%val) allocate(tab%val(n,m)) tab%dim1=n tab%dim2=m !$acc update device(tab) !$acc enter data create(tab%val) Unfortunatly, as soon as the user defined type contains more that one allocatable attribute and only one should be resized, the workaround is no more usable. The same limitation occur with chained lists uploaded on the GPU if one of the elements contains an attribute allocatable that must be resize: it is no more possible to remove and then offload again the tab component on the GPU.
[Bug bootstrap/111688] [14 regression] bootstrap failure after r14-4383-g14d0c509898b03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111688 --- Comment #3 from seurer at gcc dot gnu.org --- If you need me to try something let me know.
[Bug target/111600] [14 Regression] RISC-V bootstrap time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 --- Comment #21 from Richard Biener --- I have a release checking GCC 13.2 based host compiler, profile ordered similar to yours is the following where 'integration' is inlining callgraph ipa passes : 22.94 ( 12%) 2.24 ( 12%) 25.19 ( 12%) 3307M ( 15%) integration: 51.29 ( 27%) 5.56 ( 29%) 56.75 ( 27%) 12995M ( 59%) tree CFG cleanup : 20.37 ( 11%) 2.05 ( 11%) 22.30 ( 11%) 219M ( 1%) tree CCP : 21.72 ( 11%) 1.19 ( 6%) 22.85 ( 11%) 330M ( 2%) integrated RA : 6.65 ( 4%) 0.62 ( 3%) 6.80 ( 3%) 876M ( 4%) scheduling 2 : 5.21 ( 3%) 0.28 ( 1%) 5.45 ( 3%) 36M ( 0%) TOTAL : 189.12 19.43208.61 21939M
[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110643 --- Comment #18 from psykose --- > Could you please run a regression to identify which commit along GCC-13 > branch introduce the change at least to get the ball rolling ? note that it might not actually be a regression; it's possible the cvise minimisation (above) results in "easy to spot UB in testcase" because the original (non-minimised) program was actually broken because of UB somewhere (with newer gcc then breaking it via new optimisations), just with it being harder to find. knowing which commit causes the final bad output may or may not help find that, if it's the case. the investigation hasn't concluded quite yet.
[Bug other/111686] [13 regression] excess errors in 23_containers/vector/bool/allocator/copy.cc after r13-7931-ge6d26b141bf03a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111686 --- Comment #1 from Jonathan Wakely --- That's been failing for a while for me, and I don't think it can possibly be related to that commit.
[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 Jonathan Wakely changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #6 from Jonathan Wakely --- *** Bug 111686 has been marked as a duplicate of this bug. ***
[Bug other/111686] [13 regression] excess errors in 23_containers/vector/bool/allocator/copy.cc after r13-7931-ge6d26b141bf03a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111686 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jonathan Wakely --- It's the same warning as PR 109353 so I don't think it's new. *** This bug has been marked as a duplicate of bug 109353 ***
[Bug c++/111690] Redefinition of operator == not detected with friend <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111690 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-10-04
[Bug bootstrap/111664] [14 regression] Fails to build with mawk (error in gcc/opt-read.awk) after r14-4354-ge4a4b8e983bac8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111664 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #5 from David Binderman --- I saw this also on a raspberry pi that uses mawk. I think there is still some value in testing patches in a couple of very different places to help increase portability of code. After the correcting patch, all appears to be in order on the pi.
[Bug target/111600] [14 Regression] RISC-V bootstrap time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 --- Comment #22 from Robin Dapp --- Ah, then it's not that different, your machine is just faster ;) callgraph ipa passes : 69.77 ( 11%) 5.97 ( 13%) 76.05 ( 12%) 2409M ( 10%) integration: 91.95 ( 15%) 12.52 ( 27%) 105.93 ( 16%) 13408M ( 56%) tree CFG cleanup : 76.98 ( 13%) 1.09 ( 2%) 78.01 ( 12%) 201M ( 1%) tree STMT verifier : 66.62 ( 11%) 3.75 ( 8%) 68.31 ( 10%) 0 ( 0%) integrated RA : 47.04 ( 8%) 1.00 ( 2%) 47.79 ( 7%) 879M ( 4%) tree CCP : 44.31 ( 7%) 3.00 ( 6%) 48.39 ( 7%) 314M ( 1%) tree SSA verifier : 31.40 ( 5%) 1.60 ( 3%) 32.25 ( 5%) 0 ( 0%) CFG verifier : 14.93 ( 2%) 0.74 ( 2%) 16.53 ( 3%) 0 ( 0%) callgraph verifier : 14.26 ( 2%) 1.07 ( 2%) 15.55 ( 2%) 0 ( 0%) tree operand scan : 12.58 ( 2%) 3.73 ( 8%) 15.14 ( 2%) 1649M ( 7%) verify RTL sharing : 11.70 ( 2%) 0.89 ( 2%) 13.31 ( 2%) 0 ( 0%) TOTAL : 609.73 46.53659.45 24127M FWIW we are much faster with -fno-inline (somewhat expected but I didn't expect a factor of 3): callgraph ipa passes : 53.47 ( 27%) 5.84 ( 26%) 59.52 ( 26%) 2231M ( 26%) tree STMT verifier : 19.67 ( 10%) 1.95 ( 9%) 21.47 ( 10%) 0 ( 0%) tree SSA verifier : 11.80 ( 6%) 1.20 ( 5%) 13.32 ( 6%) 0 ( 0%) integrated RA : 8.73 ( 4%) 0.72 ( 3%) 9.83 ( 4%) 898M ( 10%) verify RTL sharing : 7.90 ( 4%) 0.69 ( 3%) 8.49 ( 4%) 0 ( 0%) scheduling 2 : 7.32 ( 4%) 0.31 ( 1%) 7.90 ( 4%) 43M ( 1%) tree PTA : 6.68 ( 3%) 0.69 ( 3%) 7.51 ( 3%) 71M ( 1%) CFG verifier : 6.67 ( 3%) 0.81 ( 4%) 7.29 ( 3%) 0 ( 0%) rest of compilation: 6.42 ( 3%) 0.93 ( 4%) 6.88 ( 3%) 89M ( 1%) parser function body : 6.35 ( 3%) 2.13 ( 9%) 8.40 ( 4%) 903M ( 11%) TOTAL : 201.12 22.90225.17 8575M
[Bug bootstrap/111688] [14 regression] bootstrap failure after r14-4383-g14d0c509898b03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111688 Martin Jambor changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-10-04 --- Comment #4 from Martin Jambor --- OK, so now confirmed (on gcc120 from compile farm) but it also fails with 14d0c509898 reverted. I'll try reverting 1be18ea110a instead.
[Bug middle-end/111669] bogus -Wnonnull in conditionally executed code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111669 --- Comment #3 from Zeb Figura --- (In reply to Xi Ruoyao from comment #2) > (In reply to Xi Ruoyao from comment #1) > > The warning given for the reduced test case is correct because it does not > > make sense. It should be just rewritten as > > I mean, the code does not make sense. > > And the warning is given exactly because GCC is optimizing the strcpy call > to unreachable. If GetWindowsDirectoryA() was idempotent, and GetSystemDirectory16() had no other users, that might be true, but as it is I don't think so. The pattern both of those functions call is, much like snprintf(), you pass a buffer and a size, and if the size is 0 then they'll return the size that would have been written if there was a large enough buffer. In that case the buffer can be NULL. In trying to reduce the test case down to the minimal possible complexity I obscured that fact, but regardless I don't think the reduced testcase is nonsensical.
[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110643 --- Comment #19 from Andrew Pinski --- Hmm, adding -fwrapv allows the testcase to pass ...
[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110643
--- Comment #20 from Andrew Pinski ---
With -fwrapv:
_87 = _92 * 2;
NativeSet___trans_tmp_3 = { -2 };
_84 = _87 == -2;
Without:
_84 = _92 == -1;
I think that is correct ...
[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110643 --- Comment #21 from Andrew Pinski --- That is the code in IsInf causes the difference ...
[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110643
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |MOVED
Status|WAITING |RESOLVED
--- Comment #22 from Andrew Pinski ---
template
HWY_API Mask128 IsInf(const Vec128 v) {
const DFromV d;
const RebindToSigned di;
const VFromD vi = BitCast(di, v);
// 'Shift left' to clear the sign bit, check for exponent=max and mantissa=0.
return RebindMask(d, Eq(Add(vi, vi), Set(di, hwy::MaxExponentTimes2(;
}
Most likely should have been:
```
template
HWY_API Mask128 IsInf(const Vec128 v) {
const DFromV d;
const RebindToUnsigned du;
const VFromD vi = BitCast(du, v);
// 'Shift left' to clear the sign bit, check for exponent=max and mantissa=0.
return RebindMask(d, Eq(Add(vi, vi), Set(du, hwy::MaxExponentTimes2(;
}
```
I noticed the bug happens in other places in highway for other targets too
(including x86_64).
this code is undefined due to an signed integer overflow and that is why using
unsigned is needed.
Yes -fsanitize=undefined does not currently work for vectors (that is a known
limitation).
[Bug rtl-optimization/110701] [14 Regression] Wrong code at -O1/2/3/s on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110701 --- Comment #8 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:263369b2f7f726a3d4b269678d2c13a9d06a041e commit r14-4398-g263369b2f7f726a3d4b269678d2c13a9d06a041e Author: Roger Sayle Date: Wed Oct 4 17:11:23 2023 +0100 PR rtl-optimization/110701: Fix SUBREG SET_DEST handling in combine. This patch is my proposed fix to PR rtl-optimization 110701, a latent bug in combine's record_dead_and_set_regs_1 exposed by recent improvements to simplify_subreg. The issue involves the handling of (normal) SUBREG SET_DESTs as in the instruction: (set (subreg:HI (reg:SI x) 0) (expr:HI y)) The semantics of this are that the bits specified by the SUBREG are set to the SET_SRC, y, and that the other bits of the SET_DEST are left/become undefined. To simplify explanation, we'll only consider lowpart SUBREGs (though in theory non-lowpart SUBREGS could be handled), and the fact that bits outside of the lowpart WORD retain their original values (treating these as undefined is a missed optimization rather than incorrect code bug, that only affects targets with less than 64-bit words). The bug is that combine simulates the behaviour of the above instruction, for calculating nonzero_bits and set_sign_bit_copies, in the function record_value_for_reg, by using the equivalent of: (set (reg:SI x) (subreg:SI (expr:HI y)) by calling gen_lowpart on the SET_SRC. Alas, the semantics of this revised instruction aren't always equivalent to the original. In the test case for PR110701, the original instruction (set (subreg:HI (reg:SI x), 0) (and:HI (subreg:HI (reg:SI y) 0) (const_int 340))) which (by definition) leaves the top bits of x undefined, is mistakenly considered to be equivalent to (set (reg:SI x) (and:SI (reg:SI y) (const_int 340))) where gen_lowpart's freedom to do anything with paradoxical SUBREG bits, has now cleared the high bits. The same bug also triggers when the SET_SRC is say (subreg:HI (reg:DI z)), where gen_lowpart transforms this into (subreg:SI (reg:DI z)) which defines bits 16-31 to be the same as bits 16-31 of z. The fix is that after calling record_value_for_reg, we need to mark the bits that should be undefined as undefined, in case gen_lowpart, which performs transforms appropriate for r-values, has changed the interpretation of the SUBREG when used as an l-value. 2023-10-04 Roger Sayle gcc/ChangeLog PR rtl-optimization/110701 * combine.cc (record_dead_and_set_regs_1): Split comment into pieces placed before the relevant clauses. When the SET_DEST is a partial_subreg_p, mark the bits outside of the updated portion of the destination as undefined. gcc/testsuite/ChangeLog PR rtl-optimization/110701 * gcc.target/i386/pr110701.c: New test case.
[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110643 --- Comment #23 from Andrew Pinski --- Note even though the optimization was in GCC 11+ (r11-2550-gca2b8c082c4f added it), only GCC 13+ hits it in this case as GCC 13 lowers the vector comparison and uses the scalar for the one element signed 64bit long. I have not looked into which revision changed the behavior there though. But as I mentioned this is not a GCC bug really.
[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #3 from Alexander Monakov --- This is predcom. It's easier to see what's going wrong with #pragma GCC unroll 99 added to the innermost loop so it's unrolled at -O2 and comparing g++ -O2 -fpredictive-commoning --param=max-unroll-times=1 vs. plain g++ -O2 (or diffing 'pcom' dump against the preceding pass).
[Bug c/111693] New: Online manual mentions -Wuse-after-free but does not document it further
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111693 Bug ID: 111693 Summary: Online manual mentions -Wuse-after-free but does not document it further Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jonathan.leffler at gmail dot com Target Milestone: --- In the 13.2.0 documentation (https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Warning-Options.html), the list of options enabled by "-Wall" includes "-Wuse-after-free=2", but there is no further mention of the option on the page. Similarly, in the 12.3.0 documentation (https://gcc.gnu.org/onlinedocs/gcc-12.3.0/gcc/Warning-Options.html), the list of options enabled by "-Wall" includes "-Wuse-after-free=3", but there is no further mention of the option on the page. It is not mentioned at all in earlier manuals, presumably because it wasn't available in the earlier versions. It would be helpful to know what the values 2 and 3 mean, and presumably what 1 and 0 mean too.
[Bug web/111694] New: Wrong behavior for signbit of negative zero when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694
Bug ID: 111694
Summary: Wrong behavior for signbit of negative zero when
optimizing
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: web
Assignee: unassigned at gcc dot gnu.org
Reporter: alonzakai at gmail dot com
Target Milestone: ---
This behaves incorrectly in 13.2.0 with -O1 and above, but is correct in 12,
11, and 10. It is also correct in 13.2.0 without optimizations.
Testcase:
#include
#include
void test(double l, double r) {
if (l == r && l == 0 && (signbit(l) || signbit(r))) {
puts("one is negative");
}
}
int main() {
test(0.0, -0.0);
test(-0.0, 0.0);
}
This should print "one is negative" twice, but only does so once in 13.2.0 with
-O1:
$ gcc-13 a.c -O1 ; ./a.out
one is negative
$ gcc-13 a.c -O0 ; ./a.out
one is negative
one is negative
$
[Bug bootstrap/111688] [14 regression] bootstrap failure after r14-4383-g14d0c509898b03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111688 --- Comment #5 from Martin Jambor --- Yeah, that seems to be it. If I cannot fix this tomorrow I'll revert the patch from master.
[Bug libstdc++/111685] Segfault while sorting on array element address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111685
--- Comment #10 from Fedor Chelnokov ---
It seems that both libc++ and MS STL implement std::sort without a temporary
object passed to cmp, because they are fine with compiling the following code
in constant expression (where unrelated pointers cannot be compared):
consteval void foo() {
std::array nums{1, 5, 4};
auto cmp = [](auto& a, auto& b) { return &a < &b; };
std::sort(nums.begin(), nums.end(), cmp);
}
Online demo: https://godbolt.org/z/jdecfP6c4
Is it right that their implementations are less optimal because of no temporary
object?
[Bug c/111695] New: Spurious -Wuse-after-free when managing two arrays in parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111695 Bug ID: 111695 Summary: Spurious -Wuse-after-free when managing two arrays in parallel Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jonathan.leffler at gmail dot com Target Milestone: --- Created attachment 56047 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56047&action=edit Variation 1 (two arrays in parallel) Related to meta-bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075 (bogus/missing -Wuse-after-free). Related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106578 (spurious -Wuse-after-free=2 after conditional free() when not optimizing), but the symptoms are different. There are 4 (smallish) source files. Files gcc-bug-1.c and gcc-bug-3.c use one algorithm for handling old and new values; files gcc-bug-2.c and gcc-bug-4.c use a slight different algorithm. Files gcc-bug-1.c and gcc-bug-2.c manage two arrays 'in parallel' — the names and sizes arrays are handled by separate allocations using the same size controls and report spurious 'use-after-free' errors. Files gcc-bug-3.c and gcc-bug-4.c manage a single array and do not report any (spurious) 'use-after-free' error. The problem reproduces with GCC 13.2.0 and also with GCC 12.2.0. Since there is no mention of -Wuse-after-free in the GCC 11 manual (or any earlier versions), there is no surprise that none of them report the error. Compiler version information: gcc -v -std=c11 -O3 -Werror -Wall -c gcc-bug-1.c Using built-in specs. COLLECT_GCC=gcc Target: x86_64-pc-linux-gnu Configured with: ../gcc-13.2.0/configure --prefix=/usr/gcc/v13.2.0 CC=/usr/gcc/v12.2.0/bin/gcc CXX=/usr/gcc/v12.2.0/bin/g++ Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.2.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-std=c11' '-O3' '-Werror' '-Wall' '-c' '-mtune=generic' '-march=x86-64' /work1/gcc/v13.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.2.0/cc1 -quiet -v -iprefix /work1/gcc/v13.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/ gcc-bug-1.c -quiet -dumpbase gcc-bug-1.c -dumpbase-ext .c -mtune=generic -march=x86-64 -O3 -Werror -Wall -std=c11 -version -o /tmp/ccX3ka4K.s GNU C11 (GCC) version 13.2.0 (x86_64-pc-linux-gnu) compiled by GNU C version 13.2.0, GMP version 6.3.0, MPFR version 4.2.0, MPC version 1.3.1, isl version isl-0.24-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/work1/gcc/v13.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/include" ignoring duplicate directory "/work1/gcc/v13.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/13.2.0/include" ignoring duplicate directory "/work1/gcc/v13.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/13.2.0/include-fixed" ignoring nonexistent directory "/work1/gcc/v13.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /work1/gcc/v13.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/include /work1/gcc/v13.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/include-fixed /usr/local/include /work1/gcc/v13.2.0/bin/../lib/gcc/../../include /usr/include End of search list. Compiler executable checksum: 76c675c9da56a319124364c69f2f4d48 Reported errors (gcc-bug-1.c): gcc-bug-1.c: In function ‘function’: gcc-bug-1.c:34:21: error: pointer ‘names’ may be used after ‘realloc’ [-Werror=use-after-free] 34 | free(old_names); | ^~~ gcc-bug-1.c:28:21: note: call to ‘realloc’ here 28 | names = realloc(names, max_names * sizeof(names[0])); | ^~~~ gcc-bug-1.c:38:21: error: pointer ‘sizes’ may be used after ‘realloc’ [-Werror=use-after-free] 38 | free(old_sizes); | ^~~ gcc-bug-1.c:29:21: note: call to ‘realloc’ here 29 | sizes = realloc(sizes, max_names * sizeof(sizes[0])); | ^~~~ cc1: all warnings being treated as errors Reported errors (gcc-bug-2.c): gcc -std=c11 -O3 -Werror -Wall -c gcc-bug-2.c gcc-bug-2.c: In function ‘function’: gcc-bug-2.c:32:21: error: pointer ‘names’ may be used after ‘realloc’ [-Werror=use-after-free] 32 | free(names); | ^~~ gcc-bug-2.c:26:32: note: call to ‘realloc’ here 26 | char **new_names = realloc(names, max_names * sizeof(names[0])); | ^~~~ gcc-bug-2.c:36:21: error: pointer ‘sizes’ may be used after ‘realloc’ [-Werror=use-after-free]
[Bug c/111695] Spurious -Wuse-after-free when managing two arrays in parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111695 Jonathan Leffler changed: What|Removed |Added CC||jonathan.leffler at gmail dot com --- Comment #1 from Jonathan Leffler --- Created attachment 56048 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56048&action=edit gcc-bug-2.c — Variation 2 (two arrays in parallel)
[Bug c/111695] Spurious -Wuse-after-free when managing two arrays in parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111695 --- Comment #2 from Jonathan Leffler --- Created attachment 56049 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56049&action=edit gcc-bug-3.c — Variation 3 (one array: does not generate -Wuse-after-free warnings)
[Bug c/111695] Spurious -Wuse-after-free when managing two arrays in parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111695 --- Comment #3 from Jonathan Leffler --- Created attachment 56050 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56050&action=edit gcc-bug-4.c — Variation 4 (one array — does not generate -Wuse-after-free warnings)
[Bug c/111695] Spurious -Wuse-after-free when managing two arrays in parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111695 Jonathan Leffler changed: What|Removed |Added Attachment #56047|0 |1 is obsolete|| --- Comment #4 from Jonathan Leffler --- Created attachment 56051 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56051&action=edit gcc-bug-1.c — Variatoion 1 (two arrays in parallel)
[Bug middle-end/111696] New: [11/12/13/14 Regression] Spurious -Wstringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111696 Bug ID: 111696 Summary: [11/12/13/14 Regression] Spurious -Wstringop-overflow Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: stilor at att dot net Target Milestone: --- Created attachment 56052 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56052&action=edit test case The attached testcase started producing a warning beginning with commit 8d57bdadd2d9c2e5c95515ca7a583d7b407b55c4 when compiled with `-O3` (or `-O2 -ftree-slp-vectorize`). Starting with commit 2b8453c401b699ed93c085d0413ab4b5030bcdb8, vectorization is also enabled at `-O2` and the testcase starting failing at `-O2` as well. The warning can be reproduced at current HEAD (96557ee6a0a234821af865800d22621efa6e7390) as well. Failure message: $ /usr/gcc-test/bin/gcc -c -O3 -Wall -Werror stringop-overflow-bug-gcc.c stringop-overflow-bug-gcc.c: In function ‘update’: stringop-overflow-bug-gcc.c:25:3: error: writing 24 bytes into a region of size 16 [-Werror=stringop-overflow=] 25 | memcpy(&last->s, &cur.s, sizeof(struct nested)); | ^~~ stringop-overflow-bug-gcc.c:10:17: note: destination object ‘a’ of size 16 10 | unsigned long a[2]; | ^ cc1: all warnings being treated as errors $ /usr/gcc-test/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/gcc-test/bin/gcc COLLECT_LTO_WRAPPER=/usr/gcc-test/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --enable-languages=c --prefix=/usr/gcc-test --disable-bootstrap Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.1 20210303 (experimental) (GCC) The message is bogus: - the "note" points to a member inside a structure and references that member's size while memcpy has the whole structure as a destination. - commenting out any of the first two statements in the update() function removes the warning even though it has no effect on the addresses passed to memcpy().
[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Component|web |tree-optimization
Summary|Wrong behavior for signbit |[13/14 Regression] Wrong
|of negative zero when |behavior for signbit of
|optimizing |negative zero when
||optimizing
Keywords||wrong-code
--- Comment #1 from Alexander Monakov ---
Reduced:
#define signbit(x) __builtin_signbit(x)
static void test(double l, double r)
{
if (l == r && (signbit(l) || signbit(r)))
;
else
__builtin_abort();
}
int main()
{
test(0.0, -0.0);
}
[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.3 Ever confirmed|0 |1 Last reconfirmed||2023-10-04 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed. EVRP removes the second __bultin_signbit incorrectly. Most likely due to: ``` Folding statement: if (_3 != 0) Registering value_relation (l_11(D) == r_12(D)) on (2->3) ``` which then we get: ``` Predicate evaluates to: DON'T KNOW Matching expression match.pd:2679, gimple-match-2.cc:35 Matching expression match.pd:2682, gimple-match-1.cc:66 Matching expression match.pd:2689, gimple-match-2.cc:96 Not folded Folding statement: _20 = __builtin_signbit (r_12(D)); Queued stmt for removal. Folds to: 0 Folding statement: if (_20 != 0) gimple_simplified to if (0 != 0) gimple_simplified to if (0 != 0) Folded into: if (0 != 0) ``` For -O1 DOM does: ``` 1>>> STMT 1 = _8 le_expr 0 1>>> STMT 1 = _8 ge_expr 0 1>>> STMT 1 = _8 eq_expr 0 1>>> STMT 0 = _8 ne_expr 0 0>>> COPY _8 = 0 Optimizing statement _10 = __builtin_signbit (r_6(D)); Replaced 'r_6(D)' with constant '0.0' gimple_simplified to _10 = 0; Folded to: _10 = 0; LKUP STMT _10 = 0 ASGN _10 = 0 Optimizing statement if (_10 != 0) Replaced '_10' with constant '0' gimple_simplified to if (0 != 0) Folded to: if (0 != 0) LKUP STMT 0 ne_expr 0 STMT 0 = _8 ne_expr 0 STMT 1 = _8 eq_expr 0 STMT 1 = _8 ge_expr 0 STMT 1 = _8 le_expr 0 COPY _8 = 0 ``` Which is wrong too.
[Bug tree-optimization/111697] New: Sub optimal code gen for initialising vector using loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111697
Bug ID: 111697
Summary: Sub optimal code gen for initialising vector using
loop
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: prathamesh3492 at gcc dot gnu.org
Target Milestone: ---
Hi,
For the following test-case:
typedef int v4si __attribute__((vector_size (sizeof (int) * 4)));
v4si f(int x)
{
v4si v;
for (int i = 0; i < 4; i++)
v[i] = x;
return v;
}
Compiling with -O2 results in following .optimized dump:
v4si f (int x)
{
v4si v;
[local count: 214748368]:
v_16 = BIT_INSERT_EXPR ;
v_20 = BIT_INSERT_EXPR ;
v_24 = BIT_INSERT_EXPR ;
v_2 = BIT_INSERT_EXPR ;
return v_2;
}
and following code-gen on aarch64:
f:
moviv0.4s, 0
fmovs31, w0
ins v0.s[0], v31.s[0]
ins v0.s[1], v31.s[0]
ins v0.s[2], v31.s[0]
ins v0.s[3], v31.s[0]
ret
which could instead be a single dup instruction:
f:
dup v0.4s, w0
ret
Similarly, code-gen on x86_64:
f:
movd%edi, %xmm0
movd%edi, %xmm1
pshufd $225, %xmm0, %xmm0
movss %xmm1, %xmm0
pshufd $225, %xmm0, %xmm0
pshufd $198, %xmm0, %xmm0
movss %xmm1, %xmm0
pshufd $198, %xmm0, %xmm0
pshufd $39, %xmm0, %xmm0
movss %xmm1, %xmm0
pshufd $39, %xmm0, %xmm0
ret
[Bug tree-optimization/111697] Sub optimal code gen for initialising vector using loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111697 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-10-04 --- Comment #1 from Andrew Pinski --- Confirmed. PR 58497 is basically the same issue in the end. I had patches for this but I was not 100% sure it was handling that in a decent location.
[Bug c/111693] Online manual mentions -Wuse-after-free but does not document it further
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111693 --- Comment #1 from Andrew Pinski --- Documented here: https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/C_002b_002b-Dialect-Options.html#index-Wuse-after-free
[Bug c/111693] Online manual mentions -Wuse-after-free but does not document it further
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111693 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- Other warnings are documented on that page too.
[Bug c/111693] Online manual mentions -Wuse-after-free but does not document it further
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111693 --- Comment #3 from Andrew Pinski --- The easiest way to find documentation for an option is to look at the index located at: https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Option-Index.html And search for the option.
[Bug c/111693] Online manual mentions -Wuse-after-free but does not document it further
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111693 --- Comment #4 from Jonathan Leffler --- The link https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/C_002b_002b-Dialect-Options.html#index-Wuse-after-free is to the "Options Controlling C++ Dialect". I was using the C compiler, not the C++ compiler, so it is not at all obvious that I should look at that page — in fact, that page is irrelevant to users of the C compiler. The information there should be either copied to the C "Warnings Options" page, or linked to from the C page, where -Wuse-after-free is only mentioned and not defined. Incidentally, under "-Wuse-after-free=1" on the C++ page, there's a typo in: whether or not the call resulted in an actual reallocatio of memory The 'n' is missing from 'reallocation'.
[Bug c/111693] Online manual mentions -Wuse-after-free but does not document it further
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111693 --- Comment #5 from Jonathan Leffler --- The link https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/C_002b_002b-Dialect-Options.html#index-Wuse-after-free is to the "Options Controlling C++ Dialect". I was using the C compiler, not the C++ compiler, so it is not at all obvious that I should look at that page — in fact, that page is irrelevant to users of the C compiler. The information there should be either copied to the C "Warnings Options" page, or linked to from the C page, where -Wuse-after-free is only mentioned and not defined. Incidentally, under "-Wuse-after-free=1" on the C++ page, there's a typo in: whether or not the call resulted in an actual reallocatio of memory The 'n' is missing from 'reallocation'.
[Bug c/111693] Online manual mentions -Wuse-after-free but does not document it further
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111693 Jonathan Leffler changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #6 from Jonathan Leffler --- Apologies for the double comment — I got a "mid-air collision" message and wasn't at all sure how to deal with that.
[Bug c/111693] -Wuse-after-free is documented in the wrong location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111693 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-10-04 Summary|Online manual mentions |-Wuse-after-free is |-Wuse-after-free but does |documented in the wrong |not document it further |location Keywords||documentation Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #7 from Andrew Pinski --- Oh yes -Wuse-after-free documentation should be moved. There are some others which are also misplaced (Wuseless-cast)
[Bug c/111693] -Wuse-after-free is documented in the wrong location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111693 --- Comment #8 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #3) > The easiest way to find documentation for an option is to look at the index > located at: > https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Option-Index.html > > And search for the option. You should also be able to find it in the option summary: https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Option-Summary.html But it's not there.
[Bug c/111693] -Wuse-after-free is documented in the wrong location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111693 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=71283 --- Comment #9 from Eric Gallager --- related: bug 71283
[Bug target/111698] New: Narrow memory access of compare to byte width
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111698
Bug ID: 111698
Summary: Narrow memory access of compare to byte width
Product: gcc
Version: 12.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
Following testcase:
--cut here--
int m;
_Bool foo (void)
{
return m & 0x0f;
}
--cut here--
compiles to:
0: f7 05 00 00 00 00 00testl $0xf,0x0(%rip)
7: 00 0f 00
The test instruction can be demoted to byte test from addr+2.
Currently, the demotion works for lowest byte, so the testcase:
--cut here--
int m;
_Bool foo (void)
{
return m & 0x0f;
}
--cut here--
compiles to:
0: f6 05 00 00 00 00 0ftestb $0xf,0x0(%rip)
which is three bytes shorter.
Any half-way modern Intel and AMD cores will forward any fully contained load,
so there is no danger of forwarding stall with recent CPU cores.
[Bug tree-optimization/98138] BB vect fail to SLP one case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98138 --- Comment #12 from Jiangning Liu --- Hi Richi, > That said, "failure" to identify the common (vector) load is known > and I do have experimental patches trying to address that but did > not yet arrive at a conclusive "best" approach. It was long time ago, so do you have the "best" approach now? Thanks, -Jiangning
