On Tue, Jan 23, 2018 at 5:49 AM, Ian Lance Taylor wrote:
> On Sun, Jan 21, 2018 at 3:13 PM, Uros Bizjak wrote:
>>
>> The default "go build" compile options over-optimize the auxiliary
>> executable, built in TestCrashDumpsAllThreads testcase
>> (libgo/go/runtime/crash_unix_test.go). This over-opt
Dear Paul,
The test suite passed without new regression with both -m32 and -m64.
Thanks for the work,
Dominique
I'm heading out of town for a meeting at the end of
week, so gfortran patches/reviews are on hold at the
moment. If someone else wants to step up to review
the patch, I won't object.
--
steve
On Mon, Jan 22, 2018 at 08:29:41PM -0800, Damian Rouson wrote:
> Is Fortran 2018 teams patch ok for tru
On Sun, Jan 21, 2018 at 3:13 PM, Uros Bizjak wrote:
>
> The default "go build" compile options over-optimize the auxiliary
> executable, built in TestCrashDumpsAllThreads testcase
> (libgo/go/runtime/crash_unix_test.go). This over-optimization results
> in removal of the trivial summing loop and i
This patch by Tony Reix adds buildid support to the go tool for AIX.
This supports caching of build results. Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
---
Is Fortran 2018 teams patch ok for trunk?
Damian
On January 19, 2018 at 2:47:39 PM, Alessandro Fanfarillo (elfa...@ucar.edu)
wrote:
I can confirm that the little change suggested by Steve passes the
regtests (on x86_64-pc-linux-gnu) and the regular tests using
OpenCoarrays.
On Fri, Ja
On 01/22/2018 12:24 PM, Thomas Koenig wrote:
> Am 22.01.2018 um 20:59 schrieb Janne Blomqvist:
>> On Mon, Jan 22, 2018 at 9:12 PM, Paul Richard Thomas
>> wrote:
>>> This patch has been triggered by Thomas's recent message to the list.
>>> Not only did I start work late relative to stage 3 but debu
On Mon, Jan 22, 2018 at 6:14 PM, Jakub Jelinek wrote:
> On Mon, Jan 22, 2018 at 04:49:34PM -0500, Jason Merrill wrote:
>> On Thu, Jan 18, 2018 at 6:13 PM, Jakub Jelinek wrote:
>> > Before location wrappers were introduced, the
>> > potential_constant_expression_1
>> > assumption that a VIEW_CONV
On Mon, Jan 22, 2018 at 12:32:13PM -0600, Segher Boessenkool wrote:
> Hi Mike,
>
> If it is needed on the branches, okay for there too (once 7 reopens).
It is needed on GCC 7 if you compile the test for -mcpu=power9 and use
an explicit __float128 instead of long double (-mabi=ieeelongdouble is no
On Mon, Jan 22, 2018 at 04:49:34PM -0500, Jason Merrill wrote:
> On Thu, Jan 18, 2018 at 6:13 PM, Jakub Jelinek wrote:
> > Before location wrappers were introduced, the
> > potential_constant_expression_1
> > assumption that a VIEW_CONVERT_EXPR must have non-NULL type was right,
> > if it is a ty
Hi!
I've recently added the complete_type call in case the structured binding
is a reference to a type that needs to be instantiated.
This testcase shows a problem where it can't be instantiated and we ICE
because we don't expect an incomplete type. If decl isn't a reference,
cp_finish_decl for i
Hi!
The ompexpssa pass will do TODO_update_ssa_only_virtuals, so don't need
to handle in detail vops. In this case the inner_phi is NULL for the vop
and we crash on it.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2018-01-22 Jakub Jelinek
PR tree-optimi
In this testcase, determine_visibility was relying on the template
argument handling to constrain the lambda in h to internal linkage.
In the new lambda model, the local lambda has no template info, so
that was breaking. So we shouldn't rely on the decl itself to trigger
checking the containing fu
On Mon, Jan 22, 2018 at 09:59:41PM +0200, Janne Blomqvist wrote:
> On Mon, Jan 22, 2018 at 9:12 PM, Paul Richard Thomas
> wrote:
> > This patch has been triggered by Thomas's recent message to the list.
> > Not only did I start work late relative to stage 3 but debugging took
> > somewhat longer t
Hi again,
On 22/01/2018 22:50, Paolo Carlini wrote:
Ok. The below passes the C++ testsuite and I'm finishing testing it.
Therefore, as you already hinted to, we can now say that what was
*really* missing from potential_constant_expression_1 was the use of
default_init_uninitialized_part, which
Hi,
On 22/01/2018 16:52, Jason Merrill wrote:
Thus the below, carefully tested over the we, would be a change completely
removing the problematic error_at call, plus some testcases checking that we
would still do the right thing in a few cases (bug submitter added
constexpr-83921-2.C). The updat
On Thu, Jan 18, 2018 at 6:13 PM, Jakub Jelinek wrote:
> Before location wrappers were introduced, the potential_constant_expression_1
> assumption that a VIEW_CONVERT_EXPR must have non-NULL type was right,
> if it is a type dependent reinterpret cast, it would be
> REINTERPRET_CAST_EXPR instead.
On Mon, 22 Jan 2018, Sebastian Huber wrote:
>> +GCC 7.3
>> +
>> +This is the > href="https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=7.3";>list
>> +of problem reports (PRs) from GCC's bug tracking system that are
>> +known to be fixed in the 7.3 releas
On January 22, 2018 8:50:44 PM GMT+01:00, David Malcolm
wrote:
>r232820 (aka 2c7b2f8860794cc9b9cf5eeea9d7dc109c0de3be) removed the
>implementation of class move_computations_dom_walker, but kept the
>decl.
>
>This patch removes the stray decl.
>
>Successfully bootstrapped®rtested on x86_64-pc-lin
Am 22.01.2018 um 20:59 schrieb Janne Blomqvist:
On Mon, Jan 22, 2018 at 9:12 PM, Paul Richard Thomas
wrote:
This patch has been triggered by Thomas's recent message to the list.
Not only did I start work late relative to stage 3 but debugging took
somewhat longer than anticipated. Therefore, to
On Fri, 2018-01-19 at 09:45 +0100, Richard Biener wrote:
> On Fri, Jan 19, 2018 at 12:36 AM, David Malcolm
> wrote:
> > PR tree-optimization/83510 reports that r255649 (for
> > PR tree-optimization/83312) introduced a false positive for
> > -Warray-bounds for array accesses within certain switch s
On Mon, Jan 22, 2018 at 9:12 PM, Paul Richard Thomas
wrote:
> This patch has been triggered by Thomas's recent message to the list.
> Not only did I start work late relative to stage 3 but debugging took
> somewhat longer than anticipated. Therefore, to get this committed
> asap, we will have to b
Dne 2018-01-22 19:36, Jakub Jelinek napsal:
On Mon, Jan 22, 2018 at 06:44:17PM +0100, Jan Hubicka wrote:
> + /* Split *THIS (ORIG) probability into 2 probabilities, such that
> + the returned one (FIRST) is *THIS * CPROB and *THIS is
> + adjusted (SECOND) so that FIRST + FIRST.invert ()
This patch adds a few extra assertions to selftest::test_location_wrappers.
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
OK for trunk?
gcc/ChangeLog:
* tree.c (selftest::test_location_wrappers): Add more test
coverage.
---
gcc/tree.c | 10 ++
1 file changed,
"make selftest-valgrind" shows a few leaks in sbitmap.c's selftests;
this patch fixes them.
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
OK for trunk?
gcc/ChangeLog:
* sbitmap.c (selftest::test_set_range): Fix memory leaks.
(selftest::test_bit_in_range): Likewise.
---
r232820 (aka 2c7b2f8860794cc9b9cf5eeea9d7dc109c0de3be) removed the
implementation of class move_computations_dom_walker, but kept the decl.
This patch removes the stray decl.
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
OK for trunk?
gcc/ChangeLog:
PR tree-optimization/69452
On Mon, Jan 22, 2018 at 12:32:13PM -0600, Segher Boessenkool wrote:
> Hi Mike,
>
> Thanks for doing this!
>
> On Sun, Jan 21, 2018 at 07:03:58PM -0500, Michael Meissner wrote:
> > With these patches, the generator code issues an UNSPEC (signbit2_dm)
> > just to get the high double word, and the s
This patch has been triggered by Thomas's recent message to the list.
Not only did I start work late relative to stage 3 but debugging took
somewhat longer than anticipated. Therefore, to get this committed
asap, we will have to beg the indulgence of the release managers and
prompt review and/or te
On Mon, Jan 22, 2018 at 06:44:17PM +0100, Jan Hubicka wrote:
> > + /* Split *THIS (ORIG) probability into 2 probabilities, such that
> > + the returned one (FIRST) is *THIS * CPROB and *THIS is
> > + adjusted (SECOND) so that FIRST + FIRST.invert () * SECOND
> > + == ORIG. */
>
> To
Hi Mike,
Thanks for doing this!
On Sun, Jan 21, 2018 at 07:03:58PM -0500, Michael Meissner wrote:
> I've reworked the patch for PR83864. This bug is due to the compiler issuing
> an internal error for code of the form on a little endian system:
>
> int sb (_Float128 *p, unsigned long n) { r
vect_float is true for arm*-*-* targets, but the support is only
available when -funsafe-math-optimizations is on. This caused
failures in two tests that disable fast-math.
The easiest fix seemed to be to add a new target selector for
"vect_float without special options".
Tested on aarch64-linux
In this PR we recognised a PLUS_EXPR as a fold-left reduction,
then applied pattern matching to convert it to a WIDEN_SUM_EXPR.
We need to keep the original code in this case since we implement
the reduction using scalar rather than vector operations.
Tested on aarch64-linux-gnu, x86_64-linux-gnu
Dne 2018-01-22 16:57, Jakub Jelinek napsal:
On Mon, Jan 22, 2018 at 02:43:50PM +0100, Jan Hubicka wrote:
> But this looks incorrect, because that computes only the above c2 in
> prob, not
> second_prob. It needs to be
> prob = cprob.invert () * prob / first_prob.invert ();
> or
> prob *= cp
Hi Roger,
On 15/01/18 14:58, Roger Sayle wrote:
I was hoping I could ask an ARM backend maintainer to look over the
following patch.
I was examining the code generated for the following C snippet on a
raspberry pi,
static inline int popcount_lut8(unsigned *buf, int n)
{
int cnt=0;
unsigne
Segher:
I put back the xxpermdi,2 stuff. Per our private discussion about the
parallel [(const_int 0)], I found that I could get GCC to compile
without parallel. GCC worked with a -O0 on the test case but I got and
IRC when using -O1. So, I had to put the parallel back in. The patch
is now wor
On Tue, Jan 16, 2018 at 03:20:24PM -0700, Martin Sebor wrote:
> gcc/ChangeLog:
>
> PR tree-optimization/83896
> * tree-ssa-strlen.c (get_string_len): Rename...
> (get_string_cst_length): ...to this. Return HOST_WIDE_INT.
> Avoid assuming length is constant.
> (handle
On 01/22/2018 01:57 AM, Jakub Jelinek wrote:
> On Mon, Jan 22, 2018 at 09:37:05AM +0100, Richard Biener wrote:
>>
>> Currently gcc_release builds GCC (for generating in-tree generated
>> files) serially - that's prohibitly expensive and takges ages (>4h for
>> me). I'm using (when I remember to e
On Sun, Jan 21, 2018 at 1:40 AM, Eric Gallager wrote:
> On 1/19/18, Nathan Sidwell wrote:
>> Jason,
>> what do you think about deprecating the ARM-era for-scope handling that
>> allows:
>>void f ()
>>{
>> for (int i = 0;;);
>> i = 2;
>>}
>>
>> we noisily accept that in c++98
On Mon, Jan 22, 2018 at 02:43:50PM +0100, Jan Hubicka wrote:
> > But this looks incorrect, because that computes only the above c2 in
> > prob, not
> > second_prob. It needs to be
> > prob = cprob.invert () * prob / first_prob.invert ();
> > or
> > prob *= cprob.invert () / first_prob.invert (
OK, thanks.
On Mon, Jan 22, 2018 at 10:44 AM, Marek Polacek wrote:
> On Mon, Jan 22, 2018 at 09:40:50AM -0500, Jason Merrill wrote:
>> This seems like a workaround rather than a fix; we should fix
>> split_nonconstant_init to work properly rather than override it.
>> Specifically, it seems odd to
On Mon, Jan 22, 2018 at 5:08 AM, Paolo Carlini wrote:
> On 20/01/2018 02:59, Paolo Carlini wrote:
>>
>> Hi again,
>>
>> On 19/01/2018 23:55, Paolo Carlini wrote:
>>>
>>> ...Therefore It seems to me that a way to more cleanly solve the bug
>>> would be moving something like || !DECL_NONTRIVIALLY_IN
On Mon, Jan 22, 2018 at 09:40:50AM -0500, Jason Merrill wrote:
> This seems like a workaround rather than a fix; we should fix
> split_nonconstant_init to work properly rather than override it.
> Specifically, it seems odd to return true if num_elts is 0; we
> shouldn't override DECL_INITIAL if we
On Mon, Jan 22, 2018 at 4:10 PM, Sudakshina Das wrote:
> Hi
>
> This is a patch to backport r256526 and r256941 (Fix case fix) of trunk to
> fix emit_store_flag_force () function to fix the ICE. The original
> discussion is at https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00219.html
> and https://
On Mon, Jan 22, 2018 at 4:01 PM, Wilco Dijkstra wrote:
> PR79262 has been fixed for almost all AArch64 cpus, however the example is
> still
> vectorized in a few cases, resulting in lower performance. Increase the cost
> of
> vector-to-scalar moves so it is more similar to the other vector cost
GRAPHITE has little testing coverage so only SPEC uncovered a latent
issue in scop_detection::harmful_loop_in_region.
Gets us some more testcases.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2018-01-22 Richard Biener
PR tree-optimization/83963
* grap
Hi
This is a patch to backport r256526 and r256941 (Fix case fix) of trunk
to fix emit_store_flag_force () function to fix the ICE. The original
discussion is at
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00219.html and
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01058.html
Is this ok
PR79262 has been fixed for almost all AArch64 cpus, however the example is still
vectorized in a few cases, resulting in lower performance. Increase the cost of
vector-to-scalar moves so it is more similar to the other vector costs. As a
result
-mcpu=cortex-a53 no longer vectorizes the testcase -
Yes, you are right, any() is not required. Here is the patch.
Thanks,
Julia
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Monday, January 22, 2018 12:36 PM
> To: Koval, Julia
> Cc: Richard Biener ; Uros Bizjak
> ; GCC Patches ; Kirill Yukhin
>
> Subject: R
On Thu, Jan 18, 2018 at 5:39 PM, Marek Polacek wrote:
> The problem in this PR is that we get
> error: constexpr call flows off the end of the function
> for a valid testcase, but not in C++17 mode. That's because in C++17 we
> execute:
>
> 4321 if (cxx_dialect >= cxx17 && !BINFO_VIRTUAL_P
On 01/19/2018 12:57 PM, Martin Liška wrote:
> Yes, there's a huge difference in between CPU 2006 and 2017. Former has 63%
> w/ dominant edges,
> and later one only 11%. It's caused by these 2 benchmarks with a high
> coverage:
>
Hi.
I'm sending details about the 2 edges that influence the stat
Boris Kolpackov:
> Ximin Luo writes:
>
>> -I to an absolute path is not that common for system / distro-built
>> stuff.
>
> Ok, thanks for clarifying.
>
>
>> In the cases that it occurs, indeed it could and should be fixed
>> by the package buildsystem, e.g. by stripping a prefix when they
>>
This patch adds a new option to control the minimum stride, for a memory
reference, after which the loop prefetch pass may issue software prefetch
hints for. There are two motivations:
* Make the pass less aggressive, only issuing prefetch hints for bigger strides
that are more likely to benefit f
The following couple patches add options to better control the loop prefetch
pass.
With the current settings the pass tends to be very aggressive, issuing a lot
of prefetch hints. Most of these don't translate to better performance. Some
of these issued hints may even cause more cache evictions.
The following patch adds an option to control software prefetching of memory
references with non-constant/unknown strides.
Currently we prefetch these references if the pass thinks there is benefit to
doing so. But, since this is all based on heuristics, it's not always the case
that we end up wit
Dne 2018-01-22 14:29, Jakub Jelinek napsal:
On Mon, Jan 22, 2018 at 01:52:11PM +0100, Jan Hubicka wrote:
In new code bb4 is reached by first_prob + (1-first_prob)*second_prob
which should be equal to prob.
Say your choosen constant is to obtain first_prob=c*prob is c=0.99 and
you
want to know
On Mon, Jan 22, 2018 at 01:52:11PM +0100, Jan Hubicka wrote:
> In new code bb4 is reached by first_prob + (1-first_prob)*second_prob
> which should be equal to prob.
>
> Say your choosen constant is to obtain first_prob=c*prob is c=0.99 and you
> want to know c2 to obtain second_prob=c2*prob
>
>
Dne 2018-01-19 22:45, Jakub Jelinek napsal:
Hi!
This PR is about a certain test FAILing on arm, because it scans for
"Invalid sum ..." message in the *.ira dump, but recent GCC versions
have
that message in there; not introduced by IRA though, but all the way
from
expansion. We are expanding
On 01/21/2018 09:21 AM, Ville Voutilainen wrote:
Finishing testing the attached, OK for trunk?
ok (I had thought typedefs would be covered by the decl_context ==
TYPENAME case, but I see that is not true.)
nathan
--
Nathan Sidwell
On Mon, Jan 22, 2018 at 01:11:34PM +0100, Christophe Lyon wrote:
> On 19 January 2018 at 22:45, Jakub Jelinek wrote:
> > That IMHO can't work and the Invalid sum message verifies that. If we want
> > the first jump to hit 99times more often than the second one or vice versa,
> > I believe first_p
On 19 January 2018 at 22:45, Jakub Jelinek wrote:
> Hi!
>
> This PR is about a certain test FAILing on arm, because it scans for
> "Invalid sum ..." message in the *.ira dump, but recent GCC versions have
> that message in there; not introduced by IRA though, but all the way from
> expansion. We
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2018-01-22 Richard Biener
PR tree-optimization/83963
* graphite-scop-detection.c (scop_detection::get_sese): Delay
including the loop exit block.
(scop_detection::merge_sese): Likewise.
On Mon, Jan 22, 2018 at 11:30:10AM +, Koval, Julia wrote:
> Hi, I tried omp_clause_mask and it looks ok. But it lacks check if there
> is any bit or none. With addition of it(as proposed or in some other way
> it should work. What do you think about this approach(patch attached)?
Well, I ce
Hi,
I tried omp_clause_mask and it looks ok. But it lacks check if there is any bit
or none. With addition of it(as proposed or in some other way it should work.
What do you think about this approach(patch attached)?
Thanks,
Julia
> -Original Message-
> From: Jakub Jelinek [mailto:ja...
Hi Kyrill
On 19/01/18 18:00, Kyrill Tkachov wrote:
On 16/01/18 10:31, Sudakshina Das wrote:
Hi Christophe
On 12/01/18 18:32, Christophe Lyon wrote:
Le 12 janv. 2018 15:26, "Sudakshina Das" a écrit :
Hi
This patch fixes my earlier test case that fails for arm-none-eabi
with explicit user o
Hi all,
This test has needlessly restrictive requirements. It tries to force a
soft-float target and tries to run.
This makes it unsupportable for any non-soft-float variant.
In fact, the test can be a run-time test for any target, and only the
scan-assembler tests are specific to
-mfloat-abi=s
Hi,
On 20/01/2018 02:59, Paolo Carlini wrote:
Hi again,
On 19/01/2018 23:55, Paolo Carlini wrote:
...Therefore It seems to me that a way to more cleanly solve the bug
would be moving something like || !DECL_NONTRIVIALLY_INITIALIZED_P to
the the above check in check_for_uninitialized_const_var
Hi,
a mail in the gcc-list https://gcc.gnu.org/ml/gcc/2018-01/msg00144.html
reminded me about this minor stuff I have (so it can be controlled by
-Werror),
but never managed to write testcases. I'm posting it here in case
it's good enough or someone wants to take over from here.
Franz
c/Chan
On Mon, Jan 22, 2018 at 09:37:05AM +0100, Richard Biener wrote:
>
> Currently gcc_release builds GCC (for generating in-tree generated
> files) serially - that's prohibitly expensive and takges ages (>4h for
> me). I'm using (when I remember to edit gcc_release ...) -j6 without
> a problem for s
Currently gcc_release builds GCC (for generating in-tree generated
files) serially - that's prohibitly expensive and takges ages (>4h for
me). I'm using (when I remember to edit gcc_release ...) -j6 without
a problem for some years, thus the following proposal.
Any recommendation for the defaul
On 01/02/2018 12:57 PM, Martin Liška wrote:
> From what I've measured, suggested adjustment for this particular predictor
> would be
> increase to 89.
Hello.
Note that I've installed the patch as r256888.
Martin
70 matches
Mail list logo
