On Fri, Apr 10, 2015 at 04:31:34AM +0100, Adam Butcher wrote:
+/* Return true iff our current scope is a default capturing generic lambda
+ defined within a template. */
+
+bool
+parsing_default_capturing_generic_lambda_in_template (void)
+{
+ if (processing_template_decl
Hello.
As originally reported by Andi Kleen, following patch fix memory leaks that can
be seen in IPA ICF and IPA CP.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Moreover, with patch applied, we can build Firefox and Linux kernel on
ppc64le-linux-gnu.
Ready for both
On Tue, 14 Apr 2015, Jan Hubicka wrote:
Hi,
while looking on a testcase, i noticed that for simple code
if (param 6.0)
BB1;
else
BB2;
the inline predicates currectly determine (param 6.0) predicate
for BB1, but they give (true) predicate to BB2 unless -fno-trapping-math is
On Thu, Apr 9, 2015 at 12:10 PM, Yvan Roux yvan.r...@linaro.org wrote:
Hi
On 7 April 2015 at 22:02, Yvan Roux yvan.r...@linaro.org wrote:
On 7 April 2015 at 21:33, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Apr 07, 2015 at 09:28:51PM +0200, Yvan Roux wrote:
validation is ongoing, but here
On 14 April 2015 at 10:19, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On Thu, Apr 9, 2015 at 12:10 PM, Yvan Roux yvan.r...@linaro.org wrote:
Hi
On 7 April 2015 at 22:02, Yvan Roux yvan.r...@linaro.org wrote:
On 7 April 2015 at 21:33, Jakub Jelinek ja...@redhat.com wrote:
On Tue,
On 10 Apr 03:15, Jan Hubicka wrote:
References are not streamed out for nodes which are referenced in a
partition but don't belong to it ('continue' condition in output_refs
loop).
Yeah, but it already special cases aliases (because we now always preserve
IPA_REF_ALIAS link
in the
On 14/04/15 10:24 +0200, Marc Glisse wrote:
On Mon, 13 Apr 2015, Jonathan Wakely wrote:
I don't have a preference, but I think the forward declarations should
work without problems. list includes bits/stl_iterator_base_funcs.h
so if the forward declarations didn't match the definitions for
On Tue, Apr 14, 2015 at 09:16:32AM +0200, Marek Polacek wrote:
On Fri, Apr 10, 2015 at 04:31:34AM +0100, Adam Butcher wrote:
+/* Return true iff our current scope is a default capturing generic lambda
+ defined within a template. */
+
+bool
From: Jeff Law [mailto:l...@redhat.com]
Sent: Monday, April 13, 2015 8:48 PM
Thomas,
I know there were several followups between Steven and yourself.
With
stage1 now open, can you post a final version and do a final
bootstrap/test with it?
Sure, I'm testing it right now. Sorry for not
This fixes PR65758 - the patch is mostly a split-out from the
patch unifying CCP and copyprop where I noticed the bitmask
comparisons against -1 are not working as expected and thus we
get invalid CONSTANT - CONSTANT transitions because that first
CONSTANT should have been VARYING...
Bootstrap
On Mon, Apr 13, 2015 at 11:37 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Mon, 13 Apr 2015, Marc Glisse wrote:
On Mon, 13 Apr 2015, Richard Biener wrote:
On Mon, Apr 13, 2015 at 2:23 PM, Marc Glisse marc.gli...@inria.fr
wrote:
Hello,
just a simple pattern for match.pd. I am ignoring
Hi Jeff,
Thanks for looking at this.
On 13/04/15 19:18, Jeff Law wrote:
On 03/16/2015 04:12 AM, Kyrill Tkachov wrote:
Hi all,
Eyeballing the mult_by_coeff_cost function I think it has a typo/bug.
It's supposed to return the cost of multiplying by a constant 'coeff'.
It calculates that by
Hi,
here is the patch that restore the assertion and swap its arguments as
discussed in the PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65729
Bootstrapped and regtested on x86_64, cross built and regtested on
i686, aarch64, arm and armeb. Is it ok for trunk (maybe after 5.1 is
released) ?
On Mon, 13 Apr 2015, Jonathan Wakely wrote:
I don't have a preference, but I think the forward declarations should
work without problems. list includes bits/stl_iterator_base_funcs.h
so if the forward declarations didn't match the definitions for some
reason we'd know right away.
Here is a
On 04/14/2015 10:18 AM, Jakub Jelinek wrote:
On Tue, Apr 14, 2015 at 10:14:06AM +0200, Martin Liška wrote:
As originally reported by Andi Kleen, following patch fix memory leaks that can
be seen in IPA ICF and IPA CP.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
On Tue, Apr 14, 2015 at 9:33 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Apr 14, 2015 at 10:32:16AM +0200, Yvan Roux wrote:
The issue is more related to armv6 than M profile, but if it is widely
tested as well I can just commit the torture test if it's ok for
Jakub.
If it is tested by
On 14 April 2015 at 10:35, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On Tue, Apr 14, 2015 at 9:33 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Apr 14, 2015 at 10:32:16AM +0200, Yvan Roux wrote:
The issue is more related to armv6 than M profile, but if it is widely
tested as
On Tue, Apr 14, 2015 at 10:08:24AM +0200, Yvan Roux wrote:
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -1656,8 +1656,7 @@ prohibited_class_reg_set_mode_p (enum reg_class rclass,
{
HARD_REG_SET temp;
- // ??? Is this assert right
- // lra_assert
Hi all,
The description of the relevant code at
https://gcc.gnu.org/ml/gcc-patches/2004-08/msg01590.html is helpful for this...
The mult synthesis code at some points assumes that a shift operation can
execute in parallel with previous steps
in the algorithm on superscalar machines. However,
On Mon, 13 Apr 2015, Rainer Orth wrote:
Kirill Yukhin kirill.yuk...@gmail.com writes:
On 13 Apr 21:16, Rainer Orth wrote:
Kirill Yukhin kirill.yuk...@gmail.com writes:
Hello Rainer,
On 08 Apr 15:27, Rainer Orth wrote:
Ok for mainline?
Patch is ok, thanks!
Thanks.
On April 14, 2015 1:36:14 AM GMT+02:00, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
while looking on a testcase, i noticed that for simple code
if (param 6.0)
BB1;
else
BB2;
the inline predicates currectly determine (param 6.0) predicate
for BB1, but they give (true) predicate to BB2
On Tue, Apr 14, 2015 at 10:32:16AM +0200, Yvan Roux wrote:
The issue is more related to armv6 than M profile, but if it is widely
tested as well I can just commit the torture test if it's ok for
Jakub.
If it is tested by enough people, just the execute.exp test is ok of course.
Jakub
Hello,
Patch in the bottom fixes PR target/65744
by adding type conversions to x86 intrinsics.
Note, that this patch is not converts type of
masking to unsigned for built-ins.
If no objections - I'll commit it tomorrow and
prepare backport patch for 4.9.x
gcc/
PR target/65744
*
On Tue, Apr 14, 2015 at 10:14:06AM +0200, Martin Liška wrote:
As originally reported by Andi Kleen, following patch fix memory leaks that
can
be seen in IPA ICF and IPA CP.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Moreover, with patch applied, we can build
committed, thanks
sorry for the delay.
Christian
On 10/14/2014 08:25 PM, Richard Henderson wrote:
On 10/14/2014 06:02 AM, Christian Bruel wrote:
2014-09-23 Christian Bruel christian.br...@st.com
* execute_dwarf2_frame (dw_frame_pointer_regnum): Reinitialize for each
function.
On 13/04/15 17:22 +0100, Jonathan Wakely wrote:
On 10/04/15 21:52 +0100, Jonathan Wakely wrote:
I'm sure this still isn't complete, but at least it now contains
information for releases since 4.5, and documents any deprecations.
Committed to trunk.
commit
Hello,
The documentation for the __sync builtins calls them legacy but doesn't clearly
say that the __atomic builtins should be prefered. This patch adds a statement
to that effect. It also simplifies some of the text and weakens a suggestion of
future change in the the __syncs behaviour.
So I've been successful with funneling
class X { public: X(int r) : res(r) {} int get() { return res; }
private: int res; };
int main() { X x(0); return x.get (); }
all the way through LTO and gdb recognizing all the nice early debug info
for X:
gdb ./a.out
(gdb) start
Temporary breakpoint 1
2015-04-13 Martin Liska mli...@suse.cz
* ipa-cp.c (ipcp_driver): Release prev_edge_clone.
* ipa-icf.c (sem_item_optimizer::subdivide_classes_by_sensitive_refs):
Release symbol_compare_collection.
* ipa-reference.c: Add TODO that a vector should be released.
---
On Mon, 2015-04-13 at 23:18 -0600, Jeff Law wrote:
But I don't see how using alloca ensures that you're going to have an
aligned spill slot. It can get you an aligned stack pointer, but that
doesn't ensure alignment of any particular spill slot IIRC.
It doesn't. I found a big hole in my
On 14 April 2015 at 14:45, Alan Lawrence alan.lawre...@arm.com wrote:
Assuming/hoping that this patch is proposed for new stage 1 ;),
IIRC the approach of using __builtin_aarch64_im_lane_boundsi doesn't
work (results in double error messages), and so the patch needs to be
rewritten to avoid it.
OK to apply ?
Ok!
2015-04-14 Nick Clifton ni...@redhat.com
* config/rl78/rl78.c (rl78_expand_prologue): Mark large stack
decrement instruction as being frame related.
(rl78_print_operand_1): Handle 'p' modifier to add +0 to HL
based addresses.
If
On April 14, 2015 6:27:14 PM GMT+02:00, Aldy Hernandez al...@redhat.com wrote:
On 04/14/2015 06:35 AM, Richard Biener wrote:
Richard, thank you so much for working on this. It's good to see your
progress here.
the late dwarf generation is a bit awkward because it insists on
creating
type
On 2015-04-14 8:26, Jakub Jelinek wrote:
I'd say best would be to just use separate ifs with return false.
Done.
On 05/09/2014 08:56 PM, Jason Merrill wrote:
I don't think we want cp_parser_class_name to find enums; better I think
to change cp_parser_qualifying_entity to use something other than
cp_parser_type_name to look for enums.
I had a go at this myself, and it was problematic, so I ended up using
OK, I'm going to commit it to trunk.
Thanks, and forgot to comment. I do not consider this critical for 5.1.
We may want to backport for 5.2.
Honza
Hi!
On Tue, 14 Apr 2015 15:15:02 +0100, Julian Brown jul...@codesourcery.com
wrote:
The other problem is that it appears that the ACC_DEVICE_TYPE
environment variable is not getting set properly on the target for (any
of) the OpenACC tests: this means a lot of the time the wrong plugin
is
You were right: my earlier fix for c/65345 only handled non-float types.
This patch thus handles even the float types. The fix is analogical to the
previous: use create_tmp_var_raw and TARGET_EXPR to avoid ICE.
This only fixes x86 though, other arches will need something similar. You'll
notice
On 04/14/2015 06:35 AM, Richard Biener wrote:
Richard, thank you so much for working on this. It's good to see your
progress here.
the late dwarf generation is a bit awkward because it insists on creating
type DIEs for all sort of contexts when we process scope vars. The type
Types
Hi all,
during further testing of a big Fortran software I encounter two bugs with
class arrays, that are somehow connected to pr60322. I therefore propose an
extended patch for pr60322. Because Paul has already reviewed most the extended
patch, I give you two patches:
1. a full patch, fixing
On 04/14/2015 10:48 AM, Steven Bosscher wrote:
So I think this stage2/3 binary difference is acceptable?
No, they should be identical. If there's a difference, then there's a
bug - which, it seems, you've already found, too.
RIght. And so the natural question is how to fix.
At first glance
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 French team of translators. The file is available at:
http://translationproject.org/latest/gcc/fr.po
(This file, 'gcc-5.1-b20150208.fr.po',
When the libstdc++ is compiled, the compiler sets the std::terminate_handler
function with __verbose_terminate_handler() or std::abort() depending on
_GLIBCXX_HOSTED _GLIBCXX_VERBOSE being true or false.
However, even if we compile with -fno-exceptions, the compiler will use
adjust_temp_type was wrapping a PTRMEM_CST in a NOP_EXPR, which confused
constexpr evaluation. We can avoid this by fixing cp_fold_convert to
properly fold away the conversion.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit a5a7219fc54d6d724a032befea810910cda01fc7
Author: Jason Merrill
On Tue, Apr 14, 2015 at 5:06 PM, Jiong Wang wrote:
but, after some investigation I found gcc actually generate difference
code when debug info enabled because
DEBUG_INSN will affect data flow analysis.
It should not, so that's a bug.
So I think this stage2/3 binary difference is acceptable?
On 04/14/2015 05:11 AM, Matthew Wahab wrote:
Hello,
The documentation for the __sync builtins calls them legacy but doesn't
clearly
say that the __atomic builtins should be prefered. This patch adds a
statement
to that effect. It also simplifies some of the text and weakens a
suggestion of
Hi DJ,
I would like permission to apply this patch to the RL78 backend. It
tidies up a few minor bugs, specifically:
* The prologue instruction to increment the stack pointer by a large
amount was not being marked as frame related.
* The %p operand operator was not using
On Tue, Apr 14, 2015 at 9:30 AM, Steve Ellcey sell...@imgtec.com wrote:
My second question is what do people think about this as a way to
dymanically
align the stack? It seems a lot simpler and more target independent than
what x86 is doing.
My biggest worry is the large disconnect
On Tue, Apr 14, 2015 at 9:58 AM, Jeff Law l...@redhat.com wrote:
On 04/14/2015 10:30 AM, Steve Ellcey wrote:
On Mon, 2015-04-13 at 23:18 -0600, Jeff Law wrote:
But I don't see how using alloca ensures that you're going to have an
aligned spill slot. It can get you an aligned stack pointer,
Hello!
The attached patch introduces LEGACY_INT_REG_P predicate to simplify
print_reg function.
2015-04-14 Uros Bizjak ubiz...@gmail.com
* config/i386/i386.h (LEGACY_INT_REG_P): New define.
(LEGACY_INT_REGNO_P): Ditto.
(GENERAL_REGNO_P): Use LEGACY_INT_REGNO_P.
That happens in your patch 2/3/4, which use __builtin_aarch64_im_lane_boundsi,
indeed. Hence I think the SIMD_ARG_STRUCT_LOAD_STORE_LANE_INDEX approach of the
first patch could well be the right way - initially I thought SIMD_ARG... too
heavyweight, but I think I take that back now.
Really I
On 04/14/2015 10:30 AM, Steve Ellcey wrote:
On Mon, 2015-04-13 at 23:18 -0600, Jeff Law wrote:
But I don't see how using alloca ensures that you're going to have an
aligned spill slot. It can get you an aligned stack pointer, but that
doesn't ensure alignment of any particular spill slot
On 2015-04-10 4:31, Adam Butcher wrote:
+parsing_default_capturing_generic_lambda_in_template (void)
I'm wondering whether we should cache this as a bool on the parser.
Currently it is called once per id-expression and will always return the
same result for any given lambda.
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 French team of translators. The file is available at:
http://translationproject.org/latest/gcc/fr.po
(This file, 'gcc-5.1-b20150208.fr.po',
2015-02-11 18:18 GMT+00:00 Jiong Wang jiong.w...@arm.com:
On 11/02/15 14:21, Kenneth Zadeck wrote:
On 02/11/2015 06:20 AM, Jiong Wang wrote:
2014-12-19 15:21 GMT+00:00 Kenneth Zadeck zad...@naturalbridge.com:
however, since i am a nice person
loop-invariant solves the DF_UD_CHAIN
Is this ok for trunk now?
Yes.
The standard says that the nested-name-specifier in a using-declaration
needs to name a base of the class. When we have dependent bases we
can't be sure whether a particular type is a base or not, but we can
certainly complain if name lookup find the current class rather than a base.
Tested
On Tue, Mar 31, 2015 at 11:33 AM, Jack Howarth howarth.at@gmail.com wrote:
On Tue, Mar 31, 2015 at 1:00 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Mar 31, 2015 at 9:39 AM, Jack Howarth howarth.at@gmail.com
wrote:
On Tue, Mar 31, 2015 at 12:14 PM, H.J. Lu hjl.to...@gmail.com wrote:
Hi Guys,
Now that the sources are unfrozen I am applying the patch discussed on
this thread:
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00736.html
It fixes the places where an address offset is computed in the wrong
mode and needs to be converted to the correct mode. Since we
On 10 Apr 03:27, Jan Hubicka wrote:
+ /* We might propagate instrumented function pointer into
+ not instrumented function and vice versa. In such a
+ case we need to either fix function declaration or
+ remove bounds from call statement. */
+ if
With C++ templates and attribute ((aligned)), you can have TYPE_ALIGN
and TYPE_USER_ALIGN set on a type before you know its size, so
layout_type and kin need to respect them if they are already set.
Tested x86_64-pc-linux-gnu. OK for trunk?
commit 9b138ff6e829e73765e7bba75771751c6239e7cc
Hi,
running tests for Asan-bootstrapped GCC, I've noted that tests for
libiberty and libbacktrace fail to link with sanitized libbacktrace.a
and libiberty.a because of missing -static-libasan -fsanitize=address
linker flags. This patch adds necessary flags to provide a linkage of
these tests
On 04/14/2015 04:11 AM, Jakub Jelinek wrote:
On Tue, Apr 14, 2015 at 10:08:24AM +0200, Yvan Roux wrote:
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -1656,8 +1656,7 @@ prohibited_class_reg_set_mode_p (enum reg_class rclass,
{
HARD_REG_SET temp;
- // ??? Is this assert
Hi!
On Tue, 14 Apr 2015 15:15:02 +0100, Julian Brown jul...@codesourcery.com
wrote:
On Wed, 8 Apr 2015 17:58:56 +0300
Ilya Verbin iver...@gmail.com wrote:
I see several regressions:
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_on_device-1.c
-DACC_DEVICE_TYPE_host_nonshm=1
On 03/17/2015 10:15 PM, Jason Merrill wrote:
On 03/17/2015 10:03 PM, Paolo Carlini wrote:
On 03/18/2015 01:11 AM, Jason Merrill wrote:
Are there other places that still need to pass complain to mark_used?
Well, if we are talking about functions getting a tsubst_flags_t and
*not* passing it
Marcus Shawcroft wrote:
On 30 January 2015 at 12:09, Alan Lawrence alan.lawre...@arm.com wrote:
This was posted towards the end of stage 3, a few days before stage 4
started. Is it now too late to ping ?
--Alan
gcc/ChangeLog:
* config/aarch64/arm_neon.h (vst1_lane_f32,
On Tue, Apr 14, 2015 at 6:14 AM, Lynn A. Boger
labo...@linux.vnet.ibm.com wrote:
I got sidetracked with some bug fixes and decided the change for this was
not real small.
Should this be submitted to gofrontend, or to the golang master source?
Let's try it in the master repo. Thanks.
Ian
On Wed, 8 Apr 2015 17:58:56 +0300
Ilya Verbin iver...@gmail.com wrote:
On Wed, Apr 08, 2015 at 15:31:42 +0100, Julian Brown wrote:
This version is mostly the same as the last posted version but has a
tweak in GOACC_parallel to account for the new splay tree
arrangement for target
On 04/14/2015 03:45 PM, Jan Hubicka wrote:
2015-04-13 Martin Liska mli...@suse.cz
* ipa-cp.c (ipcp_driver): Release prev_edge_clone.
* ipa-icf.c (sem_item_optimizer::subdivide_classes_by_sensitive_refs):
Release symbol_compare_collection.
* ipa-reference.c:
On 04/14/2015 05:27 PM, Adam Butcher wrote:
On 2015-04-10 15:57, Adam Butcher wrote:
+ cp_lexer_consume_token (parser-lexer);
Actually there should be two of these as the 'auto' isn't consumed yet.
OK.
Jason
This patch uses clobber with match_scratch instead of earlyclobber for
aarch64_lshr_sisd_or_int_mode3 so that RA can have more freedom in
selecting suitable register, as discussed in
http://thread.gmane.org/gmane.comp.gcc.patches/336162 and reported in
2015-04-14 18:24 GMT+01:00 Jeff Law l...@redhat.com:
On 04/14/2015 10:48 AM, Steven Bosscher wrote:
So I think this stage2/3 binary difference is acceptable?
No, they should be identical. If there's a difference, then there's a
bug - which, it seems, you've already found, too.
RIght. And
This patch syncs zlib.m4 with binutils-gdb and uses AM_ZLIB from zlib.m4
in gcc/configure.ac. OK for trunk?
Thanks.
H.J.
--
config/
* zlib.m4: Sync with binutils-gdb.
gcc/
* Makefile.in (top_srcdir): New.
* configure.ac: Use AM_ZLIB.
* configure: Regeneated.
On Mon, Feb 9, 2015 at 12:34 PM, Christian Bruel christian.br...@st.com wrote:
Hello,
I'd like to ping with a respin of the 7 patches for
the attribute target (thumb,arm) [0-6] :
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02455.html
On 14 April 2015 at 16:17, Federico Lenarduzzi wrote:
When the libstdc++ is compiled, the compiler sets the std::terminate_handler
function with __verbose_terminate_handler() or std::abort() depending on
_GLIBCXX_HOSTED _GLIBCXX_VERBOSE being true or false.
However, even if we compile with
On Thu, Mar 5, 2015 at 1:34 PM, Xingxing Pan xxing...@marvell.com wrote:
Hi,
The expanding of widen-sum pattern always fails. The vectorizer expects the
operands to have the same size, while the current implementation of
widen-sum pattern dose not conform to this.
This patch implements the
PING.
On Fri, Mar 6, 2015 at 9:31 AM, H.J. Lu hjl.to...@gmail.com wrote:
PING. I am enclosing the patch here for review.
On Wed, Feb 11, 2015 at 8:47 AM, H.J. Lu hjl.to...@gmail.com wrote:
PING.
On Wed, Jan 28, 2015 at 8:05 AM, H.J. Lu hjl.to...@gmail.com wrote:
PING.
On Tue, Jan 13,
This patch to the GCC 5 branch fixes PR 65755. This is a conservative
patch for the branch. I will shortly apply a more complete, less
conservative, patch to trunk. This patch simply adds the receiver
type when producing the pkgpath or the reflection string for a type
defined within a method.
On Mon, Apr 13, 2015 at 2:49 PM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
This is an update to
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02706.html,
rebased on top of the new cores that went in since that time.
It's just a refactoring.
Bootstrapped and tested on arm-linux.
On Tue, Apr 14, 2015 at 1:37 PM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
The load/store-multiple expanders reject a number of registers outside of
[2-14]
but the arm_gen_{load,store}_multiple functions that they called down to
have an even
stricter restriction of =
On 14 April 2015 at 13:59, Rainer Orth wrote:
Bootstrapped without regressions on i386-pc-solaris2.1[01] and
sparc-sun-solaris2.1[01] (with as/ld, gas/gld) on both mainline and
gcc-5 branch. Ok for mainline and gcc-5 branch? I suppose the patch is
safe enough even at this point since it only
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 French team of translators. The file is available at:
http://translationproject.org/latest/gcc/fr.po
(This file, 'gcc-5.1-b20150208.fr.po',
Ping?
Now that Stage1 is open, is this OK for trunk.
Thanks,
Kugan
On 26/03/15 18:21, Kugan wrote:
ping?
Thanks,
Kugan
On 17/03/15 12:19, Kugan wrote:
On 17/03/15 03:48, Kyrill Tkachov wrote:
On 16/03/15 13:15, Kugan wrote:
On 16/03/15 23:32, Kugan wrote:
Hi all,
The load/store-multiple expanders reject a number of registers outside of [2-14]
but the arm_gen_{load,store}_multiple functions that they called down to have
an even
stricter restriction of = MAX_LDM_STM_OPS that is = 4. If load_multiple was
called with
a number of regs larger than 4
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 French team of translators. The file is available at:
http://translationproject.org/latest/gcc/fr.po
(This file, 'gcc-5.1-b20150208.fr.po',
The libstdc++-v3 abi_check test is FAILing on Solaris 11 with gld. It
turns out this happens because a elfdump warning (printed to stderr) is
mixed with regular elfdump output. In the case at hand, elfdump warns
.gnu.version_r: zero sh_entsize information, expected 0x1
.gnu.version_d: zero
Hi all,
This patch replaces a manual ascending-order sort by a call to std::sort.
This makes the code simpler and more readable IMHO.
Bootstrapped and tested on arm.
Ok for trunk?
Thanks,
Kyrill
2015-04-14 Kyrylo Tkachov kyrylo.tkac...@arm.com
* config/arm/arm.c (gen_ldm_seq): Use
I got sidetracked with some bug fixes and decided the change for this
was not real small.
Should this be submitted to gofrontend, or to the golang master source?
On 03/17/2015 01:27 PM, Ian Lance Taylor wrote:
On Tue, Mar 17, 2015 at 7:36 AM, labo...@linux.vnet.ibm.com wrote:
I have a patch
On Tue, Apr 14, 2015 at 2:58 PM, Jakub Jelinek wrote:
PR rtl-optimization/65761
* cfgrtl.c (rtl_split_edge): For EDGE_CROSSING split, use
get_last_bb_insn (after) instead of NEXT_INSN (BB_END (after)).
--- gcc/cfgrtl.c.jj 2015-04-12 21:50:18.0 +0200
+++
Hi!
On the testcase from the PR (not suitable for testsuite, as it is
-fprofile-use only with *.gcda required and thus hard to reduce),
we ICE because rtl_split_edge decided to insert a new basic block
in between a tablejump instruction and corresponding jump table.
Fixed by using
* cp/parser.c (cp_parser_simple_type_specifier): Don't synthesize
implicit template parm if 'auto' is a placeholder for trailing return
type.
---
gcc/cp/parser.c | 23 +++
gcc/testsuite/g++.dg/cpp1y/pr65750.C | 12
2
On 2015-04-10 15:57, Adam Butcher wrote:
+ cp_lexer_consume_token (parser-lexer);
Actually there should be two of these as the 'auto' isn't consumed yet.
I noticed that lookup_template_class_1 was duplicating what
coerce_innermost_template_parms does; it should call it instead.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit d82b48765b260fae4d10738128edc720f9b197c3
Author: Jason Merrill ja...@redhat.com
Date: Tue Jan 27 11:09:01 2015
93 matches
Mail list logo
