On Sat, Apr 26, 2014 at 1:00 PM, Jonathan Wakely wrote:
> Maybe a dumb question (I don't understand a lot of the regex code!)
> but is it correct to set this to 1 in the case where
> __rep_count.first != _M_current ? Could that result in the count
> going downwards from 2 to 1? (Maybe that's corr
On Mon, 21 Apr 2014, David Malcolm wrote:
> It was pointed out to me off-list that this patch series lacks
> documentation changes. I'm working on fixing that, though am not sure I
> want to fill everyone inboxes with an updated set of patches yet.
> Should I send a combined patch for the document
The perfect is the enemy of the good.
>From all I have seen and heard, this rewrite is a clear improvement
over the status quo. So I am going to review and approve it wearing
my doc maintainer hat, deferring to and relying on Andrew and Richard
and their deep expertise on the technical side.
Hi,
Shall it a good idea to add new warning -Wsizeof-array-argument that
warns when sizeof is applied on parameter declared as an array ?
Similar to clang's -Wsizeof-array-argument:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20110613/042812.html
This was also reported as PR6940:
On Thu, 17 Apr 2014, Jan Hubicka wrote:
> + * opts.c (common_handle_option): Disable -fipa-reference coorectly
> + with -fuse-profile.
coorectly -> correctly
Gerald
On Fri, 25 Apr 2014, David Malcolm wrote:
> Successfully generates HTML, info and pdf via appropriate make
> invocations; example of resulting HTML can be seen at the bottom of:
>
> http://dmalcolm.fedorapeople.org/gcc/2014-04-25/Tuple-representation.html
>
> The diagram is split over pages 178-1
On Sat, 26 Apr 2014, Markus Trippelsdorf wrote:
> Parallel profiledbootstrap is supported on all maintained releases. So
> just remove a misleading outdated sentence, that states the opposite,
> from doc/install.texi.
>
> OK for trunk?
Okay. If this also applies to GCC 4.9 (which I think is the
> So, if you have int16 target, where unsigned int is 16-bit and UINT_MAX
> 65535, then shift count must be >= 0 and < 16, therefore, 2U << 31 is
> undefined behavior.
Well, if the shift count is masked by the target, if will be masked according
to the width of the register and the result will ne
> I believe Jakub is referring to the following in the C standard:
>
> "Bitwise shift operators
> ...
> Semantics
> ... If the value of the right operand ... is greater than or equal to the
> width of the promoted left operand, the behavior is undefined."
>
> So on 16-bit int systems you can't p
On 25/04/14 18:03 -0400, Tim Shen wrote:
* include/bits/regex_executor.h: Add _M_rep_count to track how
many times this repeat node are visited.
"is visited" not "are visited"
@@ -151,6 +156,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// character.
std::unique_ptr>> _M_
OK if bootstrap succeeds?
With testing of the bootstrap build of the patch, I ran into the following
regression compared to a reference bootstrap build without the patch:
...
FAIL: g++.dg/tsan/cond_race.C -O2 output pattern test, is ==3087==WARNING:
Program is run with unlimited stack size,
On 25/04/14 20:50 -0400, Tim Shen wrote:
* include/bits/regex.tcc (__regex_algo_impl<>): Remove
_GLIBCXX_REGEX_DFS_QUANTIFIERS_LIMIT and use
_GLIBCXX_REGEX_USE_THOMPSON_NFA instead.
* include/bits/regex_automaton.h: Remove quantifier counting variable.
* i
On Sat, Apr 26, 2014 at 03:30:25PM +0200, Eric Botcazou wrote:
> > > Not clear to me, (2U << i) should be zero if the shift count is masked.
> >
> > 2U << 31 is undefined behavior on those targets.
>
> Precisely not, or else we are not talking about the same notion of masking.
Eh, C99, 6.5.7/3:
Parallel profiledbootstrap is supported on all maintained releases. So
just remove a misleading outdated sentence, that states the opposite,
from doc/install.texi.
OK for trunk?
Thanks.
2014-04-26 Markus Trippelsdorf
* doc/install.texi (Building with profile feedback): Remove
Eric Botcazou writes:
> > > Not clear to me, (2U << i) should be zero if the shift count is masked.
> >
> > 2U << 31 is undefined behavior on those targets.
>
> Precisely not, or else we are not talking about the same notion of masking.
I believe Jakub is referring to the following in the C
Quoting Svante Signell (2014-04-26 13:59:57)
> > For reference, here are my notes about one of these crashes (Svante,
> > is this still current?):
>
> Yes it is, thanks for your help so far. Is the rpctrace bug you
> mentioned that the wrong ports are reported?
>
> > ~~~ snip ~~~
> > [...]
> > ta
> > Not clear to me, (2U << i) should be zero if the shift count is masked.
>
> 2U << 31 is undefined behavior on those targets.
Precisely not, or else we are not talking about the same notion of masking.
--
Eric Botcazou
> > 2014-03-21 James Greenhalgh
> >
> > * calls.c (initialize_argument_information): Always treat
> > PUSH_ARGS_REVERSED as 1, simplify code accordingly.
> > (expand_call): Likewise.
> > (emit_library_call_calue_1): Likewise.
> > * expr.c (PUSH_ARGS_REVERSED): Do not define.
Eric,
Honza,
This patch adds analysis in pass_final to track which hard registers are set or
clobbered by the function body, and stores that information in a
struct cgraph_node, to be used in the fuse-caller-save optmization.
This is the updated version of the previously approved patch
submitted
this is fine.
kenny
On 04/25/2014 09:44 AM, Richard Sandiford wrote:
We should write back the sign-extended value.
Tested on x86_64-linux-gnu. OK to install?
Thanks,
Richard
Index: gcc/wide-int.cc
===
--- gcc/wide-int.cc 20
i am sorry, i missed the fact that the loop counts up but you were
reversing the order in the indexes.
kenny
On 04/26/2014 04:26 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
don't you think that it would be easier to understand the number if you
printed it largest index first, as in th
Hello!
2014-04-26 Uros Bizjak
* gcc.dg/tree-ssa/alias-30.c (dg-options): Dump only fre1 details.
* gcc.dg/vect/pr60505.c: Cleanup vect tree dump.
* g++.dg/ipa/devirt-27.C (dg-options): Remove -fdump-ipa-devirt.
Committed to mainline and 4.9 branch.
Uros.
Index: gcc.dg/tree-ssa/al
On 25-04-14 15:22, Richard Sandiford wrote:
Tom de Vries writes:
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 45256e9..b61cd44 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -7027,11 +7027,17 @@ mips_expand_call (enum mips_call_type type, rtx result,
±On Sat, 2014-04-26 at 08:53 +0200, Justus Winter wrote:
> Quoting Svante Signell (2014-04-24 10:39:10)
> > On Fri, 2014-04-18 at 10:03 +0200, Samuel Thibault wrote:
> > > Samuel Thibault, le Thu 17 Apr 2014 00:03:45 +0200, a écrit :
> > > > Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écr
Attached patch implements TARGET_ATOMIC_ASSIGN_EXPAND_FENV for AARCH64.
With this, atomic test-case gcc.dg/atomic/c11-atomic-exec-5.c now PASS.
This implementation is based on SPARC and i386 implementations.
Regression tested on qemu-aarch64 for aarch64-none-linux-gnu with no new
regression. Is t
Hi,
Attached patch implements TARGET_ATOMIC_ASSIGN_EXPAND_FENV for ARM. With
this, atomic test-case gcc.dg/atomic/c11-atomic-exec-5.c now PASS.
This implementation is based on SPARC and i386 implementations.
Regression tested on qemu-arm for arm-none-linux-gnueabi with no new
regression. Is this
On Sat, Apr 26, 2014 at 11:27 AM, Tom de Vries wrote:
> On 13-03-14 21:49, Richard Henderson wrote:
>>
>> (define_expand "ldexpxf3"
>> - [(set (match_dup 3)
>> - (float:XF (match_operand:SI 2 "register_operand")))
>> - (parallel [(set (match_operand:XF 0 " register_operand")
>> -
On 13-03-14 21:49, Richard Henderson wrote:
(define_expand "ldexpxf3"
- [(set (match_dup 3)
- (float:XF (match_operand:SI 2 "register_operand")))
- (parallel [(set (match_operand:XF 0 " register_operand")
- (unspec:XF [(match_operand:XF 1 "register_operand")
-
Another column info improvements, this time for initializer
warnings. warning_init and add_pending_init had to gain new location
parameter.
What is worth mentioning is that the "(near initialization for X)"
message seems next to useless to me now with caret diagnostics (?).
Regtested/bootstrappe
Am 12.04.2014 21:33, schrieb Thomas Koenig:
please find attached a patch for PR 59604.
The patch makes sure that, if -fno-range-check is specified,
using int on an overflowing boz constant yields the same
result for compile-time simplification and run-time
execution.
OK for trunk?
Looks good
Kenneth Zadeck writes:
> don't you think that it would be easier to understand the number if you
> printed it largest index first, as in the routines in wide-int-print.cc?
Yeah, that's what the patch does. E.g. (for 32-bit HWI):
[...,0x3,0x8000]
is 7 << 31.
Thanks,
Richard
>
> kenny
>
On Thu, Apr 24, 2014 at 05:32:54PM -0700, Cong Hou wrote:
> In this patch a new reload-rewrite pattern detector is composed to
> handle the following pattern in the loop being vectorized:
>
>x = *p;
>...
>y = *p;
>
>or
>
>*p = x;
>...
>y = *p;
>
> In both cases, *p i
32 matches
Mail list logo
