[Bug target/111670] H8/300 SX uses incorrect code sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111670 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 Target||h8300
[Bug target/111670] New: H8/300 SX uses incorrect code sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111670 Bug ID: 111670 Summary: H8/300 SX uses incorrect code sequences Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: law at gcc dot gnu.org Target Milestone: --- The H8/SX port can create sequences like (set (mem (autoinc (reg sp)) (reg_sp)) Here autoinc is PRE_DECEMENT or PRE_INCREMENT addressing modes. Which is invalid RTL. I believe this is the root cause of the following H8/SX failures in the testsuite: h8300-sim/-msx/-mint32: gcc.c-torture/execute/920501-6.c -O1 execution test h8300-sim/-msx/-mint32: gcc.c-torture/execute/920501-6.c -Os execution test h8300-sim/-msx/-mint32: gcc.c-torture/execute/pr20466-1.c -O1 execution test h8300-sim/-msx/-mint32: gcc.c-torture/execute/pr20466-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test h8300-sim/-msx/-mint32: gcc.c-torture/execute/pr20466-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test h8300-sim/-msx/-mint32: gcc.c-torture/execute/pr39339.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test h8300-sim/-msx/-mint32: gcc.c-torture/execute/ssad-run.c -O1 execution test h8300-sim/-msx/-mint32: gcc.c-torture/execute/ssad-run.c -Os execution test h8300-sim/-msx/-mint32: gcc.c-torture/execute/usad-run.c -O1 execution test h8300-sim/-msx/-mint32: gcc.c-torture/execute/usad-run.c -Os execution test I suspect we need to break the "Q" constraint into two variants. One which allows autoinc addressing modes and the other does not. For movsi/movhi we would use the version which does not allow autoinc addressing modes and instead use the Z0/ZA approach like the other H8 variants are using. I'm not currently working on this.
[Bug middle-end/111669] New: bogus -Wnonnull in conditionally executed code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111669 Bug ID: 111669 Summary: bogus -Wnonnull in conditionally executed code Product: gcc Version: 13.2.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: zfigura at codeweavers dot com Target Milestone: --- Created attachment 56032 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56032&action=edit reduced testcase, compile with -O2 -Werror=nonnull Sorry about the rather useless title, but I can't really figure out what actually triggers this error. It seems to depend on some arcane combination of optimizations. I was able to reduce this down to a pretty minimal test case, attached here. It may be possible to reduce it further but I couldn't easily find a way. The actual code that triggers this is here [1]. lstrcpyA() and lstrcatA() are trivial wrappers around strcpy/strcat. The NULL comes from get_search_path() at line 192. The offending strcpy/strcat will never be reached if GetWindowsDirectoryA() returns nonzero, which it always should. However, gcc triggers a -Wnonnull warning anyway. Interestingly, the original Wine code only triggers the warning with -march=bdver2 (or other values of -march), but the reduced testcase triggers it with no -march flags. [1] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/krnl386.exe16/file.c#l639
[Bug tree-optimization/111282] `a & (b ^ ~a)` (or `a & ~(a ^ b)`) not optimized to `a & b` in gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111282
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> Note we will need to detect both `a & (b ^ ~a)` and `a & ~(a ^ b)` since a
> might be comparison too.
Well and that will handle:
```
int f0(int a, int b)
{
return (~a) & (b ^ a); // ~a & b
}
```
Which we don't currently.
on the RTL level, we currently simplify that to:
(a | b) ^ a
The interesting thing is we do simplify the above in tree via the following
pattern:
/* (X | Y) ^ X -> Y & ~ X */
[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 Kito Cheng changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-10-03 --- Comment #3 from Kito Cheng --- Proposed fix, and verified with mawk on my machine :) https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631785.html
[Bug c/111654] Introduce clang's invalid-noreturn warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111654 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #4) > Unfortunately, gcc does not have any patch tracking system I thought someone was getting a patchwork installation set up? ...ok yeah, here it is; it's being hosted on sourceware currently: https://patchwork.sourceware.org/project/gcc/list/ (could be made a little more discoverable from gcc.gnu.org IMO)
[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 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Summary|vrp2 (match and simplify) |[12/13/14 Regression] vrp2 |introduces invalid wide |(match and simplify) |signed Boolean values |introduces invalid wide ||signed Boolean values --- Comment #3 from Andrew Pinski --- Since PR 110487 is a regression, this is a regression.
[Bug target/111506] RISC-V: Failed to vectorize conversion from INT64 -> _Float16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111506 --- Comment #6 from joseph at codesourcery dot com --- On Mon, 2 Oct 2023, rdapp at gcc dot gnu.org via Gcc-bugs wrote: > In our case the int64_t -> int32_t conversion is implementation defined when > the source doesn't fit the target. GCC documents the implementation-defined semantics it uses for out-of-range conversions from an integer type to a signed integer type. That does not depend on whether the conversion is vectorized or not. And for conversions between floating and integer types in either direction, there is no conversion between two integer types involved in the abstract machine.
[Bug tree-optimization/111668] vrp2 (match and simplify) introduces invalid wide signed Boolean values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111668 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=110487 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > This was broken by r14-4125-g5c5851bd93b8 . Basically that reintroduced PR 110487 .
[Bug tree-optimization/111668] vrp2 (match and simplify) introduces invalid wide signed Boolean values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111668
Andrew Pinski changed:
What|Removed |Added
Summary|vrp2 introduces invalid |vrp2 (match and simplify)
|wide Boolean values |introduces invalid wide
||signed Boolean values
Last reconfirmed||2023-10-02
Status|UNCONFIRMED |NEW
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
Keywords||wrong-code
--- Comment #1 from Andrew Pinski ---
This was broken by r14-4125-g5c5851bd93b8 .
Before VRP:
```
# RANGE [irange] [-1, 0]
_66 = _16 ? -1 : 0;
vect_cst__67 = {_66, _66, _66, _66};
```
VRP2 dump:
```
Folding statement: _66 = _16 ? -1 : 0;
Applying pattern match.pd:5115, gimple-match-2.cc:16882
gimple_simplified to _38 = () _16;
_66 = -_38;
```
This is was the reasoning for the build_nonstandard_integer_type there.
With r14-4125-g5c5851bd93b8 reverted:
```
Folding statement: _66 = _16 ? -1 : 0;
Applying pattern match.pd:5118, gimple-match-1.cc:16933
gimple_simplified to _38 = (signed int) _16;
_43 = -_38;
_66 = () _43;
Global Exported: _66 = [irange] [-1, 0]
Folded into: _66 = () _43;
```
Note the testcase needs to compiled at -O3 on x86_64.
[Bug preprocessor/82335] Incorrect _Pragma expansion if macro passed to another macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82335 Lewis Hyatt changed: What|Removed |Added Last reconfirmed||2023-10-02 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||lhyatt at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90400, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102409 --- Comment #2 from Lewis Hyatt --- Depending which variant of the test you look at, this ended up getting resolved by r12-4797 and/or by r12-5454. It is the same issue as bug 102409 and bug 90400. The testcase from this PR seems worth adding in addition, so I will do that prior to closing this one. Patch adding the testcase submitted for review here: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631814.html
[Bug tree-optimization/111668] New: vrp2 introduces invalid wide Boolean values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111668
Bug ID: 111668
Summary: vrp2 introduces invalid wide Boolean values
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kristerw at gcc dot gnu.org
Target Milestone: ---
The vrp2 pass introduces an invalid wide Boolean when compiling the function
int *a, b, c, d;
void
foo (void)
{
for (; d <= 0; d++)
b &= ((a || d) ^ c) == 1;
}
What is happening is that vrp2 changes the IR
_Bool _16;
_66;
gimple_assign
to the incorrect
_Bool _16;
_38;
_66;
gimple_assign
gimple_assign
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050 --- Comment #15 from CVS Commits --- The releases/gcc-13 branch has been updated by Francois Dumont : https://gcc.gnu.org/g:e6d26b141bf03a0348b51e4778c79d44dc760eed commit r13-7931-ge6d26b141bf03a0348b51e4778c79d44dc760eed Author: Tim Song Date: Wed Sep 6 19:31:55 2023 +0200 libstdc++: Force _Hash_node_value_base methods inline to fix abi (PR111050) https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1b6f0476837205932613ddb2b3429a55c26c409d changed _Hash_node_value_base to no longer derive from _Hash_node_base, which means that its member functions expect _M_storage to be at a different offset. So explosions result if an out-of-line definition is emitted for any of the member functions (say, in a non-optimized build) and the resulting object file is then linked with code built using older version of GCC/libstdc++. libstdc++-v3/ChangeLog: PR libstdc++/111050 * include/bits/hashtable_policy.h (_Hash_node_value_base<>::_M_valptr(), _Hash_node_value_base<>::_M_v()) Add [[__gnu__::__always_inline__]]. (cherry picked from commit 2c1e3544a94c5d7354fad031e1f9731c3ce3af25)
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050 --- Comment #14 from CVS Commits --- The releases/gcc-12 branch has been updated by Francois Dumont : https://gcc.gnu.org/g:1be57348229666c54954f1e5937cae00e113f7f1 commit r12-9903-g1be57348229666c54954f1e5937cae00e113f7f1 Author: Tim Song Date: Wed Sep 6 19:31:55 2023 +0200 libstdc++: Force _Hash_node_value_base methods inline to fix abi (PR111050) https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1b6f0476837205932613ddb2b3429a55c26c409d changed _Hash_node_value_base to no longer derive from _Hash_node_base, which means that its member functions expect _M_storage to be at a different offset. So explosions result if an out-of-line definition is emitted for any of the member functions (say, in a non-optimized build) and the resulting object file is then linked with code built using older version of GCC/libstdc++. libstdc++-v3/ChangeLog: PR libstdc++/111050 * include/bits/hashtable_policy.h (_Hash_node_value_base<>::_M_valptr(), _Hash_node_value_base<>::_M_v()) Add [[__gnu__::__always_inline__]]. (cherry picked from commit 2c1e3544a94c5d7354fad031e1f9731c3ce3af25)
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050 --- Comment #13 from CVS Commits --- The releases/gcc-11 branch has been updated by Francois Dumont : https://gcc.gnu.org/g:50ace1f8a784d08a72edb8cb4044101fdabcc072 commit r11-11028-g50ace1f8a784d08a72edb8cb4044101fdabcc072 Author: Tim Song Date: Wed Sep 6 19:31:55 2023 +0200 libstdc++: Force _Hash_node_value_base methods inline to fix abi (PR111050) https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1b6f0476837205932613ddb2b3429a55c26c409d changed _Hash_node_value_base to no longer derive from _Hash_node_base, which means that its member functions expect _M_storage to be at a different offset. So explosions result if an out-of-line definition is emitted for any of the member functions (say, in a non-optimized build) and the resulting object file is then linked with code built using older version of GCC/libstdc++. libstdc++-v3/ChangeLog: PR libstdc++/111050 * include/bits/hashtable_policy.h (_Hash_node_value_base<>::_M_valptr(), _Hash_node_value_base<>::_M_v()) Add [[__gnu__::__always_inline__]]. (cherry picked from commit 2c1e3544a94c5d7354fad031e1f9731c3ce3af25)
[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 --- Comment #4 from Andrew Pinski --- (In reply to Patrick Palka from comment #3) > On x86_64 this seems to have started with r14-2852-gf5fb9ff2396fd4 I was expecting it was one of the loop splitting patches due to the ir changes I saw
[Bug c++/111647] g++ accepts different c++ on -fchecking= anf checking=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111647
Patrick Palka changed:
What|Removed |Added
Keywords||accepts-invalid
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-10-02
Ever confirmed|0 |1
--- Comment #2 from Patrick Palka ---
We probably want to diagnose this regardless of -fchecking.
Here's a similar IFNDR example that we don't diagnose even with -fchecking=2.
struct A { };
void g(A);
template
void f() {
g(A(42));
}
[Bug preprocessor/36887] Please report #pragma GCC poison" location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36887 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org --- Comment #4 from Lewis Hyatt --- Patch submitted for review at https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630967.html
[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 Patrick Palka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Keywords|needs-bisection | --- Comment #3 from Patrick Palka --- On x86_64 this seems to have started with r14-2852-gf5fb9ff2396fd4
[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 #2 from seurer at gcc dot gnu.org --- I installed gawk on the machine where it failed and the build works now. So definitely mawk.
[Bug middle-end/111659] document that -Wstrict-flex-arrays depends on -ftree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111659 --- Comment #3 from Cristian Rodríguez --- Example code that emits no warning (in case if there is of any interest) curl -LO https://www.netlib.org/fp/dtoa.c gcc-14 -Og -c -Warray-bounds -fstrict-flex-arrays -Werror=strict-flex-arrays -DIEEE_8087 dtoa.c
[Bug target/111506] RISC-V: Failed to vectorize conversion from INT64 -> _Float16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111506 --- Comment #5 from Robin Dapp --- Ah, thanks Joseph, so this at least means that we do not need !flag_trapping_math here. However, the vectorizer emulates the 64-bit integer to _Float16 conversion via an intermediate int32_t and now the riscv expander does the same just without the same restrictions. I'm assuming the restrictions currently imposed on two-step vectorizing conversions are correct. For e.g. int64_t -> _Float16 we require the value range of the source fit in int32_t (first step int64_t -> int32_t). For _Float16 -> int64_t we require -fno-trapping-math (first step _Float16 -> int32_t). The latter follows from Annex F of the C standard. Therefore, my general question would rather be: - Is it OK to circumvent either restriction by pretending to have an instruction that performs the conversion in two steps but doesn't actually do the checks? I.e. does "implementation-defined behavior" cover the vectorizer checking one thing and one target not doing it? In our case the int64_t -> int32_t conversion is implementation defined when the source doesn't fit the target.
[Bug libstdc++/111667] [C++23] Implement P1132R8, out_ptr - a scalable output pointer abstraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111667 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-10-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- .
[Bug libstdc++/111667] [C++23] Implement P1132R8, out_ptr - a scalable output pointer abstraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111667 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug libstdc++/111667] New: [C++23] Implement P1132R8, out_ptr - a scalable output pointer abstraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111667 Bug ID: 111667 Summary: [C++23] Implement P1132R8, out_ptr - a scalable output pointer abstraction Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Blocks: 106749 Target Milestone: --- https://wg21.link/P1132R8 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749 [Bug 106749] Implement C++23 library features
[Bug c/111665] internal compiler error: in c_objc_common_truthvalue_conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111665
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords||ice-on-valid-code
Last reconfirmed||2023-10-02
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Confirmed.
Also:
extern int func(void *);
int main(void)
{
[[gnu::assume(func)]];
}
[Bug fortran/111666] New: [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
Bug ID: 111666
Summary: [OpenMP] Fortran FE creates too many temporaries for
clauses / 'omp target'+'omp team' #teams/#threads
optimize_target_teams optimization fails
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization, openmp
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: andrewjenner at gcc dot gnu.org, jakub at gcc dot gnu.org
Target Milestone: ---
I wonder whether trans-openmp.cc in general converts too much into temporaries.
Namely the following function. the 'gfc_evaluate_now' returns a constant as a
constant but otherwise creates a temporary:
static inline tree
gfc_convert_expr_to_tree (stmtblock_t *block, gfc_expr *expr)
{
gfc_se se;
tree result;
gfc_init_se (&se, NULL );
gfc_conv_expr (&se, expr);
gfc_add_block_to_block (block, &se.pre);
result = gfc_evaluate_now (se.expr, block);
gfc_add_block_to_block (block, &se.post);
return result;
}
* * *
This bites us for something similar to libgomp.fortran/examples-4/teams-2.f90
but modified:
function dotprod (..., num_teams, block_threads)
integer, VALUE :: num_teams, block_threads
!$omp target map(to: B, C, block_size) ...
!$omp teams num_teams(num_teams) thread_limit(block_threads) ...
The problem is that the gfc_evaluate_now produces code like:
D.4323 = num_teams;
D.4324 = block_threads;
#pragma omp teams ... num_teams(D.4323) thread_limit(D.4324)
And this is then too complex for gcc/gimplify.cc's optimize_target_teams
which no longer recognizes that num_teams and block_threads are (implicitly)
firstprivatize.
* * *
A similar issue shows up above without the VALUE attribute; this matches the
OpenMP Example document teams-2.f90 example - except that the values are passed
by reference.
(That's != libgomp.fortran/examples-4/teams-2.f90; the latter has 'map(tofrom:'
which prevents the optimize_target_teams optimization.)
In order to make that work, we would need to preserve 'num_teams(*num_teams)'
in the evaluation – and handle indirect-ref+DECL_P in optimize_target_teams.
[Bug c/111665] New: internal compiler error: in c_objc_common_truthvalue_conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111665
Bug ID: 111665
Summary: internal compiler error: in
c_objc_common_truthvalue_conversion
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nrk at disroot dot org
Target Milestone: ---
Minimal reproducer:
extern int func(void *);
int main(void)
{
__attribute__((__assume__(func)));
}
`-freport-bug` output:
// Target: x86_64-pc-linux-gnu
// Configured with:
/var/tmp/portage/sys-devel/gcc-13.2.1_p20230826/work/gcc-13-20230826/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/13
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/13/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/13/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --disable-nls --disable-libunwind-exceptions
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 13.2.1_p20230826 p7' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --with-multilib-list=m64 --disable-fixed-point
--enable-targets=all --enable-libgomp --disable-libssp --disable-libada
--disable-cet --disable-systemtap --disable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --with-isl
--disable-isl-version-check --disable-default-pie --disable-default-ssp
--with-build-config='bootstrap-O3 bootstrap-lto'
// Thread model: posix
// Supported LTO compression algorithms: zlib zstd
// gcc version 13.2.1 20230826 (Gentoo 13.2.1_p20230826 p7)
//
// test.c: In function 'main':
// test.c:4:5: internal compiler error: in
c_objc_common_truthvalue_conversion, at c/c-typeck.cc:13368
// 4 | __attribute__((__assume__(func)));
// | ^
// 0x1252094 internal_error(char const*, ...)
// ???:0
// 0x1252166 fancy_abort(char const*, int, char const*)
// ???:0
// 0x1acae13 c_parse_file()
// ???:0
// 0x1ac201e c_common_parse_file()
// ???:0
// Please submit a full bug report, with preprocessed source.
// Please include the complete backtrace with any bug report.
// See
[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 Thomas Koenig changed: What|Removed |Added CC||carll at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- I ran git bisect on POWER (gcc120) and strangely got this as the first bad commit: b51795c832cf6e724d61919eb18a383223b76694 is the first bad commit commit b51795c832cf6e724d61919eb18a383223b76694 Author: Carl Love Date: Wed Jul 26 11:31:53 2023 -0400 rs6000, fix vec_replace_unaligned built-in arguments The first argument of the vec_replace_unaligned built-in should always be of type vector unsigned char, as specified in gcc/doc/extend.texi. This patch fixes the builtin definitions and updates the test cases to use the correct arguments. The original test file is renamed and a second test file is added for a new test case. This is weird because the problem also occurs on x86_64.
[Bug c++/60608] Template argument problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60608 Andrew Pinski changed: What|Removed |Added CC||janschultke at googlemail dot com --- Comment #10 from Andrew Pinski --- *** Bug 111662 has been marked as a duplicate of this bug. ***
[Bug c++/111662] Rejects valid: cv-qualifiers are not removed from function parameters of variadic templated function types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111662 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 60608. *** This bug has been marked as a duplicate of bug 60608 ***
[Bug target/111506] RISC-V: Failed to vectorize conversion from INT64 -> _Float16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111506 --- Comment #4 from joseph at codesourcery dot com --- Conversion from 64-bit integers for _Float16 is fully defined, it produces the correctly rounded result according to the current rounding direction (round-to-nearest may be assumed in the absence of -frounding-math), which may be an infinity (depending on the rounding mode) in case of overflow (and in particular, anything not representable in a 32-bit integer certainly overflows on conversion to _Float16). That's just the same as for any integer-to-floating conversions.
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #22 from joseph at codesourcery dot com --- On Mon, 2 Oct 2023, eggert at cs dot ucla.edu via Gcc-bugs wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 > > --- Comment #20 from Paul Eggert --- > (In reply to jos...@codesourcery.com from comment #14) > > This is just the same as other unspecified things like converting an > > out-of-range value from floating-point to integer. > No, because when GCC's constant folding disagrees with machine arithmetic, GCC > can generate code that violates the relevant standards. The issue you describe is orthogonal to my comment in this bug. The unspecified cases - both the one I mentioned in my comment and the one in the description of this bug - do not require any particular result (choice of quiet NaN, choice of value for out-of-range conversion to integer, etc.), and in particular do not require a result that could be generated by the hardware being used, but they do require that, for each evaluation of such an operation in the abstract machine, the implementation behaves as if some particular valid choice of result was made for that evaluation; wobbly values (some uses of the result behaving as if one choice of value were made and other uses behaving as if some other choice were made) are not permitted. (This is similar to the question of whether use of uninitialized variables (if not undefined behavior) can produce a wobbly value, as such a value naturally results from optimizing a PHI node with one uninitialized operand to the value of the other operand.)
[Bug preprocessor/90400] _Pragma not always expanded in the right location within macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90400 Lewis Hyatt changed: What|Removed |Added CC||paboyle at ph dot ed.ac.uk --- Comment #11 from Lewis Hyatt --- *** Bug 91517 has been marked as a duplicate of this bug. ***
[Bug preprocessor/91517] Pragma expansion in variadic macro reorders pragmas and breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91517 Lewis Hyatt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||lhyatt at gcc dot gnu.org --- Comment #6 from Lewis Hyatt --- Same issue as bug 90400... was resolved as well by r12-5454. *** This bug has been marked as a duplicate of bug 90400 ***
[Bug c++/109227] coroutines: ICE in tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.cc:11067
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109227 --- Comment #5 from Andrew Pinski --- Created attachment 56031 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56031&action=edit More reduced testcase from the dup
[Bug c++/109227] coroutines: ICE in tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.cc:11067
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109227 Andrew Pinski changed: What|Removed |Added CC||redboltz at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 110913 has been marked as a duplicate of this bug. ***
[Bug c++/110913] internal compiler error when I pass temporary vector of string to co_await target function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110913 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Andrew Pinski --- Dup of bug 109227. *** This bug has been marked as a duplicate of bug 109227 ***
[Bug fortran/111644] [13 regression] many failures after r13-7923-gd9b3269bdccac2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111644 seurer at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #3 from seurer at gcc dot gnu.org --- Fixed now, thanks!
[Bug target/111649] [14 Regression] Bootstrap failure in stage 1 on riscv*-*-* since r14-4348-g9d249b7e31e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649 Patrick O'Neill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Patrick O'Neill --- Builds no longer fail due to this issue. There is some follow-up discussion on the mailing list about improving the performance of the affected code using lazily allocation & dynamic initialization: https://inbox.sourceware.org/gcc-patches/da3d1e8c-3df2-2008-ad14-a3036b6f6...@rivosinc.com/T/#m65e9d134dfea988ad77b099cef83f194079078c4
[Bug testsuite/110951] [13/14] RISCV: rv32 newlib gcc.c-torture testsuite fails with xgcc: fatal error: Cannot find suitable multilib set for '-march=rv32imafdc_zicsr_zifencei'/'-mabi=ilp32d'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110951 --- Comment #4 from Patrick O'Neill --- The root cause of the problem was that we were moving files between containers after the build before the testsuite run and forgot to preserve the symlinks.
[Bug bootstrap/111664] [14 regression] error in gcc/opt-read.awk after r14-4354-ge4a4b8e983bac8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111664 Sam James changed: What|Removed |Added CC||kito at gcc dot gnu.org, ||sjames at gcc dot gnu.org --- Comment #1 from Sam James --- It's a gawk vs mawk issue, see https://inbox.sourceware.org/gcc-patches/20231002080244.105205-1-kito.ch...@sifive.com/T/#u for a patch.
[Bug bootstrap/111664] New: [14 regression] error in gcc/opt-read.awk after r14-4354-ge4a4b8e983bac8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111664 Bug ID: 111664 Summary: [14 regression] error in gcc/opt-read.awk after r14-4354-ge4a4b8e983bac8 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:e4a4b8e983bac865eb435b11798e38d633b98942, r14-4354-ge4a4b8e983bac8 I am seeing this just on our big ending machines. mawk -f /home/seurer/gcc/git/gcc-trunk/gcc/opt-functions.awk -f /home/seurer/gcc/git/gcc-trunk/gcc/opt-read.awk \ -f /home/seurer/gcc/git/gcc-trunk/gcc/opth-gen.awk \ < optionlist > tmp-options.h mawk: /home/seurer/gcc/git/gcc-trunk/gcc/opt-read.awk: line 134: syntax error at or near [ mawk: /home/seurer/gcc/git/gcc-trunk/gcc/opth-gen.awk: line 415: syntax error at or near [ mawk: /home/seurer/gcc/git/gcc-trunk/gcc/opth-gen.awk: line 417: syntax error at or near [ mawk: /home/seurer/gcc/git/gcc-trunk/gcc/opth-gen.awk: line 440: syntax error at or near [ commit e4a4b8e983bac865eb435b11798e38d633b98942 Author: Feng Wang Date: Tue Sep 12 09:18:05 2023 + RISC-V:Optimize the MASK opt generation
[Bug target/111235] [Armv7-a]: Control-dependency between atomic accesses removed by -O1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111235 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #3 from Sam James --- (In reply to Luke Geeson from comment #1) > Correction > We will follow up by reporting the bug for GCC. > -> > We have reported this in LLVM as well Could you include the link? Thanks.
[Bug target/111600] [14 Regression] RISC-V bootstrap time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org --- Comment #13 from Kito Cheng --- I guess we may need something like this g:703417a0 for those generator for md file?
[Bug target/111235] [Armv7-a]: Control-dependency between atomic accesses removed by -O1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111235 --- Comment #2 from CVS Commits --- The master branch has been updated by Wilco Dijkstra : https://gcc.gnu.org/g:0731889c026bfe8d55c4851422ca5ec9d037f7a0 commit r14-4365-g0731889c026bfe8d55c4851422ca5ec9d037f7a0 Author: Wilco Dijkstra Date: Fri Sep 29 13:21:10 2023 +0100 Arm: Block predication on atomics [PR111235] The v7 memory ordering model allows reordering of conditional atomic instructions. To avoid this, make all atomic patterns unconditional. Expand atomic loads and stores for all architectures so the memory access can be wrapped into an UNSPEC. Reviewed-by: Ramana Radhakrishnan gcc/ChangeLog: PR target/111235 * config/arm/constraints.md: Remove Pf constraint. * config/arm/sync.md (arm_atomic_load): Add new pattern. (arm_atomic_load_acquire): Likewise. (arm_atomic_store): Likewise. (arm_atomic_store_release): Likewise. (atomic_load): Switch patterns to define_expand. (atomic_store): Likewise. (arm_atomic_loaddi2_ldrd): Remove predication. (arm_load_exclusive): Likewise. (arm_load_acquire_exclusive): Likewise. (arm_load_exclusivesi): Likewise. (arm_load_acquire_exclusivesi): Likewise. (arm_load_exclusivedi): Likewise. (arm_load_acquire_exclusivedi): Likewise. (arm_store_exclusive): Likewise. (arm_store_release_exclusivedi): Likewise. (arm_store_release_exclusive): Likewise. * config/arm/unspecs.md: Add VUNSPEC_LDR and VUNSPEC_STR. gcc/testsuite/ChangeLog: PR target/111235 * gcc.dg/rtl/arm/stl-cond.c: Remove test. * gcc.target/arm/atomic_loaddi_7.c: Fix dmb count. * gcc.target/arm/atomic_loaddi_8.c: Likewise. * gcc.target/arm/pr111235.c: Add new test.
[Bug target/111600] [14 Regression] RISC-V bootstrap time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 Robin Dapp changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #12 from Robin Dapp --- We're really at a point where just building becomes a burden and turnaround times are annoyingly high. My suspicion is that the large number of modes combined with the number of insn patterns slows us down. Juzhe added a lot of VLS patterns (or rather added VLS modes to existing patterns) around the Cauldron and this is where we saw the largest relative slowdown. Maybe we need to bite the bullet and not use the convenience helpers anymore or at least very sparingly? I'm going to make some experiments on Wednesday to see where that gets us.
[Bug c++/111660] [14 Regression] Compilation of constexpr function returning enum takes exponential time with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111660 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/111660] [14 Regression] Compilation of constexpr function returning enum takes exponential time with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111660 Patrick Palka changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #11 from Patrick Palka --- (In reply to Andrew Pinski from comment #8) > I suspect r14-4140-g6851e3423c2b5e introduced the compile time slowness. Confirmed.
[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209 --- Comment #9 from Manuel López-Ibáñez --- For the sake of other potential readers: Patches should be submitted to gcc-patc...@gcc.gnu.org and reviewers do not review patches in bugzilla. Nevertheless, it is a good idea to add the link to the mailing list archive here in bugzilla so the patch is not forgotten. For more details, please read: https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps How to submit and ping patches: https://gcc.gnu.org/contribute.html#patches See other suggestions on how to interact with the GCC community here: https://gcc.gnu.org/wiki/Community
[Bug c/111654] Introduce clang's invalid-noreturn warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111654 --- Comment #4 from Manuel López-Ibáñez --- (In reply to Julian Waters from comment #2) > (In reply to Manuel López-Ibáñez from comment #1) > Yeah, I did try submitting it to gcc-patches, but it simply went ignored for > forever, so I decided to submit the patch through the bug system instead, > like others have done. I implemented it as numeric values to avoid inventing > new names for -Woption and because it was easier to implement for a gcc > beginner like myself, so worded warnings are likely to take me longer to > implement Apologies, I was not aware of that. I think it is a good idea to add the link to the mailing list here in bugzilla so it is not lost in the mailing list archive. Unfortunately, gcc does not have any patch tracking system so it is up to submitters to ping patches (the submitter is the one interested in seeing the patch committed). See for example: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627958.html It may take 4 to 10 pings to get the patch reviewed. It helps sometimes to describe the area the patch touches in the subject. In your case, I would write "[C family]". It helps reviewers if you mention how the patch was tested and also if the patch is attached as plain-text (not as application/*): https://gcc.gnu.org/contribute.html#patches See other suggestions on how to interact with the GCC community here: https://gcc.gnu.org/wiki/Community
[Bug bootstrap/111663] profiledbootstrap fails on master: gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data file not found [-Werror=missing-profile]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111663 --- Comment #1 from Sergei Trofimovich --- Proposed the change as https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631790.html
[Bug bootstrap/111663] New: profiledbootstrap fails on master: gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data file not found [-Werror=missing-profile]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111663 Bug ID: 111663 Summary: profiledbootstrap fails on master: gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data file not found [-Werror=missing-profile] Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- It is the same issue diagnosed by Martin in https://gcc.gnu.org/PR87932#c2 The only difference here is the failure of profiledbootstrap on master by default (until you disable -Werror). The reproducer: $ ~/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++ CC='gcc -O2' CXX='g++ -O2' $ make profiledbootstrap ... gcc/gcc/sort.cc: In function ‘void reorder45(sort_ctx*, char*, char*, char*, char*, char*) [with sort_ctx = sort_r_ctx]’: gcc/gcc/sort.cc:313:1: error: ‘gcc/build/sort.gcda’ profile count data file not found [-Werror=missing-profile] 313 | } | ^ gcc/gcc/genmodes.cc: In function ‘int main(int, char**)’: gcc/gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data file not found [-Werror=missing-profile] 2152 | } | ^ gcc/gcc/gengtype-parse.cc: In function ‘void parse_file(const char*)’: gcc/gcc/gengtype-parse.cc:1186:1: error: ‘gcc/build/gengtype-parse.gcda’ profile count data file not found [-Werror=missing-profile] 1186 | } | ^ cc1plus: all warnings being treated as errors make[3]: *** [Makefile:2949: build/gengenrtl.o] Ошибка 1 gcc/gcc/gengtype-parse.cc: In function ‘void parse_error(const char*, ...)’: gcc/gcc/gengtype-parse.cc:142:21: error: ‘%s’ directive argument is null [-Werror=format-overflow=] 142 | fprintf (stderr, "%s:%d: parse error: ", | ^~ Stable branches work just because -Werror is disabled. Note that autofeedback has a similar problem and it works it around with disabling -Werror: # Disable warnings as errors since inlining decisions with -fauto-profile # may result in additional warnings. STAGEautofeedback_CONFIGURE_FLAGS = $(filter-out --enable-werror-always,$(STAGE_CONFIGURE_FLAGS)) I suggest doling the same for `profiledbootstrap` as: --- a/Makefile.tpl +++ b/Makefile.tpl @@ -561,6 +561,10 @@ STAGEtrain_TFLAGS = $(filter-out -fchecking=1,$(STAGE3_TFLAGS)) STAGEfeedback_CFLAGS = $(STAGE4_CFLAGS) -fprofile-use -fprofile-reproducible=parallel-runs STAGEfeedback_TFLAGS = $(STAGE4_TFLAGS) +# Disable warnings as errors for a few reasons: +# - sources for gen* binaries do not have .gcda files available +# - inlining decisions generate extra warnings +STAGEfeedback_CONFIGURE_FLAGS = $(filter-out --enable-werror-always,$(STAGE_CONFIGURE_FLAGS)) STAGEautoprofile_CFLAGS = $(filter-out -gtoggle,$(STAGE2_CFLAGS)) -g STAGEautoprofile_TFLAGS = $(STAGE2_TFLAGS)
[Bug c++/111662] Rejects valid: cv-qualifiers are not removed from function parameters of variadic templated function types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111662 --- Comment #2 from Jan Schultke --- Bug was originally discovered here: https://stackoverflow.com/questions/77214665/problem-creating-template-function-alias-with-const-value-template-arguments/77215223#77215223
[Bug c++/111662] Rejects valid: cv-qualifiers are not removed from function parameters of variadic templated function types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111662 --- Comment #1 from Jan Schultke --- See https://godbolt.org/z/Kaf7jETaY
[Bug c++/111662] New: Rejects valid: cv-qualifiers are not removed from function parameters of variadic templated function types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111662
Bug ID: 111662
Summary: Rejects valid: cv-qualifiers are not removed from
function parameters of variadic templated function
types
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janschultke at googlemail dot com
Target Milestone: ---
## Code to reproduce
template
void f(Ts...) {}
void(*pfi)(int) = &f; // OK
void(*pfci)(int) = &f; // error
void(*pcfi)(const int) = &f; // OK
void(*pcfci)(const int) = &f; // error
> :5:21: error: no matches converting function 'f' to type 'void
> (*)(int)'
> 5 | void(*pfci)(int) = &f; // error
> | ^~~~
> :2:6: note: candidate is: 'template void f(Ts ...)'
> 2 | void f(Ts...) {}
> | ^
## Explanation
The error is nonsensical because the type of &f is already
void(*)(int). No conversion is required.
According to [dcl.fct] p5, cv-qualifiers are not part of the function type:
> After producing the list of parameter types,
> any top-level cv-qualifiers modifying a parameter type are deleted
> when forming the function type.
Variadic function templates are not exempt from this rule, and GCC should not
reject this code. Making f non-templated, or using a single T parameter instead
of a Ts... parameter pack makes this code compile.
[Bug middle-end/50481] builtin to reverse the bit order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50481 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #9 from Xi Ruoyao --- Useful for LoongArch too. And now we already have bitreverse RTX code since r14-1586.
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #21 from Alexander Monakov --- Bug 111655 is not a dup, I left a comment and reopened.
[Bug target/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 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org Ever confirmed|0 |1 Summary|wrong code generated for|[11/12/13/14 Regression] |__builtin_signbit and 0./0. |wrong code generated for |on x86-64 -O2 |__builtin_signbit and 0./0. ||on x86-64 -O2 Resolution|DUPLICATE |--- Status|RESOLVED|NEW Last reconfirmed||2023-10-02 --- Comment #9 from Alexander Monakov --- It's true that the sign of 0./0 is unpredictable, but we can fold it only when the division is being eliminated by the folding. It's fine to fold t = 0./0; s = __builtin_signbit(t); to s = 0 with t eliminated from IR, but it's not OK to fold t = 0./0 s = __builtin_signbit(t); to t = 0./0 s = 0 because the resulting program runs as if 0./0 was evaluated twice, first to a positive NaN (which was used for signbit), then to a negative NaN (which fed the following computations). This is not allowed. This bug was incorrectly classified as a dup. The fix is either to not fold this, or fold only when we know that the division will be eliminated (e.g. the only use was in the signbit). Reopening.
[Bug tree-optimization/109154] [13/14 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154 --- Comment #69 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:19610580d49f3d2d8d511fba55b39efa0764dfc2 commit r14-4361-g19610580d49f3d2d8d511fba55b39efa0764dfc2 Author: Tamar Christina Date: Mon Oct 2 11:48:26 2023 +0100 ifcvt: replace C++ sort with vec::qsort [PR109154] As requested later on, this replaces the C++ sort with vec::qsort. gcc/ChangeLog: PR tree-optimization/109154 * tree-if-conv.cc (INCLUDE_ALGORITHM): Remove. (cmp_arg_entry): New. (predicate_scalar_phi): Use it.
[Bug fortran/111661] New: [OpenACC] Detach+Attach of DT component gives libgomp: [0x405140,96] is not mapped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111661 Bug ID: 111661 Summary: [OpenACC] Detach+Attach of DT component gives libgomp: [0x405140,96] is not mapped Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: openacc Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: patrick.be...@univ-grenoble-alpes.fr, tschwinge at gcc dot gnu.org Target Milestone: --- Reported by Patrick. The following snippet gives: libgomp: [0x406180,96] is not mapped with GCC (mainline) and reportedly likewise GCC 13.2 but working with the Nvidia and Cray compiler (see comments in the snipped). [Same result with an older OG13 build: 13.1.1 20230710 [OG13].] The problem seems to be the 'acc update' command. Here, 0x406180 is the host address of 'tab': 406180- tab - host 1847B20- tab%val - host 130414- tab - device 1304140200- tab%val - device 406180- tab - host 18FF8C0- tab%val - host libgomp: [0x406180,96] is not mapped In other words, the DETACH seems to not only DETACH 'tab%val' but also somehow unmap 'tab'? #pragma omp target oacc_exit_data map(delete:tab.val.data [len: 88]) map(delete:MEM [(real(kind=8)[0:] *)_34] [len: _33]) map(to:tab.val [pointer set, len: 88]) map(force_detach:tab.val.data [bias: 0]) finalize ... #pragma omp target oacc_update map(force_to:tab [len: 96]) !--cut--- use iso_c_binding implicit none type r2tab double precision, dimension(:,:), allocatable :: val integer :: dim1 integer :: dim2 end type r2tab type(r2tab) :: tab integer :: i,j integer(c_intptr_t) :: iloc(2) !$acc enter data copyin(tab) tab%dim1 = 10 tab%dim2 = 20 allocate (tab%val(tab%dim1,tab%dim2)) print '(z16,a)', loc(tab), "- tab - host" print '(z16,a)', loc(tab%val), "- tab%val - host" !$acc enter data copyin(tab%val) !$acc serial copyout(iloc) iloc(1) = loc(tab) iloc(2) = loc(tab%val) !$acc end serial print '(z16,a)', iloc(1), "- tab - device" print '(z16,a)', iloc(2), "- tab%val - device" !... !$acc exit data delete(tab%val) finalize ! Works as is with nvfortran and CCE ftn but gfortran 13 requires ! additionally: ! !$acc exit data delete(tab) finalize tab%dim1=11 tab%dim2=30 deallocate(tab%val) allocate (tab%val(tab%dim1,tab%dim2)) print '(z16,a)', loc(tab), "- tab - host" print '(z16,a)', loc(tab%val), "- tab%val - host" ! For nvfortran and ftn: !$acc update device(tab) ! gfortran with the change above requires instead: ! !$acc enter data copyin(tab) !$acc enter data create(tab%val) !$acc parallel loop do j = 1, tab%dim2 do i = 1, tab%dim1 tab%val(i,j) = j * 100 + i end do end do !$acc end parallel loop !$acc exit data copyout(tab%val) finalize !$acc exit data delete(tab) do j = 1, tab%dim2 do i = 1, tab%dim1 if (tab%val(i,j) /= j * 100 + i) error stop end do end do end
[Bug c/111654] Introduce clang's invalid-noreturn warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111654 --- Comment #3 from Sam James --- It would be worth mentioning that then. Anyway: * https://inbox.sourceware.org/gcc-patches/cap2b4gmq7btqtequuuok7ojt8p3kdbdvpudrmo_nt95wumw...@mail.gmail.com/ * https://inbox.sourceware.org/gcc-patches/cap2b4gmfj0gx_aahmu4xcnq2l6doohr8pftzpyq4mccdzh-...@mail.gmail.com/
[Bug c/111654] Introduce clang's invalid-noreturn warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111654 --- Comment #2 from Julian Waters --- (In reply to Manuel López-Ibáñez from comment #1) > (In reply to Julian Waters from comment #0) > > Created attachment 56022 [details] > > Patch to add invalid-noreturn to gcc > > Patches should be submitted to gcc-patc...@gcc.gnu.org > > For more details, please read: > https://gcc.gnu.org/wiki/GettingStarted#Basics: > _Contributing_to_GCC_in_10_easy_steps > > Except for clang compatibility, I believe the consensus is that numerical > levels are not user-friendly. I think it would be better to have: > > -Wnoreturn-implicit-return > -Wnoreturn-explicit-return > > -Winvalid-noreturn enables / disables both. Yeah, I did try submitting it to gcc-patches, but it simply went ignored for forever, so I decided to submit the patch through the bug system instead, like others have done. I implemented it as numeric values to avoid inventing new names for -Woption and because it was easier to implement for a gcc beginner like myself, so worded warnings are likely to take me longer to implement
[Bug c/111654] Introduce clang's invalid-noreturn warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111654 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez --- (In reply to Julian Waters from comment #0) > Created attachment 56022 [details] > Patch to add invalid-noreturn to gcc Patches should be submitted to gcc-patc...@gcc.gnu.org For more details, please read: https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps Except for clang compatibility, I believe the consensus is that numerical levels are not user-friendly. I think it would be better to have: -Wnoreturn-implicit-return -Wnoreturn-explicit-return -Winvalid-noreturn enables / disables both.
[Bug target/111657] Memory copy with structure assignment from named address space should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657
--- Comment #5 from Uroš Bizjak ---
I have tried to compile with -mtune=nocona that has:
static stringop_algs nocona_memcpy[2] = {
{libcall, {{12, loop_1_byte, false}, {-1, rep_prefix_4_byte, false}}},
{libcall, {{32, loop, false}, {2, rep_prefix_8_byte, false},
{10, unrolled_loop, false}, {-1, libcall, false;
and compiler produces code as expected in both cases (use unrolled_loop when
rep movsq is unavailable):
foo:
movq%fs:0, %rdx
leaqt@tpoff(%rdx), %rsi
movl$30, %ecx
rep movsq
ret
bar:
xorl%edx, %edx
.L4:
movl%edx, %eax
movq%gs:s(%rax), %r9
movq%gs:s+8(%rax), %r8
movq%gs:s+16(%rax), %rsi
movq%gs:s+24(%rax), %rcx
movq%r9, (%rdi,%rax)
movq%r8, 8(%rdi,%rax)
movq%rsi, 16(%rdi,%rax)
movq%rcx, 24(%rdi,%rax)
addl$32, %edx
cmpl$224, %edx
jb .L4
addq%rdx, %rdi
movq%gs:s(%rdx), %rax
movq%rax, (%rdi)
movq%gs:s+8(%rdx), %rax
movq%rax, 8(%rdi)
ret
[Bug target/111657] Memory copy with structure assignment from named address space should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
Status|NEW |ASSIGNED
--- Comment #4 from Uroš Bizjak ---
Created attachment 56030
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56030&action=edit
Propsed patch
Proposed patch declares libcall algorithm unavailable to non-default address
spaces and falls back to a loop if everything else fails. The following
testcase:
--cut here--
struct a { long arr[30]; };
__thread struct a t;
void foo (struct a *dst) { *dst = t; }
__seg_gs struct a s;
void bar (struct a *dst) { *dst = s; }
--cut here--
now compiles (-O2 -mno-sse) to:
foo:
movq%fs:0, %rdx
movl$30, %ecx
leaqt@tpoff(%rdx), %rsi
rep movsq
ret
bar:
xorl%eax, %eax
.L4:
movl%eax, %edx
addl$8, %eax
movq%gs:s(%rdx), %rcx
movq%rcx, (%rdi,%rdx)
cmpl$240, %eax
jb .L4
ret
(rep movsq copies only from the default ds: address space)
[Bug c++/111651] Specific syntax with C++ 20 designated initializers and coroutines breaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111651 --- Comment #6 from Andrew Pinski --- Note it is not designated initializers which is causing the issue but rather a vector strings initialized from an array.
[Bug c++/110913] internal compiler error when I pass temporary vector of string to co_await target function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110913 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-10-02 Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW --- Comment #5 from Andrew Pinski --- Confirmed.
[Bug c++/110913] internal compiler error when I pass temporary vector of string to co_await target function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110913 --- Comment #4 from Andrew Pinski --- Created attachment 56029 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56029&action=edit Reduced testcase
[Bug c++/110913] internal compiler error when I pass temporary vector of string to co_await target function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110913 Andrew Pinski changed: What|Removed |Added CC||yunus at ayar dot eu --- Comment #3 from Andrew Pinski --- *** Bug 111651 has been marked as a duplicate of this bug. ***
[Bug c++/111651] Specific syntax with C++ 20 designated initializers and coroutines breaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111651 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- Dup of bug 110913. *** This bug has been marked as a duplicate of bug 110913 ***
[Bug c++/111651] Specific syntax with C++ 20 designated initializers and coroutines breaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111651 --- Comment #4 from Andrew Pinski --- Created attachment 56028 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56028&action=edit Reduced testcase
[Bug target/111506] RISC-V: Failed to vectorize conversion from INT64 -> _Float16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111506 Robin Dapp changed: What|Removed |Added CC||joseph at codesourcery dot com --- Comment #3 from Robin Dapp --- I just got back. The problem with this is not -fno-trapping-math - it will vectorize just fine with -ftrapping-math (and the vectorizer doesn't depend on it either). We also already have tests for this in rvv/autovec/conversions. However, not all int64 values can be represented in the intermediate type int32 which is why we don't vectorize unless the range of a[i] is know to be inside int32's range. If I'm reading the C standard correctly it says such cases are implementation-defined behavior and I'm not sure we should work around the vectorizer by defining an expander that essentially hides the intermediate type. If that's an OK thing to do then I won't complain, though. CC'ing jmyers and rsandi because they would know best. >From what I can tell aarch64 also does not vectorize this and I wonder why LLVM's behavior is dependent on -fno-trapping-math. We have the same issue with the reversed conversion from _Float16 to int64. In that case trapping math is relevant, though, but we could apply the same logic as in this patch and circumvent it by an expander. To me this doesn't seem right.
