> On 14 Dec 2024, at 09:32, Richard Biener wrote:
>
> External email: Use caution opening links or attachments
>
>
>> Am 13.12.2024 um 18:00 schrieb Jennifer Schmitz :
>>
>>
>>
>>> On 13 Dec 2024, at 13:40, Richard Biener wrote:
>>>
>>> External email: Use caution opening links or attac
On 14.12.24 15:38, Matthias Klose wrote:
I tried to use the patches to build binary packages for Debian. Found
some issues:
tried to build libgcobol on more architectures, please find the attached
patch to disable building libgcobol on some architectures.
how should patches and build failure
PING!
On Fri, 6 Dec 2024 19:10:08 +0100
Andre Vehreschild wrote:
> Hi all,
>
> I had to dive deeply into the issue with handling allocatable components in
> derived types and to find a future proof solution. I hope do have found a
> universal and flexible one now:
>
> For each allocatable (or po
On 12/14/24 3:29 AM, Jakub Jelinek wrote:
Hi!
In r10-6457 aka PR92593 fix a check has been added to reject
earlier non-static data members with current_class_type in templates,
as the deduction then can result in endless recursion in reshape_init.
It fixed the
template
struct S { S s = 1; };
S
There should be no svvptc in the riscv-ext-bitmask.def file since it has
not yet been added to the RISC-V C API Specification or the Linux
hwprobe. And there is no need for userspace software to know that this
extension exists. So remove it from the riscv-ext-bitmask.def file.
Fixes: e4f4b2dc08 ("
On Sat, 14 Dec 2024 at 14:59, Jonathan Wakely wrote:
>
>
>
> On Mon, 9 Dec 2024, 06:05 François Dumont, wrote:
>>
>>
>> On 04/12/2024 22:48, Jonathan Wakely wrote:
>> > On 04/12/24 19:27 +0100, François Dumont wrote:
>> >> Hi
>> >>
>> >> I've completed the synchronization with your equivalent PR
Handle embedded links in plain text messages. For now, merely
use the link text and discard the destination.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-6286-g7f4f49687b1f1b.
gcc/ChangeLog:
* libsarifreplay.cc (struct embedded_link): New.
Hi Tobias,
See the revised patch attached and my comments below.
On 15/11/2024 14:59, Tobias Burnus wrote:
Hi,
Paul-Antoine Arras wrote:
This patch adds support for the `dispatch` construct and the
`adjust_args` clause to the Fortran front-end.
Handling of `adjust_args` across translation un
On 12/16/24 7:15 AM, Mariam Arutunian wrote:
On Mon, Dec 16, 2024 at 5:20 PM Xi Ruoyao wrote:
A generic CRC optimization pass has been implemented in r15-5850. But
without target-specific code, it'll only optimize the CRC loop to a
table lookup. With LoongArch-specific code w
Move explicit Himode handling for SSE2 XMM regnos from
ix86_hard_regno_mode_ok to VALID_SSE2_REG_MODE.
No functional change.
gcc/ChangeLog:
* config/i386/i386.cc (ix86_hard_regno_mode_ok):
Remove explicit HImode handling for SSE2 XMM regnos.
* config/i386/i386.h (VALID_SSE2_REG_MODE)
On Mon, Dec 09, 2024 at 11:24:39AM +0100, Mark Wielaard wrote:
> On Mon, 2024-12-02 at 11:16 +0100, Mark Wielaard wrote:
> > Adjust the DCO text to match the broader community usage and
> > clarifications around the use of real names, known identities and
> > (anonymous) pseudonyms.
> >
> > These
Hi PA,
Paul-Antoine Arras wrote:
See the revised patch attached and my comments below.
First, for Fortran patches, please also CC fortran@ besides gcc-patches@.
The original patch email can be found at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671763.html
I have not looked in
On Thu, 12 Dec 2024, James K. Lowden wrote:
> A word about C style, always a lively topic. For any files already
> present in gcc, the existing style was followed, and any variation from
> it is unintentional. Files related to the parser use K&R style. The
> GENERIC interface and runtime librar
On Thu, 12 Dec 2024, James K. Lowden wrote:
> diff --git a/configure b/configure
> index 51bf1d1add1..2a8f0cadc0e 100755
> --- a/configure
> +++ b/configure
> @@ -775,6 +775,7 @@ infodir
> docdir
> oldincludedir
> includedir
> +runstatedir
> localstatedir
> sharedstatedir
> sysconfdir
Pleas
The parser appears to contain calls to diagnostic functions, so seems a
good point to comment on conventions for diagnostics in GCC:
* Please send all diagnostics (except maybe internal ones that indicate a
bug in the compiler) through the language-independent diagnostic
machinery. It appears
On Thu, 12 Dec 2024, James K. Lowden wrote:
> +static char name[PATH_MAX];
Static buffers with a PATH_MAX size will probably break the build on Hurd
host.
> +__int128 get_power_of_ten(int n);
GCC supports 32-bit hosts; you shouldn't rely on __int128 being available
on the host.
> +exter
On Mon, Dec 16, 2024 at 5:20 PM Xi Ruoyao wrote:
> A generic CRC optimization pass has been implemented in r15-5850. But
> without target-specific code, it'll only optimize the CRC loop to a
> table lookup. With LoongArch-specific code we can do it better: for
> 64-bit LoongArch and the IEEE 80
The patch optimizes code generation for comparisons of the form
X & C1 == C2 by converting them to (X | ~C1) == (C2 | ~C1).
C1 is a constant that requires li and addi to be loaded,
while ~C1 requires a single lui instruction.
As the values of C1 and C2 are not visible within
the equality expression
QHSD and QHWD are basically the same thing, but QHSD will be incorrect
when we start to add LA32 support. So it's just better to always use
QHWD.
gcc/ChangeLog:
* config/loongarch/loongarch.md (QHSD): Remove.
(loongarch__w__w): Use QHSD instead of QHWD.
(loongarch__w__w_e
gcc/testsuite/ChangeLog:
* g++.target/loongarch/crc.C: New test.
* g++.target/loongarch/crc-scan.C: New test.
---
gcc/testsuite/g++.target/loongarch/crc-scan.C | 13 ++
gcc/testsuite/g++.target/loongarch/crc.C | 113 ++
2 files changed, 126 insertions(+)
cre
> How about going for a slight variation of your original patch. After:
>
> nvectors *= 2;
>
> add:
>
> /* We need to be able to to fuse COUNT / NVECTORS elements together. */
> if (!multple_p (count, nvectors))
> return false;
>
> OK like that if it works.
Thank you, i
On Mon, 2024-12-16 at 11:26 +, Wilken Gottwalt wrote:
> Add Winbond W25Q01JV 128 MiB SPI NOR flash chip, verified working on
> the
> Zynq-7000 platform QSPI controller. The flash chip has quite high
> read
> speeds (about 60+ MiB/s), but erasing is very slow. The slow erasing
> is
> by design.
This patch support zilsd and zclsd[1] extensions.
To enable GCC to recognize and process zilsd and zclsd extension correctly at
compile time.
[1] https://github.com/riscv/riscv-zilsd
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::check_conflict_ext): New exten
On Tue, Dec 10, 2024 at 08:42:50PM +, Dimitri John Ledkov wrote:
> On Thu, 28 Nov 2024 at 15:12, Marek Polacek wrote:
> >
> > On Thu, Nov 28, 2024 at 11:27:32AM +, Dimitri John Ledkov wrote:
> > > Did bootstrap with gcc-14 (clean cherrypick, minor offsets).
> > > Built and tested on arm64
Hi,
I've reg-tested this patch on both the trunk and the releases/gcc-14
branches for x86_64-linux-gnu and arm-none-eabi and it no longer fails
for any of the out-of-bounds-diagram* tests on any of the 2 platforms.
I'm a bit puzzled if the C++ part is enough, but I can't think of a way
to trigger
Hi Wilken,
On Mon, Dec 16 2024, Wilken Gottwalt wrote:
> Add Winbond W25Q01JV 128 MiB SPI NOR flash chip, verified working on the
> Zynq-7000 platform QSPI controller. The flash chip has quite high read
> speeds (about 60+ MiB/s), but erasing is very slow. The slow erasing is
> by design.
Does t
This is a big deal, Andre! Thanks for working on this patch. I have some
test code that I can dig up if that’s helpful. Have you tested with nested
derived type components, i.e., allocatable components that are themselves
derived types that have allocatable components?
The need for this featur
A generic CRC optimization pass has been implemented in r15-5850. But
without target-specific code, it'll only optimize the CRC loop to a
table lookup. With LoongArch-specific code we can do it better: for
64-bit LoongArch and the IEEE 802.3 polynomial or the Castagnoli
polynomial, we can directl
For a textbook-style CRC implementation:
uint32_t crc = 0xu;
for (size_t k = 0; k < len; k++)
{
crc ^= data[k];
for (int i = 0; i < 8 * sizeof (T); i++)
if (crc & 1)
crc = (crc >> 1) ^ poly;
else
crc >>= 1;
}
64-bit LoongArch has native CRC instructions for two specific
polynomials. For other polynomials or 32-bit, use the generic
table-based approach but optimize bit reversing.
gcc/ChangeLog:
* config/loongarch/loongarch.md (crc_revsi4): New
define_expand.
---
gcc/config/loongarch/l
LoongArch supports native bit reverse operation for QI, SI, DI, and for
HI we can expand it into a shift and a bit reverse in word_mode.
I was reluctant to add them because until PR50481 is fixed these
operations will be just useless. But now it turns out we can use them
to optimize the bit rever
I've pushed this patch series now, and I hope I'm done with
refactoring _Hashtable.
I see about a 2% reduction in memory and in compilation time for an
explicit instantiation of std::unordered_list when
comparing r15-5031-gdd08cdccc36d08 to current trunk. It's not huge,
but it's something, and I f
Hi Harald,
thanks for finding the bug so quickly. I took another look and came up with the
attached trivially looking patch, which replaces the old version 1 entirely.
The new v2 version of the patch just makes use of existing code guessing the
type of the associate variable, which once I found i
On Mon, 16 Dec 2024 at 14:26, Jonathan Wakely wrote:
>
> I've pushed this patch series now, and I hope I'm done with
> refactoring _Hashtable.
>
> I see about a 2% reduction in memory and in compilation time for an
> explicit instantiation of std::unordered_list when
For a translation unit that d
Memmove destination overflows if size of int is less than 3, resulting in
spurious test failures. Fix by adding a requirement for effective
target int32plus.
This fixes a new FAIL for AVR backend. Pushed to trunk as obvious.
gcc/testsuite/ChangeLog:
* gcc.dg/pr117816.c: Require effecti
On Mon, Dec 16, 2024 at 10:58 PM Dongyan Chen
wrote:
>
> This patch support zilsd and zclsd[1] extensions.
> To enable GCC to recognize and process zilsd and zclsd extension correctly at
> compile time.
>
> [1] https://github.com/riscv/riscv-zilsd
>
> gcc/ChangeLog:
>
> * common/config/ri
On Fri, 13 Dec 2024 at 13:45, Jonathan Wakely wrote:
>
> This adds so that other headers don't need to include
> all of , which pulls in all of since C++23 (for the
> std::print and std::println overloads in ). This new header
> allows the constrained operator<< in to be defined
> without all o
This rather contained OpenMP patch does:
* 'interop' clause - some fixes (-Wunused),
* ICE fix related to omp_interop_t type check.
* Handle 'append_args' in C/C++ (depends on recently added
'dispatch' and utilizes the existing 'init' clause parser
of 'omp interop').
* Update gimplify for
> On Dec 16, 2024, at 23:42, Kito Cheng wrote:
>
> On Mon, Dec 16, 2024 at 10:58 PM Dongyan Chen
> wrote:
>>
>> This patch support zilsd and zclsd[1] extensions.
>> To enable GCC to recognize and process zilsd and zclsd extension correctly
>> at compile time.
>>
>> [1] https://github.com/r
On 06/12/2024 16:09, Christophe Lyon wrote:
> Like dlstp-compile-asm-1.c, this test would fail if GCC is configured
> with non-default options, such as -mtune=cortex-a9.
>
> Force -mtune=cortex-m55 to avoid this unexpected issue.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/mve/dlstp-
On 13/12/2024 14:29, Christophe Lyon wrote:
> On Tue, 10 Dec 2024 at 13:14, Richard Earnshaw (lists)
> wrote:
>>
>> On 09/12/2024 21:11, Christophe Lyon wrote:
>>> In this PR, we have to handle a case where MVE predicates are supplied
>>> as a const_int, where individual predicates have illegal bo
Hi Kees,
On Sun, Dec 15, 2024 at 08:02:57PM -0800, Kees Cook wrote:
> When initializing a nonstring char array when compiled with
> -Wunterminated-string-initialization the warning trips even when
> truncating the trailing NUL character from the string constant. Only
> warn about this when running
Add Winbond W25Q01JV 128 MiB SPI NOR flash chip, verified working on the
Zynq-7000 platform QSPI controller. The flash chip has quite high read
speeds (about 60+ MiB/s), but erasing is very slow. The slow erasing is
by design.
Signed-off-by: Wilken Gottwalt
---
drivers/mtd/spi-nor/winbond.c | 6
On Mon, Dec 16, 2024 at 01:16:37PM +0100, Torbjörn SVENSSON wrote:
> Hi,
>
> I've reg-tested this patch on both the trunk and the releases/gcc-14
> branches for x86_64-linux-gnu and arm-none-eabi and it no longer fails
> for any of the out-of-bounds-diagram* tests on any of the 2 platforms.
>
> I
On Mon, 16 Dec 2024 08:22:45 -0500
David Malcolm wrote:
> On Mon, 2024-12-16 at 11:26 +, Wilken Gottwalt wrote:
> > Add Winbond W25Q01JV 128 MiB SPI NOR flash chip, verified working on
> > the
> > Zynq-7000 platform QSPI controller. The flash chip has quite high
> > read
> > speeds (about 60+
在 2024/12/15 23:50, Jeff Law 写道:
On 12/3/24 4:02 AM, Jiawei wrote:
This patch introduces support for RISC-V Profiles RV20 and RV22 [1],
enabling developers to utilize these profiles through the -march option.
[1] https://github.com/riscv/riscv-profiles/releases/tag/v1.0
gcc/ChangeLog:
On 12/16/24 7:16 AM, Torbjörn SVENSSON wrote:
Hi,
I've reg-tested this patch on both the trunk and the releases/gcc-14
branches for x86_64-linux-gnu and arm-none-eabi and it no longer fails
for any of the out-of-bounds-diagram* tests on any of the 2 platforms.
I'm a bit puzzled if the C++ part
On Mon, 16 Dec 2024 08:37:13 PST (-0800), c...@cyyself.name wrote:
There should be no svvptc in the riscv-ext-bitmask.def file since it has
not yet been added to the RISC-V C API Specification or the Linux
hwprobe. And there is no need for userspace software to know that this
extension exists. So
Committed.
An alternative would have been to restrict the
scan-tree-dump-times lines in the tests to a list of known
targets, but that's more of a testsuite maintainer-level
change (not actually a valid excuse).
CC to m68k maintainers, who might want to check that 300
fits and add m68k to the lis
Hi Andre,
Am 16.12.24 um 15:26 schrieb Andre Vehreschild:
Hi Harald,
thanks for finding the bug so quickly. I took another look and came up with the
attached trivially looking patch, which replaces the old version 1 entirely.
The new v2 version of the patch just makes use of existing code gues
libgdiagnostics was written before the fixes for PR other/116613 allowed
a diagnostic_context to have multiple output sinks.
Hence each libgdiagnostics sink had its own diagnostic_context with just
one diagnostic_output_format.
This wart is no longer necessary and makes it harder to move state
in
This is purely for use when debugging.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-6282-ge55cfebd0016e4.
gcc/ChangeLog:
* diagnostic.cc (diagnostic_context::dump): Dump m_file_cache.
* input.cc (file_cache_slot::dump): New decls and implem
The diagnostic source-quoting machinery uses class file_cache
implemented in gcc/input.cc for (re)reading the source when
issuing diagnostics.
When sarif-replay issues a saved diagnostic it might be running
in a different path to where the .sarif file was captured, or
on an entirely different mach
This patch updates diagnostic_manager_new_logical_location so
that repeated calls with the same input values yield the same
instance of diagnostic_logical_location.
Doing so allows the path-printing logic to properly consolidate runs of
events, whereas previously it could treat each event as havin
On Tue, 2024-12-17 at 11:27 +0800, Lulu Cheng wrote:
> 在 2024/12/16 下午9:20, Xi Ruoyao 写道:
> /* snip */
> > +;; For HImode it's a little complicated...
> > +(define_expand "rbithi"
> I didn't find rtithi's template description. Are there any test cases
> ?
No, it's not a standard name. I just used
在 2024/12/17 下午12:30, Xi Ruoyao 写道:
On Tue, 2024-12-17 at 11:27 +0800, Lulu Cheng wrote:
在 2024/12/16 下午9:20, Xi Ruoyao 写道:
/* snip */
+;; For HImode it's a little complicated...
+(define_expand "rbithi"
I didn't find rtithi's template description. Are there any test cases
?
No, it's not a
On Sat, 14 Dec 2024, Iain Sandoe wrote:
> 1) to introduce new build dependencies on:
> - bison (we normally commit generated files to the repo not expect the
> end-user
>to need bison installed).
> - a version of gm4 that recognises —gnu
We don't commit bison-generated files. (We don't
On Mon, 16 Dec 2024, Matthias Klose wrote:
> On 14.12.24 15:38, Matthias Klose wrote:
> > I tried to use the patches to build binary packages for Debian. Found some
> > issues:
>
> tried to build libgcobol on more architectures, please find the attached patch
> to disable building libgcobol on so
在 2024/12/16 下午9:20, Xi Ruoyao 写道:
/* snip */
+;; For HImode it's a little complicated...
+(define_expand "rbithi"
I didn't find rtithi's template description. Are there any test cases ?
+ [(match_operand:HI 0 "register_operand")
+ (match_operand:HI 1 "register_operand")]
+ ""
+ {
+r
> So I would just do:
>
>
> tmp = force_reg (word_mode, x);
> add_input_operand (TYPE_MODE (TREE_TYPE (arg)), tmp);
>
> In the thead specific code. That generates the initial code correctly.
> At that point we just need to make sure nothing like combine, cprop, etc
> propagates the constant into
Ok for trunk?
--
Fixes Linaro CI reported regression on r15-6164-gbdf75257aad2 in
https://linaro.atlassian.net/browse/GNU-1463.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Added corresponding -mtune= option
for each fo the arm_cpu_* effective targets.
Signed-off-by: Tor
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/branches?
-- >8 --
This crash started with my r12-7803 but I believe the problem lies
elsewhere.
build_vec_init has cleanup_flags whose purpose is -- if I grok this
correctly -- to avoid destructing an object multiple times. Let's
say w
On Thu, 12 Dec 2024, James K. Lowden wrote:
> +switch(e->type) {
> +case SymFilename:
> + asprintf(&s, "%4zu %-18s %s", e->program,
> +"Filename", e->elem.filename);
> + break;
You need to check for errors from allocation functions such as asprintf
before using the
The hook changes the allocno class to either FP_REGS or GR_REGS depending on
the mode of the register. This results in better register allocation overall,
fewer spills and reduced codesize - particularly in SPEC2017 lbm.
gcc/ChangeLog:
* config/loongarch/loongarch.cc
(loongarch_ir
In order to support vectorization of loops with multiple exits, this
patch adds the implementation of the conditional branch optab for
LoongArch LSX/LASX instructions.
This patch causes the gen-vect-{2,25}.c tests to fail. This is because
the support for vectorizing loops with multiple exits has
We can't vectorize the code into instructions like vslti.w that compare
with immediate_operand, because we miss immediate_operand support for
integer comparisons.
gcc/ChangeLog:
* config/loongarch/lasx.md: Support immediate_operand.
* config/loongarch/loongarch.cc (loongarch_expan
On Tue, 2024-12-17 at 10:41 +0800, Jiahao Xu wrote:
/* snip */
> +(define_expand "cbranch4"
> + [(set (pc)
> + (if_then_else
> + (match_operator 0 "equality_operator"
> + [(match_operand:ILASX 1 "register_operand")
> + (match_operand:ILASX 2 "reg_or_vector_same_
在 2024/12/17 10:58, Xi Ruoyao 写道:
On Tue, 2024-12-17 at 10:41 +0800, Jiahao Xu wrote:
/* snip */
+(define_expand "cbranch4"
+ [(set (pc)
+ (if_then_else
+ (match_operator 0 "equality_operator"
+ [(match_operand:ILASX 1 "register_operand")
+ (match_operand:ILA
On Mon, 25 Nov 2024, Jiang, Haochen wrote:
> I will do all of the changes with little tweak here. The "and" should
> be added (actually changed the previous "or" to "and") between
> -mtune=knl and -mtune=knm.
Thank you.
I just pushed a little follow up patch, see below.
Gerald
commit 7f4a4f3
On Mon, 2 Dec 2024, Mark Wielaard wrote:
> Adjust the DCO text to match the broader community usage and
> clarifications around the use of real names, known identities and
> (anonymous) pseudonyms.
>
> These changes clarify what was meant by "real name" and that it is not
> required to be a "legal
70 matches
Mail list logo
