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 && curre
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
> > +parsing_default_capturing_generi
> 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
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 taki
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 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 (hard_reg_set
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, th
On Mon, 13 Apr 2015, Rainer Orth wrote:
> Kirill Yukhin writes:
>
> > On 13 Apr 21:16, Rainer Orth wrote:
> >> Kirill Yukhin writes:
> >>
> >> > Hello Rainer,
> >> > On 08 Apr 15:27, Rainer Orth wrote:
> >> >> Ok for mainline?
> >> >
> >> > Patch is ok, thanks!
> >>
> >> Thanks. How about th
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, 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 buil
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-trappi
On Thu, Apr 9, 2015 at 12:10 PM, Yvan Roux wrote:
> Hi
>
> On 7 April 2015 at 22:02, Yvan Roux wrote:
>> On 7 April 2015 at 21:33, Jakub Jelinek wrote:
>>> On Tue, Apr 07, 2015 at 09:28:51PM +0200, Yvan Roux wrote:
validation is ongoing, but here is my attempt to add this testcase,
doe
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 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.
Moreov
On Mon, 13 Apr 2015, Jonathan Wakely wrote:
I don't have a preference, but I think the forward declarations should
work without problems. 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 new ver
On April 14, 2015 1:36:14 AM GMT+02:00, 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
>
On 14 April 2015 at 10:19, Ramana Radhakrishnan
wrote:
> On Thu, Apr 9, 2015 at 12:10 PM, Yvan Roux wrote:
>> Hi
>>
>> On 7 April 2015 at 22:02, Yvan Roux wrote:
>>> On 7 April 2015 at 21:33, Jakub Jelinek wrote:
On Tue, Apr 07, 2015 at 09:28:51PM +0200, Yvan Roux wrote:
> validation i
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.
Jaku
On Tue, Apr 14, 2015 at 9:33 AM, Jakub Jelinek 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 enough p
On Mon, Apr 13, 2015 at 11:37 PM, Marc Glisse 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
>>> wrote:
Hello,
just a simple pattern for match.pd. I am ignoring the issue of w
On 14 April 2015 at 10:35, Ramana Radhakrishnan
wrote:
> On Tue, Apr 14, 2015 at 9:33 AM, Jakub Jelinek 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
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
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
* c
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. includes bits/stl_iterator_base_funcs.h
so if the forward declarations didn't match the definitions for some
rea
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 ad10c021b751c515a2e20c74661594a5e99d
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.
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
>>
>> * execute_dwarf2_frame (dw_frame_pointer_regnum): Reinitialize for each
>> function.
>
> It's tempting
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', h
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
* config/arm/arm.c (gen_ldm_seq): Use std::sort instead of sorti
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 get_last_bb_insn
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 sh_
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, wrote:
I have a patch to get gccgo to work on cr
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
> +
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 a
>
> 2015-04-13 Martin Liska
>
> * 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.
> ---
> gcc/
Marcus Shawcroft wrote:
On 30 January 2015 at 12:09, Alan Lawrence 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, vst1_lane_f64,
vst1_lane
On Tue, Apr 14, 2015 at 6:14 AM, Lynn A. Boger
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 03/17/2015 01:27 PM
On Wed, 8 Apr 2015 17:58:56 +0300
Ilya Verbin 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 functions:
> >
> >
On 04/14/2015 03:45 PM, Jan Hubicka wrote:
2015-04-13 Martin Liska
* 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 v
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 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 (flag_chec
2015-02-11 18:18 GMT+00:00 Jiong Wang :
> 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 :
however, since i am a nice person
loop-invariant solves the DF_UD_CHAIN which builds a data
On Tue, Mar 31, 2015 at 11:33 AM, Jack Howarth wrote:
> On Tue, Mar 31, 2015 at 1:00 PM, H.J. Lu wrote:
>> On Tue, Mar 31, 2015 at 9:39 AM, Jack Howarth
>> wrote:
>>> On Tue, Mar 31, 2015 at 12:14 PM, H.J. Lu wrote:
On Tue, Mar 31, 2015 at 9:09 AM, Jack Howarth
wrote:
> H.J.,
>
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 a
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
__verbose_termin
>
> 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
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 x
Hi!
On Tue, 14 Apr 2015 15:15:02 +0100, Julian Brown
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 being tested, and me
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 r
Hi!
On Tue, 14 Apr 2015 15:15:02 +0100, Julian Brown
wrote:
> On Wed, 8 Apr 2015 17:58:56 +0300
> Ilya Verbin 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 -DACC_MEM_SHARED=0 execution test
> > F
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
> Is this ok for trunk now?
Yes.
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
Autho
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 t
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 can
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 should
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 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. However, thanks for
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 acceptab
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 %code
On Tue, Apr 14, 2015 at 9:30 AM, Steve Ellcey 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 between
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 IIRC.
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 all
> OK to apply ?
Ok!
> 2015-04-14 Nick Clifton
>
> * 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 zero extendi
On April 14, 2015 6:27:14 PM GMT+02:00, Aldy Hernandez 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 DIEs for a
On Tue, Apr 14, 2015 at 9:58 AM, Jeff Law 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, but
Hello!
The attached patch introduces LEGACY_INT_REG_P predicate to simplify
print_reg function.
2015-04-14 Uros Bizjak
* config/i386/i386.h (LEGACY_INT_REG_P): New define.
(LEGACY_INT_REGNO_P): Ditto.
(GENERAL_REGNO_P): Use LEGACY_INT_REGNO_P.
(ANY_MASK_REG_P): Remove.
(BN
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 t
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 i
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
futur
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', h
On 2015-04-14 8:26, Jakub Jelinek wrote:
I'd say best would be to just use separate ifs with return false.
Done.
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', h
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.
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. I
On Mon, Apr 13, 2015 at 2:49 PM, Kyrill Tkachov 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.
>
> Ok for tr
On Tue, Apr 14, 2015 at 1:37 PM, Kyrill Tkachov 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 <=
On Mon, Feb 9, 2015 at 12:34 PM, Christian Bruel 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
> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02458.html
> https://gcc.
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 Thu, Mar 5, 2015 at 1:34 PM, Xingxing Pan 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 widen-sum patt
PING.
On Fri, Mar 6, 2015 at 9:31 AM, H.J. Lu wrote:
> PING. I am enclosing the patch here for review.
>
> On Wed, Feb 11, 2015 at 8:47 AM, H.J. Lu wrote:
>> PING.
>>
>> On Wed, Jan 28, 2015 at 8:05 AM, H.J. Lu wrote:
>>> PING.
>>>
>>> On Tue, Jan 13, 2015 at 3:25 PM, H.J. Lu wrote:
On T
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 compil
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 o
* 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 fil
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
Date: Tue Jan 27 11:09:01 2015 -0500
* pt.c
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.
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_3 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65139
2015-04-14 18:24 GMT+01:00 Jeff Law :
> 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. An
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', h
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:
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 d
Hello world,
here is the newest version of the matmul patch. This also honors
the -finline-matmul-limit= option, either at compile-time or at
run-time.
Question: What to do about run-time bounds checking? I am leaning
towards making an intrinsic subroutine which can not be called
by the user, a
94 matches
Mail list logo
