And excuse me, I am not quite familiar with adding testsuite, so during
I am trying, welcome any related ideas, suggestions or completions.
Thanks.
On 9/28/14 3:08, Chen Gang wrote:
> I guess it is not in our test case, or after this patch, the new
> should get a little better result than the ol
>
> Hi.
>
> Thank you Markus for presenting numbers, it corresponds with I measured. If I
> see correctly, IPA ICF pass takes about 7 seconds,
> the rest is distributed in verifier (not interesting for release version of
> the compiler) and 'phase opt and generate'. No idea
> what can make the
On Mon, Sep 22, 2014 at 04:20:12PM -0600, Jeff Law wrote:
> Can you add a testcase which shows the 3-insn combination from PR62151
> applying?
I've tried to make a stable future-proof testcase that does such a three-insn
combination. Not easy at all.
But now it dawns on me: do you just want the
On 23/09/14 01:58, Jiong Wang wrote:
> On 22/09/14 16:43, Kugan wrote:
>
>> AArch64 has the same issue ARM had where the LR register was not used in
>> leaf functions. This was reported in
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42017. In AArch64, this
>> test-case need to be added with
I guess it is not in our test case, or after this patch, the new
should get a little better result than the old (at present, they are
same).
I shall try to add related case into testsuite within this month.
Thanks
Send from Lenovo A788t.
Michael Eager wrote:
>On 09/25/14 07:03, Chen Gang wrot
On Sat, Sep 27, 2014 at 08:45:18PM +0200, Oleg Endo wrote:
> On Sat, 2014-09-27 at 11:10 -0700, Andi Kleen wrote:
> > From: Andi Kleen
> >
> > In my tests the optimized glibc out of line strcmp is always faster than
> > using inline rep ; cmpsb, even for small strings. The Intel optimization
> >
On Sat, 2014-09-27 at 11:10 -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> In my tests the optimized glibc out of line strcmp is always faster than
> using inline rep ; cmpsb, even for small strings. The Intel optimization
> manual
> also recommends to not use it. So remove the cmpstrnsi instru
On 25 September 2014 13:39, Dodji Seketeli wrote:
>> 2) In the Fortran FE, which gives quite precise location information
>> by tracking the characters that it wants to warn about instead of
>> relying on the line-map machinery.
>
> So with this feature, the Fortran FE would then use the then more
Hello,
This patch enables the streaming of LTO bytecode, needed by offload target,
using existing LTO infrastructure. It creates new prefix for the section names
(.gnu.target_lto_) and streams out the functions and variables with "omp declare
target" attribute, including the functions for outline
From: Andi Kleen
In my tests the optimized glibc out of line strcmp is always faster than
using inline rep ; cmpsb, even for small strings. The Intel optimization manual
also recommends to not use it. So remove the cmpstrnsi instruction.
Tested on Sandy Bridge, Westmere Intel CPUs.
gcc/:
2014-
From: Andi Kleen
The peephole that removes the code to compute a tristate for cmpstrnsi
when only a boolean jump is needed never triggers in my tests. Just
remove it.
gcc/:
2014-09-27 Andi Kleen
* config/i386/i386.md: Remove peepholes for cmpstrn*.
---
gcc/config/i386/i386.md | 77
On Sat, Sep 27, 2014 at 06:45:21PM +0200, Dominique d'Humières wrote:
> I think the patch for gcc.target/i386/nop-mcount.c should be
True. Thanks.
-Andi
2014-09-27 Gleb Fotengauer-Malinovskiy
libitm/
PR libitm/61164
* local_atomic (__always_inline): Add inline.
(__calculate_memory_order): Remove inline.
(atomic_thread_fence): Likewise.
(atomic_signal_fence): Likewise.
(atomic_flag_test_and_set_expl
Le 27 sept. 2014 à 18:45, Dominique d'Humières a écrit :
> I think the patch for gcc.target/i386/nop-mcount.c should be
>
> --- ../_clean/gcc/testsuite/gcc.target/i386/nop-mcount.c 2014-09-26
> 23:29:45.0 +0200
> +++ gcc/testsuite/gcc.target/i386/nop-mcount.c2014-09-27
>
On 25 September 2014 11:34, Dodji Seketeli wrote:
>> When the caret line is disabled with -fno-diagnostics-show-caret, the
>> fix-it hint is printed as:
>>
>> gcc/testsuite/g++.dg/template/crash83.C:5:21: error: an explicit
>> specialization must be preceded by 'template <>'
>> gcc/testsuite/g++.d
On Sat, Sep 27, 2014 at 01:21:29PM +0200, Dominique Dhumieres wrote:
> The new tests fail on darwin:
>
> /opt/gcc/work/gcc/testsuite/gcc.target/i386/nop-mcount.c:1:0: error:
> -mnop-mcount is not implemented for -fPIC
>
> and gcc.target/i386/record-mcount.c fails because mcount_loc is not found
Thanks for the explaination.
I have changed the loop_depth into a short interger hoping that we can
save some memory :-)
Attached please find the updated patch. Bootstrapped and reg-tested on
x86_64-suse-linux.
Please do a final revew once the assignment is ready.
As for the new list walking inter
From: Andi Kleen
-fshort-double has crashes the compiler since 4.6 (see PR60410)
Since it's an obscure option that apparently nobody uses it the
best way to fix it seems to just remove it.
This prevents constant ICEs when running an gcc optimization flags
autotuner.
gcc/testsuite/:
2014-09-26
From: Andi Kleen
Make -Q --help print the --param default, min, max values, similar
to how it does print the defaults for other flags. This is useful
to let a option auto tuner automatically query all needed information
abourt gcc params (previously it needed to access the .def file in
the source
On 09/25/14 07:03, Chen Gang wrote:
Need use VOID instead of SI, or when real VOIDmode comes, it does not
match SImode, so cause issue. This patch can fix this issue and pass
testsuite.
The related test code ('void' will cause CALL instead of SET):
typedef void (*T)(void);
f1 ()
{
On Fri, 22 Aug 2014, Marc Glisse wrote:
On Fri, 22 Aug 2014, Jason Merrill wrote:
On 08/22/2014 03:24 PM, Marc Glisse wrote:
Note that there is a patch waiting for a review that makes us accept !v
for vector v:
Ah, indeed. I still think we might as well treat vectors the same as other
typ
2014-09-27 Gleb Fotengauer-Malinovskiy
libitm/
PR libitm/61164
* local_atomic (__always_inline): Add inline.
(__calculate_memory_order): Remove inline.
(atomic_thread_fence): Likewise.
(atomic_signal_fence): Likewise.
(atomic_flag_test_and_set_expl
The new tests fail on darwin:
/opt/gcc/work/gcc/testsuite/gcc.target/i386/nop-mcount.c:1:0: error:
-mnop-mcount is not implemented for -fPIC
and gcc.target/i386/record-mcount.c fails because mcount_loc is not found in
the assembly.
TIA
Dominique
The failures for the gfortran.dg/coarray_collectives_9.f90 are fixed
with the following patch:
--- ../_clean/gcc/testsuite/gfortran.dg/coarray_collectives_9.f90
2014-09-25 12:14:05.0 +0200
+++ gcc/testsuite/gfortran.dg/coarray_collectives_9.f90 2014-09-27
13:03:41.0 +0200
Hi Patrick,
the mingw/cygwin part your patch looks fine to me. Nevertheless I
have one question regarding to you. Do you have FSF papers for gcc
already? As I asked an overseer and he didn't found you on the list.
Regards,
Kai
On 09/27/2014 09:47 AM, Markus Trippelsdorf wrote:
> On 2014.09.27 at 07:59 +0200, Markus Trippelsdorf wrote:
>>
>>> It seems that in this case we reject too many of equality candidates?
>>> It think the original numbers was about 4-5% but later some equivalences was
>>> disabled because of devirt/
On 09/27/2014 07:59 AM, Markus Trippelsdorf wrote:
> On 2014.09.27 at 01:27 +0200, Jan Hubicka wrote:
>>> While a plain Firefox -flto build works fine. LTO/PGO build fails with:
>>>
>>> lto1: internal compiler error: in ipa_merge_profiles, at ipa-utils.c:540
>>> 0x7d6165 ipa_merge_profiles(cgraph_n
On 09/27/2014 01:27 AM, Jan Hubicka wrote:
>> While a plain Firefox -flto build works fine. LTO/PGO build fails with:
>>
>> lto1: internal compiler error: in ipa_merge_profiles, at ipa-utils.c:540
>> 0x7d6165 ipa_merge_profiles(cgraph_node*, cgraph_node*)
>> ../../gcc/gcc/ipa-utils.c:540
>>
Hmm, original massage bounced, resent, without html.
> From: bernd.edlin...@hotmail.de
> To: l...@redhat.com; gcc-patches@gcc.gnu.org
> CC: jos...@codesourcery.com
> Subject: RE: [PATCH] Fix PR preprocessor/58893 access to uninitialized memory
> Date: Sat, 27 Se
Hi Vlad,
Vladimir Makarov writes:
> I guess we achieved the consensus about the following patch to fix PR61360
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61360
>
> The patch was successfully bootstrapped and tested (w/wo
> -march=amdfam10) on x86/x86-64.
>
> Is it ok to commit to trunk?
>
On 27/09/14 08:56, Andrew Haley wrote:
> I may be guilty of missing a crucial point here, but: why do we care
> about having a small limit of static TLS variables?
>
> We surely could allocate, say, a megabyte of static TLS for each
> thread. We already allocate 64M for the thread-local malloc ar
I may be guilty of missing a crucial point here, but: why do we care
about having a small limit of static TLS variables?
We surely could allocate, say, a megabyte of static TLS for each
thread. We already allocate 64M for the thread-local malloc arena,
after all. It doesn't cost anything beyond
On 2014.09.27 at 07:59 +0200, Markus Trippelsdorf wrote:
>
> > It seems that in this case we reject too many of equality candidates?
> > It think the original numbers was about 4-5% but later some equivalences was
> > disabled because of devirt/aliasing issues. Do you compare it with gold ICF
> >
33 matches
Mail list logo
