__builtin_popcount and __builtin_ffs were sharing the same range-ops
entry, but the nonzero mask optimization is not valid for ffs.
Separate them out into two entries.
PR tree-optimization/107130
gcc/ChangeLog:
* gimple-range-op.cc (class cfn_popcount): Call op_cfn_ffs.
(
On 9/30/22 18:50, Iain Sandoe wrote:
Hi Jason,
On 30 Sep 2022, at 23:06, Jason Merrill wrote:
You can't use CONVERT_EXPR to convert between two class types, and it was
breaking copy elision.
Unfortunately, this patch breaks symmetric-transfer-00-basic.C, where
susp_type is Loopy::handle_type
Tested on x86_64-pc-linux-gnu, does this look OK for trunk? FWIW using
variant<_PatternIter, _InnerIter> in the implementation means we need to
include from , which increases the preprocessed size
of by 3% (51.5k vs 53k). I suppose that's an acceptable cost?
libstdc++-v3/ChangeLog:
*
On 10/3/22 16:32, Lewis Hyatt via Gcc-patches wrote:
This PR related to _Pragma locations and diagnostic pragmas was fixed by a
combination of r10-325 and r13-1596. Add missing test coverage.
gcc/testsuite/ChangeLog:
PR c/91669
* c-c++-common/pr91669.c: New test.
OK.
jeff
This is apparently needed since we include cp-trait.def from cp-tree.h
(in order to define the cp_trait_kind enum), as with operators.def.
Tested on x86_64-pc-linux-gnu by doing make install and verifying
cp-trait.def appears in
$prefix/lib/gcc/x86_64-pc-linux-gnu/13.0.0/plugin/include/cp/
Doe
This PR related to _Pragma locations and diagnostic pragmas was fixed by a
combination of r10-325 and r13-1596. Add missing test coverage.
gcc/testsuite/ChangeLog:
PR c/91669
* c-c++-common/pr91669.c: New test.
---
Notes:
Hello-
https://gcc.gnu.org/bugzilla/show_bug.
Fixes: 341573406b39
Don't subtract one from the result of strnlen() when trying to point
to the first character after the current string. This issue would
cause individual characters (where the 128 byte buffers are stitched
together) to be lost.
gcc/ChangeLog:
* config/aarch64/driver-aa
This brings the extensions detected by -mcpu=native on Ampere-1 systems
in sync with the defaults generated for -mcpu=ampere1.
Note that some kernel versions may misreport the presence of PAUTH and
PREDRES (i.e., -mcpu=native will add 'nopauth' and 'nopredres').
gcc/ChangeLog:
* config/a
On Fri, Sep 30, 2022 at 08:15:37PM +0800, Kewen.Lin wrote:
> on 2022/9/30 01:11, Segher Boessenkool wrote:
> >> +#ifdef OS_MISSING_POWERPC64
> >> + else if (OS_MISSING_POWERPC64)
> >> + /* It's unexpected to have OPTION_MASK_POWERPC64 on for OSes which
> >> + miss powerpc64 support, so di
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/status_cxx2020.xml: Update C++20 status.
* doc/html/manual/status.html: Regenerate.
---
libstdc++-v3/doc/html/manual/status.html | 9 ++---
libstdc++-v3/doc/xml/manual/status_cxx2020.xml | 15 +
On Mon, Oct 3, 2022 at 9:05 AM Sergei Trofimovich via Gcc-patches
wrote:
>
> On Thu, 22 Sep 2022 22:07:52 +0100
> Sergei Trofimovich wrote:
>
> > On Fri, 16 Sept 2022 at 19:49, Sergei Trofimovich wrote:
> > >
> > > From: Sergei Trofimovich
> > >
> > > i386-builtin-types.inc is included indirect
stdint.h is considered a freestanding headers by C, and a valid stdint.h
is required for certain parts of libstdc++' configuration, so we should
simply provide one when we have no other way (i.e. newlib or
user-specified sysroot) of getting one.
gcc/ChangeLog:
* config.gcc: --target=*-elf
On Fri, Sep 30, 2022 at 04:39:25PM -0400, Jason Merrill wrote:
> > * fold-const.h (simple_operand_p_2): Declare.
>
> This needs a better name if it's going to be a public interface.
>
> The usage also needs rationale for why this is the right predicate for
> assume, rather than just no-side-e
On Mon, 3 Oct 2022 at 17:51, François Dumont wrote:
>
> On 01/10/22 17:30, Jonathan Wakely wrote:
> > On Sat, 1 Oct 2022 at 11:43, François Dumont wrote:
> >> On 01/10/22 12:06, Jonathan Wakely wrote:
> >>> On Sat, 1 Oct 2022 at 08:20, François Dumont via Libstdc++
> >>> wrote:
> I had forg
On 01/10/22 17:30, Jonathan Wakely wrote:
On Sat, 1 Oct 2022 at 11:43, François Dumont wrote:
On 01/10/22 12:06, Jonathan Wakely wrote:
On Sat, 1 Oct 2022 at 08:20, François Dumont via Libstdc++
wrote:
I had forgotten to re-run tests after I removed the #define
_GLIBCXX_USE_CXX11_ABI 0.
The
Hi!
On Fri, Sep 23, 2022 at 11:49:24AM -0400, Olivier Hainque wrote:
> For a powerpc compiler configured with --with-abi=elfv2, an explicit
> -mabi option other than elfv1 fails to override the default.
>
> For example, after
>
> [...]/configure --enable-languages=c --target=powerpc-elf --with
> On Sep 30, 2022, at 1:39 PM, Martin Sebor wrote:
>
> On 9/28/22 13:17, Qing Zhao wrote:
>> Hi, Martin,
>> Thanks for the comments. And sorry for my late reply till now (I just came
>> back home from LPC, GNU Cauldron and then a one-week vacation after that…)
>>> On Sep 12, 2022, at 12:42 PM,
On 10/3/22 08:48, Patrick Palka wrote:
On Fri, 30 Sep 2022, Jason Merrill wrote:
On 9/30/22 11:14, Patrick Palka wrote:
On Thu, 29 Sep 2022, Jason Merrill wrote:
On 9/29/22 11:05, Patrick Palka wrote:
Adding a new builtin trait currently involves some boilerplate (as can
be seen in r13-2956
On 10/2/22 07:35, Jakub Jelinek wrote:
On Fri, Sep 30, 2022 at 04:39:25PM -0400, Jason Merrill wrote:
--- gcc/cp/decl.cc.jj 2022-09-22 00:14:55.478599363 +0200
+++ gcc/cp/decl.cc 2022-09-22 00:24:01.121178256 +0200
@@ -223,6 +223,7 @@ struct GTY((for_user)) named_label_entry
bool in_
On Fri, 30 Sept 2022 at 19:15, Jonathan Wakely wrote:
>
> On Fri, 30 Sept 2022 at 17:46, Arsen Arsenović via Libstdc++
> wrote:
> >
> > Hi,
> >
> > This patchset:
> > - Implements the P1642 WG21 paper, with a fair few extensions,
> > - Fixes libstdc++' build system on systems --without-headers,
>
On 9/29/22 17:35, Indu Bhagat wrote:
On 9/28/22 2:15 PM, Guillermo E. Martinez via Gcc-patches wrote:
Hello GCC team,
The following is patch v2 to update BTF/CTF backend supporting
BTF_KIND_ENUM64 type. Changes from v1:
+ Fix typo in commit message.
+ Fix changelog entries.
Comments
On 23/09/2022 09:43, Torbjörn SVENSSON via Gcc-patches wrote:
The cmse-15.c testcase fails at -Os because ICF means that we
generate
secure3:
b secure1
which is OK, but does not match the currently expected
secure3:
...
bx r[0-3]
gcc/testsuite/ChangeLog:
On 29/09/2022 14:46, Richard Biener wrote:
It's not the nicest way of carrying the information but short of inventing
new modes I can't see something better (well, another optab). I see
the GCN backend expects a constant in operand 3 but the docs don't
specify the operand has to be a CONST_INT,
I audited all the op1/op2 range for undefined values, but missed that an
intervening calculation can also cause an undefined range in the middle
of operator_plus::op1_range, and that is the passed to
adjust_op1_for_overflow. That routine also needs to check for
undefined before asking for the
C2x changes the definition of *_EPSILON to apply only to
normalized numbers. The effect is that LDBL_EPSILON for IBM long
double becomes 0x1p-105L instead of 0x1p-1074L.
There is a reasonable case for considering this a defect fix - it
originated from the issue reporting process (DR#467), though
On 03/10/2022 11:43, Christophe Lyon via Gcc-patches wrote:
Like the non-predicated vrev64q patterns, mve_vrev64q_m_
and mve_vrev64q_m_f need an early clobber constraint, otherwise
we can generate an unpredictable instruction:
Warning: 64-bit element size and same destination and source opera
On Fri, 30 Sep 2022, Jason Merrill wrote:
> On 9/30/22 11:14, Patrick Palka wrote:
> > On Thu, 29 Sep 2022, Jason Merrill wrote:
> >
> > > On 9/29/22 11:05, Patrick Palka wrote:
> > > > Adding a new builtin trait currently involves some boilerplate (as can
> > > > be seen in r13-2956-g9ca14715407
The latest libsanitizer import broke Solaris 11.3 bootstrap again, due
to an oversight of mine. A fix has been committed upstream
https://reviews.llvm.org/D133556
This patch cherry-picks it. Tested on Solaris 11.3 and 11.4, SPARC and
x86.
Approved by Martin in the PR, committed to trun
Tested x86_64-linux. Pushed to trunk.
-- >8 --
In C++23 mode these tests started to FAIL because an rvalue reference
parameter can no longer be bound to an lvalue reference return type. As
confirmed by Ville (who added these tests) the problem overloads are not
intended to be called, and only exi
On 9/29/22 22:31, Fangrui Song wrote:
> At some point binutils will want to remove --compress-debug-sections=zlib-gnu
> support as well.
> I think the message can drop mentioning of --compress-debug-sections=zlib-gnu.
Yes, makes sense and I'm going to push the documentation change.
Martin
There is no need to compare nonzero masks when comparing two VARYING
ranges, as they are always the same when range types are the same.
gcc/ChangeLog:
* value-range.cc (irange::legacy_equal_p): Remove nonozero mask
check when comparing VR_VARYING ranges.
---
gcc/value-range.cc |
Currently if we have a range of [0,0] and we set the nonzero bits to
1, the current code pessimizes the range to [0,1] because it assumes
the range is [1,1] plus the possibility of 0. This fixes the
oversight.
gcc/ChangeLog:
* value-range.cc (irange::set_nonzero_bits): Do not pessimize r
Committed as obvious.
gcc/ChangeLog:
* ipa-prop.cc (struct ipa_vr_ggc_hash_traits): Do not compare
incompatible ranges in ipa-prop.
---
gcc/ipa-prop.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
index ca5b9f31570..724
There is nothing else to compare when the number of sub-ranges is 0.
gcc/ChangeLog:
* value-range.cc (irange::operator==): Early bail on m_num_ranges
equal to 0.
---
gcc/value-range.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
Like the non-predicated vrev64q patterns, mve_vrev64q_m_
and mve_vrev64q_m_f need an early clobber constraint, otherwise
we can generate an unpredictable instruction:
Warning: 64-bit element size and same destination and source operands makes
instruction UNPREDICTABLE
when calling vrevq64_m* with
On Mon, 3 Oct 2022 at 10:29, Arsen Arsenović wrote:
>
> On Monday, 3 October 2022 10:37:00 CEST Jonathan Wakely wrote:
> > I did look into this after you pointed it out on IRC. Unless I fumbled
> > my doxygen roll, the results are the same for /// and ///< so maybe
> > at some point Doxygen started
On Monday, 3 October 2022 10:37:00 CEST Jonathan Wakely wrote:
> I did look into this after you pointed it out on IRC. Unless I fumbled
> my doxygen roll, the results are the same for /// and ///< so maybe
> at some point Doxygen started to DTRT even without the < character.
It is actually unchang
Hello,
Le 02/10/2022 à 22:07, Thomas Koenig via Fortran a écrit :
I am a bit stuck of how to generate a reference to the first element
of the array (really, just dereferencing the data pointer)
in the most elegant way. I am currently leaning towards
building a gfc_expr, which should work, but
On Sat, 1 Oct 2022 at 19:43, Arsen Arsenović via Libstdc++
wrote:
>
> I accidentally that some variables were misdocumented when using
> trailing comment for documentation. I ran a search with a relatively
> simple regex[1] to look for any ///s following some code that did not
> have a <, and cam
On Thu, 22 Sep 2022 22:07:52 +0100
Sergei Trofimovich wrote:
> On Fri, 16 Sept 2022 at 19:49, Sergei Trofimovich wrote:
> >
> > From: Sergei Trofimovich
> >
> > i386-builtin-types.inc is included indirectly via i386-builtins.h
> > into 4 files: i386.cc i386-builtins.cc i386-expand.cc i386-featu
40 matches
Mail list logo
