On 3/25/20 5:36 PM, Marek Polacek wrote:
On Wed, Mar 25, 2020 at 12:00:24AM -0400, Jason Merrill wrote:
On 3/24/20 11:45 AM, Marek Polacek wrote:
On Mon, Mar 23, 2020 at 10:41:28AM -0400, Jason Merrill wrote:
On 3/20/20 7:02 PM, Marek Polacek wrote:
On Fri, Mar 20, 2020 at 02:12:49PM -0400,
On 3/23/20 12:50 PM, Martin Sebor wrote:
On 3/23/20 8:49 AM, Jason Merrill wrote:
On 3/21/20 5:59 PM, Martin Sebor wrote:
+ /* Diagnose class/struct/union mismatches. IS_DECLARATION is
false
+ for alias definition. */
+ bool decl_class = (is_declaration
+ &&
This contains the necessary sysroot flags if configured with
--with-build-sysroot, and matches the corresponding value for CC
in POSTSTAGE1_HOST_EXPORTS.
2020-03-25 Michael Forney
* Makefile.tpl (POSTSTAGE1_HOST_EXPORTS): Add XGCC_FLAGS_FOR_TARGET
and TFLAGS to CXX.
*
The attached patch fixes a bug I found in the C++ front end's handling
of OpenACC data clauses. The problem here is that the C++ front end
wraps the array bounds expressions in NON_LVALUE_EXPR tree nodes, and
the code here (which appears to have been copied from similar code in
the C front
From: Xionghu Luo
This P1 bug is exposed by FRE refactor of r263875. Comparing the fre
dump file shows no obvious change of the segment fault function proves
it to be a target issue.
frame_pointer_needed is set to true in reload pass setup_can_eliminate,
but regs_ever_live[31] is false, so
Hi,
I am pinging this because PR 91614 has been raised to P2 now:
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg00370.html
Thanks
Bernd.
On 9/6/19 2:12 PM, Bernd Edlinger wrote:
> On 9/5/19 5:55 PM, Richard Earnshaw (lists) wrote:
>> On 03/09/2019 21:45, Bernd Edlinger wrote:
>>> Hi,
On Wed, 25 Mar 2020, Jeff Law via Gcc-patches wrote:
The patch you sent, as well as what you committed as r10-7383,
was just a ChangeLog entry.
> Bootstrapped on sh4-linux-gnu and sh4eb-linux-gnu. Regression testing in
> progress (won't finish for ~12 hours). No new test as it's covered by
Hi!
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, March 24, 2020 10:14 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [RFC] Should widening_mul should consider block frequency?
>
> > > As written in the PR I'd
On 25.03.2020 23:36, Jeff Law wrote:
> On Wed, 2020-03-18 at 20:29 +0100, Kamil Rytarowski wrote:
>> Set /tmp first, then /var/tmp. /tmp is volatile on NetBSD and
>> /var/tmp not. This improves performance in the common use.
>> The downstream copy of GCC was patched for this preference
>> since
On Wed, 2020-01-29 at 18:32 +0300, Alexander Monakov wrote:
> On Tue, 28 Jan 2020, Jeff Law wrote:
>
> > On Tue, 2019-10-08 at 18:04 +0300, Alexander Monakov wrote:
> > > On Thu, 3 Oct 2019, Jeff Law wrote:
> > >
> > > > You may want to review the 2018 discussion:
> > > >
> > > >
On Mon, 2019-12-30 at 00:46 +0100, Jakub Jelinek wrote:
> Hi!
>
> The AVX512F documentation clearly states that in instructions where the
> destination is a memory only merging-masking is possible, not zero-masking,
> and the assembler enforces that.
>
> The testcase in this patch fails to
On Mon, 2020-02-10 at 19:22 +0300, Paul Gofman wrote:
> ChangeLog:
> PR target/91489
> * config/i386/i386.md (simple_return): Also check
> for ms_hook_prologue function attribute.
> * config/i386/i386.c (ix86_can_use_return_insn_p):
> Also check for ms_hook_prologue
On Mon, 2020-03-09 at 11:55 +0300, Nicholas Guriev wrote:
> gcc/c-family/ChangeLog:
>
> PR pch/86674
> * c-pch.c (c_common_valid_pch): Use cpp_warning with CPP_W_INVALID_PCH
> reason to fix -Werror=invalid-pch and -Wno-error=invalid-pch switches.
THanks. This looks pretty
On Wed, 2020-03-18 at 20:29 +0100, Kamil Rytarowski wrote:
> Set /tmp first, then /var/tmp. /tmp is volatile on NetBSD and
> /var/tmp not. This improves performance in the common use.
> The downstream copy of GCC was patched for this preference
> since 2015.
>
> Remove occurence of /usr/tmp as it
On Fri, 2020-03-20 at 11:04 +0100, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> With this simple patch, on i686-linux and x86_64-linux with -m32 (no change
> for -m64), the find_base_term visited_vals.length () > 100 find_base_term
> statistics changed (fbt is before this patch, fbt2 with this
On Wed, 2020-03-25 at 15:46 -0600, Martin Sebor via Gcc-patches wrote:
> PR 61339 - mismatch between struct and class [-Wmismatched-tags]
>
> ChangeLog:
>
> * htdocs/codingconventions.html (Struct Definitions): Remove
> old convention.
> (Class Definitions): Same.
> *
For C++20 the wait_until members of mutexes and condition variables are
required to be ill-formed if given a clock that doesn't meet the
requirements for a clock type. To implement that requirement this patch
adds static assertions using the chrono::is_clock trait, and defines
that trait.
To
These tests were supposed to be committed as part of r278904 (aka
b789efeae8c0620b83f25e4a0757c4871e02ab5f) but I didn't 'git add' them.
* testsuite/30_threads/shared_timed_mutex/try_lock_until/1.cc: New
test.
* testsuite/30_threads/shared_timed_mutex/try_lock_until/2.cc:
On 3/16/20 4:41 PM, Martin Sebor wrote:
The recent fix to avoid modifying in place the type argument in
handle_access_attribute (PR 92721) was incomplete and didn't fully
resolve the problem (an ICE in the C++ front-end). The attached
patch removes the remaining modification that causes the
Last July we agreed to remove the convention that declarations of
POD classes use the class-key struct (and others class). Attached
is a patch to update the GCC Coding Conventions and the rationale
to reflect the decision. I replaced it with a mild suggestion to
use struct for C structs and
Nathan Sidwell wrote:
> On 3/24/20 2:08 PM, Iain Sandoe wrote:
>
>>tree suspend = TREE_VEC_ELT (awaiter_calls, 1); /* await_suspend(). */
>> + tree susp_type;
>> + if (tree fndecl = cp_get_callee_fndecl_nofold (suspend))
>> +susp_type = TREE_TYPE (TREE_TYPE (fndecl));
>> + else
>> +
On Wed, Mar 25, 2020 at 12:00:24AM -0400, Jason Merrill wrote:
> On 3/24/20 11:45 AM, Marek Polacek wrote:
> > On Mon, Mar 23, 2020 at 10:41:28AM -0400, Jason Merrill wrote:
> > > On 3/20/20 7:02 PM, Marek Polacek wrote:
> > > > On Fri, Mar 20, 2020 at 02:12:49PM -0400, Jason Merrill wrote:
> > >
This adjusts the testsuite expectations for amdgcn. This reflects some
of the recent improvements to the backend.
There's one new failure because GCN can't vectorize division natively
(and there's no libgcc routine yet), but there's 24 fails turned to passes.
Andrew
testsuite: adjustments
Ping: Jason, is the latest patch acceptable or are there any other
changes you want me to make?
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542538.html
On 3/21/20 3:59 PM, Martin Sebor wrote:
On 3/20/20 3:53 PM, Jason Merrill wrote:
On 3/19/20 7:55 PM, Martin Sebor wrote:
On
Thanks for the suggestion to use type_cache_hasher::equal. I'll
revisit the idea of adding an assertion to decl_attribute in
stage 1 and will look into using it there.
Until then, unless you or anyone else has any concerns with
the original patch I will plan to commit tomorrow:
On 3/25/20 3:29 PM, Jakub Jelinek wrote:
Hi!
The standard says: "A function is user-provided if it is user-declared and
not explicitly defaulted or deleted on its first declaration."
I don't see anything about function templates having different rules here,
but user_provided_p does return true
Whee, more fallout from the pr90275 changes. Thankfully this time it's a target
issue.
The sh4/sh4eb ports are failing vector-compare-1 execution tests after the cse
changes. They only run once a week, so this wasn't caught immediately and took
some time to reproduce and analyze.
Ultimately
On Wed, Mar 25, 2020 at 11:07:04AM -0500, will schmidt wrote:
> Subject: [Patch v327] set -mcprel by default ...
>
> Include some powerpc or rs6000 reference in the subject. My filters
> missed this one. (I'm assuming this is powerpc target specific).
rs6000: Enable pcrel by default (etc.)
Unlike ELF, named sections such as .bss.* and .gnu.linkonce.b.* have no
special meaning in COFF, therefore they will have the CONTENTS and LOAD
attributes set. The result is that these sections take up space in
object files and executables. These attributes can be cleared by
emitting the "b"
Hi,
Iain Sandoe wrote:
> This is the first of two remaining changes needed to bring the GCC
> implementation into line with the standard draft at n4849.
Here is a revised version with the “initial await resume called” variable
renamed to be more consistent, as we discussed off-list.
OK for
Hi!
The standard says: "A function is user-provided if it is user-declared and
not explicitly defaulted or deleted on its first declaration."
I don't see anything about function templates having different rules here,
but user_provided_p does return true for all TEMPLATE_DECLs.
The following
On 3/24/20 3:58 AM, Jakub Jelinek wrote:
+ for (i = tsi_start (stmt); !tsi_end_p (i); tsi_next ())
+ {
+ tree t = tsi_stmt (i);
+ if (TREE_CODE (t) != DEBUG_BEGIN_STMT && nondebug_stmts < 2)
+ nondebug_stmts++;
+ cp_walk_tree
Hi all!
Proposed patch to:
Bug 94327 - Bind(c) argument attributes are incorrectly set
and to:
Bug 94331 - Bind(C) corrupts array descriptors
Patch tested only on x86_64-pc-linux-gnu.
Sorry for the double patch but applying them separately would break things.
Fixing 94327 is simple, just
On 3/25/20 12:17 PM, Patrick Palka wrote:
This PR reports that the requires-expression in
auto f = [] { };
static_assert(requires { f(); });
erroneously evaluates to false. The way we end up evaluating to false goes as
follows. During the parsing of the requires-expression, we call
Hello,
For the following MVE ACLE intrinsics, polymorphic variant supports only +mve
option,
support for +mve.fp is missing.
vabavq_p_s16, vabavq_p_s32, vabavq_p_s8, vabavq_p_u16, vabavq_p_u32,
vabavq_p_u8,
vabavq_s16, vabavq_s32, vabavq_s8, vabavq_u16, vabavq_u32, vabavq_u8,
vaddlvaq_p_s32,
On 3/25/20 8:52 AM, Patrick Palka wrote:
This simplifies conditions that test both value_dependent_expression_p and
type_dependent_expression_p, since the former predicate now subsumes the latter.
Tested on x86_64-pc-linux-gnu, does this look OK?
I'm still a bit uneasy about testing
On 25/03/2020 07:21, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> The following testcase ICEs, because arm_gen_discompare_reg creates invalid
> RTL which then propagates into DEBUG_INSNs and ICEs while handling them.
> The problem is that this function emits
> (insn 18 17 19 2 (set (reg:CC_DNE
On 2020/2/28 9:18 AM, Maciej W. Rozycki wrote:
Fix a problem with commit c8e759b4215b ("libgomp/test: Fix compilation
for build sysroot") that caused a regression in some standalone test
environments where testsuite/libgomp-test-support.exp is used, but the
compiler is expected to be determined
Hi!
On 2018-02-22T12:23:25+0100, Tom de Vries wrote:
> when using cuda 9 nvprof with an openacc executable, the executable hangs.
>
> The scenario resulting in the hang is as follows:
> 1. goacc_lazy_initialize calls gomp_mutex_lock (_device_lock)
> 2. goacc_lazy_initialize calls acc_init_1
> 3.
On Wed, 25 Mar 2020, Marek Polacek wrote:
> On Wed, Mar 25, 2020 at 12:17:41PM -0400, Patrick Palka via Gcc-patches wrote:
> > diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> > index 03ecd7838f6..14a22b85318 100644
> > --- a/gcc/cp/parser.c
> > +++ b/gcc/cp/parser.c
> > @@ -27689,7 +27689,12 @@
On Wed, 2020-03-25 at 10:41 -0600, Martin Sebor wrote:
> On 3/25/20 9:40 AM, Jeff Law wrote:
> > On Tue, 2020-03-17 at 19:35 -0600, Martin Sebor via Gcc-patches wrote:
> > > PR tree-optimization/94131 - ICE on printf with a VLA string and
> > > -fno-tree-
> > > ccp
> > >
> > >
On 3/25/20 9:40 AM, Jeff Law wrote:
On Tue, 2020-03-17 at 19:35 -0600, Martin Sebor via Gcc-patches wrote:
PR tree-optimization/94131 - ICE on printf with a VLA string and -fno-tree-ccp
gcc/testsuite/ChangeLog:
PR tree-optimization/94131
* gcc.dg/pr94131.c: New test.
On Wed, Mar 25, 2020 at 12:17:41PM -0400, Patrick Palka via Gcc-patches wrote:
> diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> index 03ecd7838f6..14a22b85318 100644
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -27689,7 +27689,12 @@ cp_parser_requires_expression (cp_parser *parser)
>
This PR reports that the requires-expression in
auto f = [] { };
static_assert(requires { f(); });
erroneously evaluates to false. The way we end up evaluating to false goes as
follows. During the parsing of the requires-expression, we call
finish_call_expr from
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the French team of translators. The file is available at:
https://translationproject.org/latest/gcc/fr.po
(This file,
Hi,
Comments inline.
(Taking a pass with focus on cosmetic stuff. This is intended to help Segher
focus on the harder parts :-) ).
On Mon, 2020-03-23 at 16:38 -0400, Michael Meissner via Gcc-patches wrote:
Subject: [Patch v327] set -mcprel by default ...
Include some powerpc or rs6000
On 3/25/20 8:52 AM, Patrick Palka wrote:
This fixes a false-positive warning from -Wduplicate-cond in the presence of an
if-statement with a non-empty init-statement. Precisely determining whether a
non-empty init-statement has side effects seems tricky and error-prone, so this > patch takes
On Wed, 25 Mar 2020, Marek Polacek wrote:
> On Wed, Mar 25, 2020 at 08:52:47AM -0400, Patrick Palka via Gcc-patches wrote:
> > This fixes a false-positive warning from -Wduplicate-cond in the presence
> > of an
> > if-statement with a non-empty init-statement. Precisely determining
> > whether
On Tue, 2020-03-17 at 19:35 -0600, Martin Sebor via Gcc-patches wrote:
> PR tree-optimization/94131 - ICE on printf with a VLA string and -fno-tree-ccp
>
> gcc/testsuite/ChangeLog:
>
> PR tree-optimization/94131
> * gcc.dg/pr94131.c: New test.
>
> gcc/ChangeLog:
>
> PR
I've checked in this trivial patch to fix another test failure I found
on nios2-elf, due to the BSP we use for simulator testing on this target
not having support for argc/argv. This testcase doesn't actually use
any command-line arguments and I think just does the argc test to avoid
On Wed, Mar 25, 2020 at 08:52:46AM -0400, Patrick Palka via Gcc-patches wrote:
> This simplifies conditions that test both value_dependent_expression_p and
> type_dependent_expression_p, since the former predicate now subsumes the
> latter.
>
> Tested on x86_64-pc-linux-gnu, does this look OK?
On Wed, Mar 25, 2020 at 08:52:47AM -0400, Patrick Palka via Gcc-patches wrote:
> This fixes a false-positive warning from -Wduplicate-cond in the presence of
> an
> if-statement with a non-empty init-statement. Precisely determining whether a
> non-empty init-statement has side effects seems
Hello,
ping for patch https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00554.html
Regards,
Paul.
On 2/21/20 12:10, Paul Gofman wrote:
> Hello,
>
> ping for patch https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00554.html.
>
> Thanks,
> Paul.
>
> On 2/10/20 19:22, Paul Gofman wrote:
On 3/20/20 10:54 AM, Iain Sandoe wrote:
diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index a943ba01de6..bcf3514bbcf 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -1348,6 +1348,7 @@ struct coro_aw_data
tree actor_fn; /* Decl for context. */
tree coro_fp;
Hi
This fixes a typo spotted by static analysis.
tested on x86_64-darwin, applied to master as obvious
thanks
Iain
gcc/cp/ChangeLog:
2020-03-25 Iain Sandoe
PR c++/94319
* coroutines.cc (captures_temporary): Fix a missing dereference.
diff --git
This fixes a false-positive warning from -Wduplicate-cond in the presence of an
if-statement with a non-empty init-statement. Precisely determining whether a
non-empty init-statement has side effects seems tricky and error-prone, so this
patch takes the route of unconditionally invalidating the
This simplifies conditions that test both value_dependent_expression_p and
type_dependent_expression_p, since the former predicate now subsumes the latter.
Tested on x86_64-pc-linux-gnu, does this look OK?
gcc/cp/ChangeLog:
* decl.c (compute_array_index_type_loc): Remove redundant
On 3/24/20 2:08 PM, Iain Sandoe wrote:
tree suspend = TREE_VEC_ELT (awaiter_calls, 1); /* await_suspend(). */
+ tree susp_type;
+ if (tree fndecl = cp_get_callee_fndecl_nofold (suspend))
+susp_type = TREE_TYPE (TREE_TYPE (fndecl));
+ else
+susp_type = TREE_TYPE (suspend);
Why,
On 3/25/20 11:59 AM, Martin Liška wrote:
Hi.
It's error that I caused by the recent update to zstd detection.
The patch fixes situation where zstd is missing and user doesn't provide
--with-zstd option.
Ready for master?
Installed as it blocks bootstrap as 68c4570a4de.
Martin
Thanks,
Hi.
It's error that I caused by the recent update to zstd detection.
The patch fixes situation where zstd is missing and user doesn't provide
--with-zstd option.
Ready for master?
Thanks,
Martin
gcc/ChangeLog:
2020-03-25 Martin Liska
PR lto/94259
* configure.ac: Report
On Wed, 25 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> As this test produces different code depending on whether
> __GCC_HAVE_DWARF2_CFI_ASM macro is defined or not, it is inherently
> incompatible with -fcompare-debug, as with
> -fcompare-debug -fno-asynchronous-unwind-tables -fno-exceptions
> the
On Wed, Mar 25, 2020 at 9:05 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following patch ICEs due to my recent change r10-6451-gb7b3378f91c.
> Since that patch, for explicit vzeroupper in the sources (when an intrinsic
> is used), we start with the *avx_vzeroupper_1 pattern which contains just the
>
On Wed, Mar 25, 2020 at 10:41:57AM +0100, Tobias Burnus wrote:
> Hence, I in my opinion the comment should be:
> "! The compiler_options() function is dependent" …
>
> OK with that change, unless compiler_version() indeed
> makes a difference – but then I would like to understand why.
You're
Hi Jakub,
thanks for the patch and to Martin for doing all the testing.
However, I fail so see why "compiler_version" should be
dependent on the debug flag. In the code, it is just:
"GCC version %s", version_string);
Hence, I in my opinion the comment should be:
"! The compiler_options()
Hi!
These 3 tests use compiler_version() and/or compiler_options() functions,
which are inherently incompatible with -fcompare-debug compilation, as they
emit into a string literal in the assembly the exact f951 command line
options, which differs between the two compilations with
Hi!
As this test produces different code depending on whether
__GCC_HAVE_DWARF2_CFI_ASM macro is defined or not, it is inherently
incompatible with -fcompare-debug, as with
-fcompare-debug -fno-asynchronous-unwind-tables -fno-exceptions
the macro is defined only in the -g case and not otherwise.
Hi Carl,
Sorry I didn't reply to this patch yet :-(
On Wed, Feb 19, 2020 at 08:16:13AM -0800, Carl Love wrote:
> The implemented argument order for the vec_rlnm() builtin for PPC64 is
> wrong. The following bugzilla was created for the issue:
>
>
On Tue, Mar 24, 2020 at 9:30 AM Kewen.Lin wrote:
>
> Hi,
>
> on 2020/3/18 下午11:10, Richard Biener wrote:
> > On Wed, Mar 18, 2020 at 2:56 PM Kewen.Lin wrote:
> >>
> >> Hi Richi,
> >>
> >> Thanks for your comments.
> >>
> >> on 2020/3/18 下午6:39, Richard Biener wrote:
> >>> On Wed, Mar 18, 2020 at
On Wed, 25 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled, because output_constructor doesn't
> output the initializer correctly. The FE creates {[1...2] = 9} in this
> case, and we emit .long 9; long 9; .zero 8 instead of the expected
> .zero 8; .long 9; .long
On Wed, 25 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, we don't guarantee DECL_UID to be the same between
> corresponding decls in -g and -g0 builds, -g can create more decls and all
> that is guaranteed is that the DECL_UIDs of the corresponding decls compare
> the same.
>
On Wed, 25 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled, because there is a buffer overflow
> in push_partial_def in the little-endian case when working 64-byte vectors.
> The code computes the number of bytes we need in the BUFFER: NEEDED_LEN,
> which is
Hi!
The following patch ICEs due to my recent change r10-6451-gb7b3378f91c.
Since that patch, for explicit vzeroupper in the sources (when an intrinsic
is used), we start with the *avx_vzeroupper_1 pattern which contains just the
UNSPECV_VZEROUPPER and no sets/clobbers. The vzeroupper pass then
Hi!
The following testcase is miscompiled, because output_constructor doesn't
output the initializer correctly. The FE creates {[1...2] = 9} in this
case, and we emit .long 9; long 9; .zero 8 instead of the expected
.zero 8; .long 9; .long 9. If the CONSTRUCTOR is {[1] = 9, [2] = 9},
Hi!
As mentioned in the PR, we don't guarantee DECL_UID to be the same between
corresponding decls in -g and -g0 builds, -g can create more decls and all
that is guaranteed is that the DECL_UIDs of the corresponding decls compare
the same.
The following testcase gets a -fcompare-debug failure
Hi!
The following testcase is miscompiled, because there is a buffer overflow
in push_partial_def in the little-endian case when working 64-byte vectors.
The code computes the number of bytes we need in the BUFFER: NEEDED_LEN,
which is rounded up number of bits we need. Then the code
Hi!
The following testcase ICEs, because arm_gen_discompare_reg creates invalid
RTL which then propagates into DEBUG_INSNs and ICEs while handling them.
The problem is that this function emits
(insn 18 17 19 2 (set (reg:CC_DNE 100 cc)
(compare (ior:SI (ne:SI (subreg:SI (reg:DI 129) 0)
76 matches
Mail list logo
