On Tue, Feb 25, 2025 at 2:48 AM James K. Lowden
wrote:
>
> On Mon, 24 Feb 2025 14:51:27 +0100
> Richard Biener wrote:
>
> > On Wed, Feb 19, 2025 at 12:38?AM James K. Lowden
> > wrote:
> > >
> > > The following 14 patches constitute 105,720 lines of code in 83
> > > files to build and document th
On 2/24/25 6:10 PM, Edwin Lu wrote:
So I preferred the earlier approach of disabling speculation of the
vsetvls, though I'm guessing you're looking at this approach because
that was insufficient?
I don't think that it was because it was insufficient, but that it might
be too constraining. I
On Mon, 24 Feb 2025 14:51:27 +0100
Richard Biener wrote:
> On Wed, Feb 19, 2025 at 12:38?AM James K. Lowden
> wrote:
> >
> > The following 14 patches constitute 105,720 lines of code in 83
> > files to build and document the COBOL front end.
[...]
> > I tested these patches using "git apply" t
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Romanian team of translators. The file is available at:
https://translationproject.org/latest/cpplib/ro.po
(This file, 'cpplib-15-b2025021
cpplib-15-b20250216.ro.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
On 2/24/2025 4:34 PM, Jeff Law wrote:
On 2/24/25 5:07 PM, Edwin Lu wrote:
See [1] thread for original patch which spawned this one.
We are currently seeing the following code where we perform a vsetvl
before a branching instruction against the avl.
vsetvli a5,a1,e32,m1,tu,ma
On 2/24/25 5:07 PM, Edwin Lu wrote:
See [1] thread for original patch which spawned this one.
We are currently seeing the following code where we perform a vsetvl
before a branching instruction against the avl.
vsetvli a5,a1,e32,m1,tu,ma
vle32.v v2,0(a0)
sub a1
On 2/24/25 16:07, Edwin Lu wrote:
> See [1] thread for original patch which spawned this one.
>
> We are currently seeing the following code where we perform a vsetvl
> before a branching instruction against the avl.
>
> vsetvli a5,a1,e32,m1,tu,ma
> vle32.v v2,0(a0)
> sub
See [1] thread for original patch which spawned this one.
We are currently seeing the following code where we perform a vsetvl
before a branching instruction against the avl.
vsetvli a5,a1,e32,m1,tu,ma
vle32.v v2,0(a0)
sub a1,a1,a5 <-- a1 potentially set to 0
s
On 2/24/25 10:01 AM, Jakub Jelinek wrote:
On Mon, Feb 24, 2025 at 08:29:31AM -0500, Jason Merrill wrote:
On 2/24/25 5:52 AM, Jakub Jelinek wrote:
The following testcases segfault because the new range for -frange-for-ext-temps
temporary extension extends even the internal TARGET_EXPRs created b
Hello,
Is this email address still the most reliable way to get in touch with you?
*Farhan Faruqui*
On Mon, 24 Feb 2025 at 20:52, François Dumont wrote:
>
> All good remarks as usual, here is a new version.
>
> I took the time to leverage on the new method to replace a usage of
> _M_src_hash_code.
>
> libstdc++: [_Hashtable] Fix hash code cache usage when stateful
> hash functor
>
> It
On 2/24/25 11:04, Indu Bhagat wrote:
> On 2/6/25 11:54 AM, David Faust wrote:
>> Translate DW_TAG_GNU_annotation DIEs created for C attributes
>> btf_decl_tag and btf_type_tag into an in-memory representation in the
>> CTF/BTF container. They will be output in BTF as BTF_KIND_DECL_TAG and
>> BT
On Tue, 4 Feb 2025 at 22:27, Patrick Palka wrote:
>
> On Tue, 4 Feb 2025, Patrick Palka wrote:
>
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
> > 14 (after a long while)?
Yes, and yes, thanks.
> >
> > -- >8 --
> >
> > LWG 4027 effectively makes the const range acce
On 2/24/25 11:03, Indu Bhagat wrote:
> On 2/6/25 11:54 AM, David Faust wrote:
>> Support the btf_decl_tag and btf_type_tag attributes in BTF by creating
>> and emitting BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG records,
>> respectively, for them.
>>
>> Some care is required when -gprune-btf is in
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 German team of translators. The file is available at:
https://translationproject.org/latest/gcc/de.po
(This file, 'gcc-15-b20250216.de.po', h
Hi Harald,
Oops, I've mixed up the two attachments. Sorry for that and thank you for
detecting it and ok'ing. I will merge tomorrow morning.
Thanks again,
Andre
Andre Vehreschild * ve...@gmx.de
Am 24. Februar 2025 20:22:25 schrieb Harald Anlauf :
Hi Andre,
Am 24.02.25 um 16:44 schrieb Andre V
On Tue, 4 Feb 2025, Patrick Palka wrote:
> On Tue, 4 Feb 2025, Patrick Palka wrote:
>
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
> > 14 (after a long while)?
> >
> > -- >8 --
> >
> > LWG 4027 effectively makes the const range access CPOs ranges::cfoo behave
> > m
All good remarks as usual, here is a new version.
I took the time to leverage on the new method to replace a usage of
_M_src_hash_code.
libstdc++: [_Hashtable] Fix hash code cache usage when stateful
hash functor
It is wrong to reuse a cached hash code from another container when
t
On 2/24/25 9:43 AM, Michael Matz wrote:
It depends, but even if that were no problem in some specific cases
(perhaps by ensuring that such sequence isn't intermingled with insns that
are in different EH regions) that doesn't seem to be what the proposal is
doing? From the description it mov
On Feb 13, 2025, at 1:51 AM, Alexandre Oliva wrote:
>
> Some vect-simd-clone tests fail when targeting ancient x86 variants,
> because the expected transformations only take place with -msse4 or
> higher.
>
> So arrange for these tests to take an -msse4 option on x86, so that
> the expected vect
On Sat, Feb 15, 2025 at 04:52:58PM -0700, Jeff Law wrote:
> On 2/12/25 2:22 PM, Jakub Jelinek wrote:
>
> >
> > Or just go with that even for GCC 15 (completely untested and dunno if
> > something needs to be done about s = NULL passed to query or not) for
> > now, with the advantage that it can d
Hi Andre,
Am 24.02.25 um 16:44 schrieb Andre Vehreschild:
Hi Harald,
I have added some comment(s). Can you take another look?
assuming that you refer to the attachment of the other submission:
that one is perfect!
This one is also OK.
Thanks for the patch(es)!
Harald
Regtested ok on x86_
"James K. Lowden" writes:
>> Having a minimal harness in GCCs testsuite is critical - I'd expect a
>> gcc/testsuite/gcobol.dg/dg.exp supporting execution tests. I assume
>> Cobol has a way to exit OK or fatally and this should be
>> distinguished as testsuite PASS or FAIL.
>
> Yes, a COBOL pro
On 2/6/25 11:54 AM, David Faust wrote:
Translate DW_TAG_GNU_annotation DIEs created for C attributes
btf_decl_tag and btf_type_tag into an in-memory representation in the
CTF/BTF container. They will be output in BTF as BTF_KIND_DECL_TAG and
BTF_KIND_TYPE_TAG records.
The new CTF kinds used to
On 2/6/25 11:54 AM, David Faust wrote:
Support the btf_decl_tag and btf_type_tag attributes in BTF by creating
and emitting BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG records,
respectively, for them.
Some care is required when -gprune-btf is in effect to avoid emitting
decl or type tags for declara
On 2/6/25 11:54 AM, David Faust wrote:
gcc/
* doc/extend.texi (Common Variable Attributes): Document
btf_decl_tag attribute.
(Common Type Attributes): Document btf_type_tag attribute.
---
gcc/doc/extend.texi | 68 +
1 file cha
On Mon, 24 Feb 2025 14:51:27 +0100
Richard Biener wrote:
> Installing the result via make install DESTDIR=/foo I see both a
> 'gcobol' and a 'gcobc' program
> being installed - is that intentional?
Yes, that is intentional. gcobol is the compiler driver, as you know.
gcobc is a shell script t
On Mon, 24 Feb 2025 14:51:27 +0100
Richard Biener wrote:
> gcc-cobol/gcc/cobol/parse.y:1361.10-16: error: require bison 3.5.1,
> but have 3.0.4
> %require "3.5.1" //3.8.2 also works, but not 3.8.0
> ^^^
>
> this requirement isn't documented, neither is a version requirement
>
Hello,
On Mon, 24 Feb 2025, Jeff Law wrote:
> The pass rejects the transformation when there are instructions in the
> sequence that might throw an exception. This was added due to having
> cases that the load instruction contains a REG_EH_REGION note and
> moving it before th
Hi Harald,
I have added some comment(s). Can you take another look?
Regtested ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Regards,
Andre
On Sat, 22 Feb 2025 17:36:55 +0100
Andre Vehreschild wrote:
> Hi Harald,
>
> thanks for the review. Silently I'd hoped that there is some macr
Hi all,
I nearly forgot to publish this patch:
When transfering data between two remote images, i.e. a third images asks image
one to read some data and then asks image two to put that data into its memory,
the size of the data to transfer between these two images was miscalculated. The
attached
On Mon, Feb 24, 2025 at 08:29:31AM -0500, Jason Merrill wrote:
> On 2/24/25 5:52 AM, Jakub Jelinek wrote:
> > The following testcases segfault because the new range for
> > -frange-for-ext-temps
> > temporary extension extends even the internal TARGET_EXPRs created by
> > get_member_function_from_
On 2/24/25 2:23 AM, Richard Biener wrote:
On Fri, Feb 21, 2025 at 4:55 PM Konstantinos Eleftheriou
wrote:
Hi Richard, thanks for the feedback.
On Tue, Feb 18, 2025 at 9:17 PM Richard Biener
wrote:
Am 18.02.2025 um 17:04 schrieb Konstantinos Eleftheriou
:
From: kelefth
The pass r
On Wed, Feb 19, 2025 at 12:38 AM James K. Lowden
wrote:
>
> The following 14 patches constitute 105,720 lines of code in 83 files
> to build and document the COBOL front end. The messages are
> in a more or less logical order. We have:
>
> 1/14 4K dir: create gcc/cobol and libgcobol directorie
On 2/24/25 5:52 AM, Jakub Jelinek wrote:
Hi!
The following testcases segfault because the new range for -frange-for-ext-temps
temporary extension extends even the internal TARGET_EXPRs created by
get_member_function_from_ptrfunc.
The following patch fixes that by marking those TARGET_EXPR_INTER
Gentle ping for
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675450.html
On Mon, 24 Feb 2025, Robin Dapp wrote:
> Hi,
>
> in PR118950 we do not zero masked elements in a gather load.
> While recognizing a gather/scatter pattern we do not use the original
> type of the LHS. This matters because the type can differ with bool
> patterns (e.g. _Bool vs unsigned char) and
LGTM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2025-02-24 19:14
To: gcc-patches
CC: pal...@dabbelt.com; kito.ch...@gmail.com; juzhe.zh...@rivai.ai;
jeffreya...@gmail.com; pan2...@intel.com; rdapp@gmail.com
Subject: [PATCH] RISC-V: Include pattern stmts for dynamic LMUL computation
[PR1
> I added the negative step check just some weeks ago and I'd see it as
> simplification to remove the restriction again if you're touching the actual
> step anyway. So I wouldn't worry about stage 4 in that regard.
Oh, I see. I'll have a try after this bug fix.
Pan
-Original Message-
> I don't explore more cases here consider we are in stage 4. I think the
> expand_const_vector need some refactor up to a point.
I added the negative step check just some weeks ago and I'd see it as
simplification to remove the restriction again if you're touching the actual
step anyway. So I wo
Thanks Robin for comments.
> I agree with the general idea but I'm a bit wary fiddling with the
> coefficients
> directly. I think for a fixed-size, non VLA vector it should be sufficient to
> check whether the last step overflows.
Initial idea I would like to take care of VLS and VLA in the sa
Hi,
when scanning for program points, i.e. vector statements, we're missing
pattern statements. In PR114516 this becomes obvious as we choose
LMUL=8 assuming there are only three statements but the divmod pattern
adds another three. Those push us beyond four registers so we need to
switch to LMU
Hi,
in PR118950 we do not zero masked elements in a gather load.
While recognizing a gather/scatter pattern we do not use the original
type of the LHS. This matters because the type can differ with bool
patterns (e.g. _Bool vs unsigned char) and we don't notice the need
for zeroing out the paddin
Hello,
and ping please.
Thanks,
Martin
On Mon, Feb 10 2025, Martin Jambor wrote:
> Hello,
>
> among other things, IPA-SRA checks whether splitting out a bit of an
> aggregate or something passed by reference would lead into a clash
> with an already known IPA-CP constant a way which would cau
From: Richard Sandiford
Various parts of the omp code checked whether the size of a decl
was an INTEGER_CST in order to determine whether the decl was
variable-sized or not. If it was variable-sized, it was expected
to have a DECL_VALUE_EXPR replacement, as for VLAs.
This patch uses poly_int_tr
Hi!
The following testcases segfault because the new range for -frange-for-ext-temps
temporary extension extends even the internal TARGET_EXPRs created by
get_member_function_from_ptrfunc.
The following patch fixes that by marking those TARGET_EXPR_INTERNAL_P.
I'm not calling get_internal_target_
The target clause in OpenMP is used to offload loop kernels to accelarator
peripeherals. target's 'map' clause is used to move data from and to the
accelarator. When the data is SVE type, it may not be suitable because of
various reasons i.e. the two SVE targets may not agree on vector size or
so
Add a function to traverse down the pointer layers to the pointee type.
gcc/ChangeLog:
* tree.h (strip_pointer_types): New.
---
gcc/tree.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/gcc/tree.h b/gcc/tree.h
index 21f3cd5525c..580997b4e5d 100644
--- a/gcc/tree.h
+++ b/gcc/
This series is based on a previous thread and review comments from RichardS and
Jakub upstream:
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674698.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674219.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674434.html
zce must imply zcf but this rule was corrupted after
refactoring in 9e12010b5e724277ea. This may be observed
ater generating an .s file from any source code file with
-mriscv-attribute -march=rv32if_zce -mabi=ilp32 -S
options. A full march will be presented in arch attribute:
rv32i2p1_f2p2_zic
DCE preserves stmts performing abnormal control flow transfer but
currently has an exception for replaceable allocations and cxa_atexit
calls. That results in a broken CFG since DCE isn't set up to prune
abnormal edges possibly hanging off those.
While we could try to add this handling, the follo
On Mon, 24 Feb 2025 at 06:23, François Dumont wrote:
>
>
> On 20/02/2025 18:28, Thomas Schwinge wrote:
> > Hi!
> >
> > On 2025-02-20T16:36:56+, Jonathan Wakely wrote:
> >> On 20/02/25 15:50 +0100, Thomas Schwinge wrote:
> >> >From 820e015494e25187c9a5ffbd69911ec6ce612789 Mon Sep 17 00:00:00 2
On Wed, Feb 12, 2025 at 1:16 PM Uros Bizjak wrote:
>
> The combine pass is trying to combine:
>
> Trying 16, 22, 21 -> 23:
>16: r104:QI=flags:CCNO>0
>22: {r120:QI=r104:QI^0x1;clobber flags:CC;}
> REG_UNUSED flags:CC
>21: r119:QI=flags:CCNO<=0
> REG_DEAD flags:CCNO
>23:
On Mon, 24 Feb 2025, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled due to a bug in
> optimize_range_tests_to_bit_test. It is trying to optimize
> check for a in [-34,-34] or [-26,-26] or [-6,-6] or [-4,inf] ranges.
> Another reassoc optimization folds the the test for the
Pushed with minor coding style fix:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4dcd3c7749734133f7f59509b1a118f3a13de4ee
On Mon, Feb 24, 2025 at 4:00 PM Kito Cheng wrote:
>
> Thanks, will push after verified on my hand :)
>
> On Mon, Feb 24, 2025 at 3:20 PM Hsing Yu Peng wrote:
> >
> > Address
Hi!
Now that the #embed paper has been voted in, the following patch
removes the pedwarn for C++26 on it (and adjusts pedwarn warning for
older C++ versions) and predefines __cpp_pp_embed FTM.
I believe we otherwise implement everything in the paper already,
except I'm really confused by the
[Exa
On Thu, Oct 3, 2024 at 6:39 PM Tom Tromey wrote:
>
> I am working on some changes to GNAT to emit hierarchical DWARF --
> i.e., where entities will have simple names nested in a DW_TAG_module.
>
> While working on this I found a couple of paths in modified_type_die
> where "mod_scope" should be us
On Fri, Feb 21, 2025 at 4:55 PM Konstantinos Eleftheriou
wrote:
>
> Hi Richard, thanks for the feedback.
>
> On Tue, Feb 18, 2025 at 9:17 PM Richard Biener
> wrote:
> >
> >
> >
> > > Am 18.02.2025 um 17:04 schrieb Konstantinos Eleftheriou
> > > :
> > >
> > > From: kelefth
> > >
> > > The pass
I would like to ping for the following patch that fixes P1 regression:
gcc/ChangeLog:
* combine.cc (distribute_notes) : Remove
REG_UNUSED note from i2 when the register is also mentioned in i3.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr118739.c: New test.
https://gcc.gnu.org/pip
Hi!
The following testcase is miscompiled due to a bug in
optimize_range_tests_to_bit_test. It is trying to optimize
check for a in [-34,-34] or [-26,-26] or [-6,-6] or [-4,inf] ranges.
Another reassoc optimization folds the the test for the first
two ranges into (a + 34U) & ~8U in [0U,0U] range,
Hi!
There is a typo in one of the OpenMP gimplification diagnostics messages.
The following patch fixes that and adjusts tests which just copied that
message including typo to dg-warning regexps in 2 tests.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2025-02-24 Ja
On Fri, Feb 14, 2025 at 09:14:48AM -0500, David Malcolm wrote:
> I haven't used ranger yet within the analyzer, and I wonder if there is
> a philosophical divide here between the goals of optimization versus
> bug finding: the optimizer makes use of undefined behavior in order to
> add assumptions
> This patch would like to perform the overflow to smode check before IOR
> the base2 series, and perform the clean highest bit if the const_vector
> overflow to smode occurs. If no overflow, there will do nothing here.
I agree with the general idea but I'm a bit wary fiddling with the coefficien
Thanks, will push after verified on my hand :)
On Mon, Feb 24, 2025 at 3:20 PM Hsing Yu Peng wrote:
>
> Address Fei's comment.
>
> Thanks
> Lino
>
> Fei Gao 於 2025年2月24日 週一 下午2:20寫道：
> >
> > The case you hit is s2 set in frame mask but s1 not. So you're trying to
> > set s1 bit manually.
> > If
65 matches
Mail list logo
