Thanks - committed as r275696.
Paul
On Thu, 12 Sep 2019 at 15:09, Steve Kargl
wrote:
>
> On Thu, Sep 12, 2019 at 09:55:20AM +0100, Paul Richard Thomas wrote:
> >
> > OK to commit?
> >
>
> Yes.
>
> --
> Steve
--
"If you can't explain it simply, you don't understand it well enough"
- Albert
Ping.
On Thu, Sep 05, 2019 at 10:24:55PM -0400, Marek Polacek wrote:
> Compiling this testcase results in a bogus "invalid cast" error; this occurs
> since the introduction of location wrappers in finish_id_expression.
>
> Here we are parsing the decltype expression via cp_parser_decltype_expr
On Sep 12, 2019, Richard Biener wrote:
> Your new predicate looks a bit excessive here given it builds the type
> again?
Err, there seems to be some misunderstanding here. The predicate avoids
outputting a type for the definition if it's the same DIE that would go
in the specification. Now,
I've committed a patch to update libgo to the final Go 1.13 release.
Bootstrapped and ran Go tests on x86_64-pc-linux-gnu.
Ian
patch.txt.bz2
Description: application/bzip
On 12/09/2019 23.54, Nick Desaulniers wrote:
> On Sat, Sep 7, 2019 at 6:11 AM Segher Boessenkool
> wrote:
>>
>> On Fri, Sep 06, 2019 at 06:04:54PM -0700, Nick Desaulniers wrote:
>>
>>> How would you even write a version check for that?
>>
>> I wouldn't. Please stop using that straw man. I'm not
On Sat, Sep 7, 2019 at 6:11 AM Segher Boessenkool
wrote:
>
> On Fri, Sep 06, 2019 at 06:04:54PM -0700, Nick Desaulniers wrote:
> > On Fri, Sep 6, 2019 at 5:14 PM Segher Boessenkool
> > wrote:
> > > On Fri, Sep 06, 2019 at 04:42:58PM -0700, Nick Desaulniers via
> > > gcc-patches wrote:
> > > >
On Mon, Sep 09, 2019 at 02:52:20PM +0100, Mark Eggleston wrote:
> gcc/fortran
>
> Mark Eggleston
>
> * arith.c (gfc_arith_concat): Set length field in typespec.
> * expr.c (gfc_get_character_expr): Set length field in typespec.
> * gfortran.h: Add length field to
On Wednesday, September 11, 2019, Richard Sandiford <
richard.sandif...@arm.com> wrote:.
>
>
> Sorry for the long write-up.
>
> Richard
>
*thanks* for the long write-up!
Ciao!
Steven
On Tue, Sep 10, 2019 at 11:47:22PM +, Joseph Myers wrote:
> On Mon, 12 Aug 2019, Lewis Hyatt wrote:
>
> > Hello-
> >
> > The attached patch for libcpp adds support for extended characters (e.g.
> > UTF-8)
> > in identifiers. A preliminary version of the patch was posted on PR c/67224
> >
2019-09-12 Uroš Bizjak
PR tree-optimization/89386
* config/i386/sse.md (smulhrs3): New expander.
(smulhrsv4hi3): Ditto.
testsuite/ChangeLog:
2019-09-12 Uroš Bizjak
PR tree-optimization/89386
* gcc.target/i386/pr89386.c: New test.
* gcc.target/i386/pr89386-1.c:
GCC maintainers:
The following patch adds define_insn support for xxswapd mnemonic. The
xxswapd mnemonic is the more prefered name for the xxpermdi mnemonic.
The following patch replaces the define_insn xxpermdi with define_insn
xxswapd.
The patch has been tested on:
Hi, thanks a lot for the patch, and I'm sorry I didn't notice it sooner;
I've adjusted my mail filters to hopefully avoid similar problems. In
the future, please CC me on C++ patches and put "C++" and "PATCH" in the
subject line.
On 7/25/19 7:57 PM, phdoftheho...@gmail.com wrote:
From:
This patch aims to allow more load/store instructions to be compressed by
replacing a load/store of 'base register + large offset' with a new load/store
of 'new base + small offset'. If the new base gets stored in a compressed
register, then the new load/store can be compressed. Since there is an
Hi,
nothing special here, various bits I missed so far or in the past meant
to test more thoroughly.
Thanks, Paolo.
//
/cp
2019-09-12 Paolo Carlini
* decl.c (grokdeclarator): Use declspecs->locations and
declarator->id_loc in a few error messages.
On 9/12/19 10:08 AM, Richard Biener wrote:
> On Wed, 11 Sep 2019, Bernd Edlinger wrote:
>
>> On 9/11/19 8:30 PM, Richard Biener wrote:
>
> More like the following? I wonder if we can assert that
> MEM_NOTRAP_P () are equal (see all the for_gcse checks in exp_equiv_p).
> But as said earlier I
On Thu, Sep 12, 2019 at 09:55:20AM +0100, Paul Richard Thomas wrote:
>
> OK to commit?
>
Yes.
--
Steve
>> Suppose a loop as:
>>
>> void f (std::map m)
>> {
>> for (auto it = m.begin (); it != m.end (); ++it) {
>> /* if (b) is semi-invariant. */
>> if (b) {
>> b = do_something();/* Has effect on b */
>> } else {
>>
A type confusion leads to illegal (and nonsensical) assembly on certain host
architectures (e.g. ARM), where HOST_WIDE_INT (64 bit) and unsigned long (32
bit) have different alignments. So this has printed an uninitialized
register instead of the intended value. This fixes float constant
The following fixes induction vectorization to use the appropriate
type for the IV init and update computations avoiding to create
undefined behavior from inappropriately using a signed integer type.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2019-09-12
On Thu, Sep 12, 2019 at 1:36 PM Alexandre Oliva wrote:
>
> On Sep 12, 2019, Richard Biener wrote:
>
> > Is this PR91507?
>
> Looks like it. Interesting, I've had this patch sitting in my tree
> since early June, waiting for the additional verification I completed
> last night. That was long
On Thu, Sep 12, 2019 at 1:29 PM Wilco Dijkstra wrote:
>
> Hi Richard,
>
> > Do we document target specific deviations from "default" behavior somewhere?
>
> Not as far as I know. The other option changes in arm-common.c are not
> mentioned
> anywhere, neither is any of
On Sep 12, 2019, Richard Biener wrote:
> Is this PR91507?
Looks like it. Interesting, I've had this patch sitting in my tree
since early June, waiting for the additional verification I completed
last night. That was long before the PR was filed.
> How do you get around the gdb issue?
I was
Hi Richard,
> Do we document target specific deviations from "default" behavior somewhere?
Not as far as I know. The other option changes in arm-common.c are not mentioned
anywhere, neither is any of arm_option_override_internal.
If we want to keep documentation useful, we shouldn't clutter
This fixes two silly mistakes I made, which weren't caught by the
existing tests.
PR libstdc++/91748
* include/bits/stl_algo.h (for_each_n): Fix random access iterator
case.
* testsuite/25_algorithms/for_each/for_each_n.cc: Test with random
access
On Mon, Jul 15, 2019 at 4:20 AM Feng Xue OS wrote:
>
> Some time passed, so ping again. I made this patch, because it can reward us
> with 7%
>
> performance benefit in some real application. For convenience, the
> optimization to be
>
> implemented was listed in the following again. And hope
On Thu, Sep 12, 2019 at 11:08:43AM +0200, Paolo Carlini wrote:
> Hi again,
>
> On 12/09/19 11:03, Paolo Carlini wrote:
> > Hi,
> >
> > On 11/09/19 23:15, Marek Polacek wrote:
> > > --- gcc/cp/pt.c
> > > +++ gcc/cp/pt.c
> > > @@ -26709,7 +26709,7 @@ build_non_dependent_expr (tree expr)
> > >
---
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 1391a562c35..28981fa1048 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -11418,6 +11418,19 @@ The maximum number of branches unswitched in a single
loop.
@item lim-expensive
The minimum cost of an expensive
Hi, Michael,
Since I was involved in other tasks, it is a little bit late to reply you.
Sorry
for that. I composed a new one with your suggestions. Please review that
when you are in convenience.
> Generally I do like the idea of the transformation, and the basic building
> blocks seem to be
On Thu, Sep 12, 2019 at 11:24 AM Alexandre Oliva wrote:
>
> A variable redeclaration or definition that provides additional type
> information for it, e.g. outermost array bounds, is not reflected in
> the debug information for the variable. With this patch, the debug
> info of the variable
On Fri, Sep 6, 2019 at 12:59 PM Graham Markall
wrote:
>
> This patch is an RFC to invite comments as to whether the approach
> to solving the problem is a suitable one for upstream GCC, or whether
> there are alternative approaches that would be recommended.
>
> Motivation
> --
>
> We
Yuliang Wang writes:
> Hi Richard,
>
> Thanks for your comments and advice; I have applied the relevant changes.
>
> Regards,
> Yuliang
>
>
> UPDATE:
>
> Added new tests. Built and regression tested on aarch64-none-elf and
> aarch64-linux-gnu.
>
> gcc/ChangeLog:
>
> 2019-09-1 Yuliang Wang
>
>
On Sep 11 2019, Ian Lance Taylor wrote:
> On Tue, Sep 10, 2019 at 11:54 PM Andreas Schwab wrote:
>>
>> On Sep 10 2019, Ian Lance Taylor wrote:
>>
>> > On Mon, Sep 9, 2019 at 2:00 PM Andreas Schwab
>> > wrote:
>> >>
>> >> ../../../libgo/go/golang.org/x/sys/cpu/cpu.go:17:30: error: reference
On Wed, Sep 11, 2019 at 5:50 PM Wilco Dijkstra wrote:
>
> While code hoisting generally improves codesize, it can affect performance
> negatively. Benchmarking shows it doesn't help SPEC and negatively affects
> embedded benchmarks, so only enable code hoisting with -Os on Arm.
>
> Bootstrap OK,
A variable redeclaration or definition that provides additional type
information for it, e.g. outermost array bounds, is not reflected in
the debug information for the variable. With this patch, the debug
info of the variable specialization gets a type attribute with the
adjusted type.
This
Committed as 'obvious' in revision 275681:
2019-09-12 Paul Thomas
PR fortran/91686
Backport from mainline
* trans-expr.c (gfc_trans_assignment_1): Copy and paste section
handling the rse.pre block from mainline.
2019-09-12 Paul Thomas
PR fortran/91686
*
Hi again,
On 12/09/19 11:03, Paolo Carlini wrote:
Hi,
On 11/09/19 23:15, Marek Polacek wrote:
--- gcc/cp/pt.c
+++ gcc/cp/pt.c
@@ -26709,7 +26709,7 @@ build_non_dependent_expr (tree expr)
if (TREE_CODE (expr) == COND_EXPR)
return build3 (COND_EXPR,
TREE_TYPE (expr),
-
Hi,
On 11/09/19 23:15, Marek Polacek wrote:
--- gcc/cp/pt.c
+++ gcc/cp/pt.c
@@ -26709,7 +26709,7 @@ build_non_dependent_expr (tree expr)
if (TREE_CODE (expr) == COND_EXPR)
return build3 (COND_EXPR,
TREE_TYPE (expr),
- TREE_OPERAND (expr, 0),
+
Hi Steve,
I have inserted a my_core%msg = '"" so that it is initialised. The
reallocation on assignment explicitly deals with an unallocated entity
or one of its allocatable components by allocation, rather than
reallocation.
I realise that my explanation of the patch might be a bit sparse. The
On Wed, 11 Sep 2019, Kewen.Lin wrote:
> Hi,
>
> Sorry for the late update. I've updated the words of target hooks part.
>
> Could someone help to review it? Thanks in advance!
>
> By the way, as previous emails in this thread, Bin has approved the IVOPTs
> part, while Segher has approved the
On Wed, 11 Sep 2019, Bernd Edlinger wrote:
> On 9/11/19 8:30 PM, Richard Biener wrote:
> > On September 11, 2019 7:41:22 PM GMT+02:00, Bernd Edlinger
> > wrote:
> >> On 9/11/19 6:08 PM, Jeff Law wrote:
> >>> On 9/11/19 7:49 AM, Bernd Edlinger wrote:
> On 9/11/19 9:23 AM, Richard Biener
Segher Boessenkool writes:
> On Wed, Sep 11, 2019 at 08:08:38PM +0100, Richard Sandiford wrote:
>>hard_reg_set_iterator hrsi;
>> - EXECUTE_IF_SET_IN_HARD_REG_SET (regs_invalidated_by_call, 0, i, hrsi)
>> + EXECUTE_IF_SET_IN_HARD_REG_SET (abi.full_and_partial_reg_clobbers (),
>>
Hi Richard,
Thanks for your comments and advice; I have applied the relevant changes.
Regards,
Yuliang
UPDATE:
Added new tests. Built and regression tested on aarch64-none-elf and
aarch64-linux-gnu.
gcc/ChangeLog:
2019-09-1 Yuliang Wang
PR tree-optimization/89386
*
Yes, you are correct. Tested it and it works as intended.
Thanks,
Jonas
--- a/gcc/config/microblaze/microblaze.h
+++ b/gcc/config/microblaze/microblaze.h
@@ -695,7 +695,7 @@ do {
\
fprintf (STREAM, "\t.align\t%d\n",
43 matches
Mail list logo
