This patch to the Go frontend fixes a bug in which the code referred
to a temporary value after it was destroyed. It also fixes an
incorrect test of the string index rather than the value parsed using
strtol. This should fix PR 90110. Bootstrapped and ran Go testsuite
on x86_64-pc-linux-gnu.
In order to make alias templates useful for SFINAE we instantiate them under
the prevailing 'complain' argument, so an error encountered while
instantiating during SFINAE context is silent. The problem in this PR comes
when we later look up the erroneous instantiation and don't give an error at
The fix for pr89797 committed in r270326 was limited to targets
with NUM_POLY_INT_COEFFS == 1 which I think is all but aarch64.
The tests for the fix have been failing with an ICE on aarch64
because it suffers from more or less the same problem but in
its own target-specific code. Attached is
On 16/04/19 23:16 +0100, Jonathan Wakely wrote:
While testing the fix I also discovered that operator== assumes the
elements are comparable with operator!= which is not required.
PR libstdc++/90105
* include/bits/forward_list.h (operator==): Do not use operator!= to
On 4/17/19 12:57 PM, Jeff Law wrote:
> On 4/17/19 9:35 AM, Peter Bergner wrote:
>> * ira-conflicts.c (print_allocno_conflicts): Always print something,
>> even for allocno's with no conflicts.
>> (print_conflicts): Print an extra newline.
> OK. And while it's technically not a
It is a bit confusing, it looks as if the compiler tried to print
something there.
Committing.
Segher
2018-04-17 Segher Boessenkool
* config/rs6000/rs6000.c (rs6000_register_move_cost): Fix typo.
---
gcc/config/rs6000/rs6000.c | 2 +-
1 file changed, 1 insertion(+), 1
On Wed, 17 Apr 2019 at 18:44, Mike Stump wrote:
>
> On Apr 17, 2019, at 8:59 AM, Jakub Jelinek wrote:
> > Ok for trunk?
>
> Ok.
Thanks!
On Wed, 17 Apr 2019, Jeff Law wrote:
* tree.c (get_qualified_type): Put found type variants at the
head of the variant list.
Seems quite reasonable to me. I just hope we don't find a case where
this is the exact worst case behavior ;-)
That seems unlikely. Competitive
The 17.04.2019 21:36, Emeric Dupont wrote:
<... Unwanted legalese ...>
Sorry, please disregard the unwanted footer added against my will. I am
actively trying to have out admins get rid of it where it is not
applicable.
--
Emeric Dupont
Zodiac Inflight Innovations
P +49815388678207
Argelsrieder
On 17/04/2019 19:11, Jeff Law wrote:
On 4/17/19 6:45 AM, Jonny Grant wrote:
Hello
Change the "collect2 -help" output to have https URL:
Overview: http://gcc.gnu.org/onlinedocs/gccint/Collect2.html
2019-04-14 Jonny Grant
* collect2.c: Change gcc.gnu.org URL to HTTPS
Thank you
Some build environments and configuration options may lead to the make
variable PLUGIN_HEADERS being too long to be passed as parameters to the
shell `echo` command, leading to a "write error" message when making the
target install-plugin.
The following patch fixes this issue by using the [Make
On 17/04/19 19:20 +0300, Ville Voutilainen wrote:
On Wed, 17 Apr 2019 at 19:12, Jonathan Wakely wrote:
The standard says the std::variant copy constructor is defined as
deleted unless all alternative types are copy constructible, but we were
making it also depend on move constructible. Fix
On Wed, Apr 17, 2019 at 01:25:05PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 17, 2019 at 02:09:33PM +0300, Claudiu Zissulescu wrote:
> >/* Warn for unimplemented PIC in pre-ARC700 cores, and disable flag_pic.
> > */
> >if (flag_pic && TARGET_ARC600_FAMILY)
> > {
> >warning
On Wed, Apr 17, 2019 at 8:13 PM Jakub Jelinek wrote:
>
> Hi!
>
> The following patch fixes a bunch of pastos in the -O0 macros in the
> PR89784 implementation plus testcase coverage that FAILs without the header
> change and succeeds with that (the tests were previously run at -O2 only
> where
On 4/15/19 11:39 AM, Simon Marchi wrote:
> On 2019-04-15 12:42 p.m., Simon Marchi wrote:
>> Hi,
>>
>> Here is a patch that adds a mention of the 2019 Cauldron, similar to the
>> entries
>> for the previous editions.
>>
>> Thanks,
>>
>> Simon
>>
>>
>> Index: index.html
>>
On 4/15/19 10:31 AM, Joao Moreira wrote:
>
>
> On 4/12/19 1:19 PM, Jeff Law wrote:
>> On 4/11/19 11:18 AM, Joao Moreira wrote:
>>> When -fpatchable-relocation-entry is used, gcc places nops on the
>>> prologue of each compiled function and creates a section named
>>> __patchable_function_entries
On 4/16/19 6:55 AM, Richard Biener wrote:
>
> The following makes the C++ FEs heavy use of build_qualified_type
> cheaper. When looking at a tramp3d -fsyntax-only compile you can
> see that for 470.000 build_qualified_type calls we end up
> with 9.492.205 calls to check_qualified_type (thus we
Hi!
The following patch fixes a bunch of pastos in the -O0 macros in the
PR89784 implementation plus testcase coverage that FAILs without the header
change and succeeds with that (the tests were previously run at -O2 only
where they test the inline functions and not the macros).
Because at -O0
On 4/17/19 6:45 AM, Jonny Grant wrote:
> Hello
>
> Change the "collect2 -help" output to have https URL:
>
> Overview: http://gcc.gnu.org/onlinedocs/gccint/Collect2.html
>
> 2019-04-14 Jonny Grant
> * collect2.c: Change gcc.gnu.org URL to HTTPS
>
>
> Thank you
> Jonny
THanks. I've
On 4/17/19 4:13 AM, Segher Boessenkool wrote:
> When auto-inc-dec creates a new mem to compute the cost of doing some
> transform, it forgets to copy over the alignment of the original mem.
> This gives wrong costs, for example, for rs6000 a floating point load
> or store is hugely expensive if
On 4/17/19 9:35 AM, Peter Bergner wrote:
> On 4/16/19 12:47 PM, Peter Bergner wrote:
>> The patch below fixes the issue not continuing if the allocno's conflict
>> array is null and instead guarding the current conflict prints by that
>> test. If the conflict array is null, we instead now print
On Wed, Apr 17, 2019 at 10:45 AM Marek Polacek wrote:
>
> This fixes a recent P1. Here we were giving the "invalid use of incomplete
> type" error, but "the operand of the decltype specifier is an unevaluated
> operand"
> and so the objects it names are not required to have a definition.
>
>
This fixes a recent P1. Here we were giving the "invalid use of incomplete
type" error, but "the operand of the decltype specifier is an unevaluated
operand"
and so the objects it names are not required to have a definition.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-04-17
Hi!
On Wed, Apr 17, 2019 at 03:05:06PM +0800, Xiong Hu Luo wrote:
> On 2019/4/16 PM6:54, Segher Boessenkool wrote:
> > ("be" and "le" are essentially PowerPC-specific selectors on the 7 branch,
> > otherwise you'd need a release manager's approval as well).
>
> Do you mean move the "be" and "le"
On Apr 17, 2019, at 8:59 AM, Jakub Jelinek wrote:
> Ok for trunk?
Ok.
On Wed, 17 Apr 2019 at 19:12, Jonathan Wakely wrote:
>
> The standard says the std::variant copy constructor is defined as
> deleted unless all alternative types are copy constructible, but we were
> making it also depend on move constructible. Fix the condition and
> enhance the tests to check
On Wed, 17 Apr 2019 at 19:09, Jonathan Wakely wrote:
>
> Remove unnecessary string literals from static_assert in C++17 tests
>
> The string literal is optional in C++17 and all these are empty so add
> no value.
>
>
> Tested powerpc64le-linux.
Looks good to me.
On Wed, 17 Apr 2019 at 19:07, Jonathan Wakely wrote:
>
> * testsuite/20_util/variant/compile.cc (MoveCtorOnly): Fix type to
> actually match its name.
> (MoveCtorAndSwapOnly): Define new type that adds swap to MoveCtorOnly.
> (test_swap()): Fix result for
The standard says the std::variant copy constructor is defined as
deleted unless all alternative types are copy constructible, but we were
making it also depend on move constructible. Fix the condition and
enhance the tests to check the semantics with pathological copy-only
types (i.e. supporting
Remove unnecessary string literals from static_assert in C++17 tests
The string literal is optional in C++17 and all these are empty so add
no value.
Tested powerpc64le-linux.
commit 028676a32fa51c0116e3c117a36550dd04cd39fe
Author: Jonathan Wakely
Date: Wed Apr 17 14:57:41 2019 +0100
* testsuite/20_util/variant/compile.cc (MoveCtorOnly): Fix type to
actually match its name.
(MoveCtorAndSwapOnly): Define new type that adds swap to MoveCtorOnly.
(test_swap()): Fix result for MoveCtorOnly and check
MoveCtorAndSwapOnly.
Tested
Hi!
On Tue, Apr 16, 2019 at 09:26:46PM +0200, Christophe Lyon wrote:
> > Actually, I managed to reproduce in a Fedora 31 chroot, in which I don't
> > have /usr/bin/python installed (I think in Fedora 30+ there is
> > /usr/bin/python2 and /usr/bin/python3 but not /usr/bin/python, at least not
> >
On 4/16/19 12:47 PM, Peter Bergner wrote:
> The patch below fixes the issue not continuing if the allocno's conflict
> array is null and instead guarding the current conflict prints by that
> test. If the conflict array is null, we instead now print out simple
> empty conflict info. This now
On Tue, 16 Apr 2019, Richard Biener wrote:
>
> Two cases from a -fsynax-only tramp3d callgrind profile.
Amended by two others.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK?
Thanks,
Richard.
2019-04-17 Richard Biener
cp/
* call.c (null_ptr_cst_p): Order checks
On 4/17/19 4:19 AM, Richard Earnshaw (lists) wrote:
> On 10/04/2019 23:03, Steve Ellcey wrote:
>>
>> Here is another patch to fix one of the failures
>> listed in PR rtl-optimization/87763. This change
>> fixes gcc.target/aarch64/lsl_asr_sbfiz.c by adding
>> an alternative version of
In C++1z drafts up to N4606 the constexpr keyword was missing from the
detailed description of this function, despite being shown in the class
synopsis. That was fixed editorially for N4618, but our implementation
was not corrected to match.
* include/std/optional
* Andreas Schwab:
> On Apr 17 2019, Florian Weimer wrote:
>
>> * Andreas Schwab:
>>
>>> On Apr 17 2019, Florian Weimer wrote:
>>>
Not just that, .bss adds to the commit charge,
>>>
>>> Only one page at most.
>>
>> That would be a bug.
>
> You cannot avoid it for the page shared with .data,
On Apr 17 2019, Florian Weimer wrote:
> * Andreas Schwab:
>
>> On Apr 17 2019, Florian Weimer wrote:
>>
>>> Not just that, .bss adds to the commit charge,
>>
>> Only one page at most.
>
> That would be a bug.
You cannot avoid it for the page shared with .data, unless you force
.bss to be page
Hello
Change the "collect2 -help" output to have https URL:
Overview: http://gcc.gnu.org/onlinedocs/gccint/Collect2.html
2019-04-14 Jonny Grant
* collect2.c: Change gcc.gnu.org URL to HTTPS
Thank you
Jonny
Index: gcc/collect2.c
* Andreas Schwab:
> On Apr 17 2019, Florian Weimer wrote:
>
>> Not just that, .bss adds to the commit charge,
>
> Only one page at most.
That would be a bug. All of it is anonymous memory which needs backing
from RAM or swap, in case the process writes to it.
Thanks,
Florian
On Apr 17 2019, Florian Weimer wrote:
> Not just that, .bss adds to the commit charge,
Only one page at most.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
This patch fixes a cases where inconsistent CFI is generated.
After restoring the hard frame pointer (r11) from an FPR we have to
set the CFA register. In order to be able to set it back to the stack
pointer (r15) we have to make sure that r15 has been restored already.
The patch also adds a
Hi,
On Tue, 16 Apr 2019, Jakub Jelinek wrote:
> > + if (type1 == type2)
> > +return true;
> > + if (TYPE_MAIN_VARIANT (type1) != TYPE_MAIN_VARIANT (type2))
> > +return false;
>
> Is this second one correct though? Doesn't comptypes return for various
> cases true even if the
Hi,
On Wed, 17 Apr 2019, Richard Biener wrote:
> for the C++ FE the LRU cache effectively moves the unqualified
> variants first in the variant list. Since we always first
> build the unqualified variants before the qualified ones
> the unqualified ones tend to be at the end of the list.
Hi,
On Tue, 16 Apr 2019, Jeff Law wrote:
> So going back to Jakub's patch... I think the discussion points to
> avoiding the REG_EQUIV notes for outgoing argument slots.
In the long run definitely, but maybe his current solution is more
amenable to stage 4, no idea.
Ciao,
Michael.
On Wed, Apr 17, 2019 at 07:14:05PM +0800, Bin.Cheng wrote:
> > As
> > #define INFTY 1000
> > what is the reason to keep the previous condition as well?
> > I mean, if cost1.cost == INFTY or cost2.cost == INFTY,
> > cost1.cost + cost2.cost >= INFTY too.
> > Unless costs can go negative.
> It's
On Wed, Apr 17, 2019 at 02:09:33PM +0300, Claudiu Zissulescu wrote:
>/* Warn for unimplemented PIC in pre-ARC700 cores, and disable flag_pic.
> */
>if (flag_pic && TARGET_ARC600_FAMILY)
> {
>warning (0,
> -"PIC is not supported for %s. Generating non-PIC code
On Wed, Apr 17, 2019 at 1:03 PM Uros Bizjak wrote:
>
> On Wed, Apr 17, 2019 at 12:29 PM Hongtao Liu wrote:
> >
> > On Fri, Apr 12, 2019 at 11:18 PM H.J. Lu wrote:
> > >
> > > On Fri, Apr 12, 2019 at 3:19 AM Uros Bizjak wrote:
> > > >
> > > > On Fri, Apr 12, 2019 at 11:03 AM Hongtao Liu wrote:
On Wed, Apr 17, 2019 at 3:10 PM Jakub Jelinek wrote:
>
> On Wed, Apr 17, 2019 at 02:13:12PM +0800, bin.cheng wrote:
> > Hi,
> > As discussed in PR90078, this patch checks possible infinite_cost overflow
> > in ivopts.
> > Also as discussed, overflow happens mostly because of cost scaling wrto
>
Apply upper/dot rule on diagnostic messages.
gcc/
-xx-xx Claudiu Zissulescu
* config/arc/arc.c (arc_init): Format diagnostic string.
(arc_override_options): Likewise.
(check_if_valid_regno_const): Likewise.
(arc_reorg): Likewise.
---
gcc/ChangeLog|
* Richard Biener:
> On Wed, Apr 17, 2019 at 9:19 AM Thomas König wrote:
>>
>> Hi,
>>
>> thanks a lot for the extensive discussion :-)
>>
>> How should we now proceed, first for gcc 9, snd then for backporting?
>> Use Richard‘s patch with the corresponding Fortran FE change?
>
> Btw, for the
On Wed, Apr 17, 2019 at 12:29 PM Hongtao Liu wrote:
>
> On Fri, Apr 12, 2019 at 11:18 PM H.J. Lu wrote:
> >
> > On Fri, Apr 12, 2019 at 3:19 AM Uros Bizjak wrote:
> > >
> > > On Fri, Apr 12, 2019 at 11:03 AM Hongtao Liu wrote:
> > > >
> > > > On Fri, Apr 12, 2019 at 3:30 PM Uros Bizjak wrote:
On Tue, 16 Apr 2019, Michael Matz wrote:
> Hi,
>
> On Tue, 16 Apr 2019, Richard Biener wrote:
>
> > Comments?
>
> I was quickly testing also with some early-outs but didn't get conclusive
> performance results (but really only superficial testing) so I'm not
> proposing it, like so:
>
>
On Fri, Apr 12, 2019 at 11:18 PM H.J. Lu wrote:
>
> On Fri, Apr 12, 2019 at 3:19 AM Uros Bizjak wrote:
> >
> > On Fri, Apr 12, 2019 at 11:03 AM Hongtao Liu wrote:
> > >
> > > On Fri, Apr 12, 2019 at 3:30 PM Uros Bizjak wrote:
> > > >
> > > > On Fri, Apr 12, 2019 at 9:09 AM Liu, Hongtao
> > >
On Wed, Apr 17, 2019 at 4:48 PM Martin Liška wrote:
>
> On 4/17/19 10:14 AM, Hongtao Liu wrote:
> > Any other comments, I'll merge this to trunk?
>
> Hi.
>
> I don't understand you. The patch in its original version will no be
> installed to trunk
> and I'll rework it to not support AVX512*
On 10/04/2019 23:03, Steve Ellcey wrote:
>
> Here is another patch to fix one of the failures
> listed in PR rtl-optimization/87763. This change
> fixes gcc.target/aarch64/lsl_asr_sbfiz.c by adding
> an alternative version of *ashiftsi_extv_bfiz that
> has a subreg in it.
>
> Tested with
When auto-inc-dec creates a new mem to compute the cost of doing some
transform, it forgets to copy over the alignment of the original mem.
This gives wrong costs, for example, for rs6000 a floating point load
or store is hugely expensive if unaligned. This patch fixes it.
This doesn't fix any
On Tue, Apr 16, 2019 at 1:24 AM Richard Biener
wrote:
> On Mon, Apr 15, 2019 at 7:09 PM Andrew Pinski wrote:
> > On Sun, Apr 14, 2019 at 11:50 PM Richard Biener
> > wrote:
> > >
> > > On Sat, Apr 13, 2019 at 12:34 AM Jeff Law wrote:
> > > >
> > > > On 4/12/19 3:24 PM, Jason Merrill wrote:
> >
On Wed, 17 Apr 2019, Martin Jambor wrote:
> Hello,
>
> On Sun, Mar 10 2019, Martin Jambor wrote:
> > Hi,
> >
> > after we have accidentally dropped the mailing list from our discussion
> > (my apologies for not spotting that in time), Richi has approved the
> > following patch which I have
Many of these patterns only worked in 32-bit mode, and some only worked
in 64-bit mode. This patch makes these use Pmode, fixing the PR. On
the other hand, the stack updates have to use the same mode for the
stack pointer as for the value stored, so let's simplify that a bit.
Many of these
Hello,
On Sun, Mar 10 2019, Martin Jambor wrote:
> Hi,
>
> after we have accidentally dropped the mailing list from our discussion
> (my apologies for not spotting that in time), Richi has approved the
> following patch which I have bootstrapped and tested on x86_64-linux
> (all languages) and on
On 4/17/19 10:14 AM, Hongtao Liu wrote:
> Any other comments, I'll merge this to trunk?
Hi.
I don't understand you. The patch in its original version will no be installed
to trunk
and I'll rework it to not support AVX512* (except AVX512F) in target_clone
attribute.
Martin
On Wed, Apr 17, 2019 at 9:19 AM Thomas König wrote:
>
> Hi,
>
> thanks a lot for the extensive discussion :-)
>
> How should we now proceed, first for gcc 9, snd then for backporting?
> Use Richard‘s patch with the corresponding Fortran FE change?
Btw, for the testcase the fortran FE could also
Hi!
On Mon, 11 Aug 2014 16:55:28 -0700, Cesar Philippidis
wrote:
> According to section 2.6.1 in the openacc spec, fortran loop variables
> should be implicitly private like in openmp.
More correctly, they are "predetermined private" (which cannot be
overridden), not "implicit private" (which
On Tue, Apr 16, 2019 at 11:41 PM H.J. Lu wrote:
>
> On Tue, Apr 16, 2019 at 8:36 AM Martin Liška wrote:
> >
> > On 4/16/19 4:50 PM, H.J. Lu wrote:
> > > On Tue, Apr 16, 2019 at 1:28 AM Martin Liška wrote:
> > >>
> > >> On 4/15/19 5:09 PM, H.J. Lu wrote:
> > >>> On Mon, Apr 15, 2019 at 12:26 AM
On Wed, Apr 17, 2019 at 08:59:08AM +0100, Kyrill Tkachov wrote:
> Similarly, spaces are allowed in the general attribute syntax, for example
> in our intrinsics header we have:
>
> __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
Well, that is how the C/C++ lexing works. We
HI Jakub,
On 4/16/19 7:32 PM, Jakub Jelinek wrote:
On Tue, Apr 16, 2019 at 07:50:35PM +0200, Jakub Jelinek wrote:
> On Fri, Apr 12, 2019 at 05:10:48PM +0100, Ramana Radhakrishnan wrote:
> > No, that's not right. we should get rid of this.
>
> Here is a patch for that.
>
> Bootstrapped/regtested
On 4/16/19 6:50 PM, Jakub Jelinek wrote:
On Fri, Apr 12, 2019 at 05:10:48PM +0100, Ramana Radhakrishnan wrote:
> No, that's not right. we should get rid of this.
Here is a patch for that.
Bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?
Ok. I don't think anyone relies on
On Tue, 16 Apr 2019, Jakub Jelinek wrote:
> On Tue, Apr 16, 2019 at 06:21:25PM +0200, Eric Botcazou wrote:
> > > The runtime check assures that at runtime, the upper 32 bits of pseudo 104
> > > must be always 0 (in this case, in some other case could be sign bit
> > > copies).
> >
> > OK, as
Hi,
thanks a lot for the extensive discussion :-)
How should we now proceed, first for gcc 9, snd then for backporting?
Use Richard‘s patch with the corresponding Fortran FE change?
Regards
Thomas
On Wed, Apr 17, 2019 at 02:13:12PM +0800, bin.cheng wrote:
> Hi,
> As discussed in PR90078, this patch checks possible infinite_cost overflow in
> ivopts.
> Also as discussed, overflow happens mostly because of cost scaling wrto
> bb_freq/loop_freq.
> For the moment, we only implement capping in
Hi Segher,
On 2019/4/16 PM6:54, Segher Boessenkool wrote:
> Hi Xiong,
>
> Sorry I took so long to review this.
>
> On Thu, Apr 04, 2019 at 02:49:29AM -0500, luo...@linux.ibm.com wrote:
>> These patches are followed changes for r25 on testcases
>> vsx-vector-6*.c. backport them to update
On Tue, Apr 16, 2019 at 08:40:29PM -0600, Martin Sebor wrote:
> --- gcc/tree.h(revision 270402)
> +++ gcc/tree.h(working copy)
> @@ -3735,9 +3735,9 @@ TYPE_VECTOR_SUBPARTS (const_tree node)
>if (NUM_POLY_INT_COEFFS == 2)
> {
>poly_uint64 res = 0;
> -
Hi,
As discussed in PR90078, this patch checks possible infinite_cost overflow in
ivopts.
Also as discussed, overflow happens mostly because of cost scaling wrto
bb_freq/loop_freq.
For the moment, we only implement capping in comp_cost operators, while in next
stage1, we may instead implement
Hi,
This patch adds missing macros that the dmd front-end makes use of, as
seen on one of the BSDs where the include for int_const.h is guarded,
and defines any __unix__ system as being POSIX.
Bootstrapped and regression tested on x86_64-linux-gnu.
Committed to trunk as r270403.
--
Iain
---
75 matches
Mail list logo
