Re: [PATCH] Predefine __STRICT_ALIGN__ if STRICT_ALIGNMENT

YunQiang Su writes: > Arm32 predefines __ARM_FEATURE_UNALIGNED if -mno-unaligned-access, > and RISC-V predefines __riscv_misaligned_avoid, while other ports > that support -mstrict-align/-mno-unaligned-access don't have such > macro, and these backend macros are only avaiable for c-family. > Note

[PATCH] Predefine __STRICT_ALIGN__ if STRICT_ALIGNMENT

Arm32 predefines __ARM_FEATURE_UNALIGNED if -mno-unaligned-access, and RISC-V predefines __riscv_misaligned_avoid, while other ports that support -mstrict-align/-mno-unaligned-access don't have such macro, and these backend macros are only avaiable for c-family. Note: Arm64 always predefine __ARM_F

Re: [PATCH] c-c++-common/Wrestrict.c: fix some typos and enable for LLP64

On Sat, Mar 2, 2024, 08:24 Jonathan Yong <10wa...@gmail.com> wrote: > On 2/15/24 14:08, Jonathan Yong wrote: > > Attached patch OK? > > > > Copy/pasted for review convenience. > Ping. > Pinging this for Jon. It's been a couple months, and this should be mostly obvious if someone has a spare minut

[pushed] Darwin: Fix bootstrap break on X86.

Tested on x86_64-darwin21, pushed to the branch, thanks Iain --- 8< --- The changes in r12-9536-gefcca6481eab18 mangled the whitespace in the ENDFILE_SPEC i386/darwin.h leading to a bootstrap fail. gcc/ChangeLog: * config/i386/darwin.h (ENDFILE_SPEC): Fix whitespace. Signed-off-by: Iai

[PATCH] LoongArch: gcc13: Implement option save/restore.

LTO option streaming and target attributes both require per-function target configuration, which is achieved via option save/restore. We implement TARGET_OPTION_{SAVE,RESTORE} to switch the la_target context in addition to other automatically maintained option states (via the "Save" option propert

[PATCH] LoongArch: gcc12: Implement option save/restore.

LTO option streaming and target attributes both require per-function target configuration, which is achieved via option save/restore. We implement TARGET_OPTION_{SAVE,RESTORE} to switch the la_target context in addition to other automatically maintained option states (via the "Save" option propert

Re: [gcc-15 1/3] RISC-V: avoid LUI based const materialization ... [part of PR/106265]

On 3/16/24 11:35 AM, Vineet Gupta wrote: ... if the constant can be represented as sum of two S12 values. The two S12 values could instead be fused with subsequent ADD insn. The helps - avoid an additional LUI insn - side benefits of not clobbering a reg e.g.

Re: [gcc-15 3/3] RISC-V: avoid LUI based const mat in prologue/epilogue expansion [PR/105733]

On 3/16/24 11:35 AM, Vineet Gupta wrote: If the constant used for stack offset can be expressed as sum of two S12 values, the constant need not be materialized (in a reg) and instead the two S12 bits can be added to instructions involved with frame pointer. This avoids burning a register and m

Re: [gcc-15 2/3] RISC-V: avoid LUI based const mat: keep stack offsets aligned

On 3/16/24 11:35 AM, Vineet Gupta wrote: Noticed that new sum of two s12 splitter was generating following: | 059930 : | 59930: add sp,sp,-16 | 59934: lui t0,0xf | 59938: sd s0,0(sp) | 5993c: sd ra,8(sp) | 59940: add sp,sp,t0 | 59

[gcc-15 1/3] RISC-V: avoid LUI based const materialization ... [part of PR/106265]

... if the constant can be represented as sum of two S12 values. The two S12 values could instead be fused with subsequent ADD insn. The helps - avoid an additional LUI insn - side benefits of not clobbering a reg e.g. w/o patch w/ patch long

[gcc-15 3/3] RISC-V: avoid LUI based const mat in prologue/epilogue expansion [PR/105733]

If the constant used for stack offset can be expressed as sum of two S12 values, the constant need not be materialized (in a reg) and instead the two S12 bits can be added to instructions involved with frame pointer. This avoids burning a register and more importantly can often get down to be 2 ins

[gcc-15 2/3] RISC-V: avoid LUI based const mat: keep stack offsets aligned

Noticed that new sum of two s12 splitter was generating following: | 059930 : | 59930: add sp,sp,-16 | 59934: lui t0,0xf | 59938: sd s0,0(sp) | 5993c: sd ra,8(sp) | 59940: add sp,sp,t0 | 59944: add s0,sp,2047 < | 59948:

[gcc-15 0/3] RISC-V improve stack/array access by constant mat tweak

Hi, This set of patches (for gcc-15) help improve stack/array accesses by improving constant materialization. Details are in respective patches. The first patch is the main change which improves SPEC cactu by 10%. There is at least one more pending change with same theme (riscv_add_offset/riscv_

New French PO file for 'gcc' (version 14.1-b20240218)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the French team of translators. The file is available at: https://translationproject.org/latest/gcc/fr.po (This file, 'gcc-14.1-b20240218.fr.po',

Re: [PATCH] i386: Fix setup of incoming varargs for (...) functions which return large aggregates [PR114175]

> Am 16.03.2024 um 08:24 schrieb Jakub Jelinek : > > Hi! > > The c23-stdarg-6.c testcase I've added recently apparently works fine with > -O0 but aborts with -O1 and higher on x86_64-linux. > The problem is in setup of incoming varargs. > > Like function.cc before r14-9249 even ix86_setup_in

Re: [PATCH] bitint: Fix up stores to large/huge _BitInt bitfields [PR114329]

> Am 16.03.2024 um 08:11 schrieb Jakub Jelinek : > > Hi! > > The verifier requires BIT_FIELD_REFs with INTEGRAL_TYPE_P first operand > to have mode precision. In most cases for the large/huge _BitInt bitfield > stores the code uses bitfield representatives, which are typically arrays > of ch

Re: _LIBCXX_DEBUG value initialized singular iterators assert failures in std algorithms [PR104316]

With the patch, sorry. On 14/03/2024 22:49, François Dumont wrote: Hi This is what I started to do. For now I haven't touch to __cpp_lib_null_iterators definition as _Safe_local_iterator still need some work. libstdc++: Implement N3644 on _Safe_iterator<> [PR114316] Consider range of value

[PATCH v3] c++: Fix handling of no-linkage decls for modules

On Mon, Mar 11, 2024 at 02:13:34PM -0400, Jason Merrill wrote: > On 3/8/24 18:18, Nathaniel Shead wrote: > > On Fri, Mar 08, 2024 at 10:19:52AM -0500, Jason Merrill wrote: > > > On 3/7/24 21:55, Nathaniel Shead wrote: > > > > On Mon, Nov 27, 2023 at 03:59:39PM +1100, Nathaniel Shead wrote: > > > >

[PATCH v4 2/2] extend.texi: Add documentation for all missing built-in traits [PR87343]

Fixed some wording and consistency issues in the documentation. -- >8 -- PR c++/87343 gcc/ChangeLog: * doc/extend.texi (Expression-yielding Type Traits): New subsection. (Type-yielding Type Traits): Likewise. (C++ Concepts): Move __is_same to ...

[PING] Re: [PATCH] testsuite: Define _POSIX_C_SOURCE for test

Ping! Kind regards, Torbjörn On 2024-03-10 18:26, Torbjörn SVENSSON wrote: Ok for trunk? -- As the tests assume that strndup() is visible (only part of POSIX.1-2008) define the guard to ensure that it's visible. Currently, glibc appears to always have this defined in C++, newlib does not. W

Re: [PATCH] Fix libcc1plugin and libc1plugin to avoid poisoned identifiers

Given its fixes build, is obvious, and tested appropriately: patch pushed as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5213047b1d50af63dfabb5e5649821a6cb157e33 FX

[PATCH] i386: Fix setup of incoming varargs for (...) functions which return large aggregates [PR114175]

Hi! The c23-stdarg-6.c testcase I've added recently apparently works fine with -O0 but aborts with -O1 and higher on x86_64-linux. The problem is in setup of incoming varargs. Like function.cc before r14-9249 even ix86_setup_incoming_varargs assumes that TYPE_NO_NAMED_ARGS_STDARG_P don't have any

[PATCH] bitint: Fix up stores to large/huge _BitInt bitfields [PR114329]

Hi! The verifier requires BIT_FIELD_REFs with INTEGRAL_TYPE_P first operand to have mode precision. In most cases for the large/huge _BitInt bitfield stores the code uses bitfield representatives, which are typically arrays of chars, but if the bitfield starts at byte boundary on big endian, the