On 3/6/20 8:12 PM, Marek Polacek wrote:
On Fri, Mar 06, 2020 at 05:49:07PM -0500, Jason Merrill wrote:
On 3/5/20 2:40 PM, Marek Polacek wrote:
The static_assert in the following test was failing on armv7hl because
we were disregarding the alignas specifier on Cell. BaseShape's data
takes up
On 3/6/20 8:24 PM, Marek Polacek wrote:
On Fri, Mar 06, 2020 at 07:40:20PM -0500, Jason Merrill wrote:
On 3/6/20 11:02 AM, Marek Polacek wrote:
On Fri, Mar 06, 2020 at 04:58:32PM +0100, Paolo Carlini wrote:
... the patch ;)
Paolo.
Fix "PR c++/94034 Broken diagnostic: 'result_decl' not
On Fri, Mar 06, 2020 at 07:40:20PM -0500, Jason Merrill wrote:
> On 3/6/20 11:02 AM, Marek Polacek wrote:
> > On Fri, Mar 06, 2020 at 04:58:32PM +0100, Paolo Carlini wrote:
> > > ... the patch ;)
> > >
> > > Paolo.
> > >
> >
> > > Fix "PR c++/94034 Broken diagnostic: 'result_decl' not supported
On Fri, Mar 06, 2020 at 05:49:07PM -0500, Jason Merrill wrote:
> On 3/5/20 2:40 PM, Marek Polacek wrote:
> > The static_assert in the following test was failing on armv7hl because
> > we were disregarding the alignas specifier on Cell. BaseShape's data
> > takes up 20B on 32-bit architectures,
On 3/6/20 6:54 PM, Marek Polacek wrote:
I got a report that building Chromium fails with the "modifying a const
object" error. After some poking I realized it's a bug in GCC, not in
their codebase.
Much like with ARRAY_REFs, which can be const even though the array
itself isn't, COMPONENT_REFs
On 3/6/20 1:41 PM, Patrick Palka wrote:
We are unconditionally emitting an error here, without first checking complain.
This is not a regression, though I guess it could loosely be considered to be a
concepts bug, and the fix seems to be relatively harmless. Does this maybe look
OK for trunk,
On 3/6/20 1:41 PM, Patrick Palka wrote:
I noticed that in some concepts diagnostic messages, we were printing typename
types incorrectly, e.g. printing remove_reference_t as
typename remove_reference::remove_reference_t
instead of
typename remove_reference::type.
Fixed this by looking
On 3/6/20 11:02 AM, Marek Polacek wrote:
On Fri, Mar 06, 2020 at 04:58:32PM +0100, Paolo Carlini wrote:
... the patch ;)
Paolo.
Fix "PR c++/94034 Broken diagnostic: 'result_decl' not supported by dump_expr"
A rather simple diagnostic issue where we failed to handle RESULT_DECL in
I got a report that building Chromium fails with the "modifying a const
object" error. After some poking I realized it's a bug in GCC, not in
their codebase.
Much like with ARRAY_REFs, which can be const even though the array
itself isn't, COMPONENT_REFs can be const although neither the object
Caveat 1: Patch is against svn 280157.
Caveat 2: I am no longer subscribed to fortran@. Hit reply-all if you
want to communicate with me.
Caveat 3: I don't do git. This is likely my last patch for GCC.
TL;DR version.
Fix the simplification and handling of the degree trigonometric
On 3/5/20 2:40 PM, Marek Polacek wrote:
The static_assert in the following test was failing on armv7hl because
we were disregarding the alignas specifier on Cell. BaseShape's data
takes up 20B on 32-bit architectures, but we failed to round up its
TYPE_SIZE. This happens since the
Hi!
On Fri, Mar 06, 2020 at 11:01:50AM -0800, Carl Love wrote:
> The following patch improves the description of the ppc64 -mlong-double
> option.
Okay for trunk. Some trivialities:
> RS6000 Fix -mlong-double documentation
rs6000: Fix [etc.]
(It's no more than just the dir name now; and the
This patch extends region_model::get_representative_tree so that dumps
are able to refer to string literals, which I've found useful in
investigating a state-bloat issue.
Doing so uncovered a bug in the handling of views I introduced in
r10-7024-ge516294a1acb28d44cfd583cc6a80354044e where the
This patch fixes a bug in which summarized state dumps involving a
non-NULL pointer to a region for which get_representative_path_var
returned NULL were erroneously dumped as "NULL".
It also extends sm-state dumps so that they show representative tree
values, where available.
Finally, it adds
On Tue, 2020-03-03 at 13:38 -0500, Hans-Peter Nilsson wrote:
> On Sat, 29 Feb 2020, Jeff Law wrote:
> > Wow, I think I wrote the v850 port back in circa 1997 and this bug has been
> > latent all this time. Vlad's IRA changes twiddled register allocation in
> > just
> > the right way to expose
GCC maintianers:
The following patch improves the description of the ppc64 -mlong-double
option.
I compiled it and tested it by hand with the command:
gcc --target-help
Please let me know if the patch is OK for mainline.
Thanks.
Carl Love
Now same_type_p rejects argument packs, we need to be more careful
calling it with template argument vector contents.
The mangler needs to do some comparisons to find the special
substitutions. While that code looks a little ugly, this seems the
smallest fix.
nathan
--
Nathan Sidwell
We are unconditionally emitting an error here, without first checking complain.
This is not a regression, though I guess it could loosely be considered to be a
concepts bug, and the fix seems to be relatively harmless. Does this maybe look
OK for trunk, or should it wait for stage 1?
I noticed that in some concepts diagnostic messages, we were printing typename
types incorrectly, e.g. printing remove_reference_t as
typename remove_reference::remove_reference_t
instead of
typename remove_reference::type.
Fixed this by looking at TYPENAME_TYPE_FULLNAME instead of
Wilco Dijkstra writes:
> The syntax for lane specifiers uses a vector element rather than a vector:
>
> fmlsv0.2s, v1.2s, v1.s[1] // rather than v1.2s[2]
>
> Fix all the lane specifiers to use Vetype which uses the correct element type.
>
> Regress pass.
OK, thanks.
Richard
> +;; vmlal_lane_s16 intrinsics
> +(define_insn "aarch64_vec_mlal_lane"
> + [(set (match_operand: 0 "register_operand" "=w")
> + (plus: (match_operand: 1 "register_operand" "0")
> + (mult:
> + (ANY_EXTEND:
> + (match_operand: 2 "register_operand" "w"))
> +
On Fri, Mar 06, 2020 at 02:07:15PM +0100, Martin Liška wrote:
> After r9-1623-gc518c1025b435e1c593a745036fc9b8ed04c5819 the code was
> changed to:
>
> - if (align_jumps_max_skip <= 0)
> - align_jumps_max_skip = 15;
> - if (align_loops_max_skip <= 0)
> -
aix61.h, aix71.h and aix72.h intends to prevent SUM_IN_TOC and FP_IN_TOC
when cmodel=large. This patch defines the variables associated with the
target options to 1 to _enable_ NO_SUM_IN_TOC and enable NO_FP_IN_TOC.
Bootstrapped on powerpc-ibm-aix7.2.0.0
PR target/94065
*
Hi all,
The two affected SVE2 patterns in this patch output a movprfx'ed
instruction in their second alternative
but don't set the "movprfx" attribute, which will result in the wrong
instruction length being assumed by the midend.
This patch fixes that in the same way as the other SVE
On 2020-03-06 09:55, Richard Biener wrote:
On Thu, Mar 5, 2020 at 5:49 PM J.W. Jagersma wrote:
diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
index 2a409dcaffe..8314db00922 100644
--- a/gcc/tree-eh.c
+++ b/gcc/tree-eh.c
@@ -2077,6 +2077,9 @@ lower_eh_constructs_2 (struct leh_state *state,
On Fri, Mar 06, 2020 at 04:58:32PM +0100, Paolo Carlini wrote:
> ... the patch ;)
>
> Paolo.
>
> Fix "PR c++/94034 Broken diagnostic: 'result_decl' not supported by dump_expr"
>
> A rather simple diagnostic issue where we failed to handle RESULT_DECL in
> dump_expr.
>
> Tested x86_64-linux.
>
Hi,
in this apparently simple regression we end up producing garbled
diagnostic because dump_expr (called via verify_constant) doesn't handle
RESULT_DECL. I think it makes sense to add the tree code together with
all the other *_DECL. Tested x86_64-linux.
Thanks, Paolo.
... the patch ;)
Paolo.
Fix "PR c++/94034 Broken diagnostic: 'result_decl' not supported by dump_expr"
A rather simple diagnostic issue where we failed to handle RESULT_DECL in
dump_expr.
Tested x86_64-linux.
/cp
PR c++/94034
* error.c (dump_expr): Handle RESULT_DECL
As noted in PR93996, haifa-sched can try to add REG_NOTEs to a NOTE_INSN. This
causes memory corruption which typically shows up as a fault in the GC system.
What happens is we have an insn before the EPILOGUE_BEG note. That insn needs
to
be split and the split form creates new basic blocks.
On Fri, 2020-03-06 at 16:39 +0200, Claudiu Zissulescu wrote:
> The test is using -O1 and, the macu instruction is generated by the
> combiner and not in the expand step. My previous "arc: Improve code
> gen for 64bit add/sub operations." is actually splitting the 64-bit
> add in the expand,
Hi!
On Fri, Mar 06, 2020 at 10:20:08AM +0800, binbin wrote:
> OK, changed the code. Bootstrap and regression tests were done on
> powerpc64le-linux-gnu (LE) with no regressions. Thanks for your suggestion.
Yes, this is fine, approved for trunk (but add a changelog!)
And one triviality:
> ---
Inline assembler instructions don't have latency info and the scheduler does
not attempt to schedule them at all - it does not even honor latencies of
asm source operands. As a result, SIMD intrinsics which are implemented using
inline assembler perform very poorly, particularly on in-order cores.
The syntax for lane specifiers uses a vector element rather than a vector:
fmlsv0.2s, v1.2s, v1.s[1] // rather than v1.2s[2]
Fix all the lane specifiers to use Vetype which uses the correct element type.
Regress pass.
ChangeLog:
2020-03-06 Wilco Dijkstra
*
On Thu, 2020-03-05 at 21:34 -0500, David Malcolm wrote:
> On Thu, 2020-01-16 at 11:11 +, Andrea Corallo wrote:
Responding to my own ideas about thread-safety.
[...]
> My first thought here was that we should have a way to get all three
> at
> once, but it turns out that parse_basever does
The test is using -O1 and, the macu instruction is generated by the
combiner and not in the expand step. My previous "arc: Improve code
gen for 64bit add/sub operations." is actually splitting the 64-bit
add in the expand, leading to the impossibility to match the multiply
and accumulate on 64 bit
On 05/03/2020 20:22, Jakub Jelinek wrote:
Status
==
The GCC 9 branch is now frozen for blocking regressions and documentation
fixes only, all changes to the branch require a RM approval now.
Quality Data
Priority # Change from last report
---
On Fri, 6 Mar 2020, Jonathan Wakely wrote:
> On 05/03/20 11:02 -0500, Patrick Palka wrote:
> > This works around PR 93978 by avoiding having to instantiate ranges::empty()
> > when checking the constraints of view_interface::operator bool(). When
> > ranges::empty() has an auto return type, then
On Thu, Mar 05, 2020 at 02:40:16PM -0500, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-linux, ok for trunk? I verified the
> fix on the attached testcase using a --target=armv7hl-linux-gnueabi cross,
> but haven't actually run the testsuite.
FYI, also successfully
Hi.
After r9-1623-gc518c1025b435e1c593a745036fc9b8ed04c5819 the code was changed to:
- if (align_jumps_max_skip <= 0)
- align_jumps_max_skip = 15;
- if (align_loops_max_skip <= 0)
- align_loops_max_skip = 15;
+
+ if (flag_align_jumps &&
Hi!
Since r10-6527-gaaa26bf496a646778ac861aed124d960b5bf549f fold_for_warn
will perform maybe_constant_value even on some cp_fold produced trees and
so can include rotate exprs which were removed last fall from constexpr.c
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
On Fri, Mar 06, 2020 at 12:35:09PM +, Jonathan Wakely wrote:
> > The GCC 9 branch is now frozen for blocking regressions and documentation
> > fixes only, all changes to the branch require a RM approval now.
>
> I'd also like to backport this one:
>
On Thu, 5 Mar 2020 at 20:23, Jakub Jelinek wrote:
>
> Status
> ==
>
> The GCC 9 branch is now frozen for blocking regressions and documentation
> fixes only, all changes to the branch require a RM approval now.
I'd also like to backport this one:
On Fri, 6 Mar 2020 at 12:18, Jakub Jelinek wrote:
>
> On Fri, Mar 06, 2020 at 12:12:09PM +, Jonathan Wakely wrote:
> > On Thu, 5 Mar 2020 at 20:23, Jakub Jelinek wrote:
> > >
> > > Status
> > > ==
> > >
> > > The GCC 9 branch is now frozen for blocking regressions and documentation
> > >
On 06/03/20 12:04 +, Jonathan Wakely wrote:
When the target doesn't define PTHREAD_RWLOCK_INITIALIZER we use a
wrapper around pthread_wrlock_init, but the wrapper only takes one
argument and we try to call it with two.
This went unnnoticed on most targets because they do define the
On Fri, Mar 06, 2020 at 12:12:09PM +, Jonathan Wakely wrote:
> On Thu, 5 Mar 2020 at 20:23, Jakub Jelinek wrote:
> >
> > Status
> > ==
> >
> > The GCC 9 branch is now frozen for blocking regressions and documentation
> > fixes only, all changes to the branch require a RM approval now.
>
>
On Thu, 5 Mar 2020 at 20:23, Jakub Jelinek wrote:
>
> Status
> ==
>
> The GCC 9 branch is now frozen for blocking regressions and documentation
> fixes only, all changes to the branch require a RM approval now.
I'd like to backport https://gcc.gnu.org/ml/gcc-patches/2020-03/msg00361.html
The
When the target doesn't define PTHREAD_RWLOCK_INITIALIZER we use a
wrapper around pthread_wrlock_init, but the wrapper only takes one
argument and we try to call it with two.
This went unnnoticed on most targets because they do define the
PTHREAD_RWLOCK_INITIALIZER macro, but it causes a
The checks for PR 93244 don't actually pass on Windows (which is the
target where the bug is present) because of a different bug, PR 94063.
This adjusts the tests to not be affected by 94063 so that they verify
that 93244 was fixed.
PR libstdc++/93244
*
Hi Delia,
On 3/5/20 4:38 PM, Delia Burduv wrote:
Hi,
This is the latest version of the patch. I am forcing -mfloat-abi=hard
because the code generated is slightly differently depending on the
float-abi used.
Thanks, I've pushed it with an updated ChangeLog.
2020-03-06 Delia Burduv
Hi Delia,
On 3/5/20 3:53 PM, Delia Burduv wrote:
Hi,
This is the latest version of the patch. I am forcing -mfloat-abi=hard
because the register allocator behaves differently depending on the
float-abi used.
Thanks, I've pushed it to master with an updated ChangeLog reflecting
the recent
---
gcc/testsuite/ChangeLog | 4
gcc/testsuite/gcc.target/riscv/pr93304.c | 7 +++
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 09d59730730..6c9206aeb27 100644
--- a/gcc/testsuite/ChangeLog
+++
On 05/03/20 11:02 -0500, Patrick Palka wrote:
This works around PR 93978 by avoiding having to instantiate ranges::empty()
when checking the constraints of view_interface::operator bool(). When
ranges::empty() has an auto return type, then we must instantiate it in order to
determine whether
On 06/03/20 10:09 +, Jonathan Wakely wrote:
On 06/03/20 07:06 +0100, François Dumont wrote:
I started to work on ranges::equal to find out if what I am trying
to do is totally silly.
With this patch ranges::equal is in pare with std::equal
specializations that is to say that it correctly
On 06/03/20 07:06 +0100, François Dumont wrote:
I started to work on ranges::equal to find out if what I am trying to
do is totally silly.
With this patch ranges::equal is in pare with std::equal
specializations that is to say that it correctly deals with Debug mode
or std::deque iterators.
On Fri, 6 Mar 2020 at 09:52, Andreas Krebbel wrote:
>
> On 3/6/20 10:15 AM, Ville Voutilainen wrote:
> > On Fri, 6 Mar 2020 at 10:41, Andreas Krebbel wrote:
> >>
> >> zTPF uses the same numeric value for ENOSYS and ENOTSUP.
> >>
> >> Ok for mainline?
> >>
> >> libstdc++-v3/ChangeLog:
> >>
> >>
On Fri, 6 Mar 2020 at 11:52, Andreas Krebbel wrote:
> > Hmm, what system does not have ENOSYS but has ENOTSUP? Meaning the
> > !defined ENOSYS
> > bit?
> >
> None that I know about. It is just to make sure the compare afterwards
> operates on defined inputs.
Ah, I see, indeed. This dance is
Delia Burduv writes:
> Hi,
>
> Here is the latest version of the patch. That test should now work.
Thanks, pushed.
Richard
On 3/6/20 10:15 AM, Ville Voutilainen wrote:
> On Fri, 6 Mar 2020 at 10:41, Andreas Krebbel wrote:
>>
>> zTPF uses the same numeric value for ENOSYS and ENOTSUP.
>>
>> Ok for mainline?
>>
>> libstdc++-v3/ChangeLog:
>>
>> 2020-03-06 Andreas Krebbel
>>
>> * src/c++11/system_error.cc:
On Fri, 6 Mar 2020 at 10:41, Andreas Krebbel wrote:
>
> zTPF uses the same numeric value for ENOSYS and ENOTSUP.
>
> Ok for mainline?
>
> libstdc++-v3/ChangeLog:
>
> 2020-03-06 Andreas Krebbel
>
> * src/c++11/system_error.cc: Omit the ENOTSUP case statement if it
> would match
On Fri, Mar 6, 2020 at 2:04 AM Martin Sebor wrote:
>
> Treating incompatible redeclarations of built-in functions as built-ins
> is a problem not just for the middle-end but even for the C front-end
> itself, when different parts of it make different assumptions about
> what is and isn't valid.
gcc/ChangeLog:
2020-03-06 Andreas Krebbel
* config/s390/s390.md ("tabort"): Get rid of two consecutive
blanks in format string.
---
gcc/config/s390/s390.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/s390/s390.md
On Thu, Mar 5, 2020 at 5:49 PM J.W. Jagersma wrote:
>
> The following patch extends the generation of exception handling
> information to cover volatile asms too. This was already mostly
> implemented, and only very minor changes are required in order to make
> it work.
>
> The change in
zTPF uses the same numeric value for ENOSYS and ENOTSUP.
Ok for mainline?
libstdc++-v3/ChangeLog:
2020-03-06 Andreas Krebbel
* src/c++11/system_error.cc: Omit the ENOTSUP case statement if it
would match ENOSYS.
---
libstdc++-v3/src/c++11/system_error.cc | 3 ++-
1 file
David Malcolm writes:
> On Thu, 2020-01-16 at 11:11 +, Andrea Corallo wrote:
>> Hi, second version of the patch here cleaning up an unnecessary
>> change.
>>
>> Does not introduce regressions with make check-jit.
>>
>> Andrea
>>
>> gcc/jit/ChangeLog
>> 2020-??-?? Andrea Corallo
>>
>>
On Thu, Mar 05, 2020 at 05:03:30PM +0100, Jakub Jelinek wrote:
> This PR has been fixed by r10-3970. Testcase tested with cross to
> armv7hl-linux-gnueabi (all of r10-3969 (FAIL), r10-3970 and current trunk
> (PASS))
It was actually fixed by
r10-1963-g24990170d318194b265c2fc76d93965275da462c
* David Malcolm:
>
> My first thought here was that we should have a way to get all three at
> once, but it turns out that parse_basever does its own caching
> internally.
>
> I don't think the current implementation is thread-safe; parse_basever
> has:
>
> static int s_major = -1, s_minor,
66 matches
Mail list logo
