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 h
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 tople
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)
|| (DECL_IN_AGGR_P
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 condit
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 need
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 powerpc64le-unknown-l
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
in
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 shou
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 t
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 f
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 t
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): Likewis
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 pa
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 is
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-b2019020
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 lett
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 use
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
#, gcc-intern
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. Th
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 i686-linux,
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 th
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 unmodifi
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)
&& DECL_INITIALIZED_IN_
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.
that
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 eval
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 wh
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
> > u
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 o
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 the
> 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 10:22:3
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 consideri
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 1944c1ed
> 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 reas
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(+)
d
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 t
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 jema
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 sur
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
gc
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:
> > > + (vec_dupli
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" "m"
61 matches
Mail list logo
