[Bug target/108322] Using __restrict parameter with -ftree-vectorize (default with -O2) results in massive code bloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108322 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #3 from Alexander Monakov --- With '-fdisable-tree-forwprop4 -msse4.1' you see what the vectorizer perhaps wanted to achieve.
[Bug middle-end/108300] `abort()` macro cause bootstrap failure on *-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300 --- Comment #6 from CVS Commits --- The master branch has been updated by Jonathan Yong : https://gcc.gnu.org/g:902c755930326cb4405672aa3ea13c35c653cbff commit r13-5055-g902c755930326cb4405672aa3ea13c35c653cbff Author: LIU Hao Date: Fri Jan 6 23:18:15 2023 +0800 Always define `WIN32_LEAN_AND_MEAN` before Recently, mingw-w64 has got updated from Wine which is included indirectly by if `WIN32_LEAN_AND_MEAN` is not defined. The `IXMLDOMDocument` class has a member function named `abort()`, which gets affected by our `abort()` macro in "system.h". `WIN32_LEAN_AND_MEAN` should, nevertheless, always be defined. This can exclude 'APIs such as Cryptography, DDE, RPC, Shell, and Windows Sockets' [1], and speed up compilation of these files a bit. [1] https://learn.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers gcc/ PR middle-end/108300 * config/xtensa/xtensa-dynconfig.c: Define `WIN32_LEAN_AND_MEAN` before . * diagnostic-color.cc: Likewise. * plugin.cc: Likewise. * prefix.cc: Likewise. gcc/ada/ PR middle-end/108300 * adaint.c: Define `WIN32_LEAN_AND_MEAN` before `#include `. * cio.c: Likewise. * ctrl_c.c: Likewise. * expect.c: Likewise. * gsocket.h: Likewise. * mingw32.h: Likewise. * mkdir.c: Likewise. * rtfinal.c: Likewise. * rtinit.c: Likewise. * seh_init.c: Likewise. * sysdep.c: Likewise. * terminals.c: Likewise. * tracebak.c: Likewise. gcc/jit/ PR middle-end/108300 * jit-w32.h: Define `WIN32_LEAN_AND_MEAN` before . libatomic/ PR middle-end/108300 * config/mingw/lock.c: Define `WIN32_LEAN_AND_MEAN` before . libffi/ PR middle-end/108300 * src/aarch64/ffi.c: Define `WIN32_LEAN_AND_MEAN` before . libgcc/ PR middle-end/108300 * config/i386/enable-execute-stack-mingw32.c: Define `WIN32_LEAN_AND_MEAN` before . * libgcc2.c: Likewise. * unwind-generic.h: Likewise. libgfortran/ PR middle-end/108300 * intrinsics/sleep.c: Define `WIN32_LEAN_AND_MEAN` before . libgomp/ PR middle-end/108300 * config/mingw32/proc.c: Define `WIN32_LEAN_AND_MEAN` before . libiberty/ PR middle-end/108300 * make-temp-file.c: Define `WIN32_LEAN_AND_MEAN` before . * pex-win32.c: Likewise. libssp/ PR middle-end/108300 * ssp.c: Define `WIN32_LEAN_AND_MEAN` before . libstdc++-v3/ PR middle-end/108300 * src/c++11/system_error.cc: Define `WIN32_LEAN_AND_MEAN` before . * src/c++11/thread.cc: Likewise. * src/c++17/fs_ops.cc: Likewise. * src/filesystem/ops.cc: Likewise. libvtv/ PR middle-end/108300 * vtv_malloc.cc: Define `WIN32_LEAN_AND_MEAN` before . * vtv_rts.cc: Likewise. * vtv_utils.cc: Likewise.
[Bug c++/108326] New: Question about definitions in c++config.h for gcc13 20221229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108326 Bug ID: 108326 Summary: Question about definitions in c++config.h for gcc13 20221229 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lukaszcz18 at wp dot pl Target Milestone: --- Amateur questions I know that creating exe files two years ago with , with _GLIBCXX_HAS_GTHREADS definition was impossible. I don't know if someone made mistake or added additional functions in c++confic.h, but gcc works differently. Differences between versions 20221124 and 20221219. /* Defined if sleep exists. */ /* #undef _GLIBCXX_HAVE_SLEEP */ /* Defined if service exists. */ /* #undef _GLIBCXX_HAVE_USLEEP */ /* Define if writev is available in . */ /* Define if gthreads library is available. */ #define _GLIBCXX_HAS_GTHREADS 1 /* Defined if sched_yield is available. */ #define _GLIBCXX_USE_SCHED_YIELD 1 /* Defined if Sleep exists. */ #define _GLIBCXX_USE_WIN32_SLEEP 1 /* Define to 1 if a verbose library is built, or 0 otherwise. */ /* Define if a non-default location should be used for tzdata files. */ /* #undef _GLIBCXX_ZONEINFO_DIR */ /* Define to 1 if mutex_timedlock is available. */ #define_GTHREAD_USE_MUTEX_TIMEDLOCK 0 The question is. Why is _GLIBCXX_HAS_GTHREADS enabled only for C++20 and above in ?
[Bug analyzer/108325] New: -Wanalyzer-null-dereference false positive with *f = 42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108325
Bug ID: 108325
Summary: -Wanalyzer-null-dereference false positive with *f =
42
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: mengli.ming at outlook dot com
Target Milestone: ---
I got a false positive error when compiling the following program with
gcc(trunk) `-O0 -fanalyzer` in https://godbolt.org/z/db7v3PGYe.
In this case, the eval statement in line 16 gives two results, FALSE and
UNKNOWN. The UNKNOWN here is a little odd, and then analyzer analyzes the codes
inside the if statement, however, these are unreachable codes.
Input:
```
#include "stdio.h"
#include "stdbool.h"
void __analyzer_eval(int);
struct a
{
int b;
} c()
{
struct a d = {1};
int e = 0;
int *f = (int *)e;
for (d.b = 0; e == 0; e++)
{
__analyzer_eval(true == ((!d.b) && e));
if ((!d.b) && e)
{
__analyzer_eval(true == ((!d.b) && e));
*f = 42;
}
}
}
void main() { c(); }
```
Output:
```
: In function 'c':
:16:9: warning: FALSE
16 | __analyzer_eval(true == ((!d.b) && e));
| ^~
:16:9: warning: UNKNOWN
:19:13: warning: TRUE
19 | __analyzer_eval(true == ((!d.b) && e));
| ^~
:16:9: warning: FALSE
16 | __analyzer_eval(true == ((!d.b) && e));
| ^~
:16:9: warning: FALSE
:16:9: warning: UNKNOWN
:19:13: warning: TRUE
19 | __analyzer_eval(true == ((!d.b) && e));
| ^~
:16:9: warning: FALSE
16 | __analyzer_eval(true == ((!d.b) && e));
| ^~
:20:16: warning: dereference of NULL 'f' [CWE-476]
[-Wanalyzer-null-dereference]
20 | *f = 42;
| ~~~^~~~
'c': events 1-20
|
| 12 | int *f = (int *)e;
| | ^
| | |
| | (1) 'f' is NULL
| 13 |
| 14 | for (d.b = 0; e == 0; e++)
| | ~~ ~~~
| | | |
| | | (11) ...to here
| | (2) following 'true' branch (when 'e == 0')...
| | (12) following 'true' branch (when 'e ==
0')...
| 15 | {
| 16 | __analyzer_eval(true == ((!d.b) && e));
| | ~
| | | |
| | | (4) following 'true'
branch...
| | | (5) ...to here
| | | (6) following 'false'
branch (when 'e == 0')...
| | | (7) ...to here
| | | (14) following 'true'
branch...
| | | (15) ...to here
| | (3) ...to here
| | (13) ...to here
| 17 | if ((!d.b) && e)
| |
| || |
| || (9) ...to here
| || (10) following 'false' branch (when 'e ==
0')...
| || (17) ...to here
| |(8) following 'true' branch...
| |(16) following 'true' branch...
| 18 | {
| 19 | __analyzer_eval(true == ((!d.b) && e));
| | ~
| | |
| | (18) following 'true'
branch...
| | (19) ...to here
| 20 | *f = 42;
| | ~~~
| ||
| |(20) dereference of NULL 'f'
|
```
I set it directly to 0 in the initialization of `d.b`, and then keep the
semantics of the for loop executing only one time, and after making the
following transformation (https://godbolt.org/z/nvePK1sdb), the NPD warning
disappeared, and the eval statement in line 19 is not output.
Thank you for taking the time to review these cases.
[Bug c++/108324] New: Temporary not bound to reference in default member initializer destroyed early from parenthesized expression-list initialization of aggregate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108324
Bug ID: 108324
Summary: Temporary not bound to reference in default member
initializer destroyed early from parenthesized
expression-list initialization of aggregate
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: rejects-valid, wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
While the lifetime-extension rules for temporaries bound to a reference member
differ between braced and parenthesized aggregate initialization, the
full-expression associated with default member initializers used in the
aggregate initialization are the same in both cases ([intro.execution]).
It seems GCC thinks that the parenthesized expression-list case causes
destruction of temporaries from the default member initializer at an earlier
point than in the braced initialization case.
ICC does not have this problem (at least when doing constant expression
evaluation).
Online compiler link: https://godbolt.org/z/aPhffr7xT
### SOURCE ():
struct A {
constexpr A(int x) : x(x) {}
constexpr ~A() { x = 13; }
int x;
constexpr A () { return *this; }
};
struct B {
const A *ap = (42).ref();
};
constexpr int f() { return B{}.ap->x; }
constexpr int g() { return B().ap->x; }
extern char q[f()];
extern char q[42];
extern char k[g()];
extern char k[42];
### COMPILER INVOCATION COMMAND:
g++ -fsyntax-only -std=c++2b -xc++ -
### ACTUAL OUTPUT:
:15:16: error: size of array 'k' is not an integral constant-expression
:16:13: error: conflicting declaration 'char k [42]'
:15:13: note: previous declaration as 'char k [1]'
### EXPECTED OUTPUT:
(Clean compile)
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20230106 (experimental) (GCC)
[Bug libstdc++/108323] combine does not change the locale name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108323 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-01-07
[Bug libstdc++/108221] Building cross compiler for H8 family fails at libstdc++-v3/src/c++20/tzdb.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221 --- Comment #10 from Jonathan Wakely --- The fix would be changing the constraint to: _Extent == dynamic_extent || _Extent == 0
[Bug libstdc++/108221] Building cross compiler for H8 family fails at libstdc++-v3/src/c++20/tzdb.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221 --- Comment #9 from Jonathan Wakely --- The reason it fails is here: D:/Works/xcomp/gcc-build/h8300-elf/normal/int32/libstdc++-v3/include/span:147:7: note: candidate: 'constexpr std::span<_Type, _Extent>::span() requires _Extent + 1 <= 1 [with _Type = char; short unsigned int _Extent = 65535]' 147 | span() noexcept | ^~~~ D:/Works/xcomp/gcc-build/h8300-elf/normal/int32/libstdc++-v3/include/span:147:7: note: constraints not satisfied The requires expression fails if size_t promotes to int, which is true for bizarre mode.
[Bug libstdc++/108221] Building cross compiler for H8 family fails at libstdc++-v3/src/c++20/tzdb.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221 --- Comment #8 from Jonathan Wakely --- (In reply to Jan Dubiec from comment #6) > Please note -mn -mint32 options – > normal mode (aka 16-bit mode) with 32-bit integers. Has this bizarre mode ever been able to build libstdc++? I have too many other things to deal with to care about this odd target, sorry.
[Bug libstdc++/108221] Building cross compiler for H8 family fails at libstdc++-v3/src/c++20/tzdb.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221 --- Comment #7 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #5) > Fixed, but the build still fails as mentioned above. See comment 3
[Bug libstdc++/108221] Building cross compiler for H8 family fails at libstdc++-v3/src/c++20/tzdb.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221
--- Comment #6 from Jan Dubiec ---
Jonathan, I am not sure to what part of the thread "above" refers to, but build
fails indeed. This time due to a different reason. This is what I got when I
was trying to build f7bd48c6. Please note -mn -mint32 options – normal mode
(aka 16-bit mode) with 32-bit integers.
Making all in c++20
make[9]: Entering directory
'/d/Works/xcomp/gcc-build/h8300-elf/normal/int32/libstdc++-v3/src/c++20'
/bin/sh ../../libtool --tag CXX --tag disable-shared --mode=compile
/d/Works/xcomp/gcc-build/./gcc/xgcc -shared-libgcc
-B/d/Works/xcomp/gcc-build/./gcc -nostdinc++
-L/d/Works/xcomp/gcc-build/h8300-elf/normal/int32/libstdc++-v3/src
-L/d/Works/xcomp/gcc-build/h8300-elf/normal/int32/libstdc++-v3/src/.libs
-L/d/Works/xcomp/gcc-build/h8300-elf/normal/int32/libstdc++-v3/libsupc++/.libs
-B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ -isystem
/usr/local/h8300-elf/include -isystem /usr/local/h8300-elf/sys-include -mn
-mint32 -I/d/Works/gcc/libstdc++-v3/../libgcc
-I/d/Works/xcomp/gcc-build/h8300-elf/normal/int32/libstdc++-v3/include/h8300-elf
-I/d/Works/xcomp/gcc-build/h8300-elf/normal/int32/libstdc++-v3/include
-I/d/Works/gcc/libstdc++-v3/libsupc++ -std=gnu++20 -fno-implicit-templates
-Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=tzdb.lo -fimplicit-templates -isystem
/d/Works/xcomp/sysroot/h8300-elf/include -mn -mint32 -c -o tzdb.lo
../../../../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc
libtool: compile: /d/Works/xcomp/gcc-build/./gcc/xgcc -shared-libgcc
-B/d/Works/xcomp/gcc-build/./gcc -nostdinc++
-L/d/Works/xcomp/gcc-build/h8300-elf/normal/int32/libstdc++-v3/src
-L/d/Works/xcomp/gcc-build/h8300-elf/normal/int32/libstdc++-v3/src/.libs
-L/d/Works/xcomp/gcc-build/h8300-elf/normal/int32/libstdc++-v3/libsupc++/.libs
-B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ -isystem
/usr/local/h8300-elf/include -isystem /usr/local/h8300-elf/sys-include -mn
-mint32 -I/d/Works/gcc/libstdc++-v3/../libgcc
-I/d/Works/xcomp/gcc-build/h8300-elf/normal/int32/libstdc++-v3/include/h8300-elf
-I/d/Works/xcomp/gcc-build/h8300-elf/normal/int32/libstdc++-v3/include
-I/d/Works/gcc/libstdc++-v3/libsupc++ -std=gnu++20 -fno-implicit-templates
-Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=tzdb.lo -fimplicit-templates -isystem
/d/Works/xcomp/sysroot/h8300-elf/include -mn -mint32 -c
../../../../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc -o tzdb.o
d:\works\gcc\libstdc++-v3\src\c++20\tzdb.cc: In member function
'std::string_view std::chrono::{anonymous}::ZoneInfo::rules() const':
d:\works\gcc\libstdc++-v3\src\c++20\tzdb.cc:402:36: warning: narrowing
conversion of '(((unsigned int)((int)((const
std::chrono::{anonymous}::ZoneInfo*)this)->std::chrono::{anonymous}::ZoneInfo::m_pos))
- 1)' from 'unsigned int' to 'std::basic_string_view::size_type' {aka
'short unsigned int'} [-Wnarrowing]
402 | r = {m_buf.data(), m_pos - 1u};
| ~~^~~~
d:\works\gcc\libstdc++-v3\src\c++20\tzdb.cc: In member function
'std::string_view std::chrono::{anonymous}::ZoneInfo::format() const':
d:\works\gcc\libstdc++-v3\src\c++20\tzdb.cc:409:52: warning: narrowing
conversion of '(((int)((const
std::chrono::{anonymous}::ZoneInfo*)this)->std::chrono::{anonymous}::ZoneInfo::m_buf.std::__cxx11::basic_string::size())
- ((int)((const
std::chrono::{anonymous}::ZoneInfo*)this)->std::chrono::{anonymous}::ZoneInfo::m_pos))'
from 'int' to 'std::basic_string_view::size_type' {aka 'short unsigned
int'} [-Wnarrowing]
409 | { return {m_buf.data() + m_pos, m_buf.size() - m_pos}; }
| ~^~~
In file included from
D:/Works/xcomp/gcc-build/h8300-elf/normal/int32/libstdc++-v3/include/chrono:48,
from d:\works\gcc\libstdc++-v3\src\c++20\tzdb.cc:28:
D:/Works/xcomp/gcc-build/h8300-elf/normal/int32/libstdc++-v3/include/bits/stl_algo.h:
In instantiation of 'void std::__merge_adaptive_resize(_BidirectionalIterator,
_BidirectionalIterator, _BidirectionalIterator, _Distance, _Distance, _Pointer,
_Distance, _Compare) [with _BidirectionalIterator =
__gnu_cxx::__normal_iterator >; _Distance = short int; _Pointer =
chrono::{anonymous}::Rule*; _Compare =
__gnu_cxx::__ops::_Iter_comp_iter
std::chrono::{anonymous}::Rule::*>(std::ranges::less&,
std::__cxx11::basic_string
std::chrono::{anonymous}::Rule::*&):: >]':
D:/Works/xcomp/gcc-build/h8300-elf/normal/int32/libstdc++-v3/include/bits/stl_algo.h:2770:32:
required from 'void std::__stable_sort_adaptive_resize(_RandomAccessIterator,
_RandomAccessIterator, _Pointer, _Distance, _Compare) [with
_RandomAccessIterator =
__gnu_cxx::__normal_iterator >; _Pointer = chrono::{anonymous}::Rule*;
_Distance = short int; _Compare =
__gnu_cxx::__ops::_Iter_comp_iter
[Bug c++/108323] New: combine does not change the locale name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108323
Bug ID: 108323
Summary: combine does not change the locale name
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: liweifriends at gmail dot com
Target Milestone: ---
for the following code
```
#include
#include
int main()
{
std::locale loc = std::locale()
.combine>(std::locale("en_US.UTF-8"));
std::cout << loc.name() << '\n';
std::cout << (std::locale() == loc);
}
```
gcc outputs 'C' and '1' (https://godbolt.org/z/q8fT4oqj3), which seems a bug?
Because locale::combine should return a new and nameless locale.
[Bug target/108322] Using __restrict parameter with -ftree-vectorize (default with -O2) results in massive code bloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108322 Andrew Pinski changed: What|Removed |Added Target||x86_64-linux-gnu Component|tree-optimization |target Keywords||missed-optimization --- Comment #2 from Andrew Pinski --- This is a cost model issue with x86_64. on aarch64, this is not vectorized unless you use -fno-vect-cost-model.
[Bug tree-optimization/108322] Using __register parameter with -ftree-vectorize (default with -O2) results in massive code bloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108322 --- Comment #1 from David Korth --- Some quick testing with Compiler Explorer at godbolt.org shows that this behavior started with gcc-8.1, and it doesn't happen with gcc-7.x or earlier.
[Bug tree-optimization/108322] New: Using __register parameter with -ftree-vectorize (default with -O2) results in massive code bloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108322
Bug ID: 108322
Summary: Using __register parameter with -ftree-vectorize
(default with -O2) results in massive code bloat
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gerbilsoft at gerbilsoft dot com
Target Milestone: ---
While examining some code using the bloaty tool, I found that a function for
deinterleaving Super Magic Drive ROM images was taking up ~5 KB when it should
have been less than 1 KB. On examining the disassembly, there appeared to be a
lot of unnecessary instructions; compiling with clang and MSVC resulted in
significantly fewer instructions. Either removing __restrict from the function
parameters (two pointers), or specifying -fno-tree-vectorize to disable
auto-vectorization, fixes this issue with gcc-12.
The generated code isn't buggy as far as I can tell, and it benchmarks around
the same as the non-bloated version.
I've narrowed it down to the following minimal test case:
#include
#define SMD_BLOCK_SIZE 16384
void decodeBlock_cpp(uint8_t *__restrict pDest, const uint8_t *__restrict pSrc)
{
// First 8 KB of the source block is ODD bytes.
const uint8_t *pSrc_end = pSrc + (SMD_BLOCK_SIZE / 2);
for (uint8_t *pDest_odd = pDest + 1; pSrc < pSrc_end; pDest_odd += 2,
pSrc += 1) {
pDest_odd[0] = pSrc[0];
}
}
Assembly output with `g++ -O2 -fno-tree-vectorize` (or removing the __restrict
qualifiers):
decodeBlock_cpp(unsigned char*, unsigned char const*):
xor eax, eax
.L2:
movzx edx, BYTE PTR [rsi+rax]
mov BYTE PTR [rdi+1+rax*2], dl
add rax, 1
cmp rax, 8192
jne .L2
ret
Assembly output with `g++ -O2` (implying -ftree-vectorize with gcc-12) and
__restrict qualifiers:
decodeBlock_cpp(unsigned char*, unsigned char const*):
pushr15
lea rax, [rsi+8192]
add rdi, 1
pushr14
pushr13
pushr12
pushrbp
pushrbx
mov QWORD PTR [rsp-8], rax
.L2:
movzx ecx, BYTE PTR [rsi+10]
movzx eax, BYTE PTR [rsi+14]
add rsi, 16
add rdi, 32
movzx edx, BYTE PTR [rsi-3]
movzx r15d, BYTE PTR [rsi-1]
movzx r11d, BYTE PTR [rsi-10]
movzx ebx, BYTE PTR [rsi-11]
mov BYTE PTR [rsp-11], cl
movzx ecx, BYTE PTR [rsi-16]
movzx ebp, BYTE PTR [rsi-12]
mov BYTE PTR [rsp-9], al
movzx r12d, BYTE PTR [rsi-13]
movzx eax, BYTE PTR [rsi-4]
mov BYTE PTR [rsp-10], dl
movzx r13d, BYTE PTR [rsi-14]
movzx edx, BYTE PTR [rsi-5]
movzx r14d, BYTE PTR [rsi-15]
movzx r8d, BYTE PTR [rsi-7]
movzx r9d, BYTE PTR [rsi-8]
movzx r10d, BYTE PTR [rsi-9]
mov BYTE PTR [rdi-32], cl
movzx ecx, BYTE PTR [rsp-11]
mov BYTE PTR [rdi-10], dl
mov BYTE PTR [rdi-30], r14b
mov BYTE PTR [rdi-28], r13b
mov BYTE PTR [rdi-26], r12b
mov BYTE PTR [rdi-24], bpl
mov BYTE PTR [rdi-22], bl
mov BYTE PTR [rdi-20], r11b
mov BYTE PTR [rdi-18], r10b
mov BYTE PTR [rdi-16], r9b
mov BYTE PTR [rdi-14], r8b
mov BYTE PTR [rdi-12], cl
mov BYTE PTR [rdi-8], al
movzx eax, BYTE PTR [rsp-9]
movzx edx, BYTE PTR [rsp-10]
mov BYTE PTR [rdi-2], r15b
mov BYTE PTR [rdi-4], al
mov rax, QWORD PTR [rsp-8]
mov BYTE PTR [rdi-6], dl
cmp rsi, rax
jne .L2
pop rbx
pop rbp
pop r12
pop r13
pop r14
pop r15
ret
$ gcc --version
gcc (Gentoo Hardened 12.2.1_p20221008 p1) 12.2.1 20221008
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/108321] New: [13 regression] g++.dg/contracts/contracts-tmpl-spec2.C fails after r13-4160-g2efb237ffc68ec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108321 Bug ID: 108321 Summary: [13 regression] g++.dg/contracts/contracts-tmpl-spec2.C fails after r13-4160-g2efb237ffc68ec Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:2efb237ffc68ec9bb17982434f5941bfa14f8b50, r13-4160-g2efb237ffc68ec make -k check-gcc RUNTESTFLAGS="dg.exp=g++.dg/contracts/contracts-tmpl-spec2.C" FAIL: g++.dg/contracts/contracts-tmpl-spec2.C output pattern test # of expected passes2 # of unexpected failures1 There was one other failure with this revision, too: FAIL: compiler driver --help=c++ option(s): "^ +-.*[^:.]$" absent from output: " -fcontract-build-level=[off|default|audit] Specify max contract level to generate runtime checks for" commit 2efb237ffc68ec9bb17982434f5941bfa14f8b50 (HEAD, refs/bisect/bad) Author: Jeff Chapman II Date: Tue Jun 29 16:52:56 2021 -0400 c++: implement P1492 contracts
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 Thomas Koenig changed: What|Removed |Added Blocks||105105 --- Comment #47 from Thomas Koenig --- (In reply to Thomas Koenig from comment #46) > Fortran gets this right: ... but only by accident. This test case shows that it doesn't: $ cat y.f90 module y implicit none integer, parameter :: wp = selected_real_kind(15) contains subroutine foo(a,b,c) use ieee_arithmetic real(kind=wp), dimension(4), intent(out) :: a real(kind=wp), intent(in) :: b, c type (ieee_round_type), dimension(4), parameter :: mode = & [ieee_nearest, ieee_to_zero, ieee_up, ieee_down] call ieee_set_rounding_mode (mode(1)) a(1) = b + c call ieee_set_rounding_mode (mode(2)) a(2) = b + c call ieee_set_rounding_mode (mode(3)) a(3) = b + c call ieee_set_rounding_mode (mode(4)) a(4) = b + c end subroutine foo end module y program main use y real(kind=wp), dimension(4) :: a call foo(a, 0.1_wp, 0.2_wp) print *,a end program main $ gfortran -O y.f90 && ./a.out 0.30004 0.30004 0.30004 0.30004 $ gfortran y.f90 && ./a.out 0.30004 0.2 0.30004 0.2 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105105 [Bug 105105] [Meta] Fortran IEEE support
[Bug tree-optimization/108320] Missing vector/array arithmetic optimization compared to valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108320 --- Comment #2 from Andrew Pinski --- valarray is specifically designed to allow these kind of optimizations really.
[Bug tree-optimization/108320] Missing vector/array arithmetic optimization compared to valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108320 --- Comment #1 from Andrew Pinski --- GCC does not implement loop fusion and you need loop fusion to handle fma2/fma3
[Bug tree-optimization/108320] Missing vector/array arithmetic optimization compared to valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108320 Andrew Pinski changed: What|Removed |Added Component|c++ |tree-optimization Severity|normal |enhancement Keywords||missed-optimization
[Bug c++/108320] New: Missing vector/array arithmetic optimization compared to valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108320
Bug ID: 108320
Summary: Missing vector/array arithmetic optimization compared
to valarray
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: diegoandres91b at hotmail dot com
Target Milestone: ---
The next code (with -O3 -mavx2 -mfma):
#include
#include
#include
using namespace std;
valarray fma1(const valarray , const valarray , const
valarray ) {
return a * b + c;
}
template
struct vec : vector {
constexpr vec(size_t count) : vector(count) {}
};
template
constexpr vec operator*(const vec , const vec ) {
vec c(a.size());
for (size_t i = 0; i < c.size(); ++i) c[i] = a[i] * b[i];
return c;
}
template
constexpr vec operator+(const vec , const vec ) {
vec c(a.size());
for (size_t i = 0; i < c.size(); ++i) c[i] = a[i] + b[i];
return c;
}
vec fma2(const vec , const vec , const vec )
{
return a * b + c;
}
template
struct arr : array {
};
template
constexpr arr operator*(const arr , const arr ) {
arr c;
for (size_t i = 0; i < c.size(); ++i) c[i] = a[i] * b[i];
return c;
}
template
constexpr arr operator+(const arr , const arr ) {
arr c;
for (size_t i = 0; i < c.size(); ++i) c[i] = a[i] + b[i];
return c;
}
constexpr size_t N = 1024;
arr fma3(const arr , const arr , const
arr ) {
return a * b + c;
}
Only optimizes the valarray version (fma1) of the fma function (uses
vfmadd132ps):
...
.L4:
vmovups ymm0, YMMWORD PTR [rdi+rax]
vmovups ymm1, YMMWORD PTR [rcx+rax]
vfmadd132ps ymm0, ymm1, YMMWORD PTR [rsi+rax]
vmovups YMMWORD PTR [rdx+rax], ymm0
add rax, 32
cmp rax, r8
jne .L4
mov rax, r10
and rax, -8
lea r9, [0+rax*4]
lea r11, [rdx+r9]
testr10b, 7
je .L22
vzeroupper
.L3:
mov r8, r10
sub r8, rax
lea r12, [r8-1]
cmp r12, 2
jbe .L6
vmovups xmm0, XMMWORD PTR [rdi+rax*4]
vmovups xmm2, XMMWORD PTR [rcx+rax*4]
vfmadd132ps xmm0, xmm2, XMMWORD PTR [rsi+rax*4]
vmovups XMMWORD PTR [rdx+r9], xmm0
testr8b, 3
je .L1
and r8, -4
add rax, r8
lea r11, [r11+r8*4]
lea r9, [0+rax*4]
...
But it does not optimize the vector or array versions of the function (fma2 and
fma3).
Note: For smaller N in fma3 optimizes, but for larger numbers like 1024 in the
example it does not.
Compiler Explorer code: https://godbolt.org/z/v8dnx5aMo
[Bug modula2/108182] gm2 driver mishandles target and multilib options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182 --- Comment #8 from Gaius Mulley --- Created attachment 54208 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54208=edit Potential fix for target multilib_dir handling -m and -f (version 2) Cleaned up and revised patch (no skip on -m).
[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108235 --- Comment #13 from Jonathan Wakely --- Maybe this time!
[Bug middle-end/93634] Improving modular calculations (e.g. divisibility tests).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93634 Gaius Mulley changed: What|Removed |Added Attachment #54207|1 |0 is patch|| Attachment #54207|0 |1 is obsolete|| --- Comment #3 from Gaius Mulley --- Comment on attachment 54207 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54207 Potential fix for target multilib_dir handling -m and -f (version 2) apologies - attachment was filed to the wrong PR.
[Bug libstdc++/108228] /usr/lib/pa20_64/dld.sl: Unsatisfied code symbol '_ZN9__gnu_cxx21zoneinfo_dir_ov errideEv'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108228 --- Comment #4 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:74852a3a2cecbd6d7ac6ddc2d1a9b60b83367d60 commit r13-5053-g74852a3a2cecbd6d7ac6ddc2d1a9b60b83367d60 Author: Jonathan Wakely Date: Fri Jan 6 20:54:23 2023 + libstdc++: Suppress -Waddress warning in tzdb.cc [PR108228] For some tarets the weak symbol is always defined, so we get a warning that its address is never null. The warning isn't useful in this case, so suppress it. libstdc++-v3/ChangeLog: PR libstdc++/108228 * src/c++20/tzdb.cc (zoneinfo_dir): Add diagnostic pragma.
[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108235 --- Comment #12 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:61da01772a3dff61cf23ba2ffba33bccb68d1063 commit r13-5052-g61da01772a3dff61cf23ba2ffba33bccb68d1063 Author: Jonathan Wakely Date: Fri Jan 6 18:39:14 2023 + libstdc++: Refactor time_zone::_Impl::rules_counter [PR108235] Abstract the atomic counter used to synchronize access to time_zone infos behind a Lockable class API, and use atomic_signed_lock_free instead of atomic, as that should be the most efficient type. (For futex-supporting targets it makes no difference, but might benefit other targets in future.) The new API allows the calling code to be simpler, without needing to repeat the same error prone preprocessor conditions in multiple places. It also allows using template metaprogramming to decide whether to use the atomic or a mutex, which gives us more flexibility than only using preprocessor conditions. That allows us to choose the mutex implementation for targets such as hppa-hp-hpux11.11 where 32-bit atomics are not lock-free and so would introduce an unwanted dependency on libatomic. libstdc++-v3/ChangeLog: PR libstdc++/108235 * src/c++20/tzdb.cc (time_zone::_Impl::RulesCounter): New class template and partial specialization for synchronizing access to time_zone::_Impl::infos. (time_zone::_M_get_sys_info, reload_tzdb): Adjust uses of rules_counter.
[Bug middle-end/93634] Improving modular calculations (e.g. divisibility tests).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93634 Gaius Mulley changed: What|Removed |Added CC||gaius at gcc dot gnu.org --- Comment #2 from Gaius Mulley --- Created attachment 54207 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54207=edit Potential fix for target multilib_dir handling -m and -f (version 2)
[Bug modula2/108182] gm2 driver mishandles target and multilib options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182 --- Comment #7 from Gaius Mulley --- About to post - I've cleaned up the patch and modified it not to skip the -m option. It is fine on x86_64 gnu/linux - it would be great to know I've not broken anything on Darwin :-)
[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299 --- Comment #11 from Jakub Jelinek --- You're right. All we'd need to do is revert PR101786 change and call __tls_init if in the current TU there are any dynamic TLS initializations when any TLS var from current TU is referenced, even when it has just static initializer.
[Bug c++/108047] [13 Regression] ICE: unexpected expression of kind implicit_conv_expr since r13-4564-gd081807d8d70e3e8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108047 --- Comment #10 from Sergei Trofimovich --- (In reply to Jakub Jelinek from comment #8) > Created attachment 54201 [details] > gcc13-pr108047.patch > > My current understanding is that even if nothing in the initializer is > dependent maybe_init_list_as_range will be called again during instantiation > with > !processing_template_decl and because this is just an optimization, I think > it should be fine to do the optimization only if !processing_template_decl. The patch fixes toml library build for me. Thank you!
[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299 Jason Merrill changed: What|Removed |Added Last reconfirmed||2023-01-06 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Keywords||wrong-code Resolution|INVALID |--- Status|RESOLVED|ASSIGNED Ever confirmed|0 |1 --- Comment #10 from Jason Merrill --- (In reply to Jakub Jelinek from comment #6) Hmm, I don't see the ABI problem: wrappers are comdat/weak and prepared to handle the absence of an init function, so TUs that either use or don't use wrappers should be ABI-compatible, though of course you would need both to be recompiled to get the currently specified behavior. For performance, the one degradation I see is preventing the PR101786 optimization with extern constinit. https://github.com/cplusplus/CWG/issues/210
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #46 from Thomas Koenig --- Fortran gets this right: $ cat set_rounding_mode.f90 module x implicit none integer, parameter :: wp = selected_real_kind(15) contains subroutine foo(a,b,c) use ieee_arithmetic real(kind=wp), dimension(4), intent(out) :: a real(kind=wp), intent(in) :: b, c type (ieee_round_type), dimension(4), parameter :: mode = & [ieee_nearest, ieee_to_zero, ieee_up, ieee_down] integer :: i do i=1,4 call ieee_set_rounding_mode (mode(i)) a(i) = b + c end do end subroutine foo end module x program main use x real(kind=wp), dimension(4) :: a call foo(a, 0.1_wp, 0.2_wp) print *,a end program main $ gfortran -O3 set_rounding_mode.f90 $ ./a.out 0.30004 0.2 0.30004 0.2
[Bug c++/108047] [13 Regression] ICE: unexpected expression of kind implicit_conv_expr since r13-4564-gd081807d8d70e3e8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108047 Andrew Pinski changed: What|Removed |Added CC||lukaszcz18 at wp dot pl --- Comment #9 from Andrew Pinski --- *** Bug 108319 has been marked as a duplicate of this bug. ***
[Bug c++/108319] Problem with std::__cxx11::basic_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108319 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 108047. *** This bug has been marked as a duplicate of bug 108047 ***
[Bug libstdc++/108319] New: Problem with std::__cxx11::basic_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108319
Bug ID: 108319
Summary: Problem with std::__cxx11::basic_string
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: lukaszcz18 at wp dot pl
Target Milestone: ---
Using built-in specs.
COLLECT_GCC=g++.exe
Target: x86_64-w64-mingw32
Configured with: /home/ma/m/source/gcc-g/configure --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --disable-nls --enable-languages=c,c++,objc,obj-c++
--with-gmp=/home/ma/m/build/for_target --with-mpfr=/home/ma/m/build/for_target
--with-mpc=/home/ma/m/build/for_target --with-isl=/home/ma/m/build/for_target
--enable-twoprocess --disable-libstdcxx-pch --disable-win32-registry
--disable-shared --enable-fully-dynamic-string --enable-libssp
--prefix=/home/ma/m/target --with-sysroot=/home/ma/m/target
Thread model: win32
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221229 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=gnu++17' '-ftree-vectorize' '-g0' '-O3' '-fPIC'
'-D' 'NJSON_NO_IO' '-D' 'JSON_HAS_CPP_14' '-D' 'JSON_HAS_CPP_17' '-D'
'JSON_DIAGNOSTICS=1' '-c' '-o' 'jpl-decoder.o' '-mtune=generic' '-march=x86-64'
c:/gcc1300/bin/../libexec/gcc/x86_64-w64-mingw32/13.0.0/cc1plus.exe -quiet -v
-iprefix c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/ -U_REENTRANT -D
NJSON_NO_IO -D JSON_HAS_CPP_14 -D JSON_HAS_CPP_17 -D JSON_DIAGNOSTICS=1
jpl-decoder.cpp -quiet -dumpbase jpl-decoder.cpp -dumpbase-ext .cpp
-mtune=generic -march=x86-64 -g0 -O3 -std=gnu++17 -version -ftree-vectorize
-fPIC -o C:\Users\KOMPUT~1\AppData\Local\Temp\ccTLv74F.s
GNU C++17 (GCC) version 13.0.0 20221229 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 13.0.0 20221229 (experimental), GMP version
6.2.1, MPFR version 4.1.1, MPC version 1.3.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring duplicate directory
"c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0"
ignoring duplicate directory
"c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0/x86_64-w64-mingw32"
ignoring duplicate directory
"c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0/backward"
ignoring duplicate directory
"c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/include"
ignoring nonexistent directory
"/home/ma/m/target/home/ma/m/target/lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include"
ignoring duplicate directory
"c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/include-fixed"
ignoring duplicate directory
"c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory "/home/ma/m/target/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0
c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0/x86_64-w64-mingw32
c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0/backward
c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/include
c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/include-fixed
c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/include
End of search list.
GNU C++17 (GCC) version 13.0.0 20221229 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 13.0.0 20221229 (experimental), GMP version
6.2.1, MPFR version 4.1.1, MPC version 1.3.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 764f1c9ee3426717f9fd65dfa7ce224a
In file included from
../../Lib/Common/../Part2/Common/../../Utils/Image/ThreeChannelImage.h:44,
from ../../Lib/Common/../Part2/Common/View.h:46,
from ../../Lib/Common/../Part2/Common/Lightfield.h:46,
from ../../Lib/Common/JPLMEncoderConfigurationLightField.h:54,
from ../../Lib/Common/JPLMCodecFactory.h:46,
from jpl-decoder.cpp:43:
../../Lib/Common/../Part2/Common/../../Utils/Image/Image.h: In member function
'std::vector >
GrayScaleImage::get_channel_names() const':
../../Lib/Common/../Part2/Common/../../Utils/Image/Image.h:455:19: internal
compiler error: unexpected expression
'(std::__cxx11::basic_string)"Gray"' of kind implicit_conv_expr
455 | return {"Gray"};
| ^
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 --- Comment #22 from Patrick J. LoPresti --- I disagree that bug 108296 is a duplicate. That bug requires code that, at least arguably, invokes undefined behavior. See e.g. https://stackoverflow.com/q/7292862/ and https://stackoverflow.com/q/61070828/. This bug is about clearly valid C++ code (object self-assignment) for which GCC emits clearly invalid calls to memcpy() (with dest == src). Now, I suspect what Andrew is thinking is that both of these bugs could be resolved by invoking memmove() instead of memcpy(). That seems like a reasonable idea to me, since small assignments get inlined and large assignments can amortize the overhead. But this bug could also be resolved in other ways, a few of which have been suggested in these comments.
[Bug libbacktrace/108297] libtool link b2test fails: Unrecognized argument: --build-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297 --- Comment #7 from dave.anglin at bell dot net --- On 2023-01-06 12:44 p.m., ian at airs dot com wrote: > If LTO doesn't work HP/UX, do you have a simple test that the configure script > could run to see whether it works? Will investigate.
[Bug c++/108317] dependent vector field is not causing field of this not to be found for fold expression inside a if constexpr block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108317 --- Comment #4 from Andrew Pinski --- I should mention that <0> works but <0,1> fails. That might get a hint to a person fixing the issue of what is going wrong inside the compiler.
[Bug c++/108317] dependent vector field is not causing field of this not to be found for fold expression inside a if constexpr block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108317
Andrew Pinski changed:
What|Removed |Added
Summary|dependent vector field is |dependent vector field is
|not causing this to be |not causing field of this
|captured for fold |not to be found for fold
|expression inside a if |expression inside a if
|constexpr block |constexpr block
--- Comment #3 from Andrew Pinski ---
Simple workaround is to do:
if constexpr(I)
{
r.v_[I] = c + this->v_[I] + (I < M ? o.v_[I] : T{});
c = c ? r.v_[I] <= this->v_[I] : r.v_[I] < this->v_[I];
}
else
{
c = (r.v_[I] = this->v_[I] + o.v_[I]) < this->v_[I];
}
[Bug c++/108317] dependent vector field is not causing this to be captured for fold expression inside a if constexpr block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108317
Andrew Pinski changed:
What|Removed |Added
Target|#1 SMP PREEMPT_DYNAMIC Sat, |
|31 Dec 2022 17:40:35 + |
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-01-06
Summary|g++ is unable to capture|dependent vector field is
|vector-extended variables |not causing this to be
||captured for fold
||expression inside a if
||constexpr block
Host|#1 SMP PREEMPT_DYNAMIC Sat, |
|31 Dec 2022 17:40:35 + |
--- Comment #2 from Andrew Pinski ---
Reduced testcase:
template
struct pint
{
T __attribute__ ((vector_size (2 * sizeof(T v_;
void f(pint const& o)
{
[&]()
{
(
[&]() noexcept
{
if constexpr(I)
{
v_[I];
}
}(),
...
);
}.template operator()<0, 1>();
}
};
int main()
{
using D = pint;
D a;
D b;
a.f(b);
return 0;
}
[Bug libbacktrace/108297] libtool link b2test fails: Unrecognized argument: --build-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Ian Lance Taylor --- The LTO problem seems like a different problem, and doesn't seem related to libbacktrace. If LTO doesn't work HP/UX, do you have a simple test that the configure script could run to see whether it works?
[Bug libbacktrace/108297] libtool link b2test fails: Unrecognized argument: --build-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297 --- Comment #5 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:f3707a55acb980fbcd412ceb980b5621decb4dc0 commit r13-5050-gf3707a55acb980fbcd412ceb980b5621decb4dc0 Author: Ian Lance Taylor Date: Fri Jan 6 09:39:49 2023 -0800 libbacktrace: don't run --build-id tests if it is not supported PR libbacktrace/108297 * configure.ac: Test whether linker supports --build-id. * Makefile.am: Only run --build-id tests if supported. * configure, Makefile.in: Regenerate.
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=56020 --- Comment #45 from Andrew Pinski --- *** Bug 56020 has been marked as a duplicate of this bug. ***
[Bug c/56020] FE_INVALID flag not set on comparison with NAN (unordered)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56020 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=34678 --- Comment #2 from Andrew Pinski --- Dup of bug 34678, FENV_ACCESS is not implemented ... *** This bug has been marked as a duplicate of bug 34678 ***
[Bug c/16989] [meta-bug] C99 conformance bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16989 Bug 16989 depends on bug 56020, which changed state. Bug 56020 Summary: FE_INVALID flag not set on comparison with NAN (unordered) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56020 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 Andrew Pinski changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #44 from Andrew Pinski --- *** Bug 108318 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/108318] Floating point calculation moved out of loop despite fesetround
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108318 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 34678. Techincally you need to use "#pragma STDC FENV_ACCESS ON" also to get this correct but GCC does not implement that pragma which is what PR 34678 is about. *** This bug has been marked as a duplicate of bug 34678 ***
[Bug c++/108309] [12 Regression] ICE in in cxx_eval_component_reference, at cp/constexpr.cc:4136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108309 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105795, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101371 --- Comment #6 from Andrew Pinski --- (In reply to Martin Liška from comment #5) > Fixed on master with r13-963-gd19b4342c19e5a7f I didn't mention it when I produced the reduced testcase but removing the empty base class does cause the ICE to go away so this looks like a real fix ...
[Bug middle-end/108298] Wrong optimization of volatile access from gcc 11 and beyond
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298 --- Comment #7 from Andrew Pinski --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69482#c7 addresses the big issue here I think.
[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108235
--- Comment #11 from Jonathan Wakely ---
(In reply to John David Anglin from comment #10)
> No. We still have the following symbols in tzdb.o:
> U __atomic_compare_exchange_4
> U __atomic_fetch_add_4
Oh the time_zone::_Impl::rules_counter atomic counter is still used even if not
lock-free. I can fix that.
> U __atomic_fetch_add_8
> U __atomic_fetch_sub_8
Ah, these are caused by __detail::__platform_wait_t being uint64_t, which will
be changed soon by
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609479.html
That would mean we only need 4-byte atomics, but if I stop using
time_zone::_Impl::rules_counter for this target, we won't need that either.
>
> There was this warning compiling tzdb.o:
> ../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc: In function 'std::string
> std::chrono::{anonymous}::zoneinfo_dir()':
> ../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:983:44: warning: the
> address of 'const char* __gnu_cxx::zoneinfo_dir_override()' will never be
> NULL [-Waddress]
> 983 | static const string dir = __gnu_cxx::zoneinfo_dir_override
> | ~~~^
> ../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:77:29: note: 'const char*
> __gnu_cxx::zoneinfo_dir_override()' declared here
>77 | [[gnu::weak]] const char* zoneinfo_dir_override()
> | ^
Harmless, it's just because we added the definition of that weak symbol, so now
it's never null.
I'll add a #pragma to ignore -Waddress there.
[Bug rtl-optimization/108318] Floating point calculation moved out of loop despite fesetround
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108318
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #1 from Alexander Monakov ---
Please see documentation for the -frounding-math option, but even with that
option added, your testcase still has the faux-invariant moved by RTL PRE
(-fno-gcse).
Interestingly, if your testcase is modified to compute the sum before the call:
#include
void
foo (double res[4], double a, double b, double x[])
{
a = x[0];
b = x[1];
static const int rm[4]
= { FE_DOWNWARD, FE_TONEAREST, FE_TOWARDZERO, FE_UPWARD };
for (int i = 0; i < 4; ++i)
{
double t = a + b;
fesetround (rm[i]);
res[i] = t;
}
fesetround (FE_TONEAREST); // restore default
}
Then it demonstrates how a few *other* optimizations also perform unwanted
motion:
* SSA PRE (-fno-tree-pre)
* TER (-fno-tree-ter)
* RTL LIM (-fno-move-loop-invariants)
* and finally the register allocator (unavoidable)
[Bug c++/106361] [11/12/13 Regression] Internal compiler error when creating an out-of-line operator==() = default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106361 Patrick Palka changed: What|Removed |Added CC||pacoarjonilla at yahoo dot es --- Comment #10 from Patrick Palka --- *** Bug 93527 has been marked as a duplicate of this bug. ***
[Bug c++/93527] Internal compiler error when static_assert concept std::regular on class with variadic constrained constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93527 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #6 from Patrick Palka --- basically a dup of PR106361, which has been fixed for 11.4/12.3/13 *** This bug has been marked as a duplicate of bug 106361 ***
[Bug libstdc++/108260] __cpp_lib_ranges_zip feature test macro not defined while std::views::zip is supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108260 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Patrick Palka --- Fixed, thanks for the report.
[Bug libstdc++/108260] __cpp_lib_ranges_zip feature test macro not defined while std::views::zip is supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108260 --- Comment #5 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:f7bd48c6bbd3d7a479943b248b973aaf6c59463b commit r13-5049-gf7bd48c6bbd3d7a479943b248b973aaf6c59463b Author: Patrick Palka Date: Fri Jan 6 10:32:10 2023 -0500 libstdc++: Add feature-test macros for implemented C++23 views [PR108260] PR libstdc++/108260 libstdc++-v3/ChangeLog: * include/bits/utility.h (__cpp_lib_ranges_zip): Define for C++23. * include/std/ranges (__cpp_lib_ranges_zip): Likewise. (__cpp_lib_ranges_chunk): Likewise. (__cpp_lib_ranges_slide): Likewise. (__cpp_lib_ranges_chunk_by): Likewise. (__cpp_lib_ranges_join_with): Likewise. (__cpp_lib_ranges_repeat): Likewise. (__cpp_lib_ranges_stride): Likewise. (__cpp_lib_ranges_cartesian_product): Likewise. (__cpp_lib_ranges_as_rvalue): Likewise. * include/std/version: Ditto. * testsuite/20_util/tuple/p2321r2.cc: Verify value of feature-test macro. * testsuite/std/ranges/adaptors/as_rvalue/1.cc: Likewise. * testsuite/std/ranges/adaptors/chunk/1.cc: Likewise. * testsuite/std/ranges/adaptors/chunk_by/1.cc: Likewise. * testsuite/std/ranges/adaptors/join_with/1.cc: Likewise. * testsuite/std/ranges/adaptors/slide/1.cc: Likewise. * testsuite/std/ranges/adaptors/stride/1.cc: Likewise. * testsuite/std/ranges/cartesian_product/1.cc: Likewise. * testsuite/std/ranges/repeat/1.cc: Likewise. * testsuite/std/ranges/zip/1.cc: Likewise. * testsuite/std/ranges/version_c++23.cc: New test.
[Bug libbacktrace/108297] libtool link b2test fails: Unrecognized argument: --build-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297 --- Comment #4 from John David Anglin --- It appears the --build-id issue is fixed by the change. But there's still a lto issue breaking make check: libtool: link: /home/dave/gnu/gcc/objdir64/./prev-gcc/xgcc -B/home/dave/gnu/gcc/ objdir64/./prev-gcc/ -B/opt/gnu64/gcc/gcc-13/hppa64-hp-hpux11.11/bin/ -B/opt/gnu 64/gcc/gcc-13/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-13/hppa64-hp-hpux11. 11/lib/ -isystem /opt/gnu64/gcc/gcc-13/hppa64-hp-hpux11.11/include -isystem /opt /gnu64/gcc/gcc-13/hppa64-hp-hpux11.11/sys-include -fchecking=1 -funwind-tables - frandom-seed=btest_lto -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-pr ototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -g -O -fl to -g -O2 -fchecking=1 -s -o btest_lto btest_lto-btest.o btest_lto-testlib.o ./ .libs/libbacktrace.a ld: Unsatisfied hidden symbol "btest.c.cfb1d6bc". Symbol was referenced from fil e /var/tmp//ccuhlRBW.debug.temp.o ld: Unsatisfied hidden symbol "btest.c.cfb1d6bc". Symbol was referenced from fil e /var/tmp//ccuhlRBW.debug.temp.o ld: Unsatisfied hidden symbol "btest.c.cfb1d6bc". Symbol was referenced from fil e /var/tmp//ccuhlRBW.debug.temp.o [...] 47 errors. collect2: fatal error: ld returned 1 exit status compilation terminated. make[1]: *** [Makefile:1340: btest_lto] Error 1
[Bug ipa/106816] noreturn/pure attributes are not set correctly on multiversioned functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106816 --- Comment #10 from Martin Liška --- (In reply to Martin Jambor from comment #9) > (In reply to Martin Liška from comment #6) > > > > @Martin: Do we have a declaration cloning code for functions somewhere? > > See e.g. cgraph_node::create_virtual_clone in cgraphclones.cc. Unless > you want to mess with the parameters, > > new_decl = copy_node (old_decl); > > should be enough (and it should copy over the DECL_PURE and > TREE_READLONY bit soo, I believe). Thanks! So apparently, we call make_dispatcher_decl which makes only a partial copy of a function_decl: original decl: > QI size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x77656d20 arg-types > pointer_to_this > volatile nothrow public static decl_5 QI /home/marxin/Programming/testcases/pr106816.c:2:6 align:8 warn_if_not_align:0 context attributes > value readonly constant static "default\000">> chain >>> initial result ignored VOID /home/marxin/Programming/testcases/pr106816.c:2:1 align:8 warn_if_not_align:0 context > full-name "void f()" struct-function 0x777df000 chain > dispatcher: (gdb) p debug_tree(func_decl) > QI size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x77656d20 arg-types > pointer_to_this > nothrow public external QI /home/marxin/Programming/testcases/pr106816.c:15:1 align:8 warn_if_not_align:0> So we modify the name, drop 'target' attribute, and so on. Thus we can't use copy_node. > > I am not sure at what point the duplication happens, in order to > duplicate also all the various IPA summaries, cgraph machinery has to > be involved and call all the summary hooks. So > cgraph_node::create_clone should probably be used (or a part of it, or > perhaps even one of its users?). It can happen during the multiple_target.cc IPA pass, so lemme combine the H.J.'s approach and cgraph_node::create_clone.
[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108235
--- Comment #10 from John David Anglin ---
No. We still have the following symbols in tzdb.o:
U __atomic_compare_exchange_4
U __atomic_fetch_add_4
U __atomic_fetch_add_8
U __atomic_fetch_sub_8
There was this warning compiling tzdb.o:
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc: In function 'std::string
std::chrono::{anonymous}::zoneinfo_dir()':
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:983:44: warning: the address
of 'const char* __gnu_cxx::zoneinfo_dir_override()' will never be NULL
[-Waddress]
983 | static const string dir = __gnu_cxx::zoneinfo_dir_override
| ~~~^
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:77:29: note: 'const char*
__gnu_cxx::zoneinfo_dir_override()' declared here
77 | [[gnu::weak]] const char* zoneinfo_dir_override()
| ^
[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108235 --- Comment #9 from John David Anglin --- Created attachment 54206 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54206=edit Updated preprocessed source
[Bug rtl-optimization/108318] New: Floating point calculation moved out of loop despite fesetround
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108318
Bug ID: 108318
Summary: Floating point calculation moved out of loop despite
fesetround
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
#include
void
foo (double res[4], double a, double b)
{
static const int rm[4]
= { FE_DOWNWARD, FE_TONEAREST, FE_TOWARDZERO, FE_UPWARD };
for (int i = 0; i < 4; ++i)
{
fesetround (rm[i]);
res[i] = a + b;
}
fesetround (FE_TONEAREST); // restore default
}
when compiled with recent trunk and -O3, yields
addsd %xmm1, %xmm0
pushq %r14
.cfi_def_cfa_offset 16
.cfi_offset 14, -16
pushq %rbp
.cfi_def_cfa_offset 24
.cfi_offset 6, -24
movq%rdi, %rbp
pushq %rbx
.cfi_def_cfa_offset 32
.cfi_offset 3, -32
xorl%ebx, %ebx
movq%xmm0, %r14
.L2:
movlrm.0(,%rbx,4), %edi
callfesetround
movq%r14, 0(%rbp,%rbx,8)
addq$1, %rbx
cmpq$4, %rbx
jne .L2
popq%rbx
.cfi_def_cfa_offset 24
xorl%edi, %edi
popq%rbp
.cfi_def_cfa_offset 16
popq%r14
.cfi_def_cfa_offset 8
jmp fesetround
.cfi_endproc
Seems all right after tree optimization, the *.optimized dump looks OK:
[local count: 858993457]:
# ivtmp.5_16 = PHI
_1 = MEM[(int *) + ivtmp.5_16 * 4];
fesetround (_1);
_5 = a_12(D) + b_13(D);
MEM[(double *)res_11(D) + ivtmp.5_16 * 8] = _5;
ivtmp.5_7 = ivtmp.5_16 + 1;
if (ivtmp.5_7 != 4)
goto ; [80.00%]
else
goto ; [20.00%]
[local count: 214748368]:
fesetround (0); [tail call]
return;
This does not seem to be a recent regression, this goes back to at
least gcc 4.1.2.
Noted by Michael S on comp.arch, on
https://groups.google.com/g/comp.arch/c/Izheu-k00Nw/m/oljg70SBBwAJ .
[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512 Jessica Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com --- Comment #11 from Jessica Clarke --- Macros and __has_feature are equally expressive, sure, but why should Clang change what it’s been doing from the start because GCC doesn’t want to be compatible with how it’s always done it? It seems a bit rude to expect Clang to change when it was the one to define how these worked first and GCC took its implementation. It’s not like it’s a complicated thing for GCC to implement, and it should really have done so when it added sanitizer support in order to be fully compatible rather than do things differently and force users to support both ways in their code (which, to this day, isn’t reliably done, so there is code out there that only works with Clang’s sanitizers).
[Bug modula2/108182] gm2 driver mishandles target and multilib options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
--- Comment #6 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Gaius Mulley from comment #4)
> > Created attachment 54184 [details]
> > Potential fix for target multilib_dir handling -m and -f.
> >
> > Work in progress.
>
> 1. (I think) the string you need is "multilib_os_dir" not "multilib_dir"
> (but ICBW about that .. there are many twisty passages in the determination
> of these things).
It seems that I was wrong about this ... at least on
x86_65-linux-gnu (which does use MULTILIB_OSDIRNAMES) and
*-darwin* (which does not).
It seems to DTRT.
(tested on linux with a 32b multilib)
> 2. The concern remains that the language spec handler is run pretty much
> first in the stack and there are several other claims on the command line
> that could have specs that alter (or add) flags to the command line, giving
> a different outcome to the computation of mulilib_{,os_}dir.
>
> perhaps it would be a good idea to post this and ask the opinion of someone
> like Joseph on the direction.
So ... the proposed patch seems to fix the problem for Darwin and X86_64 Linux.
definitely post it!
(we still need to fix the issue with the shared libraries hidden by the
additional -Ls but that's a one-line patch)
[Bug target/107843] error: incompatible type for argument in ___bpf_ctx_cast2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107843 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-01-06 Ever confirmed|0 |1 --- Comment #2 from Jose E. Marchesi --- Opened a clang/llvm bug for this, to see if they would consider turning the warning into an error to converge with GCC's behavior. https://github.com/llvm/llvm-project/issues/59858
[Bug target/106773] libbpf: failed to find BTF info for global/extern symbol 'bpf_link_fops'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773 Jose E. Marchesi changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #20 from Jose E. Marchesi --- This is fixed.
[Bug target/106745] segfault in bpf_core_get_sou_member_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106745 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jose E. Marchesi --- This is fixed.
[Bug libstdc++/108214] [13 Regression] writinng bitset to stringstream fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108214 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- Dumb mistake fixed, thanks for the report!
[Bug c++/108317] g++ is unable to capture vector-extended variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108317 --- Comment #1 from Janez Zemva --- Created attachment 54205 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54205=edit sample file demonstrating the bug
[Bug libstdc++/108214] [13 Regression] writinng bitset to stringstream fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108214 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:553332c19a04ad0a6bbdd2aafc3499a1cb4dfa0c commit r13-5048-g553332c19a04ad0a6bbdd2aafc3499a1cb4dfa0c Author: Jonathan Wakely Date: Fri Jan 6 13:42:07 2023 + libstdc++: Fix misuse of alloca in std::bitset [PR108214] The use of alloca in a constructor is wrong, because the memory is gone after the constructor returns, and will be overwritten by a subsequent function call. This didn't show up in testing because function inlining alters the stack usage. libstdc++-v3/ChangeLog: PR libstdc++/108214 * include/std/bitset (operator>>): Use alloca in the right scope, not in a constructor. * testsuite/20_util/bitset/io/input.cc: Check case from PR.
[Bug c++/108317] New: g++ is unable to capture vector-extended variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108317
Bug ID: 108317
Summary: g++ is unable to capture vector-extended variables
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janezz55 at gmail dot com
Target Milestone: ---
Created attachment 54204
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54204=edit
sample file demonstrating the bug
g++ will be unable to capture v_ in the code sample below, but clang++ will do
so just fine.
template
auto operator+(pint const& o) const noexcept
{
pint r;
[&](std::index_sequence) noexcept
{
bool c;
(
[&]() noexcept
{
if constexpr(I)
{
r.v_[I] = c + v_[I] + (I < M ? o.v_[I] : T{});
c = c ? r.v_[I] <= v_[I] : r.v_[I] < v_[I];
}
else
{
c = (r.v_[I] = v_[I] + o.v_[I]) < v_[I];
}
}(),
...
);
}(std::make_index_sequence());
return r;
}
error: 'v_' was not declared in this scope
[Bug target/107453] [13 Regression] New stdarg tests in r13-3549-g4fe34cdcc80ac2 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107453 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 54203 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54203=edit gcc13-pr107453.patch I wonder if we shouldn't apply following patch. At least c2x-stdarg-4.c with it passes on powerpc64le-linux and I don't see any regressions on dg.exp=*stdarg* on x86_64-linux -m32/-m64.
[Bug libstdc++/108305] FAIL: 27_io/basic_ofstream/open/char/noreplace.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108305 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-01-06 Status|UNCONFIRMED |NEW --- Comment #6 from Jonathan Wakely --- Bah.
[Bug libstdc++/108305] FAIL: 27_io/basic_ofstream/open/char/noreplace.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108305 --- Comment #5 from Andreas Schwab --- Ignoring unknown fopen flags is traditional behavior which is still present today, both in BSD and GNU. Only the first character is actually checked and rejected if unknown.
[Bug libstdc++/108221] Building cross compiler for H8 family fails at libstdc++-v3/src/c++20/tzdb.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- Fixed, but the build still fails as mentioned above.
[Bug libstdc++/108221] Building cross compiler for H8 family fails at libstdc++-v3/src/c++20/tzdb.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221 --- Comment #4 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8c330fd49464f3d47a7c171d767eb3a011add76b commit r13-5047-g8c330fd49464f3d47a7c171d767eb3a011add76b Author: Jonathan Wakely Date: Thu Jan 5 14:04:32 2023 + libstdc++: Disable broken std::format for floating-point types [PR108221] If we don't have std::to_chars for floating-point types (either because float and double are not IEEE format, or size_t is 16-bit) then we can't use them with std::format. This causes a bootstrap failure since std/c++20/tzdb.cc was added to the library, because now includes . This change just disables formatting support for those types. This is not a proper fix, but solves the bootstrap failure for now. libstdc++-v3/ChangeLog: PR libstdc++/108221 * include/std/format (basic_format_arg) [!__cpp_lib_to_chars]: Disable visiting floating-point types.
[Bug target/108172] [13 Regression] ICE in emit_move_multi_word, at expr.cc:4087 since r13-4616-g2cba118e538ba0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108172 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Tamar Christina --- Actually I don't really have the time right now for what the reviewer wanted. so reverted with g:a40c22c377c7cc657b0feaf0119d84d0d142a318 and will resubmit next year.
[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767 --- Comment #17 from Martin Liška --- Oh, I didn't notice it's P1 :) Then sure, send it for this release.
[Bug target/108172] [13 Regression] ICE in emit_move_multi_word, at expr.cc:4087 since r13-4616-g2cba118e538ba0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108172 Tamar Christina changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org --- Comment #3 from Tamar Christina --- A patch was already submitted for this, I just need to respin it.
[Bug middle-end/108312] NULL definition in system.h is no longer needed any more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108312 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org CC||marxin at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Martin Liška --- Lemme send a patch for it.
[Bug middle-end/108311] system.h defines va_copy but we require C++11 compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108311 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Lemme send a patch for it.
[Bug target/108172] [13 Regression] ICE in emit_move_multi_word, at expr.cc:4087 since r13-4616-g2cba118e538ba0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108172 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||ktkachov at gcc dot gnu.org, ||rearnsha at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I think the problem is that while movv8hf and movv4hf expanders have just TARGET_FLOAT condition, movv2hf has TARGET_FLOAT && TARGET_SIMD_F16INST condition. But aarch64_classify_vector_mode enables V2HFmode whenever TARGET_FLOAT. So, IMHO (but what do I know about aarch64), either we need: --- gcc/config/aarch64/aarch64.cc.jj2022-12-14 20:30:40.492312699 +0100 +++ gcc/config/aarch64/aarch64.cc 2023-01-06 13:17:53.475412480 +0100 @@ -3634,8 +3634,9 @@ aarch64_classify_vector_mode (machine_mo case E_V8BFmode: case E_V4SFmode: case E_V2DFmode: -case E_V2HFmode: return TARGET_FLOAT ? VEC_ADVSIMD : 0; +case E_V2HFmode: + return TARGET_FLOAT && TARGET_SIMD_F16INST ? VEC_ADVSIMD : 0; default: return 0; (which fixes the ICE but haven't tested it in any way further) or movv2hf needs to work even for plain TARGET_FLOAT && !TARGET_SIMD_F16INST.
[Bug target/108316] [13 Regression] ICE in maybe_gen_insn via expand_SCATTER_STORE when vectorizing for SVE since r13-2737-g4a773bf2f08656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108316 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Summary|[13 Regression] ICE in |[13 Regression] ICE in |maybe_gen_insn via |maybe_gen_insn via |expand_SCATTER_STORE when |expand_SCATTER_STORE when |vectorizing for SVE |vectorizing for SVE since ||r13-2737-g4a773bf2f08656 Last reconfirmed||2023-01-06 Target Milestone|--- |13.0 CC||marxin at gcc dot gnu.org, ||richard.sandiford at arm dot com Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r13-2737-g4a773bf2f08656.
[Bug libstdc++/103755] {has,use}_facet() and iostream constructor performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Jonathan Wakely --- Fixed then.
[Bug libstdc++/107799] Wrong return type for std::bit_width
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107799 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |13.0 --- Comment #4 from Jonathan Wakely --- Done in r13-4293-g4581328022615c
[Bug libstdc++/108118] std::weak_ptr lacks a self-usurp check on move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108118 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.4 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug middle-end/107966] [10/11/12/13 Regression] option property Var(var) documentation seems cut off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107966 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Improved, not planning to do a backport.
[Bug middle-end/107966] [10/11/12/13 Regression] option property Var(var) documentation seems cut off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107966 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:17176326de45cc7de4f8cedf4414b40df0df39bb commit r13-5045-g17176326de45cc7de4f8cedf4414b40df0df39bb Author: Martin Liska Date: Wed Dec 28 10:16:58 2022 +0100 docs: fix Var documentation for .opt files The Var documentation was somehow wrongly split into 2 pieces. PR middle-end/107966 gcc/ChangeLog: * doc/options.texi: Fix Var documentation in internal manual.
[Bug middle-end/108300] `abort()` macro cause bootstrap failure on *-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
--- Comment #5 from LIU Hao ---
A quick and obvious fix is to add `CPPFLAGS='-DWIN32_LEAN_AND_MEAN'` when
configuring. Bootstrapped successfully on {i686,x86_64}-w64-mingw32.
I still think GCC source files should be patched.
[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |10.5 --- Comment #10 from Jonathan Wakely --- Fixed on trunk, but it should be backported too.
[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288 --- Comment #9 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b9479ddc7a28fb672ca67304a67d66524d8200a4 commit r13-5044-gb9479ddc7a28fb672ca67304a67d66524d8200a4 Author: Jonathan Wakely Date: Thu Jan 5 16:23:51 2023 + libstdc++: Fix deadlock in debug iterator increment [PR108288] With -fno-elide-constructors the debug iterator post-increment and post-decrement operators are susceptible to deadlock. They take a mutex lock and then return a temporary, which also attempts to take a lock to attach itself to the sequence. If the return value and *this happen to collide and use the same mutex from the pool, then you get a deadlock trying to lock a mutex that is already held by the current thread. The solution is to construct the return value before taking the lock. The copy constructor and pre-inc/pre-dec operators already manage locks correctly, without deadlock, so just implement post-inc/post-dec in the conventional way, taking a copy then modifying *this, then returning the copy. libstdc++-v3/ChangeLog: PR libstdc++/108288 * include/debug/safe_iterator.h (_Safe_iterator::operator++(int)) (_Safe_iterator::operator--(int)): Do not hold lock around construction of return value.
[Bug tree-optimization/108314] [13 Regression] Segfault in gimple-match-head.cc:do_valueize when vectorizing for SVE since r13-707-g68e0063397ba82
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108314 Martin Liška changed: What|Removed |Added Last reconfirmed||2023-01-06 Status|UNCONFIRMED |NEW Summary|[13 Regression] Segfault in |[13 Regression] Segfault in |gimple-match-head.cc:do_val |gimple-match-head.cc:do_val |ueize when vectorizing for |ueize when vectorizing for |SVE |SVE since ||r13-707-g68e0063397ba82 Ever confirmed|0 |1 Target Milestone|--- |13.0 Version|12.0|13.0 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r13-707-g68e0063397ba82.
[Bug middle-end/108268] [13 Regression] Build failure on cross from powerpc64le-linux to nvptx-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108268 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jakub Jelinek --- r13-4980-gd010efbfb89721bc9ca9e657e980ff0d8e6187af reverted the problematic commit, so it should build now fine again.
[Bug target/108316] New: [13 Regression] ICE in maybe_gen_insn via expand_SCATTER_STORE when vectorizing for SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108316
Bug ID: 108316
Summary: [13 Regression] ICE in maybe_gen_insn via
expand_SCATTER_STORE when vectorizing for SVE
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following appears to be a regression on the trunk:
$ cat t.cc
extern bool a[];
short i;
void f(int b[][3][2]) {
for (; i; i += 4)
a[i] = b[0][i] != 0;
}
$ aarch64-none-elf-gcc -c t.cc -march=armv9-a -O2 -fvect-cost-model=unlimited
during RTL pass: expand
t.cc: In function 'void f(int (*)[3][2])':
t.cc:3:6: internal compiler error: in maybe_gen_insn, at optabs.cc:8059
3 | void f(int b[][3][2]) {
| ^
0x105f613 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
/home/alecop01/toolchain/src/gcc/gcc/optabs.cc:8059
0x105f80e maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/home/alecop01/toolchain/src/gcc/gcc/optabs.cc:8105
0x105ed93 expand_insn(insn_code, unsigned int, expand_operand*)
/home/alecop01/toolchain/src/gcc/gcc/optabs.cc:8136
0xead67a expand_scatter_store_optab_fn
/home/alecop01/toolchain/src/gcc/gcc/internal-fn.cc:3430
0xead8dd expand_SCATTER_STORE
/home/alecop01/toolchain/src/gcc/gcc/internal-fn.def:137
0xeaddd2 expand_internal_call(internal_fn, gcall*)
/home/alecop01/toolchain/src/gcc/gcc/internal-fn.cc:4436
0xeaddec expand_internal_call(gcall*)
/home/alecop01/toolchain/src/gcc/gcc/internal-fn.cc:
0xbffbdc expand_call_stmt
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.cc:2737
0xbffbdc expand_gimple_stmt_1
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.cc:3880
0xbffbdc expand_gimple_stmt
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.cc:4044
0xc0916f expand_gimple_basic_block
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.cc:6096
0xc0a9b9 execute
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.cc:6822
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/108309] [12 Regression] ICE in in cxx_eval_component_reference, at cp/constexpr.cc:4136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108309 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #5 from Martin Liška --- Fixed on master with r13-963-gd19b4342c19e5a7f and it started with r12-2304-ga42f8120442cf3ba.
[Bug middle-end/106133] ICE: SIGSEGV in diagnostic_output_format_init_json_file() with -fdiagnostics-format=json-file -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106133 --- Comment #3 from Martin Liška --- *** Bug 108307 has been marked as a duplicate of this bug. ***
[Bug driver/108307] ICE compiling .S file with -fdiagnostics-format=sarif-file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108307 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Martin Liška --- It's going to be fixed with the same patch, thus closing as duplicate. *** This bug has been marked as a duplicate of bug 106133 ***
[Bug target/108315] New: -mcpu=power10 changes ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 Bug ID: 108315 Summary: -mcpu=power10 changes ABI Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ABI, wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: amonakov at gcc dot gnu.org Target Milestone: --- Target: powerpc64le-*-* Created attachment 54202 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54202=edit testcase At least the documentation should mention that if intentional. In the attached example, the function bar is compiled to bar: .localentry bar,1 mtctr 3 mr 12,3 bctr .long 0 .byte 0,0,0,0,0,0,0,0 i.e. it does not preserve r2 (it's compiled with -mcpu=power10). If the caller is not compiled with -mcpu=power10, it needs r2 preserved (bar has a localentry, so the nop in the caller stays a nop after linking). I verified the testcase misbehaves on Compile Farm's gcc135: as it does not use any power10-specific instructions, it's runnable there.
[Bug middle-end/108298] Wrong optimization of volatile access from gcc 11 and beyond
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #6 from Martin Liška --- I think it started with r11-165-geb72dc663e9070b2.
[Bug c++/108047] [13 Regression] ICE: unexpected expression of kind implicit_conv_expr since r13-4564-gd081807d8d70e3e8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108047 --- Comment #8 from Jakub Jelinek --- Created attachment 54201 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54201=edit gcc13-pr108047.patch My current understanding is that even if nothing in the initializer is dependent maybe_init_list_as_range will be called again during instantiation with !processing_template_decl and because this is just an optimization, I think it should be fine to do the optimization only if !processing_template_decl.
[Bug target/108293] Incorrect assembly emitted for float for BPF target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108293 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Last reconfirmed||2023-01-06 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug libstdc++/106611] std::is_nothrow_copy_constructible returns wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #7 from Jiang An --- The standard wording says "... is known not to throw any exceptions ([expr.unary.noexcept])" for is_nothrow_* traits. It's arguably that the wording is ambiguous - when the defaulted function is marked `noexcept(false)` but the implicit exception specification would be `noexcept(true)`, it may still be possible to say the operation "is known not to throw any exceptions". But the reference to [expr.unary.noexcept] seemly suggests that the results consistent with noexcept operator should be used. This may deserve an LWG issue.
