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 regex
takes longer to
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 sebastian.hu...@embedded-brains.de
* config.gcc (*-*-rtems*): Add t-rtems to tmake_file.
(arm*-*-eabi* |
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
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 address
is
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 sebastian.hu...@embedded-brains.de
* config.gcc (*-*-rtems*): Add t-rtems to
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
Bernd Edlinger bernd.edlin...@hotmail.de 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
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
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,
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 /
On Thu, Jan 2, 2014 at 4:02 PM, Bingfeng Mei b...@broadcom.com 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
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))
+ {
+ gimple stmt =
On Thu, Jan 2, 2014 at 6:30 PM, Jan Hubicka hubi...@ucw.cz 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.
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);
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 sets
On Sat, Jan 4, 2014 at 12:54 AM, Mike Stump mikest...@comcast.net 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
On Sat, Jan 4, 2014 at 9:13 PM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
On Wed, Jan 01, 2014 at 07:49:16PM -0800, Mike Stump wrote:
On Nov 23, 2013, at 12:16 PM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
On Sat, Nov 23, 2013 at 11:21:21AM -0800, Mike Stump wrote:
On Mon, Jan 6, 2014 at 6:24 PM, Jeff Law l...@redhat.com 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: malloc
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 pola...@redhat.com
PR sanitizer/59667
* ubsan.c
On Tue, Jan 7, 2014 at 1:12 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Bernd Edlinger bernd.edlin...@hotmail.de writes:
How about this patch for the big comment?
The comment should say that target_set_current_function()
cannot call target_reinit() because:
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
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
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 rguent...@suse.de
PR middle-end/59630
*
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 rguent...@suse.de
PR middle-end/59630
* gimple.h
This fixes PR59471 by properly gimplifying
VIEW_CONVERT_EXPRuint8x8_t(BIT_FIELD_REF VIEW_CONVERT_EXPRvector(2)
long unsigned int(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
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
On Tue, Jan 07, 2014 at 03:54:56PM +0100, Richard Biener wrote:
This fixes PR59471 by properly gimplifying
VIEW_CONVERT_EXPRuint8x8_t(BIT_FIELD_REF VIEW_CONVERT_EXPRvector(2)
long unsigned int(x), 64, 0)
to use separate stmts for the VIEW_CONVERT_EXPRs.
Bootstrap and regtest
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
at all
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
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
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
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_EXPRuint8x8_t(BIT_FIELD_REF VIEW_CONVERT_EXPRvector(2)
long unsigned int(x), 64, 0)
to use separate stmts for the
On 01/05/2014 05:10 PM, Teresa Johnson wrote:
On Sun, Jan 5, 2014 at 3:39 AM, Bernd Schmidt ber...@codesourcery.com 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
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
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
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.
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*
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 sebastian.hu...@embedded-brains.de
* config.gcc
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
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
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
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
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
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 rmansfi...@qnx.com
PR preprocessor/56896
* incpath.c (add_standard_paths): Strip trailing sysroot
DIR_SEPARATOR
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
On 7 January 2014 00:57:47 Patrick Palka patr...@parcs.ath.cx wrote:
On Mon, Jan 6, 2014 at 6:47 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Patrick Palka patr...@parcs.ath.cx writes:
From what I inferred from the make manual[0], $* is functionally
equivalent to $(basename $@) in this
On Tue, Jan 7, 2014 at 4:02 AM, Paolo Carlini paolo.carl...@oracle.com 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
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 2:26 PM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
On 7 January 2014 00:57:47 Patrick Palka patr...@parcs.ath.cx wrote:
On Mon, Jan 6, 2014 at 6:47 PM, Andreas Schwab sch...@linux-m68k.org
wrote:
Patrick Palka patr...@parcs.ath.cx writes:
From what I
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:
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_locally will
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
Jakub Jelinek ja...@redhat.com 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.
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
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
On Tue, Jan 7, 2014 at 12:55 PM, Jeff Law l...@redhat.com 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
On 01/07/14 14:06, Andrew Pinski wrote:
On Tue, Jan 7, 2014 at 12:55 PM, Jeff Law l...@redhat.com 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
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 Jan 7, 2014, at 12:21 PM, Vidya Praveen vidyaprav...@arm.com 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
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 ja...@redhat.com
Date: Thu Jan 2
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 ja...@redhat.com
Date: Thu Jan 2
-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/2013
On Jan 7, 2014, at 1:22 PM, Mike Stump mikest...@comcast.net wrote:
On Jan 7, 2014, at 12:21 PM, Vidya Praveen vidyaprav...@arm.com wrote:
Ping!
?
We're confused, didn't someone say:
See, I was confused… I misread that… sorry.
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 pola...@redhat.com
PR
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'; 'Jakub
On Dec 17, 2013, at 6:06 AM, Vidya Praveen vidyaprav...@arm.com 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
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 using
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.
+
+@item
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. But
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, Dec 4, 2012 at 2:31 AM, James Greenhalgh
james.greenha...@arm.com 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
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 these
On Tue, Jan 7, 2014 at 4:05 PM, Marcus Shawcroft
marcus.shawcr...@arm.com wrote:
On 7 Jan 2014, at 23:10, Andrew Pinski pins...@gmail.com wrote:
On Tue, Dec 4, 2012 at 2:31 AM, James Greenhalgh
james.greenha...@arm.com wrote:
Hi,
This patch adds support for Vector Shuffle style operations
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
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
On Thu, Nov 14, 2013 at 11:12 AM, Xinliang David Li davi...@google.com wrote:
On Thu, Nov 14, 2013 at 10:17 AM, Andrew Pinski pins...@gmail.com wrote:
On Thu, Nov 14, 2013 at 8:25 AM, Xinliang David Li davi...@google.com
wrote:
Can we revisit the decision for this? Here are the reasons:
1)
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
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
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
On Tue, Jan 7, 2014 at 7:42 PM, Andrew MacLeod amacl...@redhat.com 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
On 01/07/14 06:57, Richard Biener wrote:
On Mon, Jan 6, 2014 at 6:24 PM, Jeff Law l...@redhat.com 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
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
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 it
On Fri, Jan 3, 2014 at 5:20 AM, Gerald Pfeifer ger...@pfeifer.com wrote:
H.J. Lu hjl.to...@gmail.com 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 Sat, Jan 4, 2014 at 2:34 AM, Gerald Pfeifer ger...@pfeifer.com wrote:
Ilya Tocar tocarip.in...@gmail.com 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
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 the
86 matches
Mail list logo
