Re: [pushed][PATCH v2] LoongArch: Support immediate_operand for vec_cmp

2024-12-26 Thread Lulu Cheng
Pushed to r15-6445. 在 2024/12/18 下午3:45, Jiahao Xu 写道: 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 (vec_cmp): Remove.

[PATCH 6/6] Size input line cache based on file size

2024-12-26 Thread Andi Kleen
From: Andi Kleen While the input line cache size now tunable it's better if the compiler auto tunes it. Otherwise large files needing random file access will still have to search many lines to find the right lines. Add support for allocating one line anchor per hundred input lines. This means an

[PATCH 3/6] Remove m_total_lines support from input cache

2024-12-26 Thread Andi Kleen
From: Andi Kleen With the new cache maintenance algorithm we don't need the maximum number of lines anymore. Remove all the code for that. gcc/ChangeLog: PR preprocessor/118168 * input.cc (total_lines_num): Remove. (file_cache_slot::evict): Dito. (file_cache_slot

[PATCH 2/6] Rebalance file_cache input line cache dynamically

2024-12-26 Thread Andi Kleen
From: Andi Kleen The input context file_cache maintains an array of anchors to speed up accessing lines before the previous line. The array has a fixed upper size and the algorithm relies on the linemap reporting the maximum number of lines in the file in advance to compute the position of each a

[PATCH 5/6] Add a cache of recent lines

2024-12-26 Thread Andi Kleen
From: Andi Kleen For larger files the file_cache line index will be spread out to make the index fit into the fixed buffer, so any access to the non latest line will need some skipping of lines. Most accesses for line are near the latest line because a diagnostic is likely near where the scanner

Fix file_cache for large files

2024-12-26 Thread Andi Kleen
This patch kit fixes scaling issues for the input cache, especially for C, motivated by PR118168. In overall in number of lines it is practically neutral: gcc/input.cc | 261 -- gcc/inp

[PATCH 4/6] Move ferror out of hot loop of file cache

2024-12-26 Thread Andi Kleen
From: Andi Kleen glibc ferror is surprisingly expensive. Move it out of the hot loop of finding lines by setting a flag after the actual IO operations. gcc/ChangeLog: PR preprocessor/118168 * input.cc (file_cache_slot::m_error): New field. (file_cache_slot::create): Clea

[PATCH 1/6] Add tunables for input buffer

2024-12-26 Thread Andi Kleen
From: Andi Kleen The input machinery to read the source code independent of the lexer has a range of hard coded maximum array sizes that can impact performance. Make them tunable. input.cc is part of libcommon so it cannot direct access params without a level of indirection. gcc/ChangeLog:

[PATCH] tree-optimization: Fix ICE in tree-parloops.cc reduction_phi() [PR118205]

2024-12-26 Thread Lewis Hyatt
Hello- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118205 The PR shows that on some code involving indexing into a zero-length array in a loop, we try to look up in reduction_phi() a statement that is not a PHI. Since r15-6001, that asserts, whereas it used to return NULL, so this patch restores

Re: [PATCH v3] RISC-V: Fix code gen for reduction with length 0 [PR118182]

2024-12-26 Thread Jeff Law
On 12/24/24 2:24 AM, Robin Dapp wrote: `.MASK_LEN_FOLD_LEFT_PLUS`(or `mask_len_fold_left_plus_m`) is expecting the return value will be the start value even if the length is 0. However current code gen in RISC-V backend is not meet that semantic, it will result a random garbage value if lengt

PR118200: note_simd_array_uses crashes in SIMT region with offloading to nvptx

2024-12-26 Thread Prathamesh Kulkarni
Hi, As mentioned in PR, note_simd_array_uses (and adjust_simduid_builtins), crash while processing GOMP internal functions (GOMP_SIMD_VF) in SIMT region. This happens because in SIMT region, first argument to GOMP internal function is lhs of call to IFN_GOMP_SIMT_ENTER, rather than default defini

[committed] Fix timevar.cc build on systems that don't have CLOCK_MONOTONIC

2024-12-26 Thread John David Anglin
Tested on hppa64-hp-hpux11.11. Committed to trunk. Dave --- Fix timevar.cc build on systems that don't have CLOCK_MONOTONIC 2024-12-26 John David Anglin gcc/ChangeLog: PR target/118050 * timevar.cc (get_time): Only use CLOCK_MONOTONIC if '_POSIX_TIMERS > 0 && defin

[pushed] doc: Move Modula 2 PM4 link to https

2024-12-26 Thread Gerald Pfeifer
Turns out there were two of these links in the Modula 2 docs; this takes care of the second instance. Pushed. Gerald gcc: * doc/gm2.texi (Dialect): Move PM4 link to https. --- gcc/doc/gm2.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/doc/gm2.texi b/gcc/d

Re: [PATCH 1/2] libstdc++: don't implicit-construct _Yielded_decvref [PR118022]

2024-12-26 Thread Jonathan Wakely
On Thu, 26 Dec 2024, 10:03 Jonathan Wakely, wrote: > > > On Wed, 25 Dec 2024, 01:20 Arsen Arsenović, wrote: > >> Evening! >> >> This patchset includes fixes for two bugs in libstdc++s implementation >> of std::generator, namely PR118196 and PR118022. >> >> There's little to note about these fixe

Re: [PATCH 1/2] libstdc++: don't implicit-construct _Yielded_decvref [PR118022]

2024-12-26 Thread Jonathan Wakely
On Wed, 25 Dec 2024, 01:20 Arsen Arsenović, wrote: > Evening! > > This patchset includes fixes for two bugs in libstdc++s implementation > of std::generator, namely PR118196 and PR118022. > > There's little to note about these fixes. > > Tested on x86_64-pc-linux-gnu via 'make -j17 check' with 's

Re: [PATCH 2/2] libstdc++: add missing return in generator assignment operator [PR118196]

2024-12-26 Thread Jonathan Wakely
On Wed, 25 Dec 2024, 01:15 Arsen Arsenović, wrote: > libstdc++-v3/ChangeLog: > > PR libstdc++/118196 > * include/std/generator (generator::operator=(generator)): Add > missing 'return *this;'. > * > testsuite/24_iterators/range_generators/move-assign-missing-return