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/aarch64-simd.md (aarch64_simd_vec_se
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-linux-gnu.
gcc/testsuite/ChangeLog:
The sibling and unshare passes were dropped as distinct passes 10+ years
ago. Docs weren't ever updated. This just removes them; given their
age I don't think we need to keep them around any longer.
Pushing to the trunk.
Jeffcommit 3e93035fcc9247928b58443e37fbf844278b7ac7
Author: Jeff Law
LGTM!
Thanks!
在 2025/2/14 下午9:37, Xi Ruoyao 写道:
Allowing (t + (1ul << imm >> 1)) >> imm to be recognized as a rounding
shift operation.
gcc/ChangeLog:
* config/loongarch/lasx.md (UNSPEC_LASX_XVSRARI): Remove.
(UNSPEC_LASX_XVSRLRI): Remove.
(lasx_xvsrari_): Remove.
This patch optimizes certain vector permute expansion with the FMOV instruction
when one of the input vectors is a vector of all zeros and the result of the
vector permute is as if the upper lane of the non-zero input vector is set to
zero and the lower lane remains unchanged.
Note that the patch
Compared to v1, I've added a new function aarch64_get_required_features to
avoid having to pass a long list of explicit features. I also changed
aarch64_target_switcher to only disable TARGET_GENERAL_REGS_ONLY if the
requested flags include FP, to address Richard's comment.
Bootstrapped and regre
From: Andi Kleen
The file-cache-lines / file-cache-files tunables were documented in the
wrong section. Fix that.
Reported-by: Filip Kastl
Comitted as obvious.
gcc/ChangeLog:
* doc/invoke.texi:
---
gcc/doc/invoke.texi | 20 ++--
1 file changed, 10 insertions(+), 10 de
>From f89a50238de62b73d9fc44ee7226461650ab119d Tue 18 Feb 2025 04:19:10 PM EST
From: "James K. Lowden"
Date: Tue 18 Feb 2025 04:19:10 PM EST
Subject: [PATCH] COBOL 3/14 80K bld: config and build machinery
ChangeLog
* Makefile.def: Add libgcobol module and cobol language.
* Makefi
>From f89a50238de62b73d9fc44ee7226461650ab119d Tue 18 Feb 2025 04:19:10 PM EST
From: "James K. Lowden"
Date: Tue 18 Feb 2025 04:19:10 PM EST
Subject: [PATCH] COBOL 2/14 8.0K pre: introduce ChangeLog files
gcc/cobol/ChangeLog
* ChangeLog: New file.
libgcobol/ChangeLog
* /ChangeLo
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 directories
2/14 8K pre: introduce ChangeLog files
3/14 80K bld: config
Hi all,
This is a reimplementation of Windows Thread Local Storage, rewritten to
support native thread local access on Windows, which had previous been using
emulated thread local storage mechanisms. Note that due to issues on my end, I
was unable to regenerate configure no matter what I tried.
On Tue, Feb 18, 2025 at 10:52 PM James K. Lowden
wrote:
>
> From f89a50238de62b73d9fc44ee7226461650ab119d Tue 18 Feb 2025 04:19:11 PM EST
> From: "James K. Lowden"
> Date: Tue 18 Feb 2025 04:19:11 PM EST
> Subject: [PATCH] COBOL 8/14 516K api: GENERIC interface
A few comments about this:
> +st
在 2025/2/19 下午3:27, Xi Ruoyao 写道:
On Wed, 2025-02-05 at 08:57 +0800, Xi Ruoyao wrote:
Like RISC-V, on LoongArch we don't really support %cN for SYMBOL_REFs
even with -fno-pic.
gcc/testsuite/ChangeLog:
* c-c++-common/toplevel-asm-1.c: Use %cc3 %cc4 instead of %c3
%c4 on LoongA
The issue described in PR80681 highlights a problem that:
g++'s -Wuninitialized option does not warn when a privately inherited
base class contains public const data or reference members, and the
derived class does not have a user-provided constructor.
Similarly, the same issue occurs when the pri
On Wed, 2025-02-05 at 08:57 +0800, Xi Ruoyao wrote:
> Like RISC-V, on LoongArch we don't really support %cN for SYMBOL_REFs
> even with -fno-pic.
>
> gcc/testsuite/ChangeLog:
>
> * c-c++-common/toplevel-asm-1.c: Use %cc3 %cc4 instead of %c3
> %c4 on LoongArch.
> ---
>
> Ok for trunk?
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_else and concluded that the expressions
in the "then" and "else" branche
> Pengxuan Zheng writes:
> > This patch optimizes certain vector permute expansion with the FMOV
> > instruction when one of the input vectors is a vector of all zeros and
> > the result of the vector permute is as if the upper lane of the
> > non-zero input vector is set to zero and the lower lan
On Tue, 18 Feb 2025 13:48:02 -0700, Jeff Law wrote:
>
>
> On 2/18/25 4:12 AM, Jin Ma wrote:
> > We overlooked the side effects of the rounding mode in the pattern,
> > which can impact the result of float_extend and lead to incorrect
> > optimizations in the final program. This issue likely affec
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 │ for (; b; ++b) {
7 │ f = 5 >> a ? d : d << a;
8 │ e &= c
>From f89a50238de62b73d9fc44ee7226461650ab119d Tue 18 Feb 2025 04:19:12 PM EST
From: "James K. Lowden"
Date: Tue 18 Feb 2025 04:19:12 PM EST
Subject: [PATCH] COBOL 10/14 72K doc: man pages and GnuCOBOL emulation
gcc/cobol/ChangeLog
* gcobc: New file.
* gcobol.1: New file.
>From f89a50238de62b73d9fc44ee7226461650ab119d Tue 18 Feb 2025 04:19:09 PM EST
From: "James K. Lowden"
Date: Tue 18 Feb 2025 04:19:09 PM EST
Subject: [PATCH] COBOL 1/14 4.0K dir: create gcc/cobol and libgcobol
directories
contrib/gcc-changelog/ChangeLog
* contrib/gcc-changelog/git_commi
>From f89a50238de62b73d9fc44ee7226461650ab119d Tue 18 Feb 2025 04:19:13 PM EST
From: "James K. Lowden"
Date: Tue 18 Feb 2025 04:19:13 PM EST
Subject: [PATCH] COBOL 11/14 84K lhd: libgcobol header files
libgcobol/ChangeLog
* /charmaps.h: New file.
* /common-defs.h: New file.
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 Chinese (simplified) team of translators. The file is available at:
https://translationproject.org/latest/cpplib/zh_CN.po
(This file, 'cpp
cpplib-15-b20250216.zh_CN.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
> > Pengxuan Zheng writes:
> > > This patch optimizes certain vector permute expansion with the FMOV
> > > instruction when one of the input vectors is a vector of all zeros
> > > and the result of the vector permute is as if the upper lane of the
> > > non-zero input vector is set to zero and the
This patch optimizes certain vector permute expansion with the FMOV instruction
when one of the input vectors is a vector of all zeros and the result of the
vector permute is as if the upper lane of the non-zero input vector is set to
zero and the lower lane remains unchanged.
Note that the patch
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, including
> redeclaration, and mixing target_clones and
Am 18.02.25 um 16:00 schrieb Andre Vehreschild:
Hi Thomas,
This patch series (of necessity) introduces ABI changes. What will
happen with user code compiled against the old interface?
That depends on the library you are linking against. When using caf_single from
gfortran, then you will get
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to .)
A new POT file for textual domain 'gcc' has been made available
to the language teams for translation. It is archived as:
https://translationproject.org/POT-files/gcc
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to .)
A new POT file for textual domain 'cpplib' has been made available
to the language teams for translation. It is archived as:
https://translationproject.org/POT-files/
On Fri, Feb 14, 2025 at 11:21:07AM +0100, Jakub Jelinek wrote:
> On Thu, Feb 13, 2025 at 02:10:25PM +0100, Jakub Jelinek wrote:
> > Kees, are you submitting this under assignment to FSF (maybe the Google one
> > if it has one) or DCO? See https://gcc.gnu.org/contribute.html#legal
> > for details.
cpplib-15-b20250216.uk.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
Andrew Carlotti writes:
> When initialising intrinsics with `#pragma GCC aarch64 "arm_*.h"`, we
> often set an explicit target, but currently leave current_target_pragma
> unchanged. This results in the target pragma being applied to each
> simulated intrinsic on top of our explicit target, which
From: kelefth
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 the store instructions caused an error, as it was
no longer
Fixes PR testsuite/116986. Tested on hppa-unknown-linux-gnu and
hppa64-hp-hpux11.11.
Committed to trunk.
Dave
---
testsuite: Include stdint.h instead of stdint-gcc.h in some tests
When use_gcc_stdint=provide, the stdint-gcc.h header is not provided.
2025-02-18 John David Anglin
gcc/testsu
Alfie Richards writes:
> On 18/02/2025 12:11, Richard Sandiford wrote:
>> Alfie Richards writes:
>>> This changes function version structures to maintain the default version
>>> as the first declaration in the linked data structures by giving priority
>>> to the set containing the default when co
As just agreed in the patchwork meeting let's defer that to stage 1
unless somebody really has a need for better dynamic LMUL right now.
--
Regards
Robin
We can avoid the setpsw instructions when len is a known constant.
When len is zero, the insn result is zero. When len is non-zero,
the scmpu instructions will set the flags correctly.
Signed-off-by: Keith Packard
---
gcc/config/rx/rx.md | 19 ---
1 file changed, 16 insertions(+)
> On 18 Feb 2025, at 2:27 PM, Kyrylo Tkachov wrote:
>
>
>
>> On 18 Feb 2025, at 09:48, Kyrylo Tkachov wrote:
>>
>>
>>
>>> On 18 Feb 2025, at 09:41, Richard Sandiford
>>> wrote:
>>>
>>> Kyrylo Tkachov writes:
Hi Soumya
> On 18 Feb 2025, at 09:12, Soumya AR wrote:
>
As discussed in
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675978.html
this tweaks the dump messasge added with the fix for PR118320 since it doesn't
just apply to load pairs.
Tested on aarch64-linux-gnu, pushed to trunk.
Alex
gcc/ChangeLog:
PR rtl-optimization/118320
Alex Coplan writes:
> On 17/02/2025 16:15, Richard Sandiford wrote:
>> Alex Coplan writes:
>> >> @@ -588,6 +590,10 @@ latest_hazard_before (insn_info *insn, rtx *ignore,
>> >>&& find_reg_note (insn->rtl (), REG_EH_REGION, NULL_RTX))
>> >> return insn->prev_nondebug_insn ();
>> >>
>
On 18/02/2025 12:11, Richard Sandiford wrote:
Alfie Richards writes:
This changes function version structures to maintain the default version
as the first declaration in the linked data structures by giving priority
to the set containing the default when constructing the structure.
This allows
On Tue, Feb 18, 2025 at 1:54 PM Peter0x44 wrote:
>
> 18 Feb 2025 8:51:16 am Richard Biener :
>
> > On Tue, Feb 18, 2025 at 1:21 AM Sam James wrote:
> >>
> >> Peter Damianov writes:
> >>
> >>> POSIX says that sin and cos should set errno to EDOM when infinity is
> >>> passed to
> >>> them. Make s
Thanks Richard.
> so the obvious fix would be to add
>
> if (!VECTOR_MODE_P (loop_vinfo->vector_mode))
>return false;
I also think of it, but it is too "easy" and then dropped.
> Ah, it needs -march=rv64imd_xsfvcp.
It can also be reproduced by " -march=rv64imd_zve32x -mrvv-vector-bits=zv
Alfie Richards writes:
> This changes function version structures to maintain the default version
> as the first declaration in the linked data structures by giving priority
> to the set containing the default when constructing the structure.
>
> This allows for removing logic for moving the defau
A checking assert triggers upon the following invalid code since
GCC 11:
=== cut here ===
class { a (struct b;
} struct b
=== cut here ===
The problem is that during error recovery, we call
set_identifier_type_value_with_scope for B in the global namespace, and
the checking assert added via r11-7
Alfie Richards writes:
> This is a reimplementation of get_target_clone_attr_len,
> get_attr_str, and separate_attrs using string_slice and auto_vec to make
> memory management and use simpler.
>
> gcc/c-family/ChangeLog:
>
> * c-attribs.cc (handle_target_clones_attribute): Change to use
>
On Tue, 18 Feb 2025 at 13:49, Richard Earnshaw (lists)
wrote:
>
> On 18/02/2025 08:37, Christophe Lyon wrote:
> > As discussed in the PR, removing the inner 'fix:HF/SD/DF' fixes the
> > problem, like other targets do.
> >
>
> The double-'fix' idiom was introduced in
> https://gcc.gnu.org/pipermai
Alfie Richards writes:
> diff --git a/gcc/attribs.cc b/gcc/attribs.cc
> index b00d9529a8d..d0f37d77098 100644
> --- a/gcc/attribs.cc
> +++ b/gcc/attribs.cc
> [...]
> @@ -1287,6 +1282,33 @@ make_dispatcher_decl (const tree decl)
>DECL_EXTERNAL (func_decl) = 1;
>/* This will be of type IFUNC
On 2/18/25 4:12 AM, Jin Ma wrote:
We overlooked the side effects of the rounding mode in the pattern,
which can impact the result of float_extend and lead to incorrect
optimizations in the final program. This issue likely affects nearly
all similar patterns that involve rounding modes, and the
On Tue, Feb 18, 2025 at 8:26 PM Uros Bizjak wrote:
>
> On Tue, Feb 18, 2025 at 8:23 PM 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
On Tue, 18 Feb 2025 09:35:33 +0100
Richard Biener wrote:
> > I'm sure you agree we don't want to let this tail wag the dog.
> > With my exegesis in mind, what would you recommend? If it's
> > limited to more judicious use of makefile variables, I could surely
> > implement those suggestions.
>
On Tue, 18 Feb 2025 09:37:57 +0100
Richard Biener wrote:
> > Except for "lib", patches over 400 KB consist of just one big file.
>
> For a future possible version 3 of the patch set, you do not need to
> send big generated files like 'configure' as part of the patch, but
> just the sources/chang
> Am 18.02.2025 um 17:04 schrieb Konstantinos Eleftheriou
> :
>
> From: kelefth
>
> 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 a
> 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 wrote:
When gcc is built for x86_64-linux-musl target, sta
On Tue, Feb 18, 2025 at 8:23 PM 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 K
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 Ukrainian team of translators. The file is available at:
https://translationproject.org/latest/cpplib/uk.po
(This file, 'cpplib-15-b202502
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 wrote:
> > > When gcc is built for x86_64-linux-musl target, stack unwinding from
> > > within signal handler stops at the
On Mon, Feb 17, 2025 at 6:19 PM Roman Kagan wrote:
>
> On Thu, Jan 02, 2025 at 04:32:17PM +0100, Roman Kagan wrote:
> > When gcc is built for x86_64-linux-musl target, stack unwinding from
> > within signal handler stops at the innermost signal frame. The reason
> > for this behaviro is that the
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-7610-g196e8dbddc509c.
Signed-off-by: David Malcolm
gcc/ChangeLog:
* opts-diagnostic.cc (sarif_scheme_handler::make_sink): Put
properties in alphabetical order.
S
Add some more properties to the analyzer's sarif output, to
help with debugging -fanalyzer.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r15-7611-gfcdcccdbf809f9.
gcc/analyzer/ChangeLog:
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 mention it but it should if it
is) or someth
Hi Kyrill,
Thanks for your comments, and for answering my question RE your work. Happy to
apply those changes in the next revision.
Cheers,
Spencer
When initialising intrinsics with `#pragma GCC aarch64 "arm_*.h"`, we
often set an explicit target, but currently leave current_target_pragma
unchanged. This results in the target pragma being applied to each
simulated intrinsic on top of our explicit target, which is clearly undesirable.
As far
We've been rejecting this valid code since r8-4571:
=== cut here ===
void foo (float);
int main () {
constexpr float x = 0;
(void) [&] () {
foo (x);
(void) [] () {
foo (x);
};
};
}
=== cut here ===
The problem is that when processing X in the inner lambda,
process_outer_va
Hello,
I looked into updating the hook
> -/* Implement TARGET_IRA_CALLEE_SAVED_REGISTER_COST_SCALE. */
> +/* Implement TARGET_CALLEE_SAVE_COST. */
>
> static int
> -ix86_ira_callee_saved_register_cost_scale (int)
> +ix86_callee_save_cost (spill_cost_type, unsigned int, machine_mode,
> +
> Jan Hubicka writes:
> > Concerning x86 specifics, there is cost for allocating stack frame. So
> > if the function has nothing on stack frame push/pop becomes bit better
> > candidate then a spill. The hook you added does not seem to be able to
> > test this, since it does not have frame size
We overlooked the side effects of the rounding mode in the pattern,
which can impact the result of float_extend and lead to incorrect
optimizations in the final program. This issue likely affects nearly
all similar patterns that involve rounding modes, and the tests in
this patch only highlight one
On 2025-02-18 13:30, Richard Biener wrote:
On Tue, Feb 18, 2025 at 1:54 PM Peter0x44
wrote:
18 Feb 2025 8:51:16 am Richard Biener :
> On Tue, Feb 18, 2025 at 1:21 AM Sam James wrote:
>>
>> Peter Damianov writes:
>>
>>> POSIX says that sin and cos should set errno to EDOM when infinity is
>>
Jan Hubicka writes:
> Concerning x86 specifics, there is cost for allocating stack frame. So
> if the function has nothing on stack frame push/pop becomes bit better
> candidate then a spill. The hook you added does not seem to be able to
> test this, since it does not have frame size as an para
Alfie Richards writes:
> The string_slice inherits from array_slice and is used to refer to a
> substring of an array that is memory managed elsewhere without modifying
> the underlying array.
>
> For example, this is useful in cases such as when needing to refer to a
> substring of an attribute i
The following changes how flag_complex_method is managed towards
being able to record that in the optimization set so we can stream
and restore it per function. Currently -fcx-fortran-rules and
-fcx-limited-range are separate recorded options but saving/restoring
does not restore flag_complex_meth
On Tue, Feb 18, 2025 at 10:27:46AM +, Richard Sandiford wrote:
> Thanks, this generally looks really good. Some comments on top of
> Kyrill's, and Christophe's comment internally about -save-temps.
>
> Spencer Abson writes:
> > +/* Build and return a new VECTOR_CST that is the concatenation
On 18/02/2025 08:37, Christophe Lyon wrote:
> As discussed in the PR, removing the inner 'fix:HF/SD/DF' fixes the
> problem, like other targets do.
>
The double-'fix' idiom was introduced in
https://gcc.gnu.org/pipermail/gcc-patches/2003-March/098380.html to address
target/5985. Certainly at t
18 Feb 2025 8:51:16 am Richard Biener :
On Tue, Feb 18, 2025 at 1:21 AM Sam James wrote:
Peter Damianov writes:
POSIX says that sin and cos should set errno to EDOM when infinity is
passed to
them. Make sure this is accounted for in builtins.def, and add tests.
gcc/
PR middle-end/8
Thanks, this generally looks really good. Some comments on top of
Kyrill's, and Christophe's comment internally about -save-temps.
Spencer Abson writes:
> +/* Build and return a new VECTOR_CST that is the concatenation of
> + VEC_IN with itself. */
> +static tree
> +aarch64_self_concat_vec_cs
Soumya AR writes:
>> On 18 Feb 2025, at 2:27 PM, Kyrylo Tkachov wrote:
>>
>>
>>
>>> On 18 Feb 2025, at 09:48, Kyrylo Tkachov wrote:
>>>
>>>
>>>
On 18 Feb 2025, at 09:41, Richard Sandiford
wrote:
Kyrylo Tkachov writes:
> Hi Soumya
>
>> On 18 Feb 2025, at
Alfie Richards writes:
> Notably this respects target_version semantics where an unannotated
> function can be the default version.
>
> gcc/ChangeLog:
>
> * attribs.cc (is_function_default_version): Add target_version logic.
OK for GCC 16, thanks.
Richard
> ---
> gcc/attribs.cc | 27
We already have a use of "(reg:SI FRM_REGNUM)" within the pattern, is
it not enough?
I believe the answer is not enough so you propose this patch, so could
you explain a few more about what happened?
(define_insn "@pred_single_widen__scalar"
[(set (match_operand:VWEXTF 0 "register_operand"
With a compiler setup to compile (also) for nvptx offloading,
the testcase triggered a bogus error - and that prevents in
addition the gimple scan.
Fixed by adding an xfail and an xfailed dg-bogus.
The issue itself is the known https://gcc.gnu.org/PR118694
Committed as obvious asr15-7606-g8d922
Hi Thomas,
> This patch series (of necessity) introduces ABI changes. What will
> happen with user code compiled against the old interface?
That depends on the library you are linking against. When using caf_single from
gfortran, then you will get link failures when you mix code compiled by
gfor
Hi Jerry,
thank you very much for taking on the job of reviewing and sorry for my late
answer. In fact, I was having a hard time figuring regressions in the
OpenCoarrays library.
This also answers your first question: Yes, OpenCoarrays will make use of the
new interface. Most of the changes in th
Alfie Richards writes:
> This changes behavior of target_clones and target_version attributes
> to be inline with what is specified in the Arm C Language Extension.
>
> Notably this changes the scope and signature of multiversioned functions
> to that of the default version, and changes the resolv
Hi Richard,
After some more investigation, the sample code never hit one vectorizable_*
routines which may check the loop_vinfo->vector_mode,
and then the loop_vinfo->vector_mode == DImode will hit the
vect_verify_loop_lens and trigger the assert VECTOR_MODE_P, detail
flow as below.
vect_analyz
Kyrylo Tkachov writes:
> Hi Soumya
>
>> On 18 Feb 2025, at 09:12, Soumya AR wrote:
>>
>> generic_armv8_a.h defines generic_armv8_a_prefetch_tune but still uses
>> generic_prefetch_tune in generic_armv8_a_tunings.
>>
>> This patch updates the pointer to generic_armv8_a_prefetch_tune.
>>
>> This
Alexandre Oliva writes:
> On Feb 13, 2025, Alexandre Oliva wrote:
>
>> @@ -14108,10 +14113,9 @@ proc dg-require-python-h { args } {
>> # Return 1 if the target supports heap-trampoline, 0 otherwise.
>> proc check_effective_target_heap_trampoline {} {
>> if { [istarget aarch64*-*-linux*]
>>
> On 18 Feb 2025, at 09:41, Richard Sandiford wrote:
>
> Kyrylo Tkachov writes:
>> Hi Soumya
>>
>>> On 18 Feb 2025, at 09:12, Soumya AR wrote:
>>>
>>> generic_armv8_a.h defines generic_armv8_a_prefetch_tune but still uses
>>> generic_prefetch_tune in generic_armv8_a_tunings.
>>>
>>> This
On Tue, Feb 18, 2025 at 1:21 AM Sam James wrote:
>
> Peter Damianov writes:
>
> > POSIX says that sin and cos should set errno to EDOM when infinity is
> > passed to
> > them. Make sure this is accounted for in builtins.def, and add tests.
> >
> > gcc/
> > PR middle-end/80042
> > * b
> On 18 Feb 2025, at 09:48, Kyrylo Tkachov wrote:
>
>
>
>> On 18 Feb 2025, at 09:41, Richard Sandiford
>> wrote:
>>
>> Kyrylo Tkachov writes:
>>> Hi Soumya
>>>
On 18 Feb 2025, at 09:12, Soumya AR wrote:
generic_armv8_a.h defines generic_armv8_a_prefetch_tune but still us
Result of the commit, see: https://gcc.gnu.org/projects/gomp/
Main change are sync'ing a couple of now fully/partially supported items
from libgomp.texi's implementation status table.
Otherwise as Sandra found out: a comma between directive and clauses in
'#pragma' is already supported since
On Tue, Feb 18, 2025 at 10:12 AM Richard Biener
wrote:
>
> On Tue, Feb 18, 2025 at 9:40 AM Li, Pan2 wrote:
> >
> > Hi Richard,
> >
> > After some more investigation, the sample code never hit one vectorizable_*
> > routines which may check the loop_vinfo->vector_mode,
> > and then the loop_vinfo
On Tue, Feb 18, 2025 at 9:40 AM Li, Pan2 wrote:
>
> Hi Richard,
>
> After some more investigation, the sample code never hit one vectorizable_*
> routines which may check the loop_vinfo->vector_mode,
> and then the loop_vinfo->vector_mode == DImode will hit the
> vect_verify_loop_lens and trigge
generic_armv8_a.h defines generic_armv8_a_prefetch_tune but still uses
generic_prefetch_tune in generic_armv8_a_tunings.
This patch updates the pointer to generic_armv8_a_prefetch_tune.
This patch was bootstrapped and regtested on aarch64-linux-gnu, no regression.
Ok for GCC 15 now?
Signed-off-
On Mon, Feb 17, 2025 at 6:50 PM James K. Lowden
wrote:
>
> On Sat, 15 Feb 2025 21:24:52 +
> Sam James wrote:
>
> > > +prototypes.cpp: posix.txt
> > > + awk -F'[/.]' '{ print $$6 }' $^ | \
> > > + while read F; do echo "/* $$F */" && man 2 $$F | \
> > > + ./scrape.awk -v
Hi Soumya
> On 18 Feb 2025, at 09:12, Soumya AR wrote:
>
> generic_armv8_a.h defines generic_armv8_a_prefetch_tune but still uses
> generic_prefetch_tune in generic_armv8_a_tunings.
>
> This patch updates the pointer to generic_armv8_a_prefetch_tune.
>
> This patch was bootstrapped and regtest
As discussed in the PR, removing the inner 'fix:HF/SD/DF' fixes the
problem, like other targets do.
gcc/ChangeLog:
PR rtl-optimization/117712
* config/arm/arm.md (fix_trunchfsi2): Remove inner fix:HF.
(fix_trunchfdi2): Likewise.
(fix_truncsfsi2): Remove inner fix:S
On Sat, Feb 15, 2025 at 10:01 PM James K. Lowden
wrote:
>
> The following 15 patches constitute 134,033 lines of code in 97 files
> to build and document the COBOL front end. The messages are
> grouped by files in a more or less logical order. We have:
>
> 4K dir create gcc/cobol and libgc
97 matches
Mail list logo
