[Bug tree-optimization/104288] [11/12 Regression] EVRP null pointer check removal for strcmp (and maybe others) is not flow senative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104288 --- Comment #16 from Christian Prochaska --- (In reply to Andrew Pinski from comment #14) > > There was a deferencing of myself before: > Nova::Utcb &utcb = *(Nova::Utcb *)myself->utcb(); I see. The 'Thread::utcb()' function handles the null pointer case internally with a 'this == 0' check and a local '-fno-delete-null-pointer-checks' attribute: https://github.com/genodelabs/genode/blob/a84af9a9606450471b8038a35f9b55057efa0850/repos/base-nova/src/lib/base/stack.cc#L110 So, the elimination of the 'myself' null pointer check is basically a result of undefined behavior with the 'Thread::utcb()' function?
[Bug tree-optimization/104288] [11/12 Regression] EVRP null pointer check removal for strcmp (and maybe others) is not flow senative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104288 --- Comment #17 from Andrew Pinski --- (In reply to Christian Prochaska from comment #16) > (In reply to Andrew Pinski from comment #14) > > > > There was a deferencing of myself before: > > Nova::Utcb &utcb = *(Nova::Utcb *)myself->utcb(); > > I see. The 'Thread::utcb()' function handles the null pointer case > internally with a 'this == 0' check and a local > '-fno-delete-null-pointer-checks' attribute: > > https://github.com/genodelabs/genode/blob/ > a84af9a9606450471b8038a35f9b55057efa0850/repos/base-nova/src/lib/base/stack. > cc#L110 > > So, the elimination of the 'myself' null pointer check is basically a result > of undefined behavior with the 'Thread::utcb()' function? That only handles one side of where it is undefined. Newer GCC uses it as being undefined even on the calling side. So you need to use -fno-delete-null-pointer-checks really on the command line or better yet fixes all of the places which use ->utcb() .
[Bug c/109450] VLA struct definition vs use in the function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109450 --- Comment #2 from Martin Uecker --- This is unrelated to PR29970. The cause of this is that gimplify_parm_type recurses into incomplete types which is wrong for the same reason as in gimplify_type_sizes.
[Bug c++/109455] New: false-positive -Wstringop-overflow warning when using std::vector with UBsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109455
Bug ID: 109455
Summary: false-positive -Wstringop-overflow warning when using
std::vector with UBsan
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manx-bugzilla at problemloesungsmaschine dot de
Target Milestone: ---
```
// g++ -std=c++20 -fexceptions -frtti -pthread -fsanitize=undefined -O3 -Wall
-Wextra -Wpedantic -c test.cpp
// GCC 12.2
#include
#include
struct Table {
Table();
void SetSize(std::size_t size);
std::vector m_Table;
};
Table::Table() {
m_Table.resize(42, 23);
}
void Table::SetSize(std::size_t size) {
m_Table.resize(size);
}
```
results in
```
In file included from /usr/include/c++/12/vector:60,
from test.cpp:4:
In static member function ‘static constexpr _Tp* std::__copy_move<_IsMove,
true, std::random_access_iterator_tag>::__copy_m(const _Tp*, const _Tp*, _Tp*)
[with _Tp = unsigned char; bool _IsMove = true]’,
inlined from ‘constexpr _OI std::__copy_move_a2(_II, _II, _OI) [with bool
_IsMove = true; _II = unsigned char*; _OI = unsigned char*]’ at
/usr/include/c++/12/bits/stl_algobase.h:495:30,
inlined from ‘constexpr _OI std::__copy_move_a1(_II, _II, _OI) [with bool
_IsMove = true; _II = unsigned char*; _OI = unsigned char*]’ at
/usr/include/c++/12/bits/stl_algobase.h:522:42,
inlined from ‘constexpr _OI std::__copy_move_a(_II, _II, _OI) [with bool
_IsMove = true; _II = unsigned char*; _OI = unsigned char*]’ at
/usr/include/c++/12/bits/stl_algobase.h:529:31,
inlined from ‘constexpr _OI std::copy(_II, _II, _OI) [with _II =
move_iterator; _OI = unsigned char*]’ at
/usr/include/c++/12/bits/stl_algobase.h:620:7,
inlined from ‘static _ForwardIterator
std::__uninitialized_copy::__uninit_copy(_InputIterator, _InputIterator,
_ForwardIterator) [with _InputIterator = std::move_iterator;
_ForwardIterator = unsigned char*]’ at
/usr/include/c++/12/bits/stl_uninitialized.h:147:27,
inlined from ‘_ForwardIterator std::uninitialized_copy(_InputIterator,
_InputIterator, _ForwardIterator) [with _InputIterator = move_iterator; _ForwardIterator = unsigned char*]’ at
/usr/include/c++/12/bits/stl_uninitialized.h:185:15,
inlined from ‘constexpr _ForwardIterator
std::__uninitialized_copy_a(_InputIterator, _InputIterator, _ForwardIterator,
allocator<_Tp>&) [with _InputIterator = move_iterator;
_ForwardIterator = unsigned char*; _Tp = unsigned char]’ at
/usr/include/c++/12/bits/stl_uninitialized.h:372:37,
inlined from ‘constexpr _ForwardIterator
std::__uninitialized_move_if_noexcept_a(_InputIterator, _InputIterator,
_ForwardIterator, _Allocator&) [with _InputIterator = unsigned char*;
_ForwardIterator = unsigned char*; _Allocator = allocator]’ at
/usr/include/c++/12/bits/stl_uninitialized.h:397:2,
inlined from ‘constexpr void std::vector<_Tp,
_Alloc>::_M_fill_insert(iterator, size_type, const value_type&) [with _Tp =
unsigned char; _Alloc = std::allocator]’ at
/usr/include/c++/12/bits/vector.tcc:594:7,
inlined from ‘constexpr void std::vector<_Tp, _Alloc>::resize(size_type,
const value_type&) [with _Tp = unsigned char; _Alloc = std::allocator]’ at /usr/include/c++/12/bits/stl_vector.h:1032:18,
inlined from ‘Table::Table()’ at test.cpp:14:16:
/usr/include/c++/12/bits/stl_algobase.h:431:30: warning: ‘void*
__builtin_memmove(void*, const void*, long unsigned int)’ writing 1 or more
bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
431 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
| ~^~~
In file included from
/usr/include/x86_64-linux-gnu/c++/12/bits/c++allocator.h:33,
from /usr/include/c++/12/bits/allocator.h:46,
from /usr/include/c++/12/vector:61:
In member function ‘_Tp* std::__new_allocator<_Tp>::allocate(size_type, const
void*) [with _Tp = unsigned char]’,
inlined from ‘constexpr _Tp* std::allocator<
>::allocate(std::size_t) [with _Tp = unsigned char]’ at
/usr/include/c++/12/bits/allocator.h:188:40,
inlined from ‘static constexpr _Tp*
std::allocator_traits >::allocate(allocator_type&,
size_type) [with _Tp = unsigned char]’ at
/usr/include/c++/12/bits/alloc_traits.h:464:28,
inlined from ‘constexpr std::_Vector_base<_Tp, _Alloc>::pointer
std::_Vector_base<_Tp, _Alloc>::_M_allocate(std::size_t) [with _Tp = unsigned
char; _Alloc = std::allocator]’ at
/usr/include/c++/12/bits/stl_vector.h:378:33,
inlined from ‘constexpr void std::vector<_Tp,
_Alloc>::_M_fill_insert(iterator, size_type, const value_type&) [with _Tp =
unsigned char; _Alloc = std::allocator]’ at
/usr/include/c++/12/bits/vector.tcc:575:45,
inlined from ‘constexpr void std::vector<_Tp, _Alloc>::resi
[Bug c++/109356] Enhancement idea to provide clearer missing brace line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356 --- Comment #7 from Xi Ruoyao --- (In reply to Jonny Grant from comment #6) > Tried a few other compilers on godbolt. > > ICC gets the warning on line 6 > https://godbolt.org/z/fYb9c8f61 > > nvc++ gives the warning on line 6 > https://godbolt.org/z/xvh67odzY > > MSVC and Clang don't. This is just blind luck. All of these compilers attempt to "fix" the syntax error by adding "}" at line 8 (not line 6!) and produce further warnings. It's just ICC and nvc++ report "excess elements in initializer" at the beginning of the initializer, while the other compilers report it at the end. Strictly speaking all of them are false warnings as there is no excess elements in the initializer (according to the programmer's mind). But the only thing the parser can do is guessing the programmer wanted a "}" at line 8.
[Bug c/107557] [12/13 Regression] ICE -fsanitize=undefined and VLA as argument type to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107557 --- Comment #8 from Martin Uecker --- Created attachment 54818 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54818&action=edit another version This works without regressions, but is still not correct.
[Bug libstdc++/88508] std::bad_cast in std::basic_ostringstream.oss.fill()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88508 --- Comment #5 from Jonathan Wakely --- No, you can't disable it with SFINAE, because it's a runtime property. If you define ctype yourself and add it to a locale at runtime, and use that locale with the stream, then it works. We can't disable things at compile time if the program can make them work at runtime. You get the same behaviour trying to use a stream of char16_t or unsigned char or std::byte or myprog::char_type. Like I said, it's not actually a problem with UTF-8. Streams just don't support any of those types out of the box, irrespective of the encoding they happen to use.
[Bug c/109456] New: `-ffixed` is ignored for `a` registers on RISC-V.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109456 Bug ID: 109456 Summary: `-ffixed` is ignored for `a` registers on RISC-V. Product: gcc Version: 12.2.1 Status: UNCONFIRMED Keywords: inline-asm, wrong-code Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gccriscvuser at proton dot me Target Milestone: --- Created attachment 54819 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54819&action=edit Reduced testcase to a small file that doesn't include any other file === Problem Description Register `a4` is normally used for passing parameters in a call. https:github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc As such, it would be problematic to use `a4` for a global as shown here. https:gcc.gnu.org/onlinedocs/gcc/Global-Register-Variables.html However, if this code is compiled with `-ffixed-a4`, then `a4` should be reserved for this global register variable. https:gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html If it were reserved as the documentation specifies, then the value of `global_a4` should remain `999` across the call to `alpha` below. However, it is changes to `4`, which demonstrates the bug. The bug can also be observed by inspecting the assembly language emitted by GCC. #: global_a4 = 999; li a4,999 # global_a4, #: alpha(0, 1, 2, 3, 4); li a4,4#, li a3,3#, li a2,2#, li a1,1#, li a0,0#, callalpha # #: return global_a4 < 100; sext.w a5,a4 # global_a4.0_1, global_a4 mv a3,a5 # tmp78, global_a4.0_1 li a5,99 # tmp79, sgtua5,a3,a5# tmp80, tmp78, tmp79 Note that the call uses `a4` as a parameter with `li a4,4` even though the GCC command line has `-ffixed-a4`. This is the essence of the bug. The consequence is that the data in `a4` is corrupted when it is used for `global_a4` on `sext.w a5,a4`. === Proposed Solutions Three reasonable solutions, starting with the most preferred, are: 1. Use register `a5` for `param_a4` since `a4` is not available, 2. Pass `param_a4` on the stack, or 3. Issue an error diagnostic. === Testing The issue has been identified with the following GCC versions. The command line used for each is included along with the version comment from the top of the assembly-language output. riscv64-linux-gnu-gcc (GCC) 12.2.1 20220819 (Red Hat Cross 12.2.1-2) riscv64-linux-gnu-gcc -ffixed-a4 -O0 -dA -fverbose-asm -S -o gccbug.ffizeda4.s gccbug.ffizeda4.c GNU C17 (GCC) version 12.2.1 20220819 (Red Hat Cross 12.2.1-2) (riscv64-linux-gnu) compiled by GNU C version 12.2.1 20221121 (Red Hat 12.2.1-4), GMP version 6.2.1, MPFR version 4.1.0-p13, MPC version 1.2.1, isl version none riscv64-linux-gnu-gcc-10 (Debian 10.2.1-6) 10.2.1 20210110 riscv64-linux-gnu-gcc-10 -ffixed-a4 -O0 -dA -fverbose-asm -S -o gccbug.ffizeda4.s gccbug.ffizeda4.c GNU C17 (Debian 10.2.1-6) version 10.2.1 20210110 (riscv64-linux-gnu) compiled by GNU C version 10.2.1 20210110, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.0, isl version isl-0.23-GMP riscv64-unknown-elf-gcc GCC 8.3.0 (Debian) riscv64-unknown-elf-gcc -ffixed-a4 -O0 -dA -fverbose-asm -S -o gccbug.ffizeda4.s gccbug.ffizeda4.c GNU C17 () version 8.3.0 (riscv64-unknown-elf) compiled by GNU C version 9.2.1 20190909, GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version none riscv64-elf-gcc (GCC) 8.2.0 riscv64-elf-gcc -ffixed-a4 -O0 -dA -fverbose-asm -S -o gccbug.ffizeda4.s gccbug.ffizeda4.c GNU C17 (GCC) version 8.2.0 (riscv64-elf) compiled by GNU C version 4.4.7 20120313 (Red Hat 4.4.7-17), GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP
[Bug c/109456] `-ffixed` is ignored for `a` registers on RISC-V.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109456 --- Comment #1 from gccriscvuser at proton dot me --- Corrected URLs from original description: Register `a4` is normally used for passing parameters in a call. https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc As such, it would be problematic to use `a4` for a global as shown here. https://gcc.gnu.org/onlinedocs/gcc/Global-Register-Variables.html However, if this code is compiled with `-ffixed-a4`, then `a4` should be reserved for this global register variable. https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
[Bug middle-end/109456] `-ffixed` is ignored for `a` registers on RISC-V.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109456 --- Comment #2 from Andrew Pinski --- > or in some other fixed role
[Bug middle-end/109456] `-ffixed` is ignored for `a` registers on RISC-V.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109456 --- Comment #3 from Andrew Pinski --- Seems like using a global register is not really recommended, especially one that is used for argument passing.
[Bug target/109456] `-ffixed` is ignored for `a` registers on RISC-V.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109456 Andrew Pinski changed: What|Removed |Added Component|middle-end |target Keywords|inline-asm | Target||riscv --- Comment #4 from Andrew Pinski --- Anyways this is a target issue when setting up arguments.
[Bug libstdc++/86164] std::regex crashes when matching long lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164 --- Comment #15 from Nadav Har'El --- More than 5 years later, more and more projects are discovering this bug the hard way, and moving from std::regex to boost::regex which doesn't have this bug - boost::regex defaults to BOOST_REGEX_NON_RECURSIVE mode, which uses a stack on the heap instead of recursion (but I don't know if the specific examples shown the various duplicates all need this stack in practice, for example it's unfortunate if matching " *" needs to copy the entire input string in a stack). The latest example of this exodus is https://github.com/scylladb/scylladb/pull/13452. So I think it's about time this issue is solved. Maybe even the Boost implementation can studied for inspiration and implementation ideas?
[Bug tree-optimization/109455] false-positive -Wstringop-overflow warning when using std::vector with UBsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109455 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Component|c++ |tree-optimization --- Comment #1 from Andrew Pinski --- From https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fsanitize_003dundefined Note that sanitizers tend to increase the rate of false positive warnings, most notably those around -Wmaybe-uninitialized. We recommend against combining -Werror and [the use of] sanitizers.
[Bug c++/109457] New: %z[asmSymbolicName] in AssemblerTemplate fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109457
Bug ID: 109457
Summary: %z[asmSymbolicName] in AssemblerTemplate fails to
compile
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: seeson at pku dot edu.cn
Target Milestone: ---
Created attachment 54820
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54820&action=edit
The code that fails to compile, with the .ii and .s files saved.
Ubuntu 22.04.2 LTS
g++ (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
When using modifier `z` on `[asmSymbolicName]`, the code won't compile.
// the one's complement addition on x86_64
template
inline T onec_add(T a, T b)
{
asm("add%z[b]\t%[b], %[a]"
"\n\tadc%z[b]\t$0, %[a]"
: [a]"+g"(a) // inputs
: [b]"g"(b) // outputs
: "cc"// clobbers
);
return a;
}
$ g++ -Wall -g -Og test.cpp -o test
test.cpp: In function ‘int main()’:
test.cpp:42:3: error: invalid 'asm': invalid operand type used with operand
code 'Z'
42 | asm("add%z[b]\t%[b], %[a]"
| ^~~
test.cpp:42:3: error: invalid 'asm': invalid operand type used with operand
code 'Z'
test.cpp:42:3: error: invalid 'asm': invalid operand type used with operand
code 'Z'
42 | asm("add%z[b]\t%[b], %[a]"
| ^~~
test.cpp:42:3: error: invalid 'asm': invalid operand type used with operand
code 'Z'
test.cpp:42:3: error: invalid 'asm': invalid operand type used with operand
code 'Z'
42 | asm("add%z[b]\t%[b], %[a]"
| ^~~
test.cpp:42:3: error: invalid 'asm': invalid operand type used with operand
code 'Z'
test.cpp:42:3: error: invalid 'asm': invalid operand type used with operand
code 'Z'
42 | asm("add%z[b]\t%[b], %[a]"
| ^~~
test.cpp:42:3: error: invalid 'asm': invalid operand type used with operand
code 'Z'
Unexpectedly, the error report says the wrong modifier is 'Z', but what I use
is actually 'z'. I believe that something must go wrong when GCC addresses the
modifier 'z' followed by [asmSymbolicName].
I have pasted the error reporting of g++ in the code attached.
Above all, thanks a lot for the great compilers.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.3.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)
[Bug target/109457] %z[asmSymbolicName] in AssemblerTemplate fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109457
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Andrew Pinski ---
This has nothing to do with [x] but rather the constraint g and z operand
modifier.
The g constraint is defined as:
Any register, memory or immediate integer operand is allowed, except for
registers that are not general registers.
So constant 1 will be allowed here.
While the modifier z says:
z Print the opcode suffix for the size of the current integer operand
(one of b/w/l/q). %z0 l
Note integer constants don't have a size ...
This is the corrected inline-asm:
template
inline T onec_add(T a, T b)
{
asm("add%z[a]\t%[b], %[a]"
"\n\tadc%z[a]\t$0, %[a]"
: [a]"+g"(a) // inputs
: [b]"g"(b) // outputs
: "cc"// clobbers
);
return a;
}
Note I see you did the replacement of [a] and [b] in your example but when you
replaced %z[b], you replaced it with %z0 rather than what it was originally
which was %z1.
[Bug target/109457] %z[asmSymbolicName] in AssemblerTemplate fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109457
lyazj changed:
What|Removed |Added
Resolution|INVALID |FIXED
CC||seeson at pku dot edu.cn
--- Comment #2 from lyazj ---
](In reply to Andrew Pinski from comment #1)
> This has nothing to do with [x] but rather the constraint g and z operand
> modifier.
>
> The g constraint is defined as:
> Any register, memory or immediate integer operand is allowed, except for
> registers that are not general registers.
>
>
>
> So constant 1 will be allowed here.
>
> While the modifier z says:
> z Print the opcode suffix for the size of the current integer operand (one
> of b/w/l/q). %z0 l
>
> Note integer constants don't have a size ...
>
>
> This is the corrected inline-asm:
> template
> inline T onec_add(T a, T b)
> {
> asm("add%z[a]\t%[b], %[a]"
> "\n\tadc%z[a]\t$0, %[a]"
> : [a]"+g"(a) // inputs
> : [b]"g"(b) // outputs
> : "cc"// clobbers
> );
> return a;
> }
>
>
>
> Note I see you did the replacement of [a] and [b] in your example but when
> you replaced %z[b], you replaced it with %z0 rather than what it was
> originally which was %z1.
Thanks very much for the quick and concise solution. I'm sorry that I missed
the truth that I could have probably put the modifier `z` on an immediate and
did the substitution that broke the equivalence to the original code. However,
since the modifier is case-sensitive, I suggest revising the error reporting
routines to report the improper modifier 'z' instead of 'Z' looked like a bug.
:)
[Bug target/109457] %z[asmSymbolicName] in AssemblerTemplate fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109457 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug target/109457] %z[asmSymbolicName] in AssemblerTemplate fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109457 --- Comment #3 from Andrew Pinski --- (In reply to lyazj from comment #2) > Thanks very much for the quick and concise solution. I'm sorry that I missed > the truth that I could have probably put the modifier `z` on an immediate > and did the substitution that broke the equivalence to the original code. > However, since the modifier is case-sensitive, I suggest revising the error > reporting routines to report the improper modifier 'z' instead of 'Z' looked > like a bug. :) The issue there is the code which implements 'z' is shared with 'Z' and the error message only references 'Z' and missed that it is shared with 'z'. Let me file a bug for that.
[Bug target/109458] New: invalid use 'z' operand modifier in some cases mention the 'Z' operand modifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109458
Bug ID: 109458
Summary: invalid use 'z' operand modifier in some cases mention
the 'Z' operand modifier
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
The problem here is the code in i386 does this:
case 'z':
...
if (GET_MODE_CLASS (GET_MODE (x)) == MODE_FLOAT)
warning (0, "non-integer operand used with operand code %");
/* FALLTHRU */
case 'Z':
...
else
{
output_operand_lossage ("invalid operand type used with "
"operand code 'Z'");
return;
}
output_operand_lossage ("invalid operand size for operand code 'Z'");
So the error messages for 'Z' modifier is shared with 'z' but only references
'Z'.
[Bug target/109457] %z[asmSymbolicName] in AssemblerTemplate fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109457 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > The issue there is the code which implements 'z' is shared with 'Z' and the > error message only references 'Z' and missed that it is shared with 'z'. Let > me file a bug for that. Filed as PR 109458.
[Bug tree-optimization/100958] two_value_replacement should move to match.pd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100958
--- Comment #1 from Andrew Pinski ---
Here is the start of the conversion to match.pd, there must be an easier way to
see the range too:
#if GIMPLE
/* Optimize
x in range [cst1, cst2] where cst2 = cst1 + 1
(x op CSTN) ? CST3 : CST4
# where op is == or != and N is 1 or 2
# where cst3 == cst4 + 1 or cst4 == cst3 + 1
to x + (min (cst3, cst4) - cst1) or
(min (cst3, cst4) + cst1) - x depending on op, N and which
of cst3 and cst4 is smaller. */
(for eqne (eq ne)
(simplify
(cond (eqne @0 INTEGER_CST@1) INTEGER_CST@2 INTEGER_CST@3)
(if (tree_int_cst_lt (@2, @3)
? wi::to_widest (@2) + 1 != wi::to_widest (@3)
: wi::to_widest (@3) + 1 != wi::to_widest (@2))
(with { wide_int min, max;
value_range r;
get_range_query (cfun)->range_of_expr (r, lhs);
if (r.kind () == VR_RANGE)
{
min = r.lower_bound ();
max = r.upper_bound ();
}
else
{
int prec = TYPE_PRECISION (TREE_TYPE (lhs));
signop sgn = TYPE_SIGN (TREE_TYPE (lhs));
min = wi::min_value (prec, sgn);
max = wi::max_value (prec, sgn);
}
}
(if (min + 1 == max
&& (wi::to_wide (@1) == min
|| wi::to_wide (@1) == max))
#endif
[Bug target/109457] %z[asmSymbolicName] in AssemblerTemplate fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109457 lyazj changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #5 from lyazj --- Thanks a lot! Please feel free to tell me if needing any help or have further progress.
[Bug target/109457] %z[asmSymbolicName] in AssemblerTemplate fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109457 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=109458 Status|UNCONFIRMED |RESOLVED --- Comment #6 from Andrew Pinski --- Invalid as explained, the diagnostic issue was filed seperately as PR 109458.
[Bug target/109458] invalid use 'z' operand modifier in some cases mention the 'Z' operand modifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109458 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2023-04-09 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 Lénárd Szolnoki changed: What|Removed |Added CC||leni536 at gmail dot com --- Comment #33 from Lénárd Szolnoki --- (In reply to jos...@codesourcery.com from comment #32) > On Fri, 28 Oct 2022, jakub at gcc dot gnu.org via Gcc-bugs wrote: > > > > That said, if C allows us to limit to 128bits then let's do that for now. > > > 32bit targets will still see all the complication when we give that a > > > stab. > > > > I'm afraid once we define BITINT_MAXWIDTH, it will become part of the ABI, > > so > > we can't increase it afterwards. > > I don't think it's part of the ABI; I think it's always OK to increase > BITINT_MAXWIDTH, as long as the wider types don't need more alignment than > the previous choice of max_align_t. It's not part of the ABI until people put _BitInt(BITINT_MAXWIDTH) on ABI boundaries of their libraries. If a ridiculously large BITINT_MAXWIDTH does nothing more than discourages usages of _BitInt(BITINT_MAXWIDTH) in general, than that's already great. We don't need an other intmax. Also I don't want to think about the max N for _BitInt(N), similarly how I don't want to think about the max N for int[N]. There might be implementation limits, but it should be high enough so I don't have to think about those for everyday coding. > Thus, starting with a 128-bit limit (or indeed a 64-bit limit on 32-bit > platforms, so that all the types fix within existing modes supported for > arithmetic), and adding support for wider _BitInt later, would be a > reasonable thing to do. I disagree. > (You still have ABI considerations even with such a limit: apart from the > padding question, on x86_64 the ABI says _BitInt(128) is 64-bit aligned > but __int128 is 128-bit aligned.) > > > Anyway, I'm afraid we probably don't have enough time to implement this > > properly in stage1, so might need to target GCC 14 with it. Unless somebody > > spends on it > > the remaining 2 weeks full time. > > I think https://gcc.gnu.org/pipermail/gcc/2022-October/239704.html is > still current as a list of C2x language features likely not to make it > into GCC 13. (I hope to get auto and constexpr done in the next two > weeks, and the other C2x language features not on that list are done.)
[Bug c++/109356] Enhancement idea to provide clearer missing brace line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356 --- Comment #8 from Jonny Grant --- (In reply to Xi Ruoyao from comment #7) > (In reply to Jonny Grant from comment #6) > > Tried a few other compilers on godbolt. > > > > ICC gets the warning on line 6 > > https://godbolt.org/z/fYb9c8f61 > > > > nvc++ gives the warning on line 6 > > https://godbolt.org/z/xvh67odzY > > > > MSVC and Clang don't. > > This is just blind luck. All of these compilers attempt to "fix" the syntax > error by adding "}" at line 8 (not line 6!) and produce further warnings. > It's just ICC and nvc++ report "excess elements in initializer" at the > beginning of the initializer, while the other compilers report it at the end. > > Strictly speaking all of them are false warnings as there is no excess > elements in the initializer (according to the programmer's mind). But the > only thing the parser can do is guessing the programmer wanted a "}" at line > 8. ok, thank you for your further replies
[Bug libstdc++/88508] std::bad_cast in std::basic_ostringstream.oss.fill()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88508 --- Comment #6 from Frank Heckenbach --- Yet ironically, char8_t and char16_t are meant to be used with a certain encoding (UTF-8 and UTF-16, respectively) which is locale-independent, whereas char is very much locale-dependent (with even EBCDIC still supported), yet it's the latter that works out of the box without setting a locale.
[Bug tree-optimization/71336] Suboptimal code generated for "(a & 1) ? (CST1 + CST2) : CST1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71336
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2021-07-19 00:00:00 |2023-4-9
--- Comment #9 from Andrew Pinski ---
Take:
```
int test(int a) {
return a & 1 ? 7 : 3;
}
int test1(int a) {
int t = (a & 1) ? 4 : 0;
return t+3;
}
int test2(int a) {
int t = a & 1;
t *= 4;
return t+3;
}
```
these 3 all produce different code on x86_64. test2 produces the best though.
For aarch64, test1/test2 produce the same decent code; the and/shift has been
merged. for riscv, test1/test2 produce the same decent code too, 3 instructions
and no branches.
[Bug tree-optimization/59660] We fail to optimize common boolean checks pre-inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59660 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #14 from Andrew Pinski --- Mine, working on improving phi-opt here.
[Bug tree-optimization/68894] Recognition min/max pattern with multiple arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68894
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #7 from Andrew Pinski ---
Mine, working on improving phi-opt here; though the hoisting of the load is
something which needs to be looked into further.
I have the match.pd pattern for what is mentioned in comment #3:
/* These was part of minmax phiopt. */
/* Optimize (a CMP b) ? minmax : minmax
to minmax, c> */
(for minmax (min max)
(for cmp (lt le gt ge)
(simplify
(cond (cmp @1 @3) (minmax:c @1 @4) (minmax:c @2 @4))
(with
{
tree_code code = minmax_from_comparison (cmp, @1, @2, @1, @3);
}
(if (code == MIN_EXPR)
(minmax (min @1 @2) @4)
(if (code == MAX_EXPR)
(minmax (max @1 @2) @4)))
I also have the improvements to match_simplify_replacement which are needed to
use those patterns too. I will be submitting them for GCC 14.
[Bug tree-optimization/59660] We fail to optimize common boolean checks pre-inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59660 --- Comment #15 from Andrew Pinski --- (In reply to Andrew Pinski from comment #13) > Using the C front-end we still have a casting issue. There are a few issues of even for the C++ front-end IR: In phiopt1 we have: if (n_6(D) == m_7(D)) goto ; [INV] else goto ; [INV] : _1 = n_6(D) + -1; # .MEM_9 = VDEF <.MEM_8(D)> _10 = m_is_less_than_n (_1, m_7(D)); if (_10 != 0) goto ; [INV] else goto ; [INV] : # .MEM_4 = PHI <.MEM_9(3), .MEM_8(D)(2)> : # iftmp.0_3 = PHI <1(4), 0(3)> # .MEM_5 = PHI <.MEM_4(4), .MEM_9(3)> the conditional in "bb 3" could be replaced with tmp = _10. I will have to think of how to handle this in the current code but it is definitely more complex really because you have 2 phi nodes to worry about and such.
[Bug tree-optimization/68894] Recognition min/max pattern with multiple arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68894
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> Mine, working on improving phi-opt here; though the hoisting of the load is
> something which needs to be looked into further.
>
> I have the match.pd pattern for what is mentioned in comment #3:
> /* These was part of minmax phiopt. */
> /* Optimize (a CMP b) ? minmax : minmax
>to minmax, c> */
> (for minmax (min max)
> (for cmp (lt le gt ge)
> (simplify
>(cond (cmp @1 @3) (minmax:c @1 @4) (minmax:c @2 @4))
>(with
> {
> tree_code code = minmax_from_comparison (cmp, @1, @2, @1, @3);
> }
> (if (code == MIN_EXPR)
> (minmax (min @1 @2) @4)
> (if (code == MAX_EXPR)
> (minmax (max @1 @2) @4)))
>
> I also have the improvements to match_simplify_replacement which are needed
> to use those patterns too. I will be submitting them for GCC 14.
Note these patterns are enough for the ifcvt pass for the vectorizer to
generate:
pretmp_24 = a3D.2740[i_20];
_35 = MIN_EXPR <_1, _2>;
d_9 = MIN_EXPR ;
Rather than the current:
d_14 = MIN_EXPR <_1, pretmp_24>;
_23 = _1 < _2;
d_13 = MIN_EXPR <_2, pretmp_24>;
d_9 = _23 ? d_14 : d_13;
[Bug tree-optimization/88540] Issues with vectorization of min/max operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88540 --- Comment #5 from Andrew Pinski --- > Also minmax_replacement in phi-opt could make > use of the FMIN/FMAX IFNs when HONOR_NANS || HONOR_SIGNED_ZEROS > and the direct IFN is available. You should just need to teach match.pd rather than minmax_replacement to do these days. I have patches that start to remove minmax_replacement even.
[Bug c++/109459] New: static_assert with operator""s causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109459
Bug ID: 109459
Summary: static_assert with operator""s causes internal
compiler error
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: stevenxia990430 at gmail dot com
Target Milestone: ---
The following program reports an internal compiler error: Segmentation fault
To quickly reproduce: https://gcc.godbolt.org/z/T6E8Tb7ff
```
#include
#include
int main()
{
using namespace std::literals;
int x = 0;
static_assert(std::is_void_v>, "Cannot process
pair."s);
return 0;
}
```
Removing the operator""s removes the internal compiler error.
[Bug c++/109459] static_assert with operator""s causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109459 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #1 from Jiang An --- Seems fixed recently: https://gcc.godbolt.org/z/zTWoT4rsY
[Bug c/109460] New: Build gcc for win32 failed in gcc13 master branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460 Bug ID: 109460 Summary: Build gcc for win32 failed in gcc13 master branch Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: fanghuaqi at vip dot qq.com Target Milestone: --- Hi there, I tried to build gcc 13 for windows host using mingw gcc in linux. But I am facing the following issue. i686-w64-mingw32-g++ -fno-PIE -c /work/gcc/gcc/config/i386/sym-mingw32.cc sym-mingw32.o i686-w64-mingw32-g++: error: sym-mingw32.o: No such file or directory echo timestamp > s-bversion It seems the sym-mingw32.o is not generated via this command, and I thought it should be like gcc -c hello.c -o hello.o, so I changed gcc/config/i386/x-mingw32-utf8 diff --git a/gcc/config/i386/x-mingw32-utf8 b/gcc/config/i386/x-mingw32-utf8 index 2783dd259a6..b008497ca0b 100644 --- a/gcc/config/i386/x-mingw32-utf8 +++ b/gcc/config/i386/x-mingw32-utf8 @@ -34,7 +34,7 @@ utf8rc-mingw32.o : $(srcdir)/config/i386/utf8-mingw32.rc \ # Create an object file that just exports the global symbol # HOST_EXTRA_OBJS_SYMBOL sym-mingw32.o : $(srcdir)/config/i386/sym-mingw32.cc - $(COMPILER) -c $< $@ + $(COMPILER) -c $< -o $@ This issue disappeared, but other issue like this happened, I didn't have ideas to how to fix it. utf8-mingw32.o: In function `WinMainCRTStartup': ./mingw-w64-crt/crt/crtexe.c:171: multiple definition of `WinMainCRTStartup' /usr/lib/gcc/i686-w64-mingw32/7.3-win32/../../../../i686-w64-mingw32/lib/../lib/crt2.o:./mingw-w64-crt/crt/crtexe.c:171: first defined here utf8-mingw32.o: In function `mainCRTStartup': ./mingw-w64-crt/crt/crtexe.c:199: multiple definition of `mainCRTStartup' /usr/lib/gcc/i686-w64-mingw32/7.3-win32/../../../../i686-w64-mingw32/lib/../lib/crt2.o:./mingw-w64-crt/crt/crtexe.c:199: first defined here /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Could not find abbrev number 101. /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Offset (7496040) greater than or equal to .debug_line size (9993). /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Offset (1684826487) greater than or equal to .debug_line size (9993). /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Offset (1685024119) greater than or equal to .debug_line size (9993). /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Offset (7496040) greater than or equal to .debug_line size (9993). /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Offset (6644847) greater than or equal to .debug_line size (9993). /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Offset (1414356820) greater than or equal to .debug_line size (9993). /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Offset (1230261845) greater than or equal to .debug_line size (9993). /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Offset (1599555406) greater than or equal to .debug_line size (9993). /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Could not find abbrev number 117. /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Offset (1599555406) greater than or equal to .debug_line size (9993). /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Could not find abbrev number 101. /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Offset (1230261845) greater than or equal to .debug_line size (9993). /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Offset (1414356820) greater than or equal to .debug_line size (9993). /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Could not find abbrev number 97. /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Could not find abbrev number 101. /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Offset (6644847) greater than or equal to .debug_line size (9993). /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Could not find abbrev number 110. /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Offset (7496040) greater than or equal to .debug_line size (9993). /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Could not find abbrev number 101. /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Offset (1685024119) greater than or equal to .debug_line size (9993). /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Could not find abbrev number 110. /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Offset (1684826487) greater than or equal to .debug_line size (9993). /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Offset (7496040) greater than or equal to .debug_line size (9993). /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Could not find abbrev number 101. /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Could not find abbrev number 110. utf8-mingw32.o:cygming-crtbegin.c:(.text+0x500): multiple definition of `__gcc_register_frame' /usr/lib/gcc/i686-w64-mingw32/7.3-win32/crtbegin.o:cygming-crtbegin.c:(.text+0x0): first defined here utf8-mingw32.o:cygming-crtbegin.c:(.text+0x520): multiple definition of `__gcc_deregister_frame' /usr/lib/gcc/i686-w64-mingw32/7.3-win32/crtbegin.o:cygming-crtbegin.c:(.text+0x20): first defined here /usr/bin/i686-w64-mingw32-ld: Dwarf Error: Offset (15
[Bug c/109461] New: build gcc for riscv target failed with `execvp: /bin/sh: Argument list too long error when using with --with-multilib-generator`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109461 Bug ID: 109461 Summary: build gcc for riscv target failed with `execvp: /bin/sh: Argument list too long error when using with --with-multilib-generator` Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: fanghuaqi at vip dot qq.com Target Milestone: --- Hi there, I am using gcc master branch source code(gcc 13), and tried to use this repo https://github.com/riscv-collab/riscv-gnu-toolchain to cross build toolchain for riscv target with multilib enabled, the multilib configuration is as below --with-multilib-generator="rv32emc-ilp32e--;rv32emac-ilp32e--;rv32imc-ilp32--;rv32imac-ilp32--zfh*zfhmin*zve32x;rv32imafc-ilp32f--zfh*zfhmin*zve32f;rv32imafdc-ilp32d--zfh*zfhmin*zve32f;rv32imac_zba_zbb_zbc_zbs-ilp32--zfh*zfhmin*zbkb_zbkc_zbkx_zk*zve32x;rv32imafc_zba_zbb_zbc_zbs-ilp32f--zfh*zfhmin*zbkb_zbkc_zbkx_zk*zve32f;rv32imafdc_zba_zbb_zbc_zbs-ilp32d--zfh*zfhmin*zbkb_zbkc_zbkx_zk*zve32f;rv32ima_zca_zcb_zcmp_zcmt-ilp32--zfh*zfhmin*zve32x;rv32imaf_zca_zcb_zcf_zcmp_zcmt-ilp32f--zfh*zfhmin*zve32f;rv32imafd_zca_zcb_zcf_zcd-ilp32d--zfh*zfhmin*zve32f;rv32ima_zca_zcb_zcmp_zcmt_zba_zbb_zbc_zbs-ilp32--zfh*zfhmin*zbkb_zbkc_zbkx_zk*zve32x;rv32imaf_zca_zcb_zcf_zcmp_zcmt_zba_zbb_zbc_zbs-ilp32f--zfh*zfhmin*zbkb_zbkc_zbkx_zk*zve32f;rv32imafd_zca_zcb_zcf_zcd_zba_zbb_zbc_zbs-ilp32d--zfh*zfhmin*zbkb_zbkc_zbkx_zk*zve32f;rv32imac_xxldsp-ilp32--xxldspn1*xxldspn2*xxldspn3*zfh*zfhmin*zve32x;rv32imafc_xxldsp-ilp32f--xxldspn1*xxldspn2*xxldspn3*zfh*zfhmin*zve32f;rv32imafdc_xxldsp-ilp32d--xxldspn1*xxldspn2*xxldspn3*zfh*zfhmin*zve32f;rv32imaczba_zbb_zbc_zbs_xxldsp-ilp32--xxldspn1*xxldspn2*xxldspn3*zfh*zfhmin*zbkb_zbkc_zbkx_zk*zve32x;rv32imafc_zba_zbb_zbc_zbs_xxldsp-ilp32f--xxldspn1*xxldspn2*xxldspn3*zfh*zfhmin*zbkb_zbkc_zbkx_zk*zve32f;rv32imafdc_zba_zbb_zbc_zbs_xxldsp-ilp32d--xxldspn1*xxldspn2*xxldspn3*zfh*zfhmin*zbkb_zbkc_zbkx_zk*zve32f;rv32ima_zca_zcb_zcmp_zcmt_xxldsp-ilp32--xxldspn1*xxldspn2*xxldspn3*zfh*zfhmin*zve32x;rv32imaf_zca_zcb_zcf_zcmp_zcmt_xxldsp-ilp32f--xxldspn1*xxldspn2*xxldspn3*zfh*zfhmin*zve32f;rv32imafd_zca_zcb_zcf_zcd_xxldsp-ilp32d--xxldspn1*xxldspn2*xxldspn3*zfh*zfhmin*zve32f;rv32ima_zca_zcb_zcmp_zcmt_zba_zbb_zbc_zbs_xxldsp-ilp32--xxldspn1*xxldspn2*xxldspn3*zfh*zfhmin*zbkb_zbkc_zbkx_zk*zve32x;rv32imaf_zca_zcb_zcf_zcmp_zcmt_zba_zbb_zbc_zbs_xxldsp-ilp32f--xxldspn1*xxldspn2*xxldspn3*zfh*zfhmin*zbkb_zbkc_zbkx_zk*zve32f;rv32imafd_zca_zcb_zcf_zcd_zba_zbb_zbc_zbs_xxldsp-ilp32d--xxldspn1*xxldspn2*xxldspn3*zfh*zfhmin*zbkb_zbkc_zbkx_zk*zve32f;rv64imac-lp64--xxldsp*xxldspn1*zfhmin*zfh*v;rv64imafc-lp64f--xxldsp*xxldspn1*zfhmin*zfh*v;rv64imafdc-lp64d--xxldsp*xxldspn1*zfhmin*zfh*v;rv64imac_zba_zbb_zbc_zbs-lp64--xxldsp*xxldspn1*zfhmin*zfh*zbkb_zbkc_zbkx_zk*v;rv64imafc_zba_zbb_zbc_zbs-lp64f--xxldsp*xxldspn1*zfhmin*zfh*zbkb_zbkc_zbkx_zk*v;rv64imafdc_zba_zbb_zbc_zbs-lp64d--xxldsp*xxldspn1*zfhmin*zfh*zbkb_zbkc_zbkx_zk*v;rv64ima_zca_zcb_zcmp_zcmt-lp64--xxldsp*xxldspn1*zfhmin*zfh*v;rv64imaf_zca_zcb_zcf_zcmp_zcmt-lp64f--xxldsp*xxldspn1*zfhmin*zfh*v;rv64imafd_zca_zcb_zcf_zcd-lp64d--xxldsp*xxldspn1*zfhmin*zfh*v;rv64ima_zca_zcb_zcmp_zcmt_zba_zbb_zbc_zbs-lp64--xxldsp*xxldspn1*zfhmin*zfh*zbkb_zbkc_zbkx_zk*v;rv64imaf_zca_zcb_zcf_zcmp_zcmt_zba_zbb_zbc_zbs-lp64f--xxldsp*xxldspn1*zfhmin*zfh*zbkb_zbkc_zbkx_zk*v;rv64imafd_zca_zcb_zcf_zcd_zba_zbb_zbc_zbs-lp64d--xxldsp*xxldspn1*zfhmin*zfh*zbkb_zbkc_zbkx_zk*v" But when I build the toolchain, it will fail with the following messsage if test yes = yes \ || test -n ""; then \ /bin/sh /work/gcc/gcc/genmultilib \ .. too long to show, ignore it . _zbs_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b_xxldsp/mabi.lp64d march.rv64imafd_zca_zcb_zcd_zcf_zba_zbb_zbc_zbs/mabi.lp64d=march.rv64imafdv_zfhmin_zca_zcb_zcd_zcf_zba_zbb_zbc_zbs_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b_xxldsp_xxldspn1/mabi.lp64d march.rv64imafd_zca_zcb_zcd_zcf_zba_zbb_zbc_zbs/mabi.lp64d=march.rv64imafdv_zfhmin_zca_zcb_zcd_zcf_zba_zbb_zbc_zbs_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b_xxldspn1/mabi.lp64d" \ "yes" \ > tmp-mlib.h; \ else \ /bin/sh /work/gcc/gcc/genmultilib '' '' '' '' '' '' '' '' \ "" '' no \ > tmp-mlib.h; \ fi make[2]: execvp: /bin/sh: Argument list too long make[2]: *** [Makefile:2252: s-mlib] Error 127 For more details, you can check in https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1226, and others can repeat this issue. Thanks for any help you could provide.
[Bug bootstrap/109461] build gcc for riscv target failed with `execvp: /bin/sh: Argument list too long error when using with --with-multilib-generator`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109461 Andrew Pinski changed: What|Removed |Added Component|c |bootstrap Build||Mingw Host||Mingw --- Comment #1 from Andrew Pinski --- Oh yea windows command limits are much smaller than any other target
[Bug bootstrap/109461] build gcc for riscv target failed with `execvp: /bin/sh: Argument list too long error when using with --with-multilib-generator`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109461 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org --- Comment #2 from Kito Cheng --- https://github.com/gcc-mirror/gcc/commit/5ca9980fc86242505ffdaaf62bca1fd5db26550b https://github.com/gcc-mirror/gcc/commit/d72ca12b846a9f5c01674b280b1817876c77888f New multi-lib selection scheme should improve this, so that you don't need to specify so loong multi-lib config. I guess I should write more doc and adding release note to mention that.
[Bug target/70243] PowerPC V4SFmode should not use Altivec instructions on VSX systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243 --- Comment #7 from CVS Commits --- The master branch has been updated by Michael Meissner : https://gcc.gnu.org/g:725bcdeec60771cb9ee387978716028b64ea1b7f commit r13-7132-g725bcdeec60771cb9ee387978716028b64ea1b7f Author: Michael Meissner Date: Sun Apr 9 23:32:27 2023 -0400 Do not generate vmaddfp and vnmsubfp This is version 3 of the patch. This is essentially version 1 with the removal of changes to altivec.md, and cleanup of the comments. Version 2 generated the vmaddfp and vnmsubfp instructions if -Ofast was used, and those changes are deleted in this patch. The Altivec instructions vmaddfp and vnmsubfp have different rounding behaviors than the VSX xvmaddsp and xvnmsubsp instructions due to VSCR[NJ] and other corner cases. In particular, generating these instructions seems to break Eigen on big endian systems. 2023-04-09 Michael Meissner gcc/ PR target/70243 * config/rs6000/vsx.md (vsx_fmav4sf4): Do not generate vmaddfp. (vsx_nfmsv4sf4): Do not generate vnmsubfp. gcc/testsuite/ PR target/70243 * gcc.target/powerpc/pr70243.c: New test.
[Bug bootstrap/109461] build gcc for riscv target failed with `execvp: /bin/sh: Argument list too long error when using with --with-multilib-generator`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109461 --- Comment #3 from Huaqi --- Thanks Kito, maybe you can add more examples in this script https://github.com/gcc-mirror/gcc/blob/master/gcc/config/riscv/multilib-generator and in this doc https://github.com/riscv-collab/riscv-gnu-toolchain#build-with-customized-multi-lib-configure. Thank you very much.
[Bug tree-optimization/56223] Integer ABS is not recognized for more complicated pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56223 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290 Andrew Pinski changed: What|Removed |Added Attachment #54813|0 |1 is obsolete|| --- Comment #28 from Andrew Pinski --- Created attachment 54821 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54821&action=edit New set of patches including some other improvements This new set includes moving some of cond_removal_in_builtin_zero_pattern (though not removing it as match-and-simplify phiopt needs to be improved to support 2 defining statements for each bb). It also includes fixing the issue dealing with predicate statements which was missed before. Also reduces the number of patches for the c++ifing by combining some patches together. Note the first patch in the series is an obvious patch which I am going to apply once GCC 13 branches; it removes a prototype which is not needed as gate_hoist_loads is defined before its use.
