On Wed, Jan 30, 2019 at 9:51 PM Janne Blomqvist
wrote:
>
> On Wed, Jan 30, 2019 at 9:12 PM Uros Bizjak wrote:
>>
>> On Wed, Jan 30, 2019 at 10:37 AM Uros Bizjak wrote:
>>
>> > > Your decription suggests that this fixes PR fortran/88678.
>> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678
Hi folks.
The problem here is that Wprintf* uses the evrp_range_analyzer engine,
and doesn't understand that the x_5 != 256 conditional below should make
the RANGE [0, 255], not [0, 256].
[local count: 1063004407]:
# RANGE [0, 256] NONZERO 511
# x_10 = PHI <0(2), x_5(3)>
snprintf (,
On Wed, Jan 30, 2019 at 05:29:52PM -0800, Jerry DeLisle wrote:
> The attached patch is straight-forward and self explanatory.
>
> Regression tested on x86-64-pc-linux-gnu. Test case attached.
>
> OK for trunk?
>
Yes. Thanks for patch.
--
Steve
On Wed, 30 Jan 2019, Martin Sebor wrote:
> A change I made a couple of years ago to the Cast To a Union section
> of the manual incorrectly stated that the cast yields an lvalue when
> it, in fact, yields an rvalue. The attached patch corrects this
> mistake and expands the description to
The attached patch is straight-forward and self explanatory.
Regression tested on x86-64-pc-linux-gnu. Test case attached.
OK for trunk?
2019-01-31 Jerry DeLisle
PR fortran/52564
* io.c (match_io): Add check for comma after '*' without subsequent
IO list.
diff
It's too risk to reuse the type field for USING_DECL_SCOPE.
Language-independent parts of the compiler, such as location and
non-lvalue wrappers, happily take the TREE_TYPE of a USING_DECL as if
it was a type rather than an unrelated scope.
For better or worse, USING_DECLs use the non-common
On Wed, 23 Jan 2019, Tamar Christina wrote:
> This patch adds the documentation for Stack clash protection and
> Armv8.3-a support to changes.html for GCC 9.
Some additional notes, all minor, for consideration before you commit.
+The probing interval/guard size can be set by using
+
A change I made a couple of years ago to the Cast To a Union section
of the manual incorrectly stated that the cast yields an lvalue when
it, in fact, yields an rvalue. The attached patch corrects this
mistake and expands the description to further clarify the construct
based on a discussion
On 1/30/19 6:37 PM, Jakub Jelinek wrote:
Hi!
The r265077 changes broke
+FAIL: libstdc++-prettyprinters/cxx17.cc print p
+FAIL: libstdc++-prettyprinters/cxx17.cc print p
+FAIL: libstdc++-prettyprinters/cxx17.cc print q
+FAIL: libstdc++-prettyprinters/cxx17.cc print q
+FAIL:
Hi!
As mentioned in the PR, we refuse to inline with -fsanitize=address
no_sanitize_address functions into functions without that attribute,
which is good and has been requested in PR59600.
We also refuse to inline functions without that attribute into
no_sanitize_address functions, which is ok
Hi!
The r265077 changes broke
+FAIL: libstdc++-prettyprinters/cxx17.cc print p
+FAIL: libstdc++-prettyprinters/cxx17.cc print p
+FAIL: libstdc++-prettyprinters/cxx17.cc print q
+FAIL: libstdc++-prettyprinters/cxx17.cc print q
+FAIL: libstdc++-prettyprinters/cxx17.cc print wp
+FAIL:
Hi!
DECL_OMP_PRIVATIZED_MEMBER VAR_DECLs aren't capture proxies, handling them
that way results in various ICEs.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk.
2019-01-30 Jakub Jelinek
PR c++/88988
* lambda.c (is_capture_proxy):
Previously the operator+=(extension) call would have re-parsed the path
and recreated the components with the right extension. Since optimising
it to not re-parse the whole string, we need to actually remove the
extension from the final filename before appending anything to it, and
append the dot
PR c/89122 reports that we emit a bogus fix-it hint for the case where
the code uses FLT_MAX, but has included rather than :
x.c:3:11: error: 'FLT_MAX' undeclared here (not in a function); did you
mean 'INT_MAX'?
3 | float f = FLT_MAX;
| ^~~
| INT_MAX
On 1/30/19 4:15 PM, Marek Polacek wrote:
On Wed, Jan 30, 2019 at 04:11:11PM -0500, Marek Polacek wrote:
On Tue, Jan 29, 2019 at 09:40:18PM -0500, Jason Merrill wrote:
On Tue, Jan 29, 2019 at 6:53 PM Marek Polacek wrote:
My recent patch for 88815 and 78244 caused 89083, a P1 9 regression,
libgomp/
* testsuite/libgomp.oacc-fortran/optional-cache.f95
* testsuite/libgomp.oacc-fortran/optional-data-copyin-by-value.f90
* testsuite/libgomp.oacc-fortran/optional-data-copyin.f90
* testsuite/libgomp.oacc-fortran/optional-data-copyout.f90
*
This patch allows allocatable arrays to be used as Fortran optional
arguments. When an optional argument is detected, the Fortran front-end
now generates extra code to test if the argument is null. If so, it sets
the size of the array contents to zero, and the pointers to data to
null. This
The lowering for firstprivate uses the pointer size rather than the size
of the referenced object when passed an optional argument. This patch
detects optional arguments as a special case and treats them as
reference types.
gcc/
* omp-general.c (omp_is_optional_argument): New.
A non-present passed-by-reference Fortran optional argument is
represented by a null pointer. When passed to an update directive, it
should be ignored as variable mappings are not created for null
pointers. This should be safe as it is not possible to change a
non-present argument into a
This patch series adds support for the use of Fortran optional arguments
in OpenACC constructs as specified by the OpenACC 2.6 standard.
I will shortly commit these to openacc-gcc-8-branch if there are no
objections.
Kwok
On 1/29/19 7:15 PM, Martin Sebor wrote:
+ /* Try to convert the original SIZE to a ssizetype. */
+ if (orig_size != error_mark_node
+ && !TYPE_UNSIGNED (TREE_TYPE (orig_size)))
+ {
+ if (TREE_CODE (size) == INTEGER_CST
+ &&
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87246
The patch was successfully bootstrapped and tested on x86-64 and ppc64.
Committed as rev. 268404
Index: ChangeLog
===
--- ChangeLog (revision
On Wed, Jan 30, 2019 at 04:11:11PM -0500, Marek Polacek wrote:
> On Tue, Jan 29, 2019 at 09:40:18PM -0500, Jason Merrill wrote:
> > On Tue, Jan 29, 2019 at 6:53 PM Marek Polacek wrote:
> > >
> > > My recent patch for 88815 and 78244 caused 89083, a P1 9 regression, which
> > > happens to be the
On Tue, Jan 29, 2019 at 09:40:18PM -0500, Jason Merrill wrote:
> On Tue, Jan 29, 2019 at 6:53 PM Marek Polacek wrote:
> >
> > My recent patch for 88815 and 78244 caused 89083, a P1 9 regression, which
> > happens to be the same problem as 80864 and its many dupes, something I'd
> > been meaning
On Wed, Jan 30, 2019 at 9:12 PM Uros Bizjak wrote:
> On Wed, Jan 30, 2019 at 10:37 AM Uros Bizjak wrote:
>
> > > Your decription suggests that this fixes PR fortran/88678.
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678
> >
> > Actually, additional patch is needed to fully fix PR88678.
Hi,
On 30/01/19 17:25, Alexandre Oliva wrote:
+static inline bool
+instantiates_primary_template_p (tree node)
I'm rather surprised by the inline: as a general rule, we want functions
this size all inline? I would say that in the C++ library we don't,
sure, not very big but already too big.
Hi Paul,
Are you sure about the && in
+ && ref->u.c.component->ts.type != BT_DERIVED))
should not it be ||?
TIA
Dominique
Sorry about the premature 'send'.
This one is more or less obvious and is described in the ChangeLog.
The key point is that full or section array references to intrinsic
components were returning a false true from expr.c (is_subref_array).
Returning false if a component is intrinsic and following
This one is more or less obvious and is described in the ChangeLog.
The key point is that full or section array references to intrinsic
components were returning a false true from expr.c (is_subref_array).
Returning false if a component is intrinsic and following anything
other than an array
On Wed, Jan 30, 2019 at 10:37 AM Uros Bizjak wrote:
> > Your decription suggests that this fixes PR fortran/88678.
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678
>
> Actually, additional patch is needed to fully fix PR88678.
> support_fpu_trap enables and disables exceptions and this may
On 1/30/19 11:25 AM, Alexandre Oliva wrote:
On Jan 30, 2019, Jason Merrill wrote:
Hmm, I wouldn't expect that from a function named
"instantiates_primary_template_p".
Hmm, indeed.
Perhaps another function that calls instantiates_primary_template_p
and then checks for dependent innermost
On 1/30/19 12:43 PM, Marek Polacek wrote:
While looking at the other PR I came across this ICE. We're substituting
{.a={[0 ... 3]=0}}
which contains a RANGE_EXPR that build_value_init_noctor created, but none
of the tsubst_* functions handle it. As discussed in the PR, a RANGE_EXPR
will
On 1/28/19 9:46 PM, Marek Polacek wrote:
This patch fixes an ICE-on-invalid (becase out-of-line constructors can't have
template arguments and also because function templates can't be partially
specialized) in C++2a: when we're parsing
template template A::A ()
in the attached test we end
I have committed this patch to openacc-gcc-8-branch. When invoking gcc
to compile fortran code, fortran.exp is currently adding the options
-lgfortran -foffload=-lgfortran to the gcc command line. libgfortran
statically links to libquadmath and the gfortran driver invokes the
linker with
While looking at the other PR I came across this ICE. We're substituting
{.a={[0 ... 3]=0}}
which contains a RANGE_EXPR that build_value_init_noctor created, but none
of the tsubst_* functions handle it. As discussed in the PR, a RANGE_EXPR
will always be created with constant operands, so
On Jan 30, 2019, Jason Merrill wrote:
> Hmm, I wouldn't expect that from a function named
> "instantiates_primary_template_p".
Hmm, indeed.
> Perhaps another function that calls instantiates_primary_template_p
> and then checks for dependent innermost template args?
Does that come up as
Because of rank compares, and checks for ck_list, we know that if we
see user_conv_p or ck_list in ics1, we'll also see it in ics2. This
reasoning does not extend to ck_aggr, however, so we might have
ck_aggr conversions starting both ics1 and ics2, which we handle
correctly, or either, which we
This patch by Ben Shi to the Go frontend fixes it to support an
aliases to a pointer type as a method receiver. This fixes
https://golang.org/issue/28252. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
No objection, so committed as revision r268396 with the ChangeLog
2019-01-30 Dominique d'Humieres Le 27 janv. 2019 à 15:19, Dominique d'Humières a écrit :
>
> Hi,
>
> The following patch is an update of
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52884#c3,
> I am planning to commit
Hi Gerald,
Yup that's fine :) I won't be able to commit it before Monday anyway.
Cheers,
Tamar
From: Gerald Pfeifer
Sent: Wednesday, January 30, 2019 3:37 PM
To: James Greenhalgh
Cc: Tamar Christina; gcc-patches@gcc.gnu.org; nd; Richard Earnshaw; Marcus
On Wed, 30 Jan 2019, James Greenhalgh wrote:
> Otherwise OK, though I don't remember if that is for me to OK, or
> someone else.
Yes, it is. :-)
(But I'll also have a look tonight if you want to wait for that
Tamar, but that's only an offer. We can always iterate.)
Gerald
On 30/01/19 15:29, James Greenhalgh wrote:
On Wed, Jan 23, 2019 at 04:43:02AM -0600, Tamar Christina wrote:
> Hi All,
>
> This patch adds the documentation for Stack clash protection and Armv8.3-a
support to
> changes.html for GCC 9.
> I have validated the html using the W3C validator.
>
> Ok
On Wed, Jan 23, 2019 at 04:43:02AM -0600, Tamar Christina wrote:
> Hi All,
>
> This patch adds the documentation for Stack clash protection and Armv8.3-a
> support to
> changes.html for GCC 9.
> I have validated the html using the W3C validator.
>
> Ok for cvs?
Almost OK by me.
>
> Thanks,
>
> Le 28 janv. 2019 à 14:54, Manfred Schwarb a écrit :
>
> Am 26.01.2019 um 16:14 schrieb Dominique d'Humières:
>> I have committed the following patch to the gcc-7-branch as r268294 after a
>> regtest.
>> Manfred, could you please check with your script that I did not miss
>> some test in
Hi!
On Thu, 28 Jan 2016 10:38:51 -0500, Nathan Sidwell wrote:
> This patch adds default compute dimension handling. [...]
> --- gcc/doc/invoke.texi (revision 232881)
> +++ gcc/doc/invoke.texi (working copy)
> @@ -1963,9 +1963,13 @@ Programming Interface v2.0 @w{@uref{http
>
Hi Jakub,
On Wed, Jan 30, 2019 at 02:06:01PM +, Tamar Christina wrote:
> > Thanks for the feedback, but I think those are changes for another patch.
>
> At least the memory leak is something that should be fixed even in stage4
> IMNSHO.
I'll provide a separate patch for this then.
> Anyway,
On Mon, 21 Jan 2019, Alexander Monakov wrote:
> Ah, I see now. I agree transparent_union ought to work, but today both GCC
> and Clang will reject such attempt; I've filed PR 88955 for the GCC issue.
>
> So unfortunately such code would still need a cast or an unnamed temporary,
> which may be
Hi!
On Fri, 27 May 2016 08:19:56 -0700, Cesar Philippidis
wrote:
> This patch backports the recent firstprivate subarray changes I've made
> [...]
> Thomas, I decided to xfail a bunch of kernels tests in gomp4 instead of
> removing them so that we can have a better record on what changed. [...]
On 01/30/2019 07:45 AM, Richard Biener wrote:
The PR89115 spends ~66% of its compile-time in LRA reload inheritance
because of a weak hash and a lot of collisions in the invaraints hash.
This can be fixed by the following, bringing down inheritance time
to the noise.
Bootstrap / regtest
On Wed, Jan 30, 2019 at 02:06:01PM +, Tamar Christina wrote:
> Thanks for the feedback, but I think those are changes for another patch.
At least the memory leak is something that should be fixed even in stage4
IMNSHO.
Anyway, will defer to aarch64 maintainers here.
Just one question, for
This patch simplifies the function tanh (x) * cosh (x) -> sinh (x).
This rule is derived from the relationship between hyperbolic
functions.
I ran the tests and gfortran.dg/pr79966.f90 failed, but this failure
is unrelated to the patch (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88711 for
Hi Jakub,
Thanks for the feedback, but I think those are changes for another patch.
The patch here does not introduce the problems you highlighted and I don't feel
these changes are appropriate for stage4 or that they should block this patch.
Kind regards,
Tamar
Ping.
From: gcc-patches-ow...@gcc.gnu.org on behalf
of Tamar Christina
Sent: Tuesday, January 15, 2019 5:12:46 PM
To: Kyrill Tkachov
Cc: gcc-patches@gcc.gnu.org; nd; James Greenhalgh; Richard Earnshaw; Marcus
Shawcroft
Subject: Re:
Ping.
From: gcc-patches-ow...@gcc.gnu.org on behalf
of Tamar Christina
Sent: Wednesday, January 23, 2019 10:43:02 AM
To: gcc-patches@gcc.gnu.org
Cc: nd; James Greenhalgh; Richard Earnshaw; Marcus Shawcroft; Ramana
Radhakrishnan; ni...@redhat.com;
The following works around the DSE part of PR89115, consuming huge
amounts of memory and compile-time. To make "bad" testcases behave
more reasonably the following cuts down --param
max-dse-active-local-stores from 5000 to 500, reducing compile-time
by a factor of 2.5 and memory use by a
Hi,
Segher wrote:
>On Tue, Jan 29, 2019 at 02:51:30PM -0800, Andrew Pinski wrote:
>
>> Seems to me rather this should have been simplified to just:
>> (set (reg:SI 93)
>> (ashift:SI (sign_extract:SI (reg:SI 95)
>> (const_int 3 [0x3])
>> (const_int 0 [0]))
The PR89115 spends ~66% of its compile-time in LRA reload inheritance
because of a weak hash and a lot of collisions in the invaraints hash.
This can be fixed by the following, bringing down inheritance time
to the noise.
Bootstrap / regtest running on x86_64-unknown-linux-gnu, OK for trunk
On 29/01/2019 11:31, Richard Biener wrote:
OK.
Thanks. Patch committed.
Andrew
On Tue, Jan 29, 2019 at 9:20 PM Steve Kargl
wrote:
>
> On Tue, Jan 29, 2019 at 08:46:40PM +0100, Uros Bizjak wrote:
> >
> > When changing trap masks, it is necessary to clear pending traps to
> > prevent firing spurious interrupts. Attached patch also optimizes
> > set_fpu_trap_exceptions
I am testing the following patch to restrict MEM canonicalization
in LIM further.
Bootstrap and regtest running on x86_64-unkown-linux-gnu.
Richard.
2019-01-30 Richard Biener
PR tree-optimization/89111
* tree-ssa-loop-im.c (gather_mem_refs_stmt): Restrict
60 matches
Mail list logo
