On Fri, 10 Jan 2025, Alexandre Oliva wrote:
>
> There was a cut&pasto in the rr_and_mask's adjustment to match the
> combined type: the test on whether there was a mask already was
> testing the wrong variable, and then it might crash or otherwise fail
> accessing an undefined mask. This only hi
On Fri, 10 Jan 2025, Alexandre Oliva wrote:
>
> If fold_truth_andor_for_ifcombine applies a mask to an xor, say
> because the result of the xor is compared with a power of two [minus
> one], we have to apply the same mask when processing both the left-
> and right-hand xor paths for the transform
On Fri, 10 Jan 2025, Alexandre Oliva wrote:
>
> A narrowing conversion and a shift both drop bits from the loaded
> value, but we need to take into account which one comes first to get
> the right number of bits and mask.
>
> Fold when applying masks to parts, comparing the parts, and combining
On Thu, 9 Jan 2025, Robert Dubner wrote:
> I am going to trim back some of the older stuff.
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Tuesday, January 7, 2025 08:32
> > To: Robert Dubner
> > Cc: jklow...@symas.com; Joseph Myers ; gcc-
> > patc...@gcc.gnu.org
> > Subjec
Could you rebase and send the patch set again? I can't apply the patch set:
[kitoc@hsinchu18 gcc]$ git am
/tmp/git-pw8sm7zbop/RISC-V-Add-intrinsics-support-and-testcases-for-SiFive-Xsfvcp-extension..patch
Applying: RISC-V: Add intrinsics support for SiFive Xsfvcp extensions.
error: patch failed: g
There was a cut&pasto in the rr_and_mask's adjustment to match the
combined type: the test on whether there was a mask already was
testing the wrong variable, and then it might crash or otherwise fail
accessing an undefined mask. This only hit with checking enabled,
and rarely at that.
Regstrap
If fold_truth_andor_for_ifcombine applies a mask to an xor, say
because the result of the xor is compared with a power of two [minus
one], we have to apply the same mask when processing both the left-
and right-hand xor paths for the transformation to be sound. Arrange
for decode_field_reference
A narrowing conversion and a shift both drop bits from the loaded
value, but we need to take into account which one comes first to get
the right number of bits and mask.
Fold when applying masks to parts, comparing the parts, and combining
the results, in the odd chance either mask happens to be
dfp.exp sets the default to compile when dfprt is not available, but
some dfp bitint tests override the default without that requirement,
and try to run even when dfprt is not available.
Instead of overriding the default, rewrite the requirements so that
they apply even when compiling, since the
On Thu, Jan 09, 2025 at 05:41:07PM -0500, Patrick Palka wrote:
> On Fri, 10 Jan 2025, Nathaniel Shead wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/14?
>
> Nice approach, thanks for fixing this!
>
> >
> > -- >8 --
> >
> > In the linked testcase, an ICE occurs bec
Pushed to r15-6755.
在 2025/1/7 下午9:04, chenxiaolong 写道:
When analyzing 525 on LoongArch architecture, it was found that the
for loop of hotspot function x264_pixel_satd_8x4 could not be quantized
256-bit due to the cost of vec_construct setting. After re-adjusting
vec_construct, the performan
在 2025/1/10 上午10:03, Lulu Cheng 写道:
Pushed to r15-6755.
Sorry, I replied to the wrong email.
在 2025/1/6 下午4:16, mengqinggang 写道:
Generate 0x1010 instead of 0x101>>12 for lu12i.w. lu32i.d and
lu52i.d use
the same processing.
gcc/ChangeLog:
* config/loongarch/lasx.md: Use new loong
On Linux/x86_64,
fab96de044f1f023f52d43af866205d17d8895fb is the first bad commit
commit fab96de044f1f023f52d43af866205d17d8895fb
Author: Vladimir N. Makarov
Date: Thu Jan 9 16:22:02 2025 -0500
[PR118017][LRA]: Don't inherit reg of non-uniform reg class
caused
FAIL: gcc.target/i386/pr118
On 12/20/24 2:37 PM, Simon Martin wrote:
We currently fail due to "infinite recursion" on the following invalid
code with -std=c++20 and above
=== cut here ===
template struct S { struct U { const S s; } u; };
S t{2};
=== cut here ===
The problem is that reshape_init_class for S calls reshape_
On Thu, 2025-01-09 at 21:15 -0500, Jason Merrill wrote:
> On 1/9/25 7:00 PM, David Malcolm wrote:
> > On Thu, 2025-01-09 at 14:21 -0500, Jason Merrill wrote:
> >
> > Thanks for taking a look...
> >
> > > > On 1/9/25 2:11 PM, David Malcolm wrote:
> > > >
> > > > @@ -4743,7 +4769,38 @@ convert_arg
On 12/20/24 12:54 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK
-- >8 --
Here we ICE in expand_expr_real_1:
if (exp)
{
tree context = decl_function_context (exp);
gcc_assert (SCOPE_FILE_SCOPE_P (context)
Tested x86_64-pc-linux-gnu. Is the diagnostic.h change OK for trunk?
-- 8< --
To respect the #pragma diagnostic lines in libstdc++ headers when compiling
with module std, we need to represent them in the module.
I think it's reasonable to make module_state a friend of
diagnostic_option_classifi
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In std/ranges/concat/1.cc we end up instantiating
concat_view::iterator::operator-, which has nested generic lambdas, where
the innermost is all constexpr if. tsubst_lambda_expr propagates
the returns_* flags for generic lambdas since we mi
On 12/12/24 4:41 AM, Jakub Jelinek wrote:
Hi!
I believe we need to clear padding bits even in empty types when using
zero initialization,
https://eel.is/c++draft/dcl.init.general#6.2
doesn't have an exception for empty types.
I came to this when playing with an optimization for PR116416 to impro
On 12/19/24 1:38 PM, Jakub Jelinek wrote:
On Thu, Dec 19, 2024 at 11:44:54AM -0500, Jason Merrill wrote:
--- gcc/cp/call.cc.jj 2024-12-19 16:10:12.977071898 +0100
+++ gcc/cp/call.cc 2024-12-19 16:55:40.953546502 +0100
@@ -4386,7 +4386,13 @@ maybe_init_list_as_array (tree elttype,
if
On 12/20/24 4:24 AM, Jakub Jelinek wrote:
On Thu, Dec 19, 2024 at 07:01:39PM +0100, Jakub Jelinek wrote:
So far lightly tested, ok for trunk this way if it passes bootstrap & testing?
Bootstrap/regtest found an issue, warning about
if ()
for ()
if ()
else if ()
els
Generate 0x1010 instead of 0x101>>12 for lu12i.w. lu32i.d and lu52i.d use
the same processing.
gcc/ChangeLog:
* config/loongarch/lasx.md: Use new loongarch_output_move.
* config/loongarch/loongarch-protos.h (loongarch_output_move):
Change parameters from (rtx, rtx) to
On 1/7/25 2:48 PM, Jakub Jelinek wrote:
Hi!
With the following patch I actually get a simple namespace scope structured
binding working with modules.
The core_vals change ensure we actually save/restore DECL_VALUE_EXPR even
for namespace scope vars, the get_merge_kind is based on the assumption
On 1/8/25 9:19 AM, Jakub Jelinek wrote:
On Tue, Jan 07, 2025 at 03:20:35PM -0800, Andi Kleen wrote:
There is one case I didn't handle and I'd like to discuss.
The initial commit to enable this new extension also changed
cp_parser_asm_specification_opt to use cp_parser_asm_string_expression.
That
On 1/9/25 7:00 PM, David Malcolm wrote:
On Thu, 2025-01-09 at 14:21 -0500, Jason Merrill wrote:
Thanks for taking a look...
On 1/9/25 2:11 PM, David Malcolm wrote:
@@ -4743,7 +4769,38 @@ convert_arguments (tree typelist, vec **values, tree fndecl,
if (typetail && typetail != void_lis
Pushed to r15-6755.
在 2025/1/6 下午4:16, mengqinggang 写道:
Generate 0x1010 instead of 0x101>>12 for lu12i.w. lu32i.d and lu52i.d use
the same processing.
gcc/ChangeLog:
* config/loongarch/lasx.md: Use new loongarch_output_move.
* config/loongarch/loongarch-protos.h (loongarch_
Since there's regression to use vpermq, and it's manually disabled by
!TARGET_AVX512BW. I remove the codes related to vpermq and make
ix86_expand_vecop_qihi2 only handle vpmovbw + op + vpmovwb case.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready to push to trunk.
gcc/ChangeLog:
On Thu, 2025-01-09 at 14:21 -0500, Jason Merrill wrote:
Thanks for taking a look...
> > On 1/9/25 2:11 PM, David Malcolm wrote:
> >
> > @@ -4743,7 +4769,38 @@ convert_arguments (tree typelist, vec > va_gc> **values, tree fndecl,
> > if (typetail && typetail != void_list_node)
> > {
>
Hi All,
The Parts Num field for the MIDR for Cortex-X4 is wrong. It's currently the
parts number for a Cortex-A720 (which does have the right number).
The correct number can be found in the Cortex-X4 Technical Reference Manual [1]
on page 382 in Issue Number 5.
[1] https://developer.arm.com/doc
Akram Ahmad writes:
> Hi Kyrill,
>
> Thanks for the feedback on V2. I found a pattern which works for
> the open-coded signed arithmetic, and I've implemented the other
> feedback you provided as well.
>
> I've send the modified patch in this thread as the SVE patch [2/2]
> hasn't been changed, bu
On Fri, 10 Jan 2025, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/14?
Nice approach, thanks for fixing this!
>
> -- >8 --
>
> In the linked testcase, an ICE occurs because when reading the
> (duplicate) function definition for _M_do_parse from module
Thanks! Committed.
Edwin
On 1/9/2025 1:04 PM, Jeff Law wrote:
On 1/9/25 11:33 AM, Edwin Lu wrote:
The effective-target selector for riscv on sync_char_short did not
check to see if atomics were enabled. As a result, these test cases were
ran on targets without the a extension. Add additional
Hi,
Sorry for the slow reply.
I ran the numbers filliping the probabilities. Most of it was in the noise and
not statistically relevant.
However there were some outliers:
+---+---+---+---++
| benchmark | container | Type | Size | difference
On 1/9/25 8:25 AM, Simon Martin wrote:
We segfault upon the following invalid code
=== cut here ===
template struct S {
friend void foo (int a = []{}());
};
void foo (int a) {}
int main () {
S<0> t;
foo ();
}
=== cut here ===
The problem is that we end up with a LAMBDA_EXPR callee in
On 1/9/25 9:31 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/14?
OK.
-- >8 --
In the linked testcase, an ICE occurs because when reading the
(duplicate) function definition for _M_do_parse from module Y, the local
type definitions have already bee
Changes since v1:
- Added dg-add-options arm_arch_v5te_thumb
- Added -std=c17 to dg-options.
- Removed -march=armv5te -mfloat-abi=soft -mthumb from dg-options
- Updated the commit message to reflect the new changes
Note: This changes from armv5te to armv5te+fp and from soft to softfp.
Does this m
On 2025-01-09 12:42, Richard Earnshaw (lists) wrote:
On 22/12/2024 15:27, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
When the test was initially created, -fcommon was the default, but in
commit r10-4867-g6271dd984d7 the default value changed to -fno-common.
This change ma
The patch in the attachment solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118017
The patch was successfully bootstrapped and tested on x86-64 and aarch64.
commit 6ffaed8d8713874b7c4ee112249ed8a91ff9
Author: Vladimir N. Makarov
Date: Thu Jan 9 16:22:02 2025 -0500
[PR118017][LRA
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
r15-3532 made us more strict about exception-specification mismatches with
the standard library, but let's still be permissive about operator new,
since previously you needed to say throw(std::bad_alloc).
gcc/cp/ChangeLog:
* decl.c
On 2025-01-09 12:56, Richard Earnshaw (lists) wrote:
On 27/12/2024 17:01, Torbjörn SVENSSON wrote:
Ok for trunk?
--
This change will enforce that the expected instructions are generated
per function rather than allowing some other function to use the
expected instructions.
gcc/testsuite/Ch
While writing the summary for my push of r15-6745-g794f6721e0e, I
noticed the following typo.
Pushed this patch as obivous.
--
gcc/testsuite/ChangeLog:
* gcc.target/arm/armv8_2-fp16-conv-1.c: Fix typo.
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/gcc.target/arm/armv8_2-fp16-con
On 1/9/25 11:33 AM, Edwin Lu wrote:
The effective-target selector for riscv on sync_char_short did not
check to see if atomics were enabled. As a result, these test cases were
ran on targets without the a extension. Add additional checks for zalrsc
or zabha extensions.
gcc/testsuite/ChangeLog
On Thu, Jan 09, 2025 at 07:21:53PM +0100, Jakub Jelinek wrote:
> On Thu, Jan 09, 2025 at 01:29:27PM +0100, Stefan Schulze Frielinghaus wrote:
> > Optimization s390_constant_via_vgbm_p() should only apply to constant
> > vectors which can be expressed by the hardware, i.e., which have a size
> > of
> On Jan 9, 2025, at 14:10, Jeff Law wrote:
>
>
>
> On 1/9/25 10:48 AM, Qing Zhao wrote:
>
>>>
>>> I think Jeff's patch is not reasonable since it boils down to not diagnose
>>> -Warray-bounds but instead remove those stmts.
>> If these stmts are dead-code that are generated by compiler op
I am going to trim back some of the older stuff.
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, January 7, 2025 08:32
> To: Robert Dubner
> Cc: jklow...@symas.com; Joseph Myers ; gcc-
> patc...@gcc.gnu.org
> Subject: RE: [PATCH] COBOL 3/8 gen: GENERIC interface
>
> On Mon,
I spent way too long poking at various adjustments of this; here's what I
settled on for GCC 15.
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
When the program requests a conversion to a typedef, let's try harder to
remember the new name.
Torbjörn's original patch changed the type of
On 1/9/25 2:11 PM, David Malcolm wrote:
Here's v2 of the patch. I only changed the C++ parts, for the nits
identified by Marek. I didn't attempt to add coverage for the objc++
method stuff.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Are the C++ parts OK for trunk? (Joseph
Here's v2 of the patch. I only changed the C++ parts, for the nits
identified by Marek. I didn't attempt to add coverage for the objc++
method stuff.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Are the C++ parts OK for trunk? (Joseph already approved the C parts)
Thanks
Dave
On 1/9/25 10:48 AM, Qing Zhao wrote:
I think Jeff's patch is not reasonable since it boils down to not diagnose
-Warray-bounds but instead remove those stmts.
If these stmts are dead-code that are generated by compiler optimization (NOT
from source code),
removing them before diagnosis is
On 9 Jan 2025, at 20:00, Marek Polacek wrote:
> On Thu, Jan 09, 2025 at 12:05:43PM -0500, Patrick Palka wrote:
>> On Wed, 8 Jan 2025, Jason Merrill wrote:
>>
>>> On 12/21/24 11:35 AM, Simon Martin wrote:
When erroring out due to an incomplete type, we add a contextual
note
about th
On Thu, Jan 09, 2025 at 12:05:43PM -0500, Patrick Palka wrote:
> On Wed, 8 Jan 2025, Jason Merrill wrote:
>
> > On 12/21/24 11:35 AM, Simon Martin wrote:
> > > When erroring out due to an incomplete type, we add a contextual note
> > > about the type. However, when the error is suppressed by
> > >
The effective-target selector for riscv on sync_char_short did not
check to see if atomics were enabled. As a result, these test cases were
ran on targets without the a extension. Add additional checks for zalrsc
or zabha extensions.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Fix
The test case uses a nested function, which is not supported by some
targets.
This fixes a spurious error for pru-unknown-elf, where nested functions
are not supported. Pushed to trunk as obvious.
gcc/testsuite/ChangeLog:
* gcc.dg/pr118325.c: Require effective target trampolines.
Signe
On Thu, Jan 09, 2025 at 01:29:27PM +0100, Stefan Schulze Frielinghaus wrote:
> Optimization s390_constant_via_vgbm_p() should only apply to constant
> vectors which can be expressed by the hardware, i.e., which have a size
> of at most 16-bytes, similar as it is done for s390_constant_via_vgm_p()
>
Ping patch to fix PR target/117251, Add PowerPC XXEVAL support for fusion
optimization in power10
Message-ID
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669138.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
Ping patch for PR target/108958, Use mtvsrdd to zero extend GPR DImode to VSX
TImode
Message-ID
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669242.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
Ping patch to fix PR target/117487, Add power9/power10 float to logical
operations
Message-ID
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669137.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
Ping patches 1-2 to separate PowerPC ISA bits from architecture bits set by
-mcpu=.
Message-ID
Explanation of the patch set:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669108.html
Patch #1, add rs6000 architecture masks:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/66910
Ping patch to fix PR target/99293, Optimize splat of a V2DF/V2DI extract with
constant element:
Message-ID
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669136.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
Ping patch to not allow -mvsx to boost the cpu to power7
Message-ID
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669106.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
Ping patches 1-4 to add support for -mcpu=future in the PowerPC
Message-ID
Information about the patch set:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669099.html
Patch #1, Add support for -mcpu=future in the PowerPC
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669101.ht
Ping patches 1-5 to Add more user friendly TARGET_ names for PowerPC:
Message-ID
Information for patch set:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669067.html
Patch #1, Change TARGET_POPCNTB to TARGET_POWER5:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669068.html
Richard Sandiford writes:
> Andrew Carlotti writes:
>> On Mon, Nov 25, 2024 at 11:26:39PM +, Richard Sandiford wrote:
>>> Sorry for the slow review.
>>>
>>> Andrew Carlotti writes:
>>> > These new flags (+fcma, +jscvt, +rcpc2, +jscvt, +frintts, +wfxt and +xs)
>>> > were only recently added
> On Jan 9, 2025, at 03:17, Sam James wrote:
>
> Richard Biener writes:
>
>> On Wed, Jan 8, 2025 at 5:34 PM Qing Zhao wrote:
>>>
>>>
>>>
On Jan 7, 2025, at 07:29, Richard Biener
wrote:
On Mon, Jan 6, 2025 at 5:40 PM Qing Zhao wrote:
>
>
>
>> On J
> On Jan 9, 2025, at 03:08, Richard Biener wrote:
>
> On Wed, Jan 8, 2025 at 5:34 PM Qing Zhao wrote:
>>
>>
>>
>>> On Jan 7, 2025, at 07:29, Richard Biener wrote:
>>>
>>> On Mon, Jan 6, 2025 at 5:40 PM Qing Zhao wrote:
> On Jan 6, 2025, at 11:01, Richard Biener
>>
On 1/9/25 12:05 PM, Patrick Palka wrote:
On Wed, 8 Jan 2025, Jason Merrill wrote:
On 12/21/24 11:35 AM, Simon Martin wrote:
When erroring out due to an incomplete type, we add a contextual note
about the type. However, when the error is suppressed by
-Wno-template-body, the note remains, makin
Le 09/01/2025 à 18:12, Andre Vehreschild a écrit :
Hi Jakub,
Yes, that is what I had in mind. Being German I don't see any problem with the
explanation, but that is better judged by a native English speaker.
Is the send patch hunk intentional where only indentation is changed? I haven't
applied
On 9 Jan 2025, at 18:05, Patrick Palka wrote:
> On Wed, 8 Jan 2025, Jason Merrill wrote:
>
>> On 12/21/24 11:35 AM, Simon Martin wrote:
>>> When erroring out due to an incomplete type, we add a contextual
>>> note
>>> about the type. However, when the error is suppressed by
>>> -Wno-template-body
On Thu, Jan 09, 2025 at 06:12:51PM +0100, Andre Vehreschild wrote:
> Yes, that is what I had in mind. Being German I don't see any problem with the
> explanation, but that is better judged by a native English speaker.
>
> Is the send patch hunk intentional where only indentation is changed? I
> h
Hi Jakub,
Yes, that is what I had in mind. Being German I don't see any problem with the
explanation, but that is better judged by a native English speaker.
Is the send patch hunk intentional where only indentation is changed? I haven't
applied it though.
Thanks for the patch,
Andre
On
On Wed, 8 Jan 2025, Jason Merrill wrote:
> On 12/21/24 11:35 AM, Simon Martin wrote:
> > When erroring out due to an incomplete type, we add a contextual note
> > about the type. However, when the error is suppressed by
> > -Wno-template-body, the note remains, making the compiler output quite
> >
> Hi,
>
> PR 118138 and quite a few duplicates that it has acquired in a short
> time show that even though we are careful to make sure we do not loose
> any bits when newly allowing type conversions in jump-functions, we
> still need to perform the fold conversions during IPA constant
> propagati
> -Original Message-
> From: Richard Sandiford
> Sent: Thursday, January 9, 2025 3:09 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; ktkac...@gcc.gnu.org
> Subject: Re: [PATCH]AArch64: Fix costing of emulated gathers/scatters
> [PR118188]
>
> Tamar Chri
On Thu, Jan 09, 2025 at 03:28:28PM +0100, Jakub Jelinek wrote:
> So like this?
Thomas mentioned bad wording in a private mail. Here is a better patch:
2025-01-09 Jakub Jelinek
PR fortran/118337
* module.cc (use_iso_fortran_env_module): Add a comment explaining
the opt
Ping
On 02/12/24 2:20 pm, Surya Kumari Jangala wrote:
> I have incorporated review comments in this patch.
>
> Regards,
> Surya
>
>
> rs6000: Inefficient vector splat of small V2DI constants [PR107757]
>
> On P8, for vector splat of double word constants, specifically -1 and 1,
> gcc generates
On 09/01/2025 14:50, Christophe Lyon wrote:
> The previous fix only worked for C, for C++ we need to add more
> information to the underlying type so that
> finish_class_member_access_expr accepts it.
>
> We use the same logic as in aarch64's register_tuple_type for AdvSIMD
> tuples.
>
> This pat
Hello,
On Wed, 13 Nov 2024, Michael Matz wrote:
> Hello,
>
> this is essentially
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651025.html
>
> from Kewen in functionality. When discussing this with Segher at the
> Cauldron he expressed reservations about changing the default
> i
Tamar Christina writes:
>> > + After the final loads are done it issues a
>> > + vec_construct to recreate the vector from the scalar. For costing
>> > when
>> > + we see a vec_to_scalar on a stmt with VMAT_GATHER_SCATTER we are
>> dealing
>> > + with an emulated instruction and
The previous fix only worked for C, for C++ we need to add more
information to the underlying type so that
finish_class_member_access_expr accepts it.
We use the same logic as in aarch64's register_tuple_type for AdvSIMD
tuples.
This patch makes gcc.target/arm/mve/intrinsics/pr118332.c pass in C+
Wilco Dijkstra writes:
> Hi Richard,
>
>> The patch below is what I meant. It passes bootstrap & regression-test
>> on aarch64-linux-gnu (and so produces the same results for the tests
>> that you changed). Do you see any problems with this version?
>> If not, I think we should go with it.
>
> T
On 1/8/25 4:14 PM, H.J. Lu wrote:
On Thu, Jan 9, 2025 at 5:35 AM Jeff Law wrote:
On 1/8/25 1:53 PM, H.J. Lu wrote:
Skip extension on stack pointer since we can't turn
(insn 27 26 139 2 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/14?
-- >8 --
In the linked testcase, an ICE occurs because when reading the
(duplicate) function definition for _M_do_parse from module Y, the local
type definitions have already been streamed from module X and setup as
regular backr
On Thu, Jan 09, 2025 at 11:32:35AM +0100, Andre Vehreschild wrote:
> I am sorry, I don't get it. So we are trying to help the compiler, i.e. the
> C++
> one, to create a fast gfortran binary. But we don't care about devs that
> stumble
> about the code and ask themselves, "Why is this done (witho
Am 09.01.25 um 14:45 schrieb Andre Vehreschild:
You forgot to add the patch!
Sent two minutes later :-)
https://gcc.gnu.org/pipermail/fortran/2025-January/061540.html
On Thu, 9 Jan 2025 at 12:25, Richard Earnshaw (lists)
wrote:
>
> On 09/01/2025 08:58, Christophe Lyon wrote:
> > OK for gcc-14?
> >
> > This backport is a cherry pick of commit
> > 2089009210a1774c37e527ead8bbcaaa1a7a9d2d, with a small change needed
> > because force_lowpart_subreg does not exist
You forgot to add the patch!
On Thu, 9 Jan 2025 14:34:50 +0100
Thomas Koenig wrote:
> Hello world,
>
> This patch fixes and reorganizes dumping C prototypes. It makes the
> following changes:
>
> - BIND(C) types are now always output before any global symbols
> - CFI_cdesc_t is issu
Am 09.01.25 um 14:34 schrieb Thomas Koenig:
This patch fixes and reorganizes dumping C prototypes.
And here is the "five seconds later, I realized I had forgotten
to attach the patch" e-mail...
diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 8d31ddfcffb..826f
Hi!
On 2024-12-03T12:32:35-0700, Jeff Law wrote:
> Jakub noted that these tests were using dg-skip-if directives that
> implied the tests were expected to run under multiple optimization
> options, which means they probably should be in gcc.dg/torture rather
> than in the gcc.dg directory.
>
>
Hello world,
This patch fixes and reorganizes dumping C prototypes. It makes the
following changes:
- BIND(C) types are now always output before any global symbols
- CFI_cdesc_t is issued for assumed shape and assumed rank arguments.
- BIND(C,NAME="...") entities were no
We segfault upon the following invalid code
=== cut here ===
template struct S {
friend void foo (int a = []{}());
};
void foo (int a) {}
int main () {
S<0> t;
foo ();
}
=== cut here ===
The problem is that we end up with a LAMBDA_EXPR callee in
set_flags_from_callee, and dereference its N
Hi!
On 2024-09-20T18:49:46+0200, I wrote:
> We'd like to raise nvptx code generation from PTX ISA 6.0, sm_30 "Kepler"
> to default PTX ISA 7.3, sm_52 "Maxwell", therefore CUDA 11.3 (2021-04).
> This is, primarily, so that we're able to use 'alloca' and related stack
> manipulation instructions, an
This patch adds a warning when FMV is used for Aarch64.
The reasoning for this is the ACLE [1] spec for FMV has diverged
significantly from the current implementation and we want to prevent
potential future compatability issues.
There is a patch for an ACLE compliant version of target_version an
On Sat, Dec 21, 2024 at 6:05 AM Alexandre Oliva wrote:
>
> On Dec 20, 2024, Jakub Jelinek wrote:
>
> > On Wed, Dec 18, 2024 at 12:59:11AM -0300, Alexandre Oliva wrote:
> >> * gcc.dg/field-merge-16.c: New.
>
> > Note the test FAILs on i686-linux or on x86_64-linux with -m32.
>
> Indeed, thanks. H
On 20/12/2024 22:53, Christophe Lyon wrote:
> Commit r15-6389-g670df03e5294a3 only partially fixed support for moves
> of large modes: despite the introduction of V2x* and V4x* modes in
> r15-6245-g4f4e13dd235b to support MVE tuples, we still need to support
> TI, OI and XI modes, which appear for
On Mon, Jan 6, 2025 at 2:12 PM Richard Sandiford
wrote:
>
> g:d882fe5150fbbeb4e44d007bb4964e5b22373021, posted at
> https://gcc.gnu.org/pipermail/gcc-patches/2000-July/033786.html ,
> added code to treat:
>
> (set (reg:CC cc) (compare:CC (gt:M (reg:CC cc) 0) (lt:M (reg:CC cc) 0)))
>
> as a nop.
When we have the situation of an external SLP node that is
permuted the scalar stmts recorded in the permute node do not
mean the scalar computation can be removed. We are removing
those stmts from the vectorized_scalar_stmts for this reason
but we fail to check this set when we cost scalar stmts.
duplicate_loop_body_to_header_edge redirects the original loop entry
edge to the loop copy header and the copied loop exit to the old
loop header. But it does so in the order that requires temporary
space for an extra edge on the original loop header, causing
unnecessary re-allocations. The follo
Hi Kyrylo,
(resending due to missing CC)
On 09/01/2025 10:41, Kyrylo Tkachov wrote:
diff --git a/gcc/config/aarch64/aarch64.cc
b/gcc/config/aarch64/aarch64.cc
index 91de13159cb..afc0749fd67 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -20347,6 +20347,9 @@ a
From: Eric Botcazou
The RM 4.5.5(19.1/2) subclause says that the predefined multiply operator
for universal_fixed is still available, despite the declaration of a user-
defined primitive multiply operator for the fixed-point type at stake, if
it is identified using an expanded name with prefix de
From: Eric Botcazou
In Ada 2012, the compiler fails to check that a primitive equality operator
for an untagged record type must appear before the type is frozen, when the
operator returns a subtype of Boolean. This plugs the legality loophole but
adds the debug switch -gnatd_q to go back to the
1 - 100 of 125 matches
Mail list logo
