On Thu, Apr 28, 2022 at 8:44 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 4/28/2022 10:30 AM, Aldy Hernandez wrote:
> > [Jeff, this is the same patch I sent you last week with minor tweaks
> > to the commit message.]
> And I just dropped it into the tester. We should have the vast majority
> of
The PR points out dead code after previous refactoring.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-02-01 Richard Biener
PR tree-optimization/104322
* tree-vect-loop.cc (vectorizable_reduction): Remove dead code.
---
gcc/tree-vect-loop.cc | 7 +--
1
The following adds gsi_after_labels for gimple_seq so I do not have
to open-code it. I took the liberty to remove the two #defines
wrapping gsi_start_1 and gsi_last_1 as we now have C++ references.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
2022-02-01 Richard Biener
*
On Thu, 28 Apr 2022 at 22:40, Rainer Orth wrote:
>
> The following patch updates the Solaris baselines for GCC 12.1.
>
> Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (Solaris 11.3
> and 11.4 in each case).
>
> The only (expected) difference between the 11.3 and 11.4 versions is
>
> --- b
[I will be committing a series of small, hopefully non-intrusive
cleanups to trunk in preparation for work to be done later this cycle
that will definitely be invasive ;-). If these changes turn out to be
remotely problematic, I can revert them, but I'm trying to get them in
early because I'm leav
Small clean up to use set_undefined instead of duplicating the
functionality therein.
Tested on x86-64 Linux.
gcc/ChangeLog:
* value-range.h (irange::irange): Use set_undefined.
---
gcc/value-range.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/gcc/value-range.h
Hi!
The following testcase fails -fcompare-debug on aarch64-linux. The problem
is that for the n variable we create a varpool node, then remove it again
because the var isn't really used, but it keeps being referenced in debug
stmts/insns with -g. Later during sched1 pass we ask whether the n va
This patch consolidates the multiple ways we have of storing global
ranges into one accepting a range.
In an upcoming patch series later this cycle we will be providing a
way to store iranges globally, as opposed to the mechanism we have now
which squishes wider ranges into value_range's. This is
This patch cleans up some irange methods in preparation for other
cleanups later in the cycle.
First, we prefer the reference overloads for union and intersect as
the pointer versions have been deprecated for a couple releases.
Also, I've renamed the legacy union/intersect whose only function was
In preparation for the agnostication of ranger, this patch moves
common code that can be shared with non-integer ranges (initially
pointers) into the relevant header files.
This is a relatively non-invasive change, as any changes that would
need to be ported to GCC 12, would occur in the range-op
This avoids undefined signed overflow when calling powi_as_mults_1.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-04-29 Richard Biener
PR tree-optimization/105431
* tree-ssa-math-opts.cc (powi_as_mults_1): Make n unsigned.
(powi_as_mults): Use absu_
On Fri, 29 Apr 2022, Jakub Jelinek wrote:
> Hi!
>
> The following testcase fails -fcompare-debug on aarch64-linux. The problem
> is that for the n variable we create a varpool node, then remove it again
> because the var isn't really used, but it keeps being referenced in debug
> stmts/insns wit
This uses CASE_CONVERT more which eases eventual removal of NOP_EXPR.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK for trunk?
Jason, from the experiment this is from I know that the C++ FE
distinguishes between CONVERT_EXPR and NOP_EXPR at the moment,
are the C++ bits nevertheless OK
The following fixes wrongly used is_gimple_condexpr and makes
canonicalize_cond_expr_cond honor either, delaying final checking
to callers where all but two in ifcombine are doing the correct
thing already.
This fixes bugs but is now mainly in preparation for making
COND_EXPRs in GIMPLE assignment
On Fri, Apr 29, 2022 at 11:32:15AM +0200, Richard Biener wrote:
> I think that's reasonable (we indeed shouldn't create a varpool node
> here). I do think that we eventually want to retain removed nodes
> but mark them so. In fact any debug references will be thrown away
> because of this anyway.
On Fri, 29 Apr 2022, Jakub Jelinek wrote:
> On Fri, Apr 29, 2022 at 11:32:15AM +0200, Richard Biener wrote:
> > I think that's reasonable (we indeed shouldn't create a varpool node
> > here). I do think that we eventually want to retain removed nodes
> > but mark them so. In fact any debug refer
On Fri, Apr 29, 2022 at 9:09 AM Richard Biener
wrote:
>
> On Thu, Apr 28, 2022 at 8:44 PM Jeff Law via Gcc-patches
> wrote:
> >
> >
> >
> > On 4/28/2022 10:30 AM, Aldy Hernandez wrote:
> > > [Jeff, this is the same patch I sent you last week with minor tweaks
> > > to the commit message.]
> > And
On Fri, Apr 29, 2022 at 11:53 AM Aldy Hernandez wrote:
>
> On Fri, Apr 29, 2022 at 9:09 AM Richard Biener
> wrote:
> >
> > On Thu, Apr 28, 2022 at 8:44 PM Jeff Law via Gcc-patches
> > wrote:
> > >
> > >
> > >
> > > On 4/28/2022 10:30 AM, Aldy Hernandez wrote:
> > > > [Jeff, this is the same patc
Jonathan Wakely writes:
> On Thu, 28 Apr 2022 at 22:40, Rainer Orth wrote:
>>
>> The following patch updates the Solaris baselines for GCC 12.1.
>>
>> Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (Solaris 11.3
>> and 11.4 in each case).
>>
>> The only (expected) difference between the
On Fri, Apr 29, 2022 at 12:32:08PM +0200, Rainer Orth wrote:
> Jonathan Wakely writes:
>
> > On Thu, 28 Apr 2022 at 22:40, Rainer Orth wrote:
> >>
> >> The following patch updates the Solaris baselines for GCC 12.1.
> >>
> >> Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (Solaris 11.3
>
On Fri, Apr 29, 2022 at 11:52:37AM +0200, Richard Biener wrote:
> On Fri, 29 Apr 2022, Jakub Jelinek wrote:
>
> > On Fri, Apr 29, 2022 at 11:32:15AM +0200, Richard Biener wrote:
> > > I think that's reasonable (we indeed shouldn't create a varpool node
> > > here). I do think that we eventually w
On Fri, 29 Apr 2022, Jakub Jelinek wrote:
> On Fri, Apr 29, 2022 at 11:52:37AM +0200, Richard Biener wrote:
> > On Fri, 29 Apr 2022, Jakub Jelinek wrote:
> >
> > > On Fri, Apr 29, 2022 at 11:32:15AM +0200, Richard Biener wrote:
> > > > I think that's reasonable (we indeed shouldn't create a varpo
The following fixes missing handling of non-integer mode but
masked (SVE or MVE) compares in vector lowering by using the
appropriate mask element width to extract the components and
adjust the index.
Bootstrapped and tested on x86_64-unknown-linux-gnu. Alex is
testing this on ARM - if that goes
On Fri, Apr 29, 2022 at 12:58:12PM +0200, Richard Biener wrote:
> So we don't have varpool nodes for the constant pool decls? Are they
Depends. DECL_IN_CONSTANT_POOL decls can appear 2 ways, through
tree_output_constant_def which does create a varpool node for them
and is generally invoked durin
On Fri, Apr 29, 2022 at 01:11:31PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Depends. DECL_IN_CONSTANT_POOL decls can appear 2 ways, through
> tree_output_constant_def which does create a varpool node for them
> and is generally invoked during GIMPLE passes or so, and using
> output_constant_d
On Fri, 29 Apr 2022, Jakub Jelinek wrote:
> On Fri, Apr 29, 2022 at 12:58:12PM +0200, Richard Biener wrote:
> > So we don't have varpool nodes for the constant pool decls? Are they
>
> Depends. DECL_IN_CONSTANT_POOL decls can appear 2 ways, through
> tree_output_constant_def which does create a
On Fri, 29 Apr 2022, Jakub Jelinek wrote:
> On Fri, Apr 29, 2022 at 01:11:31PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > Depends. DECL_IN_CONSTANT_POOL decls can appear 2 ways, through
> > tree_output_constant_def which does create a varpool node for them
> > and is generally invoked during
Introduce peephole2 pattern to convert from:
mov %esi, %edx
negl %eax
adcl $0, %edx
negl %edx
to:
xorl %edx, %edx
negl %eax
sbbl %esi, %edx
This conversion is profitable only when initial move is found. Otherwise,
additional move to a temporary together with clearing xor is
On Thu, Apr 28, 2022 at 8:43 PM Jeff Law wrote:
>
>
>
> On 4/28/2022 10:30 AM, Aldy Hernandez wrote:
> > [Jeff, this is the same patch I sent you last week with minor tweaks
> > to the commit message.]
> And I just dropped it into the tester. We should have the vast majority
> of targets tested b
On Thu, 2022-04-28 at 14:05 +0200, Ilya Leoshkevich wrote:
> On Thu, 2022-04-28 at 13:27 +0200, Jakub Jelinek wrote:
> > On Thu, Apr 28, 2022 at 01:03:26PM +0200, Ilya Leoshkevich wrote:
> > > This is determined by default_elf_select_rtx_section (). If we
> > > don't
> > > want to mix non-reloc an
On Fri, Apr 29, 2022 at 01:52:49PM +0200, Ilya Leoshkevich wrote:
> > This doesn't resolve the problem, unfortunately, because
> > references to discarded comdat symbols are still kept in .rodata:
> >
> > `.text._ZN7testing15AssertionResultlsIPKcEERS0_RKT_' referenced in
> > section `.rodata' of .
An alias can't be declared with a qualified-id in actual code, but in
diagnostics we want to know which scope it belongs to, and I think a
nested-name-specifier is the best way to provide that.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* error.cc (dump_decl): Check
The decl pretty-printing code wasn't looking at the flags parameter, so we
were printing 'using' in the middle of an expression.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/102987
gcc/cp/ChangeLog:
* error.cc (dump_decl) [USING_DECL]: Respect flags.
gcc/testsuite/Chan
This was fixed by r12-6329-g4f6bc28fc7dd86.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/71424
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-array15.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/initlist-array15.C | 13 +
1 file changed, 13 insertions(+)
On Fri, 2022-04-29 at 13:56 +0200, Jakub Jelinek wrote:
> On Fri, Apr 29, 2022 at 01:52:49PM +0200, Ilya Leoshkevich wrote:
> > > This doesn't resolve the problem, unfortunately, because
> > > references to discarded comdat symbols are still kept in .rodata:
> > >
> > > `.text._ZN7testing15Asserti
This was finally fixed for GCC 11 by r11-434.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/78244
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/Wnarrowing20.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/Wnarrowing20.C | 26 +++
1 file changed, 26 insertions(
Tested powerpc64le-linux (both long double ABIs, and also with old
glibc) and x86_64-linux.
Pushed to trunk, also needed for gcc-12 and gcc-11 branches.
-- >8 --
The --with-long-double-abi=ibm build is missing some exports that are
present in the --with-long-double-abi=ieee build. Those symbols
On Sun, Mar 20, 2022 at 11:33:10AM +0200, Mohamed Atef via Gcc-patches wrote:
> hello,
>I know it's too much.
> we fixed the functions' names that are not part of the standard form ompd_
> * prefix to gompd_
Sorry for the delay, have been busy with GCC 12. Now that it branched, I
can look at
Hi Tom!
On 2022-04-06T11:57:57+0200, Tom de Vries wrote:
> On 4/5/22 17:14, Thomas Schwinge wrote:
>> Regarding the following:
>>
>> On 2022-03-30T14:27:41+0200, Tom de Vries wrote:
>>> The -mptx flag has been added to specify the PTX ISA
>>> version
>>> for the generated code; perm
This was fixed by r269078.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/83596
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/nontype5.C: New test.
---
gcc/testsuite/g++.dg/cpp1z/nontype5.C | 11 +++
1 file changed, 11 insertions(+)
create mode 100644 gcc/testsuite/g+
Hi Roger!
On 2022-04-05T19:46:08+0100, "Roger Sayle" wrote:
> I apologise that it might complicate things
No worries; that's why I asked. :-)
> one potential benefit of --with-cuda-driver
> (i.e. linking the compiler against proprietary libraries) is that it would
> allow support for
> -march
[dcl.dcl]/5 says that
enum { };
is ill-formed, and since r197742 we issue a pedwarn. However, the
pedwarn also fires for
enum { } x;
which is well-formed. So only warn when {} is followed by a ;. This
should be correct since you can't have "enum {}, " -- that
produces "expected unqualif
This patch fixes crashes with invalid attributes. Arguably it could
make sense to assert seen_error() too.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk = GCC 13?
PR c++/96637
gcc/ChangeLog:
* attribs.cc (decl_attributes): Check error_mark_node.
gcc/cp/ChangeLog:
On 4/29/2022 3:37 AM, Richard Biener via Gcc-patches wrote:
This uses CASE_CONVERT more which eases eventual removal of NOP_EXPR.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK for trunk?
Jason, from the experiment this is from I know that the C++ FE
distinguishes between CONVERT_EX
On Fri, Apr 29, 2022 at 12:13 PM Richard Biener
wrote:
>
> On Fri, Apr 29, 2022 at 11:53 AM Aldy Hernandez wrote:
> >
> > On Fri, Apr 29, 2022 at 9:09 AM Richard Biener
> > wrote:
> > >
> > > On Thu, Apr 28, 2022 at 8:44 PM Jeff Law via Gcc-patches
> > > wrote:
> > > >
> > > >
> > > >
> > > > O
Add .note.GNU-stack assembly source to avoid linker warning:
ld: warning: /tmp/ccPZSZ7Z.o: missing .note.GNU-stack section implies
executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future version
of the linker
FAIL: gcc.target/i386/iamcu/test_3_element_struct_and_u
On 28.04.22 19:17, Bernhard Reutner-Fischer wrote:
ISTM that this should be s/mod.e/mode./ ?
Yep, fixed as obvious and simple on trunk with
r13-49-g4a8b45e8bc8246bd141dad65f571a3e0cc499c6b .
OK for backport to gcc-12? (This is both extremely safe and
not particularly important :-)
Best regard
Normally we check for incomplete type in start_decl, but that obviously
doesn't work for auto variables. Thanks to Pokechu22 for the analysis and
testcases:
"When cp_finish_decl calls cp_apply_type_quals_to_decl on a const auto or
constexpr auto variable, the type might not be complete the first t
On 4/29/22 05:37, Richard Biener wrote:
This uses CASE_CONVERT more which eases eventual removal of NOP_EXPR.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK for trunk?
Jason, from the experiment this is from I know that the C++ FE
distinguishes between CONVERT_EXPR and NOP_EXPR at the
On 4/29/22 10:12, Marek Polacek wrote:
[dcl.dcl]/5 says that
enum { };
is ill-formed, and since r197742 we issue a pedwarn. However, the
pedwarn also fires for
enum { } x;
which is well-formed. So only warn when {} is followed by a ;. This
should be correct since you can't have "enu
On Friday, 29 April 2022 03:53:40 CEST Alexandre Oliva via Gcc-patches wrote:
> Thanks, awaiting feedback on the suggestion above to post the consolidated
> patch.
LGTM. I think this improves clarity for the __intrisic_type static assertions
significantly.
And don't bother with my other mail. If
On 4/27/22 19:48, Jason Merrill wrote:
On 4/27/22 13:02, Joseph Myers wrote:
On Wed, 27 Apr 2022, Jason Merrill via Gcc-patches wrote:
+ if (typedef_variant_p (type))
+ {
+ /* Set up the typedef all over again. */
This seems wrong when the typedef is just being used in another
On Fri, 29 Apr 2022, Jason Merrill via Gcc-patches wrote:
> Marek pointed out elsewhere that the first testcase should have
>
> // { dg-additional-options -g }
>
> OK for 13 with that change?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
the attached patch documents the support for IEEE long double for
Fortran. OK? Suggestions for better wording?
I'd like to get this in before the gcc12 release. It would also
qualify as obviously correct, I think :-) so I'll commit this
on Sunday unless there are any objections.
Patch at
The stage 4 patch limited direct propagation of dependent type to capture
field/proxy to the "current instantiation", but many more types should be
suitable as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* lambda.cc (type_deducible_expression_p): Allow more typ
In this testcase, we were trying to substitute into
variant>::__accepted_type, but failed to look it up because
variant> doesn't exist. In other cases we already rewrite such
things into a dependent reference; we need to do that for alias templates as
well.
This caused some testsuite regressions
The the different calling of check_explicit_specialization for class and
namespace scope friends bothered me, so this patch combines them.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/91618
PR c++/96604
gcc/cp/ChangeLog:
* friend.cc (do_friend): Call check_expli
On Fri, 29 Apr 2022 20:03:55 +0200
Thomas Koenig wrote:
> On 28.04.22 19:17, Bernhard Reutner-Fischer wrote:
> > ISTM that this should be s/mod.e/mode./ ?
>
> Yep, fixed as obvious and simple on trunk with
> r13-49-g4a8b45e8bc8246bd141dad65f571a3e0cc499c6b .
thanks!
>
> OK for backport to gc
Some tests check for fenv and then proceed to use fesetround() directly,
but some platforms (at least RISC-V soft-float) have fenv but don't
support rounding modes. This adds a DG check that fesetround() actually
functions, which is then used by all the tests that call fesetround()
explicitly.
gc
59 matches
Mail list logo
