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
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
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:
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
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
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
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
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
Date: Tue Jan 27 11:09:01 2015 -0500
* pt.c
* 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
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
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
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 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
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 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.
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, 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
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 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', 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 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
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
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
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
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
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
> 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
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
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.
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
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 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
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 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 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
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
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
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
> Is this ok for trunk now?
Yes.
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
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
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:
> 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
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
>
> 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
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
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
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.,
>
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 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
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 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
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 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
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
>
> 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/
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
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
> +
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
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_
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
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
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,
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
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
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.
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
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
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 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
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 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 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 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 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 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 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 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
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 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
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
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 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
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 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,
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) ?
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
> 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
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
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
94 matches
Mail list logo
