On 6 March 2019 19:49:59 CET, Thomas Koenig wrote:
>Hello world,
>
>the attached patch fixes a 7/8/9 regression where dependency checking
>was for class arrays and a scalar value was mishandled when the
>dependency happened in an elemental function.
>
>There was an ICE for the test case which is
On 3/7/19 2:13 PM, Jakub Jelinek wrote:
On Wed, Mar 06, 2019 at 07:44:25PM -0500, Jason Merrill wrote:
In addition to that, it mentions in the documentation that qualifiers are
not allowed at toplevel asm statements; apparently our documentation at
least from r220506 for GCC 5 says that at
On 3/7/19 2:29 PM, Jakub Jelinek wrote:
Hi!
The last testcase in the patch diagnoses invalid constexpr in the
ptr case, but doesn't for arr.
The array is constexpr, so we do:
value = fold_non_dependent_expr (value);
if (DECL_DECLARED_CONSTEXPR_P (decl)
||
On 3/7/19 2:25 PM, Jakub Jelinek wrote:
Hi!
If no diagnostics is emitted by this pedwarn, whether because of
-Wno-system-headers and location from system headers, or because of -w
etc., we still emit the follow-up messages as if the pedwarn emitted
something.
The following patch makes it
For named function calls in a template, the result of unqualified lookup is
safed in CALL_EXPR_FN. But for operator expressions, no unqualified lookup
is performed until we know whether the operands have class type. So when we
see in a lambda a use of an operator that might be overloaded, we
Hi,
As PR88497 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497),
when we meet some code pattern like:
V1[0] + V1[1] + ... + V1[k] + V2[0] + ... + V2[k] + ... Vn[k]
// V1...Vn of VECTOR_TYPE
We can teach reassoc to transform it to:
Vs = (V1 + V2 + ... + Vn)
Vs[0] + Vs[1] +
Hi,
We recently discovered a problem in swap optimization where the du- and
ud-chains
were getting corrupted after a preliminary modification phase and prior to the
main body of the pass. The fix for this is to rebuild the chains between
phases.
Bootstrapped and tested on
On 07/03/19 23:57 +, Jonathan Wakely wrote:
On 07/03/19 22:22 +0100, François Dumont wrote:
Hi
I consider the implementation to decide to invalidate iterators
or not. As nodes are not deallocated and only slghtly impacted
during the rehash process I consider that they shouldn't be
On 07/03/19 22:22 +0100, François Dumont wrote:
Hi
I consider the implementation to decide to invalidate iterators or
not. As nodes are not deallocated and only slghtly impacted during the
rehash process I consider that they shouldn't be invalidated appart
from the local iterators. I
On 07/03/19 22:34 +0100, François Dumont wrote:
Hi
PR 89477 fixes haven't been applied to the Debug mode. Here it is
to fix the different deduction.cc tests.
PR libstdc++/89477
* include/debug/map.h (map): Use _RequireNotAllocator to constrain
parameters in deduction guides.
On Wed, Mar 6, 2019 at 6:22 AM Andreas Schwab wrote:
> * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: New file.
I thought we had fixed this already. I vaguely recall discussing it
with you. But I see that nothing was checked in, and I see that you
posted a patch in November
On Mar 7, 2019, at 11:37 AM, Jakub Jelinek wrote:
>
> The following patch just makes it two complete diagnostic messages that
> translators can translate as they wish.
>
> Ok for trunk?
Ok.
The PR rightly complains about bad error messages for invalid pointer
assignments. I've tried to adjust the logic slightly so that we now
print error messages that should explain more clearly what is wrong.
This required adjustment of 2 testcases, one of which also had an
incorrect comment.
OK
This was one of those PRs where the more you poke, the more ICEs turn up.
This patch fixes the ones I could find. The original problem was that
maybe_instantiate_noexcept got a TEMPLATE_DECL created for the member
friend template in do_friend. Its noexcept-specification was deferred,
so we went
Hi
PR 89477 fixes haven't been applied to the Debug mode. Here it is
to fix the different deduction.cc tests.
PR libstdc++/89477
* include/debug/map.h (map): Use _RequireNotAllocator to constrain
parameters in deduction guides.
* include/debug/multimap.h (multimap):
On Thu, Mar 07, 2019 at 10:11:56PM +0100, Matthias Klose wrote:
> On 07.03.19 00:39, Jakub Jelinek wrote:
> > The following patch tries to improve diagnostics of toplevel asm qualifiers
> > in C++ by actually parsing them and complaining if they appear at toplevel,
> > instead of just emitting a
Hi
I consider the implementation to decide to invalidate iterators or
not. As nodes are not deallocated and only slghtly impacted during the
rehash process I consider that they shouldn't be invalidated appart from
the local iterators. I should have just consider the Standard.
Here
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/cpplib/sv.po
(This file,
cpplib-9.1-b20190203.sv.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
On Thu, Mar 7, 2019 at 8:45 PM Jakub Jelinek wrote:
>
> Hi!
>
> The following patch fixes a couple of issues in i386.c diagnostics.
>
> In particular, diagnostics emitted to the user (not in dump files)
> should not start with a capital letter unless it is something that
> starts with capital
On 07.03.19 00:39, Jakub Jelinek wrote:
> Hi!
>
> The following patch tries to improve diagnostics of toplevel asm qualifiers
> in C++ by actually parsing them and complaining if they appear at toplevel,
> instead of just emitting a parse error that ( is expected, e.g. some
> versions of Qt do
On Thu, Mar 07, 2019 at 08:40:37PM +0100, Jakub Jelinek wrote:
>
> 2019-03-07 Jakub Jelinek
>
> PR other/80058
> * lra-constraints.c (process_alt_operands): Avoid one space before
> " at the end of line and another after " on another line in a string
> literal.
>
Hi!
As mentioned in the PR, using HOST_WIDE_INT_PRINT_* in the middle of
translatable message is highly undesirable, we end up with:
#: config/s390/s390.c:737
#, gcc-internal-format
msgid "constant argument %d for builtin %qF is out of range (0.."
msgstr ""
#: config/s390/s390.c:754
#,
Hi!
The following testcase clarifies the diagnostics for OpenMP doaccross
and adds a testcase to cover warnings that weren't covered in the testsuite
previously.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2019-03-07 Jakub Jelinek
PR translation/7
Hi!
The following patch fixes a couple of issues in i386.c diagnostics.
In particular, diagnostics emitted to the user (not in dump files)
should not start with a capital letter unless it is something that
starts with capital letter in a middle of a sentence, and should not end
with a period.
Hi!
The following patch fixes a couple of cases where two or more spaces
are introduced in a middle of diagnostic message because we've split source
line and left a space both at the end of one line and at the start of next
one.
Fixed thusly, bootstrapped/regtested on x86_64-linux and
Hi!
In this PR, the translators complained that this diagnostics is composed of
two parts, one that can be translated and the other can't, and while ASCII
and NUL probably don't need translation, character, embedded and non do.
The following patch just makes it two complete diagnostic messages
Hi!
When looking at the diagnostics PRs, I've noticed that several diagnostic calls
in gimple-ssa-warn-alloca.c use G_(...) uselessly, it is only needed if the
argument is not a string literal.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
verified the messages are
Hi!
The following patch fixes two diagnostics issues in ipa-devirt.c, one
is trailing space in one warning, the other is lack of articles in another
warning, both reported by the translation team.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2019-03-07 Jakub Jelinek
Hi!
The last testcase in the patch diagnoses invalid constexpr in the
ptr case, but doesn't for arr.
The array is constexpr, so we do:
value = fold_non_dependent_expr (value);
if (DECL_DECLARED_CONSTEXPR_P (decl)
|| (DECL_IN_AGGR_P (decl)
&&
Hi!
If no diagnostics is emitted by this pedwarn, whether because of
-Wno-system-headers and location from system headers, or because of -w
etc., we still emit the follow-up messages as if the pedwarn emitted
something.
The following patch makes it conditional on pedwarn returning true (i.e.
Hi!
We have -fconstexpr-loop-limit= option to have an upper bound for constexpr
evaluation of a single loop. Even with that limit in place, if we have
several nested loops during constexpr evaluation, even when each could have
a few hundred iterations, the whole loop nest could take years to
Hi!
While looking at why we didn't warn before Richi's commit, I've discovered
is that the change is that in a different pass we used to call c_strlen too,
but at that point with a location from system headers, so no warning has
been printed, but TREE_NO_WARNING has been set anyway and later on
On Wed, Mar 06, 2019 at 07:44:25PM -0500, Jason Merrill wrote:
> > In addition to that, it mentions in the documentation that qualifiers are
> > not allowed at toplevel asm statements; apparently our documentation at
> > least from r220506 for GCC 5 says that at toplevel Basic Asm needs to be
> >
Hi,
This patch merges the D front-end implementation with dmd upstream
d517c0e6a, fixing the ICE reported in PR d/89016.
Bootstrapped and regression tested on x86_64-linux-gnu.
Committed to trunk as r269465.
--
Iain
diff --git a/gcc/d/dmd/MERGE b/gcc/d/dmd/MERGE
index 97aa40d1ace..3f416dbfb7b
Here the problem was that in order to form a FUNCTION_DECL for foo in
the uninstantiated template, we were trying to deduce template args for S
from the template parm itself, and failing.
Tested x86_64-pc-linux-gnu, applying to trunk.
* pt.c (do_class_deduction): Handle parm used as its
Dne 2019-02-27 13:00, Martin Jambor napsal:
Hi,
in the discussion in PR 87525 Honza noted that IPA-CP should not
estimate any local time benefits from cloning an extern inline
function,
that any benefits this might bring about have to come from other
specializations such cloning might enable.
Dne 2019-03-06 13:22, Martin Jambor napsal:
Hi,
PR 88235 is a cgraph verification failure which is a false positive.
The problem is that after thunk expansion which is done as a part of
thunk inlining the verifier is no longer able to detect that a call
graph edge callee points to a clone of
> Hi.
>
> The patch makes a significant verifier speed up in a project that
> has a dtor for which we create ~70.000 clones.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2019-02-22 Martin Liska
The following fixes PR89578, an optimization regression with the
recent restrict fixes. The idea is to keep track of the original
function context by attaching that to our loop structure.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2019-03-07 Richard Biener
Some more additions.
Committed to CVS.
Index: htdocs/gcc-9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.51
diff -u -r1.51 changes.html
--- htdocs/gcc-9/changes.html 6 Mar 2019
On 07/03/19 14:15 +, Jonathan Wakely wrote:
* include/std/functional [C++20] (_Bind_front, _Bind_front_t): Define
helpers for bind_front.
(bind_front, __cpp_lib_bind_front): Define.
* testsuite/20_util/function_objects/bind_front/1.cc: New test.
I'm
On 07/03/19 14:15 +, Jonathan Wakely wrote:
* include/std/functional [C++20] (_Bind_front, _Bind_front_t): Define
helpers for bind_front.
(bind_front, __cpp_lib_bind_front): Define.
* testsuite/20_util/function_objects/bind_front/1.cc: New test.
The new test
* doc/xml/manual/status_cxx2020.xml: Update C++20 status.
* doc/html/*: Regenerate.
Committed to trunk.
commit bdac401ac5bb8046cfb19951820af229991151f2
Author: Jonathan Wakely
Date: Thu Mar 7 14:19:43 2019 +
Update C++20 status table in libstdc++ manual
Hi ,James:
The modified patch has been uploaded for ten days. If you have time, I hope to
get your comments earlier, thank you very much!
Best Regards,
* include/std/functional [C++20] (_Bind_front, _Bind_front_t): Define
helpers for bind_front.
(bind_front, __cpp_lib_bind_front): Define.
* testsuite/20_util/function_objects/bind_front/1.cc: New test.
Tested powerpc64le-linux, committed to trunk.
commit
> On Thu, Feb 28, 2019 at 12:18 PM Jason Merrill wrote:
> > On Thu, Feb 28, 2019 at 11:58 AM Jan Hubicka wrote:
> > > sorry for late reply - I did not identify it as a patch to symbol table.
> > > Indeed we want can_refer_decl_in_current_unit_p is a good place to test
> > > this. Is there a
Hi.
The removal causes build failures of *-vms targets.
I'm going to define the function again.
Martin
gcc/ChangeLog:
2019-03-07 Martin Liska
* dwarf2out.c (add_AT_vms_delta): Revert function removal.
---
gcc/dwarf2out.c | 18 ++
1 file changed, 18 insertions(+)
On Wed, Mar 6, 2019 at 11:05 AM Richard Biener
wrote:
>
> On Tue, Mar 5, 2019 at 10:36 PM Jeff Law wrote:
> >
> > On 3/5/19 7:44 AM, Richard Biener wrote:
> >
> > > So fixing it properly with also re-optimize_stmt those stmts so we'd CSE
> > > the MAX_EXPR introduced by folding makes it somewhat
On Thu, Mar 07, 2019 at 01:03:43PM +0100, Richard Biener wrote:
>
> This fixes a missed vectorization because loop_version (and in the end
> copy_loop_info) didn't copy IVDEP info (safelen) during if-conversion
> versioning.
>
> Bootstrap & regtest running on x86_64-unknown-linux-gnu.
>
> Even
This fixes a missed vectorization because loop_version (and in the end
copy_loop_info) didn't copy IVDEP info (safelen) during if-conversion
versioning.
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
Even though this isn't a regression I'd like to fix this for GCC 9,
it may appear as
On 06/03/19 22:27 +, Pádraig Brady wrote:
On 03/06/2019 01:44 AM, Jonathan Wakely wrote:
On 06/03/19 09:20 +, Pádraig Brady wrote:
On 03/06/2019 12:50 AM, Jonathan Wakely wrote:
On 06/03/19 02:43 +, Pádraig Brady wrote:
On 02/26/2019 04:23 PM, Padraig Brady wrote:
Note
Hi,
sorry for a somewhat long turnaround...
On Tue, Mar 05 2019, Richard Biener wrote:
> On Tue, 5 Mar 2019, Richard Biener wrote:
>
>> On Tue, 5 Mar 2019, Martin Jambor wrote:
>> > @@ -1165,14 +1165,9 @@ contains_vce_or_bfcref_p (const_tree ref)
>> >ref = TREE_OPERAND (ref, 0);
>> >
On 3/7/19 11:27 AM, Uros Bizjak wrote:
> On Thu, Mar 7, 2019 at 10:50 AM Martin Liška wrote:
>>
>> On 3/7/19 9:54 AM, Uros Bizjak wrote:
>>> On Thu, Mar 7, 2019 at 9:45 AM Martin Liška wrote:
Hi.
Thanks to Intel guys, we've done some re-measurement in PR86952
about usage
On Thu, Mar 7, 2019 at 10:50 AM Martin Liška wrote:
>
> On 3/7/19 9:54 AM, Uros Bizjak wrote:
> > On Thu, Mar 7, 2019 at 9:45 AM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> Thanks to Intel guys, we've done some re-measurement in PR86952
> >> about usage of jump tables when retpolines are used.
>
Looks good to me.
Thanks.
On Thu, Mar 7, 2019, 4:15 PM Uros Bizjak wrote:
> On Thu, Mar 7, 2019 at 9:09 AM Jakub Jelinek wrote:
> >
> > On Thu, Mar 07, 2019 at 08:11:53AM +0100, Uros Bizjak wrote:
> > > > +(define_insn "*avx512f_load_mask"
> > > > + [(set (match_operand: 0 "register_operand"
On 3/7/19 9:54 AM, Uros Bizjak wrote:
> On Thu, Mar 7, 2019 at 9:45 AM Martin Liška wrote:
>>
>> Hi.
>>
>> Thanks to Intel guys, we've done some re-measurement in PR86952
>> about usage of jump tables when retpolines are used.
>> Numbers prove that disabling of JT should be the best for now.
>>
On Thu, Mar 7, 2019 at 9:45 AM Martin Liška wrote:
>
> Hi.
>
> Thanks to Intel guys, we've done some re-measurement in PR86952
> about usage of jump tables when retpolines are used.
> Numbers prove that disabling of JT should be the best for now.
>
> Patch can bootstrap on x86_64-linux-gnu and
Hi.
Thanks to Intel guys, we've done some re-measurement in PR86952
about usage of jump tables when retpolines are used.
Numbers prove that disabling of JT should be the best for now.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
On Thu, Mar 7, 2019 at 9:09 AM Jakub Jelinek wrote:
>
> On Thu, Mar 07, 2019 at 08:11:53AM +0100, Uros Bizjak wrote:
> > > +(define_insn "*avx512f_load_mask"
> > > + [(set (match_operand: 0 "register_operand" "=v")
> > > + (vec_merge:
> > > + (vec_merge:
> > > +
On Thu, Mar 07, 2019 at 08:11:53AM +0100, Uros Bizjak wrote:
> > +(define_insn "*avx512f_load_mask"
> > + [(set (match_operand: 0 "register_operand" "=v")
> > + (vec_merge:
> > + (vec_merge:
> > + (vec_duplicate:
> > + (match_operand:MODEF 1 "memory_operand"
61 matches
Mail list logo
