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
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
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:
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
-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
[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
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
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
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
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
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
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.')
+
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
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;
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
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
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,
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.
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:
> 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
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
*
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
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
cess 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/gimple-loop-jam.cc
+++ b/gcc/gi
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
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
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
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
> 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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
> >>>
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
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
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
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
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:
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
@@
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
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
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
> -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
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
>
80 matches
Mail list logo
