On Fri, Mar 15, 2019 at 11:33:06PM +0100, Thomas Koenig wrote:
> Am 15.03.19 um 21:31 schrieb Steve Kargl:
> > Patch is missing?
>
> Entirely correct. Here it is.
>
Patch looks ok to me.
--
Steve
Am 15.03.19 um 21:31 schrieb Steve Kargl:
Patch is missing?
Entirely correct. Here it is.
Regards
Thomas
Index: symbol.c
===
--- symbol.c (Revision 269635)
+++ symbol.c (Arbeitskopie)
@@ -1689,7 +1689,15 @@ gfc_add_subro
I've committed a slightly rewritten version of the error messages
to trunk as rev.269717, see attached.
Thanks for the review and the comments.
Harald
On 03/12/19 23:19, Thomas Koenig wrote:
> Hi Harald,
>
>> how about the attached version? It is quite verbose and produces
>> messages like
>>
Hi!
On Fri, Mar 15, 2019 at 04:25:01PM -0400, Vladimir Makarov wrote:
> On 2019-03-15 2:30 p.m., Segher Boessenkool wrote:
> >PR89721 shows LRA treating an unspec_volatile's result as invariant,
> >which of course isn't correct. This patch fixes it.
> Segher, thank you for fixing this. The patch
On Thu, 14 Mar 2019 10:19:17 +0100
Jakub Jelinek wrote:
> On Thu, Mar 14, 2019 at 09:57:27AM +0100, Richard Biener wrote:
> > I'd say make it work, thus your patch below is OK.
>
> Ok, here is an updated patch with some self-tests coverage as well that I'll
> bootstrap/regtest.
I had the simp
Hi!
As the testcase shows, we replace TLS vars that need initialization
in finish_id_expression_1 and in tsubst_copy_and_build of a VAR_DECL
with a _ZTW* call, but miss it in other cases where finish_id_expression
is not actually called. In particular build_class_member_access_expr
when we do obj
Hi!
As the enhanced testcase shows, ix86_expand_floorceildf_32 doesn't emit
correct ceil when honoring signed zeros, because it performs copysign,
then comparison and then based on the comparison an optional addition of 1.
The comment claims that it is essential to use x2 -= -1.0 instead of
x2 +=
On Fri, Mar 15, 2019 at 07:55:51PM +0100, Thomas Koenig wrote:
> Hello world,
>
> this patch fixes a rejects-valid 7/8/9 regression where subroutines like
> _deallocate are added to a derived type in a block data, and because
> they were marked PRIVATE, an error occurred.
>
> This solution is loo
On 2019-03-15 2:30 p.m., Segher Boessenkool wrote:
PR89721 shows LRA treating an unspec_volatile's result as invariant,
which of course isn't correct. This patch fixes it.
Segher, thank you for fixing this. The patch is ok to commit.
Question. Is side_effects_p the correct check? Or do we
Hi!
As reported in the PR, when glibc installs math-vector-fortran.h header,
e.g. continuation_9.f90 testcase breaks.
The problem is that load_line does its own current line counting and does
that as a rolling count of how many lines were seen already, ignoring
preprocessor line numbers, or includ
On Fri, Mar 08, 2019 at 02:51:42PM +0100, Richard Biener wrote:
> Well, I think having only a single limit is desirable which means we have to
> count something resembling the overall work done. We don't have to document
> that it matches "statements" (whatever that exactly would be).
>
> I don't
Hello world,
this patch fixes a rejects-valid 7/8/9 regression where subroutines like
_deallocate are added to a derived type in a block data, and because
they were marked PRIVATE, an error occurred.
This solution is look for this particular case by checking for an
underscore as the first letter
PR89721 shows LRA treating an unspec_volatile's result as invariant,
which of course isn't correct. This patch fixes it.
Question. Is side_effects_p the correct check? Or do we want to
allow PRE_INC etc. here? What about CALL?
Segher
2019-04-15 Segher Boessenkool
PR rtl-optimiz
On 3/15/19 9:28 AM, Paolo Carlini wrote:
Hi,
another - rather long standing - error-recovery regression, where, in
some rather special circumstances, we end up passing the FUNCTION_DECL
representing the operator () of the lambda to maybe_dummy_object and
obviously we almost immediately crash.
On 3/15/19 9:33 AM, Richard Biener wrote:
The following is an attempt to fix PR71598 where C (and C++?) have
an implementation-defined compatible integer type for each enum
and the TBAA rules mandate that accesses using a compatible type
are allowed.
This does not apply to C++; an enum does no
This patch by Than McIntosh fixes the Go frontend to preserve the
nointerface property when inlining method bodies. This fixes
https://golang.org/issue/30862. Bootstrapped and ran Go tests on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
Hi,
I moved my entry in the MAINTAINERS file per
https://gcc.gnu.org/ml/gcc/2011-11/msg00264.html and
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00761.html .
Alexander
* MAINTAINERS (Reviewers): Add myself as selective scheduling reviewer.
(Write After Approval): Remove myself
Hi,
On Fri, 15 Mar 2019, Michael Matz wrote:
> I.e. what you touched is the naming of sets (giving them identifiers),
> whereas you should have touched where the relations between the sets are
> established. I _think_ instead of giving enum and basetypes the same
> alias set you should have r
Hi,
On Fri, 15 Mar 2019, Richard Biener wrote:
> >But different enums aren't compatible with each other (or are they?),
> >while your fix simply gives enums the aliasing set of the underlying
> >type, i.e. makes all of them alias with each other. That's quite
> >conservative.
>
> But that fo
On Thu, 14 Mar 2019, Jonathan Wakely wrote:
> The checksum file uses SHA512 not MD5SUM, so the instructions should be
> updated accordingly.
>
> SInce there's only one tarfile these days (not separate ones for
> gcc-base, gcc-g++, gcc-fortran, etc) it doesn't seem necessary to
> filter out the "O
On Wed, Mar 13, 2019 at 10:01 AM Martin Sebor wrote:
>
> A recent change (r269633 AFAICS) introduced the constexpr keyword
> into go which breaks bootstrap with a C++ 98 compiler. I fixed
> it like this in my tree but haven't fully tested it. I just
> thought I'd send a heads up before others ru
Hi,
during the last few days I tried to get D running on s390x (apparently
the first Big Endian platform to try it?). I did not yet go through the
code systematically and add a version(SystemZ) in every place where it
might be needed but rather tried to fix test failures as they arose.
After en
On March 15, 2019 3:39:16 PM GMT+01:00, Michael Matz wrote:
>Hi,
>
>On Fri, 15 Mar 2019, Richard Biener wrote:
>
>> The following is an attempt to fix PR71598 where C (and C++?) have an
>
>> implementation-defined compatible integer type for each enum and the
>> TBAA rules mandate that accesses u
Hi,
On Fri, 15 Mar 2019, Richard Biener wrote:
> The following is an attempt to fix PR71598 where C (and C++?) have an
> implementation-defined compatible integer type for each enum and the
> TBAA rules mandate that accesses using a compatible type are allowed.
But different enums aren't compa
Hi , James:
Thank you very much for your meticulous review work. The explanation of
the two questions as follows:
The first problem is caused by my negligence and should be changed to "
crypto_sha256_fast" .
The second question I have verified with the hardware engineer. Only ALU2/ALU3
On Mar 14, 2019, Jason Merrill wrote:
>> You can use VAR_P for this.
> OK with that change.
Thanks, I went ahead and also added a test before dereferencing it,
since there was evidence shortly thereafter that it could possibly be
NULL.
Here's what I'm installing.
P0732R2 / C++ 2a introduce c
Hi,
The patch merges the D front-end implementation with dmd upstream 8d4c876c6.
Backports fix where the extern storage class flag was wrongly
propagated to function scope when starting the semantic pass on the
body.
Bootstrapped and regression tested on x86_64-linux-gnu.
Committed to trunk as
The following is an attempt to fix PR71598 where C (and C++?) have
an implementation-defined compatible integer type for each enum
and the TBAA rules mandate that accesses using a compatible type
are allowed.
The fix is applied to all C family frontends and the LTO frontend
but not Fortran, Ada
Hi,
another - rather long standing - error-recovery regression, where, in
some rather special circumstances, we end up passing the FUNCTION_DECL
representing the operator () of the lambda to maybe_dummy_object and
obviously we almost immediately crash. Not sure how much we want to dig
- but s
>
> A previous patch of mine correcting the vectorizer target cost model
> to properly cost scalar FP ops vs. scalar INT ops regressed
> 416.gamess by ~10% on all modern x86 archs.
>
> The following mitigates this in the cost modeling by noticing
> the vectorized loop in question has all loads an
A previous patch of mine correcting the vectorizer target cost model
to properly cost scalar FP ops vs. scalar INT ops regressed
416.gamess by ~10% on all modern x86 archs.
The following mitigates this in the cost modeling by noticing
the vectorized loop in question has all loads and stores perf
On 15.03.19 13:19, Robin Dapp wrote:
> Hi,
>
> r269586 puts single quotes around option names. This patch fixes tests
> that expect the old format.
>
> Regards
> Robin
>
> ---
>
> gcc/testsuite/ChangeLog:
>
> 2019-03-15 Robin Dapp
>
> * gcc.target/s390/target-attribute/tattr-1.c (ht
Hi,
r269586 puts single quotes around option names. This patch fixes tests
that expect the old format.
Regards
Robin
---
gcc/testsuite/ChangeLog:
2019-03-15 Robin Dapp
* gcc.target/s390/target-attribute/tattr-1.c (htm0):
-mhtm -> '-mhtm'.
* gcc.target/s390/target-a
On Fri, Mar 15, 2019 at 02:27:35PM +0300, Alexander Monakov wrote:
> On Fri, 15 Mar 2019, Jakub Jelinek wrote:
>
> > On Fri, Mar 15, 2019 at 01:25:57PM +0300, Andrey Belevantsev wrote:
> > > As explained in the PR trail, we incorrectly update the availability sets
> > > in the rare case of several
On Fri, 15 Mar 2019, Jakub Jelinek wrote:
> On Fri, Mar 15, 2019 at 01:25:57PM +0300, Andrey Belevantsev wrote:
> > As explained in the PR trail, we incorrectly update the availability sets
> > in the rare case of several successors and one of them having another
> > fence. Fixed as follows. Ok
On Fri, Mar 15, 2019 at 01:25:57PM +0300, Andrey Belevantsev wrote:
> As explained in the PR trail, we incorrectly update the availability sets
> in the rare case of several successors and one of them having another
> fence. Fixed as follows. Ok for trunk?
>
> Best,
> Andrey
>
> 2019-03-15 And
Hello,
As explained in the PR trail, we incorrectly update the availability sets
in the rare case of several successors and one of them having another
fence. Fixed as follows. Ok for trunk?
Best,
Andrey
2019-03-15 Andrey Belevantsev
PR middle-end/89676
* sel-sched.c (comput
Hi all,
As of recently the -march,-mcpu,-mtune strings in the error messages are
now quoted.
This patch adjusts the testcases in gcc.target/aarch64/ that had started
failing due to that change.
Committing to trunk as obvious.
Thanks,
Kyrill
2019-03-15 Kyrylo Tkachov
PR target/89719
The following backports support for --param logical-op-non-short-circuit
to the GCC 8 branch (but not all the testsuite adjustments) and adjusts
the gcc.dg/uninit-pred-8_b.c as was done on trunk for the PR89497 fix.
Boostrap / regtest running on x86_64-unknown-linux-gnu.
Richard.
2019-03-15 R
On Fri, 15 Mar 2019, Jakub Jelinek wrote:
> On Fri, Mar 15, 2019 at 09:46:33AM +0100, Richard Biener wrote:
> > On Fri, 15 Mar 2019, Jakub Jelinek wrote:
> >
> > > On Fri, Mar 15, 2019 at 09:22:26AM +0100, Richard Biener wrote:
> > > > That said, I think we can go with my patch for GCC 9 and defe
On Thu, 14 Mar 2019, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, r267272 added STRIP_ANY_LOCATION_WRAPPERS
> at the start of operand_equal_p, but has not updated inchash::add_expr
> which needs to follow what operand_equal_p does, so that if two trees
> compare equal, they get the same
On Fri, Mar 15, 2019 at 09:46:33AM +0100, Richard Biener wrote:
> On Fri, 15 Mar 2019, Jakub Jelinek wrote:
>
> > On Fri, Mar 15, 2019 at 09:22:26AM +0100, Richard Biener wrote:
> > > That said, I think we can go with my patch for GCC 9 and defer a more
> > > complete and elaborate solution to GCC
On Fri, 15 Mar 2019, Jakub Jelinek wrote:
> On Fri, Mar 15, 2019 at 09:22:26AM +0100, Richard Biener wrote:
> > That said, I think we can go with my patch for GCC 9 and defer a more
> > complete and elaborate solution to GCC 10 (where I'd still prefer
> > sth simple).
> >
> > What do you think?
>
On Fri, Mar 15, 2019 at 09:22:26AM +0100, Richard Biener wrote:
> That said, I think we can go with my patch for GCC 9 and defer a more
> complete and elaborate solution to GCC 10 (where I'd still prefer
> sth simple).
>
> What do you think?
Ok. gimple_purge_dead_abnormal_call_edges after all is
Hi.
One more documentation patch.
Martin
>From 12a1a2bf98075d79d60189d3d3b4d6c3de79a877 Mon Sep 17 00:00:00 2001
From: marxin
Date: Thu, 14 Mar 2019 14:19:33 +
Subject: Backport r269684
gcc/ChangeLog:
2019-03-14 Martin Liska
PR other/89712
* doc/invoke.texi: Remove -fdump-class-hiera
On Thu, 14 Mar 2019, Jakub Jelinek wrote:
> On Thu, Mar 14, 2019 at 03:10:59PM +0100, Richard Biener wrote:
> > I've added a testcase.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK for trunk
> > or should it wait for GCC10?
>
> I meant something like following where we'd clean
46 matches
Mail list logo
