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
> >>> wrote:
> >>>
> >>> On Mon, Jan 6, 2025 at 3:43 PM Qing Zhao wro
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 Jan 6, 2025, at 11:01, Richard Biener
>> >>> wrote:
>> >>>
>> >>>
From: Javier Miranda
Avoid reporting spurious errors.
gcc/ada/ChangeLog:
* freeze.adb (Freeze_Expr_Types): Reverse patch; that is, restore
calls to Preanalyze_Spec_Expression instead of Preanalyze_And_Resolve
for the sake of consistency with Analyze_Expression_Function.
From: squirek
This patch fixes an issue in the compiler whereby instantiating Multiway_Trees
with a formal type leads to a compile-time error due to the expression supplied
for aspect Disable_Controlled specified on types decalred within
Multiway_Trees' body not being static.
gcc/ada/ChangeLog:
On Thu, Jan 9, 2025 at 9:08 AM 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, Ri
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
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 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
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:
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_
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
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
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)
> > {
>
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
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 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
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 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
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
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
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
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
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)
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
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 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
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
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
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
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/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
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 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
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
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
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
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
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/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
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
在 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
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
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
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 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.
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 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
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
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
> 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 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
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 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
> 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
>>
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
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
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
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 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 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/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 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/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
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()
>
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, 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:45 schrieb Andre Vehreschild:
You forgot to add the patch!
Sent two minutes later :-)
https://gcc.gnu.org/pipermail/fortran/2025-January/061540.html
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
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
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 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:
>
> 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 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)
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
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+
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
在 2025/1/8 下午11:16, Xi Ruoyao 写道:
On Tue, 2025-01-07 at 10:44 +0800, Lulu Cheng wrote:
After changing this cost from 1 to 3, the performance of spec2006
401 473 416 465 482 can be improved by about 2% on LA664.
Would this fix https://gcc.gnu.org/PR114978 (or at least make it
latent)?
The co
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.
Thanks for the detailed example - u
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 in gcc-14: the patch
replaces it with the equivalent:
-x = force_lowpart_subreg (mode, x, GET_MODE (x));
+{
+ auto
On 08/01/2025 18:54, 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.
>
> This patch makes gcc.target/arm/mve/intrinsics/pr118332.c pass in C++
> mode.
>
> gcc/Change
On Thu, Jan 09, 2025 at 01:17:24PM +0100, Tobias Burnus wrote:
> A case where 'omp error' diagnostic should be delayed - and (here) suppressed:
>
> program_control/sources/error.1.c:15:23: error: ‘pragma omp error’
> encountered: GNU compiler required.
>15 | otherwise(error at(com
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
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
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
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
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.
This patch adds a warning whenever 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
future compatability issues.
There is a patch for and ACLE compliant version of target_version and
targ
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
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
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
Hi Mikael,
merged only patch #2 as gcc-15-6729-gd1071402055.
Thanks for the ok and regards,
Andre
On Wed, 8 Jan 2025 22:46:15 +0100
Mikael Morin wrote:
> Le 08/01/2025 à 18:23, Andre Vehreschild a écrit :
> >
> > First of all the recursive attr must not be set on vtypes, neither on m
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 in gcc-14: the patch
> replaces it with the equivalent:
>
> -x = force
Hi all,
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 (without a comment) so
oddly?"! Furthermore is the code again using conventi
Hi Alfie,
> On 9 Jan 2025, at 10:58, alfie.richa...@arm.com wrote:
>
> This patch adds a warning whenever 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
> future compatability is
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/ChangeLog:
>
> * gcc.target/arm/armv
Hi Jason,
On 8 Jan 2025, at 22:56, 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 out
Hi Sandra,
I had a first glance at your patch, albeit very superficial. I found one
issue reading the code - and observed some issues when running it against
some existing external tests.
I will have a deeper looker later, will now first do another iteration
on your main/middle-end patch #2, whi
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()
and s390_constant_via_vrepi_p().
gcc/ChangeLog:
PR target/118362
*
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
1 - 100 of 125 matches
Mail list logo
