Hi!
On Thu, 7 Nov 2013 22:10:12 +, "Iyer, Balaji V"
wrote:
> > > * Makefile.def: Add libcilkrts to target_modules. Make libcilkrts
> > > depend on libstdc++ and libgcc.
> > > [...]
> > > * Makefile.in: Added libcilkrts related fields to support
> > > buildin
This fixes PR59038 by reverting the wrong fix for PR58955 and instead
installing the correct fix (fingers crossing).
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-11-07 Richard Biener
PR tree-optimization/59038
PR tree-optimization/58955
On Thu, 7 Nov 2013, Kenneth Zadeck wrote:
> On 11/07/2013 01:07 PM, Richard Sandiford wrote:
> > Kenneth Zadeck writes:
> > > I very strongly disagree with this. The standard needs to be high than
> > > "does it pass the test suite."
> > >
> > > What we are introducing is a case where the progr
Hi,
Here is an updated patch version with no langhook.
Regarding TLS objects issue - I do not think compiler should compensate the
absence of instrumentation in libraries. Compiler should be responsible for
initialization of Bounds Tables for .tdata section. Correct data copy is a
responsibi
On Nov 7, 2013, at 5:13 PM, Mingjie Xing wrote:
> Well, it is my understanding that the warning should be emitted for a
> volatile variable only if it is not accessed. Initialization means
> accessing, even though it is not used anywhere.
Let me try. A warning is useful, if there is no way a co
On Fri, Nov 8, 2013 at 1:07 AM, Joern Rennecke
wrote:
> On 7 November 2013 20:01, Uros Bizjak wrote:
>
>> OTOH, looking a bit deeper, it looks that there is a problem in
>> mode-switching infrastructure. If we have a BB without any mode
>> requirements, but an insn that switched the mode via MODE
ups, I did ping in the wrong thread about this issue. Sorry.
Anyway, I noticed that after r204334 my patch cannot be applied
without conflicts.
Here is the updated one attached. Bootstrapped and regtested on
x86_64-unknown-linux-gnu.
2013-11-08 Alexander Ivchenko
* gcc/cp/call.c (bui
ChangeLog:
2013-11-01 Julian Brown
Joey Ye
* config/arm/arm.c (arm_cortex_m_branch_cost): New.
(arm_v7m_tune): New.
(arm_*_tune): Add comments for Sched adj cost.
List all names here please rather than a regexp.
* config/arm/arm-cores.def (cortex-m4, cortex
On Fri, Nov 8, 2013 at 12:39 AM, Ian Lance Taylor wrote:
>> Recent Go mega-patch broke Alpha bootstrap. Following fixlet is needed:
>>
> Thanks for the patch and report. This patch should fix them.
> Bootstrapped and tested on x86_64-unknown-linux-gnu, not that that
> proves much. Committed to
Hello!
Attached patch fixes an oversight in mode-switching. For blocks
without ANY mode requirements, we have to consider instructions with
MODE_AFTER mode changes. If the exiting mode from the block is
different that no_mode (the mode we start), we have to mark the block
as nontransparent.
2013-
On Fri, Nov 8, 2013 at 5:03 PM, Mike Stump wrote:
> On Nov 7, 2013, at 5:13 PM, Mingjie Xing wrote:
>> Well, it is my understanding that the warning should be emitted for a
>> volatile variable only if it is not accessed. Initialization means
>> accessing, even though it is not used anywhere.
>
Hello,
this issue was discussed on cygwin's ML some time ago. For shared libgcc-DLL
use it might happen that the DLL is released too early, so we need to perform
an explicit load of it for increasing the load-count. By this we make sure
that the DLL is still loaded on destruction.
I will app
On Thu, Nov 7, 2013 at 5:00 PM, wrote:
> From: Trevor Saunders
>
> Hi,
>
> This is the result of seeing what it would take to get rid of the has_gate
> and
> has_execute flags on pass_data. It turns out not much, but I wanted
> confirmation this part is ok before I go deal with all the places
On Nov 8, 2013, at 1:32 AM, Bin.Cheng wrote:
> On Fri, Nov 8, 2013 at 5:03 PM, Mike Stump wrote:
>> On Nov 7, 2013, at 5:13 PM, Mingjie Xing wrote:
>>> Well, it is my understanding that the warning should be emitted for a
>>> volatile variable only if it is not accessed. Initialization means
On Thu, Nov 7, 2013 at 7:55 PM, Jeff Law wrote:
> On 11/07/13 04:50, Ilya Enkovich wrote:
>>
>> Hi,
>>
>> Here is an updated patch version.
>
> I think this needs to hold until we have a consensus on what the parameter
> passing looks like for bounded pointers.
I still think the best thing to do
On Thu, Nov 7, 2013 at 7:26 PM, Joseph S. Myers wrote:
>> Please note that following code form fenv.c won't generate overflow
>> exception on x87:
>>
>> if (excepts & FP_EX_OVERFLOW)
>> {
>> volatile float max = __FLT_MAX__;
>> r = max * max;
>> }
>
> r being volatile is int
On Fri, Nov 8, 2013 at 3:24 AM, Cong Hou wrote:
> Ping. OK for the trunk?
Ok.
Thanks,
Richard.
>
>
>
> thanks,
> Cong
>
>
> On Fri, Nov 1, 2013 at 10:47 AM, Cong Hou wrote:
>> It seems that on some platforms the loops in
>> testsuite/gcc.dg/vect/pr58508.c may be unable to be vectorized. This
>
2013/11/8 Richard Biener :
> On Thu, Nov 7, 2013 at 7:55 PM, Jeff Law wrote:
>> On 11/07/13 04:50, Ilya Enkovich wrote:
>>>
>>> Hi,
>>>
>>> Here is an updated patch version.
>>
>> I think this needs to hold until we have a consensus on what the parameter
>> passing looks like for bounded pointers.
On Fri, Nov 08, 2013 at 10:43:26AM +0100, Richard Biener wrote:
> >> Here is an updated patch version.
> >
> > I think this needs to hold until we have a consensus on what the parameter
> > passing looks like for bounded pointers.
>
> I still think the best thing to do on GIMPLE is
>
> arg_2 = __
On Fri, Nov 8, 2013 at 10:39 AM, Mike Stump wrote:
>
> On Nov 8, 2013, at 1:32 AM, Bin.Cheng wrote:
>
>> On Fri, Nov 8, 2013 at 5:03 PM, Mike Stump wrote:
>>> On Nov 7, 2013, at 5:13 PM, Mingjie Xing wrote:
Well, it is my understanding that the warning should be emitted for a
volatile
On 4 April 2013 23:01, Ian Lance Taylor wrote:
> On Thu, Apr 4, 2013 at 12:53 PM, Bernhard Reutner-Fischer
> wrote:
>>
>> 2013-03-24 Bernhard Reutner-Fischer
>>
>> * configure.ac (libgcc_cv_dfp): Extend check to probe fenv.h
>> availability.
>> * configure: Regenerate
>
On Fri, Nov 8, 2013 at 5:39 PM, Mike Stump wrote:
>
> On Nov 8, 2013, at 1:32 AM, Bin.Cheng wrote:
>
>> On Fri, Nov 8, 2013 at 5:03 PM, Mike Stump wrote:
>>> On Nov 7, 2013, at 5:13 PM, Mingjie Xing wrote:
Well, it is my understanding that the warning should be emitted for a
volatile
On 11 April 2013 14:18, Paolo Carlini wrote:
> Hi,
>
>
> On 04/11/2013 02:04 PM, Bernhard Reutner-Fischer wrote:
>>
>> I would have expected that somebody would tell me that omitting ::tmpnam
>> violates 27.9.2 from the spec but noone yelled at me yet?
>
> Frankly, I didn't because the targets I
Some comments from looking through the diff with the merge point,
ignoring wide-int.h and wide-int.cc. A few more to follow in the
form of patchses.
dwarf2out.c has:
+case CONST_WIDE_INT:
+ if (mode == VOIDmode)
+ mode = GET_MODE (rtl);
+
+ if (mode != V
Oops, if it is not a bug, please close the report
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57258
Thanks,
Mingjie
2013/11/8 Richard Biener :
> On Fri, Nov 8, 2013 at 10:39 AM, Mike Stump wrote:
>>
>> On Nov 8, 2013, at 1:32 AM, Bin.Cheng wrote:
>>
>>> On Fri, Nov 8, 2013 at 5:03 PM, Mike Stum
On Nov 8, 2013, at 2:25 AM, Bin.Cheng wrote:
> Thanks for elaborating. The warning message is actually for no-use of
> variable, and it has few things to do with whether it's accessed or
> not.
I disagree. If you examine why the warning was put in, you realize it was put
in so that lazy progra
On 11/06/13 09:45, James Greenhalgh wrote:
Hi,
This patch is a respin of the aarch-common improvements to use a generic
search to find SETs and the variety of shifts, rather than relying on the
hope that we will find something well formed.
I've bootstrapped the patch on a chromebook with -mcpu
On Nov 8, 2013, at 2:30 AM, Richard Sandiford
wrote:
> From gcse.c:
>
> --- wide-int-base/gcc/gcc/gcse.c 2013-11-05 13:09:32.148376180 +
> +++ wide-int/gcc/gcc/gcse.c 2013-11-05 13:07:28.431495118 +
> @@ -1997,6 +1997,13 @@ prune_insertions_deletions (int n_elems)
> bitmap_c
> On Tue, Nov 5, 2013 at 9:58 AM, Cong Hou wrote:
> > Thank you for your detailed explanation.
> >
> > Once GCC detects a reduction operation, it will automatically
> > accumulate all elements in the vector after the loop. In the loop the
> > reduction variable is always a vector whose elements ar
On 4 April 2013 22:20, Bruce Korb wrote:
> Except as noted below, fine by me.
>
> On 04/04/13 12:56, Bernhard Reutner-Fischer wrote:
>> Bootstrapped and regtested on x86_64-unknown-linux-gnu and
>> x86_64-mine-linux-uclibc without regressions, ok for trunk?
>>
>> fixincludes/ChangeLog:
>>
>> 2013-
On Nov 8, 2013, at 2:35 AM, Mingjie Xing wrote:
> Oops, if it is not a bug, please close the report
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57258
Well, I've stated my position. I can be swayed by a good argument, if someone
has one. I'd give people a chance to weigh in if they can think
On 7 November 2013 21:00, François Dumont wrote:
>
> * include/debug/safe_iterator.h (_BeforeBeginHelper<>::_S_Is):
> Take only a const safe iterator reference.
> (_BeforeBeingHelper<>::_S_Is_beginnest): Likewise.
There's a typo here, "Being" not "Begin"
> Ok to commit ?
Yes, with th
The recent Go patch (couldn't find the submission on gcc-patches) broke
Solaris bootstrap: on Solaris 10/x86 I get
/vol/gcc/src/hg/trunk/local/libgo/go/net/fd_unix.go:414:72: error: reference to
undefined identifier 'syscall.F_DUPFD_CLOEXEC'
r0, _, e1 := syscall.Syscall(syscall.SYS_FCNTL, uint
On 6 November 2013 08:04, Jakub Jelinek wrote:
> On Wed, Nov 06, 2013 at 02:24:01AM +, Iyer, Balaji V wrote:
>> Fixed patch is attached. The responses to your question are given below.
>> Is this patch OK?
>>
>> Here is the ChangeLog entry:
>>
>> +2013-11-05 Balaji V. Iyer
>> +
>> +
> Hello,
> This is new patch version.
> Comments from Bernhard Reutner-Fischer review applied.
> Also, test case bitfildmrg2.c modified - it is now execute test.
>
>
> Example:
>
> Original code:
>D.1351;
>D.1350;
>D.1349;
> D.1349_2 = p1_1(D)->f1;
> p2_3(D)->f1 = D.1349_2;
> D
Hi,
On Nov 8 04:36, Kai Tietz wrote:
> Hello,
>
> this issue was discussed on cygwin's ML some time ago. For shared
> libgcc-DLL use it might happen that the DLL is released too early, so
> we need to perform an explicit load of it for increasing the
> load-count. By this we make sure that the
The following fixes PR59047 - data-ref and bitfields.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
Index: gcc/tree-predcom.c
===
*** gcc/tree-predcom.c (revision 204561)
--- gcc/tree-predcom.c (
The tests introduced in revision 204544 fail with -m32
(see http://gcc.gnu.org/ml/gcc-regression/2013-11/msg00213.html
or http://gcc.gnu.org/ml/gcc-testresults/2013-11/msg00526.html ).
This revision may also causes the failures of
gfortran.dg/typebound_operator_9.f03 and
FAIL: gfortran.fortran-tor
On Fri, 8 Nov 2013, Uros Bizjak wrote:
> Can we introduce a target-dependant source here, in the same way as
Sure, that seems a reasonable thing to do. I think putting a file fenv.c
in an appropriate subdirectory of libatomic/config will result in it being
found automatically by the existing s
On Fri, 8 Nov 2013, Dominique Dhumieres wrote:
> This revision may also causes the failures of
> gfortran.dg/typebound_operator_9.f03 and
> FAIL: gfortran.fortran-torture/execute/forall_1.f90.
I doubt the patch affects Fortran (there are language-independent changes,
but they are fairly small a
According to http://gcc.gnu.org/ml/gcc-regression/2013-11/msg00197.html
revision 204538 is breaking several tests. On x86_64-apple-darwin* the
failures I have looked at are of the kind
/opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_9.f03: In function
'nabla2_cart2d':
/opt/gcc/work/gcc
> I doubt the patch affects Fortran (there are language-independent changes,
> but they are fairly small and shouldn't affect code not using _Atomic
> qualifiers).
The Fortran failures seem related to revision 204538.
Dominique
Hi all,
In arm_new_rtx_costs we need a break; statement after handling the comparisons
cases. Otherwise we fall through and compute garbage. This small patch adds that.
Tested arm-none-eabi on qemu.
Ok for trunk?
Thanks,
Kyrill
2013-11-08 Kyrylo Tkachov
* config/arm/arm.c (arm_new_
Hi,
This patch refactors force_expr_to_var_cost and handles type conversion
along with other tree nodes. It is split from the patch posted at
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00546.html
Bootstrap and test with the patch lowering address expressions on
x86/x86_64/arm. Is it OK?
Thanks
On Fri, Nov 8, 2013 at 2:41 PM, bin.cheng wrote:
> Hi,
> This patch refactors force_expr_to_var_cost and handles type conversion
> along with other tree nodes. It is split from the patch posted at
> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00546.html
> Bootstrap and test with the patch loweri
Hi!
Here is an updated version of the patch I've posted yesterday.
The changes since then are that the expander can now handle the CONSTRUCTORs
this patch creates (although we probably want to add some vec_concat
optab and at least improve handling of concatenation of two half sized
vectors into o
Hi,
On Thu, 7 Nov 2013, Alec Teal wrote:
> > > subclass, by adding empty subclasses derived from the GSS_-based
> > > subclasses as appropriate (I don't bother for gimple codes that already
> > > have their own subclass due to having their own GSS layout). I also
> > > copied the comments from g
On 11/08/13 07:10, Jakub Jelinek wrote:
Hi!
Here is an updated version of the patch I've posted yesterday.
The changes since then are that the expander can now handle the CONSTRUCTORs
this patch creates (although we probably want to add some vec_concat
optab and at least improve handling of conc
AutoFDO sometimes has 0 profile in the loop's entry block because the
debug info are lost and unrecoverable.
E.g.
if (a)
if (b)
for () {}
This patch checks if the scale factor is 0, then use the normal scale.
Bootstrapped and passed regression test and performance test.
OK for google-4_8
This creates new base classes for the parts of _State and _NFA which
are not dependent on template parameters, and replaces some copies
with moves.
2013-11-08 Jonathan Wakely
* include/bits/regex_automaton.h (__detail::_State): Split
non-dependent parts into new _State_base.
This removes some more redundant _CharT template parameters.
2013-11-08 Jonathan Wakely
* include/bits/regex_compiler.h (__detail::_AnyMatcher,
__detail::_CharMatcher, __detail::_BracketMatcher): Remove redundant
_CharT template parameters.
* include/bits/regex_
This removes the redundant _CharT template parameters that can be
obtained from the _Traits parameters. It also adds the __compile_nfa
function to create a _Compiler (deducing its template arguments) and
get the _NFA from it.
2013-11-08 Jonathan Wakely
* include/bits/regex_automaton.h
bootstrapped / regtested on i686-pc-linux-gnu.
2013-11-08 Joern Rennecke
PR middle-end/59049
* expmed.c (emit_cstore): Avoid generating a comparison of two
VOIDmode constants.
Index: gcc/expmed.c
===
--- gc
2013/11/8 Jonathan Wakely :
> As I suggested yesterday on the libstdc++ list, this adds an overload
> for string and vector iterators to extract a raw pointer and re-use
> the _Compiler specialization, so that std::regex(".")
> and std::regex(std::string(".")) and std::regex(std::vector(1,
> '.'))
As I suggested yesterday on the libstdc++ list, this adds an overload
for string and vector iterators to extract a raw pointer and re-use
the _Compiler specialization, so that std::regex(".")
and std::regex(std::string(".")) and std::regex(std::vector(1,
'.')) only instantiate _Compiler once.
2013
On Fri, Nov 8, 2013 at 3:40 PM, Joern Rennecke
wrote:
> bootstrapped / regtested on i686-pc-linux-gnu.
Not a very elaborate description of the patch, eh? :-)
This is IMHO not OK without at least an explanation of why the
comparison of two const_ints is not folded. Better yet would be to fix
that
On 8 November 2013 14:45, Steven Bosscher wrote:
> Also would need a test case.
As is mentioned in the PR, we already have a test case, which shows a
regression.
Hello,
I'd like to make JUMP_TABLE_DATA a non-active insn before the end of
stage1. Most of the work required for this is pretty simple. It
involves finding and fixing the few places where insns are walked
across basic block boundaries and ignoring barriers. Ah, the madness
of that! :-) Fortunatel
On 8 November 2013 14:45, Steven Bosscher wrote:
> This is IMHO not OK without at least an explanation of why the
> comparison of two const_ints is not folded. Better yet would be to fix
> that underlying problem. We should not present such non-sense to the
> RTL parts of the middle end.
Which pa
On Fri, Nov 08, 2013 at 10:37:00AM +0100, Richard Biener wrote:
> On Thu, Nov 7, 2013 at 5:00 PM, wrote:
> > From: Trevor Saunders
> >
> > Hi,
> >
> > This is the result of seeing what it would take to get rid of the has_gate
> > and
> > has_execute flags on pass_data. It turns out not much,
On Fri, Nov 8, 2013 at 4:18 PM, Joern Rennecke wrote:
> On 8 November 2013 14:45, Steven Bosscher wrote:
>> This is IMHO not OK without at least an explanation of why the
>> comparison of two const_ints is not folded. Better yet would be to fix
>> that underlying problem. We should not present such
On Fri, Nov 08, 2013 at 04:32:09PM +0100, Steven Bosscher wrote:
> On Fri, Nov 8, 2013 at 4:18 PM, Joern Rennecke wrote:
> > On 8 November 2013 14:45, Steven Bosscher wrote:
> >> This is IMHO not OK without at least an explanation of why the
> >> comparison of two const_ints is not folded. Better y
On 8 November 2013 14:51, Daniel Krügler wrote:
> I have fully not grasped for which T the specializations of
> __has_contiguous_iter are intended to be used,
Currently, only std::container iterators passed to a basic_regex
constructor, but in theory the trait could get moved to another header
and
On Tue, May 14, 2013 at 3:47 PM, Steven Bosscher wrote:
> On Wed, Apr 24, 2013 at 12:58 AM, Sriraman Tallam wrote:
>> Hi,
>>
>> This patch generates labels for cold function parts that are split when
>> using the option -freorder-blocks-and-partition. The cold label name
>> is generated by suff
On Fri, Nov 8, 2013 at 4:41 PM, Jakub Jelinek wrote:
> On Fri, Nov 08, 2013 at 04:32:09PM +0100, Steven Bosscher wrote:
>> On Fri, Nov 8, 2013 at 4:18 PM, Joern Rennecke wrote:
>> > On 8 November 2013 14:45, Steven Bosscher wrote:
>> >> This is IMHO not OK without at least an explanation of why the
On 11/08/13 07:45, Steven Bosscher wrote:
On Fri, Nov 8, 2013 at 3:40 PM, Joern Rennecke
wrote:
bootstrapped / regtested on i686-pc-linux-gnu.
Not a very elaborate description of the patch, eh? :-)
This is IMHO not OK without at least an explanation of why the
comparison of two const_ints is
On 8 November 2013 15:41, Jonathan Wakely wrote:
> On 8 November 2013 14:51, Daniel Krügler wrote:
>> I have fully not grasped for which T the specializations of
>> __has_contiguous_iter are intended to be used,
>
> Currently, only std::container iterators passed to a basic_regex
> constructor, but
On Fri, Nov 8, 2013 at 4:45 PM, Teresa Johnson wrote:
> On Tue, May 14, 2013 at 3:47 PM, Steven Bosscher wrote:
> I'd like to revisit this old patch from Sri to generate a label for
> the split out cold section, now that all the patches to fix the
> failures and insanities from -freorder-blocks-and
On Fri, Nov 8, 2013 at 8:14 AM, Steven Bosscher wrote:
> On Fri, Nov 8, 2013 at 4:45 PM, Teresa Johnson wrote:
>> On Tue, May 14, 2013 at 3:47 PM, Steven Bosscher wrote:
>> I'd like to revisit this old patch from Sri to generate a label for
>> the split out cold section, now that all the patches t
This has been on my todo list for a little while now. Over time I've
written the loop to delete a jump threading path several times. It's
just 3 lines of code, but I hate repeating it all over the place.
This pulls those trivial 3 lines into a function and calls it from the
appropriate pla
On Fri, Nov 8, 2013 at 4:45 PM, Teresa Johnson wrote:
> For example, from mcf with -freorder-blocks-and-partition:
>
> main:
> .LFB40:
> .cfi_startproc
> ...
> jne .L27 < jump to main's text.unlikely
> ...
> .cfi_endproc
> .section
Hello!
> I've applied this patch to update libgcc's copy of soft-fp from
> glibc. There are lots of coding standards fixes, but also various bug
> fixes; I've added testcases for various of the fixed bugs illustrating
> them for __float128.
Is there really no way to get those "missing prototypes
Sure. Looks good to me. Thanks
On Fri, Nov 8, 2013 at 2:57 AM, Bernhard Reutner-Fischer
wrote:
> On 4 April 2013 22:20, Bruce Korb wrote:
>> Except as noted below, fine by me.
>>
>> On 04/04/13 12:56, Bernhard Reutner-Fischer wrote:
>>> Bootstrapped and regtested on x86_64-unknown-linux-gnu an
Hello Everyone,
Attached, please find a patch that will fix a crash in a function in
libcilkrts when optimization was turned on. The issue was that the longjump and
setjmp were called in the same function. This patch should fix that issue. The
change is not in the compiler side but only
On 11/08/13 13:34, Kyrill Tkachov wrote:
Hi all,
In arm_new_rtx_costs we need a break; statement after handling the comparisons
cases. Otherwise we fall through and compute garbage. This small patch adds
that.
Tested arm-none-eabi on qemu.
Ok for trunk?
Ok - thanks.
Ramana
On 8 November 2013 15:50, Steven Bosscher wrote:
> Even with the gimple opts disabled, a const-const comparison would
> normally be folded by the RTL expanders.
Well, in this spirit, attached is another way to address the RTL side
of the problem.
As mention in the PR, the tree side of the problem
On Fri, Nov 8, 2013 at 2:13 PM, Joseph S. Myers wrote:
>> Can we introduce a target-dependant source here, in the same way as
>
> Sure, that seems a reasonable thing to do. I think putting a file fenv.c
> in an appropriate subdirectory of libatomic/config will result in it being
> found automati
On Wed, Oct 30, 2013 at 5:03 AM, Andrew Pinski wrote:
> Here is what I applied in the end; Jeff told me just to remove the
> testcase. I added the comment trying to explain why it was the
> opposite order of PHI-opt.
>
> Thanks,
> Andrew Pinski
>
> ChangeLog:
> * tree-ssa-ifcombine.c: Include rtl.
On Fri, Nov 8, 2013 at 6:23 AM, Dehao Chen wrote:
> AutoFDO sometimes has 0 profile in the loop's entry block because the
> debug info are lost and unrecoverable.
Is that a separate problem to track and fix?
Also is it better to do a round of loop profiling smoothing after auto
profile annotati
On 8 November 2013 16:03, Jonathan Wakely wrote:
> On 8 November 2013 15:41, Jonathan Wakely wrote:
>> On 8 November 2013 14:51, Daniel Krügler wrote:
>>> I have fully not grasped for which T the specializations of
>>> __has_contiguous_iter are intended to be used,
>>
>> Currently, only std::contai
Code like this
type S struct {
F int
}
var V = S{F: 1}
var F = V.F
could trigger an incorrect "variable initializer refers to itself" error
because the Go frontend would confuse itself into thinking that the "F"
in the composite literal was the same as the global variable "F", rather
th
On Fri, Nov 8, 2013 at 6:20 PM, Steven Bosscher wrote:
> On Wed, Oct 30, 2013 at 5:03 AM, Andrew Pinski wrote:
>> Here is what I applied in the end; Jeff told me just to remove the
>> testcase. I added the comment trying to explain why it was the
>> opposite order of PHI-opt.
>>
>> Thanks,
>> Andr
> On Nov 8, 2013, at 9:20 AM, Steven Bosscher wrote:
>
>> On Wed, Oct 30, 2013 at 5:03 AM, Andrew Pinski wrote:
>> Here is what I applied in the end; Jeff told me just to remove the
>> testcase. I added the comment trying to explain why it was the
>> opposite order of PHI-opt.
>>
>> Thanks,
>
On 11/07/13 09:09, Martin Jambor wrote:
I am glad this is becoming a useful infrastructure rather than just a
part of IPA-SRA. Note that while ipa_combine_adjustments is not used
from anywhere and thus probably buggy anyway, it should in theory be
able to process new_param adjustments too. Can
I merged GCC mainline revision 204583 to the gcgo branch.
Ian
On Nov 8, 2013, at 4:09 AM, Bernhard Reutner-Fischer
wrote:
> On 6 November 2013 08:04, Jakub Jelinek wrote:
>> On Wed, Nov 06, 2013 at 02:24:01AM +, Iyer, Balaji V wrote:
>>>Fixed patch is attached. The responses to your question are given below.
>>> Is this patch OK?
> May i suggest
On Fri, Nov 8, 2013 at 8:48 AM, Iyer, Balaji V wrote:
> Hello Everyone,
> Attached, please find a patch that will fix a crash in a function in
> libcilkrts when optimization was turned on. The issue was that the longjump
> and setjmp were called in the same function. This patch should f
in libgcov-driver.c
> /* Flag when the profile has already been dumped via __gcov_dump(). */
> static int gcov_dump_complete;
> inline void
> set_gcov_dump_complete (void)
>{
> gcov_dump_complete = 1;
>}
>inline void
>reset_gcov_dump_complete (void)
>{
> gcov_dump_complete = 0;
>}
These sh
On Fri, Nov 8, 2013 at 10:22 AM, Xinliang David Li wrote:
> in libgcov-driver.c
>
>> /* Flag when the profile has already been dumped via __gcov_dump(). */
>> static int gcov_dump_complete;
>
>> inline void
>> set_gcov_dump_complete (void)
>>{
> > gcov_dump_complete = 1;
>>}
>
>>inline void
>>r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59050
This is my bad. I forget to check the test result for gfortran. With
this patch the bug should be fixed (tested on x86-64).
thanks,
Cong
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 90b01f2..e62c672 100644
--- a/gcc/ChangeLog
+++ b/gcc/Chan
On 10/31/2013 05:47 AM, Adam Butcher wrote:
+ become_template = true;
+ push_deferring_access_checks (dk_deferred);
Why is this call here? I don't see anything in the rest of the function
that would trigger an access check, or a matching pop.
+ /* Create a distinct
Thank you for the report. I have submitted a bug fix patch waiting to
be reviewed.
thanks,
Cong
On Fri, Nov 8, 2013 at 5:26 AM, Dominique Dhumieres wrote:
> According to http://gcc.gnu.org/ml/gcc-regression/2013-11/msg00197.html
> revision 204538 is breaking several tests. On x86_64-apple-dar
> 1) I don't think you need in_mem flag. For in memory merge, the source !=
> NULL.
discard this comment.
David
>
>
>
>
>
>
> On Thu, Nov 7, 2013 at 3:34 PM, Rong Xu wrote:
>> On Thu, Nov 7, 2013 at 9:40 AM, Joseph S. Myers
>> wrote:
>>> On Thu, 7 Nov 2013, Rong Xu wrote:
>>>
Thanks Jose
A question about inhibit_libc.
When inhibit_libc is defined, we provide dummy functions for all the
__gcov_* methods.
Is it purposely to minimize the footprint?
I'm thinking to allow some codes that are independent of libc (and its
headers) under this. Is it OK?
-Rong
On Fri, Nov 8, 2013 at 10:48
On Fri, Nov 8, 2013 at 10:48 AM, Rong Xu wrote:
> On Fri, Nov 8, 2013 at 10:22 AM, Xinliang David Li wrote:
>> in libgcov-driver.c
>>
>>> /* Flag when the profile has already been dumped via __gcov_dump(). */
>>> static int gcov_dump_complete;
>>
>>> inline void
>>> set_gcov_dump_complete (void)
On Wed, 2013-11-06 at 22:32 -0700, Jeff Law wrote:
> [ Just a note, of this reply is meant for Michael and other parts for
> David, hopefully the audience is clear from the context. ]
>
> On 11/06/13 21:56, David Malcolm wrote:
> > On Wed, 2013-11-06 at 16:32 +0100, Michael Matz wrote:
> >> Hi,
>
On Fri, Nov 8, 2013 at 10:56 AM, Rong Xu wrote:
> A question about inhibit_libc.
> When inhibit_libc is defined, we provide dummy functions for all the
> __gcov_* methods.
> Is it purposely to minimize the footprint?
> I'm thinking to allow some codes that are independent of libc (and its
> header
On Fri, Nov 8, 2013 at 11:02 AM, Xinliang David Li wrote:
> On Fri, Nov 8, 2013 at 10:48 AM, Rong Xu wrote:
>> On Fri, Nov 8, 2013 at 10:22 AM, Xinliang David Li
>> wrote:
>>> in libgcov-driver.c
>>>
/* Flag when the profile has already been dumped via __gcov_dump(). */
static int gc
On Fri, Nov 8, 2013 at 11:21 AM, Rong Xu wrote:
> On Fri, Nov 8, 2013 at 11:02 AM, Xinliang David Li wrote:
>> On Fri, Nov 8, 2013 at 10:48 AM, Rong Xu wrote:
>>> On Fri, Nov 8, 2013 at 10:22 AM, Xinliang David Li
>>> wrote:
in libgcov-driver.c
> /* Flag when the profile has alre
> This patch just changes a QImode (const_int 255) to (const_int -1),
> since the canonical form is to sign-extend. As things stand the pattern
> trips a new assert added on the wide-int branch.
Ok. Thanks!
1 - 100 of 122 matches
Mail list logo