On Sun, Oct 27, 2013 at 9:26 PM, Jonathan Wakely wrote:
> I'm happy for that latest patch to be committed, thanks for taking the
> time to improve the comments.
Committed.
Thanks!
--
Regards,
Tim Shen
On Mon, Oct 21, 2013 at 8:21 PM, Richard Biener
wrote:
> On Fri, Oct 18, 2013 at 5:48 PM, Bin.Cheng wrote:
>> Hi Richard,
>> Is the first patch OK? Since there is a patch depending on it.
>> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01931.html
>
> Yes.
I committed the patch fixing strip_offse
Here is an implementation for C++14 digit separators (single quote).
It's still testing on x86_64-linux but I wanted to give folks a chance
to check it out.
Ed
libcpp:
2013-10-28 Edward Smith-Rowland <3dw...@verizon.net>
implement C++14 digit separators.
* include/cpplib.h
On 28 October 2013 00:23, Tim Shen wrote:
> Thank you for figuring out so many syntax errors, I'll be careful next time.
No problem, I'm always happy to help review the grammar, syntax or
spelling in documentation improvements.
> On Sun, Oct 27, 2013 at 5:38 PM, Jonathan Wakely
> wrote:
>> +
Hi Joseph,
On Sun, 27 Oct 2013, Joseph S. Myers wrote:
> I've committed this patch to rework the page so it starts with a summary
> of the overall C99 state, then describes each feature by listing the GCC
> version in which it was substantially supported (not necessarily obscure
> corner cases)
On 10/25/2013 04:46 PM, Tobias Burnus wrote:
+ do_range_for_auto_deduction (range_decl, range_expr); // FIXME:IVDEP
I think in this situation let's set a flag on the RANGE_FOR_STMT so we
can do ivdep handling at instantiation time.
Jason
Thank you for figuring out so many syntax errors, I'll be careful next time.
On Sun, Oct 27, 2013 at 5:38 PM, Jonathan Wakely wrote:
> + // The order of which states needs to be recursively applied DFS matters,
> + // depend on which greedy mode we use.
>
> I don't understand this sentence at a
Oleg Endo wrote:
> The attached patch adds a new macro TARGET_BIG_ENDIAN. I think it's a
> bit easier to read than !TARGET_LITTLE_ENDIAN. Moreover, some not so
> obvious looking uses of TARGET_LITTLE_ENDIAN for selecting MSW and LSW
> register offsets are clarified by using new macros SH_REG_MSW
This patch add the new option "-fopenmp-simd", which allows to use
OpenMP 4.0's "simd" pragmas without enabling OpenMP's threading or
target features - and, thus, it also doesn't require linking of libgomp.
The purpose is to permit a fine-tuning of vectorization without adding
the additional l
+ // This function serves in different modes, DFS mode or BFS mode, indicated
+ // by template variable __dfs_mode. See _M_main for details.
I think this would make more sense if you replace "serves" with
"operates", and __dfs_mode is a template parameter, not a variable.
+ // It applys a Dept
On Sun, Oct 27, 2013 at 9:39 PM, Uros Bizjak wrote:
> I have committed a couple of testcases from the PR, the first was
> actually fixed by [1], the second is a short testcase that failed
> without the revert.
>
> 2013-10-27 Uros Bizjak
>
> PR target/58679
> * gcc.target/i386/pr58679-1
Hello!
> It seems one my yesterday patch created problems with mode switching:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58679
>
> I reverted it until further investigation (committed as rev. 204094). Sorry
> for inconvenience.
>
> 2013-10-26 Vladimir Makarov
>
>Revert:
>
On Sun, Oct 27, 2013 at 4:20 PM, Paolo Carlini wrote:
> Should we move this comment too before the 'case', and aligned with it?
Actually this comment is for the if statement below, not the whole
case branch. I've made this clearer by moving "Every change..." part
to the switch statement, where it
Hi,
On 10/27/2013 09:12 PM, Tim Shen wrote:
@@ -190,9 +224,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
break;
case _S_opcode_subexpr_begin:
- // Here's the critical part: if there's nothing changed since last
- // visit, do NOT continue. This prevents th
Add comments for last regex commit.
Thanks!
--
Regards,
Tim Shen
commit b4aa16a08992866ca6fd60f40e422f551d0d6b2a
Author: tim
Date: Sun Oct 27 15:50:44 2013 -0400
2013-
diff --git a/libstdc++-v3/include/bits/regex_executor.tcc b/libstdc++-v3/include/bits/regex_executor.tcc
index d3b9a04
On Sat, Oct 26, 2013 at 4:49 PM, Andrew Pinski wrote:
> On Sat, Oct 26, 2013 at 2:30 PM, Andrew Pinski wrote:
>> On Fri, Oct 18, 2013 at 2:21 AM, Zhenqiang Chen
>> wrote:
>>> On 18 October 2013 00:58, Jeff Law wrote:
On 10/17/13 05:03, Richard Biener wrote:
>>>
>>> Is it OK for tru
Hi,
On Fri, 25 Oct 2013 12:51:13, Richard Biener wrote:
> Finally I think the recursion into the VIEW_CONVERT_EXPR case
> is only there because of the keep_aligning flag of get_inner_reference
> which should be obsolete now that we properly handle its effects
> in get_object_alignment. So you woul
On Sun, 27 Oct 2013, Richard Sandiford wrote:
> Tested on powerpc64-linux-gnu and x86_64-linux-gnu. OK to install?
> Or, if the code is still needed, is there a testcase we could add?
OK. I agree that sign-extension makes no sense here (integer constants
are always nonnegative).
--
Joseph S.
GCC's c99status.html seem persistently to confuse people into thinking the
state of C99 support is worse than it is, by listing things as "Missing"
or "Broken" when in fact what's missing or broken isn't needed to
implement C99 but is some optional extra for ideal support, or is only
broken or
> The PIC register setup code is emitted after NOTE_INSNS_FUNCTION_BEG,
> because it uses the insert_insn_on_edge mechanism, and the corresponding
> insertion in cfgexpand.c:gimple_expand_cfg takes care to insert the code
> after the parm_birth_insn:
> ...
> /* Avoid putting insns befor
This patch adds some more optimisations to the wi:: comparison functions.
It uses the:
#define CONSTANT(X) (__builtin_constant_p (X) && (X))
idiom that was mentioned before, except that I thought CONSTANT would be
too easily confused with CONSTANT_P, so I went for CAN_TELL instead.
Better names
PRED_NORETURN seems a better match; not that I see anything in
the current source that actually treats them differently other
than generating them, but my grep-fu may be weak and certainly
my crystall-ball-fu is.
After testing (no regressions compared to r204080 before the
breakage), committed.
Until now, eq_p and ne_p have enforced the same argument rules as things
like addition, while order comparisons like lts_p have treated the two
arguments as independent and signed. Richard, I think you said on IRC
that you thought lts_p should behave like the others. E.g. lts_p on two
trees or tw
Hi,
pinging this patch of mine, sent beginning of September:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01435.html
Just checked that it still applies cleanly and passes testing.
Thanks!
Paolo.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
== Administrivia ==
This is my first patch. I have emailed in the signed copyright transfer
documents already. Several versions of this patch have been sent to
the mailing list already. I believe that I have incorporated all
comments into the attac
interpret_integer has:
integer = cpp_interpret_integer (parse_in, token, flags);
integer = cpp_num_sign_extend (integer, options->precision);
if (integer.overflow)
*overflow = OT_OVERFLOW;
where options->precision is the precision of (u)intmax_t. Looking at
the implementation of cpp_nu
> -Original Message-
> From: Joey Ye [mailto:joey.ye...@gmail.com]
> Sent: Monday, October 21, 2013 6:31 AM
> To: Vladimir Simonov; Ian Lance Taylor; d...@redhat.com
> Vladimir,
>
> I found no more issue on patch itself. But ChangeLogs are missing.
> Please refer to format in /include/Cha
Ping.
Original submission at http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00903.html .
This patch fixes a regression of 174 tests in the gdb testsuite for
arm-linux-gnueabi with -fPIC (or arm-linux-androideabi) caused by the fix for
PR47028.
The fix for PR47028 made sure that insertions on the s
On 10/22/2013 02:28 PM, Ed Smith-Rowland wrote:
I think this is pretty easy - gnu::deprecated has the same semantics.
Since we decided to have this now, we should also update the docs, thus
htdocs/projects/cxx1y.html (which normally would link
htdocs/gcc-4.9/changes.html, thus a line or so ther
Early *PING*
Tobias Burnus wrote:
A rather simple patch, which tries to implement Fortran 2008's C1116
(see also PR for the wording).
While creating the patch, I found a reject-valid issue, which is now
tracked as PR fortran/58857.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
30 matches
Mail list logo