"Kewen.Lin" writes:
> Hi,
>
> on 2023/11/15 10:26, HAO CHEN GUI wrote:
>> Hi,
>> This patch cleans up by_pieces_ninsns and does following things.
>> 1. Do the length and alignment adjustment for by pieces compare when
>> overlap operation is enabled.
>> 2. Remove unnecessary mov_optab checks.
>>
Hi,
on 2023/11/15 10:26, HAO CHEN GUI wrote:
> Hi,
> This patch cleans up by_pieces_ninsns and does following things.
> 1. Do the length and alignment adjustment for by pieces compare when
> overlap operation is enabled.
> 2. Remove unnecessary mov_optab checks.
>
> Bootstrapped and tested on
Hi,
This patch cleans up by_pieces_ninsns and does following things.
1. Do the length and alignment adjustment for by pieces compare when
overlap operation is enabled.
2. Remove unnecessary mov_optab checks.
Bootstrapped and tested on x86 and powerpc64-linux BE and LE with
no regressions. Is t
Hi,
This patch cleans up by_pieces_ninsns and does following things.
1. Do the length and alignment adjustment for by pieces compare when
overlap operation is enabled.
2. Remove unnecessary mov_optab checks.
Bootstrapped and tested on x86 and powerpc64-linux BE and LE with
no regressions. Is t
On 11/26/20 8:42 AM, H.J. Lu wrote:
On Tue, Nov 24, 2020 at 5:13 PM Martin Sebor via Gcc-patches
wrote:
The attached patch cleans up most remaining -Wformat-diag instances
in an x86_64-build. I tried to minimize using #pragma diagnostic
so I tweaked the code instead. A preferable solution mi
H.J. Lu via Gcc-patches wrote:
On Tue, Nov 24, 2020 at 5:13 PM Martin Sebor via Gcc-patches
wrote:
The attached patch cleans up most remaining -Wformat-diag instances
in an x86_64-build. I tried to minimize using #pragma diagnostic
so I tweaked the code instead. A preferable solution might
On Tue, Nov 24, 2020 at 5:13 PM Martin Sebor via Gcc-patches
wrote:
>
> The attached patch cleans up most remaining -Wformat-diag instances
> in an x86_64-build. I tried to minimize using #pragma diagnostic
> so I tweaked the code instead. A preferable solution might be to
> introduce a new form
On 11/24/20 8:09 PM, Martin Sebor via Gcc-patches wrote:
The attached patch cleans up most remaining -Wformat-diag instances
in an x86_64-build. I tried to minimize using #pragma diagnostic
so I tweaked the code instead. A preferable solution might be to
introduce a new format attribute and use
The attached patch cleans up most remaining -Wformat-diag instances
in an x86_64-build. I tried to minimize using #pragma diagnostic
so I tweaked the code instead. A preferable solution might be to
introduce a new format attribute and used it to exempt the pp_printf()
and verbatim() functions fr
Yes, it was leftover from the original irange work years ago.
Aldy
On Mon, Nov 9, 2020 at 3:42 PM Andrew MacLeod wrote:
>
> On 11/9/20 9:38 AM, Aldy Hernandez wrote:
> > Currently we have all the irange and range-op tests in range-op.cc.
> > This patch splits them up into the appropriate file (i
On 11/9/20 9:38 AM, Aldy Hernandez wrote:
Currently we have all the irange and range-op tests in range-op.cc.
This patch splits them up into the appropriate file (irange
tests in value-range.cc and range-op tests in range-op.cc). The patch
also splits up the tests themselves by functionality. I
Currently we have all the irange and range-op tests in range-op.cc.
This patch splits them up into the appropriate file (irange
tests in value-range.cc and range-op tests in range-op.cc). The patch
also splits up the tests themselves by functionality. It's not perfect,
but significantly better th
On Fri, 6 Nov 2020, Jiufu Guo wrote:
> On 2020-11-05 21:43, Richard Biener wrote:
>
> Hi Richard,
>
> Thanks for your comments and suggestions!
>
> > On Thu, Nov 5, 2020 at 2:19 PM guojiufu via Gcc-patches
> > wrote:
> >>
> >> In PR87473, there are discussions about loop-closed PHIs which
> >
On 2020-11-05 21:43, Richard Biener wrote:
Hi Richard,
Thanks for your comments and suggestions!
On Thu, Nov 5, 2020 at 2:19 PM guojiufu via Gcc-patches
wrote:
In PR87473, there are discussions about loop-closed PHIs which
are generated for loop optimization passes. It would be helpful
to
On Thu, Nov 5, 2020 at 2:19 PM guojiufu via Gcc-patches
wrote:
>
> In PR87473, there are discussions about loop-closed PHIs which
> are generated for loop optimization passes. It would be helpful
> to clean them up after loop optimization is done, then this may
> simplify some jobs of following p
In PR87473, there are discussions about loop-closed PHIs which
are generated for loop optimization passes. It would be helpful
to clean them up after loop optimization is done, then this may
simplify some jobs of following passes.
This patch introduces a cheaper way to propagate them out in
pass_t
On Mon, Jan 13, 2020 at 01:12:15PM -0500, Eric S. Raymond wrote:
> Jonathan Wakely :
> > Email the patches to gcc-patches@gcc.gnu.org, that's how things get
> > merged.
> >
> > We're not looking to change any workflows now.
>
> Roger that.
>
> Once the dust from the conversion has settled, thoug
On 19/01/20 20:06 -0700, Sandra Loosemore wrote:
On 1/13/20 9:12 AM, Joseph Myers wrote:
On Mon, 13 Jan 2020, Sandra Loosemore wrote:
On 1/13/20 7:02 AM, Eric S. Raymond wrote:
Clean up references to SVN in in the GCC docs, redirecting to Git
documentation as appropriate.
This is OK, althou
On 1/13/20 9:12 AM, Joseph Myers wrote:
On Mon, 13 Jan 2020, Sandra Loosemore wrote:
On 1/13/20 7:02 AM, Eric S. Raymond wrote:
Clean up references to SVN in in the GCC docs, redirecting to Git
documentation as appropriate.
This is OK, although the set of changes for the libstdc++ manual lik
On 13/01/20 09:02 -0500, Eric S. Raymond wrote:
diff --git a/libstdc++-v3/doc/xml/faq.xml b/libstdc++-v3/doc/xml/faq.xml
index b4bf333e26a..21c312dce35 100644
--- a/libstdc++-v3/doc/xml/faq.xml
+++ b/libstdc++-v3/doc/xml/faq.xml
@@ -34,9 +34,8 @@
clauses 20 through 33 and annex D (prior to t
On Mon, 13 Jan 2020, Jonathan Wakely wrote:
> Here's what I've committed to releases/gcc-9, I'll do something
> similar for gcc-8.
Cool, thank you.
That was a good catch, even without the conversion to GIT; I'll
see that I'll contribute to the conversion on the wwwdocs side
over the coming even
Jonathan Wakely :
> Email the patches to gcc-patches@gcc.gnu.org, that's how things get
> merged.
>
> We're not looking to change any workflows now.
Roger that.
Once the dust from the conversion has settled, though, there is a
related issue I intend to bring up on the main list.
You've only col
On 13/01/20 12:24 -0500, Eric S. Raymond wrote:
Joseph Myers :
I think you'll need to commit this for Eric (using --author= to set the
git author, whenever you commit a patch for someone else). The libstdc++
maintainers can probably handle regenerating the HTML version of the
libstdc++ document
Joseph Myers :
> I think you'll need to commit this for Eric (using --author= to set the
> git author, whenever you commit a patch for someone else). The libstdc++
> maintainers can probably handle regenerating the HTML version of the
> libstdc++ documentation.
I'm hesitant to request push acc
On 13/01/20 16:21 +, Jonathan Wakely wrote:
On 13/01/20 09:09 -0700, Sandra Loosemore wrote:
On 1/13/20 7:02 AM, Eric S. Raymond wrote:
Clean up references to SVN in in the GCC docs, redirecting to Git
documentation as appropriate.
This is OK, although the set of changes for the libstdc++
On 13/01/20 09:09 -0700, Sandra Loosemore wrote:
On 1/13/20 7:02 AM, Eric S. Raymond wrote:
Clean up references to SVN in in the GCC docs, redirecting to Git
documentation as appropriate.
This is OK, although the set of changes for the libstdc++ manual like
this gave me pause:
diff --git a
On Mon, 13 Jan 2020, Sandra Loosemore wrote:
> On 1/13/20 7:02 AM, Eric S. Raymond wrote:
> > Clean up references to SVN in in the GCC docs, redirecting to Git
> > documentation as appropriate.
>
> This is OK, although the set of changes for the libstdc++ manual like this
> gave me pause:
I thin
On 1/13/20 7:02 AM, Eric S. Raymond wrote:
Clean up references to SVN in in the GCC docs, redirecting to Git
documentation as appropriate.
This is OK, although the set of changes for the libstdc++ manual like
this gave me pause:
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
b
Clean up references to SVN in in the GCC docs, redirecting to Git
documentation as appropriate.
Where references to "the source code repository" rather than a
specific VCS make sensxse, I have used them. You might, after
all, change VCSes again someday.
I have not modified either generated HTML f
On 7/30/19 10:36 AM, Richard Biener wrote:
> On Tue, Jul 30, 2019 at 9:27 AM Martin Liška wrote:
>>
>> Hi.
>>
>> We have to clean up dangling pointers before we call ggc_free for a
>> cgraph_edge.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>> And it survives --en
On Tue, Jul 30, 2019 at 9:27 AM Martin Liška wrote:
>
> Hi.
>
> We have to clean up dangling pointers before we call ggc_free for a
> cgraph_edge.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> And it survives --enable-checking=release bootstrap on x86_64-linux-gnu.
Hi.
We have to clean up dangling pointers before we call ggc_free for a cgraph_edge.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
And it survives --enable-checking=release bootstrap on x86_64-linux-gnu.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-07-30
Tested x86_64-linux, committed to trunk.
Thomas Rodgers writes:
> Jonathan Wakely writes:
>
>> On 31/05/19 17:15 -0700, Thomas Rodgers wrote:
>>>
>>>Revising previous version of this patch to pick another missed
>>>uglification.
>>
>> OK for trunk, thanks.
>>
>> I also see this one:
>>
>> include
Jonathan Wakely writes:
> On 31/05/19 17:15 -0700, Thomas Rodgers wrote:
>>
>>Revising previous version of this patch to pick another missed
>>uglification.
>
> OK for trunk, thanks.
>
> I also see this one:
>
> include/pstl/parallel_backend_tbb.h:__buffer(std::size_t n) :
> _M_allocator(),
On 31/05/19 17:15 -0700, Thomas Rodgers wrote:
Revising previous version of this patch to pick another missed
uglification.
OK for trunk, thanks.
I also see this one:
include/pstl/parallel_backend_tbb.h:__buffer(std::size_t n) :
_M_allocator(), _M_ptr(_M_allocator.allocate(n)), _M_buf_s
Revising previous version of this patch to pick another missed
uglification.
>From 543d6be586ad8c29ef0ceefd55a249c715bd2480 Mon Sep 17 00:00:00 2001
From: Thomas Rodgers
Date: Fri, 31 May 2019 13:28:32 -0700
Subject: [PATCH] Clean up non-conforming names
* include/pstl/algorithm_imp
* include/pstl/algorithm_impl.h (__parallel_set_union_op):
Uglfiy copy_range1 and copy_range2
* include/pstl/parallel_backend_tbb.h (struct __binary_no_op):
Rename parameter _T to _Tp.
---
libstdc++-v3/include/pstl/algorithm_impl.h | 16
lib
On Thu, May 9, 2019 at 11:59 AM Thomas Schwinge wrote:
>
> Hi!
>
> On Wed, 13 Feb 2019 14:47:36 +0100, Richard Biener
> wrote:
> > On February 13, 2019 6:53:17 AM GMT+01:00, "Martin Liška"
> > wrote:
> > >As Honza noticed, there's still some leftover from MPX removal.
> > >May I remove another
255ef8f2ec03bc49 Mon Sep 17 00:00:00 2001
From: tschwinge
Date: Thu, 9 May 2019 09:52:10 +
Subject: [PATCH] Clean up MPX-related stuff: CIF_CHKP
..., which was forgotten in recent r268844.
gcc/
* cif-code.def (CHKP): Remove.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@271029 138bc75d-
On February 13, 2019 6:53:17 AM GMT+01:00, "Martin Liška"
wrote:
>Hi.
>
>As Honza noticed, there's still some leftover from MPX removal.
>May I remove another bunch of fields now, or should I wait
>for next stage1?
You can do it now.
Richard.
>Patch can bootstrap on x86_64-linux-gnu and surv
Hi.
As Honza noticed, there's still some leftover from MPX removal.
May I remove another bunch of fields now, or should I wait
for next stage1?
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Thanks,
Martin
gcc/ChangeLog:
2019-02-13 Martin Liska
* builtins.h
* testsuite/27_io/filesystem/operations/canonical.cc: Remove
directory created by test.
* testsuite/27_io/filesystem/operations/symlink_status.cc: Remove
symlink created by test.
Tested x86_64-linux, committed to trunk.
commit c981ab59c04fe12ffee89bbfe466a40d66e40
On Thu, Nov 22, 2018 at 8:47 PM Jakub Jelinek wrote:
>
> Hi!
>
> While adjusting the PR85644 patch, I've noticed that while pretty much
> the whole ix86_option_override_internal works only with opts_set->x_
> and opts->x_, the stack protector guard code was accessing
> global_options_set.x_ or usi
Hi!
While adjusting the PR85644 patch, I've noticed that while pretty much
the whole ix86_option_override_internal works only with opts_set->x_
and opts->x_, the stack protector guard code was accessing
global_options_set.x_ or using the macros that expand to
global_options.x_ . While it is proba
Ok, so I discussed that with Honza, the patch does not make sense any longer.
Reason is that histograms are used in RTL expansion in order to provide
hint for memcpy, memset-like operations.
Please ignore the patch.
Martin
Hi.
Attempt of the patch is to remove all histograms right after
"profile_estimate" pass. Then nobody should use them. That
will simplify code we'll not need verification and currently
we leaked some histograms till the end of compilation.
Patch can bootstrap on x86_64-linux-gnu and survives regr
On Wed, Apr 11, 2018 at 11:26:26AM +0200, Martin Liška wrote:
> This is a small clean-up which Jakub suggested.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Martin
>
>
> gcc/lto/ChangeLog:
>
> 2018-04-11 Martin Liska
>
> * lt
Hi.
This is a small clean-up which Jakub suggested.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Martin
gcc/lto/ChangeLog:
2018-04-11 Martin Liska
* lto-symtab.c (lto_symtab_merge_p): Use attribute_value_equal
function.
---
On 01/23/2018 10:43 AM, Jan Hubicka wrote:
>> Hi.
>>
>> I'm aware in which development stage we are. However the patch is small and
>> makes
>> dump files readable. Hope such patch can be accepted even now?
>>
>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>>
>> Mart
> Hi.
>
> I'm aware in which development stage we are. However the patch is small and
> makes
> dump files readable. Hope such patch can be accepted even now?
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Martin
>
> gcc/ChangeLog:
>
> 2018-01-22 Martin Li
Hi.
I'm aware in which development stage we are. However the patch is small and
makes
dump files readable. Hope such patch can be accepted even now?
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Martin
gcc/ChangeLog:
2018-01-22 Martin Liska
* tree-prof
> Hello.
>
> This is patch for i586 bootstrap that is triggered by bug in detail described
> in the PR.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?
> Martin
>
> gcc/ChangeLog:
>
> 2018-01-09 Martin Liska
>
> PR bootstrap/8
Hello.
This is patch for i586 bootstrap that is triggered by bug in detail described
in the PR.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
gcc/ChangeLog:
2018-01-09 Martin Liska
PR bootstrap/82831
* basic-block.h
On Wed, Jan 03, 2018 at 02:07:36PM +0100, Martin Liška wrote:
> 2018-01-03 Martin Liska
>
> PR tree-optimization/83593
> * tree-ssa-strlen.c (strlen_check_and_optimize_stmt): Clean-up
> EH gimple statements.
> (strlen_dom_walker::before_dom_children): Call
> gimple
to propagate that in
strlen_dom_walker::m_cleanup_cfg.
I've just triggered tests.
Ready to install after it finishes?
>From 217982bae6969865051f12798e4da444dd4aaa3f Mon Sep 17 00:00:00 2001
From: marxin
Date: Wed, 3 Jan 2018 12:15:40 +0100
Subject: [PATCH] Clean-up EH after strlen transform
On 01/03/2018 01:49 PM, Marc Glisse wrote:
> On Wed, 3 Jan 2018, Martin Liška wrote:
>
> + *cleanup_eh = maybe_clean_or_replace_eh_stmt (stmt,
> + stmt);
>
> Do you mean *cleanup_eh |= ... ?
>
Yes. Thanks!
On Wed, Jan 03, 2018 at 01:27:01PM +0100, Martin Liška wrote:
> /* Reading the final '\0' character. */
> tree zero = build_int_cst (TREE_TYPE (lhs), 0);
> gimple_set_vuse (stmt, NULL_TREE);
> gimple_assign_set
On Wed, 3 Jan 2018, Martin Liška wrote:
+ *cleanup_eh = maybe_clean_or_replace_eh_stmt (stmt,
+ stmt);
Do you mean *cleanup_eh |= ... ?
--
Marc Glisse
Hi.
Strlen pass does following transformation:
Optimizing: _7 = *ju_5(D);
into: _7 = 0;
which leads to need of removal of EH for the gimple statement. That's done via
maybe_clean_or_replace_eh_stmt
and then we need to call gimple_purge_dead_eh_edges. Last question I have is
whether it's also n
On Thu, Nov 3, 2016 at 9:56 PM, Eric Botcazou wrote:
> Hi,
>
> WORD_REGISTER_OPERATIONS and LOAD_EXTEND_OP are partially used directly as
> preprocessor macros and partially tested in the code. This patch brings a bit
> of consistency into this by converting the remaining macro cases.
>
> Tested
Hi,
WORD_REGISTER_OPERATIONS and LOAD_EXTEND_OP are partially used directly as
preprocessor macros and partially tested in the code. This patch brings a bit
of consistency into this by converting the remaining macro cases.
Tested on SPARC/Solaris and x86-64/Linux, OK for the mainline?
2016-1
Hi David,
On 06/06/2016 22:26, David Malcolm wrote:
Thanks, looks like a nice simplification.
I see the new prototypes are wrapped in #ifdef ATTRIBUTE_GCC_DIAG.
Isn't that redundant? Looking at diagnostic-core.h, isn't it always
defined? (perhaps to the empty string)
Also the new functions ar
On Mon, 2016-06-06 at 10:55 +0200, Paolo Carlini wrote:
> Hi,
>
> yesterday I had the idea of this small clean-up: move the work done
> by
> emit_diagnostic to a new non-variadic diagnostic_impl and use it to
> implement the former and all the various inform, warning, permerror,
> etc
> (lately
Hi,
yesterday I had the idea of this small clean-up: move the work done by
emit_diagnostic to a new non-variadic diagnostic_impl and use it to
implement the former and all the various inform, warning, permerror, etc
(lately we have the *_at_rich_loc variants too). Something similar can
be don
On Wed, 18 May 2016, Jeff Law wrote:
> FWIW, Fedora 24 uses dejagnu-1.6. Not sure about other distributions.
openSUSE Tumbleweed is on 1.5.3, but I'm pretty sure we can get
that updated. FreeBSD Ports are at 1.6.
IMHO, go ahead.
Gerald
On May 18, 2016, at 2:59 PM, Jeff Law wrote:
>
> On 05/02/2016 10:24 AM, Dominik Vogt wrote:
>> On Mon, May 02, 2016 at 09:29:50AM -0600, Jeff Law wrote:
>>> On 04/29/2016 05:56 PM, Dominik Vogt wrote:
...
Maybe a comment should be added to the test case
/* If this test is *r
On 05/02/2016 10:24 AM, Dominik Vogt wrote:
On Mon, May 02, 2016 at 09:29:50AM -0600, Jeff Law wrote:
On 04/29/2016 05:56 PM, Dominik Vogt wrote:
...
Maybe a comment should be added to the test case
/* If this test is *run* (not just compiled) and therefore fails
on non sh*-targets, this
On 05/11/2016 01:39 AM, Alexander Monakov wrote:
On Wed, 30 Mar 2016, Bernd Schmidt wrote:
On 03/25/2016 04:43 AM, Aldy Hernandez wrote:
If Bernd is fine with this, I'm happy to retract my patch and any
possible followups. I'm just interested in having no path causing a
possible out of bounds
On Wed, 30 Mar 2016, Bernd Schmidt wrote:
> On 03/25/2016 04:43 AM, Aldy Hernandez wrote:
> > If Bernd is fine with this, I'm happy to retract my patch and any
> > possible followups. I'm just interested in having no path causing a
> > possible out of bounds access. If your patch will do that, I'
On Wed, May 4, 2016 at 9:40 PM, Jakub Jelinek wrote:
> Hi!
>
> When looking for constraints that only have x's and not v's, these
> useless constraints caught my search too. In define_expand, constraints
> aren't really needed, they are needed only on define_insn* etc.
>
> So, I'd like to kill th
Hi!
When looking for constraints that only have x's and not v's, these
useless constraints caught my search too. In define_expand, constraints
aren't really needed, they are needed only on define_insn* etc.
So, I'd like to kill these.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok fo
On Mon, May 02, 2016 at 09:29:50AM -0600, Jeff Law wrote:
> On 04/29/2016 05:56 PM, Dominik Vogt wrote:
> > ...
> >Maybe a comment should be added to the test case
> >
> > /* If this test is *run* (not just compiled) and therefore fails
> > on non sh*-targets, this is because of a bug older De
On 04/29/2016 05:56 PM, Dominik Vogt wrote:
Yeah, sorry, I really should have mentioned this but forgot about
it. It's a bug in DejaGnu. When it encounters a conditional
dg-do and the condition does not match, it *still* replaces the
do-action of a prior dg-do with the current one. With DejaG
Hi,
nice bug, we should not test it in the gcc testsuite.
Could you just split the spec-options.c test case in one that
compiles everywhere, and one that executes only on target sh*-*-* ?
Bernd.
On Fri, Apr 29, 2016 at 10:03:40PM +0200, Rainer Orth wrote:
> Dominik Vogt writes:
>
> > The attached patch cleans up some (mostly unnecessary) dg-do
> > directives in the gcc.dg and gcc.target test cases.
>
> This part
>
> * gcc.dg/spec-options.c: Switch order of the two "dg-do run" so
Dominik Vogt writes:
> The attached patch cleans up some (mostly unnecessary) dg-do
> directives in the gcc.dg and gcc.target test cases.
This part
* gcc.dg/spec-options.c: Switch order of the two "dg-do run" so that
the test ist actually "run" on sh*-*-*. Order _does_ matter.
On 04/27/2016 09:50 AM, Dominik Vogt wrote:
> The attached patch cleans up some (mostly unnecessary) dg-do
> directives in the gcc.dg and gcc.target test cases.
Applied. Thanks!
-Andreas-
On 04/27/2016 09:50 AM, Dominik Vogt wrote:
The attached patch cleans up some (mostly unnecessary) dg-do
directives in the gcc.dg and gcc.target test cases.
Ok except...
* gcc.dg/spec-options.c: Switch order of the two "dg-do run" so that
the test ist actually "run" on sh*-*-*
Vogt
Date: Wed, 9 Mar 2016 15:42:23 +0100
Subject: [PATCH] Clean up tests where a later dg-do completely overrides
another.
In most tests the first dg-do could be simply removed. In one case the two
lines needed to be swapped so that the condition of the "run" was not
overridden by
I'm committing the __throw_bad_alloc() part on the branch too.
commit 02221ce47cade82036c7d78ed79e5fe536fdfcfd
Author: Jonathan Wakely
Date: Thu Sep 3 23:01:02 2015 +0100
* include/std/shared_mutex (shared_timed_mutex::shared_timed_mutex):
Replace throw with __throw_bad_alloc.
diff
This adjusts some missing or redundant includes, and replaces "throw
bad_alloc()" (which won't work with -fno-exceptions) with a call to
__throw_bad_alloc().
Tested powerpc64e-linux, committed to trunk.
commit ca17448c303cfd58191c64abe42a750c9590aa14
Author: Jonathan Wakely
Date: Thu Sep 3 21
On Wed, May 13, 2015 at 10:52 AM, Eric Botcazou wrote:
>> The libgo parts are fine, but since libgo is mirrored from an external
>> repository I'll commit those parts myself.
>
> Thanks!
>
>> I assume I can go ahead and commit them now?
>
> Yes, you can, the libgo bits are independent.
libgo port
> The libgo parts are fine, but since libgo is mirrored from an external
> repository I'll commit those parts myself.
Thanks!
> I assume I can go ahead and commit them now?
Yes, you can, the libgo bits are independent.
--
Eric Botcazou
On Tue, May 12, 2015 at 9:42 AM, Eric Botcazou wrote:
>
> 6 target libraries in the tree detect whether they are being compiled by a
> compiler configured for setjmp/longjmp exceptions: libada, libgcc, libgo,
> libjava, libobjc and libstdc++. They can be divided into 3 categories:
> 1) libada on
> This patch fixes an issue preventing mingw-w64 i686 dwarf2-eh
> bootstrapping described at:
>
> http://sourceforge.net/p/mingw-w64/mailman/message/34101954/
>
> I'm assuming this has more to do with switching away from the current
> sjlj configuration method since configuring gcc with
> "--disa
This patch fixes an issue preventing mingw-w64 i686 dwarf2-eh
bootstrapping described at:
http://sourceforge.net/p/mingw-w64/mailman/message/34101954/
I'm assuming this has more to do with switching away from the current
sjlj configuration method since configuring gcc with
"--disable-sjlj-excepti
On 12/05/15 18:42 +0200, Eric Botcazou wrote:
libstdc++-v3/
* acinclude.m4 (GLIBCXX_ENABLE_SJLJ_EXCEPTIONS): Delete.
* configure.ac: Remove GLIBCXX_ENABLE_SJLJ_EXCEPTIONS.
* config.h.in: Regenerate.
* configure: Likewise.
* libsupc++/eh_personality.cc: Repl
On Tue, May 12, 2015 at 9:42 AM, Eric Botcazou wrote:
> Hi,
>
> 6 target libraries in the tree detect whether they are being compiled by a
> compiler configured for setjmp/longjmp exceptions: libada, libgcc, libgo,
> libjava, libobjc and libstdc++. They can be divided into 3 categories:
> 1) lib
> Generally OK. However, please confirm with ian on the libgo bits just
> in case you're hitting something that's shared with golang.
OK, I can certainly wait for Ian's approval for the libgo bits.
> We could certainly consider cleaning up the targets (hppa). That'd be a
> fine follow-up :-) I
On 05/12/2015 10:42 AM, Eric Botcazou wrote:
Hi,
6 target libraries in the tree detect whether they are being compiled by a
compiler configured for setjmp/longjmp exceptions: libada, libgcc, libgo,
libjava, libobjc and libstdc++. They can be divided into 3 categories:
1) libada only checks th
Hi,
6 target libraries in the tree detect whether they are being compiled by a
compiler configured for setjmp/longjmp exceptions: libada, libgcc, libgo,
libjava, libobjc and libstdc++. They can be divided into 3 categories:
1) libada only checks the preprocessor macro __USING_SJLJ_EXCEPTIONS__
On 10/10/14 02:17, Zhenqiang Chen wrote:
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: Thursday, October 09, 2014 5:21 PM
To: Zhenqiang Chen
Cc: GCC Patches
Subject: Re: [PATCH] Clean up duplicated function seq_cost
On Thu, Oct 9, 2014 at 11:20 AM
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Thursday, October 09, 2014 5:21 PM
> To: Zhenqiang Chen
> Cc: GCC Patches
> Subject: Re: [PATCH] Clean up duplicated function seq_cost
>
> On Thu, Oct 9, 2014 at 11:20 AM,
On Thu, Oct 9, 2014 at 11:20 AM, Richard Biener
wrote:
> On Thu, Oct 9, 2014 at 11:14 AM, Zhenqiang Chen
> wrote:
>> Hi,
>>
>> The are two implementations of seq_cost. The function bodies are exactly the
>> same. The patch removes one of them and make the other global.
>>
>> Bootstrap and no mak
On Thu, Oct 9, 2014 at 11:14 AM, Zhenqiang Chen wrote:
> Hi,
>
> The are two implementations of seq_cost. The function bodies are exactly the
> same. The patch removes one of them and make the other global.
>
> Bootstrap and no make check regression on X86-64.
>
> OK for trunk?
The prototype shou
Hi,
The are two implementations of seq_cost. The function bodies are exactly the
same. The patch removes one of them and make the other global.
Bootstrap and no make check regression on X86-64.
OK for trunk?
Thanks!
-Zhenqiang
ChangeLog:
2014-10-09 Zhenqiang Chen
* cfgloopanal.c (s
On 05/13/14 02:13, Marek Polacek wrote:
On Tue, May 13, 2014 at 04:08:21PM +0800, Zhenqiang Chen wrote:
On 13 May 2014 15:55, Marek Polacek wrote:
On Tue, May 13, 2014 at 03:14:34PM +0800, Zhenqiang Chen wrote:
Thanks. Committed the patch @r210351 with changes:
(1) Create shrink-wrap.h.
(2) M
On 13 May 2014 16:13, Marek Polacek wrote:
> On Tue, May 13, 2014 at 04:08:21PM +0800, Zhenqiang Chen wrote:
>> On 13 May 2014 15:55, Marek Polacek wrote:
>> > On Tue, May 13, 2014 at 03:14:34PM +0800, Zhenqiang Chen wrote:
>> >> Thanks. Committed the patch @r210351 with changes:
>> >> (1) Create
On Tue, May 13, 2014 at 04:08:21PM +0800, Zhenqiang Chen wrote:
> On 13 May 2014 15:55, Marek Polacek wrote:
> > On Tue, May 13, 2014 at 03:14:34PM +0800, Zhenqiang Chen wrote:
> >> Thanks. Committed the patch @r210351 with changes:
> >> (1) Create shrink-wrap.h.
> >> (2) Move all shrink-wrapping
On 13 May 2014 15:55, Marek Polacek wrote:
> On Tue, May 13, 2014 at 03:14:34PM +0800, Zhenqiang Chen wrote:
>> Thanks. Committed the patch @r210351 with changes:
>> (1) Create shrink-wrap.h.
>> (2) Move all shrink-wrapping related interfaces from function.h to
>> shrink-wrap.h.
>> (3) shrink-wrap
1 - 100 of 121 matches
Mail list logo
