On Thu, 8 Apr 2021, Maciej W. Rozycki wrote:
> > Does the patch also help to optimise my example above? If so,
> > it sounds like a good thing for that reason alone.
>
> Nope, it actually regresses code produced, causing an extra instruction
> to be used where it doesn't have to:
>
> ---
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h: Tweak doxygen comment.
Tested powerpc64le-linux. Committed to trunk.
commit 96292c3e3439aa167ed7ae595f89b8776e705897
Author: Jonathan Wakely
Date: Thu Apr 8 23:39:29 2021
libstdc++: Remove spurious line break in doxygen
The C front end ordinarily merges function type attributes upon
the redeclaration of a function but it doesn't do that for those
at local scope, unless the declaration refers to a built-in.
Because the new -Warray-parameter warning relies on the internal
access attribute on the type of the
On Thu, 25 Mar 2021, Richard Sandiford wrote:
> "Maciej W. Rozycki" writes:
> > On Wed, 26 Aug 2020, Vladimir Makarov via Gcc-patches wrote:
> >
> >> On 2020-08-26 5:06 a.m., Richard Sandiford wrote:
> >> >
> >> > I don't think we should we restrict this to (plus (mult X Y) Z),
> >> > since
On Thu, 8 Apr 2021, Jason Merrill wrote:
> On 4/7/21 12:10 PM, Patrick Palka wrote:
> > We currently substitute through a lambda's constraints whenever we
> > regenerate it via tsubst_lambda_expr. This is the wrong approach
> > because it can lead to hard errors due to constraints being
On Thu, Apr 08, 2021 at 04:37:00PM -0400, Patrick Palka wrote:
> On Thu, 8 Apr 2021, Marek Polacek via Gcc-patches wrote:
>
> > When we have a member function with auto parameter like this:
> >
> > struct S {
> > void f(auto);
> > };
> >
> > cp_parser_member_declaration -> grokfield
If pdflatex runs out of memory the build fails with no hint what's
wrong. This adds another grep command to the makefile so that an
out-of-memory error will result in more information being shown.
As suggested in https://bugzilla.redhat.com/show_bug.cgi?id=1841056
using lualatex can be used as a
On 06/04/21 16:54 +0100, Jonathan Wakely wrote:
A change in Doxygen 1.8.16 means that "// @}" is no longer recognized by
Doxygen, so doesn't close a @{ group. A "///" comment needs to be used.
There are a few cases of /* @} */ which need a similar fix.
Tested powerpc64le-linux. Committed to
On Thu, 8 Apr 2021, Marek Polacek via Gcc-patches wrote:
> When we have a member function with auto parameter like this:
>
> struct S {
> void f(auto);
> };
>
> cp_parser_member_declaration -> grokfield produces a FUNCTION_DECL
> "void S::foo(auto:1)", and then
When we have a member function with auto parameter like this:
struct S {
void f(auto);
};
cp_parser_member_declaration -> grokfield produces a FUNCTION_DECL
"void S::foo(auto:1)", and then finish_fully_implicit_template turns
that FUNCTION_DECL into a TEMPLATE_DECL. The bug here is that
Hi!
When looking into PR99420, I have noticed several comment typos.
Fixed thusly, committed to trunk as obvious.
2021-04-08 Jakub Jelinek
* c-warn.c (do_warn_double_promotion): Fix comment typo,
occured -> occurred.
(check_alignment_of_packed_member): Fix a comment
This puts the logic for the noexcept-specifier in one place, and then
reuses it elsewhere. This means checking whether the move constructor
can throw doesn't need to do overload resolution and then check whether
some other constructor can throw, we just get the answer directly.
Here we were complaining about binding the lvalue reference to the rvalue
result of converting from float to int, but didn't mention that conversion.
Talk about the type of the initializer instead.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/91849
*
The comment for a peephole provided for the `*bit' pattern to be
produced in comparison elimination from a sequence involving a bitwise
complement operation of one input operand followed by a bitwise AND
operation between a bitwise complement of said intermediate result and
the other input
On 4/7/21 12:10 PM, Patrick Palka wrote:
We currently substitute through a lambda's constraints whenever we
regenerate it via tsubst_lambda_expr. This is the wrong approach
because it can lead to hard errors due to constraints being evaluated
out of order (as in the testcase concepts-lambda17.C
Hi, Kees,
Thanks a lot for your testing on the linux kernel, I am so happy that this time
it works well.
> On Apr 7, 2021, at 5:19 PM, Kees Cook wrote:
>
> On Wed, Mar 24, 2021 at 04:21:49PM -0500, Qing Zhao wrote:
>> This is the 2nd version of the patch for the new security feature for GCC.
On 4/8/2021 8:06 AM, Richard Sandiford via Gcc-patches wrote:
The sve/vcond_3.c tests had started to fail after PR97690/99305,
because we were generating:
a = VEC_COND_EXPR ;
b = a << 15;
instead of:
a = VEC_COND_EXPR ;
We already have a match.pd rule to handle this kind of thing,
On 4/8/2021 8:08 AM, Richard Sandiford via Gcc-patches wrote:
Some AArch64 tests force -mbig-endian and indirectly include stdint.h.
However, not all OSes support both endiannesses, leading to:
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_get-be.c -O0 (test for
excess errors)
On 4/8/2021 8:09 AM, Richard Sandiford via Gcc-patches wrote:
scan-lto-assembler was looking for the old dump names instead of
the new ones. There are only two uses of this:
gcc.target/nios2/custom-fp-lto.c
gcc.target/aarch64/pr70044.c
Both of them use single source files, so I
This works around the remaining reported execution FAILs of this test on
AIX, Solaris and Darwin. Eventually we should rewrite this test to be
less fragile, but there's not enough time to do that for GCC 11.
Tested on AIX, Solaris and x86_64-pc-linux-gnu, committed to trunk as
"obvious".
On 4/7/21 5:33 PM, Patrick Palka wrote:
In the testcase below, we're crashing during constraint checking of the
implicitly generated deduction guides for the nested class template A::B
because we never substitute the outer template arguments (for A) into
the constraint, neither ahead of time nor
On 4/8/21 5:36 AM, Jakub Jelinek wrote:
When cxx_bind_parameters_in_call is called e.g. on a method on an automatic
variable, we evaluate the argument and because ADDR_EXPR of an automatic
decl is not TREE_CONSTANT, we set *non_constant_args and don't cache it.
But when it is called on an object
scan-lto-assembler was looking for the old dump names instead of
the new ones. There are only two uses of this:
gcc.target/nios2/custom-fp-lto.c
gcc.target/aarch64/pr70044.c
Both of them use single source files, so I think they both want
the same behaviour.
Tested on aarch64-linux-gnu.
Some AArch64 tests force -mbig-endian and indirectly include stdint.h.
However, not all OSes support both endiannesses, leading to:
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_get-be.c -O0 (test for
excess errors)
UNRESOLVED: gcc.target/aarch64/advsimd-intrinsics/bf16_get-be.c -O1
The sve/vcond_3.c tests had started to fail after PR97690/99305,
because we were generating:
a = VEC_COND_EXPR ;
b = a << 15;
instead of:
a = VEC_COND_EXPR ;
We already have a match.pd rule to handle this kind of thing,
but it didn't handle shifts.
Tested on aarch64-linux-gnu. OK to
pr99102.c needs to override the default options to exercise the original
problem, but that means that it also needs to respecify the dump flags.
Tested on aarch64-linux-gnu, pushed to trunk as obvious.
Richard
gcc/testsuite/
* gcc.dg/vect/pr99102.c: Add -fdump-tree-vect-details.
---
The “previous definition of 'x'” notes now include the type
of the original definition before “was here”. There's not really
any need to hard-code that much of the message in the ACLE tests,
so this patch just removes the “was here” from the match string.
Tested on aarch64-linux-gnu, pushed to
This patch just adds some missing +nosve directives to Advanced
SIMD vectorisation tests.
Tested on aarch64-linux-gnu, pushed to trunk.
Richard
gcc/testsuite/
* gcc.target/aarch64/asimd-mull-elem.c: Add +nosve.
* gcc.target/aarch64/pr98772.c: Likewise.
*
Some sve/mul_2.c tests were failing because we'd (reasonably)
decided to use shifts and adds instead of MULs for some simple
negative constants. We'd already needed to avoid that when
picking positive constants, so this patch does the same thing
for the negative ones.
Tested on
This allows the docs to be generated on hosts without the necessary
files present for multilib support.
maintainer-scripts/ChangeLog:
* generate_libstdcxx_web_docs: Add --disable-multilib to
configure command.
Tested x86_64-linux. Committed to trunk.
commit
libstdc++-v3/ChangeLog:
* include/std/string_view: Adjust Doxygen @file comment.
Tested x86_64-linux. Committed to trunk.
commit 2c1557ac7b7652c63418abac1a1c4b7a9860a9f9
Author: Jonathan Wakely
Date: Thu Apr 8 14:47:47 2021
libstdc++: Fix Doxygen warning about ambiguous file
Prior to this patch, program_state::detect_leaks worked by finding all
live svalues in the old state and in the new state, and calling
on_svalue_leak for each svalue that has changed from being live to
not being live.
PR analyzer/99042 and PR analyzer/99774 both describe false leak
diagnostics
This patch updates the GCC attribute support in the D front-end to have
a baseline parity with the LLVM D compiler's own `ldc.attributes'.
The handler that extracts GCC attributes from a list of UDAs has been
improved to take care of some mistakes that could have been warnings.
UDAs attached to
On 29/03/21 10:33 -0400, Patrick Palka via Libstdc++ wrote:
This rewrites our range adaptor implementation for more comprehensible
error messages, improved SFINAE behavior and conformance to P2281.
The diagnostic improvements mostly come from using appropriately named
functors instead of
On 11/03/21 18:51 +0100, François Dumont via Libstdc++ wrote:
I eventually prefer to propose this version.
Compared to the previous one I have the _M_can_advance calling the
former one with correct number of elements to check for advance. And
the former _M_can_advance is also properly making
Pushed to master.
maintainer-scripts/ChangeLog:
* branch_changer.py: Modernize and fix flake8 issues.
* setup.cfg: New file.
---
maintainer-scripts/branch_changer.py | 70
maintainer-scripts/setup.cfg | 5 ++
2 files changed, 45
Status
==
GCC 10.3.0 tarballs have been generated and uploaded and the
GCC 10 branch is again open for regression and documentation fixes.
Quality Data
Priority # Change from last report
--- ---
P1
P2
We were telling users they needed more template<> to specialize a member
template in a testcase with no member templates. Only produce that message
if we actually see a member template, and also always print the candidates.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
On 20/03/21 09:18 -0500, Tim Song wrote:
On Sat, Mar 20, 2021 at 3:58 AM Jonathan Wakely wrote:
On Sat, 20 Mar 2021, 01:13 Tim Song via Libstdc++,
wrote:
On Fri, Mar 19, 2021 at 3:13 PM Jonathan Wakely via Libstdc++
wrote:
>
> Implement this C++23 feature, as proposed by P1048R1.
>
>
> Change the preprocessor logic so RTEMS uses utime().
> gcc/ada/
> * adaint.c (__gnat_copy_attribs): RTEMS should use utime().
This change is OK.
> ---
> gcc/ada/adaint.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
>
On Thu, Apr 8, 2021 at 11:24 AM Martin Jambor wrote:
>
> Hi,
>
> When IPA-SRA removes an SSA_NAME from a LHS of a call statement
> because it is not necessary, it does not release it. This patch fixes
> that.
>
> Bootstrapped and tested on x86_64, at some point I'll LTO-bootstrap it
> too. I
Hi!
When cxx_bind_parameters_in_call is called e.g. on a method on an automatic
variable, we evaluate the argument and because ADDR_EXPR of an automatic
decl is not TREE_CONSTANT, we set *non_constant_args and don't cache it.
But when it is called on an object located on the heap (allocated using
Hi!
The following testcase is miscompiled on x86_64-linux.
expand_compound_operation is called on
(zero_extract:DI (mem/c:TI (reg/f:DI 16 argp) [3 i+0 S16 A128])
(const_int 16 [0x10])
(const_int 63 [0x3f]))
so mode is DImode, inner_mode is TImode, pos 63, len 16 and modewidth 64.
A
Hi,
When IPA-SRA removes an SSA_NAME from a LHS of a call statement
because it is not necessary, it does not release it. This patch fixes
that.
Bootstrapped and tested on x86_64, at some point I'll LTO-bootstrap it
too. I assume this is GCC 12 material, so OK once stage 1 opens?
Thanks,
ping
On Tue, Mar 16, 2021 at 06:13:21PM +0100, Stefan Schulze Frielinghaus wrote:
> [snip]
>
> Please find attached a new version of the patch. A major change compared to
> the previous patch is that I created a separate pass which hopefully makes
> reviewing also easier since it is almost
> -Original Message-
> From: Alex Coplan
> Sent: 07 April 2021 14:15
> To: gcc-patches@gcc.gnu.org
> Cc: ni...@redhat.com; Richard Earnshaw ;
> Ramana Radhakrishnan ; Kyrylo
> Tkachov ; Richard Sandiford
>
> Subject: [PATCH v2] arm: Various MVE vec_duplicate fixes [PR99647]
>
> Hi,
>
46 matches
Mail list logo
