On 2/20/25 7:16 AM, Julian Waters wrote:
Patch with the amendments to the commit message as requested.
best regards,
Julian
From e8e742b1f809af2c1a9697c31335e184738b258a Mon Sep 17 00:00:00 2001
From: Julian Waters
Date: Tue, 15 Oct 2024 20:56:22 +0800
Subject: [PATCH] Implement Windows TLS
M
On Wed, Feb 19, 2025 at 11:29 PM Jeff Law wrote:
>
>
> An interesting little bug. We're just emitting what appears to me to be
> a silly warning.
>
> By the time the array-bounds checker runs we have this statement in the IL:
>
> > MEM[(int *)_42 + -4B] ={v} {CLOBBER(eob)};
>
> Naturally that
On Wed, 19 Feb 2025, Jeff Law wrote:
>
>
> On 2/15/25 6:36 AM, Richard Biener wrote:
> > The PR indicates a very specific issue with regard to SSA coalescing
> > failures because there's a pre IV increment loop exit test. While
> > IVOPTs created the desired IL we later simplify the exit test i
On Thu, Feb 20, 2025 at 3:11 PM Uros Bizjak wrote:
>
> On Thu, Feb 20, 2025 at 3:17 AM H.J. Lu wrote:
> >
> > On Thu, Feb 20, 2025 at 5:37 AM H.J. Lu wrote:
> > >
> > > On Wed, Feb 19, 2025 at 10:09 PM Uros Bizjak wrote:
> > > >
> > > ...
> > > > > My algorithm keeps a list of registers which c
Patch with the amendments to the commit message as requested.
best regards,
Julian
>From e8e742b1f809af2c1a9697c31335e184738b258a Mon Sep 17 00:00:00 2001
From: Julian Waters
Date: Tue, 15 Oct 2024 20:56:22 +0800
Subject: [PATCH] Implement Windows TLS
MIME-Version: 1.0
Content-Type: text/plain;
On Thu, Feb 20, 2025 at 3:17 AM H.J. Lu wrote:
>
> On Thu, Feb 20, 2025 at 5:37 AM H.J. Lu wrote:
> >
> > On Wed, Feb 19, 2025 at 10:09 PM Uros Bizjak wrote:
> > >
> > ...
> > > > My algorithm keeps a list of registers which can access the stack
> > > > starting with SP and FP. If any registers
On Sat, Feb 15, 2025 at 1:27 AM H.J. Lu wrote:
>
> On Fri, Feb 14, 2025 at 10:08 PM Richard Biener wrote:
> >
> > On Fri, 14 Feb 2025, Uros Bizjak wrote:
> >
> > > On Fri, Feb 14, 2025 at 4:56 AM H.J. Lu wrote:
> > > >
> > > > On Thu, Feb 13, 2025 at 5:17 PM Uros Bizjak wrote:
> > > > >
> > > >
On Thu, 2025-02-20 at 10:31 +0800, Jin Ma wrote:
> On Wed, 19 Feb 2025 21:53:32 +0800, Jeff Law wrote:
> >
> >
> > On 2/19/25 1:00 AM, Robin Dapp wrote:
> > > > > As I mentioned before, this may not be a good solution, as it risks
> > > > > missing other
> > > > > optimization opportunities. As
So gcc.target/aarch64/rev16_2.c started to fail after r15-268-g9dbff9c05520a7,
the problem is combine now rejects the instruction combine. This happens because
after a different combine which uses a define_split and that define_split
creates
a new pseudo register. That new pseudo register is dead
On Tue, 18 Feb 2025 21:40:06 -0700, Jeff Law wrote:
>
>
> On 2/18/25 7:30 PM, Jin Ma wrote:
>
> >
> > I apologize for not explaining things more clearly. I also discovered that
> > the issue is caused by CSE. I think that during the substitution process,
> > CSE recognized the syntax of if_then
On Wed, 19 Feb 2025 21:53:32 +0800, Jeff Law wrote:
>
>
> On 2/19/25 1:00 AM, Robin Dapp wrote:
> >>> As I mentioned before, this may not be a good solution, as it risks
> >>> missing other
> >>> optimization opportunities. As you pointed out, we need a more general
> >>> approach
> >>> to fix
On Wed, Feb 19, 2025 at 9:06 PM Jan Hubicka wrote:
>
> Hi,
> this is a variant of a hook I benchmarked on cpu2016 with -Ofast -flto
> and -O2 -flto. For non -Os and no Windows ABI should be pratically the
> same as your variant that was simply returning mem_cost - 2.
>
I've tested O2/(Ofast march
On Thu, Feb 20, 2025 at 5:37 AM H.J. Lu wrote:
>
> On Wed, Feb 19, 2025 at 10:09 PM Uros Bizjak wrote:
> >
> ...
> > > My algorithm keeps a list of registers which can access the stack
> > > starting with SP and FP. If any registers are derived from the list,
> > > add them to the list until all
On Wed, 19 Feb 2025 12:55:03 +0100
Matthias Klose wrote:
> libgcobol/ChangeLog
> * Makefile.in: New file.
> * acinclude.m4: New file.
> * aclocal.m4: New file.
> * configure.ac: New file.
> * configure.tgt: New file.
>
> I had updated the configure.tgt, please find
On 2/15/25 6:36 AM, Richard Biener wrote:
The PR indicates a very specific issue with regard to SSA coalescing
failures because there's a pre IV increment loop exit test. While
IVOPTs created the desired IL we later simplify the exit test into
the undesirable form again. The following fixes
On 2/17/25 3:12 AM, Richard Sandiford wrote:
"Li, Pan2" writes:
Thanks Jeff and Richard S.
Not sure if I followed up the discussion correct, but this patch only try to
fix the vxrm insn
deleted during late-combine (same scenario as frm) by adding it to global_regs.
If global_regs is not t
On 2/18/25 4:22 AM, Li, Pan2 wrote:
I see, thanks Richard S for explaining, that makes sense to me and we do
similar things for frm.
It sounds like we need to re-visit what the semantics of vxrm is, from the spec
I only find below words.
Does that indicates callee-save(the spec doesn't ment
An interesting little bug. We're just emitting what appears to me to be
a silly warning.
By the time the array-bounds checker runs we have this statement in the IL:
MEM[(int *)_42 + -4B] ={v} {CLOBBER(eob)};
Naturally that looks like an out of bounds array index and we warn.
Which see
..., where "support" means that the build doesn't fail, but it doesn't mean
that all target libraries get built and we get pretty test results for the
additional languages.
* configure.ac (unsupported_languages) [GCN, nvptx]: Add 'ada'.
(noconfigdirs) [GCN, nvptx]: Add 'target-libo
This test has been failing since r15-1619-g3b9b8d6cfdf593, which made
IRA prefer a call-clobbered register over a call-preserved register
for mem1 (the second load). In this particular case, that just
forces the variable p3 to be allocated to a call-preserved register
instead, leading to an extra
On Wed, Feb 19, 2025 at 10:09 PM Uros Bizjak wrote:
>
...
> > My algorithm keeps a list of registers which can access the stack
> > starting with SP and FP. If any registers are derived from the list,
> > add them to the list until all used registers are exhausted. If
> > any stores use the reg
This adds one more ISR test to the ave testsuite.
Johann
--
AVR: Add new ISR test gcc.target/avr/torture/isr-04-regs.c.
gcc/testsuite/
* gcc.target/avr/torture/isr-04-regs.c: New test.
* gcc.target/avr/isr-test.h: Don't set GPRs to values
that are 0 mod 0x11.AVR: Ad
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
In this PR we crash in cxx_eval_constant_expression/GOTO_EXPR on:
gcc_assert (cxx_dialect >= cxx23);
The code obviously doesn't expect to see a goto pre-C++23. But we can
get here with the new prvalue optimization. In this
The attached patch does some ground-laying work for OpenMP
deep mapping - touching common gfortran code.
It does so by:
(1)gfc_tree_array_size now can determine the array size not only from the
passed Fortran gfc_expr but also using a descriptor, passed as gimple
'tree'.
(2) Adds missingGFC_
> -Original Message-
> From: Matthias Klose
> Sent: Wednesday, February 19, 2025 06:55
> To: gcc-patches@gcc.gnu.org; James K. Lowden
> Subject: Re: [PATCH] COBOL 3/15 92K bld: config and build machinery
>
> libgcobol/ChangeLog
> * Makefile.in: New file.
> * acinclude.m4: N
> -Original Message-
> From: Andrew Pinski
> Sent: Wednesday, February 19, 2025 02:13
> To: James K. Lowden
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] COBOL v3: 8/14 516K api: GENERIC interface
>
> On Tue, Feb 18, 2025 at 10:52 PM James K. Lowden
> wrote:
> >
> > From f89a50
On Wed, Feb 19, 2025 at 10:14:21AM -0500, Patrick Palka wrote:
> On Wed, 19 Feb 2025, Marek Polacek wrote:
>
> > I suppose it's safer to leave this for GCC 16, but anyway:
> >
> > Bootstrapped/regtested on x86_64-pc-linux-gnu.
> >
> > -- >8 --
> > Since r10-7718 the attached tests produce an ICE
Hi,
this is a variant of a hook I benchmarked on cpu2016 with -Ofast -flto
and -O2 -flto. For non -Os and no Windows ABI should be pratically the
same as your variant that was simply returning mem_cost - 2.
It seems mostly SPEC netural. With -O2 -flto there is
small 4% improvement on povray (whic
Julian Waters writes:
> Apologies, here is the implementation with regenerated configure this time.
> Do excuse me sending an entirely new mail instead of replying to the previous
> one, I have to do it this way due to a quirk in my email client.
>
> best regards,
> Julian
>
> gcc/ChangeLog:
>
Thanks for the advice, I will apply the suggested changes to the commit
message as soon as possible. I'm assuming the target maintainers in this
case would be the MINGW maintainers, Jonathan Yong and Liu Hao?
best regards,
Julian
On Wed, Feb 19, 2025 at 10:27 PM Sam James wrote:
> Julian Waters
On Wed, 19 Feb 2025 at 15:03, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK, thanks.
>
> -- >8 --
>
> Even though iterator is a reserved macro name, we can't use it as the
> name of this implementation detail type since it could introduce name
> lookup a
gcc.target/aarch64/sve/var_stride_2.c started failing after
r15-268-g9dbff9c05520, but the change was an improvement:
@@ -36,13 +36,11 @@
b.any .L9
ret
.L17:
- ubfiz x5, x3, 10, 16
- ubfiz x4, x2, 10, 16
- add x5, x1, x5
- add x4, x0, x4
-
On Wed, 19 Feb 2025, Marek Polacek wrote:
> I suppose it's safer to leave this for GCC 16, but anyway:
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu.
>
> -- >8 --
> Since r10-7718 the attached tests produce an ICE in verify_address:
>
> error: constant not recomputed when 'ADDR_EXPR' chan
On 2/19/25 7:45 AM, abhi wrote:
Signed-off-by: abhi
---
libiberty/memcmp.c | 3 +++
1 file changed, 3 insertions(+)
Passing a NULL pointer to memcmp is undefined behavior, so if you're
patching this in response to seeing a NULL pointer for str1 or str1,
then you need to investigate where
On Wed, 19 Feb 2025 at 14:57, Patrick Palka wrote:
>
> On Wed, 19 Feb 2025, Patrick Palka wrote:
>
> > On Wed, 19 Feb 2025, Jonathan Wakely wrote:
> >
> > > On Tue, 18 Feb 2025 at 04:11, Patrick Palka wrote:
> > > >
> > > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> > > >
> >
On 19/02/2025 12:53, Richard Sandiford wrote:
No unfortunately the error is just:
../FMV_REWRITE/gcc/testsuite/g++.target/aarch64/mvc-error2.C:9:1: error:
redefinition of ‘float foo()’
9 | foo () { return 3; }
| ^~~
../FMV_REWRITE/gcc/testsuite/g++.target/aarch64/mvc-error2.C:6:1:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
Even though iterator is a reserved macro name, we can't use it as the
name of this implementation detail type since it could introduce name
lookup ambiguity in valid code, e.g.
struct A { using iterator = void; }
struct B :
On Wed, 19 Feb 2025, Patrick Palka wrote:
> On Wed, 19 Feb 2025, Jonathan Wakely wrote:
>
> > On Tue, 18 Feb 2025 at 04:11, Patrick Palka wrote:
> > >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> > >
> > > -- >8 --
> > >
> > > The original implementation was accidentally
Previously the analyzer treated IFN_UBSAN_BOUNDS as a no-op, but
the other IFN_UBSAN_* were unrecognized and conservatively treated
as having arbitrary behavior.
Treat IFN_UBSAN_NULL and IFN_UBSAN_PTR also as no-ops, which should
make -fanalyzer behave better with -fsanitize=undefined.
Successful
input.cc's file_cache was borrowing copies of the file name.
This could lead to use-after-free when writing out sarif output
from Fortran, which frees its filenames before the sarif output
is fully written out.
Fix by taking a copy in file_cache_slot.
Successfully bootstrapped & regrtested on x86
Signed-off-by: abhi
---
libiberty/memcmp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libiberty/memcmp.c b/libiberty/memcmp.c
index 5b1af020e6c..449434e049e 100644
--- a/libiberty/memcmp.c
+++ b/libiberty/memcmp.c
@@ -22,6 +22,9 @@ as if comparing unsigned char arrays.
int
memcmp (c
On Wed, 19 Feb 2025, Jonathan Wakely wrote:
> On Tue, 18 Feb 2025 at 04:11, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> > -- >8 --
> >
> > The original implementation was accidentally based off of an older
> > revision of the paper, P2542R7 inst
On Wed, Feb 19, 2025 at 2:10 PM H.J. Lu wrote:
>
> On Wed, Feb 19, 2025 at 8:16 PM Uros Bizjak wrote:
> >
> > On Wed, Feb 19, 2025 at 12:53 PM H.J. Lu wrote:
> > >
> > > Since stack can only be accessed by GPR, check GENERAL_REG_P, instead of
> > > REG_P, in ix86_find_all_reg_use_1.
> > >
> > >
On 2/19/25 1:00 AM, Robin Dapp wrote:
As I mentioned before, this may not be a good solution, as it risks missing
other
optimization opportunities. As you pointed out, we need a more general approach
to fix it. Unfortunately, while I’m still trying to find a solution, I currently
don't have a
On Mon, 17 Feb 2025 at 21:27, François Dumont wrote:
>
> Ping for this bug fix, would you like a PR ?
No, I don't think we need one, I'm reviewing the patch now.
>
> On 20/01/2025 22:12, François Dumont wrote:
> > Hi
> >
> > In my work on fancy pointer support I've decided to always cache the
>
On 20/01/25 22:12 +0100, François Dumont wrote:
Hi
In my work on fancy pointer support I've decided to always cache the
hash code.
Doing so I spotted a bug in the management of this cache when hash
functor is stateful.
libstdc++: [_Hashtable] Fix hash code cache usage when hash
functo
I suppose it's safer to leave this for GCC 16, but anyway:
Bootstrapped/regtested on x86_64-pc-linux-gnu.
-- >8 --
Since r10-7718 the attached tests produce an ICE in verify_address:
error: constant not recomputed when 'ADDR_EXPR' changed
but before that we wrongly rejected the tests with "is
On Wed, Feb 19, 2025 at 8:16 PM Uros Bizjak wrote:
>
> On Wed, Feb 19, 2025 at 12:53 PM H.J. Lu wrote:
> >
> > Since stack can only be accessed by GPR, check GENERAL_REG_P, instead of
> > REG_P, in ix86_find_all_reg_use_1.
> >
> > gcc/
> >
> > PR target/118936
> > * config/i386/i386.cc (ix86_find
On Mon, 17 Feb 2025 at 11:59, François Dumont wrote:
>
>
> On 16/02/2025 23:14, Jonathan Wakely wrote:
> > On Sun, 16 Feb 2025 at 21:15, François Dumont wrote:
> >> Hi
> >>
> >> A minor simplification.
> >>
> >> libstdc++: Simplify _Hashtable::_M_merge_multi
> >>
> >> When merging two hashtable i
Alfie Richards writes:
> On 18/02/2025 15:32, Richard Sandiford wrote:
> > Alfie Richards writes:
> >> This changes the ambiguation error for C++ to cover cases of differently
> >> annotated FMV function sets whose signatures only differ by their return
> >> type.
> >>
> >> It also adds tes
Pengxuan Zheng writes:
> Similar to the canonicalization done in combine, we canonicalize vec_merge
> with
> swap_communattive_operands_p in simplify_ternary_operation too.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-protos.h (aarch64_exact_log2_inverse): New.
> * config/aarch64/a
On Tue, 18 Feb 2025 at 04:11, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> The original implementation was accidentally based off of an older
> revision of the paper, P2542R7 instead of R8. As far as I can tell
> the only semantic change i
On 18/02/2025 15:32, Richard Sandiford wrote:
> Alfie Richards writes:
>> This changes the ambiguation error for C++ to cover cases of differently
>> annotated FMV function sets whose signatures only differ by their return
>> type.
>>
>> It also adds tests covering many FMV errors for Aarch64, in
Andrew Carlotti writes:
> [...]
> @@ -204,6 +207,18 @@ static constexpr aarch64_processor_info all_cores[] =
>{NULL, aarch64_no_cpu, aarch64_no_arch, 0}
> };
>
> +/* Return the set of feature flags that are required to be enabled when the
> + features in FLAGS are enabled. */
> +
> +aarc
On Wed, Feb 19, 2025 at 12:53 PM H.J. Lu wrote:
>
> Since stack can only be accessed by GPR, check GENERAL_REG_P, instead of
> REG_P, in ix86_find_all_reg_use_1.
>
> gcc/
>
> PR target/118936
> * config/i386/i386.cc (ix86_find_all_reg_use_1): Replace REG_P
> with GENERAL_REG_P.
>
> gcc/testsuite/
Ping^5 for patches 2-4:
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672677.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672678.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672679.html
On 12/02/2025 11:20, Alex Coplan wrote:
> Ping
>
> On 03/02/2025 14:46,
On Tue, Feb 18, 2025 at 08:23:15PM +0100, Richard Biener wrote:
> > Am 18.02.2025 um 20:07 schrieb Roman Kagan :
> > On Tue, Feb 18, 2025 at 07:17:24PM +0100, Uros Bizjak wrote:
> >>> On Mon, Feb 17, 2025 at 6:19 PM Roman Kagan wrote:
> >>> On Thu, Jan 02, 2025 at 04:32:17PM +0100, Roman Kagan wro
libgcobol/ChangeLog
* Makefile.in: New file.
* acinclude.m4: New file.
* aclocal.m4: New file.
* configure.ac: New file.
* configure.tgt: New file.
I had updated the configure.tgt, please find it attached here again.
also disabling cobol in the toplevel co
Since stack can only be accessed by GPR, check GENERAL_REG_P, instead of
REG_P, in ix86_find_all_reg_use_1.
gcc/
PR target/118936
* config/i386/i386.cc (ix86_find_all_reg_use_1): Replace REG_P
with GENERAL_REG_P.
gcc/testsuite/
PR target/118936
* gcc.target/i386/pr118936.c: New test.
OK for ma
Andrew Pinski writes:
> This testcase started to fail with r15-268-g9dbff9c05520a7.
> When late_combine was added, it was turned on for -O2+ only,
> so this testcase still failed.
> This changes the option to be -O2 instead of -O and the testcase
> started to pass again.
>
> tested for aarch64-lin
> Am 19.02.2025 um 02:55 schrieb pan2...@intel.com:
>
> From: Pan Li
>
> This patch would like to fix the ICE similar as below, assump we have
> sample code:
>
> 1 │ int a, b, c;
> 2 │ short d, e, f;
> 3 │ long g (long h) { return h; }
> 4 │
> 5 │ void i () {
> 6 │
> Well, this adopts the same approach as the fix for PR 117525 (same
> problem, but on hppa).
> In that PR there's also a mention of a similar problem on Sparc, and
> Konstantinos says he is working on a middle-end fix (see comment #9 in
> PR117712).
The problem clearly comes from the middle-end
Apologies, here is the implementation with regenerated configure this time. Do
excuse me sending an entirely new mail instead of replying to the previous one,
I have to do it this way due to a quirk in my email client.
best regards,
Julian
gcc/ChangeLog:
* config/i386/i386.cc (ix86_leg
>> As I mentioned before, this may not be a good solution, as it risks missing
>> other
>> optimization opportunities. As you pointed out, we need a more general
>> approach
>> to fix it. Unfortunately, while I’m still trying to find a solution, I
>> currently
>> don't have any other good ideas.
64 matches
Mail list logo
