On 07/01/14 23:23, Richard Biener wrote:
> On Tue, 7 Jan 2014, Kugan wrote:
[snip]
> Note that VIEW_CONVERT_EXPR is wrong here. I think you are
> handling this wrong still. From a quick look you want to avoid
> the actual promotion for
>
> reg_1 =
>
> when reg_1 is promoted and thus
On Sat, Jan 4, 2014 at 2:34 AM, Gerald Pfeifer wrote:
> Ilya Tocar wrote:
Why not -march=broadwell instead?
>>Done.
>
> Mind updating the release notes with these changes? Let me know if you need
> any pointers or help.
>
It is included in
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg0191
On Fri, Jan 3, 2014 at 5:20 AM, Gerald Pfeifer wrote:
> "H.J. Lu" wrote:
>>This patch adds Intel microarchitecture changes to GCC 4.9
>>changes.html.
>>OK to install?
>
> Okay, modulo the fix Bernhard noted.
Updated and checked in.
Thanks.
--
H.J.
On 12/20/13 13:44, Jeff Law wrote:
On 12/20/13 10:25, Jakub Jelinek wrote:
Yes. So my suggestion actually was not correct for that:
&& !reg_overlap_mentioned_p (dest, XEXP (src, 0))
because the first extension above has r1:SI and r2:DI which don't
overlap, only r1:DI and r2:DI overlap. So i
On 01/07/14 01:08, Steven Bosscher wrote:
On Tuesday, January 7, 2014, Jeff Law wrote:
On 12/24/13 13:19, Steven Bosscher wrote:
For GCC 4.10
we should define what behavior should result from
builtin_unreachable
(Should it trap? Can it be optimized away afte
On 01/07/14 06:57, Richard Biener wrote:
On Mon, Jan 6, 2014 at 6:24 PM, Jeff Law wrote:
On 01/02/14 19:31, dxq wrote:
hi,
In hw-doloop.c, is there a memory leak?
valgrind checking shows:
==18622== 1,479,296 bytes in 364 blocks are definitely lost in loss record
559 of 559
==18622==at
On Tue, Jan 7, 2014 at 7:42 PM, Andrew MacLeod wrote:
> On 01/07/2014 06:47 PM, Xinliang David Li wrote:
>>
>> A related question. I have not followed the header file restructuring
>> discussion. Is there a documentation on header file structure and how
>> they are organized? In a new .c file, si
On 01/07/2014 06:47 PM, Xinliang David Li wrote:
A related question. I have not followed the header file restructuring
discussion. Is there a documentation on header file structure and how
they are organized? In a new .c file, simply including gimple.h would
require many rounds of iterations to
The attached change is more a work around than a true fix.
Occasionally with 4.8 and 4.9, there is a reload problem with 14-bit
register offsets. The problem occurs
when both the offset and the register need reloading. It occurs when
the register is equivalent to a
SYMBOL_REF and the insn i
On 1/7/2014 8:46 PM, Andrew Pinski wrote:
Correctness over speed is better. I am sorry GCC is the only one
which gets it correct here. If people don't like there is a flag to
disable it.
Obviously in a case like this, it is the programmer who should
be able to decide between fast-and-accepta
On Thu, Nov 14, 2013 at 11:12 AM, Xinliang David Li wrote:
> On Thu, Nov 14, 2013 at 10:17 AM, Andrew Pinski wrote:
>> On Thu, Nov 14, 2013 at 8:25 AM, Xinliang David Li
>> wrote:
>>> Can we revisit the decision for this? Here are the reasons:
>>>
>>> 1) It seems that the motivation to make C++
This patch to libgo changes the os/user package to use the POSIX
functions on Solaris. Bootstrapped and ran os/user testsuite on
x86_64-unknown-linux-gnu and Solaris. Committed to mainline. This
fixes PR 59430.
Ian
diff -r 5917b9bd0ed0 libgo/Makefile.am
--- a/libgo/Makefile.am Tue Jan 07 16:42
This libgo patch changes the support for systems that use select for
network polling to not allocate all the fd_sets on the stack. That was
causing threads to run out of stack space, as described in PR 59433.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu after
hacking it to use sel
On Tue, Jan 7, 2014 at 4:05 PM, Marcus Shawcroft
wrote:
>
> On 7 Jan 2014, at 23:10, Andrew Pinski wrote:
>
>> On Tue, Dec 4, 2012 at 2:31 AM, James Greenhalgh
>> wrote:
>>>
>>> Hi,
>>>
>>> This patch adds support for Vector Shuffle style operations
>>> through support for TARGET_VECTORIZE_VEC_P
On Tue, 2014-01-07 at 22:18 +, Joseph S. Myers wrote:
> On Tue, 7 Jan 2014, Bill Schmidt wrote:
>
> > Yes, sorry for not being more clear. This is indeed for interpretation
> > of element numbers in Altivec intrinsics such as vec_splat, vec_extract,
> > vec_insert, and so forth. By default t
A related question. I have not followed the header file restructuring
discussion. Is there a documentation on header file structure and how
they are organized? In a new .c file, simply including gimple.h would
require many rounds of iterations to find missing headers via trial
(compilation) and er
On Tue, Dec 4, 2012 at 2:31 AM, James Greenhalgh
wrote:
>
> Hi,
>
> This patch adds support for Vector Shuffle style operations
> through support for TARGET_VECTORIZE_VEC_PERM_CONST_OK and
> the vec_perm and vec_perm_const standard patterns.
>
> In this patch we add the framework and support for t
On 7 January 2014 21:12, François Dumont wrote:
> I saw on another thread that 4.9 release was getting closer. Applying this
> patch sounds like a good idear for this release.
>
> Any feedback ?
Yes, it's coming :-)
I imagine most of us have been on holiday and are just getting back to
speed, and
On Tue, 7 Jan 2014, Bill Schmidt wrote:
> Yes, sorry for not being more clear. This is indeed for interpretation
> of element numbers in Altivec intrinsics such as vec_splat, vec_extract,
> vec_insert, and so forth. By default these will match array element
> order for the target endianness. Bu
On Tue, 2014-01-07 at 21:51 +, Joseph S. Myers wrote:
> On Tue, 7 Jan 2014, Bill Schmidt wrote:
>
> > +@item -maltivec=be
> > +@opindex maltivec=be
> > +Generate Altivec instructions using big-endian element order,
> > +regardless of whether the target is big- or little-endian.
> > +
> > +@i
On Tue, 7 Jan 2014, Bill Schmidt wrote:
> +@item -maltivec=be
> +@opindex maltivec=be
> +Generate Altivec instructions using big-endian element order,
> +regardless of whether the target is big- or little-endian.
> +
> +@item -maltivec=le
> +@opindex maltivec=le
> +Generate Altivec instructions us
On Dec 17, 2013, at 6:06 AM, Vidya Praveen wrote:
> bind_pic_locally is broken for targets that doesn't pass -fPIC/-fpic by
> default [1][2].
Let's give Jakub 2 days to weigh in… If no objections, Ok, though, do see
about adding documentation for it. I kinda would like a simpler interface for
On Tue, Jan 07, 2014 at 09:24:21PM +, Iyer, Balaji V wrote:
> > -Original Message-
> > From: Jason Merrill [mailto:ja...@redhat.com]
> > Sent: Tuesday, January 7, 2014 3:41 PM
> > To: Iyer, Balaji V; 'Jeff Law'; 'Aldy Hernandez'
> > Cc: 'gcc-patches@gcc.gnu.org'; 'r...@redhat.com'; 'Jak
On 01/07/14 06:59, Marek Polacek wrote:
In case we're dealing with (*)[N] types, we should strip the
ARRAY_TYPEs prior to getting the type name. Otherwise we segv, since
the DECL_NAME is NULL.
Regtested on x86_64-linux, ok for trunk?
2014-01-07 Marek Polacek
PR sanitizer/59667
> -Original Message-
> From: Jason Merrill [mailto:ja...@redhat.com]
> Sent: Tuesday, January 7, 2014 3:41 PM
> To: Iyer, Balaji V; 'Jeff Law'; 'Aldy Hernandez'
> Cc: 'gcc-patches@gcc.gnu.org'; 'r...@redhat.com'; 'Jakub Jelinek'
> Subject: Re: [PATCH] _Cilk_for for C and C++
>
> On 12/17
On Jan 7, 2014, at 1:22 PM, Mike Stump wrote:
> On Jan 7, 2014, at 12:21 PM, Vidya Praveen wrote:
>> Ping!
>
> ?
> We're confused, didn't someone say:
See, I was confused… I misread that… sorry.
In the case of a static anonymous union we have a decl with no DECL_NAME
(just a DECL_ASSEMBLER_NAME), and write_guarded_name shouldn't crash.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 0d626f236f9daf2891362c17db1220214ab0a64d
Author: Jason Merrill
Date: Thu Jan 2 22:50:11 2014 -05
On Jan 7, 2014, at 12:21 PM, Vidya Praveen wrote:
> Ping!
?
We're confused, didn't someone say:
> Hi Vidya,
>
> > bind_pic_locally is broken for targets that doesn't pass -fPIC/-fpic by
> > default [1][2].
> >
> > One of the suggestions was to have a effective target check called
> > bind_pic_
For an alias template to be considered equivalent to its underlying
class template, it needs to have the same number of template parameters.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit d6edbf20723a2e43f9f0e63c0a929bfb3ef24e69
Author: Jason Merrill
Date: Thu Jan 2 23:04:48 2014 -0500
I saw on another thread that 4.9 release was getting closer. Applying
this patch sounds like a good idear for this release.
Any feedback ?
On 12/27/2013 07:27 PM, François Dumont wrote:
Hi
Here is a patch to fix an issue in normal mode during the move
assignment. The destination vector
On 01/07/14 14:06, Andrew Pinski wrote:
On Tue, Jan 7, 2014 at 12:55 PM, Jeff Law wrote:
On 01/07/14 09:16, Bernd Schmidt wrote:
This is PR56791. The address inside of an autoinc is reloaded, and the
autoinc is reloaded, but the reload insns are emitted in the wrong order.
As far as I can te
On Tue, Jan 7, 2014 at 12:55 PM, Jeff Law wrote:
> On 01/07/14 09:16, Bernd Schmidt wrote:
>>
>> This is PR56791. The address inside of an autoinc is reloaded, and the
>> autoinc is reloaded, but the reload insns are emitted in the wrong order.
>>
>> As far as I can tell, this is because find_relo
Hi,
This patch adds flavors of the -maltivec option that allow explicit
specification of vector element order. This is independent of the
target endianness in effect. The primary use of this is to allow
specifying big-endian vector element order when targeting a
little-endian processor, which ai
On 01/07/14 09:16, Bernd Schmidt wrote:
This is PR56791. The address inside of an autoinc is reloaded, and the
autoinc is reloaded, but the reload insns are emitted in the wrong order.
As far as I can tell, this is because find_reloads_address_1 has two
methods of pushing a reload for an autoinc
Jakub Jelinek writes:
> On Mon, Jan 06, 2014 at 10:27:06AM +, Richard Sandiford wrote:
>> Of course, IMO, the cleanest fix would be to use switchable targets
>> for i386...
>
> The following patch does that, bootstrapped/regtested on x86_64-linux and
> i686-linux.
Neat, thanks. Looks like it
On 12/17/2013 07:21 PM, Iyer, Balaji V wrote:
The reason why I store it in OMP_FOR_CLAUSE is because OMP clauses cannot occur
in _Cilk_for. So adding a new clause seem to be an overkill IMHO. I need a
place to store the grain value and so I chose this spot.
But code expects OMP_FOR_CLAUSES to
Ping!
On Tue, Dec 17, 2013 at 02:06:13PM +, Vidya Praveen wrote:
> Hello,
>
> bind_pic_locally is broken for targets that doesn't pass -fPIC/-fpic by
> default [1][2].
>
> One of the suggestions was to have a effective target check called
> bind_pic_locally_ok which checks if bind_pic_locall
On Mon, Jan 06, 2014 at 10:27:06AM +, Richard Sandiford wrote:
> Of course, IMO, the cleanest fix would be to use switchable targets
> for i386...
The following patch does that, bootstrapped/regtested on x86_64-linux and
i686-linux. The only problem with the patch is PCH,
+FAIL: 17_intro/head
On Tue, Jan 7, 2014 at 2:26 PM, Bernhard Reutner-Fischer
wrote:
> On 7 January 2014 00:57:47 Patrick Palka wrote:
>
>> On Mon, Jan 6, 2014 at 6:47 PM, Andreas Schwab
>> wrote:
>> > Patrick Palka writes:
>> >
>> >> From what I inferred from the make manual[0], $* is functionally
>> >> equivalent
No comments?
On Sunday 29 December 2013, Allan Sandfeld Jensen wrote:
> The function dispatcher might currently choose functions declared with
> target("arch=ivybridge") on a Sandy Bridge CPU. This happens because the
> function is only detected as sandybridge when generated. The attached patch
>
On Tue, Jan 7, 2014 at 4:02 AM, Paolo Carlini wrote:
> Ideally, I would suggest committing first the improvements in your previous
> patch (by the way, thanks for the numbers!) + the pure bug fixes and
> separate the further performance improvements which have compile-time
> performance implicatio
On 7 January 2014 00:57:47 Patrick Palka wrote:
On Mon, Jan 6, 2014 at 6:47 PM, Andreas Schwab wrote:
> Patrick Palka writes:
>
>> From what I inferred from the make manual[0], $* is functionally
>> equivalent to $(basename $@) in this case.
>
> Or $(base), I think.
>
> Andreas.
>
> --
> Andr
Hi,
I forgot to put the optimize test to the ipa_compute_jump_functions
when fixing PR 57358 which is where it is most necessary. This patch
adds it there and to parm_preserved_before_stmt_p which is also
reachable through ipa_load_from_parm_agg_1 that is also called from
outside of jump function
On 13-12-10 01:47 PM, Ryan Mansfield wrote:
Fixes missing DIR_SEPARATOR if --with-gxx-include-dir configured as
subdir of sysroot.
2013-12-10 Ryan Mansfield
PR preprocessor/56896
* incpath.c (add_standard_paths): Strip trailing sysroot
DIR_SEPARATOR
only if appende
On 07/01/14 17:02, James Greenhalgh wrote:
Ugh.
Now we have two ASM_SPECs which try to handle -mcpu as input.
One of them just returns the input, the other does the cpu rewriting
we actually want, so we can end up with:
gcc -mcpu=cortex-a57.cortex-a53
Getting passed through to the assembl
Hi!
On Fri, Jan 03, 2014 at 11:33:50AM +0100, Jakub Jelinek wrote:
> On Fri, Jan 03, 2014 at 11:24:53AM +0100, Richard Biener wrote:
Anyway, back to the original patch, so do you prefer something like
this instead? I.e. handle only __builtin_unreachable and
__cxa_pure_virtual specially, and not
If no one objects, I will commit this later today.
--joel
On 1/7/2014 10:58 AM, Sebastian Huber wrote:
> v2: Do not override an existing tmake_file in (arm*-*-uclinux*eabi*).
>
> The ARM changes are already approved:
>
> http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00254.html
>
> The rest is RTEMS
On 07/01/14 17:02, James Greenhalgh wrote:
>
> Ugh.
>
> Now we have two ASM_SPECs which try to handle -mcpu as input.
>
> One of them just returns the input, the other does the cpu rewriting
> we actually want, so we can end up with:
>
> gcc -mcpu=cortex-a57.cortex-a53
>
> Getting passed thr
Ugh.
Now we have two ASM_SPECs which try to handle -mcpu as input.
One of them just returns the input, the other does the cpu rewriting
we actually want, so we can end up with:
gcc -mcpu=cortex-a57.cortex-a53
Getting passed through to the assembler as:
as -mcpu=cortex-a57 -mcpu=cortex-a57
v2: Do not override an existing tmake_file in (arm*-*-uclinux*eabi*).
The ARM changes are already approved:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00254.html
The rest is RTEMS specific.
gcc/ChangeLog
2014-01-07 Sebastian Huber
* config.gcc (*-*-rtems*): Add t-rtems to tmake_fi
Hi,
This patch is to sync up include/longlong.h with its glibc peer after
the proposed change here:
http://sourceware.org/ml/libc-alpha/2014-01/msg00114.html
The patch defines a number of macros in stdlib/longlong.h to use GCC
builtins __builtin_clz* to implement the __clz* and __ctz* functi
Hello,
Ping...
We still need a decision how to fix this.
There are two alternative patches:
1. My latest proposal: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01675.html
2. Eric's latest proposal:
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01667.html
Thanks
Bernd.
This fixes a problem identified by Chung-Lin. Once reload is done, all
equivalencing insns for pseudos that didn't get a hard reg but could be
eliminated using their REG_EQUIV are deleted. However, we still can
produce reloads and reload insns for them in certain cases, leading to
unnecessary s
This is PR56791. The address inside of an autoinc is reloaded, and the
autoinc is reloaded, but the reload insns are emitted in the wrong order.
As far as I can tell, this is because find_reloads_address_1 has two
methods of pushing a reload for an autoinc, one of them using the
previously ide
On 01/05/2014 05:10 PM, Teresa Johnson wrote:
On Sun, Jan 5, 2014 at 3:39 AM, Bernd Schmidt wrote:
I have a different patch which I'll submit next week after some more
testing. The assert in cfgrtl is unnecessarily broad and really only needs
to trigger if -freorder-blocks-and-partition; there'
On Tue, 7 Jan 2014, Jakub Jelinek wrote:
> On Tue, Jan 07, 2014 at 03:54:56PM +0100, Richard Biener wrote:
> >
> > This fixes PR59471 by properly gimplifying
> >
> > VIEW_CONVERT_EXPR(BIT_FIELD_REF > long unsigned int>(x), 64, 0>)
> >
> > to use separate stmts for the VIEW_CONVERT_EXPRs.
> >
Hi Alan,
This issue is not yet resolved, in the moment this cross-compiler issue looks
like a regression.
But I have tried your follow-up patches, and they make sense for me:
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01149.html
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01544.html
How c
On 07/01/14 15:09, Yufeng Zhang wrote:
> Hi,
>
> The patch fixes an ICE in gcc/config/arm/arm.c:arm_expand_neon_args ().
> When the destination address for vst1q_lane_u64 is not aligned,
> calling expand_normal will get a REG, which is not expected by
> arm_expand_neon_args, resulting in an a
On Tue, Jan 07, 2014 at 04:12:57PM +0100, Richard Biener wrote:
> > What about if something post gimplification creates VCE(BFR(VCE())) or
> > similar and tries to force_gimple_operand_gsi or similar, then without
> > making the above invalid in the predicates we'd still not try to gimplify it
> >
Hello Everyone,
The attached patch will fix the issue reported in PR 59631. The main
issue was the usage of Cilk spawn [and _Cilk_sync] with -fcilkplus caused an
ICE. This patch should fix that. The issue was only reported for C++ but the
issue exists in C compiler also. This patch fixe
On Tue, Jan 07, 2014 at 03:54:56PM +0100, Richard Biener wrote:
>
> This fixes PR59471 by properly gimplifying
>
> VIEW_CONVERT_EXPR(BIT_FIELD_REF long unsigned int>(x), 64, 0>)
>
> to use separate stmts for the VIEW_CONVERT_EXPRs.
>
> Bootstrap and regtest running on x86_64-unknown-linux-gn
Hi,
The patch fixes an ICE in gcc/config/arm/arm.c:arm_expand_neon_args ().
When the destination address for vst1q_lane_u64 is not aligned,
calling expand_normal will get a REG, which is not expected by
arm_expand_neon_args, resulting in an assertion failure. Now, call
expand_expr with EXPA
This fixes PR59471 by properly gimplifying
VIEW_CONVERT_EXPR(BIT_FIELD_REF (x), 64, 0>)
to use separate stmts for the VIEW_CONVERT_EXPRs.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2014-01-07 Richard Biener
PR middle-end/59471
* gimplify.c (gimpl
This fixes the testcase in PR59630 by properly using (and extending)
the predicates we have to check for builtin calls.
Boostrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2014-01-07 Richard Biener
PR middle-end/59630
* gimple.h (is_gimple_builtin_call): R
This fixes PR59630 by using the appropriate predicates more and
extending them to also verify builtins have matching return type.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2014-01-07 Richard Biener
PR middle-end/59630
* gimple.h (is_gimple_built
This fixes the gimple verification ICEs in the Fortran testsuite.
We can easily make more types equivalent for alias-set computation.
This reduces the amout of differences we introduce for pointers
(following get_alias_set and useless_type_conversion_p).
Queued for testing.
Richard.
2014-01-07
On Tue, Jan 07, 2014 at 01:59:19PM +0100, Florian Weimer wrote:
> gcc.target/i386/pr59099.c fails on x86_64-redhat-linux-gnu with
> --disable-multilib because linking -m32 code is not supported. The
> test case passes in 64-bit mode as well. The other -m32 tests do
> not use dg-do run, so they do
On Tue, Jan 7, 2014 at 1:12 PM, Richard Sandiford
wrote:
> Bernd Edlinger writes:
>>> How about this patch for the big comment?
>>>
>>
>> The comment should say that target_set_current_function()
>> cannot call target_reinit() because:
>>
>> target_reinit()=>lang_dependent_init_target()
>> =>init
In case we're dealing with (*)[N] types, we should strip the
ARRAY_TYPEs prior to getting the type name. Otherwise we segv, since
the DECL_NAME is NULL.
Regtested on x86_64-linux, ok for trunk?
2014-01-07 Marek Polacek
PR sanitizer/59667
* ubsan.c (ubsan_type_descriptor): Cal
On Mon, Jan 6, 2014 at 6:24 PM, Jeff Law wrote:
> On 01/02/14 19:31, dxq wrote:
>>
>> hi,
>>
>> In hw-doloop.c, is there a memory leak?
>>
>> valgrind checking shows:
>>
>> ==18622== 1,479,296 bytes in 364 blocks are definitely lost in loss record
>> 559 of 559
>> ==18622==at 0x4006ADD: mallo
On Sat, Jan 4, 2014 at 9:13 PM, Steve Kargl
wrote:
> On Wed, Jan 01, 2014 at 07:49:16PM -0800, Mike Stump wrote:
>> On Nov 23, 2013, at 12:16 PM, Steve Kargl
>> wrote:
>>> On Sat, Nov 23, 2013 at 11:21:21AM -0800, Mike Stump wrote:
Richi has asked the we break the wide-int patch so that the
On Sat, Jan 4, 2014 at 12:54 AM, Mike Stump wrote:
> I'm wondering if all the outstanding issues you raised with "tree" have been
> addressed. If there are any that remain, let us know.
I hope so ;)
> If they have been, is the original patch (as modified of course by approved
> later work) Ok
On Tue, Jan 07, 2014 at 02:27:04PM +0100, Florian Weimer wrote:
> gimplify_modify_expr_rhs, in the CALL_EXPR case:
>
> if (use_target)
> {
> CALL_EXPR_RETURN_SLOT_OPT (*from_p) = 1;
> mark_addressable (*to_p);
> }
Yeah, that
On 01/07/2014 02:07 PM, Jakub Jelinek wrote:
On Tue, Jan 07, 2014 at 01:51:00PM +0100, Florian Weimer wrote:
+static bool
+stack_protect_return_slot_p ()
+{
+ basic_block bb;
+
+ FOR_ALL_BB_FN (bb, cfun)
+for (gimple_stmt_iterator gsi = gsi_start_bb (bb);
+!gsi_end_p (gsi); gsi_nex
On Thu, Jan 2, 2014 at 6:30 PM, Jan Hubicka wrote:
> Hi,
> those functions are not inlined since they are too large anyway.
> I do not think it is disaster. get_attr_length_1 takes a callback
> that may make it more interesting inlining candidate than others,
> perhaps.
>
> Bootstrapped/regtested
On Tue, Jan 07, 2014 at 01:51:00PM +0100, Florian Weimer wrote:
> +static bool
> +stack_protect_return_slot_p ()
> +{
> + basic_block bb;
> +
> + FOR_ALL_BB_FN (bb, cfun)
> +for (gimple_stmt_iterator gsi = gsi_start_bb (bb);
> + !gsi_end_p (gsi); gsi_next (&gsi))
> + {
> + gim
On Thu, Jan 2, 2014 at 4:02 PM, Bingfeng Mei wrote:
> Hi,
> This patch fixes pr59651. The original regression for pr52943 only appears on
> AArch64 target. I constructed a similar test that also exposes bug on x86-64.
> The problem is that calculation of address range in alias versioning for
>
gcc.target/i386/pr59099.c fails on x86_64-redhat-linux-gnu with
--disable-multilib because linking -m32 code is not supported. The test
case passes in 64-bit mode as well. The other -m32 tests do not use
dg-do run, so they do not exhibit this problem.
Okay for trunk?
--
Florian Weimer / Red
On 01/03/2014 10:43 PM, Florian Weimer wrote:
Lastly, I wonder if gimple_call_return_slot_opt_p is really what you are
after, why does NRV matter here?
The C code we generate does not construct the returned value in place
(presumably because the partial write would be visible with threads,
lon
On Tue, 7 Jan 2014, Kugan wrote:
> ping ?
>
> I have reorganised the last patch and now handling only
> VIEW_CONVERT_EXPR, CONVERT_EXPR and NOP_EXPR. Once it is reviewed and
> necessary changes are made, I will address the other cases as a separate
> patch (when it reaches that stage).
Note that
Bernd Edlinger writes:
>> How about this patch for the big comment?
>>
>
> The comment should say that target_set_current_function()
> cannot call target_reinit() because:
>
> target_reinit()=>lang_dependent_init_target()
> =>init_optabs()=>init_all_optabs(this_fn_optabs);
>
> uses this_fn_optabs
ping ?
I have reorganised the last patch and now handling only
VIEW_CONVERT_EXPR, CONVERT_EXPR and NOP_EXPR. Once it is reviewed and
necessary changes are made, I will address the other cases as a separate
patch (when it reaches that stage).
Thanks,
Kugan
gcc/
+2014-01-07 Kugan Vivekanandaraja
On 07/01/14 09:35, Sebastian Huber wrote:
> Hello Richard,
>
> would you mind having a look at the ARM specific part of this patch:
>
> On 01/06/2014 07:27 PM, Sebastian Huber wrote:
>> 2014-01-06 Sebastian Huber
>>
>> * config.gcc (*-*-rtems*): Add t-rtems to tmake_file.
>> (arm*-*-
> On 01/02/14 10:21, Jan Hubicka wrote:
> >Hi,
> >While looking for -Winline messages I noticed that sched-int.h has self
> >recursive
> >function declared inline. The recursion is tail recursion but we fail to
> >recognize
> >it as such. The problem ist hat there is a local variable link whose
LAST_UPDATED: Updated Mon Jan 6 10:13:16 CET 2014 to revision 206354.
=== acats tests ===
=== acats Summary ===
# of expected passes2320
# of unexpected failures0
Native configuration is x86_64-apple-darwin10.8.0
=== g++ tests
Hello Richard,
would you mind having a look at the ARM specific part of this patch:
On 01/06/2014 07:27 PM, Sebastian Huber wrote:
2014-01-06 Sebastian Huber
* config.gcc (*-*-rtems*): Add t-rtems to tmake_file.
(arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*): Do not
Hi,
On 01/07/2014 07:48 AM, Tim Shen wrote:
I'd prefer to propose another patch that should be commited with this
one, which fix bugs (say _M_flags & regex_constants::icase, not "&&"),
and do more "matcher optimization".
It is now more DRY (_RegexTranslator<>) and efficient, but
takes longer
87 matches
Mail list logo
