This patch makes -fstrict-volatile-bitfields not be the default on any
target. It is unchanged from part 4 of the previous version (v3) of
this patch set that I originally posted back in June and have been
re-pinging many times since then.
Some reviewers of my original patch series argued qui
This patch fixes various -fstrict-volatile-bitfields wrong-code bugs,
including instances where bitfield values were being quietly truncated
as well as bugs relating to using the wrong width. The code changes are
identical to those in the previous version of this patch series
(originally poste
Here is the latest version of my -fstrict-volatile-bitfields patches.
I have gone ahead and committed part 1 of the previous version of this
patch series, which was approved back in mid-June. That part just
removes the warning about conflicts with packed structs (which everybody
seemed to agr
The current GCC vectorizer requires the following pattern as a simple
reduction computation:
loop_header:
a1 = phi < a0, a2 >
a3 = ...
a2 = operation (a3, a1)
But a3 can also be defined outside of the loop. For example, the
following loop can benefit from vectorization but the G
On Fri, Sep 27, 2013 at 4:08 PM, Xinliang David Li wrote:
> d.growth -= (info->size
> * (100 - PARAM_VALUE (PARAM_COMDAT_SHARING_PROBABILITY))
> + 50) / 100;
>
> What is the purpose of '50' here?
Rounding after division by 100.
> The patch is fine for Google branch.
>
> Other tunings to
d.growth -= (info->size
* (100 - PARAM_VALUE (PARAM_COMDAT_SHARING_PROBABILITY))
+ 50) / 100;
What is the purpose of '50' here?
The patch is fine for Google branch.
Other tunings to think about -- I think the sharing probability should
not be a fixed value -- but depending on the functio
Hi,
builtin_expect should be a NOP in size_estimation. Indeed, the call
stmt itself is 0 weight in size and time. But it may introduce
an extra relation expr which has non-zero size/time. The end result
is: for w/ and w/o builtin_expect, we have different size/time estimation
for inlining.
This p
Hi,
Current default probability for builtin_expect is 0.9996.
This makes the freq of unlikely bb very low (4), which
suppresses the inlining of any calls within those bb.
We used FDO data to measure the branch probably for
the branch annotated with builtin_expert.
For google internal benchmar
I've merged revision 202996 from the GCC 4.8 branch to the gccgo branch.
Ian
I realized that in the amd64 implementation of MakeFunc I forgot that
it's not OK to just take the address of a value on the stack, since the
function might hang onto the address. The value needs to be copied onto
the heap first. This patch implements that. Bootstrapped and ran Go
testsuite on x
This patch increases comdat-sharing-probability to 80 under -Os. This
reduces the amount of inlining and helps internal benchmarks.
Unfortunately, this causes slight regression on spec 2006. Ok for
google branches if all tests pass?
- Easwaran
comdat_sharing.patch
Description: Binary data
Following up on my earlier patch, this patch implements the
reflect.MakeFunc function for 386.
Tom Tromey pointed out to me that the libffi closure support can
probably be used for this. I was not aware of that support. It
supports a lot more processors, and I should probably start using it.
The
On Thu, Sep 26, 2013 at 3:27 PM, Jan Hubicka wrote:
>> Hi,
>>
>> Current default probably for builtin_expect is 0.9996.
>> This makes the freq of unlikely bb very low (4), which
>> suppresses the inlining of any calls within those bb.
>>
>> We used FDO data to measure the branch probably for
>> th
Hi
Tim Shen ha scritto:
>Do I need to bootstrap again?
Nah, only double check that the testcase you are un-xfail-ing uses
-std=gnu++11, otherwise will not pass ;)
Paolo
Gerald> And looking at the code, I see
Gerald> +COMPILE.base = $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS)
-o $@
[...]
Gerald> Where does $(ALL_COMPILERFLAGS) compile from?
Look a little further down in the patch:
.cc.o .c.o:
- $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS)
The issue is that building the instrumented binary with and without,
say, -gmlt, may result in different module grouping.
Teresa
On Fri, Sep 27, 2013 at 1:18 PM, Rong Xu wrote:
> I don't quite understand here. We use the profile-generate memory
> consumption to estimate the profile use memory co
The key is that grouping results should not dependent on the presence
of -g flags. The downside of the patch is that it may slightly
underestimate the memory pressure at profile-use time, but that should
not be a big problem.
David
On Fri, Sep 27, 2013 at 1:18 PM, Rong Xu wrote:
> I don't quite
On Fri, Sep 27, 2013 at 9:37 AM, Jonathan Wakely wrote:
> Ah I see. I definitely agree it's good to accept that instead of
> being unnecessarily strict, but other people will want the option of
> strict conformance, so I think we can please everyone with something
> like:
>
> else
> {
> #ifdef
I don't quite understand here. We use the profile-generate memory
consumption to estimate the profile use memory consumption.
we still have -g/-gmlt in profile-use compilation. Will this change
effectively under estimate the memory use in the use phrase?
-Rong
On Fri, Sep 27, 2013 at 11:50 AM, Te
ok.
David
On Fri, Sep 27, 2013 at 1:03 PM, Teresa Johnson wrote:
> On Fri, Sep 27, 2013 at 12:01 PM, Xinliang David Li
> wrote:
>> On Fri, Sep 27, 2013 at 11:50 AM, Teresa Johnson
>> wrote:
>>> David and Rong,
>>>
>>> The following patch will disable -g/-gmlt when instrumenting for LIPO
>>>
On Fri, Sep 27, 2013 at 12:01 PM, Xinliang David Li wrote:
> On Fri, Sep 27, 2013 at 11:50 AM, Teresa Johnson wrote:
>> David and Rong,
>>
>> The following patch will disable -g/-gmlt when instrumenting for LIPO
>> since they will affect the recorded ggc_memory used in the module
>> grouping deci
Jan Hubicka writes:
>
> I also added X86_TUNE_SSE_UNALIGNED_STORE_OPTIMAL to bobcat tuning, since it
> seems like obvious omision (after double checking in optimization manual) and
> droped X86_TUNE_FOUR_JUMP_LIMIT for buldozer cores.
When tuning for Intel SandyBridge+ it would be actually intere
Hello,
a format string in the example for DATE_AND_TIME contained a syntax
error. Committed as obvious.
2013-09-27 Janne Blomqvist
* intrinsic.texi (DATE_AND_TIME): Fix example.
Index: intrinsic.texi
===
--- intrinsic.texi
Hi Tom,
On Mon, 23 Sep 2013, Tom Tromey wrote:
> This adds the configury needed for automatic dependency tracking. It
> also adds some bits to the Makefile so we can begin converting
> (removing) explicit dependencies.
>
> * Makefile.in (CCDEPMODE, DEPDIR, depcomp, COMPILE.base)
> (C
On Fri, Sep 27, 2013 at 11:50 AM, Teresa Johnson wrote:
> David and Rong,
>
> The following patch will disable -g/-gmlt when instrumenting for LIPO
> since they will affect the recorded ggc_memory used in the module
> grouping decision. Added -fripa-allow-debug to override this behavior.
>
> Passe
David and Rong,
The following patch will disable -g/-gmlt when instrumenting for LIPO
since they will affect the recorded ggc_memory used in the module
grouping decision. Added -fripa-allow-debug to override this behavior.
Passes regression tests and simple tests on the new functionality.
Ok for
Can the sh people weigh in on this? Are the PSI and PDI precisions 32 and 64?
On Sep 17, 2013, at 10:24 AM, Mike Stump wrote:
> On Sep 16, 2013, at 8:41 PM, DJ Delorie wrote:
>> m32c's PSImode is 24-bits, why does it have "32" in the macro?
>>
>> /* 24-bit pointers, in 32-bit units */
>> -PART
On Sep 27, 2013, at 1:48 AM, nick clifton wrote:
> OK by me, although I cannot approve that particular patch.
I know, the intent is for someone that can, to approve it.
> But I ran into a very strange problem. With your PARTIAL_INT_MODE_NAME patch
> applied GCC started erroneously eliminating
On Thu, Sep 26, 2013 at 3:23 PM, Jan Hubicka wrote:
>> Hi,
>>
>> builtin_expect should be a NOP in size_estimation. Indeed, the call
>> stmt itself is 0 weight in size and time. But it may introduce
>> an extra relation expr which has non-zero size/time. The end result
>> is: for w/ and w/o builti
The Go standard library has an interesting function named
reflect.MakeFunc. It takes a Go function F that accepts and returns a
slice of reflect.Value, and a function type T, and returns a pointer to
a function of type T that converts its arguments to reflect.Value, calls
F, and converts the retur
Please review the changes.html change and suggest better wordings if possible:
ndex: htdocs/gcc-4.9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrieving revision 1.26
diff -u -r1.26 changes.html
--- htd
On 09/27/13 09:23, Jakub Jelinek wrote:
On Thu, Sep 26, 2013 at 02:31:33PM -0500, Aldy Hernandez wrote:
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -42806,6 +42806,43 @@ ix86_memmodel_check (unsigned HOST_WIDE_INT val)
return val;
}
+/* Return the default vector mangling
On Fri, Sep 27, 2013 at 1:20 AM, Richard Biener
wrote:
> On Fri, Sep 27, 2013 at 12:23 AM, Jan Hubicka wrote:
>>> Hi,
>>>
>>> builtin_expect should be a NOP in size_estimation. Indeed, the call
>>> stmt itself is 0 weight in size and time. But it may introduce
>>> an extra relation expr which has
On 09/27/2013 10:48 AM, James Greenhalgh wrote:
On Fri, Sep 27, 2013 at 04:32:10PM +0100, Jeff Law wrote:
If you could pass along a .i file it'd be helpful in case I want to look
at something under the debugger.
I've opened http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58553 to save
everyone's i
On Fri, Sep 27, 2013 at 04:32:10PM +0100, Jeff Law wrote:
> If you could pass along a .i file it'd be helpful in case I want to look
> at something under the debugger.
I've opened http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58553 to save
everyone's inboxes.
Let me know if I can do anything else
Hi,
sorry it took me so long, but it also took me quite a while to chew
through. Please consider posting context diff in cases like this.
Nevertheless, most of the patch is a nice improvement.
On Wed, Sep 25, 2013 at 12:20:50PM +0200, Jan Hubicka wrote:
> Hi,
> this is updated version of
> http
The gimple builder no longer support normal form. The ssa_mode
enum is not needed now.
Committed to trunk.
* gimple.h (enum ssa_mode): Remove.
---
gcc/gimple.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/gcc/gimple.h b/gcc/gimple.h
index 3047ab4..a031c8d 100644
--- a/gcc/
On Thu, 2013-09-26 at 14:47 +0100, Marcus Shawcroft wrote:
> I'm in two minds about whether further sticky tape of this form is the
> right approach or whether the original patch should be reverted until a
> proper fix that does not regress the tree can be found.
>
> Thoughts?
>
> 2013-09-26
On Fri, Sep 27, 2013 at 8:36 AM, Jan Hubicka wrote:
>> On Fri, Sep 27, 2013 at 1:56 AM, Jan Hubicka wrote:
>> > Hi,
>> > this is second part of the generic tuning changes sanityzing the tuning
>> > flags.
>> > This patch again is supposed to deal with the "obvious" part only.
>> > I will send se
Nice extension. Test cases would be great to have.
thanks,
David
On Fri, Sep 27, 2013 at 7:50 AM, Jan Hubicka wrote:
> Hi,
> this patch makes it possible to access value range info from setmem/movstr
> that
> I plan to use in i386 memcpy/memset expansion code. It is all quite
> straighforward
> On Fri, Sep 27, 2013 at 1:56 AM, Jan Hubicka wrote:
> > Hi,
> > this is second part of the generic tuning changes sanityzing the tuning
> > flags.
> > This patch again is supposed to deal with the "obvious" part only.
> > I will send separate patch for more changes.
> >
> > The flags changed ag
On 09/27/2013 08:42 AM, James Greenhalgh wrote:
On Thu, Sep 26, 2013 at 04:26:35AM +0100, Jeff Law wrote:
Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
Installed on trunk.
Hi Jeff,
This patch caused a regression on Arm and AArch64 in:
PASS->FAIL: gcc.c-torture/execute/memcp
On 13-09-27 4:55 AM, Dodji Seketeli wrote:
Let's CC Vladimir on this easy one.
Cheers.
All targets I know have ELIMINABLE_REGS defined. Therefore it was not
caught before.
.
The patch is ok for me. Thanks.
Jan-Benedict Glaw a écrit:
On Fri, 2013-09-20 20:51:37 +0200, Jan-Benedict Glaw
On Fri, Sep 27, 2013 at 1:56 AM, Jan Hubicka wrote:
> Hi,
> this is second part of the generic tuning changes sanityzing the tuning flags.
> This patch again is supposed to deal with the "obvious" part only.
> I will send separate patch for more changes.
>
> The flags changed agree on all CPUs con
Hi,
this patch makes it possible to access value range info from setmem/movstr that
I plan to use in i386 memcpy/memset expansion code. It is all quite
straighforward except that I need to deal with cases where max size does not
fit in HOST_WIDE_INT where I use maximal value as a marker. It is th
On Fri, Sep 27, 2013 at 06:10:41PM +0400, Yury Gribov wrote:
> Hi all,
>
> I've recently submitted a bug report regarding invalid unpoisoning
> of stack frame redzones
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543). Could someone
> take a look at proposed patch (a simple one-liner) and chec
On Thu, Sep 26, 2013 at 02:31:33PM -0500, Aldy Hernandez wrote:
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -42806,6 +42806,43 @@ ix86_memmodel_check (unsigned HOST_WIDE_INT val)
>return val;
> }
>
> +/* Return the default vector mangling ISA code when none is specifie
On Thu, Sep 26, 2013 at 3:02 PM, Jan Hubicka wrote:
>>
>> Why not just have probably_never_executed_bb_p return simply return
>> false bb->frequency is non-zero (right now it does the opposite -
>
> We want to have frequencies guessed for functions that was not trained
> in the profiling run (that
Hi all,
I've recently submitted a bug report regarding invalid unpoisoning of
stack frame redzones
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543). Could someone take
a look at proposed patch (a simple one-liner) and check whether it's ok
for commit?
Thanks!
-Yuri
diff --git a/gcc/asan
PR libstdc++/57465
* include/std/functional
(_Function_base::_Base_manager::_M_not_empty_function): Fix overload
for pointers.
* testsuite/20_util/function/cons/57465.cc: New.
Tested x86_64-linux, committed to trunk. I'll apply it to the
branches after it'
Hi!
I've committed the following fix to a regression introduced in 4.9
early loop construction. SESE regions, as documented above
move_sese_region_to_fn, are allowed to contain calls to noreturn functions
like abort/exit. But, basic blocks leading to noreturn functions aren't
actually placed in
On 27 September 2013 13:32, Paolo Carlini wrote:
> On 9/27/13 4:34 AM, Jonathan Wakely wrote:
>>
>> On 27 September 2013 03:15, Tim Shen wrote:
>>>
>>> POSIX ERE says that escaping an ordinary char, say R"\n" is not
>>> permitted, because 'n' is not a special char. However, they also say
>>> that :
On 09/27/13 03:18, Richard Biener wrote:
On Thu, Sep 26, 2013 at 9:35 PM, Aldy Hernandez wrote:
+ /* To distinguish from an OpenMP simd clone, Cilk Plus functions to
+ be cloned have a distinctive artificial label in addition to "omp
+ declare simd". */
+ bool cilk_clone = flag_enabl
On 9/27/13 4:34 AM, Jonathan Wakely wrote:
On 27 September 2013 03:15, Tim Shen wrote:
POSIX ERE says that escaping an ordinary char, say R"\n" is not
permitted, because 'n' is not a special char. However, they also say
that : "Implementations are permitted to extend the language to allow
these.
Hi,
this fixes the ICE during the build of the Ada runtime on the SPARC, a fallout
of the recent inliner changes:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01033.html
The ICE is triggered because the ldd peephole merges an MEM with MEM_NOTRAP_P
and a contiguous MEM without MEM_NOTRAP_P, ke
Gary Benson wrote:
> Hi all,
>
> This is a resubmission of my previous demangler fix [1] rewritten
> to avoid using hashtables and other libiberty features.
>
> From the above referenced email:
>
> d_print_comp maintains a certain amount of scope across calls (namely
> a stack of templates) whic
On Fri, Sep 27, 2013 at 01:48:36AM +0200, Jakub Jelinek wrote:
> Perhaps. What if I do just minor cleanup (use flexible array members for
> the reallocated vectors, and perhaps keep only the last out/inout task
> in the hash table chains rather than all of them), retest, commit and then
> we can d
On 27 September 2013 05:17, Ed Smith-Rowland wrote:
>
> The complex user-defined literals finally passed (n3779) with the resolution
> to DR1473 allowing the suffix id to touch the quotes (Can't find it but I
> put it in not too long ago).
I think it's been approved by the LWG and looks like it wi
On 27 September 2013 03:15, Tim Shen wrote:
> POSIX ERE says that escaping an ordinary char, say R"\n" is not
> permitted, because 'n' is not a special char. However, they also say
> that : "Implementations are permitted to extend the language to allow
> these. Conforming applications cannot use su
Hi,
this is second part of the generic tuning changes sanityzing the tuning flags.
This patch again is supposed to deal with the "obvious" part only.
I will send separate patch for more changes.
The flags changed agree on all CPUs considered for generic (and their
optimization manuals) + amdfam10,
Let's CC Vladimir on this easy one.
Cheers.
Jan-Benedict Glaw a écrit:
> On Fri, 2013-09-20 20:51:37 +0200, Jan-Benedict Glaw
> wrote:
>> Hi!
>>
>> With the VAX target, I see this warning:
>>
>> g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
>> -fno-rtti -fasynchrono
Hi Mike,
I must say though, it seems wrong to have to provide a sign-extend pointer
pattern when pointers (on the MSP430) are unsigned.
Agreed. If we instead ask, is it sane for gcc to ever want to signed extend in
this case, the answer appears to be no. Why does it, ptr_mode is SImode, an
> Like the following.
>
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>
> Richard.
>
> 2013-09-26 Richard Biener
>
> * alias.h (component_uses_parent_alias_set): Rename to ...
> (component_uses_parent_alias_set_from): ... this.
> * alias.c (component_uses_par
> below is a trivial patch, which makes both parts of test signed.
> With this, bootstrap completes on powerpc-darwin9 - however, you might want
> to check that it still does what you intended.
Please install under PR middle-end/58547 if not already done.
--
Eric Botcazou
On Thu, Sep 26, 2013 at 6:07 PM, Andrew MacLeod wrote:
> On 09/25/2013 04:49 AM, Richard Biener wrote:
>>
>> On Tue, Sep 24, 2013 at 4:39 PM, Andrew MacLeod
>> wrote:
>>>
>>> This larger patch moves all the immediate use and operand routines from
>>> tree-flow.h into tree-ssa-operands.h.
>>> It a
> Thanks for the testing. It also passes bootstrap on x86_64-linux-gnu.
> OK to install?
Yes, thanks.
--
Eric Botcazou
> They don't need to be kept synchronised as such. It's fine for the index
> to allow more than must_be_index_p. But if you're not keen on the current
> structure, does the following look better? Tested on x86_64-linux-gnu.
>
> Thanks,
> Richard
>
>
> gcc/
> * rtlanal.c (must_be_base_p,
> Sure, but the modifier is not meant to force something into memory,
> especially when it is already in an register. Remember, we are only
> talking of structures here, and we only want to access one member.
>
> It is more the other way round:
> It says: "You do not have to load the value in a re
On Fri, Sep 27, 2013 at 7:07 AM, bin.cheng wrote:
>
>
>> -Original Message-
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>> Sent: Tuesday, September 24, 2013 6:31 PM
>> To: Bin Cheng
>> Cc: GCC Patches
>> Subject: Re: [PATCH]Fix computation of offset in ivopt
>>
>> On Tue, S
On Fri, Sep 27, 2013 at 12:23 AM, Jan Hubicka wrote:
>> Hi,
>>
>> builtin_expect should be a NOP in size_estimation. Indeed, the call
>> stmt itself is 0 weight in size and time. But it may introduce
>> an extra relation expr which has non-zero size/time. The end result
>> is: for w/ and w/o built
On Thu, Sep 26, 2013 at 9:35 PM, Aldy Hernandez wrote:
>> + /* To distinguish from an OpenMP simd clone, Cilk Plus functions to
>> + be cloned have a distinctive artificial label in addition to "omp
>> + declare simd". */
>> + bool cilk_clone = flag_enable_cilkplus
>> +&& lookup_att
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of bin.cheng
> Sent: Friday, September 27, 2013 1:07 PM
> To: 'Richard Biener'
> Cc: GCC Patches
> Subject: RE: [PATCH]Fix computation of offset in ivopt
>
>
>
> > -Origin
72 matches
Mail list logo
