The uses of finite_operands_p removed are guarded by a call to
finite_operands_p already.
gcc/ChangeLog:
* range-op-float.cc (foperator_lt::fold_range): Remove extra check
to finite_operands_p.
(foperator_le::fold_range): Same.
(foperator_gt::fold_range): Same.
gcc/ChangeLog:
* value-range-pretty-print.cc (vrange_printer::print_real_value):
Avoid printing INF and NAN twice.
---
gcc/value-range-pretty-print.cc | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/gcc/value-range-pretty-print.cc b/gcc/value-range-pretty-
We recently agreed that setting a range of NAN should instead set
UNDEFINED for -ffinite-math-only. This patch makes that change to
frange::set_nan() directly. Also, calling frange::update_nan() will now
be a nop for !HONOR_NANS.
Doing this in the setters simplifies everywhere we set NANs, as it
On 10/5/22 22:02, Patrick Palka wrote:
Roughly speaking, optimize_specialization_lookup_p returns true
for a non-template member function of a class template, e.g.
template struct A { int f(); };
The idea behind the optimization in question seems to be that if we want
to look up the speciali
On 10/4/22 05:28, Stefan Schulze Frielinghaus via Gcc-patches wrote:
For BImode get_narrowest_mode evaluates to QImode but BImode < QImode.
Thus FOR_EACH_MODE_UNTIL never reaches BImode and iterates until OImode
for which no wider mode exists so we end up with VOIDmode and fail.
Fixed by adding
I agree with Kito; I don't support merging this patch. My reasoning is twofold:
- The default settings should be fairly neutral, avoiding codegen that
severely disadvantages some targets. Misaligned memory accesses are
certainly a problematic case in that respect. (And it's highly
asymmetric: t
Roughly speaking, optimize_specialization_lookup_p returns true
for a non-template member function of a class template, e.g.
template struct A { int f(); };
The idea behind the optimization in question seems to be that if we want
to look up the specialization A::f [with T=int], then we can just
-1 for this, default enable fast unaligned access could cause many
problems, and lots of RISC-V cores
don't support HW unaligned access (Rocket-base RISC-V core, most
SiFive core, and most Andes core IIRC),
change this to default means package from RISC-V linux distro might
contain unaligned access
[C++ maintainers / global reviewers, note that there is a C++
front-end change here needing review.]
C2x adds typeof as a standard feature. In general this follows
existing GNU C semantics very closely, but there are various ways in
which the implementation involves more than simply enabling the
On 10/5/22 17:27, Marek Polacek wrote:
This PR reports that
struct Base {};
struct Derived : Base {};
static_assert(__reference_constructs_from_temporary(Base const&, Derived));
doesn't pass, which it should: it's just like
const Base& b(Derived{});
where we bind 'b' to the Base s
Hi Mikael,
> Gesendet: Mittwoch, 05. Oktober 2022 um 11:23 Uhr
> Von: "Mikael Morin"
> An: "Harald Anlauf" , "fortran" ,
> "gcc-patches"
> Betreff: Re: [PATCH] Fortran: error recovery for invalid types in array
> constructors [PR107000]
> The following does.
>
>
> diff --git a/gcc/fortran/ari
This PR reports that
struct Base {};
struct Derived : Base {};
static_assert(__reference_constructs_from_temporary(Base const&, Derived));
doesn't pass, which it should: it's just like
const Base& b(Derived{});
where we bind 'b' to the Base subobject of a temporary object of type
Derive
Hi Mikael,
> Gesendet: Mittwoch, 05. Oktober 2022 um 12:34 Uhr
> Von: "Mikael Morin"
> Please move the check to resolve_transfer in resolve.cc.
I have done this, see attached updated patch.
Regtests cleanly on x86_64-pc-linux-gnu.
> Strangely, the patch doesn't seem to fix the problem on the t
On Wed, 5 Oct 2022, Qing Zhao via Gcc-patches wrote:
> + /* if not the last field, return false. */
Comments should start with an uppercase letter.
> + /* if not an array field, return false. */
> + /* if there is a strict_flex_array attribute attached to the field,
> + override the fl
On Wed, 5 Oct 2022, Torbjörn SVENSSON via Gcc-patches wrote:
> -/* These should be defined if and only if signaling NaNs are supported
> - for the given types. If the testsuite gains effective-target
> - support for targets not supporting signaling NaNs, or not
> - supporting them for all t
On 05.10.22 20:41, Martin Liška wrote:
+++ b/contrib/gcc-changelog/git_update_version.py
@@ -127,6 +127,7 @@ def update_current_branch(ref_name):
repo.git.add(datestamp_path)
if not args.current:
repo.index.commit('Daily bump.')
+origi
On 10/5/22 09:47, Jakub Jelinek wrote:
On Tue, Oct 04, 2022 at 05:50:50PM -0400, Jason Merrill wrote:
Another question is the suffixes of the builtins. For now I have added
bf16 suffix and enabled the builtins with !both_p, so one always needs to
use __builtin_* form for them. None of the GCC
Add the following new option -fstrict-flex-arrays[=n] and a corresponding
attribute strict_flex_array to GCC:
'-fstrict-flex-arrays'
Control when to treat the trailing array of a structure as a flexible array
member for the purpose of accessing the elements of such an array.
The pos
Use array_at_struct_end_p to determine whether the trailing array
of a structure is flexible array member in __builtin_object_size.
gcc/ChangeLog:
PR tree-optimization/101836
* tree-object-size.cc (addr_object_size): Use array_at_struct_end_p
to determine a flexible array
This is the 6th version of the patch set.
Compare to the 5th version, the major change is: (Address Joseph's
comment on the attribute):
1. to require the attribute to be applied to a declaration;
(c-family/c-attribs.cc)
2. update testing case to include such case;
(testsuite/gcc.dg/strict-flex-arr
2022-10-05 Segher Boessenkool
* config/rs6000/constraints.md (wD): Delete.
* doc/md.texi (Machine Constraints): Adjust.
---
gcc/config/rs6000/constraints.md | 6 --
gcc/doc/md.texi | 3 ---
2 files changed, 9 deletions(-)
diff --git a/gcc/config/rs6000/co
We can use "n" instead of "wD" if we simply test the value of the
integer constant directly.
2022-10-05 Segher Boessenkool
* config/rs6000/vsx.md (*vsx_extract__store): Use "n" instead of
"wD" constraint.
---
gcc/config/rs6000/vsx.md | 5 +++--
1 file changed, 3 insertions(+)
Extracting the left and right halfs of a vector are entirely different
operations. Things are simpler if they are separate define_insns, and
it is easy to get rid of the "wD" constraint use then.
This also give the variant that is a no-op copy its own alternative, of
length 0 (and this, cost 0, m
This series rewrites the code now using the wD constraint, because this
constraint is a) unnecessary to have at all, and b) we want to use the
constraint name for a more mnemonic purpose.
As an extra benefit the new code is simpler than the original was.
I'll commit this to trunk shortly.
Seghe
As seen from recent days, the script fails when it pushes
a branch while another revision was pushed by a user.
Prevent that by doing fetch right before the pull.
The error message example:
cmdline: git push origin releases/gcc-11
stderr: 'fatal: unable to parse object: 4249a65c814287af667aa78789
> On Oct 5, 2022, at 1:36 PM, Martin Liška wrote:
>
> On 10/5/22 16:50, Qing Zhao wrote:
>> I have two questions on this:
>
> Hello.
>
>>
>> 1. What’s the motivation to enable -flive-patching with -flto? Is there any
>> application that will try -flive-patching with -flto now?
>
> We're p
PR analyzer/107158 reports an ICE when using
-fanalyzer -fanalyzer-call-summaries
on a particular source file.
It turns out I just fixed this ICE in r13-3094-g6832c95c0e1a58.
This followup patch adds a somewhat reduced reproducer as a regression
test. Unfortunately, although the ICE is fixed,
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-3095-g2eff4fe383a59d.
gcc/analyzer/ChangeLog:
* analysis-plan.cc: Simplify includes.
* analyzer-pass.cc: Likewise.
* analyzer-selftests.cc: Likewise.
* analyzer.cc: Likewise.
This doesn't fix the various false positives seen with
-fanalyzer-call-summaries on PR 107060, but stops it crashing at -O2.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-3094-g6832c95c0e1a58.
gcc/analyzer/ChangeLog:
PR analyzer/107060
* cal
On 10/5/22 16:50, Qing Zhao wrote:
> I have two questions on this:
Hello.
>
> 1. What’s the motivation to enable -flive-patching with -flto? Is there any
> application that will try -flive-patching with -flto now?
We're planning supporting GCC LTO Linux kernel support, so that's one
motivati
On Wed, Oct 05, 2022 at 02:29:56PM +0200, Tobias Burnus wrote:
> + gfc_error ("!OMP ASSUMES at %C must be in the specification part of a "
s/!OMP/!$OMP/
Otherwise LGTM.
Jakub
Wilco Dijkstra writes:
> Since AArch64 sets all flags on logical operations, comparisons with zero
> can be combined into an AND even if the condition is LE or GT.
>
> Passes regress, OK for commit?
>
> gcc:
> PR target/105773
> * config/aarch64/aarch64.cc (aarch64_select_cc_mode):
t is a write-after-write if the access function is not
affine or constant.
2022-10-05 Eric Botcazou
* gcc.c-torture/execute/20221005-1.c: New test.
--
Eric Botcazoudiff --git a/gcc/gimple-loop-jam.cc b/gcc/gimple-loop-jam.cc
index a8a57d3d384..4f7a6e5bbae 100644
--- a/gcc/
This patch stops reporting fails for Arm targets with single
precision floating point unit for types wider than 32 bits (the width
of float on arm-none-eabi).
As reported in PR102017, fenv is reported as supported in recent
versions of newlib. At the same time, for some Arm targets, the
implementa
ping?
On 9/12/22 10:13, Christophe Lyon via Gcc-patches wrote:
Hi!
On 9/9/22 11:33, Christophe Lyon wrote:
This is a backport from trunk to gcc-12.
Several MVE builtins incorrectly use the same predicate/constraint
pair for several modes, which does not match the specification.
This patch us
Hi, Martin:
I have two questions on this:
1. What’s the motivation to enable -flive-patching with -flto? Is there any
application that will try -flive-patching with -flto now?
2. Why only enable -flive-patching=inline-clone with -flto?
thanks.
Qing
> On Oct 5, 2022, at 7:41 AM, Martin Lišk
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
I was wondering how lvalue_kind handles VIEW_CONVERT_EXPR; in cases where
the type actually changes, it should have the same prvalue->xvalue effect as
ARRAY_REF, since we need to materialize a temporary to get an object we can
reinterpret as
> On Oct 4, 2022, at 1:37 PM, Joseph Myers wrote:
>
> On Tue, 4 Oct 2022, Qing Zhao via Gcc-patches wrote:
>
>> + { "strict_flex_array", 1, 1, false, false, false, false,
>> + handle_strict_flex_array_attribute, NULL },
>
> You're not requiring that the attribut
Committed, thanks :)
On Fri, Sep 30, 2022 at 2:59 PM wrote:
>
> From: Ju-Zhe Zhong
>
> gcc/ChangeLog:
>
> * config.gcc: Add riscv_vector.h.
> * config/riscv/riscv-builtins.cc: Add RVV builtin types support.
> * config/riscv/riscv-c.cc (riscv_pragma_intrinsic): New functio
gcc/ChangeLog:
* range-op.cc (operator_cast::fold_range): Handle truncating casts
for nonzero masks.
---
gcc/range-op.cc | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index 6fa27a8904e..df0735cb42a 100644
On Tue, Oct 04, 2022 at 05:50:50PM -0400, Jason Merrill wrote:
> > Another question is the suffixes of the builtins. For now I have added
> > bf16 suffix and enabled the builtins with !both_p, so one always needs to
> > use __builtin_* form for them. None of the GCC builtins end with b,
> > so th
On Thu, 7 Jul 2022, Jonathan Wakely via Gcc-patches wrote:
> This adds a new built-in to replace the recursive class template
> instantiations done by traits such as std::tuple_element and
> std::variant_alternative. The purpose is to select the Nth type from a
> list of types, e.g. __builtin_type
I forgot to do this after applying Arsen's patches to my tree.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/Makefile.in: Regenerate.
---
libstdc++-v3/include/Makefile.in | 101 +++
1 file changed, 49 insertions(+), 52 dele
On Tue, 4 Oct 2022, Patrick Palka wrote:
> Here when lazily loading the binding for f at parse time from the
> template g, processing_template_decl is set and thus the call to
> note_vague_linkage_fn from module_state::read_cluster has no effect,
> and we never push f onto deferred_fns and end up
On 10/5/22 14:01, Jakub Jelinek wrote:
> On Wed, Oct 05, 2022 at 01:49:40PM +0200, Martin Liška wrote:
>> PR c/107156
>>
>> gcc/ChangeLog:
>>
>> * attribs.h (lookup_attribute_by_prefix): Support attributes
>> starting with underscore (like _noreturn, or __Noreturn).
>
> There are no
On 10/5/22 14:04, Jørgen Kvalsvik via Gcc-patches wrote:
> Edges with locus are candidates for splitting so that the edge with
> locus is the only edge out of a basic block, except when the locuses
> match. The test checks the last (non-debug) statement in a basic block,
> but this causes an unnece
Tested x86_64-linux, pushed to trunk.
-- >8 --
Another case where I forgot that non-GCC compilers don't have this
built-in yet.
libstdc++-v3/ChangeLog:
* include/bits/invoke.h (__invoke_r): Check
__has_builtin(__reference_converts_from_temporary) before using
built-in.
-
On 10/5/22 05:55, Jakub Jelinek wrote:
On Tue, Oct 04, 2022 at 04:42:04PM -0400, Jason Merrill wrote:
It could choose which function to call based on whether the constexpr_ctx
parameter is null?
Done, though it needs to be in constexpr.cc then because struct
constexpr_ctx and cxx_eval_constant
Since AArch64 sets all flags on logical operations, comparisons with zero
can be combined into an AND even if the condition is LE or GT.
Passes regress, OK for commit?
gcc:
PR target/105773
* config/aarch64/aarch64.cc (aarch64_select_cc_mode): Allow
GT/LE for merging comp
Minor update to just posted patch: the table did not revert all strings where a
substring directive name existed, i.e. 'target' vs. 'target update', 'assume'
vs. 'assumes'. Now fixed. Otherwise unchanged:
Tobias
On 05.10.22 13:19, Tobias Burnus wrote:
Hi Jakub,
On 04.10.22 14:58, Jakub Jelin
On 10/5/22 14:04, Jørgen Kvalsvik via Gcc-patches wrote:
> The coverage support will under some conditions decide to split edges to
> accurately report coverage. By running the test suite with/without this
> edge splitting a small diff shows up, addressed by this patch, which
> should catch future
PR tree-optimization/107052
gcc/ChangeLog:
* gimple-range-op.cc (cfn_popcount::fold_range): Take into account
nonzero bit mask.
---
gcc/gimple-range-op.cc | 15 ---
gcc/testsuite/gcc.dg/tree-ssa/pr107052.c | 13 +
2 files changed,
Track nonzero masks through a cast in range-ops.
We could also track through a truncating cast if the mask fits in the
outer type. I will do that as a follow-up patch because I already have
this patchset tested.
PR tree-optimization/107052
gcc/ChangeLog:
* range-op.cc (operator
Track nonzero masks through a cast in range-ops.
We could also track through a truncating cast if the mask fits in the
outer type. I will do that as a follow-up patch because I already have
this patchset tested.
PR tree-optimization/107052
gcc/ChangeLog:
* range-op.cc (operator
The coverage support will under some conditions decide to split edges to
accurately report coverage. By running the test suite with/without this
edge splitting a small diff shows up, addressed by this patch, which
should catch future regressions.
Removing the edge splitting:
diff --git a/gcc/prof
Hi!
The following patch uses the new lookup_attribute overload and extra
tests to avoid emitting weird warnings on foreign namespace attributes
which we should just ignore (perhaps with a warning), but shouldn't
imply any meaning to them just because they have a name matching some
standard or gnu
Edges with locus are candidates for splitting so that the edge with
locus is the only edge out of a basic block, except when the locuses
match. The test checks the last (non-debug) statement in a basic block,
but this causes an unnecessary split when the edge locus go to a block
which coincidentall
Original discussion: https://gcc.gnu.org/pipermail/gcc/2022-October/239544.html
Some tiny test additions as well as more accurate check for when to
split edges for coverage. This patch preserves the edge splitting
heuristic except using a slightly more precise comparison, but makes a
huge differen
On Wed, Oct 05, 2022 at 01:49:40PM +0200, Martin Liška wrote:
> PR c/107156
>
> gcc/ChangeLog:
>
> * attribs.h (lookup_attribute_by_prefix): Support attributes
> starting with underscore (like _noreturn, or __Noreturn).
There are no _noreturn or __Noreturn attributes, there is
PR c/107156
gcc/ChangeLog:
* attribs.h (lookup_attribute_by_prefix): Support attributes
starting with underscore (like _noreturn, or __Noreturn).
---
gcc/attribs.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/gcc/attribs.h b/gcc/attribs.h
index b2836560fc2..706d35
On Okt 05 2022, Martin Liška wrote:
> * attribs.h (lookup_attribute_by_prefix): Support attributes
> starting with dash (like _noreturn, or __Noreturn).
s/dash/underscore/
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EE
Support attributes starting with dash (like _noreturn, or __Noreturn).
Note the only consumer of lookup_attribute_by_prefix comes from IPA ICF.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
PR c/107156
gcc/ChangeLog:
There's no fundamental reason why -flive-patching=inline-clone can't
coexist with -flto. Yes, one can theoretically have many more clone
function that includes a live patch. It is pretty much the same
as in-module inlining.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Re
Fixes:
gcc/analyzer/call-summary.h:103:13: warning: private field 'm_called_fn' is not
used [-Wunused-private-field]
gcc/analyzer/engine.cc:1631:24: warning: unused parameter 'uncertainty'
[-Wunused-parameter]
gcc/analyzer/ChangeLog:
* call-summary.cc (call_summary_replay::call_summary
Hi Jakub,
On 04.10.22 14:58, Jakub Jelinek via Gcc-patches wrote:
On Tue, Oct 04, 2022 at 02:26:13PM +0200, Tobias Burnus wrote:
On Sun, Oct 02, 2022 at 07:47:18PM +0200, Tobias Burnus wrote:
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
OK?
Ok, thanks.
Committed as
https://gcc.gnu.
Hello
Le 04/10/2022 à 21:27, Harald Anlauf via Fortran a écrit :
Dear all,
when looking at output item lists we didn't catch procedures
and procedure pointers and ran into a gfc_internal_error().
Such items are not allowed by the Fortran standard, e.g. for
procedure pointers there is
C1233 (R1
Hi!
I'd like to ping this patch.
Thanks.
> 2022-09-19 Jakub Jelinek
>
> * unwind-dw2.h (REG_UNSAVED, REG_SAVED_OFFSET, REG_SAVED_REG,
> REG_SAVED_EXP, REG_SAVED_VAL_OFFSET, REG_SAVED_VAL_EXP,
> REG_UNDEFINED): New anonymous enum, moved from inside of
> struct frame_sta
Pushed as pre-approved by Jeff.
Martin
PR tree-optimization/106679
gcc/testsuite/ChangeLog:
* gcc.dg/tree-prof/cmpsf-1.c: Mark as a known limitation.
---
gcc/testsuite/gcc.dg/tree-prof/cmpsf-1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/g
On Tue, Oct 4, 2022 at 5:42 PM Andrew MacLeod wrote:
>
>
> On 10/4/22 11:14, Aldy Hernandez wrote:
> > On Tue, Oct 4, 2022 at 4:34 PM Richard Biener
> > wrote:
> >>
> >>
> >>> Am 04.10.2022 um 16:30 schrieb Aldy Hernandez :
> >>>
> >>> On Tue, Oct 4, 2022 at 3:27 PM Andrew MacLeod
> >>> wrote:
On 2022-10-05 11:51, Kyrylo Tkachov wrote:
Hi Torbjörn,
-Original Message-
From: Torbjorn SVENSSON
Sent: Wednesday, October 5, 2022 10:28 AM
To: Kyrylo Tkachov
Cc: Yvan Roux
Subject: Fwd: PING^1 [PATCH] testsuite: 'b' instruction can't do long enough
jumps
Hi Kyrill,
I checked w
On Tue, Oct 04, 2022 at 04:42:04PM -0400, Jason Merrill wrote:
> It could choose which function to call based on whether the constexpr_ctx
> parameter is null?
Done, though it needs to be in constexpr.cc then because struct
constexpr_ctx and cxx_eval_constant_expression is local to constexpr.cc.
Hi Torbjörn,
> -Original Message-
> From: Torbjorn SVENSSON
> Sent: Wednesday, October 5, 2022 10:28 AM
> To: Kyrylo Tkachov
> Cc: Yvan Roux
> Subject: Fwd: PING^1 [PATCH] testsuite: 'b' instruction can't do long enough
> jumps
>
> Hi Kyrill,
>
> I checked with Richard Sandiford if he
On 10/5/22 09:15, Torbjorn SVENSSON via Gcc-patches wrote:
Hi,
Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602541.html
Kind regards,
Torbjörn
Looks good to me, pushed to master branch as
fa8e3a055a082e38aeab2561a5016b01ebfd6ebd.
On 10/5/22 09:34, Jonathan Yong wrote:
On 9/29/22 17:38, Torbjörn SVENSSON via Gcc-patches wrote:
When running the DejaGNU testsuite on a toolchain built for native
Windows, the path /dev/null can't be used to open a stream to void.
On native Windows, the resource is instead named "nul".
The er
Hi,
On 2022-10-05 11:34, Jonathan Yong via Gcc-patches wrote:
On 9/29/22 17:38, Torbjörn SVENSSON via Gcc-patches wrote:
When running the DejaGNU testsuite on a toolchain built for native
Windows, the path /dev/null can't be used to open a stream to void.
On native Windows, the resource is inst
On 9/29/22 17:38, Torbjörn SVENSSON via Gcc-patches wrote:
When running the DejaGNU testsuite on a toolchain built for native
Windows, the path /dev/null can't be used to open a stream to void.
On native Windows, the resource is instead named "nul".
The error would look like this:
c:/arm-11.3.re
Le 05/10/2022 à 10:51, Mikael Morin a écrit :
Unfortunately, it doesn't fix the bogus incommensurate arrays errors.
The following does.
diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index e6e35ef3c42..2c57c796270 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -14
Hi,
Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602534.html
Kind regards,
Torbjörn
On 2022-09-29 19:38, Torbjörn SVENSSON wrote:
When running the DejaGNU testsuite on a toolchain built for native
Windows, the path /dev/null can't be used to open a stream to void.
On native W
Hi,
Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602111.html
Kind regards,
Torbjörn
On 2022-09-23 14:03, Torbjörn SVENSSON wrote:
For some test cases, it's required that the optional module mapper
"g++-mapper-server" is built. As the server is not required, the
test cases wil
Hi,
Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602541.html
Kind regards,
Torbjörn
On 2022-09-29 20:07, Torbjörn SVENSSON wrote:
When the mapper can't be executed, Windows report the error like:
.../bad-mapper-1.C: error: failed CreateProcess mapper 'this-will-not-work'
On
Hello
Le 04/10/2022 à 23:19, Harald Anlauf via Fortran a écrit :
Dear all,
we did not recover well from bad expressions in array constructors,
especially when there was a typespec and a unary '+' or '-', and
when the array constructor was used in an arithmetic expression.
The attached patch in
> -Original Message-
> From: Andre Vieira (lists)
> Sent: Tuesday, October 4, 2022 11:34 AM
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org;
> Richard Sandiford ; Richard Biener
>
> Subject: Re: [PATCH][AArch64] Implement ACLE Data Intrinsics
>
> Hi all,
>
> Can I backport this to gcc-
Wilco Dijkstra writes:
> Improve immediate expansion of immediates which can be created from a
> bitmask immediate and 2 MOVKs. This reduces the number of 4-instruction
> immediates in SPECINT/FP by 10-15%.
>
> Passes regress, OK for commit?
>
> gcc/ChangeLog:
>
> PR target/106583
>
83 matches
Mail list logo
