On Wed, Feb 10, 2021 at 6:16 PM Martin Sebor wrote:
>
> The attached patch replaces calls to print_generic_expr_to_str() with
> a helper function that returns a std::string and releases the caller
> from the responsibility to explicitly free memory.
I don't like this. What's the reason to use
Hi,
Hope you are doing well!!
Are you interested in the Productronica Show Updated Client List?
Please let me know your industry so that I can share you the Samples & Cost
details.
I appreciate your quick response
Christina Ridlon | Marketing Specialist
To stop receiving this
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 French team of translators. The file is available at:
https://translationproject.org/latest/cpplib/fr.po
(This file,
cpplib-11.1-b20210207.fr.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
On Feb 9, 2021, Kyrylo Tkachov wrote:
> Ok. Aren't there more tests that have this problem?
Thanks. This was the only test that exhibited this problem.
--
Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
Vim, Vi,
Here an unexpanded parameter pack snuck into prep_operand which doesn't
expect to see an operand without a type, and since r247842
NONTYPE_ARGUMENT_PACK doesn't have a type anymore.
This only happens with the do-while loop whose condition may not
contain a declaration so we never called
On 2/7/21 9:07 AM, Thomas Koenig wrote:
Hi Jerry,
OK for trunk and backport to 10 since it is simple enough?
OK for trunk.
Because this is a user-visible change (even if we did the wrong
thing before) I don't feel that we should backport (but I am
open to suggestions otherwise).
Could
On 2/10/21 5:25 PM, Patrick Palka wrote:
On Wed, 10 Feb 2021, Jason Merrill wrote:
On 2/10/21 12:32 PM, Patrick Palka wrote:
On Wed, 10 Feb 2021, Jason Merrill wrote:
On 2/9/21 5:12 PM, Patrick Palka wrote:
On Tue, 2 Feb 2021, Jason Merrill wrote:
On 2/2/21 12:19 AM, Patrick Palka
On 2/10/21 7:27 PM, Marek Polacek wrote:
On Wed, Feb 10, 2021 at 04:48:56PM -0500, Jason Merrill wrote:
On 2/10/21 12:35 PM, Marek Polacek wrote:
Freeing the condition chain needs to use vec_free which does ->release,
or we leak memory.
OK, but if chain were an auto_vec, delete would work.
On Wed, Feb 10, 2021 at 04:48:56PM -0500, Jason Merrill wrote:
> On 2/10/21 12:35 PM, Marek Polacek wrote:
> > Freeing the condition chain needs to use vec_free which does ->release,
> > or we leak memory.
>
> OK, but if chain were an auto_vec, delete would work.
Yes.
> Can we merge auto_vec
On Wed, Feb 10, 2021 at 03:54:52PM -0700, Martin Sebor via Gcc-patches wrote:
> On 2/10/21 3:33 PM, Marek Polacek wrote:
> > We ICE in handle_assume_aligned_attribute since r271338 which added
> >
> > @@ -2935,8 +2936,8 @@ handle_assume_aligned_attribute (tree *node, tree
> > name, tree args,
On 2/10/21 3:33 PM, Marek Polacek wrote:
We ICE in handle_assume_aligned_attribute since r271338 which added
@@ -2935,8 +2936,8 @@ handle_assume_aligned_attribute (tree *node, tree name,
tree args, int,
/* The misalignment specified by the second argument
must be
We ICE in handle_assume_aligned_attribute since r271338 which added
@@ -2935,8 +2936,8 @@ handle_assume_aligned_attribute (tree *node, tree name,
tree args, int,
/* The misalignment specified by the second argument
must be non-negative and less than the alignment. */
On Wed, 10 Feb 2021, Jason Merrill wrote:
> On 2/10/21 12:32 PM, Patrick Palka wrote:
> > On Wed, 10 Feb 2021, Jason Merrill wrote:
> >
> > > On 2/9/21 5:12 PM, Patrick Palka wrote:
> > > > On Tue, 2 Feb 2021, Jason Merrill wrote:
> > > >
> > > > > On 2/2/21 12:19 AM, Patrick Palka wrote:
>
On 2/10/21 12:32 PM, Patrick Palka wrote:
On Wed, 10 Feb 2021, Jason Merrill wrote:
On 2/9/21 5:12 PM, Patrick Palka wrote:
On Tue, 2 Feb 2021, Jason Merrill wrote:
On 2/2/21 12:19 AM, Patrick Palka wrote:
In this testcase, we're crashing because the lookup of operator+ from
within the
On 2/10/21 12:35 PM, Marek Polacek wrote:
Freeing the condition chain needs to use vec_free which does ->release,
or we leak memory.
OK, but if chain were an auto_vec, delete would work.
Can we merge auto_vec with vec now that we're compiling as C++11?
Bootstrapped/regtested on
The bug was resolved by r11-4745. I pushed the test in r11-7180.
Martin
commit 21c6ad7a12fecc4c85ac26289d9096379b550585
Author: Martin Sebor
Date: Wed Feb 10 14:42:22 2021 -0700
Add test for PR tree-optimization/92879.
gcc/testsuite/ChangeLog:
PR
On Wed, 10 Feb 2021, Marek Polacek via Gcc-patches wrote:
> Freeing the condition chain needs to use vec_free which does ->release,
> or we leak memory.
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> gcc/c/ChangeLog:
>
> * c-parser.c (c_parser_if_statement): Use
Joel Hutton writes:
> @@ -277,6 +277,81 @@ optab_for_tree_code (enum tree_code code, const_tree
> type,
> }
> }
>
> +/* Function supportable_half_widening_operation
> +
I realise existing (related) functions do have a “Function foo” line,
but it's not generally the GCC style, so I think
I apologize. I left a dangling space in the patch. I am guessing
that this is against whitespace policy. I had actually corrected
it but forgot to add the file to the commit. Please see the
attached.commit a9b60f36b499463b49095f28ce8053f6387c506d
Author: Brian Sobulefsky
Date: Tue Feb 9
PR preprocessor/96391 describes an ICE in the C++ frontend on:
#define CONST const
#define VOID void
typedef CONST VOID *PCVOID;
where the typedef line occurs after enough code has been compiled
that location_t values are beyond LINE_MAP_MAX_LOCATION_WITH_COLS,
and hence no column numbers
There are some changes needed for ppc64 before the gcc11 release.
On Wed, 10 Feb 2021, 13:10 Andreas Schwab, wrote:
> These are the lists I could test.
>
> libstdc++-v3/
> * config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
> *
On 2/10/21 3:39 AM, Richard Biener wrote:
On Tue, Feb 9, 2021 at 4:37 PM Martin Sebor wrote:
On 2/9/21 12:41 AM, Richard Biener wrote:
On Tue, Feb 9, 2021 at 1:04 AM Martin Sebor via Gcc-patches
wrote:
On 2/8/21 12:09 PM, Jeff Law wrote:
On 2/3/21 3:45 PM, Martin Sebor wrote:
On
> On Feb 9, 2021, at 11:36 AM, Richard Biener wrote:
>
> On Tue, 9 Feb 2021, Qing Zhao wrote:
>
>> Richard,
>>
>> Thank you for the reply.
>>
>> Yes, I understand that without a working testing case to repeat the error,
>> it’s very hard to debug and fix the issue.
>>
>> However,
Andrea Corallo via Gcc-patches writes:
> "Richard Earnshaw (lists)" writes:
>
>> On 09/02/2021 16:27, Andrea Corallo via Gcc-patches wrote:
>>> Jakub Jelinek writes:
>>>
On Tue, Feb 09, 2021 at 03:09:43PM +0100, Jakub Jelinek via Gcc-patches
wrote:
>>"TARGET_32BIT &&
Freeing the condition chain needs to use vec_free which does ->release,
or we leak memory.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
gcc/c/ChangeLog:
* c-parser.c (c_parser_if_statement): Use vec_free.
gcc/cp/ChangeLog:
* parser.c
On Wed, 10 Feb 2021, Jason Merrill wrote:
> On 2/9/21 5:12 PM, Patrick Palka wrote:
> > On Tue, 2 Feb 2021, Jason Merrill wrote:
> >
> > > On 2/2/21 12:19 AM, Patrick Palka wrote:
> > > > In this testcase, we're crashing because the lookup of operator+ from
> > > > within the generic lambda via
The attached patch replaces calls to print_generic_expr_to_str() with
a helper function that returns a std::string and releases the caller
from the responsibility to explicitly free memory.
With the patch installed, Valgrind shows more leaks in this code that
I'm not sure what to do about:
1) A
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 Brazilian Portuguese team of translators. The file is available at:
https://translationproject.org/latest/cpplib/pt_BR.po
(This file,
cpplib-11.1-b20210207.pt_BR.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
On 2/10/21 10:05 AM, Jakub Jelinek wrote:
On Tue, Feb 09, 2021 at 04:08:03PM -0500, Jason Merrill via Gcc-patches wrote:
They are not in the symtab from the C++ FE. And we don't allow those VAR_DECLs
or their
addresses to leak into the IL anyway.
But, they are TREE_STATIC because pretending
This wasn't fixed upstream for mingw-w64 so we still need the
workaround.
libstdc++-v3/ChangeLog:
PR libstdc++/1
* src/c++17/fs_ops.cc (fs::status): Re-enable workaround.
Tested x86_64-w64-mingw32. Committed to trunk.
commit 3df5b249b3c81e95cdcb293a388155ae5b168f9e
Author:
When the result of GetLastError() is stored in a std::error_code it
should use std::system_category(), not std::generic_category() that is
used for POSIX errno values.
libstdc++-v3/ChangeLog:
* src/c++17/fs_ops.cc (fs::create_hard_link, fs::equivalent)
(fs::remove): Use
libstdc++-v3/ChangeLog:
* testsuite/27_io/filesystem/operations/proximate.cc: Fix typo
in __MINGW32__ macro name.
* testsuite/27_io/filesystem/path/compare/lwg2936.cc: Likewise.
* testsuite/27_io/filesystem/path/generation/proximate.cc:
Likewise.
*
Hi,
I am trying to add testing cases for verifing pattern initialization or zero
initialization to fix-point type auto variables.
Please let me know where in the test suite directory I can find a good example
for fix-point type programming?
Thanks.
Qing
On Wed, Feb 10, 2021 at 4:12 PM Jakub Jelinek wrote:
>
> Hi!
>
> In these patterns, we call simplify_gen_subreg on the input operand
> to create paradoxical subregs that have 2x, 4x or 8x elements as the input
> operand. That works fine if the input operand is a REG, but when it is a
> SUBREG,
On Wed, 10 Feb 2021, Jakub Jelinek wrote:
> Hi!
>
> My FE change from 2 years ago uses TREE_ASM_WRITTEN in -fsyntax-only
> mode more aggressively to avoid "expanding" functions multiple times.
> With -fsyntax-only nothing is really expanded, so I think it is acceptable
> to adjust the assert and
On Wed, Feb 10, 2021 at 4:16 PM Tamar Christina via Gcc-patches
wrote:
>
> Hi Honza and Martin,
>
> As explained in PR98782 the problem is that the behavior of IRA is quite
> tightly
> bound to the frequencies that IPA puts out. With the change introduced in
>
Hi!
My FE change from 2 years ago uses TREE_ASM_WRITTEN in -fsyntax-only
mode more aggressively to avoid "expanding" functions multiple times.
With -fsyntax-only nothing is really expanded, so I think it is acceptable
to adjust the assert and allow declare_weak at any time, with -fsyntax-only
we
Hi!
In these patterns, we call simplify_gen_subreg on the input operand
to create paradoxical subregs that have 2x, 4x or 8x elements as the input
operand. That works fine if the input operand is a REG, but when it is a
SUBREG, RTL doesn't allow SUBREG of SUBREG and so relies on simplify_subreg
On Tue, Feb 09, 2021 at 04:08:03PM -0500, Jason Merrill via Gcc-patches wrote:
> > They are not in the symtab from the C++ FE. And we don't allow those
> > VAR_DECLs or their
> > addresses to leak into the IL anyway.
> > But, they are TREE_STATIC because pretending they are automatic didn't
> >
Thanks for the quick review.
Updated patch attached. I've addressed your comments below.
Tests are still running, OK for trunk assuming tests come out clean?
[aarch64][vect] Support V8QI->V8HI WIDEN_ patterns
In the case where 8 out of every 16 elements are widened using a
widening pattern and
On Tue, 9 Feb 2021, Jason Merrill wrote:
> On 2/8/21 2:03 PM, Patrick Palka wrote:
> > This sets up the functionality for controlling the initial set of
> > template parameters to pass to normalization when dealing with a
> > constraint-expression that is not associated with some constrained
> >
Rain Mark writes:
> After enabling -fsplit-stack, dynamic stack expansion of the coroutine
> is realized, but calling functions without -fsplit-stack will directly
> expand the space by 1M, which is too wasteful for a system with a large
> number of coroutines running under the 128K stack size.
Hi Honza and Martin,
As explained in PR98782 the problem is that the behavior of IRA is quite tightly
bound to the frequencies that IPA puts out. With the change introduced in
g:1118a3ff9d3ad6a64bba25dc01e7703325e23d92 some, but not all edge predictions
changed. This introduces a local problem
When running the testsuite with -mcpu=XXX/-march=YYY, some tests fail
because they specify -mcpu or -march (or both), which can be
incompatible with values used to run the tests. There is no easy way
to check such cases, so skip such tests.
Unfortunately this means the tests might be skipped in
On 2/9/21 5:12 PM, Patrick Palka wrote:
On Tue, 2 Feb 2021, Jason Merrill wrote:
On 2/2/21 12:19 AM, Patrick Palka wrote:
In this testcase, we're crashing because the lookup of operator+ from
within the generic lambda via lookup_name finds multiple bindings
(namely C1::operator+ and
On Wed, Feb 10, 2021 at 3:04 PM Martin Liška wrote:
>
> It's fix needed after my commit g:0d701e3eb89870237669ef7bf41394d90c35ae70.
> Tobias tested the patch for me.
>
> Ready to be installed?
ok
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> * config/nvptx/nvptx.c (nvptx_option_override):
On 2/10/21 2:17 PM, Martin Liška wrote:
> It's fix needed after my commit g:0d701e3eb89870237669ef7bf41394d90c35ae70.
> Tobias tested the patch for me.
>
> Ready to be installed?
LGTM.
Thanks,
- Tom
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> * config/nvptx/nvptx.c (nvptx_option_override):
Lambdas can refer to local externs from their enclosing scope. When
the lambda's generic but the containing function is not a temploid,
we'll never have tsubsted the declaring decl so won't have a local
specialization. But in that case we can just use the decl we
tsubsting directly -- it's not
It's fix needed after my commit g:0d701e3eb89870237669ef7bf41394d90c35ae70.
Tobias tested the patch for me.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
* config/nvptx/nvptx.c (nvptx_option_override): Use
flag_patchable_function_entry instead of the removed
On Wed, Feb 10, 2021 at 12:44 PM Martin Liška wrote:
>
> This one fixes 2 more memory leaks.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> I also tested that building postgresql with valgrind does not display
> anything related to the affected files.
>
> Ready to be
This cleans up allocation/deallocation of reference_vars_to_consider,
specifically always releasing the vector allocated in ipa_init and
also making sure to release it before re-allocating it in
ipa_reference_write_optimization_summary.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
On Wed, 10 Feb 2021, Jakub Jelinek wrote:
> On Wed, Feb 10, 2021 at 11:30:42AM +0100, Richard Biener wrote:
> > The optimize pragma/attribute parsing calls decode_cmdline_options_to_array
> > but doesn't free the array. The following fixes that.
> >
> > Bootstrapped and tested on
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Japanese team of translators. The file is available at:
https://translationproject.org/latest/gcc/ja.po
(This file,
On Wed, Feb 10, 2021 at 11:30:42AM +0100, Richard Biener wrote:
> The optimize pragma/attribute parsing calls decode_cmdline_options_to_array
> but doesn't free the array. The following fixes that.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
>
> Thanks,
> Richard.
>
>
This one fixes 2 more memory leaks.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I also tested that building postgresql with valgrind does not display
anything related to the affected files.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
PR
On Tue, Feb 9, 2021 at 4:37 PM Martin Sebor wrote:
>
> On 2/9/21 12:41 AM, Richard Biener wrote:
> > On Tue, Feb 9, 2021 at 1:04 AM Martin Sebor via Gcc-patches
> > wrote:
> >>
> >> On 2/8/21 12:09 PM, Jeff Law wrote:
> >>>
> >>>
> >>> On 2/3/21 3:45 PM, Martin Sebor wrote:
> On 2/3/21 2:57
This fixes a leak of the vector retured by find_partition_fixes
by turning it into an auto_vec.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-02-10 Richard Biener
PR rtl-optimization/99054
* cfgrtl.c (rtl-optimization/99054): Return an auto_vec.
The optimize pragma/attribute parsing calls decode_cmdline_options_to_array
but doesn't free the array. The following fixes that.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
2021-02-10 Richard Biener
gcc/c-family/
* c-common.c (parse_optimize_options):
"Richard Earnshaw (lists)" writes:
> On 09/02/2021 16:27, Andrea Corallo via Gcc-patches wrote:
>> Jakub Jelinek writes:
>>
>>> On Tue, Feb 09, 2021 at 03:09:43PM +0100, Jakub Jelinek via Gcc-patches
>>> wrote:
>"TARGET_32BIT && TARGET_HAVE_LOB"
> - "le\t%|lr, %l0")
> + "*
Hi!
gimplify_scan_omp_clauses was already calling gimplify_expr with false as
last argument to make sure it is not an SSA_NAME, but as the testcases show,
that is not enough, SSA_NAME temporaries created during that gimplification
can be reused too and we can't allow SSA_NAMEs to be used across
Joel Hutton writes:
> Hi Richards,
>
> This patch adds support for the V8QI->V8HI case from widening vect patterns
> as discussed to target PR98772.
Thanks, the approach looks good to me. Mostly just minor comments below.
> Bootstrapped and regression tested on aarch64.
>
>
> [aarch64][vect]
This makes sure to release the vec<> of callees.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-02-10 Richard Biener
PR ipa/99029
* ipa-pure-const.c (propagate_malloc): Use an auto_vec<>
for callees.
---
gcc/ipa-pure-const.c | 2 +-
1 file changed,
When we analyzed a loop as epilogue but later in peeling decide
we're not going to use it then in the DTOR we clear the original
loops ->aux which causes us to leak the main loop vinfo.
Fixed by only clearing aux if it is associated with the vinfo
we're destroying.
Bootstrapped and tested on
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 Vietnamese team of translators. The file is available at:
https://translationproject.org/latest/cpplib/vi.po
(This file,
cpplib-11.1-b20210207.vi.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
On Mon, Feb 08, 2021 at 11:16:31AM +, Nick Alcock via Binutils wrote:
> intl/ChangeLog
> 2021-02-04 Nick Alcock
>
> * configure.ac (LIBINTL): Transform into -L/-lintl form.
> * configure: Regenerate.
OK for binutils.
--
Alan Modra
Australia Development Lab, IBM
On Mon, Feb 08, 2021 at 11:16:30AM +, Nick Alcock via Binutils wrote:
> intl/ChangeLog
> 2021-02-02 Nick Alcock
>
> * aclocal.m4: include picflag.m4.
> * configure.ac (PICFLAG): Add and substitute.
> * Makefile.in (PICFLAG): New.
> (COMPILE): Use it.
> *
69 matches
Mail list logo
