On Fri, Jul 19, 2013 at 11:00 PM, Jakub Jelinek wrote:
> On Fri, Jul 19, 2013 at 04:56:47PM +0200, Uros Bizjak wrote:
>> > OK for trunk?
>>
>> Assuming that Jakub is OK with the patch, it is OK for trunk.
>
> With the line wrapping fix and Uros' suggested improvement this is ok for
> both trunk an
Hi Uros,
On 21 Jul 2013, at 08:34, Uros Bizjak wrote:
>
Sure, I can test that - do you want me to apply it assuming it reg-tests OK on
darwin & linux?
(also I can amend the back ports - since I didn't have time to get to them
yesterday)
thanks
Iain
On Sun, Jul 21, 2013 at 9:42 AM, Iain Sandoe wrote:
>>
>
> Sure, I can test that - do you want me to apply it assuming it reg-tests OK
> on darwin & linux?
> (also I can amend the back ports - since I didn't have time to get to them
> yesterday)
Yes, please test it on darwin. The build test o
Mikael Morin wrote:
Le 17/07/2013 11:02, Tobias Burnus a écrit :
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
The fortran bits look good.
Thanks for the review Mikel and David! Thanks for the patch Uros.
I have now committed the patch (Rev. 201093). - Hopefully, it works on
al
Hi Paul,
This is OK for trunk. Could you expand the comment to capture the two
cases without dependency. eg.
There is no dependency if the vector indices are equal or things are
known to be different in a different dimension.
Committed to trunk with an updated comment, as you suggested, as re
Hi,
This is series of typo fixing patches. They are generated with stylepp
https://github.com/neleai/stylepp
which makes patch generation very effective.
This series should be applied in sequence to avoid reviewing duplicates.
Now I exclude those directories that are upstream, see file
https://g
On Sun, 21 Jul 2013, Ondřej Bílka wrote:
This is series of typo fixing patches. They are generated with stylepp
https://github.com/neleai/stylepp
which makes patch generation very effective.
This series should be applied in sequence to avoid reviewing duplicates.
Now I exclude those directorie
I do not believe such fixes in testsuites make sense. They are definitely
inappropriate in testsuite input data (as opposed to comments) without
specific rationale in the patch posting for why the change is OK.
Changes to gcc/go/gofrontend/ and libgo/ have their own rules as those
directories
Tobias Burnus wrote:
I have now committed the patch (Rev. 201093).
I missed the attached patch, which fixes the build. (Rev. 201095)
Tobias
Index: libgfortran/ChangeLog
===
--- libgfortran/ChangeLog (Revision 201094)
+++ libgfortra
Hello Richard,
> "Jürgen Urban" writes:
> >> "Jürgen Urban" writes:
> >> >> "Jürgen Urban" writes:
> >> >> > I used the SPU code in GCC as example for creating an
> >> >> > r5900_single_format structure. The patch is attached to the e-mail. I
> >> >> > want to submit this patch.
> >> >>
> >> >>
Marc Glisse wrote:
>On Fri, 19 Jul 2013, Jeff Law wrote:
>
>> It's also worth noting that fold-const.c also does some type
>> hoisting/sinking.
>
>fold-const.c does everything ;-)
>
>> Ideally that code should just be going away.
>
>Like most of the code from fold-const.c that isn't about foldin
On Sun, Jul 21, 2013 at 04:32:04PM +0200, Ondřej Bílka wrote:
> Hi,
>
> This is series of typo fixing patches. They are generated with stylepp
> https://github.com/neleai/stylepp
> which makes patch generation very effective.
>
> This series should be applied in sequence to avoid reviewing duplic
On Jul 21, 2013, at 7:32 AM, Ondřej Bílka wrote:
> + * c-c++-common/raw-string-13.c: Likewise.
>
> + * c-c++-common/raw-string-14.c: Likewise.
>
On Sun, Jul 21, 2013 at 05:37:23PM +0200, Marek Polacek wrote:
>
> A few comments:
>
snip
> diff --git a/gcc/ipa.c b/gcc/ipa.c
> index 7c0d495..d44cf38 100644
> --- a/gcc/ipa.c
> +++ b/gcc/ipa.c
> @@ -548,7 +548,7 @@ static bool
> comdat_can_be_unshared_p_1 (symtab_node node)
> {
>/* When a
On Sun, Jul 21, 2013 at 09:09:37AM -0700, Mike Stump wrote:
> On Jul 21, 2013, at 7:32 AM, Ondřej Bílka wrote:
> > + * c-c++-common/raw-string-13.c: Likewise.
> >
> > + * c-c++-common/raw-string-14.c: Likewis
On Jul 21, 2013, at 7:32 AM, Ondřej Bílka wrote:
> This is series of typo fixing patches. They are generated with stylepp
> https://github.com/neleai/stylepp
> which makes patch generation very effective.
I've checked in most changes to Objective-C things and test suite things after
reviewing al
On Jul 21, 2013, at 8:37 AM, Marek Polacek wrote:
> diff --git a/gcc/ada/gcc-interface/utils2.c b/gcc/ada/gcc-interface/utils2.c
> index 3f39a43..7f7f6af 100644
> --- a/gcc/ada/gcc-interface/utils2.c
> +++ b/gcc/ada/gcc-interface/utils2.c
> @@ -1902,7 +1902,7 @@ build_simple_component_ref (tree re
I've applied these fixes, to ensure that they are not corrected incorrectly,
thanks for the corrections.
On Jul 21, 2013, at 8:37 AM, Marek Polacek wrote:
> diff --git a/gcc/ipa.c b/gcc/ipa.c
> index 7c0d495..d44cf38 100644
> --- a/gcc/ipa.c
> +++ b/gcc/ipa.c
> @@ -548,7 +548,7 @@ static bool
>
On Jul 21, 2013, at 7:32 AM, Ondřej Bílka wrote:
> This is series of typo fixing patches.
I've reviewed and applied the gcc/doc changes that were trivial. The only
patches not applied were the ok->OK patches.
On Sun, Jul 21, 2013 at 04:44:40PM +0200, Marc Glisse wrote:
> On Sun, 21 Jul 2013, Ondřej Bílka wrote:
>
> >Then I ran script/stylepp_fix_spell which produced following 300kb patch:
> >
> >http://kam.mff.cuni.cz/~ondra/0001-Fix-common-typos.patch
>
> There are still some wrong fixes, humans real
On Jul 21, 2013, at 7:32 AM, Ondřej Bílka wrote:
> This is series of typo fixing patches.
I reviewed and applied all the trivial patches in gcc/config. Excluded were
ok->OK, and
/* My current feeling is that r14 should go to the end and maybe even r12.
On 18 July 2013 11:06, Tim Shen wrote:
>
> These will be fixed when commit to SVN.
OK. The rest of the patch is fine - would you like me to commit it for
you, with those fixes?
On Jul 21, 2013, at 7:32 AM, Ondřej Bílka wrote:
> This is series of typo fixing patches.
I checked in all the changes to gcc/cp that were trivial.
Ondřej Bílka wrote:
This is series of typo fixing patches. They are generated with stylepp
https://github.com/neleai/stylepp
which makes patch generation very effective.
[...]
Then I ran script/stylepp_fix_spell which produced following 300kb patch:
http://kam.mff.cuni.cz/~ondra/0001-Fix-common
On Jul 21, 2013, at 7:32 AM, Ondřej Bílka wrote:
> This is series of typo fixing patches.
I reviewed and checked in all that changes to gcc/tree\* that were trivial. I
left out ok->OK, and
--- a/gcc/tree-ssa-pre.c
On Jul 21, 2013, at 7:32 AM, Ondřej Bílka wrote:
> This is series of typo fixing patches.
I checked in the fixes to gcc/[l-t]* that were trivial. (ok->OK being the
usual exclusion).
On Sat, Jul 20, 2013 at 08:17:34PM -0400, Jason Merrill wrote:
> On 07/20/2013 10:27 AM, Jakub Jelinek wrote:
> >So, the middle-end can only use
> >some other type, say build_nonstandard_integer_type (POINTER_SIZE, 1);
> >which often will be the same type as uintptr_type_node, but perhaps not on
>
On Jul 21, 2013, at 7:32 AM, Ondřej Bílka wrote:
> gcc/c/c-decl.c | 4 +-
>
> gcc/c/c-objc-common.c | 4 +-
>
On Jul 21, 2013, at 7:32 AM, Ondřej Bílka wrote:
> This is series of typo fixing patches.
I reviewed gcc/[a-i]* and checked in those I thought were trivial.
On Jul 21, 2013, at 11:31 AM, Mike Stump wrote:
> On Jul 21, 2013, at 7:32 AM, Ondřej Bílka wrote:
>> This is series of typo fixing patches.
>
> I reviewed gcc/[a-i]* and checked in those I thought were trivial.
So, I checked in the potentially controversial thru -> through in gcc/ada.
I'll l
On 16 June 2013 15:35, Jonathan Wakely wrote:
> In order to conform to [thread.condition.condvarany]/5 and fix this
> PR we need an ABI change to std::condition_variable_any, so that its
> internal mutex can outlive the condition_variable_any while there are
> threads blocked on the mutex, which t
On Sun, 21 Jul 2013, Mike Stump wrote:
> I've reviewed and applied the gcc/doc changes that were trivial. The
> only patches not applied were the ok->OK patches.
*For formal documentation* such as gcc/doc, I think changing ok->OK is
appropriate; the formal documentation should be more conserva
On Sun, 21 Jul 2013, Mike Stump wrote:
> > diff --git a/gcc/testsuite/c-c++-common/pr41779.c
> > b/gcc/testsuite/c-c++-common/pr41779.c
> > index 80c8e6b..f80412c 100644
> > --- a/gcc/testsuite/c-c++-common/pr41779.c
> > +++ b/gcc/testsuite/c-c++-common/pr41779.c
> > @@ -1,4 +1,4 @@
> > -/* PR417
On Sun, 21 Jul 2013, Mike Stump wrote:
> > diff --git a/libiberty/regex.c b/libiberty/regex.c
> > index 17091ce..8a2dd41 100644
> > --- a/libiberty/regex.c
> > +++ b/libiberty/regex.c
> > @@ -3396,7 +3396,7 @@ PREFIX(regex_compile) (const char
> > *ARG_PREFIX(pattern),
> >
On Mon, Jul 22, 2013 at 1:48 AM, Jonathan Wakely wrote:
> OK. The rest of the patch is fine - would you like me to commit it for
> you, with those fixes?
I can commit on my own. I've already been a write-after-approval.
Thank you again for reviewing!
--
Tim Shen
-- Tim,
while you work on these improvements, I think it would nice to also
commit, when appropriate, testcases which came with bug reports which we
closed as duplicates of the "std::regex is not implemented yet" report.
I'm not referring to this specific commit, just a general comment.
Than
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57513 is already in the
testsuite and can passed(even before this patch?).
To fully test it, a fully regex_search implementation is required. I'm
working on a (damning) backtracking engine for it.
--
Tim Shen
iterators.patch
Description: Binary data
On 07/22/2013 02:47 AM, Tim Shen wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57513 is already in the
testsuite and can passed(even before this patch?).
To fully test it, a fully regex_search implementation is required. I'm
working on a (damning) backtracking engine for it.
A couple of com
Hi,
The problem appears in revision 201034 in version 4.9. I attached a
one-line patch that fixes it. I also reported this problem
at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57790
I bootstrapped and ran the regression tests for this patch on x86_64-linux
and all tests pass.
In method "can_
On Fri, Jul 19, 2013 at 5:09 PM, Andrew Pinski wrote:
> I was creating a new gimple/folding interface and wanted some opinions
> on the interface.
>
> typedef double_int (*nonzerobits_t)(tree var);
> typedef tree (*valueizer_t)(tree var);
>
> class gimple_combine
> {
> public:
> gimple_combine(n
On 07/21/2013 02:26 PM, Marek Polacek wrote:
(pointer_sized_type_node): Define.
Let's call it pointer_sized_int_node.
Jason
On Sat, Jul 20, 2013 at 01:45:37AM -0400, Joern Rennecke wrote:
> Although the gcc.dg/debug/dwarf2/dwarf2.exp generally requests dwarf-2
> information, so that the test will work with targets that have a different
> default output format, that doesn't happen where the test specifies specific
> targ
On Mon, Jul 22, 2013 at 10:31:03AM +0530, Senthil Kumar Selvaraj wrote:
> On Sat, Jul 20, 2013 at 01:45:37AM -0400, Joern Rennecke wrote:
> > Although the gcc.dg/debug/dwarf2/dwarf2.exp generally requests dwarf-2
> > information, so that the test will work with targets that have a different
> > def
On Mon, Jul 22, 2013 at 9:12 AM, Paolo Carlini wrote:
> Also you are wrongly "un-uglyfying" many names, eg:
>
> - position_iterator __position;
> - const value_type* __result;
> - value_type__suffix;
> - std::size_t __n;
> - std::vector __subs;
>
>
> Remembe
Hi,
>Should I change them all to "_M_" or "__" format, and why?
Definitely. For the usual reason that if somebody in user code has a macro with
the same name before including the header the code is busted. Of course _M_ or
_S_ (vs _uppercase) is our specific convention for data members and st
Ping?
Is the updated patch OK for trunk?
Thanks!
-Zhenqiang
On 16 July 2013 17:29, Zhenqiang Chen wrote:
> On 11 July 2013 18:31, Eric Botcazou wrote:
>>> Shrink-wrap optimization sinks some instructions for more
>>> opportunities. It uses DF_LR_BB_INFO (bb)->def to check whether BB
>>> clobbe
On Mon, Jul 22, 2013 at 1:29 PM, Paolo Carlini wrote:
> Definitely. For the usual reason that if somebody in user code has a macro
> with the same name before including the header the code is busted. Of course
> _M_ or _S_ (vs _uppercase) is our specific convention for data members and
> statis
Hi,
>Great. This is the fixed version.
Patch is Ok with me but before committing please give a chance to Jon and other
interested parties to have a look.
Two more general comments: when you opencode more than a few lines don't
hesitate to add comments too (remember that the new code must be
48 matches
Mail list logo
