> Am 25.01.2025 um 10:47 schrieb Jakub Jelinek :
>
> Hi!
>
> We already do this canonicalization in
> simplify_using_ranges::simplify_div_or_mod_using_ranges, but that means
> that it is not done at -O1 or when vrp is otherwise disabled, and that
> it can be done too late in some cases when e
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
This is a fix for slowness accessing random lines in the source file
for diagnostics.
This version I added a unit test as requested by David, and also
added a x86 vectorization hint for the hot line search function (with the
early break work the vectorizer is powerful enough to handle it now)
If
From: Andi Kleen
gcc/ChangeLog:
* input.cc (check_line): New.
(test_replacement): New function to test line caching.
(input_cc_tests): Call test_replacement
---
gcc/input.cc | 46 ++
1 file changed, 46 insertions(+)
diff --git
From: Andi Kleen
This is the hot function in input.cc
The vectorizer can vectorize it now, but in a generic cpu O2 x86 build it isn't.
Add a automatic target clone to handle it for x86 and build
that function with O3.
The ifdef here is ugly, perhaps gcc should have a more convenient
"clone for
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:
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
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
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
"Li, Pan2" writes:
> Thanks Jeff and Sam, updated v2 for -fno-strict-aliasing.
Thanks! The test looks good now.
>
> Pan
>
> -Original Message-
> From: Jeff Law
> Sent: Sunday, January 26, 2025 1:06 AM
> To: Li, Pan2 ; gcc-patches@gcc.gnu.org
> Cc: juzhe.zh...@rivai.ai; kito.ch...@gmai
lgtm
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2025-01-26 09:00
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; vineetg;
richard.sandiford; Pan Li
Subject: [PATCH v2] RISC-V: Make FRM as global register [PR118103] [PR118646]
From: Pan Li
After we enabled the labe-combin
Thanks Jeff and Sam, updated v2 for -fno-strict-aliasing.
Pan
-Original Message-
From: Jeff Law
Sent: Sunday, January 26, 2025 1:06 AM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; rdapp@gmail.com;
vine...@rivosinc.com; richard.sandif...@arm
From: Pan Li
After we enabled the labe-combine pass after the mode-switching pass, it
will try to combine below insn patterns into op. Aka:
(insn 40 5 41 2 (set (reg:SI 11 a1 [151])
(reg:SI 69 frm)) "pr118103-simple.c":67:15 2712 {frrmsi}
(nil))
(insn 41 40 7 2 (set (reg:SI 69 frm)
(const
Am 25.01.25 um 21:05 schrieb Jerry D:
On 1/25/25 11:12 AM, Harald Anlauf wrote:
Dear all,
the attached patch fixes bogus errors with CLASS variables in BLOCK DATA
that showed up because some compiler-generated components were not
declared as artificial.
Furthermore, a warning can be emitted fo
On 1/25/25 11:12 AM, Harald Anlauf wrote:
Dear all,
the attached patch fixes bogus errors with CLASS variables in BLOCK DATA
that showed up because some compiler-generated components were not
declared as artificial.
Furthermore, a warning can be emitted for variables declared but not in
a COMMO
Dear all,
the attached patch fixes bogus errors with CLASS variables in BLOCK DATA
that showed up because some compiler-generated components were not
declared as artificial.
Furthermore, a warning can be emitted for variables declared but not in
a COMMON block if the option "-Wunused-variable" i
Hi,
On 24 Jan 2025, at 17:50, Jason Merrill wrote:
> On 1/23/25 12:20 PM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 21 Jan 2025, at 22:51, Jason Merrill wrote:
>>
>>> On 1/3/25 3:00 PM, Simon Martin wrote:
We currently accept this code with c++ <= 17 even though it's
invalid
since
On 1/25/25 1:07 AM, pan2...@intel.com wrote:
From: Pan Li
After we enabled the labe-combine pass after the mode-switching pass, it
will try to combine below insn patterns into op. Aka:
(insn 40 5 41 2 (set (reg:SI 11 a1 [151])
(reg:SI 69 frm)) "pr118103-simple.c":67:15 2712 {frrmsi}
On 1/25/25 4:12 AM, Jakub Jelinek wrote:
On Fri, Jan 24, 2025 at 07:07:15PM -0500, Jason Merrill wrote:
Hypothetically, but those cases are just either error or DECL_EXTERNAL. In
the error case we're failing anyway; in the external case all the
base/nonbase for a particular structured binding de
So under the umbrella of pr116256 (P3 regression) I've been exploring
removal of the mvconst_internal pattern. Not surprisingly, that's
going to cause all kinds of undesirable fallout. While I can kind of
see a path forward for that work, it's going to require some combine
work that I don't
*Hi,*
*Hope you're doing awesome!*
*I'm reaching out to see if you're interested in diving into the
possibilities of acquiring the Visitors/Registrants List.*
*Here's what's on the table:*
*Event Name: Street Mineral, Fossil, Gem & Jewelry Show 2025*
*Date: 30 Jan - 16 Feb 2025*
*Location
Hi!
In the following testcase we error on the first case because it is
trying to construct an array from overaligned type, but if there are
qualifiers, we accept it silently (unlike in C++ which diagnoses all 3).
The problem is that grokdeclarator if TYPE_QUALS (element_type) is
non-zero just use
Hi!
We already do this canonicalization in
simplify_using_ranges::simplify_div_or_mod_using_ranges, but that means
that it is not done at -O1 or when vrp is otherwise disabled, and that
it can be done too late in some cases when e.g. the r8-2064
"X / C1 op C2 into a simple range test." optimizatio
Hi!
This is something the C++ FE has been diagnosing but C FE only
complained if there wasn't an identifier right after opening (
Bootstrapped/regtested on x86_64-linux and i686-linux, commited to trunk.
2025-01-25 Jakub Jelinek
PR c/118639
* c-parser.cc (c_parser_omp_variabl
On Fri, Jan 24, 2025 at 07:07:15PM -0500, Jason Merrill wrote:
> Hypothetically, but those cases are just either error or DECL_EXTERNAL. In
> the error case we're failing anyway; in the external case all the
> base/nonbase for a particular structured binding declaration should be
> consistent.
So
pan2...@intel.com writes:
> From: Pan Li
>
> After we enabled the labe-combine pass after the mode-switching pass, it
> will try to combine below insn patterns into op. Aka:
>
> (insn 40 5 41 2 (set (reg:SI 11 a1 [151])
> (reg:SI 69 frm)) "pr118103-simple.c":67:15 2712 {frrmsi}
> (nil))
> (i
From: Pan Li
After we enabled the labe-combine pass after the mode-switching pass, it
will try to combine below insn patterns into op. Aka:
(insn 40 5 41 2 (set (reg:SI 11 a1 [151])
(reg:SI 69 frm)) "pr118103-simple.c":67:15 2712 {frrmsi}
(nil))
(insn 41 40 7 2 (set (reg:SI 69 frm)
(const
27 matches
Mail list logo
