On 21 December 2017 at 12:53, Prathamesh Kulkarni
wrote:
> Hi Jakub,
> Based on your suggestions in PR83501, I have updated the patch to
> check for integer_zerop for 2nd operand of mem_ref.
>
> With the patch, Warray-bounds started warning for the following test
> in Warray-bounds-3.c in line 362
Now backported to branch.
On 24/12/2017 08:55, Jonathan Wakely wrote:
On 19 December 2017 at 21:33, François Dumont wrote:
Hi
I plan to apply attached patch tomorrow to fix those _GLIBCXX_DEBUG
failures:
FAIL: 23_containers/map/modifiers/insert/dr2354.cc (test for excess errors)
FAIL: 23_
match_results::begin() and match_results::end() are required to work
even when the object is not ready, so the current definition of end()
is broken (it performs an undefined subtraction to return an invalid
iterator).
PR libstdc++/83600
* include/bits/regex.h (match_results::end(
The standard requires that std::regex("", f).flags() == f so we
shouldn't modify the flags passed to the constructor. We can just
remove the code that does so, because the _Compiler class repeats the
code to conditionally set ECMAScript in the flags anyway, so there's
no need to do so for the valu
Thanks for the additional information Thomas. It sounds like I should test
Paul’s patch. I should be able to do so today and will post the results by
tomorrow. I’m adding OpenCoarrays developer Zaak Beekman to the cc and
attaching the patch again in case he wants to try it as well.
Zaak, the
This was changed between C++11 and C++14.
PR libstdc++/83538
* doc/xml/manual/intro.xml: Document LWG 2306 change.
* include/bits/regex.h (match_results::reference): Change to
non-const reference.
* testsuite/28_regex/match_results/typedefs.cc: Check types
Fixed in revision 256011.
Hi Damian,
Does breaking binary compatibility simply mean that CAF codes will need to be
recompiled (which is fine)
Well... not really. We are not supposed to break binary compatibility
in a release. For gcc-8, we have greater freedom because we had to
do it anyway.
Now, the interesting que
Hi Paul,
Does breaking binary compatibility simply mean that CAF codes will need to be
recompiled (which is fine) or does it mean that there will need to be work done
on OpenCoarrays to support the changes in this patch (which is unlikely to
happen soon without new contributors to OpenCoarray
It also fixes pr78983 and partially pr80235.
Thanks
Dominique
> Le 27 déc. 2017 à 19:04, Thomas Koenig a écrit :
>
> Hi Paul,
>
> by the way, the patch is OK for trunk. It is just gcc-7 that I am
> worried about.
>
> Regards
>
> Thomas
Hi Paul,
by the way, the patch is OK for trunk. It is just gcc-7 that I am
worried about.
Regards
Thomas
Hi Thomas,
That's a good question. I have kept Damian in copy. It must be said
that the OpenCoarray folk are more concerned with PR83319, where there
is no problem of binary compatibility. I am awaiting some input from
him.
Cheers
Paul
On 27 December 2017 at 17:50, Thomas Koenig wrote:
> Hi P
Hi Paul,
It will break binary compatibility for caf with scalar,
allocatable/pointer components. This comes about because I decided
that the caf tokens for thes components, should come after all other
components, rather than immediately after the "owner" component. This
has the advantage, that t
(this isn't an i386 patch)
On Wed, 27 Dec 2017, Shalnov, Sergey wrote:
Should we use vector instructions if the scalar and vector costs in SLP are the
same?
According to the source line comment (already in source code) we should not
use vector instructions in this case.
"Vectorization is pro
Hi Thomas,
It will break binary compatibility for caf with scalar,
allocatable/pointer components. This comes about because I decided
that the caf tokens for thes components, should come after all other
components, rather than immediately after the "owner" component. This
has the advantage, that t
Hi Paul,
This is a complete rework of the patch and of the original mechanism
for adding caf token fields and finding them.
In this patch, the token fields are added to the derived types after
all the components have been resolved. This is done so that all the
tokens appear at the very end of t
Hi All,
This patch is very straightforward. The PR itself was fixed by not
freeing the parameterized components on leaving function scope. The
lhs expression in the assignment had pointers to parameterized
components that were overwritten on assignment, thereby causing some
memory leakage. This is
Hi.
As we introduced noipa attribute, I believe proper fix to not to crash
is to ignore all functions with the attribute in iteration of IPA visibility
pass.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
gcc/ChangeLog:
2017-12-27 Mart
Hi,
Should we use vector instructions if the scalar and vector costs in SLP are the
same?
According to the source line comment (already in source code) we should not
use vector instructions in this case.
I would like to propose to use scalars if costs are the same.
Sergey
2017-12-27 Sergey Sha
On 12/22/2017 05:44 PM, Jakub Jelinek wrote:
> You need to do that only if (!is_gimple_val (arg1_len)).
> Can you please emit the additional stmt only if that isn't true?
Sure.
This is what I'm going to install.
Martin
>From 509e884e909a0b2ed56bf025c852f30b9ed43ae1 Mon Sep 17 00:00:00 2001
From:
On 12/21/2017 06:19 PM, Cesar Philippidis wrote:
My test results are somewhat inconsistent. On MG's build servers, there
are no regressions in CUDA 8.
Ack.
On my laptop, there are fewer regressions
in CUDA 9, than CUDA 8.
If the patch causes regressions for either cuda 8 or cuda 9, then th
Hi,
this patches fixes a problem in the gang-static-2.c test-case, which
works around the PR83046 ICE, re-enabling the test-case.
Tested libgomp for x86_64 with nvptx accelerator.
Committed.
Thanks,
- Tom
Workaround PR83046 in gang-static-2.c
2017-12-27 Tom de Vries
PR c++/83046
* tes
[ was: Re: [SFN+LVU+IEPM v4 6/9] [SFN] Introduce -gstatement-frontiers
option, enable debug markers ]
On 11/10/2017 03:34 AM, Alexandre Oliva wrote:
Introduce a command line option to enable statement frontiers, enabled
by default in optimized builds with DWARF2+ debug information.
This patch
23 matches
Mail list logo
